知识库真正难的，从来不是“能不能搜”
很多项目知识库失败，不是因为没有搜索框，而是因为内容更新速度跟不上项目变化速度。页面改了一轮、分类改了一轮、发布边界重画了一轮，文档里的判断却还是旧的。久而久之，知识库就会从“帮助你恢复上下文”的工具，变成“你需要额外判断它是否还可信”的负担。
这也是我后来重新理解 AI 在知识库里的位置的原因。它最有价值的地方，不是替我生成更多文档，而是帮我维持“结构与现实尽量同步”。如果这件事做不到，搜索能力越强，反而越容易把人带到一堆看似完整、实则过时的材料里。
我先定义的不是问答，而是知识对象
一开始我也很容易把知识库理解成一个大问答系统：把项目资料喂进去，然后希望自己以后直接向 AI 提问。但这种方式有一个根本问题——如果底层没有被拆成稳定的知识对象，问答就很容易把旧信息、新信息、局部事实和作者猜测混在一起。
所以我后来先拆的是对象，而不是问法。对我来说，项目里真正应该被长期保存的知识大致有几类：
- 决策：为什么这样做，而不是为什么代码现在长这样
- 约束：哪些边界是平台、业务或结构决定的
- 路径：关键文件和运行链路在哪
- 历史：某次重构或发布为什么会发生
- 当前状态：哪些部分已经收口，哪些仍在演化
一旦知识对象清楚了，AI 才适合介入。因为它此时面对的不是一堆散乱材料，而是有层次的整理任务。
我把 AI 放在整理员位置，而不是最终解释者位置
我现在会让 AI 做三类工作。
第一类是归档。比如把一次迭代里的测试、文档、路由、发布变更整理成一个紧凑摘要，方便后续回看。
第二类是对齐。比如检查某份总览文档、某个 checklist、某个作者说明，是否和当前代码结构已经明显脱节。
第三类是检索辅助。比如当我要回忆“为什么 payment 入口默认关闭”或“为什么某条 Cloudflare 构建链路必须单独跑”时，让 AI 帮我从现有材料里先拉出相关片段和上下文。
但我不会让它承担最后解释。也就是说，AI 可以帮我找材料、整理关系、提示不一致，但最后决定“这是不是当前有效判断”的仍然是我。因为知识库里最重要的不是文本本身，而是哪些内容现在仍然成立，哪些只是历史阶段的痕迹。这种有效性判断，不能偷懒外包。
如果没有人工兜底，AI 会把知识库做成一种更危险的幻觉
AI 在知识管理里最容易制造的错觉，是“它说得很顺，所以它一定已经理解了项目”。这其实非常危险。项目知识不是语言流畅度问题，而是边界是否准确的问题。一旦边界错了，语句越顺，误导性越强。
我踩过最典型的坑，就是让它总结一个阶段的工作时，它会自然把几个并行发生的改动组织成一条过于圆滑的叙事线，好像每一步都是提前计划好的、每个决定都互相一致。但真实项目不是这样运作的。真实情况往往包含回头修、临时补洞、先做再收口、甚至中途改主意。
如果不人工兜底，AI 就会把这种原本对判断很关键的摩擦抹平。最后知识库看起来更整洁了，但真正重要的项目现场感和决策条件被洗掉了。
所以我现在会刻意保留三种人工检查：
- 这条结论是不是仍然有效
- 这段总结有没有把阶段性方案说成长期原则
- 这次整理有没有抹掉返工、失败和限制条件
只要这三件事不检查，知识库就会慢慢滑向“看起来懂项目，实际上只会复述文本”的状态。
一套可用的项目知识库，核心是低维护而不是高智能
对独立开发者来说，知识系统最重要的不是炫技，而是低维护。因为你没有额外的知识运营角色。如果一套知识库需要你不断手工修饰格式、不断喂复杂 prompt、不断重新整理结构，它最终就会被你放弃。不是因为你不重视知识，而是因为这套系统已经比项目本身更需要被维护。
所以我更看重的标准非常朴素：
- 内容源是不是明确
- 结构是不是稳定
- 失真是不是容易被发现
- AI 介入后是不是降低了维护负担
- 下次我回来看项目时，是不是能更快恢复上下文
只要这些问题能被稳定回答，这套知识库就已经成立了。它不需要假装自己是全知问答机，也不需要把每个细节都实时嵌入进去。对真实工作来说，“可靠地帮助你找回上下文”比“偶尔给出一个很聪明的回答”重要得多。
我现在保留的判断
第一，知识库的第一任务不是回答更多问题，而是维持项目判断、约束和历史原因可被重新找到。
第二，AI 最适合做整理员、对齐员和检索辅助，不适合做项目真相的最终解释者。
第三，一套对独立开发者真正有用的知识系统，关键指标是低维护和高可信，而不是功能看起来多聪明。
所以我现在让 AI 参与项目知识库时，目标不再是“让它替我记住一切”，而是“让它帮助我以更低成本维持一套仍然可信的项目记忆系统”。这两者看起来只差一点，实际效果却完全不同。