第三章：新旧范式的核心差异
AOSE继承并升华敏捷理念，核心转变是从"亲手编码"到"定义需求规格与审查AI方案"。价值创造从实现环节前移至定义与验证，要求技术人员培养规格定义与AI审查的新核心能力。
1 从敏捷到意图驱动：一场范式的跃迁
回顾软件工程的发展历程，敏捷开发（Agile）无疑是过去二十年间最具影响力的范式革新。它通过短周期迭代、持续交付和快速响应变化等实践，有效解决了"如何在需求不断变化的环境中保持响应能力"这一核心问题。然而，随着大语言模型和AI Agent技术的成熟，软件工程正面临着一个全新的命题：“如何在AI时代重新定义人与机器的分工协作模式”。
面向智能体软件工程（AOSE）正是为回应这一命题而生。需要特别强调的是，AOSE绝非对敏捷理念的否定或颠覆，恰恰相反，它是在敏捷方法论基础上实现的又一次范式跃迁——敏捷解决了"人如何高效协作"的问题，而AOSE将进一步解决"人与AI如何高效协同"的问题。两者是一脉相承、递进演化的关系。
2 核心维度对比
为了更清晰地理解两种范式的差异，让我们从核心单元、开发流程、团队角色和交付物四个维度进行系统性的对比分析。
用户故事的演进：从人际沟通到人机协同
敏捷开发中的用户故事（User Story）作为需求表达的核心单元，在AOSE时代依然保有其价值，但其表达形式和目标受众发生了重要变化。
在传统敏捷实践中，用户故事主要服务于团队成员之间的沟通。经典的"作为一个<角色>，我想要<功能>，以便<价值>“格式，旨在促进业务人员与技术人员的对话，确保双方对需求有一致的理解。然而，这种自然语言的表达方式往往存在歧义，许多细节需要开发者在实现过程中自行推断。
在AOSE范式下，用户故事需要承载更多的使命：它不仅要让人类团队成员理解需求，还要让编码Agent能够准确执行。这就要求我们采用更加结构化、无歧义的表达方式。行为驱动开发（BDD）的Gherkin语法是一种行之有效的选择——它通过"Given-When-Then"的格式描述场景，既保持了自然语言的可读性，又具备了机器可解析的严谨结构。
这种演进的关键在于：产品需求定义"做什么”，作为人机共读的需求表达；技术人员据此定义实现规格，指导Agent完成"如何拆解和执行"。产品需求面向业务价值，实现规格面向技术执行，两者协作完成从需求到代码的转化。
需要强调的是，这里仅作概念性介绍。如何在实践中撰写适合Agent执行的用户故事和验收标准，将在后续的实施落地章节中详细阐述。
开发流程的变迁
| 开发阶段 | 敏捷开发实践 | 面向意图开发实践 |
|---|---|---|
| 需求输入 | 产品经理编写PRD文档，通过需求评审会讨论确认 | 产品经理定义业务需求和产品需求，技术人员据此指导Agent执行 |
| 任务拆解 | 技术负责人手动拆解任务，进行估点和排期 | 技术意图中的任务拆分直接指导Agent执行 |
| 编码实现 | 开发者手动编写每一行代码 | Agent根据技术意图的实现规格生成代码，人类审查 |
| 测试验证 | QA工程师编写测试用例，人工与自动化结合执行 | Agent根据验收规格自动生成并执行测试 |
| 代码审查 | 人工Review代码风格、逻辑正确性 | 人工审查意图对齐度、实现规格合理性 |
流程变迁的本质是价值创造环节的转移：人类从"亲手实现"转向"定义和验证"，AI接手"具体执行"的环节。
团队角色的变迁
| 角色 | 敏捷时代的核心能力要求 | AOSE时代的核心能力要求 |
|---|---|---|
| 产品经理 | 编写PRD、绘制原型、需求沟通协调 | 定义产品需求、设计业务规则、验证价值实现 |
| 架构师/技术负责人 | 绘制架构图、技术选型决策 | 定义技术意图（实现规格+约束）、设计系统拆分 |
| 开发者 | 编码实现、调试排错、性能优化 | 定义实现规格、审查AI方案、处理边缘情况 |
| 测试工程师 | 编写测试用例、执行测试、报告缺陷 | 设计验收规格、定义质量门禁、审查测试覆盖 |
| 运维工程师 | 系统部署、监控告警、故障处理 | SRE策略设计、配置自愈规则、可观测性架构 |
角色的变迁不是简单的技能替换，而是能力重心的转移。每个人都从"执行者"向"定义者"和"审查者"方向移动。
交付物的变迁
| 交付物类型 | 敏捷时代 | AOSE时代 |
|---|---|---|
| 需求文档 | PRD文档、用户故事列表 | 业务需求 + 产品需求 |
| 设计文档 | 架构图、时序图、流程图 | Agent执行过程产物 |
| 代码 | 主要由人类编写和维护 | AI根据实现规格生成，人类审查和编写关键模块 |
| 测试资产 | 人工编写的测试脚本和用例 | 验收规格驱动，AI生成测试代码 |
值得特别关注的是交付逻辑的升级：从"人类阅读文档后手动编码"转变为"编码Agent直接理解需求并生成代码"。这不是简单的文档形式变化，而是围绕编码智能体重构了价值交付链路——业务需求指明方向，产品需求定义功能，技术意图指导Agent完成具体开发。业务需求和产品需求构成需求层面的核心交付物，技术意图则是技术人员指导Agent执行的实现蓝图，使业务价值能够以更快的速度从概念转化为可运行的软件。
3 三种关键思维转变
范式转换的深层基础是思维模式的转变。从敏捷到AOSE，我们需要在三个维度上完成认知升级。
从"控制实现细节"到"定义实现规格"
在敏捷时代，架构师的工作往往是"控制型"的：绘制详细的类图、时序图、状态图，规定每一个模块的接口和数据结构。开发者的任务是按图索骥，严格遵循设计文档，不得偏离预设轨道。
在AOSE时代，技术负责人的角色转变为"实现规格定义者"：
- 不再手写每一行代码，而是定义技术意图中的实现规格——包括模块如何拆分、数据模型如何设计、接口契约如何定义、开发任务如何拆分；
- 不再规定"每个类应该如何实现"，而是定义"领域层不得依赖基础设施层"这样的架构约束，以及"所有对外接口必须满足P99响应时间<100ms"的性能约束；
- AI根据实现规格自主完成编码，人类负责审查实现是否符合规格、方案是否合理。
这种转变的本质是从编码执行者转向规格定义者。技术人员的核心价值体现在"能否定义出足够清晰、完整的实现规格，使得AI能够据此自主完成开发任务"。
从"亲手编写代码"到"审查AI方案"
让我们用流程图来直观展示这种变化：
敏捷时代的价值创造链：
需求 → 设计 → 编码 → 测试 → 上线
↑人类在此处创造核心价值
AOSE时代的价值创造链：
产品需求 + 技术意图 → Agent根据实现规格生成 → 人审查 → Agent实现 → 自动测试 → 人验收上线
↑人类定义功能方向和实现规格 ↑人类判断实现是否符合规格
价值的创造点从"编码实现"转移到了"产品需求定义"、“技术意图（实现规格）定义"和"实现审查”。这要求技术人员培养全新的能力：如何将产品功能拆解为可执行的模块、如何设计清晰的数据模型和接口契约、如何定义可验证的验收规格，以及如何快速判断AI生成实现是否符合规格。
从"人与人之间的协作"到"人与Agent、Agent与Agent之间的协同"
敏捷开发高度强调"人与人之间的互动"，每日站会、结对编程、代码审查等实践都是为了促进团队成员之间的高效协作。
AOSE时代则引入了新的协作维度：
- 人与Agent的协作：人类定义意图，Agent执行实现，人类审查结果；
- Agent与Agent的协作：多个专业化Agent并行工作——需求分析Agent、架构设计Agent、代码生成Agent、测试Agent等，它们之间通过结构化的意图描述进行协作。
这种转变并不意味着人与人之间的协作不再重要，而是说协作的复杂性和效率得到了AI的增强——人类可以聚焦于更高层次的策略讨论和价值判断，将执行层面的协调交给AI。
4 敏捷内核的保留与升华
面向智能体软件工程绝不是对敏捷的抛弃，恰恰相反，它升华了敏捷宣言中的核心价值，使其在AI时代焕发出新的生命力：
| 敏捷宣言原文 | 在AOSE中的具体体现 |
|---|---|
| 个体和互动 高于 流程和工具 | 人类专注于高价值的意图定义和验证，AI处理重复性的执行工作，释放人的创造力 |
| 工作的软件 高于 详尽的文档 | 轻量化的意图描述即可驱动Agent完成需求分析、设计并生成可运行软件，文档被极大简化 |
| 客户合作 高于 合同谈判 | 客户意图可快速通过Agent转化为可验证的原型，缩短反馈周期，实现需求实时对齐 |
| 响应变化 高于 遵循计划 | 意图变更后AI能够在分钟级别重新生成实现，响应速度实现指数级提升 |
基于这种传承与升华的关系，我们可以尝试提出面向智能体时代的"敏捷宣言2.0"：
- 意图的清晰明确 高于 代码的精巧复杂
- 约束的完备严谨 高于 流程的繁琐规范
- 人机协同的整体效率 高于 人与人之间的协调成本
- 价值的快速交付 高于 功能的快速堆砌
5 变革的阻力与应对策略
任何深刻的变革都会遇到阻力。理解这些阻力的来源并采取有效的应对策略，是转型成功的关键。
认知惯性：“不写代码，那我做什么？”
典型表现：资深开发者可能会问：“我写了十年代码，你现在让我不写代码，那我在干什么？我的价值在哪里？”
应对策略：
- 重新定义价值度量：帮助团队建立新的价值认知——从"我写了多少行代码"转变为"我定义了多少高价值产品需求"、“我设计了多少清晰的实现规格”、“我发现了多少AI方案中的问题”;
- 系统性技能升级培训：提供从编码技能到意图表达、约束设计、系统思维等新能力的培养路径；
- 树立标杆示范：让率先完成转型的成功者分享他们的经验和成就感来源，用事实说话。
流程依赖：“现在的流程跑得挺顺的”
典型表现：团队可能会说：“我们的Scrum流程已经跑顺了，Sprint节奏也很稳定，为什么要折腾？”
应对策略：
- 小步试点，以点带面：从非核心业务或新启动的项目开始试点，不触动已经在稳定运行的核心流程；
- 数据驱动决策：建立清晰的对比指标，用试点前后的效率、质量数据说话；
- 尊重既有仪式，改变实质内容：保留团队熟悉的敏捷仪式（如每日站会、Sprint回顾），但改变其讨论的内容——从"昨天写了什么代码"变为"昨天定义了哪些产品需求、完善了哪些实现规格"。
信任缺失：“我不相信AI能写好代码”
典型表现：对AI生成代码的质量持怀疑态度，担心引入不可控的风险。
应对策略：
- 建立透明机制：让AI在生成代码的同时解释"为什么选择这种实现方案"，增强可理解性和可审计性；
- 完善约束保障体系：通过规则引擎和静态检查工具确保AI不会越界，在风险可控的范围内逐步扩展AI的权限；
- 渐进式授权策略：从AI辅助编码（如代码补全）开始，逐步过渡到AI生成模块代码，再到AI实现完整功能，让团队在过程中逐步建立信任。
6 本章小结
通过对新旧范式的系统性对比，我们可以将核心差异归纳为一句话：
敏捷开发解决的核心问题是"人在需求变化中如何高效协作"，而面向智能体软件工程解决的核心问题是"人与AI如何分工协作、各尽所能"。
| 关键维度 | 敏捷时代的特征 | AOSE时代的特征 |
|---|---|---|
| 核心工作单元 | 用户故事（User Story） | 业务需求、产品需求、实现规格 |
| 人机分工模式 | 人类编写代码，机器负责编译执行 | 人类定义产品需求和技术意图，Agent根据实现规格生成代码 |
| 团队角色定位 | 按技能进行专业分工 | 产品人员定义业务需求和产品需求，技术人员定义实现规格 |
| 核心交付物 | 代码和文档 | 业务需求、产品需求、AI生成的代码 |
| 思维重心所在 | How（如何实现） | What（产品需求）+ How to implement（实现规格） |
这场变革不是对软件工程历史的否定，而是在AI能力跃升的背景下，软件工程的自然演进和升级。深刻理解这些差异，是我们成功完成范式过渡的前提和基础。
思考题
回顾你所在团队当前采用的敏捷实践（如Scrum、看板或XP），哪些实践在AOSE范式下可能变得不再必要，哪些实践需要保留但改变其形式？例如，每日站会是否还有价值？Sprint评审会的形式应该如何调整？
假设你的团队决定在下个季度试点AOSE范式，你认为最大的阻力会来自哪个角色——是担心价值被稀释的资深开发者、担心失去控制权的架构师，还是担心流程混乱的管理层？你将如何针对这一角色设计沟通策略？
对比敏捷宣言的四个价值观与AOSE的升华表述，哪一个转变对你个人的工作方式影响最大？是"文档被极大简化"带来的表达习惯改变，还是"客户意图快速验证"带来的协作模式变化？