3. 改个函数ClaudeCode把模块重构了。最近我在处理卡了挺久的账单合并Bug。当时我只想把支付模块里calculateTotalAmount这个金额计算函数的舍入逻辑微调一下,把原本的向零截断改成银行家舍入。代码很简单,也就是几行的事情。为了防止修改范围扩散,我特意在终端里敲了一句自以为很严谨的指令:只修改calculateTotalAmount本身的实现,确保金额计算正确,千万不要动其他地方。
我转头去抽了根烟,回来时看到终端里已经刷屏了。我发现自己低估了当前Coding Agent的工具链机制。它并没有老老实实地只读那一个文件,而是直接通过底层符号索引检索Symbol Index/Repo Search触发了引用回溯,顺着调用链把所有调用这个函数的上游节点全捞了出来。更要命的是,因为金额截断到舍入的语义变更影响了返回值边界,工具链在跑类型检查和自动化测试时直接吐了一堆报错反馈。整个工具执行链根据这些type/test feedback触发了多轮retrieval,直接基于符号索引与引用检索结果,最终确定了受影响文件集合Affected Files Set。
当我敲下快捷键打开Diff对比的那一刻,看着满屏红红绿绿的修改,我原本以为只会看到四五行的变动,结果映入眼帘的是十几个文件被改动。在多文件补丁生成策略Multi-file Patch的驱动下,它不仅改了目标函数,还为了对齐接口契约和实现类型一致性传播,把上游路由层的参数适配、Service层的签名同步、底层Utility的包装函数甚至一大批test case的快照全部级联修改了。这种全局一致性修复在视觉上极具欺骗性,看起来就像是它自发把整个支付模块的架构重写了一遍。
这种完全超出预期的改动规模,让我瞬间失去了对代码仓库的掌控感。这其实不是模型在主观上有了什么架构师的审美驱动,而是当前Agent编排系统Orchestrating System重视全局一致性的必然结果。回想以前用早期工具时,由于上下文窗口限制与检索策略保守,它更像个局部补丁生成器。而在当前一代coding agent工具链下,更激进的multi-file patch workflow配合更高recall的检索系统,让它变成了一个高一致性修复导向的系统。当type/test feedback这种硬性信号存在时,系统的流程控制会倾向优先进入错误修复路径,而不是严格遵守用户提示词里的局部编辑约束。
经历过这次Diff震撼后,我重新调整了跟Claude Code的协作工作流。面对这种具备依赖图传播修复能力的Agent,你不能再给它模糊的局部目标,否则它的检索范围扩散能让你大吃一惊。我现在必须手动切到Single-file Mode限制它的编辑权限,或者显式加上no dependency propagation changes这样的边界死锁,把任务拆成原子级的Commit步骤,每一步都强制停在Plan阶段人工Review。
你有没有遇到过Claude Code把一个小改动扩大成大重构的情况?
#Claude #程序员日常 #AI写代码 #真实生活分享计划 #OpenClaw