作者丨Boris Tane

译者丨明知山

策划丨Tina

AI 智能体并不是让软件开发生命周期变得更快，而是直接终结了它。

我经常听到人们把 AI 称为“10 倍开发者工具”，这种定位是错误的。这种观点假设开发流程不变，AI 只是提升了速度，但事实并非如此。整个开发生命周期——那个我们赖以建立职业生涯、催生出数百亿产业的体系——正在崩塌。

而大多数人尚未察觉。

你所了解的 SDLC 已成为过去

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

每个阶段都有对应的工具、流程和配套产业：Jira 管需求、Figma 做设计、VS Code 写代码、Jest 做测试、GitHub 审代码、AWS 管部署、Datadog 做监控。

每一步都是离散、按序执行的，交接无处不在。

而现在，工程师使用编程智能体时真实发生的却是：

开发阶段彻底崩塌了。它们不是变快了，而是彻底融合。智能体并不清楚自己处于哪一步，因为根本就没有步骤，只有意图、上下文与迭代。

AI 原生工程师

不知道什么是 SDLC

我花了很多时间与那些在 Cursor 出现后才开启职业生涯的工程师交流。他们不知道什么是软件开发生命周期，也不知道什么是 DevOps，什么是 SRE。这并非因为他们不够优秀，而是他们从不需要这些。他们从未做过敏捷规划，从未估算过故事点，也从未为等待 PR 审核而苦等三天。

他们只管把东西做出来。

你说出需求，智能体编写代码，你查看、迭代、发布，所有环节同步推进。

这些工程师并没有因为省去繁文缛节而变得平庸，反而因此挣脱了束缚。冲刺规划、代码审核流程、发布节奏、估算仪式——全都没有。他们跳过了整套所谓的正统流程，直接动手构建。

说实话，我很羡慕。

每个阶段都在崩塌

让我带着你重新审视 SDLC，看看它还剩下什么。

需求收集：灵活流动，而非硬性规定

在过去，需求是自上而下传递的。产品经理撰写 PRD，工程师进行评估，规范在编码开始前就已冻结。这在构建成本高昂的年代是合理的——当每个功能都需要数周时间才能完成时，你必须提前确定要做什么。

这种限制已经不复存在。当智能体能在几分钟内生成一个完整的功能时，你无需提前定义每一个细节。你只需要给出方向，智能体构建出一个版本，你再进行评审、调整和尝试不同的方案。你可以生成十个版本，然后从中选择最优的一个。需求不再是一个独立阶段，而是迭代过程的副产品。

那么，当协作对象不再是需要跨流程沟通的人，而是能直接理解上下文的智能体时，Jira 成了什么？它不过是在追踪那些早已不复存在的阶段工作。如果你的“需求”只是喂给智能体的上下文，那么工单系统就不再是项目管理工具，而是一个上下文存储库——而且是一个极其糟糕的存储库。

系统设计：在实践中探索，而非事先规定

系统设计依然重要，但其实现方式正在发生根本性转变。

设计曾经是编码前的必经步骤：你在白板上勾勒架构、探讨各类取舍、绘制方框与箭头，然后动手实现。设计与编码之间相隔数天甚至数周。

这个差距正在缩小。设计不再是提前定好的方案，而是通过为智能体提供恰当上下文在交互中逐步探索出来的结果。模型见过的系统、架构与设计模式远超任何一位工程师。当你描述问题时，智能体不只是实现你的设计，还会给出往往比你独自思考更优秀的架构。你们实时进行设计对话，最终直接输出可运行的代码。

你仍然需要判断智能体是否存在过度设计或遗漏了约束条件。但你们是在协作完成设计，而不是由你单方面规定方案。

实现：现在是智能体的工作

这一点显而易见。智能体直接编写代码——完整的功能，包含错误处理、类型定义与边界情况的全套解决方案。

就我个人而言，我已经不认识还在逐行手写代码的人了。我们审核智能体生成的内容，为它提供上下文、把控方向，只专注于真正需要人类判断的问题。

测试：并行进行，而非串行

智能体会在编写代码的同时完成测试，而非事后补充，也不存在单独的“测试阶段”。测试是生成过程的一部分。TDD 不再只是一种方法论，而是智能体默认的工作方式。

原本独立的 QA 阶段已经彻底消失。当代码与测试一同生成、一同验证、一同迭代时，就不再有交接环节，没有“抛给 QA”这回事。智能体本身就能完成 QA 工作。

代码评审：没必要再做了

