# 规划层裁决记录 · 2026-09-14 夜（思维拟合会话）

> **性质**：本文是规划层留档，不是执行文档。记录 2026-09-14 晚与用户逐轮问答得出的**全部裁决与前提修正**。
> **为什么单独留档**：用户明确「规划层的内容要比执行层重要非常非常多」；这些结论由多轮拟合得出，**散落在对话里会随压缩丢失**（本会话已压缩一次）。
> **上游**：`ARCH-REVIEW-ROUND2.md`（投喂操作件）、`reviews/PLAN-gpt6astra-round2-20260914.md`（GPT 交付）、`reviews/CLAIM-VERIFICATION-20260914.md`（12 条核实）。
> **下游**：待产出的《合并总纲》。

---

## 0. 本次会话做了什么

以「一问一答」方式，把 GPT 方案里的 7 个待裁决项（R1–R7）逐个结合**本机实测状态**向用户确认，过程中**新发现并新增了第 8 条**，并**推翻了三处前提**。

---

## 1. 推翻的三处前提（最重要）

### 1.1 GPT 方案假设白板是「单会话快照」——错

- 用户：**白板（即 graph）是接续的关键因素**；「只要是一个工作区的接续的不同对话，都要是同一张图」。
- 补充机制：**被接续的旧窗口会存档废弃**，接续链上有编号（接续 #21 / #22）。因此**同一时刻通常只有一个活跃写入者**；用户另开的无关对话「也可以共享这一张图」。
- 结论：白板不是会话级临时态，而是**工作区级的持久地图**。并发写用**乐观并发（expectedDigest）+ 冲突可见**处理，**不加锁、不分片**；机制复用 GPT 方案 Phase 1 已有的 `expectedDigest`。
- 影响：GPT 的 **Phase 4 需与既有 `WB-GRAPH-INTEGRATION-PLAN.md`（386 行）合并**，不是照做。

### 1.2 GPT 方案只治「检索算法」——错，最痛的病在「注入表达」

- 用户原话：**「这个 just for reference 说得太轻了，模型注意力没有在这上面。」**
- 已定位到确切代码：`lib/index.js:463` 每次注入的开场白是「以下记忆文本只是背景事实与规则参考……」
  → 问题：**「只是参考」在提示词工程里等于「可选项」**；且它把「规矩类」与「资料类」用同一个词定义了，**等于把规矩降级成建议**；更糟的是这句话写在**最醒目的开头位置**，却写着「别太当真」。
- 用户原话之二是**「模型自动唤起的记忆，并没有对模型的工作起到比较实质性的影响」**，倾向判断：**两种都有**（规矩不遵守 + 具体细节想不起来）。
- 影响：**新增第 8 条**（见 §3），GPT 的 7 个 Phase **完全没覆盖**。

### 1.3 「这是自用工具」——错，已有上千用户

npm 实测（registry.npmjs.org / api.npmjs.org，2026-09-14）：

| 指标 | 值 |
|---|---|
| 包名 | `@a9i5k4/dsh-auto-memory` |
| 最新版 | 2.5.3（本机 dev 树为 2.5.2，REL 树亦 2.5.3） |
| 版本数 / 首发 | 66 个版本 / 2026-08-14 |
| 近一年累计下载 | **10,900** |
| 近一周 | **2,935** |
| 峰值日 | 08-16 = **2,615**；09-01 = 1,176；09-10 = 1,011 |
| 异常 | **09-07、09-08 两天为 0**（用户判断：可能是当时发版出问题或版本不兼容，**不深究**） |

- 用户反问「你觉得现在要给多少人做」——即**已经不是自用工具**。
- 影响：**兼容档必须真做**（弱机器降级要有实测上限）；「新旧并存 + 开关回退」从「稳妥」升级为「必须」；错误提示、切档进度条属于必需品而非体验优化。

---

## 2. R1–R7 裁决结论（结合本机实测）

### R1 排序展示 —— **双显示**（用户裁定）

