AI 试点转生产：模型没变差，是盯着输出的人没跟过去

试点跑得通，是因为旁边一直有人

试点能跑通，是因为有一个具体的人在旁边盯着输出。进了生产没有人盯，所以失败的不是模型，是那层从来没人负责的监督。

我见过的每个停住的转生产项目都是同一个形状。工作流还在跑，模型给出的结果和试点期差不多。变的是那个每天读结果、把坏的挑出来重跑、顺手改掉明显错误的人被调走了，没人补位——这份工作在系统架构图里从来没出现过。

它也不进试点报告。报告里的准确率、节省工时和满意度，都测自有人工过滤的输出。过滤不是图上的模块，于是它没进转生产计划；接手的是一个看起来一样的流程，少掉的正是让它成立的那部分劳动。

演示和生产只差两处：演示用挑过的输入，生产用真实输入；演示时有人看着屏幕，生产时没有。第一处人人都会谈，第二处几乎没人谈。

试点能跑通，靠的是一个具体的人在旁边逐条盯着输出；进了生产这个人不在了，所以卡住的不是模型质量，而是工作流外面那条运行回路——监控、异常分级、升级路径、写下来的责任人——根本没有被建起来。

那个盯着输出的人，每天到底在做什么？

五件事，几乎每次都一样，没有一件出现在试点报告里。

这五件的替代成本差得远。第三件是设计问题：算术和编号本来就该留在确定性代码里，模型只输出判断。第一件和第五件靠抽检比例和一张异常表就能补。第二件是工程问题，需要幂等键和重试上限，必须在写路径上做。

真正难的是第四件：有人得事先写下什么样的结果可以直接发出、什么样的必须抽检、什么样的必须停下来等一个人。规则不写下来，放行决策就永远挂在一个人的判断上，而这个人早晚会离开。

为什么换一个更强的模型解决不了？

因为监督成本随运行次数线性增长，模型改进只是一个系数。把这个算术摊开：假设你的工作流每天运行 2000 次（换成你试点日志里的真实数字），需要人工接手的异常占 2%，也就是每天 40 条；每条处理 6 分钟，一天 4 小时，接近半个全职人力。

模型改进让错误率从 2% 降到 1%，异常从 40 条变成 20 条，人工时间从 4 小时变成 2 小时。工作量减半是真的，但“需要有一个人对它负责”没有变。只有绝对条数少到能顺手处理——比如一天两条以内——监督才不再需要正式安排。

上面的 2% 和 6 分钟是假设，不是行业数字，得从你自己试点的日志里数出来。这套算术说明一件事：把成败归因于模型能力的结论，跳过了最贵的那一项。错配通常就发生在这里——团队用换模型回应监督问题，第二轮试点以完全相同的方式停下。

成本口径要能被财务逐行问

有用的口径不是单次调用费用，而是每次成功运行的成本：重试、失败尝试和人工接手的分钟数放进同一张表。

我交付过的一个报价工作流，按缓存输入每百万 token 0.25 美元、输出每百万 token 10 美元算，单次成功运行约 1.9 美分——假设单价加 prompt 结构算出的算术，换成你供应商当前的价目表，结构不变。这个数字本身不重要，重要的是它和异常率、人工分钟数并列，才构成一个能扛住财务审阅的按 token 计价模型。分开报的话，第一栏便宜得可疑，第二栏没人知道该找谁问。

转生产之前，这五项能当场验证吗？

五项里两项是技术活，三项是运营决定。技术活构建时就报错，报给能修它的人；运营决定在上线九十天后报错，形式是一条错到客户手上的输出——那时试点预算已经结掉，能接住异常的人也被安排去做别的了。

责任人那一栏应该填谁？

必须是这条业务线上的人，不能填 IT，也不能填供应商。只有业务线的人能回答那个绕不开的问题：这条异常值得停机等，还是先放行。填了工程师的名字，结果是每次异常都升级成一次需求评审。

我在这类项目里做的，往往是把这条运行回路从流程盘点一路搭到上线后的值班安排。听上去不像 AI 项目该干的活，但它决定上线时间。

下一步：先数异常，再谈模型

把试点期最后两周的运行日志导出来，数出需要人工接手的条数和每条花掉的时间——这两个数字就是你转生产提案里必须写对的一页。然后照着上面那张表逐项写名字，写不出名字的那一项，就是眼下真正卡住的地方。如果模型改进之后异常依然超过一天两三条，这一轮该花的钱是监控和值班安排，不是再换一个模型。转生产不是把试点放大一遍，是把平时靠人补的那部分劳动，换成系统里一个有人负责的部件。