跳至正文
i@laoer.com

技术、生活、感悟 -- Laoer的博客

i@laoer.com

技术、生活、感悟 -- Laoer的博客

  • 首页
  • 关于
  • 首页
  • 关于
关

搜索

  • X
这次真不慌了,Claude随时可以取消订阅
人工智能博客文章

这次真不慌了,Claude随时可以取消订阅

作者 Laoer
2026年7月21日 1 分钟阅读
2

过去一年,Claude大概是AI Coding领域存在感最强的名字之一。

Claude 3.7之后,Claude 4、Claude 4.5再到后续模型,Anthropic几乎一直占据着编程模型第一梯队的位置。Claude Code的出现,又进一步放大了Claude模型在真实软件开发中的优势。从最初在Terminal里写代码,到后来增加Plan、Sub-agent、Skills、Hooks等能力,Claude Code逐渐从一个命令行工具变成完整的Coding Agent。

Codex也是类似的路径。随着GPT模型能力不断提高,OpenAI也开始把重点从“模型会不会写代码”,转向如何让模型独立完成一个完整的软件开发任务。

这两个产品很快成为AI编程领域的标杆,也让很多开发者开始产生一种过去很少有过的依赖。

这种依赖不是因为品牌忠诚,而是生产力。

在Reddit、X、GitHub以及各种开发者社区里,经常可以看到类似讨论:Claude Code很好用,但是账号、地区、额度和订阅政策的不确定性让人担心;Codex能力很强,但同样存在额度和平台依赖的问题。尤其对已经把Coding Agent融入日常开发流程的人来说,一旦习惯让Agent直接阅读整个项目、修改多个文件、运行测试、查找错误再继续修复,很难再退回以前复制代码到聊天窗口里问AI的方式。

所以过去大家担心Claude账号出问题,本质上并不是少了一个聊天机器人,而是暂时找不到同样好用的替代品。

但最近半年,这件事情正在发生变化。

国产模型终于跨过了“能不能用”的门槛

以前讨论国产模型和Claude、GPT的编程能力,最大的问题其实不是Benchmark差了多少分,而是落到真实项目里以后,体验差距往往比Benchmark看起来更大。

简单写一个函数、解释一段代码,大多数模型都可以完成。但进入一个几十万行代码的真实项目,让模型自己搜索文件、理解依赖、连续修改代码、执行命令、处理编译错误,再根据结果反复修正,差距就很容易暴露出来。

这也是为什么很长一段时间里,即使国产模型便宜很多,真正重度使用AI Coding的人还是会优先选择Claude或者GPT。生产力工具最重要的毕竟还是生产力,如果一个任务Claude Code一次能够完成,换一个工具需要人工来回纠正很多次,价格便宜的意义就没有那么大。

现在这种情况开始改变了。

GLM-5.2、Kimi K3陆续发布,Qwen3.8也开始进入市场,DeepSeek V4正式版同样值得期待。和一年以前相比,这一代国产模型已经明显不再停留在“会生成代码”的阶段,而是在长上下文、工具调用、Agentic Coding和长时间任务执行上快速进步。

最重要的变化并不是某个Benchmark超过Claude两分或者落后GPT三分,而是这些模型已经越来越能够真正参与软件开发。

过去国产模型和前沿闭源模型之间,很多时候是“能不能做”的差距。现在越来越变成“谁做得更好”的差距。

这两者其实完全不同。

只要进入“可以完成”的区间,替代关系就会开始发生变化。一个开发任务不一定非要Claude才能完成,可以使用GLM,也可以换Kimi、Qwen或者DeepSeek。模型之间的能力仍然有高低,但已经不像过去那样存在明显断层。

更重要的是,这些模型还在逐渐和具体的编程工具解耦。

一个模型可以接入不同的CLI、IDE和Agent Framework,一个Coding Agent也可以支持多个模型。模型开始越来越像AI Coding系统里的“发动机”,而不是整个产品本身。

一旦发动机可以替换,过去那种“Claude不能用,工作流就断掉”的焦虑自然会下降很多。

Claude Code真正领先的,已经不只是Claude

不过,如果只看到国产模型能力快速提高,就认为Claude Code和Codex很快没有优势了,也并不准确。

目前AI Coding真正明显的差距,已经越来越从Model转移到了Agent。

同样一个Claude或者GPT模型,放在普通聊天窗口里使用,和放进Claude Code、Codex这样的Coding Agent里,最终完成复杂开发任务的能力可以有很大区别。

原因在于,现在真正的AI编程已经不是简单的:

用户提出需求,模型生成代码。

