1. 为什么AI需要真正理解你的产品?
在制造业企业IT部门工作多年,我见过太多"AI替代人工"的失败案例。去年我们尝试在一家年产值30亿的汽车零部件企业部署AI助手,结果发现一个有趣的现象:演示阶段AI能完美处理80%的常规操作,但真正上线后,连最基本的"修改供应商交货日期"这样的需求都频频出错。问题出在哪?经过半年实地观察,我发现核心矛盾在于:现有AI系统只能识别界面元素,却无法理解业务语义。
举个例子,当用户说"帮我把A供应商的订单延期一周"时:
- 人类操作员会:1) 进入采购模块 2) 筛选该供应商订单 3) 检查是否有未生效合同限制 4) 批量修改交货日期
- 当前AI会:1) 识别"延期"关键词 2) 随机点击界面上的日期控件 3) 因缺少前置条件检查导致系统报错
这种差距源于业务系统的四层认知鸿沟:
- 界面层:按钮/字段的物理属性(AI可见)
- 流程层:操作间的跳转关系(AI部分可见)
- 逻辑层:业务规则与约束(AI不可见)
- 意图层:操作背后的业务目标(AI完全盲区)
关键发现:AI操作失败案例中,83%源于对逻辑层和意图层的误解,而非技术执行错误
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Spec:AI理解产品的语义桥梁
2.1 传统AI训练方式的局限
我们曾尝试三种主流方案:
- 操作手册训练法:维护成本每月高达40人时,且文档与系统实际版本同步率不足60%
- 屏幕录像分析法:需200+小时视频才能覆盖主要场景,且无法捕捉后台逻辑
- RPA脚本移植法:脚本脆弱性导致平均每2周就需要人工干预
这些方法本质上都在做"界面到动作"的映射,就像教鹦鹉学舌,却不解释词语含义。
2.2 Spec的结构化表达革命
OpenSpec标准通过四层建模解决这个问题:
| 层级 | 内容 | 示例(采购模块) | 技术实现 |
|---|---|---|---|
| 实体层 | 业务对象定义 | PurchaseOrder | JSON Schema |
| 动作层 | 可执行操作 | postponeDelivery(orderId, newDate |