- 用户：「两个都显示是非常好的。而且一般不会真的有人去点开上下文注入去看吧。这是给机器看的，又不是给人看的。」
- **实测澄清**：`memory_recall_pre` 返回的数字是**稠密余弦相似度**（`lib/index.js:4429`，过滤线 `minScore: 0.5`，按它降序）；排序侧的 RRF 分与原始分**已在数据结构里**（`recall-fusion-pre.js:35` 明确「原始分数逐条保留供审计」）。
- 因此「双显示」接近**零成本**（数据已在手上，只是 UI 未显示）。
- **关键区分**：UI 上的分数是**给人调试**用的；模型看到的是**注入文本**。两条展示链路不应混。
- UI 上显示顺序：**相似度在前，融合排序分在后**。
- 与 S5.4 的关系：因为**没有拿融合分冒充相似度**（两个都摆出来），冲突不存在。

### R2 margin / 决策阈值 —— **维持现有架构**（工程判断）

- 代码里已经做对了：`recall-fusion-pre.js:10-12` 明确「**融合分数只用于排序；是否注入的决策必须使用绝对分数（稠密余弦）与校准阈值比较**」。
- 实测记录（`lib/index.js:7254`）：「bge-m3 校准的 0.03 对 e5 的压缩分布过严（live 实测 margin 0-0.0284 全被拦）」→ **两档的 margin 尺度不同，不能互相套用**。
- 裁决：新策略**消费带版本的融合间隔必须重新校准**（采纳 GPT 的 R2 推荐）；旧 `margin` 定义与阈值**冻结**，新特征先跑 shadow。

### R3 注入预算边界 —— **分开算**（用户裁定）

- 用户：「以目前的情况来说，分开算应该是非常好的。反正可以让用户在设置里随便改。」
- **实测修正**：本机 `injectBudgetChars` 实际为 **4800**，而 GPT 方案的成本模型假设是 **2000**——**方案建立在一个用户并未使用的数字上**。
- 裁决：**记忆条目一个额度，其他动态内容（白板 / 账本 / 日历 / 外部记忆）另一个总额度**。
- **但新增一条覆盖规则**：**规则类不参与任何预算裁剪**（见 §3）。
- 附带：设置页「大修、提升 UI 质感与可操作度」记为**独立排期项**，不塞进 Phase 0–6。

### R4 共用契约 —— 按 GPT 推荐（无异议）

两档共用流程、字段与判据，允许适配器、数量与预算不同；避免把「同路径」解释为「相同的模型调用」。

### R5 白板 lint —— **要做，且归属变更**（用户裁定）

- 用户：「这个白板后面我要 combine 进 dsh graph 这个开源项目……这个用户是肯定要看的，而且这个肯定是需要改的。甚至有些不明白的时候，AI 可以主动去向用户提问。」
- 裁决：lint **要做**，且**不只是报告**——有问题要能改；AI 不明白时可**主动向用户提问**。
- **归属**：并入 WB-GRAPH 重构，**不单独作为 Phase 4 的一部分**。

### R6 白板人机分区 —— **需要用户手写区**（用户裁定，推翻了「全 AI 维护」的初答）

- 用户先说「全是 AI 写的，由 AI 来维护」，随后**自我修正**：「确实需要有用户手写区来保护用户，或许有时候确实需要手动去改。然后 AI 应该也会有和用户共同编辑。」
- **实测现状（关键）**：`WB-FORMAT-CONVENTION.md` §5 **早已定义人机分区**（每张卡片分 `<!-- model -->` / 用户区，永不互相覆盖），但**实际 PLAN.md 里一个锚点、一个分区标记都没有**——规范已批准、**代码从未实现**。
- **这解释了今天早些时候那个事故**：没有锚点、没有分区 ⇒ **整篇覆盖是唯一可行的写入方式** ⇒ 系统自动快照一写，白板全貌就没了。
- 裁决：分区要真做，并入 WB-GRAPH 重构 P1/P2。

### R7 数值与计量 —— 按 GPT 推荐（无异议）

定义源记录已批准数值，行为测试独立验证；字符估计只标「估计」，真实 tokenizer 计量另报。

---

## 3. 新增第 8 条（GPT 方案完全没有）

### 8.1 病症

用户原话（本次会话最有价值的信号）：

> **「just for reference 说得太轻了，模型注意力没有在这上面。」**
> **「模型自动唤起的记忆，并没有对模型的工作起到比较实质性的影响。」**

