optimize-prompt-token-efficiency

优化提示词 Token 效率

通过验证循环最大化信息密度，迭代优化提示词 Token 效率。主要目标：在保留面向 AI 消费的提示词（CLAUDE.md、技能、Agent 提示词、规格说明）全部语义内容的前提下，减少 Token 消耗。

概述

本技能通过以下方式将冗长的提示词转换为 Token 高效的版本：

1. 验证优先 - prompt-token-efficiency-verifier 在任何更改之前检查低效之处
2. 优化 - 根据验证器反馈应用有针对性的压缩
3. 重新验证 - 验证压缩是无损的，若仍有问题则迭代（最多 5 次迭代）
4. 输出 - 仅在验证通过后进行原子替换

循环：读取 → 验证 →（若已高效则退出）→ 根据反馈优化 → 重新验证 →（若仍有问题则迭代）→ 输出

关键原则：不要试图一次完成优化。验证器驱动所有更改 - 如果它未发现低效之处，说明提示词已经是 Token 高效的。

工作流

阶段 0：创建任务列表（立即使用任务管理）

创建跟踪工作流各阶段的待办事项。列表反映工作领域，而非固定步骤。

初始待办事项：

- [ ] Input validation
- [ ] Initial verification
- [ ] (Expand: optimization iterations on INEFFICIENCIES_FOUND)
- [ ] Output optimized prompt

阶段 1：输入验证

将“Input validation”待办事项标记为 in_progress。

步骤 1.1：解析参数

从 $ARGUMENTS 中提取文件路径。如果未提供路径，则报错并显示用法说明。

步骤 1.2：验证文件

• 使用 Read 工具检查文件是否存在
• 验证支持的类型：.md、.txt、.yaml、.json
• 如果不支持，报错：“Unsupported file type. Supported: .md, .txt, .yaml, .json”

步骤 1.3：读取并测量原始内容

• 读取文件内容
• 估算 Token 数量：Math.ceil(content.length / 4)（近似值）
• 存储原始内容和 Token 数量以供比较

步骤 1.4：存储元数据

• original_path：源文件路径
• original_content：完整提示词文本
• original_tokens：估算的 Token 数量
• working_path：用于迭代的 /tmp/optimized-efficiency-{timestamp}.{ext}

将“Input validation”待办事项标记为 completed。

阶段 2：初始验证

将“Initial verification”待办事项标记为 in_progress。

步骤 2.1：复制到工作路径

使用 Write 工具将原始内容复制到 working_path（验证需要文件路径）。

步骤 2.2：首先运行验证器

在任何优化之前，通过 Task 工具启动 prompt-token-efficiency-verifier Agent：

• subagent_type："prompt-engineering:prompt-token-efficiency-verifier"
• prompt："Verify prompt token efficiency. File: {working_path}. Check for redundancy, verbose phrasing, filler words, structural inefficiencies, and compression opportunities. Report VERIFIED if already efficient, or INEFFICIENCIES_FOUND with specific details."

步骤 2.3：处理验证器响应

• 如果为“VERIFIED”：将待办事项标记为已完成，直接进入阶段 4（输出），并显示消息：“Prompt is already token-efficient. No changes needed.”
• 如果为“INEFFICIENCIES_FOUND”：将待办事项标记为已完成，保存问题列表，添加“Optimization iteration 1”待办事项并进入阶段 3
• 如果验证器失败或返回意外格式：使用相同参数重试一次。如果重试失败，报告错误：“Verification failed - cannot proceed without verifier.”

步骤 2.4：显示验证器发现

如果发现低效之处，向用户显示摘要并继续：

Verifier found {count} token efficiency issues. Proceeding with optimization...

将“Initial verification”待办事项标记为 completed。

阶段 3：优化循环（由验证器驱动）

将“优化迭代 1”待办标记为 in_progress。

关键原则：所有修复都由验证器反馈驱动。不要独立分析提示词——只修复验证器报告的特定低效之处。

对于从 1 到 5 的每次迭代：

1. 应用验证器反馈中的压缩建议：对于验证器报告中的每处低效，应用建议的压缩。将优化后的版本写入 working_path。

   • 只修复验证器指出的低效之处——不要添加你自己的改进

2. 重新验证：通过 Task 工具启动 prompt-token-efficiency-verifier Agent：

   • subagent_type: "prompt-engineering:prompt-token-efficiency-verifier"
   • prompt: "Verify compression is lossless. Original file: {original_path}. Compressed file: {working_path}. Compare semantic content - check for missing facts, altered meaning, lost emphasis, removed nuance. Report VERIFIED if lossless, or ISSUES_FOUND with specific gaps."

3. 处理响应：

   • 如果为 "VERIFIED"：将待办标记为已完成，退出循环，进入阶段 4
   • 如果为 "ISSUES_FOUND" 且 iteration < 5：将待办标记为已完成，保存新的问题列表，添加“优化迭代 {next}”待办，继续下一次迭代
   • 如果为 "ISSUES_FOUND" 且 iteration = 5：将待办标记为已完成并注明未解决的问题，带警告进入阶段 4
   • 如果验证器失败或返回意外格式：向用户显示错误，使用相同参数重试一次。如果重试失败，带警告进入阶段 4："Verification incomplete - manual review recommended."

