SDLC 已死：AI 时代，软件开发的整个流程都塌了

AI 代理没有让 SDLC 变得更快——它直接杀死了 SDLC。

我总听人说 AI 是”10 倍开发者工具”。这个定位错了。它假设工作流不变，只是速度提升了。但事实并非如此。

整个开发生命周期——那个我们职业生涯围绕它转的、那个催生出数十亿美元工具产业的流程——正在自我坍塌。

而大多数人还没意识到。

一、你学的 SDLC，已经是文物了

我们大多数人被教的经典软件开发生命周期是这样的：

需求分析 → 系统设计 → 代码实现 → 测试 → 代码审查 → 部署 → 监控 → 回到需求

每个阶段都有自己的工具、仪式和产业链：

• • Jira 管需求
• • Figma 做设计
• • VS Code 写代码
• • Jest 做测试
• • GitHub 做 Code Review
• • AWS 搞部署
• • Datadog 做监控

每一步都是独立的、顺序的、到处都是交接。

但当一个工程师和编程代理一起工作时，实际发生的是这样的：

意图 → AI 代理 → 代码+测试+部署 → 能用吗？→ 不能就回去迭代，能就上线

阶段坍塌了。不是变快了，是合并了。代理不知道自己在”哪一步”，因为根本没有步骤。只有意图、上下文和迭代。

二、AI 原生工程师，根本不知道 SDLC 是什么

我和很多在 Cursor 出现之后才入行的工程师聊过。他们不知道软件开发生命周期是什么，不知道 DevOps 是什么，不知道 SRE 是什么。

不是因为他们差，是因为他们从来不需要。

他们从没参加过冲刺规划会，从没估算过故事点，从没等过三天 PR 审查。

他们就是造东西。

你描述想要什么 → 代理写代码 → 你看一眼 → 迭代 → 上线。一切同时发生。

这些工程师没有因为跳过仪式而变差——他们反而不受其束缚。冲刺规划、代码审查流程、发布火车、估算仪式……全都没有。他们跳过了整套正统教义，直接去造东西了。

说实话，我挺羡慕的。

三、每个阶段都在坍塌

让我挨个拆解 SDLC，看看还剩下什么。

📋 需求收集：流动的，不是下达的

以前需求是自上而下的。产品经理写 PRD，工程师估工期，一行代码还没写，规格就冻结了。

这在”建东西很贵”的时候是合理的。每个功能要花几周，你当然得先决定做什么。

但这个约束已经不存在了。

当代理几分钟就能生成一个完整功能时，你不需要提前指定每个细节。你给方向，代理出一版，你看看，调整，换个思路再试。你可以生成十个版本挑最好的。

需求不再是一个”阶段”——它是迭代的副产品。

那 Jira 呢？当受众不再是跨流水线协作的人类，而是消费上下文的代理时，Jira 是什么？

Jira 是为追踪”已经不存在的阶段”而建的。如果你的”需求”只是代理的上下文，那工单系统就不再是项目管理工具——它是个上下文存储库。而且是个很烂的上下文存储库。

🏗️ 系统设计：发现的，不是规定的

系统设计依然重要，但它发生的方式正在根本改变。

以前设计是写代码之前做的事。白板上画架构、权衡利弊、画方框箭头，然后去实现。设计和代码之间隔着几天甚至几周。

这个间隙正在闭合。

设计变成了”通过给代理正确的上下文来发现”，而不是”提前规定好”。模型见过的系统、架构、模式，比任何单个工程师都多。

当你描述一个问题，代理不只是实现你的设计——它会建议架构，而且往往比你自己想出来的更好。你在实时进行设计对话，输出就是可运行的代码。

你仍然需要判断代理是不是过度设计了、是不是漏掉了约束。但你是在协作设计，而不是下达设计。

💻 代码实现：这是代理的工作了

这个最明显。代理写代码。整个功能。带错误处理、类型、边界情况的完整解决方案。

我认识的人里，已经没人还在一行行敲代码了。我们审查代理写的东西，喂给它上下文，把握方向，然后把精力放在真正需要人类判断的问题上。

🧪 测试：同步的，不是顺序的

代理写代码的同时就写测试。不是事后补的，不是在单独的”测试阶段”。测试就是生成的一部分。

TDD 不再是一种方法论——它就是代理默认的工作方式。

整个 QA 职能作为独立阶段，已经消失了。

当代码和测试一起生成、一起验证、一起迭代时，就没有交接了。没有”扔给 QA 那边”。代理自己就能做 QA。

👀 代码审查：放弃吧

PR 流程该淘汰了。我本来就不喜欢，但现在它纯粹就是过去的遗物。

