上一篇文章《这次真不慌了，Claude随时可以取消订阅》发出来以后，评论区里有不少读者反馈，在他们的实际使用中，Kimi、GLM、Qwen等国产模型，与Claude相比仍然存在明显差距，有些任务国产模型来回修改几次都做不好，换成Claude之后却很快就能完成。
这些反馈当然不能简单理解为不会使用AI，其中可能有很多同样从事软件开发的人。后来我想了一下，大家的感受之所以如此不同，可能并不是谁高估或者低估了某个模型，而是我们虽然都在谈AI Coding，实际交给AI完成的却不是同一种工作。
模型之间的能力差距真实存在，但不会平均地出现在所有任务中。任务越模糊、链条越长、需要模型自己做决定的地方越多，Claude等旗舰模型的优势越容易被感受到；任务越清晰、拆解越充分、人工控制越强，Kimi、GLM等模型与Claude之间的实际差距就越容易缩小。
同样叫AI Coding，实际可能是完全不同的工作
现在只要使用自然语言让AI修改代码，大家都会把它称为AI Coding，但这里面包含的工作跨度非常大。
最简单的一类，是在现有项目里增加字段、修改页面或补充接口，需求、架构和实现方式都比较清楚，AI主要负责执行。另一类则是让AI进入陌生代码库，自己寻找模块、判断问题并设计修改方案。
再往前一步，有些人给AI的甚至不是一项开发任务，而只是一个产品想法。技术选型、系统架构、数据库设计、模块拆分、测试和部署，全部需要模型与编程Agent自行完成。表面上都是“让AI做一个功能”，背后需要的能力却完全不同。
真正拉开差距的，往往不是一段代码能不能写出来，而是模型能不能在信息不完整时作出正确判断，能不能理解很多文件之间的关系，能不能在执行很久以后仍然记得最初目标，以及第一次方案失败后，能不能找到真正原因，而不是继续在错误方向上打补丁。
Anthropic对Claude Opus 4.6的介绍，重点就放在更谨慎的规划、更长时间的Agent任务、大型代码库以及代码审查和调试能力上；Claude Code本身也不只是聊天窗口，而是一套能够读取代码库、编辑文件和运行命令的完整编程Agent。它的优势不只是代码写得更漂亮，而是在复杂任务中更少走错方向。
模型真正昂贵的能力，是替人做决定
假如需求已经明确，数据结构和接口都设计完成，测试条件也写清楚，那么模型面对的是一道有标准答案的执行题。但如果用户只说“帮我增加一个会员系统”，模型就要自己判断会员分几级、权益如何配置、权限在哪里控制、数据表怎样设计，以及修改失败后如何回滚。后一个任务未必多写多少代码，却包含了更多需要判断的地方。
Claude等旗舰模型的价值，往往就体现在这些判断中。一次正确的架构选择或根因定位，可以省掉很多返工。对于需要AI长时间自主工作，或者无法逐步检查结果的人来说，这种差距会直接转化为成功率和最终质量。
Kimi和GLM也在向这个方向进步。Kimi K3已经把长程编程、百万Token上下文和Agent工作作为主要能力，GLM-5.2同样把长时间任务作为升级重点。国产模型也在努力承担更多原本需要人完成的规划与执行。
但从“能够完成不少编程任务”，到“能够在复杂项目中持续作出正确决定”，中间仍然有距离。也正是在这段距离上，不同人的感受开始分化。
我的开发经验，只是减少了模型需要做的决定
从我自己的使用情况来说，大多数时候确实用不到最强的模型。原因并不是我认为Kimi、GLM已经在所有能力上与Claude相同，而是很多最考验模型的工作，在调用AI之前已经由我完成了。
做一个系统时，我通常会先确定需求是否合理，选择技术方案，划分模块和接口，设计数据结构，再把工作拆成可以独立完成和验证的小任务。交给AI的往往不是“帮我做一个系统”，而是“按照现有架构完成这个模块，并通过这些测试”。
当任务被拆到这个程度，模型需要猜测的内容已经很少。它更像一个执行者，只需要理解局部上下文、遵守已有规则并产出代码。只要模型跨过了基本能力门槛，更强模型增加的推理和规划能力，就不一定能够同比转化成效率提升。有时我真正关心的反而是速度、价格、额度和是否可以随时切换。
这并不意味着开发经验越深，就越感觉不到差距。另一些资深开发者经常处理遗留系统、复杂重构或陌生技术栈，对代码质量要求也更高，自然更容易发现模型之间的差别。
所以，开发经验真正改变的是人与AI如何分工。有的人用经验提前消化了复杂性，让AI在一条比较清楚的轨道上执行；有的人则希望AI进入未知环境，自行寻找道路。即使同样是专业开发者，这两种工作方式也会带来完全不同的评价。
我们使用的不是模型，而是一整套系统
用户实际感受到的“Claude”“Kimi”或“GLM”，通常并不是单独一个模型，而是模型、Agent、上下文管理、工具调用、项目规范以及用户自身能力共同组成的结果。
同一个模型放进不同的编程Agent里，表现可能完全不同。Agent怎样搜索代码、什么时候压缩上下文、如何运行测试、失败后是否回退、能否记住此前决定，都会影响最后结果。2026年的一项Agent Harness研究，在不更换基础模型的情况下，通过改进工具、中间件和长期记忆，把Terminal-Bench 2的通过率从69.7%提高到77.0%；另一项研究也发现，不同Harness会让同一模型每完成一个任务的Token成本相差数十倍。
这说明我们经常把一整套系统的体验，归因到模型名字上。有人说Claude更强，比较的可能是Claude模型加Claude Code的完整能力；有人说国产模型已经够用，背后可能是成熟的项目规范、清楚的任务拆解和持续的人工检查。
模型比较当然有意义，但进入真实工作后，更合理的比较单位是模型与Agent的组合，以及它在具体约束下能够交付什么结果。
国产AI Coding真正要解决的，是降低对使用者经验的依赖
从开发者角度看，未来未必需要为所有任务都使用最强模型。明确、可验证、执行性强的工作，可以优先考虑速度和成本；模糊、复杂、跨模块和长时间任务，则更值得使用能力更强的旗舰模型。同一个项目里，让不同模型承担不同层级的任务，可能比选择一个“永远最好”的模型更符合实际。
但对国产AI Coding产品来说，仅仅让有经验的开发者觉得“已经够用”，还不是终点。更大的市场来自那些没有能力提前设计架构、拆解任务和检查代码的人。对他们来说，真正需要的不是一个更会写代码的聊天机器人，而是一个能够主动澄清需求、发现矛盾、制定计划、运行测试并在失败后纠正自己的完整Agent。
国产模型与Claude之间真正需要缩小的，也不只是排行榜上的几分，而是结果对使用者经验的依赖程度。即使用户没有把任务描述得非常准确，没有事先搭好架构，也不知道怎样判断生成的代码是否可靠，Agent仍然能够把项目带到一个基本正确的方向，这才是真正降低软件开发门槛。
所以，Kimi、GLM和Claude的差距确实存在，但它不是一个固定数字，更不会在每个人的工作里以同样方式出现。有人测试的是代码执行能力，有人测试的是架构和规划，有人测试的是长时间自主工作，还有人比较的是包含Agent和工作流在内的完整产品。
大家得出不同结论，不一定是谁判断错了，而是他们测试的能力不同。模型是否够用，从来不只是模型单方面的问题，它取决于任务需要模型做多少决定，也取决于人和Agent已经替它解决了多少问题。