### 8.2 两条独立病因

| | 病因 | 证据 |
|---|---|---|
| **A. 措辞** | 注入开场白把「规矩」与「资料」统一降格为「参考」；且写在最醒目位置却写着「别太当真」 | `lib/index.js:463` |
| **B. 节奏** | `snapshotMinGapRounds = 5` ⇒ **规矩在第 2–5 轮不在场**；模型不是不听话，是**没收到** | `lib/index.js:326`、`7455` |

### 8.3 裁决：规则/参考分层

| 层级 | 存放 | 注入节奏 | 预算 | 谁写 |
|---|---|---|---|---|
| **用户级规则** | 用户级记忆（现有 `~/.dsh/memory/MEMORY.md`） | **每个工作区、每轮都注入**（相当于用户画像） | **不参与预算裁剪** | AI 写入，用户可改 |
| **工作区级规则** | 工作区自己的规则文件 | **每轮都注入** | **不参与预算裁剪** | AI 写入，用户可改 |
| **参考类** | 现有 `MEMORY.md` / 日志 / 反思 | 三层漏斗（目录常驻 → 摘要 → 原文） | 受 R3 的额度约束 | 现有机制不变 |

- 用户裁定：**两层都要**（工作区级 + 用户级）。换工作区 = 换工作区级规则；用户级跨工作区恒定。
- 用户补充的**膨胀对策**：「让规则写得稍微克制一点，以每个工作区为锚点」。
- **成本可行性**：规则几乎不变 ⇒ 位于注入前缀 ⇒ **命中 DeepSeek 前缀缓存（约原价 1/10）** ⇒ **每轮注入的边际成本极小**。用户判断「注入这点东西用不了多少缓存预算」**成立**。
- **分类时机（用户裁定，重要）**：**不做成独立 LLM 调用**。`memory_log` 本来就在**本轮内由模型直接写**（「这个是直接写的，就在本轮当中确定什么是规则、什么是参考」），顺手打标 = **零额外成本**。将来 procedural memory 同理。
- **反驳与保留（我的建议，待用户确认）**：AI 分类的风险是**漏判**——真规则被判成「偏好」就会掉进参考类，**而这正是要修的病**。建议**前缀双保险**：出现 `【用户硬性规则】`/「严禁」/「必须」/「绝不」等字样时，**无论 AI 怎么判一律强制进规则类**。规则集小，多塞代价低；漏一条的代价是反复纠正。

### 8.4 附带的 UI 缺口（用户提出）

- 用户：「这个约束性的东西**必须得让用户看到**，并且让用户能进行精修。比如在记忆窗格的可视化里面，能够让用户看到目前模型有什么约束。」
- **实测**：记忆窗格现有 **12 个标签页**（概览 / 日志 / 精炼 / 记忆中枢 / 存储 / 笔记 / 白板 / 反思 / 连接 / 日历 / 工作区……），**没有任何一页显示「当前模型受什么约束」**。
- 裁决：新增「约束」视图，归入**UI 提质排期**。

---

## 4. 引擎隔离与切换（用户裁定）

- 用户：「本来它们就是分隔的，只要在切换的时候强制前排（全量重建）就可以了。直接给用户显示一个进度条。」
- **实测两档用的是两个不同模型**：C2 = `Xenova/multilingual-e5-small` q8（端侧）；C3 = `Xenova/bge-m3` int8（Python sidecar，555MB）。**向量空间不通用**。
- 代码已有意识（`PROVIDER_ID_INT8 = 'bge-m3-onnx-int8-pre-v1'`），**但没做成硬约束**。
- **新增能失败断言 T2-9（引擎隔离）**：用 e5 建的索引，切到 bge-m3 后**必须整体失效并重建**；若出现两套向量参与同一次排序，**判失败**。成本为零（仅加身份校验）。
- **用户强调的耦合约束**：切档进度条**必须并进现有「引导 / 向导」体系**（Python BGE 下载、venv 建环境已有可视化指导），**不得另起一套**。

---

## 5. 精排（H2）——方案被实测数据推翻，需重写

### 5.1 方案假设 vs 实测

