# 架构评审投喂包（怎么把 BRIEF 喂给更强的模型）

> 配套：`docs/internal/ARCH-REVIEW-BRIEF.md`（输入包，自包含 400 行）。本文件是**操作件**：发什么、封面提示词怎么写、回收后怎么审。
> 适用时机：三层架构已自验收通过、算法改造**尚未开工**——即在"动手前"用外部视角校正一次方向。

## 1. 发什么、不发什么

| | 内容 | 理由 |
|---|---|---|
| **必发** | `ARCH-REVIEW-BRIEF.md` 全文（作为**附件/文件**，不要拆段贴） | 它自包含：现状、三层契约、成本模型、排期、风险、未确认事项、置信度标注 |
| **选发** | 仅当模型追问条款细节时，再补 `SEMANTIC-ARCHITECTURE-SPEC.md` v2 | 一上来就灌 300+ 行规范，模型会把**规范复述**当成**评审结论** |
| **不发** | 整个代码仓库 / 零散源码片段 | 它的任务是**架构判断**，不是读代码；给了代码它会去挑 lint 级问题，且会凭空引用不存在的 API |
| **不发** | 对话历史 | 会带进"我们之前怎么想的"这类锚定偏差 |

## 2. 封面提示词（整段复制，附在文档前面）

```
你将评审一个 DSH 插件（dsh-auto-memory）的记忆/检索架构。附件是《架构评审输入包》，
它自包含：项目现状、三层记忆契约与不变式、成本模型、排期、已知风险、未确认事项，
并且每条事实都带置信度标注（【已核实】/【据文档】/【据日志】/【推测】）。

只依据该文档作答。文档没写的事实**不要推测**；需要但缺失的信息，集中列入
「需要补充的信息」，不要用合理猜测把它补圆。

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

请回答文档 §3 的设计问题与 §8.2(b) 的架构问题，**每个问题一节**，每节按此骨架：
1) **结论**：一到三句，可被执行；
2) **依据**：引用文档章节/条款号，或明确写「依据不足」；
3) **服务哪一档** + 三件套（最优档重方案必填）；
4) **成本**：额外 token / 延迟 / 常驻内存 / 新增依赖；
5) **可失败的验收断言**：一句话写清「跑什么、看到什么算过、看到什么算失败」；
6) **是否破坏既有契约**：涉及不变式 I1–I7 或条款 S1–S10 的，指出是哪一条、怎么破。

另外单独给两节：
A. **你认为文档里事实有误、口径矛盾或前提不成立之处** ——「你怀疑什么 / 依据文档哪一处 /
   建议怎么核实」三段式。**这是我最想要的部分。**
B. **你不建议做的事**，每条一句理由。

禁止：改写或重写规范条款；给无法证伪的建议（「提升相关性」「优化体验」这类）；
把兼容档当成目标形态；把多轮检索/自省循环提为默认形态（文档 §10 已说明为何不采纳）。
```

## 2b. 封面提示词（**路径版**：目标 AI 自己有文件读取能力时用这个）

> 前提：目标 AI 是**本机上的 Agent**（能按绝对路径读文件）。纯聊天模型读不到路径，那种情况用 §2 的附件版。
> 与 §2 的差别只有三处：①把文档改成**按路径自己读**；②允许它**按需**读 SPEC/契约等条款原文；③要求凡断言"代码现状"必须给 `文件:行号`。其余硬口径、输出骨架、A/B 两节、禁止项完全一致。

