如何最大化利用你的Token

我感觉 AI 现在对我来说，就是一个游戏机，Token 就是游戏币，每天玩得不亦乐乎。只要有一个想法，立刻就能去验证和实现，这种正反馈太强了。

不过，Token 很贵，人的精力也有限。如何把 Token 用好，又不至于让自己太累，是一个值得认真想想的问题。

第一个问题，是 Token 不够用。

我买了 200 美元的 Codex 订阅，经常额度刚重置，两三天就把一周的额度消耗得差不多了。但花了这笔钱，到底有没有充分发挥它的价值？

回头看看这两三天完成的事情，它们真的需要耗费一周的额度吗？有时候只是图省事，直接开着最好的模型、最高的推理强度去完成所有任务。任务做完了，但中间可能有不少浪费。

这就需要对自己的工作做一些分析：平时都在让 AI 处理什么任务，哪些需要比较强的推理能力，哪些要求并没有那么高，再给不同任务分配合适的模型和推理强度。

网上有很多经验可以参考。比如我看到 Tibo 提到过，Astra 的 low 强度已经相当于甚至超过了 Sol 的 high 强度。这类说法可以作为自己尝试的起点，但具体到手上的任务，还是要实际用过才知道。

我也根据这段时间的开发体验，总结了一些模型和推理强度的分配方法。每个人的任务类型不同，对结果的要求也不同，适合别人的配置，未必适合自己。这块还是得自己总结，看看哪些任务可以降低配置，哪些任务省下来的额度又被返工消耗掉了。

第二个问题，是 Token 用不完。

不够用会焦虑，用不完有时候也会焦虑。比如 Tibo 提前通知接下来会重置额度，而手上还有很多额度没用，第一反应就是：这不是白白浪费了吗？

我的办法是平时就准备一些需求。

有点子的时候，先告诉 AI，让它帮忙记下来。为此我专门做了一个需求池项目，给需求打标签，设置权重，再按重要程度排序。还写了一个 Skill，把随口说出来的想法整理成具体需求。

这里很重要的一步，是确定这个需求该怎么验证。

只把“我想做个什么东西”说出来，其实还不够。你还需要想清楚，AI 做到什么程度才算完成，怎么判断它有没有满足你的预期。如果没有验证方法，AI 很可能做出一个看起来像那么回事、实际却偏离初衷的东西。额度花了，最后还是用不了。

所以需求池需要时不时拿出来看看，补充背景，把验收标准想清楚。有些想法刚记下来时很模糊，过几天再看，可能就知道该怎么做了，也可能发现根本没必要做。

这样，等到知道额度即将重置时，就可以从需求池里按优先级挑出重要、准备充分的需求，让 AI 去跑。临时找事情消耗 Token 的焦虑会少很多，因为平时已经想过这些事情值不值得做，也知道怎么验收。

第三个问题，是额度的使用节奏。

这段时间使用 Codex，经常会碰到额外重置，但很多时候也不知道下一次会在什么时候发生。因此，我希望有一套使用策略，在重置时间不确定的情况下，也能尽量把额度用起来。

我目前的做法是：额度重置以后，根据自己的精力状态，尽快推进已经准备好的需求，直到用掉周额度的 90% 左右。

剩下的 10%，主要用来讨论后续需求、做方案设计，以及用 Luna Max 处理一些相对简单的任务。如果前两天已经用掉了 90%，后面几天就放慢节奏，整理下一批要做的事情，等额度恢复以后再集中开发。

这里的前提还是精力允许。需求池里有值得做的事情，自己也有精力判断和验收，就多推进一些。到了后半周，把注意力转到需求和方案上，开发强度也跟着降下来。

这样对我来说有两个好处。一是尽量提前完成有价值的工作，遇到额外重置时，不会还剩一大堆额度；二是前紧后松，有张有弛，不至于整周都处于不停提需求、看结果、继续追问的状态。

90% 是我目前给自己设的分界，并没有证明这是一个最优比例。

最近在 B 站看到一个视频，作者用蒙特卡洛模拟，把额度重置的时间、人的注意力等因素放到一起分析。按我的理解，得出的策略和我现在的做法比较接近：重置以后，在精力允许的情况下，尽早使用额度。不过，模拟的结论也依赖它的假设，我更多是把它当作一个有意思的对照。

第四个问题，是如何减少管理 AI Agent 消耗的精力。

人的精力和注意力是有限的。AI 可以同时跑很多任务，但如果每个任务都需要我盯着，反复解释背景、检查进度、告诉它下一步做什么，最后先耗尽的可能是我自己。

所以这段时间，我有不少工作是在把日常任务沉淀成 Skill，再通过多个 Skill 构建 Workflow，把重复的工作整理成 SOP。

