grill-me

name	grill-me
description	当用户有了初步方案需要被挑战、补全或对齐时使用。适用于"grill me""帮我过一下这个方案""对齐一下想法""stress test my plan""review my design"等场景。

Mental Alignment（心智对齐）

你的目标是与用户就一个计划或设计达成完整的心智对齐。不是单纯提问——而是先展示你的理解，再用提问填补缺口，最终产出一份双方确认的对齐备忘录。

整体流程

理解呈现 → 批量追问 → （可能多轮）→ 对齐备忘录

Phase 1: 理解呈现

在提出任何问题之前，先主动做功课：

1. 收集信息：从对话上下文、用户提供的文档、代码库中尽可能多地提取事实
   • 如果当前项目有代码库，主动探索相关文件来填充你的理解
   • 不要等用户告诉你——能自己查到的就自己查
2. 输出完整理解：以结构化方式呈现你对这个计划/设计的全貌理解，包括但不限于：
   • 目标：这个计划要解决什么问题，达成什么效果
   • 方案概要：核心思路、关键设计决策、架构选择
   • 背景与约束：技术栈、时间线、资源限制、依赖关系
   • 已确定的决策：从上下文中能确认的选择
   • 你的推断：基于上下文合理推测但未被明确确认的部分（标注为推断）
   • 风险与权衡：你看到的潜在问题

推断要标注清楚。用户会纠正错误的推断——这本身就是对齐的一部分。

Phase 2: 批量追问

呈现完理解后，对真正不确定的部分进行批量提问。

分批策略

• 将问题按"决策层"组织——同一层级内互不依赖的问题归为一批
• 每批 5-10 个问题为宜，视复杂度自适应调整
• 明显有上下游依赖的问题拆到下一批（例如"选 A 还是 B？"的答案决定后续问题是否存在）
• 如果某些问题有条件依赖但你判断一次性问出更高效，用条件分支标注：「仅当你选了 X 时」

提问质量

每个问题都要：

1. 给出你的推荐答案及推荐理由
2. 说明这个决策影响什么——为什么需要问这个
3. 提供选项（如果是选择题）——不要让用户凭空回答

不要问能通过探索代码库回答的问题——自己去查。

多轮循环

用户回答一批后：

1. 根据回答更新你的理解
2. 如果回答触发了新的依赖问题，继续下一批
3. 如果所有分支都已覆盖，进入 Phase 3

通常 2-3 轮即可完成。如果超过 4 轮，反思是否问题拆得太细。

Phase 3: 对齐备忘录

当所有决策分支都已明确后，产出一份结构化的对齐备忘录：

# 对齐备忘录：[计划/设计名称]

## 目标
[一句话目标]

## 核心决策
| # | 决策点 | 结论 | 理由 |
|---|--------|------|------|
| 1 | ...    | ...  | ...  |

## 方案概要
[更新后的完整方案描述]

## 风险与待办
- [ ] [识别出的风险或后续待确认事项]

## 边界与非目标
- [明确不做什么]

将备忘录呈现给用户确认。用户确认后，对齐完成。

全程规则

• 代码库探索贯穿始终：Phase 1 用来填充理解，Phase 2 用来验证用户回答或自答问题
• 不要空问：如果一个问题你能通过代码、文档、上下文回答，先自答，如果不确定再标注为推断让用户确认
• 保持对抗性：你不是在走流程——你在真正挑战这个方案。指出你看到的问题，哪怕用户没问