OpenViking团队文档不再各说各话

周三下午，客户在电话那头问了一个再普通不过的问题：这票货没保价，出了问题怎么赔？刚接手业务不太熟悉，在工作群里问了一句，结果：

老王说按 1 倍运费，他做这块四年了；小李翻出一份产品文档，白纸黑字写着 3 倍基本运费、最高 1000 元；售后的同事更谨慎：这个得分产品，我再查查。

三个人，三个答案，而且每个人都能翻出一份正式材料。负责任的新人没有立刻报一个赔付数字，转头把这句话输入给办公智能体想进一步核实清楚再回复。Agent 能检索团队知识库、给出引用，似乎应该比单独问人更靠谱。但是 Agent 这次也帮不上忙，它告诉你"根据当前信息无法给出准确回复"，然后甩给了你一堆线索文档，让你自己先确认清楚客户采购的服务类型，再去查看相应的计费标准找答案。

这就是团队知识最容易卡住的地方：团队沉淀了很多文档和知识库，AI 办公工具也有，但资料都找到了，适用关系却还没有理清。

二、团队真正缺的是一张 Wiki 网络

Agent 找到了很多资料，却仍然无法回答"到底怎么赔"。团队真正缺少的，不是更多知识库文档，而是围绕客户、产品、规则和流程组织的 Wiki 网络。

2026 年 4 月，Karpathy 提出了 LLM-Wiki 这一知识库范式：在原始资料和用户之间，增加一层由 LLM 维护的、持久化的 md Wiki。新资料进入后，需同步更新实体页、概念页、对比页，补充交叉引用，并标记新旧材料之间的矛盾。这些 Wiki 既能独立维护，又能被 Agent 按问题动态检索和串联。当新证据出现时，更新的是同一套知识，而不是再生成一份互不相认的新答案。

下一次遇到赔付问题，可以不再从一堆文档中拼凑答案，而是有一条可追溯的知识链：先查客户 Wiki，确认客户采购了什么服务、属于哪种业务类型；再查产品 Wiki，确定对应的产品、线路和服务范围；最后关联到计费与赔付 Wiki，找到当前生效的标准、适用条件和例外规则。

三、用 OpenViking 三步搭起团队 Wiki

方法论有了，那应该如何搭建起团队的 LLM-Wiki？OpenViking 已提供零代码路径。

第一步是资料导入。OpenViking 已有现成的 Connector 和导入入口，可以把分散在不同位置的数据接进来，作为后续编译 Wiki 的原料。本地文件选择"本地上传"，上传赔付细则、历史规则和业务说明等文件；网页、在线资料与 Git 仓库通过链接接入，例如把代码仓库地址填入即可把 README、代码和配置文件一起纳入团队知识；飞书里的产品说明与 FAQ 选择"数据源同步 → 飞书文档"按页面提示完成授权与导入配置。如果需要定期跟进仓库更新，也可以用 add-resource 命令配合 --watch-interval 60 表示每 60 分钟同步一次。Git 导入保留原有目录层级，并遵循 .gitignore 等过滤规则。

第二步是把数据编译为 Wiki。Compile 是 OpenViking 最新上线的功能，可以支持自定义 Skill 或使用预置的 LLM-Wiki Skill，并基于 Skill 指导 Agent 把原始数据重新组织、编译成你想要的形式。要先把"怎样才算一份好 Wiki"写进自定义 Skill。Skill 可以说清四件事：给谁用、按什么方式组织、哪些事实和条件必须保留、完成后如何检查。官方也提供 llm-wiki 模板，用于生成有出处、相互链接、带导航入口的知识库，可以直接导入。发起 compile 任务时，核心参数有 3 个：来源 --from、目标 --to、生成规则 --skill。

第三步是把 Wiki 接入 Agent。资料导入并完成处理后，就可以接入 Agent 使用。按官方接入指南，为 Codex、TRAE 等配置对应的插件或集成，让它们访问同一套 OpenViking 资源。OpenViking 的检索是层级式渐进读取：先看摘要与概述，定位到相关模块后，再读取具体文档详情——这种全新的检索范式，可以节省很多检索 Token。

