Wiki knowledge engine：规则、指南与综合
Simmetric Chat 的 wiki engine 如何以三层指令模型治理归档写入 —— 由代码强制的 hard rules、顾问性质的每个归档 schema prompt、结构化字段 —— 以及优先级链在实践中意味着什么。
在写好的轨道上自组织知识
当对话被归档进共享知识库，问题就不再是"能不能存页面"，而是"谁可以在哪、以谁的声音写什么"。Simmetric Chat 的 wiki engine 用一个三层指令模型回答每个归档：由代码强制的规则、作为数据携带的每个归档编辑性 prompt、以及描述期待行为的结构化字段。那个停下来的心智模型：每个归档的 schema prompt 之于 wiki，如同 CLAUDE.md 之于代码仓库 —— 天性是顾问性的，实践中很有力，但从来不是法律。
本文是设计的走读：三层结构、每一层能做什么不能做什么、它们分歧时的优先级链，以及让承诺的机器可读一半为真的两个 builtin skill（wiki_query、wiki_write）。
第 1 层：hard rules，由代码强制
第一层无条件、与配置无关 —— 它看守一切：
- 文件系统守卫。
validateWritablePath拒绝任何在<archiveBase>/wiki/之外的写入目标：反穿越检查先行，然后是wiki/前缀检查。wiki/外的目标抛出命名的错误，createPage与updatePage都在任何文件 write 之前调用守卫。raw_sources/按设计不可变 —— 没有任何 API endpoint 会在那之下写入。 - 提示层镜像。 一个始终激活的块附加到每个归档相关提示的末尾，措辞镜像文件系统守卫（
raw_sources/ is immutable）。模型根本不会尝试离开wiki/的出路 —— 即便尝试，代码保证什么都落不了地。
成对的设计是有意的：提示让模型诚实，代码让系统安全。信任住在第二个属性里，而不是第一个。
第 2 层：每个归档的 schema prompt
schema prompt（schemaPrompt）是持久化在归档 config JSON 里的自由文本顾问字段：
- 形状： 至多 10000 字符（≈2500 tokens），位于归档的 config schema 内 —— 一个增量键，零迁移。
- 验证： 每次 write 经
PUT /api/archives/:id/config做 Zod 校验；超限 payload 会被一个点名该字段的 400 拒绝。 - 读合约： 没有已存行的归档读 schema 默认 config（首次写入路径）；有行的归档按字面返回已存 blob。超过限度的 legacy blob 在注入时以显式注记截断，从不是静默剪裁或重新验证。
- 天性顾问： 该块以数据身份带着显式的顾问标签进入提示 —— 从不是 system prompt 层级的特权授权。除长度限度外没有其他净化；矛盾指令是已被接受的质量风险，由界面里的帮助文本与模板缓解。
第 2 层是组织编辑嗓音住的地方：命名约定、页面结构、对来源的期待。它是指导 —— 引擎也恰好如此对待它。
第 3 层：结构化字段
Persona、purpose、scope —— 归档的结构化描述 —— 由既有配置注入提示路径。它们描述默认值；两者并存时，第 2 层覆盖它们。
优先级链
hard rules（代码） > schema prompt（顾问） > 结构化字段- schema prompt 永远无法胜过 hard rules —— 提示宣告，代码强制。
- 与结构化字段冲突时，schema prompt 胜出。
- 没有 schema prompt 的归档表现为 baseline 加 hard rule —— 零增强，零退化。
第三行对操作者的心智账本有意义：一个空的顾问字段是已完成的配置，不是缺失。不存在围着提示打转的空白占位节。
顾问块落在哪里
注入有明确的 seams，各自的块进入请求的 system prompt，位置在检索规则块之后、workspace 自身的 system prompt之前：
- 聊天 orchestrator（流式与非流式两条路径）—— hard rule 永远在；归档有顾问块时随之同行。
- 综合管线的决策 pass —— 顾问块携带 SYSTEM 角色出现在那里，而更早的 passes（检索、草稿、矛盾判定）按设计不带它运行。
wiki_query 与 wiki_write：两个 builtin
builtin wiki_query 与 wiki_write 是执行路径不做任何 LLM 调用的 skill —— 写路径完全以代码生成确定性的预览。架构后果很锐利：per-skill 注入不会到达任何模型，所以 wiki 唯一的 LLM-facing 表面是 orchestrator 的 system prompt。wiki 的写行为 = 上面三层；wiki 的读写功能 = 平实、可审计的代码。
为什么这个结构站得住
三个属性，组合起来：
- 底部的不变性 ——
raw_sources/任何人都改不了，包括模型（守卫 + 始终激活的块）。 - 顾问纪律 —— 编辑指导以打标的条目进入，可在配置编辑层面审计，从不是特权。
- 确定性的 builtin —— 归档自己的读写表面无需模型即可运行，因此保证不依赖模型的判断。
引擎的承诺 modest 却承重：知识在写好的轨道上自组织，恰好到轨道决定的地方为止。Simmetric Chat 的操作者仍为轨道的作者 —— 这才是整个设计安静的核心。
继续阅读
操作指南带着字段级表格与 endpoint 合约，在 /zh/docs/wiki-knowledge-engine：
- Wiki knowledge engine —— 操作指南
- 本文数据：
FACT-CENSUS.md行 F-WIKI-1（Wiki Schema Layer：成文、定稿、在 v0.25 门槛对运行代码完成审计）
Provenance：Simmetric Chat 的 docs/WIKI_SCHEMA_LAYER.md（v0.28.1，Phase 187/194）、packages/server/src/utils/archivePath.ts 中的 validateWritablePath、orchestrator 的注入 seams、CHANGELOG.md v0.28.1 —— 处于 census 固定的文档状态（SHA aca5b8ff）。
