补档说明：本文属于「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 应用从“会说话”推进到了“能协作、能执行、能被治理”。
如果只允许我用一个事故来解释这篇文章，我会选“重复建单”。
场景很简单：我们做了一个退款助手，模型拿到用户问题后，会先调 searchOrder 确认订单状态，再调 createRefundTicket 创建退款工单，最后调 notifyAgent 给人工客服发提醒。这条链路在演示时很顺，因为每次只跑一单，也很少超时。
真正的问题发生在灰度流量上来以后。有一类请求会卡在 createRefundTicket 这一步，工具其实已经成功落库，但响应在网关层超时了。系统把这次调用当成失败，又自动重试了一次。于是第二张退款工单被建出来了。
最糟糕的地方在于，当时我们第一眼根本看不出来问题在哪。业务方看到的是“怎么有重复工单”，模型侧看到的是“工具偶尔失败”，后端看到的是“数据库写入成功”。如果没有一条完整的 trace，这个问题会像鬼一样，到处出现，但没人知道是谁干的。