拒绝后座指挥

它解决什么问题

当你把一句话需求交给一个 Agent，比如「我想做一个排行榜功能」「帮我实现用户导入」，最初的表述往往模糊、自相矛盾，或者缺失关键细节。缺少澄清就直接开工，代价是返工、推翻架构，甚至交付一个跑不通的半成品。这个技能的思路是先当副驾驶：上路之前，先把路线问清楚。核心理念是——不要在别人开车时从后座指挥，先弄清路线再上路。

它如何工作

三个核心概念

• relentless：追问的语气与强度——犀利、直面矛盾、拒绝模糊词，追问到不可追问为止
• fact-autonomy：事实性问题自己查（读文档、读代码、查环境），决策性问题才追问用户
• append-only：追问记录追加写入，已记录内容不可修改、不可覆盖，追加是唯一允许的写入方式

工作流程

1. Phase 1 初步评估：判定需求属于工程类还是非工程类，按对应审查维度清单识别不明确点并标记 ✗；能自行查证的事实问题直接记录并标记 ✓（注明来源），只把决策性问题列入追问清单
2. Phase 2 relentless 追问循环：每次只问一个决策性问题。先给出推理分析与推荐方向，再直面矛盾发问，并通过 AskUserQuestion 弹出 2–3 个结构化选项（每个选项说明代价与约束）加自由填写；用户回答后追加写入 requirement-inquiry-{topic-slug}.md。收敛条件：清单全部 ✓、无 ✗ 或 △、最近一轮回答无「大概」「尽量」这类模糊词、关键术语均有清晰定义
3. Phase 3 收敛与输出：整合出完整无歧义的需求文档，替需求提出者做犀利反思（每条指向具体表述，带 critical / warning / notice 严重度标签），基于 assets/output-template.html 填充 A 原始需求、B 分类与审查维度、C 追问过程、D 最终需求、E 犀利反思五个 section，输出 requirement-report-{topic-slug}.html

适用边界

• 触发场景：需求、想法、功能规划的表述存在模糊、矛盾或缺失；请求评审需求文档或方案；要求验证想法是否可行、完整
• 不触发：纯知识问答、已完全明确无歧义的小操作指令、闲聊
• 混合需求会拆分为子需求分别审查，最后验证子需求间的衔接与一致性；审查维度详见 references/requirement-classification.md，追问方法与收敛策略见 references/socratic-method.md