去年 9 月，一篇关于 Claude Code 如何重构写作工作的经验分享引起了不小关注。大半年过去了，用它做的事情远不止写代码和写文章，过程中踩了不少坑，也攒下了一些值得拿出来细聊的细节。这篇文章就把这些集中梳理一下。
一、为什么是 Claude Code
先简单交代一下工具选择的路径。
Cursor 算是比较早的一批用户，最初那段时间，它的确体验最好的 AI 编程工具之一。但 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 这些对手也在奋起直追。一年之后这个格局会不会变，不重要。作为用户，押注哪个工具最终会赢毫无意义，真正要紧的是把现在最好的工具用好，提升自己的工作效率。
希望今天分享的这些命令和工作流对你有用。
本文作者正在和团队打造 Omni-Growth Agent，海外全域营销 Agent。用一个 Agent 覆盖 Google / Meta / LinkedIn / Reddit / SEO 等多个渠道，收入和客户的增长同步，你不增长，我们不收钱。文中讨论的 Claude Code 实践，也正是我们在 Omni-Growth Agent 上的真实工作经验。
