Is The Software Development Lifecycle Changed 软件开发生命周期是否改变
AI agent 时代，我们的软件开发生命周期是否改变？
在 2026 年的时间里，AI Agent 能力在快速的发展，各种各种的 Skills 快速出现。这好像使得软件开发的生命周期已经改变。 一个不需要太多时间学习，没有软件编程经验的人，也可以使用 AI Agent 来完成软件开发的任务，而且是以比以前更快的速度来完成。
作为我们软件工程师赖以生存的软件开发生命周期是不是真的改变了，还是只是提升效率呢。
我们所遵循的软件开发生命周期
以上是我们大多数人遵循的经典的软件开发生命周期。
每个阶段都有专属的工具、流程、规范，和负责的人员。大家在整个流程中互相协作，把一个需求想法转化为一个上线的功能。
- 需求分析：可以使用 Jira，飞书等工具。
- UI 设计：Figma 或者 Sketch。
- 开发：VsCode 用于开发。
- 测试：Jest / Vitest 构建单测和 Cypress 用于 E2E 测试。部分业务需求需要 QA 人工完成测试。
- Code Review：gitlab / GitHub 等代码仓库进行 Code Review。
- 上线部署：使用 vercel / AWS 等服务进行部署。
- 监控：使用 Grafana / Sentry 等监控工具进行监控。
每一步都是独立且不可或缺的，我们按流程顺序进行，并和不同的角色进行协作，完成整个流程。
当使用 Coding Agent 时的软件开发流程
各个阶段被重新定义了，它不是变得更快，而是整个流程被重新组织了。没有严格的步骤，只有意图、上下文、迭代。
你和 Agent 描述你的需求，Agent 会根据你的需求，调用不同的 Skills 来完成任务，包括开发、测试。你审查代码，并做些修改，并完成发布。
每个步骤都已经发生改变了吗
让我们再看一下遵循的的传统软件开发流程，还剩下什么？
需求确认：灵活、面向 AI Agent 设计
过去，每个需求都是下达式的，产品经理负责编写产品需求文档（PRD），工程师进行评估，确认最终要实现的需求细节。
现在，当智能体能在几个小时能就能完成一个完整的功能版本时，在公司内复杂的业务产品中，我觉得需求会会出现两种类型：
- 不需要 PRD，Agent 直接完成：当前 Agent 已经能够理解上下文，对于足够清晰的改动（一般比较小、涉及模块比较少），这种情况 Agent 能够直接完成。所以不需要产品经理描述需求，只需要工程师根据上下文，描述一下改动即可。
- 面向 AI Agent 设计的需求：如果 PRD 能够对 Agent 提供更加清晰的上下文和任务描述，最终生成的结果会更加可控。这就要求一个需求描述，把任务拆解描述清楚。让 Agent 可以按照需求描述，根据任务描述，来完成任务。
技术方案设计：和 Agent 协作设计
系统设计仍然非常重要，但是实现方式正在发生变化。
过去，方案设计在编写代码之前完成。我们需要做好系统架构设计、流程设计，花费大量时间去探索权衡不同方案的优缺点。确认最终的方案后再去实现它。
现在，我们首先要意识到，Agent 所接触、理解的系统、架构、模式比任何单个工程师都多得多。当我提供一个问题的时候，Agent 不仅仅会实现代码，而且还会 提出一些优于你独立思考的方案。
所以，我们需要和 Agent 协作设计，而不是单独完成。给它更多的上下文（包括业务场景、问题等）让它为我们提供更多的思路，最后你来决策最合适的设计方案。
开发：主要交给 Agent，这是它的工作
这一点显而易见，Agent 很会写代码，而且很快。我们主要负责 Review Agent 的代码。
我们应该更加专注为 Agent 提供上下文，引导它朝着正确的方向前进（Skill、MCP 等），并专注于需要人类判断的问题。
测试：Agent 会同时进行
Agent 会同时进行测试，确保代码的质量。而不是事后添加，也不是单独的“测试阶段”。测试是代码开发中的一部分。
过去，TDD 像是一种理想的开发模式，很多研发不能很好的实践它。我们还是先开发，然后补充相关的单元测试、E2E 测试。一些业务需求需要 QA 人工完成测试。
现在，整个质量保证不再是独立阶段。代码和测试用例同时生成、同时验证、同时迭代，不再需要交接，也不再是“把东西扔给 QA”。Agent 可以自行完成 QA 工作。
Code Review：需要重新设计
理想情况，Agent 会自动完成 Code Review。但是 Code Review 需要谨慎对待环节，因为 Code review 不仅仅是检查代码是否符合规范，还需要检查代码是否符合业务需求。
过去 Code review 一直被当作发现 bug、分享知识、维护规范的重要环节。随着 Agent 对研发效率的提升，如果 Code Review 完全依赖研发来完成，会逐渐成为一个瓶颈。
未来需要重新设计：
- 融入到在开发阶段：它可以成为代码生成过程的一部分，Agent 根据计划文档验证自身工作、运行测试、检查问题、验证是否符合规范。
- Agent 互相审查：由第二个 Agent 审查第一个 Agent 的输出。
当出现冲突或者可疑问题时，人工进行 Code Review。
现在 Agent 还不能很好的获取浏览器实际运行的结果，如果未来 Agent 能够很好的感知浏览器的行为，那么 Code Review 就不需要人工参与了。
上线部署：持续进行和自我调整
在过去，未来稳定性考虑，我们一般需要严格控制上线部署的时间和窗口。
而现在，Agents 已经能够编写出比大多数团队手动构建的更加复杂和专业的部署 pipeline。关键的转变在于，Agent 自然而然地将部署与发布解耦。
- 代码持续部署，每次变更一旦生成并验证，便能自动生成一个集成任务，通过发布流程进入生产环境。
- 发布则是一个独立的决策，由功能标志（Feature Flag）或流量规则（Traffic Rules）驱动。
试想一下，如果 Agent 不仅负责部署代码，还能管理整个发布生命周期，监控部署过程，根据错误率调整流量分配比例，在出现错误时自动回滚，并且只有在出现真正前所未有的问题时才会通知人工干预，那将会是怎样一番景象。 部署“阶段”不仅实现了自动化，更变成了一个持续进行、自我调整的永无止境的过程。
监控：还需要不断的发展
监控是软件开发生命周期中唯一保留下来的阶段。
当我们交付代码的速度远超人工 Review 的速度时，监控就显得更加重要了，可观测性将作为整个生命周期崩溃后的主要安全机制。其他的步骤要么被简化或者取消了。
但现在很多监控系统主要还是为人设计的，警报、日志搜索、仪表盘等等，都是为了让人查看、分析、处理的。如果未来，每天上线 10 个变更，我们不可能依赖人工去检查每个异常。
可观测性层成为驱动整个循环的反馈机制，而不是最后的阶段，而是整个系统的连接组织
能够将可观测性直接反馈到 Agent 循环而非人工 on call ——将比其他团队更快、更安全地交付产品。那些未能做到这一点的团队将会被大量的警报淹没。
新的软件开发生命周期
