“每次写文章，它都在旁边盯着”

---

朋友公司做制造业的，200来人，文档散落各处。他想用AI搭知识库提效，我脑子一热答应了。

一个月下来，踩了不少坑。自己搭和帮别人搭，完全是两回事。

---

先说技术选型：用的不是RAG，是LLM Wiki

很多人想到知识库就是RAG：向量数据库 + 检索管道 + 重排 + 生成，搭建周期起码两三个月。

我没走这条路。

这案例用的是 LLM Wiki——Andrej Karpathy在2026年4月提出的概念。核心区别就一句话：

	传统RAG	LLM Wiki
每次提问	从原始文档重新检索、拼凑	从已编译的知识库里直接查
部署周期	2-3个月	1-2周
知识复用	用完即弃，每次重查	一次编译，持续迭代
维护成本	高（向量DB+索引管道+缓存）	低（Markdown+Git+SQLite）

底层用的是一套叫 Harness Wiki 的开源工具。核心就是Markdown知识库 + SQLite索引加速，AI可以直接读写。

目录结构长这样：

knowledge-base/
├── raw/               # 原始文档（不动，留底）
├── wiki/
│   ├── entities/      # 人物、组织、产品
│   ├── concepts/      # 概念、框架、方法论
│   ├── sources/       # 每份原始文档的摘要
│   ├── syntheses/     # 分析、对比、决策记录
│   └── index.md       # 全库索引
├── CLAUDE.md          # AI规范（给AI看的说明书）
└── AGENTS.md          # 多AI协作规范

整套东西跑在一台16核32G的服务器上，月成本不到两千。

---

坑1：Lint不先配，知识库一周变垃圾场

这是第一个踩的，也是最大的坑。

我把框架搭好，让他们自己往里填东西。我的预期是：目录结构有了，规范文件写好了，大家照着放就行。

结果一周后去看——知识库又乱又冗余，索引都找不见了。

原因：员工都是AI新手。他们不知道什么该放、什么不该放。"这个可能有用"→塞进去。"那个以后可能要看"→塞进去。一周下来，知识库变成了"可能有用"的大杂烩。

解法：花了一周时间重建lint机制。

核心不是代码层面的lint（ESLint那种），是**"内容质量"层面的lint**。

每个子目录的CLAUDE.md写清楚三件事：

1. 该目录的用途和边界
2. 命名规范和内容要求
3. 禁止操作

# /wiki/entities/customer-service/CLAUDE.md

## 目录用途
存放客户服务FAQ、话术模板、投诉处理SOP

## 命名规范
- FAQ：faq-{业务线}-{编号}.md
- 话术模板：script-{场景}.md

## 内容要求
- 每个FAQ必须包含标签：#FAQ + 业务线
- 必须有"适用场景"和"不适用场景"
- 投诉案例必须标注等级：P0-P3

## 禁止操作
- 不得存放非客服相关内容
- 不得删除其他模块的索引文件

然后配了一个简单的脚本做自动检查：

# 检查所有FAQ是否包含必要字段
for file in $(find wiki/entities -name "*.md"); do
    if grep -q "适用场景" $file && grep -q "不适用场景" $file; then
        echo "✅ $file"
    else
        echo "❌ $file 缺少必要字段"
    fi
done

教训：lint不能后补。要在第一天就配好，让规则跑在混乱前面。

但后来我发现还有更根本的问题——

---

坑2：Shared context比lint更重要

lint机制跑了一周，知识库确实不乱了。但沉淀的东西没什么用。

查了一下发现根因：大家不知道"什么值得进知识库"。

问题不是操作规范，是没有shared context——公司的决策逻辑是什么？优先级是什么？什么叫做好的output？

这些东西没对齐之前，lint再严也只是在管理混乱，不是在建秩序。

先对齐共识，再配lint。这个顺序不能错。

正确顺序：

1. 开个会，对齐"什么值得存、什么不值得存"
2. 共识写下来，变成CLAUDE.md
3. 再上lint机制做自动化检查

---

坑3：一开始不要追RAG，从LLM Wiki起步

这个坑是我自己跳进去的。

一开始想一步到位——向量数据库+检索管道+排序+生成，全套RAG方案铺上去。

踩完才知道：对一个200人的传统企业来说，RAG太重了。

