补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-01-08 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去一年我最常被问到的问题，不是“哪个模型更强”，而是“这个业务值不值得接大模型”。我后来发现，很多团队在这个问题上其实一开始就走偏了，因为他们问的是“技术上能不能做”，而不是“产品上值不值，工程上扛不扛得住”。
为了让这个判断不继续停留在口头经验里，我后来逼自己把它压成一张更像决策表的东西。它不保证你每次都选对，但至少能逼着团队先面对代价，而不是只盯着 Demo 效果。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-01-10 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这周我试了一个偏“小而快”的模型，本来只是想验证它能不能扛住基础分类任务。结果最有价值的发现并不是“它比大模型便宜”，而是它在一个被约束得很清楚的场景里，稳定性反而比我预期更好。
当时的任务非常简单：把用户问题分成几个固定类别，再把结果交给后面的规则链路处理。这个任务没有复杂推理，也不要求长文本生成，真正重要的是输出稳定、延迟低、格式不要乱。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-04-02 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只讲原则，这篇文章还是会显得空。所以我直接拿一个真实得不能再真实的例子来说：退款工单分诊。
这类任务的目标通常是把用户自然语言输入转成一个后续系统能继续处理的对象，例如：
团队最早的做法很常见：先让模型直接输出一段 JSON，大概长这样：
{
"title": "用户申请退款",
"summary": "用户表示重复支付，希望退款",
"tags": ["退款", "重复支付"]
}
看上去没毛病，前端也能展示，测试样本甚至都能过。但真正进系统后，这种 Schema 很快就会把问题暴露出来：它描述了内容，却没有描述动作边界。
真正让系统难受的不是模型会不会吐 JSON，而是下游根本不知道怎么用这个结果继续执行。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-09 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
AI 功能一旦进入真实流量，成本问题迟早会从“财务关心的事情”变成“工程必须立刻处理的事情”。最麻烦的是，它通常不会一开始就用一种非常明显的方式爆炸，而是会先通过一些不太起眼的信号慢慢浮上来。等到大家真正感觉到痛，往往已经不是“优化一下”能解决的程度了。
我现在看 AI 接口成本是否快要失控，不会先看总账单，而会先看系统里有没有出现下面三个信号。它们一旦出现，就意味着网关层和调度层必须尽快补队列、缓存和限流，不然越往后越被动。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-16 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只选一个真实场景来解释这篇文章，我会选“客服混合链路”。
这个链路里同时存在三类请求：
项目最初为了省事，几乎所有请求都默认走最强模型。早期流量小，大家只觉得“效果不错，就是稍微贵一点”。但一旦请求量上来，问题很快暴露：
这也是我后来越来越笃定的一点：不是所有请求都要走最强模型。模型分层不是为了抠预算，而是为了让系统真正进入可运营状态。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-21 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队第一次做 AI 成本复盘时，最先盯住的都是一个总数：这周花了多少钱，比上周多了还是少了。
这个数字当然重要，但它几乎永远不够解释问题。
我后来越来越相信，AI 成本看板如果只能回答“贵了没有”，那它对工程决策的帮助非常有限。真正有价值的是：这笔钱是被哪种请求、哪种失败路径、哪种系统漂移吃掉的。
前阵子我就碰到过一次很典型的情况：业务请求量几乎没变，但一周总成本突然涨了三成多。乍一看像是模型贵了，结果真正的问题根本不在模型单价。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-24 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队做 AI 应用时，最先花时间调的是模型和 Prompt，最晚补上的才是评测集。结果就是每次改完一版，大家只能靠感觉判断：
我后来基本不再接受这种“看起来顺一点”的判断方式。因为一旦系统要持续迭代，你迟早得回答一个很现实的问题：这次变更到底改善了什么，又伤害了什么。
所以我现在给 AI 应用搭第一版评测集，目标从来不是“做出一套完美 Benchmark”，而是先做出一套能指导下一次工程决策的小而准的样本集。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-31 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队一提到“评测”，脑子里其实混着三件完全不同的事：
它们都叫评测，但解决的问题并不一样。
如果边界没分清，团队就很容易出现两种典型混乱：
所以我现在会先把这三种方法当成不同阶段的不同工具，而不是互相替代的同一种东西。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-06 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多 AI 项目一旦进入评测阶段，最容易被一个数字绑架：准确率。
准确率当然重要，但我后来越来越少单独看它。因为在线上系统里，准确率高并不自动等于业务效果好。有时候它甚至会掩盖真正的问题。
一个最典型的例子，就是某类客服分流功能。离线看分类准确率挺高，团队一开始很满意。但上线后业务同学还是不买账，因为真正痛的地方并没有被解决：
也就是说，模型在“答题”这件事上可能不错，但业务在“运转”这件事上并没有变更好。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-10 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队把 AI 成本看板做成了另一种账单页面：
这些数字不是没用，但如果成本看板只能回答财务问题，它对产品和工程团队的帮助会非常有限。因为真正要做决策的人，通常更关心另外一些问题：
所以我现在越来越不把成本看板当“财务报表”，而把它看成一块产品控制面板。