如果让我给还打算继续做 AI 的团队只留三项投资建议，我不会先选更复杂的 Agent 框架，也不会先选更花哨的工作台。我会先问三个很现实的问题：线上某次异常到底发生了什么，最近一次改动到底是变好了还是变差了，三周前那次事故今天还能不能重放出来。如果这三个问题答不上来，后面所有“持续迭代”都很容易变成盲飞。

内容审核最难看的时刻，通常不是漏了一条规则，而是补丁已经打上去了，现场却没人说得清它到底会影响谁、优先级会不会把旧规则压掉、误杀一旦冒出来要怎么撤。这个阶段如果还把规则更新理解成“改几行配置”，系统就很容易开始靠运气运行。

把单点 AI 功能做成系统能力，关键变化不在模型更强，而在团队开始补模型路由、评测回放和成本视图这些控制面。

很多被高估的 AI 话题之所以显得迷人，是因为大家只看到了 demo 的上限，没有认真算集成成本、维护成本和失败代价。

如果让我回头看这一年最值得保留下来的 AI 工程经验，我已经不太想再列那些听上去很大的词，比如“平台化”“智能体化”或者“工作流升级”。这些词当然都重要，但真正被我反复带进不同项目里的，往往是更朴素、更具体的一层：哪些字段必须有，哪些状态必须落盘，哪些样本必须先收起来，哪些动作必须能回滚。

大模型接口的超时不是单个配置项，而是一条贯穿前端等待、网关 deadline 和异步补偿的用户体验契约。

审批助手一旦影响报销、准入、风控这类结果，系统就不能只输出一个结论，而必须把证据、置信度和最终确认者一起设计进去。

LLM 网关安全真正要收住的，不只是 prompt 注入，而是身份、工具、数据和输出这四层边界。

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

很多团队一开始做 AI 系统时，会把“人在回路”理解成一种过渡方案：

• 现在模型还不够好，所以先让人兜着
• 等以后模型更强，就把人拿掉

我以前也有点这样想。后来做的系统越来越多，反而越来越不这么看了。
我现在更倾向于认为：人在回路不是妥协，而是很多 AI 系统天然就该有的一层设计。

因为很多业务问题本来就不是“把人替掉”才算成功，而是“把人的注意力放到真正值得判断的地方”才算成功。

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

有一次我们为了把检索时延压下来，动了向量库的一组参数。改动本身不大，甚至可以说很“合理”：

• 降一点搜索深度
• 控一点候选数
• 让查询更快一点

结果上线后最先变化的不是延迟，而是答案味道。
用户不会告诉你“召回率下降了”，他们只会说：

• 怎么最近更容易答偏了
• 怎么有些问题又像没看文档一样

后来追回去才发现，这次参数调整表面上节省了一点查询成本，实际上悄悄改掉了检索质量的下限。