有开发者称 Codex 无法独立完成 500 行以上的代码改动，并据此判断模型能力见顶，但大量相反经验说明行数并不是有效刻度。下面拆解三类真实原因：模型来源不可靠、Agent 框架与上下文准备不到位、存量代码与需求本身的问题，并给出一份可执行的排查清单和拆分策略。
一位开发者公开表示：超过 500 行的代码改动，Codex 根本无法独立完成，换成另一个模型也一样，并由此得出「自回归模型走到头了」的结论。评论区却几乎一边倒地给出相反经验——有人几十万行的项目一直在用，有人单次改动涉及十几个文件、几千行，还有人认为连更小的开源模型改 500 行都不该是问题。
两边说的可能都是真话，因为他们测的根本不是同一件事。把这场争论拆开，能得到一份相当实用的排查思路：先确认你手里的模型是不是你以为的那个，再谈行数。
一、「能改多少行」不是可比指标
diff 行数是结果，不是输入。模型真正看到的是上下文窗口里的文件内容、项目规则、示例代码和任务描述。同样是 500 行改动，可能是三个文件里的小重构，依赖清晰、有现成模式可抄；也可能是横跨四十个文件的横切改动，每处都要理解不同的调用链。后者对上下文的要求高一个数量级，但两者的 diff 行数完全一样。
所以「某模型一次改了两千行」和「某模型五百行都改不动」这两句话放在一起比较，在不知道仓库规模、任务描述质量、Agent 框架和上下文注入方式的前提下，没有任何信息量。
还有一层分歧是「改得动」的定义：编译通过算、跑通测试算、一次成型算、还是方向正确但需要人接手也算？标准不同，结论自然相反。
二、先排查模型来源，这是最常见也最容易被忽略的原因
从公开截图看，出问题的界面更像某个网页对话窗口或「智能机器人」，而不是官方 CLI 或 IDE 插件。这类第三方转发服务有几个共性风险：
- 模型替换：请求被路由到更便宜的模型或量化版本，界面上显示的参数不作数；
- 上下文被截断：system prompt 被改写、历史被裁剪，长任务直接崩；
- 数据留存：代码和提示词经过第三方，等于把仓库内容交出去；
- 服务不稳定：限流、断连、随时中断；
- 合规风险：这类转售通常不符合服务条款，账号可能被处置，不建议用在正式项目上。
稳妥做法是回到官方渠道：个人用官方订阅和官方客户端，团队走官方 API 并做好用量与密钥管理。如果所在网络环境访问境外服务不稳定，可以让合规的云服务商提供接入，或把开发环境放到网络稳定的机器上——例如整台 Mac mini 放在新加坡机房、按月远程使用，把长时间运行的 Agent 任务挂在稳定网络里，避免本地休眠中断长任务。选择前请自行确认数据合规与代码托管策略。
自检清单：
- 客户端来源与版本是否来自官方发布渠道；
- 请求日志里的
model字段是否与官方命名一致； - 官方控制台里能否查到这次调用的用量与账单记录；
- 用官方渠道跑同一个任务，能否复现「改不动」的现象。
需要提醒的是：网上流传的「随机数测试」「身份探测」一类方法，只能识别同一家模型内部的版本降级；如果转发方直接换成了另一家厂商的模型，这类测试分辨不出来。可靠的判断依据是官方账单记录加可复现的对照实验。
三、模型没问题时，问题通常在上下文工程
大量「改不动」的案例，换个用法就通了。可操作的调整：
- 写规则文件：把编码规范、目录结构、命名习惯、禁止事项写进项目根目录的规则文件，让 Agent 每次自动读取；
- 给示例：想让它按某种模式写，先在仓库里放一个同类实现，比在提示词里描述十遍有效；
- 先要计划再要代码：要求它先列出受影响的文件、改动点和风险，确认后再动手，能挡掉大部分跑偏；
- 限制单次范围：一次只处理一个模块或一条调用链，把大改动拆成有依赖顺序的小任务；
- 先定接口再填实现：先产出接口与类型定义，再让它逐个填实现，结构不容易塌；
- 缩小上下文：排除无关文件，只喂真正相关的部分，长上下文里的噪声会显著拉低准确率；
- 换 Agent 框架：同一模型在不同 harness 下的表现差异可以很大，工具调用、文件读写、测试回环的实现方式都会影响结果。
四、「能改」和「改得好」是两件事
讨论里有一条切中要害：AI 在有现成框架和样例时加功能很顺，一旦要扩展或修改原有架构，就容易用一堆 if-else 打补丁，而不是在基类上加一个虚函数。这跟行数无关，是缺少可模仿模式时的保守策略。
两种立场各有适用场景：
| 立场 | 适用场景 | 代价 |
|---|---|---|
| 跑通就行，事后再说 | 原型验证、一次性脚本、内部工具 | 技术债累积，维护成本高 |
| 必须符合既有架构 | 长期维护的核心业务代码 | 需要人工先定抽象、审 diff 结构 |
折中做法：抽象层由人先定，让模型只负责填实现；代码审查时重点看 diff 的结构而不是行数，发现补丁式写法就退回重做。
五、还有一类情况：代码本身和需求本身的问题
如果项目是长期叠加、文件关联复杂的存量代码，模型容易开始瞎写；如果需求描述含糊、验收标准缺失，模型只能用大量防御性代码和多余测试来兜底，看起来就像「改了一大堆但没解决问题」。这类问题换模型解决不了，得先补文档、补测试、把需求拆到可验证的程度。
六、小结
「500 行改不动」这个结论，最大概率来自三类原因的叠加：模型来源不可靠、Agent 用法不对、任务与代码上下文的准备不足。建议按下面的顺序排查，不要一上来就归因于模型能力：
- 确认走的是官方渠道，账单可查、结果可复现；
- 补上规则文件、示例代码和任务拆分；
- 检查 Agent 框架与上下文注入方式；
- 用同一任务在不同渠道做对照实验；
- 最后才考虑换模型。
模型能力确实有边界，但这个边界在哪里，需要在可控条件下测出来才算数。涉及具体模型版本、套餐与地区可用性的信息变化很快，请以官方最新说明为准。