The AI-Native SDLC playbook

Fri, 21 Aug 2026 00:00:00 +0800

Note

如何用 AI 逐阶段改造你的软件开发生命周期。

代码不再是瓶颈 Link to heading

不少组织已经能用 AI 以一年前想都不敢想的速度写代码，但代码周围的那套流程并没有跟着变快。

许多工程团队仍在沿用原先那套审批关卡、评审、交接和策略，用 Claude Code 这类 agentic 编码方案换来的提速，就这样被抵消掉了。

软件开发生命周期（SDLC）是把软件从一个想法推进到生产环境的过程。大多数组织都在跑着大致相同的六个阶段：规划、设计、构建、测试、部署、维护。传统上，每个阶段都由不同角色负责，各管一段：产品经理写需求，技术架构师把需求转成设计，工程师实现设计，受监管企业里的 QA 团队负责验证，发布团队负责上线，运维团队盯着运行状况。工作在阶段之间流转，靠的是文档、工单和签字确认。

传统的 SDLC 流程繁重，为的是保证每一步都有人负责、都在掌控之中。但它是为一个「编写和实现代码是最耗时、最昂贵的阶段」的年代设计的，这个前提现在已经不成立了。PRD、估算仪式、产品安全评审这些环节之所以存在，就是为了在可能拖上几周、几个月甚至几个季度的开发周期里，硬逼各方对齐。

传统 SDLC 还有一个特点：每道控制措施都默认由人来执行。而那些收获最多的组织，已经围绕 agentic AI 现在能做到的事重建了流程，并始终把人留在其中。这份指南介绍的是 Applied AI 团队在 SDLC 每个阶段集成 Claude 的一组最佳实践，来自我们与客户合作的经验，目的是加快开发、让流程转得更快。

当代码不再是瓶颈、构建阶段的速度超出传统 SDLC 能容纳的范围时，会出现三件事：

瓶颈转移到构建阶段前后的环节，主要是规划、评审/测试和部署，它们仍然以人类的速度运转。
控制措施不再符合现实，变得难以应付。代码由人编写时，逐行人工审查是合理的；一旦 Agent 产出了 diff 的大部分内容，人工审查就跟不上了。
治理成本上升，因为例外情况仍然要靠每周、每月才开一次的会议和委员会来处理。

构建不再是制约因素，它周围那些以人类速度运转的环节才是。以人类速度运转的阶段维持原有时长，构建则被压缩到数小时。

拿安全瓶颈举个例子。安全团队的规模是按人类产出来配置的，所以当 Agent 让代码产出成倍增长时，要么评审队列越积越长，要么代码在评审不足的情况下上线。受监管的组织两种结果都无法接受，安全和策略检查必须跟上 Agent 的节奏才行。

传统 SDLC 需要经历一次和「实现」环节同等力度的转型，才能既保住 agentic AI 带来的效率，又守住安全。

什么是 AI 原生 SDLC？ Link to heading

AI 原生 SDLC 是一次重新构想：旧有的控制目标不变，但换成新的执行方式。流程不再是线性的，而是变成一个循环，AI 被嵌入每一个节点。它倡导自动化的交接、自动触发的后续打法，正好解决传统 SDLC 各阶段之间那些手工、笨拙的交接。

SDLC on Chang

The AI-Native SDLC playbook

代码不再是瓶颈 Link to heading

什么是 AI 原生 SDLC？ Link to heading