AI原生SDLC不会只有一种流程
内容提要
Anthropic发布AI原生SDLC手册，指出代码不再是瓶颈，瓶颈转向规划、审查、部署与治理。现有工具强制统一流程，不适用于不同风险的变更。建议将流程定义为状态机，按变更风险分类路由，用规则响应系统事实，并安全演进流程，让人类判断用在关键处。
延伸解读
单一流程的局限与风险
文章指出，现有AI原生SDLC工具（如Amazon Kiro、GitHub Spec Kit）往往强制统一流程，但真实组织中不同变更的风险和合规要求差异巨大。例如，文档修复、依赖升级和支付服务的模式迁移不应走相同路径。若工具只提供一种流程，团队会为不适配的变更绕开工具，导致实际流程不可见，或迫使供应商不断添加配置，最终变成无人能懂的工作流引擎。
状态机模型：以事实驱动流程
文章建议将流程定义为状态机，状态是变更在系统（如仓库、CI、集群、跟踪器）中的事实，如已审查、已验证依赖、已批准生产。流程不是执行步骤的程序，而是一组响应系统观察的规则。规则作为数据存储并像代码一样审查。组织可为每个风险类别运行小型状态机，运行时无组件跟踪“第四步”，流程随事实出现而推进，迟到、重复或重启后的事件也能正常处理。
分类路由与安全演进
变更路径应由分类决定，而非作者选择。组织利用现有信号（如变更触及的路径、所在仓库、跟踪问题标签）定义分类。流程定义本身也需安全演进：由于是数据，编辑它也是一次变更，需经过自己的门控流程。例如，放宽发布流程的审批门控应像模式迁移一样被审查，而非像配置文件一样直接编辑。每次转换都记录谁批准及依据什么证据。
Q&A
AI原生SDLC中，为什么说代码不再是瓶颈？
因为AI代理可以在几分钟内生成实现，构建阶段不再是限制因素，瓶颈转移到了规划、审查、验证、部署和治理等环节。
Anthropic的AI原生SDLC手册主要讲了什么？
手册指出代码不再是瓶颈，瓶颈转向规划、审查、部署与治理，并建议将流程定义为状态机，按变更风险分类路由，用规则响应系统事实，并安全演进流程。
为什么现有的AI原生SDLC工具（如Kiro、Spec Kit）不适合所有组织？
因为这些工具强制统一流程，要求每个变更都经过相同的固定阶段和产物，但实际组织需要根据变更的风险和问责要求采用不同的流程。
如何为不同风险的变更设计合适的流程？
将流程定义为状态机，状态是变更的事实（如已审查、已验证、已批准），规则响应这些事实。组织为每个风险类别运行小型状态机，通过分类信号（如变更路径、仓库、标签）路由变更。
在AI原生SDLC中，如何安全地演进流程定义？
因为流程定义是数据，编辑它本身就是一个变更，需要经过自己的门控流程。例如，放宽发布流程的审批门控要像模式迁移一样被审查，而不是像编辑配置文件那样随意。
AI原生SDLC中，人类判断应该用在什么地方？
人类判断应该只用在需要的地方，由代理无法自行产生的证据支持，从而在吞吐量倍增的同时保持质量。
