夜雨聆风过去几十年，工程经理一直在解决一个问题：如何让许多程序员在同一共享代码库中协同工作。这个问题最早可以追溯到 1975 年的"系统开发生命周期"概念，也就是我们今天熟知的 SDLC（Software Development Lifecycle）：
计划 → 设计 → 实现 → 测试 → 部署 → 维护 → 停用
AI 把其中曾经最慢、最贵的环节——实现——变成了最快、最便宜的。这不仅不是解脱，反而引发了连锁崩塌：负责 SDLC 中其他所有步骤的人不堪重负。
开源维护者被成千上万的 PR 和 Issue 轰炸，生产工程师在软件交付速度提升几个数量级的情况下拼命避免系统崩溃，代码审查者面对 AI 生成的代码感到无从下手。
我们一边享受 AI 带来的效率提升，一边陷入新的混乱。
SDLC 正在失效
传统 SDLC 的前提假设是：代码编写是瓶颈。所以我们在代码审查、测试、部署等环节投入了大量精力和自动化工具。但当代码编写不再是瓶颈，整个链条的压力就转移到了下游环节。
AI 编码工具让个人产出提升了 2-3 倍，但团队的审查、部署、运维能力没有同步提升。结果是：
- •审查堆积：AI 生成的代码 PR 堆积如山，审查者根本看不完
- •质量下降：审查疲劳导致放行不合格代码
- •运维压力：部署速度加快，但生产环境的问题排查能力跟不上
- •维护成本飙升：AI 生成的代码风格不一致，后续维护困难
一个有经验的工程师一天能认真审查 3-5 个 PR。AI 一小时能生成 50 个 PR。这数学题谁都算得出来。
从 SDLC 到 ADLC：智能体开发生命周期
我们需要一个新的范式，不是把 AI 当工具，而是把 AI 当协作者——甚至当"开发者"。
这就是 ADLC（Agent Development Lifecycle）的概念：智能体不仅负责写代码，还要参与审查、测试、部署、监控和修复的全流程。
简单说，不能让 AI 只负责产出，而把其他环节丢给人类。AI 产生的负担，必须由 AI 自己消化。
◆ADLC 的六个关键要求
程序化：所有操作都必须有 API。人类可以"点点点"的操作，智能体调不了。既然要让智能体干活，就得给它遥控器，不能指望它用手去拧旋钮。
水平可扩展：每个智能体都需要独立的预览环境，而不是让人类盯着屏幕看构建过程。AI 并行跑 100 个任务，就需要 100 个独立的预览环境。
可重现：普通单元测试和集成测试在特定环境下的 bug 面前无能为力。智能体需要能创建和销毁任意环境来复现问题。
实时推送：依赖人去盯着仪表盘判断系统是否正常，对智能体完全行不通。需要用事件触发智能体执行任务。
原子性：每一项变更都必须能独立测试、独立发布、独立回滚，不波及无关功能。
自我改进：人会从经验中学习——第一周值班时手忙脚乱，一个月后游刃有余。智能体也需要从经验中学习的方法。
软件工厂：让 AI 承担完整链路
"软件工厂"的概念正在兴起——这是一个由智能体驱动的系统，接收输入（生产错误、客户 bug 报告、新功能想法），然后自主地构建、改进、部署和管理软件。
但问题在于，即使使用了智能体，大多数软件项目仍然受限于人类参与的步骤。人类对智能体发出提示，告诉它们继续推进，指示它们将来自代码审查的反馈应用到代码中，持续照顾多个智能体并下达指令。
这就像让一个高级工程师配了 10 个实习生——不是解脱，而是另一种形式的负担。
真正的软件工厂，应该让人类的时间投入到真正需要人类的事情上：设计、客户交流、大胆的愿景。而把实现、测试、部署、监控这些可流程化的工作交给智能体自主完成。
信任问题：为什么不敢让 AI 合入 PR？
问自己一个问题：为什么你还没有让智能体自动批准并合并自己的 PR 到生产服务中？
你构建的东西越重要，理由就越多。这背后是信任问题，也是眼下最核心的治理挑战。
回顾上一篇文章提到的数据所有权问题，AI 时代的软件开发面临同样的困境：
- •谁对 AI 生成的代码负责？ 是提示词的作者？是审查者？还是 AI 工具本身？
- •谁对 AI 引入的安全漏洞负责？ 当 AI 生成了包含供应链攻击的代码，谁来为后果买单？
- •AI 代码的质量标准是什么？ 通过编译不代表没问题，跑通测试不代表没隐患
- •AI 的"学习"如何治理？ 如果 AI 在训练数据中学习了有问题的代码模式，谁来纠正？
这些问题的答案还在探索中，但有一点是确定的：赋予 AI 更多自主权的前提，是建立与之匹配的治理体系。
给软件团队的实操建议
抛开 Cloudflare 等云计算厂商的具体产品，回到通用方法论层面，我认为当前阶段软件团队应该做五件事：
◆1. 把"代码审查"升级为"系统审查"
AI 生成的代码，审查重点从"这段代码写得对不对"转向"这段代码是否匹配系统设计、是否引入安全风险、是否符合业务逻辑"。不要逐行审查 AI 代码，要审查 AI 的意图和结果。
◆2. 建立 AI 代码的质量基线
不是所有 AI 生成的代码都值得审查。建立明确的准入标准：
- •必须通过全部自动化测试
- •必须通过静态代码分析
- •必须包含可追溯的测试用例
- •必须附有 AI 生成声明
低于基线的一律打回重写。
◆3. 投资可观测性，而非更多代码
AI 让写代码变便宜了，但让理解系统变贵了。把更多精力投入在日志、追踪、指标上，让系统状态可观测。当 AI 改了代码，你需要知道它改变了什么行为。
◆4. 设计"渐进式信任"机制
不要试图一步到位让 AI 完全自主。建立一个信任阶梯：
- •阶段一：AI 写代码，人类审查+部署
- •阶段二：AI 写代码+测试，人类审查+部署
- •阶段三：AI 写代码+测试+部署（灰度），人类监控
- •阶段四：AI 全链路自主，人类处理异常
每个阶段都需要验证通过后，再进入下一阶段。
◆5. 重新定义团队角色
当 AI 承担了大部分"实现"工作，人类工程师的角色需要重新定义：
- •架构师：设计系统边界，确保 AI 能在约束内安全运作
- •审查者：从代码审查转向系统审查
- •训练者：训练和调优 AI 编码模型
- •护航者：处理 AI 无法处理的边界情况
数据治理的启示：所有权是 AI 开发的基础
回到上一篇文章的核心观点——所有权不能自动化，它需要被设计。
这句话同样适用于 AI 驱动的软件开发。在推出 AI 编码工具之前，先回答三个问题：
- •谁对 AI 生成的代码在生产环境的表现负责？
- •谁有权决定 AI 可以自主完成哪些任务？
- •AI 代码的质量由谁把关？标准是什么？
没有清晰的答案，AI 编码工具只会从"效率工具"变成"混乱加速器"。
结语
AI 正在从根本上改变软件开发的方式。SDLC 诞生于 1975 年，它的前提是代码编写是瓶颈。2026 年的今天，这个前提已经不再成立。
我们需要新的范式，新的工具，新的治理体系。ADLC 提供了一种思路，但更重要的是组织层面的转变：从"让 AI 写更多代码"转向"让 AI 参与完整链路"，从"审查 AI 的输出"转向"设计 AI 的边界"，从"AI 辅助人类"转向"人类与 AI 协作"。
这不是一个技术问题，而是一个组织和治理问题。就像数据治理的核心不是工具，而是所有权一样，AI 时代的软件开发核心也不是代码生成速度，而是信任与责任的重新分配。
🖊️ IT鼹鼠点评
这篇文章的观点来自 Cloudflare 最新发布的 ADLC 概念，但我剔除了厂商特定的内容，专注于通用方法论。
Cloudflare 的核心洞察值得深思：AI 写代码的能力已经远超人类审查和运维的能力，继续用 SDLC 的框架去管理 AI 驱动的开发，就像用马车驾照去开跑车。
现实中，我看到很多团队在犯一个错误：给程序员配了 AI 编码助手，让个人产出翻倍，但团队的基础设施（代码审查流程、测试覆盖、部署管线、监控体系）纹丝不动。结果就是代码质量下降、线上故障增多、团队士气反而降低。
工具提升了，流程没跟上，混乱就来了。
所以我的建议是：在引入 AI 编码工具之前，先把"审查能力"和"可观测性"这两个短板补上。否则，AI 不是帮你加速，而是帮你加速翻车。
原文链接：https://blog.cloudflare.com/zh-cn/agent-development-lifecycle/