真实的软件开发通常是一个很长的过程。Agent首先要理解项目结构,然后搜索相关代码,找到需要修改的位置,理解调用关系,制定方案,修改多个文件,运行编译或者测试,读取错误信息,再继续定位问题和修改。如果是一个复杂任务,中间还可能使用Git、浏览器、数据库、MCP工具,甚至启动多个Sub-agent分别处理不同工作。

模型当然是整个过程最重要的核心之一,但仅有模型并不能完成这一切。

把模型、工具、上下文和执行环境组织起来的这一层,就是现在越来越重要的Harness。

而让Agent不断执行“观察、思考、行动、获得反馈、继续行动”,直到任务真正完成,则是Loop Engineering。

这也是Claude Code和Codex现在真正领先的地方。

一个优秀的Coding Agent需要解决很多模型之外的问题。例如,一个大型项目不可能把所有代码一次性塞进Context,Agent必须知道什么时候搜索文件,什么时候读取源码,哪些内容值得长期保留,哪些内容应该在Context接近上限时压缩掉。

工具调用也是一样。什么时候应该使用grep,什么时候应该直接打开文件,什么时候运行完整测试,什么时候只运行局部测试,一个命令失败以后应该继续尝试还是改变方案,这些都属于Agent系统本身的能力。

还有一个非常关键的问题,是验证。

真正好用的Coding Agent不能只会写代码,还必须知道自己有没有写对。修改完成以后主动Build、Lint、Test,运行程序查看结果,发现问题以后重新修改,再次验证。这个不断反馈的循环,才让AI从代码生成器变成能够独立完成任务的Agent。

所以在很多开发者的实际评价中,经常会出现一种现象:两个模型在Benchmark上的差距并不大,但放进不同的Coding Agent以后,使用体验却可能差一个档次。

原因就在这里。

大家最终使用的从来不是一个裸模型,而是一整个系统。

国产AI Coding现在最大的短板,已经变成工具

这其实是一个很值得注意的变化。

过去国产AI Coding的问题首先是模型不够强,工具即使做得不错,上限也会受到限制。现在模型这一块正在迅速补齐,剩下更明显的差距开始集中到Harness和Loop Engineering。

目前国内已经出现了不少比较完整的AI编程产品,包括CodeBuddy、Qoder、TRAE,以及GLM、Kimi、Qwen等模型相关的CLI工具。和早期AI编程工具主要围绕代码补全、IDE聊天不同,这些产品现在也明显开始转向Agent。

它们已经可以阅读整个代码库、修改多个文件、调用Terminal、执行命令,并开始加入Plan、Sub-agent、MCP等能力。从产品方向来看,国内厂商和Claude Code、Codex已经没有本质上的路线分歧,大家做的都是同一件事情:让AI从“帮程序员写代码”,变成“直接帮程序员完成开发任务”。

真正的差距更多体现在工程成熟度上。

比如一个Agent执行一个复杂任务两个小时以后,还能不能保持最初的目标;Context越来越长以后,能不能正确保留关键的信息;中间执行失败以后,是不是能够主动换一种思路;面对一个大任务时,能不能合理拆分成多个小任务;多个Sub-agent之间怎么共享信息;代码修改完成以后,是否能够形成稳定的验证闭环。

这些事情单独看起来都不是什么特别惊人的功能,但最终决定Coding Agent是否好用的,恰恰就是这些细节。

Claude Code和Codex的优势,是它们已经通过大量真实用户和真实软件工程任务,把这些细节做成了一套越来越成熟的系统。

国产Coding Agent目前真正要追的,也正是这一层。

Harness的差距,可能比模型更容易追

训练一个前沿模型是极其昂贵而且复杂的事情。

需要大量GPU、数据、算法团队、训练基础设施和强化学习能力,而且竞争对手不会停下来等待。今天刚刚追上Claude,Anthropic下一代模型可能很快又出来了。

Harness不一样。

它当然也需要很强的工程能力,但很多问题已经从“未知问题”变成了“已知问题”。

今天一个先进的Coding Agent大概应该具备什么能力,行业实际上已经越来越清楚。

CLI、Plan模式、Sub-agent、MCP、Skills、Hooks、Sandbox、Git Worktree、Context Compaction、后台任务、自动测试和验证,这些方向已经被Claude Code、Codex以及其他产品不断验证。

后来者不再需要从零回答“AI编程工具应该长什么样”,而是可以直接学习已经被证明有效的设计,再根据自己的模型和用户场景快速迭代。

这和追赶基础模型的难度并不一样。

以前国内Coding Agent还有一个很现实的限制,就是即使Harness设计得不错,底层模型能力不足,整个系统仍然很难达到Claude Code的效果。

