【轨物方案】老师傅退休之后，制造企业真正失去的不是一个人，而是一套判断系统

在很多制造企业，最难被替代的员工，往往不是最会操作软件的人，而是那个遇到异常时能迅速判断“问题出在哪里”的老师傅。

一台设备为什么这样选型？某类结构为什么要预留额外工艺余量？客户要求看似相同，为什么这一次报价不能沿用上一次的成本口径？某个参数落在标准边界附近时，究竟应该按常规方案处理，还是必须让技术负责人复核？

这些问题通常没有完整写进制度。它们藏在一次次报价、设计、工艺调整、质量返工和客户沟通里，靠长期积累形成判断。企业日常运转时，这种能力看起来理所当然；等到关键人员离职、退休、调岗，或者业务突然增加时，企业才发现：真正难以交接的，从来不是文件，而是文件背后的判断。

企业通常并不缺资料。图纸在技术部，物料价格在采购系统，工时记录在车间，历史报价在商务台账，质量问题在检验记录，客户特殊要求可能还留在邮件或个人聊天里。文件数量越来越多，系统也越来越完善，但关键问题依然难以回答。

原因在于，资料记录的是“发生过什么”，经验还需要解释“为什么这么做”。

历史报价单可以告诉新人某个型号过去报过多少钱，却未必说明当时采用了什么材料价格、工时假设、风险余量和付款条件。图纸可以表达结构尺寸，却未必解释某类结构在特定工况下为什么需要额外处理。质量报告记录了返工结果，却未必把返工原因转化成下一次设计或报价时可以使用的规则。

当企业只保存文件，却没有把判断逻辑整理出来，知识就处于一种尴尬状态：对熟悉业务的老员工而言，它很有价值；对新人、跨部门协作和 AI 系统而言，它却难以直接使用。

老师傅通常不是不愿意传经验，而是很多经验已经变成了下意识动作。他可能只说“这个不能这么报”“这类结构要留点余量”“这个客户要谨慎”，却很难在没有具体情境时，把背后的条件、例外和判断边界一次讲清楚。

这意味着，经验传承不能简单等同于录音、写文档或把聊天记录放进知识库。有效的经验萃取至少要追问四件事：当时面对什么情境？依据哪些信息作出判断？哪些条件触发了这个判断？遇到什么情况时，这条经验不再适用？

例如，“某类结构要增加工艺余量”不是一条完整规则。还需要明确适用的产品范围、尺寸或工况条件、余量依据、例外情况，以及需要由谁确认。否则，经验被数字化后仍可能只是另一段模糊描述，甚至因为被错误套用而制造新风险。

因此，企业真正要沉淀的，不是老师傅说过的所有话，而是经过核实、能够追溯来源、明确适用边界，并且可以在真实业务中被调用的判断。

轨物科技的 T-HUB 老师傅经验库，围绕三个环节开展工作。

第一，连接已有资料，而不是要求员工从头重建一套资料。企业原有的 ERP、PLM、MES、CAD、报价台账、图纸库和共享盘，仍然承担各自的业务职责。T-HUB 的设计方向是在现有权限范围内只读接入，不改动原系统，不把经验沉淀变成一场推倒重来的 IT 工程。

第二，让分散资料能够围绕同一业务对象建立关联。以产品型号、订单号或工程编码等业务主键为线索，尝试把图纸参数、材料价格、工时、历史成交价和质量记录关联起来。这样，业务人员不只是在搜索“某份文件”，而是有机会进一步分析“这个型号为什么这样报价”“不同订单的成本差异来自哪里”。

第三，通过访谈和业务复盘，把老师傅的判断整理成可查询、可审核、可持续更新的规则。规则应保留来源和适用条件；对存在争议、信息不足或超出规则边界的情况，应交给相应人员复核，而不是让 AI 自行作出没有依据的决定。

这三件事共同指向一个目标：让知识不仅能够被找到，还能够被理解、核对和用于业务。

这是经验资产化必须面对的边界。老师傅的判断来自长期实践，但实践经验也可能过时，可能受到当时供应商、设备、标准、工艺路线和客户条件的限制。把经验保存下来，不意味着每条经验都应该永久有效。

因此，经验库必须回答：这条规则来自哪里？由谁确认？适用于哪些产品和条件？何时复核？如果新标准、新材料或新工艺改变了原来的判断，谁负责更新？

同样，AI 给出的答案也不应取代业务签认。对于报价、设计、质量和合规等关键环节，系统更适合把相关资料、历史依据、规则和差异集中呈现，让人更快作出有依据的判断。最终责任仍应由企业明确的岗位承担。

真正成熟的经验库，不是把某个人的意见神化，而是让经验能够被核查、讨论、修订和传承。

经验库项目容易陷入两个极端：一种是追求“大而全”，试图一次性整理所有系统和所有资料；另一种是只搭建一个检索界面，导入一批文件后便认为项目完成。前者成本高、周期长，后者则很容易变成无人使用的空壳。

更务实的方式，是从一个高频、可验证、损失清晰的业务场景开始，例如报价核对、历史方案复用或标书条款查证。先盘点资料分布和口径差异，再选择少量真实业务问题，整理第一批经验规则，并与人工处理结果对照。只有当业务人员愿意使用、能够核查结果、企业内部有人接手维护，才有理由逐步扩展。

建设结果也应有明确标准：已有资料是否在不改动原系统的前提下被接入；关键关联口径是否经过业务人员确认；第一批经验是否在真实业务中被调用；企业人员是否能够独立维护至少一个场景。这些标准比“录入了多少份文档”更能说明项目是否有用。

老师傅退休是一个时间节点，经验流失却是长期管理问题。企业不可能阻止人员流动，也不应把所有能力都寄托在少数个人身上。可以做的是趁经验还在、业务仍在运行时，把关键判断问清楚、核实好、留下来源和边界，再让它进入企业日常工作。

T-HUB 所要解决的，不是让机器取代老师傅，而是让老师傅多年形成的判断，不再随着某个人离开岗位而从企业的工作流程中消失。