Codex 实战，从一堆企业文档，到一个真正可用的知识库

我最近在本地搭一套企业知识库。

刚开始的时候，想法非常直接。把企业里的制度、产品资料、操作手册和常见问题放进去，再接一个问答入口，不就可以了吗？

真跑起来以后，我很快发现事情没这么简单。

同一个业务问题，旧文档和新文档可能给出两个答案。一个文件写着流程已经调整，另一个文件还保留着几年前的操作。文件名看起来像定稿版，打开以后里面还有待确认。检索确实找到了内容，但它找到的究竟是知识，还是一段已经失效的文字？

这一下把问题拉回了我熟悉的系统思维。

知识库不是一个会搜索的文件夹，它也是一个有状态、有版本、有责任边界的系统。

我开始让 Codex 做的第一件事，不是接模型，而是整理资料。扫描目录，识别文件类型，抽取标题和更新时间，把重复文件、疑似旧版和无法解析的内容单独列出来。这个阶段很笨，甚至有点慢，但它决定了后面的回答有没有资格被相信。

随后，我给每份资料补上几个字段，来源、所属业务、版本、更新时间、负责人和当前状态。字段不一定要一次设计得很漂亮，关键是让系统能区分正在生效的事实和仅供参考的历史记录。

企业知识库最难的不是让答案出现，而是让答案带着证据出现。

资料整理好以后，才轮到切分和检索。

很多方案会按固定字数切文档。我自己更倾向于先看业务结构。一个审批条件、一套退款规则、一个产品参数表，应该尽量保持完整。因为用户问的不是第 1260 到 1840 个字符，而是这件事现在到底怎么办。

Codex 在这里比较适合扮演工作台里的工程搭档。它可以根据文档结构生成清洗脚本，检查缺失字段，整理测试问题，再把失败案例记录下来。遇到冲突资料时，它不替企业做决定，而是把冲突和来源摆出来，等真正负责这项业务的人确认。

这也是 FDE AI 实战和普通演示最大的差别。

演示里，我们只需要问出一个漂亮答案。到了企业现场，大家真正关心的是，答案错了怎么办，资料更新后多久能生效，谁能看到哪些内容，系统为什么引用了这份文件。

所以我会提前准备一组问题，有正常问题，也有故意刁钻的问题。问一个文档中明确写过的事实，问一个跨两份资料才能回答的问题，再问一个资料里根本没有答案的问题。前两个要给出来源，第三个必须承认不知道。

如果系统什么都敢回答，我反而不敢用。

顺着这个思路，知识库还需要一条更新链路。新文件进入以后，先判断它替代了谁，再重新建立索引，跑一遍关键问题，并留下更新时间和测试结果。旧知识不是简单删除，而是保留历史身份，同时从当前答案里降权或退出。

坦率的讲，这套东西我还没有完全跑通。文档质量、权限设计和持续维护，每一块都比做一个问答页面麻烦。但也正因为这样，我越来越确定，企业知识库的价值不在于它能回答多少问题。

它真正要解决的是，企业散落在文件、人和系统里的经验，怎样变成可以追溯、可以更新、也可以被下一次工作安全调用的知识。

Codex 在其中不是一个自动回答所有问题的神奇大脑。

它更像一个愿意陪你整理仓库、编写工具、补齐测试，并且把每一次失败留下来的工程搭档。