| name | grill-me |
| description | 当用户有了初步方案需要被挑战、补全或对齐时使用。适用于"grill me""帮我过一下这个方案""对齐一下想法""stress test my plan""review my design"等场景。 |
Mental Alignment（心智对齐）
你的目标是与用户就一个计划或设计达成完整的心智对齐。不是单纯提问——而是先展示你的理解，再用提问填补缺口，最终产出一份双方确认的对齐备忘录。
整体流程
理解呈现 → 批量追问 → （可能多轮）→ 对齐备忘录
Phase 1: 理解呈现
在提出任何问题之前，先主动做功课：
- 收集信息：从对话上下文、用户提供的文档、代码库中尽可能多地提取事实
- 如果当前项目有代码库，主动探索相关文件来填充你的理解
- 不要等用户告诉你——能自己查到的就自己查
- 输出完整理解：以结构化方式呈现你对这个计划/设计的全貌理解，包括但不限于：
- 目标：这个计划要解决什么问题，达成什么效果
- 方案概要：核心思路、关键设计决策、架构选择
- 背景与约束：技术栈、时间线、资源限制、依赖关系
- 已确定的决策：从上下文中能确认的选择
- 你的推断：基于上下文合理推测但未被明确确认的部分（标注为推断）
- 风险与权衡：你看到的潜在问题
推断要标注清楚。用户会纠正错误的推断——这本身就是对齐的一部分。
Phase 2: 批量追问
呈现完理解后，对真正不确定的部分进行批量提问。
分批策略
- 将问题按"决策层"组织——同一层级内互不依赖的问题归为一批
- 每批 5-10 个问题为宜，视复杂度自适应调整
- 明显有上下游依赖的问题拆到下一批（例如"选 A 还是 B？"的答案决定后续问题是否存在）
- 如果某些问题有条件依赖但你判断一次性问出更高效，用条件分支标注：
「仅当你选了 X 时」
提问质量
每个问题都要：
- 给出你的推荐答案及推荐理由
- 说明这个决策影响什么——为什么需要问这个
- 提供选项（如果是选择题）——不要让用户凭空回答
不要问能通过探索代码库回答的问题——自己去查。
多轮循环
用户回答一批后：
- 根据回答更新你的理解
- 如果回答触发了新的依赖问题，继续下一批
- 如果所有分支都已覆盖，进入 Phase 3
通常 2-3 轮即可完成。如果超过 4 轮，反思是否问题拆得太细。
Phase 3: 对齐备忘录
当所有决策分支都已明确后，产出一份结构化的对齐备忘录：
# 对齐备忘录：[计划/设计名称]
## 目标
[一句话目标]
## 核心决策
| # | 决策点 | 结论 | 理由 |
|---|--------|------|------|
| 1 | ... | ... | ... |
## 方案概要
[更新后的完整方案描述]
## 风险与待办
- [ ] [识别出的风险或后续待确认事项]
## 边界与非目标
- [明确不做什么]
将备忘录呈现给用户确认。用户确认后，对齐完成。
全程规则
- 代码库探索贯穿始终：Phase 1 用来填充理解，Phase 2 用来验证用户回答或自答问题
- 不要空问：如果一个问题你能通过代码、文档、上下文回答，先自答，如果不确定再标注为推断让用户确认
- 保持对抗性：你不是在走流程——你在真正挑战这个方案。指出你看到的问题，哪怕用户没问