PR 流程早已该被淘汰。我从来都不认同这套模式，而如今它更是成了过去时代的遗留产物。

我知道这会让人难以接受。代码评审向来被视为金科玉律，是你发现漏洞、传递知识、守住标准的方式，也是一种身份认同——我们是工程师，评审代码本就是工程师该做的事。可在智能体驱动的世界里，死守 PR 流程并非严谨，而是一种身份危机。

想想看，一个智能体一天能生成 500 个 PR，而你的团队可能只能审核 10 个。审核队列只会不断积压。这根本不是值得优化的瓶颈，而是伪瓶颈——只是我们把人类的工作仪式，强行套在了机器的工作流程上。

这样的流程根本不该存在，整套模式都已经过时了。

评审机制必须被重新审视。它要么成为代码生成的一部分——由智能体依据设计文档自检、运行测试、排查回归、验证架构约束，要么由第二个智能体评审前者的输出。对抗式智能体检验变更逻辑，尝试从各个维度进行破坏。我们已经有这些工具了。人类评审将变成例外处理，只有在自动验证无法解决冲突或变更涉及真正创新的内容时才介入。

没有 PR 的世界会是什么样子？智能体直接提交到主分支，自动执行检查、测试、类型校验、安全扫描、行为差异验证。如果全部通过，就自动发布；如果不通过，由智能体自行修复。只有当系统确实无法处理时，人类才会介入。

我们把评审时间浪费在查看智能体几秒就能验证的代码变更上，这不是质量保证，这是卢德主义。

部署：解耦且持续的

智能体已经在构建比大多数团队手工打造的、更复杂、更专业的部署流水线。功能开关、金丝雀发布、渐进式推出、自动回滚触发机制——这些过去需要专业平台团队才能实现的发布工程能力，如今智能体都能完成。

关键转变在于智能体天然地将部署与发布解耦。代码持续部署，每一个变更在生成并验证后都会生成可进入生产环境的工件，并隐藏在开关之后。发布则是独立的决策，由功能开关或流量规则来驱动。

一些团队已经在接近真正意义上的持续部署与发布。代码生成、测试通过、制品构建、变更上线，全程自动化，从需求构思到上线生产无需人工介入。

下一步会更有趣。想象一下，智能体不仅负责部署代码，还能管理整个发布生命周期：监控发布进程、根据错误率调整流量比例、延迟飙升时自动回滚，只在出现全新问题时才通知人类。所谓的部署“阶段”不只是自动化，而是演变成一个持续、自我调节的过程，永远不会结束。

监控：唯一幸存的阶段，

而且需要进化

监控是 SDLC 唯一幸存的阶段，它不仅仅是幸存了下来，更成为一切的基础。

当智能体发布代码的速度远超人工审核时，可观测性就不再是可有可无的仪表盘，而是整个研发生命周期的核心安全机制。以往的所有保障手段——设计评审、代码审核、QA 阶段、发布审批——要么被整合，要么被淘汰。监控成了唯一的留存，也是最后一道防线。

但大多数可观测性平台都是为人类设计的。告警、日志检索、仪表盘——全都面向人类的查看、解读与操作。当变更速度超出人类所能跟上的范围，这个模式就会彻底失效。如果一个智能体一天发布 500 次变更，而你的可观测系统还需要人工排查每一个异常，你就制造了新的瓶颈——只是把瓶颈从代码审核转移到了故障响应。

没有实际行动的可观测性只是昂贵的存储消耗。可观测性的未来不在于仪表盘，而在于闭环系统——遥测数据会成为代码发布智能体的上下文，让它能够自动检测并修复问题。

可观测性将成为驱动整个闭环的反馈机制，它不再是最后一个环节，而是整个系统的核心纽带。

率先想明白这一点的团队——让可观测性直接反馈给智能体循环，而不是推送到人类的告警设备——将能更快、更安全地持续发布。没能理解的团队，只会淹没在无穷无尽的告警里。

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

传统的 SDLC 是一个宽松的大循环：需求→设计→编码→测试→审核→部署→监控。它是线性、串行的，交接与等待无处不在。

新的生命周期是一个更紧凑的循环。

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

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

只有明确意图的人类和执行任务的智能体。

那么还剩下什么？

上下文，就这些。

你用智能体构建出的产品质量与你提供给它们的上下文质量直接成正比。决定结果的不是流程，不是形式，而是上下文。

SDLC 已死。新的核心能力是上下文工程，新的安全防线是可观测性。

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