| | GPT 方案假设 | 本机实测（`artifacts/m7-rerank-pre/results.json`） |
|---|---|---|
| 额外等待 | **≤750 ms** | **bge-reranker-v2-m3：P95 37.4 秒；qwen3-reranker-0.6b：P95 8.8 秒** |
| 模型资产 | U5「缺，阻塞」 | **已下载**（bge-reranker-v2-m3 2.1GB / qwen3-reranker-0.6b 1.1GB，各带 tokenizer） |
| 精度收益 | 未量化 | **recall@1：0.739 → 0.898（bge）/ 0.800（qwen）** |

### 5.2 硬件实测（我最初查错了，此处更正）

- **有可用显卡**：`NVIDIA GeForce RTX 4070 Ti SUPER`，**16GB 显存**，驱动 616.64。
- （我最初只列了前 3 个显示适配器就误判「无 GPU」，**此处更正并留痕**。另有 AMD Radeon 集显 + 3 个虚拟适配器。）
- 当前 Python 环境：`torch 2.13.0+cpu`（**CPU 版**）、`transformers 5.15.1`、`onnxruntime 1.23.2`、16 核 CPU、31GB 内存。

### 5.3 用户裁定：改为「多级选项」

用户原话：「这恐怕是一个**可以多级选项**的问题。发烧友、追求高质量的人或者研究人员，可以打开显卡加速进行精排……普通用户的话，用粗排就可以……（或者只在主动翻记忆的时候跑。亦或者拉长自动注入的时间。反正目前自动注入的时间窗口间隔是 1 分钟，也是可以改的。）」

| 档 | 谁用 | 跑在哪 | 触发时机 |
|---|---|---|---|
| **关** | 默认 | — | 不精排，纯粗筛 |
| **快档** | 普通用户 | int8 量化 / ONNX / CPU | 主动翻记忆时 |
| **发烧档** | 作者 / 研究者 | 完整模型 + RTX 4070 Ti SUPER | 主动翻记忆 + 可选自动注入 |

**并且新增方案里没有的机制**：精排改为 **1 分钟异步窗口** —— 本轮先用现有排序，精排在后台跑完，**结果留给下一次注入**。「准确率」与「不卡等待」不必二选一。

### 5.4 两个开发中遇到的实测坑（保留）

- **精排模型量化后更小更快**：用户提到 `multilingual` 100 多 MB、`bge` 500 多 MB（= `models-xenova-bge-m3-int8`，实测 555MB），比完整版快很多。
- **已有 int8 vs fp32 对照脚本**：`python/bench/l2_bench_int8_vs_fp32.py`（尚未读到结果，待补）。

---

## 6. 用户级判断：成本模型的正确算法

用户反问：「你觉得这个成本模型的成本要怎么算？反正付钱的又不是我给这几千人一起付，是他们自己付自己的钱。」

**结论：我原先的推理有隐含错误**——把「上千用户 × 每轮注入」当成**一张账单**来吓自己。真实情况：

| 项目 | 谁付钱 | 对作者的成本 |
|---|---|---|
| 记忆注入 token | 用户自己的 API key | **0** |
| 精排算力 | 用户自己的机器（本地推理） | **0** |
| 嵌入建索引 | 用户自己的机器（一次性 + 增量） | **0** |

- 「上千用户」对**成本模型的影响为 0**；真正的影响是**代码质量**（bug 被放大）与**兼容档必须真做**。
- 推论：**该省的地方是「别浪费」（不重复注入同样内容），不该省的地方是准确性**；而前缀缓存让「规则每轮注入」的边际成本极小。

---

## 7. 白板 / graph 的战略裁决（用户裁定：(乙)）

用户裁定：**「(乙) 两者合并：把 GPT 的『写入门 + 引擎隔离 + 状态过滤』这套通用原则，注入到你 WB-GRAPH 方案的 P1/P2 里。」**
并补充：**「我认为这个 dsh graph 正是我想要的 Karpathy 模块。」**

查证结果（仓内既有资产）：

| 文档 | 规模 | 状态 |
|---|---|---|
| `WB-GRAPH-INTEGRATION-PLAN.md` | 386 行 | 2026-09-13 完成，含判据 Schema、sidecar 设计、两工具方案 |
| `WB-GRAPH-DECISIONS-20260914.md` | 54 行 | 一页纸拍板点（A1–A8 / B1–B7），**大部分仍标 🎯 未拍板** |

