ai-fit-check

三条硬闸门:为什么「能生成」不等于「能批量」

这份文档解释 audit.py 的判据来源。判据全部来自实际交付中的失败与纠正,不是理论推演。

0. 问题的错问法

最常见的问法是「这个能不能用 AI 做」。这个问题没有答案,因为「能做」有三种互相矛盾的意思:

  1. 能生成 —— 模型能输出一个看起来像样的结果(今天的模型几乎都能)
  2. 能验收 —— 有人(或机器)能判断这个结果对不对
  3. 能规模 —— 每个案例的处理成本不随人头线性上升

绝大多数「AI 降本」的账算错,是把 ① 当成了 ③。

1. G1:有唯一正确答案或可核对的对照

判据:把结果给两个互不通气的专业人士看,他们是否给出相同结论?

不通过不代表不能做,只代表不能批量——每一份都要人看,成本随份数线性增长。

2. G2:失败可被自动检测

判据:出错时,不需要人看,系统自己能不能报警?

这条比 G1 更硬。很多任务有客观答案(G1 过),但没有可自动化的检测手段(G2 不过):

推论:很多”不可批量”的任务,卡点不在模型能力,在缺一个检测器。造检测器往往比造生成器便宜,且更值钱。

3. G3:差异不会引出公平感比较

判据:两个客户拿到不同质量的结果时,会不会变成”凭什么他有我没有”?

这条最容易被忽略,也最容易把项目做死。

真实反例(已发生,代价是六位数的人力):

据此得到的操作规则:判断一件事要不要做,先问「不做会损失什么」。答案是「什么都不损失」,就不要做——这比「ROI 为正」更严格。

4. 两条软闸门

5. 怎么用这份判据

  1. 把手上所有重复任务列出来,填进 tasks.json(字段见 README)。
  2. 先跑一遍,看哪些是 BATCH、哪些是 NOT_BATCHABLE。
  3. 对 BATCH 的任务,先做一个试点,用真实数据算节省,再谈铺开。
  4. 对 NOT_BATCHABLE 的任务,问一句:缺的是检测器,还是根本没有客观标准? 前者可以工程化,后者不应该碰。

6. 免责与边界