软件开发生命周期已死

我经常听到人们把 AI 描述为“10x 开发工具”。这种说法是错误的。它假设工作流保持不变，速度会提升。但事实并非如此。整个生命周期，我们围绕它建立职业生涯、并催生了一个数十亿美元的工具行业的那个生命周期，正在自我崩塌。

而大多数人还没有注意到。

1、你学到的 SDLC 已成遗物

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

每个阶段都有自己的一套工具、仪式和小型行业。需求用 Jira。设计用 Figma。实现用 VS Code。测试用 Jest。代码评审用 GitHub。部署用 AWS。Datadog 用于监控。

每一步都是离散的。按顺序执行。处处都有交接。

现在来看，当工程师与编码代理一起工作时，实际发生了什么：

graph TD    A[Intent] --> B[Agent]    B --> C[Code + Tests + Deployment]    C --> D{Does it work?}    D -->|No| B    D -->|Yes| E[Ship]    style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46

阶段崩塌了。它们并没有变得更快。它们合并了。代理不知道自己处在第几个步骤，因为没有步骤。只有意图、上下文和迭代。

2、AI 原生工程师不知道 SDLC 是什么

我花了大量时间与 Cursor 推出后才开始职业生涯的工程师交谈。他们不知道软件开发生命周期是什么。不知道 DevOps 是什么，SRE 又是什么。不是因为他们是糟糕的工程师。因为他们从未需要过它。他们从未参与过冲刺计划。他们从未估算故事点。他们也从未等过 PR 审查三天。

他们只是去构建东西。

你描述你想要的。代理写出代码。你查看。你迭代。你交付。所有事情同时进行。

这些工程师并不是因为跳过仪式而更糟。他们不受束缚。冲刺计划、代码评审工作流、发布列车、估算仪式。全部都没有。他们绕开了整套正统性，直接进入构建阶段。

说实话？我很羡慕。

3、每个阶段都在崩塌

让我带你走过 SDLC，看看它还剩下什么。

3.1 需求收集：灵活的，而非被规定

过去，需求往往由上而下传达。项目经理写 PRD，工程师进行估算，规格在写第一行代码前就被冻结。当时开发成本很高。每个功能需要数周时间，你必须提前决定要构建什么。

现在，这种约束已经消失了。当一个代理能在几分钟内生成一个完整版本的功能时，你不再需要事先指定每一个细节。你给出方向，代理生成一个版本，你查看、调整、尝试另一种方法。你可以生成十个版本并挑选最佳的一个。需求不再是一个阶段，而是迭代的副产品。

那么当受众不是人类在协调工作流时，Jira 是什么？当 Jira 变成让代理获取上下文的工具时，Jira 是什么？Jira 的初衷是跟踪穿越那些不再存在的阶段的工作。如果你的“需求”只是给代理的上下文，那么工单系统就不再是项目管理工具，而是一个上下文存储，且很糟糕。

3.2 系统设计：发现，而非被规定

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

设计过去是在编写代码之前完成的工作。你会在白板上勾画架构，争论权衡，画出方框和箭头，然后去实现。设计与代码之间的差距曾经是天数甚至是数周。

这个差距正在缩小。设计正在成为通过给代理提供正确上下文来发现的过程，而不是你事先规定的东西。模型已经见过比任何个人工程师都多的系统、架构和模式。当你描述一个问题时，代理不仅实现你的设计，还会提出通常比你自己想到的架构更优的方案。你正在进行实时的设计对话，输出的是可工作的代码。

你仍然需要知道何时代理在过度设计或错过某些约束。但你是在共同设计，而不是在规定它。

3.3 实现：现在是代理的工作

这点很明显。代理写出代码。完整的功能。带有正确处理、类型、边界情况的完整解决方案。

我个人认识的高质量工程师现在几乎不再敲代码。我们审查代理写的内容，给它们上下文，指引方向，专注于真正需要人类判断的问题。

3.4 测试：并行进行，而非按顺序

代理在编写代码的同时编写测试。不是事后才写。也不是在单独的“测试阶段”中。测试是生成过程的一部分。测试驱动开发（TDD）不再是一种方法论，而是代理默认的工作方式。

整套 QA 作为独立阶段的功能已经消失。当代码与测试一起生成、一起验证、一起迭代时，就不存在交接。也不再需要“把它扔给 QA”的流程。代理本身就能完成 QA。

