原创 孔某人 2025-06-01 22:22 广东
谈为什么我认为应该用Claude Code+Claude Max 200刀订阅
本文更多是我5月使用GenAI模型产品的一些感受，但正好从我本月的一次分享中有一个视角可以做标题。
1、为什么说在变贵？
实际上与很多人理解的不同，GenAI模型价格一般是不变的，特别是海外市场。Claude 3.5 Sonnet发布距今已经快1年，但整个Sonnet系列的定价一直维持不变。实际上除了国内模型厂在上一轮打价格战时有所降价外，所有的LLM模型自发布之后都没有降价过。大家是通过发布新的更便宜的模型来实现替换的。
从应用层开发者的角度，分为两种情况：
应用已经PMF，此时会随着新的更便宜的模型推出而不断切换到更便宜的模型，实现模型推理成本降低。
应用尚未PMF，此时会随着更强模型的推出，而不断的换到更强的模型上，减少距离PMF的gap。
而从今年来说，后者一般都是在不断地换到更贵的模型上。也就有了本文的标题：对于尚未PMF的领域，应用层的模型推理成本正在不断增加，而并非大家所期待的下降。
换个角度也不难理解，大家需要的首先是有用，然后才是便宜，（再之后才是更好的满足个性化偏好）。一个“便宜的不可用垃圾”不如一个“昂贵但有用的工具”。
2、个人在5月的使用体验
对于遗留的自动化workflow场景，我目前使用的模型为Gemini 2.5 Pro和Claude 3.7/4 Sonnet。在一些场景还在使用GPT-4.5和o1 Pro。（这不是本节重点）
2.1、日常使用
在非workflow场景，目前我现在几乎唯一在使用的模型就是ChatGPT产品的o3+搜索。以至于我觉得ChatGPT不能设置默认模型给我带来的不小的困扰，因为有些时候会丢失上次使用的模型设置，变成4o。剩下在一些我不在乎时间，但希望更完整调研的场景，我还在使用OpenAI Deep Research（ODR）。
对于信息搜索、问题解决之类的效率场景，o3是独一档的存在，快速并调研/思考深入。对于ODR来说，似乎还有人总在讨论跟其他Deep Research的功能比如何，但o3目前是没有竞争者的。
2.2、Coding场景-Codex
我使用了一段时间ChatGPT 200刀Pro订阅的Codex，给我自用的小项目贡献了20个PR，它比我想象的好。我之前更多在用Cursor的Agent模式，大部分时候不开Max模式，只有在我觉得需要解决的问题context明显较长需要Max模式时才偶尔使用Max模式。
我也听到有人推荐Augment Code，因为它处理更大型的项目时效果更好。但截至目前我并没有使用过。
Codex给我的感觉是明显好于我对于Cursor的印象，特别是它的非Max模式。感觉也好于Max模式，但我并没有进行仔细比较。考虑到它是o3+RL针对性训练的，这理所当然。
不过Codex有着比较多的限制，例如：
一切工作都是基于GitHub repo进行的，生成的代码/patch也必须以 PR 形式输出。
只能绑定单个GitHub账号。
每个任务只能基于一个GitHub repo。
对于已经写完的PR，靠prompt进行细节微调还不如手工修改。因为容易破坏之前的结果，不能充分的遵从指令，还比较慢。
Codex agent在运行时不能联网（这是个故意的限制）
考虑到ODR会持续更新模型，所以Codex大概也会如此。我的这些使用体验大多是截止到5月上半月。
2.3、Coding场景-Claude Code
然后从5月25日开始，我开始尝试使用Claude Code，此时它已经更新为使用Claude 4系列模型。
Claude Code需要Claude Max订阅才能使用，或者是使用API按量计费。我个人使用感觉100刀的Max订阅很容易撞上用量限制，要使用的话请做好上到200刀Max订阅的准备。Claude在苹果渠道支付还会额外加收25%的苹果税，请考虑其他方式支付。在使用Max订阅的大部分时候，后台模型应该是Claude Opus 4。
Claude Code是在本地运行的，这使得它没有Codex的各种限制，而会在使用体验上有很大的差距。也能够让Claude Code扩展到更多的使用场景。
考虑到Codex和Claude Code的使用体验，我的评价是，月订阅费是否达到200刀是一个重要的分水岭。200 刀以下与以上的产品，在使用体验上仍能拉开明显差距。现在我会把Codex和Claude Code当成是一种Agent来对待，但Cursor仍然只像是一种高级的GitHub Copilot+自动导入代码片段和应用patch的辅助工具。
（当然Cursor如果全都用Max模式的话，应该能力也会有提升，但价格也会很贵，绝非20刀的水平。）
我认为所有自认为还在关注LLM模型能力前沿（对模型的评判落后于发布时间不超过2个月）的人都应该至少去用一个月的Claude Code（200刀Max订阅）。单就泛编程场景来说，它的200刀比Codex值得多。而且Claude Code的使用是需要想象力的，我自从开始用之后，就不断地在扩展它的用法。
下面列举我使用的几个场景：
【1】Claude Code as Deep Research
跟当初Devin就可以被当作DR工具一样，Claude Code也可以，Claude Code带有search tool。所有的输入、输出和中间步骤都以md格式存储。可以让Claude Code去做DR，用起来感觉跟其他DR工具一样好。（当然这并不是说它能全方位的不差于ODR。）而且它的可控性更好一些。
不过Claude模型在大规模的输出时仍然会懒惰，例如计划还没有执行完就停下来问你是否还要继续。
【2】多repo的联合分析工作区
很多人对于AI Coding工具的使用都是基于单个git repo的。但只要Agent能力足够强，其实你可以构建一个目录，把所有相关的项目repo都放进去，然后直接在根目录启动Claude Code进行使用。然后使用的体验就上了一台阶：
当你需要在多个项目之间来回切换/分析时，再也不用切换到目标项目。甚至也不必知道你的问题到底涉及哪些项目。整个项目都类似于知识库的感觉。当然Claude Code不是传统RAG的模式，它仍然是自主决策进行探索的。
天然的跨语言支持，从前端到后端，从算法到数仓，都可以在一个工作区内，在一次prompt中被分析。
当然这有个问题是，一些并不显然的信息在多个session中都需要调研时，会重复调研。但这可以通过人工构建一些文档放在工作区中，当然这些文档也是通过prompt要求Claude Code进行构建的。人工要做的就是设计需要哪些中间层面的文档，以及判断这些文档达到何种状态才算符合要求。
【3】Claude Code as Text2SQL
继续前面的多repo工作区用法，不光是代码可以放在其中，也可以把数仓中的表定义也都放在这个工作区中。
表没有说明？让Claude Code根据生产代码构建说明文档就好了。
然后基于生产代码、表的Schema和表的说明，就可以直接进行复杂的Text2SQL了。我没有用过这类产品，但我感觉这种用法已经很符合我对于Text2SQL的期待了。
如果我使用的数仓平台也能通过MCP接入Claude Code，由它自行进行查询执行和验证就更好了。当然这不是Claude Code的问题，是我用的数仓的问题。
在这个过程中，对于数仓发现的新信息和一些代表性任务SQL都可以统统放在工作区中。一些会反复进行的任务要求也可以放在CLAUDE.md中。虽然用起来还需要那么一点手动设计目录体系，需要手动编辑CLAUDE.md增加公共信息和要求。但这个随着不断使用而越来越熟悉场景的系统相对于之前用过的AI产品都是完全不同的。
【4】总结
实际上Claude Code已经开始超脱于纯Coding场景了。只要有一些自己组织和设计Context/Workspace目录内容的想法，就可以与Claude Code结合体验很接近于下一代Agent产品的效果了。这是我第一个感觉能够实用和定制通用Agent的记忆的产品和使用方式。
相对来说，Cursor的“基本版本”的体验就明显差了很多，特别是Cursor产品设计中并没有那种让你去进行“记忆配置”的引导。当然似乎Cursor也可以使用一些方式来模拟我上述的这种用法，但我对它是否能够完全对齐效果是存疑的。
目前的Claude Code（后面的模型）还没有得到RL的加持，当有针对性的RL优化之后，这个产品将变得更加可怕。
当然目前纯命令行的界面是有一些问题，但其实Cursor的界面我对比来说也没有感觉大幅改善。本质上这种场景首先看的开始智能，智能不够，在哪边编辑都不是很好的体验。而目前Claude Code这边是够的（Claude Opus 4）。
3、该给GenAI模型分配更多的预算了
虽然200刀似乎是一个贵的无法接受的价格，但这是我们不能正确判断其价值时才会有的感受。基于20刀的产品的功能去判断200刀定价的产品是否值并没有太多意义，特别是现在这个200刀产品的试用体验稀缺的时候。
现在我觉得包括PM在内的所有产研都应该去体验一个月的Claude Code。
在过去我试用Claude Code的一个星期中，我感受到了目前为止最大的智力放大杠杆。而且与Codex不同还很具有灵活性和可定性质。我在这个过程中感觉完成了之前基于其他所有产品都无法完成的任务，当然这与我这段时间的任务目标与之契合也很相关（更多的是在熟悉已有代码库）。
在过去的一个月中大概也是我感受到最大智力杠杆的时期。这并不是在大量的调用已有的workflow，而是完全独立的任务。我不只一天地撞上ODR的每日最大限额（大概20次）。我感觉如果没有这两个200刀的产品，我在过去1个月完全做不到类似的产出。
所以到这里让我回到本文的标题。很多场景其实还没有PMF，模型的智能提升仍然能够带来明显的使用体验提升。在这些场景中无论是应用的开发者还是用户，都应该考虑分配更多的AI预算了。至少今年模型厂都在刷智能，放在优化成本方面精力并不多。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 专栏简介 及 联系方式 2024。
本文于2025.6.1 首发于微信公众号
