第五章：开发流程的重构

面向智能体的软件工程将开发核心从"写代码"转移到"描述需求"，核心矛盾从人际沟通成本转变为需求精确性。通过"需求撰写→Agent执行→价值验证"的三阶段闭环，迭代周期从数周压缩至小时级，人类从编码执行者转变为需求架构师和Agent指挥官。

1 为什么流程必须重构

当AI Agent从辅助工具演进为执行主体，软件开发的根本性矛盾也随之转移。传统敏捷流程的核心痛点在于"协作中的沟通成本"——需求从业务方传递到产品经理，再传递到技术团队，每一个环节都伴随着信息的损耗和理解的偏差。而在面向智能体的范式下，这一矛盾被转化为"需求的精确性与一致性"问题——只要需求能够被清晰、无歧义地表达，AI Agent就能够忠实地将其转化为可运行的软件，沟通成本几乎降为零。

这种根本矛盾的转移，决定了流程必须围绕新的核心要素重新设计。传统的敏捷流程是围绕"人"和"人与人之间的协作"而构建的，它的每一个仪式——需求评审会、每日站会、迭代回顾会——都是为了促进团队成员之间的信息同步和共识达成。然而，在面向智能体的软件工程中，执行主体变成了AI Agent，流程的设计逻辑必须转向如何确保"需求能够被正确理解、严格执行和有效验证"。这意味着，我们需要一套全新的流程框架，围绕"需求"的生命周期——从定义、拆解、执行到验证——来重新组织开发活动。

2 新旧流程对比

敏捷开发流程回顾

Scrum敏捷流程的核心特征：以2-4周为固定迭代周期，通过产品待办列表（Product Backlog）管理需求，依赖每日站会、评审会和回顾会等仪式促进团队同步。流程以人为核心，需求从业务方→产品经理→开发团队的逐级传递中易产生信息损耗，编码、测试、评审均需人工逐环节执行，沟通成本高且迭代节奏受限于人类工作时长与上下文切换效率。

面向智能体开发流程

Agent时代软件工程的核心特征：从"纯人工链路"演进为"人机协同的闭环系统"。产品经理转化为"提示工程师"，负责定义产品灵魂和边界，将模糊需求转化为智能体可理解的高质量指令；Coding Agent承担80%以上的基础编码、测试工作，工程师从"写代码"转变为"看代码"，专注架构设计与核心逻辑评审；Ops Agent自主执行发布上线、灰度发布与故障自愈，人类仅作为"最后一道防线"兜底。需求→开发→运维的数据与经验通过Agent快速反馈沉淀，形成持续进化的自动化飞轮。

3 流程环节的详细对比

4 面向智能体的核心流程环节

需求撰写与迭代（Requirements Authoring & Iteration）

目的：产品经理定义清晰的产品需求，Agent在理解过程中逐步澄清需求并迭代技术方案

参与者：产品经理（主导业务需求和产品需求）、Agent工程师/技术负责人（审核技术方案）、业务方（确认业务价值）

输出物：

• 业务需求文档（Why）：阐明业务目标和价值主张
• 产品需求文档（What）：定义功能、场景、用户体验和验收标准（产品经理撰写）
• 技术需求（How）：在开发过程中逐步形成的实现规格——包括系统如何拆分模块、核心数据模型如何设计、接口契约如何定义（Agent生成，人类审核确认）

关键活动：

三个阶段紧密衔接：

第一阶段：产品经理定义产品需求。产品经理撰写结构化的业务需求（Why）和产品需求（What），明确"为什么要做"、“做成什么样”。需求边界越清晰，Agent执行效率越高。

第二阶段：Agent理解与需求澄清。Agent主动分析需求边界和潜在歧义点，如有疑问会向产品经理请求澄清。例如：“徽章颜色建议用金色体现尊贵感，是否使用品牌色#FFD700？”

第三阶段：技术需求迭代形成。技术需求在开发过程中逐步涌现：Agent基于澄清后的产品需求生成技术方案（实现规格），Agent工程师审核技术方案并提出修改意见（如"建议采用Redis缓存提升查询性能"），Agent根据反馈优化方案，识别需求间的依赖与冲突，形成最终的技术需求。

这种"产品经理定义产品需求 → Agent理解澄清 → 迭代形成技术需求"的流程，充分发挥了Agent的自主性，同时保留了人类在关键决策点的把控。

为什么是"涌现式"而非"预设式"？

