grill

grill — 压力式访谈

两个用途。可独立调用：它会对已加载节点中的事实施加压力，并分发得出的内容，不会凭空创建新的目的地。可供引用的方法：任何进行访谈的工具都会引用下文，而不是复制它——引用者可以调整访谈对象或使用的示例，这属于参数化，而不是另一个方法副本。

方法

任何进行访谈的工具都应通过标题引用本节（.agents/skills/grill/SKILL.md#method）。这十项要素分为两组：第 1-5 项说明如何对单个事实施加压力，第 6-10 项说明如何开展整个访谈。应用顺序如下：

1. 用具体示例提出反问

面对无法证伪的回答（“大家都喜欢”“这很成功”“团队对此很清楚”），既不接受，也不改述，而是提出反问，询问背后的事实，并举例说明什么样的回答才算合格。

不好：“能再详细说说吗？”

好：“‘他们喜欢’是按什么衡量的——他们是独立完成了任务、亲口这么说了，还是你推断出来的？合格的回答会列出数据：‘5 人中有 3 人无需求助就完成了，2 人在第 3 步退出’。”

2. 施压最多 1-2 次

针对同一事实，反问最多两轮。第三轮不会带来更多信息：它会让受访者不堪其扰，使方法从访谈变成审讯。

3. 退出途径

有两种退出方式，都不是“继续追问”：

• 第二次仍有抵触——对第二次反问的回答依然没有事实依据。既不放弃这次尝试，也不强行进行第三轮：记录这处缺口，以及由谁补上，然后继续。
• 一开始就有有力证据——如果首个回答已经包含事实（观察到的行为、测量数据），就无需反问：确认后继续。

4. 证据层级

行为 > 数据 > 主张 > 假设。面对针对同一事实的两个相互竞争的回答，层级更高的一方胜出——即使置信度相同，假设也不等同于观察到的行为。

5. 记录每一处缺口，绝不自行填补

施压后仍未弥合的缺口，不应靠推断补全，只为让文档看起来整齐。应将其记录为未解决，并注明由谁补上。默默填补缺口，和系统其他部分所禁止的那类情况相同：扫描并不完整，却被呈现为完整。

6. 按轮次提问，而非沿决策树逐项提问

访谈中的各项决策依赖关系构成一棵有序的树。每一轮都会汇总并编号所有当前已经可以回答的问题。同一轮中，如果某个问题依赖另一个尚未解决的问题，就移至下一轮。每轮结束后，重新计算哪些问题现在可以回答。

每轮格式（纯文本，无需格式化也可在终端中阅读）：

Round 1

1. Who pays for the product, the person who uses it or their manager?
   Recommended: the manager pays, the analyst uses it.

2. Does the first version include a free tier?
   Recommended: no, a free tier is not part of the first version.

回答者说“yes”即可接受所有建议，或者按编号修改其中一些。问题编号、问题和建议必须各占一行。

不好：一条很长的消息里有 6 个问题，其中 3 个取决于第一个问题的答案。

好：第 1 轮询问买家是谁，以及他们目前使用什么。得到这两个问题的答案后，第 2 轮再询问定价，因为定价取决于前两项。

7. “yes”即可接受的建议答案

每个问题都附带 Agent 建议的答案，并以让回答者说“yes”即可接受的方式措辞。同意建议绝不需要回答“no”。

不好：“建议：不要只面向一个细分市场？”

好：“建议：首个版本只面向一个细分市场，即中型公司的财务团队。”

8. 查询事实，询问决策

环境能够回答的事实（文件、早期研究、主体仓库或其他工具），由 Agent 查询，绝不向提问者询问。如果发现的内容与提问者所说的相矛盾，就向对方指出。成分 1 中的追问只针对提问者独有的事实。决策始终由提问者做出。

如果环境提供了可以执行搜索的辅助工具，就将搜索交给其中一个，同时继续询问不依赖该事实的问题。如果没有，就在需要该事实的那轮开始前完成搜索。

不佳：“研究里说你采访了多少位客户？”（研究文件里有答案）

良好：“研究文件显示有 8 次访谈，其中 5 次的对象是财务负责人。你提到‘十来次交流’：多出的 4 次不在那个文件里吗？”

