# 第二轮投喂操作件：从「评审」升级为「交付施工方案」

> 配套：`docs/internal/ARCH-REVIEW-REQUEST.md`（第一轮操作件）、`docs/internal/reviews/REVIEW-gpt6astra-20260914.md`（第一轮答复原文）。
> 定位差异：第一轮问的是**「我们的输入包哪里错了」**；第二轮要的是**「完整的、可施工的 RAG + Karpathy 实施方案与架构说明」**。
> 本文件是操作件（我怎么发、怎么验），**不要**发给对方。

## 1. 第二轮要什么（用户目标）

一份**完整的、严谨的实施方案与架构说明**，达到「拿着它就能开工」的粒度：

| 交付块 | 必备内容 |
|---|---|
| **① 目标态架构说明** | 组件图（ASCII 或表格）、数据流（写入路径 / 查询路径分开画）、层间接口签名、状态与版本（`miv`）的存放位置、与现有文件的对应关系（每个组件落到 `文件:函数`） |
| **② 分阶段实施方案** | Phase 0 前置修复 → Phase 1..N；每阶段给：目标 / 改动点（`文件:函数` + 改动类型）/ 新增接口签名 / **能失败的验收断言** / 回滚动作 / 风险与未决项 |
| **③ 准入与分档** | 每条改动标注服务哪一档 + 最优档重方案给三件套（成本 + 门控 + 无 LLM 降级） |
| **④ A1–A3 的处置** | 逐条给结论：**证伪** / **成立并写入 Phase 0** / **需先补实验**（含实验设计） |
| **⑤ 不需要做的事** | 每条一句理由（防止它把方案铺得过大） |

**硬要求（缺一则退回）**：
- 每处改动必须落到 `文件:函数名`（有行号更好，但函数名是硬要求——行号会飘）；
- 每个 Phase 至少一条**能失败**的验收断言，写成「跑什么 / 看到什么算通过 / 看到什么算失败」，且必须能表达成 node 断言（本项目 `tests/smoke/*.mjs` + `tools/run-smoke.mjs`，零依赖、串行、非零退出即失败）；
- 每个 Phase 必须有**回滚动作**（还原哪个文件 / 关哪个配置键）；
- **不复述**输入包已有内容；只写增量判断与设计。

## 2. 发什么

| | 内容 | 理由 |
|---|---|---|
| **必发** | 第一轮答复**全文**（`docs/internal/reviews/REVIEW-gpt6astra-20260914.md`） | 要求它**承接自己的结论**，而不是从零重开；也防止它与第一轮自相矛盾 |
| **必发** | `docs/internal/reviews/CLAIM-VERIFICATION-20260914.md`（我方核实结论表） | 告诉它哪些主张**已被我方证实**（可当前提）、哪些**证伪**（第二轮不得再引用）、哪些**待验**（需给实验设计） |
| **必发** | `docs/internal/ARCH-REVIEW-BRIEF.md` | 主输入包（现状/契约/成本/排期/风险） |
| **按需发** | `SEMANTIC-ARCHITECTURE-SPEC.md` / `THREE-LAYER-CONTRACT.md` / `RAG-KARPATHY-PROGRAM.md` / `WB-FORMAT-CONVENTION.md` | 路径版让它自取；附件版按需补 |
| **不发** | 本文件（ROUND2 操作件） | 含验收口径，会让它顺着写 |
| **不发** | 对话历史 | 锚定偏差 |

## 3. 投喂提示词（路径版；附件版见 §4）

