记得上篇文章说过吗？

> “GUI抓取解决了’功能在哪’的问题，但知识库标准化才是根本解。”

当时写这句话的时候，我心里其实还没完全想清楚。直到后来被一件事彻底点醒——

我发现知识库里56.88%的召回内容，都是重复的。

一、GUI抓完之后，我以为问题解决了

GUI抓取上线之后，服装品类的功能覆盖终于有了着落。

数据也给我吃了颗定心丸：用户粘度从40.72%提升到66%，Goodcase从43提升到56。

我当时真的松了口气。

甚至在一次周会上，我还挺有信心地说：”功能入口的问题基本解决了，接下来把剩下的品类补充完，知识库这块就算告一段落了。”

结果话音刚落，我打开了召回来抽检——

然后愣住了。

56.88%。

召回来的内容里，超过一半存在重复信息。

同一个功能的描述，这个文档有一份，那个文档也有一份，内容还略有出入。AI读完这一堆重复的东西，理解偏差一下子就出来了。

我盯着这个数字愣了很久。

功能入口的问题解决了，但知识本身的质量问题才刚刚露出水面。

二、那个让我彻底清醒的会议

那是一次讨论知识库方向的周会。

我提出：”我们是不是应该做一套标准化的知识结构？按字段、按维度去组织知识，这样运营起来也有规律可循。”

话音刚落，研发同学就开口了：

“标准化这事，对AI来说完全没必要。”

他说得很直接：

“标不标准，切chunk做RAG的时候都会整理成适合AI理解的内容。长文本可以，结构化字段也可以——技术上没有区别。”

我还没来得及回应，运营同学也说话了：

“我也不太明白，AI怎么实现的。但你告诉我缺什么、哪里不对，我去补充就好了。”

两边说得都没错。

但这两边合在一起，问题就来了。

三、问题就在这个”补”字上

研发说”缺知识”，但他说不清楚缺什么知识，只给你一个case。

“这个query回答不对，补一个QA吧。”

运营说”我去补”，但他不知道怎样才能尽量完善，只知道按case来补。

这个case补了，好了。过两天，新的case来了——”这个query也不对，再补一个QA。”

再过几天，更新的case来了，继续补。

周而复始。

我开始觉得不对。

每补一个QA，我能解决当前这一个case。但这个case背后，有没有更深的问题？我不知道。

运营同学也不知道。他只知道有人告诉他哪不对，他就去补哪。

研发同学也不关心这个。他的KPI是模型效果，模型需要的输入”能理解”就够了，至于这个输入是怎么来的、怎么维护的——不在他的职责范围内。

三个角色，都在做眼前对的事。

研发觉得无所谓，运营觉得被动补就行，我夹在中间，不停地收到badcase，不停地打补丁。

直到有一天，我发现——

QA库里的内容越来越多了，但AI的回答效果，反而越来越差了。

四、那堆QA，到底烂成了什么样

说一个具体的。

有一次，我发现两个QA说的是同一件事，但内容表述完全相反。

QA1：”订单取消后，优惠券自动退回。”

QA2：”订单取消后，优惠券不退回。”

我不知道哪个是对的，也没人知道。

因为这两个QA是两批运营同学在两个不同的时间点写的，写的时候谁也没查重、谁也没比对。

类似的情况越来越多：重复的QA、冲突的QA、过期的QA（业务规则变了，但旧QA没人删）……

每一批QA补进去的时候都解决了眼前的问题，但整体上，它们正在慢慢地把知识库变成一座废墟。

这就是”局部最优、全局负优化”最典型的例子。

每个人都在做对自己有利的事，整体却在一点一点崩坏。

五、那一刻，我彻底想通了

我一直被研发的说法动摇过：”AI能理解，无所谓标准不标准。”

但那次开完会，我回到家想了很久，突然想通了一件事：

“能理解”≠”能维护”。

一个人写知识，可以写得清楚。

但一个团队长期运营知识库，没有结构、没有规范、没有标准——

写着写着，就乱了。

运营同学补QA，是被动响应。研发同学说”无所谓”，是只看眼前。

只有PM，得看全局。

PM得问一个问题：如果不标准化，这套知识体系能长期运营下去吗？

答案显然是不能。

六、我的标准化方案：6个字段

想清楚之后，我开始设计标准化方案。

核心思路是：给每个知识点，定义一套固定的字段结构。

不是丢一篇文档进去，而是按维度去组织知识：

字段	说明
功能名称	这个功能叫什么
功能介绍	这个功能是干什么的
功能服务范围	这个功能在哪些场景下能用
功能解决问题点	用户用这个功能能解决什么问题
功能操作指南	怎么操作
功能常见问题	高频疑问有哪些

六个字段，每个功能都按这个结构来填充。

这个结构有什么用？

有了这个结构，badcase出现的时候，我能精准定位：

·是”服务范围”字段过时了？

·还是”解决问题点”字段缺失了？

·还是”操作指南”写错了？

问题锁定，从模糊变得透明。

如果所有字段都填得完整、准确，但badcase还是出现——

那问题就不在知识，在模型的总结能力上。

分层诊断，这才是标准化的真正价值。

七、补丁方式 vs 体系化方式

回过头来想，为什么我一直觉得补QA不对劲，但说不清楚哪里不对？

因为我一直在用”补丁思维”解决问题。

补丁思维的特点是：眼前的问题能解决，但长远的问题无法预防。

补一个QA，眼前好了。新的case来了，继续补。

知识库越来越厚，重复的、冲突的、过期的越积越多。

补丁打得越努力，洞冒出来得越快。

体系化思维的特点是：先把结构搭好，让问题能被发现、能被定位、能有追踪机制。

按标准字段组织知识，定期review字段完整性，主动补缺失的字段。

长期可持续，可维护，可迭代。

八、AI越来越强，标准化还有必要吗？

可能有人会问：”如果AI能自己理解功能平台，自己判断知识是否准确——标准化还是必须的吗？”

这个问题我想过。

如果AI真的能自己做到：准确理解业务、准确判断知识质量、自动发现并修复错误——

那标准化确实不是必须的。

但短期来看，AI做不到这个程度。

至少目前，AI还是需要结构清晰的知识输入，才能发挥好的效果。

所以标准化这件事，不是AI够不够聪明的问题，而是——

运营能不能可持续的问题。

写在最后

写这篇文章，我想了很久。

最想说的那句话是什么？

不是”标准化很重要”，那太像方法论了。

是这句话：

做AI产品经理之后，我学会了一件重要的事：不要只看局部最优，要看体系化最优。

每个人都在做眼前对的事，整体却在恶化——这种情况太常见了。

研发说无所谓，运营说被动补，PM夹在中间不停地打补丁。

这时候，需要有人站出来说一句：我们需要一个更好的结构。

推动这件事很难。需要和各方的沟通，需要面对质疑，需要时间。

但只有这件事，才能让知识体系真正可持续。

补丁能走多远？

补丁只是治标，标准化才是治本。

──────────────────────────────

下期预告：

补了那么多QA，为什么效果反而越来越差？

下一篇文章，我们聊：无限补QA的陷阱——每个角色都在做眼前对的事，整体却在恶化。

欢迎评论区聊聊你做AI知识库时遇到的坑。

关注我，一起见证一个AI产品经理的成长。