泥潭日报 uscardforum · 每日精选

OpenAI会不会被Claude夺舍啊

内容摘要

Claude在编码领域表现强劲,引发是否会被夺舍的讨论。

1. 关键信息

  • Claude编码能力突出,界面/parser/schema理解快,可快速调整并跨端移植 (#1, #8, #14)。
  • Claude在调试和精准定位问题(如null值)上优于GPT-5 (#14)。
  • 用户粘性高,企业与开发者已形成依赖,迁移成本高 (#18)。
  • 混合本地与云端LLM成为趋势,本地部署Qwen-3等模型可媲美云端 (#31, #34)。
  • Claude出现过自动记忆与上下文更新行为 (#40)。

2. 羊毛/优惠信息

3. 最新动态

  • GPT-5发布在即,预期在coding上有提升 (#13, #5)。
  • 本地部署DGX Spark与Qwen-3 80B+embedding栈性能强劲 (#34)。
  • Claude稳定性与价格争议,token限制促使转向免费模型 (#22, #24)。

4. 争议或不同意见

  • 模型差距不大,各有擅长:Claude编码强,GPT写文章更细腻 (#19)。
  • 迁移困难:企业习惯与成本权衡,偏好稳定而非低价 (#18)。
  • 本地部署受硬件与成本限制 (#32)。

5. 行动建议

  • 开发者可结合Claude与ChatGPT/Gemini,按任务分发选择模型。
  • 尝试本地部署轻量模型以降低长期成本与提升隐私。
原始内容
--- 第 1 楼来自 Ansel 的回复 (2025-07-30 00:41:14 PDT) ---

最近在网上看到有人说Vibe Coding像摇老虎机,诚不我欺!仅仅两个晚上我就把之前想做的个人财务管理,日程管理(特别加了信用卡管理)和读书记录这三个软件写了。不得不说Claude在web 设计这块简直是无敌的存在,界面/parser/schema等方方面面一点就通,如果第一下没戳中G点,只需稍微点拨它也能迅速调整到位。接下来想移植到iOS或者安卓,一句话就能“翻译”,不知道调试体验能不能一样无脑。

这样下去OpenAI会不会被夺舍啊?Claude发力做coding策略太正确了,o4试了几次感觉好像不如Claude Sonnet。OpenAI在对话这块仍然是“废话学”的王者,随便问个现象学问题,它就能洋洋洒洒给你整出几千字的现象学报告。Agent也试过,但总感觉要输入大量个人隐私偏好,结果才能有用,速度也太慢。OpenAI的战线是不是铺得太广了?盈利预期会不会没有Claude好啊?结果最后起了个大早赶了晚集?

有没有啥跨端手机应用操作Claude或者Cursor啊?Vide Coding太适合手机时不时拿起来瞟一眼了!有人试过配置Slack Bot吗?

--- 第 2 楼来自 HyattConcierge 的回复 (2025-07-30 00:45:04 PDT) ---

OAI靠chatgpt的concept领先就已经死不了了

我觉得claude很有可能被gemini夺舍

反正这御几家里第一个倒的我猜就anthropic

--- 第 3 楼来自 hoodl 的回复 (2025-07-30 01:01:05 PDT) ---

Claude 我用着很好,只要指令给的足够小足够明确。
【引用自 HyattConcierge】:
反正这御几家里第一个倒的我猜就anthropic
为何?

--- 第 4 楼来自 oOTTOo 的回复 (2025-07-30 01:01:13 PDT) ---

现在推荐充值哪个啊 claude比chatgpt好不少?

--- 第 5 楼来自 HyattConcierge 的回复 (2025-07-30 01:01:57 PDT) ---

我觉得technology上的领先是最不值一提的,几个月就能赶上

rumor是gpt5最大的提升就是coding

像claude code这种又贵又没有切换成本的,gemini给你打个一折最后大家肯定都去给gemini

--- 第 6 楼来自 hoodl 的回复 (2025-07-30 01:03:07 PDT) ---

有道理,现金流为王。

--- 第 7 楼来自 93133795 的回复 (2025-07-30 01:04:15 PDT) ---

先不论画饼,目前大家能用的东西里面,claude code就是遥遥领先啊

但是就像上面说的,这个领域感觉很好追上,看大厂能不能发力出个更屌更便宜的

--- 第 8 楼来自 hoodl 的回复 (2025-07-30 01:04:24 PDT) ---

【引用自 Ansel】:
有没有啥跨端手机应用操作Claude或者Cursor啊?
有Windows PC的话试试远程桌面。其他系统看看能不能用SSH+CLI。

--- 第 9 楼来自 hoodl 的回复 (2025-07-30 01:05:11 PDT) ---

我对此的理论是:能出早就出了,现在没出将来很可能也出不来。

--- 第 10 楼来自 93133795 的回复 (2025-07-30 01:08:30 PDT) ---

qwen3-coder就不错啊,但是我没想到国产竟然比sonnet4还贵

--- 第 11 楼来自 hoodl 的回复 (2025-07-30 01:10:05 PDT) ---

“总算找到能应用的领域了,让我们狠赚一笔”?

--- 第 12 楼来自 aluckyboy 的回复 (2025-07-30 09:05:37 PDT) ---

ai再过几年 到时候所有models应该差别不太大了吧?

--- 第 13 楼来自 gedeepege 的回复 (2025-07-30 16:00:16 PDT) ---

先等7/31 GPT-5出来再说吧

--- 第 14 楼来自 Ansel 的回复 (2025-08-09 22:30:50 PDT) ---

有人试过GPT5吗?虽然整体上和Claude-4-sonnet Max大差不差,但我还是偏爱Claude一点,GPT5在一些细节问题有时让人无语:

遇到一个因为明显的null value而导致的网页显示问题,GPT5反复坚持说我的文件过时了,乐此不疲地反复删掉重新生成。相比之下,Claude仅一次就准确指出是哪个变量空值了,并且追踪到具体业务逻辑。

还有一个头疼问题,GPT5在修改代码时,会悄无声息删掉我的一些业务逻辑。在开发初期测试还不全的时候,我要过好久才能检查发现这些“被消失”的旮旯儿代码。

最后这个最有趣了,我的代码里有一个分支应该是 $varA = $varB,而另一个分支是 $varA = $varB + 1。但不知为何两个分支都变成了 $varA = $varB + 1。GPT-5 在处理这个问题时又开始“鬼打墙”,没能给出正确的解决方案。

感觉还是细分基座模型比较重要,广告可以吹嘘全能通用型模型,最好还是用个小的前置路由模型进行任务分发。GPT5应该也是用了吧?所以还是模型编程能力不足?

--- 第 15 楼来自 TheWorld 的回复 (2025-08-09 23:50:12 PDT) ---

不知道是不是我用得不对,claude帮我debug的时候一直把问题归因到无关的另一个小问题上,它自己发现不对疯狂道歉,但再聊一会提出的建议又是一开始的错误选项

--- 第 16 楼来自 ootiger 的回复 (2025-08-10 00:03:12 PDT) ---

1,claude是会这样,但是我也是一直在用claude,不确定其他家是不是也这样。

--- 第 17 楼来自 xxxyyy 的回复 (2025-08-10 00:55:08 PDT) ---

会写代码的人(和觉得自己能靠ai写的人)终究是少数。gpt能帮到绝大部分人,Claude只能帮到开发者,不一样的。

--- 第 18 楼来自 xxxyyy 的回复 (2025-08-10 00:56:35 PDT) ---

用户积累很重要吧,不然openai也没有理由能一直高占有率,在Gemini这些性能已经追赶上的情况下。目前并没有看到用户在别的模型相似性能价格便宜的时候马上切换过去,ChatGPT用户粘性巨高。

我一直劝ld用我免费薅的Gemini 2.5 Pro,但是就是不乐意,因为gpt用习惯了,宁愿付费都不愿意用免费的新模型。

Claude这件事也是一样的。领先半年追赶可能确实很快,但是大量企业和开发者在这半年已经选定好了用Claude作为自己的开发底座,可能都已经有大量的生成的代码库了,甚至已经开始盈利了。这个时候你说让他们换刚追上的其他公司的模型,就算便宜,他们估计也不乐意,稳定才是重要的(云服务也是如此,小公司迁移你说不上成本多高,但人家就是要给AWS交钱,用了那么久就是不想换)。

再举个例子,别说换成另一个公司的模型,我最近写AI Agent的时候,发现仅仅只是从一个公司的弱一点的模型换成强一点的模型,都导致我的agent变得很不稳定,prompt engineering之前搞的很多东西都要重新调整才能不出问题。

--- 第 19 楼来自 xxxyyy 的回复 (2025-08-10 01:05:24 PDT) ---

技术上差距应该不大,但是应该会各自擅长的点(有的写代码强,有的写文章更细腻,有的写文章更有创意),不可能一个人什么都做得好,因为涉及到创作的很多方面其实是主观的,众口难调。就跟汽车行业,不都是发动机变速箱什么的,但也能搞出来那么多牌子,每个品牌都有自己的拥趸

--- 第 20 楼来自 草莓饼饼酱 的回复 (2025-08-10 01:06:11 PDT) ---

会的。。经常会这样。。你要drive/oversee debug process。。

--- 第 21 楼来自 rey 的回复 (2025-08-10 03:54:10 PDT) ---

只有 chatgpt 有良好的 user memory。其他家认知有点问题,自降身份为 model api。从这点来说,Google 有戏追上openai,而 claude 会被收购。

--- 第 22 楼来自 arteryappeal 的回复 (2025-08-10 06:14:02 PDT) ---

这几家感觉就是强的方面太强弱的地方太弱了

Gemini 那个长 context 太好了,结果 Gemini CLI 就是一坨,连执行命令都不触发,UI 也做的差
Claude 实在太贵了,几乎每天都在卡 token 限制,根本不敢去用按用量的 API,coding 确实是好,而且对齐做得好可能我确实更信任他在我本地执行脚本,而且他可能是唯一家 $20 块钱级别客户端给 MCP 的
上面两家聊天界面都做的烂,ChatGPT 比他俩界面强太多了,但我感觉他们就是模型阉割的太厉害了,GPT4 前期感觉比什么 4o 和现在的 5 写东西好多了,5 我感觉幻觉比 4o 还严重

我以前也相信技术好的能活下来,现在我已经不太信了,看 Google 这么多年 Pixel 还这么半死不活的,我感觉他做用户产品可能是好不过这些更新更小的公司了

--- 第 23 楼来自 Rosmontis 的回复 (2025-08-10 06:47:17 PDT) ---

挺好的,我现在就是三家都用,coding用claude,架构系统聊天用chatgpt,学习研究用gemini。

--- 第 24 楼来自 gevilot 的回复 (2025-08-10 09:48:24 PDT) ---

【引用自 arteryappeal】:
Claude 实在太贵了,几乎每天都在卡 token 限制
感觉它就是故意想逼人转 Max 版,但对泥潭羊毛族结果可能是在预计需要在短时间内多问的时候转用免费 Gemini Pro。

--- 第 25 楼来自 icework 的回复 (2025-08-10 10:00:42 PDT) ---

首先 2C 和 2B 两个是非常不一样的

2C的通用大模型,技术各家以后都不会差太多,但是产品能力做的好不好就是决定因素。现在Chatgpt肯定是领先的。

2B 会有很多不同的垂类,这时候怎么样把自己的模型调试的好还是很看技术能力的,因为2B对于结果准确率的要求高太多了,大家也会只把最好的模型用在2B。 现在coding是2B最大的蛋糕,以后还会有其他领域。大的机会会被大厂刮风,小的机会startup也可以做的不错。

--- 第 26 楼来自 fredl 的回复 (2025-08-10 10:14:45 PDT) ---

gemini pro 实在太慢了

--- 第 27 楼来自 Ansel 的回复 (2026-02-12 23:42:12 PST) ---

感觉这个预测要收回一半——开放爱Codex配合最新的GPT5.3大模型编程体验已经超过Claude了:Claude速度慢,冗长啰嗦,每次对话开头还整一些云里雾里的长单词,自以为很有“个性”,有效内容少;而Codex这边代码刷刷刷出,干净利落,debug也直中要害。

当然,不同人使用coding agents感受也不同。我这段时间的体感总结如下:

上下文管理是关键,不光影响成本和速度,还关乎输出质量。要随时主动做compact和clear,不要等到自动压缩,上下文会decay。可以提示并行分支subagents,同时要尽量避免subagents改动同一份文件,最后合并超级浪费时间。
要想得到高质量代码,必须“诱导”大模型跃迁到高质量的代码语料压缩区,这时候高层语义关键词很有作用,本科那会儿痴迷于编程语言战争,由此熟悉的语言landscape中不同idioms感觉非常有帮助,比如希望改进局部代码质量,可以提示它从函数编程思维和尽量immutable的角度重构,效果立竿见影。
要让大模型跟随你独特的业务逻辑或者核心抽象,有时给它一个命名很有效,这种锚定作用能显著节省上下文,而且不太会被遗忘或者出现逻辑漂移的错误。

哎,总体感觉手搓代码不太妙啊

--- 第 28 楼来自 jackalsin 的回复 (2026-02-12 23:45:48 PST) ---

【引用自 hoodl】:
指令给的足够小足够明确
所有的tool不都这样么

--- 第 29 楼来自 mengyu202 的回复 (2026-02-13 00:05:00 PST) ---

【引用自 Ansel】:
Claude
不是最近已经被clawdbot威胁中么

--- 第 30 楼来自 索马里二当家 的回复 (2026-02-13 00:14:33 PST) ---

老哥写的很好 要不要展开说说

--- 第 31 楼来自 Ansel 的回复 (2026-03-15 20:51:12 PDT) ---

大家觉得,LLM的大型机终端到个人电脑tipping point,是不是就在今明两年?DGX Spark本地部署的 Qwen-3 80B + embedding 模型用来日常问答、写作辅助、个人知识库管理,体验都可以媲美或超越 OpenAI / Claude 的免费档了。

唯一短板是开源agentic coding harness跟不上,但我感觉问题不大啊,工作项目用公司的claude/codex账号,自己平时的项目也没那么复杂,不正好可以自己在开源harness上折腾吗?把之前写码经验沉淀进harness,不比写进SKILL白白送给公司好吗?

--- 第 32 楼来自 收束观测者 的回复 (2026-03-15 21:16:23 PDT) ---

【引用自 Ansel】:
DGX Spark
成本也太高了

摩尔定律不管用了

过去几年内存降价有限

--- 第 33 楼来自 Ansel 的回复 (2026-03-15 21:53:51 PDT) ---

不上Spark,其实2000刀的mac mini也够了,qwen3 30B也能摸到免费档,就是可玩性没有Spark那么高。本地部署很多好处啊,隐私,成本,论文随随便便往里扔,个人知识库也很有搞头

--- 第 34 楼来自 Ansel 的回复 (2026-03-18 10:17:39 PDT) ---

NVIDIA Developer Forums – 3 Feb 26

Building Local + Hybrid LLMs on DGX Spark That Outperform Top Cloud Models

Accelerated Computing

DGX Spark / GB10 User Forum

DGX Spark / GB10 Projects

llama3-70b-instruct
llama
jetson
nim
deepseek
nemotron

From “Can It Run?” to Sovereign Hybrid RAG on DGX Spark – Qwen3‑80B + vLLM + LiteLLM (Live Stack) 1. Why I’m Sharing This Stack My DGX Spark is now running a full hybrid RAG stack with Qwen3‑80B at roughly 45 tok/s, under 150 ms end‑to‑end...

阅读时间: 16 mins 🕑
赞: 45 ❤

--- 第 35 楼来自 Ryan2021 的回复 (2026-03-18 17:24:07 PDT) ---

claude崩了?各位能用吗?美东时间 2026年03月18日20:23:52

--- 第 36 楼来自 yelo 的回复 (2026-03-18 17:27:43 PDT) ---

好好的啊

--- 第 37 楼来自 Ryan2021 的回复 (2026-03-18 17:28:26 PDT) ---

谢谢。 我这一直显示这个

--- 第 38 楼来自 noby 的回复 (2026-03-18 17:30:02 PDT) ---

/uploads/short-url/8NPx1M11aQLkn1gGOpBqqArHdWH.png?dl=1 可能确实有问题

--- 第 39 楼来自 Ryan2021 的回复 (2026-03-18 17:34:11 PDT) ---

非常感谢

--- 第 40 楼来自 Ansel 的回复 (2026-04-08 21:28:21 PDT) ---

今天被Claude惊到了。 起因是昨天修bug时突发奇想,构思了一个挺orthogonal的新feature,就让Claude写了PLAN,随后顺手在Claude Code里用shell cmd把它复制到我的个人scratch路径。 结果今天在同一个库里修另外一个bug,结束后随手打了个/review。它识别出了今天的bug跟昨天PLAN有重叠并且更新了,神奇的是它竟然模仿我,把更新后的PLAN又复制到了scratch路径。 问题是这个PLAN完全是side-channel的事,到今天又隔了这么久,compact好几回了,我也没有提示说few-shot对齐我的习惯

--- 第 41 楼来自 收束观测者 的回复 (2026-04-17 18:51:30 PDT) ---

早就有自动memory系统了