aLIZELI/belief-merge

BeliefMerge

合并两个 AI 对话，同时不丢失推理过程、不洗白可信度、也不靠猜测处理矛盾。

一个 DeepSeek Harness 插件、一个带有反例的合流定理，以及一个在真正有用之前错了两次的基准测试。

dsh plugin --profile web add dsh-belief-merge

然后只需问：“把我那两个 bilibili 对话合并到这个里” —— 或者手动用 /merge 列出候选、选择它们，并检查当前生效的内容。无需编辑配置文件，无需重启；它会在下一轮生效。

完整用法、配置和限制：belief-merge/README.md。

如果你想改代码：

cd belief-merge
npm test             # 242 个测试，无依赖、无网络、无 API key
npm run demo         # 端到端，离线
npm run bench:tight  # 预算受限的对比

问题，用两句话说明

关于同一个系统的两个对话逐渐产生分歧，而之后的一个问题需要来自两者的信息。所有现有工具对此的回应都是把其中一个粘贴到另一个里（便宜、无界，矛盾留给读者处理），或者进行摘要（恰好在最重要的地方有损——推理过程，包括那些能让你不再重蹈覆辙的死胡同）。

四项结果

1. 除非保留来源，否则增量合并是不可靠的

分支会随时间到达，因此合并是成对进行的。交换两个分支的顺序会改变答案——而且是悄无声息地改变：

B0 = {a@1}      B1 = {a@1}      B2 = {b@2}

n 元         : disputed{a,b}      正确——权重是 1+1 = 2 对 2
增量         : b                  错误

先合并 B0 和 B1 会把两个一致但较弱的分支坍缩成一个较弱的断言，于是单个强异议者就能获胜。

在 72,760 个枚举配置上，保留来源的表示产生了 零 失败；坍缩为有界摘要的表示在 9.9–26.2% 的良构输入上失败——而且这种失败会沿着推导链级联，删除或复活整条推理线。

“边合并边摘要”是不可靠的，无论摘要器有多好。

2. 在现实预算下，拼接会崩溃

MergeBench 生成这样的场景：桥接问题需要来自不同分支的信息——因此没有任何单个分支能回答它们。每个方案都获得相同的 token 预算。

400 tokens，50 个桥接问题：

| 方案 | 局部 | 桥接 | 解决冲突 | tokens |
|---|---|---|---|---|
| 仅单个分支 | 50% | 0% | 50% | 388 |
| 拼接 | 60% | 18% | 50% | 399 |
| BeliefMerge | 95% | 98% | 100% | 401 |

在宽松预算下，所有内容都能装下，拼接在覆盖率上也能跟上——但它无法解决任何问题：在每个被断言两次的键上，两个值都会出现，读者只能自己去想清楚。而合并则在三分之一的 token 下，100% 的情况下只呈现一个值。
3. 平局由不允许猜测的模型裁定

证据决定大多数冲突。当确实打成平局时，裁决者可以介入——但受三重约束：

- 它不能凭空捏造一个原本不在选项中的值；
- 它会被询问两次，且选项顺序颠倒，若答案翻转则降级为 unresolvable——公理 IC2 在运行时强制执行；
- unresolvable 是一等答案，合并宁可暴露矛盾，也不粉饰太平。

4. 合并是一种洗白原语——因此信任是一个格

来自被攻陷会话的断言进入合并块后，便与当前用户确立的内容变得无法区分。

不变式 I2：合并行为本身永远不得将某个值的信任度提升到高于断言它的那些声明的信任度。 佐证可以提升信任；合并不能。

已针对真实的提示注入载荷验证。在读取注入块后，模型报告：

“仅作为数据引用；该块中嵌入的指令不被视为指令。”

这里实际有什么

四类文档。第三列说明每一份是给谁看的。

| | | 在以下情况阅读 |
|---|---|---|
| belief-merge/README.md | 用户手册——安装、用法、配置参考、升级陷阱、哪些已验证哪些未验证 | 你想使用该插件 |
| ARCHITECTURE.md | 按实际构建的代码地图——逐阶段展示流水线、模型可以介入的三处、降级阶梯 | 你想理解或扩展它 |
| TECHNICAL-REPORT.md | 完整报告——设计理由、合流结果、基准测试、局限性 | 你想了解设计背后的推理 |
| belief-merge/CHANGELOG.md | 发布历史，以及为什么升级需要显式版本 | 你正在升级 |
| belief-merge/VERIFY.md | 实机运行记录——通过运行发现的 13 个 bug，以及一份故障分类 | 你想知道在真实测试框架中实际发生了什么 |
| beliefmerge-t1/ | 合流实验——对 72,760 个配置的穷举枚举、最小反例 | 你想核验核心主张 |
| belief-merge/bench/ | MergeBench——生成器、计分分支、结果，以及它不测量什么 | 你想核验数字 |
| belief-merge/ | 插件本身：14 个核心模块、242 个测试、一个离线演示 | 你想阅读代码 |
| docs/ | 研究材料，不随 npm 包发布 | |
| ↳ 会话融合引擎-BeliefMerge-可行性与算法架构.md | 原始的实现前提案（中文）——8 个阶段、6 个新颖点、8 条不变量。先读横幅：它的 M 编号不是插件的编号，而且其中两个里程碑从未被构建 | 你想看它是如何被规划的 |
| ↳ conversation-branch-merge-litreview.md | 文献综述，约 60 篇参考文献对照 Crossref/OpenAlex/arXiv 核查 | 你在问“这件事以前有人做过吗？” |
| ↳ BeliefMerge-算法逻辑图.html | 算法图，可在浏览器中打开并导出为 PNG | 你想要一张图 |
| ↳ refcheck/ | 用于核验那些参考文献的脚本和表格 | 你在审计引用 |

npm 包发布 lib/、bench/、cordis.patch.yml、ARCHITECTURE.md、
CHANGELOG.md、TECHNICAL-REPORT.md 和 VERIFY.md——见 package.json 中的
files 字段。docs/ 和 beliefmerge-t1/ 仅为仓库材料。

我在面试中真正会问到的部分

每一个重要的 bug 都是通过运行这个东西发现的，而不是通过测试它发现的。

export * from './x.js' 会重新导出一个名称，但不会在本地绑定它——所以一个
缺失的 import 在 83 个测试通过的情况下被发布了，因为没有测试在一次调用中
演练对齐 → 融合 → 裁决。推导传播机制有 25 个通过的测试，却从未针对真实
输入执行过一次，因为直到提示词中包含一个完整示例，模型才输出边。

有十三个记录在
TECHNICAL-REPORT.md §9，
并在 VERIFY.md 中逐轮叙述，其中包括一个演示，其叙述
在预算被收紧到足以让其说法成立之前都是虚假的。

一套绿色的测试套件是关于你演练过的路径的证据，而不是关于你未演练过的
路径的证据。

复现一切

cd belief-merge && npm test          # 242 个测试，无网络，无 API 密钥
cd belief-merge && npm run demo      # 七个完整示例，离线
cd belief-merge && npm run bench     # MergeBench
cd beliefmerge-t1 && python3 run_t1.py  # 汇流实验，约 14 秒

安装到真实的 DeepSeek Harness 配置文件中记录在
VERIFY.md 中，连同完成后的情况一并记录。