我用 Claude Code 的另外七个技巧

我的十四条 Claude Code 使用经验 

之后，另外的几条经验：

第一，笔记本留在家，人走电脑不走。

所有工作都在那台笔记本上跑，离开家就不带走。这一条本身不稀奇，但跟下面几条配合起来才有意思。

第二，Claude Code 开 remote control。

在设置里打开 remote control 之后，手机上的 Claude Code 可以直接连回家里那台电脑。我人在外面，任务在家里一直跑，手机上看输出、下指令，两边都不耽误。这个感觉比随身带电脑还顺手——因为很多任务根本不需要我盯着，它自己跑就行，我偶尔瞄一眼就够了。另外还有一个细节：在settings.json里把remoteControlAtStartup设成启动项，这样开机就直接连上，不用每次手动开。

第三，Claude Design 和 Claude Code 配合，Mobile 效果出来挺不错的。

Claude Code 生成的 App 不用太好看，大概有那个意思就行了。具体做法是：在 Claude Design 里把所有相关文件都倒进去，让他在里面给你出图，不断调整，满意了之后直接把结果导出到 Claude Code，Claude Code 接下来就把这个 App 的样式扣进去。整个做法还是挺顺的。

第四，GitHub Actions 和 Claude Code 打通。

让 Claude Code 负责 Mobile App 的打包，然后发布到 TestFlight，或者直接推 App Store 提交审核——这些操作全部甩给他干。我基本上不想碰这块的手工操作，能自动化的就自动化掉。顺带一提，我在用 VoiceDrop 口述 App 的过程里，一不小心这两天就推了 58 个版本。。。

第五，给任务安排一个对手方，让两个 agent 互相打架。

很多任务，与其让一个 agent 一路干到底，不如给他找个对手。

做法是：先把要做的产品功能描述清楚，让一个 agent 去实现，哪怕他对背景的了解很有限也没关系，让他先做出来。然后再起一个完全没有上下文的 agent——甚至换一个模型——把最原始的需求和这个实现一块儿扔给他，让他挑毛病。我的经验是，换一个模型，总归还是能挑出来一些挺有道理的毛病的。挑出来了，再让做的那个人把毛病修掉，基本上就已经超过了绝大多数人能想到的了。

没有对手方，生成端自己评自己，基本上是自欺欺人。

第六，让他定期写状态报告。

一个对话走得很久、里面堆了很多工作的时候，不要信任他自己的内存管理。正确做法是：明确让他把当前状态沉淀到一个 state 文件里，然后把整个对话清空，下次开新对话先让他去读那个 state 文件。这样沉淀下来的内容更高效，也更容易管理。

第七，Claude Code 只是测试的地方，真正的工作要沉淀成工具、部署到服务器。

本地的 Claude Code，就是个玩耍和测试的地方。测试好了之后，把它沉淀成工具，部署到服务器上去，然后用 Claude Agent SDK 起一个服务——这样大多数日常工作就真的能跑起来了，既不依赖本地电脑，也不依赖使用者复杂的本地环境，隔离到服务器上之后，所有人都能有相同的智能体验。

这一点是我最近想通的，对我特别有帮助——在本地做测试，做好了以后，再把标准的 MCP 和相关工具都部署到服务器上去。

注：这篇文章是我纯用 VoiceDrop 生成的，意识流地把想法记下来，生成以后再用口述的方式对他进行修改——告诉他这个错了、那个字要改。比如我说 Voice 和 Drop 之间不要空格，他就把文章里涉及到 VoiceDrop 的地方全把空格去掉了。所以这两天我会把 App Store 的正式版放出来。