上下文翻译断层：为什么 AI 编程智能体总是搞砸？

周二上午，你正坐在产品会议里。你的运营经理正在解释，新的 Shopify 集成得能处理拆单发货，但仅限欧盟客户，而且还得是缺货延迟超过三天的情况。

她在白板上画了个流程图。对屋里的人来说，这逻辑再清楚不过了。你看着你的首席开发人员点点头，他脑子里已经开始把这些乱七八糟、充满条件的业务逻辑，转化成严谨的数据库架构和 API 传输协议了。

这时候，你的 LinkedIn 动态里全是各种视频，吹嘘自主智能体（autonomous agents）能在十分钟内写出一个《乒乓》小游戏。这种炒作简直震耳欲聋。但在真空环境里写个独立的小游戏只是个江湖骗术。要把一条新的物流规则集成到一套跑了五年的定制 ERP 系统里，同时还不把财务团队的月末报表搞崩，这才是真正的软件工程。

语境翻译断层

「语境翻译断层」是一层看不见的工作，它把混乱的业务现实转化为严谨的技术约束。这是软件工程中最难的部分，而且除了靠写代码吃饭的人，谁也看不见这层工作。

当老板想要一个新功能时，他们说的是「简写」。他们说想要一个简单的仪表盘来追踪供应商延迟。他们不会说明，如果供应商在月中改了名字，系统该怎么处理。他们也不会提，当一个产品 SKU 停产后，历史数据该怎么办。他们默认系统「自己会知道」。

人类开发人员本能地知道要问这些问题。他们看一眼现有的 PostgreSQL 数据库，看到那些陈年约束，就会意识到这个「简单的仪表盘」其实需要重写整个库存表。他们在人类的模糊性与机器的精确性之间架起了一座桥。

这种「翻译」过程发生在英国每一个冲刺计划会议（sprint planning）上。销售代表想要在 Pipedrive 里加个按钮，自动生成定制的 PDF 方案。开发人员就得琢磨：如果客户没填注册地址怎么办？或者如果定价档位里包含一个 2022 年留下的老客户折扣码，又该怎么办？

AI 工具填补不了这个断层。它们默认你的提示词（prompt）是完整的。如果你让 AI 写个仪表盘，它写出的代码会和你要求的一模一样，完全忽略那些没说出来的极端情况（edge cases）——而这些情况准保会在上线第三天让系统崩溃。断层依然在那儿，一团糟，没人知道为什么。就这么回事。

为什么自主编程智能体会碰壁

自主编程智能体之所以会碰壁，是因为它们只写你要求它们写的代码，而忽略了维持系统运行的那些隐性业务语境。大多数中小企业尝试的「速效药」，是直接把一份原始的产品路线图丢给一个现成的 SaaS 智能体，指望它表现得像个资深工程师。