3.5 代码审查：放手吧

拉取请求（PR）流程将不再需要。我曾经不是很喜欢它，但现在它只是过去的一个遗物。

我知道这很不舒服。代码审查是神圣的。它是你发现错误、分享知识、维护标准的方式。它也是一种身份认同。我们是工程师，审查代码是工程师的职责。但在一个由代理驱动的世界里，执着于 PR 工作流并不等于严谨。这是一种身份危机。

想想看。一个代理每天会生成 500 个 PR。你的团队也许只能审查 10 个。审查队列会堆积。这不是值得优化的瓶颈。这是一个假瓶颈，只存在于我们强加给机器工作流的人类仪式之上。

这张图不应该存在。整个流程都是错的。

审查需要从头重新考虑。要么让它成为代码生成本身的一部分，要么让代理在计划文档中验证自己的工作、运行测试、检查回归、验证架构约束，或者由第二个代理对第一个代理的输出进行审查。对抗性代理会在拟变更的各个维度进行挑战。我们已经有工具可以做到这一点。人机结合的审查成为例外情况，仅在自动验证无法解决冲突或变更确实新颖时触发。

没有 PR 的世界会是什么样子？代理直接提交到主分支。自动化检查、测试、类型检查、安全扫描、行为差异、验证变更。如果一切通过，它就会自动发布。如果有问题，代理会修复。只有在系统确实不知道如何处理时，才需要人为干预。

我们把代理能在几秒钟内验证的变更花在人工审查上。那不是质量保证。这是反技术守旧。

4、部署：解耦并持续

代理已经在编写比多数团队亲自构建更复杂、更专业的部署流水线。功能标记、金丝雀发布、渐进式扩展、自动回滚触发器、曾经需要专门平台团队的发布工程能力。

关键转变在于代理自然地将部署与发布解耦。代码会持续部署，每一次变更在生成并经过验证后产生一个制品，放在生产环境的门控后面。发布是一个单独的决策，由功能标记或流量规则驱动。

一些团队已经接近真正的持续部署与发布。代码被生成，测试通过，制品被构建，变更上线，全部在一个自动化流程中完成，意图与生产之间没有人类参与。

下一步会更有意思。想象这样一种场景：代理不仅部署代码，还管理整个发布生命周期，监控落地情况，基于错误率调整流量比例，在延迟上升时自动回滚，只有在确实出现新颖问题时才通知人类。部署的“阶段”不再只是一段自动化过程，而是一个持续自我调节的循环，永不结束。

5、监控：唯一存活的阶段，需要进化

监控是唯一存活的 SDLC 阶段。它不仅存活下来，还是其他一切的基础。

当代理比人类审查得更快地发布代码时，可观测性不再只是一个可视化的仪表盘层。它成为整条生命周期的首要安全机制。其他所有保护措施——设计审查、代码审查、QA 阶段、发布签字——都被吸收或消除。现在剩下的就是可观测性。

但大多数可观测性平台是为人类打造的。告警、日志检索、仪表板等都为人观看、解读和行动而设计。当变更量超过人类注意力时，这一模型就会崩溃。如果一个代理每天发布 500 个变更，而你的可观测性设置需要人类去调查每一个异常，你就创造了一个新的瓶颈。你把它从代码审查推到了事件响应。

只有动作的可观测性才是有价值的。未来的可观测性不是仪表盘，而是一个闭环系统，其中遥测数据成为已发布代码的上下文，使代理能够检测回归并修复它。

可观测性层成为驱动整个循环的反馈机制。 它不是末端的某个阶段。它是整个系统的连接组织。

最先搞清楚这一点的团队——将可观测性直接回馈到代理循环中，而非回到某人类的监控系统——将比其他人更快、更安全地交付。否则他们将淹没在警报中。

6、新生命周期是一个紧凑循环

SDLC 曾经是一个宽循环。需求 → 设计 → 编码 → 测试 → 审查 → 部署 → 监控。线性。顺序。充满交接和等待。

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

Intent。构建。观察。重复。

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

只有一个人类的意图和一个执行任务的代理。

7、那么剩下的是什么？

上下文。就这么简单。

用代理构建的内容质量与你给予它们的上下文质量直接相关。不是流程。不是仪式。是上下文。

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

而且大多数行业仍在配置没有人看的人为 Datadog 仪表板。

原文链接：软件开发生命周期已死 - 汇智网