AI改造, 技术评估, 架构设计, 数据治理
前言
过去一年，我至少被问了二十次同一个问题："我们这个业务能不能上AI？"
问的人里有做电商ERP的、有做工厂MES的、也有做本地生活SaaS的。共同点是焦虑------怕错过，又怕烧钱打水漂。
这篇文章不聊大模型参数，也不聊Agent架构。我想把过去两年陪客户做AI改造评估时，真正用来"劝退"或者"放行"的三个判断标准摊开讲。适合技术负责人、产品经理，以及被老板逼着写AI立项报告的人。看完你至少能判断：手上这个需求，是该老老实实写规则引擎，还是值得动用AI。
问题背景：为什么大部分AI改造项目死在了POC阶段
去年下半年，我们团队接手过一个零售客户的"智能补货"项目。对方老板很兴奋，说要用AI预测销量，替代原来那套Excel加人工经验的补货流程。
我们花了三周做数据摸底，结论是：这个业务不适合用AI。
原因不复杂。他们的SKU有八千多个，但真正有稳定销量的不到三百个，剩下的长尾商品一个月卖不出几件，历史数据稀疏得可怜。更麻烦的是，补货决策的"正确答案"根本不存在------店长凭经验拍脑袋，卖爆了算运气，压货了算市场波动。没有稳定的标签，模型学什么？
最后我们给了一套基于安全库存和移动平均的规则方案，两周上线，效果比他们预期的还好。老板一开始有点失望，觉得"没用上AI"。三个月后他跟我说，幸亏没上，隔壁同行上了AI预测，光数据清洗就烧了小两百万，到现在还没跑通。
这个故事里藏着三个判断维度，我下面拆开讲。
原理：判断业务是否适合AI改造的三个维度
我把它们叫做数据密度、决策容错率、反馈闭环速度。这三个维度不是拍脑袋来的，是我们复盘了十几个项目后归纳的。
维度一：数据密度够不够
AI不是魔法，它本质是在历史数据里找规律。数据密度包含两层意思：样本量和特征丰富度。
样本量好理解。一个业务场景，如果每天产生的有效决策样本少于几百条，或者关键类别的样本稀疏到个位数，模型基本学不出东西。这里有个粗略的经验值：
| 任务类型 | 最低样本量参考 |
|---|---|
| 二分类（如欺诈识别） | 正样本至少1000+ |
| 多分类（如工单归类） | 每类至少300-500 |
| 回归预测（如销量） | 至少覆盖2-3个完整业务周期 |
| 序列生成（如文案） | 预训练模型可缓解，但微调仍需千级 |
特征丰富度更关键。我见过一个做设备故障预测的客户，传感器数据倒是每秒都在采，但只有温度和振动两个维度，而且故障样本两年才出现四次。这种数据密度，上什么模型都是玄学。
维度二：决策容错率有多高
这一条最容易被忽略，但往往决定项目生死。
AI的输出是概率性的，不是确定性的。如果一个业务的错误决策代价极高，且没有人工兜底环节，那AI改造就是给自己埋雷。
我一般会问客户三个问题：
- 这个决策错了，最坏后果是什么？
- 错误发生后，多久能发现？
- 有没有人工复核的环节？
比如智能客服的意图识别，错判了顶多用户多问一句，容错率高，适合AI。但如果是医疗诊断或者金融风控的最终放款决策，容错率极低，AI只能做辅助，不能做最终裁决。
维度三：反馈闭环速度
模型需要持续迭代，迭代依赖反馈。反馈闭环速度指的是：从AI做出决策，到我们能知道这个决策对不对，中间隔多久。
推荐系统为什么适合AI？因为用户点没点、买没买，几秒钟就有反馈。而战略采购决策，可能半年后才知道当初的判断对不对，这种慢反馈场景，AI迭代周期太长，投入产出比很难看。
实操：一个可落地的评估打分表
光讲维度太虚，我给一个我们内部在用的打分表。每个维度1-5分，总分15分。
python
# 业务AI适配度评估脚本
# 我们团队内部用的简化版，仅供参考
def evaluate_ai_fitness(data_density, error_tolerance, feedback_speed):
"""
三个维度各1-5分
data_density: 数据密度（样本量+特征丰富度）
error_tolerance: 决策容错率（越高越适合AI）
feedback_speed: 反馈闭环速度（越快越适合AI）
"""
total = data_density + error_tolerance + feedback_speed
if total >= 12:
return "适合AI改造，建议立项"
elif total >= 8:
return "可尝试，但建议先做规则方案兜底"
else:
return "不建议AI改造，优先考虑规则引擎或人工优化"
# 举个实际例子：电商商品标题自动生成
# 数据密度：有历史商品库和点击数据，4分
# 容错率：标题生成错了可以人工改，4分
# 反馈速度：上线后一周看点击率，3分
result = evaluate_ai_fitness(4, 4, 3)
print(result) # 输出：适合AI改造，建议立项这个脚本当然粗糙，但能帮你在立项会上快速给出一个有理有据的判断，而不是拍脑袋。
踩坑：我们犯过的两个典型错误
第一个坑：把"有数据"等同于"数据可用"。
有个做物流的客户，说他们有五年的运单数据。我们一查，字段缺失率超过40%，地址信息格式五花八门，同一个城市能写出七八种写法。光数据清洗就花了两个月，项目周期直接翻倍。后来我们学乖了，评估阶段一定先跑一遍数据质量报告，缺失率、重复率、字段规范度，一个都不能少。
第二个坑：忽略了业务方的配合成本。
AI改造不是技术团队单方面的事。标注数据、复核结果、调整流程，都需要业务方投入人力。有个项目，技术侧模型都调好了，业务侧没人愿意花时间标注反馈，模型效果一直上不去，最后不了了之。现在我们在评估阶段就会问：业务方能不能承诺每周投入多少人力配合？答不上来的，先缓缓。
总结
判断业务是否适合AI改造，别一上来就聊模型选型。先看数据密度够不够，再看决策容错率高不高，最后看反馈闭环快不快。三个维度加起来，基本能筛掉一大半不该上的项目。
剩下的那一小半，才是真正值得投入资源去做的。省下来的钱和精力，够你把规则引擎打磨得很好了。
如果你手上正好有个AI改造的立项需求，不妨拿这三个维度先自测一遍。有不同看法或者踩过别的坑，欢迎在评论区聊聊。