先交代下我的消耗量级，免得显得在空谈。我和大多数人一样，从 Claude 的 $20 套餐买起，然后 $100 的 5x，再到 $200 的 20x。截止 2026 年 5 月 29 日，我日均能吃掉一个 20x 套餐的 30% 以上，一周差不多得烧掉 1.5 个 20x 才够用，日产出有效代码在 1 万到 3 万行以上。怎么用到这个量的？核心就一句话：把人从决策环节里尽量抠出去。

用 /one-shot 把一个需求跑成全自动流程

/one-shot 不是某个具体工具，而是一个概念——它可以是一个 skill，也可以是一个 plugin，本质是「研发一个需求的全自动化流程」。

思路很简单：你平时怎么开发需求，就把那套流程原样自动化。比如我的习惯是先 brainstorm 产出 design，然后迭代 design，再 impl。那我就想办法把这整条链路串成一个自动流程，重点是把那些不重要的决策点全部丢给 AI，减少人在中间的卡顿。

目标是让一个 task 能自己跑 20 分钟、30 分钟甚至 1 小时，全程不用你盯着。一旦你确信一个 /one-shot 丢出去之后，任务大概率能被高质量地完成，你就敢同时并行跑 n 个任务了。说白了，自动化的真正价值不是省那点手速，而是解放你的注意力——人一旦不用守着进度条，并发就成立了。

并发与 issue 管理

并发量上，给个参照系：boris 日处理峰值 200+，我目前在 70+，如果不卡 token 的话努努力能上 100+。

并发方案：不少同学用 worktree，我没用，走的是「古法多目录法」——所以你会看到我的目录后缀是 -2、-3、-4、-5，通常开 5 个并发就够用了。相比 worktree，多目录的好处是省掉了每次环境 setup 的开销，而且一旦某个任务出问题，我能直接钻进对应目录、对应 session 去调试，不绕弯子。

issue 驱动：我有一套 issue 管理系统，当某个 issue 被标记成 todo，系统就会自动调用前面说的 /one-shot 去执行，跑完直接提 PR。于是我的日常工作被压缩成了两件事——创建 n 个 todo 状态的 issue，然后等验收。

连建 issue 都交给 AI：因为 AI 能基于你的分析产出事无巨细的 issue 描述，往往比你手写得还细。我每个项目下都挂了一个 /create-issue 的 skill，一通分析后调它来干这个脏活。

loop 越多，迭代越快

这是整套打法里最关键的飞轮：你的 loop 越多，效率就越高。 loop 可以和 /create-issue 串起来，举几个我在跑的例子：

  • 错误日志 loop：日志系统会自动收集错误日志，一个分析 loop 定时去扫，找到问题就 /create-issue。
  • 竞品分析 loop：每天早上 7:10 自动运行，抓取重要资讯逐条分析，跟当前项目做匹配，筛出值得做的，然后 /create-issue。
  • 找 bug loop：每天晚上用 /clawpatch-bugs skill 扫 bug，扫到就建 issue。

逻辑是闭环的：loop 越多 → issue 创建得越多 → 项目迭代速度越快。你只要把「发现问题」这件事也自动化掉，整台机器就自己转起来了。

验收：目前没有银弹

这是真正的难题，我感觉业界也没有什么通用解。我现在是靠用例 + 人工验收 + 提升每个 issue 的代码质量 + 详细日志这四件套硬扛。

  • 提升代码质量：影响因素太多了——已有代码、架构、实施阶段 design 的完整性等等。我的 /one-shot 会把 80% 的时间砸在 design 阶段，尽可能多地把 edge case 想清楚，剩下 20% 的时间才用来写代码。前置思考做得越足，产出代码的质量自然越高。
  • 管好架构和复杂度：架构很重要，但更重要的是控制项目复杂度。一个判断信号是——当某个任务你来回改了 n 次都改不利索时，别再跟代码死磕了，多半是架构出了问题。
  • 日志要舍得花心思：我每次验收遇到问题，就把错误描述丢给 AI，让它直接去分析相关日志、给方案。日志写得越细，AI 帮你定位问题的能力就越强，这部分投入回报极高。

我的 setup

最后交代下家伙事，原则就一条——用最好的模型和工具：

  • Claude Code Max 两个账号，一个 20x、一个 5x，日常跑 Opus 4.8 1M。
  • Backup 是 zenmux 加一个朋友的中转站。因为 Claude Code 经常挂，挂了就随时切，保证不断流。
  • 还没用上 codex，总觉得把任务交给它没那么放心。不过身边用的人越来越多了，也准备找时间试试。

如果你也想把消耗量级拉上去，别从「怎么烧更多 token」入手，那是结果不是原因。先把一条需求的完整流程自动化成 /one-shot，再用各种 loop 持续往里灌 issue——当机器开始自己给自己派活，token 自然就不够用了。验收这关暂时绕不过人工，那就把功夫下在前面：design 阶段多想一步，日志多写一行，后面省下的都是返工的时间。