我理解 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` 中。
