> ## Documentation Index
> Fetch the complete documentation index at: https://cc.cyber101.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# 一个半月高强度 Claude Code 使用后感受 

> 一个半月高强度使用 Claude Code 的个人体验和见解

## [Vibe Coding 的迭代速度](#vibe-coding-的迭代速度)

说到 vibe coding，最让我震撼的其实不是模型有多智能或者是能完成什么尖端任务，而是由它带来的产品迭代速度的提升。有个有意思的现象：Claude Code 本身就是 Anthropic 内部 dogfooding 的产物：从六月中旬我开始使用到现在，短短一个半月时间里，我们见证了很多崭新的功能：自定义命令让我们避免重复输入一样的 prompt，Hooks 功能可以在各种事件触发时自动执行命令，Subagent 则解决了上下文窗口的限制问题。这种更新频率，放在传统软件开发时代简直是天方夜谭。
不光是 CC，整个 AI 辅助开发领域都在以令人眩晕的速度前进。几天甚至几小时完成一个产品，不再是不可能的任务。
不过，这种加速带来了一个有趣的悖论：AI 确实解放了开发者的双手，让我们不用再纠结于那些繁琐的样板代码。但另一方面，当所有人都开上了"法拉利"，赛道上的竞争反而变得更加激烈了。以前你可以精心打磨一个功能，现在？竞争对手可能已经用 AI 快速迭代了三四个版本了。手工匠人式的打磨方式，无疑将被卷死在沙滩上。
说实话，有时候我会怀念那个慢工出细活的年代。但现实就是这样，技术的车轮滚滚向前，你要么跟上，要么被碾过。去适应和利用它，而不是被裹挟前进，可能才是新时代的立命之本。如果这篇文章你只能记住一句话，那我希望是这句：\*\*在 vibe coding 时代，千万别让工具把自己逼死。\*\*效率是提高了，但人还是人，我们需要的不仅仅是更快的开发速度，还有思考的时间和生活的空间。

## [从传统 Editor AI 的转换](#从传统-editor-ai-的转换)

在投身 CC 之前，我也算是各种 AI 编辑器的老用户了。从最早期的 Cursor，到后来的 Windsurf，再到 GitHub Copilot 和各种 VS Code 插件如 Cline，基本上市面上叫得出名字的我都试过。但说实话，这些 Editor AI 工具并没有像 CC 这样给我带来那么大的冲击和震撼。
我想，这类编辑器工具最大的问题是可能是**缺少全局感**。想象一下你使用这些编辑器 AI 时的经典场景：打开一个文件，选中几行代码，然后让 AI 帮你改改。这种交互模式天然就把开发者的思维框在了**当前文件**甚至**当前这几行**的范围内。这种模式对于刚从传统编程过渡到 AI 辅助编程的开发者来说，确实是个不错的起点。毕竟，你还保留着对代码的掌控感：AI 写得不好？没关系，我随时准备自己上。但问题是，如果你真的想进入深度的 vibe coding 状态，让 AI 发挥最大潜力，这种随时准备接管的心态反而会成为阻碍。人类开发者的干预时机和直接下场写代码的时候越少，最终呈现出的效率和效果反而越好。
另外更致命的是同步问题：AI 在上下文中认为文件是 A 状态，实际文件已经被开发者插手改成 B 状态了，然后你让 AI 基于它的认知继续修改，结果可想而知：要么产生混乱，要么 AI 需要再读一遍所有内容。有时候光是解决这种不同步带来的问题，花的时间就比写代码还多。
而命令行工具从理念上就不同：没有华丽的界面，没有实时的代码提示，开发者在过程中难以直接插手"微调"。但恰恰是这种简陋，反而让它能够更深入地理解和操作整个项目。它不会被某个文件或某几行代码限制视野，而是从项目的根目录开始，建立起对整个代码库的认知。没有了编辑器这个中间层，开发者想直接修改代码变难了，这在某种程度上"强迫"你更多地依赖和使用 AI，给它更多信息和反馈，这反而能发挥出更大的效能。
当然，我不是说编辑器 AI 就一无是处。本质上，当前两者的差异更多来自于使用方式和模型质量，而非架构设计。CC 背靠 Anthropic 这棵大树，模型质量自然没得说。更关键的是，它可以肆无忌惮地使用 token（虽然最近加了 weekly 限制），这种量大管饱的豪横，确实在末端引起了质变，让最终效果好了不止一个档次。如果让编辑器 AI 也能随便烧 token，可能效果未必会差到哪里去。
但现实就是现实，至少在当下，如果你想体验真正的 vibe coding，CC 可能是唯一选择。

