ARTICLE · 1041147
AI原生软件开发流程不应只有一种模式
本文指出，AI时代的软件开发不能依赖单一僵化的流程。作者提出将开发流程定义为状态机，根据变更的风险等级自动路由，实现由系统事实驱动而非人工干预，从而在提升效率的同时保障质量与合规。
译自：The AI-native SDLC won't be one process[1]
作者：Anirudh Ramanathan
Anthropic 最近发布了其 AI 原生软件开发生命周期 (SDLC) 手册。其核心观点是“代码不再是瓶颈”。当智能体 (agents) 可以在几分钟内完成实现时，约束条件就转移到了构建阶段之外的环节：计划、审查、验证、部署和治理。
如果组织处理不当，风险在于产生十倍的变更，但每次变更的质量持平或下降，且无法识别哪些是坏变更。传统的做法是人工逐一检查，但在这种体量下，这种方法完全失效。
风险在于……产生十倍的变更，但每次变更的质量持平或下降，且无法识别哪些是坏变更。
这份手册[2]打下了良好的基础。但它没有捕捉到的一点是：组织的流程具有细微差别，它实际上是一系列随具体变更而变化的流程组合，而不是每一项变更都必须经过的单一流程。
规范驱动浪潮
这份手册是更广泛的规范驱动开发工具浪潮的一部分，其中包括 Amazon 的 Kiro[3] 和 GitHub 的 Spec Kit[4]。这些工具具有共同的特征：书面工件驱动工作：意图文档转化为规范、计划、差异比对 (diff) 和审查结果，所有内容都提交到版本控制中。策略由钩子 (hooks) 等确定性机制强制执行，而不是通过提示词 (prompt) 中的指令。智能体在人类看到之前会先自行检查工作，而由人类负责批准。
但这些工具中的每一个也都规定了特定的流程：产生固定工件的固定阶段序列，且每一项变更都要经过这一路径。采用该工具意味着采用其流程。
一个组织运行多种流程
没有真正的组织只运行单一流程。适合某种变更的流程取决于其携带的风险和所需的责任归属。文档修复、依赖项升级和支付服务中的模式迁移不应走同一路径。它们需要不同层级的验证、不同的审批人和不同的记录。在受监管的领域，流程本身就是合规义务的一部分：审计人员期望有记录显示谁批准了每项变更，以及基于何种证据。必须记录的内容因变更类型而异。
当工具规定单一流程时，团队会针对不合适的变更绕过它，这是最糟糕的结果，因为真正的流程变得不可见了。
当工具规定单一流程时，团队会针对不合适的变更绕过它，这是最糟糕的结果，因为真正的流程变得不可见了。或者厂商会不断增加配置，直到该工具变成一个没人能完全理解的工作流引擎。
工具不应规定流程，它应该为组织提供一种定义自身流程的方法。
作为状态机的流程
更好的模型是将每个流程定义为状态机。状态是关于变更的事实：已审查、已针对其依赖项进行验证、已批准用于生产。这些事实存在于没有单一工具拥有的系统中：存储库、CI、集群、跟踪器。因此，流程不能是一个执行步骤的程序，而是一组对这些系统的观察做出反应的规则。每条规则指定：
1. 在触发前所需的事实。 2. 其门控 (gate)：自动触发，还是等待人工批准。 3. 触发时授予的权限，例如合并或部署。
定义就是这套规则，作为数据存储并像代码一样进行审查。一个组织运行许多小型机器，每种风险等级对应一个。
在运行时，这与工作流引擎完全不同。没有组件会跟踪“我们处于第四步”：当事实出现在拥有它的系统中时，流程就会推进，规则会做出反应。迟到、重复或重启后到达的事件会像其他事件一样被处理，因为规则只对当前状态做出反应。门控是规则的条件之一，因此你可以在事故或发布冻结期间暂停触发，而无需编辑任何定义。
门控需要执行。作为提示词指令实现的门控依赖于模型是否遵循它。智能体框架可以提供运行状态机和执行其门控所需的确定性，在门控得到响应之前停止智能体执行操作，同时由基础设施执行其余部分。
流程适应变更
每个存储库一个固定的流程定义是不够的：该存储库中的每个变更仍然会走相同的路径，无论其风险如何。变更所走的路径应取决于变更的内容，这种路由来自对变更的分类，而不是由作者选择路径。组织使用其现有的信号来定义分类：变更涉及的路径、它所在的存储库、跟踪问题上的标签等。
定义本身也需要随时间改变，而且必须是安全的。由于流程定义是数据，编辑它本身就是一种变更，它会经历自己的门控流程。放宽发布流程的审批门控，其审查方式应像模式迁移一样，而不是像编辑配置文件那样。
点击放大图片。
具体来说，考虑对同一个服务的三项变更：
• 文档修复：按其涉及的路径进行分类。其流程有两个状态：构建通过，合并。无需人工参与。 • 依赖项升级：跳过设计审查，但其流程要求提供兼容性证据：升级后的服务针对真实依赖项运行集成测试。主版本升级会增加补丁升级所没有的审批环节。 • 支付服务中的模式迁移：按其涉及的组件进行分类，无论它声称是什么类型的变更。其流程增加了其他变更所没有的状态：支付所有者审查、针对生产环境形状数据的验证，以及来自该领域负责人的发布批准。
路径中的每一次转换都会记录谁批准了它以及基于何种证据。
原则
这些流程应遵循的原则：
• 自主权按操作授予，并随时间增长。 每个转换都设置为自动触发、需要批准或挂起。随着智能体在某类变更上证明了可靠性，该设置会放宽，因此流程无需重新设计就能吸纳智能体的改进。 • 人的注意力只花在需要判断的地方。 智能体的投入成本不断降低，而监督工时不会。只有在决策需要人类判断时才会让人员参与，并提供背景信息以供快速决策。 • 证据来自智能体之外。 智能体自己的报告永远不会推进变更。转换基于智能体无法写入的系统中的事实触发，例如测试结果和在现实环境中的验证[5]。 • 流程记录即审计追踪。 定义是书面策略，转换日志显示了谁批准了每一步、基于什么证据、在哪个版本的策略下。
规模化质量
该手册及其同类工具打下了良好的基础。缺失的是组织定义自身流程、根据每次变更的风险改变流程并安全地演进流程的能力。目标不是减少人工干预，而是将人类判断力仅用于需要的地方，并辅以智能体无法自行产生的证据，从而在吞吐量倍增的同时保持质量。
我们正在 Signadot[6] 构建这些理念，并作为小白鼠，通过这个流程运行我们自己的开发工作。如果你也在尝试这些想法，我们很乐意交流！
引用链接
[1] The AI-native SDLC won't be one process: https://thenewstack.io/spec-driven-sdlc-gates/[2] 手册: https://claude.com/blog/the-ai-native-sdlc-playbook[3] Kiro: https://kiro.dev/[4] Spec Kit: https://github.com/github/spec-kit[5] 在现实环境中的验证: https://thenewstack.io/enabling-autonomous-agents-with-environment-virtualization/[6] Signadot: https://www.signadot.com/?utm_source=tns&utm_medium=sponsorship&utm_campaign=q3_26_sponsored_content