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

过去一年，RAG 几乎成了大模型落地的标准答案。只要有人问“模型回答不准怎么办”，大家第一反应往往就是“上 RAG”。这条路线当然没有错，很多知识型场景确实该这么做。但我越来越警惕另一种倾向：把 RAG 变成条件反射，仿佛只要做 AI 问答，前面就必须先接一个向量库。

现实没有这么简单。RAG 不是一个按钮，而是一整套系统：文档清洗、切分、索引、召回、重排、上下文拼装、引用展示、评估和回放。只要其中一个环节没做好，最后用户看到的就不是“更智能”，而是“更复杂且更不稳定”。

所以我现在会先问：这件事真的需要检索增强吗？如果不需要，硬上 RAG 不仅没有收益，反而会把系统搞重。

这周我做了一轮很朴素的小模型实验。任务不复杂，就是把用户问题先分到固定类别里，再交给后面的规则链路处理。我原本只是想验证“小而快”的模型能不能扛住这类基础分类，结果最后最有价值的发现并不是成本更低，而是另一个更值得记住的事实：当问题边界足够清楚时，小模型往往比大家想象中更稳。

当时的任务很像很多团队都会有的第一层网关能力：先判断用户意图，再决定往知识检索、订单查询、人工转接还是普通 FAQ 解释去走。它没有复杂推理，也不追求文风，只要求三件事：标签别漂、格式别乱、延迟别太高。

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

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

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

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

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

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

商品列表一旦开始承载搜索、分类、品牌、价格区间和上下架状态，索引策略就会马上变成瓶颈。很多系统前期会本能地给几个常用字段都加索引，但到了真实查询组合场景里，效果常常并不理想。

支付回调是电商系统里最不能靠运气的一段链路。第三方会重试、网络会抖、人工也可能补触发，如果服务端没有幂等控制，订单状态、支付记录和库存侧影响很容易重复执行。

很多电商系统初期都会把购物车当成“订单的前半段”，这样做短期很快，但项目一复杂就容易出问题。购物车本质上服务的是选购过程，订单服务的是成交结果，这两个对象关注点本来就不一样。

订单系统走到线上以后，最容易失控的往往不是下单本身，而是订单状态怎么流转。待支付、已支付、已发货、已完成、已关闭这些状态只要边界没定清楚，后面退款、补发、人工改单一进来，服务逻辑就会越来越绕。

发布时间：2024-08-05
作者：一介布衣
标签：Feathers.js, Sequelize, 电商系统, 实战项目, 完整案例

发布时间：2024-07-30
作者：一介布衣
标签：Feathers.js, Sequelize, 高级查询, 性能优化, 事务