Harness Engineering 实践：LLM Wiki 何时引入、如何落地

最近观察到一种现象：一些团队在基础知识体系尚未健全的情况下，就急于引入 LLM Wiki。PRD、技术方案、测试用例、接口约束等核心交付资产还未形成稳定的事实源，就开始把 LLM Wiki 作为产研知识体系的入口。这种做法表面上看很「先进」，但风险不容忽视——如果底层知识本身不可信，LLM Wiki 很容易将「混乱」包装成「智能」，让回答看起来流畅、页面看起来完整，但事实依然是散的、旧的、无人负责的。

概述

LLM Wiki 的本质是什么？它不是传统意义上的知识库，而是一个智能解释层。传统 Wiki 负责保存知识，而 LLM Wiki 的核心价值在于「读懂已有知识」。它将代码仓库、产品文档、设计文档、测试资产、Issue、PR、发布记录、Runbook 等资料接入后，通过大模型完成索引、摘要、结构化、语义检索和自然语言问答。新人接手订单模块时，可以快速理解业务场景和模块边界；产品经理可以查询某个能力是否已有类似设计；测试工程师可以了解某个异常场景过去是否覆盖过；Agent 可以借此快速定位上下文。

知识分层：Git 与 LLM Wiki 的职责边界

在讨论 LLM Wiki 之前，首先需要对产研知识进行合理分层。我认为可以粗略分为三类：第一类是和产品交付直接相关的核心知识，包括正式 PRD、验收标准、技术方案、ADR、API contract、数据模型、核心测试用例、测试执行结论、发布记录、Runbook 等。这类知识一旦与代码不一致，就会直接影响交付质量，必须优先进入 Git 或同等可版本化、可审计、可追溯的事实源。原因很直接：Git 离代码近，天然具备版本、差异、分支、Review、回滚和审计能力。第二类是过程态知识，如 PRD 草稿、方案讨论、评审意见、缺陷分析、待确认问题等。这类知识可以先放在 CR 或 issue 里跟随变更走，等评审通过后再将稳定部分写回 specs/、delivery/ 或 constraints/。第三类是探索型和横向知识，如产品脑暴、客户访谈、竞品观察、会议纪要、团队经验贴等，这类知识不必全部进 Git，更适合放在协作文档工具里，由 LLM Wiki 做检索和摘要。

Git 知识底座与 LLM Wiki 的配合模式

我不建议将问题简化为「到底用 Git 还是用 Wiki」——这是一种偷懒的二分法。更合理的关系是：Git 管事实，LLM Wiki 管使用。Git 知识底座解决的是：哪些是当前事实、谁改过为什么改、是否经过 Review、产品和技术基线是什么、知识之间的追溯链路如何建立。LLM Wiki 解决的是：人如何更快理解这些事实、如何跨角色查资料、Agent 如何快速定位上下文、历史知识如何更容易被发现。关键规则是：发现问题不在 Wiki 页面里「修表述」，而是回到源头改 PRD、SDD、测试用例、Runbook 或 ADR。另外，如果一个问题被问三次，就不应该只存在于问答记录里，而应该回写到知识底座中。

引入时机与团队阶段匹配

LLM Wiki 的引入应该按团队阶段而非工具热度来决定。小团队、早期产品阶段先别急——如果团队只有几个人，产品还在快速试错，靠高频沟通推进，那么优先把最小事实源建起来：产品目标、关键 PRD、验收标准、核心测试用例、关键 ADR、Runbook、接口说明、AGENTS.md。这时候上完整 LLM Wiki，容易制造虚假的完整感。中等团队、模块变多时，可以小范围试点。当出现新人理解慢、跨模块问题总要问老人、测试回归范围靠经验、文档「曾经是对的」等现象时，就可以选一个知识密度高的模块（如订单、权限、计费）进行试点。试点时不要看页面生成得漂不漂亮，而要看几个关键信号：回答是否引用来源、错误是否能追溯到源文档、高频问题是否能回写、测试同学是否更容易定位影响范围。大团队、复杂系统阶段，LLM Wiki 的价值会明显变大，但需要配套权限、数据分级、来源追溯、回答质量抽检和成本控制。

如有侵权，请联系删除。