你可能看过这类新闻。PCMag 最近的一篇报道吹捧了 Cognition Labs 的 Devin AI，说它能独立开发网站、训练其他 AI，甚至能在 Upwork 上接单干活，完全不需要人类干预 [来源](https://www.pcmag.com/news/this-software-engineer-ai-can-train-other-ais-code-websites-by-itself)。老板们的第一反应通常是：我可以裁掉外包公司了，不用招初级开发了，每个月给 AI 交个订阅费就行。

这里有个反直觉的真相：这些自主智能体之所以失败，并不是因为代码写得烂。而是因为它们写得太丝合缝了——完全照着你的要求写。

当你让一个智能体去改代码库，加一个新的 Stripe 订阅档位时，它的 Python 函数会写得非常完美。但它没有语境，它不知道你的财务团队依赖一个自定义的 webhook，而那个 webhook 是靠旧的档位名称触发的。智能体发布了代码，测试也通过了，结果你月末的账目对账悄无声息地崩了。没错，这事儿挺烦人的。

在我审查过几十个中小企业代码库的经验里，写语法只占工作的 20%。剩下的 80% 是防御性架构。是得知道旧系统的哪些部分很脆弱。是得理解为什么三年前某个 API 调用要写成那种怪样，就为了绕过第三方物流供应商系统里的一个 Bug。

因为存在语境翻译断层，AI 智能体会把每个任务都当成「白地起新房」。它缺乏处理成熟、混乱代码库所需的「机构记忆」。它会盲目地覆盖掉一个关键的临时方案（workaround），仅仅因为那个方案看起来代码效率不高。

你省下了 £35k 的初级员工工资，却引入了一个隐蔽的结构性风险。等这颗雷最终爆掉的时候，得花一个资深开发三周时间才能理顺。智能体不会反驳坏主意。它只会完美地执行它们，带着你的架构直接冲下悬崖。

混合架构方案

混合架构方案把 AI 看作一个高速逻辑引擎，但得套上人类设计的安全网。你不能让 AI 做结构性决策。你让它在人类工程师设计的系统里，执行特定的、边界清晰的任务。

举个实际例子：处理复杂的供应商发票。

与其让 AI 智能体去盖整座大楼，不如让你的开发人员来设计流水线。他们设置一个 n8n webhook 来抓取 Outlook 里的邮件。webhook 剥离 PDF 附件，然后把它发给 Claude 的 API 接口。

注意这一步。开发人员不只是让 Claude 提取数据。他们在 API 调用中传递了一个严格的 JSON schema，强迫 Claude 必须返回 Xero 需要的字段：供应商名称、项目描述、税码和金额。

人类开发人员写下的逻辑是：如果 JSON 数据里缺了税码，别瞎猜。把它转到 Slack 频道让人类去审核。如果数据完美，n8n 工作流就直接通过 Xero API 去更新发票条目。

AI 承担了提取非结构化数据的重活，但人类工程师掌控着路由、错误处理和数据库写入。在数据被允许碰核心财务系统之前，他们规定了数据的精确形状。

搭建这样一个混合流水线通常需要 2-3 周，成本大概在 £6k 到 £12k 之间，具体取决于你现有的集成有多乱。

这里已知的失败模式是「幻觉导致的格式变化」。有时候，大模型会心血来潮，把价格那一列本该是整数的地方返回成字符串。如果你让这玩意儿直接进数据库，系统就挂了。

你的应对办法是在 AI 输出和数据库写入之间加一个严格的验证层。如果验证失败，webhook 就不写数据，并报错提醒。人类开发人员负责织安全网， AI 负责表演杂技。

混合模式在什么时候会失效

如果你想在底子已经烂掉的旧流程或脏数据上强行套一层现代 AI 提取，混合模式就会失效。这种方法很强大，但它需要一定的数字化成熟度作为底线。在把 AI 接入系统之前，你得搞清楚系统的边界到底在哪儿。

如果你的核心业务逻辑跑在一个有 15 年历史、只接受 SOAP XML 请求的本地服务器 ERP 上，加个 AI 提取层带来的痛苦绝对比解决的问题多。现代 API 工具在尝试跟老古董服务器沟通时会不断超时。你会把大把时间花在调试网络协议上，而不是写有用的业务逻辑。

同样，如果你的输入源本身就是烂的，AI 就会信心满满地生成烂结果。如果你的发票是从老旧会计系统里扫描出来的模糊 TIFF 图片，你得先搞个专门的 OCR 层。如果你跳过这一步，直接把模糊图片喂给视觉模型，错误率会从 1% 飙升到 12% 左右。

在动手开发之前，你得检查数据卫生。如果你的团队连处理拆单发货的标准作业程序（SOP）都达不成共识，AI 模型也没法自动化。AI 修复不了烂流程。它只会以光速执行烂流程。如果底层逻辑是错的，自动化只会让混乱成倍放大。

问题不在于 AI 最终写的 Python 代码是否会比你的首席开发更好。它现在就已经写得更好了。问题在于，一个自主智能体是否知道你的运营经理每天下午都依赖一个格式诡异的 CSV 导出文件，以及把数据库架构改得「更高效」会彻底搞瘫她的工作流。

软件工程不是在终端里敲代码。它是要把人类的意图映射到死板的数字结构上，同时还不把现有的好东西搞坏。你依然需要人类开发人员，因为总得有人守住这些语境。总得有人知道旧代码库里的坑都在哪儿。你可以用 AI 来写模板代码、解析混乱的输入、加快开发周期。但一旦你把架构的钥匙交给机器人，你就不再是在构建业务系统了。你只是在坐等那场必然发生的、悄无声息的崩溃。