如何跟着 AI 写的代码学习
先建立问题，再读实现
第一次阅读可以按 45 分钟安排：用 10 分钟读项目全景和需求，用 15 分钟走销售同比案例，用 10 分钟理解架构和模块边界，再用 10 分钟选择 V0 第一个任务。这是阅读建议，不是开发工期。
之后采用三遍阅读：
| 次数 | 读什么 | 你应该产出什么 |
|---|---|---|
| 第一遍：业务 | 用户故事、样例数据、验收 | 一句话解释输入与输出 |
| 第二遍：结构 | API、DTO、编排、Repository | 一张不看代码也能画出的调用图 |
| 第三遍：机制 | 核心函数、失败处理、测试 | 一个能修改、预测并验证的实验 |
代码尚未生成时
先学习“接口应该承诺什么”。例如检索模块应返回对象 ID、版本、排名与证据，不应只返回一段文本。问自己：缺少版本时，发布新 schema 后如何避免取到旧字段？这个问题会自然引出版本过滤与重建任务。
手册中的 server/... 是规划路径。看到“设计示例”时，应把它视为待实现契约；只有 代码索引 中标注已实现并带证据的条目，才可以当作真实实现导读。
每次开发形成一个学习闭环
- 从 计划 选一个依赖满足的未完成任务。
- 使用 AI 执行模板，让 AI 解释业务行为和关键边界。
- 先预测正常与错误输入的输出，再运行测试。
- 按请求流读三到五个关键函数，追踪 ID、版本和权限如何传递。
- 改动一个条件，复现一个失败，解释为什么负责模块应在这里阻断。
- 填证据、更新真实代码入口、勾选任务，用两分钟复述。
判断自己是否真的理解
不要用“这个模块用了工厂模式”结束解释。继续回答：它隔离了哪个变化？移除它会怎样？为何此时不需要更复杂的模式？
以 SearchRepository 为例：业务编排要“找 schema”，不需要知道 Milvus collection 或 OpenSearch DSL。接口既隔离 SDK，也让融合和降级的输出格式一致。如果只为一个永不替换的函数加五层抽象，却不能解释边界收益，应简化设计。
面试材料如何积累
每完成一个故事记录：遇到的具体失败、最小复现数据、方案、备选方案、测试、实测与代价。只有你能复现和解释的内容才放入项目经历。详见 面试叙事 与 问题练习。