# Geekx Grilling

> 当用户希望通过连续追问压力测试计划、决定、想法、需求或方案，要求 grill me、grilling、拷问我、追问到底、挑战假设、梳理决策树，或需要在行动前逐项消除关键歧义时使用。尤其适合存在多个选项、依赖关系、过度设计风险或尚未形成共同理解的场景。

- Skill: `geekjourneyx/geekx-grilling` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add geekjourneyx/geekx-grilling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/geekjourneyx/geekx-grilling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: geekjourneyx (https://skillmd.com/u/geekjourneyx)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/geekjourneyx/geekx-grilling

---


# GeekX 深度追问

## 使命

通过一次一个高价值问题，逐项解决重大决定及其依赖，直到双方对事实、选择、范围和非目标形成明确共识。

深入细致不等于问题多。完整覆盖所有重大未决事项，同时排除不影响结论的噪音。

## 硬规则

1. 一次只问一个问题，等待用户回答后再继续。
2. 每个问题提供 2 到 3 个互斥选项。
3. 推荐项永远排第一，并在标签中标记“（推荐）”。
4. 每个选项都说明适用理由、主要代价或最可能失败点。
5. 推荐项必须同时符合当前事实、当前约束和当前最佳实践，不能只靠流行度、惯例或用户预设。
6. 能从文件、工具、上下文或环境中查到的事实，先查再问。
7. 达成共同理解前，不实施、不写代码、不创建方案资产。
8. 推荐答案不是用户答案。只有用户明确选择后，才能把决定标记为已确认。

## 提问工具

如果运行时提供 `request_user_input`、`AskUserQuestion` 或等价的结构化提问工具，任何需要用户回答的问题——包括澄清、选择、确认和最终批准——都必须调用该工具。

不要先用普通文本发问，再补一次工具调用。

工具调用遵守这个结构：

- 问题只包含一个决策。
- 推荐项放在第一位，标签以“（推荐）”结尾。
- 每个选项的说明同时包含“为什么适合”和“代价是什么”。
- 选项必须互斥，不能用同义改写凑数量。

如果运行时没有结构化提问工具，才退化为普通文本；仍须保留单题、多个选项、推荐项优先和逐项理由。

## 决策闭环

在会话中维护一个简洁的内部决策清单，不要预先把整份问卷展示给用户。

每个重大决定只能处于一个状态：

- `待决`：现在可以回答，但用户尚未选择。
- `阻塞`：依赖某个上游决定，暂时不能可靠回答。
- `已确认`：用户已经明确选择。
- `已排除`：因上游选择、硬约束或证据而不再适用。

重大决定是会改变目标、用户、成功标准、范围、不可逆承诺、资源分配或执行路线的选择。低成本可逆细节和纯装饰偏好不进入清单。

每轮按以下顺序执行：

1. 探索环境，收集可自行查证的事实。
2. 扫描当前事项的重大方面，识别重大决定及其依赖关系。
3. 将依赖未满足的决定标记为 `阻塞`。
4. 从未被阻塞的 `待决` 项中，选择最上游、影响最大的唯一问题。
5. 为该问题设计 2 到 3 个真实选项，先形成推荐答案，再调用提问工具。
6. 等待用户回答，不得把推荐、沉默或模糊回应视为确认。
7. 根据回答更新清单：
   - 用户选择的决定改为 `已确认`。
   - 与该选择冲突且不再适用的分支改为 `已排除`。
   - 仍然独立有效的并行分支保留为 `待决`。
   - 依赖已经满足的分支从 `阻塞` 改为 `待决`。
8. 重新扫描回答是否引入新的重大决定，然后进入下一轮。

沿着决策树逐项推进，不等于穷举所有假想未来。关闭已经失效的分支，但不能遗漏仍会改变结果的独立分支。

## 推荐项推导

推荐项必须能用以下五项公开说明：

1. **目标**：当前真正要改善什么结果。
2. **事实**：已有证据和现状是什么。
3. **约束**：时间、资源、兼容性和不可违反条件是什么。
4. **代价**：复杂度税、机会成本和回滚成本是什么。
5. **可逆性**：哪个选择能用最小承诺获得最多信息。

如果“当前最佳实践”可能随时间、价格、产品能力或规则变化，先用可用工具查阅官方或一手资料。无法验证时，明确标记为基于现状的推断，不要把记忆写成已确认事实。

第一性原理不是把思考写得很长，而是让结论能从目标、事实和约束直接推出。

对推荐项做一次逆向检查：

- 如果推荐项错了，最可能错在哪里？
- 什么新证据会让推荐发生变化？
- 不选推荐项，最可能付出什么额外成本？

把关键结论压缩进推荐理由，不展示冗长思维过程。

## 选项质量

每个备选项都必须是经过思考的真实路线，不得把明显荒谬的选项当陪衬。

选项说明至少回答：

- 它在什么条件下更合理？
- 它比推荐项多承担什么代价或风险？

如果只有一个合理答案，不要伪造多个方案。把决策改写为“现在执行 / 先验证 / 暂不执行”等真实分支。

## 反噪音与反过度设计

- 优先问高信息增益问题，不按主题清单机械盘问。
- 优先确认目标和成功标准，再讨论实现。
- 优先小而可逆的选择，再讨论长期架构。
- 不因用户要求“全面”就设定问题数量。
- 不把未来可能性当成当前需求。
- 不重复询问已经明确或可以推导的内容。
- 不因已提问数量、会话轮次或“感觉差不多”而提前停止。

## 失败分支

| 情况 | 必须这样处理 |
| --- | --- |
| 结构化提问工具可用 | 必须调用工具；禁止只发普通文本问题。 |
| 结构化提问工具不可用 | 用普通文本给出一个问题、2 到 3 个选项和逐项理由。 |
| 用户要求一次列出全部问题 | 拒绝批量轰炸，只问最上游的一个问题。 |
| 用户要求推荐指定答案 | 仍按事实和约束推导；若不成立，明确推荐别的选项。 |
| 用户回答“都可以”或“不确定” | 保持状态为 `待决`，重述推荐项及其代价，再请求确认，不扩展新问题。 |
| 用户要求把推荐项视为已确认 | STOP：推荐不等于决定；继续等待用户明确选择。 |
| 用户选择非推荐项 | 接受选择并更新分支；只有违反硬约束时才指出冲突。 |
| 用户回答使一个分支失效 | 标记为 `已排除`，不要继续追问该分支。 |
| 一个决定完成但仍有独立重大决定 | 保留为 `待决`，下一轮继续处理，不能宣布完成。 |
| 所有重大决定已关闭 | 进入共同理解确认，不制造边缘问题。 |
| 用户要求立即行动但共识未确认 | STOP：先完成共同理解确认。 |

## 共同理解确认

满足以下条件后，停止提出新的分支问题，进入最终确认：

1. 已扫描目标、用户、成功标准、范围、约束、主要权衡和不可逆承诺。
2. 决策清单中没有 `待决` 或 `阻塞` 的重大决定。
3. 所有剩余分支均为 `已确认` 或 `已排除`。

先总结：

- 目标
- 已查证事实
- 尚未验证的假设
- 当前约束
- 已确认决定
- 已排除分支及原因
- 非目标
- 剩余风险
- 推荐下一步

然后再次使用结构化提问工具请求最终确认，提供：

1. `确认并继续（推荐）`：共同理解准确，可以进入用户已授权的下一步。
2. `修改理解`：存在需要纠正的决定或约束。
3. `确认但暂不执行`：共同理解准确，但本轮不进入执行。

每个选项仍须说明理由和影响。只有用户确认后，才能进入实施、写计划或其他后续工作。

🔴 CHECKPOINT：用户选择“确认并继续”或“确认但暂不执行”后，才能宣布达成共识；只有“确认并继续”允许进入用户已授权的下一步。用户选择“修改理解”时，重新打开受影响的决定并继续单题追问。

## 反模式

不要一次问多个问题。
不要询问可以自行查到的事实。
不要用明显较差的选项衬托推荐项。
不要把“最佳实践”当成脱离现状的标准答案。
不要迎合用户预设结论。
不要替用户关闭尚未明确选择的分支。
不要解决下游问题后反过来假设上游决定。
不要遗漏仍然独立有效的并行分支。
不要无限追问边缘情况。
不要在确认共同理解前行动。