## [认识 CC 的边界和长处](#认识-cc-的边界和长处)

就像所有工具一样，CC 或者说 AI 辅助编程，也有自己擅长和不擅长的领域。认清这些边界，才能让你的 vibe coding 之旅更加顺畅。
如果你让 CC 分析一段复杂的代码逻辑，理解各个模块之间的调用关系，然后画一张时序图或者架构图，它会完成得相当出色。这种需要理解和总结的任务，正是 LLM 的看家本领。又或者，你想快速实现一个算法、搭建一个项目框架、编写测试用例，CC 都能给你满意的答案。
但是，千万别指望它在所有场景下都能大杀四方。比如说，你想在整个代码库里做一次全局的变量重命名，或者进行某些需要精确匹配的复杂重构，那老老实实用 IDE 的重构功能会靠谱得多。LLM 毕竟说到底也只是一个概率生成器，这类需要 100% 准确性的任务，从起源上就不是 LLM 的强项。如果你真的需要使用 AI 帮助完成这类任务，那么请它写一段脚本去执行并修改代码，往往会比直接指挥它去修改文件，要来的靠谱。
还有个更现实的问题：训练数据的偏差。CC 在处理前端代码或者 TypeScript 时简直如鱼得水，各种框架信手拈来，CSS 炫技让人眼花缭乱，最新的 API 也了如指掌。但换成 iOS/Swift 开发？那可就是另一番景象了。各种过时的 API 用法是家常便饭，有时干脆臆造一些不存在的方法，幻觉严重，而更冷门的语言和框架情况则更加糟糕。训练集丰富程度的差异直接决定了模型在不同领域的表现。
市面上也存在着其他不少基于命令行的 code agent，像是 Crush，Gemini CLI 等等。但实测下来，它们现在和 CC 还存在很大差距。CC 作为"软硬件一体"解决方案带来了巨大的优化空间：Anthropic 既是模型提供方，又是工具开发方，这种垂直整合让他们可以针对具体使用场景进行深度优化。这就像苹果的生态系统——当你同时控制硬件和软件时，能做到的事情远超各自为战的组合。其他竞品要么受限于模型能力，要么受限于工具设计，很难达到 CC 这种浑然一体的使用体验。

## [思考先行还是实践先行](#思考先行还是实践先行)

