数字员工上线两个月，抱怨一定会来：识别不准、答数不对、这个功能不好用。抱怨本身不可怕——可怕的是所有抱怨都往一个筐里装："AI 不行"。装着装着，老板的信心装没了，项目的信任装没了。
一家服装厂十月底开了一场特别的对齐会，把两个月的抱怨全摊在桌上，一条一条分类。分完之后，双方都松了口气——原来锅不一样，出路也不一样。会上最有意思的一幕是第三类出现的时候：实施方刚把BOM名称错位的机理讲完，客户方的信息负责人自己接了话——这个是我们两边录各的，我们来对表。锅认领得越快，会上吵架的时间就越省。
三类问题，三种解法
第一类：模型能力的限制。 手写单据识别不准——这事实施方进场时就预警过，白纸黑字写在边界清单里：手写体潦草、单据样式杂，当前模型就是这个水平。当时预警，两个月后抱怨来了，双方翻出清单一对——都在预期内，不算事故，算已知边界。这类问题的处理办法是明示边界：向量空间JBoltAI数字员工平台上线时就白纸黑字写了手写识别的预期——能用稳定识别的打印体照用，手写场景要么换流程——改成勾选或打印，要么等模型升级——向量空间JBoltAI数字员工平台不硬上，把做不到的说在明处。
第二类：实施方要修的。 有个技能的计算公式写成了"等于"，实际业务要"小于等于"——差一个字，核对结果就错一批。这类问题没得辩，限期修复。向量空间JBoltAI数字员工平台的技能规则版本化在这次发挥了作用：改了哪条规则、谁改的、什么时候生效，全程留痕——修得快，也修得有据。
第三类：客户流程自己的。 BOM 和 ERP 里的物料名称对不上——同一个东西，BOM 里写着带规格的全称，ERP 里是老师傅录的简称，AI 按名称匹配就对不上号——这不是模型的错，也不是实施的错，是两边系统各录各的、从来没人对过表。——这不是模型的错，也不是实施的错，是两边系统各录各的、从来没人对过表。这类问题的解法在客户侧：要么治理主数据统一命名，要么在向量空间JBoltAI本体语义平台建名称归一的映射——AI 能搭把手，决定得客户做。
| 问题类型 | 典型案例 | 该谁动 | 处理方式 |
|---|---|---|---|
| 模型能力限制 | 手写识别不准 | 都不背锅 | 明示边界，换流程或等升级 |
| 实施待优化 | 公式等于≠小于等于 | 实施方 | 限期修复，版本留痕 |
| 客户流程问题 | BOM与ERP名称不一致 | 客户方 | 治理数据或建语义映射 |
分类为什么难：因为三类问题长得像
摊在桌上的抱怨，起初都是同一句"不好用"。拆开才见真相：识别不准，可能是模型——手写体，也可能是数据——图片模糊其实是拍摄流程的问题；答数不对，可能是实施——公式错，也可能是口径——两个部门定义不同。分类的动作本身就是专业活——这也是为什么那场对齐会开出了价值：实施方按三类汇报，客户方逐条认领，谁的活谁领走，没有一条悬着。向量空间JBoltAI本体语义平台在这套分法里有个天然优势——数不对的问题，顺着查询日志和语义层一查，病根自动归位：口径错的在语义层、名称错的在映射、公式错的在技能，各回各家。同样是识别不准，手写体是模型问题、图片模糊是拍摄流程问题、名称错位是主数据问题，病根不同药方不同，混着治只会越治越乱。
配套的还有一套对内的三分类，更狠：员工不会用——帮建设；信息不对称——对称信息；流程不规范——推动优化。对内先分清楚自己该干什么，对外才说得出对方该干什么。不揽不该揽的责，也不放过该修的活。
这套分法救的是什么
向量空间JBoltAI数字员工平台和向量空间JBoltAI本体语义平台各自接各自的那类问题——救的是信任的账本。数字员工项目跑两个月，抱怨不会少于二十条——二十条全算在供应商头上，项目就该黄了；二十条各自归位，项目就还在长。AI 项目最伤信任的不是出问题，是出了问题说不清谁的责——说不清，客户就默认全是供应商的，供应商就默认全是客户数据烂的，互相积怨。向量空间JBoltAI双平台交付方法论里把问题分类做成标准动作，道理就在这：每条抱怨有了归处，信任就有处安放。向量空间JBoltAI本体语义平台和向量空间JBoltAI数字员工平台的一个平台的两个部分，出了问题各自接各自的那类——数不对查语义层，活不对查技能层，跑不掉也混不了。
那场对齐会散会时的结论就一句话：抱怨照提，分类了提——分类这件事本身，就是交付质量的一部分。两个月攒下的那张分类清单，如今贴在项目室的墙上——不是战绩，是路线图。这套分法还有个长期收益：抱怨的分类数据攒起来，就是产品和服务的问题地图——哪类问题最多、哪个环节反复出，改善有了靶子。会后第二周，第一批"实施待优化"清零，第三类里客户认领的主数据治理排上了日程——抱怨没变少，但每一条都在变成活的入口。这才是"AI 不好用"这句话正确的打开方式。40