比如项目管理、进度跟踪、任务的创建与更新，以及正在和组里同事一起做的开发流程自动化，都在往这个方向推进。希望后续只需要一句话，甚至在手机上发送一个指令，AI 就能沿着已有流程把事情处理下去。

这件事可以分成三个阶段。

第一个阶段，是让 AI 帮助你一起干活。通常是以前没做过的新事情，自己也没有完整思路，需要和 AI 一起讨论、尝试，再看结果。这个阶段需要投入比较多的精力，因为很多判断还没有形成。

第二个阶段，是让 AI 替你干某个具体的活。做过几次以后，把任务的处理方法、需要的材料和验收要求写成 Skill。下次再做，直接调用这个 Skill，就不用从头解释一遍。自己仍然需要参与，但投入会少一些。

第三个阶段，是构建系统，让系统替你干活。把平时一批有先后关系的工作组织成一套 AI 工作流，让上一步的结果能够接着进入下一步。这样就不用完成一个任务以后，再由自己手动安排另一个任务。

当然，写成 SOP 只是基础。要让整条流程跑起来，还需要把每一步怎么检查、出现问题怎么处理、哪些事情需要自己决定写清楚。否则 AI 跑到一半还是会停下来，等你告诉它接下来怎么办。

之前看到关于 OpenClaw 创始人的介绍，说他会同时管理多台电脑，每台电脑又跑着几十个 session。我猜测，他应该也构建了类似的自动化系统。具体怎么做的我不了解，但如果每个 session 都需要人逐条回复、逐个安排下一步，这种工作量很难长期维持。

我也想继续把自己的日常工作往这个方向整理，把需要反复交代的事情交给流程，腾出精力来处理那些确实需要自己参与判断的问题。

第五个问题，是如何构建任务处理工作流。

前面说到把工作交给系统，具体到一个项目，我目前的做法是先用自己手上最好的模型 Astra，和我一起分析、拆解需求。特别是在需求分析阶段，会借助 Eval First 这个 Skill，把需求和验收标准澄清清楚，再拆成可以并行处理的子任务，交给不同的 AI 执行。

这里有一步特别关键：把整个项目的目标和阶段性里程碑明确下来，写进文档，并且在 AGENTS.md 里做好导航，让后续接手的 AI 能找到这些内容。

一个项目持续迭代以后，需求会变，复杂度也会增加。如果 AI 每次只看到眼前这个新需求，做几轮以后，就很可能逐渐偏离项目原来的目标。单看每次修改似乎都有道理，放回整个项目里，却未必还是自己最初想做的东西。因此，拆任务之前需要把项目目标写清楚，后面有调整，也要同步更新这些文档。

拆解时，我会给 AI 一个大致的格式，让它把每个子任务整理成本地 Markdown 文档。除了具体要做的事情，还要写清楚任务范围、依赖关系和验收要求，方便不同的 AI 接着执行。能独立处理的任务可以并行，有前后依赖的任务则需要排好顺序。

同时，让 AI 为每个子任务生成一个标题、一段简短描述，以及一个可以直接复制的 Prompt。标题和描述方便我快速知道这个任务是干什么的；Prompt 则指向对应的任务文档，交给其他 AI 工具以后，就可以直接从文档开始工作，不用再手动解释一遍背景。

我也会要求 AI 在执行过程中自动记录过程信息、更新进度，并按约定自动提交代码。这样任务中断以后，可以根据记录继续做；项目整体的进展也能及时更新，让后面接手其他任务的 AI 知道哪些已经完成、哪些正在处理，减少重复工作和任务交叉。任务进度要和实际结果对应，不能只是文档里写了“完成”，代码和验证结果却没有跟上。

这套拆解任务、生成文档和 Prompt 的方法，也可以做成一个 Skill，后面在不同项目里复用。

任务准备好以后，就可以交给 Agent 管理工具。我用得比较多的是 Multica，会把拆出来的子任务创建成里面的 issue，形成一批可以随时启动的任务。需要马上处理的，就直接启动；项目不着急的，可以先放着，等 Token 比较充裕时再做。有些任务还可以设成定时执行，安排在自己不需要盯着的时段，或者非高峰时段处理。

这样，需求分析和任务执行就可以分开安排。自己有精力的时候，先和 Astra 把目标、方案和验收标准想清楚；后面有额度时，再启动已经准备好的任务，不必临时一边想需求，一边催着 AI 开工。

工具也不局限于 Multica。按我目前的了解，DeepSeek Harness 借助项目管理面板插件，也能实现类似的任务组织方式。对我来说，换工具时需要保留下来的，是项目目标、任务文档和执行记录。有了这些内容，才能让不同的 AI 接着干，而不用每换一个工具就重新讲一遍。