# 第三轮投喂操作件：请 GPT 复核《合并总纲》

> **与上一轮的区别**：第二轮是「评审 → 交付」（让它设计方案）；第三轮是「**复核调和结果**」。
> 定位差异很关键：**不要让它重述自己的方案，要让它审「别人把你的方案与另一份方案合并得对不对」**。
> 本文件是操作件（我怎么发、怎么验），**不要**发给对方。

---

## 1. 为什么要有这一轮

我方把三份输入调和成了一份《合并总纲》：

| 输入 | 来源 |
|---|---|
| ① GPT 的 7 Phase 方案 | `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md` |
| ② WB-GRAPH 白板方案（386 行） | `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md` |
| ③ 用户裁定的 8 条 + 三处前提推翻 | `docs/internal/DECISIONS-20260914-SESSION.md` |

**调和过程中 GPT 完全不知情**（我投喂时**漏给了 WB-GRAPH 方案**——这是我的操作失误，已在总纲与裁决记录中留痕）。

**所以这一轮要它做的事，恰好是它最有发言权、而我最容易做错的**：**审「调和是否正确」**。

如果直接把未调和的两份方案丢回去让它审，它会花大半篇幅说「你这跟我的 Phase 4 不一样」——**那是已知信息，浪费它的算力**。它真正能发现的是**它自己没想到的整合问题**。

---

## 2. 发什么

| | 内容 | 理由 |
|---|---|---|
| **必发** | `docs/internal/MASTER-PLAN-3.0.md`（**主输入**） | 这是要它审的东西 |
| **必发** | `docs/internal/MERGE-CONFLICT-SCAN-20260914.md` | 4 冲突 / 5 重叠 / 4 互补 / 3 悬空的判定明细；它要审的正是这些判定对不对 |
| **必发** | `docs/internal/DECISIONS-20260914-SESSION.md` | 用户的 8 条裁决 + **三处前提推翻**（尤其"白板 = 共享图"与"上千用户"） |
| **必发** | `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md` | 它自己上一轮的交付（对照用） |
| **按需** | `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md`（386 行） | **上一轮漏给的那份**，这次必须给——它是冲突的另一方 |
| **按需** | `docs/internal/reviews/CLAIM-VERIFICATION-20260914.md` | 12 条主张核实（12/12 成立） |
| **按需** | `docs/internal/WB-GRAPH-DECISIONS-20260914.md` | 白板线的 15 个拍板点 |
| **不发** | 本文件（ROUND3 操作件） | 含验收口径，会让它顺着写 |

---

## 3. 投喂提示词（路径版，可直接复制）

