AI 功能不是增长按钮，而是一份用注意力、账单和信任支付的长期租约。
一、一句「能不能自动读发票」的代价
林岚一个人做发票对账工具，按月收 19 美元，客户是十几家小贸易公司。某个周五，最大的客户在支持邮箱里写：「你们能不能自动读发票？我们财务每周要手工录三十多张。」
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
她当晚就算了一笔账：三十张发票、每张录三分钟，一周九十分钟，一个月六小时。按客户财务的时薪折算，这确实是一笔值得省下的钱。于是她停了正在做的对账规则优化，花两周接上强模型，做了「上传 PDF 自动识别」的按钮。
上线第一个月，十二个付费客户里只有三个用过，合计调用 47 次。账单不算高，但问题不在账单：模型把两张不同供应商的发票金额认错，客户照着错误数据付了款，第二天才发现。她花了整个上午道歉、核对、手工冲正。那位最初提需求的客户说了一句让她印象很深的话：「我以为它会像扫描枪一样，扫完就能用。」
她做错的不是技术选型，而是把「有人提」当成了「该做」。 提需求的人愿意描述痛点，不等于愿意改变工作流；愿意试用，不等于愿意为结果负责。自动识别把错误直接写进了付款动作，而她的产品没有任何环节能让用户在付款前发现错误。这是判据缺失，不是模型不够强。
第二周的数据更难看。 三个试用客户里有两个回到手工录入，理由是「改错比录一遍还慢」。他们并不是嫌识别率低，而是无法判断哪一张被认错了，只能全部复核。一个把复核成本转嫁给用户的自动化，本质上没有省下任何时间，只是把工作从录入换成了检查。
真正的需求可能更便宜。 后来她把同样的三十张发票交给规则模板：固定版式的供应商走坐标提取，非固定版式走人工确认队列。开发用了三天，识别准确率没有提高，但错误全部停在「待确认」状态，客户自己就能改。她省下的不是模型费，而是两周注意力和一次信任事故。
二、四道判据：频次、材料、可撤销、已付费
判断一个任务值不值得上模型，不要问「AI 能不能做」，而要问这四个问题能不能同时回答「是」。4/4 才做自动型，3/4 只做辅助型，≤2 先停。
| 判据 | 通过标准 | 不通过时先做什么 |
|---|---|---|
| 任务频次 | ≥3 次/周/用户，且不是一次性配置 | 做成手动入口，观察四周真实使用 |
| 判断成本 | 需读至少 2 份材料，或人工处理至少 5 分钟 | 先做搜索、筛选或模板，压缩到 1 分钟内 |
| 错误可撤销 | 用户能当场发现并撤销，或结果不直接触发付款、发送、删除 | 加确认步骤，或改为只给建议不落库 |
| 已付费工作流 | 结果落在客户已经在付钱的核心流程里 | 先验证这个流程本身有人付费 |
频次决定学习成本是否摊得平。 一个月用一次的功能，用户每次都要重新理解按钮、等待时间和失败提示，你也要为这少量调用维持提示、评测和降级链路。每周三次以上的任务，用户才会形成稳定预期，异常也才有足够样本暴露。
材料数量是「模型是否真的有增量」的代理指标。 只读一行字就能判断的任务，规则往往更稳；要同时对照合同、历史记录和当前状态的任务，才是模型擅长的区间。五分钟是保守刻度：低于五分钟的判断，人工成本很难被推理成本明显压低。
可撤销性是风险闸门，不是体验细节。 同样准确率 90%，用在「生成一段可编辑的回复草稿」和「直接给客户退款」上是两种生意。前者错一次是麻烦，后者错一次是事故。若错误不可撤销，就必须先设计确认、抽样或人工复核，否则不应进入自动型。
已付费工作流决定预算从哪里出。 如果 AI 结果只是一个周边小工具，客户不会因此提高套餐；如果它嵌在客户每天必用的对账、开票、排班里，你才有提价或减少人工的空间。判据得分只是入口，付费路径才决定这笔投入能不能收回。
四道判据要分开打分，不要互相补偿。 高频但错误不可撤销，不能因为「用得多」就放行；已付费但一个月用一次，也不值得为它建整套推理链路。把四项写成 0/1，得分就是通过项数除以四，讨论时只争事实，不争感觉。
判据的证据必须来自日志，不是访谈。 「用户经常需要」这类说法没有分母。去后台数最近四周有多少个不同用户触发过这个动作、人均几次、其中多少人在动作后还有下一步操作。数不出来，就先按未通过处理；这比事后解释使用率为什么低要便宜得多。
三、三种替代：规则、搜索、人工
在写第一个提示之前，先把三种更便宜的替代摆在桌上。多数「AI 需求」在这三步里就已经被解决，剩下的才是模型该接的部分。
| 替代方案 | 适用信号 | 单次成本口径 | 什么时候仍该上模型 |
|---|---|---|---|
| 规则与模板 | 输入版式稳定、字段位置固定、判断标准能写成清单 | 开发工时摊薄后接近零，维护按变更次数计 | 版式经常变，或需要理解自由文本语义 |
| 搜索与筛选 | 用户其实是在找已有内容，而不是在生成新内容 | 索引与查询成本，通常低于一次生成调用 | 需要跨多条结果归纳、改写或解释 |
| 人工 concierge 或外包 | 需求低频、判断复杂、错误代价高 | 单次人工分钟 × 时薪，按实际发生付费 | 验证需求真实后，再把重复部分自动化 |
用同一把尺子比较。 人工单次成本等于「单次人工分钟 × 时薪」，模型单次成本等于输入 token 乘 p_in 加输出 token 乘 p_out，再乘上重试与失败系数。把两个数字写在同一条时间线上，你会看到很多任务的人工成本只有几美分到几十美分，模型并没有数量级优势。
规则不是落后的选择。 规则的优势是确定性、可审计和零边际成本，缺点是维护。一个人维护规则的成本，往往低于维护一套提示、评测和降级链路的成本。只有当输入的自由度让规则数量爆炸时，模型才划算。
搜索常常被误认成生成。 用户说「帮我找一下上次那条款」，真实动作是检索；说「帮我总结这三份合同」，才是生成。把检索做成搜索框加筛选器，响应更快、错误更少，也不需要为每次查询付推理费。
人工 concierge 是最好的需求探测器。 前十个客户你可以手工做：收到请求，自己整理，再发回去。连续四周仍然有人来，说明流程真实；两周后没人再提，说明那只是顺口的期待。手工阶段积累的输入，还会成为后面评测集的种子。
替代方案可以组合。 规则先过滤掉八成标准件，搜索负责定位，模型只处理剩下的疑难件，人工兜底最后的边界。这种分层不是妥协，而是把最贵的资源放在最需要判断的地方。
给替代方案一个观察期。 规则、搜索或人工上线后，连续四周记录三件事：处理量、返工率、用户是否主动要求「更智能一点」。处理量在涨、返工率在降、没人再提智能化，就说明替代方案已经够用；反过来，再考虑模型。观察期不需要写代码，只需要一张表和每周十分钟。
四、60 天退出条件与 90 分钟预验证
加 AI 最难的不是上线，而是承认它不成立。提前写下退出条件，等于提前给自己留一条体面的退路。
| 退出信号 | 触发阈值 | 触发后的动作 |
|---|---|---|
| 周活使用率 | 连续四周低于 20% 的付费用户 | 降为辅助型，或从主界面移除 |
| AI 归因收入 | 低于当月推理成本 | 停止扩展，转为手动或规则方案 |
| 人工兜底 | 转人工会话超过 40% | 先修事实边界与置信度，不加大模型 |
| 客诉与退款 | 比上线前基线高 2 个百分点 | 立即降级，保留草稿与人工入口 |
| 维护工时 | 每月超过 8 小时且收入没有增长 | 冻结新能力，只保留人工入口 |
退出条件要在上线前写。 上线后每个人都倾向于解释数据：「这周是假期」「用户还没发现」。提前写死阈值和观察窗口，才能把争论变成查表。四条里任意一条连续两个观察周期触发，就执行降级或下线，不叠加新功能去救。
90 分钟预验证比两周开发便宜。 找 20 条真实输入，其中至少 5 条是你最不想遇到的脏数据，手工在供应商 A 的强模型上跑一遍提示。逐条记录「可直接用」「改一改能用」「不能用」。可用少于 12 条，直接停；12 到 15 条只做辅助型；16 条以上再谈自动型。
失败样本不要丢。 那 8 条不可用的输入，正是第 05 篇小样本评测的起点。它们告诉你边界在哪：是缺上下文、缺事实来源，还是任务本身不该由模型判断。把这 8 条连同期望要点写进表格，后续每次改提示都先跑它们。
预验证要模拟真实延迟与成本。 不要只在一个短输入上试。取最长的一份材料，记录首 token 时间、总时长和 token 数，再乘上你预期的月调用次数。如果单次等待超过用户愿意停留的时间，或者月成本超过套餐价差，方案在纸面上就已经不成立。
同一输入至少跑三次。 生成结果有波动，一次成功不代表稳定。三次里有一次不可用，就按不可用计；三次都不稳定，说明这个任务对确定性的要求超过了模型当前能给的范围。把波动写进记录，比只记最好的一次更接近上线后的真实体验。
让提出需求的人参与验收。 把 20 条结果发回给最初提需求的客户，请他只做一件事：标出哪些结果他会直接采用。这个动作比任何内部评审都诚实，也能提前暴露「他要的其实是导出地址，不是识别」这类名词错位。
20 条输入要覆盖真实分布。 不要全挑干净的标准件。按最近一个月的实际类型分桶，常见单据占一半，模糊、缺页、手写、跨页的占另一半。预验证的通过率如果只在干净样本上成立，上线后一定会被脏数据打回原形。
五、行动清单与复算验收
先做减法：清单前四项都不写模型代码，但它们决定后面所有工时是否值得。任何一项写不出具体数字，就先停在替代方案。
把决定写成一句话。 做完上面几步，你应该能写出「因为通过 3 项判据、20 条里 14 条可用，所以先做辅助型，60 天后按四条阈值复核」。这句话同时包含证据、范围和复核日期，比「先上一个试试」更容易在两个月后被诚实检验。
- 记录提出需求的原始句子，并追问它对应的是生成、检索还是导出。
- 给这个任务打四道判据的 0/1 分，算出通过项数除以四。
- 统计目标用户最近四周的真实频次，不用访谈里的「经常」。
- 列出规则、搜索、人工三种替代的单次成本，与模型单次成本并排。
- 找 20 条真实输入，手工跑一遍提示并记录可用条数。
- 把不可用的 8 条整理成期望要点，留作评测集种子。
- 上线前写下四条退出阈值、观察窗口和触发动作。
- 指定一个负责人，每两周用同一张表复核一次。
验收标准：四道判据的得分、20 条预验证的可用条数、四条退出阈值都能用当天的事实复算出来，且没有一项靠「感觉应该可以」通过。
判据得分 = 通过项数 ÷ 4
示例：频次、材料、可撤销通过，已付费不通过 → 3 ÷ 4 = 0.75 → 只做辅助型
AI 增量毛利 = 升级用户数 × 套餐价差 − 当月推理成本
示例：40 × 9 − 260 = 100 美元/月
结论：增量毛利为正，且连续 60 天不触发任一退出信号，才扩大自动范围
使用边界与实操验收
本文判断的是「一个已有人付费的产品，此刻该不该加一个 AI 功能」，不讨论模型选型、提示工程或供应商合同。它假设你有可观察的真实用户和一条能算清的收入线；如果是尚未验证需求的新产品，先做人工 concierge，而不是先接模型。
- SaaS 加 AI 功能：先找可验证工作流，不要先做聊天框 ：它讲如何从工作流反推功能形态，本文讲用四道判据决定做不做、做到什么程度。
- LLM 商业化应用开发与产品化方法论：从价值验证到规模化盈利 ：它讲商业化路径与定价模型，本文只回答单个功能此刻的取舍与退出。
- 要不要做 API：三类买家、收入结构与退出条件 ：它讲 API 产品线的成本结构，本文沿用同一套「先验证再建设」的纪律。
实操验收建议做两件事。第一，把 20 条预验证结果和四道判据填进同一张表，请最初提需求的人签字确认「哪些会直接用」；第二，在上线前把退出阈值写进内部文档，并约定每两周复核一次。两项都完成，再决定是自动型、辅助型还是停。
这些阈值不是行业标准。 每周 3 次、5 分钟、20%、40%、2 个百分点，都是为了让判断可执行而选的教学刻度。你的客单价、支持成本和风险承受度不同，阈值应当重算，但口径要保持一致。
三种情形不适用本文。 一是 AI 本身就是产品核心、没有既有工作流可嵌；二是受监管行业，错误不可撤销且需要外部审计；三是需求来自单一客户的口头承诺，尚无付费证据。这三类要另做合规、合同或需求验证。
关键参考与核验范围
核对日期：2026-10-25。下列来源仅支持明确标注的机制或原则。
- NIST AI Risk Management Framework : 用于核对 AI 风险管理应结合用途、影响与测量的框架。
使用边界。 四道产品判据、替代方案和退出刻度是本文的决策模板，不是 NIST 的量化标准。
如何自行复核。 记录每道判据的用户证据、可撤销路径和成本；无法举证的项先列为待验证，不用总分替代风险判断。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。