grilling

Grilling

这是什么： 一套可复用的访谈协议，不是流水线阶段。嵌套在父级流程中（例如 brainstorm 的第 2 步、establish-project、triage）时，你仍处于父级流程的对话和检查清单中——应用这些规则，不要宣布切换模式，也不要在你的事项勾选后就认为父级流程已完成，并按照下文 Todos 的要求执行父级检查清单。独立使用（用户未指定父级流程，只要求接受提问）时，你独自负责访谈，直到双方达成共同理解。

持续访谈，直到你们对情况有相同的认识：每个可能导致技术债或错误架构选择的隐含假设，都已被明确提出并作出决定。这项技能的关键词：开放集合、疆域、问题卡、结束方案。地图（提示词、计划、已知信息）不是疆域（代码库、运行时、用户、历史）——在错误猜测变得代价高昂之前，通过提问缩小两者之间的差距。

铁律——沟通渠道

EVERY QUESTION IS INLINE CHAT WITH FULL CONTEXT.
NEVER use AskUserQuestion, structured MCQ pickers, or any harness UI that
truncates labels, option text, or the "why this matters" line.

只能点按的 UI 会剥离决策后果，因此并不会更快——它只会让访谈变得不同且更糟。“团队风格偏好选择器”“五分钟后要开站会”“负责人说要用结构化 UI”以及“选项描述字段够长了”都不是例外。

铁律——开放集合（无固定轮次）

THERE IS NO FIXED ROUND COUNT.
NEVER "Question k of N", "last of 5", or "we budgeted four cards".
Stop only when the open set is empty of judgment calls that change
architecture, data, auth/security, UX flow, or implementation scope.

开放集合 = 尚未决定且影响范围广的未知事项 + 上一个回答引出的分支 + 父级已知但仍需用户确认的未知事项。

核心规则： 每次回答后都要重新计算开放集合，然后选择下一张问题卡或结束方案。其他地方提到“重新计算”，都指向此规则。

预先列出的决策领域待办清单是动态地图，不是配额：出现新分支时添加，解决后移除；只要仍有影响范围广的事项未解决，就绝不能因为原始清单已完成而结束。时间、站会、资深同事说“问几个就收尾”以及精力耗尽，只会改变你何时汇报进度，而不会改变是否存在尚未明确的决定。

起始地图（第一张问题卡之前）

