考察点
这是 2026 年面试里替代「你会用 Copilot 吗」的新高频题，面试官默认候选人都用 AI，想区分的是「丢一句话让 AI 自由发挥」和「有一套工程化打法」的人。考察实质是你对 AI 能力边界的理解：AI 擅长执行，不擅长猜意图。追问常往「哪一步最不能省」「AI 写偏了怎么纠正」走。
参考答案
为什么直接「帮我写个 XX」会翻车
先讲反面教材。一句话需求丢给 AI，它会用自己训练分布里最常见的理解去补齐你没说的一切：目录结构、错误处理风格、依赖选型、接口命名。写出来往往「能跑但不对」——不符合你项目的分层约定，引入了你不想用的库，边界情况按它自己的想法处理。任务越大偏差越大，最后你花在读代码和返工上的时间超过了自己写。问题的根源是意图在对话里会漂移，而 AI 从不为歧义停下来问你，它只会自信地选一个答案。工作流的设计目标就是把「猜」从流程里挤出去。
第一步：Spec，把意图写死
动手前先用几句话写清楚要做什么：功能目标、输入输出、边界条件、不做什么。spec 不用长，但必须可验证——「列表接口支持按状态过滤，非法状态返回 400，不影响现有分页参数」就是好 spec，AI 没法瞎发挥。复杂功能我会让 AI 先复述一遍理解，对不上就改 spec，改到对齐为止。这一步花十分钟，能省后面一小时的返工。
第二步：Plan，方案先审后写
spec 定了让 AI 出实现方案：改哪几个文件、新增什么接口、数据怎么流转、有什么风险。这一步是人工 gate，必须看完再放行。AI 的方案常见毛病是过度工程——你要个过滤参数它给你抽象出三层策略模式——或者没看见项目里已有的轮子要重造。在 plan 阶段纠偏只要一句话，等代码写完再纠就是重写。Claude Code 的 plan mode 干的就是这件事：只调研出方案，不碰代码。
第三步：Todos，拆小步执行
确认的方案拆成一串独立可验证的小任务，逐个执行。拆小的原因很实际：上下文有限，AI 在一个长任务里跑到后半段会「忘记」前面的约束；而且小步出错好定位、好回滚，git 上每一步一个 commit，错了 reset 一步而不是推翻全部。每个 todo 完成就看一眼 diff，不对劲立刻打断，别等它一口气跑完八步再验收。
第四步：Verify，让机器和人各验一层
每个 todo 完成后两层验证。机器层：跑构建、类型检查、相关测试——这步要逼着 AI 自己跑，它的自我报告「已完成」不可信，测试绿了才算完。人工层：看 diff 的风格和意图，测试只证明没挂，不证明写得对、写得像这个项目的代码。全部完成后最后走一遍真实的端到端路径，AI 写的代码在「局部正确、集成翻车」上栽的跟头最多。
一句话总结这套打法
AI 是执行力拉满但零判断力的下属，你的角色从写代码变成：定义清楚要什么（spec）、审它的方案（plan）、控制节奏（todos）、守住质量底线（verify）。省掉任何一环，省下的时间都会加倍还回去。
可能的追问
- 四步里最不能省的是哪步？——verify。spec 写糙了还能在 verify 阶段兜住，没有验证环节的 AI 产出就是开盲盒，上线前总要有人为正确性负责。
- AI 中途写偏了怎么办？——别在原地反复用自然语言纠正，越纠上下文越乱；回到上一步：plan 偏了改 plan，spec 偏了改 spec，改完让它从新起点重新生成。
- 小任务也值得走全流程吗？——不值得。改个文案、加个日志直接干。这套流程是给「超过一次对话能装下的复杂度」准备的，流程成本要和任务规模匹配。