代码不再是瓶颈，瓶颈换了个地方

Claude 官方博客最近发了一篇文章，叫《The AI-native SDLC playbook》。标题挺唬人，翻成人话就是：怎么用 AI 重新设计一遍软件开发的整条流水线。

我把它整篇读完了，说实话，读之前我以为又是一篇"AI 帮你写代码更快"的软文。读完发现不是——它讲的其实是一个更扎心的事实：

代码，已经不是研发流程里最慢的那一环了。真正拖后腿的，是流程本身。

这篇文章我尽量用人话把它复述一遍，中间穿插我自己的理解和踩过的坑。原文链接放在最后。

先搞清楚一个词：SDLC

SDLC 全称 Software Development Life Cycle，软件开发生命周期。别被这个词吓到，说白了就是"一个需求从冒出来到真正在线上跑起来，要走过哪几步"：

1. Plan 计划——想清楚要做什么
2. Design 设计——想清楚怎么做
3. Build 构建——写代码
4. Test 测试——验证代码没问题
5. Deploy 部署——发布上线
6. Maintain 维护——上线之后持续盯着、修问题

不管是一个人的副业项目，还是几百人的大公司，做软件都逃不开这六步，区别只是每一步做得正不正式。

过去几十年，这六步里最慢的一步一直是"Build"——写代码。 于是行业里所有的方法论、所有的工具，都在想办法让"写代码"这一步变快：敏捷开发、低代码平台、代码补全插件……直到 AI 编程助手出现，把这一步的速度直接干到了原来的几十倍。

问题也就出在这——

水桶的最短板，换了一块

有个很老的比喻，叫木桶效应：一只水桶能装多少水，取决于最短的那块木板，不取决于最长的那块。

过去，"写代码"这块板最短。现在，Claude Code 这类工具把它一下焊长了。

但其余五块板——想清楚需求、设计方案、测试验证、发布上线、上线后维护——大多还是靠人一步步手工走。 于是新的最短板出现了：不是代码写得不够快，而是"审批要等人、评审要排队、上线要开会"这些环节，速度完全没跟上。

Claude 这篇文章里给了一个我觉得挺到位的说法：

代码生成速度提高了几十倍，如果流程的其余部分还是人力速度，你只是把瓶颈从"写代码"搬到了"审批、测试、发布"上，总时长几乎没变，甚至因为代码量暴增，评审和治理的负担反而更重了。

这也是为什么很多团队接入 AI 编程工具之后，第一个月觉得爽翻了，第二个月却发现：代码堆得更快了，但 PR 排队更长了、评审更累了、线上事故也没见少。不是 AI 不行，是流程没跟着 AI 的速度重新设计。

这篇文章要解决的，就是这个问题：把 SDLC 六个阶段，一步步改造成"AI 原生"的样子。

传统流程 vs AI 原生流程

先给一张对照表，感受一下差别在哪：

划重点：AI 原生流程不是"把人去掉"，而是"把 AI 塞进每一个环节里打下手，人只在真正需要判断力的地方出现"。 这条界限很重要，下面六个阶段会反复出现。

六个阶段，逐个拆开讲

1 · Plan——先把"到底要做什么"写清楚

传统做法里，需求这件事经常是这样收集的：开一堆会、走一圈工作坊、最后凑出一份没人爱看的需求文档。

AI 原生的做法反过来：你直接跟 AI 聊你遇到的问题，不用讲究措辞，AI 会追问你没想到的地方——这个功能给谁用？边界在哪？做到什么程度算成功？聊到双方都想明白了，AI 把这次对话整理成一份人能读、AI 也能照着执行的文档，文章里管它叫 intent.md（“意图文档”）。

这份文档不是聊完就扔了——它被提交进代码仓库，谁写的、什么时候写的都留痕，产品负责人过一遍，接受或者打回。

这一步最值得抄的做法：别再把"和 AI 头脑风暴"当成随手聊天，聊完顺手把结论落成一份文档存下来。以后回头看"当初为什么这么设计"，就不用靠回忆了。

2 · Design——需求和设计不再是两拨人接力

传统流程里，需求分析师写完文档扔给设计师，设计师再重新理解一遍——这个"翻译"的过程本身就在丢信息、拖时间。

AI 原生的做法是一次会话里把这两件事一起搞定：把上一步的 intent.md 丢给 AI，同时告诉它要遵守哪些团队规范（品牌调性、安全底线、合规要求），AI 直接产出一份需求 + 设计合一的规格文档 spec.md，遇到拿不准的地方会主动标出来"这里我不确定，需要人来定"。

这里有个细节我很喜欢：AI 不是自由发挥，而是被套上了组织已经沉淀下来的规则（文章里叫 Skills，下面会细讲）。这意味着新人和老手用 AI 出来的设计规格，遵守的是同一套底线。