压缩技巧

应用这些技巧来修复验证器标记的低效之处：

技巧	描述	之前 → 之后
移除冗余	消除重复的概念	"It is important to note that you should always remember to..." → "Always..."
简洁措辞	替换冗长的构造	"In order to accomplish this task, you will need to..." → "To do this:"
消除填充词	移除模糊限定、修饰语、开场白	"Make sure that you do not forget to include..." → "Include:"
结构优化	合并/重组章节	"First X. After that Y. Then Z." → "Steps: X → Y → Z"
上下文感知缩写	首次提及后缩写术语	"Model Context Protocol server"（×10）→ "MCP server"（首次之后）
密集格式	使用列表、表格、紧凑表示法	散文段落 → 表格、项目符号列表

转换规则：

1. 保留所有语义信息 —— 每个事实、指令、约束和示例都必须保留
2. 保留细微差别和强调 —— 加粗、大写、重复、表示优先级的排序；有意的模糊限定（不确定性是有意义的）
3. 允许重组 —— 如果不丢失优先级信号且能提高密度，可以重新排序、合并章节
4. 格式保留 —— 输出必须与输入格式相同（markdown 保持 markdown）
5. 无缩减目标 —— 保留细微差别的 10% 缩减 > 丢失细微差别的 40% 缩减

避免产生歧义：

• 不要合并具有不同触发条件的条件（"when A, do X; when B, do Y" ≠ "when A/B, do X/Y"）
• 保留明确的指代对象（如果上下文不明确，不要将 "Use Read tool" 缩减为 "Use the tool"）
• 不要扁平化关系（"A requires B, C requires D" ≠ "A, C require B, D"）
• 确保范围清晰（限定语适用于哪些项？）

阶段 4：输出

将“输出优化后的提示词”待办标记为 in_progress。

步骤 4.1：计算指标

• 原始 token 数（来自阶段 1）
• 压缩后 token 数：Math.ceil(compressed_content.length / 4)
• 缩减百分比：((original - compressed) / original * 100).toFixed(0)

步骤 4.2：应用更改（原子替换）

如果验证通过：

# Replace original atomically
mv {working_path} {original_path}

步骤 4.3：显示结果

如果验证通过：

Optimized: {path}
Iterations: {count}
Original:  {original_tokens} tokens
Optimized: {compressed_tokens} tokens
Reduction: {percentage}%

Changes applied:
- {summary of compressions}

Status: Token-efficient and lossless

如果 5 次迭代后验证失败：

Optimized with warnings: {path}
Iterations: 5
Original:  {original_tokens} tokens
Optimized: {compressed_tokens} tokens
Reduction: {percentage}%

Unresolved issues:
- {list from last verification}

Review the changes manually.

将“输出优化后的提示词”待办标记为 completed。将所有待办标记为完成。

核心原则

原则	规则
验证优先	任何优化前始终先运行验证器；也许提示词已经足够高效
验证器驱动	只修复验证器识别出的低效之处 - 不做独立分析或改进
跟踪进度	使用任务管理跟踪各阶段；在迭代时扩展任务
无损性	绝不为了密度牺牲语义信息；每条事实都必须保留
保留细微之处	保留强调、有意的模糊措辞、优先级信号；带细微之处的 10% 优于不带细微之处的 40%
无歧义	压缩后必须与原始内容一样无歧义
必须验证	未经验证器检查绝不输出
原子输出	验证通过前原始内容保持不变

边缘情况

场景	处理方式
未提供输入	错误：“Usage: /optimize-prompt-token-efficiency ”
文件未找到	错误：“File not found: {path}”
不支持的类型	错误：“Unsupported file type. Supported: .md, .txt, .yaml, .json”
已经足够高效	验证器在首次检查时返回 VERIFIED → 报告：“Prompt is already token-efficient. No changes needed.”
初始验证失败	重试一次；如果仍然失败，错误：“Verification failed - cannot proceed without verifier.”
重新验证失败	显示错误，重试一次；如果重试失败，带警告输出
YAML/JSON 结构	保持结构有效性，仅压缩字符串值
超大文件（>50KB）	作为单个单元处理
0-10% 缩减	成功：“Content was already near-optimal density”
验证失败 5 次	带警告输出最佳尝试

示例用法

# Optimize a verbose CLAUDE.md
/optimize-prompt-token-efficiency CLAUDE.md

# Optimize a skill file
/optimize-prompt-token-efficiency claude-plugins/my-plugin/skills/my-skill/SKILL.md

# Optimize an agent prompt
/optimize-prompt-token-efficiency agents/code-reviewer.md

示例输出

Optimized: docs/README.md
Iterations: 2
Original:  4,250 tokens
Optimized: 3,612 tokens
Reduction: 15%

Changes applied:
- Removed redundant intro section
- Consolidated overlapping examples
- Tersified verbose instructions
- Preserved emphasis markers and conditional logic

Status: Token-efficient and lossless

Prompt is already token-efficient. No changes needed.
Original: 1,995 tokens