AI 生产需要积累自己的工艺

假设一位卖家希望每天拿到一批可以上架的商品图。系统能生成漂亮的图片，是一个很好的开始。但卖家还需要核对商品有没有变形、包装文字是否准确、图片是否符合上架要求。不合格的要修改，拿不准的要找人确认，这些工作也都占用时间。

这篇文章的起点，是一次关于 AI 生产成本的讨论。为了算清一项任务花了多少钱，就得继续追问：哪些结果可以交付，失败的尝试由谁补救，用户还要投入多少时间？沿着这些问题想下去，要把成本算清楚，就得跟完一项任务从开始到交付的全过程。

我关心的是，AI 产品准备把其中多少工作接过来。对于已经能生成候选结果、并且需要反复按约定要求交付的业务，围绕生成的筛选、纠错、验收和异常处理，本身就应该成为产品能力。这些工作做得怎样，会影响用户最后得到了多少帮助。

我想借工业生产的经验提出三个判断：效率要算到约定工作完成为止，工程投入要跟着交付瓶颈走，有效做法要积累成能够复用、也能够重新检验的工艺。

这里的工艺，是完成一类任务时经过验证的输入条件、处理步骤、验收方法和异常安排。

本文讨论的，主要是方向已经确定、需要按约定要求反复交付的业务。创意探索中的候选方案本身就可能有价值，未被采用也不等于失败。把两个阶段混在一起，可能把探索误算成返工，也可能把一次成功误当成稳定交付的能力。

用户接手的工作也要算进去

继续看商品图的例子。一次模型调用结束之后，剩下的工作很容易被写成产品介绍里轻描淡写的一句：用户可以自行筛选和调整。

但对每天处理一批商品的人来说，“自行筛选和调整”可能正是最耗神的部分。他需要逐张比对原图，辨认模型是否改动了商品，处理偶尔出现、却又不能放过的错误。有时还得来回尝试，直到得到可以使用的结果。

这些工作交给用户，可以是一种明确的产品选择。产品也可能确实节省了大量时间。不过，当我们声称它提高了生产效率，就应该把用户继续承担的部分算进去。工作离开了平台，并不意味着它已经完成。

ASQ 的质量成本框架把预防、检验，以及交付前后出现的失败成本都纳入考察。这个框架对我的启发很直接：判断一种生产方法是否划算，要连同它为了获得合格结果而付出的代价一起看。一次生成便宜了，后面的筛选和补救却变多了，总投入就未必下降。

因此，对于这类产品，我会先追踪一组任务从输入到验收的全过程。模型用了多少资源，人工花了多少时间，到了约定时间完成了多少，还有多少没有完成，都需要放在一起看。失败尝试已经消耗的资源也应计入；只挑最后成功的结果来算，会把获得它们的过程删掉一部分。比较两种方案时，输入范围和交付要求还需要相近，否则很容易把承接了更简单的任务误认为效率提升。

用户每次都要重复完成、又影响基本可用性的检查，应当进入产品规划。能否接过这些工作，直接影响用户能否把一项完整任务交给系统。

比如，尺寸、格式、商品编号这样的要求，适合交给明确的规则检查。商品是否失真，需要更合适的判断方法；品牌风格和审美取舍，则可能仍然需要使用者参与。把这些工作分别弄清楚，才能决定系统该接过哪一部分，以及接过之后怎样证明做得可靠。

我并不期待把所有人工判断都消除。人的选择可以是服务的重要组成部分。但用户为了维持基本可用性而反复补洞，应该被当作产品有待解决的问题。对一个已经能产出可用候选的业务，我愿意优先减少这类劳动，并用完成同样交付要求所需的总投入来判断改进有没有价值。

先解决拖慢交付的环节

把整个过程放进视野，改进的优先级也会变化。

假设一条流程持续以每小时一千张的速度生成图片，每张都必须经过人工审核，而审核每小时只能处理一百张。即使其他环节都没有损耗，这套流程持续交付的上限也只有每小时一百张。继续提高实际生成速度，待审核的积压会增长得更快，交付速度却不会因此提高。

这是一个刻意简化的例子，但它让我倾向于一个很明确的选择：工程投入应该跟着完整交付的瓶颈走。当审核已经限制了交付量，改善生成速度就不该自动排在最前面。

实际工作里，瓶颈未必固定在某个环节。输入材料不完整，可能让任务卡在开始之前；某类错误频繁出现，可能让大量时间消耗在来回修改中；判断必须依赖少数专业人员，也可能限制整个流程的进度。我们需要先看到任务具体在哪里等待、为什么重做，再决定投入。

