MetaSkill/skills/le-spec/references/acceptance.md

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。