补档说明：本文属于「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 很快就拉长，用户体感会立刻变差。
这类问题最容易被忽视，因为在小样本测试里，大家通常盯的是“平均值”，可线上真正决定体验的，经常是那些最慢的一批请求。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-04-10 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
React 19 正式落地之后，前端圈很自然会讨论“它到底带来了什么变化”。但如果把场景缩小到 AI 产品，我更关心的不是版本号本身，而是哪些能力真的能改善 AI 交互中的真实问题。因为 AI 产品前端和普通内容站点不太一样，它天然会面对几类更极端的状态：
在这种场景里，前端体验的核心不是“页面够不够炫”，而是“用户会不会在等待和变化中失去控制感”。从这个角度看，React 19 真正有价值的能力，并不是平均意义上的升级项，而是那些能让状态过渡更顺、交互反馈更稳、异步处理更自然的能力。
如果只讲原则，这篇文章还是会显得空。所以我直接拿一个真实得不能再真实的例子来说：退款工单分诊。
这类任务的目标通常是把用户自然语言输入转成一个后续系统能继续处理的对象，例如：
团队最早的做法很常见：先让模型直接输出一段 JSON，大概长这样：
{
"title": "用户申请退款",
"summary": "用户表示重复支付，希望退款",
"tags": ["退款", "重复支付"]
}
看上去没毛病，前端也能展示，测试样本甚至都能过。但真正进系统后，这种 Schema 很快就会把问题暴露出来：它描述了内容，却没有描述动作边界。
真正让系统难受的不是模型会不会吐 JSON，而是下游根本不知道怎么用这个结果继续执行。
这次短更想记录一个很现实的判断：工作流一旦开始接触外部用户、业务数据或正式内容发布，人审节点往往不是多余，而是让系统真正能上线的关键。
很多自动化链路在 Demo 阶段看起来都很顺，因为样本干净、场景单一、风险还没真的压上来。但只要开始进入真实业务，团队很快就会发现，完全自动执行的吸引力，往往比不上“可控上线”的价值。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-23 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
2025 年 3 月 11 日之后，我对 AI 应用的一些判断开始变得更明确了。不是因为那天突然出现了一个完全颠覆的新世界，而是因为“工具调用”和“围绕工具调用组织工作流”这件事，被越来越正式地推到了台前。那之后我更确定了一点：很多 AI 产品的价值中心，正在从“模型单次回答得多聪明”，转向“系统能不能围绕模型把事情做成”。
这两者看起来只差一点点，实际是完全不同的工程重心。
前一种重心下，团队更容易围绕 Prompt、模型榜单、单次回答效果去优化；后一种重心下，团队会开始更认真地讨论：
我觉得这就是为什么“工作流 + 工具调用”在这个时间点之后显得更重要了。因为它把 AI 应用从“会说话”推进到了“能协作、能执行、能被治理”。