传统开发中，技术方案需要在编码前完全确定，这要求人类在前期就考虑到所有边界条件和实现细节。但在AOSE模式下，技术需求是在人机对话中逐步"涌现"的——Agent基于产品需求生成初步方案，人类针对关键设计点提出约束（如缓存策略、接口契约），Agent再根据反馈优化。这种方式的优势在于：

• 降低前期认知负担：无需在一开始就穷举所有技术细节
• 充分利用Agent的全局分析能力：Agent可以快速评估多种技术方案的优劣
• 快速响应需求变化：当产品需求调整时，技术方案可以灵活重构

Agent执行

目的：编码Agent基于需求自主完成开发任务

当前模式（IDE时代）：

目前主流的编码Agent（如Cursor、Windsurf等）以IDE插件形式存在。人类通过自然语言指令与Agent交互，Agent内置多个能力模块（代码生成、重构、测试、调试等），根据指令自动选择合适的能力执行任务。

工作流程：

flowchart LR
    A[人类指令] --> B[Agent分析]
    B --> C[需求澄清]
    C --> D[技术设计]
    D --> E[任务拆解]
    E --> F[代码实现]
    F --> G[人类验证]

    style A fill:#e8f5e9,stroke:#333,stroke-width:2px
    style G fill:#fff3e0,stroke:#333,stroke-width:2px

关键活动：Agent接收需求文档后，依次完成需求分析（识别模糊点，必要时向人类澄清）、技术设计（生成技术方案，人类审核确认）、任务拆解（自主拆解任务，确定执行顺序）、代码实现与单元测试（编码、调试、生成测试，失败时自我诊断修复）、端到端测试（开发测试用例，准备测试数据，验证功能完整性）、结果交付（提交代码、测试及说明）。整个过程形成开发-测试闭环，Agent自主处理大部分工作，人类仅需监控关键决策点。

Agent的自我审视与迭代机制：

sequenceDiagram
    participant H as 人类指挥者
    participant A as 编码Agent

    H->>A: 1. 输入需求文档

    opt 需求澄清（可选）
        A->>A: 分析需求，识别模糊点
        alt 需求存在疑问
            A->>H: 请求澄清
            H-->>A: 提供解答
        else 需求明确
            A->>A: 完成需求分析
        end
    end

    opt 技术方案确认（可选）
        A->>A: 生成技术方案
        A->>H: 提交方案审核
        alt 方案需调整
            H-->>A: 反馈修改意见
            A->>A: 优化技术方案
        else 方案确认通过
            H-->>A: 批准执行
        end
    end

    A->>A: 拆解开发任务

    loop 编码与单元测试循环
        A->>A: 编写代码 + 生成单元测试
        alt 单元测试失败
            A->>A: 自我诊断并修复代码
        else 单元测试通过
            A->>A: 继续下一步
        end
    end

    A->>A: 开发端到端测试用例 + 准备测试数据

    loop 端到端测试验证循环
        A->>A: 执行端到端测试
        alt 发现Bug
            A->>A: 返回编码阶段修复
        else 测试通过
            A->>A: 验证完成
        end
    end

    A->>H: 提交结果（代码+测试+数据+说明）

关键决策点说明：

• 需求模糊 → 找人类澄清：Agent在分析阶段遇到不确定点时主动寻求人类确认
• 单元测试失败 → 自我修改代码：Agent自主诊断测试失败原因并修复代码
• 端到端测试失败 → 返回编码阶段修复：Bug修复后重新执行测试闭环

未来模式（Web时代）：

随着编码Agent能力成熟，开发界面将从IDE向Web演进。人类通过Web界面向Agent下达指令，Agent在云端完成全部开发工作。人类角色从"代码编写者"彻底转变为"Agent指挥者和协调者"：

• 协调多Agent协作：当涉及多个系统模块时，协调不同Agent实例并行工作
• 冲突解决：处理Agent间依赖冲突和边界问题
• 结果验证：审核Agent产出，确保符合原始需求
• 质量把控：对关键设计决策进行人工确认

上线与价值验证（Deployment & Value Verification）

目的：将功能部署上线，收集用户反馈，验证商业价值

技术测试已完成：在 6.4.2 Agent执行阶段，单元测试、端到端测试、代码质量检查已全部完成并通过。此阶段不再进行技术验证，专注于业务价值验证。

参与者：产品经理（主导）、业务方、数据分析师

关键活动：

1. 部署上线：Agent自动完成代码合并、构建、发布流程
2. 用户反馈收集：通过埋点数据、用户行为分析、直接反馈渠道收集用户反应
3. 商业价值验证：对比业务目标，验证是否达成预期效果
4. 快速迭代决策：基于反馈决定是否继续优化、回滚或推广

价值验证指标：

