泥潭日报 uscardforum · 每日精选

被Claude code征服 - 第一次让我感受到了AI革命

内容摘要

Claude Code 提升编码效率,依赖额度与稳定性。

1. 关键信息

  • 需 Pro/Max 5x 额度支撑;服务器不稳定易中断(#16)。
  • 上下文窗口限制影响体验(#46, #47)。
  • 适合逻辑简单、功能实现任务,复杂逻辑易烂尾(#13, #32)。
  • 需配合 Git 回滚优化工作流(#23, #26)。

2. 羊毛/优惠信息

3. 最新动态

4. 争议或不同意见

  • 有人认为 Copilot/Opus 4.6 更具性价比(#17, #21)。
  • 部分用户反馈 Claude 在代码审查与复杂逻辑上仍需人工介入(#32, #38)。
  • 中转站可能阉割上下文或涉及灰产(#53)。

5. 行动建议

  • 评估任务复杂度,小白从简单项目起步。
  • 监控额度使用,适时升级 Max 或考虑中转站。
  • 结合 Git 版本控制提升可维护性。
原始内容
--- 第 1 楼来自 Sunnigjr 的回复 (2026-03-02 21:16:28 PST) ---

作为一个 coding 小白,本来对所谓的AI 革命持怀疑态度,直到这两天试了一下被 Claude Code 彻底震撼了:以前很多想搞但不会实现的 idea,这两天全都 vibe 出来了

但有几个槽点不发不快:

额度: Pro 真的别想了,在 Claude Code 面前完全不够刷。我已经买了 Max,亲身体验确实需要这 5x 的额度才勉强够使用

稳定性: 今天这服务器咋回事,早上挂一次,现在又 Down 了,在创作热情最高涨的时候被浇冷水,难受,于是来发个帖子缓解一下

坛友们最近都在用它搞什么?除了强上 Max 20x,大家还有什么解决额度焦虑的姿势吗?

--- 第 2 楼来自 258 的回复 (2026-03-02 21:18:00 PST) ---

max20x买了不亏吧

--- 第 3 楼来自 Sunnigjr 的回复 (2026-03-02 21:20:32 PST) ---

我也觉得应该不亏,我现在一周在5x 90% limit附近,平时常常会看一下usage limit,然后焦虑,今天好像出bug了不显示usage limit于是今天就不焦虑了 在用几周看看要不要升到20x

--- 第 4 楼来自 258 的回复 (2026-03-02 21:21:32 PST) ---

开了过几天选择降级就会有retention offer

--- 第 5 楼来自 Sunnigjr 的回复 (2026-03-02 21:21:51 PST) ---

nice!

--- 第 6 楼来自 Wujiu 的回复 (2026-03-02 21:23:56 PST) ---

真小白吗 lz什么水平

最近也想上手玩一玩

--- 第 7 楼来自 eRic.DDDDDX 的回复 (2026-03-02 21:25:05 PST) ---

【引用自 Sunnigjr】:
作为一个 coding 小白

--- 第 8 楼来自 CB2 的回复 (2026-03-02 21:27:22 PST) ---

我原先也是这么想的,直到自己的代码里被拉了一大坨屎,还没法人工debug只能整个module删了重写

--- 第 9 楼来自 Sunnigjr 的回复 (2026-03-02 21:27:54 PST) ---

只会hello world的小白

--- 第 10 楼来自 Sunnigjr 的回复 (2026-03-02 21:28:36 PST) ---

哈哈 对于小白来说 就是 能实现和不能实现的区别,真的是解放了思想

--- 第 11 楼来自 金卡会员 的回复 (2026-03-02 21:28:38 PST) ---

支持claude

--- 第 12 楼来自 金卡会员 的回复 (2026-03-02 21:28:52 PST) ---

不向五角大楼低头

--- 第 13 楼来自 ztik 的回复 (2026-03-02 21:31:26 PST) ---

我的感觉是,有一个idea想用ai实现,最初的30%-40%可以很顺利实现,当框架搭建起来后,精雕细琢部分会很快失去耐心,烂尾在那里

--- 第 14 楼来自 CB2 的回复 (2026-03-02 21:33:01 PST) ---

对于逻辑不复杂的代码。只需要实现某个功能确实是革命性的,举个例子,你要个网站,cc做个前端,设计数据库之类的他很行,他可能知道怎么用库处理高并发,但要他自己写thread或者mq处理并发(虽然我也不会),基本上就是胡扯

--- 第 15 楼来自 Sunnigjr 的回复 (2026-03-02 21:33:34 PST) ---

确实有可能,好在我现在的想法还很小(毕竟小白) 没那么复杂

--- 第 16 楼来自 zzr215 的回复 (2026-03-02 21:36:14 PST) ---

【引用自 Sunnigjr】:
今天这服务器咋回事,早上挂一次,现在又 Down 了,在创作热情最高涨的时候被浇冷水,难受,于是来发个帖子缓解一下
中年人学点东西不易(同样coding零基础),替发小(国内)开了Pro,他说一块儿用,结果我一天都没用。然后他今天来找我说:开200的max,太爽了。好不容易调动起来情绪学了一天,发现的确好用,然后Claude服务器就挂了

--- 第 17 楼来自 CB2 的回复 (2026-03-02 21:40:53 PST) ---

你们都真花自己钱开200的max啊,我觉得copilot能有cc 90%的效果,价格只要cc的1/10.只要你知道自己需要implement什么,写的prompt够仔细,copilot可以用opus 4.6(虽然3x,但一次换算下来一毛钱)连续跑几个小时不带停的

--- 第 18 楼来自 zzr215 的回复 (2026-03-02 21:45:18 PST) ---

我帮人开的,没花我钱啊 等过一阵我要自己用的话试试你说的方法

--- 第 19 楼来自 hahaandhehe 的回复 (2026-03-02 21:50:03 PST) ---

【引用自 CB2】:
copilot
copilot 里面的 claude and openai model 是残废的

context window 比原版 claude or open ai models 小很多,claude model 残的更多

reddit 上说更高级的 copilot plan 也是同样残疾,没有满血原版。

--- 第 20 楼来自 crazyconsultant 的回复 (2026-03-02 21:53:06 PST) ---

今天claude挂不是说因为中东被炸了吗 这你也能赶上

--- 第 21 楼来自 CB2 的回复 (2026-03-02 21:56:07 PST) ---

claude的模型context window比cc基本上砍一半吧,但中途会给你自动compact而且不会额外算request。opus4.6刚出那会高强度用cc和copilot用了几天,感觉copilot出来的效果还算可以,比cc稍微差一点

--- 第 22 楼来自 不知道是谁 的回复 (2026-03-02 21:56:41 PST) ---

体感codex比claude好使多了

--- 第 23 楼来自 xhxhxhxh 的回复 (2026-03-02 21:58:05 PST) ---

没git?

--- 第 24 楼来自 CB2 的回复 (2026-03-02 22:00:31 PST) ---

和git有什么关系吗

--- 第 25 楼来自 Allen_Z 的回复 (2026-03-02 22:05:24 PST) ---

因为ta在装逼 我觉得ta可能不懂git和OOD

--- 第 26 楼来自 xhxhxhxh 的回复 (2026-03-02 22:06:31 PST) ---

我意思是直接git reset到之前可用的commit,这样就不用删了重写

--- 第 27 楼来自 hoodl 的回复 (2026-03-02 22:06:34 PST) ---

commit之前不看一眼?

--- 第 28 楼来自 serelee 的回复 (2026-03-02 22:43:09 PST) ---

不是。是最近用的人疯狂涨

--- 第 29 楼来自 CB2 的回复 (2026-03-02 22:44:07 PST) ---

是个用来优化一个图的module,用的是一个特定算法(15年的paper,其实算老的),简单的就是拼接,也能用就是效果烂,cc搞不定 读论文-理解算法-写出来算法 这个事情,网上有python的implementation他也不太抄的明白。和version control没有什么关系

--- 第 30 楼来自 bujidao 的回复 (2026-03-02 23:51:31 PST) ---

因为llm就是个超强记忆的傻子 不用指望它真的理解读懂一个新概念 纯靠pretraining的数据 俗话说吃老本

--- 第 31 楼来自 bujidao 的回复 (2026-03-02 23:56:06 PST) ---

?关于dc被炸 aws自己都出公告了

--- 第 32 楼来自 Pericles 的回复 (2026-03-02 23:58:01 PST) ---

有些坨过大,或者逻辑比较复杂,很容易出现一些似是而非的东西,review非常花时间,稍微一偷懒就容易shi山

--- 第 33 楼来自 002 的回复 (2026-03-03 00:04:15 PST) ---

有答案可抄的时候是好用的,没答案可抄的时候就乱来了。

--- 第 34 楼来自 002 的回复 (2026-03-03 00:05:19 PST) ---

对对对,我也是这么评价的,就是有一个巨型抄答案机器

想到我对十年前大热的机器学习的评价就是计算机辅助统计学

--- 第 35 楼来自 002 的回复 (2026-03-03 00:25:08 PST) ---

当你依赖它了以后会产生惰性,然后就懒得看了

--- 第 36 楼来自 DeusX 的回复 (2026-03-03 01:07:40 PST) ---

那你是小看 cc 了。问题真出现了能复现了,cc 给你写的明明白白

--- 第 37 楼来自 harvey8 的回复 (2026-03-03 01:09:38 PST) ---

Claude Code 真正革命的地方不在于它懂算法,而在于它懂你的 Repo。 它把原本需要你手动 grep、手动跳转定义的脏活累活全干了。所以没答案时它会乱来,但对于 90% 的工程任务,答案就藏在你的已有代码和官方文档里。

而且,cc 厉害在它是一个 能闭环执行的 Agent ,而不仅仅是一个聊天框。

--- 第 38 楼来自 CB2 的回复 (2026-03-03 01:59:59 PST) ---

写了几十个test,出问题了就加,每次都能整出新问题,实在不想浪费时间在这个上了

--- 第 39 楼来自 jzj 的回复 (2026-03-03 02:13:51 PST) ---

我想到了这篇文章: The reasons for the big discrepancy between satisfied vs dissatisfied developers using AI for coding

有coding大神被 Claude Code 征服的吗?

--- 第 40 楼来自 AmmiNi 的回复 (2026-03-03 02:42:18 PST) ---

比如kalpathy?但是我觉得更多的是“ai做的速度快”以及“能做”而不是做得足够好。还是需要人不停的微调(是不是用ai微调无所谓)

--- 第 41 楼来自 Startrek 的回复 (2026-03-03 03:08:28 PST) ---

至少现在的ai绝对做不到不需要人参与的程度

--- 第 42 楼来自 jian 的回复 (2026-03-03 04:50:24 PST) ---

我觉得带着娃自己写个app挺好的

--- 第 43 楼来自 fularji 的回复 (2026-03-03 05:14:00 PST) ---

可以买第三方代理 按量收费 正常情况下应该比20x便宜

或者可以拼车反重力ultra 给的opus量很大

--- 第 44 楼来自 charliemisaka 的回复 (2026-03-03 05:20:39 PST) ---

改UI方面的还是有一些小问题,但是已经足够amazing了。我用20块一个月的cursor已经干了几个小项目了

--- 第 45 楼来自 无名之辈 的回复 (2026-03-03 05:32:31 PST) ---

其实最后ai的隔阂就是有没有钱买token

--- 第 46 楼来自 Sunnigjr 的回复 (2026-03-03 05:37:46 PST) ---

还有个问题:CC的context window好像很小,动不动就要compact conversation,这会影响claude进行coding的质量吗?

--- 第 47 楼来自 skyblu 的回复 (2026-03-03 05:43:43 PST) ---

context window是模型决定的和cc没啥关系吧除非你需要提前compact

一般模型记忆力也没那么好200K完全够用了吧 有钱可以上1M的model

--- 第 48 楼来自 002 的回复 (2026-03-03 09:25:56 PST) ---

对的,这一点我也觉得很神奇,就是它可以知道我在说什么并且精确地找到要改的东西/地方。

不过这应该不是LLM的功劳,应该是写Agent的程序员小哥建立了某种机制/数据结构用来deserialize代码库,利用LLM的功能来帮助找到要改的地方,以及怎么改。

--- 第 49 楼来自 金卡会员 的回复 (2026-03-03 21:31:16 PST) ---

是的,而且不太懂coding的话一旦有一个blocker就g

--- 第 50 楼来自 Upsfedex 的回复 (2026-03-03 21:36:01 PST) ---

有代码洁癖的人不活了。。。

--- 第 51 楼来自 DOOMFIST 的回复 (2026-03-03 22:02:28 PST) ---

中转站api跟原生subscription比差别大吗

--- 第 52 楼来自 incheonnn 的回复 (2026-03-04 12:22:28 PST) ---

为啥我无法注册

--- 第 53 楼来自 Onvon 的回复 (2026-03-04 12:29:32 PST) ---

中转站有可能会对prompt和context做优化(ie 阉割)压低成本

也有很多中转站的钱是灰产来的

--- 第 54 楼来自 uplus5f7b 的回复 (2026-03-04 15:46:42 PST) ---

反正公司是不会再买牛马而是买token了

--- 第 55 楼来自 jnnksn 的回复 (2026-03-04 16:01:18 PST) ---

codex怎么样?ChatGPT反正订阅了不用白不用

--- 第 56 楼来自 CB2 的回复 (2026-03-04 16:45:17 PST) ---

只用过一次,对着plan写还是有些问题,有些逻辑太难他就直接偷懒不写

--- 第 57 楼来自 Tarmagu 的回复 (2026-03-04 16:54:54 PST) ---

虽然我非常认同这篇文章的观点,但我心底总有一丝担忧:这会不会就像精通剑技的武士在讨论哪些人会喜欢火枪?