维度	RAG方案	LLM Wiki方案
部署周期	2-3个月	1-2周
团队学习成本	高（需懂向量DB+索引管道）	低（Markdown+Git）
运维成本	高	低（一台16核32G就行）
检索质量	依赖切片策略+重排	依赖索引质量
改错了能回滚吗	不能（向量不可逆）	能（Git回滚）

对企业来说，能跑起来比跑得完美重要多了。LLM Wiki两周就能跑通闭环，先让团队看到AI能干活，再考虑要不要上RAG。

---

坑4：追求"完美知识库"是最大的时间黑洞

前期有个执念：把所有文档整理好了再上线。

结果发现永远整理不完。

格式不统一：PDF有、Word有、PPT有、邮件有、聊天记录也有。
切片策略不对：按500字切，表格被切烂、代码被切断。
版本控制缺失：文档改了但AI不知道，检索结果还是旧的。
知识不在一个地方：云盘有、OA有、个人电脑也有，搜个东西要翻五个系统。

后来想通了：先搭框架，用起来，边用边补。

Harness Wiki的Skill初始化流程：

Use the Harness Wiki skill to initialize an LLM Wiki vault here.
Name: knowledge. Domain: 制造业客户服务

它会自动生成 wiki/index.md 和 wiki/log.md。一个管索引，一个管变更记录。然后工作流就简单了：

1. 员工扔文档进 raw/
2. AI自动生成摘要、提取实体、关联已有概念
3. 更新索引
4. 其他人提问时，AI从索引检索，给出带引用的答案

知识一次编译，持续复用。不用等"整理完"再上线。

---

坑5：Spec的价值，藏在5%的边界场景里

知识库跑顺之后开始做二次开发。我推了Spec-Coding流程——先写需求文档，再写技术方案，再拆任务，再开发。

有人听了，有人没听，继续Vibe Coding。

刚上线的时候看不出区别。大家都跑得通。

区别在边界场景。

维度	Vibe Coding	Spec-Coding
正常流程	都能跑	都能跑
边界输入	直接挂	有预案
出问题后	翻代码靠猜	翻文档追溯
新人接手	读代码猜意图	读Spec就懂
长期维护成本	越来越高	稳定可控

有严格Spec流程的项目，边界场景处理能力明显更强。就算解决不了，也能留下较高的可观测性。没Spec的项目，一遇到边界场景就是一连串git commit，费劲改半天。

Spec的结构：

## 用户故事
作为客服管理员，我希望能够查询和更新客户订单状态，以便快速响应客户咨询。

## 验收标准
1. THE System SHALL 提供基于订单号的精确查询功能
2. WHEN 用户输入有效订单号时，THE System SHALL 返回订单详情
3. WHEN 用户输入无效订单号时，THE System SHALL 返回"订单不存在"
4. WHEN 订单状态为"已取消"时，THE System SHALL 禁止执行更新操作

关键判断：如果边界失败代价高（财务、合规、客户交付），Spec是刚需。否则Vibe coding够用。

---

坑6：规划超过一个月基本失效

最后说一个非技术但最痛的。

刚开始搞的时候，我跟朋友画了半年的饼：第一个月搭知识库、第二个月跑通三个场景、第三个月全面铺开、第四到六个月建立AI中台……

结果一个月后发现，当时定的规划已经没有意义了。

工具和能力迭代太快。

• 有些事计划半年搞定，三天有结果了
• 有些事计划一个月搞定，半年都够呛
• 随着对组织理解的深入，很多问题的解法和优先级全变了

解法：不做长规划，保持高频review。

每周花一个下午，跟核心团队过一遍：这周做了什么、下周做什么优先级最高、方向要不要调。

靠规划和OKR牵引已经意义不大。保证及时调整方向的能力，比规划本身重要一万倍。

---

写到最后

回头看，这些坑的核心原因就一个——工具能力越来越强了，但组织的协作方式还没跟上。

不是员工不努力，不是工具不好用，是组织还没建立起"什么值得存、什么用AI做、怎么和AI协作"的共识。

MIT的研究说，高达95%的企业AI项目达不到预期。大部分失败不是因为技术不行，是数据孤岛、期望管理失调、缺乏全局成本视角。

下一步不是升级工具，是升级协作方式。

📌 如果你也在公司推AI落地，刚开始不知道从哪里切入——私信"AI落地" + 你的行业，我帮你判断第一个坑在哪。