太长不读：
这个制造业项目最值得学习的，不是用了什么模型，也不是选了哪一种向量数据库。
它真正做对的是：FDE 没有一上来就做聊天机器人，而是先进入新人培训现场，收集真实问题，梳理知识地图，把老师傅脑中的隐性经验变成组织知识，最后才用 RAG 把知识送到新人手里。
这条顺序，比任何技术选型都重要。
一、新人明明有培训材料，为什么还要天天追着老师傅问？
很多制造企业并不缺文档。
设备手册、操作规范、维修记录、培训课件、历史故障单，往往一个都不少。
但新人到了现场，还是会不断问：
-
• 这个报警代码到底是什么意思？ -
• 机器一直抖，应该先检查哪里？ -
• 手册里写了三种处理方法，当前型号该用哪一种？ -
• 这个现象算正常波动，还是必须停机？
问题不是“有没有资料”，而是新人很难在需要的那一刻，从大量资料里找到真正能解决问题的那一段。
更麻烦的是，现场最有价值的知识，常常根本不在文档里。
老师傅听一下声音，就知道可能是夹具松了；看一眼振动方式，就知道先别急着换零件；遇到某种材料，他会下意识调整参数。
这些经验长期存在于个人判断里。
新人只能靠跟班、观察和反复提问慢慢学。老师傅被相同问题不断打断，企业也很难把经验稳定复制给下一批人。
所以这个项目表面上像是“做一个 RAG 知识助手”，真正的问题其实是：
怎样把个人经验变成组织可以持续使用的知识，并在新人最需要的时候交付给他？
二、FDE 进场后，没有立刻开始做机器人
普通的软件项目很容易从功能清单开始：
text上传文档
→ 建向量库
→ 做聊天页面
→ 接一个大模型
几个星期以后，Demo 看起来很像样。
但真正的新人一问，系统就开始答非所问。因为项目团队知道怎么做 RAG，却不知道新人到底卡在哪里，也不知道老师傅判断问题时真正依赖什么。
这个案例里的 FDE 顺序不一样。
团队先进入现场，观察新人怎样学习、怎样找资料、在什么环节需要求助；再去收集高频问题，访谈老师傅，确认哪些问题可以由已有文档回答，哪些问题必须补充现场经验。
也就是说，他们先完成了三件事：
-
1. 找到新人最常遇到的真实问题； -
2. 找出已有资料覆盖不到的知识缺口； -
3. 搞清楚一个可靠答案需要哪些业务条件。
这就是 FDE 和普通交付团队很不一样的地方。
FDE 交付的起点不是“客户要什么功能”，而是“现场究竟发生了什么”。
三、先画知识地图，再谈向量数据库
当问题被收集起来以后，下一步不是马上生成 embedding，而是建立 Knowledge Map，也就是知识地图。
它要回答的不是“我们有多少份 PDF”，而是：
-
• 新人需要完成哪些任务？ -
• 每类任务需要掌握哪些知识？ -
• 哪些知识已经写在文档里？ -
• 哪些知识只在老师傅脑中？ -
• 哪些问题必须带上设备、型号、材料或工况才能回答？ -
• 哪些答案需要专家确认，不能让模型自由发挥？
把知识按业务任务组织起来以后，原来散落的材料才开始形成结构。
比如“设备振动”不能只是一段孤立文本，它可能需要同时关联：
text设备型号
+ 故障现象
+ 报警代码
+ 当前工况
+ 可能原因
+ 排查顺序
+ 安全边界
+ 适用版本
+ 确认专家
这时，知识库才不再是一个文件仓库，而开始变成可以服务业务判断的知识系统。
四、真正困难的，是把老师傅的“感觉”说清楚
隐性经验采集，往往是整个项目里最费力、也最有价值的部分。
老师傅可能会说：
“听声音就知道不对。”
这句话对老师傅有用，对新人和 AI 都没有用。
FDE 要继续追问：
-
• 什么样的声音？ -
• 通常发生在什么设备和工况？ -
• 你会先排除哪些原因？ -
• 第一步检查什么？第二步为什么不是直接换零件？ -
• 出现什么信号必须立即停机？ -
• 有没有容易误判的相似现象？
只有把这种经验拆成条件、判断、动作和边界，它才可能被复用。
所以，隐性知识进入系统之前，至少要经历一次结构化：
text现场经验
→ 追问适用条件
→ 拆解判断依据
→ 明确处理步骤
→ 补充风险边界
→ 专家确认
→ 进入知识库
这一步不是“让 AI 总结一段访谈录音”那么简单。
它本质上是知识工程，也是 FDE 必须和领域专家共同完成的业务工作。
五、RAG 的作用，是把正确知识送到正确位置
知识地图和知识内容准备好以后，RAG 才真正有用武之地。
新人不需要先知道文档名称，也不需要翻几十页手册。他可以直接描述现场问题，例如：
“M100 出现 E-203，而且设备一直抖，应该先看哪里？”
系统根据设备型号、报警代码和自然语言描述，召回相关知识片段，再组织成新人容易执行的回答。
更重要的是，这个能力没有被做成一个孤立的新工具，而是嵌入了企业原有的培训平台。
新人仍然在熟悉的入口里学习，只是从过去的“浏览课程”，升级成了“遇到问题就能问”。
这看起来只是产品形态上的小变化，实际上决定了系统会不会被真正使用。
很多 AI 项目失败，不是模型不够好，而是额外创造了一套业务人员不愿意打开的新系统。
最好的 AI 界面，往往不是一个新的聊天框，而是原有工作流程里恰到好处的一层能力。
六、95% 和 80%+，到底说明了什么？
公开案例披露的早期验收结果包括：
-
• 文档解析准确率约 95%； -
• 问题召回片段准确率达到 80% 以上。
这两个数字至少说明，团队没有只凭主观感觉说“效果不错”，而是设置了技术验收门槛。
更值得肯定的是，前期调研收集的高频问题，后来直接变成了测试问题。
这形成了一条非常好的链路：
text现场调研
→ 真实高频问题
→ RAG 测试集
→ 老师傅验收
→ 继续修正知识与检索
不过，我们也不能因为两个数字就把项目包装成“行业顶级 RAG”。
公开信息没有进一步说明：80%+ 是 Precision 还是 Recall、Top-K 取多少、测试集有多大、没有答案时系统是否会拒答，也没有完整披露知识版本、权限控制和自动化评测机制。
因此，更准确的判断应该是：
这个项目已经证明了业务方向和技术路线可以跑通，但距离完整的企业级知识系统，还有继续工程化的空间。
七、这个项目真正做得好的四件事
第一，问题来自真实现场。
不是先设计一个聊天机器人，再去寻找使用场景，而是从新人每天遇到的问题出发。
第二，同时处理显性知识与隐性知识。
文档只是起点。真正形成差异的，是把老师傅的判断方法也纳入知识体系。
第三，把业务调研变成了评测资产。
前期收集的问题没有在需求文档里沉睡，而是变成了后续验收 RAG 的真实测试集。
第四，把 AI 嵌回现有流程。
新人不需要改变工作习惯，老师傅也能参与答案验收，系统因此有机会形成持续反馈。
这四件事加起来，才构成了一个完整的 FDE 项目。
八、如果今天重新做一遍，我会再补上什么？
在现有路径上，我会继续补齐几项企业级能力：
-
• 用 Metadata、全文检索和向量检索做 Hybrid Retrieval； -
• 召回后增加 Reranker，提高最终片段精度； -
• 每个回答显示来源、页码、版本和责任人； -
• 对低置信度问题明确拒答或转交专家； -
• 建立知识审批、有效期和旧版本失效机制； -
• 持续扩充 Golden Dataset，自动回归测试； -
• 把新人反馈和专家修正重新沉淀成知识。
最终形成的闭环应该是：
text业务现场
→ 真实问题
→ 知识采集与治理
→ 检索与回答
→ 专家确认
→ 用户反馈
→ 知识继续更新
走到这一步，它才不只是一个问答机器人，而是一套会持续成长的企业知识系统。
九、FDE 真正交付的，不是 RAG
回过头看，这个项目最值得学习的地方，是 FDE 没有把“完成一个 RAG 应用”当作终点。
他们真正处理的是一条更长的链路：
text新人为什么学不会
→ 哪些知识没有被表达
→ 老师傅怎样做判断
→ 如何把经验组织起来
→ 怎样在工作现场随时获得
→ 如何证明系统确实找对了
RAG 只是其中的一段技术。
FDE 真正交付的，是从现场问题到业务结果的完整路径。
这也是企业 AI 落地最容易被忽略的一点：模型能力越来越便宜，真正稀缺的是有人愿意进入现场，把问题、知识、系统和使用者连起来。
下一篇，我们继续拆解：当企业真的要把 RAG 做成生产系统时，为什么只用向量检索往往不够，以及 PostgreSQL + pgvector 和 Elasticsearch 应该怎么选。
关注「MarvinTalk / 码文说」，一起研究 AI 如何真正进入企业交付现场。