AI Coding 搞了一年,我才认准真正的护城河是知识库

AI Coding 时代最大的护城河，不是模型，不是 Agent，也不是工作流。

而是知识库。

这是我折腾了一整年 AI Coding，到最后才慢慢看明白的事。

可一开始，我和大多数人一样，劲儿全使在另一个地方——工作流。

怎么把写 PRD、出方案、写代码、生成测试串成一条链路，让 AI 一步步往下跑。

工作流跑通了，下一个问题马上冒出来——

AI 跑这些命令的时候，到底读什么？

光给它代码，不够。

于是所有人又一窝蜂去搞知识库。研发在搞，产品在搞，业务也在搞。

可搞着搞着我发现一件事：几乎没人能说清，知识库到底该是什么。

先说说，知识库不该是什么

很多人理解的知识库，是"把代码翻译成文字"。

我一开始也差点掉进这个坑。

可你冷静想想——我有上百万行代码，难道要一对一翻译成几十万行的文字描述？

这事既做不动，也没意义。 🤦

翻译出来的文字，本质还是代码的复述。AI 直接读代码就行了，何必脱裤子放屁。

还有一种，是把知识库做成"又一个文档库"。

这个更常见，也死得最惨。

文档写完那一刻就开始过时。

三个月后没人维护，半年后没人敢信，一年后躺在某个角落吃灰。

写文档的人前脚走，文档后脚就死了。

所以我想了很久：如果知识库不是代码的翻译、也不是堆文档，那它到底是什么？

代码本身，到底缺什么

要回答知识库是什么，得先搞清楚——代码本身缺什么。

我后来总结出三个点：

一是只有现状，没有意图。

你读代码，能知道接口长啥样、表结构是什么、调用链怎么走。

但你看不出：这个字段为什么这么设计？这个 if 是哪次线上事故留下的补丁？这条规则到底是正经逻辑还是临时将就？

代码只告诉你"是什么"，从不告诉你"为什么"。

二是单个服务看不到全局。

一条业务，往往横跨好几个系统、好几个服务。

你盯着一个 repo 看，只能看见局部。端到端的链路、系统之间的断层，全是盲区。

三是关键知识，根本不在代码里。

它在老员工的脑子里，在某条 commit message 里，在一次拉群对齐的聊天记录里。

老司机一走，这些东西就跟着蒸发了。

想清楚这三个洞，知识库是什么就有答案了——

知识库要装的，恰恰是代码自己补不出来的那部分。

那它到底该装什么？我把知识库定义成四类知识

绕了这么久，我给我们的知识库下了一个定义：

它是一张面向 AI Agent 和人类工程师共同消费的知识网络，同时覆盖代码和业务两个维度。

它的活儿，就是把"代码原文"加工成"AI 和人都能拿来推理的知识"。

而这张网，我把它拆成了四类知识。

这四类，是我想了最久、也最得意的一块——因为只有把"知识"按性质切开，AI 才知道哪些能信、哪些只能参考。

第一类，事实（Facts）。

代码扫出来的客观事实：接口签名、表结构、调用关系、MQ 事件，再加上测试平台沉淀的基线用例。

全是机器能验证的硬事实，零脑补。 表里有没有这个字段，一扫便知，不需要 AI 猜。

第二类，知识（Knowledge）。

这是代码看不出来的那部分业务理解：某条业务规则为什么这么定、这个接口有什么坑、历史上做过哪些关键决策。

Facts 回答"是什么"，Knowledge 回答"为什么"。 这一类，恰恰是最值钱、也最容易丢的。

第三类，模式（Patterns）。

跨服务、跨技术域的全部规范——团队的组织级共识。

它又分五小类：语言规范（Java/Go/PHP/Python/JS 各自的编码约定）、通用规范（数据库、错误处理、日志、API 兼容性）、中间件规范（Redis、MQ、RPC、分布式锁、定时任务）、测试规范、平台规范（前端/移动/桌面的工程化约定）。

有了它，AI 写出来的代码才不会十个人十个样。

第四类，视图（Views）。

它不原创内容，而是把前三类重新聚合，切出不同视角的切片。最主要的是两个维度：

一个是业务域维度——按"寄卖、回收、交易"这些业务域，把散在好几个服务里的相关规则、流程、实体归并到一处，回答"这条业务到底怎么跑"。

