Anthropic最近在讲AI-Native SDLC，开篇就把我钉住了：

Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven't changed at the same pace.

代码已经不是瓶颈了，但代码周围那一整套流程，还是老样子。

这句话，其实是在说一个挺尴尬的现实：

企业现在能用Claude Code这类AI工具，用快到一年前不敢想的速度在写代码，但审批关卡、评审流程、交接环节，一个都没跟着提速。

类似，把发动机换成了火箭引擎，但外面还套着马车的轮子。

01

传统SDLC

为什么不配了？

因为，它是为“写代码很贵”的时代设计的。

软件开发生命周期（SDLC）传统上分六个阶段：规划、设计、开发、测试、部署、运维。

每个阶段归不同角色管，产品经理写需求，架构师转成设计，工程师实现，测试团队验证，发布团队上线，运维团队盯着。

阶段之间靠文档、工单、签字来传递。

这套流程之所以这么重，是因为它是在写代码和实现功能是最耗时、最贵的那个环节下设计出来的。

需求文档、项目评估、安全评审，本质上都是为了在可能长达几周甚至几个季度的开发周期里，强行把各方对齐。

现在的问题是：这个前提已经不成立了。 

当开发阶段被压缩到几个小时，整套流程会暴露出三个连锁反应：

1

瓶颈整个往两边挪

开发阶段前后那些阶段，还在按人类速度运转的环节，主要是规划、评审、测试和部署。

2

代码审计跟不上

原来的管控方式和现实脱节，传统代码审计方式在人写代码的时代讲得通，但当大部分diff是Agent生成的，这套审查方式根本跟不上节奏。

3

治理成本反上升

因为例外情况还是要走每周或每月才开一次的评审会。

比如：

安全团队的编制是按人类产出规模配的，一旦Agent把代码产出量翻倍，要么评审队列越堆越长，要么代码带着不够充分的审查就上线了。

受监管的企业，这两个结果一个都承受不起。

02

AI-Native SDLC

一个不断喂养自己的循环

AI-Native SDLC，本质是把线性流程改造成一个闭环：

每个阶段结束时，都要提交一份可被下一阶段直接读取和执行的产物，而不是靠人层层转述。

拿规划阶段举例：

·

传统做法

传统做法想法要经过backlog、用户故事、故事点评估、需求梳理会议才能进入执行。

每一次交接都换一次owner，传到工程团队手里的东西，已经和最初提出者的本意隔了好几层。

·

AI-Native做法

AI-Native的做法是提出想法的人，直接和AI头脑风暴，产出一份intent.md。

一份人能读、机器也能直接执行的意图说明书，包含要解决什么问题、为什么、有什么限制。

这个模式贯穿了六个阶段，每个阶段结束都提交一个版本控制的文件：

这条提交链本身，就是审计轨迹。

谁提的需求、Agent产出了什么、谁批准的，全部留痕。

03

最实在的

写代码之前，先逼AI交一份计划书

我觉得最实用的一个设计，是开发阶段的plan mode。

·

传统做法

传统流程里，工程师读完设计文档就直接开始写代码，具体怎么改、改哪些文件、写哪些测试，全在工程师脑子里，最多写在工单评论里，没人能提前审查。

评审者第一次看到的东西，是写完的diff。

这时候想返工，已经很慢了。

·

AI-Native做法

AI-Native的做法反过来：

Agent先进入计划模式，只读代码库、不动代码，把实现方案、要改的文件、工作顺序、验证方式先写成一份计划，工程师逐条盘问。

这一步可能破坏什么、哪一步风险最大、还有哪些方案被放弃了。

改到一个完全没参与过这次对话的工程师，光看这份计划就能实现这个改动的程度，才批准执行。

这个设计的精妙之处在于：

它把改主意的成本，从改代码降回了改文档。 

设计评审发生在任何代码被生成之前，路线还是一份文档的时候。

04

安全还在

只是换了一种执行方式

自动化不等于放弃管控，只是把管控从开会评审变成了写死在代码和配置里。

具体落到几个机制上：