• 用户行为指标：功能使用率、完成率、停留时长变化
• 业务目标指标：转化率提升、收入变化、成本节约
• 用户满意度：NPS评分、反馈情感分析、客诉变化

输出物：

• 上线部署报告
• 用户反馈综合分析
• 商业价值达成度评估
• 后续迭代建议

关键角色的转变

产品经理：从PRD撰写者到需求架构师

传统模式下，产品经理的核心产出是PRD文档，通过文字和原型描述功能。在AOSE模式下，产品经理更像是"提示工程师"（Prompt Engineer），需要把模糊的业务诉求转化为结构化的、Agent可理解的需求规格。这不仅要求对业务有深度理解，还需要具备将人类语言精准转换为机器可执行指令的能力。

Agent工程师：从代码编写者到Agent指挥官

这是AOSE时代诞生的新角色。Agent工程师不需要像传统工程师那样逐行编码，而是需要：

• 设计技术约束与验收标准：定义"好代码"的边界条件
• 审核Agent生成的技术方案：在关键设计决策点把关
• 处理Agent无法自主解决的复杂问题：如系统架构调整、跨模块依赖冲突
• 持续优化Agent的执行效率：通过调整约束规则提升Agent的一次成功率

运维工程师：从被动响应到主动兜底

在Agent主导的运维模式下：

• 日常运维：发布上线、灰度放量、监控告警、故障自愈由Ops Agent自主完成
• 人工介入：仅在复杂生产环境或Agent无法决策的突发状况下介入
• 角色转变：从"盯着仪表盘"变为"设计运维策略和兜底预案"

5 本章小结

面向智能体的软件工程从根本上重构了软件开发流程。传统敏捷流程的核心矛盾是"人与人之间的沟通成本"，而AOSE将这一矛盾转化为"需求的精确性与一致性"问题——只要需求能够被清晰表达，AI Agent就能够忠实地将其转化为可运行的软件。

核心流程的三阶段闭环

AOSE流程的本质是从"写代码"转移到"描述需求"，形成"需求撰写 → Agent执行 → 价值验证"的飞轮：

1. 需求撰写与迭代：产品经理定义业务需求和产品需求，Agent主动分析并澄清模糊点，通过人机协作迭代形成技术需求。技术需求在开发过程中"涌现"，而非一开始就完全预设。

2. Agent执行：Agent自主完成需求分析、技术设计、代码实现、测试验证的全流程，人类仅在关键决策点介入。Agent自我诊断并修复代码问题，形成开发-测试闭环。

3. 上线与价值验证：Agent自动完成部署与灰度发布，此阶段完全聚焦于业务价值验证——用户是否真正感知到新功能？行为数据是否支持业务假设？财务指标是否改善？基于数据洞察规划下一迭代。

关键转变

实践效果

以一个典型的会员徽章功能开发为例：

• 时间效率：需求撰写45分钟 + Agent执行40分钟 + 部署5分钟 = 1.5小时内完成从需求到上线
• 人工分布：产品经理主导需求撰写（67%时间），Agent工程师监控执行（11%时间），上线验证（22%时间）
• 质量成果：代码覆盖率87%，接口响应10ms，零故障上线
• 业务价值：续费率+3%，NPS+3分，预估年增收150万元

流程本质

AOSE流程的本质是将软件开发的重心从"如何写代码"转移到"如何描述需求"。当Agent能够以极高效率将需求转化为代码时，人类的真正价值在于：

1. 精准描述业务需求：让Agent理解"为什么做"和"做成什么样"
2. 设计有效验证方式：确保能够衡量业务目标的达成度
3. 基于数据持续优化：将验证结果转化为下一轮的需求输入

流程不再是管理"人的工作"，而是管理"需求的流动"——从业务需求到产品需求，从技术需求到可运行软件，从用户反馈到新的业务需求。这种流动越快，组织的创新能力就越强。

思考题

1. 对比传统敏捷的"需求评审→技术方案→编码实现"流程与AOSE的"产品需求→Agent澄清→迭代技术需求"流程，你认为后者最大的变化是什么？这种变化对产品经理的能力要求有何不同？

2. 在"需求撰写与迭代"流程中，技术需求是在开发过程中逐步形成的，而非一开始就完全预设。这种"涌现式"的技术设计方式，与你当前的开发实践有何差异？你认为这种方式会带来哪些优势或风险？

3. 回顾你最近完成的一个功能开发，如果按照本章的AOSE流程重新梳理，产品需求应该如何撰写？Agent可能会在需求澄清阶段提出哪些问题？技术需求又会在哪些关键决策点上逐步成型？