重度使用 Claude Code 又半年：几个命令、一个搭档、两个坑

你好，我是曹犟，欢迎关注我的公众号。

去年 9 月，我写过一篇Claude Code 不止能编程，我用它每周写两万字，分享了当时我使用 Claude Code 来重构写作工作的经验。这大半年过去，我用它做的事情更多了，这个过程中也踩了不少坑，积攒了一些值得分享的细节，这篇文章就把这些集中分享给大家。

一、为什么是 Claude Code

先简单交代一下我的工具选择路径。

我大概是 Cursor 最早的一批用户。在最初的一段时间里，Cursor 的确是我体验最好的 AI 编程工具。但 Claude Code 出来之后，我陆续把工作主力切到了 Claude Code 上：编程、写作、做技术设计、跑 Agent，基本都在它上面完成。Cursor 现在我已经卸载了，Codex 也只在少数场景下会用，例如对抗审查跟 Claude Code 互为参考，后面会展开。

为什么不混用几个工具？因为对于真正的生产力场景，工具值得用最好的。哪怕一个工具只是比另一个工具好 5 分（90 分对 85 分），叠加到几个月、几千个任务上之后，差距也会积累得非常大。同时，生产力工具和差旅类似，也是典型的个人使用、公司买单的场景。既然我们出差的时候会在预算范围内住最好的酒店，那么选择生产力工具的时候我们也会在预算范围内选择最好的工具。这可能也是为什么这类工具的市场份额很容易集中到头部一两个产品上。

正因为如此，我对工具的选择更多是看它在我自己的最难、最复杂的任务上能不能交付，而不仅仅是在简单 demo 上的体验。Claude Code 现在能稳定完成我的绝大部分长程任务，这就是它对我最大的价值。

二、用 Claude Code 做什么

很多人对 Claude Code 的认知还停留在“AI 写代码的命令行工具”，但其实我使用它的场景早就远远超出了 coding 本身。我目前用它做的事大致有三类。

第一类，编程、技术设计和 Skill 开发。 这是它的基本能力。需要补充的是，我现在写代码的过程里，“设计”和“实现”的边界变得越来越模糊。原型阶段我会让 Claude Code 直接把技术方案落到代码里跑一遍，跑通之后再回头补文档；而对核心模块，反而会让它跟我反复讨论方案，文档来回改几轮再动手。它在 Skill 开发方面也很有优势，同时，只要是会重复多次的工作流，我都会让它帮我整理成 Skill，沉淀下来复用。

第二类，文档、PPT 和图文制作。 写作的事情上一篇文章里已经写过。需要补充的一些新的变化是，我现在的 PPT 和图文已经几乎全面转向 HTML 来制作了。Claude Code 写 HTML、CSS 比让它操作 PPT、Word 自如得多，而 HTML 又可以方便地导出图片、PDF，最终交付效果完全够用。今天的 PPT 和图文，其实没必要局限在 PowerPoint 或者图文编辑器里折腾。

顺便推荐一个相关的开源项目：PPT Master。它是一个 Skill，可以把 PDF、DOCX、Markdown 等素材直接生成原生可编辑的 PPTX，真正的 PowerPoint shapes，不是图片，还支持原生动画、模板复用和 TTS 配音。如果你需要可以在 PowerPoint 里继续手动编辑的源文件，它很合适你。

第三类，作为 Agent 运行框架，跑自己开发的 Agent。 这一条对程序员尤其有用。Claude Code 本身已经是一个相当成熟的 Agent 运行环境，自带工具调用、上下文管理、并行子 Agent 等基础能力。我们自己很多内部 Agent，干脆就是写一组 Skill 文件加一组工具，挂在 Claude Code 上跑，不必再从零搭一套 Agent 框架。这也很契合我之前讲过的“文档驱动，AI 放大”的思路。

三、几个容易被忽略的命令

在日常工作中，我陆续发现 Claude Code 有一些命令容易被忽略，但在日常工作流中对效率提升非常明显。

Claude Code 的效率提升，很大一部分就是来自于“管理上下文、并行探索和保留中间的决策过程”。

不打断主线的上下文管理

/btw 适合临时插入一个问题。比如 Claude 正在改一个复杂功能，你突然想问“这个文件为什么这么设计”，直接问很容易把主任务带偏。/btw 的价值是把这个问题放到单独的并行进程里回答，不污染当前主线。

