2025 到 2026 这段 AI 工程复盘：真正留下来的不是热点，而是控制机制
如果只看工具清单，2025 到 2026 这段时间变化确实很大。模型在换，供应商在换，RAG 方案在换，Agent 说法也几乎一季一变。可我回头看一圈，真正留下来的并不是那些当时最热的名词，而是几件特别“土”的事情：版本、评测、日志、回放、人工接管。
这不是因为这些词更高级，而是因为它们最后真的救过命。
我现在回忆这一段时间，印象最深的不是某个模型第一次答得多好，而是几次很具体的“被现实打回来”的时刻。
第一次被打醒：问题往往不在模型那一层
像 一次 RAG 检索命中率异常排查 和 一次向量库参数调整带来的召回变化 这类问题，最开始都特别像“模型最近怎么有点飘”。结果真查下去，问题根本不在最后那一层，而在召回、排序、索引元数据这些更靠前的位置。
这件事对我的影响很大。因为它直接把“AI 工程”从一种围着 Prompt 和模型打转的工作，拉回到一条更完整的链路里。之后再遇到异常，我已经很难再接受那种“一上来先调 Prompt 试试”的冲动了。
第二次被打醒：复杂度最先长在边界层
2025 年另外一个很明显的变化，是我越来越确信网关层和边界层往往比业务逻辑更早变复杂。像 Node.js 接 AI 服务时，为什么网关层比业务层更先复杂 里说的那些问题，后来基本都被反复验证了：
- 路由该怎么选
- 成本怎么控
- fallback 怎么做
- trace 怎么统一
- 权限怎么裁剪
这些问题刚开始很容易被误判成“后面再补”的基础设施，但现实是，只要请求真的跑起来，这层复杂度一定最先长出来。业务逻辑甚至还没来得及变大，边界层已经膨胀了。
所以后来我看很多架构讨论，第一反应已经不是“图画得顺不顺”，而是边界有没有被承认。
第三次被打醒：没有统一控制面，团队其实在各说各话
到 2025 年底以后，我对版本化、评测和回滚这几件事的态度明显比年初更激进了。原因很简单，只要 Prompt、工具、知识和评测不共享一套版本语言，团队内部迟早会进入一种特别熟悉的混乱状态：
- 前端说“这次是新版本”
- 算法说“模型没换”
- 业务说“上周还不是这样”
- 运维说“监控看起来也没问题”
表面上谁都没说错，但合在一起根本对不上现场。
这也是为什么后来我越来越认同 AI 团队统一 Prompt、工具、知识和评测：版本号、发布流和回滚点怎么设计 这个方向。组织提效的拐点，很多时候真不是“模型更强了”，而是终于开始说同一种变更语言了。
所以最后被证明值得长期保留的，其实就是这些东西
版本化
版本化最重要的不是管理整齐，而是让“我们现在到底在跑什么”变成一个能被回答的问题。只要没有版本号，线上状态迟早会越来越像一团雾。
评测
评测的价值，不是做一张漂亮分数表，而是把“最近感觉不稳”这种模糊焦虑压缩成可比较的样本和指标。没评测的时候，很多讨论其实都还停留在情绪层面。
日志与链路字段
没有统一日志字段时，故障经常不是修不了，而是团队先得花很长时间确认自己到底在看同一条请求。日志不是附属品，它是团队能不能对齐现实的前提。
回放
只要没有回放，很多复盘最后都会退化成“我记得当时不是这样”。能回放，争论就能重新回到现场。
人工兜底和回滚
这两件事我现在已经彻底不把它们看成“系统还不够智能”的标志了。恰恰相反，很多团队能快速迭代，就是因为他们知道系统坏了以后还有出口。
我对“成熟”这件事的理解也变了
以前我也很容易把成熟理解成：
- 组件更多了
- 平台更大了
- 能做的场景更多了
现在我更愿意用另一套更朴素的标准判断成熟：
- 改动更容易解释
- 故障更容易定位
- 版本更容易比较
- 失败更容易回退
这套标准听起来一点都不热血，甚至有点“后端老工程师味”，但我越来越觉得它更接近真实系统的长期价值。
所以如果把这段复盘最后压成一句话，我大概会这么说：2025 到 2026 这段 AI 工程演进里，真正被证明非有不可的，不是某个时髦做法，而是那些能把系统拉回可解释、可验证、可回退状态的控制机制。
热点当然还会继续变，模型也会继续变。但只要版本、评测、日志、回放和人工接管这条线还在变强，系统就不是在瞎长，而是在往更成熟的方向走。