83 篇博文 含有标签「AI工程」

这次失败并不复杂，但特别典型。模型表面上已经按 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，这个问题会像鬼一样，到处出现，但没人知道是谁干的。

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

过去几个月，几乎所有做 AI 应用的人都会碰到一个问题：这件事到底应该设计成 Agent，还是设计成 Workflow？一开始我对这个边界也没有特别强的判断，很多场景看起来都“可以上 Agent”，因为它听起来更灵活、更聪明、更接近用户对 AI 的想象。

但做过几轮之后，我反而越来越保守。我现在更倾向于把 Workflow 当成默认选项，把 Agent 当成例外选项。不是因为 Agent 没价值，而是因为大多数业务流程真正需要的不是自由发挥，而是稳定、可解释、可观测、可回退。

换句话说，Agent 的价值在于处理不确定性；Workflow 的价值在于约束不确定性。真正的设计重点，不是二选一，而是先判断你的业务到底更怕哪一种东西。