这段时间看 AI 圈，会有一个很明显的感觉：
模型越来越便宜了。
也越来越快了。
Google 有 Flash / Flash-Lite 这类速度和成本优先的模型分层，阿里 Qwen 这类开源模型持续降低企业试错门槛，Anthropic 也把 Claude Science 这类工作台产品推到更垂直的科研场景里。
这些事情不是同一类新闻。
但放在一起看，会指向同一个问题：
当模型调用不再总是贵到只能省着用，AI 应用团队到底应该重新思考什么？
我的答案是：
不是只重算 token 单价。
而是重算产品边界。
尤其是做企业级 AI 应用，特别是 B2B 电商这类业务链路长、角色多、验收复杂的场景，如果只把它理解成又便宜了一点，很容易低估后面的变化。
先记住三句话
对大部分应用团队来说，模型成本下降以后，最先变化的是三件事：
- 原来不敢调用的地方，会变成可以常驻的能力。
- 原来只做 demo 的链路，会变成可以进主流程的能力。
- 成本问题不会消失，只是从 token 账单，转移到延迟、稳定性、评估、人审和团队协作上。
第 3 点最容易被忽略。
也是最容易踩坑的。
很多团队一开始算 AI 成本，会本能地打开一个表格：
token 单价。
调用次数。
用户量。
一乘。
账单出来了。
看起来很科学。
但这个算法太粗了。
企业级 AI 应用不是这么算的。
一、模型贵的时候，大家会下意识省着用
我之前看很多 AI 产品方案，有一个很典型的现象：
大家会把模型调用当成一个奢侈动作。
能不用就不用。
能少调就少调。
能让用户点按钮触发，就不要后台自动跑。
这背后的逻辑很正常。模型贵的时候，每一次调用都是成本，每一次调用都可能拉高延迟，每一次调用都可能让老板问一句：
这个钱花得值吗？
于是很多 AI 能力会被设计成辅助按钮。
比如：
- 商品标题旁边放一个 AI 优化
- 客服回复框旁边放一个 AI 生成
- 经营分析页面放一个 AI 解读
- 内容发布页面放一个 AI 改写
用户点击。
模型工作。
结果返回。
这个设计没有问题，甚至是很多团队的第一步。
但它有一个隐含前提：
AI 是工具，不是流程。
工具是被调用的。
流程是持续运转的。
这两者差别很大。
当模型调用成本下降到一定程度后，我们就可以问一个新问题：
哪些地方不应该再等用户点击？
哪些地方应该让 AI 变成默认的后台能力？
比如，一个 B2B 商品发布流程里，AI 不一定只是在用户点按钮时帮他润色标题。它可以在用户录入商品信息时，实时发现参数缺失、类目不匹配、卖点表达不清、图片与描述不一致。
比如，一个商家经营后台里，AI 不一定只是在用户点分析时生成一段总结。它可以每天扫一遍异常指标，把真正值得看的问题推到人面前。
这不是多加几个按钮。
这是产品边界变了。
二、AI 会从页面功能变成系统能力
我粗暴地把 AI 应用分成两类：
第一类，页面功能。
第二类，系统能力。
页面功能很好理解。用户看得到一个入口，点一下，AI 给结果。这个阶段最适合验证需求，也最容易做出 demo。
系统能力就复杂多了。它不一定有明显入口，甚至用户不一定知道背后调了模型。
它更像一个后台同事。
每天上班。
默默巡检。
发现异常。
写好草稿。
等人确认。
这里有个小剧场。
产品经理说：我想加一个 AI 助手。
研发同学说：入口放哪里？
算法同学说：提示词谁写？
运营同学说：结果不准谁背锅？
老板说：上线后能提升多少？
然后会议室安静了三秒。
最后大家做了一个聊天框。
不是聊天框不好，而是聊天框太容易成为团队的心理安全区。它边界清楚，责任清楚，出了问题也好解释：用户自己问的，AI 自己答的。
但真正有价值的企业级 AI，很多时候不是聊天框，而是嵌在流程里的判断、生成、推荐、校验和编排。
以前一次任务只能调一次模型，现在可能可以调三次：
一次做理解。
一次做生成。
一次做校验。
以前只能在核心链路末端做总结，现在可能可以在链路前中后都做辅助。
但这也意味着，AI 不再是一个孤立功能。
它会进入产品主流程。
进入主流程，就要接受主流程的要求：
稳定。
可控。
可解释。
可回滚。
可评估。
三、token 便宜了，不代表总成本便宜了
这是我最想提醒的一点。
模型厂商降价之后，很多人第一反应是：
太好了，成本问题解决了。
答案没这么简单。
token 成本只是显性成本。
真正把 AI 应用从 demo 推到生产，后面还有一堆隐性成本。
1. 延迟成本
用户能不能等？
后台任务能不能排队？
同步链路能不能接受模型抖动？
如果一次调用变成三次调用，单次 token 便宜了，但端到端延迟可能上去了。延迟一上去，产品体验就变了。
2. 评估成本
模型输出不是传统函数。
今天看起来不错，明天换个输入就可能跑偏。
所以你要有评估集，要有人工抽检，要有线上监控，要知道哪些 bad case 能接受，哪些绝对不能接受。
我见过一个很典型的场景：
算法同学跑离线评测，核心指标已经达到预设阈值了。
从模型视角看，挺好。
从评测报表看，也挺好。
然后拿给业务一用，业务同学皱眉：
这个不太行。
这时候，问题才真正开始。
这里不是谁不专业，而是评估口径不一样。
bench 评估的是一组被定义出来的任务、样本分布和打分规则；真实业务评估的，则是模型在用户现场能不能稳定解决问题。
这中间经常隔着一层分布偏移：
脏数据。
残缺信息。
表达不规范。
上下文缺失。
还有一些很难写进测试集的隐性规则。
算法看的是指标。
业务看的是能不能交付。
这两个东西不天然等价。
所以 AI 能力进生产前，不能只问 bench 过了吗，还要问三个问题：
- 评估集是不是覆盖了真实业务分布？
- 业务不能接受的 bad case 有没有单独拎出来？
- 算法指标和业务验收之间，有没有一张翻译表？
所谓翻译表，就是把技术指标翻译成业务决策：
什么结果可以灰度。
什么问题必须一票否决。
什么场景只能给建议不能自动执行。
什么结果必须进入人审。
没有这张翻译表，bench 分数越漂亮，争论可能越大。
3. 人审成本
很多企业场景不能完全自动化。
尤其是涉及商家经营、交易、合规、客服、内容发布的时候，AI 给建议可以，AI 直接替人做决定就要谨慎。
这时你会发现，模型越便宜，生成内容越多，人审压力可能越大。
AI 很勤奋。
人类很累。
最后压力还是回到人身上。
4. 协同成本
AI 应用不是算法团队一个人的事。
它通常需要产品定义场景，前端嵌入交互，后端接入链路，算法调模型，数据做评估，运营给规则，业务给反馈。
而且 AI 应用有一个跟传统互联网产品很不一样的地方：
业务和产品往往没办法一开始就把产品能力边界和验收标准定义得特别清楚。
传统功能相对好办。
按钮点了，状态变了。
表单提交，数据入库。
搜索条件命中，列表刷新。
大家对什么是对、什么是错，比较容易达成共识。
AI 应用不一样。
业务说：这个效果不好。
产品说：那我们优化一下体验。
算法说：离线指标还可以，但可能是评估集没覆盖到这类 case，也可能是线上分布变了。
工程说：那我们先把链路拆开看：输入数据、检索上下文、prompt / skill、工具调用、后处理、交互日志，哪个环节能复现这个问题？
场面一度很安静。
这就是 AI 项目里最容易卡住的地方：不是大家不努力，而是问题归因变复杂了。
一个结果不好，可能是模型能力边界问题，可能是评估集没有覆盖，可能是检索上下文不完整，可能是 prompt / skill 没讲清楚，可能是工具编排或后处理出了问题，也可能是业务验收标准本身还没定义清楚。
所以多工种协作时，最先要补的不是某个技术方案。
而是一套共同语言。
什么叫可用？
什么叫好？
什么叫不能上线？
什么问题归模型，什么问题归链路，什么问题归业务规则？
这些不说清楚，团队就会进入一种很消耗的状态：每个人都在优化自己那一段，但整体效果还是没有人能拍板。
四、产品边界应该怎么重算？
如果模型成本持续下降，应用团队应该怎么做？
我建议不要一上来就问：
我们要不要把所有地方都 AI 化？
这个问题太大，也太容易把团队带偏。
更好的问法是：
哪些任务过去因为成本、延迟或稳定性原因被挡在门外，现在可以重新评估？
可以从四类任务开始看。
第一类，高频低风险任务。
比如草稿生成、摘要、标签推荐、字段补全、表达润色。这类任务适合更早铺开，因为错了可改，人可以接管。
第二类，低频高价值任务。
比如复杂经营诊断、客户机会分析、商品结构优化建议。这类任务调用频率不一定高，但每次价值可能很大，适合用更强模型。
第三类，后台巡检任务。
比如异常检测、内容质量扫描、信息完整性检查。这类任务过去如果每条都调模型，成本可能不划算。成本下降后，可以从抽样变成更高覆盖率。
第四类，多步推理任务。
比如先理解用户意图，再检索业务知识，再生成建议，再做自检。这类任务以前最怕贵，因为一次用户请求背后可能有多次模型调用。模型便宜之后，它的产品空间会变大。
但每一类都要加一句括号：
能做，不等于应该马上做。
企业级产品里，最怕的不是没有 AI。
最怕的是到处都是 AI，但没有一个能稳定解决问题。
看起来很热闹。
实际只是多了很多入口、提示词和维护成本，用户不知道该信哪个，团队也很难说清楚哪个能力真正改善了主流程。
五、技术负责人要补一张新表
过去我们做项目评估，常见几张表：
需求优先级。
研发排期。
资源投入。
收益预估。
到了 AI 应用这里，我建议技术负责人额外补一张表：
AI 能力成本表。
但这张表不只写 token。
至少要写 7 个字段：
- 单次模型成本：这只是第一列，不是结论。
- 调用频率：用户触发、后台定时、全量扫描，完全不是一个量级。
- 端到端延迟：尤其要看同步链路。
- 错误代价：错了是用户笑笑，还是业务事故。
- 人审比例：多少结果必须人确认。
- 评估方式：离线评测、线上抽检、用户反馈、规则校验怎么组合。
- 降级方案：模型不可用、结果不可信、成本超预算时怎么办。
这张表一出来，很多争论会变得清楚。
产品说：这个能力很酷。
技术说：酷，但同步链路扛不住。
业务说：这个能帮我省人。
技术说：可以，但先定义哪些场景必须人审。
老板说：模型不是降价了吗？
技术说：降了，但错误代价没降。
这时候讨论就从要不要做 AI，变成在哪个边界内做 AI。
这个变化很关键。
我现在更倾向于用一个两段式口径来判断 AI 能力要不要进主流程。
第一段，上线前判断。
先看数据，再做用户调研。
数据告诉我们：这个问题是不是高频，是不是影响主流程，是不是值得投入。
用户调研告诉我们：这个问题在真实使用里到底痛不痛，用户愿不愿意把这一步交给 AI，交给 AI 以后他担心什么。
如果数据上不高频，用户也不觉得痛，那它更适合做成辅助能力，而不是进主流程。
第二段，上线后复核。
能力上线以后，不要急着宣布胜利。要继续看线上效果数据和用户反馈，判断它对用户体验和业务效果是不是正向。
用户有没有真的用？
用了以后有没有继续用？
结果有没有被采纳？
有没有带来新的投诉、误解或人工负担？
这一步很重要。因为 AI 能力经常会出现一种错觉：
演示时很惊艳。
真实使用时很安静。
安静到你以为它在工作。
其实用户已经绕开它了。
所以是否进主流程，不应该只靠立项时的想象，也不应该只靠一次模型评测。
它应该是一个闭环：
上线前用数据和调研判断值不值得做，上线后用效果和反馈判断该不该继续放大。
结尾
这轮模型成本下降，对 AI 应用团队肯定是好事。
门槛降了。
试错空间大了。
很多过去因为成本原因放在 backlog 里的想法，可以重新拿出来看。
但我更想说的是，不要只盯着价格表。
价格下降只是开始。
真正的机会在于：我们能不能重新理解产品边界。
过去 AI 是一个按钮。
后来 AI 是一个助手。
再往后，AI 可能会变成系统里默认存在的一层能力：
理解。
生成。
检查。
推荐。
编排。
兜底。
它不一定总是站在台前。
但会越来越多地参与后台流程。
对应用团队来说，接下来拼的不是谁更早接入某个新模型。
而是谁能把模型成本、产品体验、业务风险和团队协作放在一张图里，算清楚。
便宜很重要。
但边界更重要。
AI 应用真正进入生产，拼的从来不是一时热闹。
是持续把账算明白。