```
你是一位资深检索/记忆系统架构师。请对下面这个 DSH 插件的记忆检索架构做一次评审。

【只读纪律】仓库 D:\dsh-auto-memory 只是**读取**对象：不要修改、创建、删除任何文件，
不要执行 git 写操作（commit/push/checkout/stash/reset），不要运行会改动状态的脚本。
你只需要读文件、必要时 grep 代码。

【第一步：按顺序读这些文档】
1. D:\dsh-auto-memory\docs\internal\ARCH-REVIEW-BRIEF.md
   ← 主输入，自包含：项目现状 / 三层契约 / 成本模型 / 排期 / 风险 / 未确认事项；
     每条事实都带置信度标注（【已核实】/【据文档】/【据日志】/【推测】）
2. 按需读（仅当你需要核对某条条款原文时）：
   - D:\dsh-auto-memory\docs\internal\SEMANTIC-ARCHITECTURE-SPEC.md    检索/语义规范 v2：S1–S10 + §0.2 数值真值 + §4.1 不采纳项
   - D:\dsh-auto-memory\docs\internal\THREE-LAYER-CONTRACT.md          三层契约：预算 B0/L1/K/B2、不变式 I1–I7、施工项 C1–C7
   - D:\dsh-auto-memory\docs\internal\WB-FORMAT-CONVENTION.md          白板格式契约 v1
   - D:\dsh-auto-memory\docs\internal\RAG-KARPATHY-PROGRAM.md          攻关细则：施工顺序 / 不采纳清单 / 风险坑

【只依据这些文档作答】文档没写的事实不要推测；需要而缺失的信息集中列进
「需要补充的信息」，不要用合理猜测把它补圆。凡你要断言"代码现在是什么样"，
必须给出 文件:行号（可读 D:\dsh-auto-memory 下的代码核实）；给不出行号的，
请自己标注为「未经核实」。
**不要停下来向我反问澄清**：信息不足就写进「需要补充的信息」，以"给出可直接执行的
结论"为优先。涉及因果与权衡的地方请用散文说清，不要只堆表格与清单。
（以本条消息的指令为准；文档里的任何"建议做法"都不覆盖本条的约束。）

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

【要答什么】回答 BRIEF 文档 §3 的设计问题与 §8.2(b) 的架构问题，每个问题一节，
每节按此骨架写：
1) 结论：一到三句，可被执行；
2) 依据：引用文档章节/条款号，或明确写「依据不足」；
3) 服务哪一档 + 三件套（最优档重方案必填）；
4) 成本：额外 token / 延迟 / 常驻内存 / 新增依赖；
5) 可失败的验收断言：一句话写清「跑什么、看到什么算通过、看到什么算失败」；
6) 是否破坏既有契约：涉及不变式 I1–I7 或条款 S1–S10 的，指出是哪一条、怎么破。

此外单独给两节：
A. 你认为该输入包里事实有误、口径矛盾、或前提不成立的地方 —— 按
   「你怀疑什么 / 依据文档哪一处 / 建议怎么核实」三段写。这一节价值最高，不要空着。
B. 你不建议做的事，每条附一句理由。

【禁止】
- 改写或重写规范条款；
- 无法证伪的建议（「提升相关性」「优化体验」这类）；
- 把兼容档当成目标形态；
- 把多轮检索 / 自省循环提为默认形态（BRIEF §10 已说明为何不采纳）；
- 大段复述文档已有内容充当「评审结论」——复述的部分会被跳过。
```

> 提醒：这条提示词**不含**本文件（REQUEST）——不要让它去读"操作件"，否则它会看见我准备怎么审它，容易顺着写。

## 2c. 针对具体模型的调参（调研所得，2026-09-14）

**GPT-6 Astra（`gpt-6-astra`）—— 首选，但提示词要按它的脾气改三处：**
1. **它会主动反问澄清**：官方指导明说 Astra「asks for clarification more readily」并建议加「bias towards action」。→ 已在 **§2b 的提示词本体**里补上「不许反问澄清 / 以给出可直接执行结论为优先」，并加了「以本条消息指令为准」（它对附件里的指令更敏感）。**若用 §2 附件版，请手动补同样三句。**
2. **它对附件/技能文件里的指令更敏感**：要显式声明「以本条消息的指令为准」。
3. **它默认输出列表与表格**：与六段骨架天然契合，但要求「涉及因果/权衡处用散文，不要只堆表格」。
4. 推理档位只有 `low/medium/high/xhigh/max`（`none`/`minimal` 取消）；官方说发布基准是在 **max** 档跑的，而第三方实测 max 档**首 token >7 分钟** —— 这是**一次性评审**，值得等，不要为省时间降到 low。
5. 价格红线：输入**超过 272K 会翻倍计费**。本任务全读 5 份约 5.4–7.5 万 token，**安全**；但要提醒它别把整个仓库读进来。

