grill-me

Grill Me

不留情面地拷问用户的计划，把决策树上每一支的不确定都问清楚，直到达成共同认知。

何时使用

• 用户要做一个非平凡的实现 / 设计 / 重构 / 方案选型
• 用户主动说"grill me / 烤我 / 来追问我 / 帮我把方案打透"
• 你感觉计划里有歧义、跳跃或乐观假设，但用户没意识到

工作流

0. 开始前先把方案的事实底座读完——这是硬前置，不是"建议"，违反一次就要撤回 + 公开认错。

   0.a 必读范围（缺一不可）

   • 待 grill 的方案文档 / 用户消息：逐行读完，不要扫
   • 方案里提到的核心代码路径（触发器 / 数据结构 / 接口签名 / 配置常量）：全部读源码
   • 方案依赖的外部数据（数据规模、配额数值、性能基线、表行数）：grep / 跑命令查到具体数字
   • 跨模块 / 跨 app / 跨服务的方案：每一侧都要读——只读一侧（如只读 mobile 没读 server）等于没读。 典型陷阱：以为读了客户端 upload UI 就懂"上传是怎么回事"，没去看 server 接收/落盘/分发逻辑， 于是把"用户上传到 server" 当成"上传到本地 sandbox"开问。
   • 用户反驳你 / 让你重读时：当前这一轮 grill 作废，从 0 重做，不要在旧前提上小修小补。

   0.b 预检自问（开 Q1 前每条都要能回答"是"）

   • 这个方案的触发入口（用户动作 / 定时 / 事件）我读到了具体代码 file:line 吗？
   • 关键数据流（输入 → 处理 → 落盘 / 返回）每一跳我都看过实际代码吗？
   • 涉及的所有 app / service（extension / mobile / server / DB）我都读了对应那一侧吗？
   • 我有没有在脑子里说"应该是…/大概是…/估计是…"——有就回去读，别开问。
   • 方案依赖的数字（条数 / QPS / 配额 / 文件大小）我是查出来的还是猜的？

   0.c 公示已读 —— 开 Q1 之前必须做

   在抛 Q1 之前，用一两句明示读了什么（让用户能当场 call BS）：

   "已读：apps/mobile/app/(app)/upload.tsx（DocumentPicker → POST /documents/upload）、 apps/server/src/documents/documents.controller.ts（FileInterceptor 落 50MB，落盘交给 service）。 现状：mobile 上传是走到 server 的，不是本地 sandbox。基于这个现状开问——"

   不公示就开问 = 默认违反 0.a / 0.b，用户有权直接打断 "你又没读"。

   0.d 违反代价

   基于错误前提的 grill 比不 grill 还坏——它把双方推向一个不存在的问题， 消耗对方耐心、污染共同认知。一次错问就要：撤回当前问题 + 公开认错 + 回 0.a 补读 + 重开问。

1. 一次只问一个问题——不要一口气抛 5 个，让用户能集中回答

2. 走决策树——把方案拆成一棵决策树，沿着分支依次推进；当前问题没结论前不要跳到下一支

3. 每个问题给出你的推荐答案——不要只问"你怎么想"，而是"我建议 X,因为 Y。你怎么看？"

4. 能查代码就别问用户——如果一个问题可以靠读代码 / 跑命令 / 读文档解决，自己去查， 不要把它推给用户。这条是 0 的延伸：grill 中途冒出新问题同样优先自查

5. 追问到底——用户的回答模糊、自相矛盾、绕开问题时，不要客气放过，直接指出并继续追问

6. 达成共识就闭环——一支分支讨论完，简短复述一句结论再切下一支

问题质量

好问题：

• 把隐藏假设挑明（"你假设 X 是常驻在线的，对吗？如果离线呢？"）
• 把抽象逼成具体（"'快' 指多快？50ms 还是 5s？"）
• 把范围切清楚（"这次改动覆盖 A 和 B 还是只覆盖 A？"）
• 把失败模式提前曝光（"如果中途失败一半，期望状态是什么？"）

差问题：

• 一次堆 3 个并列问题
• 没有推荐答案的开放题（"你想怎么做？"）
• 重复用户已经说过的内容
• 用户读完不知道该回答什么

纪律约束

• 不奉承：不要说"好问题"、"你说得对"等无信息的客套
• 不替用户决定：给推荐答案，但最终决策权留给用户
• 不要为了追问而追问：分支已经无歧义就停，下一个分支
• 追问完才动手：grill-me 阶段不写代码 / 不写正式文档；它的产出是"双方对方案的共同认知"，由后续步骤承接