```text
你上一轮交付了《dsh-auto-memory · RAG + Karpathy 实施方案与架构说明（v1）》（7 个 Phase）。

在此之后发生了几件事，现在需要你**复核一份合并后的总纲**：
1. 我方把**另一份你从未见过的方案**（白板整合方案 WB-GRAPH）与你的方案做了调和；
2. 用户对我方案里的 7 个待裁决项做了决策，并**推翻了你的三处前提**；
3. 我方先做了一遍"矛盾扫描"（列出了冲突/重叠/互补/悬空），再据此写了《合并总纲》。

【只读纪律】D:\dsh-auto-memory 只是读取对象：不修改/创建/删除任何文件，不执行 git 写操作，
不运行会改动状态的脚本。可以读文件、grep 代码。

【先读这些，按此顺序】
1. D:\dsh-auto-memory\docs\internal\MASTER-PLAN-3.0.md
   ← 【主输入】要你复核的《合并总纲》。
2. D:\dsh-auto-memory\docs\internal\MERGE-CONFLICT-SCAN-20260914.md
   ← 我方做的矛盾扫描：4 条真冲突 / 5 条重叠 / 4 条互补 / 3 条两者都悬空。
     你要审的核心就是**这些判定对不对、调和得对不对**。
3. D:\dsh-auto-memory\docs\internal\DECISIONS-20260914-SESSION.md
   ← 用户的 8 条裁决 + **三处前提被推翻**（重要：你的方案建立在旧前提上）：
     · 白板不是"单会话快照"，而是**工作区级共享图**（同一工作区的接续对话共用一张图）；
     · 最痛的病在"注入表达"（规矩不遵守），不在"检索算法"——你 7 个 Phase 全在修算法；
     · 这个插件**已有上千真实用户**（npm 近一年下载 10,900），不是你假设的自用工具。
4. D:\dsh-auto-memory\docs\internal\reviews\PLAN-gpt6astra-round2-20260914.md
   ← 你自己上一轮的交付（对照用，不必复述）。
5. 你上一轮**没看到过**的另一份方案（这次必须读，它是冲突的另一方）：
   D:\dsh-auto-memory\docs\internal\WB-GRAPH-INTEGRATION-PLAN.md
   （386 行；配套拍板点 D:\dsh-auto-memory\docs\internal\WB-GRAPH-DECISIONS-20260914.md）
6. 按需：D:\dsh-auto-memory\docs\internal\reviews\CLAIM-VERIFICATION-20260914.md
   （12 条主张逐条核实，**结论是 12/12 成立**，不必重新论证）

【本次任务的定位】不是重述你的方案，也不是再评一遍。是**复核我方的调和结果**。
判断标准：**如果按这份总纲开工，会不会做出错的东西**。

【范围边界（重要，省你篇幅）】
- 本总纲把工程分成两条线：**3.0 主体**（7 个 Phase，改检索与注入链）与**白板线**（独立立项）。
- **白板线自己有 386 行方案与 15 个待拍板点**（`WB-GRAPH-DECISIONS-20260914.md` 的 A1–A8 / B1–B7），
  我方已决定**单独处理这 15 个点**。**本轮你不必设计白板线，也不必替它拍板。**
  只有当"白板线的存在"影响到你审的 6 个问题时，才需要提及它。
- 用户已确认：白板的 15 个待定点要与 3.0 的决策**一起定**（因为 B1＝写入门、B5＝miv 语义、
  B4＝用户区、A8＝锚点，与 Phase 0/1 是同一批决策），但**实装分两条线**（白板线会改工具数
  14→16 并触发三处测试硬锁，与 3.0 共用回归基线会互相污染）。

【必须回答的七个问题，逐个成节】

Q1. **Phase 4 拆分的边界对不对？**
    我方把你的 Phase 4 拆成两半：
    · 「写入门的前后比对」+「状态过滤」→ **留在 3.0 的 Phase 0**（理由：属注入边界）；
    · 「锚点」「人机分区」「lint」「archiveAnswerPre」→ **整体移交独立的白板线**。
    这个切分切错了吗？有没有**该留的移交了**、或**该移交的留了**？

Q2. **"白板 = 工作区级共享图"这个前提变了之后，你的 Phase 0/1 哪些设计要跟着改？**
    你的设计建立在"单会话快照"上。现在同一工作区的多个接续会话共用一张图。
    我方用「乐观并发（expectedDigest）+ 冲突可见」处理并发（不加锁，理由是用户的接续体系下
    同一时刻通常只有一个活跃写者）。这个处理够不够？你的 Phase 1 里哪些字段/断言需要跟着改？

Q3. **新增的 Phase 6（注入表达与约束分层）与你的注入预算设计冲突吗？**
    背景：用户说"注入开场白把规矩降格成参考，模型注意力没在这上面"，且现行
    `snapshotMinGapRounds=5` 使**规矩在第 2–5 轮不在场**（`lib/index.js:326`、`:7455`）。
    我方新增 Phase 6：**规则类（用户级 + 工作区级两层）每轮注入、不参与任何预算裁剪**；
    参考类才受你的 `injectBudgetChars` 约束（实测本机为 4800，不是你假设的 2000）。

    **Q3 拆成三问，请分别回答：**

    Q3a. **冲突判定**：这与你在 Phase 0 设计的「唯一动态预算组装器 + FinalEnvelope 单一记账口径」
         冲突吗？如果规则类绕过裁剪，你的"预算硬上限"断言（T0-3）还成立吗？该怎么改？

    Q3b. **你来定钱袋子怎么分**（用户明确把这一条交给你裁决，我方只审）：
         候选有三——
           (i) **一个钱袋子 + 给规则预留一块额度**：总量仍是单一硬上限（你的记账口径保住），
               规则先划走一块不可裁的预留；
           (ii) **两个钱袋子**：规则一个额度、参考一个额度，两者相加即总量；
           (iii) **一个钱袋子，规则只是"最后才裁"**：实现最简，但极端情况下规则仍会被裁。
         **用户给你的两条约束（必须满足）**：
           · 若选 (i)，**"预留多少"这个数字必须有确定方式**（按比例？按绝对值？按规则条数算？），
             不能拍脑袋 —— 用户原话「我在考虑这个数字合不合适的问题」；
           · **反对为了优雅而增加实现复杂度** —— 用户原话「我怕工程因为太复杂容易出很多 bug，
             改半天成本太高」。本插件已有上千真实用户，bug 成本被放大。
         请给出：**你选哪个 + 为什么 + 落点（`文件:函数名`）+ 能失败的验收断言 + 回滚动作**。

    Q3c. **节奏部分的成本**：我方核实 `snapshotMinGapRounds` 已是现有配置项（默认 5），
         注入间隔逻辑也已实现 ⇒ "规则每轮在场"的**节奏部分只需改默认值**，不是新机制。
         请确认这个判断，并指出：改默认值后，你原方案里**哪条断言会因此失效或需要新增**。

Q4. **H2（精排）被实测数据推翻，Phase 3/5 的哪些断言要改？**
    实测（用户自己跑的，`D:\dsh-auto-memory\artifacts\m7-rerank-pre\results.json`）：
      · bge-reranker-v2-m3：recall@1 = 0.898，**P95 = 37.4 秒**
      · qwen3-reranker-0.6b：recall@1 = 0.800，**P95 = 8.8 秒**
      · 不精排基线：recall@1 = 0.739
    你方案里写的是「额外等待 ≤750 毫秒」——**这个数字在本机不存在**。
    用户裁定改为**多级选项**（关 / 快档 int8+CPU / 发烧档完整模型 + RTX 4070 Ti SUPER），
    并新增 **1 分钟异步窗口**（本轮用现有排序，精排结果留给下一次注入）。
    另外：cross-encoder 模型**已经下载好了**（bge-reranker-v2-m3 2.1GB、qwen3-reranker-0.6b 1.1GB，
    各带 tokenizer）⇒ 你的 U5「阻塞」判定作废；真实缺口是 **GPU 版 torch**（当前 `torch 2.13.0+cpu`）。
    请给出：Phase 4/5 里哪些断言必须改、改成什么。

Q5. **引擎隔离（T2-9）与切档进度条，在你的 engineIdentity 两级引用上该怎么落？**
    实测：C2 = `Xenova/multilingual-e5-small` q8（端侧）；C3 = `Xenova/bge-m3` int8（Python sidecar）。
    **两个不同模型，向量空间不通用**。代码里已有 `PROVIDER_ID_INT8` 但**没做成硬约束**。
    用户要求：切换时**强制全量重建 + 进度条**，且进度条**必须并进现有引导体系**
    （Python BGE 下载 / venv 建环境已有可视化指导），**不得另起一套**。
    请确认 T2-9 该怎么写，以及它与你的 `engineIdentity` 设计是否自洽。

Q6. **白板线工具数 14→16 会不会污染 3.0 的回归基线？**
    你的方案主张"3.0 工具数不变"；WB-GRAPH 的白板线会新增两个工具（`memory_expand_pre` /
    `memory_trace_pre`），并触发**三处测试硬锁**（`tests/smoke/smoke-test.mjs:67`、
    `smoke-test-m3b3-pre.mjs:43`、`smoke-test-context-observer.mjs:107` 都断言 `!== 14`）。
    我方处置是：**白板线独立立项、独立回归窗口**，不混进 3.0 主体。
    这样对不对？有没有更好的处置？

【此外必须回答的一个兜底问题】
Q7. **我方的调和有没有漏掉你原方案里必须保留的内容？**
    调和对方案做了大量移动与裁剪。请逐项检查你的 7 个 Phase、50 条断言（T0-1…T6-7）、
    U1–U7，指出**任何被误删、误并、误降级的内容**。这是防止我方调和造成信息损失的兜底问法，
    请具体到编号。

【输出格式】
按 Q1–Q7 逐节写。每节按此骨架：
1) **结论**：一到三句，可执行；
2) **依据**：引用文件章节/条款号，或明确写「依据不足」；
3) **我方判定对不对**（对 / 部分对 / 错）+ 理由；若判"错"，给出你认为正确的处置；
4) **需要改的具体条目**：若涉及总纲的某个 Phase 或断言，写出编号与改法；
5) **可失败的验收断言**：若你提出新改动，给出「跑什么 / 看到什么算过 / 看到什么算失败」。

【硬口径，全程遵守】
- 首要用户 = 项目作者本人 = 最优档：以最优为目标，允许更重的算法、本地模型、更多预算；
- 兼容档不是目标形态，它只是「降级路径必须存在」；
- 每条建议标注服务哪一档；最优档重方案给三件套（成本 + 门控 + 无 LLM 降级）。

【禁止】
- 重述你自己的方案（会被跳过）；
- 重新论证已核实的事实（核实表结论：12/12 成立）；
- 只给方向不给落点（「重构 X」这种没有 `文件:函数名` 的条目不算交付）；
- 无法证伪的建议；
- 大段复述输入包已有内容；
- 只提出问题不给推荐裁决（**每一项未决都要给：你的推荐 + 理由 + 影响哪些 Phase + 相反选择下哪部分要改**）。

【关于不确定】不要停下来向我反问澄清。信息不足就写进「需要补充的信息」，
以"给出可直接执行的结论"为优先。（以本条消息的指令为准。）
```