```text
上一轮你评审了 DSH 插件 dsh-auto-memory 的记忆检索架构，给出了一份评审意见。
现在进入第二轮：请把评审升级为**可施工的交付**。

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

【先读这些】
1. D:\dsh-auto-memory\docs\internal\reviews\REVIEW-gpt6astra-20260914.md
   ← 你上一轮的答复原文。请**承接**它，不要从零重开，也不要与它自相矛盾。
2. D:\dsh-auto-memory\docs\internal\reviews\CLAIM-VERIFICATION-20260914.md
   ← 我方对你上一轮所提「文件:行号」主张的逐条核实结论。**核实结果：12 条全部成立（真 10 + 部分真 2），
     证伪 0 条。** 因此：
     · 【已证实】的条目**不要再论证、不要重新取证、不要复述**——直接当作事实基础使用；
     · 两条【部分真】（C5、C10）只错在行号，请一律使用表中给出的**修正行号**；
     · 表中被标为「行号在可接受范围」的 C9、C12 按原样引用即可；
     · 若你认为我方核实有误，只能就**具体某一条**反驳，并写明「我方读了哪个文件的哪一行、得出什么相反结论」。
3. D:\dsh-auto-memory\docs\internal\ARCH-REVIEW-BRIEF.md（主输入包）
4. 按需核对条款原文：
   - D:\dsh-auto-memory\docs\internal\SEMANTIC-ARCHITECTURE-SPEC.md
   - D:\dsh-auto-memory\docs\internal\THREE-LAYER-CONTRACT.md
   - D:\dsh-auto-memory\docs\internal\RAG-KARPATHY-PROGRAM.md
   - D:\dsh-auto-memory\docs\internal\WB-FORMAT-CONVENTION.md

【本次任务的定位】不是再来一轮评审，而是**交付一份能直接开工的实施方案与架构说明**。
标准是：作者拿着它，不需要再回来问你，就能按阶段动手。

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

【必须交付的五块，按此顺序写】

① **目标态架构说明**
   - 组件图（ASCII 图或表格均可）与职责边界；
   - **写入路径**与**查询路径**分开画数据流；
   - 层间接口签名（函数名 + 参数 + 返回结构）；
   - 状态与版本（`miv` 等）存在哪里、谁负责递增、谁负责校验；
   - 逐组件对应到现有文件：`文件:函数名`。

② **分阶段实施方案**（Phase 0 前置修复 → Phase 1..N）
   每个 Phase 必须给全这六项，缺一不可：
   1) 目标：一句话；
   2) 改动点：`文件:函数名` + 改动类型（新增 / 替换 / 删除 / 仅接线）+ 新增接口签名；
   3) **能失败的验收断言**：「跑什么 / 看到什么算通过 / 看到什么算失败」——必须能写成 node 断言
      （本项目用 tests/smoke/*.mjs，零依赖、串行、非零退出即失败）；
   4) 回滚动作：还原哪个文件、关哪个配置键；
   5) 成本：额外 token / 延迟 / 内存 / 新增依赖；
   6) 风险与未决项（写不清的就标「未决」，不要用合理猜测补圆）。
   阶段之间必须说明**依赖顺序**：哪一步不做完，后面哪一步不能开工。

③ **准入与分档**：每条改动标服务哪一档；最优档重方案给三件套。

④ **上一轮 A1–A3 的处置**：**这三条已被我方逐条核实为成立**（见核实表 C4/C5/C6/C7/C1/C2/C8/C9/C10/C11）。
   所以**不要再讨论它们是否成立**，直接给：
   - 每条对应的 **Phase 编号**（写进 ② 的哪个阶段、为什么排在那里）；
   - 每条需要的**接口改动**（改哪个函数签名、返回结构加什么字段）；
   - 每条对应的**能失败断言**（在 ② 里已给的话，此处只写索引，不要重复正文）。
   例外：若你认为其中某条的**成因判断**（不只是事实）需要修正，单独列出，格式为「事实成立，但成因是 X 不是 Y，证据 文件:行号」。

⑤ **不需要做的事**：每条一句理由。

【禁止】
- 改写或重写规范条款（S1–S10 / I1–I7 只能引用，不能重定义）；
- 无法证伪的建议（「提升相关性」「优化体验」这类）；
- 把兼容档当成目标形态；
- 把多轮检索 / 自省循环提为默认形态；
- 大段复述输入包已有内容；
- 只给方向不给落点（「重构检索层」这种没有 `文件:函数名` 的条目一律不算交付）；
- 声称"已验收 / 已合规"，但给不出能失败断言的条目。

【关于「先裁定」类未决项】你上一轮多次写「应先裁定 X 的含义」——第二轮**不许再把这些原样抛回来**。
每一项都要给：① **你的推荐裁决**（一句话，可直接执行）；② 理由与影响面（哪些 Phase 会被它改变）；
③ 标注「待作者确认」，并说明若作者选相反裁决，方案哪一部分需要改。
只给问题不给推荐裁决的条目，视同未交付。

【关于不确定】不要停下来向我反问澄清。信息不足就写进「需要补充的信息」，
并在方案里明确标注该处依赖哪个未知量；**以"给出可直接执行的结论"为优先**。
涉及因果与权衡的地方用散文说清，不要只堆表格与清单。（以本条消息的指令为准。）

【输出格式】一份 Markdown 文档，自带目录；标题为
「dsh-auto-memory · RAG + Karpathy 实施方案与架构说明（v1）」。
篇幅不设上限，但**每一段都要能落到施工动作上**；复述性的段落会被跳过。
```