四、编译 Skill 与检索 Skill 的分工

Wiki 进入生产环境后，Skill 主要分两类：编译 Skill 和检索 Skill。两者职责清晰，分工明确。

编译 Skill 决定如何处理资料、生成什么内容。它在 Compile 阶段被调用，把导入的原始数据按既定规则组织成 Wiki。一线团队可以根据业务场景编写自己的编译 Skill，例如要求 Wiki 同时保留产品、地区、版本和例外，并把相关页面连接起来。

检索 Skill 则向 Agent 交代何时使用、去哪查、怎么沿"客户→服务→产品→规则"核实适用关系、如何给出结论与来源。它规定依据不足或口径冲突时明确说明而不补猜。一线看到的不再是三份互相打架的文档，而是包含确认口径、适用产品地区时段与例外、历史版本与变更关系、未解决冲突及每句话来源的可展开知识链。确认结果回到同一套知识，下一位同事不必重新找三个人。

五、为什么旧工作流越来越撑不住

团队知识出现"各说各话"的根因是三重的。第一重是文档碎片化。产品说明在飞书、赔付细则在本地、变更背景在 Git，三种来源互相不引用，新人靠记忆拼起来。第二重是版本漂移。一份文档去年是 3 倍运费，今年可能改成了 5 倍，但旧版本还在资料库里流传。第三重是 Agent 推理的局限。即便 Agent 能检索全部文档，它也无法判断哪条口径适用于眼前这个具体客户。

LLM-Wiki 范式正是对这三层问题的回应：通过统一 Wiki 网络把碎片化整合，通过"标记新旧材料矛盾"控制版本漂移，通过 Skill 约束让 Agent 的检索带有"核实适用关系"的逻辑。

六、反面观点：维护成本与质量门禁

Wiki 网络看似优雅，但运行起来并不轻松。

第一个门槛是维护成本。每当业务规则变化、产品迭代或地区政策调整，Wiki 都要同步更新。缺乏专人负责时，Wiki 会逐渐和真实业务脱节，反而比文档更难发现错误。

第二个门槛是 Skill 编写的复杂度。官方 Skill 模板能解决 70% 的场景，但每个团队的细微差别仍需要定制。Skill 写得过于宽松，编译产物会变得稀松；写得过于严格，又会漏掉边界情况。

第三个门槛是 Agent 的信任成本。Wiki 网络把"资料找到了但结论不一致"的卡点前移到一面——Wiki 答错时，团队失去的不仅是答案，而是整套知识基础设施的可信度。

七、不适合用 Wiki 网络的两种情况

Wiki 网络也并非万能。两种场景建议不要强上：

第一种是规模极小的团队。3 人以下的小团队用聊天记录就够了，引入 Wiki 网络反而增加维护负担。等到团队规模超过 15 人、跨多个产品线、跨多个地区时，Wiki 网络的边际收益才真正开始显现。

第二种是文档本身还没沉淀的团队。Wiki 网络解决的是"如何把已有文档组织得更好"，如果连原始文档都还没写，那应该先补原始文档，再考虑 Wiki 化。

八、我的评价

Wiki 网络的真正价值，是把"分散的经验"重新组织成"可复用的共同知识"。这套范式的核心不是 Wiki 工具本身，而是 Wiki 背后的"维护责任"——谁负责导入、谁负责编译、谁负责审核、谁负责更新。没有这层责任，Wiki 网络很快就会变成另一个没人维护的文档库。

未来 12 个月里，把 Skill 模板和 Wiki 工具一起带给一线团队的实践方案，将决定这套范式是停留在头部公司，还是真正落到中小团队的日常。LLM-Wiki 范式的真正考验，是三年后第一批使用它的团队，究竟有没有把日常知识管理的边际成本真正降下来。