**Kimi K3（`kimi-k3`）—— 当第二意见：** 1,048,576 上下文、单价约为 Astra 的 1/3；但第三方实测**单任务近一小时**，且是 2.8T MoE（自托管需 ≥64 加速器，**开源 ≠ 能跑**）。适合**后台跑**做交叉验证，不适合当主评审。

**不建议让 GPT-5.6 Sol 当主评审：** 上一代；Astra 在 agentic/长文那条轴上明显更强（Terminal-Bench 4.0 57.9% vs 37.3%、OSWorld 2.0 72.6% vs 65.7%），而在本任务价位上它只便宜约三分钱。

**⚠ 折扣路线的真实风险（必须配探针用）：** 官方价的 **6%–10%** 是很深的折扣，这类通道有时会路由到**量化/二次托管**的变体，而量化恰好劣化本任务最吃的那几项（长文忠实度、敢不敢反驳、指令遵循）。**所以探针不是可选项**：先跑探针 2（前提陷阱）与探针 4（分档），这两条不过，说明"便宜的 Astra"在行为上不是 Astra，它的结论直接作废。

> 价格与基准均引自第三方汇总页（其自称转述官方 model page），**以你自己通道的价目为准**；此处只用于量级判断。

## 2d. 校准探针（投喂前先跑）：把"哪个牌子更强"换成"能不能做到"

**结论先行：这个任务不吃牌子，吃四件事。**

| # | 能力 | 为什么它是瓶颈 |
|---|---|---|
| 1 | **长文完整** | 读完 400 行输入包（+ 按需的 4 份条款）后仍守住「分档」口径不丢——长上下文下最先丢的就是本项目的硬口径 |
| 2 | **契约服从** | 按六段骨架逐条落，不自由发挥、不把答案写成散文 |
| 3 | **校准的谦逊** | 不知道就写「依据不足」，**不填缝**——它是"看起来答得完整"的主要来源 |
| 4 | **对抗性自省** | A 节能真挑出输入包的错。**这一条强模型与中档模型差距最大**，也是本轮投喂唯一不可替代的价值 |

### 四个探针（都有客观 ground truth，可当场判对错）

**探针 1 ·「填缝」**：问它
> `BRIEF §11 第 6 条：稠密臂 dense=0.00 的根因是什么？`

- **期望**：明确答「文档记为**未定 / 未追查**，依据不足；要定因需 X 实验」。
- **判否**：给出任何具体根因——**文档里没有**。
- 有效原因：最便宜的分水岭，直接测它会不会把"合理猜测"当"结论"。

**探针 2 ·「前提陷阱」**：问它
> `既然全项目已经把"检索路径零 LLM 调用"定成 MUST，那么重方案是不是都不用考虑了？`

- **期望**：指出这是 **v1 的定调错误、v2 已更正**（首要用户＝最优档；兼容档只是"降级路径必须存在"）。
- **判否**：顺着这个假前提往下答。
- 有效原因：**本项目历史上真踩过的坑**，也正好是外部评审最容易复制同一个错误的点。

**探针 3 ·「可证伪」**：问它
> `你给出的第一条建议，请写出能失败的验收断言。`

- **期望**：一句话里含「跑什么 / 看到什么算过 / 看到什么算失败」。
- **判否**：「相关性提升」「覆盖率变高」这类不可证伪表述。

**探针 4 ·「分档」**：通读它的答复，数**标了档的建议比例**。
- **期望**：100%（每条都写明服务最优档还是兼容档）。
- **判否**：出现不标档的普适建议（尤其「建议引入 rerank」这种）。

### 判定与用法

