补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-04-19 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
4 月 14 日之后，很多团队最自然的问题就是：GPT-4.1 到底应该放在什么位置上？每次新模型发布，讨论都很容易迅速滑向两个极端：一种是“新模型来了，旧方案都该重做”；另一种是“反正模型只会越来越多，不如先别理”。我现在越来越不认同这两个极端。
在我看来，真正有价值的问题不是“它是不是最强”，而是“它在当前这条产品链路里，应该担任什么角色”。因为模型再强，也只是系统中的一个能力位。谁把它当成“要么全量替换、要么完全无视”的开关，谁就很容易做出成本高、收益低的决策。
所以我更愿意把 GPT-4.1 看成一个新的工程选项，而不是一条自动正确的路线。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-04-28 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只拿一个具体页面来说这个问题，我会选“运营助手”里的改写面板。
这个面板的交互表面很普通：用户贴一段原始文案，点“优化”，系统开始生成一版可发布草稿。我们最早做的时候，认为流式输出只是锦上添花，于是做了一个很自然的版本：后端流式返回 token，前端就把 token 不断 append 到页面里。能跑，效果也看起来很“AI”。
但上线一周后，反馈几乎都集中在体验而不是效果上：
这时候我才真正意识到：对话产品前端里，流式输出不是一个展示细节，而是一整套状态管理问题。模型决定内容质量，前端决定用户是否愿意把这个过程当成一个可靠工具来使用。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-03 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这次失败并不复杂，但特别典型。模型表面上已经按 JSON 返回了结果，接口也没有报错，前端甚至还能正常展示。但真正把结果往下游流程里送时，系统才发现有一个关键字段类型不稳定，有时候是字符串，有时候是数组。
这种问题最麻烦的地方就在于，它不像完全报错那样容易被发现，而是会先以“偶发脏数据”的形式悄悄混进链路。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-06 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只用一个真实链路来解释这个标题，我会选“内部知识问答 API”。
这套服务最开始的目标很简单：前端把用户问题丢给后端，后端转发给模型，再把答案返回。最早大家以为复杂度会集中在业务逻辑上，比如：
但上线后很快发现，真正最先失控的不是这些，而是业务层外面那一圈：谁能调用、该走哪个模型、超时怎么退、缓存怎么命中、配额怎么算、错误怎么统一。
也就是说，业务逻辑还没来得及长大，网关层已经先膨胀了。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-09 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
AI 功能一旦进入真实流量，成本问题迟早会从“财务关心的事情”变成“工程必须立刻处理的事情”。最麻烦的是，它通常不会一开始就用一种非常明显的方式爆炸，而是会先通过一些不太起眼的信号慢慢浮上来。等到大家真正感觉到痛，往往已经不是“优化一下”能解决的程度了。
我现在看 AI 接口成本是否快要失控，不会先看总账单，而会先看系统里有没有出现下面三个信号。它们一旦出现，就意味着网关层和调度层必须尽快补队列、缓存和限流，不然越往后越被动。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-16 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只选一个真实场景来解释这篇文章，我会选“客服混合链路”。
这个链路里同时存在三类请求：
项目最初为了省事，几乎所有请求都默认走最强模型。早期流量小，大家只觉得“效果不错，就是稍微贵一点”。但一旦请求量上来，问题很快暴露：
这也是我后来越来越笃定的一点：不是所有请求都要走最强模型。模型分层不是为了抠预算，而是为了让系统真正进入可运营状态。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-22 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这次短更想记录一个很直接的收益：加上一层像样的工具调用 trace 之后，一次原本要靠猜半天的问题，几分钟就定位到了。
问题表面上是“回答质量偶尔变差”，但真正看了 trace 之后，很快就能看到：不是模型理解错了，而是某个工具返回慢了一次，后面的重试触发了 fallback，最终结果自然就偏掉了。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-25 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只拿一个线上场景来说超时策略，我会选“知识问答 + 检索 + 工具调用”的组合请求。
这类请求最容易暴露一个错觉：团队经常以为“只要给 SDK 设一个 30 秒超时就够了”。但真实请求进来之后你会发现，30 秒这个数字根本没有回答任何关键问题：
当这些问题没有分开，超时就不会是一个边界，而只是一个会随机爆炸的数字。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-30 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只用一个真实项目来说这篇文章，我会选“内容同步流水线”。
这条流水线要做的事情其实不复杂：
这类事情非常适合用 n8n 这类工作流工具来做。因为它的核心难点不是算法，而是“把几个系统串起来”。可问题也正是在这里：很多团队一看到可视化编排很方便，就会很自然地把更多业务逻辑一起拖进去，最后把工作流画布变成半个业务系统。
所以我越来越觉得，n8n 这类工具最容易被误用的地方，不是功能不够，而是边界不清。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-06-06 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只谈“生成一篇内容”，现在的大模型其实已经能做得像模像样了。真正把团队拖进泥里的，往往不是生成这一步，而是后面三件更现实的事：
我之所以会把这个问题单独拉出来讲，是因为我见过太多内容自动化项目，一开始都卡在“怎么生成得更好”，结果真正上线后最先出事故的，都是审核和回滚链路。
最典型的一次，是一条自动生成的内容流里，模型把一个引用来源写错了。正文本身看起来挺顺，发布动作也正常完成，但问题在于：
这时候真正难的已经不是“修正文案”，而是“怎么让整条发布链恢复一致”。