大家好，我是卡卡罗特。
最近 AI 圈又开始热闹起来了。
Anthropic 前2天重新上架了全新的 Fable 5 模型。OpenAI 的 GPT-5.6 据说也马上就要发布了；连 Google 的 Gemini 那边也有新动静，下一代模型蓄势待发。
7月，估计又是神仙打架的一个月。
模型越来越强，但随之而来的问题是——烧钱也越来越快了。
不知道大家有没有发现，最近 Codex 的额度似乎越来越不经用了。随便聊几个需求，5 小时的额度转眼就见底。
Plus 也好，Pro 也好，在 Token 面前一律平等。
所以今天给大家分享一些真正实用的省 Token 技巧，帮你在不降低效率的前提下，把每一分额度都花在刀刃上。
当然无论你用的是 Codex 还是 Claude Code，这些技巧都是通用的。
由简单到进阶，废话不多说，直接开始。
1、先聊需求，再写代码
如果你是一个空项目，需要 AI 帮你从0到1做一个项目。
那就建议前期先把需求沟通好，让 AI 完全理解你的需求，再让它去开发。
如果前期没有把需求沟通好，AI 做出的效果可能跟你想象的天差地别。
沟通需求这里强烈建议装一个 Superpowers 技能。
✅** 技能链接：**github.com/obra/superp…
这是一个 GitHub 上热门的开源项目，它是一个 skill 集合，内置了很多 skill，都非常好用。
怎么安装？
如果你是 Claude Code，直接通过这个命令安装：
/plugins install https://github.com/obra/superpowers
或者可以在你的控制台输入这个提示词（Codex 同样适用）：
帮我安装这个 skill：https://github.com/obra/superpowers
怎么用？ 装上这个技能之后，你提问的时候，它会根据你的提问，自动使用里面对应的 Skill。
这个里面有很多 skill。比如跟你聊需求的 /brainstorming 头脑风暴。
以下面这个为例。
比如它会反复跟你聊需求，确认你的技术栈、有哪些功能、布局呀、排版啊……
然后给你生成技术方案、执行方案。有了这些，它生成代码也不容易跑偏。
这里不再多说，感兴趣可以去搜一下。以后有空单独写一篇教程🤣。
2、少用 Fast 模式
在 Codex 里面有个速度选项，可以选择"快速"，官方说是 1.5 倍速度。
实测标准模式即可，快也快不到哪里去，Token 消耗量还会飙升，性价比很低。
直接用标准就行了🤔。
3、关掉 AI 的讨好模式
Codex 默认的回复语气是"亲和"。
它会花里胡哨地说很多”讨好你”的无用废话，占用上下文。😁
可以直接改成务实风格。
**更改路径：**在左下角【设置】→【个性化】中更改个性为【务实】。
改了之后，Codex 的回复就比较简洁了。它不会说一堆正确但是没用的废话。
4、一段规则，省掉重复沟通
Codex、Claude Code 都支持自定义全局的规则。
设置全局规则之后，它会自动将这规则加载到系统提示词中，就不需要每个项目都额外设置了。
**用了有什么好处？**🤔 它可以更懂你，更理解你的需求。
比如 Codex 可以在【个性化】这里设置【自定义指令】。
这里建议把 AI 大神卡帕西的规则放进去就行了，非常好用。
就这么一个规则文件，收获了 186K 的 star😁，可见有多牛。
✅开源地址：github.com/multica-ai/…
这个提示词里有很多非常实用的规则。
比如 Think Before Coding：指导 AI 在写代码之前多思考，如果需求不明确，需要跟人确认好再写代码。
比如 Simplicity First：做尽量少的改动。
感兴趣可以多去了解一下，可以让你对规则文件有一个新的认识。
✅规则文件地址：github.com/multica-ai/…
直接拷贝，然后放到个性化设置里就行了。
放在个性化这里相当于做了全局设置，之后你所有的项目都会加载这个全局规则。
当然，放在项目目录下的 AGENTS.md 里也可以。
如果你懒得找，我把它拷贝出来了。
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
## 1. Think Before Coding
**Don't assume. Don't hide confusion. Surface tradeoffs.**
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
- [Step] → verify: [check]
- [Step] → verify: [check]
- [Step] → verify: [check]
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
---
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
5、聊多了？赶紧开新会话
问大家一个问题，Claude Code、Codex 这种 AI Agent 为什么可以记住我们的对话内容？
比如你告诉它你叫卡卡罗特，然后多轮对话之后问它"你是谁？"，它还是知道你是卡卡罗特。
**它是怎么记住的呢？或者说原理是什么 **🤔
是因为它会记住你的“上下文”，可以理解成所有的聊天记录内容。
在同一个会话中，你每次问它一个问题，它都会把这些聊天记录发给 Codex 的服务端，然后服务端给出回答。
随着你跟 Codex 对话次数越多，聊天记录也越来越多，每次发送给 Codex 服务端的 Token 会不断增长，Token 的消耗量也会越来越大。
当然，Codex 的”上下文窗口”是有限的，它会自动压缩。
所以我强烈建议你，不要在一个会话中问很多问题。尤其是新的问题跟之前的问题出入比较大的时候，可以新开一个会话。
新会话的上下文窗口是全新的，不会携带之前的聊天记录。
提问的时候，Token 自然会少很多。
6、清理不用的 Skill
之前 skill 这个功能刚出的时候，很多人估计装了很多 Skill 玩，只是尝鲜而已。
一些小白用户看到好用的 Skill，赶紧装起来，后面却没用过，导致 skill 越攒越多。
这会导致 Codex 的系统上下文过长，占用 Token。
为什么？ 因为 skill 的元数据会加载到系统提示词里，占用上下文。
什么叫 skill 的元数据？
以下面这个例子为例。
红框内的是元数据，这段文字会加载到 Agent 的系统提示词里。
有了这个元数据，你在 Codex 提问时，如果提问的内容命中了某个 skill 的描述，它就会自动使用对应的 Skill。
如果你电脑装了几十个甚至上百个 skill，光这些元数据就占用了很多 Token。
把一些不用的 Skill 删掉，很有必要。
7、问题越精准，越省 Token
如果你的工作空间中代码或文件很多，提出问题尽量明确。
如果要改某个逻辑或文件，可以使用 @ 指定具体文件，让它修改。
尽量给它下达明确的任务，不然它会全文检索，根据关键词猜需要改哪个文件，然后去读，发现不对又去猜，再去读。
这些读取的文件都会加载到上下文中，非常占用 Token，并且也容易带来幻觉，不利于开发。
8、写一份项目说明书
当你的工作空间中文件越来越多之后，向 Agent 提问比较宽泛的问题时，它只能根据关键词搜索，猜需要改哪个文件，然后去读这个文件，读了之后就把文件内容加载到上下文。
所以有必要优化一下你的 AGENTS.md 文件，把重要的目录结构和规则写在里面。
比如一个空项目，你可以直接跟 Codex 说：根据目前的项目规范和业务逻辑，帮我生成一个 AGENTS.md 文件。
或者使用 /init 命令。
它一般会帮你生成如下这些内容。
- 项目使用什么技术
- 目录如何划分
- 如何安装、启动、测试
- 修改代码必须遵守什么规则
- 哪些文件不能修改
- 什么情况下才算任务完成
这些内容会自动加载到系统提示词，也就是上下文中，所以它会更懂你的项目，回答也更准确。
当然，写出一个好的规则文件很考验技巧，需要逐渐迭代、慢慢优化。
你可以在 OpenAI 的官方文档里学习一下：developers.openai.com/codex/learn…
后面我单独出一篇教程，好好聊一聊这个文件该怎么写。等我🤗！
共用规则文件
事实上，Claude Code 和 Codex 的规则文件命名不一样。Claude Code 叫 CLAUDE.md，Codex 叫 AGENTS.md。
如果需要维护两套，那就比较麻烦了。
好在 AGENTS.md 已经成为了一个行业惯例，主流的 Coding Agent 都能识别，比如 Cursor、OpenCode、Codex 等。
你可以把所有规则写在 AGENTS.md 里，然后在 CLAUDE.md 文件中写 @AGENTS.md，Claude Code 也能识别，它会加载 @ 引用的内容。
又是一个小技巧🤔
9、杀鸡别用牛刀
能手动执行的操作，比如 Git 提交，就自己手动做。
或者把一些简单的任务交给 Claude Code，用 Deepseek 模型来跑，那就非常节省 Token 了。
你可以直接在 Codex 里启动 Claude Code。（不会吧不会吧，不会有人才知道吧？😁）
还是不够用？
如果 Token 还是不够用，那就开 Pro。100 美金/月的 Pro 是 Plus 的 5 倍额度，200 美金/月是 Plus 的 20 倍额度。
如果你在开发重要项目，或者做一个很重要的功能，时间就是成本，不要省这点钱了，用到就是赚到。
你还知道哪些省 Token 的方式呢？🤔欢迎大家在评论区交流～
我是卡卡罗特，持续分享对你有用的 AI 干货内容，我们下期见～
