从“AI 写代码”到“AI 工程失控”：大模型时代的三大技术管理挑战与系统重构路径

过去几个月，大模型能力的跃迁让软件开发进入一个前所未有的阶段：构建速度被指数级放大，而工程复杂度却被隐性放大。

几乎所有技术团队都在经历同一种转变——从“是否使用 AI”转向“如何驾驭 AI”。但真正的挑战，不在于模型能力，而在于：现有工程体系并未为 AI 做好准备。

这篇文章聚焦三个正在快速显现的问题：AI 生成代码的技术债、遗留系统的 AI 适配，以及 Agent 权限与安全边界。

导语：AI 把“写代码”变简单，把“做工程”变困难

一个广泛共识正在形成：

• 从 0 到 1：前所未有地容易
• 从 1 到 N：前所未有地困难

借助大模型，开发者可以在极短时间内生成登录页、CRUD API、数据脚本，甚至完整原型系统。但这些代码往往具备一个共同特征：

能运行，但不可维护

这标志着软件工程正在进入一个新的阶段——生成能力溢出，工程能力滞后。

第一部分：AI 生成代码的“技术债爆炸”

AI 写代码的核心问题，并不是“对不对”，而是“有没有结构”。

典型问题包括：

• 命名随意，缺乏语义一致性
• 抽象缺失，大量重复逻辑
• 边界条件硬编码
• 注释缺失或无意义
• 模块之间缺乏清晰依赖关系

这些问题叠加后，会形成一种新的工程负担，可以称为“AI Slop”。

为什么比人类写的烂代码更难维护？

人类写的代码，即使质量不高，通常仍然隐含：

• 某种设计意图
• 一致的思维模型
• 可追溯的演进路径

而 AI 生成代码的逻辑来源于：

• 单次 prompt 的局部最优解
• 缺乏全局架构视角
• 不具备长期一致性约束

这导致一个关键问题：

当你需要修改系统时，你首先要理解“它为什么能跑”，而不是“它为什么这样设计”。

换句话说，AI 降低了“建楼”的成本，却提高了“修楼”的难度。

第二部分：遗留系统与 AI 的结构性不兼容

如果说 AI Slop 是新系统的问题，那么另一个更现实的挑战来自老系统。

绝大多数团队的现状是：

• 系统运行多年
• 拥有内部 SDK、私有框架、历史约定
• 文档不完整，依赖经验传承

在这种环境下引入 AI，会出现一个典型现象：

AI 写出的代码“看起来对”，但在系统中“完全不合适”

问题本质：系统对 AI 不可解释

AI 在生成代码时依赖：

• 上下文（context）
• 明确接口定义
• 可预测的约定

但很多企业系统存在：

• 非标准 API 命名（如 flag2、dataX）
• 隐式规则（只存在于老员工脑中）
• 不一致的模块边界

结果是，AI 只能“猜”。

这种猜测带来的风险包括：

• 接口调用错误
• 数据结构误解
• 隐性 bug（最难排查）

解法不在 prompt，而在系统重构

很多团队的第一反应是优化 prompt，但真正有效的路径是：

让系统变得 AI-ready

这意味着：

• 明确 API 规范（命名、输入输出）
• 建立完整文档与 schema 描述
• 模块边界清晰化
• 减少隐式依赖

本质上，这是一次“工程规范升级”。

有意思的是，这些改进同时也会提升人类开发效率。AI 只是把问题提前暴露出来。

第三部分：Agent 权限控制——最难的问题才刚开始

随着 AI 从代码生成走向 Agent（自动执行任务），问题进一步升级。

当 AI 被赋予以下能力：

• 访问数据库
• 调用内部 API
• 执行业务流程
• 操作文件系统

一个核心问题变得不可回避：

它不该做的事，如何禁止？

三种主流控制思路

1. 工具层控制（MCP / Tool Layer）

通过限制 Agent 可调用的工具集合，实现权限隔离：

• HR Agent 只能访问 HR 工具
• Finance Agent 只能访问财务接口

优点是逻辑清晰，但问题在于：

• 粒度较粗
• 工具数量增长后难以管理
• Agent 仍可能误用工具

2. 网络层控制（Zero Trust / Firewall）

通过网络策略限制访问范围：

• 限制域名
• 限制服务调用

优点是安全性强，但缺点明显：

• 无法表达业务逻辑
• 配置复杂
• 与应用层脱节

3. Sandbox + Primitives（当前更优路径）

核心思路是：

• Agent 运行在隔离沙盒中
• 只能访问预定义的“原语”（primitives）
• 所有能力通过组合原语实现

例如：

• 只能读取指定表
• 只能写入特定字段
• 只能调用特定 API

在多 Agent 架构中：

• 每个 Agent 独立沙盒
• 通过明确接口通信
• 默认不共享数据

这种模式的本质是：

从“开放执行”转向“约束执行”

数据边界：比权限更隐蔽的问题

权限控制之外，还有一个更复杂的问题：

数据如何流动？

关键原则正在逐渐明确：

• 数据共享必须显式声明
• Agent 之间通信需走标准接口
• 默认不允许跨域访问
• 不允许直接访问彼此存储

这类似于微服务架构中的“服务隔离”，但在 Agent 体系中更加关键，因为：

• Agent 行为不可完全预测
• 调试成本远高于传统系统

结语：AI 工程的真正挑战，不是模型，而是系统设计

回看这三个问题，其实指向同一个核心：

• AI 放大了构建能力
• 也放大了系统设计的缺陷

未来的技术竞争，将不再只是模型能力，而是：

• 工程规范（Engineering Discipline）
• 系统可解释性（System Interpretability）
• 权限与数据治理（Governance）

对于技术管理者来说，一个新的命题已经出现：

系统不再只是“给人用”，而是要“给 AI 用”。

而这，意味着软件工程需要一次深层次的重构——不仅是技术层面的，更是组织与文化层面的。