企业官网建设流程全解析

在为 AI 代理配备代码库、设计文档、邮件记录或研究资料时，最标准的做法是 RAG：分块、嵌入、查询时检索 top-k 片段，再让模型生成回答。这套流程跑得通，但存在一个结构性的缺陷——合成永远发生在查询时刻。模型每回答一次问题，都要从原始碎片重新拼凑上下文、重建理解。第十次问同一个代码库的架构逻辑，和第一次一样需要模型重新梳理，没有任何知识沉淀。

LLM Wiki 把这个时间点彻底前移：合成只在摄入时发生一次，之后通过持久的 Markdown 页面实现积累与更新。四个独立团队在几个月内不约而同地验证了同一套架构，这不是巧合，而是对一个底层问题的共同解答。

维护簿记工作如何成为传统 wiki 的隐形杀手

人类 wiki 失败的原因从来不是缺少洞察，而是无止境的簿记。新增一份设计文档后，需要手动更新几十个实体页的摘要、补全交叉引用、检查与已有内容的矛盾。这些工作没有即时反馈，也没有上限。团队一忙起来就自然放弃，wiki 逐渐腐烂，人们不再信任它，它就死了。

模型却不介意做这些 unglamorous 的工作。它不厌倦，不会遗漏交叉引用，能一次性触达多个文件并保持一致。Karpathy 在原始 gist 中直指这一点：普通文档流程的问题在于“模型每次都在从头 rediscover 知识”，而 LLM Wiki 的核心是“编译一次，然后保持新鲜”。

这就像数据库里的物化视图。原始表是不可变的源数据，每次查询都做复杂 join 计算（类似 RAG 的每问重推导）；物化视图则在数据变更时预先计算并维护结果，后续查询直接读视图，速度快且一致。LLM Wiki 做的正是知识层的物化。

LLM Wiki 的三层结构为什么专为代理阅读而设计

整个模式只有三层，极简却极度适配模型的阅读习惯：

• 原始来源层：不可变。论文、仓库、邮件、Notion 页面——模型只读不写。
• Wiki 层：模型完全拥有的 Markdown。包含实体页、概念摘要、交叉引用。页面不是写给人看的，而是写给下一个读取它的模型看的。
• Schema 层：一个配置文件（常见命名 CLAUDE.md、AGENTS.md 或类似）。它定义 wiki 的组织规则、页面模板、以及模型必须执行的工作流。这让模型从“会写文件的聊天机器人”变成“有纪律的维护者”。

三层之间通过三个核心操作闭环运行：摄入（新来源到达时，模型识别受影响实体，更新或创建页面，修订摘要，标记矛盾）、查询（从 wiki 读取上下文，可选地把高质量回答回写为新页面，让探索持续 compounding）、Lint（定期扫描陈旧声明、矛盾、孤儿页并修复）。

下面是这个闭环的逻辑架构建议（Mermaid）：

四团队不约而同的选择揭示了什么底层正确性

四家团队解决的问题不同（公开代码库、CI 构建、私人知识、生活记录），却在几个月内收敛到几乎相同的形状：

收敛点清晰：Markdown 存 Git + Schema 文件 + 摄入时合成 + 变更时刷新。分歧主要在“如何保持新鲜”——Factory 把 staleness 当成构建问题用 CI 解决，其他团队则依赖按需触发。这正是成熟度的信号：当独立团队在不同约束下走到同一架构时，这个形状大概率是对的。

它不是用户记忆 而是语料的持久编译产物

这里有一个容易混淆但必须区分的边界。LLM Wiki 解决的是语料知识：把一堆文档/仓库/邮件“说了什么”编译成可查询、可维护的页面。它回答“这个材料集合包含哪些事实和关系”。

它不解决用户与体验记忆：某个具体用户上周改变了供应商决策、某个方法在某个 App 里已经试过失败、用户的偏好随时间演变。这些是按 user_id 绑定的、从交互中积累、需要支持矛盾与删除的记忆。

把 wiki 当成“给代理加了记忆”是一种常见的误判。Wiki 给你的是编译后的语料资产，而不是跟随用户的长期个人记忆。两者是互补的，前者让代理能高效读取稳定知识，后者让代理真正记住“你”。

规模、忠实度与陈旧性构成的真实边界

这个模式不是万能的，它有清晰的适用范围：

• 规模：Karpathy 自己指出，无 embedding 的 index-first 方式在中等规模（约 100 个来源、几百页）表现惊人。超过这个量级，就需要引入混合搜索（BM25 + 向量 + LLM 重排），正如原 gist 推荐的 qmd 那样。
• 忠实度：摄入时编译意味着早期摘要可能悄无声息地丢失源细节，后续所有回答都会继承这个损失。纯检索原始 chunk 不存在这个压缩风险。
• 陈旧性：编译页面的正确性只等于上次刷新的时刻。过时的 wiki 比没有 wiki 更危险，因为它以权威格式自信地给出错误信息。Factory 用 CI 解决这个问题，其他方案则依赖人工触发。
• 编译成本：你需要 upfront 支付 token 来构建可能永远不会被查询的页面，以及定期 lint。

在生产环境落地前必须权衡的编译与检索边界

当语料稳定且被频繁重读时，优先编译成 wiki，能把后续查询的合成成本降到极低，并让知识真正积累。
当语料快速变化或规模已经很大时，纯编译的忠实度与陈旧风险会上升，需要在关键路径上保留检索能力，或采用混合策略（小规模编译 + 大规模混合搜索）。

我起初以为这只是文档自动生成的又一次迭代，后来对比 Karpathy 的原始表述和四团队的实际工程差异后才意识到：这是在重新定义代理持有知识的方式——从“每次都重新教育模型”变成“模型负责维护一个活的知识资产”。

知识的积累不是检索的自然副产品，而是编译的主动结果。维护从来不是写的问题，而是持续更新的簿记问题。而模型恰好是唯一不怕做这些工作的存在。

当你的语料规模从几十页增长到几百页时，你会如何在纯编译 wiki 和混合检索之间动态切换？这个选择对长期 token 效率和回答一致性的影响，值得每位构建生产级 AI 代理的工程师认真思考。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。