相当于给新Agent的入职说明书，写清楚代码规范、常用命令、架构原则、团队最常踩的坑。

有个挺朴素的经验法则：

Claude犯了两次同一个错误，这条纠正就该写进CLAUDE.md。

把组织的制度性知识变成可执行、可版本控制、可被集中更新的规则包。

但Skill是建议性的管控，不是强制的，模型不一定100%照做。

这才是真正的硬约束。

在Agent每次动作前触发的脚本，可以放行、拦截，或者暂停等人批准。

比如禁止修改受保护的路径、强制跑完格式化和lint、把密钥挡在diff之外。

Skill让违规变得罕见，Hook让违规变得几乎不可能。

每次Agent的配置，如提示词、技能、钩子发生变化，都会跑一遍20到50个真实任务的回归测试。

确保模型换了、提示词改了之后，产出质量没有偷偷下滑。

这套组合拳的逻辑是：

• 能写死的规则，就别指望AI自觉遵守；

• 只有写成钩子这种确定性代码的规则，才叫真正兜底的管控。

这里，我们把六个阶段拆成了一整套具体的打法，每个打法之间还标了依赖关系。

哪个打法必须先落地、哪个可以独立起步不依赖任何前置条件。

05

部署审核

AI只能一路干到生产环境门口

部署这一环，我看到一条挺硬的红线：

Agent可以做到生产发布Gate之前的所有事，但没有一条路能直接跨过这道Gate。

• 分支保护策略，确保Agent写的任何东西都只能以PR形式出现，没有直接推到主分支的通道；

• 生产环境的部署钩子会拦住发布，直到有名有姓的发布负责人签字授权；

• 每个环境的权限分层不同，开发环境Agent可以自由部署，预发布环境介于中间，生产环境则是Agent准备好发布包、人来拍板。

我扒到一份受监管企业的配置示例，细到禁止读取.env文件和密钥目录、禁止任意网络请求、代码沙箱在操作系统层面兜底、所有技能和插件必须来自组织审批过的应用市场。

这套配置传递的信号是：

光靠跟AI说不要做危险的事是不够的，得从系统权限层面让危险的事根本做不了。

06

运维最赞

让AI自己发现问题、自己走完整个流程

运维阶段是我觉得最赞的部分。

·

传统做法

传统运维是被动的。

工单等人来处理，凌晨三点的告警可能被漏掉，复盘之后该改的代码可能因为下一场救火又被搁置。

·

AI-Native做法

AI原生的做法是一个确定性的监控脚本持续盯着生产指标，一旦某个指标偏离基线超过设定阈值，就无需人介入，直接触发AI告警。

先只读诊断，问题更严重时才允许提出修复方案，而且修复方案只能以PR的形式提交、走回评审规范，从不允许直接绕过审查上线。

Agent诊断出的问题，会被写成一份新的intent.md，重新流入整个六阶段循环。

闭环真正闭上了。

一次线上异常，不需要人去发起，就能自动变成一次完整的开发周期，人只在关键节点做裁决。

除了指标触发的自动闭环，我还注意到另一种入口：

事故也可能通过Slack这类协作工具冒出来。

Claude Tag可以作为团队里的成员，以自己的身份第一时间响应事故，整个对话过程和处理记录都留痕，这本身就是一份天然的审计记录。

07

一点碎碎念

当写代码这个动作本身不再稀缺，稀缺的东西就变成了人的判断力该往哪投放。

过去，人的注意力平均分散在每一行代码、每一次交接、每一次会议上。

现在，人的注意力被逼着往两个地方集中：Gate和Intent。

一头是决定这事儿能不能干的规划起点，另一头是决定这事儿能不能上线的发布终点。

中间那一大段怎么干的过程，正在越来越多地交给Agent自己跑完、自己验证、自己修正。

但我也想留一个问题：

这套架构里，人类判断力被压缩成了一个个离散的审批节点，批准intent.md、批准spec.md、批准plan.md、批准PR。

当这些节点之间的时间越来越短、频率越来越高，人类审批者会不会在某个临界点之后，从认真判断的裁决者退化成习惯性点头的橡皮图章？