AI写代码为什么越改越乱？企业如何用约束驾驭Agent开发

AI工程落地｜不是反对模型，而是反对无约束生成

第一次，让AI给工单增加一个字段。它修改了数据库、DTO、接口和前端表单。

第二次，让AI增加查询条件。它又创建了一个名字相近的字段。

第三次，为了兼容旧数据，它在三个地方增加了不同的兜底逻辑。

功能看起来都能用，代码也可能通过编译。但几轮对话以后，同一个概念出现两套命名，两条路由和三种默认值。下一位开发者已经说不清哪一个才是事实来源。

这就是AI开发中的“漂移”：每一次局部修改似乎合理，系统整体却在逐渐偏离原来的需求、架构和数据契约。

问题通常不在于模型不会写代码。模型会根据当前上下文寻找一条最可能完成任务的路径；如果仓库里没有稳定规范、结构边界和验证门禁，它也会忠实地放大仓库中已有的混乱。

01、代码漂移，不只是“模型幻觉”

企业经常把AI生成错误代码归因于幻觉，但工程现场更常见的是四种漂移：

需求漂移：原本只要求查询，修改过程中逐渐加入编辑、删除和自动执行。

契约漂移：数据库、后端DTO、API字段和前端类型开始使用不同命名。

架构漂移：新逻辑绕过既有服务层，在控制器、页面或脚本里直接完成业务处理。

安全漂移：为了让功能跑通，权限范围被扩大，校验和审批被改成了默认放行。

漂移往往不是一次严重错误，而是许多“先兼容一下”“先加个兜底”“先复制一份”的累积。等团队察觉时，维护成本已经高于最初开发成本。

02、反模式一：把Prompt当成需求规格

“帮我增加批量处理”“把这个页面优化一下”“参考旁边模块实现”，这些指令适合启动讨论，却不足以直接控制代码变更。

如果目标、非目标、验收条件和影响范围只存在于对话里，模型每一轮都会重新解释任务。对话越长，旧要求、临时判断和过期上下文越容易相互污染。

约束方法：每个任务先形成一份最小变更契约。

它要写清业务目标、明确不做什么、验收场景、允许修改的模块、数据影响、风险和回滚方式。

Prompt可以变化，变更契约必须成为稳定事实来源。

03、反模式二：只修眼前报错，不追踪完整数据流

页面字段为空，AI最容易在页面增加一个兼容判断；接口返回异常，它可能直接返回空数组；路由找不到，它可能新建一条相似路由。

这些修改能让眼前症状消失，却可能掩盖真正问题：字段从数据库到仓储、服务、DTO、API客户端和页面的传递链已经断裂。

约束方法：修改前先画出最短系统地图。

数据库 → Repository → Service → API → 前端Client → 状态 → 页面

AI必须先定位事实从哪里产生、在哪一层转换、由谁消费，再提出修改计划。没有完成数据流追踪，就不应该开始堆补丁。

04、反模式三：让AI模仿仓库里“最近的代码”

模型很擅长沿用已有模式。但离当前文件最近的实现，可能恰好是历史兼容代码、临时方案或者尚未清理的重复实现。

如果仓库同时存在新旧两套路由、两种错误处理和多个服务入口，AI不会天然知道哪一种是企业希望长期保留的架构。

约束方法：给仓库建立一部简短、可执行的“宪法”。

在AGENTS.md或仓库指令中说明分层方向、标准目录、构建测试命令、推荐样例和禁止模式。

不要把它写成几十页口号。规则应能回答：“这个功能应该放在哪一层，改完如何证明是对的？”

05、反模式四：用兼容逻辑掩盖契约冲突

字段对不上，就同时读取snake_case和camelCase；接口不一致，就保留新旧两个地址；数据缺失，就返回零值。短期看，这是最快的修复方式。

但每增加一次无期限兜底，系统就多一个无法删除的分支。AI下一次读到这些代码，还会把它们当成“项目最佳实践”继续复制。

一个业务概念 一个规范名称 · 一个契约 · 一个事实来源

约束方法：新增兼容分支必须写明原因、观测指标、删除条件和截止时间。能够修复源头时，不允许用消费端兜底替代根因修复。

06、反模式五：把“编译通过”当成“功能正确”

AI报告里最容易出现的一句话是：“测试已通过。”但它可能只运行了类型检查，或者只验证了刚写的一个单元函数。

真正的业务故障可能发生在权限、状态流转、接口契约、数据库迁移或多个服务连接起来以后。局部绿色不等于业务链路绿色。

第1层：格式化、静态检查、类型检查和编译。

第2层：单元测试与契约测试。

第3层：数据库、接口和服务集成测试。

第4层：真实用户路径的端到端测试。

第5层：能够复现本次问题、并阻止问题再次出现的回归测试。

测试不是任务结束时的汇报材料，而是限制AI可提交结果的工程门禁。

07、反模式六：给Agent无限范围、无限工具和无限时间