3 · Build——写代码之前，先让 AI 交一份"作业计划"

这是整篇文章篇幅最长的一节，因为"怎么让 AI 靠谱地写代码"这件事，细节最多。拆成五个小招：

3.1 先用 Plan Mode，不要一上来就写代码

Claude Code 里有个 Plan Mode（只读模式）：AI 先把代码库看一遍，想清楚要改哪些文件、按什么顺序改、可能踩到什么坑，写成一份 plan.md 给你看。你确认这份计划没问题，AI 才动手改代码——这一步等于把"设计评审"提前到了写代码之前，而不是代码写完了才发现方向错了。

3.2 把"教训"写进 CLAUDE.md，别让 AI 一直犯同一个错

CLAUDE.md 就是给 AI（也是给新同事）看的说明书：项目怎么跑起来、有什么约定俗成的规矩、架构长什么样、AI 之前踩过哪些坑。文章里给了一条特别实用的规则：

AI 在同一个地方犯错两次，就把这条教训写进 CLAUDE.md。

这条我自己深有体会——AI 助手不会"记吃亏"，你不写下来，它下次还会犯一模一样的错。写一次，等于给以后所有会话都打了个补丁。

3.3 把"必须遵守的规矩"做成 Skill，而不是每次重复交代

有些知识不是"建议参考"，而是"每次都必须照做"——比如"每个对外接口都要挂鉴权"“涉及金额的字段一律用高精度类型，不能用浮点数”。这类硬规矩，文章建议做成一个个 Skill（说明书 + 触发条件），团队所有人用的都是同一份，规则改了只改一处，不用挨个人重新交代。

3.4 用 Hook 顶住底线

Skill 是"建议"，AI 理论上可以不听；Hook 是"硬卡口"——该挡的动作直接拦截，不给商量的余地。比如：不许改某些受保护的文件、每次改完代码自动跑一遍格式化、密钥类信息不许出现在对话里。这一层不指望 AI 自觉，靠的是程序化的强制。

3.5 多开几个会话，让 AI 并行干活

一个人可以同时开好几个 Claude Code 会话，各自在独立的工作目录里改不同的模块，互不干扰，人在中间做协调。重复性的检查工作（比如"跑起来看看有没有明显问题"）可以固定成一个子代理，专门干这一件事，不用每次都重新交代。

4 · Test——让 AI 自己先把关，人看到的是"已经验证过"的东西

这一节的核心思路，文章说得很直白：

给 AI 一个反馈回路，让它在你看到之前，自己先检查自己的工作。

传统流程里，"测试"是代码写完之后单独排的一个环节，出问题往往是几天甚至几周之后才发现，人成了信号链路里最慢的一环。AI 原生的做法是把验证塞进写代码的过程里：AI 边写边跑测试、边看结果、边修，迭代到真正通过了，才把结果交给人看。

文章给了一条很具体的操作建议，我觉得特别值得抄下来：修 bug 的时候，先让 AI 写一个能复现这个 bug 的失败测试，确认这个测试确实因为这个 bug 而失败，把测试提交上去锁定，然后才让 AI 去改代码让测试通过——过程中不许它偷偷把测试改简单了。 这个顺序看似麻烦，但堵住了"AI 为了让测试变绿而悄悄放水测试标准"这个最容易被忽略的坑。

再往上一层，文章提到一个叫 Continuous Evals（持续评测） 的做法：把 20～50 个真实遇到过的任务和"什么样的结果算合格"整理成一套评测集，每次改动配置（CLAUDE.md、Skill、Hook）都自动跑一遍，通过率下降就要有人来看一眼再决定要不要合并。每出一次线上事故，就把它变成一条新的评测用例——这样同类问题理论上只会踩一次坑。

5 · Deploy——AI 既当评审员，也接受评审

AI 参与 PR 评审：以前 PR 排队等人评审，人一多、一忙，评审质量就开始飘。AI 原生的做法是让 AI 先给每一个 PR 过一遍统一标准的评审（分优先级：哪些是硬伤、哪些只是风格问题），人只需要聚焦在真正有风险的地方。文章特别提醒一句我觉得很重要的边界：

AI 不能给自己写的代码盖章通过。最终批准权，必须留在人手里。

Hook 从"拦路虎"变成"审批关卡"：前面 Build 阶段的 Hook 是"自动拦下不该做的事"，到了 Deploy 这一步，Hook 的角色变成"该暂停就暂停，等指定的人点头再继续"——比如生产环境的发布，必须等发布负责人手动批准。

