AI ROI 不等于 Token 成本：用“被接受任务成本”判断是否扩张

很多团队讨论 AI 预算时，先看模型单价、席位数或对话次数。这些都是使用信号，却不能证明有价值的 工作真的完成了。

OpenAI 在 2026 年 7 月发布的 AI scorecard 提出应关注 useful work、每个成功任务成本、可靠性和 计算回报。无论团队是否使用 OpenAI 产品，这个视角都值得借鉴。关键不在“任务”，而在成功任务。

一个工作流生成了 100 份草稿，并不代表它产生了价值。只有当其中一部分在明确标准下被接受、安全地 进入下一步，并且总投入低于原有流程时，AI 才真正创造了回报。

先定义“被接受”，再开始计量

最容易做出好看 ROI 的方式，是统计调用次数。最有用的方式，是在第一次运行前写清验收规则。

以客服草稿为例，被接受不应只是“模型生成了文字”，而可以是：回复符合当前政策，引用了正确账号 信息，只需一次小修改，且在服务时限内发送。以代码任务为例，可以是：变更通过测试，遵守仓库规则， 经过代码审查，且没有引发后续事故。以销售研究为例，可以是：线索信息足够让销售行动，而不是销售 又花十分钟重新查一遍。

验收规则要能重复执行，也不能为了容易通过而写得过窄。“有输出”不是规则；“审核人依据当前政策 批准，且修订不超过三分钟”才接近可测标准。

一个团队真的能运行的评分卡

先固定任务集。它应包含普通任务、边界案例，以及少量正确答案应该是拒绝、升级或要求更多信息的 任务。不要每次模型表现不佳就替换任务集。

每次尝试至少记录以下字段：

可以用一个简单公式强迫自己看全成本：

被接受任务成本 =（AI 直接成本 + 审核成本 + 失败修复成本）/ 被接受任务数

这不是统一会计准则，而是一种防错机制。它能阻止团队只因 token 便宜就庆祝，同时忽略审核人每次都 要花十二分钟修复结果的事实。

从选模型转向设计工作流

假设 A 工作流每次尝试只花 0.08 美元，但通过率 55%，每次还需要六分钟审核；B 每次花 0.24 美元， 通过率 82%，审核只需一分钟。只看 token，A 更便宜；把人工时间和重试放入“被接受任务成本”后， 结论可能相反。

但这也不自动代表 B 必胜。也许 A 的输出可以批量修订；也许 B 在少数任务上会产生高风险错误；也许 某个模型在目标市场不可用。评分卡的价值不是替你选一个赢家，而是把这些取舍显性化。

OpenAI 关于 Agent 投资的文章将“每美元的有效工作”和可靠性放在中心。这比泛泛的“效率提升”更 接近运营事实。一个有价值的工作流需要清楚的任务边界、稳定的验收条件，以及在失败时能改善周边 上下文的负责人。

不要把每次失败都改写成提示词问题

坏结果通常属于四个不同层面：

1. 输入失败：缺少最新资料、权限、客户事实或清晰指令。
2. 执行失败：工具调用、检索、模型输出或集成没有完成。
3. 验收失败：结果看起来合理，但不符合质量、政策或格式要求。
4. 经济失败：结果可用，但审核、等待或支出过高，无法扩大。

这也是上下文工程：提示词和可靠 AI 产品之间的新层为什么不仅是技术概念。 如果 Agent 从未拿到最新退款政策，换更高分的模型也不能解决；如果审核人无法快速看到来源，更贵的 模型可能只会让问题更难发现。

先建立基线，再自动化整个流程

选择一个重复任务，从真实工作中抽取 20-50 个代表性案例，必要时脱敏。标记预期结果、允许使用的 来源，以及何时必须升级给人工。然后用相同任务集比较人工流程和 AI 辅助流程，记录耗时、审核时间、 直接花费、接受结果和拒绝原因。

这不需要先买昂贵评估平台。一张结构化表格加上固定审核节奏，往往比没有成功定义的漂亮 Dashboard 更可靠。对于中文团队，还要把中英混合材料、海外客户时区、外包审核和本地客服转交纳入人工成本， 不要只用美元模型单价替代真实交付成本。

在热情变成支出前写下停止条件

每个试点都应有停止条件：低风险任务经过规定迭代后通过率仍不足；审核时间高于人工基线；出现高严重 等级错误；直接成本增长快于被接受产出；团队说不出最常见的失败原因。停止不是 AI 失败，而是防止 团队因为 Demo 很惊艳就持续投入一个尚不适合生产的工作流。

小型 SaaS 最先找到回报的，往往是重复但不完全自治的工作：对入站请求分类、从允许来源整理研究、 生成供审核的回复、检查结构化数据、准备交接材料。它们有可测的前后变化，也有人能及时发现错误。

从一个固定任务集开始，统计被接受结果，把审核与修复放进成本分母。只有评分卡证明工作在持续赚钱， 才扩大自动化，而不是扩大兴奋感。

相关阅读：上下文工程：提示词和可靠 AI 产品之间的新层、AI 工具创意：先找到值得构建的重复工作、工具。