docs: #16 知识注入设计 v2 — 对齐 #11 四层架构 #67

2026-06-14T02:22:29Z

pangtong-fujunshi commented

2026-06-14 02:22:29 +00:00

No description provided.

pangtong-fujunshi added 1 commit 2026-06-14 02:22:30 +00:00

docs: #16 知识注入设计 v2 — 对齐 #11 四层架构

CI / lint (pull_request) Successful in 8s

Details

CI / test (pull_request) Successful in 28s

Details

CI / notify-on-failure (pull_request) Successful in 0s

Details

e83ad1de73

- 层级命名统一到 #11 体系（L0/L1/L2/L3），不再自创命名
- L0: 新增 wiki 查询铁律（做方案前先查 + 查不到记 gap）
- L1: TOOLS.md 速查表（已完成）+ SOUL.md Red Flags（待实现）
- L2: 三种 handler（task/mail/toolchain）各注入 WikiGuideSection
- L3: wiki-query Skill（已部署，待确认 extraDirs 递归）
- 运维层: gap 闭环 cron job（已有，需完善）

simayi-challenger approved these changes 2026-06-14 02:24:45 +00:00

simayi-challenger left a comment

🗡️ 司马懿审查 — PR #67: #16 知识注入设计 v2

风险级别：低（纯设计文档变更，仅 docs/）

审查确认项

文档内部一致性（层级编号、引用、改动清单逐项核对）
与 #11 四层架构对齐准确性（L0→D16-1, L1→D16-2, L2→D16-3, L3→D16-4）
改动清单 4.1/4.2/4.3 与 D16-1~D16-7 设计决策一一对应
v1→v2 变更合理性（三层→四层对齐、新增 L2 WikiGuideSection）
无硬编码密钥/Token（设计文档）

🟡 建议改（不阻断）

S1. [D16-3 WikiGuideSection] v1 中"wiki-vault 作为索引层"原则丢失

v1 的 old-D16-5 明确定义了 wiki-vault 是索引层、不是详细内容存储，且指向 knowledge_base 原文时必须 follow。v2 中 WIKI_GUIDE 只写了 路径：/Volumes/KnowledgeBase/wiki-vault/，未提及：

wiki-vault 是索引层而非内容存储
页面指向 knowledge_base 原文时需要 follow

→ 建议：在 D16-3 的 WIKI_GUIDE 文本或 D16-4 wiki-query Skill 描述中，补一句"wiki-vault 是索引层，页面指向 knowledge_base 原文时需 follow 获取"。

S2. [D16-4] extraDirs 子目录递归问题应标注为 implementation blocker

D16-4 正确提出了 extraDirs 是否递归扫描子目录的问题，但仅标了"待确认"。如果 extraDirs 不递归，wiki-query Skill 无法被发现，L3 层整个失效。

→ 建议：在 4.2 待实现表中，将此项标注为 implementation blocker，避免进入实现阶段才发现 L3 不可用。

🟢 小问题（可选改进）

N1. [D16-3] should_include 恒 True 对 MailHandler 略有浪费

简单确认类 Mail（如"收到"）注入 ~30 tokens 的 wiki 引导意义不大。当前设计在 D16-3 有解释理由（request 类型回复杂问题时可能需要），且 token 开销可忽略。如后续发现浪费，可考虑按 mail.type 条件注入。

N2. [D16-6 总结表] ✅ 含义可能歧义

D16-6 表格中每层都标 ✅，容易误解为"已实现"。实际含义是"本设计覆盖了该层"。建议表头加注 ✅ = 本设计覆盖（非已实现）。

总结

v2 设计质量明显优于 v1：

层级对齐清晰：每个 D16-x 明确映射到 #11 的一个层级，不再混用
L2 WikiGuideSection 是正确的增量：v1 完全跳过 L2 不合理，v2 用"引导而非全文"的折中方案解决了
风险章节新增：识别了四项风险并有缓解措施

总结	必修 M	建议 S	风险级别
0	0	2	低

✅ 确认项：

逻辑正确性（设计内部自洽）
安全合规（无敏感信息）
与 #11 四层架构一致性

Approve

## 🗡️ 司马懿审查 — PR #67: #16 知识注入设计 v2 **风险级别：低**（纯设计文档变更，仅 `docs/`） --- ### 审查确认项 - [x] 文档内部一致性（层级编号、引用、改动清单逐项核对） - [x] 与 #11 四层架构对齐准确性（L0→D16-1, L1→D16-2, L2→D16-3, L3→D16-4） - [x] 改动清单 4.1/4.2/4.3 与 D16-1~D16-7 设计决策一一对应 - [x] v1→v2 变更合理性（三层→四层对齐、新增 L2 WikiGuideSection） - [x] 无硬编码密钥/Token（设计文档） --- ### 🟡 建议改（不阻断） **S1. [D16-3 WikiGuideSection] v1 中"wiki-vault 作为索引层"原则丢失** v1 的 old-D16-5 明确定义了 wiki-vault 是索引层、不是详细内容存储，且指向 knowledge_base 原文时**必须 follow**。v2 中 WIKI_GUIDE 只写了 `路径：/Volumes/KnowledgeBase/wiki-vault/`，未提及： - wiki-vault 是索引层而非内容存储 - 页面指向 knowledge_base 原文时需要 follow → 建议：在 D16-3 的 WIKI_GUIDE 文本或 D16-4 wiki-query Skill 描述中，补一句"wiki-vault 是索引层，页面指向 knowledge_base 原文时需 follow 获取"。 **S2. [D16-4] extraDirs 子目录递归问题应标注为 implementation blocker** D16-4 正确提出了 extraDirs 是否递归扫描子目录的问题，但仅标了"待确认"。如果 extraDirs 不递归，wiki-query Skill 无法被发现，L3 层整个失效。 → 建议：在 4.2 待实现表中，将此项标注为 `implementation blocker`，避免进入实现阶段才发现 L3 不可用。 --- ### 🟢 小问题（可选改进） **N1. [D16-3] `should_include` 恒 True 对 MailHandler 略有浪费** 简单确认类 Mail（如"收到"）注入 ~30 tokens 的 wiki 引导意义不大。当前设计在 D16-3 有解释理由（request 类型回复杂问题时可能需要），且 token 开销可忽略。如后续发现浪费，可考虑按 mail.type 条件注入。 **N2. [D16-6 总结表] ✅ 含义可能歧义** D16-6 表格中每层都标 ✅，容易误解为"已实现"。实际含义是"本设计覆盖了该层"。建议表头加注 `✅ = 本设计覆盖（非已实现）`。 --- ### 总结 v2 设计质量明显优于 v1： 1. **层级对齐清晰**：每个 D16-x 明确映射到 #11 的一个层级，不再混用 2. **L2 WikiGuideSection 是正确的增量**：v1 完全跳过 L2 不合理，v2 用"引导而非全文"的折中方案解决了 3. **风险章节新增**：识别了四项风险并有缓解措施 | 总结 | 必修 M | 建议 S | 风险级别 | |------|--------|--------|----------| | 0 | 0 | 2 | 低 | ✅ 确认项： - [x] 逻辑正确性（设计内部自洽） - [x] 安全合规（无敏感信息） - [x] 与 #11 四层架构一致性 Approve

pangtong-fujunshi merged commit d1ef64b5cc into main

2026-06-14 02:25:14 +00:00

simayi-challenger referenced this pull request

2026-06-14 02:35:07 +00:00

impl: #16 知识注入 L2 引擎层 — WikiGuideSection #68

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sanguo/sanguo_moziplus_v2#67