CC 提供了一个很有意思的功能：Plan Mode。在这个模式下，你可以先和 AI 进行充分的讨论，制定详细的实施计划，然后再开始实际的编码工作。这就引出了一个有趣的话题：我们是应该追求先想清楚再动手，还是先动手搞出东西来之后再慢慢改？
在传统软件开发领域，这个争论也由来已久。瀑布派说要先设计后实现，敏捷派说要快速迭代。到了 AI 时代，这个问题又有了新的含义。
我见过两种极端的使用方式。第一种是"规划魔"：进入 Plan Mode 后，和 AI 讨论个把小时，上下文用光两三次，从架构设计到具体实现，从错误处理到性能优化，事无巨细地规划每一个细节。等到真正开始写代码时，基本上 AI 就是照着计划一步步执行。另一种则是"莽夫流"：上来就是一句"给我实现一个 XXX 功能"，然后就看着 AI 噼里啪啦地写代码，写完了发现不对再改，改完了又发现新问题，如此循环往复。
哪种方式更好？也许乍看下来先规划再执行更好？但我的答案可能会让你失望：要看情况。
如果你是个经验丰富的开发者，对项目架构已经有了清晰的认识，那么先进行充分的规划确实能让后续的实现更加顺畅。特别是对于那些需要遵循特定架构模式的既有项目，Plan Mode 能帮你确保 AI 生成的代码符合项目规范。我自己就经常在 Plan Mode 里和 AI 讨论："我们的项目使用了 MVVM 架构，新功能应该怎么拆分到各个层？" "这部分内容已经有类似实现了，你需要参考现有实现和模式"， 这种讨论能让 AI 更好地理解项目的整体结构，生成的代码质量更高，开发者对具体代码的掌控也更好。
但如果你对某个技术栈完全不熟悉，或者正在做一个全新的探索性项目，那么"先干起来"可能反而是更好的选择。这种情况下，很多时候你根本不知道自己不知道什么。所以与其空想，不如让 AI 先写个原型出来，跑起来看看效果，发现问题再迭代。这种方式特别适合那些"短平快"的项目，或者你只是想快速验证一个想法。
我个人的偏好？我更喜欢先进入 Plan Mode，和 AI 讨论后再开始实施。对我来说，日常维护已有代码库的工作是占大头的，我需要更稳定和可靠的迭代，先 plan 有利于我掌控全局。但在接触新技术栈时，我也不太愿意直接莽起来。不同技术栈下，很多开发的理念是共通的：如何组织可维护的架构（不仅为了人类，也为了 AI 今后进行维护，合理的组织结构还是必要的），如果调度和安排代码以保证高效，各个模块的连接方式等。就算是新技术栈，适当的讨论相比无脑梭哈，也提供了一种更有效的学习方式。但是这样做的代价是慢，如果着急上线功能，或者写的是可以无视代码质量的"快消品"，那么事无巨细的 plan 可能就不太适用了。
最后想说的是，Plan Mode 还有个隐藏的好处：它能帮你整理思路。有时候你觉得自己想清楚了，但真要说出来或者写下来，才发现还有很多细节没考虑到。和 AI 的对话过程，其实也是一个自我梳理的过程。这算是"橡皮鸭调试法"的变种，在 vibe coding 时代依然很有价值。
Claude Code 的 [Best practices 官方博文](https://www.anthropic.com/engineering/claude-code-best-practices)中介绍了几种常见的 workflow，比如：

* 探索，计划，编码，提交
* 编写测试，提交，编码，迭代，提交
* 编写代码，截图，迭代
  相比于直接用 prompt 命令 CC 开始干活，先指导它对代码库的现状进行理解，往往会得到更好的结果。参考这些常见 workflow 并逐渐发展出自己的使用 AI 的 style，也是一种成长。

## [小步迭代还是放飞自我](#小步迭代还是放飞自我)

在手工编程时代，一天能写几百行代码就算是高产了。但 vibe coding 彻底改变了游戏规则：现在，你可以在十几分钟内生成上千行代码，甚至一口气完成整个项目。这种"生产力爆炸"带来了一个新问题：我们应该如何使用这种能力？
我见过的使用方式大致分两派。一派是"小步快跑"：每次只让 AI 完成一个小功能，验证没问题后再进行下一步。另一派是"一步到位"：直接把整个需求扔给 AI，让它一次性生成所有代码。更极端的，还有人会开启 `--dangerously-skip-permissions` 模式（也就是所谓的 yolo 模式），让 AI 可以不经确认就执行任何操作。
两种方式我都深度尝试过，结论是：**如果能选，小步迭代往往总是更好的选择**。
举个例子，有次我想重构一个模块，大概涉及七八个文件的修改。我当时想，既然 AI 这么厉害，那让它一次性搞定吧！于是我详细描述了需求，然后就看着 CC 开始疯狂输出代码。几分钟后，上千行代码的修改完毕，编译也通过了。我心想：这也太爽了吧！
然而，实际开始尝试时，噩梦开始了。首先是一个小 bug，因为上千行的修改肯定是懒得看的，所以只能描述情况，让 AI 去修复；修复过程中又引入了新问题；再修复，又有新问题…几轮下来，代码库已经面目全非。由于一次性改动太多，开发者失去了掌控，对于修改不理解，也就无法辨别哪些修改是必要的，哪些又是 AI 为了修复新 bug 临时加上的。最后的结果，往往只能是 git reset 整个修改，重新开始。
这类经历让我明白了一个道理：AI 生成代码的能力很强，但它对整体架构的把握和长期维护的考虑还是有限的。一次性生成太多代码，就像是在黑暗中狂奔——你可能跑得很快，但也可能一头撞上墙。而且，当出现问题时，调试的复杂度会呈指数级增长。
相比之下，小步迭代的好处显而易见：

1. **可控性高**：每次只改动一小部分，出问题了也容易定位和回滚。
2. **能够理解**：你能跟上 AI 的思路，理解每一步在做什么。
3. **质量保证**：可以在每一步后进行测试，确保代码质量。
4. **学习机会**：通过观察 AI 的实现方式，你也能学到新东西。
   当然，我不是说"放飞自我"就完全不可取：在进行新功能实现时，如果已经进行了充分讨论和规划，那么确实不太需要人类的监督，CC 就可以完成大部分工作。如果你真的想尝试"放飞自我"的开发方式，我有几个建议：
5. **必须有完善的测试**：采用 TDD 的方式，先写测试（当然这也是 AI 来写），再让 AI 实现功能。这样至少能保证基本的正确性。
6. **做好版本控制**：在开始之前创建新分支，随时准备回滚。
7. **分模块进行**：即使要一次性完成很多功能，也尽量按模块来组织，不要把所有东西混在一起。
8. **交叉评审**：AI 生成的代码看起来能跑，但可能隐藏着各种问题，对于生成的代码，不要照单全收。最简单的方式，就是找到另一个 AI，将变更喂进去，看看有什么需要改进的地方，这种迭代往往能收获不错的结果。

## [任务规模和上下文制约](#任务规模和上下文制约)

人类和 AI 在某个方面惊人地相似：处理小任务时游刃有余，面对大项目就容易手忙脚乱。对 CC 来说，这个问题更加明显，因为它还要面对一个硬性限制——200k 的上下文窗口。在当前动辄模型给 1M 窗口的年代，这个限制又是确实相当痛苦。
体感上来说，普通使用个十几二十分钟，你就会看到上下文使用量飙到 90% 以上。这时候 CC 就像一个塞满东西的行李箱，再想往里装点什么都困难。更糟糕的是，如果在执行任务的过程中触发了自动压缩，整个 agent 可能会陷入混乱，忘记自己在做什么，或者陷入死循环重复做一件事。
所以，如何在有限的上下文窗口内完成复杂任务，就成了使用 CC 的一门必修课。

### [任务拆解是关键](#任务拆解是关键)

与其给 AI 一个笼统的"帮我完成 XXX 系统"的需求，不如先把大任务拆解成具体的小任务。这一步最好在 Plan Mode 中进行，让 AI 帮你一起梳理。比如：

```
我：我想实现一个用户认证系统，帮我拆解需求
AI：好的，让我们拆解一下需要完成的任务：
1. 设计数据库表结构（用户表、会话表等）
2. 实现注册功能（验证、加密、存储）
3. 实现登录功能（验证、生成 token）
4. 实现中间件（验证 token、刷新机制）
5. 添加测试用例
...
```

对于一个 session 难以完成的任务，可以让 AI 把讨论内容进行文档化，保存到项目里（比如 `dev-note/auth-implementation-plan.md`）。这样，即使换了新的 session，你也可以让 AI 读取这个文档，快速恢复上下文。

### [使用 Subagent](#使用-subagent)

CC 最近推出的 Subagent 功能在一定程度上缓解了这个问题。在以前，当 CC 使用 Task 工具进行任务时，实际上是在一个全新的上下文中进行工作。这相当于扩展了主 Session 的上下文窗口。
以前我们只能通过 prompt 技巧来"诱导"CC 使用 Task 工具，效果时好时坏。现在有了专门的 subagent 配置，稳定性大大提升。你可以为不同类型的任务创建专门的 agent：

* 代码分析 agent：专门负责理解现有代码结构
* 代码审查 agent：检查代码质量和潜在问题
* 测试 agent：编写和运行测试用例
* Git agent：处理代码提交和 PR
  通过合理链式调用这些 agent，即使是大型任务也有机会能在同一个 Session 里有条不紊地完成。每个 agent 都在独立的上下文中工作，不会相互干扰，也不会耗尽主 session 的上下文。

### [在合适的时机手动 compact](#在合适的时机手动-compact)

虽然 CC 会自动进行上下文压缩，但我的经验是：主动出击会更好。当你看到上下文使用量接近用满时，不妨手动执行 `/compact` 命令。这可以让压缩发生在一个更自然的断点进行。比如刚完成一个功能模块，或者刚跑完一轮测试。这时候压缩，AI 不太会丢失重要信息。而如果等到自动压缩，可能正好在你改代码改到一半的时候触发，那就很容易出问题。
另一个技巧是：对于相对独立的任务，干脆新开一个 session。反正你已经把任务计划文档化了，新 session 读取文档就能快速上手。这比在一个快要爆炸的 session 里硬撑要明智得多。
当前在 AI 辅助编程中，上下文窗口依然是稀缺资源，要像管理内存一样管理它。合理规划、及时清理、必要时"换个房间"，才能让 vibe coding 的体验保持流畅。

## [善用命令和周边工具](#善用命令和周边工具)

### [Command 和 Hooks](#command-和-hooks)

我有个暴论：**凡是重复了两次以上的类似 prompt 都应该用命令来表述！**
每次都输入类似的 prompt 真的非常无趣："运行测试并修复失败的用例"、"提交代码时请使用规范的 commit message"…如果你发现自己在重复类似的请求，立刻停下来，花一分钟配置一个 command。
Command 相比 subagent 有个巨大的优势：它拥有完整的当前会话上下文。如果你的任务和当前正在进行的工作高度相关，那么 command 的效率会更高。比如我常用的几个：

* `/test-and-fix`：运行测试，如果有失败自动尝试修复
* `/review`：对当前修改进行代码审查，给出改进建议
* `/commit-smart`：分析改动，生成合适的 commit message 并提交
  至于 Hooks，说实话我用得不多。理论上它能在特定事件触发时自动执行命令，比如每次提交前自动运行测试。但实际使用中，我更喜欢保持一定的控制权，不太喜欢太多自动化的东西在背后悄悄运行。不过这纯属个人偏好，如果你的工作流比较固定，Hooks 确实能省不少事。

### [MCP](#mcp)

通过 [MCP](https://onevcat.com/2025/02/mcp/) 补充模型不知道的知识。我最常用的几个场景：
**1. 最新的 Apple 文档**
Apple 的文档页面大量使用 JavaScript 渲染，因此 CC 的 WebFetch 抓不到内容。但通过 [apple-docs-mcp](https://github.com/kimsungwhee/apple-docs-mcp)，我可以获取最新最准确的 API 文档。这对 iOS 开发来说简直是救命稻草。
**2. 项目管理集成**
通过 [mcp-atlassian](https://github.com/sooperset/mcp-atlassian) 连接 JIRA，可以让 CC 直接读取和更新任务状态，或者自动将分析的情况和实现进行回复，保持沟通畅通。
**3. LSP 支持**
CC 暂时还原生支持 LSP，但通过 [mcp-language-server](https://github.com/isaacphi/mcp-language-server)，可以获得准确的代码补全和类型信息。特别是对于那些 CC 不太熟悉的语言，这个功能价值巨大。
配置 MCP 可能需要一点时间，但绝对物有所值。它让 CC 从一个通用的工具变成了为你量身定制的助手。

### [编译、分析和测试](#编译分析和测试)

永远记住：AI 生成的代码，未经测试都是废品。
我的工作流程通常是这样的：

1. 在 CLAUDE.md 中详细列出项目的编译命令、测试命令、linter 配置
2. 每完成一个小功能，立即编译
3. 编译通过后，运行相关测试
4. 测试通过后，运行 linter 和 formatter
   听起来很繁琐？其实配置好之后，这些都可以通过简单的命令完成和 subagent。关键是要让这些步骤成为习惯，而不是等全部写完再说。
   如果你的项目支持 TDD，那就更好了。先让 AI 根据需求写测试，然后再实现功能。这样生成的代码质量通常会高很多，因为 AI 有了明确的目标。
   当然，根据编译器的废柴程度（你们大概应该知道我在说谁..）和项目的规模，编译一次的时间代价可能会很大。这种情况下，我会拆分模块，尽量只去编译改过的模块。如果这比较困难，那么也可以使用 `git worktree` 来创建多个工作目录：这样你可以让多个任务并行进行，互不干扰，也算是弥补等待编译所带来的时间损失。

### [Code 之外，大有可为](#code-之外大有可为)

别把 CC 只当成写代码的工具，它的能力远不止于此。
我现在的日常使用场景：

* 代码提交和 PR：写完代码后，直接让 CC 分析改动、生成 commit message、推送代码、创建 PR。它生成的 PR 描述往往比我自己写的还要清晰。
* 撰写技术文档和 wiki: 让 CC 分析代码生成 API 文档、更新 README、编写使用示例。它的文档往往更加规范和完整，甚至不会出现语法错误。
* JIRA 更新：完成任务后，让 CC 更新 ticket 状态、添加评论回复用户、甚至创建新的子任务。再也不用在网页上点来点去了。
* 数据处理：需要批量处理文件、转换格式、清洗数据？以前我会写脚本，现在直接描述需求让 CC 来做。而且每次需求不同时，不用维护一堆一次性脚本了。
  更有意思的是 CC 解锁了随时随地工作的可能性。通过像是 [VibeTunnel](https://vibetunnel.sh/) 或者任意手机 SSH 客户端，配合 Tailscale，我可以在任何地方连接到家里的工作机器，用手机指挥 CC 干活。虽然不适合与 CC 进行复杂的计划和交互，但处理一些简单的需求，比如跑个脚本、修个小 bug，更新下文档什么的，是完全没问题的。出门在外突然想到什么，立刻就能实现，这种感觉很奇妙。
  最后，个人强烈推荐配一个好的麦克风。在 vibe coding 时代，用语音输入描述需求，比打字更加自然流畅。现在的语音识别已经很准确了，而中英文混杂也能处理得很好。想不到当年为了当游戏主播买的麦克风，吃灰这么多年后，终于在今天找到了真正的用武之地。
  当然，Mac 系统自带的语音输入是幼儿园级别，从准确性和易用性上都不值一提。你肯定需要一款 AI 转译的 app，我也试用过一些，总结几个当前市面上的优秀选择：
* [MacWhisper](https://goodsnooze.gumroad.com/l/macwhisper?a=864919667)：以前买的，现在在用，原生 macOS app，作者支持速度很快。
* [VoiceInk](https://tryvoiceink.com/?atp=k3GcF3)：提供开源以供确认，隐私安全，付费省心。
* [Wispr Flow](https://ref.wisprflow.ai/wei-wang-onevcat)：订阅制，小贵，但胜在 UI 漂亮，UX 流畅。
  它们都是很不错的选择，功能也都类似。除了基础的语音识别和输入外，再配合转译后接入 LLM 进行文本润色/修改的能力，根据不同场景将我的语言自动转为合适的文字和格式。这些 app 把人机交互提升了一个档次，语音输入的内容往往比我自己劳心劳力组织的文字还要清晰精确。现在，绝大多数情况下，我和同事用不同语言交流时，以及自己在书写 PR 和各种文档时，我几乎也都是说中文，然后让 AI 当我的"同传"转换为合适的目标语言，以此确保准确和及时。

## [体感降智和更多限制](#体感降智和更多限制)

接下来要说的内容，有些是我自己的感受，有些是社区里朋友们的吐槽。很多东西无法证实或证伪，大家权且一听。

### [Opus 远强于 Sonnet](#opus-远强于-sonnet)

这几乎是板上钉钉的事实：Opus 的效果比 Sonnet 好很多。毕竟价格摆在那里，Opus 是 Sonnet 的 5 倍。100 美金的 max 订阅，5 小时时间窗口的 Opus 只能跑几个小任务额度就用光了。200 美金的订阅也只是勉强够用。
如果你是 100 美金档的用户，建议养成手动切换模型的习惯。日常用 Sonnet 处理简单任务，遇到复杂的架构设计或者棘手的 bug，再切到 Opus。

### [时间玄学](#时间玄学)

这个听起来很离谱，但确实有体感：美国半夜（也就是北京时间的白天）的效果比美国白天要好。实际上软件开发最活跃的还是中美两国，而 Anthropic 在中国其实是没有正规渠道能用的。所以可能是因为美国夜里使用的人少，服务器压力小，从而模型性能不会退化？总之，如果北京时间大清早遇到无法解决的问题，留到下午时段处理，可能会有惊喜。

### [降智疑云](#降智疑云)

最让人担心的是这个：个人体感，前一个月的使用体验明显比最近两周要好。开始我以为是自己的错觉，但社区里抱怨的声音也越来越多。合理的猜测是大量开发者涌入导致的资源紧张。就像一个原本只供应 100 人的自助餐厅，突然来了 1000 人，菜品质量下降几乎是必然的。结合最近 Anthropic 寻求新的融资的新闻和推出 weekly 限制的政策，想要在这个定价和使用策略下盈利，似乎是不太可能的。

### [限制的阴霾](#限制的阴霾)

从 8 月底开始，weekly 限制正式实施。虽然官方说是为了公平使用，但谁都知道这背后是算力不足的无奈。而且不排除未来会有更严格的限制。
这让我想起一个老段子：中国先解决显卡问题，还是美国先解决电力问题？在这两个问题解决之前，AI 发展的瓶颈可能不是算法，而是最基础的硬件资源。

### [一些应对策略](#一些应对策略)

面对这些限制，可能我们不得不采取一些"省着用"的技巧：

1. **分级使用**：简单任务用 Sonnet，复杂任务才上 Opus
2. **错峰使用**：避开美国工作时间，选择服务器负载低的时段
3. **提高 prompt 质量**：一次说清楚，减少来回对话消耗的 token
4. **合理使用 subagent**：把消耗大的任务分配给 subagent
5. **保持多个选择**：虽然 CC 目前最强，但保持对其他工具的关注

## [总结和未来展望](#总结和未来展望)

一个半月的 CC 使用经历，有惊喜，有担忧，有对未来的憧憬，也有对现实的无奈。但总的来说，我感受到的是自己切实地站在在历史的进程之中。Vibe coding 不仅仅是一种新的编程方式，更是一种全新的思维模式。它要求我们重新思考什么是编程、什么是创造、什么是价值。在这个 AI 与人类共舞的时代，愿我们都能找到属于自己的节奏。
最后，回到文章开头的那句话：在 vibe coding 时代，千万别让工具把自己逼死。技术是为人服务的，不是相反；工作是让人有机会追寻和思考自我的，而不是让自己迷失。保持这份清醒，可能比掌握任何具体的技巧都更重要。

***

## [来源和致谢](#来源和致谢)

本文基于王巍 (onevcat) 的原创文章 [一个半月高强度 Claude Code 使用后感受](https://onevcat.com/2025/08/claude-code/) 进行扩展和本地化。
**原作者**: 王巍 (onevcat)\
**原始链接**: [https://onevcat.com/2025/08/claude-code/](https://onevcat.com/2025/08/claude-code/)\
**发布日期**: 2025年8月3日
感谢王巍分享这个宝贵的 Claude Code 实战经验，为 AI 辅助开发提供了深刻的洞察和实用的建议。本文保留了所有技术细节、代码示例和最佳实践说明，同时进行了适当的格式优化。

* [Andrej Karpathy 谈 LLM 辅助编程的演进：哲学与实践的融合](/docs/guides/coding-evolution) - AI 传奇人物 Andrej Karpathy 对多层次 LLM 编程工作流的深度洞察，结合实用的 Claude Code 技巧和策略，探索最佳 AI 辅助开发方案。
* [使用 Claude Code 的六周回顾](/docs/guides/six-weeks-experience) - 在生产开发中使用 Claude Code 六周后的回顾与思考