你大概遇到过这种场面：有人把定时跑脚本说成「我们上了 AI」，也有人以为买了大模型接口，活儿就会自己干完。这两个词混着用，需求会写歪，验收也没法验。这篇不抠学术定义，只给一套能落地的判断顺序：先看流程怎么走、再看决策从哪来，最后落到你该怎么选、怎么验。
你大概遇到过这种场面：有人把定时跑脚本说成「我们上了 AI」，也有人以为买了大模型接口，活儿就会自己干完。这两个词混着用，需求会写歪，验收也没法验。更麻烦的是，一旦写进合同或者立项文档，后面扯皮的就是你。
这篇不抠学术定义，只给一套能落地的判断顺序：先看流程怎么走、再看决策从哪来，最后落到你该怎么选、怎么验。判断标准都带上「什么情况下不适用」，不会给你一个放之四海皆准的结论。
先分清：混的是哪两件事
多数人混淆的其实是「流程自动化」和「AI 推理能力」两个层面。一个管怎么走，一个管怎么判断。你可以把自动化理解成水管，AI 理解成水龙头上的感应器；水管负责把水送到，感应器负责决定什么时候放水。两样东西经常装在一起，但不是一回事。
- 流程自动化
- 固定步骤、固定触发、结果可预期，强调按顺序执行
- AI 推理
- 从数据里学到的判断，输出带不确定性，强调临场做决定
- 叠加形态
- AI 常被塞进自动化流程的某个节点，自动化也常被用来调度 AI 的调用
判断口诀很简单：把 AI 拿掉，流程还能不能跑完？能跑完就是纯自动化，跑不动才说明 AI 是核心。如果拿掉之后要靠人补班才能跑完，那属于半自动加人肉兜底，不算自动化系统。
四个维度当场对照
下面这张表可以当场对着你手上的系统过一遍。别只看一个维度就下结论，四个维度里三个偏自动化，基本就是脚本；反过来才是 AI 系统。
| 维度 | 偏自动化 | 偏 AI |
|---|---|---|
| 触发与路径 | 步骤写死，分支提前枚举 | 要看情况临场决定走哪条路 |
| 输入形态 | 结构化字段、固定格式文件 | 自然语言、图片、语音、开放文本 |
| 输出稳定性 | 同样输入永远同样输出 | 换个说法结果就变 |
| 失败处理 | 报错即停，靠人工修 | 给候选、给置信度、允许重试换路 |
- 触发维度不适用的情况：定时任务里嵌套了 AI 判断，触发是死的但决策是活的，别只看触发器就下判断
- 输出稳定性不适用的情况：温度参数调低、做了严格约束后，AI 输出也能很稳定，稳定不等于没有 AI
- 失败处理不适用的情况：早期 AI 项目也常常报错即停，只是还没做兜底，别把工程成熟度当成技术分类
如果你手上系统介于两者之间，去站内工具目录翻一翻同类工具的能力描述，对比一下别人怎么归类，比自己拍脑袋准。到 /tools/speed-test 可以顺手测一下实际响应的分布情况。
什么情况下不该用 AI
AI 不是万能补丁。规则明确、量又大又稳定的活，用脚本更便宜更快，上模型只会引入不确定性，还得额外做兜底和监控。省下的那点人工，远不够填后面排查的坑。
有硬性合规要求、必须可追溯到每一条判断依据的环节，也不要把判断塞进模型黑盒。你可以用 AI 做初筛，但最终那条必须能指着规则说清楚为什么。数据本身没整理好、字段乱七八糟时，先把清洗做完，换什么模型都救不了。
AI 适合处理「人说不清规则但看得懂结果」的活，不适合处理「规则写得明明白白」的活。
三个典型的不适用信号
- 规则能写成 if-else 且覆盖绝大多数情况，别上模型
- 出错后果不可逆、且必须逐条解释原因，别把判断权交出去
- 连人工做一遍都很难保持一致结论，先解决流程本身，再谈模型
选型与验收怎么做
先画一张流程图，把每个节点标成「规则可判定」或「需要经验判断」。只有后者才考虑接模型。标记完你会发现要接模型的地方比想象中少，这是好事，省钱也省心。
- 标节点逐个节点问「这一步能不能写成确定的规则」，能写的留自动化，不能写的才列入 AI 候选
- 定验收给每个 AI 节点准备一批真实样本，跑一遍看通过率，不要只看演示效果。样本要包含边界和坏输入
- 补三件事上线前确认超时与重试怎么设、失败后走人工还是走兜底、日志要记下输入输出与耗时这四项
- 做回看上线后按周回看失败样本，判断是提示词问题、模型能力问题，还是这条活本来就不该交给 AI
验收标准别只写「效果好」。写成「这批样本里通过多少条、失败的那几条失败在哪类输入上」，后面才好归因。具体的价格和性能数据变动很快，选型前到 /price-watch 核对当时的数字，再决定用哪个接口。
下一步把你手上那条流程按上面的四维度表过一遍，再决定哪里接模型、哪里有现成脚本就够了；需要选具体工具时去站内目录按能力筛一遍，比从零调研快得多。→常见问题
自动化脚本里调了模型，这算 AI 还是自动化？
看模型在流程里的位置。如果模型只是某个节点的一个可选判断，去掉它流程照样能跑完，本质还是自动化，模型只是插件。如果去掉模型整个流程就没法做决定，那 AI 才是核心。写需求时把这个位置标清楚，后面验收才不会扯皮。
小团队没算法工程师，能搞 AI 吗？
可以，但先把边界划小。挑一个规则说不清、但结果好坏一眼能看出的环节先试，比如分类、摘要、字段抽取，用接口调用而不是自己训模型。剩下的流程照旧用脚本和人工兜底。跑通一段再加第二段，别一上来就整体重做。
怎么判断一个需求到底该不该上 AI？
问三个问题：这件事有没有明确规则可写？同样的输入是不是要同样的输出？错了会不会有硬性后果？只要规则能写清、输出必须完全一致，就别用 AI。反过来，规则写不出来但人能判断对错，才是 AI 的用武之地。拿不准就先跑小样本对比。
