当代码不再是瓶颈，研发流程就该重做一遍

最近读了 Anthropic 这篇长文：The AI-Native SDLC playbook。

说实话，刚看到标题时，我以为又是一篇“AI 如何改造软件开发”的标准大稿。名词很多，框架很全，里面还夹着 Claude Code、skills、hooks、managed settings 这些产品语汇。这样的文章，看多了容易麻。

但这篇我还是读完了。读完以后，真正留在我脑子里的，不是某个产品能力，也不是 intent.md、spec.md、plan.md 这些文件名，反而是一个更朴素的判断：代码生成提速之后，研发流程里最慢的那一段，已经换地方了。

以前团队默认的前提是，最稀缺的环节是“把需求翻成代码”。所以流程设计得很重，很正常。需求澄清、技术评审、测试、发布、交接，层层叠叠，都是为了围住那段最贵的生产环节。那时候写代码慢，前后多包几层，也说得过去。

现在中间那一段忽然快了，旧流程的笨重就会被放大。代码几分钟就能吐出来，需求还在口头来回传，验证还得靠人肉点，发布还卡在人工审批，线上问题还得有人抄成工单再回到研发。速度差一拉开，哪里堵，几乎一眼就能看见。

堵车的地方，已经不在 Build 了

Anthropic 在原文里放了一张图，我觉得挺到位：

图来自 Anthropic 原文。Build 这一段收缩得很快，前后的需求、评审、测试、发布还是按原来的节奏在走。

这件事拿修路来打比方最好懂。以前整条路都窄，谁也别嫌谁慢。现在中间忽然拓成了八车道，收费站、匝道口、红绿灯马上就刺眼了。大家这才发现，真正拖时间的，不一定是写代码，而是写代码前后的那一大圈人工动作。

所以这篇文章真正想解决的，不是“AI 还能多写多少”。它想解决的是另一件事：当 Build 变快以后，Plan、Review、Test、Deploy、Maintain 这些环节要不要跟着重写。

我觉得这个问题提得很对。很多团队今天的效能问题，不是 agent 不够强，而是流程接不住它的速度。

这篇文章最打动我的，不是工具，是三个判断

原文里有很多内容，但如果让我只留下三条，我会留这三条。

第一条：每个阶段都该留下一个下一棒能接住的东西

这篇文章虽然用了 intent.md、spec.md、plan.md 这些名字，但我觉得名字根本不重要。重要的是它把研发流程重新看成了一场接力，而不是一串聊天记录。

每一阶段结束时，都应该留下一个明确的 artifact：

• 人能看；
• agent 能读；
• 下一阶段能直接消费；
• 版本里能追溯。

以前很多团队也有文档、有票据、有审批记录，但那套东西更像留痕，不像接力。你真把它交给下一环，很多时候还是得靠人站在旁边解释半天。

这一点我很认同。流程如果只靠口头传递，最后一定卡在人身上。流程得靠产物接力，才能跑起来。

flowchart LR
    A[intent.md<br/>把想法说清楚] --> B[spec.md<br/>把约束和方案写清楚]
    B --> C[plan.md<br/>把改哪些文件和怎么验写清楚]
    C --> D[代码 + 测试<br/>开始实现]
    D --> E[PR / Review / Gate<br/>审风险、审合规、审发布]
    E --> F[监控 / 告警 / 线上事件]
    F -->|回写新一轮需求| A

这个图我喜欢，不是因为它形式完整，而是它提醒了一件常被忽略的事：聊天可以发散，流程不能发散。

第二条：规则不能只挂在文档里，得写进执行面

原文里反复提 CLAUDE.md、skills、hooks、managed settings。表面看像是 Anthropic 在讲产品组合拳，往下拆，其实就是一个很工程化的判断：规则别只留在纸面上，得进入运行时。

这几年很多团队都在补流程，但补法常常还是老路子：

• 规则写到 Wiki；
• 约束说在会上；
• 风险靠 review 时提醒；
• 高危操作靠“原则上不允许”。

这套东西一旦碰上 agent，马上就显得太软。因为 agent 不会“体会气氛”，它只会沿着允许的路径跑。你不把边界写进执行面，最后就只能在出事以后靠人来补锅。

所以这一条我也很认同：

• 团队约定，能落 repo 文件就别只放脑子里；
• 安全要求，能变 skill 就别只停在培训里；
• 高风险动作，能卡 hook 就不要只写“请谨慎”；
• 能平台托管的权限和策略，也别放给项目自己凭自觉守。

这不是什么“AI 时代的新哲学”，就是一句很老的工程话：软约束守不住硬风险。

第三条：人要站到闸门上，不要继续站在流水线上

这条我尤其认同。

以前很多人其实花了太多时间做搬运工。抄需求，转述设计，追 review，人肉点测试，再把结论抄到另一套系统里。这些动作里有不少并不需要判断，只是流程在搬运信息。

AI 进来以后，人当然还在流程里，但站位应该变。人更适合看的，是方向对不对、风险能不能接、哪种例外要升级处理、哪些动作必须有人签字，而不是一路跟在旁边补窟窿。