丰田生产方式的说明中有两个值得放在一起看的安排：发现异常时可以停止生产，避免继续制造不良品；各环节按需要的时间和数量衔接。借用这个视角，一个环节是否值得继续运转，需要放在完整交付中判断。

放到商品图的例子里，如果已经发现某种包装上的文字经常被改错，先暂停这类任务、弄清适用边界，是合理的生产动作。让同一套有问题的方法继续批量运行，会把一个已知缺陷扩展成更多需要检查和补救的结果。

具体到产品选择，我会先处理最常见、影响最大的阻塞。大量时间用在核对格式上，就补规则校验；同一类输入反复生成错误，就修正方法或收窄支持范围；专业判断确实不可省，就按审核能力安排批次和节奏。等到生成本身成为限制，而且后续环节能够承接更多结果，再去增加生成能力。

模型升级也可以解决这些问题。一个更合适的模型如果显著减少错误，就可能同时降低返工和审核负担。但这项收益需要在后续工作中得到验证，不能只从生成速度或单次评分推断。

值得积累的是经过验证的工艺

如果前面这些工作都属于生产，那么一个产品长期应该留下什么，也就更清楚了。

我愿意把可靠完成一类任务的方法，当作一项需要维护的产品资产。这里说的“工艺”，包括输入需要满足什么条件，工作怎样组织，结果怎样验收，以及遇到特定异常怎样处理。还应该知道：这套方法在哪些条件下经过验证，哪些地方仍然需要人来判断。

保存一张工作流图，可以留下调用顺序。但一套流程能运行，离我们知道何时可以依赖它，还有很多需要补上的认识。

批处理领域的 ISA-88 提供了一个有用参照。它把产品配方与设备控制分开描述，让生产方法和执行它的设备可以分别管理。Yokogawa 对 ISA-88 批控制的介绍解释了这种分离的用意。对 AI 业务，我由此得到的启发是：完成任务的方法值得被单独描述和维护，不能全部藏在某次模型调用的细节里。

这种分离当然不意味着模型可以随意替换。同样的提示词和流程，换一个模型以后，原有的质量判断可能需要重新验证。把方法保存下来，是为了知道哪些条件发生了变化，也为了判断原来的经验还能用到哪里。

仍以商品图为例。假设一套流程适合背景简单、主体清晰的输入，却经常处理不好反光包装上的文字。一次次运行之后，应当留下这类适用边界，也应当留下失败样例和已经验证过的处理方法。下一次遇到相似任务时，团队才能据此决定沿用流程、要求补充材料，还是转交人工处理。

如果这些判断一直留在少数人的记忆里，每次交接、每批新任务都可能重新付出学习成本。把它们写回流程、输入要求和验收方法之后，一次问题的解决才有机会改善后续很多次执行。

这里的“经过验证”很重要。保存运行记录提供了线索，却不会自动证明某种方法可靠。修正一个提示词之后，我们还需要观察它是否减少了目标错误，有没有带来新的问题，效果是否只存在于少数样例上。成功样例、失败样例和方法版本应当能够对应起来，方便以后继续判断。

验收方法本身也需要被检查。格式校验抓不到商品结构的错误，一个模型给出的高分也需要与实际验收结果对照。NIST AI 风险管理框架把接近实际运行条件的评估、有效性判断和生产中的持续监测都纳入了考虑。它给我的提醒是，不能把一个方便统计的分数直接当作业务要求已经得到满足的证据。

因此，我会优先为反复使用、多人协作、出现过重复缺陷的流程积累这些知识。起步可以很小：明确一类输入的边界，保留一组有代表性的样例，记下常见异常怎样处理。模型、流程或验收要求变化后，再对受影响的部分重新验证。真正需要积累的，是下一次做决定时用得上的依据。

对于已经能够持续生成候选的业务，我更看重产品是否逐渐掌握了某类交付的具体方法。模型能力进步会带来新的可能，积累的工艺则让团队知道怎样把这些可能用到实际业务里。

如果据此安排下一阶段的工作，我会先跟完一批真实任务，找出用户补救最多、交付等待最久、同类错误反复出现的地方，选择其中影响最大的一个加以改进。然后在相近的任务和相同的交付要求下，检查总投入与完成情况，把有效的方法保留下来。

我希望看到的进展很具体：同类任务再次到来时，系统已经能避开上次的常见缺陷，用户少做了一遍重复检查，团队也更清楚哪些例外需要人来接手。围绕这些进展积累起来的工艺，是我认为 AI 生产最值得向工业界学习的部分。