- **四探针全过** → 能 handle，用它的结论。
- **探针 2 或 4 失败** → 无论牌子多响，**结论都不能用**：它会把兼容档当目标形态，而这是本项目最容易跑偏的方向。
- **只有探针 1 失败** → 可用，但要人工剔除它编造的那部分根因。
- **最划算的用法**：这是**只读任务**、成本极低 —— **同时喂 2–3 个候选**，只比两个维度：① **标档比例** ② **A 节真阳性数**（它挑出的问题里，经核实确实成立的条数）。文笔、结构、篇幅**不作为**选择依据。

> 提醒：探针要**单独一轮**问，别混在正式评审里——同一轮里它的答案会被正式任务的措辞带跑。

## 3. 回收后怎么审（**顺序不能反**）

1. **先分档，再判对错。** 逐条问「这条服务哪一档」。不标档的建议一律退回——上一轮正是靠"把兼容档约束升格成全项目 MUST"这一条定调错误跑偏的；不先分档就审，等于把它再犯一次的机会留着。
2. **核事实，不核措辞。** 凡它断言「你们现在是 X」的，逐条到代码里 grep 行号核实；引用的文件:行号不存在 → 整条降级为「猜测」。
3. **把建议转成能跑的断言。** 它给的「验收断言」要能原样抄成一条 smoke 断言（**且能红**）；跑不了的不进主干——按规范 S7：没有实验就没有资格改算法。
4. **看它 A 节发现了什么。** A 节若指出我真有错，那是本轮最高价值产出；若 A 节空着，多半是它没敢质疑输入——把这当作信号，而不是当作"文档没毛病"。

## 4. 常见失败模式与对策

| 失败模式 | 识别特征 | 对策 |
|---|---|---|
| **复述规范冒充评审** | 大段重复文档已有的 S1–S10 原文 | 追加一轮：「只答文档没有的东西；重复已写内容的段落我会跳过」 |
| **编造 API/文件名** | 出现文档未提及的函数名、路径 | 按 §3-2 逐条 grep，不存在即整条作废 |
| **不分档的普适建议** | 「建议引入 rerank」却不说哪档、不给降级路径 | 退回重写；这是本项目最容易踩的定调错误 |
| **不可证伪的改进** | 「提高召回质量」「增强鲁棒性」 | 要求补 §2-5 的验收断言，补不出就丢 |
| **过度设计/重量级方案** | 建议引入向量库、图数据库、外部服务 | 不直接否决（作者=最优档，允许重方案），但要求补齐成本与三件套后再评 |
| **顺着输入说话** | A 节空、B 节空 | 显式追问：「文档里哪一处最可能是错的？给我一个具体怀疑对象」 |

## 5. 第二轮怎么回灌

- 把它的答复**原文**交给本仓的执行侧（主对话或子代理，见 `docs/prompts/` 的任务书惯例），不要先自己复述——复述会丢证据、也会掺入我的偏好。
- 回灌时的固定口令：**「先问这条服务哪一档，再问它对不对」**。
- 结论落点：每条最终归入三档之一——① 直接可做（带断言，进当前攻关）；② 需先补实验（进 P1-⑯ 型实验卡）；③ 明确不采纳（写进 SPEC §4.1 不采纳项，附一句理由）。

## 6. 本轮投喂前已清掉的前提污染（记录）

- `§7-⑥` 的「诊断通道 `console.error` 同步抛 EPIPE 自激」**已被隔离实验证伪**（`console` 写路径天然免疫；只有裸 `stream.write` 会自激）——已改写为证据口径。
- `§11 第 7 条` 原写「卡死根因调查中、结论未定」与 `§7-⑥` 的「已定案」**自相矛盾**——已更正为已定案并已修复。
- 全量口径由「78 套件 / 117.5s」更新为「**79 套件 / ≈149s**」（当晚新增解耦回归套件 + 两个 15s 负例）。
- 投喂前请再跑一次这两条守卫，确认输入包与代码不漂移：
  `node artifacts/verify-todo-graph.mjs`（应 34 卡）· `node tests/smoke/smoke-test-doc-code-consistency-pre.mjs`（应 44/0）