养虾日记 1
最近闲着没事，正赶上鱼皮的openclaw 教程，把公司知识库的部分文档给扒下来了，于是想着折腾一个知识助手，提升工作效率（纯粹是懒得翻文档）。
目标其实不复杂，就是把现有的产品文档、项目资料、接口说明、实施经验收进一个本地知识库里，让它能回答实际业务问题。
这篇不聊概念，也不讲什么“大模型改变工作方式”。就老老实实复盘一下，这套东西从开始部署到现在，具体做了什么，踩了什么坑，哪些判断后来被推翻了，现在又走到了哪一步。
一、最开始先做的，不是知识库，而是执行底座
一开始我没有直接去做问答效果，而是先把执行环境和规则收了一遍。
原因很简单，底层不稳，后面知识导入、文档同步、问答脚本、群聊接入全都会变成一次性操作，没法持续迭代。尤其这套东西不是只跑一次，它后面还要反复更新、修、验证，所以执行底座必须先稳住。
这一步主要做了几件事： 把 OpenClaw 的本地执行链路调到可真正干活的状态 明确哪些动作默认主动执行，哪些高风险动作仍然要保守处理 把规则、安全边界、错误处理 SOP 写进工作区文件 建立“出错就复盘，复盘就落规则”的方式，避免同类坑重复踩 这部分看起来不显山不露水，但后面证明很值。因为很多后续问题，最后不是靠“再试一次”解决的，而是靠这一步提前打下来的约束和执行习惯兜住了。
二、知识源的第一轮处理，是先把内容真正落到本地
执行底座稳定之后，主线就转到了知识采集。
这套知识助手的核心知识源，主要来自几部分： 语雀上的产品资料 接口相关文档 产品相关资料 项目实施过程中的阶段文档和总结材料 这一阶段没有追求“问答很聪明”，而是先做两件事： 把文档抓下来 把结构理顺 当时已经完成了一批核心文档抽取，并建了独立的飞书知识空间，把首页、导航和若干正文节点先落了进去。
这里有一个很明确的取舍：没有把超大表格和超长原始数据直接硬塞进飞书正文。
像8k多条静态词条这种内容，如果直接塞进文档，写入风险高，可读性也差，后面维护更麻烦。所以那一轮更偏“先把知识入口、分类、导航和重点内容搭出来”，而不是追求一步到位。
到这里，知识助手第一次有了一个像样的知识底座。
三、飞书文档同步这件事，实际比想象中更脆
后面开始把需求文档、实施计划、任务清单这三份总文档和实际进展对齐。也是在这个阶段，踩到了一个很典型的问题：
飞书文档在局部替换时，存在新内容插入成功、旧内容删除失败的情况，结果就是内容重复。
这不是猜测，是实际踩出来的。表面上看像是更新成功了，回头一读，发现旧块还留着，整篇文档开始变脏。
这个问题带来的直接结论是：
飞书不能继续作为唯一真源。
后面的策略就改成了： 三份总文档先维护本地 .md 飞书里只保留稳定同步区 夜间定时把本地内容回填到飞书 白天不再以飞书为主直接改总文档 这一步是整个项目里一个比较关键的转折点。因为它把维护方式从“在线文档优先”切成了“本地真源优先”。后来回头看，这个决定基本是对的，不然后面同步次数越多，文档越容易被自己搞脏。
四、知识库开始从“资料集合”转成“问答底座”
文档抓下来之后，真正的问题才开始出现：
这些内容怎么被问答系统真正用起来？
这一步最后没有直接上复杂 RAG，也没有一开始就做重型向量方案，而是先走了一条更务实的路： SQLite 作为本地底座 FTS5 做全文检索 问答结构拆成几层： qa_history，存原始问答 qa_evidence，存回答证据 faq_entries，存可复用 FAQ synonym_map，做同义词归一化 这里有个原则，从一开始就定得比较死：
回答不是只求“像对的”，而是要尽量能追到依据。
所以后面针对业务问题，回答口径也收得很紧： 文档事实和我的推断必须分开 不能确认的地方直接标“待确认” 不靠猜测把口径补圆 到这一步，知识助手才算开始有了“助手”的样子，不然它最多只是一个文档仓库外面套个聊天壳。
五、接口文档全量采集，是这套系统第一次真正上强度
后面最实的一轮推进，是把产品手册做了全量采集。
当时确认到的目录规模是： 109 个 TOC 条目 其中 83 篇正文文档 26 个目录标题 后面通过复用现成登录态和脚本方式，完成了： 83 篇文档全量采集 0 失败 同时也补了一整套配套产物： 批次清单 执行报告 正文与表格产物 元数据 总目录清单 轻量索引 本地检索脚本 接入说明 这一步的意义，不是“数量更多了”，而是后面回答产品相关问题时，终于不用再手工翻几十篇文档了。可以直接走本地轻量索引和检索脚本，命中效率和稳定性都好很多。
六、真正有价值的，不是多答，而是纠偏
在把 EIP 文档接进来之后，开始用这套知识库回答实际业务问题。这时候一个比较明显的价值开始出现：
它不只是能找资料，还能纠偏。
比如 BeforeWIPFeedingCheck 这个点，前面一度误以为它可能只是 API023 的别名或者内部名称。后面根据新文档证据确认： BeforeWIPFeedingCheck 是独立接口 它用于开始投料前的预校验 API023 / WIPFeedingCheck 是正式入场校验 API024 / WIPInStationCheck 是进站校验，不是投料校验 这个纠偏过程挺关键。因为它说明这套东西不是单纯把旧认知包装得更像真理，而是开始具备了根据新证据修正旧口径的能力。
如果知识助手做不到这一点，它很容易变成一个更会胡说的搜索框。
七、能答还不够，后面卡住的是“太慢”
文档和问答链路都有了之后，下一阶段暴露出来的问题其实更现实：
回答太慢。
不是数据量已经大到跑不动，而是整个问答流程太重，深挖太多，读文档范围也偏大。尤其在群聊试点场景里，这种回答方式体验不太行。
所以后面又做了一轮提速改造。核心思路不是“再堆模型”，而是先把流程做轻。
主要改动包括： 把知识助手拆成两个角色： kb-ops 负责迁移和调优 kb-qa 负责问答 把 kb-qa 的默认策略改成： 先快答 答不稳再深挖 为 workspace-kb-qa 落地一套轻量提速链路： FAQ 快路径 路由后检索 快表 + 查询缓存 新增和改造了一批脚本： SQLite 优化 快答路由 快表重建 FAQ 优先 子集检索 缓存命中 当前的检索链路大致是：
query_cache → FAQ → 路由 → doc_fast_index → 接口专用检索 / 子集检索 → 全文 fallback
这一轮做完之后，问答风格明显变了。它从“研究型回答”开始转向“先给靠谱结论，再决定要不要深入”。
目前看，这个方向是对的。因为现在的瓶颈不是检索技术不够高级，而是问答流程太重。
八、为什么现在还没真正把它放进更多群里试用
做到这一步，系统本身其实已经具备试点基础了，所以后面开始探索群聊接入。
最先试的是飞书群接入。内部群路由已经验证过能跑通，也做过独立 kb-qa 工作区和群绑定。 但后面想往外部群走时，遇到了平台限制： 现有飞书机器人不能直接进外部群 要进外部群，需要外部共享能力、企业认证、管理员审核发布等前提 后面也顺手看了钉钉和 Telegram： 钉钉：当前环境里没有原生通道，能做，但要走定制接入 Telegram：通道扩展是现成有的，技术上更顺，但是否适合团队试点，取决于实际沟通场景 所以到现在，群聊接入这件事并不是做不到，而是进入了一个更现实的问题：
不是“能不能接”，而是“接到哪，才最符合真实使用场景”。
九、当前状态
到现在为止，这套知识助手大概走到了这个阶段。 已经完成的 本地执行底座和规则体系已经稳定 文档采集主链路已跑通 飞书知识空间和总文档同步机制已建立 本地真源 + 夜间同步方案已落地 SQLite + FTS5 的知识库底座已成型 API全量采集和轻量索引已完成 问答证据链和 FAQ 结构已落地 一轮“从能答到快答”的提速改造已完成 当前还在继续的 回答格式和出处规范继续收口 群聊试点入口还在选 还需要更多真实问题来打磨 FAQ 和路由策略
十、这次得到的几个结论
- 外部文档平台适合展示，不适合做唯一真源 这次飞书同步踩坑之后，这一点基本坐实了。文档平台更适合协作和展示，真源还是得放在可控的本地文件里。
- 当前这个阶段，轻量方案比重型方案更合适 文档量还没大到必须上复杂 RAG。 SQLite + FTS + FAQ + 路由 + 快表 + 缓存，这套组合目前性价比更高，也更容易调。
- 知识助手最怕的，不是答不上来，而是答错了还很像对的 所以证据、口径、待确认标记，比“看起来聪明”重要得多。
- 真正难的，不是导文档，而是把“同步、检索、问答、纠偏、试点”串成闭环 前面每一步单看都不复杂，难的是这些东西要能一起工作，而且每次迭代不能把前面的东西带坏。
十一、下一步
后面的重点不会再是继续堆文档，而是两件事： 用真实问题继续打磨 kb-qa 的回答质量和响应速度 选一个最适合试点的群聊入口，把这套东西真正放进使用场景里 如果只用一句话总结现在的进度，那就是：
这套知识助手已经过了“能不能做出来”的阶段，接下来真正要验证的是，它能不能在真实场景里稳定好用。
以上均由 openclaw 自主总结
