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

如果只用一个真实项目来说这篇文章，我会选“内容同步流水线”。

这条流水线要做的事情其实不复杂：

• 定时拉取选题
• 生成摘要
• 写入 CMS
• 通知审核人
• 审核通过后同步到站点和搜索索引

这类事情非常适合用 n8n 这类工作流工具来做。因为它的核心难点不是算法，而是“把几个系统串起来”。可问题也正是在这里：很多团队一看到可视化编排很方便，就会很自然地把更多业务逻辑一起拖进去，最后把工作流画布变成半个业务系统。

所以我越来越觉得，n8n 这类工具最容易被误用的地方，不是功能不够，而是边界不清。

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

如果只拿一个线上场景来说超时策略，我会选“知识问答 + 检索 + 工具调用”的组合请求。

这类请求最容易暴露一个错觉：团队经常以为“只要给 SDK 设一个 30 秒超时就够了”。但真实请求进来之后你会发现，30 秒这个数字根本没有回答任何关键问题：

• 用户愿意盯着这个页面等多久？
• 整条链路最多能烧掉多少预算时间？
• 单个检索或工具步骤慢到什么程度时就该放弃？

当这些问题没有分开，超时就不会是一个边界，而只是一个会随机爆炸的数字。

这次短更想记录一个很直接的收益：加上一层像样的工具调用 trace 之后，一次原本要靠猜半天的问题，几分钟就定位到了。

问题表面上是“回答质量偶尔变差”，但真正看了 trace 之后，很快就能看到：不是模型理解错了，而是某个工具返回慢了一次，后面的重试触发了 fallback，最终结果自然就偏掉了。

如果只选一个真实场景来解释这篇文章，我会选“客服混合链路”。

这个链路里同时存在三类请求：

1. 很简单的分类，例如“这是退款还是咨询”。
2. 中等复杂度问答，例如“这张券为什么不能用”。
3. 少量高难样本，例如“多个订单、多个活动规则叠加后的争议场景”。

项目最初为了省事，几乎所有请求都默认走最强模型。早期流量小，大家只觉得“效果不错，就是稍微贵一点”。但一旦请求量上来，问题很快暴露：

• 成本并不是“稍微贵”，而是被大量简单请求一起抬上去了。
• 用户等待时间变长，前端体验开始变差。
• 团队失去了判断“哪些任务其实根本不需要强模型”的机会。

这也是我后来越来越笃定的一点：不是所有请求都要走最强模型。模型分层不是为了抠预算，而是为了让系统真正进入可运营状态。

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

AI 功能一旦进入真实流量，成本问题迟早会从“财务关心的事情”变成“工程必须立刻处理的事情”。最麻烦的是，它通常不会一开始就用一种非常明显的方式爆炸，而是会先通过一些不太起眼的信号慢慢浮上来。等到大家真正感觉到痛，往往已经不是“优化一下”能解决的程度了。

我现在看 AI 接口成本是否快要失控，不会先看总账单，而会先看系统里有没有出现下面三个信号。它们一旦出现，就意味着网关层和调度层必须尽快补队列、缓存和限流，不然越往后越被动。

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

如果只用一个真实链路来解释这个标题，我会选“内部知识问答 API”。

这套服务最开始的目标很简单：前端把用户问题丢给后端，后端转发给模型，再把答案返回。最早大家以为复杂度会集中在业务逻辑上，比如：

• 检索怎么做
• 答案怎么组织
• 是否需要引用来源

但上线后很快发现，真正最先失控的不是这些，而是业务层外面那一圈：谁能调用、该走哪个模型、超时怎么退、缓存怎么命中、配额怎么算、错误怎么统一。

也就是说，业务逻辑还没来得及长大，网关层已经先膨胀了。

这次失败并不复杂，但特别典型。模型表面上已经按 JSON 返回了结果，接口也没有报错，前端甚至还能正常展示。但真正把结果往下游流程里送时，系统才发现有一个关键字段类型不稳定，有时候是字符串，有时候是数组。

这种问题最麻烦的地方就在于，它不像完全报错那样容易被发现，而是会先以“偶发脏数据”的形式悄悄混进链路。

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

如果只拿一个具体页面来说这个问题，我会选“运营助手”里的改写面板。

这个面板的交互表面很普通：用户贴一段原始文案，点“优化”，系统开始生成一版可发布草稿。我们最早做的时候，认为流式输出只是锦上添花，于是做了一个很自然的版本：后端流式返回 token，前端就把 token 不断 append 到页面里。能跑，效果也看起来很“AI”。

但上线一周后，反馈几乎都集中在体验而不是效果上：

• “它到底是还没生成完，还是卡住了？”
• “我想复制刚才那句，结果它还在跳。”
• “中间突然停了三秒，我以为挂了。”
• “我点了继续生成，怎么前面那段也被改了？”

这时候我才真正意识到：对话产品前端里，流式输出不是一个展示细节，而是一整套状态管理问题。模型决定内容质量，前端决定用户是否愿意把这个过程当成一个可靠工具来使用。

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

4 月 14 日之后，很多团队最自然的问题就是：GPT-4.1 到底应该放在什么位置上？每次新模型发布，讨论都很容易迅速滑向两个极端：一种是“新模型来了，旧方案都该重做”；另一种是“反正模型只会越来越多，不如先别理”。我现在越来越不认同这两个极端。

在我看来，真正有价值的问题不是“它是不是最强”，而是“它在当前这条产品链路里，应该担任什么角色”。因为模型再强，也只是系统中的一个能力位。谁把它当成“要么全量替换、要么完全无视”的开关，谁就很容易做出成本高、收益低的决策。

所以我更愿意把 GPT-4.1 看成一个新的工程选项，而不是一条自动正确的路线。

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

这次上线后最先暴露的问题，不是模型质量，而是尾部延迟。平均响应时间看着还行，但只要请求稍微复杂一点，P95 很快就拉长，用户体感会立刻变差。

这类问题最容易被忽视，因为在小样本测试里，大家通常盯的是“平均值”，可线上真正决定体验的，经常是那些最慢的一批请求。