大型系统里的代码修改很少是单个文件内的局部替换。一个支付状态的调整可能同时影响订单模块、库存模块和风控接口。MiMo Code 编程代理面对这类任务时，不是直接生成一个巨大补丁，而是先进入只读分析阶段，把变更边界、受影响的符号和验证手段确认下来，再进入执行阶段。这样每一轮修改都能对应到明确的测试信号，后续审查和回滚也更有依据。
一、大型系统修改为什么要先建立变更边界
大型代码库的复杂度主要来自隐式依赖。函数签名变更可能通过继承、反射或配置注入传导到完全不相邻的模块。很多回归不是新代码本身写错，而是破坏了某个未被测试覆盖的旧契约。直接让模型一次性修改十几个文件，看起来高效，实际会把问题推迟到合并之后。MiMo Code 的做法是先缩小影响面，把修改声明为受控单元。
变更边界包含三部分：
- 文件范围：列出允许改动的路径；
- 符号范围：标记将要修改的类、函数或接口；
- 行为约束：说明哪些公共 API 必须保持兼容。
代理在只读阶段用 AST 和调用图生成这些信息，人工确认后再进入写文件阶段。这个设计让后续每一步都有明确的检查对象，而不是依赖模型对全局影响的主观判断。
二、修改规划：用结构化文件锁定意图
MiMo Code 不会把任务描述直接当作执行指令，而是先产出修改计划文件。计划文件通常包含任务目标、文件清单、测试命令、验收标准和回滚策略。它的作用有两个：一是让人和代理对本次修改有一致理解；二是为后续验证提供脚本化入口。计划文件可以被版本管理跟踪，如果代理执行偏离，审查者可以立刻发现。
下面是一份简化的 plan.json 示例：
{
"task": "refactor payment state machine",
"scope": [
"src/payment/state.py",
"src/payment/handlers.py"
],
"symbols": [
"PaymentState",
"transition"
],
"tests": [
"tests/payment/test_state.py"
],
"acceptance": [
"all payment tests pass",
"public method signatures remain unchanged"
]
}
规划文件不是静态文档，它会随着执行反馈更新。比如第一次运行测试发现库存模块也依赖 PaymentState，代理会在计划中追加该模块的只读分析和兼容性测试。上下文裁剪也会参考这份计划：只把命中范围的源码、测试和文档放入模型上下文，避免无关代码占用窗口并引入噪声。
三、执行与验证：小步提交和快速回滚
执行阶段按计划文件中的单元推进。每完成一个单元，代理先运行最小测试集，再做静态检查。只有测试和检查都通过，才允许提交当前步骤。小步提交让差异审查变得容易，也让 git bisect 能定位到具体引入问题的提交。
python -m pytest tests/payment/test_state.py -q ruff check src/payment git diff --check git add src/payment/state.py git commit -m "refactor: adjust payment state transition"
如果测试失败，代理会先回滚当前单元。回滚可以基于 git stash 或文件快照。然后读取失败日志，判断是测试预期本身需要更新，还是实现偏离了计划。大量场景中，失败来自测试固件里的旧假设。此时代理会修改测试并附上原因，而不是静默跳过。回滚和重试都记录在计划文件的执行历史里，避免重复错误。
四、冲突处理与多人协作中的策略
大型系统通常由多个开发者或代理同时修改。MiMo Code 在写文件前会检查工作区状态，如果目标文件正在被其他任务修改，就暂停当前单元，等待合并或重新规划。基于文件的锁比全库锁更实用，能减少协作阻塞。并行代理之间的提交规范也要统一，比如提交信息携带任务编号，变更必须包含对应测试。
同一模块内部的不同区域仍可能发生语义冲突。例如一个代理修改状态枚举，另一个代理新增状态分支。计划文件中的符号范围可以帮助合并工具判断冲突是否可以自动解决。如果两个任务都声明了同一个符号，MiMo Code 会标记为高风险，要求人工确认合并结果，而不是自动选择一方。
从实际效果看，这种策略让大型系统代码修改从一次性大补丁转变为可审查的增量过程。它的核心不是让模型更强大，而是把代理放到一个反馈更快的环境中。每次代码写入都有测试、静态检查和回滚作为约束，代理的可靠性自然提升。对维护长期项目或接手遗留系统的团队来说，这种工作流比单纯追求生成速度更有价值。