大多数 AI 编码演示展示的是智能体从零构建一个 Todo 应用，或者干净地实现一个全新的 API。而你的代码库，却是一个有着十五年历史的单体应用：充满未文档化的隐性契约、三个团队都依赖但没人完全搞清楚的废弃依赖，以及一个从单一类起步、如今已蔓延到四十个文件的服务层。演示与现实之间的差距，不仅仅是规模问题——更是结构性问题。在把代码库的"钥匙"交给智能体之前，理解这一点，能让你避开一类既隐蔽又代价高昂的失败。
AI 编码智能体确实能帮助处理遗留系统，但只在特定任务边界内才有效。超出这些边界，它们不是显眼地失败——而是生成外观可信、语法正确、语义却有误的变更，这些变更能通过代码审查，最终在生产环境中暴露出来。
每个 AI 演示都从绿地起步：一个干净的代码仓库、一个全新的 API key，不到一小时就能跑通流式聊天响应。然后有人问："我们能把这个加到真正的产品里吗？"——那个运行在十年老单体系统上、存有无数未记录存储过程的产品，那个部署流程需要三个团队外加一个变更顾问委员会的产品，那个数据模型比 JSON 还古老的产品。
大多数 AI 集成工作都死在这里。不是因为 LLM 不好用，而是因为周围的系统根本不肯配合。超过 75% 的企业 AI 项目都卡在集成边界上——无法将 AI 能力与真正持有所需数据的系统连接起来。
本能反应是计划重写。别这样做。那些真正将 LLM 功能推进生产遗留系统的团队，都是以渐进的方式完成的——通过将现有代码库视为具有已知接口的黑盒的适配器模式。以下是具体做法。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
