从第一次用 Claude，到逐渐离不开 Claude Code：一个开发者的真实使用变化
一、最开始接触 Claude，只是当作一个新工具试试
最早知道 Claude，其实并没有抱太大期待。
当时看到的评价大多是：
- 写代码更顺
- 上下文更长
- 更像一个“程序员模型”
但在实际使用中，一开始的场景很简单：
- 查 API 用法
- 写一些工具函数
- 改点前端样式
说实话，这个阶段和用 GPT 的差别并不算特别明显。
二、真正的变化：开始用 Claude 写完整功能
让我开始明显感觉到差异，是在一次相对完整的功能开发中。
当时的需求包括：
- 多个文件之间的逻辑配合
- 状态流转
- 一些边界条件的处理
我尝试把同样的需求分别交给 GPT 和 Claude。
体验差异很快就体现出来了：
-
GPT：
- 需要我不断拆分问题
- 持续补充上下文
-
Claude：
- 更容易一次理解整体目标
- 生成的代码结构更清晰
- 对边界情况考虑得更自然
那次之后，我开始在更复杂的任务中，优先选择 Claude。
三、开始用 Claude Code，开发方式发生了变化
后来我接触到了 Claude Code / CLI 这种使用方式。
最大的变化是：
我不再只是“问问题”，而是把它当成一个随时在旁边的搭档。
我常用它来：
- 快速理解一个陌生仓库
- 重构已有模块
- 给现有代码补测试
- 帮我分析一段历史代码的设计思路
在这些场景下，Claude 对长上下文和项目结构的理解优势非常明显。
四、随之而来的现实问题：成本和稳定性
随着使用频率越来越高，一些现实问题也开始显现。
1. 成本问题
Claude Code 用起来很“顺”，但也意味着：
- 调用频繁
- Token 消耗快
- 用久了成本压力会比较明显
2. 使用稳定性
在国内使用时：
- 偶尔会遇到不稳定的情况
- CLI 场景下感受更明显
- 对正在进行的开发会有一定干扰
当 Claude Code 已经融入日常开发流程后，这些问题就很难忽略。
五、我后来选择了一种更适合自己的方案
为了解决这些问题，我也尝试过不同的方式：
- 换接入方式
- 对比不同方案的成本
- 观察稳定性表现
后来我选择了一种支持 Claude Code 的中转方案，
并不是因为它“多高级”，而是因为它：
- 在国内使用更稳定
- 成本相对可控
- 不需要改变原本的 Claude Code 使用习惯
用了这一段时间之后，对我来说是一个比较平衡的选择。
六、我的使用习惯，其实已经被改变了
现在回头看，自己的工具分工已经变得很清晰：
- GPT：
更偏向零散问题、通用问答 - Claude / Claude Code：
复杂逻辑、完整功能、项目级开发
Claude 对我来说，已经不只是“偶尔用一下”的工具，
而是写代码时一个默认存在的辅助角色。
七、给同样在用 Claude Code 的人
如果你：
- 已经在用 Claude / Claude Code
- 或正准备尝试
- 或被成本、稳定性问题影响过体验
也可以多看看不同方案，找到更适合自己使用节奏的方式。
我目前在用的这个方案，也放在下面，
主要是作为一个补充选择，供有类似需求的人参考。
最后的一点感受
如果要总结这段变化，我会这样形容：
Claude 并没有替我写代码，而是让我更愿意去写复杂的代码。
如果你也有类似体验，欢迎交流
