你的产品该用 AI 吗？一份务实指南

AI 在产品里可以很有用，但「加上 AI」不是一条产品需求。请从用户的问题、软件必须支撑的那个决定，以及这个决定出错的代价开始。

采用的压力是真的，压力背后的落差也是真的。

斯坦福 HAI 的 2026 AI Index （在新标签页中打开） 报告称，2025 年组织层面的 AI 采用率升至受访组织的 88%。报告同时指出，在几乎所有业务职能中，AI 智能体的使用「仍处于早期」。

德勤的 2026 State of AI in the Enterprise （在新标签页中打开） 调查了 24 个国家的 3,235 位高级管理者。结果显示，74% 的组织希望借助 AI 增加收入，而已经做到的只有 20%。

采用几乎是普遍的，兑现的价值却不是。

正是这道落差，值得在决定之前放慢一次对话。问题不在于 AI 有没有能力，而在于这项功能对这位用户而言，是不是一个适合用 AI 去解的问题。

什么时候适合 AI，什么时候不适合

规则清楚时，常规的工作流往往是更好的选择。表单、权限、搜索、计算、通知和定时任务，并不会因为手边有语言模型就需要它。

这并不是唱反调。Google 的 Rules of Machine Learning （在新标签页中打开）——它面向 ML 工程师的内部指南——开篇就是一句直白的指令：「不要害怕在没有机器学习的情况下发布产品」。

理由是：一条简单的经验法则就已经能拿到大部分价值。只有当这些规则复杂到难以维护时，机器学习才值得上场。

出现以下情况时，常规工作流通常是更好的答案：

• 规则写得下来，并且能与流程负责人达成一致
• 同样的输入应当始终得到同样的输出
• 答错的代价很高，而正确答案事先就可知
• 必须有人能准确解释系统为什么这么做
• 数据已经结构化、经过校验且完整

当输入杂乱、难以预测、或者很难用固定规则框住时，AI 才值得上场：

• 总结长文档、会话串或通话记录
• 对措辞差异很大的自由文本消息做分类
• 从从不遵循单一模板的文档中抽取字段
• 帮助一个人探索信息，而不是替他做决定
• 起草一份由人复核和编辑的初稿

第二类的共同点是：人始终留在流程之中。输出是草稿、建议或起点，而不是最终决定。

这类功能通常最先在这里挣得自己的位置。

先问对问题

第一个问题不是「我们该用哪个模型」。请改问：「用户应该能做什么，不确定性又在工作流的哪一步进来？」这个答案决定了 AI 是否属于这款产品。

动手之前，先定好什么算好结果。一份草稿摘要，也许人快速看一眼就够；而软件自己做出的决定，可能需要更严的管控、清楚的解释，以及能安全叫停或纠正的办法。

NIST 的 AI Risk Management Framework （在新标签页中打开）——2023 年 1 月作为自愿性指南发布——把这一点说得很清楚。在它列出的可信系统特性中， 有效且可靠 是「可信性的必要条件」。

它是其他特性赖以成立的基础。一项令人惊艳却不可靠的功能，还没跨过第一道门槛。

在拍板之前该问的问题

如果有人提出一项 AI 功能，一份简短的问题清单通常就能把深思熟虑的方案和一腔热情的方案区分开：

1. 这在做什么任务？不用 AI 我们会怎么做？
2. 答错会让用户付出什么代价？谁最先察觉？
3. 这项功能会看到哪些数据？这些数据流向哪里？
4. 上线前我们怎么测？上线后多久测一次？
5. 当模型不可用或没有把握时，产品会怎么做？
6. 在当前十倍的用量下，这项功能每位用户每月要花多少钱？

这些问题都不需要技术背景才能提出，但每一个都很难在没有技术背景的情况下答得让人信服。

为人工复核而设计

人工复核不是一句含糊的安全口号。请给复核者足够的上下文去核对输出、一条清晰的编辑路径，以及一条能让产品团队去追查故障的反馈通道。

成熟的框架要求的是能在文件里指出来的监督，而不是打算去做的监督。

NIST 框架的 Map 功能要求「用于人工监督的流程，须按照组织政策加以定义、评估并记录」。

在欧盟， Article 14 of the AI Act （在新标签页中打开） 要求其高风险类别中的系统在设计上「能够在使用期间由自然人进行有效监督」。

并不是每款产品都落入那个类别。但早在它成为法律义务之前，这条设计原则就已经是一个合理的默认。

安全方面的指南也是同样的看法。 OWASP Top 10 for LLM Applications （在新标签页中打开） 把 Excessive Agency 列入其 2025 年的风险清单。

它建议的缓解措施很直接：「采用人在回路的控制，要求高影响操作在执行前先由人批准」。

如果一项功能能够自行花钱、发送消息或改动记录，那道审批步骤就是开发的一部分，而不是以后再做的加固工作。

动手之前先定数据规则

数据访问与隐私必须是设计的一部分。请确认这项功能会收到哪些信息、在哪里处理、保留多久，以及哪些人或系统可以访问其结果。

OWASP 把 Sensitive Information Disclosure （在新标签页中打开） 列为其 2025 年 LLM 风险的第二位。它的指引可以归结为一条大多数团队都懂、却在赶工期时略过的规则：「依据最小权限原则限制对敏感数据的访问」。

模型只是又一个能接触到用户信息的系统，也应当按同样的方式限定其范围。

各家厂商都公布了具体条款，而这些条款的差别大到值得在意。设计定型之前，有三份值得一读：