**GPT 的 Phase 4 与既有 WB-GRAPH 方案的差异**：

| | GPT Phase 4 | WB-GRAPH 方案 |
|---|---|---|
| 目标 | 白板进语料 + 写入门 + lint | 白板 → **看板化**（combine dsh-graph） |
| 判据 | 卡片集合比对 | 完整判据表（H1–Hn） |
| 存储 | 直接改 Markdown | **Markdown = 人读真相源，sidecar JSON = 机读派生件** |
| 检索 | 进 L0 语料 | **新增两工具**（expand / trace），工具数 14 → 16 |
| 人机 | 用户区保护（一整块） | **每卡片分区**（模型区 / 用户备注区） |

**合并后的分工（我的建议，待确认）**：
- GPT Phase 4 中**真正新增**的只有 **lint** 一项 → **挂到 WB-GRAPH 的 P1 上**；
- 「写入门的前后比对」与 WB-GRAPH 的 **B1 同源** → 合并实现；
- 「用户区保护」与 **B4 选项 (c)** 同源 → 按 WB-GRAPH 的每卡片分区做；
- GPT 的 **引擎隔离（T2-9）与状态过滤（C8）** 属 Phase 0/2，**不随白板走**。

---

## 8. 评测题集（U3）

- 用户：题集是**很早期初创算法时做的**，后面需要**结合已有记忆（现在记忆量已丰富）继续优化算法，或再整一套丰富的测试题和标准答案**。
- 待查：`python/bench/results/m7-2-results.json`（799KB）与 `m7-2-l2-results.json`（468KB）的内容形态。
- **建议方向（待确认）**：新题集应当**从真实记忆语料出发**（用户已有大量真实记忆），而不是凭空造题——这样才测得出「真实使用中的召回质量」。

---

## 9. 开工节奏与风险（用户裁定）

- 用户裁定：**要新旧并存 + 开关切换，随时能退回**。
- 用户裁定第一步：**先出《合并总纲》**。
- 用户追问：现在可以开工了吗？还是先找 GPT 再咨询 / 总纲出来再让 GPT 审一遍？

**我的建议（写作本文时给出）**：

> **总纲 → 我方先做「矛盾扫描」→ GPT 审 → 开工**

理由：GPT 审之前，两份方案（它的 7 Phase 与 WB-GRAPH）之间的**表面对齐**应由我方先做；否则它会花大量篇幅指出「你这跟我的 Phase 4 不一样」——那是**已知信息**。让它审「调和是否正确」，比让它审「自己的方案」有效得多：**它能发现自己没考虑的整合问题，发现不了自己没想到的东西**——后者今天这场对话已经做了。

**开工前必须先补的三件**：
1. 《合并总纲》（含 GPT 7 Phase + 第 8 条 + WB-GRAPH 的合并与排序）；
2. 矛盾扫描结果（两份方案冲突清单 + 调和方案）；
3. **不做**：在总纲出来前动 `lib/index.js` 的注入链。

**唯一的例外（可以立刻做、且建议做）**：
- **C8 缺陷修复**——`superseded` / `retracted` 条目**现在真的会进入注入文本**（本会话已用 `tools/_redproof/red-proof-phase0-t01.mjs` 跑出 4/4 报红）。这是一个**正在发生的真实危害**，且修复范围极小、可独立回滚。

---

## 10. 本次会话产出的文件

| 文件 | 内容 |
|---|---|
| `docs/internal/reviews/REVIEW-gpt6astra-20260914.md` | 第一轮评审原文（补录，此前并未真正落盘） |
| `docs/internal/reviews/CLAIM-VERIFICATION-20260914.md` | 12 条主张逐条核实（12/12 成立） |
| `docs/internal/ARCH-REVIEW-ROUND2.md` | 第二轮投喂操作件 |
| `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md` | GPT 第二轮交付：RAG+Karpathy 实施方案 v1（37071 字） |
| `tools/_redproof/red-proof-phase0-t01.mjs` | T0-1 断言的「能红」证明（4/4 报红） |
| **本文** | 规划层裁决记录 |