如果有父级的已知信息清单、盲点列表和扫描摘要，请先加载（例如 .skills/*-knowns.md、.skills/*-scan.md）。然后在普通聊天中给出一份简短的思考伙伴地图——不是问题卡，也不是一连串问题：

1. 已锁定——你视为固定的信息（立场、明确不可妥协事项、摘要事实）。
2. 影响范围广的开放事项——你预期首先要探讨的决策分支（只列名称，暂不列选项）。
3. 如何解决未知事项——判断类问题使用问题卡；当用户只有亲眼看到结果后才能判断，或答案属于事实时，使用参考资料或 prototype/research；当盲点阻碍真实选择时，先讲解再提问。

只有地图有误时才请用户纠正（“如果有锁定事项不成立，请告诉我”）。然后提出第一张问题卡。如果已嵌套在一个已经说明这份地图的父级流程中，则跳过重述，直接提出第一张问题卡。

问题卡片（每轮）

每条消息只做一个决定。以普通聊天形式输出此结构——不要调用工具。每个栏位都必填；时间紧时省略内容属于违反通道规范。

1. 影响范围——从以下选一项：architecture · data · auth/security · UX flow · polish（标注出来）。
2. 讨论脉络——三行简短内容，让用户在看到问题前快速浏览：
   • 目前已锁定 — 1–3 项已做出的决定，它们会约束这个分岔（或写“尚无”）。
   • 本卡片 — 当前这一个分岔。
   • 之后仍待决定 — 如果当前问题得到回答，剩余的高影响名称（动态待决项集合，绝不要写“5 项中的 3 项”）。
3. 背景事实——来自代码仓库、摘要或父级已知信息的事实（路径、中间件、先前 PR、当前行为、潜在问题），足以让选项有据可依。如果盲点会妨碍选择，就在此处讲清楚（解释它是什么，以及为什么会在本产品中造成问题），然后再提出问题。如果确实没有事实，就直说；不要编造。绝不要让用户回想你能查到的内容。
4. 问题——用直白语言说明要做的决定。
5. 为何重要——说明答案不同会带来哪些变化（队列还是同步、架构、权限边界、范围、返工成本）。提供足够信息，让用户无需追问就能选择。结合本代码仓库或产品说明；不要只说“确认一下”。
6. 关闭项——本卡片将消除的未知类别：known-unknown · unknown-known · blindspot-confirm。
7. 选项（2–4 个）——简短标题加上后果说明。只有标签不算选项。
8. 建议——给出你的选择，放在第一位或明确标注，并用一句话说明理由，让用户可以用两个字表示接受或反对。
9. 停止。 等待。收到回答后：重新计算待决项集合（铁律——待决项集合），然后提出下一张卡片或结束整个方案。

不要一次提出多个问题。卡片本身就是详细内容——不是“如果需要，我可以继续”的引子。

格式示例

**architecture** · export generation locus

Thread
- Locked so far: comment API stays stable; posture = Prototype
- This card: where PDF generation runs
- Still open after: guest export auth · stroke storage · plan quota

Territory
- Export is `POST /api/reviews/:id/export`, session-auth only today.
- Gateway idle timeout is 30s; large reviews with drawings already time out
  similar heavy handlers on the request thread.
- Workers already exist for transcode (`jobs/transcode`); no export job yet.

Where should export generation run?

↳ This decides whether we need a job queue, a ready-notification path, and
  an artifacts bucket — or none of those. Large reviews will blow the 30s
  gateway if we stay on the request thread; picking wrong here rewrites the
  API shape and ops surface mid-build.

Closes: known-unknown

- **Sync in the API request** — simplest; a 400-comment export times out.
- **Background job on the existing queue** (Recommended) — reuses the
  transcode worker patterns; needs a "ready" notification.
- **Client-side only** — zero backend; caps formats and helps support less.

Recommended: background job — export size is unpredictable with drawings.

顺序与覆盖范围

• 先处理影响范围大的事项。 下一个待决项中，凡是可能改变架构、数据模型、公开 API、身份验证/安全、UX 流程或实现范围的，都优先处理——即使用户要求先从润色开始。
• 遍历每个分支。 按依赖顺序处理；先处理展开的子分支，再处理主干。停止规则 = 待决项集合为空（铁律——待决项集合）。
• 只有判断需要交由用户。 将事实放入背景；只有必须由人确定的分岔才生成问题卡片。
• 根据项目状态调整范围。 如果父级信息提供了项目状态，或 docs/agents/project.md 中有项目状态：对于 Prototype · Research · Learning，跳过数据迁移 / 向后兼容 / 弃用；对于 Released · Scaling · Maintenance，则重点处理。若未提供项目状态，遍历所有分支。项目状态与团队规模档位相互独立。
• 按团队规模档位组织方案。 如果 ## Team 中有非空成员名单或 Workflow 规模档位覆盖项，则从该部分读取规模档位并据此组织方案。Small/Multi：相关时可选询问负责人/审核人。Solo 或未提供 Team：不要假设需要多人分派。绝不要编造团队；缺少 Team 时绝不要直接失败。

实施前访谈路线图

Grilling 负责处理实施前未知事项中的访谈环节。其他环节是开放集合中的来源或交接事项，而不是额外的固定轮次：

环节	Grilling 的职责	不重新负责的事项
盲点检查	加载上级 Blindspot；高影响范围的事项 → 教学后提问卡片或明确锁定。没有上级清单且熟悉度低 → 在偏好卡片前，简要讲解相关领域的风险点。	完整扫描 / 已知事项清单（brainstorm 第 1 步）
头脑风暴 / 范围界定	如果真正的问题是涉及多个子系统的范围界定，则交回上级进行分解。	方案选项和层级（brainstorm 第 4–5 步）
访谈	丰富的卡片；先处理影响范围大的事项（见上文的时段和顺序）。	—
参考资料	最佳参考资料是源代码（文件夹、模块、以往的 PR，甚至是另一种语言的实现）。重述其语义；锁定接受 / 调整 / 拒绝。图表和截图是较弱的备选方案。	实现参考资料
未知的已知事项	不进行抽象的偏好盘问。走参考资料路径，或交给上级的 prototype / research，然后针对结果提一张卡片。	运行原型会话
计划就绪度	完成收尾包中的高调整可能性表面（数据模型、类型接口、面向用户的流程）。	编写 tasks.md（write-plan）

只要存在具体的参考资料，“做个合理的东西就行”就不算决定：找出它，重述其语义，再接受 / 调整 / 拒绝。臆造行业惯例属于事实错误。

收尾包（必需）

当开放集合中不再有待定的高影响范围判断——且在将控制权交还上级或声称双方理解一致之前——输出：

1. 决策表——行：影响范围 · 主题 · 决定（使用用户的原话）· 已解决的未知事项类别。
2. 约束块——可直接粘贴的锁定项（先架构和数据，最后润色）。标出与高影响范围锁定项冲突的低影响范围回答。
3. 高调整可能性表面——在真实实现压力下最可能变化的锁定项（数据模型、类型接口、UX 流程）。机械式重构仍埋在内部；不要在此重新访谈。
4. 明确确认——这是否是双方共同认可的方案？只有对此收尾包的肯定答复才算数。

以下不算确认：“还有其他问题吗？”，“我们意见一致，跳过表格吧”，“直接去写需求吧”，资深人员施压要求跳过流程，或保持沉默。如果用户更正某一行，编辑后重新确认。如果确认过程中出现新的高影响范围分歧，则返回卡片环节。

确认完成前，不得执行任何事项——不得编写生产代码、搭建脚手架或执行计划。（在访谈过程中某个术语确定后，允许通过 domain-modeling 被动更新术语表 / CONTEXT.md。）

待办事项

嵌套场景：不要另建竞争清单。你在上级的检查清单中运行——访谈项目在收尾包确认前始终保持进行中。开放集合的进度就是该项目的进度，不是第二条进度渠道。

独立场景：可以维护一份持续更新的决策领域开放集合清单——仍然每条消息只放一张卡片；每次回答后仍须重新计算（铁律——开放集合）。如果上级技能已在执行，绝不另开第二条渠道。

合理化借口

想法	现实
“团队风格／负责人说要用 AskUserQuestion”	渠道是铁律。内嵌卡片就是访谈；选择器会截断原因和后果。
“五分钟后就要开站会——标签简短就好”	被截断的决策比一张清晰的卡片更慢。时间压力会改变你何时汇报，而不是决策需要什么。
“选项描述字段够长了”	如果工具限制文本长度，那它就不是合适的渠道。完整上下文应放在聊天中。
“我会用 AskUserQuestion，也贴上上下文”	双渠道。一张内嵌卡片；不要用选择器。
“推荐选项 + 一句话理由就够了”	如果每个选项都没有讨论脉络、领域范围和后果，用户就无法分析，只能接受默认选项。
“Why 控制在一行，这样更利落”	无需追问就足以做决定，是最低要求。句子预算不是内容单薄的通行证。
“如果他们问起，后续再补充上下文”	卡片本身就是细节。只在后续提供上下文，就是卡片内容单薄的问题。
“待办事项里的 4 个领域都完成了——收尾吧”	待办事项是一张持续更新的地图。只有开放集合为空时才停止；预先承诺的 N 不算。
“第 3 个问题，共 5 个，然后就整理打包”	没有固定的 N。倒计时式表述是危险信号。
“用户先问了按钮颜色”	仍应先考虑影响范围。架构、数据和身份验证的分支都确定后，再处理外观细节。
“我们已经达成共识——跳过决策表吧”	共同理解要通过方案包 + 明确同意来确认。没有决策表的共识表演不算确认。
“资深人员说只要写需求就行”	用户／资深人员可以覆盖流程所有权；但他们不能让一个未明确的决策凭空成立。发出方案包；取得明确同意。
“我会假设安全的默认选项，并标记为完成”	假设不是决策。一张卡片；然后等待。
“直接选行业最佳实践就好——他们说要合理些”	先查阅该领域的参考资料；重新表述；再与用户确认并定案。
“资深人员说直接切换到 grilling，把父项搁置”	嵌套进行才是干净的切换。搁置父项并新开一份 grilling 清单，是双渠道折腾。
“grilling 下的简短决策清单不算另一份清单”	它就是第二份清单。决策领域应作为父项中进行中的访谈条目。
“宣布正在使用 grilling，让用户知道已交接”	嵌套时：不要宣布模式切换。独立进行（没有父项）时：可以提一次 grilling。

危险信号——停止并重写这一轮

• 用 AskUserQuestion 或任何会截断内容的 MCQ 工具来处理 grilling 决策
• 在一条发给用户的消息中出现多个问号（选项文本中的澄清示例除外）
• 选项只有标签，没有后果说明
• 卡片缺少讨论脉络、领域范围、重要性说明或关闭条件
• 在高影响范围事项仍未确定时，使用“第 k 个问题，共 N 个”“最后一轮”，或因为预先承诺的数量已完成而收尾
• 在架构／数据／身份验证分支仍未确定时，先从外观细节入手
• 用“还有其他问题吗？”收尾，而不是提供决策方案包
• 未取得用户对方案包的明确同意，就交还给父项或开始编写需求
• 向用户询问仓库或父项扫描摘要中已有的信息
• 已有参考资料或原型路径时，仍针对未知但已有答案的事项提出抽象的品味类问题