跳到主要内容

2025 年做 AI 应用，为什么重点已经不是 Prompt

· 阅读需 7 分钟
一介布衣
一介布衣
全栈开发者

如果只允许我用一个真实项目来解释这个标题，我会选“售后助手”。

这个项目最早的需求很朴素：让客服在处理退款、催发货、优惠券争议这些问题时，能更快给出初步答复。我们第一版做法非常典型，也很像过去两年大多数团队的自然选择：写一版足够强的 system prompt，把常见规则塞进去，再给一些 few-shot 示例，让模型看起来像一个经验丰富的客服。

第一轮演示效果甚至很好。模型能说人话，语气也像样，面对常见问题能给出八九不离十的回答。于是团队很容易得出一个结论：看起来只要继续打磨 Prompt，就能把它推到生产。

真正的转折发生在灰度阶段。我们发现，问题并不是“Prompt 不够强”，而是它被要求承担了太多本不该由它承担的事情：记住不断变化的活动规则、理解订单状态、引用最新制度、决定什么时候必须转人工、在失败时保持输出稳定。做到这一步之后，我才真正意识到，2025 年做 AI 应用，Prompt 仍然重要，但它早就不是主战场了。

把问题都推给 Prompt，通常会在 4 个地方一起崩​

在这个售后助手的例子里，我们最初确实试过“继续打磨 Prompt”这条路。方法也很典型：

  • 把退款规则直接写进 system prompt
  • 加入十几个示例问答
  • 要求模型必须礼貌、简洁、像人工客服
  • 要求无法确认时给出保守回答

前几天效果挺好，但一进灰度就暴露出 4 类问题。

1. 规则一变，Prompt 就过期​

活动规则、优惠券门槛、售后时效，只要改一点，Prompt 就要跟着改。问题不只是“麻烦”，而是你很难保证所有相关 Prompt 都同步更新。

我们当时就出现过这种错：客服政策已经从“签收后 7 天可退”改成“部分类目 15 天可退”，但模型因为还拿着旧 Prompt，在灰度期间连续答错了三次。

2. 该查系统状态时，Prompt 根本帮不上忙​

用户问“我的订单到底有没有发货”“这张券为什么不能用”“上次申请退款现在到哪一步了”，这些都不是语言问题，而是系统状态问题。

只要答案依赖实时数据，Prompt 再长也只能装懂，不能真查。

3. 输出稳定性会越来越差​

Prompt 一旦同时承担规则、语气、格式、边界和异常说明，模型就会在多个目标之间摇摆。你会看到：

  • 今天强调退款条件
  • 明天强调安抚话术
  • 后天又把“转人工”埋得很深

这不是模型突然变笨，而是 Prompt 被塞成了一个大杂烩。

4. 出错时根本不知道错在哪​

如果系统只有“用户输入”和“模型输出”，那一旦结果不对，你几乎没法回答：

  • 是 Prompt 版本的问题？
  • 是知识过期？
  • 是检索没命中？
  • 是工具没查到？
  • 还是这次本来就该转人工？

这才是 Prompt-only 方案最致命的地方。它让错误变得不可定位。

这个项目后来真正稳定下来，靠的是把链路拆开​

我们后来没有继续堆 Prompt，而是把链路拆开。

先看一条更像真实系统的执行路径：

用户问题
  -> 意图识别
  -> 判断是否需要实时数据
  -> 查订单 / 查优惠券 / 查知识库
  -> 模型组织回复
  -> 结构化校验
  -> 人工兜底或直接返回

这条链路里，Prompt 不再承担“记住一切”的责任，而是承担三件更清晰的事：

  • 说明当前任务是什么
  • 说明输出格式和语气
  • 说明在信息不足时必须明确说不确定

它的角色从“万能大脑”退回成“指令层”，反而让系统稳定了。

一个更接近上线的版本，责任分布应该很清楚​

后来我们把售后助手收敛成下面这类逻辑：

async function handleSupportMessage({userId, message}) {
  const intent = await classifyIntent(message)

  if (intent.type === 'order_status') {
    const order = await orderService.getLatestStatus(userId)
    return buildOrderReply(order)
  }

  if (intent.type === 'coupon_rule') {
    const kb = await knowledgeService.search('coupon-policy', message)
    const draft = await llm.generate({
      system: '你是售后助手，只能根据提供的上下文回答，无法确认时必须明确说明。',
      input: message,
      context: kb,
      schema: supportReplySchema,
    })

    return validateReply(draft).ok ? draft : handoffToHuman(message)
  }

  return handoffToHuman(message)
}

真正关键的变化不是这段代码写得多漂亮，而是职责分清了：

  • 实时状态交给系统查
  • 变动知识交给检索层
  • 模型只负责组织答案
  • 结果不稳时直接兜底

这时候 Prompt 才终于回到一个合理的位置。

2025 年为什么这种变化会更明显​

因为 2025 年做 AI 应用，团队关注的已经不只是“模型会不会说话”，而是“它能不能接进真实系统并长期运行”。

一旦项目进入真实业务，几个问题就会同时出现：

  • 知识会变
  • 工具会超时
  • 输出要进系统
  • 成本需要看
  • 错误需要回放

这些事情没有一件是单靠 Prompt 能解决的。

所以“Prompt 不再是主战场”并不是一句口号，而是项目进入工程化后的自然结果。

Prompt 当然还值得认真做，只是不该继续包打天下​

当然值得，但只在它擅长的地方认真做。

我现在更愿意把 Prompt 的价值收敛成三件事：

1. 明确任务边界​

例如这次到底是做分类、抽取、解释还是草稿生成。

2. 约束输出行为​

例如必须 JSON、必须引用上下文、必须在不确定时拒答。

3. 统一产品口径​

例如客服助手统一语气、统一边界、统一转人工表达。

只要超出这三件事，我都会优先考虑把责任外置到：

  • 检索层
  • 工具层
  • 校验层
  • 工作流层

这一步对我来说，不是“弱化 Prompt”，而是把它从一个总包角色拉回到系统里更合理的位置。

现在如果还想继续只改 Prompt，我会先过这张判断清单​

如果今天还有人问我“是不是继续打磨 Prompt 就够了”，我会先让他过这张表：

1. 这个问题需要实时数据吗​

如果需要，先接工具，不要只改 Prompt。

2. 这个问题依赖变化中的知识吗​

如果依赖，先做检索和知识治理，不要只改 Prompt。

3. 结果要不要进入系统流程​

如果要，先定义结构化输出和校验，不要只改 Prompt。

4. 出错代价高不高​

如果高，先设计人工兜底和回退，不要只改 Prompt。

5. 出错后能不能定位​

如果不能，先补日志和评测，不要只改 Prompt。

我真正想保留的结论​

“2025 年做 AI 应用，为什么重点已经不是 Prompt”这个判断，不是因为 Prompt 失去了价值，而是因为项目一旦从 Demo 进入灰度和生产，真正拖后腿的往往不是提示词技巧，而是知识、工具、校验、观测和回退。

Prompt 依然要认真写，但它不该再承担整个系统的复杂度。谁越早把 Prompt 从“万能解法”降回“系统组件”，谁的 AI 应用就越有机会真正跑起来。