Appearance
4.7 AI 编程实战工作流
前面几节讲的是 Claude Code 的功能。这一节讲方法论——同样的工具，为什么有人用得行云流水，有人天天和 AI 互相折磨。区别不在工具，在工作流。
核心心法：你是技术负责人，AI 是执行者
把 AI 当成一个能力很强但不了解你项目、记性不长、偶尔自信地犯错的初级工程师。你的职责不是"提需求然后验收"，而是给清晰的规格、定边界、审查产出、给反馈。
💡 用得好不好，取决于你给的"输入质量"和"反馈质量"，而不是 AI 本身。
一、规格先行，不要让它猜
最常见的失败：需求一句话，AI 脑补一大堆。
❌ "帮我加个登录功能"
✅ "加手机号+验证码登录。验证码走已有的 SMS 服务（src/sms.ts）。
登录态用 JWT，复用 src/auth/jwt.ts 的工具函数。
失败要返回明确错误码。先别写前端，只做后端接口。"需求越含糊，AI 越容易做出"合理但不是你要的"东西（这正是 2.4 任务歧义 那种失控）。花两分钟写清规格，省半小时返工。
二、先计划，后执行
复杂任务，别让它直接动手。先让它输出方案，你确认后再写。
"先别改代码。告诉我你打算改哪些文件、大概怎么改、有没有风险点。
我确认后你再动手。"好处：在它跑偏之前就纠正，而不是等它改了 20 个文件你才发现方向错了。Claude Code 的计划模式就是为此设计的。
三、小步快跑，别让它一口气做完
一次让 AI 改一整个系统，你根本审不过来，它也容易在长链条里跑偏（推理雪崩）。
- 把大任务拆成能独立验证的小步
- 每步做完就看一眼、跑一下，对了再继续
- 一个独立任务用一个干净的会话，别在一个超长会话里做所有事（上下文污染）
四、给它反馈闭环：让它能自己发现错
AI 最强的时候，是它能看到自己改的对不对。
- 有测试就让它跑测试，红了自己修
- 能跑起来就让它运行/截图看效果（多模态，1.8）
- 报错直接把完整错误贴回去，别自己转述
"跑一下 pnpm test，如果有失败，自己分析并修复，直到全绿。"有反馈闭环的 AI，能力上一个台阶；没有的话，它只能"盲写"。
五、审查产出，别盲信
AI 写的代码默认当作需要 review 的 PR，重点看：
- 逻辑对不对（尤其边界条件）
- 有没有"为了能跑"偷偷改了不该改的东西
- 有没有引入多余依赖、删掉你要的代码
- 错误处理、安全（2.7）有没有漏
⚠️ 最危险的不是它写错——错的你能发现。最危险的是它写了看起来对、跑得过、但逻辑微妙错误的代码。所以关键逻辑一定要自己看懂。
六、用 CLAUDE.md 固化上下文
每次都重复交代技术栈、规范、禁区，很累。把这些写进项目根目录的 CLAUDE.md（4.4），AI 每次自动读取——相当于给那个"记性不长的初级工程师"一份常驻的入职手册。
七、知道什么时候自己上
AI 不是万能。出现这些信号，果断接管：
- 同一个问题它改了三四次还没对 → 它大概率理解错了，停下来重新讲清楚，或自己写
- 任务高度依赖你脑子里的隐性上下文 → 先把上下文显式写出来
- 很微妙的核心逻辑 / 高风险改动 → 自己写，让 AI 做周边（测试、文档）
🛠️ 实战练习：对比两种工作流
挑一个你最近要做的真实小需求，用两种方式各做一遍：
- 方式 A（随意）：一句话需求，让 AI 直接写。
- 方式 B（本节方法）：先写清规格 → 让它先给计划 → 确认后小步执行 → 跑测试闭环 → review。
对比：哪种返工少？哪种最终代码你更敢合并？把方式 B 里"最能减少返工的那一步"记下来，固化成你的习惯。
📌 关键结论
- 把自己当技术负责人，AI 当"强但健忘、会自信犯错"的执行者——产出质量取决于你的规格和反馈
- 规格先行、先计划后执行、小步快跑：在跑偏之前纠正，而不是事后救火
- 给 AI 反馈闭环（跑测试、跑程序、贴真实报错），它能力立刻上一个台阶
- AI 代码当 PR 审，警惕"看起来对但逻辑微错"的产出；核心逻辑自己看懂
- 用 CLAUDE.md 固化上下文；该接管时果断接管