CI/CD 里嵌入 AI 做判断：一开始只做低风险的事——帮忙看看构建为什么失败、总结一下哪些测试老是随机失败；确认好用了，再逐步放开一些"写"的权限，但所有改动照样要走 PR、走人工把关，不给 AI 直接改主分支的路。开发环境可以放得开一些，生产环境永远卡最严的关。

6 · Maintain——闭环真正闭上的地方

前面五个阶段，都是"人发起，AI 配合"。到了 Maintain 这一步，画风变了：AI 可以在没有人手动触发的情况下，自己发现问题、自己诊断、自己把发现写成一份新的 intent.md，重新丢回第一步的流程里。

具体怎么做的：先选一个稳定的监控指标（比如线上错误率、CI 测试失败率），写一套纯粹靠数据判断、不依赖模型的异常检测规则。指标正常就只是记录一下；轻度异常，喊 AI 用只读权限去看看是怎么回事；真出问题了，AI 才被允许通过受限的通道去动手处理，处理完的结论照样要写成文档，交给值班的人来判断"现在修、排期修、还是这次误报了"。

这一段读完我最大的感受是：这才是整篇文章标题里"闭环"两个字的真正含义。 前五步是一条线，第六步把这条线的尾巴接回了第一步的开头——线上出的问题，不再是拍脑袋记一下就完了，而是自动变成下一轮迭代的起点。

一张图看懂这个闭环

我把这六个阶段和之间两个最关键的关卡画成了一张图（Plan → Design → Build →〔AI 自检通过〕→ Test → Deploy →〔评审通过才发布〕→ Maintain → 指标异常，自动开一轮新的 Plan，回到起点）：

看这张图的时候，注意两个关卡：Build 到 Test 之间是"AI 自检通过"——这是 AI 自己把的第一道关；Deploy 面板上写着"评审通过才发布"——这是人工把的最后一道关。 这条线不是一次性的——走到 Maintain，指标一旦异常，就会自动开一轮新的 Plan，回到起点，形成一个环。

治理这件事，不是拍脑袋定规矩

文章里反复出现一个词：governance，治理。翻译成大白话就是：谁能做什么、谁来批准、出了事怎么追溯。

它给了三层控制手段，我觉得这个分层特别清楚：

• Skill（建议性）：告诉 AI"应该怎么做"，靠 AI 自己理解和执行，人事后抽查
• Hook（拦截性）：程序化写死"能做/不能做"，不给 AI 商量的余地，出手是瞬间的事
• 人工审批关卡：真正高风险的动作（比如生产发布），Hook 负责在这一步"暂停"，等指定的人点头才放行

三层叠在一起，形成的效果是：日常琐碎的决定交给 AI 按规矩自己走，真正担责任的决定，权力还在人手里。 这跟"AI 全自动"完全是两回事——它更像是给 AI 配了一整套"能做的事有多大范围"的权限体系,而不是撒手不管。

这套东西，普通开发者今天就能抄一部分

我知道，“控制带阈值”“持续评测 CI”"managed settings"这些词，听起来像是给几百人的大公司准备的。但读完整篇文章，我觉得下面三件事，任何一个用 Claude Code 干活的人，今天就能开始做：

1. 写一份 CLAUDE.md，AI 犯错就往里加一条——这是全篇成本最低、见效最直接的一条。
2. 改代码前先用 Plan Mode 让 AI 出一份计划，你看完确认了再让它动手——把"想清楚"这一步挪到"写代码"前面，而不是代码写完了再返工。
3. 修 bug 的时候，先让 AI 写一个能复现问题的失败测试，再让它去修——避免"看起来修好了，其实只是巧合"。

这三件事都不需要额外的工具，纯粹是使用习惯的调整。AI 原生 SDLC 不是一整套要么全上要么不做的系统，它更像一套原则——你可以先抄一小块，抄顺手了再抄下一块。

最后

这篇 Claude 官方文章最打动我的一句话，其实是开头那句判断：代码不再是瓶颈。

这句话背后的意思是：这一轮 AI 带来的改变，真正的考验不是"AI 会不会写代码"，这件事已经过关了。真正的考验是，我们愿不愿意跟着重新设计一遍围绕代码的那些流程——计划怎么定、评审怎么做、上线怎么批、出了问题怎么办。工具已经跑到前面去了，流程要是不跟上，跑得越快，摔得可能越疼。

（本文是对 Claude 官方博客文章 The AI-native SDLC playbook 的中文通俗解读，原文作者 Louis Claxton，发布于 2026-08-21。文中六阶段划分、intent.md/spec.md/plan.md/CLAUDE.md 等术语与流程图内容均来自原文，我做了顺序梳理和大白话翻译，个别举例是我自己的理解，如有出入以原文为准。）

本文首发于我的个人站 chengbei.org，同步转载于此。