一个是业务系统维度——按一个完整的业务系统（比如供应链、售后），梳理它由哪些服务组成、系统内的业务怎么串起来，回答"这个系统到底怎么搭"。

一个顺着业务看，一个顺着系统看。两个维度叠在一起，AI 才能一眼看到全局，不用自己满世界拼图。

事实、知识、模式、视图。 这四类合在一起，才是我心里那张完整的知识网络。

这四类知识，分别从哪来？

定义清楚了，更难的问题是：面对一个跑了好几年的老项目，这四类知识怎么生产出来？

我的总原则是：别想着"写一份文档"，要想着"修一条知识生产线"。

文档是死的，生产线是活的。下面一类一类说。

事实（Facts）：靠扫，不靠写。

我们做了一个专门的「项目扫描」skill，自动扫单个服务的代码，把接口、表结构、调用关系一股脑扒出来。

但这里有个坑：不同语言的代码结构差太远了。 Java 的 Controller、Go 的 handler、前端的路由，长得完全不一样。

所以我为每种语言单独设计了扫描模板——保证不管什么语言，扫出来的事实都落到统一的格式里。

再叠上从测试平台同步过来的基线用例，事实层就齐了。

系统拓扑：靠「系统扫描」把孤岛连成片。

单个服务扫完，还是一座座孤岛。

于是又有一个「系统扫描」命令，专门读 K8S 的部署配置——域名怎么挂、服务怎么暴露、谁依赖谁，把孤立的服务还原成"域名 → 前端 → API → 后端"的完整系统拓扑。

这一步，补的就是"单服务看不到全局"那个点。

知识（Knowledge）：靠人补，靠纠错喂。

业务理解，机器扫不出来，只能靠两条人工通路。

一是主动补全：把那些"不成文的规矩"手写进去。

二是纠错反哺：开发过程中 AI 哪里理解错了、哪个字段会错意了，让 AI Agent 在运行过程中随时记录，需求上线后再统一沉淀回知识库。

下次它就不会在同一个坑里栽第二次。

模式（Patterns）：靠团队一条条沉淀。

五大类规范，主要是把团队历史的规范和现有项目的使用现状，让 AI 汇总整理而来。未来还需要持续维护与优化。

视图（Views）：靠聚合，不靠重写。

它不产生新内容，只是把前三类按业务域、系统重新组织一遍。前三类越扎实，视图就越有用。

你看，四类知识、四种来路：能扫的就扫，扫不动的靠人补，跨域的靠规范，全局的靠聚合。

扫出来的知识，只有八成可信

这里得先说句大实话：机器扫出来的东西，并不是百分百准的。

我自己估了下，扫描产出的知识，置信度大概在 80% 左右。

剩下那两成，可能是 AI 推断错了，可能是它顺着代码瞎猜的，也可能几个来源本身就对不上。

那问题就来了——这些有真有假的知识，混在一起怎么用才不出事？

我的办法是：给每一条知识，都标上可信度。

为什么这一步这么关键？

因为如果你把"确定的事实"和"AI 的猜测"混在一起喂给它，它生成的方案、测试、校验里，就会混进一堆不可验证的脑补。

而你根本分不清哪句是真的，哪句是它编的。 😨

所以每一条知识，我都要求它带着证据来——是哪行代码、哪条 commit、哪个用例支撑的。

回溯不到证据的，就不配进知识库。

然后按可信度分成三档：

• 确定——直接来自代码，或多个来源交叉验证一致
• 推断——只有单一来源，或带点猜的成分，必须标上"待确认"
• 冲突——多个来源对不上

分完档，神奇的事情发生了：不同环节可以按不同规则去吃这些知识。

出技术方案，只吃确定的——绝不让方案建在猜测上。

做测试设计，专挑冲突的——因为多个来源对不上的地方，往往就是系统最脆弱、最该测的地方。

写新 PRD，先看现状边界——免得需求一上来就跟现有能力打架。

冲突信息不但不该被藏起来，反而是最值钱的风险入口。

而且不管是冲突，还是那些拿不准的推断，AI 都不会默默吞掉——

出方案时一旦撞上，它会在技术方案里标一个"待人工确认"，或者直接跳出来提示你去纠正，把判断权交回给人。

人拍完板，这条结论又顺着反哺重新沉淀回去，下次就不必再纠结第二遍。

让它活起来：扫描、消费、反哺三个循环

