把“多想点子”和“给准结论”压进同一次会话，通常两边都做不好：Hyra 在发散模式下会给出大量方向，但收敛模式要求逐条核对证据、明确取舍，两者的产出节奏并不一样。更实用的做法是把一次长会话拆成两个阶段：第一阶段只让 Hyra 铺假设和线索，明确禁止它下结论；第二阶段由你自己拿原始材料逐条核对，再把核对结果写成下一轮的输入。分工没有写进开场提示之前，不建议开长会话，否则后续整理的成本会超过省下的时间。

适用场景：用 Hyra 做方案梳理、故障排查方向列举、需求分析这类“先发散再取舍”的任务。操作动作：每次会话先用一句话钉死角色——第一阶段只产出假设与待查线索，不写结论；第二阶段由人核对证据并决定去留。验证方式：看会话里是否出现了未经核对的定语，如“根本原因是”“显然是”，出现就说明分工漏了。风险边界：这套分工不减少核对工作量，只是把它从对话中移到你自己可控的表格里。

第一阶段只让它铺假设、不下结论

发散阶段的目标是产出量和角度覆盖，不是准确率。开场提示里要把“不许收敛”写成硬约束，并指定输出格式，否则模型很容易在第三四条就自己收口。下面这段骨架可以直接改用，方括号内换成你的场景：

你是[场景]的假设生成者，本轮只做发散，不做结论。
任务：围绕[问题]列出至少 12 条可能原因/可能方案。
每条格式固定为：
  假设：一句话，可被证实或证伪
  线索：需要查什么才能验证（文件、日志、配置项、指标、接口返回）
  反例：如果这条假设成立，应该看不到什么现象
规则：
  1) 不写“根本原因是”“说明”“因此”这类收口语；
  2) 不确定的地方写“待查”，不要补全；
  3) 允许重复方向，但每条线索必须不同。
输出：只给列表，不给总结段。

“先不下结论”的限定要落到可检查的层面：禁止总结段、禁止因果断言、每条必须带验证线索。你把这段提示贴进会话后，可以先发一句“确认规则后开始”，让 Hyra 复述约束，通常能显著减少它中途自行收敛的情况。

把假设按可查证据的难度排序

第二阶段开始前要先排序，否则容易挑顺手的先查，把难查但更关键的假设拖到最后。建议用三个维度定义难度：证据是否现存（日志/配置里已有 vs 需要加采集）、验证动作是否可逆（只读检查 vs 需要改动环境）、以及单次核对的耗时量级。排序不必精确，能形成先后顺序就够。

排序记录建议直接落在表格文件里，和后面的核对结果放在同一张表，避免两处维护。排序完成后就不要在核对途中临时插队，除非新证据推翻了前面的判断。

第二阶段由人逐条核对证据

这一步不建议再让 Hyra 代劳。核对需要的是原文：日志的原始行、配置文件的真实片段、接口的实际返回体、页面上看到的状态。把原文贴回来给它解释，和让它凭印象回答，是两件事。常见做法是：自己先取到原文，再让 Hyra 做“这段话支持还是反对哪条假设”的判定辅助，判定结果由你签字。

• 证据来源要带定位：文件路径与行号、命令与执行时间、页面路径与操作步骤。
• 核对结果只填三种状态：已证、已否、未证（材料不足或需要补采集）。
• “未证”不等于“已否”，两者混用会让下一轮重复劳动。
• 每条结论后面挂一条证据引用，写不出引用的先归到未证。

把核对结果写成下一轮的输入

核对完不写回结构里，下一轮又要从头发散。把结果压成三栏，作为新一轮会话的开头材料，是形成闭环成本最低的方式：

已证（附证据定位）：
  - H2 配置项 x.y 在 /etc/app/conf.yaml 第 42 行被覆盖为旧值（证据：文件原文）
未证（缺什么材料）：
  - H3 上游返回异常：缺该时段网关访问日志，需补采集后重查
已否（附反证）：
  - H1 写入失败：同时间段写入成功记录存在，与假设相悖（证据：应用日志第 N 行）

下一轮开场时，把这三栏原样贴给 Hyra，并说明“已证部分不再发散，只围绕未证部分补充假设”。这样每轮的增量都落在未证项上，而不是把已经排除的方向重新翻一遍。

判断哪些假设值得继续投入

取舍是这个流程里唯一不能外包的动作。继续投入的判断条件通常是：该假设仍有未证部分，且补齐材料的方式明确、单项成本可接受，同时它一旦成立能解释当前的主要现象。搁置的条件通常是：核心证据需要改动环境才能取得、影响面大于当前问题本身，或者它成立也解释不了主要现象，只能算旁支。

• 继续：未证项有明确取数路径，且验证动作只读或可回滚。
• 继续：该假设成立能同时解释多个已观察到的现象。
• 搁置：验证需要改动环境且无回滚方案，先记录，等条件具备再取。
• 搁置：多条假设指向同一现象但互不排斥，先处理证据最容易拿到的那条。

搁置不是删除，把搁置项和搁置理由一起留在表里，下一轮换人接手或环境变化时可以直接捡回来。整轮结束的标志不是“有结论了”，而是未证项都写清楚了缺什么材料。