9. 随着术语逐渐明确，对词汇表提出质疑并及时记录

在第一轮开始前，如果词汇表存在，就先阅读。如果提问者使用的词与词汇表冲突，应立即打断对方，并指出与之冲突的定义。对于含糊不清或有多种含义的词，应提出一个精准术语，并给出一个用于检验该术语的边界案例，以消除歧义。

提问者在某一轮中接受术语的准确表述后，立即记录该术语，绝不要等到最后。词汇表存放在已加载产品节点的 context/glossary.md 中；如果没有产品节点，则存放在当前文件夹的 product-context/glossary.md 中。双方首次就某个术语达成一致时，创建该文件。每个词条都包含术语、一两句定义，以及应避免使用的词语。词汇表不包含任何实现细节：它不是规范说明。

**Account** — The company that signs the contract and pays for the seats. _Avoid_: client, customer.

不佳：提问者说“客户”，词汇表将其定义为最终用户；访谈仍继续进行。

良好：“词汇表将 Customer 定义为最终用户，而你刚才用它指代付费的公司。建议术语：Account，即签约的公司。边界案例：自己付费的自由职业者算 Account 吗？建议答案：算。”

10. 所有未决问题都已解决且提问者确认后，访谈才结束

当没有任何尚未回答、且可以回答的问题，并且提问者确认双方理解一致时，访谈才结束。在得到确认之前，只能记录词汇表术语（成分 9）、待解决问题（成分 5）和决策；不得产出任何交付物，也不得执行任何已达成一致的事项。

不佳：最后一个问题得到回答后，Agent 就开始编写交付物。

良好：“没有尚未解决且可以回答的问题了。已记录两个待解决问题。我们是否理解一致：这是面向财务负责人的团队版产品，销售对象是经理？确认后即可结束。”

可调用界面

它会独立运行，处理已加载的节点。它会用上述方法审视事实，并将产出分发到已有的规范文件中——不会新建任何文件：

产出	存放位置
一项决策	工作区 decisions/ 中的独立文件；由会话结束流程写入，若已加载节点是产品、课程、频道或账户，则使用该节点的 about:
一个缺口	已加载项目的待办列表——或者，若已加载节点是产品、课程、频道或账户，则记录到该节点的常设项目待办列表（capture --about）中；将其记为待处理，并在文本中注明由谁来解决——沿用会话结束流程已有的自由文本原文行格式
一个已获操作者认可的术语	产品术语表（context/glossary.md），写入位置和格式遵循要素 9
一个缺口，若已加载的产品节点声明了自己的未决问题层	写入该层（节点的 context/open-questions.md），而不是待办列表

决策和缺口的存放位置在使用此工具前就已存在；术语表则在首个术语达成一致时创建。如果审视某项事实会导致写入本表以外的位置，grill 不会擅自创建：它会说明情况并停止——应由操作者而非会话添加该行。

关键决策

每项决策都会被记录。关键决策是指在记录时也被标记为关键的决策，这样接手工作的人会先读到它，而不必等搜索结果找到它。只有同时满足以下三个条件，决策才算关键；满足其中两个不算：

1. 难以撤销：撤销需要付出实实在在的工作、金钱或信任成本。
2. 脱离上下文会令人意外：不了解这段对话的人不会猜到它。
3. 源于真实的权衡：曾有一个真实的备选方案摆在面前，但最终被舍弃。

关键：“公司首先面向 B2B 销售”——撤销它意味着重写定价和宣传内容（满足 1）；新来的人会以为面向 B2C（满足 2）；而 B2C 方案曾经过权衡并被放弃（满足 3）。

非关键：“每周报告在周一发出”——改起来很容易（不满足 1），没人会对此感到意外（不满足 2），也没有权衡过其他方案（不满足 3）。

标记由 Agent 提议，并由操作者确认。 将决策标记为关键之前，应向操作者并列展示该决策与三个条件，说明哪些条件成立、哪些不成立，并且只有在操作者同意后才进行标记。若决策不满足其中一个条件，就不要提议将其标记为关键：说明不满足哪项条件，并保持未标记状态。