网站首页 收藏本站
广告位联系

APP正在开发中...
返回顶部
您的位置： 主页 > Ai >

收藏
分享到

Codex节省Token Skills的五种开源方案

Ai 来源：互联网 作者：佚名 发布时间：2026-08-26 22:35:57 人浏览
摘要

Codex 的 token 消耗来自两端：输入端（每轮把 CLAUDE.md、技能文件、代码上下文喂给模型）和输出端（模型回复、代码生成、解释说明）。多数人只关注输出端的废话，但输入端的文件膨胀同样在

Codex 的 token 消耗来自两端：输入端（每轮把 CLAUDE.md、技能文件、代码上下文喂给模型）和输出端（模型回复、代码生成、解释说明）。多数人只关注输出端的"废话"，但输入端的文件膨胀同样在悄悄烧钱——尤其是每轮把整个 PDF 文档、大型 Word 文件塞进上下文的习惯，消耗可能超过代码生成本身。本文整理 GitHub 上星数最高的 5 个 token 省钱方案：4 个 Skills 覆盖从"压缩 AI 回复"到"控制代码生成量"的不同路径，1 个 Microsoft 出品的文档转换工具帮你在 PDF 进入 Codex 之前先把体积打薄，给出安装方式、实际减少比例和适用场景，帮你按用量结构找到最划算的组合。

为什么 Codex 消耗这么多 token

Codex 的 token 账单由三块构成：

输入 token（通常占大头）

  • 每轮携带的 CLAUDE.md / AGENTS.md 文件内容
  • 已加载的 Skills 文件
  • 代码上下文（读取的文件内容）
  • 历史对话消息
  • 直接投喂的 PDF / Word / PPT 文档（往往几千 token 起步）

输出 token（更贵，V4-Flash 输出是输入的 2 倍单价）

  • 模型的文字解释和前后套话
  • 生成的代码
  • 计划、状态报告、执行叙述

工具调用 token

  • 每次 Read、Edit、Bash 调用都有开销
  • 读整个文件而不是目标行，会把数千行无关代码塞进上下文

下面 5 个方案针对不同消耗来源各有侧重。

1. Ponytail — 最高 94% 代码行减少，逻辑决策层

GitHub：DietrichGebert/ponytail｜Star 数：~9.5 万

Ponytail 的核心不是"让 AI 少说话"，而是在 AI 决定写什么代码之前加一道决策梯：

1

2

3

4

5

6

7

1. 这个东西需要存在吗？    → 不需要：跳过（YAGNI）

2. 代码库里已有？          → 复用，不重写

3. 标准库能做？            → 用标准库

4. 原生平台功能？          → 用原生

5. 已装的依赖能搞定？      → 用依赖

6. 一行能写完？            → 一行

7. 以上都不行：最小可用实现

经典案例：你说"加个日期选择器"，普通 Codex 会装 flatpickr、写 wrapper 组件、加样式表，开始讨论时区。Ponytail 介入后的输出：

1

2

<!-- ponytail: browser has one -->

<input type="date">

在对 FastAPI + React 真实代码库的 12 项功能任务测试（Haiku 4.5，n=4）中：

指标 vs 无技能基准
代码行数 -54%（最高达 -94%）
token 消耗 -22%
成本 -20%
耗时 -27%
安全性 100%（保留所有错误处理和验证）

安装（Claude Code）：

1

2

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

（需分两条消息发送）

安装（Codex）：

1

2

codex plugin marketplace add DietrichGebert/ponytail

codex plugin add ponytail@ponytail

适合场景：前端开发、功能迭代、AI 倾向过度实现的场景（安装第三方库替代一行原生代码）。不适合场景：算法密集型任务，代码本来就没有"更简单的原生替代"。

2. Caveman — 65% 输出 token 压缩，换一种说话方式

GitHub：JuliusBrussee/caveman｜Star 数：~9.5 万

Caveman 的思路完全不同：让 AI 像穴居人一样说话——去掉所有铺垫和废话，保留准确的技术信息。

对比示例：

普通 Codex（69 token） Caveman Codex（19 token）
“The reason your React component is re-rendering is likely because you’re creating a new object reference on each render cycle. When you pass an inline object as a prop, React’s shallow comparison sees it as a different object every time, which triggers a re-render. I’d recommend using useMemo to memoize the object.” “New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.”

代码、命令、错误信息保持原样，只压缩散文叙述。

在 JetBrains 86 个任务的独立测评中，Agent 模式下实测减少 8.5% 输出 token（纯对话场景可达 65%——Agent 工作流大部分输出是代码和工具调用，散文占比低）。

一键安装（自动检测本机所有 Agent）：

1

2

3

4

5

# macOS / Linux / WSL

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

 

# Windows PowerShell

irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex

支持三档语气：默认标准穴居人、--standard、--ultra（最简电报体）。

适合场景：对话密集型工作流、需要大量解释的复杂重构任务。Agent 自动化流水线效果有限（代码输出本就不啰嗦）。

3. token-diet — 多维度全覆盖，平均降账单 31%

