22
33## 目标
44
5- 定义 AgentDevFlow 的完整开发交付流程,基于 hedge-ai V2.0/V2.2 双 PR 机制,作为所有 Agent 的核心必读流程文档。
5+ 定义 AgentDevFlow 的完整开发交付流程,基于 V2.0/V2.2 双 PR 机制,作为所有 Agent 的核心必读流程文档。
66
77本文档与 ` 004_delivery_gates.md ` (Gate 合规检查定义)、` 017_human_review_and_signoff.md ` (Human Review 规范)配套使用。
88
9- ## 流程概览
9+ ## 关键原则(Critical Rules)
10+
11+ - ** Issue 是强制入口** :无 Issue 不进入正式交付流程
12+ - ** 无 Issue 不进入 PRD** :PM 领取 Issue 后与 Human 讨论(必须 Comment)才能开始 PRD
13+ - ** 讨论结果必须 Comment** :每次讨论结束必须将结论 Comment 到 Issue,** 未 Comment 视为未完成**
14+ - ** 方案不等于有效** :当 Issue 包含解决方案时,PM 必须回归问题本身讨论
15+ - ** PRD 不含技术实现** :PRD 只描述问题/产品设计/能力边界/方案,不含技术实现
16+ - ** 无 PRD Review 不进入 Tech Review**
17+ - ** 无 Human Review #1 不进入 Implementation**
18+ - ** 双 PR 分支策略** :文档 PR(doc-{issue})和代码 PR(feature-{issue})分离
19+ - ** 文档 PR 合并 = 设计确认**
20+ - ** 代码 PR 合并 = 实现确认**
21+ - ** PR 合并是 Human 专属操作** ,Agent 只负责推动流程,不执行合并
22+ - ** Issue 关闭是 Human 专属操作** ,Agent 只负责发布关闭请求评论
23+ - Human Review 结论未正式落地,不视为通过
24+ - ** 打回 = 回滚 + 重新走流程** :任意节点被打回 → 回滚到该节点编写阶段 → 修改文档(版本+1)→ 从该节点重新走完整流程
25+ - ** 变更级联效应** :PRD 变更 → Tech Spec 版本+1 → Case Design 版本+1;Tech Spec 发生 Major/Breaking 变更 → 回到 Gate 1 重新评审 PRD
26+
27+ ---
28+
29+ ## 三个流程图
30+
31+ 本文档包含三个独立的流程图,从不同视角描述开发交付流程:
32+
33+ ### 流程图 A:完整 Issue 交付流程(正向流程,从认领到关闭)
1034
1135```
12- Agent Team 启动
13- │
14- ▼
15- 扫描所有 open GitHub Issues(Human 随时可能创建新 Issue)
16- │
17- ▼
18- PM 领取 Issue → 与 Human 讨论问题(必须 Comment 到 Issue)
36+ PM 领取 Issue → 与 Human 讨论问题(每次讨论后必须 Comment 到 Issue)
1937 │
2038 ▼
2139Gate 1: PRD Review — 需求评审(PM + Architect + QA 三方签字)
2240 │
2341 ▼
24- Gate 2: Tech Review — 技术评审(PM + QA 两签 )
42+ Gate 2: Tech Review — 技术评审(QA + Engineer + PM 三签 )
2543 │
2644 ▼
2745QA Case Design(三方:PM + Architect + Engineer 签字)
@@ -38,16 +56,32 @@ Gate 3: Implementation — 开发实现(feature-{issue} 分支)
3856 ▼
3957Gate 4: QA Validation — 质量验证
4058 │
41- ▼
59+ ├── QA 根据 Case Design 开发测试代码(case 代码)
60+ ├── QA 运行 case 验证 Engineer 完成的代码质量
61+ ├── 不合格 → 排查问题来源:
62+ │ • 代码问题 → Engineer 修复 → 重新验证
63+ │ • Case 问题 → QA 修复 case → 重新验证
64+ ├── 验证通过 → QA 编写测试报告(QA Report)
65+ │
66+ ├── PM + Architect + Engineer 三方评审测试报告并签字
67+ │
68+ ▼ (通过)
4269代码 PR(feature-{issue} 分支)— Human Review #2
4370 │
4471 ▼
4572代码 PR 合并 = 实现确认 ✅
4673 │
4774 ▼
48- Gate 5: Release / Issue Close — 发布 / 关闭
75+ Gate 5: Release — 发布
76+ │
77+ ▼
78+ PM 通过 github_issue_sync.py 发布关闭请求 → Human 执行关闭
4979```
5080
81+ ** 强制 Comment 规则** :` PM 领取 Issue ` 后每次与 Human 讨论结束必须 Comment 到 Issue。** 未 Comment 视为未完成** ,不得进入下一阶段。
82+
83+ ** Human Review 绑定** :Human Review #1 = 文档 PR(doc-{issue})合并 = 设计确认;Human Review #2 = 代码 PR(feature-{issue})合并 = 实现确认。
84+
5185### 流程图 B:需求变更与打回流程(异常处理)
5286
5387```
@@ -105,27 +139,70 @@ Team Lead 协调多角色并行工作
105139- 流程图 B:需求变更与打回的异常处理流程(被打回时触发)
106140- 流程图 C:Team 启动后的全局视角(多 Issue 并行调度)
107141
108- ## 关键原则
142+ ---
109143
110- - ** Issue 是强制入口** :无 Issue 不进入正式交付流程
111- - ** 无 Issue 不进入 PRD** :PM 领取 Issue 后与 Human 讨论(必须 Comment)才能开始 PRD
112- - ** 讨论结果必须 Comment** :每次讨论结束必须将结论 Comment 到 Issue,** 未 Comment 视为未完成**
113- - ** 方案不等于有效** :当 Issue 包含解决方案时,PM 必须回归问题本身讨论
114- - ** PRD 不含技术实现** :PRD 只描述问题/产品设计/能力边界/方案,不含技术实现
115- - ** 无 PRD Review 不进入 Tech Review**
116- - ** 无 Human Review #1 不进入 Implementation**
117- - ** 双 PR 分支策略** :文档 PR(doc-{issue})和代码 PR(feature-{issue})分离
118- - ** 文档 PR 合并 = 设计确认**
119- - ** 代码 PR 合并 = 实现确认**
120- - ** PR 合并是 Human 专属操作** ,Agent 只负责推动流程,不执行合并
121- - ** Issue 关闭是 Human 专属操作** ,Agent 只负责发布关闭请求评论
122- - Human Review 结论未正式落地,不视为通过
123- - ** 打回 = 回滚 + 重新走流程** :任意节点被打回 → 回滚到该节点编写阶段 → 修改文档(版本+1)→ 从该节点重新走完整流程
124- - ** 变更级联效应** :PRD 发生变更 → Tech Spec 需同步变更(版本+1)→ Case Design 需同步变更(版本+1);Tech Spec 发生 Major/Breaking 变更 → 回到 Gate 1 重新评审 PRD
144+ ## 双 PR 分支策略
145+
146+ ### 分支命名
147+
148+ | 阶段 | 分支名 | 内容 | Human Review |
149+ | ------| --------| ------| --------------|
150+ | 设计确认 | ` doc-{issue_number}-{简短描述} ` | PRD + Tech + QA Case Design | ** HR#1** |
151+ | 实现确认 | ` feature-{issue_number}-{简短描述} ` | 代码 + 测试报告 | ** HR#2** |
152+
153+ ### 文档 PR 创建条件(必须同时满足)
154+
155+ ```
156+ ✅ PRD 文档完成(docs/prd/PRD-XXX_v*.md)
157+ ✅ Tech 文档完成(docs/tech/Tech-XXX_v*.md)
158+ ✅ Gate 2 Tech Review 三签通过(QA + Engineer + PM)
159+ ✅ QA Case Design 完成(docs/qa/QA-Case-XXX_v*.md)
160+ ```
161+
162+ ### 代码 PR 创建条件(必须同时满足)
163+
164+ ```
165+ ✅ 文档 PR 已合并(设计已确认)
166+ ✅ 代码开发完成
167+ ✅ QA 测试报告完成(docs/qa/qa-report-XXX_v*.md)
168+ ✅ 三方签字验收完成(Architect + Engineer + PM)
169+ ```
170+
171+ ---
172+
173+ ## Issue Comment 强制要求(V2.2.4)
174+
175+ ** ⚠️ 强制规则** :未 Comment 视为未完成。每个角色完成工作后必须在 Issue 下 Comment。
176+
177+ | 节点 | 执行者 | Comment 内容 | 示例 |
178+ | ------| --------| -------------| ------|
179+ | Issue 领取 | PM | 说明领取,开始分析 | "Issue #N 已领取,开始分析需求" |
180+ | 问题讨论完成 | PM | 讨论结论(回归问题本质)| "讨论完成:问题根源是 X,方案 Y 已被否决" |
181+ | PRD 产出 | PM | PRD 链接 + 概述 | "PRD 已完成: [ 链接] - 概述..." |
182+ | PRD 评审完成 | PM | 评审结论 + 签署人 | "PRD 评审通过 - PM[ ✅] Architect[ ✅] QA[ ✅] " |
183+ | Tech 产出 | Architect | Tech 链接 + 概述 | "Tech 已完成: [ 链接] - 概述..." |
184+ | Tech Review 完成 | Architect | 评审结论 + 签署人 | "Tech Review 通过 - PM[ ✅] QA[ ✅] " |
185+ | QA Case Design 完成 | QA | Case 链接 + 概述 | "QA Case Design 完成: [ 链接] " |
186+ | 文档 PR 创建 | PM | PR 链接 + 文档清单 | "文档 PR 已创建: [ 链接] - PRD/Tech/QA Case" |
187+ | 文档 PR 合并 | PM | 合并确认 | "文档 PR 已合并,设计确认完毕" |
188+ | 开发完成 | Engineer | 开发报告 | "开发完成 - [ 组件列表] - 待测试" |
189+ | 测试完成 | QA | 测试报告链接 | "测试完成 - [ 报告链接] " |
190+ | 代码 PR 创建 | Engineer | PR 链接 + 测试报告 | "代码 PR 已创建: [ 链接] - Fixes #N" |
191+ | 代码 PR 合并 | Engineer | 合并确认 | "代码 PR 已合并 - 等待 Issue 关闭" |
192+ | Issue 关闭 | PM | 关闭原因 + 关闭请求 | "Issue #N 请求关闭 - 完成/重复/无法复现" |
193+
194+ ** 必须通过 ` scripts/github_issue_sync.py ` 发布 Comment** :
195+ ``` bash
196+ python scripts/github_issue_sync.py \
197+ --post-comment \
198+ --issue N \
199+ --body " $( cat comment.md) " \
200+ --agent " Agent名称"
201+ ```
125202
126203---
127204
128- ## 前置阶段:PM 领取 Issue + 讨论
205+ ## 阶段详解
129206
130207### 触发条件
131208
0 commit comments