Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 知道不同任务类型对应怎样的上下文、提问方式和验证方式。
- 能让 AI 参与测试生成与代码审查，而不是只生成业务代码。
- 学会通过 diff、日志和失败用例逐步压缩问题范围。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
50 分钟
Bug 修复任务的最小闭环
从最小复现开始，让 AI 围绕错误信息和目标行为工作。
60 分钟
新增功能时如何保持结构清晰
先有设计草图，再让 AI 落地局部实现，避免接口和状态管理失控。
55 分钟
重构时先守住测试
让 AI 提供重构草稿，但是否合并、如何拆步仍由你决定。
45 分钟
把 AI 用到 review 与文档同步
让 AI 输出变更摘要、风险点和手动验证说明，降低团队沟通成本。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
修 bug 的关键不是 prompt，而是复现
如果你不能稳定复现 bug，AI 也很难给出可靠修复。最好的输入不是“帮我看看哪里错了”，而是具体日志、复现步骤、怀疑范围和目标行为。
一旦最小复现和失败测试建立起来，AI 在定位和提出修复方案时会更有效。
新功能要先有骨架
让 AI 从零定义整套架构，风险通常很高。更好的做法是你先给出页面结构、接口边界、状态来源和验收标准，再让它补局部实现与样板代码。
这样得到的代码更容易融入原项目，也更容易通过 review。
review 是 AI 价值最被低估的部分
很多人只让 AI 写代码，却忽略它在解释 diff、指出潜在风险、补测试方向和整理发布说明上的价值。
在成熟团队里，AI 最稳定的收益往往出现在审查和验证阶段，而不是完全自动生成阶段。
Mission
为一个真实 bug 设计 AI 修复流程
选择你熟悉的一类 bug，例如表单校验错位或接口超时，写出最小复现、怀疑范围、修复目标和验证步骤。
- 先生成失败用例或手动复现步骤，再请求修复建议。
- 要求输出必须解释改动理由，而不是只给补丁。
- 把 review、测试和回归动作写进任务末尾。