/rewind 则适合试错之后回退。写代码时最怕的是“代码改乱了，聊天记录也乱了”。它可以选择只回退代码、只回退对话，或者两者一起回退。这个能力其实很关键，因为 Agent 工作不是一次性生成，而是不断试探、验证、回退。/branch 或 /fork 则更适合在不破坏当前会话的情况下尝试另一种方案。我的理解是，/rewind 是后悔药，/branch 是平行实验。比如一个重构有 A、B 两种方向，不要在一个会话里来回摇摆，直接分叉出去看哪个方案更好。

让模型更像一个协作团队

/model opusplan 的思路很实用：规划和复杂推理阶段用 Opus，真正执行写代码时切回 Sonnet。这样既能利用 opus 的规划能力，又能控制成本和额度，我们日常的很多任务并不是始终都需要最高档模型。

/simplify 可以理解为一次三合一 code review：并行启动几个 Agent，从代码复用、代码质量、运行效率等不同角度检查。它真正的价值在于把 review 维度拆开了。一个模型在同一次回答里同时扮演架构师、性能专家、代码洁癖工程师，每个角度都会看得不够深。

把 Claude Code 变成长期任务执行器

/loop 适合定时重复执行任务，比如 /loop 5m 检查部署状态。这类命令的本质是 heartbeat：让 Agent 每隔一段时间回来检查一次，而不是你守着屏幕不断追问。部署、监控、长时间跑脚本、等待异步结果时都很有用。

/remote-control 或 /rc 则是手机远程控制。它会生成一个管理 URL，手机打开之后可以同步查看和操作当前 Claude Code 会话。需要注意的是，代码仍然在本地机器运行，手机更像一个遥控器。这个场景适合你离开电脑，但还想看任务有没有跑完，或者临时给下一步指令。当然，通过中转站的用户是无法使用这个功能的。

把过程沉淀下来

/insights 可以生成使用习惯分析报告，看看自己常用哪些命令、习惯怎样、是否有适合自定义的命令。对高频使用 Claude Code 的人来说，优化自己的工作流，本身就是一件很有长期价值的事情。

/export 可以把整段对话导出为 Markdown。这个我觉得很重要，因为很多时候 Claude Code 的价值不只在最后那几行代码，而在中间的架构讨论、取舍判断、重构路径。导出之后可以沉淀到知识库里，也可以交给 Codex 或其他工具继续加工。

需要提醒一下的是，命令本身记不住并不重要，更值得关注的是它们背后的几件事：临时冒出来的问题，分叉出去问就行，没必要把主线带偏；遇到拿不准的方向，与其在一个会话里反复改，不如直接开个新会话同时试两种方案。长任务尽量让 Agent 自己跑、自己汇报，比一直盯着屏幕高效得多。至于中间那些架构讨论和取舍判断，往往比最终代码更值得沉淀，结束之前记得导出来。

四、用 Codex 做对抗审查

最近还有一个很有意思的事情：OpenAI 官方做了一个 Claude Code 插件，可以让 Claude Code 直接调用 Codex。

它的名字叫 Codex plugin for Claude Code，GitHub 地址是 https://github.com/openai/codex-plugin-cc 。安装之后会多出一组 /codex:* 命令，最常用的几个：

• /codex:review：让 Codex 对当前改动做一次普通 code review

• /codex:adversarial-review：让 Codex 做更偏反方视角的挑战式审查

• /codex:rescue：把一个问题委托给 Codex 调查或尝试修复

• /codex:status、/codex:result、/codex:cancel：管理后台运行的 Codex 任务

这个插件的意义远远超出“又多接了一个模型”。它让 Claude Code 和 Codex 共同形成一个带有批判性视角的审核流程。在这个流程中，我还是让 Claude Code 负责推进任务，包括理解需求、改代码、跑测试、整理文档；但在关键节点，我会让 Codex 站到反方视角，专门找问题。

尤其是下面几类任务，最适合加一道 Codex review：

• 改动涉及核心模块、公共组件、基础设施

• 一次重构跨了多个文件，Claude Code 已经连续工作了比较久

• 设计方案看起来“差不多对”，但还没有被另一个模型认真挑战过

• 测试能过，但担心有边界条件、性能问题、安全问题或者长期维护问题

• 需要在合并前做一次类似 senior engineer 的 code review

我一般会给 Codex 一个比较明确的审查提示，比如：

请作为一个严格的代码审查者，审查当前改动。
重点不要总结优点，而是找问题：功能 bug、边界条件、并发/性能风险、测试缺口、设计过度或欠设计、未来维护成本。
请按 P0/P1/P2 标注严重程度。每个问题都要说明依据、影响范围，以及最小修改建议。
如果你认为某个点只是个人偏好，请明确标注为建议，不要伪装成 bug。