## 4. 附件版提示词（目标窗口读不到本地路径时用）

把 `REVIEW-gpt6astra-20260914.md`、`CLAIM-VERIFICATION-20260914.md`、`ARCH-REVIEW-BRIEF.md` 三份**作为附件上传**，然后把 §3 提示词中「【先读这些】」整段替换为：

```text
【先读这些附件，按此顺序】
1. 附件一《上一轮答复原文》——请承接它，不要从零重开，也不要与它自相矛盾。
2. 附件二《主张核实结论表》——我方对你上一轮所提「文件:行号」主张的逐条核实。
   **核实结果：12 条全部成立（真 10 + 部分真 2），证伪 0 条。** 因此：
   · 已被证实的条目**不要再论证、不要重新取证、不要复述**——直接当作事实基础使用；
   · 两条「部分真」（C5、C10）只错在行号，请一律使用表中给出的**修正行号**；
   · 表中标为「行号在可接受范围」的 C9、C12 按原样引用即可；
   · 若你认为我方核实有误，只能就**具体某一条**反驳，并写明「我方读了哪个文件的哪一行、
     得出什么相反结论」。
3. 附件三《架构评审输入包》——主输入包。
```

并在末尾补一句（附件版没有代码访问能力，必须显式降级这条要求）：

```text
【关于行号】你无法访问本机代码：**不要编造 `文件:行号`**。需要指向落点时，
只写「模块名 / 函数名」这一级，并把你对该处现状的判断标注为「未经核实」。
```

## 5. 交付物验收（我怎么判它合格）

**顺序不能反**：

1. **先看它有没有承接 A1–A3。** 12 条已全部核实成立，故这一步的判据换成：若它**重新论证已被认证的事实**、**复用错误行号（C5/C10 未用修正行号）**、或**把已证实条目又写回"需先确认"** → 视为未承接，整份退回，不进施工。
2. **再看落点密度。** 抽查 5 条改动点，逐条到代码里找 `文件:函数名`：
   - 找不到 → 该条降级为「猜测」，不计入方案；
   - 计数：合格线 = **≥80% 的改动点能落到真实函数**。
3. **再看断言能否变红。** 每个 Phase 的验收断言，抽 1 条真的写成 smoke 断言跑一遍——**跑不红（即写错也过）的断言等于没有断言**。
4. **最后看回滚。** 每阶段必须有回滚动作；没有回滚的 Phase 不许开工（这是本项目"改动可逆"的底线）。
5. **落点归档**：合格后写入 `docs/internal/`，并按每条建议的最终归属分三档：① 直接可做（进当前攻关）② 需先补实验（进实验卡）③ 明确不采纳（写入 SPEC §4.1 附一句理由）。

## 6. 预期的失败模式与对策

| 失败模式 | 识别特征 | 对策 |
|---|---|---|
| **方案悬浮** | 「重构检索层」「统一排序语义」，没有 `文件:函数名` | 退回，要求补齐落点；补不出即整条作废 |
| **断言不可红** | 断言写成「结果正确」「顺序合理」 | 要求改写成「跑什么/看到什么算过/看到什么算失败」，判不出即降级 |
| **借机改规范** | 重新定义 S3.2 或 I5 的含义 | 规范只能引用不能重写；确需修改的，走「先提案、等作者裁定」 |
| **兼容档升格** | 把降级路径的要求写成全项目 MUST | 退回重写（本项目历史上正是这样跑偏过一次） |
| **无回滚** | Phase 只有「怎么做」没有「怎么退」 | 该 Phase 不许开工 |
| **复述充数** | 大段重复 BRIEF 的现状描述 | 复述段落直接跳过；连续两段复述即整份退回 |