AI 工程师为什么还是得补软件工程:接口契约、回放句柄和幂等键比 Prompt 更救命
· 阅读需 6 分钟
有次上线一个看起来很轻的生成接口,前端只是多加了一个“重新生成”按钮,工作流层为了稳妥又补了自动重试,结果当天晚上数据库里就出现了三份互相打架的结果。产品同学以为模型突然变飘,工程同学第一反应去翻 Prompt,最后真正把问题钉住的,却是一串再普通不过的事实:入口没有幂等键,调用链没有统一 traceId,谁也说不清那三次请求到底是不是同一件事。
有次上线一个看起来很轻的生成接口,前端只是多加了一个“重新生成”按钮,工作流层为了稳妥又补了自动重试,结果当天晚上数据库里就出现了三份互相打架的结果。产品同学以为模型突然变飘,工程同学第一反应去翻 Prompt,最后真正把问题钉住的,却是一串再普通不过的事实:入口没有幂等键,调用链没有统一 traceId,谁也说不清那三次请求到底是不是同一件事。
我现在越来越少把一整段 AI 逻辑塞进一个“很聪明的 Agent”里。不是因为 Agent 没价值,而是只要功能开始进入多人协作、线上排查和持续演进阶段,把能力拆成可组合服务,几乎总会比单一大黑盒更容易维护。
如果让我给还打算继续做 AI 的团队只留三项投资建议,我不会先选更复杂的 Agent 框架,也不会先选更花哨的工作台。我会先问三个很现实的问题:线上某次异常到底发生了什么,最近一次改动到底是变好了还是变差了,三周前那次事故今天还能不能重放出来。如果这三个问题答不上来,后面所有“持续迭代”都很容易变成盲飞。
如果让我回头看这一年最值得保留下来的 AI 工程经验,我已经不太想再列那些听上去很大的词,比如“平台化”“智能体化”或者“工作流升级”。这些词当然都重要,但真正被我反复带进不同项目里的,往往是更朴素、更具体的一层:哪些字段必须有,哪些状态必须落盘,哪些样本必须先收起来,哪些动作必须能回滚。