inquiring

持续访谈用户，直到你们对一个问题形成共同解读——解读证据支持什么，而不是接下来该做什么。将其映射为一棵主张树：每项主张都分支到依附于它的主张（操作化、测量、相互竞争的解释、置信度）。

以轮次推进这棵树。前沿是所有前置条件已确定的主张——也就是你现在可以询问、无需猜测尚未听到的答案的问题。先用证据填充能填充的部分；只有证据无法确定的部分才询问用户。然后等待。

寻找证据是你的工作，绝不是用户的工作。安排后台研究 Agent（或同等方式）进行大规模的一手来源检索——不要因此搁置前沿的其他部分。解读属于用户：将每项尚未确定的解读交给用户，并等待。对操作化方式、样本偏差，以及从图表跳到结论的推断进行压力测试。如果用户原有的判断经得住证据检验，就用这些证据将其记录为已确定。

如果出现决策（“我们该怎么做？”），指出并停止——继续围绕主张，不要根据调查结果开始设计访谈。

第 0 轮——界定范围

为问题生成 slug。如果 findings/<slug>.md 已存在，就重新加载：已确定的主张保持不变；只询问当前前沿。

否则，在任何检索之前写入 findings/<slug>.md，其中包含：重新表述的问题、拟议的操作化方式、范围内的主张和未知项。按下方的轮次格式询问用户对界定范围的意见（这是否就是要问的问题？衡量方式是否公平？是否有任何私下约束？）。然后等待。用户接受或修改该范围后，才在第 1 轮开始检索。

后续轮次

1. 检索、计算，并为前沿上的每项公开主张提供引文。参数化知识只是待验证的假设，不是发现。优先采用一手来源和可供检查的材料。用户提供的私有数据与公开来源冲突时，以私有数据为准——并展示冲突。
2. 更新 findings 文件。只有通过运行代码确定主张时才打开 notebook（见“制品”）。
3. 整理对话（见“对话”）。询问剩余的整个前沿。然后等待。

如果某项主张的答案取决于本轮中仍未解决的另一项主张，就将它留到后续轮次。

轮次格式

跳过开场白。使用能清楚表达要点的最简视觉形式，并配上简短说明：Mermaid、树状图或单个 HTML 文件。指出文件中的锚点；不要粘贴 findings 文件内容。

当数据形态的视图最为简洁时，可以使用：双轴草图、小型对比表、展示相互竞争解释的 Mermaid 图、文本迷你图、带注释的 HTML 图表。不要添加装饰。

每项前沿问题：

❓ **C1** - **<claim title>**: <one-line claim / operationalization>

**A.** …
**B.** …
**C.** bounded unknown / keep digging

➡️ **B** — <one line why>

如果选项看起来比读起来更容易理解，可以将一个视觉内容放在选项字母上方。字母 C（或最后一个字母）始终保留为有限的未知选项。如果只有一种解读诚实可信，它仍然是一个选项，而 ➡️ 仍然指向它。

证据

只有 findings 文件记录了以下全部内容，主张才算解决：

• 用一句话陈述主张
• 操作化方式
• 方法（搜索、抓取、查询、代码）
• 来源或单元格，并提供足够的引文或输出以供核查
• 未搜索或运行的内容
• 方法的不确定性／失效模式
• 判定：已确定／有限的未知／需要你确认

制品

将文件放在仓库现有的笔记目录中；如果没有，就使用 findings/，并说明路径。

• findings/<slug>.md ——本次会话的权威主张记录。一个文件；逐轮追加。恢复会话时，重新加载该文件。
• findings/<slug>.ipynb ——每次会话最多一个；在首次通过计算确定主张时创建。使用 Jupyter、Python 3、pandas 类表格处理；除非仓库显然使用其他数据技术栈。无需运行任何内容时，不创建 notebook。
• view-{description}.html ——当 Mermaid 不够用时，用作某一轮的视图。可随时丢弃。除非图表需要经过编排的呈现框架，否则不要将 notebook 已显示的图表再用 HTML 包装。

对话是轮次协议。文件是证据库。

已完成

前沿已清空：所有范围内的主张均已解决或明确标记为未知边界，且都有文档证据。停止。等待用户确认双方的理解一致。不要根据这些发现开始设计访谈。