ChatGPT、Codex实战：为什么AI一次改太多代码，反而更容易出问题？
很多开发者第一次真正把Codex用在大型项目里，会遇到一个非常奇怪的体验。
以前：
自己改代码。
一个Bug可能改几个文件。
每次修改的位置都非常明确。
提交之前，大概知道：
哪里变了。
为什么变。
风险在哪里。
但是现在：
你把任务交给AI。
例如：
“修复这个支付流程异常。”
几个小时后，AI返回：
- 修改8个文件；
- 调整多个函数；
- 新增工具类；
- 补充测试；
- 优化部分结构。
然后告诉你：
“任务已完成，测试通过。”
从结果来看：
非常漂亮。
代码更规范。
测试也通过。
效率提升明显。
但是很多开发者打开Diff以后，会出现一种新的焦虑：
“它到底改了什么？”
不是因为AI写得不好。
而是因为：
一次修改的范围，已经超过了人的理解速度。
这就是AI Coding时代一个越来越明显的问题：
AI正在降低代码修改成本。
但同时扩大了工程变化范围。
而软件工程真正害怕的，往往不是代码多。
而是：
不知道哪些变化会产生影响。
一、真实开发场景：AI解决一个问题，却改变了太多东西
假设一个项目出现一个问题：
用户提交订单偶尔失败。
以前开发者处理：
找到订单模块。
定位异常。
修改几个地方。
增加测试。
提交。
现在交给Codex。
AI开始分析：
订单创建。
支付流程。
数据库事务。
异常处理。
日志系统。
然后发现：
“这里存在多个潜在优化点。”
于是它不仅修复Bug。
还：
统一错误处理。
调整数据结构。
重构部分逻辑。
优化几个重复代码。
最后：
Bug解决。
代码质量看起来提升。
但是Review的时候，问题出现：
如果线上再次异常。
到底是哪一次修改导致？
如果需要回滚。
应该回滚哪个部分？
如果未来出现兼容问题。
影响来自哪里？
这就是为什么：
AI一次改太多代码，有时候反而增加风险。
因为问题从：
“有没有修好？”
变成：
“我们是否理解所有变化？”
二、为什么AI会倾向一次修改更多代码？
很多人会觉得：
是不是AI喜欢炫技？
其实不是。
背后有几个工程原因。
第一：AI看到的是关联关系
当AI分析一个问题时，它不会像人一样：
“只改这里。”
它会寻找：
相关调用。
上下游逻辑。
潜在影响。
比如：
你让AI修复一个接口。
它发现：
这个接口调用了三个地方。
三个地方又依赖另外几个模块。
于是它认为：
这些地方都属于问题范围。
从代码逻辑看：
它的判断可能完全合理。
但是工程实践里：
关联 ≠ 应该一起修改。
很多时候：
两个地方有关。
不代表：
它们应该同时变化。
第二：AI倾向优化当前状态
AI看到：
重复代码。
不统一结构。
缺少抽象。
通常会认为：
这些地方可以改善。
但是工程师考虑：
现在改是否值得？
风险是否超过收益？
未来是否真的需要？
所以AI容易出现一种情况：
它解决的是：
“代码看起来更好。”
但工程师关心：
“系统未来是否更稳定。”
第三：Agent拥有连续行动能力
普通聊天模式：
AI建议。
人执行。
Agent模式：
AI分析。
AI修改。
AI测试。
AI继续修改。
连续行动提高效率。
但也带来一个问题：
每一步决策都会影响下一步。
一次小判断错误，可能不断扩大。
三、背后的工程机制：Change Surface（修改面）正在扩大
软件工程里有一个非常重要的概念：
变化范围。
可以理解为：
一次修改可能影响多少东西。
以前：
人工修改。
变化范围通常比较小。
因为人的执行速度有限。
现在：
AI可以快速探索大量代码。
一次任务可能涉及：
文件。
模块。
服务。
数据库。
测试。
配置。
于是出现：
Change Surface扩大
也就是：
修改面越来越大。
修改面扩大以后，会带来三个问题。
第一：理解成本增加
代码不是越多越难。
未知变化才难。
如果你知道：
修改了A文件。
影响B函数。
很好判断。
但如果：
12个文件。
多个模块。
几十处变化。
你需要重新建立整个理解模型。
第二：验证成本增加
每个修改都可能正确。
但是组合起来可能产生问题。
比如：
A修改没问题。
B修改没问题。
C修改没问题。
但是：
A+B+C一起运行时出现问题。
这就是大型系统复杂性的来源。
第三：回滚成本增加
小修改：
出问题。
撤销。
大修改：
出问题。
你甚至不知道：
哪个部分应该撤销。
所以AI时代的重要能力之一：
不是让AI改更多。
而是控制：
修改面的大小。
四、为什么未来这个问题会越来越明显？
因为AI Coding的发展方向，就是更强的Agent。
未来AI不会只是：
帮你写一个函数。
而是：
完成一个Feature。
维护一个模块。
重构一个系统。
任务规模越大：
一次执行范围越大。
以前：
AI帮助开发者提高编码速度。
未来：
AI帮助开发者管理复杂任务。
但复杂任务最大的风险：
不是执行。
而是控制。
就像飞机自动驾驶。
自动化越高。
人不需要一直操作。
但是关键时刻：
必须知道系统正在做什么。
AI Coding也是一样。
未来开发者的重要能力：
不是阻止AI行动。
而是设计：
AI应该在哪些范围内行动。
五、可以用“修改半径”判断自己的AI阶段
这里可以建立一个自测指标：
AI修改半径
简单理解：
一次AI任务平均影响多大范围。
可以观察：
第一：
一次任务通常修改多少文件？
如果：
1-3个文件。
说明范围较小。
如果：
十几个文件。
多个模块。
说明修改半径扩大。
第二：
你Review时主要看什么？
如果：
看代码是否正确。
说明偏执行。
如果：
需要判断：
架构影响。
业务风险。
长期维护。
说明进入工程级协作。
第三：
AI修改以后，你是否敢直接提交？
如果：
基本可以。
说明信任成本低。
如果：
必须重新理解整个链路。
说明修改半径已经超过你的管理能力。
六、如何降低AI一次修改太多带来的风险？
第一：让AI先规划，不要直接执行
复杂任务不要直接：
“帮我修复。”
先让AI输出：
问题分析。
影响范围。
修改计划。
预计文件。
风险点。
确认以后再执行。
第二：限制任务边界
告诉AI：
只处理这个模块。
不要重构。
不要优化无关代码。
不要修改公共接口。
明确边界，比事后Review更有效。
第三：拆成多个小任务
不要：
一次完成整个功能。
拆成：
第一步：
定位问题。
第二步：
修改核心逻辑。
第三步：
补充测试。
第四步：
优化。
每一步都容易验证。
第四：让AI解释变化原因
不要只看：
修改结果。
要求AI说明：
为什么改。
影响什么。
有哪些风险。
这会降低理解成本。
第五：建立自动验证体系
包括：
自动测试。
代码检查。
CI。
类型检查。
安全扫描。
让机器先过滤问题。
不要把所有压力放在人身上。
七、修改半径小：Plus通常够用
如果你的情况：
个人项目。
小型功能。
简单Bug。
AI主要辅助：
写代码。
补测试。
优化局部逻辑。
一次修改影响范围有限。
你能够快速Review。
那么核心需求：
提高开发速度。
Plus通常已经可以满足。
八、修改半径大：Pro价值开始体现
另一类用户：
每天使用Codex处理：
大型Repository。
复杂Feature。
跨模块任务。
长期Agent流程。
你的问题已经不是：
AI会不会写。
而是：
AI产生的变化规模，是否超过人工处理能力。
如果你的开发流程已经具备：
测试。
Review规范。
任务拆分。
上下文管理。
但是仍然需要高频处理大量AI修改。
那么更高强度的AI使用方式才开始体现价值。
最后：AI时代，控制变化比生成代码更重要
过去：
优秀开发者：
写代码快。
未来：
优秀开发者：
管理变化快。
因为AI正在解决：
“如何产生代码。”
但软件工程真正困难的是：
“这些变化是否应该发生。”
AI一次改很多代码，并不一定代表它能力不足。
很多时候恰恰说明：
它已经拥有更强的工程行动能力。
真正需要提升的是：
人和流程如何管理这种能力。
如果AI只是帮助你完成明确任务：
Plus通常够用。
如果AI已经成为长期工程协作者，每天处理大量复杂修改：
Pro才开始真正匹配。
未来AI Coding竞争的核心，不是谁让AI写最多代码。
而是谁能够：
让AI在正确边界内，安全地产生更多变化。
持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。
葡萄城是专业的软件开发技术和低代码平台提供商，聚焦软件开发技术，以“赋能开发者”为使命，致力于通过表格控件、低代码和BI等各类软件开发工具和服务，一站式满足开发者需求，帮助企业提升开发效率并创新开发模式。
更多推荐
1
0- 0
已为社区贡献7条内容
所有评论(0)