Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 理解什么任务适合交给 AI，什么任务应该由人类主导。
- 知道为什么“会运行”不等于“可维护”。
- 学会把 AI 输出放进正常的工程流程，而不是绕过流程。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
Course Content
正式课程内容
下面这部分才是这个阶段真正要读、要练、要做的正文。建议先顺序读，再回头做 mission 和 quiz。
这一阶段的重点是把 AI 放回它应有的位置：它是高效率协作者，不是责任承担者。只要你把任务边界、验证标准和人工复核点放清楚，AI 就能变成极强的提速器。
如果你把这些责任全部外包给 AI，最后得到的往往不是“省时间”，而是“技术债提速器”。所以这阶段要建立的是协作习惯，不是工具崇拜。
哪些任务最适合交给 AI
先识别高收益场景，再让 AI 发挥价值，而不是什么都让它做。
这一课要掌握什么
- 识别最适合 AI 的任务类型。
- 区分模式化工作与强判断工作。
- 建立优先把 AI 用在高回报场景的意识。
正式讲解
AI 最稳定的价值通常出现在模式明显、规则清楚、可快速验证的任务上。比如生成初版测试、整理重复代码、解释错误日志、补文档骨架、梳理接口结构，这些任务都容易获得高质量回报。
相反，跨团队协调、长期架构决策、复杂业务取舍、兼容历史系统等任务，虽然 AI 也能参与，但它不能代替人拍板。它更适合先帮你列选项、提风险、找遗漏，再由你做最后判断。
所以最好的提问不是“AI 能不能做”，而是“这件事里哪一部分适合交给 AI 做初版，哪一部分必须保留人工判断”。
Practice
练习：给任务做 AI 适配度判断
- 列出 5 个你常做的开发任务。
- 标记哪些适合交给 AI 先做草稿，哪些必须人主导。
- 写下判断原因。
Homework
课后作业：哪些任务最适合交给 AI
- 用你自己的话重写这一课的核心观点，不要照抄正文。
- 围绕“哪些任务最适合交给 AI”设计一个你所在项目或练习场景中的应用例子。
- 把这节课的内容整理成一份可以直接交给 AI 或同伴执行的小任务单。
交付一份包含概念解释、场景示例和执行清单的学习笔记。
Test
如果你真的理解了“哪些任务最适合交给 AI”，你能不能在一个新场景里复用它？
你应该能回答
- 请不用原文措辞，解释这节课最重要的一条判断。
- 请给出一个容易做错的反例，并说明为什么错。
- 请描述你会如何在真实任务里验证自己已经学会这节课。
通过标准
- 能准确复述核心概念，而不是只会摘抄名词。
- 能举出至少一个真实工作流中的应用方式。
- 能说清怎样验证自己不是“看懂了但做不出来”。
Evaluation
优秀
你能把这节课的方法迁移到新问题中，并主动指出常见误区与验证方法。
达标
你能解释核心概念，并在给定场景里按步骤使用它。
还需加强
你还停留在记定义阶段，遇到真实问题时不知道该如何落地。
学完自检
- 我知道 AI 最擅长什么类型的工作。
- 我不会把战略判断任务完全交给 AI。
- 我开始从任务拆分角度使用 AI。
如何给上下文
有效上下文不是越多越好，而是刚好覆盖当前决策需要的最小闭环。
这一课要掌握什么
- 理解什么叫最小闭环上下文。
- 知道如何筛选相关文件和信息。
- 学会避免“整仓库倾倒式输入”。
正式讲解
很多新手的第一个错误，就是把整个项目都丢给 AI，然后希望它自己提炼重点。实际上，模型和人一样，如果被迫在大量无关信息里找关键点，效果通常会下降。
最小闭环上下文的意思是：给出完成当前任务必须知道的信息，但不要附加太多与这次决策无关的噪声。比如你在修一个表单 bug，通常需要的是复现步骤、相关组件、相关接口、不能破坏的行为和当前报错，而不是整个仓库历史。
当你能稳定给出这种上下文，AI 结果会明显更贴近项目实际，因为它知道这次要在什么范围内负责。
Practice
练习：筛上下文
- 选一个具体功能或 bug。
- 列出 10 条你知道的信息。
- 删到只剩完成当前任务必须知道的 4 到 6 条。
Homework
课后作业：如何给上下文
- 用你自己的话重写这一课的核心观点，不要照抄正文。
- 围绕“如何给上下文”设计一个你所在项目或练习场景中的应用例子。
- 把这节课的内容整理成一份可以直接交给 AI 或同伴执行的小任务单。
交付一份包含概念解释、场景示例和执行清单的学习笔记。
Test
如果你真的理解了“如何给上下文”，你能不能在一个新场景里复用它？
你应该能回答
- 请不用原文措辞，解释这节课最重要的一条判断。
- 请给出一个容易做错的反例，并说明为什么错。
- 请描述你会如何在真实任务里验证自己已经学会这节课。
通过标准
- 能准确复述核心概念，而不是只会摘抄名词。
- 能举出至少一个真实工作流中的应用方式。
- 能说清怎样验证自己不是“看懂了但做不出来”。
Evaluation
优秀
你能把这节课的方法迁移到新问题中，并主动指出常见误区与验证方法。
达标
你能解释核心概念，并在给定场景里按步骤使用它。
还需加强
你还停留在记定义阶段，遇到真实问题时不知道该如何落地。
学完自检
- 我能筛出相关上下文。
- 我不再默认整仓库都要喂给 AI。
- 我能解释某条信息为什么对当前任务有用。
先 review，再相信
AI 输出不是终稿，而是待审稿。review 是接收结果前的必要动作。
这一课要掌握什么
- 理解 review 在 AI 编程里的必要性。
- 学会看 diff、看测试、看边界条件。
- 建立接收 AI 改动前的最小检查动作。
正式讲解
AI 给出的代码再顺眼，也不能跳过 review。因为真正需要审查的不是“代码像不像高手写的”，而是“它改了什么、有没有破坏原行为、有没有留下边界漏洞”。
最小的 review 流程通常包括三步：先看 diff，确认改动范围是否合理；再跑测试或构建，确认没有直接报错；最后检查关键边界条件，比如空状态、异常输入、兼容行为是否还成立。
当你把这套动作固定下来，AI 输出就会越来越可控。否则你会频繁遇到“看起来不错，上线后出问题”的典型返工。
Practice
练习：做一次最小 review
- 找一段 AI 生成的代码或补丁。
- 先描述 diff 改了什么，再写 3 个你担心的风险点。
- 列出至少 2 个你会验证的边界条件。
Homework
课后作业：先 review，再相信
- 用你自己的话重写这一课的核心观点，不要照抄正文。
- 围绕“先 review，再相信”设计一个你所在项目或练习场景中的应用例子。
- 把这节课的内容整理成一份可以直接交给 AI 或同伴执行的小任务单。
交付一份包含概念解释、场景示例和执行清单的学习笔记。
Test
如果你真的理解了“先 review，再相信”，你能不能在一个新场景里复用它？
你应该能回答
- 请不用原文措辞，解释这节课最重要的一条判断。
- 请给出一个容易做错的反例，并说明为什么错。
- 请描述你会如何在真实任务里验证自己已经学会这节课。
通过标准
- 能准确复述核心概念，而不是只会摘抄名词。
- 能举出至少一个真实工作流中的应用方式。
- 能说清怎样验证自己不是“看懂了但做不出来”。
Evaluation
优秀
你能把这节课的方法迁移到新问题中，并主动指出常见误区与验证方法。
达标
你能解释核心概念，并在给定场景里按步骤使用它。
还需加强
你还停留在记定义阶段，遇到真实问题时不知道该如何落地。
学完自检
- 我先看 diff 再看代码细节。
- 我会跑测试或构建。
- 我会主动查边界条件。
让 AI 成为提速器，而不是技术债放大器
速度必须建立在结构清晰和持续可维护的前提上。
这一课要掌握什么
- 理解技术债为什么会被 AI 放大。
- 知道哪些结构性问题需要人守住。
- 学会把一致性和命名质量纳入日常要求。
正式讲解
AI 很容易快速产出大量代码，但它不会天然替你维护长期一致性。如果你自己都没有明确的模块边界、命名规范、目录约定和测试标准，AI 只会把混乱加速放大。
所以真正成熟的用法不是“让 AI 自由发挥”，而是让它在规则内提速。规则包括命名一致、抽象边界稳定、接口契约清楚、测试覆盖关键路径，以及每次改动都能被回顾。
你可以把 AI 想成一位非常快但非常依赖任务约束的执行助手。没有规则时，它可能看起来高效，长期却会把项目推向更难维护的方向。
Practice
练习：给项目写一份 AI 协作规则
- 写 5 条你希望 AI 始终遵守的项目规则。
- 至少覆盖命名、目录、接口、测试和 review。
- 检查这些规则是否足够具体。
Homework
课后作业：让 AI 成为提速器，而不是技术债放大器
- 用你自己的话重写这一课的核心观点，不要照抄正文。
- 围绕“让 AI 成为提速器，而不是技术债放大器”设计一个你所在项目或练习场景中的应用例子。
- 把这节课的内容整理成一份可以直接交给 AI 或同伴执行的小任务单。
交付一份包含概念解释、场景示例和执行清单的学习笔记。
Test
如果你真的理解了“让 AI 成为提速器，而不是技术债放大器”，你能不能在一个新场景里复用它？
你应该能回答
- 请不用原文措辞，解释这节课最重要的一条判断。
- 请给出一个容易做错的反例，并说明为什么错。
- 请描述你会如何在真实任务里验证自己已经学会这节课。
通过标准
- 能准确复述核心概念，而不是只会摘抄名词。
- 能举出至少一个真实工作流中的应用方式。
- 能说清怎样验证自己不是“看懂了但做不出来”。
Evaluation
优秀
你能把这节课的方法迁移到新问题中，并主动指出常见误区与验证方法。
达标
你能解释核心概念，并在给定场景里按步骤使用它。
还需加强
你还停留在记定义阶段，遇到真实问题时不知道该如何落地。
学完自检
- 我知道哪些结构问题必须人来守。
- 我有最小项目规则。
- 我不会把提速建立在牺牲可维护性上。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
AI 适合做什么
AI 特别适合处理模式明显、标准清晰、可快速验证的工作，例如生成初版测试、补齐文档、批量重构、解释错误日志或整理 API 结构。
当任务需要强业务判断、长期架构权衡、兼容历史包袱或跨团队协作时，AI 仍然可以参与，但不能替代人做主导。
高质量协作的最小动作
在真实项目里，你需要形成一套固定动作：先定义任务，再给上下文，再要求输出包含测试或验证方式，最后通过代码审查和实际运行做结论。
一旦把这些动作固定下来，AI 的产出会稳定很多，因为它知道自己是在工程流程里工作，而不是在做一次性演示。
为什么流程感比提示词技巧更重要
很多新手把注意力放在“有没有神奇 prompt”，但高手真正依赖的是流程模板。流程能保证复用、审查、协作和持续改进，这才是可扩展的方法。
后面进入 Codex CLI 后，你会看到命令本身并不复杂，复杂的是你是否能持续给出高质量任务输入。
Mission
把一个 bug 修复任务写成 AI 可执行任务
假设表单提交按钮点击后无响应，请把问题描述、可能范围、期望修复和验证方式整理成一份任务单。
- 先写用户层面的症状，再写你怀疑受影响的模块或文件。
- 明确说明不能破坏哪些已有行为，例如校验规则和埋点。
- 要求输出必须包含测试建议或最小验证步骤。