现在 AI 已经可以承担相当一部分开发工作。

从分析需求、设计数据库，到编写接口、调整页面，甚至补充测试，很多工作都可以直接交给 AI。

但实际用下来，我发现一个问题：

AI 真正难控制的，往往不是它会不会写，而是它知不知道应该在哪里停下来。

明明只是增加一个字段，它可能顺手调整接口结构；只是修改一个状态判断，它却继续重构附近的代码。

最后功能虽然完成了，打开 git diff 却发现改动已经远远超出预期。

1、为什么 AI 总会“顺手多改一点”

最开始，我也会在提示词里反复强调：

不要修改无关代码。不要进行不必要的重构。尽量保持最小改动。

这些话并非完全没用，但效果不太稳定。

因为“无关代码”本身就是一个主观概念。

对熟悉业务的人来说，这次可能只是给订单列表增加一个导出按钮，原有查询、权限和数据结构都不需要变化。

但 AI 看到的可能是：

  • 查询条件来自公共组件；

  • 接口字段命名不够统一；

  • 当前导出方式不适合大数据量；

  • 附近还有几段可以抽取的重复代码。

于是，它会根据自己的理解继续向外扩展。

这些想法从技术角度看不一定错，但对当前需求来说，已经明显做多了。

AI 不清楚哪些旧逻辑是历史妥协，也不知道哪些公共代码牵涉其他业务。没有明确边界时，它只能自己补全。

2、需求确定后，不要马上让 AI 写代码

现在处理功能需求时，我通常不会把一句需求直接丢给 AI。

比如：

在订单列表增加导出功能，支持按照当前筛选条件导出数据。

这句话看起来已经比较明确，但真正实现时，仍然有很多问题：

  • 导出当前页，还是全部查询结果？

  • 是否沿用页面现有的筛选条件？

  • 导出字段是否和页面展示字段一致？

  • 哪些角色拥有导出权限？

  • 是否需要记录导出日志？

  • 数据量过大时如何处理？

  • 是否需要建设异步导出任务？

  • 能不能修改公共查询组件？

  • 历史数据是否需要特殊处理？

这些问题如果没有答案，AI 就会自己猜。

所以在功能需求基本确定以后，我会先补充本次需求的边界：

本次需求只实现订单列表按照当前筛选条件导出 Excel。 本次包含： - 订单列表增加导出入口；- 导出时沿用页面现有筛选条件；- 后端增加对应的导出接口；- 沿用系统现有权限校验方式；- 导出字段按照已经确认的字段清单处理。 本次不包含： - 不调整原有订单查询逻辑；- 不修改公共列表组件；- 不重新设计权限体系；- 不建设异步导出任务中心；- 不处理历史数据补偿；- 不升级或新增依赖；- 不顺带重构订单模块。 如果现有代码无法在以上范围内完成需求，先说明原因，不要自行扩大修改范围。

这段内容并不复杂，却可以提前挡住不少“顺手做掉”的内容。

3、需求文档和边界文档不是一回事

需求文档主要回答：

这次要做什么？

边界文档则需要继续回答：

做到什么程度？哪些地方不能动？

以“增加导出功能”为例，边界文档还需要说明：

  • 这个功能属于哪个业务模块；

  • 可以使用哪些现有能力；

  • 不能影响哪些已有流程；

  • 哪些数据允许导出；

  • 权限按照什么规则判断；

  • 原有接口结构能不能变化；

  • 哪些异常情况本次需要处理；

  • 哪些扩展功能留到以后再做。

在新项目里，很多东西还可以重新设计。

但现有业务已经有自己的数据结构、权限方式、状态流转和接口约定，不能因为 AI 认为另一种写法更好，就在一个小需求里全部调整。

边界文档的作用，就是把这些隐藏条件变成 AI 可以读取和核对的内容。

4、我的边界文档一开始也比较简单

最早整理项目文档时，我主要是把几个重要的技术问题先固定下来。

包括：

  • 新项目建设原则；

  • 系统初始化和数据导入；

  • 项目现状与建设基线；

  • 权限矩阵；

  • 多租户技术设计；

  • 数据库详细设计；

  • 接口契约设计；

  • 部署回滚与应急预案；

  • 监控指标与告警规则。

图一：最初整理的项目文档目录，内容主要集中在项目原则和核心技术设计上。

这一版已经能够解决一部分问题。

例如，AI 在修改接口前可以先看接口契约；处理权限功能前可以先看权限矩阵；涉及数据库时，也不需要完全依赖实体类和 SQL 反推设计。

