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

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

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

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

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

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

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

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

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

这周我试了一个偏“小而快”的模型，本来只是想验证它能不能扛住基础分类任务。结果最有价值的发现并不是“它比大模型便宜”，而是它在一个被约束得很清楚的场景里，稳定性反而比我预期更好。

当时的任务非常简单：把用户问题分成几个固定类别，再把结果交给后面的规则链路处理。这个任务没有复杂推理，也不要求长文本生成，真正重要的是输出稳定、延迟低、格式不要乱。

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

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

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

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

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

我发现 AI 项目最容易产生错觉的阶段，就是 Demo 成功之后。团队通常会在那一刻异常兴奋：模型能答、流程能跑、页面也有了，于是大家很自然地认为“离上线不远了”。可真正做过几轮交付之后就会知道，从 Demo 到上线，中间隔着的不是几个小优化，而是一整层工程现实。

Demo 的目标是证明“这件事有可能”；上线的目标是证明“这件事在真实流量、真实错误、真实业务约束下还能稳定工作”。前者看效果，后者看系统。

所以我现在评估一个 AI 项目，往往不会问“Demo 是否惊艳”，而是问：这个功能在失败时会发生什么，在高峰时会发生什么，在知识变旧时会发生什么，在模型波动时会发生什么，在业务追责时又该怎么解释。

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

这次失败实验发生在一个看起来很“稳”的场景里。我们当时做的是一段常见的知识问答链路：用户提问，系统从知识库里取回上下文，再让模型给出总结式回答。小样本测试时效果不错，前十几个问题几乎都能答到点上，所以团队一度觉得这个方向很顺。

但把样本放大一点之后，结果开始明显飘了。同样的提问方式，今天答得不错，隔几小时再测一次，回答里的重点就会变化；换一个近义表达，答案会突然把次要信息讲得很重，真正关键的结论反而变淡。

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

企业知识库是过去一年我见过最多的 AI 落地入口之一。几乎每个团队在讨论 AI 能做什么的时候，都会很快想到它：把文档喂进去、把制度接进去、把 FAQ 接进去，然后做一个“问什么答什么”的系统。这个方向当然成立，但也正因为看起来太成立了，大家很容易低估它背后的难度。

我现在一听到“我们想做一个企业知识库”，脑子里不会先出现模型，也不会先出现向量库，而是先出现七个问题。只要其中有几项答不清楚，我就不会建议直接开工。因为很多知识库项目，不是死在技术实现上，而是死在一开始的问题定义就不清楚。

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

很多团队在做 RAG 优化时，容易把问题切成几个独立模块来看：Chunk 怎么切、检索怎么召回、重排怎么加、最后模型怎么答。表面上看这很合理，因为技术栈确实也是这么拆开的。但真正调过一轮系统之后就会发现，这几个环节并不是并列关系，它们是串联关系，而且前一个环节的决策会强烈限制后一个环节的上限。

也就是说，很多 RAG 项目效果不好，不是某一个组件单独弱，而是顺序没想清楚：一开始切分就把信息结构破坏了，后面再怎么改召回和重排，都只能在一堆不完整片段里做“最优选择”。

所以我现在更在意的是这条链路的顺序：先怎么切，再怎么召，再怎么排，最后才轮到模型组织答案。

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

这篇短更记录一个很典型的失误：我把一个原本表现还算稳定的 Prompt 模板，越改越复杂，最后亲手把它改坏了。

当时出发点完全没问题。我只是想让结果更完整一点、更礼貌一点、格式更统一一点，于是不断往模板里加约束、加示例、加例外说明。每次改动都显得很合理，但累积到一起之后，模板开始越来越重，输出反而变得更飘。

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

大模型幻觉一直是个高频话题，但我越来越觉得，真正难缠的不是“模型会不会出错”，而是“系统知不知道它正在出错”。前者是模型能力边界，后者是工程设计问题。只要是概率系统，出错几乎不可避免；但一个能不能上线、能不能长期维护的 AI 功能，关键在于它出错时是否能被识别、被限制、被回收。

很多团队会把幻觉理解成一个纯模型问题，于是自然会把主要精力放在换模型、换 Prompt、加限制词上。可真正进入业务之后，最危险的往往不是明显胡说八道，而是那种“看起来很像对、实际上悄悄偏了”的结果。因为这类错误更难被用户第一时间看穿，也更容易混进流程。

所以我现在的看法是：幻觉并不可怕，可怕的是系统既没有提前识别风险的机制，也没有在出错时给出信号。