Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 理解什么任务适合交给 AI，什么任务应该由人类主导。
- 知道为什么“会运行”不等于“可维护”。
- 学会把 AI 输出放进正常的工程流程，而不是绕过流程。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
40 分钟
哪些任务最适合交给 AI
样板代码、测试模板、重构草稿、文档同步和问题排查，是最容易获得稳定收益的类型。
45 分钟
如何给上下文
不是把整个仓库喂给 AI，而是要提供当前决策需要的最小闭环信息。
50 分钟
先 review，再相信
阅读 diff、跑测试、验证边界条件，是每次接收 AI 改动的最小动作。
45 分钟
让 AI 成为提速器，而不是技术债放大器
命名、抽象边界、架构一致性和接口稳定性，仍然要由你做最终判断。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
AI 适合做什么
AI 特别适合处理模式明显、标准清晰、可快速验证的工作，例如生成初版测试、补齐文档、批量重构、解释错误日志或整理 API 结构。
当任务需要强业务判断、长期架构权衡、兼容历史包袱或跨团队协作时，AI 仍然可以参与，但不能替代人做主导。
高质量协作的最小动作
在真实项目里，你需要形成一套固定动作：先定义任务，再给上下文，再要求输出包含测试或验证方式，最后通过代码审查和实际运行做结论。
一旦把这些动作固定下来，AI 的产出会稳定很多，因为它知道自己是在工程流程里工作，而不是在做一次性演示。
为什么流程感比提示词技巧更重要
很多新手把注意力放在“有没有神奇 prompt”，但高手真正依赖的是流程模板。流程能保证复用、审查、协作和持续改进，这才是可扩展的方法。
后面进入 Codex CLI 后，你会看到命令本身并不复杂，复杂的是你是否能持续给出高质量任务输入。
Mission
把一个 bug 修复任务写成 AI 可执行任务
假设表单提交按钮点击后无响应，请把问题描述、可能范围、期望修复和验证方式整理成一份任务单。
- 先写用户层面的症状，再写你怀疑受影响的模块或文件。
- 明确说明不能破坏哪些已有行为，例如校验规则和埋点。
- 要求输出必须包含测试建议或最小验证步骤。