推文

Claude Code 用到这个程度，我算是开眼了 Matt Van Horn 最近写了一篇长文，把他用 Claude Code 的所有技巧和工作流全盘托出了。这篇文章在开发者社区引起了不小的反响，因为他展示的东西已经远远超出了“用 AI 辅助写代码”的范畴。他的核心主张只有一句话：不用 IDE，只用 plan.md 文件和语音。听起来像是在吹牛，但看完他的整套操作之后，你会发现这句话是认真的。 一切从计划开始，代码是最后才写的东西 Matt 说他学到的最重要的一件事就是：脑子里一冒出想法，第一反应永远是 /ce: plan。不管是一个疯狂的产品创意、一个 GitHub 上的 bug 报告，还是终端里弹出的一条报错信息，他都是先截图或者复制链接，扔进 Claude Code，让它先出一份计划。 这个 /ce: plan 命令背后的机制挺有意思的。它会同时启动好几个研究 Agent 并行工作，一个去分析你的代码库，读文件、找模式、检查代码规范；另一个去翻你以前修 bug 时积累的经验文档；如果话题需要，还会有更多 Agent 去查外部的最佳实践和框架文档。全部同时进行，最后汇总成一份结构化的 plan.md，里面写清楚了问题是什么、用什么方案、要动哪些文件、验收标准带勾选框，而且这些内容全部是基于你自己的代码库和历史记录的，不是泛泛而谈的通用建议。 然后 /ce: work 接过这份计划去执行，拆任务、写代码、跑测试、逐条勾掉验收标准。如果中间上下文丢了，开个新会话指向那份计划就能继续。计划文件就是一个永远不会丢的存档点。 传统开发是 80% 写代码、20% 做规划，Matt 把这个比例完全反过来了。思考发生在计划里，执行交给机器。这个理念其实不只适用于写代码，做任何复杂的事情，花更多时间想清楚要做什么、怎么做，然后把执行层面的事情尽可能自动化，效率都会高得多。很多人习惯上来就动手，边做边想，结果经常做到一半发现方向不对，推倒重来。先规划再执行这个道理大家都懂，但 Matt 用工具把它变成了一个强制性的流程，这才是关键。 Compound Engineering：让计划驱动开发成为现实的插件 让这套 plan 优先的工作流真正跑起来的，是一个叫 Compound Engineering 的插件，来自 Every 公司。安装命令就一行：/plugin marketplace add EveryInc/compound-engineering-plugin. Matt 从这个插件的死忠粉变成了 GitHub 上的第三大贡献者，提交了 21 个 commit。他现在有 70 个 plan 文件，过去 30 天提交了 263 个 commit。他给自己定了一条铁律：除非真的只改一行代码，否则一定先写 plan.md。 这个数字本身就很说明问题。70 个计划文件对应 263 个代码提交，意味着平均每份计划产出将近 4 个 commit。计划写得越清楚，执行的效率就越高，返工的概率就越低。这跟很多项目管理方法论里强调的“前期投入”是一个道理，只不过 Matt 把它落地到了每天的开发工作中，而且有工具来保证执行。 语音输入：当听的人足够聪明，说话就变成了最高效的输入方式 Matt 说他以前特别受不了语音备忘录，苹果自带的听写功能让他想摔手机。但语音转 LLM 完全不一样。转录不需要完美，因为 Claude Code 能理解上下文，它会猜出麦克风没听清的部分。你可以含糊不清、说到一半跑题、重新起头，都没关系。 他用的工具叫 Monologue，也是 Every 公司做的，能把你说的话直接输入到当前聚焦的应用里。你说话，它就往 Claude Code 里打字。他还专门买了个鹅颈麦克风放在办公桌上。更夸张的是，他写那篇文章的时候，有一段就是在特斯拉的 FSD 自动驾驶模式下一边送孩子一边口述的。 语音输入这件事之所以过去一直不好用，核心问题在于转录精度。你说的每个字都必须被准确识别，否则就会出错。但当接收方从一个死板的文字处理器变成一个能理解上下文的 AI 之后，这个瓶颈就消失了。AI 不需要你每个字都说清楚，它能根据前后文推断出你的意思。这个变化看似很小，但它实际上解锁了一种全新的人机交互方式：你可以像跟同事说话一样跟 AI 交流，不用字斟句酌，不用担心措辞，甚至不用担心语法。 四到六个窗口并行跑：一个人活成一个团队 Matt 日常的工作状态是同时开四到六个 Ghostty 终端窗口，每个跑一个独立的 Claude Code 会话。一个在写计划，一个在根据另一份计划构建代码，一个在跑 /last30days 做调研，一个在修他测试上一个功能时发现的 bug。 当一个窗口里 /ce: plan 正在启动研究 Agent 的时候，他切到另一个窗口 /ce: work 执行一份已经写好的计划。那边在构建的时候，第三个窗口又粘进去一个新 bug。等他切回第一个窗口，计划已经写好了，安静地等在编辑器里。 为了让这种并行工作模式跑得通，他改了三个关键配置。第一个是跳过权限确认，Claude Code 默认每个操作都要你点“允许”，他直接在配置文件里把所有权限都放开了，让每个会话完全自主运行。第二个是完成时播放提示音，这样他可以走开去干别的，听到声音再回来看结果。第三个是 Zed 编辑器每 500 毫秒自动保存，这样 Claude Code 改了文件，编辑器里立刻能看到变化，反过来他在编辑器里打字，Claude 一秒内就能感知到。整个体验就像在 Google Docs 上跟人协作，只不过协作者是个 AI。 这种工作方式的代价也很直观：他的 MacBook 大概一小时就没电了，六个 Claude 会话并行跑太耗电了，他刚下单了新款 MacBook Pro。但换个角度想，一个人同时推进四到六个任务，这在以前是不可想象的。过去你需要一个团队来并行处理不同的工作流，现在一个人加一组 AI 会话就能做到。 /last30days：做任何决策之前，先看看社区在聊什么 Matt 在做 /ce: plan 之前，经常先跑一个叫 /last30days 的调研工具。这个工具是他自己开源的，GitHub 上已经有 4500 颗星了。它能并行搜索 Reddit、X、YouTube、TikTok、Instagram、Hacker News、Polymarket 和网页，几分钟内把某个话题在过去 30 天里的社区讨论全部拉回来。 他举了个例子。当时他在 Vercel 的 agent-browser 和 Playwright 之间做选择，没去翻文档，直接跑了 /last30days。几分钟后结果出来了：78 个 Reddit 帖子、76 条推文、22 个 YouTube 视频、15 个 Hacker News 讨论。数据显示 agent-browser 的上下文 token 消耗比 Playwright 少 82% 到 93%，Playwright 光工具定义就要吃掉 13700 个 token。 然后他把全部输出喂给 /ce: plan，写出来的计划是基于社区当下真实认知的，不是六个月前的训练数据。 这个做法的价值在于：AI 模型的训练数据总是有滞后的，但技术社区的讨论是实时的。先用工具抓取最新的社区共识，再让 AI 基于这些信息做规划，决策质量会高很多。这个思路不只适用于技术选型，做产品决策、市场调研、竞品分析的时候，先看看真实用户在聊什么，比自己闭门造车靠谱得多。 午餐聊天变产品提案：上下文的复利效应 Matt 讲了一个特别有意思的故事。他跟一个潜在候选人吃了顿午饭，聊了一个半小时，内容包括一个新产品想法、美食、餐厅、孩子，什么都聊。他全程开着 Granola 录音。 午饭后，他把完整的会议记录粘贴到 Claude Code 里，让它把这段对话变成一份产品提案。关键在于，Claude Code 已经知道他们公司的产品代码在 GitHub 的什么位置，还能访问他之前写的每一份战略 plan.md。所以它处理这段午餐对话的时候，不只是提取里面的产品想法，而是在跟实际代码库和过去所有战略决策做交叉比对。 结果一次就生成了一份非常出色的提案，目标、用户故事、技术方案、里程碑一应俱全，关于餐厅和寿司的部分自动忽略了。当晚发给了那个候选人，这个人后来全职加入了他们，现在就在做那个产品。 这个故事里最值得关注的概念是“上下文的复利效应”。每一份你写过的战略文档、每一个你做过的技术决策、每一次你积累的经验，如果都以结构化的方式存下来，它们就会成为 AI 做下一次决策时的参考依据。时间越长，积累越多，AI 给出的建议就越精准。这就像复利一样，前期看不出什么差别，但随着时间推移，差距会越来越大。 Mac Mini 变成 24 小时在线的 AI 工作站 Matt 有一台 Mac Mini 专门跑 OpenClaw，但他还用它做了两件很聪明的事。 第一件是通过 Telegram 远程操控。Claude Code 有 Telegram 集成，他从手机给 Mac Mini 发消息就行。吃饭的时候想到一个 bug，往 Telegram 里打一句 /ce: plan fix the timeout issue，等回到电脑前，计划已经在编辑器里等着了。 第二件是飞机上用 tmux。Claude Code 处理飞机 WiFi 的能力很差，连接一断会话就挂了。但如果先 tmux 到 Mac Mini 上，会话就跑在那台机器上，笔记本只是一个窗口。WiFi 断了 20 分钟？重新连上就行，会话还在原来的地方，而且一直在干活。他从欧洲飞回来的整趟航班都在发布功能。 一台几千块的 Mac Mini，加上一些配置，就变成了一个 24 小时在线、随时可以远程调度的 AI 工作站。这个思路的性价比极高，对于任何需要长时间跑 AI 任务的人来说都值得参考。 费用策略：Claude 负责思考，Codex 负责干活 这种高强度的使用方式自然会带来费用问题。四到六个 Opus 会话全天并行跑，每月 200 美元的 Claude Max 套餐很快就会烧完。 Matt 的解决办法是再买一个每月 200 美元的 Codex 套餐。他给 Compound Engineering 提交了一个 /ce: work --codex 功能，当 Claude 额度不够时自动切换到 Codex 执行。两个套餐互补：Claude 负责规划和编排，Codex 负责重度代码实现。 有些朋友用 Codex 来 review Claude Code 写的代码，反过来也一样。还有人更喜欢 Codex 的代码输出质量，但通过 Claude Code 来做编排调度。这种“让不同的 AI 各司其职”的思路，跟管理团队其实是一个逻辑：你不会让同一个人既做战略规划又做具体执行，AI 也一样，让擅长思考的去思考，让擅长执行的去执行。 他还提到自己有一个“晚安模式”，能在睡觉的时候让 Agent 继续干活，但具体怎么做他说下次再讲。光是这个概念就已经够让人兴奋了，相当于你的工作时间从每天十几个小时变成了 24 小时。 迪士尼世界：这套工作流不只是用来写代码的 文章最后 Matt 讲了一个完全跟代码无关的实战案例，非常生动。他在足球场看孩子比赛，旁边一个家长跟他聊迪士尼世界的旅行计划。他当场掏出笔记本演示。 先跑 /last30days Disney World，两分钟后拿到了 66 个 Reddit 帖子、34 条推文、8 个 YouTube 视频的最新信息，包括价格趋势、哪些项目在维修、哪些即将重新开放。然后用 /ce: plan 输入自己的需求：一天跑四个园区、想玩哪些项目、预算多少、孩子多大。Claude 的研究 Agent 交叉比对数据后，写出了一份结构化的攻略，包括园区顺序、快速通道预订策略、提前一周要设的闹钟提醒，甚至还列了孩子的身高要求。 他还帮那位家长也做了一份三天的攻略，305 行，包含逐日行程和一条“这周先给你家五岁的穿着鞋量一下身高”的提醒。然后一句话让 Claude 把攻略部署成了一个 Vercel 网页，方便在手机上看。最后通过 Telegram 把计划扔给 OpenClaw，让它在日历上设好提醒，还做了 cron 定时任务作为双重保险。 语音到调研到计划到网站到自动提醒，全程在足球场边完成。 这个案例的意义在于，它证明了这套工作流的适用范围远远超出了软件开发。调研、规划、执行、部署、自动化，这个循环适用于任何需要处理复杂信息并做出决策的场景。旅行规划只是一个例子，换成市场调研、活动策划、投资分析，逻辑都是一样的。 Matt 在文章结尾总结了他的全部装备： 一个语音应用、一个计划文件插件、三个配置修改、四到六个并行会话、一台 Mac Mini，再加上能变成产品提案的午餐会议。没有 IDE，没有代码。说、规划、构建。在书桌前、在沙发上、在车里、在球场边。 这篇文章最大的价值可能不在于具体的工具和配置，而在于它展示了一种全新的工作范式：人负责思考和决策，AI 负责调研和执行。当你把这两者之间的协作流程打磨得足够顺畅的时候，一个人能做到的事情会远远超出你的想象。 而这一切的起点，只是一个简单的习惯：有想法的时候，先写计划。 #AI #AIAgent @grok