六月中旬某个闷热的夜晚，在初浅尝试使用 API Key 帮我迅速完成了一个任务后，我毫不犹豫地点下了 Claude Max 的订阅按钮。作为一个“买断制”时代的遗老，每月一两百美金的订阅对当时的我来说还是太超前了。但是在一个半月之后回头望去，看着那些按照 API 计价的被我烧掉的价值 3000 多美金的 token，我似乎捡到了一个超大便宜？不过最近 Anthropic 宣布了新的 weekly 限制，想来大概针对的就是我这种“重度”用户吧。所以近几天来我也在研究有没有其他替代方案，可以让我从这种限制中解脱出来。不过尝试了一圈下来（包括 CC 接其他 API，也包括像 Codex/Gemimi/Qwen/Crush/Amp/AugmentCode 等等），似乎一时半会儿在这个领域 Claude Code (后文用 CC 指代) 还是没有竞争对手。既然还得续费，那不如阶段性地做一个总结，来记录下这一个半月使用 CC 的一些感受吧。
Vibe Coding 的迭代速度
说到 vibe coding，最让我震撼的其实不是模型有多智能或者是能完成什么尖端任务，而是由它带来的产品迭代速度的提升。有个有意思的现象：Claude Code 本身就是 Anthropic 内部 dogfooding 的产物：从六月中旬我开始使用到现在，短短一个半月时间里，我们见证了很多崭新的功能：自定义命令让我们避免重复输入一样的 prompt，Hooks 功能可以在各种事件触发时自动执行命令，Subagent 则解决了上下文窗口的限制问题。这种更新频率，放在传统软件开发时代简直是天方夜谭。
不光是 CC，整个 AI 辅助开发领域都在以令人眩晕的速度前进。几天甚至几小时完成一个产品，不再是不可能的任务。
不过，这种加速带来了一个有趣的悖论：AI 确实解放了开发者的双手，让我们不用再纠结于那些繁琐的样板代码。但另一方面，当所有人都开上了“法拉利”，赛道上的竞争反而变得更加激烈了。以前你可以精心打磨一个功能，现在？竞争对手可能已经用 AI 快速迭代了三四个版本了。手工匠人式的打磨方式，无疑将被卷死在沙滩上。
说实话，有时候我会怀念那个慢工出细活的年代。但现实就是这样，技术的车轮滚滚向前，你要么跟上，要么被碾过。去适应和利用它，而不是被裹挟前进，可能才是新时代的立命之本。如果这篇文章你只能记住一句话，那我希望是这句：在 vibe coding 时代，千万别让工具把自己逼死。效率是提高了，但人还是人，我们需要的不仅仅是更快的开发速度，还有思考的时间和生活的空间。
从传统 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 或者说 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 官方博文中介绍了几种常见的 workflow，比如：
- 探索，计划，编码，提交
- 编写测试，提交，编码，迭代，提交
- 编写代码，截图，迭代
相比于直接用 prompt 命令 CC 开始干活，先指导它对代码库的现状进行理解，往往会得到更好的结果。参考这些常见 workflow 并逐渐发展出自己的使用 AI 的 style，也是一种成长。
小步迭代还是放飞自我
在手工编程时代，一天能写几百行代码就算是高产了。但 vibe coding 彻底改变了游戏规则：现在，你可以在十几分钟内生成上千行代码，甚至一口气完成整个项目。这种“生产力爆炸”带来了一个新问题：我们应该如何使用这种能力？
我见过的使用方式大致分两派。一派是“小步快跑”：每次只让 AI 完成一个小功能，验证没问题后再进行下一步。另一派是“一步到位”：直接把整个需求扔给 AI，让它一次性生成所有代码。更极端的，还有人会开启 --dangerously-skip-permissions 模式（也就是所谓的 yolo 模式），让 AI 可以不经确认就执行任何操作。
两种方式我都深度尝试过，结论是：如果能选，小步迭代往往总是更好的选择。
举个例子，有次我想重构一个模块，大概涉及七八个文件的修改。我当时想，既然 AI 这么厉害，那让它一次性搞定吧！于是我详细描述了需求，然后就看着 CC 开始疯狂输出代码。几分钟后，上千行代码的修改完毕，编译也通过了。我心想：这也太爽了吧！
然而，实际开始尝试时，噩梦开始了。首先是一个小 bug，因为上千行的修改肯定是懒得看的，所以只能描述情况，让 AI 去修复；修复过程中又引入了新问题；再修复，又有新问题…几轮下来，代码库已经面目全非。由于一次性改动太多，开发者失去了掌控，对于修改不理解，也就无法辨别哪些修改是必要的，哪些又是 AI 为了修复新 bug 临时加上的。最后的结果，往往只能是 git reset 整个修改，重新开始。
这类经历让我明白了一个道理：AI 生成代码的能力很强，但它对整体架构的把握和长期维护的考虑还是有限的。一次性生成太多代码，就像是在黑暗中狂奔——你可能跑得很快，但也可能一头撞上墙。而且，当出现问题时，调试的复杂度会呈指数级增长。
相比之下，小步迭代的好处显而易见：
- 可控性高：每次只改动一小部分，出问题了也容易定位和回滚。
- 能够理解：你能跟上 AI 的思路，理解每一步在做什么。
- 质量保证：可以在每一步后进行测试，确保代码质量。
- 学习机会：通过观察 AI 的实现方式，你也能学到新东西。
当然，我不是说“放飞自我”就完全不可取：在进行新功能实现时，如果已经进行了充分讨论和规划，那么确实不太需要人类的监督，CC 就可以完成大部分工作。如果你真的想尝试“放飞自我”的开发方式，我有几个建议：
- 必须有完善的测试：采用 TDD 的方式，先写测试（当然这也是 AI 来写），再让 AI 实现功能。这样至少能保证基本的正确性。
- 做好版本控制：在开始之前创建新分支，随时准备回滚。
- 分模块进行：即使要一次性完成很多功能，也尽量按模块来组织，不要把所有东西混在一起。
- 交叉评审：AI 生成的代码看起来能跑，但可能隐藏着各种问题，对于生成的代码，不要照单全收。最简单的方式，就是找到另一个 AI，将变更喂进去，看看有什么需要改进的地方，这种迭代往往能收获不错的结果。
任务规模和上下文制约
人类和 AI 在某个方面惊人地相似：处理小任务时游刃有余，面对大项目就容易手忙脚乱。对 CC 来说，这个问题更加明显，因为它还要面对一个硬性限制——200k 的上下文窗口。在当前动辄模型给 1M 窗口的年代，这个限制又是确实相当痛苦。
体感上来说，普通使用个十几二十分钟，你就会看到上下文使用量飙到 90% 以上。这时候 CC 就像一个塞满东西的行李箱，再想往里装点什么都困难。更糟糕的是，如果在执行任务的过程中触发了自动压缩，整个 agent 可能会陷入混乱，忘记自己在做什么，或者陷入死循环重复做一件事。
所以，如何在有限的上下文窗口内完成复杂任务，就成了使用 CC 的一门必修课。
任务拆解是关键
与其给 AI 一个笼统的“帮我完成 XXX 系统”的需求，不如先把大任务拆解成具体的小任务。这一步最好在 Plan Mode 中进行，让 AI 帮你一起梳理。比如：
1
2
3
4
5
6
7
8
我：我想实现一个用户认证系统，帮我拆解需求
AI：好的，让我们拆解一下需要完成的任务：
1. 设计数据库表结构（用户表、会话表等）
2. 实现注册功能（验证、加密、存储）
3. 实现登录功能（验证、生成 token）
4. 实现中间件（验证 token、刷新机制）
5. 添加测试用例
...
对于一个 session 难以完成的任务，可以让 AI 把讨论内容进行文档化，保存到项目里（比如 dev-note/auth-implementation-plan.md）。这样，即使换了新的 session，你也可以让 AI 读取这个文档，快速恢复上下文。
使用 Subagent
CC 最近推出的 Subagent 功能在一定程度上缓解了这个问题。在以前，当 CC 使用 Task 工具进行任务时，实际上是在一个全新的上下文中进行工作。这相当于扩展了主 Session 的上下文窗口。
以前我们只能通过 prompt 技巧来“诱导”CC 使用 Task 工具，效果时好时坏。现在有了专门的 subagent 配置，稳定性大大提升。你可以为不同类型的任务创建专门的 agent：
- 代码分析 agent：专门负责理解现有代码结构
- 代码审查 agent：检查代码质量和潜在问题
- 测试 agent：编写和运行测试用例
- Git agent：处理代码提交和 PR
通过合理链式调用这些 agent，即使是大型任务也有机会能在同一个 Session 里有条不紊地完成。每个 agent 都在独立的上下文中工作，不会相互干扰，也不会耗尽主 session 的上下文。
在合适的时机手动 compact
虽然 CC 会自动进行上下文压缩，但我的经验是：主动出击会更好。当你看到上下文使用量接近用满时，不妨手动执行 /compact 命令。这可以让压缩发生在一个更自然的断点进行。比如刚完成一个功能模块，或者刚跑完一轮测试。这时候压缩，AI 不太会丢失重要信息。而如果等到自动压缩，可能正好在你改代码改到一半的时候触发，那就很容易出问题。
另一个技巧是：对于相对独立的任务，干脆新开一个 session。反正你已经把任务计划文档化了，新 session 读取文档就能快速上手。这比在一个快要爆炸的 session 里硬撑要明智得多。
当前在 AI 辅助编程中，上下文窗口依然是稀缺资源，要像管理内存一样管理它。合理规划、及时清理、必要时“换个房间”，才能让 vibe coding 的体验保持流畅。
善用命令和周边工具
Command 和 Hooks
我有个暴论：凡是重复了两次以上的类似 prompt 都应该用命令来表述！
每次都输入类似的 prompt 真的非常无趣：“运行测试并修复失败的用例”、“提交代码时请使用规范的 commit message”…如果你发现自己在重复类似的请求，立刻停下来，花一分钟配置一个 command。
Command 相比 subagent 有个巨大的优势：它拥有完整的当前会话上下文。如果你的任务和当前正在进行的工作高度相关，那么 command 的效率会更高。比如我常用的几个：
/test-and-fix：运行测试，如果有失败自动尝试修复/review：对当前修改进行代码审查，给出改进建议/commit-smart：分析改动，生成合适的 commit message 并提交
至于 Hooks，说实话我用得不多。理论上它能在特定事件触发时自动执行命令，比如每次提交前自动运行测试。但实际使用中，我更喜欢保持一定的控制权，不太喜欢太多自动化的东西在背后悄悄运行。不过这纯属个人偏好，如果你的工作流比较固定，Hooks 确实能省不少事。
MCP
通过 MCP 补充模型不知道的知识。我最常用的几个场景：
1. 最新的 Apple 文档
Apple 的文档页面大量使用 JavaScript 渲染，因此 CC 的 WebFetch 抓不到内容。但通过 apple-docs-mcp，我可以获取最新最准确的 API 文档。这对 iOS 开发来说简直是救命稻草。
2. 项目管理集成
通过 mcp-atlassian 连接 JIRA，可以让 CC 直接读取和更新任务状态，或者自动将分析的情况和实现进行回复，保持沟通畅通。
3. LSP 支持
CC 暂时还原生支持 LSP，但通过 mcp-language-server，可以获得准确的代码补全和类型信息。特别是对于那些 CC 不太熟悉的语言，这个功能价值巨大。
配置 MCP 可能需要一点时间，但绝对物有所值。它让 CC 从一个通用的工具变成了为你量身定制的助手。
编译、分析和测试
永远记住：AI 生成的代码，未经测试都是废品。
我的工作流程通常是这样的：
- 在 CLAUDE.md 中详细列出项目的编译命令、测试命令、linter 配置
- 每完成一个小功能，立即编译
- 编译通过后，运行相关测试
- 测试通过后，运行 linter 和 formatter
听起来很繁琐？其实配置好之后，这些都可以通过简单的命令完成和 subagent。关键是要让这些步骤成为习惯，而不是等全部写完再说。
如果你的项目支持 TDD，那就更好了。先让 AI 根据需求写测试，然后再实现功能。这样生成的代码质量通常会高很多，因为 AI 有了明确的目标。
当然，根据编译器的废柴程度（你们大概应该知道我在说谁..）和项目的规模，编译一次的时间代价可能会很大。这种情况下，我会拆分模块，尽量只去编译改过的模块。如果这比较困难，那么也可以使用 git worktree 来创建多个工作目录：这样你可以让多个任务并行进行，互不干扰，也算是弥补等待编译所带来的时间损失。
Code 之外，大有可为
别把 CC 只当成写代码的工具，它的能力远不止于此。
我现在的日常使用场景：
- 代码提交和 PR：写完代码后，直接让 CC 分析改动、生成 commit message、推送代码、创建 PR。它生成的 PR 描述往往比我自己写的还要清晰。
- 撰写技术文档和 wiki: 让 CC 分析代码生成 API 文档、更新 README、编写使用示例。它的文档往往更加规范和完整，甚至不会出现语法错误。
- JIRA 更新：完成任务后，让 CC 更新 ticket 状态、添加评论回复用户、甚至创建新的子任务。再也不用在网页上点来点去了。
- 数据处理：需要批量处理文件、转换格式、清洗数据？以前我会写脚本，现在直接描述需求让 CC 来做。而且每次需求不同时，不用维护一堆一次性脚本了。
更有意思的是 CC 解锁了随时随地工作的可能性。通过像是 VibeTunnel 或者任意手机 SSH 客户端，配合 Tailscale，我可以在任何地方连接到家里的工作机器，用手机指挥 CC 干活。虽然不适合与 CC 进行复杂的计划和交互，但处理一些简单的需求，比如跑个脚本、修个小 bug，更新下文档什么的，是完全没问题的。出门在外突然想到什么，立刻就能实现，这种感觉很奇妙。
最后，个人强烈推荐配一个好的麦克风。在 vibe coding 时代，用语音输入描述需求，比打字更加自然流畅。现在的语音识别已经很准确了，而中英文混杂也能处理得很好。想不到当年为了当游戏主播买的麦克风，吃灰这么多年后，终于在今天找到了真正的用武之地。
当然，Mac 系统自带的语音输入是幼儿园级别，从准确性和易用性上都不值一提。你肯定需要一款 AI 转译的 app，我也试用过一些，总结几个当前市面上的优秀选择：
- MacWhisper：以前买的，现在在用，原生 macOS app，作者支持速度很快。
- VoiceInk：提供开源以供确认，隐私安全，付费省心。
- Wispr Flow：订阅制，小贵，但胜在 UI 漂亮，UX 流畅。
它们都是很不错的选择，功能也都类似。除了基础的语音识别和输入外，再配合转译后接入 LLM 进行文本润色/修改的能力，根据不同场景将我的语言自动转为合适的文字和格式。这些 app 把人机交互提升了一个档次，语音输入的内容往往比我自己劳心劳力组织的文字还要清晰精确。现在，绝大多数情况下，我和同事用不同语言交流时，以及自己在书写 PR 和各种文档时，我几乎也都是说中文，然后让 AI 当我的“同传”转换为合适的目标语言，以此确保准确和及时。
体感降智和更多限制
接下来要说的内容，有些是我自己的感受，有些是社区里朋友们的吐槽。很多东西无法证实或证伪，大家权且一听。
Opus 远强于 Sonnet
这几乎是板上钉钉的事实：Opus 的效果比 Sonnet 好很多。毕竟价格摆在那里，Opus 是 Sonnet 的 5 倍。100 美金的 max 订阅，5 小时时间窗口的 Opus 只能跑几个小任务额度就用光了。200 美金的订阅也只是勉强够用。
如果你是 100 美金档的用户，建议养成手动切换模型的习惯。日常用 Sonnet 处理简单任务，遇到复杂的架构设计或者棘手的 bug，再切到 Opus。
时间玄学
这个听起来很离谱，但确实有体感：美国半夜（也就是北京时间的白天）的效果比美国白天要好。实际上软件开发最活跃的还是中美两国，而 Anthropic 在中国其实是没有正规渠道能用的。所以可能是因为美国夜里使用的人少，服务器压力小，从而模型性能不会退化？总之，如果北京时间大清早遇到无法解决的问题，留到下午时段处理，可能会有惊喜。
降智疑云
最让人担心的是这个：个人体感，前一个月的使用体验明显比最近两周要好。开始我以为是自己的错觉，但社区里抱怨的声音也越来越多。合理的猜测是大量开发者涌入导致的资源紧张。就像一个原本只供应 100 人的自助餐厅，突然来了 1000 人，菜品质量下降几乎是必然的。结合最近 Anthropic 寻求新的融资的新闻和推出 weekly 限制的政策，想要在这个定价和使用策略下盈利，似乎是不太可能的。
限制的阴霾
从 8 月底开始，weekly 限制正式实施。虽然官方说是为了公平使用，但谁都知道这背后是算力不足的无奈。而且不排除未来会有更严格的限制。
这让我想起一个老段子：中国先解决显卡问题，还是美国先解决电力问题？在这两个问题解决之前，AI 发展的瓶颈可能不是算法，而是最基础的硬件资源。
一些应对策略
面对这些限制，可能我们不得不采取一些“省着用”的技巧：
- 分级使用：简单任务用 Sonnet，复杂任务才上 Opus
- 错峰使用：避开美国工作时间，选择服务器负载低的时段
- 提高 prompt 质量：一次说清楚，减少来回对话消耗的 token
- 合理使用 subagent：把消耗大的任务分配给 subagent
- 保持多个选择：虽然 CC 目前最强，但保持对其他工具的关注
总结和未来展望
一个半月的 CC 使用经历，有惊喜，有担忧，有对未来的憧憬，也有对现实的无奈。但总的来说，我感受到的是自己切实地站在在历史的进程之中。Vibe coding 不仅仅是一种新的编程方式，更是一种全新的思维模式。它要求我们重新思考什么是编程、什么是创造、什么是价值。在这个 AI 与人类共舞的时代，愿我们都能找到属于自己的节奏。
最后，回到文章开头的那句话：在 vibe coding 时代，千万别让工具把自己逼死。技术是为人服务的，不是相反；工作是让人有机会追寻和思考自我的，而不是让自己迷失。保持这份清醒，可能比掌握任何具体的技巧都更重要。