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

我现在越来越少把一整段 AI 逻辑塞进一个“很聪明的 Agent”里。不是因为 Agent 没价值，而是只要功能开始进入多人协作、线上排查和持续演进阶段，把能力拆成可组合服务，几乎总会比单一大黑盒更容易维护。

这两年我越来越觉得，AI 产品里的 BFF 又变得重要了。但它重要，不是因为我们突然怀念传统前后端分层，而是因为很多团队在 AI 功能早期图快，把会话拼装、模型选择、权限裁剪和供应商切换都散落在不同地方，后面一扩展就开始失控。

组织真正开始提效，通常不是因为又接了一个新模型，而是 Prompt、工具、知识和评测终于共享了一套版本和发布语言。

聊天机器人刚起步时，很多事情都很顺。用户发一句话，模型回一段结果，页面把消息 append 上去，看起来就已经像个产品了。真正开始露出边界，通常是在需求变成这样的时候：帮我整理这批资料，明天继续；如果权限不足就先挂起等审批；调用外部系统失败就自动重试；执行到一半也要能从详情页接着看。到这一步，你会突然发现，消息列表已经不够当系统主结构了。

AI 成本和体验看板里最该删掉的，往往是那些看起来平滑、却掩盖尾部问题的平均指标。

从零搭内部 AI 平台时，最重要的不是一次性把能力做全，而是先收出一个最小可治理的底座。

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

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

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

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