这里最关键的是：不要让 Codex 只是“再夸一遍”或者“复述一遍”。要明确要求它站在反方，优先找缺陷，而且每个结论都要给证据。这样 Claude Code 后续处理反馈时，也不是机械照单全收，而是逐条判断：哪些是真问题，哪些只不过是风格偏好，还有哪些需要进一步补测试验证。

这个流程有点像给两个工程师结对分工：一个负责快速推进，一个负责冷静挑刺。大多数时候，Claude Code 已经能把事情做得很好，但长程 Agent 执行很容易出现一个问题：它会沿着自己前面形成的思路越走越深，不太容易主动推翻自己的假设。而 Codex 则提供了一个新的视角，在实践中往往能发现一些不一样的盲点。

所以对我来说，Codex 是 Claude Code 的一个唱反调的搭档，而不是替代品。在两个工具之间反复比较反复横跳没什么意义。真正有价值的，是让它们各司其职：Claude Code 把活干完，Codex 在关键节点挑毛病，最后由人来判断哪些反馈值得吸收、哪些只是模型口味不必当真。

五、几个零碎的坑

下面这两条不属于工作流层面的总结，更像是这段时间踩过的具体小坑，分享出来供大家参考。

第一，中转链路的 cache 失效问题。 现在很多用户因为价格或者网络原因，会通过 sub2api 这类公共中转服务，或者干脆自己攒一个号池、搭一套中转代理来多人共用。需要提醒的是，不管是公共中转还是自建中转，prompt cache 在这种链路上经常会失效，或者命中率很不稳定。表现就是同一段长 prompt，每次请求都像是冷启动，token 消耗远高于直连。我自己也是在同一个任务上对比直连账号和走自建中转两种情况时，才发现两边的 token 消耗差了一大截，后来排查下来，问题就出在 cache 命中率上。如果你也在走中转，又觉得 token 消耗得莫名其妙地快，可以先从这个角度排查一下。

第二，Opus 4.7 与 4.6 的取舍。 实测下来，Opus 4.7 在长程 Agent 执行、复杂开发等场景下，的确比 4.6 更强，遵循指令的稳定性也更好。但是它输出中文文本的时候，能明显感觉到“翻译腔”过重，经常会发明一些奇葩的词汇，不太像人话。我目前的做法是：在编程、做技术设计、跑 Agent 时默认用 4.7；到写需要给人看的文档，例如官网博客、客户沟通材料这一步时，再手动切回 4.6。

不过 4.6 还有一个让我比较困惑的现象：同样的任务，4.6 消耗的 token 数量明显比 4.7 大不少。需要强调的是，Anthropic 官方目前已经下架了 4.6，想用 4.6 只能手动指定模型 ID 强制切回去才能用上。所以这个 token 异常增多到底是 bug，还是官方在产品层面有意的引导，目前我也没有定论，只能在写作时多观察一下用量。

六、写在最后

回头看这段时间，Claude Code 已经逐渐覆盖了我的整个工作流：从最早只用来写代码，到后来用来写作，再到现在用来跑开发的 Agent。我自己挑主力工具的标准其实挺简单的，就是看它在每天最难、最长程的那部分工作上稳不稳。功能多不多、demo 漂不漂亮，反而是次要的。

回到开头那个观察：在生产力工具的市场里，最好的一两个产品会赢走绝大多数高价值用户。今天的 Claude Code 在 Coding 和 Agent 能力上明显处于第一梯队，但 Codex 这些对手也在奋起直追。一年之后这个格局会不会变，我不知道，也觉得不重要。作为用户，押注哪个工具最终会赢其毫无意义。真正要紧的是把现在最好的工具用好，提升自己的工作效率。

希望今天分享的这些命令和工作流对你有用。如果你也在重度使用 Claude Code，欢迎在评论区或者读者群里交流你的经验和踩过的坑。

一家之言，仅供参考。

本文作者曹犟正在和团队打造 Omni-Growth Agent，海外全域营销 Agent。我们做了一个不太一样的事：用 1 个 Agent 覆盖 Google / Meta / LinkedIn / Reddit / SEO 等多个渠道，而且收入和客户的增长同步，你不增长，我们不收钱。如果你在做海外营销，欢迎免费让 AI Agent 跑一次诊断报告：https://omni-growth.ai/apply.html 文中讨论的 Claude Code 实践，也正是我们在 Omni-Growth Agent 上的真实工作经验。