但真正放进现有业务里使用后，我发现它还是偏技术。

很多容易导致 AI 越界修改的内容，并不在数据库和接口里，而是在业务规则、模块职责和验收范围里。

5、后来逐渐补成了一套边界文档

后面我重新整理了项目文档。

图二：结合实际业务补充后的边界文档目录，开始覆盖模块、数据、权限、规则和验收边界。

这次最大的变化，并不只是文件数量增加了。

更重要的是：每一类容易产生歧义的地方，都有了相对明确的文档入口。

项目范围与技术边界

说明系统负责什么、不负责什么，以及当前项目允许使用哪些技术方案。

它可以避免 AI 为了完成一个局部需求，临时引入新的框架、依赖或实现方式。

系统总体架构与模块边界

说明模块之间的职责和依赖关系。

一个功能应该放在哪个模块、哪些公共能力可以复用、哪些业务不能反向依赖，都可以在这里约定。

数据安全与隐私边界

限制敏感数据的查询、展示、导出和日志记录。

AI 在补接口或调试日志时，有时会直接返回或打印完整对象。对于存在用户信息和业务隐私的系统，这类修改需要格外注意。

客户端页面与接口覆盖矩阵

把页面、操作入口和后端接口对应起来。

修改某个页面时，可以先确认它实际涉及哪些接口，不需要让 AI 顺着调用关系调整其他页面。

机构与数据权限技术设计

权限矩阵解决的是“谁可以做什么”，数据权限还要回答“谁可以看到哪些数据”。

一个角色可能拥有查看权限，但只能查看本机构数据；另一个角色可以跨机构查看，却不一定拥有编辑权限。

这类规则如果没有写清楚，AI 很容易只控制前端按钮，却遗漏后端的数据范围。

业务状态机与规则矩阵

很多业务系统真正复杂的地方并不是增删改查，而是状态流转。

例如：

  • 什么状态允许编辑；

  • 什么状态允许撤回；

  • 什么状态只能查看；

  • 哪个操作会把数据推进到下一个状态；

  • 状态变化后需要触发哪些业务动作。

把状态和操作整理成矩阵以后，AI 可以先核对规则，不需要根据页面按钮或方法名称猜业务。

导入导出与文件安全设计

导入导出通常会牵涉数据范围、字段权限、文件类型、异常处理和敏感信息。

单独写一份设计，可以明确哪些内容属于当前需求，哪些扩展能力以后再做。

测试用例与验收清单

这份文档负责告诉 AI：

功能做到什么程度，就应该停下来。

只有需求，没有验收条件时，AI 容易继续补充一些它认为“可能有用”的功能。

验收清单明确以后，它只需要完成已经确认的内容。

6、README 用来告诉 AI 应该先看什么

文档逐渐增多以后，我又增加了一个 README.md。

它不需要写得特别长，主要说明每份文档解决什么问题，以及遇到不同需求时应该优先阅读哪些内容。

例如：

涉及权限调整： - 阅读权限矩阵；- 阅读机构与数据权限技术设计。 涉及接口调整： - 阅读接口契约设计；- 阅读客户端页面与接口覆盖矩阵。 涉及业务状态变化： - 阅读业务状态机与规则矩阵；- 阅读测试用例与验收清单。 涉及导入导出： - 阅读数据安全与隐私边界；- 阅读导入导出与文件安全设计。 涉及上线变更： - 阅读测试用例与验收清单；- 阅读部署回滚与应急预案；- 阅读监控指标与告警规则。

这样 AI 不需要每次把整个 doc 目录全部读一遍。

README 更像一个导航，根据任务类型告诉它应该优先阅读哪些文档。

7、先分析影响范围，再允许 AI 修改

即使边界文档已经比较完整，我也不会直接让 AI 开始实现。

通常会先让它阅读需求、相关文档和现有代码，然后做一次影响范围分析：

先不要修改代码。 请结合本次需求、边界文档和现有实现，确认： 1. 当前功能涉及哪些业务模块；2. 预计需要修改哪些文件；3. 每个文件为什么需要修改；4. 是否会影响原有业务；5. 是否存在文档中没有说明的问题；6. 是否存在需求与现有实现冲突的地方。 如果发现必须扩大修改范围，先说明原因，不要直接修改。

如果 AI 列出的修改文件明显太多，我会继续追问：

为什么必须修改公共组件？
不修改公共组件能否完成？
修改它会影响哪些已有页面？

