Hedy 复盘·工作版要点 —— 企业 AI 知识库从 demo 到真正用起来

← 返回目录

原文：Hedy Zhang（@xiaomanhedy，一线 FDE）《一线 FDE 深度复盘：企业 AI 知识库，从 demo 到真正用起来》，2026-10-22，https://x.com/xiaomanhedy/status/2113174733344673956 提炼：小沐 2026-10-23。工作版，面向企业内部 AI 平台 / 知识库类项目的立项、评审与交付；原案例细节从略，判断与流程按原文。

案例一句话

2023 年一家制造业企业的知识库项目：研发天天被客服（不懂产品）、销售（记不住型号）、售后（解决不了问题）打断，外加新人培训成本。外部团队建了 3 个月、维护 3 个月；公司里有网管、没人管知识，团队撤场后系统停摆，直到 2024 年有人接手管知识、翻新后才复活。

核心论点

知识库死于交付后无人运营，不死于检索技术。 Demo 的价值只是让客户看见可能性；把可能性变成日常价值，靠的是后面大量具体工作——谁收集更新、谁确认内容、谁处理反馈、谁推动按时完成。这四件事没人认领，回答一句”以后看情况”，持续运营就落不了地。

立项前必谈：八步链路

真实问题 → 小范围验证 → 资料核对 → 查询设计 → 业务验收 → 人工接管 → 知识更新 → 持续运营。

接单前把这八步逐项谈清：每步要做什么、由谁负责，再开始建设。重点在最后两步——多数项目死在这里，却最少在立项时被谈及。

答错时的排查顺序：先验源头

案例里验收发现认证信息答错，追下去是原始 PDF 本身标错、缺标——这种错调提示词解决不了。顺序应该是：

1. 先查源资料本身（内容错、版本旧、导入时图表/型号参数对应关系丢失）；
2. 请懂业务的人确认正确内容，修源资料、重新入库；
3. 再回头怀疑检索与提示词。

配套的事先约定：每类重要知识都要有确认人，另设一个 owner 推动修改、更新与复测；冲突出现时找谁裁定，也要在立项时说清。

人工答过的问题：五步回流

人工接管答过的问题不能留在聊天记录里，按五步沉淀给下一个人用：

1. 记录没答好的问题、提问和原回答；
2. 请懂业务的人确认正确答案及适用条件；
3. 审核内容是否进入正式知识库；
4. 更新资料，并处理与旧内容的冲突；
5. 用原问题复测，确认系统能正确回答。

注意：聊天里的随口回答不能直接变成正式知识——要剥离一次性的客户语境，否则一句话会误导后来的人。

范围与报价：四件事分开算

• 初次建设：哪些资料入库、怎么组织、支持哪些问题；
• 软件维护：出故障找谁、支持多久、修复范围多大；
• 知识运营：新资料、旧版本、答错、用户反馈分别归谁处理；
• 新增需求：新部门、新场景、新系统对接，如何重新评估。

先算真实工作量，再谈范围；客户现有方案够用就不要硬卖；签约前没算进去的持续工作，不能留到上线后靠加班兜底。

验收要点（业务口径，不是技术口径）

• 答案正确性、关键条件有没有漏、依据能不能溯源；
• 等待时间是否适配岗位——案例里换模型后部分答案变好，但延迟从约 10 秒涨到 40–50 秒，客服场景直接没法用；
• 员工看完还要自己核对多少；答不好时，下一步找谁；
• 业务专家必须参加验收：研发不信内容，客服就会回去问研发，系统等于白建。

落地次序

先内部、后对外：员工提问 → 系统给答案加依据 → 员工核对 → 无法确认时转业务专家。查询设计先分清问题类型：查单个型号参数，和筛出全部符合条件的型号，是两种活——后者要的是完备性，案例里靠结构化表格加数据库查询解决，纯检索保证不了不漏。

评审时的一句收尾问题

“这套系统交付以后，公司里谁来让里面的知识一直可用？” ——方案评审结束前问这一句，答不上来的方案，技术再漂亮也先别过。