GitHub：Kulaxyz/token-diet｜Star 数：515

token-diet 覆盖范围最广，从回复措辞到工具调用策略全部管控：

  • 回复：先给结论，无开场白（“Sure! Here’s…”），无结尾客套（“Let me know…”），报结果不叙述过程
  • 文档 / 计划 / 注释：最少用词，只注释"为什么"不注释"做什么"
  • 测试：只写关键路径和边界情况，每次会话 ≤10 个测试用例
  • 代码：YAGNI，不写死代码，不过度抽象
  • 上下文：先 grep 再读，只读需要的行，不读整个文件；批量发独立读取调用；不重读刚编辑的文件
  • 工具调用：批量独立调用，够信息立即行动，针对性运行测试

真实 Sonnet 5 运行数据：

场景 输出减少 账单减少
输出密集（建议、规划、解释） -81% -54%
代码修改 + 测试（1673 文件项目） -49% -22%
读密集型理解任务 -30% -17%
平均 -53% -31%

支持三档：on（默认全部规则）、lite（仅沟通 + 文件）、ultra（电报体对话）。

安装：

1

2

3

curl -fsSL https://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh | bash

# ultra 档：

curl -fsSL https://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh | bash -s -- --ultra

4. claude-token-efficient — 最轻量，一个 CLAUDE.md 文件搞定

GitHub：drona23/claude-token-efficient｜Star 数：5913

最低安装成本的方案：一个文件，放进项目根目录，自动生效。

针对 Claude / Codex 默认的七种废话行为：

  • “Sure!”、“Great question!”、“Absolutely!” 等开场白
  • “I hope this helps! Let me know if you need anything!” 结尾
  • em 破折号、花引号等会破坏解析器的特殊字符
  • 回答前先复述你的问题
  • 主动提供你没要求的建议
  • 过度抽象的代码
  • 对错误说法点头称是（“You’re absolutely right!”）

基准测试（5 个提示）：

测试 基准 优化后 减少
解释 async/await 180 词 65 词 64%
代码审查 120 词 30 词 75%
什么是 REST API 110 词 55 词 50%
幻觉纠正 55 词 20 词 64%
合计 465 词 170 词 63%

重要限制：CLAUDE.md 文件本身每轮都作为输入 token 消耗，低用量场景下输入成本可能高于节省的输出成本。高输出量的自动化流水线最划算，偶发低频使用可能不合算。

安装：
直接下载 CLAUDE.md 放进项目根目录，或放进 ~/.claude/ 作为全局配置：

1

curl -fsSL https://raw.githubusercontent.com/drona23/claude-token-efficient/main/CLAUDE.md -o ~/.claude/CLAUDE.md

5. MarkItDown — PDF / Office 转 Markdown，在文档进入 Codex 前先瘦身

GitHub：microsoft/markitdown｜Star 数：~17.1 万

前四个方案针对的是 Codex 的"输出侧"和"回复方式"，MarkItDown 解决的是完全不同的问题：文档在进入上下文之前就把体积压下来。

一份 50 页 PDF 直接投给 Codex，Vision 模式可能消耗 5000-20000 token 来"读图"。MarkItDown 先把 PDF 转成干净的 Markdown 文本，同样内容通常只需 1000-3000 token——进入模型之前就省掉了 70-80%。

支持格式

PDF、PowerPoint（.pptx）、Word（.docx）、Excel（.xlsx/.xls）、图片（EXIF + OCR）、音频（语音转文字）、HTML、CSV / JSON / XML、ZIP、YouTube 字幕、EPUB……几乎涵盖企业日常文档全部类型。

基础用法

1

2

3

4

5

6

7

8

# 安装

pip install 'markitdown[all]'

 

# 命令行转换

markitdown 技术规格.pdf -o 技术规格.md

 

# 管道用法

cat 合同文件.pdf | markitdown > 合同文件.md

在 Codex / Claude Code 工作流中使用

典型场景：需要让 AI 分析一份 PDF 需求文档、读一份 Excel 报表，或参考一个 PPTX 演示文稿时，先用 MarkItDown 转换，再把 Markdown 文件交给 Codex：

1

2

3

# 转换后交给 Codex 分析

markitdown 需求规格.pdf -o 需求规格.md

# 然后在 Codex 中：Read 需求规格.md

Python API（嵌入流水线）

1

2

3

4

from markitdown import MarkItDown

md = MarkItDown()

result = md.convert("技术文档.pdf")

print(result.text_content)  # 直接得到 Markdown 字符串

如需 LLM 辅助图片描述（针对含大量图表的 PDF）：

1

2

3

4

5

6

7

8

from markitdown import MarkItDown

from openai import OpenAI

client = OpenAI(

    api_key="你的 API Key",

    base_url="https://api.qnaigc.com/v1"   # 兼容 OpenAI 协议的接入端点

)

md = MarkItDown(llm_client=client, llm_model="你选用的视觉模型")

result = md.convert("含图表的报告.pdf")

