硅谷大佬 Boris Tane 的思考：软件开发生命周期已死

人工智能代理并没有加快软件开发生命周期，反而扼杀了它。

我总是听到有人把人工智能称为“十倍速开发者工具”。这种说法是错误的。它假设工作流程保持不变，只是速度提升了。但事实并非如此。我们赖以生存的整个生命周期，我们赖以谋生的、催生了数十亿美元工具产业的整个生命周期，正在崩溃瓦解。

大多数人还没有注意到这一点。

你学到的软件开发生命周期（SDLC）已经过时了。
以下是我们大多数人所学的经典软件开发生命周期：

每个阶段都有其专属的工具、流程和行业惯例。Jira 用于需求分析，Figma 用于设计，VS Code 用于实现，Jest 用于测试，GitHub 用于代码审查，AWS 用于部署，Datadog 用于监控。

每一步都是独立的，按顺序进行的，处处都有交接。

现在，让我们来看看工程师与编码代理合作时实际发生的情况：

各个阶段崩溃了。它们并没有变得更快，而是合并了。代理不知道自己处于哪个步骤，因为根本没有步骤可言。只有意图、上下文和迭代。

人工智能领域的工程师不知道什么是软件开发生命周期（SDLC）。
我花了很多时间和那些在 Cursor 发布后才入行的工程师交流。他们不了解软件开发生命周期，也不知道 DevOps 或 SRE 是什么。这并非因为他们技术不好，而是因为他们从未真正需要这些。他们从未参加过迭代计划会议，从未估算过故事点数，也从未经历过 PR 审核要等三天的煎熬。

他们只是建造东西。

你描述你的需求。代理编写代码。你查看代码。你迭代修改。你发布。所有步骤同时进行。

这些工程师并没有因为省略了繁文缛节而变得更差。他们反而摆脱了这些束缚。迭代计划、代码审查流程、发布周期、估算仪式，统统都不用做。他们跳过了所有正统流程，直接投入到开发工作中。

说实话？我有点嫉妒。

每个阶段都在崩溃
让我带你了解一下软件开发生命周期，并向你展示它还剩下什么。

需求收集：灵活，而非强制性
过去，需求是下达式的。产品经理编写产品需求文档（PRD），工程师进行估算，然后在编写任何代码之前确定最终规格。在开发成本高昂的年代，这种方式是合理的。那时，每个功能都需要数周时间才能完成，所以必须提前决定要开发什么。

这种限制已经不复存在。当智能体能够在几分钟内生成一个完整的功能版本时，您无需预先指定所有细节。您只需提供方向，智能体构建一个版本，您查看它，进行调整，尝试不同的方法。您可以生成十个版本，然后选择最佳版本。需求不再是一个阶段，而是迭代的副产品。

那么，当用户不再是需要协调整个流程的人类时，Jira 又是什么呢？当用户只是接收上下文信息时，Jira 又是什么呢？Jira 的设计初衷是为了跟踪那些已经不复存在的阶段中的工作。如果你的“需求”仅仅是给客服人员提供的上下文信息，那么这个工单系统就不再是项目管理工具，而是一个上下文信息库。而且，它还非常糟糕。

系统设计：探索发现，而非人为规定
系统设计仍然重要，但其实现方式正在发生根本性的转变。

过去，设计是在编写代码之前进行的。你会先在白板上画出架构图，讨论各种权衡取舍，画出方框和箭头，然后再去实现它。设计和代码之间的时间间隔往往长达数天甚至数周。

这种差距正在缩小。设计不再是预先设定的，而是通过赋予智能体合适的上下文信息来发现的。该模型接触过的系统、架构和模式比任何单个工程师都多。当你描述一个问题时，智能体不仅会实现你的设计，还会提出一些通常优于你独自构思的架构。你们可以实时进行设计对话，而输出则是可运行的代码。

你仍然需要知道代理何时过度设计或忽略了某些约束条件。但你们是在合作设计，而不是制定设计方案。

实现：这是代理现在的任务。
这一点显而易见。代理会编写代码，包括所有功能，以及包含错误处理、类型定义和边界情况的完整解决方案。

我个人认识的人里，已经没有人还在写代码了。我们会审核智能体编写的代码，为它们提供上下文信息，引导它们朝着正确的方向前进，并专注于那些真正需要人类判断的问题。

测试：同时进行，而非顺序进行
智能体在编写代码的同时也会编写测试，而不是事后添加，也不是在单独的“测试阶段”。测试是生成过程的一部分。TDD不再是一种方法论，而是智能体默认的工作方式。

整个质量保证（QA）流程不再是独立的阶段。代码和测试用例同时生成、同时验证、同时迭代，不再需要交接，也不再是“把东西扔给QA”。代理程序可以自行完成QA工作。

