1. 项目概述:当AI遇上业务"潜规则"
在AI系统落地的真实战场摸爬滚打多年后,我发现一个令人头疼的现象:那些写在需求文档里的业务规则,最终能在代码里实现80%,在模型提示词里覆盖60%,但实际业务跑起来还是频频踩坑。问题往往出在那些没人写下来却天天在用的"潜规则"——比如销售老张知道客户A的紧急需求要先微信确认再走系统,客服小李清楚某产品线的投诉电话必须10秒内接听否则必遭差评。
这些散落在组织毛细血管中的经验碎片,我称之为"业务暗知识"。它们既不像代码那样有严格的语法检查,也不像提示词那样容易调整测试,却实实在在地影响着每个决策节点的质量。去年我们团队就吃过亏:一个根据工单内容自动分派的AI系统,明明准确率报表很漂亮,实际使用中却被投诉"不懂变通"——因为它不知道某些特定客户的历史工单需要人工复核这条潜规则。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术方案设计:BCA六要素解剖
2.1 核心问题拆解
业务暗知识之所以难处理,源于三个本质特征:
- 条件触发型:只在特定场景生效(如"大客户周末的加急订单要抄送总监")
- 动态演变性:随业务发展高频调整(如"新版本上线首周所有故障自动升级P1级")
- 多维关联性:往往涉及多个系统的协同判断(如"当CRM客户标签为VIP且订单来自线下渠道时,需检查库存预留记录")
传统方案要么写成硬编码(难以维护),要么塞进提示词(难以追溯),而BCA的创新在于将其转化为结构化元数据。这就好比给AI系统装上了"业务经验U盘"。
2.2 BCA六要素详解
通过17个真实项目的迭代,我们提炼出BCA的标准化结构:
| 要素 | 说明 | 示例 | 实现方式 |
|---|---|---|---|
| 作用域 | 知识适用的业务边界 | 仅限北美区电商售后流程 | 打标系统+属性过滤 |
| 触发条件 | 何时激活该知识 | 客户历史订单>5且本次金额>5000 | 规则引擎+特征计算 |
| 建议动作 | 期望系统采取的行为 | 自动分配专属客服经理 | API调用工作流引擎 |
| 置信要求 | 执行该动作的确定性阈值 | 需满足3/5个关联特征 | 概率评估模块 |
| 失效机制 | 知识自动退出的条件 | 促销活动结束后48小时 | 时间触发器+状态检 |