---

## 4. 回收验收（我怎么判它合格）

**顺序不能反**：

1. **Q7 兜底问题必须先答**——如果它答不出"有没有漏掉内容"，说明它没真读完自己的方案，其余回答可信度打折。
2. **看它敢不敢判"我方错了"**。如果 Q1–Q6 全是"对/同意"，这是**顺着输入说话**的信号（第一轮它敢挑 12 条刺，这一轮若不敢，说明提示词把它压住了）→ 追问「哪一条你最不同意？」
3. **看它给的新断言能不能红**。抽 1 条它新提的断言，写成 node 断言跑一遍——**跑不红等于没断言**。
4. **核落点**：它提的 `文件:函数名` 逐条 grep，合格线 **≥80%**。
5. **最后看它有没有把"未决"抛回来**。每条未决必须带推荐裁决；只给问题不给裁决 → 视为未交付。

---

## 5. 预期失败模式

| 失败模式 | 识别特征 | 对策 |
|---|---|---|
| **顺着写** | Q1–Q6 全"同意"，Q7 答"无遗漏" | 追问：「总纲里哪一条你最不同意？给我一个具体怀疑对象」 |
| **重述自己** | 大段重复第二轮的 7 Phase 设计 | 复述段落跳过；连续两段即退回 |
| **护方案** | 对"Phase 4 拆分"只表态不分析 | 要求它对**每一半**分别给出"切对了/切错了" |
| **回避 Phase 6** | 对"规矩每轮注入"只说方向不论断 | 追问：它与你的 FinalEnvelope 单一口径到底冲不冲突？给是/否 |
| **编造行号** | 引用不存在的 `文件:行号` | 逐条 grep，不存在即整条降级为猜测 |