为了让AI“自主完成任务”，团队可能把整个仓库写权限、Shell、网络、云凭证和生产接口一次性开放。任务没有文件边界、变更预算、暂停点和结束条件。

这并不会自动带来更高效率，只会扩大错误半径。一个错误判断可能从代码文件扩散到依赖、数据库、部署配置甚至生产数据。

作用域：明确允许修改的模块和禁止触碰的区域。

工具：默认只读，按任务临时开放写入、网络和外部系统。

动作：删除、迁移、发布和生产操作必须经过人工批准。

时间：长任务设置检查点，偏离计划时暂停而不是继续试错。

证据：保留命令、差异、测试、假设和未解决风险。

Agent可以在局部实现上自主，但架构、权限和验收边界必须由企业系统控制。

08、反模式七：多Agent并行，却没有文件所有权

一个Agent修改后端契约，另一个同时修改前端类型，第三个重构公共组件。如果它们没有共享计划和清晰所有权，就可能覆盖彼此修改、重复实现同一能力，或者基于已经过期的接口继续工作。

约束方法：并行任务先按责任和文件边界拆分，每个子任务有唯一所有者；公共契约先确定再并行；合并前由一个协调者检查整体数据流，而不是只解决Git冲突。

多Agent的价值来自任务可分解，不来自同时打开更多生成窗口。

09、真正有效的约束，要从文档升级为机器门禁

“请遵守分层架构”“不要吞掉异常”“控制文件大小”写在文档里有用，但还不够。模型会遗漏，人也会遗漏。

OpenAI在介绍其Agent优先工程实践时，强调把架构边界转化为自定义Lint和结构测试：依赖只能沿固定方向流动，日志、命名、文件大小和可靠性规则由工具机械执行。

文档告诉AI应该怎么做 类型系统限制它能怎么做 Lint与测试阻止错误进入主干

GitHub Copilot也支持仓库级、路径级和Agent指令，用于告诉编码Agent如何理解项目、构建、测试和验证。关键不只是“写一份说明”，而是让仓库本身成为持续更新的事实来源。

10、企业可以建立一套“七层约束栈”

1. 意图约束：目标、非目标、验收条件、风险和回滚形成变更契约。

2. 仓库约束：用AGENTS.md、架构地图和标准样例明确项目规则。

3. 结构约束：用类型、Schema、依赖方向、路由注册和生成客户端固定契约。

4. 变更约束：先计划再编辑，限制文件范围和差异规模，禁止无期限兜底。

5. 验证约束：Lint、单元、契约、集成、端到端和回归测试逐层门禁。

6. 权限约束：沙箱、工具白名单、最小权限和高风险动作审批。

7. 学习约束：把重复出现的评审意见沉淀为文档、规则、测试和模板。

AI工程质量

明确意图 × 可读仓库 × 机械约束 × 快速反馈 × 人工边界

这里使用乘法，是因为任何一项接近零，其他能力再强也很难弥补。模型升级可以提高生成上限，却不能替企业定义业务边界和工程责任。

11、AI开发也需要变更管理，而不是只有代码生成

传统ITSM用变更申请、影响分析、审批、实施、验证和回退控制生产变更。Agent开始大量写代码以后，这套思想并没有过时，反而需要变得更自动化。

需求或缺陷进入任务系统，形成结构化变更契约；

Agent读取CMDB和代码地图，识别受影响的应用、接口和责任团队；

系统按风险分配工具权限、测试门禁和人工审批；

执行过程保留代码差异、命令、测试和评审证据；

发布后观测业务指标，异常时能够定位变更并快速回退。

这也是AI Native ITSM值得探索的方向：不只是让AI回答工单，而是让AI产生的每一次工程变更都有范围、有责任、有证据、可验证、可回退。

结语

企业不是要通过更多Prompt“管住”AI，而是要把隐性的工程经验变成仓库事实、结构规则、验证门禁和权限策略。

好的约束不会阻止AI发挥。它会把架构、安全和质量的选择提前固化，让Agent把算力集中在边界内的实现问题上。

AI开发真正的反模式，不是模型偶尔写错代码，而是企业把一个概率型生成系统直接接进生产工程，却没有为它建设可执行的边界。

我们正在开源构建 AI Native ITSM：

https://github.com/heidsoft/itsm

参考资料：

OpenAI，Harness engineering: leveraging Codex in an agent-first world：https://openai.com/index/harness-engineering/

GitHub Docs，Best practices for using Copilot to work on tasks：https://docs.github.com/en/copilot/using-github-copilot/using-copilot-coding-agent-to-work-on-tasks/best-practices-for-using-copilot-to-work-on-tasks

GitHub Docs，Adding repository custom instructions：https://docs.github.com/en/copilot/how-tos/configure-custom-instructions-in-your-ide/add-repository-instructions-in-your-ide

Anthropic，Building effective agents：https://www.anthropic.com/engineering/building-effective-agents