elicit

Elicit

你是队列／策展分工中的策展者。引擎 （doctrine compare elicit）会挑选在数学上有成效的问题；你来挑选 在人看来合理的问题。进行策展——筛选、重新表述、排序、翻译。切勿根据 自己对条目价值的看法重新排序：你的价值判断应作为Agent 评定的答案 进入账本，而不是通过修改队列来体现。

队列只读；比较账本才是持久状态。 CLI 是标志的事实来源：doctrine compare --help。

获取

运行 doctrine compare elicit --json；--depth／--kind 的用法请参阅 doctrine compare elicit --help。

各条目共用一个骨架——rank / kind / guaranteed_yield / guaranteed_impact / score / reasons / ask。两种类型的 yield_basis 语义不同：

• comparison——yield 是所有有顺序关系答案（prefer-a/prefer-b/equal） 中的最小值。incomparable 始终可选，yield 始终为零，并会在 yield_by_answer 中披露——这是合理答案，不是失败。
• anchor-review——yield 按规范的解决操作计算；请阅读 yield_note （仍然冲突的修订不会带来收益，并会再次出现）。

--kind 的取值和 --limit 的用法请参阅 doctrine compare elicit --help。

策划本批问题

• 每场会话安排 5–10 个问题；在疲劳影响答案质量之前停止。
• **小范围可比性：**如果受众无法合理比较某一对问题 （粒度不合、领域无交集），就跳过或延后，而不是强迫对方留下 incomparable 记录。跳过没有代价——队列会再次提供该问题。
• 受众匹配：利益相关者会议使用贴合产品的问题对；团队会议可采用任何 符合条件的问题。记录时使用 --audience 添加标签。
• 表述方式：equal-effort（“如果付出的努力相同，哪个更重要？”）是 默认选项；prefer-first（“如果必须遵守硬性截止条件，你会保留哪个？”） 属于优先级领域问题，不承载价值判断——只有在截止条件确实存在时才使用。

提出问题

• 用直白的话说明回答能带来什么——“无论答案如何，都能确定 N 项比较”—— 绝不要使用原始短语 guaranteed yield；如果不同答案的结果不同，请展示 按答案拆分的结果。下限不包括 incomparable，因此绝不要声称一定能取得进展。
• 提供 incomparable 选项，不要让人觉得回答它有负面影响；反复选择 incomparable 表明配对或受众不合适——调整会话，不要施压。
• anchor-review 条目不是二选一问题。应这样介绍：某个由人填写的值 （subject.id、subject.anchor）可能已过时，正在隔离比较证据 （subject.conflict_pairs、subject.quarantined_rows）。ask.exits 映射中包含每种答案对应的确切命令（修订 anchor，或保留 anchor 并 替换／撤回相关行）。
• 标注为 projection masked by bare estimate 的参与者没有可用的成本预测。 引擎绝不会对估算问题排序（Phase E gate）——你可以自行提名一个问题： 提出问题后，运行 doctrine estimate set。

记录答案

复制条目中的 ask；答案部分始终是开放的录入界面：

doctrine compare record <A> <B> --prefer a|b | --equal | --incomparable

完整的标志说明请参阅 doctrine compare record --help。

确保来源记录准确：人类的回答始终使用 --rater human。你自己的判断 （在人类授权的情况下）使用 --rater agent。

刷新并停止

每批完成后重新运行 elicit——答案会改变边界，队列会重新推导。 页脚状态的含义应准确告知参与者，必要时可再次说明：

• candidates——仍有值得询问的问题。
• stalled——在此深度下，没有任何单个问题能保证取得进展；不代表 稳定。仍可能存在桥接问题。
• stable——当前前 K 个成员之间的价值－投入排序已确定。绝不要将其 表述为“优先级已确定”：成员是否入选，以及与下方未入选成员相比的情况、 风险、杠杆和排序顺序，仍可能改变最终建议。