知识库最怕的，是变成一潭死水。

要让它活，得靠三个循环转起来：

第一个，扫描循环。 代码一变，「项目扫描」「系统扫描」就把事实层刷新一遍。这是上行——代码流向知识。

第二个，消费循环。 AI 跑工作流时，从知识库里取它要的那部分知识，去出方案、写代码、生成用例。

第三个，反哺循环。 这是最关键、也最容易缺的一环——AI 用错了、人纠正了，这些纠错不能停在聊天记录里，得回写进知识库。这是下行——经验流回知识。

扫描是上行，反哺是下行。一上一下，闭环才转得起来。

只有上行没有下行，它就是个会过时的快照仓库——和那些吃灰的文档库，没区别。

每出一次方案、每写一批用例、每完成一个需求，知识库都该比昨天更厚一点、更准一点。

说个真事。

这套东西刚推给团队那会儿，其实没人爱用。

问题一大堆：扫得不准、规则缺失、AI 时不时跑偏，同学们用得直皱眉。

我没惯着，硬逼着大家用，每天站在大家后面问，“用了没？”“用了没？”。

可在逼的过程里，事情悄悄变了——

每用一次，就纠一批错、补一点知识、磨一回命令。

用得越多的模块，知识攒得越厚，AI 跑出来的效果就越好。

效果一好，不用我催，大家自己就用上了。哪个模块顺手，口碑立马传开。

这就是反哺飞轮转起来的样子：不是先做到完美再推广，而是在用的过程里，一点点变好。

它不只是研发的，是产研全流程的"智识库"

聊到这你可能以为，这是个给程序员用的东西。

不是。

我给我们这套知识库的定位，是覆盖整个产研流程的"智识库"——从"知识"到"智识"，差的就是它能不能真正参与判断。

它不光用来生成代码。

它还用来检测 PRD——拿系统现状去校验产品需求，提前揪出"需求跟现状打架"的地方。

它还用来设计测试、生成用例——复用历史的回归资产，而不是每次从零写。

它甚至能用来指导 UI 和产品决策。

第一消费者是 AI Agent，但人也能直接读。

这是它和传统文档最大的不同：文档是写给人看的，这套东西是 AI 和人一起消费的。

现在它还太单薄，但我更怕它将来太吵

说句实在话，这套知识库，现在还远远不够。

很多服务扫得浅，很多业务规则没补上，纠错也才刚跑起来。

但"不够"这件事，我不太担心。

只要扫描在跑、反哺在转，知识就会一天天多起来——这只是时间问题。

我真正担心的，是另一头：

知识越堆越多，AI 的噪音也会越来越多。

前面我说过，知识库不需要做到百分百准。

这话现在成立。可量变早晚会引起质变。

等库里塞进几万条、几十万条知识，哪怕只有一小撮是过时的、错的、互相打架的，AI 一读到，生成的东西就跟着跑偏。

知识越多，噪音的绝对量越大，早晚有一天会拖垮使用的质量。

到那时候，光靠"往里加"就不够了，得反过来做减法——给知识库去噪。

把过时的清掉，错的纠正，冗余的合并，矛盾的裁决。

我大概能想到未来的样子：

知识不够 → 拼命积累 → 越堆越多 → 噪音变多 → 回头去噪 → 接着再积累……

这是一个会一直转下去的循环。

说不定再往后，我们大半的精力都会耗在这上面——不是怎么把知识喂进去，而是怎么让这一大堆知识，始终保持干净、可信、好用。

这一天还没到。但我知道，它一定会来。

为什么我愿意在这件事上死磕

说实话，建这套东西很累，维护更累。

但我越来越确信它值得。

因为 AI 时代，有几样东西正在飞快地变得不值钱：

模型会同质化——大家都用最强的那几个。

工具会标准化——协议一统一，谁都能接。

工作流会被复制——我搭的命令，别人抄一遍也能用。

那到最后，什么是抄不走的？

是这套深度绑定你自己业务的、活着的知识库。

它装着只属于你们团队的那些"为什么"，是你们一砖一瓦、一次次纠错喂出来的。

就像数据是机器学习时代的护城河，知识库就是 AI Coding 时代的护城河。

谁先把它建好、让它活起来、让它自己越长越壮，谁就在这个时代拿到了结构性的优势。

工作流是手脚，知识库才是灵魂。