代码审查：放弃吧
拉取请求流程应该被淘汰。我从来都不喜欢它，现在它更是过时的东西了。

我知道这让人不舒服。代码审查是神圣的。它是发现 bug、分享知识、维护标准的方式。它也关乎身份认同。我们是工程师，审查代码是工程师的职责。但在一个以代理为主导的世界里，固守 PR 流程并非严谨，而是一场身份认同危机。

想想看。一个代理每天生成 500 个 PR。你的团队可能只能审核 10 个。审核队列就会积压。这并非值得优化的瓶颈。这只是一个人为造成的瓶颈，它之所以存在，仅仅是因为我们把人类的流程强加到了机器的工作流程中。

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

代码审查必须从头开始重新设计。它可以成为代码生成过程的一部分，也可以由智能体根据计划文档验证自身工作、运行测试、检查回归问题、验证是否符合架构约束，或者由第二个智能体审查第一个智能体的输出。对抗性智能体会深入分析提出的变更，尝试从各个方面破坏它。我们已经拥有实现这一点的工具。人机交互审查将基于异常情况，仅当自动化验证无法解决冲突或变更涉及真正新颖的内容时才会触发。

如果没有拉取请求，世界会是什么样子？系统会将更改提交到主分支。自动化的检查、测试、类型检查、安全扫描、行为差异分析等流程会验证更改。如果一切顺利，更改就会自动发布。如果出现问题，系统会进行修复。只有当系统确实不知道该怎么做时，才需要人工干预。

我们把审核时间都花在阅读那些代理商几秒钟就能验证的差异上。这不是质量保证，这是技术落后。

部署方式：解耦且持续
代理商们已经能够编写出比大多数团队手动构建的更加复杂和专业的部署管道。功能开关、金丝雀发布、渐进式推广、自动回滚触发器，这些发布工程以前都需要专门的平台团队来完成。

关键的转变在于，代理程序自然而然地将部署与发布解耦。代码持续部署，每次变更一旦生成并验证，就会生成一个工件，该工件会通过安全门进入生产环境。发布则是一个独立的决策，由功能标志或流量规则驱动。

有些团队已经接近真正的持续部署和发布。代码生成、测试通过、工件构建、变更上线，所有这一切都在一个自动化流程中完成，从意图到生产环境之间无需人工干预。

接下来的发展方向更加令人期待。试想一下，如果代理不仅负责部署代码，还能管理整个发布生命周期，监控部署过程，根据错误率调整流量分配比例，在延迟飙升时自动回滚，并且只有在出现真正前所未有的问题时才会通知人工干预，那将会是怎样一番景象。部署“阶段”不仅实现了自动化，更变成了一个持续进行、自我调整的永无止境的过程。

监测：最后一个阶段，它需要不断发展
监控是软件开发生命周期中唯一保留下来的阶段。而且它不仅保留了下来，还成为了其他所有环节赖以生存的基础。

当系统交付代码的速度远超人工审核速度时，可观测性不再是锦上添花的仪表盘层，而是整个生命周期崩溃后的主要安全机制。其他所有保障措施，例如设计评审、代码评审、质量保证阶段和发布验收，都已被吸收或取消。监控成为仅存的手段，也是最后的防线。

但大多数可观测性平台都是为人设计的。警报、日志搜索、仪表盘等等，都是为了让人查看、解读和处理。当变更量超过人脑的处理能力时，这种模式就失效了。如果一个代理每天提交 500 次变更，而你的可观测性设置需要人工来调查每个异常，那么你就制造了一个新的瓶颈。你只是把瓶颈从代码审查转移到了事件响应。

缺乏行动的可观测性只是昂贵的存储。可观测性的未来不在于仪表盘，而在于闭环系统，其中遥测数据成为交付代码的代理的上下文信息，以便其能够检测并修复回归问题。

可观测性层成为驱动整个循环的反馈机制，而不是最后的阶段，而是整个系统的连接组织。

率先解决这一问题的团队——即能够将可观测性直接反馈到代理循环而非人工呼叫器——将比其他团队更快、更安全地交付产品。而那些未能做到这一点的团队将会被大量的警报淹没。

新的生命周期是一个更紧密的循环
软件开发生命周期是一个很长的循环：需求分析→设计→编码→测试→评审→部署→监控。线性流程，顺序执行，充满了交接和等待。

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

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

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

只不过是一个有意图的人和一个执行指令的代理。

那么还剩下什么呢？
背景。仅此而已。

你与代理共同构建的产品的质量，与你提供给他们的环境质量直接相关。不是过程，也不是仪式，而是环境。

软件开发生命周期（SDLC）已死。新的技能是情境工程。新的安全保障是可观测性。

而业内大多数企业仍在配置无人问津的 Datadog 控制面板。