软件工程在 AI Coding 的挑战
一、AI Coding 时代的核心挑战
无论 AI Coding 发展到什么阶段,软件研发中始终有三个维度的范围需要人来划定:
| 范围维度 | 要回答的问题 | 一旦模糊的后果 |
|---|---|---|
| 需求范围 | 做什么、不做什么?为谁做?成功标准是什么? | AI 产出功能正确但方向错误 |
| 技术范围 | 用什么技术栈?分层怎么切?模块边界在哪? | AI 写出的代码零散、无法集成 |
| 数据范围 | 有哪些实体?关系是什么?数据怎么流转? | 数据孤岛、接口不匹配 |
这与 Harness Engineering 的理念一脉相承——不是替代人的判断,而是将人的领域判断力"装上方向盘":让人来决定方向,让 AI 来执行驾驶。AI 的执行力放大了生产效率,但也同步放大了范围错误的代价。所以在 AI 时代,范围划定比以往任何时候都更重要。
二、我们的答案:BA + SA 划定三维范围,PM 统筹 Harness Engineering
真实的范围划定由 BA 和 SA 两个 Agent 承担——前者锁定业务边界,后者锁定技术边界:
flowchart LR
subgraph AGENTS["Agent 层"]
BA["BA Agent
业务分析师"] SA["SA Agent
系统架构师"] end subgraph SCOPE["三大范围维度"] D["数据范围
实体 / 关系 / 流转"] R["需求范围
做什么 / 不做什么
为谁做 / 成功标准"] T["技术范围
技术栈 / 分层
模块 / 部署 / 接口"] end PM["PM Agent
项目经理"] BA -->|"产出需求规格说明书
场景深挖 / 流程建模
数据字典 / 用户故事"| R BA -->|"产出数据字典
ER 图 / 字段规范
数据流图"| D SA -->|"产出技术架构说明书
总体架构 / 模块拆分
数据架构 / 部署架构"| T SA -->|"产出接口文档
部署指南"| T D -->|"数据基线"| PM R -->|"需求基线"| PM T -->|"技术基线"| PM PM -->|"Harness Engineering
迭代计划编排
工作量评估 / 进度协调"| OUT["项目整体计划
+ 可演示 MVP"]
业务分析师"] SA["SA Agent
系统架构师"] end subgraph SCOPE["三大范围维度"] D["数据范围
实体 / 关系 / 流转"] R["需求范围
做什么 / 不做什么
为谁做 / 成功标准"] T["技术范围
技术栈 / 分层
模块 / 部署 / 接口"] end PM["PM Agent
项目经理"] BA -->|"产出需求规格说明书
场景深挖 / 流程建模
数据字典 / 用户故事"| R BA -->|"产出数据字典
ER 图 / 字段规范
数据流图"| D SA -->|"产出技术架构说明书
总体架构 / 模块拆分
数据架构 / 部署架构"| T SA -->|"产出接口文档
部署指南"| T D -->|"数据基线"| PM R -->|"需求基线"| PM T -->|"技术基线"| PM PM -->|"Harness Engineering
迭代计划编排
工作量评估 / 进度协调"| OUT["项目整体计划
+ 可演示 MVP"]
BA Agent 覆盖需求范围和数据范围,SA Agent 覆盖技术范围。PM Agent 不直接划定范围,而是作为 Harness Engineering 的"方向盘"——基于 BA/SA 产出的需求基线、数据基线和技术基线,编排迭代节奏、协调交付进度,让需求和技术在正确的时序下对齐。
三、Agent 如何真正参与 MVP 过程
以迭代 0 为例,三个 Agent 的协作流程如下:
- 阶段一(概念输入):PM 收集素材、提炼概念级需求,BA 协助理解业务,SA 协助评估技术可行性
- 阶段二(三维并行):BA 产出初版 PRD(场景定义、业务流程、数据实体、系统边界)+ MVP 用户故事集;SA 产出技术风险评估(风险清单、初步架构图、集成方案)+ 开发任务清单;PM 整合产出执行计划和项目计划总表
- 阶段三(范围确认):PM 主持业务-技术交叉评审,BA 和 SA 从各自维度回应,最终敲定 In/Out/TBD/Won't 范围
- 阶段四(执行期):开发团队编码 MVP,BA 深化全量 PRD(流程建模、数据字典、全量故事),SA 深化全量架构(模块拆分、接口、数据、部署、非功能架构),BA/SA 穿插审阅开发产出
这个四阶段模型是 PM Agent 驱动迭代 0 的核心框架,详细的执行流程和任务拆解请见 迭代0计划。
四、如何开始
你可以按以下顺序探索: