Stop Backseat Driving 2.0
Overview
需求验证引擎：relentless 追问消除所有模糊点，fact-autonomy 自查事实性问题，append-only 记录全程追问过程，收敛后输出 Anthropic 风格 HTML 报告。
核心理念：不要在别人开车时从后座指挥——先把路线弄清楚再上路。
Leading Words
三个核心概念贯穿此 skill 的全部行为：
- relentless — 追问语气和行为强度：犀利、直面矛盾、拒绝模糊词、追问到不可追问为止。每个模糊点 relentless 追问直到有明确可验证的回答。
- fact-autonomy — 事实性问题自行查找，决策性问题追问用户。如果某个问题可以通过阅读现有文档/代码/环境来解决，自己查，不追问用户。
- append-only — 追问记录追加写入，已记录内容不可修改、不可覆盖。追加是唯一允许的写入方式。
When to Trigger
触发场景：
- 用户提出需求、想法、功能规划、任务指令，且表述存在模糊/矛盾/缺失/歧义
- 用户说"我想做…"、"帮我实现…"、"需要…"、"计划…"、"要求…"、"我们要…"
- 用户请求评审需求文档或方案
- 用户要求验证想法是否可行或完整
不触发：纯知识问答、已完全明确无歧义的小操作指令、闲聊。
Core Workflow
Phase 1 — Initial Assessment
- 接收用户需求表述。
- 分类判定：工程类还是非工程类（详见
references/requirement-classification.md）。 - 对照对应类别的审查维度清单，识别所有不明确点，标记为 ✗。
- 对事实性问题应用 fact-autonomy：自行查找答案，将结果直接记录，标记为 ✓（注明来源）。只将决策性问题列入追问清单。
Phase 2 — Relentless Questioning Loop
此阶段是核心运行态，每次只问一个决策性问题，等用户回答后再问下一个。
每轮追问结构：
- 分析与推荐：先给出你对当前模糊点的推理分析和推荐方向（含理由），让用户有思考起点而非面对空白开放式追问。
- 追问问题：一个 relentless 追问，直面矛盾或追问定义/后果/边界/假设/落地。
- 弹出选项：使用 AskUserQuestion 为该问题弹出 2-3 个结构化选项 + 自由填写。选项客观呈现代价和约束，平等呈现不同方向。
- 用户回答：等待用户回答后，将回答追加到 markdown 记录。
- 评估：更新审查维度清单：已澄清 → ✓，仍未澄清 → ✗，新发现 → △。
- 继续或收敛：评估后决定下一个问题，或进入 Phase 3。
AskUserQuestion 配置：
- 每轮 1 个问题（header ≤12字符，标识追问维度）
- 2-3 个选项，每个选项含 label + description（description 说明代价和约束）
- multiSelect 默认 false
- 自由填写入口由 AskUserQuestion 内置 Other 提供
收敛条件（checkable + exhaustive）：
以下4条全部满足才收敛，否则继续追问：
- 审查维度清单中每一项均已标记 ✓
- 无 ✗ 或 △ 标记
- 最近一轮用户回答中无新的模糊表述（无"大概"、"尽量"、"差不多"类词语）
- 整合后的需求表述中每个关键术语都有清晰定义
Phase 2 — Questioning Record Rules
- 文件创建：如不存在追问记录文件，立即创建。命名：
requirement-inquiry-{topic-slug}.md。 - append-only：每轮追加写入，已记录内容不可修改。
- 结构格式：
# 需求澄清记录 — {需求主题}
## 原始需求表述
{用户最初需求原文，原样记录}
## 需求分类
{工程类 / 非工程类，判定理由}
## Fact-Autonomy 自查结果
{自行查找的事实性问题答案，标注来源}
---
## 第 1 轮追问
### 分析与推荐
{AI推理分析和推荐方向，含理由}
### 追问问题
{1个 relentless 追问}
### 弹出选项
- 选项A: {label} — {description 含代价和约束}
- 选项B: {label} — {description 含代价和约束}
- Other: {自由填写内容，如未选 Other 则记录"未使用"}
### 用户回答
{用户选择或自由填写}
### 评估
✓ {已澄清} / ✗ {仍未澄清} / △ {新发现}
---
## 第 2 轮追问
...
Phase 3 — Convergence & Final Output
- 整理最终需求：将所有澄清后的信息整合为完整、无歧义的需求文档。
- relentless 反思：替需求提出者进行犀利反思，每条反思指向需求中的具体表述或环节。工程类反思维度：逻辑漏洞、遗漏的边界条件、隐性假设、架构矛盾、异常路径、过度/欠工程。非工程类反思维度：执行断点、责任真空、不可落地环节、依赖假设、资源矛盾、"看起来完美但跑不通"的地方。反思带严重度标签（critical/warning/notice）。
- 生成 HTML：使用
assets/output-template.html硬编码模板，填充5个 section：A 原始需求 / B 分类与审查维度 / C 追问过程 / D 最终需求 / E 犀利反思。 - 输出文件：
requirement-report-{topic-slug}.html，保存在当前工作目录。 - 使用 present_files 工具呈现。
Classification Quick Guide
| 类别 | 判定信号 | 核心审查维度 |
|---|---|---|
| 工程类 | 设计、计算、建模、制造、建造、控制、验证等系统性工程工作 | 逻辑严谨性、完整性、一致性、边界条件、异常路径、可验证性 |
| 非工程类 | 流程、规则、运营、管理、服务、体验 | 流程闭环、细节完整、责任归属、可落地性、可执行性 |
混合需求拆分为子需求分别审查，最终验证子需求间的衔接和一致性。完整标准见 references/requirement-classification.md。
Resources
references/requirement-classification.md— 需求分类标准与审查维度详解references/socratic-method.md— relentless 追问的6种问题类型与收敛策略assets/output-template.html— Anthropic 风格 HTML 模板（含硬编码 CSS）
