我怎么判断一个业务值不值得接入大模型

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-01-08 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

过去一年我最常被问到的问题，不是“哪个模型更强”，而是“这个业务值不值得接大模型”。我后来发现，很多团队在这个问题上其实一开始就走偏了，因为他们问的是“技术上能不能做”，而不是“产品上值不值，工程上扛不扛得住”。

为了让这个判断不继续停留在口头经验里，我后来逼自己把它压成一张更像决策表的东西。它不保证你每次都选对，但至少能逼着团队先面对代价，而不是只盯着 Demo 效果。

我先拿 4 个真实需求做判断

为了避免这篇文章继续停留在抽象层，我先摆 4 个在团队里最常见的需求：

需求	第一反应	我的结论
查询订单是否签收	“可以做智能客服”	不该优先上大模型，先查系统状态
解释最新退款规则	“做问答助手”	可以上，但必须接知识源和引用
生成销售跟进摘要	“做总结助手”	很适合上，且收益明显
审批是否通过	“让 AI 给建议”	可以做辅助，但不能让模型拍板

只看这张表，你会发现一个关键事实：不是“业务和大模型契合不契合”这么简单，而是同样叫“智能化”，背后的问题结构完全不同。

我的判断方法不是一句话，而是一张决策矩阵

我现在会把一个需求放进 5 个维度里看：

维度	要问的问题	高分意味着什么
语言复杂度	输入是否高度依赖自然语言理解	越高越适合模型
正确性要求	出错代价是否很高	越高越不适合直接交给模型
知识时效性	答案是否依赖实时或频繁变更知识	越高越要接检索或工具
系统可替代性	规则/查库/搜索能否更简单解决	越高越不该先上模型
运维能力	团队能否做日志、评测、回收、回滚	越低越不该急着上

这张表的作用不是给出数学分数，而是逼团队承认：有些需求从业务上看很诱人，但从工程上并不值得做成 AI 能力。

一个我明确不会优先接大模型的例子

拿“订单是否签收”举例。

很多人看到客服场景就会本能想到大模型，但这个问题本质上只是：

• 识别用户订单号
• 查询订单状态
• 返回状态解释

其中只有“识别用户意图”这一小段和语言有关，真正答案来自数据库。这里如果上大模型做主路径，常见问题是：

• 成本更高
• 延迟更长
• 状态过期时更危险
• 用户对错误更敏感

所以我更愿意这样做：

async function handleOrderStatus(question, userId) {
  const extracted = await smallModelExtract({
    question,
    schema: {
      orderId: 'string | null',
    },
  })

  if (!extracted.orderId) {
    return '请提供订单号，我来帮你查询。'
  }

  const order = await orderService.getStatus(userId, extracted.orderId)
  return formatOrderStatus(order)
}

这里模型只负责抽参数，不负责生成事实本身。这个方案比“让大模型完整回答”更便宜，也更稳。

一个适合上的例子：销售跟进摘要

再看“生成销售跟进摘要”。

这个需求天然符合大模型擅长的部分：

• 输入是长文本、口语记录、聊天片段
• 输出是归纳、改写、提炼重点
• 允许一定概率性表达
• 出错代价相对可控

这种场景我就会给高分，因为它的核心确实是语言理解和总结，而不是确定性规则执行。

但即便如此，我也不会直接让它变成“生成完自动发给客户”。更合理的做法通常是：

• 先生成内部摘要
• 再让销售确认
• 最后才决定是否进入对外链路

这就是我经常说的：值得接大模型，不等于值得全自动。

一个最容易被误判的例子：制度问答

“解释最新退款规则”这种需求，是我最常见到团队判断失误的地方。

表面看它像问答，似乎很适合模型；但真正上线时会遇到两个硬问题：

• 知识一直在变
• 用户往往需要依据，而不是只要一句答案

这类需求如果要做，我通常默认不是“纯模型回答”，而是：

• 检索最新制度
• 把证据片段带给模型
• 输出时保留引用
• 没把握就拒答或转人工

也就是说，这不是一个“接不接模型”的问题，而是“模型在这条链路里处于什么位置”的问题。

最该克制的例子：审批建议

“用 AI 帮忙审批”听起来特别像提效项目，但我对这类需求通常最谨慎。

因为它经常同时具备几个危险条件：

• 错误代价高
• 责任边界模糊
• 历史口径不统一
• 最终判定必须有人担责

这类项目如果强行上大模型做主判断，很容易变成：

• 表面效率提升
• 实际上线风险陡增

更合理的姿势通常是让模型做：

• 材料摘要
• 风险点提示
• 缺失字段提醒

而不是让它做“审批是否通过”的最后决定。

我更看重的不是“能不能做”，而是“有没有更便宜的替代方案”

这可能是我和很多团队最大的分歧点。

我经常会先问一句：

这件事如果不用大模型，能不能被规则、搜索、数据库查询或人工流程更稳地解决？

如果答案是“能，而且明显更稳”，那我基本不会建议直接上大模型。因为这说明模型不是在补能力空白，而是在制造新的复杂度。

最后形成一个实际可用的决策清单

现在如果一个需求摆在我面前，我会按这 6 步快速判断：

1. 先问核心难点是不是语言理解。
2. 再问答案是不是依赖实时数据或变动知识。
3. 再问错误代价高不高。
4. 再问有没有更简单的替代方案。
5. 再问团队有没有评测、日志、回滚能力。
6. 最后才问选哪个模型。

顺序不能反。只要把“选模型”放到最前面，团队就很容易直接滑进技术兴奋，而忽略产品和工程代价。

总结

我怎么判断一个业务值不值得接入大模型？核心不是“模型能不能做出来”，而是：

• 它是不是语言问题
• 它值不值得承担概率性风险
• 它有没有更简单的替代方案
• 团队有没有能力把它长期托住

一个业务真正值得接大模型，不只是因为“模型能帮忙”，而是因为模型补的是系统真正缺的那块能力，而且补进去之后，系统仍然能稳。