一家华南地区的工业设备制造商, 产品在客户现场运行, 技术服务部门负责故障响应。

二十余年积累下来的处理经验存在于三个地方: 工单系统里的处理记录、工程师之间的邮件与群聊、以及几位资深工程师的记忆。前两者数量巨大但检索困难, 第三者面临明确的退休时间表。

他们此前尝试过接入一个通用问答工具, 结果被放弃——★ 因为它会把十年前已经废止的处理方案和上个月的新方案同等地讲出来, 且语气同样确定。

一、无法判断材料是否仍然有效。 设备迭代过好几代, 早期的处理方案对新机型不仅无效, 有些是有害的。而工单记录里没有"这条已经不适用了"这样的标记。

二、矛盾被抹平。 同一故障现象在不同年份有不同结论。通用问答会把它们合成一个自洽的回答, 而这个回答可能两边都不对。

三、无法追溯就无法采信。 技术服务的处理建议要发给客户, 出问题要担责。一个说不出依据的建议, 工程师不敢用。

核心是知识资产项目里的状态层——这正是它与普通检索系统的区别。

第一步: 按机型与年代切分。 把工单与文档按设备型号、软硬件版本、时间段结构化, 使"适用范围"成为可过滤的字段而非正文里的一句话。

第二步: 标注状态。 每个知识单元标为有效 / 已被取代 (指向取代它的单元) / 存疑 / 已归档。★ 这一步由资深工程师完成, 无法自动化——判断一条经验是否仍然作数, 需要的正是那些即将退休的人所拥有的东西。这也是项目最紧迫的部分。

第三步: 强制引用。 回答必须绑定原始片段; 找不到支撑就明说"知识层中没有依据", 不用通用知识补足。

第四步: 冲突并列。 检索到互相矛盾的材料时并列呈现并标注冲突, 由工程师裁决, 系统不做调和。

回答变短了, 也变得可用了。 强制引用之后, 回答不再流畅完整, 而是若干条带出处的片段加一句判断。技术服务部门起初不适应, 一个月后反馈说这才是他们能拿去用的形态——★ 因为可以直接把依据一并转给客户。

"没有依据"成了有价值的回答。 此前工具总能给出些什么, 于是无法区分"确实有经验"与"编了一个像样的说法"。现在明确说没有依据的情况占相当比例, 而这恰恰指出了知识的真实缺口。

退休倒计时变成了可执行的任务。 状态标注把"把老工程师的经验留下来"这件模糊的事, 变成了一份有限的、可分配、可验收的清单。

一个持续的挑战: 状态需要人维护, 而维护没有即时回报。我们与他们一起把复查排进了季度例行工作, 但这一条能否长期守住, 现在还不能下结论。