先把这些问题弄清楚，再决定是否允许扩大范围。

这比改完十几个文件以后再回退省事得多。

8、把允许修改和禁止修改的范围写出来

影响范围确认以后，可以进一步限制本次修改：

本次允许修改： - 当前业务模块的页面；- 当前业务模块对应的接口和服务；- 完成当前功能所需的数据转换代码；- 已经确认的测试用例。 本次禁止修改： - 公共列表组件；- 公共权限模块；- 其他业务模块；- 项目配置和依赖版本；- 与当前需求无关的格式、命名和注释。 发现可以优化的地方可以单独记录，但不要在本次需求中直接修改。

最后一句比较重要。

AI 可以提出优化建议，但不要把“完成需求”和“重构代码”混在同一次修改中。

如果确实需要优化，后面再单独建立任务处理。这样代码审查时也更容易看清本次到底改了什么。

9、边界文档不能代替人工检查

边界写得再完整，也不能保证 AI 永远不会越界。

功能完成后，我会先让它按照文档做一次自检：

请根据本次需求和边界文档检查实际修改： - 修改了哪些文件；- 每项修改是否属于本次需求；- 是否改变了原有业务行为；- 是否存在额外重构、格式化或重命名；- 是否修改了边界之外的内容；- 是否还有未经确认的假设。 如果发现越界修改，先列出来。

然后自己再检查：

git statusgit diff --statgit diff

我通常先看修改文件数量。

如果一个很小的功能突然修改了十几个文件，就需要多留意一下。

接着检查：

  • 有没有整个文件被重新格式化；

  • 公共代码是否发生变化；

  • 接口结构是否被调整；

  • 原有业务判断是否被替换；

  • 是否增加了需求中没有提到的功能。

AI 的修改说明只能作为参考，最终还是以 diff 为准。

10、边界文档不需要一次写完

现在这套文档并不是一开始就设计好的。

很多内容都是在实际需求中逐渐补出来的。

遇到一次权限理解偏差，就把权限和数据范围写得更明确；遇到一次状态判断遗漏，就补充业务状态机；发现导出功能经常涉及敏感字段，就单独整理文件安全；验收时总出现理解不一致，就增加验收清单。

所以，边界文档不必一开始就追求面面俱到。

先把当前最容易出问题的地方写下来，后面每遇到一次真实问题，再补上一块。

慢慢地，这些文档就会从普通的项目说明，变成一套人和 AI 都可以使用的项目规则。

11、我现在处理需求的大致流程

目前在现有业务项目里，我大致按照下面的顺序处理：

  1. 确认功能需求；

  2. 补充本次包含和不包含的范围；

  3. 更新相关边界文档；

  4. 指定 AI 需要阅读的文档；

  5. 让 AI 分析影响范围，暂不修改；

  6. 确认允许修改的模块和文件；

  7. 按照最小范围实现；

  8. 让 AI 根据边界文档自检；

  9. 人工检查 git diff；

  10. 按照验收清单验证功能。

看起来比直接把需求交给 AI 多了几个步骤，但实际往往更快。

直接开始写，前面确实能省一点时间；一旦 AI 理解偏了，后面就要花更多时间检查、回退和重新解释。

12、AI 可以负责写代码，但边界仍然要由人决定

用了一段时间以后，我越来越觉得，不存在一句万能提示词，可以保证 AI 永远不动无关文件。

“保持最小改动”只能表达一个大致要求。

真正能够约束修改范围的，还是项目本身有没有明确的边界：

  • 模块由谁负责；

  • 数据可以流向哪里；

  • 不同角色可以看到什么；

  • 业务状态如何变化；

  • 接口结构能不能调整；

  • 哪些内容属于本次需求；

  • 做到什么程度算验收通过。

这些内容如果没有写下来，AI 就只能通过代码猜。

而在一个已经运行多年的业务系统里，只看代码通常是不够的。很多规则藏在历史原因、业务习惯和实际使用流程中，代码只能表达最后的结果，不一定能解释为什么必须这样做。

所以现在功能需求确定以后，我不会立刻让 AI 开始修改。

先补边界，再分析影响范围，确认以后才开始实现。最后无论 AI 说得多有把握，都要自己检查一遍改动。

AI 写代码可以很快。

但这次应该改到哪里为止，仍然需要人来决定。

大家在现有项目里使用 AI 时，会提前整理类似的边界文档吗？还有哪些控制修改范围的方法，欢迎一起交流。