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

AI 编码助手真正开始可用之后，我最大的变化不是“写代码更快”这么简单，而是工作流本身变了。以前很多开发动作天然是线性的：看需求、想实现、写代码、跑测试、再修。现在它更像一个往返过程：

• 我先定义边界
• 让 AI 生成一个初版
• 我负责验证、删减、改名、重构
• 再把更清楚的上下文喂回去

也就是说，AI 没把开发变成“自动完成”，而是把很多工作从“手打实现”转移成了“定义问题和审查结果”。

这个变化一开始会让人有点不适应，因为你会明显感觉到自己不再只是 coder，而更像 reviewer、router 和 constraint designer。但一旦进入节奏，效率提升确实是实打实的。

这次优化很小，但非常值钱。问题出在一个对话页：模型流式返回 token 时，我们最初每收到一段就直接 setState 一次，结果页面在长回答场景里会明显抖动，尤其是移动端更明显。

最初大家直觉上以为这是“模型流太慢”或者“前端机器太差”，但真正看性能面板后才发现，问题不是响应慢，而是我们把过多的小更新直接推给了 React 渲染。

工作流只在单系统里跑的时候，凭证问题常常被低估。很多团队一开始会觉得，不就是在环境变量里放几个 token 吗？等到真的开始跨系统：

• 调知识库
• 调邮件服务
• 调 CMS
• 调对象存储
• 调内部 API

这些 token、key、secret 就会突然从“配置细节”变成整条工作流最脆弱的一层。

我后来对这个问题印象最深的一次，是一个看起来很普通的内容发布工作流。它需要同时访问：

• 内部内容数据库
• 站点构建服务
• 第三方通知渠道
• 搜索索引 API

结果真正先出问题的，不是业务逻辑，而是凭证边界混乱：有的 token 权限过大，有的 token 被多个流程共用，有的过期了没人知道，还有的出错日志里直接把敏感信息暴露出来。

从那之后我才真正把“凭证管理”当成跨系统工作流的核心设计问题，而不是交给运维顺手处理的附属项。

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

很多团队在接入大模型之后，都会很快进入一个误区：只要某个功能里有“判断”“调用工具”“多轮交互”这些词，就想把它包装成 Agent。看起来好像更先进，也更符合行业叙事。

但真落到工程里，很多小功能的问题恰恰在于它们太小了，小到根本不值得引入 Agent 这一整套复杂度。

我后来越来越明确的一条原则是：能用一次结构化调用解决的问题，不要先升级成带规划、带循环、带状态恢复的 Agent 任务。

这不是保守，而是成本意识。因为对一个小功能来说，Agent 带来的往往不是“更强能力”，而是额外的系统负担：

• 更多运行时状态
• 更多日志和追踪字段
• 更多失败路径
• 更多权限边界
• 更多测试和回归成本

很多团队在做 AI 内容流水线时，一开始只盯着“生成”。但只要流程开始进入多人协作、审核和发布，真正麻烦的问题马上会变成：

• 这篇内容现在处在哪一步
• 是谁改过它
• 哪一版被审核通过了
• 哪个模型、哪个模板生成的
• 出错时到底该回滚到哪里

如果这些问题回答不出来，系统虽然能生成内容，但很难被真正信任。

所以我后来越来越把“AI 内容流水线”理解成一条需要被追踪的状态链，而不是一个“生成完就结束”的文本处理脚本。

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

如果只谈“生成一篇内容”，现在的大模型其实已经能做得像模像样了。真正把团队拖进泥里的，往往不是生成这一步，而是后面三件更现实的事：

• 谁来审核
• 错了怎么撤
• 撤了以后系统怎么恢复一致

我之所以会把这个问题单独拉出来讲，是因为我见过太多内容自动化项目，一开始都卡在“怎么生成得更好”，结果真正上线后最先出事故的，都是审核和回滚链路。

最典型的一次，是一条自动生成的内容流里，模型把一个引用来源写错了。正文本身看起来挺顺，发布动作也正常完成，但问题在于：

• 审核同学只看了前两段
• 发布后外链已经同步出去
• 内容又被下游渠道抓走了一份

这时候真正难的已经不是“修正文案”，而是“怎么让整条发布链恢复一致”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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