重要限制：MarkItDown 定位是"为 LLM 提取结构"而非"高保真排版还原"——表格、列表、标题会保留，复杂的多栏布局、页眉页脚、背景水印不保证完整还原。如果需要的是像素级排版复现，这不是合适的工具；如果需要的是让 AI 读懂内容，Markdown 文本是更经济的选择。

安全提示：MarkItDown 以当前进程权限执行 I/O，在多租户或服务端场景下需要自行校验输入路径，避免目录穿越；优先用 convert_local() 或 convert_stream() 代替 convert() 以缩小权限范围。

五个方案怎么组合

你的主要痛点 推荐组合
AI 生成了一堆用不上的代码 Ponytail（从决策层减少生成量）
AI 回复太啰嗦，话太多 Caveman 或 token-diet ultra
什么都想省，有稳定自动化流水线 token-diet（全覆盖，31% 账单降幅）
零配置快速上手 claude-token-efficient（一个文件）
需要让 AI 分析 PDF / Word / PPT MarkItDown（文档进入上下文前先转 Markdown）
同时有文档分析 + AI 回复啰嗦两个问题 MarkItDown + Caveman 组合

注意叠加使用：多个 Skills 同时加载会增加输入 token 成本，不是越多越好。建议先单独测试每个方案 1 周，确认在你的工作流里净节省为正，再考虑组合。Ponytail + Caveman 是实测叠加效果最好的 Skills 组合（Ponytail 减少生成量，Caveman 压缩叙述），两者不冲突。MarkItDown 是独立的预处理工具，可以和任何 Skill 叠加，不占 Skills 加载 token。

常见问题

Q：这些 Skills 对 Codex 接 DeepSeek V4-Flash 有效吗？

有效，且效果更明显。DeepSeek V4-Flash 的输出定价（2 元/百万 token）已经很低，但 Agent 模式下多轮调用的累计输出量才是大头——每轮减少 30-54% 输出，乘以调用次数后节省金额显著。输入端的上下文裁剪（token-diet 的 grep-before-read 策略）在 Agent 模式下节省效果同样明显。

Q：CLAUDE.md 文件越多越省钱吗？

不是。CLAUDE.md 文件本身每轮作为输入 token 消耗。文件过大（超过 500 token）时，每轮增加的输入成本可能超过节省的输出成本。claude-token-efficient 的维护者明确测量过：轻量使用场景下，CLAUDE.md 的输入成本是净负。规则文件应尽量简短，只写真正有效的指令。

Q：Ponytail 会不会让 AI 漏掉错误处理？

不会。Ponytail 的决策梯明确豁免了"信任边界验证、数据丢失处理、安全、无障碍"——这些不在 YAGNI 的裁剪范围内。benchmark 的安全性测试项 Ponytail 得分 100%，与无技能基准相同，而 “YAGNI + 一行” 直接提示词版本安全得分是 95%（有 5% 漏掉了安全检查）。

Q：caveman 模式下 AI 还能写正常的代码注释吗？

能。Caveman 只压缩 AI 的对话输出（散文解释），代码本身、命令、错误信息、注释的风格不受影响——除非你明确要求 AI 用穴居人风格写注释（通常没必要）。

Q：MarkItDown 转换的 Markdown 质量怎么样？

适合"让 AI 读懂内容"的场景，不适合"高保真还原排版"。正文文字、表格、列表、标题层级保留良好；复杂多栏布局、内嵌图表的数值（如 Excel 图表的数字）、页眉页脚装饰文字可能丢失或顺序错乱。对于以文字为主的需求文档、合同、报告，转换质量通常足够；数据密集型 Excel 表格建议用 markitdown[xlsx] 单独安装 Excel 依赖，直接把表格数据转成 Markdown 表格，效果比走 PDF 截图更准确。

小结

五个方案的定位各有不同：Ponytail 在生成决策层减少 token，Caveman 和 token-diet 在输出压缩层减少 token，claude-token-efficient 以最低配置成本清理输出废话，MarkItDown 在文档输入层解决 PDF / Office 文件进入上下文时的体积问题——这是其他四个工具都没有覆盖的场景。

实际效果取决于工作流：对话密集型受益最大（Caveman 的 65% 散文压缩），代码生成密集型用 Ponytail 效果显著，需要频繁分析文档的团队用 MarkItDown 在入口处省钱。选对场景，月度 token 账单减少 20%-50% 是可预期的。
版权声明 : 本文内容来源于互联网或用户自行发布贡献，该文观点仅代表原作者本人。本站仅提供信息存储空间服务和不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权， 违法违规的内容， 请发送邮件至2530232025#qq.cn(#换@)举报，一经查实，本站将立刻删除。

您可能感兴趣的文章 :

原文链接 :
相关文章
推荐阅读
最新更新
友情链接
  • 本站所有内容来源于互联网或用户自行发布，本站仅提供信息存储空间服务，不拥有版权，不承担法律责任。如有侵犯您的权益，请您联系站长处理！
  • Copyright © 2017-2022 F11.CN All Rights Reserved. F11站长开发者网 版权所有 | 苏ICP备2022031554号-1 | 51LA统计