37 lines
2.4 KiB
Markdown
37 lines
2.4 KiB
Markdown
# Phase 4：需求反向验收规程
|
||
|
||
**问题意识**：Phase 4 检查的不是"文档漂不漂亮"，而是**需求是否明确到足以形成规格**。核心一问：
|
||
|
||
> "一个完全没有参与讨论的资深工程师现在接手开发，哪些重要产品行为仍然需要他自己猜测？哪些必须回头找需求负责人确认？"
|
||
|
||
## 执行方式（按优先级）
|
||
|
||
1. **子代理独立审查（首选）**：用 Agent 工具派 fresh-context 子代理（general-purpose 或 Explore）。提示词要点：
|
||
- 角色：资深开发工程师，第一次见到这个项目；
|
||
- 输入：只给 state.md 路径（+ 已有 openspec specs 路径，如有）——**不给会话历史、不给 Le SPEC 的阶段叙事**，确保视角独立；
|
||
- 任务：逐条检查下列清单，输出"我会被迫猜测/必须确认"的清单，每条注明影响哪个功能点与后果严重度；
|
||
- 产出格式：问题列表（问题/影响/严重度建议/建议澄清方式）。
|
||
2. **无子代理能力时的降级**：自审前显式重置角色（"放下前文立场，作为首次接手的工程师仅凭 state.md 判断"），只允许引用 state.md 与项目文件内容。**必须在产出中声明"本轮为同上下文自审，独立性弱于子代理审查"**——不装作独立。
|
||
|
||
## 检查清单
|
||
|
||
- [ ] 用户流程有断点（走不到下一步/回不去）
|
||
- [ ] 功能之间缺关联规则（A 发生时 B 如何）
|
||
- [ ] 数据关系歧义（谁拥有谁、一对多还是多对多、删除级联）
|
||
- [ ] 状态机不完整（缺状态、缺转换、缺终态）
|
||
- [ ] 权限与业务边界不明（谁能做什么、越界怎样）
|
||
- [ ] 异常场景缺处理原则（失败/超时/并发/空数据）
|
||
- [ ] 需求间冲突（同一对象两种定义）
|
||
- [ ] 未经确认的重要默认假设（state.md 里的 [默认] 项逐条复核用户知情度）
|
||
- [ ] 验收判据缺失（做完了怎么算"对"）
|
||
|
||
## 分级与处置
|
||
|
||
| 级别 | 判定 | 处置 |
|
||
|---|---|---|
|
||
| blocking | 不澄清就无法实现核心行为 / 两种理解导致完全不同的产品 | 终止回合向用户澄清（用 grilling 单轮格式，记账本） |
|
||
| major | 影响正确性但可从已确认决策推导 | 推导入 state.md 并标注依据；推导不了升 blocking |
|
||
| minor | 边缘场景、可延后 | 记开放问题，进 SPEC 的"非阻塞事项" |
|
||
|
||
更新后**只复核受影响项**，不重跑全清单。清零 blocking → 进 Phase 5。
|