复杂任务怎么拆给 AI？先写 spec 再让 AI 实现是什么流程？
谁在问：二面·工程方法向；带团队的面试官尤其爱问，因为这直接决定异步派活能不能规模化
口语化问法
- 一个稍微复杂点的需求，你怎么拆了交给 AI？
- 你们用 spec-driven 那一套吗？具体是什么流程？
- 你怎么保证它做出来的东西是你想要的，而不是它以为你想要的？
考察意图
三层：
- 你是不是还在「一句话丢过去」阶段。同步陪跑时一句话够用，因为你随时能打断；一旦异步派活，一句话就等于放弃控制。面试官想知道你有没有跨过这道坎。
- 你写不写得出「可判定的完成判据」。这是本题真正的分水岭——绝大多数人的「规格」写的是做什么，漏的是怎么算做完了。
- 你有没有反向判断。2026 年规格先行已经是显学，人人都说好；能说出「什么时候不该写规格」的人，才证明是自己用过而不是听来的。
参考答案
60 分答案（及格线）
我一般不会一句话丢过去。先让它读相关代码，然后让它出一个实现计划，我看过计划、确认方向对了，再让它动手。改动大的会让它分步做，每步做完我看一眼再继续。这样比直接让它写要可控得多。
这是合格的直觉，方向完全对：探索与执行分开、先计划后实现、小步走。但它停在「我盯着」，一旦任务要异步派出去、或者要交给别人复用，这套就撑不住了。
90 分答案（有生产经验的回答）
先说我为什么要写规格：它换的是「返工成本 > 规格成本」的那部分任务。同步陪跑时不需要，因为我随时能喊停；异步派活时必须要，因为我不在，就得有一份东西替我判断它做对没有。
一份能用的规格最少三件事：目标（要什么）、约束（不许动什么、必须兼容什么）、完成判据（什么现象出现就算做完了）。第三条最容易漏也最值钱。举个反例：我们有次的需求写的是「加失败重试，超过三次进死信队列」，agent 交回来 CI 全绿，上线发现死信队列一条没有——因为判据只写了「要有死信队列」，没写「压测中入队计数必须大于 0」。判据不可判定，等于没有判据。
流程上我分四步：探索（只读不写，让它先说清现状和影响面）→ 计划（产出规格文件，我逐条改）→ 开一个全新会话执行（干净上下文，避免探索阶段的垃圾污染）→ 验证并提交。业界成体系的做法大同小异：有的是命令链式的（从项目铁律到规格、计划、任务清单，最近还加了一步「收敛」，专门拿现有代码去对照规格看偏了多少）；有的是三段审批式的（需求 → 设计 → 任务，阶段之间设人工审批门，需求还要求写成
WHEN [条件] THE SYSTEM SHALL [行为]这种能直接转成测试的句式）；有的是轻量四阶段。共同点比差异重要：都要求完成判据落成文件，都要求探索与执行分开。代价是什么：规格本身要写、要维护，而且规格会腐化——写完三周代码就漂走了。这正是为什么成熟工具链要加「收敛」这一步。
什么时候不该用：一句话能描述清楚的 diff，写规格是纯亏。这条官方文档里有原话可以背——「如果你能用一句话描述这个 diff，就别做计划」。我自己的阈值是：要动三个以上模块、或者要异步派出去，才写。
追问链
规格里最容易漏的是什么？
期望完成判据，而且必须可判定——看它能不能自动跑：「日志格式迁移完成」不合格，「解析器对全量样本解析成功率 100%」合格；「要有死信队列」不合格，「压测中死信入队计数 > 0」合格。第二漏项是负向约束：不许动什么、什么行为必须不变，模型不会自己知道哪些不能碰信号自发把判据往「能自动跑」上靠 → 真写过；答「漏需求细节」→ 还没意识到问题不在细节多少规格写好了，怎么保证执行时不跑偏？
期望三条按可靠性排：① 换会话执行，避开探索阶段的上下文污染；② 判定权要离开被判定者——测试可以它写，判定必须由确定性的东西说了算（跑测试、lint、压测断言），否则它优化的是「让测试通过」而非「让代码正确」；③ 确定性闸门不达标就阻塞回合，且要有次数上限（连续 8 次强制收尾）信号只答「多 review 几遍」→ 靠人力；说得出「写的和判的不能是同一个」→ 摸到了这题的本质规格自己会过期，你怎么处理？
期望承认它是有维护成本的资产：① 只写长期约束与判据，会随实现变的细节下沉到任务清单（清单是一次性的）→ ② 定期做收敛检查，拿现有代码对照规格列出偏移 → ③ 判据优先于描述：只有一样能保鲜就保判据，判据可以跑，描述只能读信号答「定期更新文档」→ 空的；提得出「哪部分保鲜、哪部分一次性」的分层 → 真维护过什么任务不值得写规格？
期望给判据不给清单。三类不值得：一句话能描述的 diff、探索性任务（自己都不知道要什么，先原型后规格）、判据写不出来的（性能调优的取舍、文案质量，只能人在环里）。值得的信号是：改动跨模块、要异步派、以后还会再做一遍——那规格就成了模板信号答「小任务不用」→ 太粗；说得出「探索性任务顺序反了会写出一份想当然的规格」→ 有过教训两周的迭代，你规格写了三天，产品说太慢，你怎么办？
期望不硬顶也不全让：① 先认——三天确实太长，规格合理占比约任务总时长的一成，超了就是在把设计当规格写 → ② 拆开谈：值钱的是完成判据与负向约束，半天能写完，剩下两天半是架构设计，那是设计评审的事 → ③ 给替代方案：半天出「判据 + 约束」的最小规格让 agent 先开工，设计并行推进，第一版跑出来再补，规格从「开工的前置门」变成「验收的对照物」信号硬答「写完才能开工，质量优先」→ 缺协作意识；讲得出「最小规格 + 并行推进」→ 在有交付压力的团队干过
评分要点
- 说得清规格先行换的是什么（返工成本 > 规格成本），而不是当成通用最佳实践
- 规格三要素齐全，且强调完成判据必须可判定
- 举得出「判据不可判定导致事故」的具体例子或反例
- 流程上体现探索与执行分开、换会话执行
- 承认代价：规格要维护、会腐化，并给出收敛/分层的应对
- 给得出反向判据（一句话能描述的 diff 不写规格）
- 追问「怎么防跑偏」时能说到判定权要独立
- 面对进度压力能给出「最小规格 + 并行」的取舍方案，而不是硬顶或全让