说得再直一点，人不该继续守在流水线上，人该守在闸门口。

原文六个阶段，我翻成了人话

Anthropic 还是按六个阶段来讲：Plan、Design、Build、Test、Deploy、Maintain。这个分法不新，但它每一段真正想改的东西，我觉得可以用更直白的话说。

Plan：先把“差不多”压成“说得清”

intent.md 的意义，不在于多了一个 markdown 文件，而在于先把最初的输入定住。问题是什么，目标是什么，影响谁，有什么约束，哪些地方还没定，先写清楚。

很多团队前面那段磨损，其实就发生在这里。大家都觉得自己懂了，一到开工才发现每个人脑子里的版本都不一样。intent.md 干的，就是先把这层雾打掉。

Design：让约束早点撞上来

原文建议让 agent 基于 intent.md 生成 spec.md，同时吃进品牌、安全、合规、UX 这些现成规则。我觉得这一招最有价值的地方，不是省写文档的时间，而是把返工往前挪。

很多团队现在的痛，不在设计写不出来，而在规则总是最后一刻才出现。方案写完了，代码做完了，review 再跳出一堆不允许。到了那一步，再重来就很伤。

Build：别一上来写代码，先把计划钉住

现在用 coding agent，很容易一开口就是“帮我改完”。原文在这里反而很克制：先产出 plan.md，把改哪些文件、顺序怎么走、风险在哪、靠什么验证完成写清楚，让人先看懂，再让 agent 动手。

这一小步看上去慢，其实很值。便宜的改动，本来就发生在下手之前。

Test：别把兜底永远留给人

这一段我也挺认同。代码是 agent 生成的，验证最好也让它先做一轮。测试、build、lint、截图对比、verifier、eval，能自动跑的尽量先跑完。否则 agent 负责提速，人负责收尾，最后人还是会重新变成整条链上最慢的那一环。

Deploy：不是放开 agent 发版，是把门修严一点

很多人一看到“AI 进入部署流程”，就会先担心安全。我觉得这个担心没错。原文真正强调的也不是“全自动发生产”，而是另一件事：agent 可以把流程推进到门口，但过门得按闸门来。

生产要授权，某类 infra 改动要有变更单，某些命令只能跑在受控环境里，secrets 和外网访问默认关死。听上去很保守，但我反而觉得这是成熟的地方。真正危险的，不是 agent 有能力，而是它没有边界。

Maintain：把线上事件重新写回开发闭环

我最喜欢的是最后这段。它想做的，不只是让 agent 帮你排障，而是让线上事件真正回到下一轮开发。

告警、工单、频道消息进来以后，agent 先做诊断。小问题直接出修复 PR，大一点的，写回新的 intent.md，再重新进计划、设计、实现、验证、发布这一圈。这样一来，维护就不再是开发流程外面的售后区，而是下一轮开发的入口。

下面这张图，把这个闭环味道画得很清楚：

我挺喜欢这张图。它说明的不是“把 AI 塞进每个环节”，而是整个流程都该按新的速度重排。

如果真要落地，我会先做这四件事

如果要把这篇文章里的东西搬回团队里，我不会先学它的文件名，也不会先做一个“全链路 AI 化”的大蓝图。我更愿意先补几块最基础、也最容易漏掉的地方。

第一，先补阶段产物。每一阶段结束时，到底有没有一个下游能直接接住的东西？没有的话，先补这个。阶段之间全靠人解释，流程一定跑不快。

第二，先把验证做稳。AI 写得快不可怕，验证不稳才可怕。测试命令、CI、截图对比、数据准备、环境一致性，这些如果飘，所谓自证闭环只会变成新的噪音源。

第三，把高风险规则升成硬闸门。凡是明确不希望越界的动作，都别只写在文档里。能 deny 就 deny，能 sandbox 就 sandbox，能 hook 就 hook，能平台托管就平台托管。建议型规则，守不住高风险动作。

第四，把线上回流打通。如果线上问题最后还得靠人手抄成需求卡片，闭环就只完成了一半。监控、工单、复盘结论，至少要能进入下一轮输入，而不是永远停在群聊里。

最后

我读完这篇文章，真正被说服的地方，不是某个功能点，也不是 Anthropic 的产品阵列。打动我的，是它终于把视线从“多写代码”挪开了，开始认真讨论流程本身。

代码生成提速当然重要。但那只是引子。真正要改的，是围着代码转的那整套研发机制。

文件名可以不一样，工具也可以不一样，组织形态更不会一夜之间变成 Anthropic。可方向我觉得已经很清楚了：流程得靠 artifact 接力，规则得进入运行时，人得站到闸门上，线上事件得能回写下一轮开发。

如果把这篇文章再炼成一句话，我会写成这样：

AI-native SDLC，说的不是“让 AI 参与研发流程”，说的是把研发流程改造成一个可被 AI 执行、被系统约束、被人类审计的控制回路。