我理解 ai 时代一个很重要的能力是有效消耗 token 的能力。之前看到 token king 都是各种羡慕,到处问别人是怎么消耗 Token 的。我也和很多同学一样,从 claude 的 $20 买起,然后 $100 5x,然后 $200 20x,截止 2026.5.29,日消耗 20x 的 30%+,一周得差不多 1.5 个 20x 才能满足需求了,日产出有效代码也到了 1w ~ 3w+ 。
所以怎么用到这个量?说下我的方法论,欢迎探讨。1、用 /one-shot 研发需求。/one-shot 是个概念,可以是 skill 或 plugin。ta 是你研发一个需求的全自动化流程。你日常怎么开发需求的,比如我是用 brainstorm 产出 design,然后迭代 deisng,然后 impl,然后就想办法把这个过程给全自动化,重点是把不重要的决策点全交给 AI。减少人在这中间的决策过程,让一个 task 跑 20m+、30m+ 甚至 1h 完全不需要管,当你知道一个 /one-shot 出去后这个任务可以被高质量完成,就能并行执行 n 个任务了。2、并发和 issue 管理。boris 日处理峰值 200+,我目前 70+,如果不限 token 的话,努努力能上 100+。1)并发不少同学用的是 worktree,我没用,我用的古法多目录法,所以会有 -2、-3、-4、-5,通常 5 个并发量,够用了,相比 worktree 的好处是省去了环境 setup 消耗,同时出问题时也可以方便地进入到对应的环境对应的 session 进行调试。2)我有个 issue 管理系统,当 issue 被标记为 todo 时,就会自动用前面的 /one-shot 去执行然后提 PR,所以我的工作就变成了 create n 个 todo status 的 issue,然后等验收。3)create issue 也可以是 ai 做的,因为 ai 可以基于你的分析,产出更事无巨细的 issue 描述,我的每个项目下都有个 /create-issue 的 skill 来干这件事,一通分析后调 /create-issue 来让 ai 干活。
3、循环(loop)。你的循环越多,效率就越高。循环可以和 /create-issue 结合。比如,1)你有完善的日志系统,会收集错误日志,有一个错误日志分析的循环,找到问题后,执行 /create-issue,2)你有个竞品分析系统,每天早上 7:10 运行,找到重要的资讯,然后逐条分析,和当前项目做匹配,把重要的筛出来,然后执行 /create-issue,3)每天晚上使用 /clawpatch-bugsskill 查找 bug,然后创建 issue。循环越多,创建的 issue 就越多,项目迭代速度就越快。/clawpatch-bugs4、然后是怎么做验收。这是个难题,感觉没有很好的通用解。我目前是通过用例 + 人工验收 + 提升每个 issue 的代码质量 + 详细日志来做的。1)提升代码质量相关性的东西太多了,比如已有代码、架构、代码实施阶段 design 的完整性等,我的 /one-shot 会在 design 阶段消耗 80% 的时间,尽可能多的考虑 edge case,然后 20% 的时间用来写代码,所以产出代码质量会更高一些 , 2)架构也很重要,同时要管理好项目的复杂度,当一个任务需要来回改来改去要改 n 次都改不好的时候,就要考虑架构问题了,3)日志得多花点心思,我是每次验收时遇到问题时,把错误描述给他,让 ai 直接分析相关的日志,然后给方案。最后说一下我的配置。1)原则是用最好的模型和工具,2)Claude Code Max 两个账号,一个 20x 一个 5x,日常用 Opus 4.8 1M,3)Backup zenmux + 一个朋友的中转站,因为 Claude Code 经常挂了,挂了的时候随时切,4)还没开始用 codex,总感觉交任务给他没那么放心,但身边越来越多人开始用他,也准备试试。 补充:
听劝,开始用 worktree 了,整理下笔记。
-
1\ 最简单的起手式。 ``` # 终端 1 claude -w feature-auth # 终端 2 claude -w bugfix-login ``` 默认建在 `.claude/worktrees/<名字>/`,自动开一条 `worktree-<名字>` 分支。 不取名?`claude -w` 直接给你生成一个,比如 bright-running-fox。
2\ 不想切换终端?也可以让 Claude 自己进去。 在会话中直接说"在 worktree 中工作",它就会用 `EnterWorktree` 工具帮你设置好,甚至中途还能切到另一个 worktree。完事后用 `ExitWorktree` 回到原始目录,全程不用手动敲 git 命令。 我个人更偏好这种方式。
3\ 新 worktree 从哪个分支派生? 默认是 `"fresh"`,从远程默认分支拉取干净树,与线上版本一致。 想包含本地未推送的提交?在设置中配置: ```json { "worktree": { "baseRef": "head" } } ```
4\ 审查 PR 的神级操作。 ``` claude -w "#1234" ``` 这会把 PR 直接拉到一个隔离的 worktree 中(`.claude/worktrees/pr-1234`),也可以粘贴完整的 GitHub PR 链接。让 Claude 在干净环境中阅读 PR,不会污染你当前的工作区。
5\ 坑点 1:.env 不会带过来。 在根目录放一个 `.worktreeinclude`(语法同 .gitignore),列出要携带的本地文件: ``` .env .env.local config/secrets.json ``` 新的 worktree 会自动拷贝这些文件。
6\ 坑点 2:每个 worktree 都会重新安装 `node_modules`。 ```json { "worktree": { "symlinkDirectories": ["node_modules", ".cache"] }} ``` 用软链接共享它们,节省磁盘空间。 对于大型单体仓库,添加 `sparsePaths` 只检出你需要操作的目录,启动更快。
7\ 子 agent 启动 worktree? 在自定义子 agent 的前置信息中添加一行: ``` isolation: worktree ``` 每个子 agent 拥有独立的仓库副本可独立工作,未做任何修改的会在结束时自动删除,零杂乱。
8\ 最后一条建议。 记得将 `.claude/worktrees/` 添加到你的 `.gitignore` 中。