现在这个限制正在快速消失。

当GLM、Kimi、Qwen和DeepSeek逐渐进入前沿模型附近以后,Context管理优化一点、工具调用稳定一点、Loop设计成熟一点,都会直接反映到最终的产品体验上。

因此,我个人的判断是,未来半年国产AI Coding最值得关注的,可能并不是又有哪个新模型在Benchmark上超过Claude,而是CodeBuddy、Qoder、TRAE以及各家模型CLI会进化到什么程度。

我甚至认为,不到半年时间,国内头部Coding Agent就有机会在大多数常见的软件开发场景中,把和Claude Code、Codex之间的差距缩小到普通用户并不明显的程度,甚至在部分场景实现追平。

这里说的“追上”,并不是所有Benchmark全面超过,也不是每一个复杂任务都比Claude Code和Codex更强,而是作为生产力工具,已经能够成为真正平替。

对于用户来说,这才是最重要的标准。

如果Claude Code是100分,国产工具只有50分,那么基本没有替代价值。但如果国产工具已经做到85分或者90分,同时模型选择更多、价格更低、使用限制更少,那么很多用户并不会为了最后那10分一直绑定在同一个平台上。

竞争往往并不需要把第一名彻底打败。

只需要让第一名不再不可替代。

Claude最重要的变化,是从“必须用”变成了“可以选”

这可能才是最近这一轮国产模型进步带来的最大变化。

Claude Code目前仍然是最成熟的Coding Agent之一,Codex同样处在第一梯队。对于重度开发者而言,它们在复杂任务、长时间运行、上下文管理和整体稳定性上的优势仍然存在,这一点没有必要回避。

但和一年前相比,整个市场的状态已经完全不同。

以前是Claude和GPT站在前面,后面隔着很长一段距离才是其他模型。Claude账号、额度或者订阅一旦出现问题,用户很难立刻找到体验相近的替代方案。

现在下面已经有GLM、Kimi、Qwen、DeepSeek,工具层还有CodeBuddy、Qoder、TRAE、OpenCode以及各种CLI和Agent Framework。

模型正在变得可以替换,Coding Agent也正在变得越来越开放。

这意味着用户不需要再把全部生产力绑定在一家公司、一个账号或者一个订阅上。

AI Coding过去两年的主要竞争,大家一直在看模型。Claude和GPT到底谁写代码更好,新模型在SWE-bench又提高了多少,成为每次模型发布时最受关注的话题。

但是当模型能力逐渐接近以后,下一阶段真正决定AI Coding体验的,很可能越来越不是模型本身,而是Harness、Loop Engineering和整个Agent系统。

这场竞争才刚刚开始。

Claude Code和Codex目前领先,但国内的模型和编程工具已经进入同一条赛道,而且追赶速度明显加快。未来半年到底能不能追上,这是一个判断,现在当然还不能当作事实。

但至少有一件事情已经和以前不同了。

现在即使Claude调整订阅、限制额度,甚至账号真的出现问题,也不再意味着AI Coding工作流就没有了替代方案。

Claude好用,当然可以继续订。

哪天不好用了,或者有更合适的选择,也可以取消。

这次确实不用那么慌了。

标签:

AIAnthropicClaudeCodexDeepSeekGLMKimiLLMOpenAIQwen
作者

Laoer

关注我
其他文章
Kimi卖爆之后,我发现AI可能不是一门互联网生意
上一个

Kimi卖爆之后,我发现AI可能不是一门互联网生意

Kimi K3之后,我第一次觉得美国有点输不起了
下一个

Kimi K3之后,我第一次觉得美国有点输不起了

2 评论
  1. Kimi、GLM和Claude的差距,为什么每个人感受完全不同? – i@laoer.com说道:
    2026年8月3日 13:40

    […] 上一篇文章《这次真不慌了,Claude随时可以取消订阅》发出来以后,评论区里有不少读者反馈,在他们的实际使用中,Kimi、GLM、Qwen等国产模型,与Claude相比仍然存在明显差距,有些任务国产模型来回修改几次都做不好,换成Claude之后却很快就能完成。 […]

  2. DeepSeek Harness来了,国产AI Coding终于开始补最短的那块板 – i@laoer.com说道:
    2026年8月15日 12:00

    […] 前段时间,我在《这次真不慌了,Claude随时可以取消订阅》里写过一个判断:随着 DeepSeek、Kimi、GLM 这些国产模型的 Coding 能力越来越强,国产 AI Coding 与 Claude Code 之间最明显的差距,正在从模型本身转移到 Harness。 […]

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

微信订阅

