去年Q3，我们团队的后端代码量涨了47%。不是业务爆发，是AI图像识别这个功能在膨胀。它像往西装里塞羽绒服——表面看不出来，但走路姿势全变了。
直接集成模型不是罪。但当图像识别只是系统里的一个功能，而非全部时，后端开始干一些"不是它该干的事"。这是我自己的案例，对你可能不重要，但对我——是。
第一道裂缝：从"调个API"开始
最初的决策毫无戏剧性。用户上传图片，想要结构化数据——发票、文档、名片、书封。对象换了衣服，机制不变。直接在后端调模型，最快。
但"最快"是有利息的。提示词管理、分支逻辑、重试机制、输出格式化、供应商特定参数、回调行为……这些开始往业务代码里渗。一次小型的模型迭代，开始表现得像一次应用发版。
更麻烦的是，后端工程师开始讨论"这个提示词版本要不要回滚"，"那家供应商的token限制是多少"。这些不是应用层该操心的事，但它们就躺在`utils/ai_helpers.py`里，和业务规则缠在一起。
当AI只是系统的一个功能，却让整个系统为它改变呼吸节奏，这笔账就不划算了。
我想要的边界很简单：应用管认证、校验、业务状态；另一层管模型相关的编排。实践中，这层经常是n8n（工作流自动化工具）。不是"把AI塞进应用"，是另一种构造——一道窄窄的集成边界。
拆出来的结构：三个盒子，各干各的
具体怎么切？应用端只保留两个普通端点：
一个收图片+用户上下文，返回请求ID和"处理中"。另一个收回调，验证签名，更新状态。就这么简单。
中间层（n8n）干所有脏活：预处理图片、拉取领域上下文、调模型、解析归一化结果、跑置信度检查、路由到人工复核或降级方案、最后给应用发签名回调。
应用不需要知道：哪个模型在处理、提示词长什么样、重试几次、输出怎么被清洗的。它只认一个契约：我给你图片，你最终给我结构化数据，或者告诉我需要人工介入。
这个结构有个副产品：应用代码量回去了。更隐蔽的好处是，模型相关的实验——换供应商、调提示词、加后处理——不再触发应用层的回归测试。两边可以各自迭代。
不是反对SDK，是反对"SDK思维"的蔓延
这不是对SDK的圣战。SDK本身没问题，问题在于"模型周边的所有混乱该住在哪里"。
我见过一种反模式：后端为了"复用"，把AI调用封装成一个通用服务。听起来合理，结果这个服务成了全公司提示词的垃圾场。二十个业务线，各自的需求往里塞，最后没人敢动那坨代码。
另一种极端是，每个团队自己集成。于是同样的重试逻辑、同样的输出清洗，在不同代码库里重复生长，带着各自微妙的差异。
n8n在这里的角色不是"低代码救星"，是一个明确的托管边界。它承认自己就是编排层，不假装是业务系统的一部分。提示词版本管理、供应商切换、降级策略，这些在可视化界面里反而比代码更清晰——因为它们的复杂度本来就是流程复杂度，不是算法复杂度。
当系统不会因为加了AI就长出额外的肢体，方向通常是对的。
有个细节让我确认这个拆分是对的：我们的SRE（站点可靠性工程师）开始能独立处理模型相关的告警了。以前后端报错，他们得拉工程师一起看是业务问题还是模型问题。现在n8n层的监控和应用的监控完全分离，故障域清晰，on-call（值班）的人少熬很多夜。
热门跟贴