Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 知道不同任务类型对应怎样的上下文、提问方式和验证方式。
- 能让 AI 参与测试生成与代码审查，而不是只生成业务代码。
- 学会通过 diff、日志和失败用例逐步压缩问题范围。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
Course Content
正式课程内容
下面这部分才是这个阶段真正要读、要练、要做的正文。建议先顺序读，再回头做 mission 和 quiz。
这一阶段的核心不是“让 AI 多写代码”，而是把不同开发场景都变成稳定的协作模板。修 bug、加功能、重构、补测试，看起来像四类问题，本质上都在考同一件事：你能不能把任务边界和验证标准说清楚。
只要你能做到“先界定问题，再让 AI 参与，再通过测试和 review 收口”，AI 在真实编码中的收益就会越来越稳定。
Bug 修复任务的最小闭环
真正有效的 bug 修复，不是先问 AI，而是先把问题缩成可复现、可验证的最小范围。
这一课要掌握什么
- 知道 bug 修复为什么要从复现开始。
- 理解日志、失败测试和目标行为的作用。
- 学会写一份可执行的 bug 修复任务单。
正式讲解
如果一个问题连你自己都不能稳定复现，AI 也很难修得准。最小复现不是形式主义，而是在回答：这个 bug 的边界到底在哪里。
修 bug 时最有价值的输入通常是三类：复现步骤、错误日志、目标行为。复现步骤告诉系统“怎么触发问题”，错误日志告诉系统“实际发生了什么”，目标行为告诉系统“正确结果应该是什么”。
所以成熟做法不是“帮我看看哪里错了”，而是把问题压缩到最小闭环，再让 AI 在这个闭环内提出修复思路和补丁。
Practice
练习：为一个 bug 写最小修复说明
- 写出 3 步以内的复现流程。
- 补上当前错误表现和目标行为。
- 要求修复输出必须附带验证方法。
Homework
课后作业：Bug 修复任务的最小闭环
- 选一个真实功能或 bug，把这节课的方法应用一遍。
- 记录你让 AI 参与的部分，以及你自己保留判断的部分。
- 补一份最小验证清单，确保这节课不是只停留在“会说”。
交付一份真实任务记录，包含改动目标、AI 参与方式和验证结果。
Test
你能不能把这节课的方法用到一个陌生但相似的问题上？
你应该能回答
- 请说明这节课最关键的工作流顺序。
- 请举例说明如果跳过验证会发生什么。
- 请给出一个你会保留人工判断的节点。
通过标准
- 能说清正确顺序，而不是只记住几个动作名词。
- 知道这节课最主要的风险点。
- 能把 AI 和人工判断分工讲明白。
Evaluation
优秀
你已经能把这节课的方法稳定迁移到真实开发任务中，并主动补验证。
达标
你能在给定场景里按步骤完成任务，并识别主要风险。
还需加强
你还容易把 AI 当作自动完成器，没有把验证和人工判断守住。
学完自检
- 我先写复现，而不是先求补丁。
- 我能区分现象、日志和目标行为。
- 我会把验证写进 bug 任务。
新增功能时如何保持结构清晰
做新功能时先给骨架，再让 AI 填局部实现，能显著降低后期返工。
这一课要掌握什么
- 理解为什么新功能不能让 AI 从零拍脑袋设计整套结构。
- 学会先定义页面、接口和状态边界。
- 知道如何让 AI 只填最适合它的部分。
正式讲解
新增功能失败，往往不是代码写不出来，而是结构一开始就没定清楚。页面谁负责、状态从哪里来、接口怎么定义、哪些行为必须兼容，这些问题如果不先收敛，AI 就会按自己的猜测补空白。
更稳的做法是你先给出功能骨架：用户路径、关键页面、数据流、组件边界、验收标准。然后再让 AI 帮你补局部实现、样板代码和测试草稿。
这样做的好处是，你把“系统该长成什么样”牢牢掌握在自己手里，而 AI 专注做它最擅长的高效率生成。
Practice
练习：画一条功能切片骨架
- 挑一个功能，例如“新增收藏夹”。
- 写出页面、状态、接口、测试四层骨架。
- 标出你会交给 AI 先做的 2 个小块。
Homework
课后作业：新增功能时如何保持结构清晰
- 选一个真实功能或 bug，把这节课的方法应用一遍。
- 记录你让 AI 参与的部分，以及你自己保留判断的部分。
- 补一份最小验证清单，确保这节课不是只停留在“会说”。
交付一份真实任务记录，包含改动目标、AI 参与方式和验证结果。
Test
你能不能把这节课的方法用到一个陌生但相似的问题上？
你应该能回答
- 请说明这节课最关键的工作流顺序。
- 请举例说明如果跳过验证会发生什么。
- 请给出一个你会保留人工判断的节点。
通过标准
- 能说清正确顺序，而不是只记住几个动作名词。
- 知道这节课最主要的风险点。
- 能把 AI 和人工判断分工讲明白。
Evaluation
优秀
你已经能把这节课的方法稳定迁移到真实开发任务中，并主动补验证。
达标
你能在给定场景里按步骤完成任务，并识别主要风险。
还需加强
你还容易把 AI 当作自动完成器，没有把验证和人工判断守住。
学完自检
- 我先画骨架再写实现。
- 我能说明状态和接口边界。
- 我不会把整套结构设计外包给 AI。
重构时先守住测试
重构不是追求更漂亮，而是追求行为不变、结构更清晰。
这一课要掌握什么
- 理解重构和重写的区别。
- 知道为什么重构必须先守住测试。
- 学会把重构拆成可验证的小步。
正式讲解
AI 很擅长提出重构建议，但重构的风险也很高，因为它很容易在“看起来更整洁”的同时悄悄改变行为。没有测试兜底，你几乎无法判断这些变化到底是优化还是回归。
重构时最好的顺序通常是：先补最小行为测试，再要求 AI 给出小步重构方案，而不是一次性大改。这样每走一步都能验证系统还在原来的轨道上。
你要记住，重构不是为了让代码符合某种美学，而是为了让系统更好维护，同时保持对外行为稳定。
Practice
练习：把一次重构拆成 3 步
- 选择一段你觉得混乱的逻辑。
- 先列出需要守住的行为。
- 把重构拆成 3 个可独立验证的小步骤。
Homework
课后作业：重构时先守住测试
- 选一个真实功能或 bug，把这节课的方法应用一遍。
- 记录你让 AI 参与的部分，以及你自己保留判断的部分。
- 补一份最小验证清单，确保这节课不是只停留在“会说”。
交付一份真实任务记录，包含改动目标、AI 参与方式和验证结果。
Test
你能不能把这节课的方法用到一个陌生但相似的问题上？
你应该能回答
- 请说明这节课最关键的工作流顺序。
- 请举例说明如果跳过验证会发生什么。
- 请给出一个你会保留人工判断的节点。
通过标准
- 能说清正确顺序，而不是只记住几个动作名词。
- 知道这节课最主要的风险点。
- 能把 AI 和人工判断分工讲明白。
Evaluation
优秀
你已经能把这节课的方法稳定迁移到真实开发任务中，并主动补验证。
达标
你能在给定场景里按步骤完成任务，并识别主要风险。
还需加强
你还容易把 AI 当作自动完成器，没有把验证和人工判断守住。
学完自检
- 我先守行为再谈重构。
- 我能把重构拆小。
- 我不会把“更好看”当成唯一标准。
把 AI 用到 review 与文档同步
AI 在 review、风险总结和变更说明上的收益，常常比直接写业务代码更稳定。
这一课要掌握什么
- 理解 AI 在审查与说明层的价值。
- 知道怎样让 AI 生成变更摘要和风险点。
- 把文档同步视为正式交付的一部分。
正式讲解
很多人把 AI 当成“代码生成器”，却忽略它在 review 与文档层的价值。实际上，变更摘要、风险点列表、手动验证说明、发布备注，往往更适合 AI 来帮你起草，因为这些内容模式明显、又容易让人遗漏。
当你让 AI 先总结 diff，再列风险，再补验证清单，你会明显减少沟通成本。特别是在团队协作里，这一步能让 review 更快聚焦到真正重要的问题。
同样，文档同步也不该被看成‘可有可无’。AI 很适合先帮你更新 README、变更说明和操作说明，再由你校正事实与边界。
Practice
练习：为一段改动生成交付说明
- 选一个你最近做过的小改动。
- 写出变更摘要、风险点和验证说明三个部分。
- 判断哪部分最适合交给 AI 先起草。
Homework
课后作业：把 AI 用到 review 与文档同步
- 选一个真实功能或 bug，把这节课的方法应用一遍。
- 记录你让 AI 参与的部分，以及你自己保留判断的部分。
- 补一份最小验证清单，确保这节课不是只停留在“会说”。
交付一份真实任务记录，包含改动目标、AI 参与方式和验证结果。
Test
你能不能把这节课的方法用到一个陌生但相似的问题上？
你应该能回答
- 请说明这节课最关键的工作流顺序。
- 请举例说明如果跳过验证会发生什么。
- 请给出一个你会保留人工判断的节点。
通过标准
- 能说清正确顺序，而不是只记住几个动作名词。
- 知道这节课最主要的风险点。
- 能把 AI 和人工判断分工讲明白。
Evaluation
优秀
你已经能把这节课的方法稳定迁移到真实开发任务中，并主动补验证。
达标
你能在给定场景里按步骤完成任务，并识别主要风险。
还需加强
你还容易把 AI 当作自动完成器，没有把验证和人工判断守住。
学完自检
- 我开始让 AI 参与 review 说明。
- 我会补风险点和验证说明。
- 我把文档同步当成交付的一部分。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
修 bug 的关键不是 prompt，而是复现
如果你不能稳定复现 bug，AI 也很难给出可靠修复。最好的输入不是“帮我看看哪里错了”，而是具体日志、复现步骤、怀疑范围和目标行为。
一旦最小复现和失败测试建立起来，AI 在定位和提出修复方案时会更有效。
新功能要先有骨架
让 AI 从零定义整套架构，风险通常很高。更好的做法是你先给出页面结构、接口边界、状态来源和验收标准，再让它补局部实现与样板代码。
这样得到的代码更容易融入原项目，也更容易通过 review。
review 是 AI 价值最被低估的部分
很多人只让 AI 写代码，却忽略它在解释 diff、指出潜在风险、补测试方向和整理发布说明上的价值。
在成熟团队里，AI 最稳定的收益往往出现在审查和验证阶段，而不是完全自动生成阶段。
Mission
为一个真实 bug 设计 AI 修复流程
选择你熟悉的一类 bug，例如表单校验错位或接口超时，写出最小复现、怀疑范围、修复目标和验证步骤。
- 先生成失败用例或手动复现步骤，再请求修复建议。
- 要求输出必须解释改动理由，而不是只给补丁。
- 把 review、测试和回归动作写进任务末尾。