欢迎订阅微信公众号--“Laoer杂谈”,搜索微信号:laoertalk,“Laoer杂谈”是关于技术、创业、生活的杂谈与随笔,希望与大家多多交流。

用药有数·DoseLoop

用药有数·DoseLoop 一款不会响完就消失的用药提醒。每次计划用药持续追踪,直到有明确结果。支持慢病、老人、ADHD 等各种用药场景。

标签

AGI AI AI Agent Anthropic Claude Claude Code Codex DeepMind DeepSeek Gemini GLM Google GPT iOS iPhone IT Java JavaScript jQuery Kimi Kohana Linux LLM Mac Memcached Meta Mysql Nginx O2O OpenAI Oracle PHP RSA Sam Altman SNS Struts Tomcat Web2.0 互联网 人工智能 创业 工作 旅游 生活 管理

日历

2026 年 10 月
日 一 二 三 四 五 六
 123
45678910
11121314151617
18192021222324
25262728293031
« 9 月    

近期评论

  • 99%的代码都由AI写了,那程序员真正值钱的是什么? – i@laoer.com 发表在《我把DeepSeek Harness接进生产环境后,发现AI运维真正改变的不是查日志》
  • 爱生活 发表在《你的一分钟语音,可能是别人的十分钟》
  • 爱生活 发表在《Bill Gates为什么突然不相信“AI最终会创造更多工作”了?》
  • DeepSeek Harness来了,国产AI Coding终于开始补最短的那块板 – i@laoer.com 发表在《这次真不慌了,Claude随时可以取消订阅》
  • Kimi、GLM和Claude的差距,为什么每个人感受完全不同? – i@laoer.com 发表在《这次真不慌了,Claude随时可以取消订阅》
  • 携程被罚51.79亿元,酒店行业终于出了一口气 – i@laoer.com 发表在《萝卜快跑真的砸了底层劳动者的饭碗吗?》
  • Kimi卖爆之后,我发现AI可能不是一门互联网生意 – i@laoer.com 发表在《当中国开始开源最强模型,OpenAI和Anthropic的护城河还剩什么?》
  • Kimi卖爆之后,我发现AI可能不是一门互联网生意 – i@laoer.com 发表在《瓜子 vs 天天拍车:一次卖车体验的对比与思考》
  • 最强的模型,不一定能赢:AI Coding开始拼“好用”了 – i@laoer.com 发表在《一个人、一款 App、一个月:从 DoseLoop 看 AI 时代 OPC 的可能与边界》
  • 2024年度总结 – i@laoer.com 发表在《瓜子 vs 天天拍车:一次卖车体验的对比与思考》

分类

  • iOS
  • Java
  • JavaScript
  • Linux
  • Mac
  • PHP
  • Web2.0
  • 互联网
  • 人工智能
  • 创业
  • 博客文章
  • 商业观察
  • 工作
  • 数据库
  • 构架设计
  • 生活

归档

  • 2026 年 10 月
  • 2026 年 9 月
  • 2026 年 8 月
  • 2026 年 7 月
  • 2026 年 6 月
  • 2026 年 1 月
  • 2024 年 12 月
  • 2024 年 10 月
  • 2024 年 8 月
  • 2024 年 7 月
  • 2023 年 12 月
  • 2023 年 1 月
  • 2022 年 8 月
  • 2021 年 12 月
  • 2021 年 10 月
  • 2020 年 12 月
  • 2020 年 1 月
  • 2018 年 12 月
  • 2018 年 8 月
  • 2018 年 4 月
  • 2017 年 12 月
  • 2016 年 12 月
  • 2016 年 8 月
  • 2016 年 2 月
  • 2015 年 12 月
  • 2015 年 1 月
  • 2013 年 6 月
  • 2013 年 5 月
  • 2012 年 11 月
  • 2012 年 7 月
  • 2012 年 6 月
  • 2012 年 5 月
  • 2012 年 3 月
  • 2012 年 1 月
  • 2011 年 12 月
  • 2011 年 11 月
  • 2011 年 10 月
  • 2011 年 9 月
  • 2011 年 8 月
  • 2010 年 11 月
  • 2010 年 2 月
  • 2010 年 1 月
  • 2009 年 12 月
  • 2009 年 11 月
  • 2009 年 9 月
  • 2009 年 7 月
  • 2009 年 6 月
  • 2009 年 5 月
  • 2009 年 4 月
  • 2009 年 3 月
  • 2009 年 2 月

其他操作

  • 登录
  • 条目 feed
  • 评论 feed
  • WordPress.org
Copyright 2026 — i@laoer.com. All rights reserved. Blogsy WordPress Theme