• 用于训练。 OpenAI 的 数据控制文档 （在新标签页中打开） 写明「发送至 OpenAI API 的数据不会用于训练或改进 OpenAI 的模型」，同时另有一段用于滥用监测的保留期。
• 数据保留。 Anthropic 的 数据保留文档 （在新标签页中打开） 把零数据保留描述为：响应返回之后，提示词与回复不会被静态存储。其自身的适用范围表把有状态的功能列为例外，因此零保留并非一概而论。
• 推理在哪里运行。 地域可以配置，并单独计价。Anthropic 的 数据驻留文档 （在新标签页中打开） 指出，仅在美国境内推理「按标准价格的 1.1 倍计费」。

如果产品处理欧盟境内人员的个人数据，设计阶段的义务就是明文规定的。

欧盟委员会关于 数据保护的设计默认原则 （在新标签页中打开） 的指引指出，各组织「应确保个人数据在默认情况下以最高的隐私保护水平被处理」。

这是在集成之前作出的决定，而不是在事故之后。

规划每位用户的成本

不要因为第一次试验很便宜，就以为托管的 AI 服务是免费的。用量、存储、监控、重试、复核时间以及将来的模型更换，都会影响运营成本。

AI 厂商通常按处理的文本量计费，因此成本随使用量增长，而不是随人数增长。

这些杠杆就写在厂商自己的 定价文档 （在新标签页中打开）里：模型选择、提示词缓存、工具调用带来的额外 token，以及批处理。Anthropic 的 Batch API 对异步任务提供「输入与输出 token 均打五折」。

一项按全价算不划算的功能，在任务不必即时完成时也许就行得通。

这里还有安全的一面。OWASP 的 Unbounded Consumption （在新标签页中打开） 条目描述了「攻击者通过发起大量操作，利用云端 AI 服务按次计费的模式」。

这有时被称为「钱包耗尽」。速率限制、配额与用量监控，属于第一个版本，而不是第二个。

先用真实样本测试

在宣布功能就绪之前，先做一个小的测试集。用有代表性的样本，纳入困难案例，并记录那些对最终使用者真正要紧的错误类型。

两家主要厂商都把这当作先要做的事，而不是事后再补的东西。

Anthropic 关于 构建实证评估 （在新标签页中打开） 的指引，对一个有用的评估集应有的样子说得很具体：「针对具体任务：设计能反映你真实任务分布的评估。别忘了把边界情况算进去！」

OpenAI 的 评估指南 （在新标签页中打开） 把同一实践表述为：理解一个应用相对于预期表现如何。正是这一点让更换模型或提示词的改动可以安全上线。

一次有用的评估不必预测每一个回答。它只需说明这项功能对目标任务是否有帮助、在哪里会失败，以及工作流何时必须把控制权交还给人。

评估同样不会止步于上线。微软的 可观测性指南 （在新标签页中打开） 描述了生命周期如何延续到生产环境，其中包括「按抽样比例对生产流量做质量与安全评估」。

真实使用中出现的输入，一定有你的测试集从未设想过的。

规划兜底方案

兜底方案同样需要务实的设计。当模型不可用、太慢或没有把握时，产品仍应说明用户接下来能做什么，而不是留下一片空白或一个误导性的答案。

请事先决定这项功能在三种情形下的行为：模型没有返回可用结果时、请求超时时，以及置信度很低时。

每一种都是对用户可见的产品决定。每一种放到现在来定，都比在事故当中便宜。

同样值得决定的是：将来更换模型或厂商会有多容易。保留提示词、评估集，以及产品与模型之间一层薄薄的接口，就保住了这个选项。

一个具体的例子

把它落到实处：想象一个被来信淹没的客服团队。每一封邮件都要读、要分类、要转给合适的人，而邮件量已经超出了这些人的处理能力。

第一反应是去找一个能读每封邮件并作答的 AI 智能体。不妨先让它过一遍上面那些问题。

任务是什么？不用 AI 我们会怎么做？ 按关键词和发件人分流，已经能处理清楚的情形。难的是那些含混的自由文本消息——恰恰是适合模型的形状。

答错的代价是什么？ 转错一封邮件损失的是几分钟。而一封自动回复凭空编出一条退款政策，代价要大得多。所以安全的第一版只建议分类并起草，仍由人来发送。

我们怎么测？ 几百封已经处理完的邮件就是评估集，并有意把杂乱和罕见的那些放进去。如果建议的分类正确率高到能省下阅读时间，它就挣得了自己的位置。

最终上线的功能很窄：分类加起草，由人发送，关键词规则继续处理显而易见的情形，并且全程记录，让评估集不断变大。

这比团队最初设想的那个智能体更小、更安全、更便宜——也更可能在真实收件箱里存活下来。

决定要做什么

用 AI 来做东西，和把 AI 装进产品里出货，是两个不同的决定。开发者可以一边用 AI 工具写代码，一边交付一个跑在普通软件上、跑在 AI 功能上，或者两者兼有的产品。

对一款新产品，先决定最小的有用工作流。只有当一项 AI 功能能为某个明确的用户改进这条工作流，并且能用团队维护得住的证据加以检验时，才把它加进来。

最扎实的 AI 产品方案，对自己的边界很明确。在这项功能变成承诺之前，它已经点名了任务、数据、复核者、兜底、评估方法与成本假设。

如果你正在 AI、自动化和定制软件之间权衡，请早一点把这个决定带进规划的对话里。正确答案可能是 AI，可能是一条基于规则的工作流，也可能是不引入任何新技术。