我知道这话让人不舒服。Code Review 是神圣的——它是抓 bug、传知识、保标准的方式。它也是一种身份认同：我们是工程师，审查代码是工程师该做的事。

但在代理驱动的世界里，死守 PR 流程不是严谨——是身份危机。

想想看：一个代理一天生成 500 个 PR，你的团队一天能审 10 个。审查队列越积越长。

这不是一个值得优化的瓶颈——这是个假瓶颈，一个只因我们把人类仪式强加给机器工作流而存在的瓶颈。

审查必须从头重新思考。要么它成为代码生成本身的一部分：

• • 代理根据计划文档验证自己的工作
• • 跑测试、查回归、对照架构约束验证

要么第二个代理审查第一个代理的输出——对抗式代理，从各个维度试图攻破改动。

我们已经有这些工具了。

人类介入的审查变成”例外机制”——只有当自动化验证无法解决冲突，或者改动触及真正新颖的东西时才触发。

没有 PR 的世界是什么样的？

• • 代理直接提交到主分支
• • 自动化检查、测试、类型检查、安全扫描、行为差异验证
• • 全过了就自动上线
• • 出问题代理自己修
• • 只有系统真的不知道怎么办时，人才介入

我们把审查周期花在读 diff 上，而代理几秒钟就能验证。这不是质量保障——这是勒德主义。

🚀 部署：解耦且持续

代理已经在写部署流水线了，比大多数团队手工建的更精细、更专业。功能开关、金丝雀发布、渐进式放量、自动回滚触发——那种以前需要专门平台团队才能做的发布工程。

关键转变是：代理天然地把部署和发布解耦了。

代码持续部署——每个改动，一生成验证完就产出制品，落在生产环境的闸门后面。发布是单独的决策，由功能开关或流量规则驱动。

有些团队已经在接近真正的持续部署和持续发布：代码生成、测试通过、制品构建、改动上线——全在一条自动化流里，从意图到生产，中间没有人类。

更有意思的还在后面。想象一下，代理不只是部署代码，而是管理整个发布生命周期：监控放量、根据错误率调整流量百分比、延迟飙升就自动回滚，只有真正新颖的问题出现时才通知人。

部署”阶段”不只是被自动化了——它变成了一个持续的、自我调整的过程，一个永远不会真正结束的过程。

📊 监控：最后幸存的阶段，但也需要进化

监控是 SDLC 里唯一幸存下来的阶段。而且它不只是幸存——它变成了其他一切赖以存在的基石。

当代理上线代码的速度快到人类审不过来，可观测性就不再是一个”挺好的仪表盘层”——它是整个坍塌后生命周期的主要安全机制。

其他所有保障措施——设计评审、代码审查、QA 阶段、发布签字——要么被吸收，要么被消灭。监控是剩下的东西。它是最后一道防线。

但大多数可观测性平台是为人类建的。告警、日志搜索、仪表盘……都是设计给人看、人来解读、人来行动的。

当改动量超过人类注意力时，这个模式就崩了。如果代理一天上线 500 个改动，而你的可观测性设置需要人去调查每个异常，你只是制造了一个新瓶颈——把瓶颈从代码审查移到了事故响应而已。

没有行动能力的可观测性，只是昂贵的存储。

可观测性的未来不是仪表盘——而是闭环系统：遥测数据变成上线代码的那个代理的上下文，让它自己检测回归并修复。

可观测层变成驱动整个循环的反馈机制。
不是末尾的一个阶段，而是整个系统的结缔组织。

最先搞明白这件事的团队——可观测性直接反馈回代理循环，而不是反馈到人的Pager上——会比所有人都上线更快、更安全。搞不明白的团队，会淹死在告警里。

四、新的生命周期，是更紧的循环

SDLC 是一个宽循环：

需求 → 设计 → 编码 → 测试 → 审查 → 部署 → 监控

线性、顺序、充满交接和等待。

新的生命周期是一个紧循环：

人类意图 + 上下文 → AI 代理 → 构建+测试+部署 → 观测 → 有问题就回去迭代，没问题就下一个意图

意图。构建。观测。重复。

没有工单。没有冲刺。没有故事点。没有排队等审的 PR。没有单独的 QA 阶段。没有发布火车。

只有一个带着意图的人，和一个执行意图的代理。

五、那还剩下什么？

上下文。就这个。

你用代理造出的东西的质量，和你给它的上下文质量成正比。

不是流程，不是仪式——是上下文。

SDLC 死了。新的技能是上下文工程。新的安全网是可观测性。

而行业里大多数人，还在配置没人看的 Datadog 仪表盘。

原文作者：Boris Tane
发布时间：2026年2月20日
原文链接：boristane.com/blog/the-software-development-lifecycle-is-dead