prompt-enhancer

提示词优化 Skill

用途

将用户提示词转换为增强版、可用于生产环境的版本，使其简洁、清晰，并针对 AI Agent 和子 Agent 进行优化。包含减少大模型输出 Token 用量的优化技巧，同时保持语义准确性和向后兼容性。

何时使用此 Skill

在以下情况下使用此 Skill：

• 用户明确要求改进、增强或优化提示词
• 用户发送的提示词含糊、冗长或结构不佳
• 用户提到希望从 AI 交互中获得更好的结果
• 用户请求帮助编写用于 Agent 或自动化的提示词
• 用户的请求缺乏清晰度或恰当的结构
• 用户希望减少大模型输出 Token 用量或 API 成本
• 用户需要优化 JSON schema，以提高 Token 效率
• 用户要求使用紧凑的输出格式，同时保持兼容性

核心原则

1. 简洁：在保留原意的同时，删除不必要的词语
2. 结构：采用清晰的格式，使用多行内容和逻辑分区
3. XML 集成：将自然语言文本与 XML 标签结合，以提高清晰度并便于解析
4. 直接说明任务：主要任务／目标／使命不应放在 XML 元素中
5. 输出整洁：仅返回增强后的提示词，不添加元评论

优化流程

输入分析

• 确定核心目标
• 提取关键要求和约束
• 检测歧义或缺失的信息
• 判断目标 Agent 或使用场景

基于任务选择技巧（可选）

评估任务是否适合使用特定提示技巧：

思维链（CoT）

• 适用于：复杂推理、数学问题、逻辑推导、逐步分析
• 实施方式：添加“逐步思考”或“展示推理过程”的指令

草稿链（Chain-of-Draft）

• 适用于：写作任务、内容创作、迭代优化
• 实施方式：要求先生成初稿，再逐步改进

少样本学习（Few-Shot Learning）

• 适用于：基于模式的任务、特定格式、保持输出一致
• 实施方式：提供 2～3 个输入与输出配对示例

ReAct（推理 + 行动）

• 适用于：使用工具、多步骤任务、决策流程
• 实施方式：将推理过程与行动步骤结合

自一致性（Self-Consistency）

• 适用于：需要验证或存在多种有效方案的任务
• 实施方式：要求生成多个方案，再进行综合

思维树（Tree-of-Thoughts）

• 适用于：复杂问题求解、探索替代方案
• 实施方式：要求先探索多种路径，再选择最佳方案

基于角色的提示（Role-Based Prompting）

• 适用于：特定领域的专业知识、换位思考
• 实施方式：指定专家角色（例如：“以资深工程师的身份行事……”）

由简到繁提示（Least-to-Most Prompting）

• 适用于：将复杂问题拆解为子问题
• 实施方式：从较简单的版本开始，逐步增加复杂度

仅在某种技巧确实能改善任务结果时才使用。

LLM 输出令牌优化

当目标是在保持功能的同时减少输出令牌（API 成本）时：

核心策略：紧凑输出 + 服务端重新映射

LLM 生成超紧凑格式，应用程序将其重新映射为客户端使用的原始格式。这样可以实现：

• 显著节省令牌（30-60%）
• 100% 向后兼容
• 可忽略不计的重新映射开销（<10 微秒）

优化技巧：

1. 超紧凑 JSON 键

• 将较长的键替换为 1-2 个字符的缩写
• 示例：queries → q、keyword → kw、filter → f、sort_by → s
• 每个键节省：70-85%

2. 为重复值使用短代码

• 将较长的 ID/枚举值替换为短代码（c1-c18 等）
• 示例：category=MjUzOTM= → c=c4
• 在应用程序中提供反向映射表
• 类别/枚举值节省：75-90%

3. 结构化数据的字符串压缩

• 尽可能使用紧凑字符串格式替代嵌套对象
• 示例：[{"filter_by":"category","operator":"=","value":"c4"}] → "c=c4"
• 在服务端解析并展开
• 过滤器/查询结构节省：60-80%

4. 省略默认值

• 指示 LLM 省略具有默认值的字段
• 应用程序在重新映射时填入默认值
• 示例：当 "sort_by":"relevant" 为默认值时将其省略
• 当默认值较常见时，可额外节省 10-30%

5. 运算符缩写

• 使用最短形式：使用 p<50000 替代 price<50000
• 在重新映射时解析 p/c 前缀
• 使用分号组合：c=c4;p<50000 表示多个过滤条件

实现模式：

System Prompt Structure:
1. Define ultra-compact schema with examples
2. Specify key mappings (q=queries, kw=keyword, etc.)
3. Provide short codes table (c1=category1, c2=category2, etc.)
4. Show examples of compact output
5. Emphasize: omit defaults when possible

Application Layer:
1. Parse compact LLM output
2. Expand abbreviated keys
3. Map short codes to full values
4. Fill in default values
5. Return original format to client

转换示例：

优化前（原始输出）：

{
  "queries": [
    {"keyword": "milk", "filter": "category=dairy", "sort_by": "relevant"},
    {"keyword": "bread", "filter": "category=bakery", "sort_by": "relevant"}
  ]
}

优化后（LLM 输出，缩短 60%）：

{
  "q": [
    {"kw": "milk", "f": "c=c8"},
    {"kw": "bread", "f": "c=c3"}
  ]
}

**客户端收到：**原始格式（自动重新映射）

权衡分析：

✅ 优点：

• 通常可节省 30-60% 的令牌
• 降低 API 成本
• LLM 响应更快（需要生成的内容更少）
• 100% 向后兼容

⚠️ 缺点：

• 重新映射开销（<10μs，可忽略不计）
• 实现更复杂
• 需要应用程序侧的映射逻辑
• 提示词的可读性略低

适用场景：

• 高调用量 API 使用（>1000 次请求/天）
• 对成本敏感的应用程序
• 输出令牌占总成本的 >50%
• 架构稳定且定义明确
• 应用程序能够处理重新映射逻辑

不适用场景：

• 调用量较低（<100 次请求/天）
• 架构经常变化
• 可读性至关重要
• 没有应用层（LLM 直接连接客户端）

结构改进

• 将复杂请求拆分为清晰的部分
• 使用 XML 标签标记：约束、示例、上下文、格式要求
• 将主要目标/任务写成直接的自然语言
• 合理换行以提高可读性

语言优化

• 用简洁的替代表达替换冗长短语
• 使用主动语态和直接指令
• 删除冗余内容和填充词
• 在缩短篇幅的同时保持具体明确

XML 标签使用指南

使用 XML 标签标记：

• <constraints> - 限制和边界
• <examples> - 输入/输出示例
• <context> - 背景信息
• <format> - 输出结构要求
• <requirements> - 需要满足的具体标准
• <guidelines> - 应遵循的最佳实践

不要使用 XML 标签标记：

• 主要目标陈述
• 主要任务描述
• 核心请求或问题

输出格式

仅返回增强后的提示词，并满足以下要求：

• 不要添加对话式开场白
• 不要添加解释或评论
• 不要添加占位文本
• 不要在提示词外加引号
• 不要讨论增强过程

转换示例

之前： “我需要你帮我为一个 Web 应用编写一些代码，让用户能够注册和登录。我希望它安全并采用现代最佳实践，同时还要有漂亮的 UI。也许你可以推荐该用什么框架？”

之后： 为 Web 应用创建安全的身份验证系统，实现用户注册和登录功能。

- 实施现代安全最佳实践 - 包含密码哈希和会话管理 - 设计简洁、易用的界面 - 推荐框架并说明理由 - 代码实现 - 安全注意事项 - 框架选择理由 - UI/UX 指南

---

之前： “你能分析这些数据，告诉我其中有什么有趣的发现吗？如果有助于更好地理解数据，也可以制作一些图表或可视化内容。另外，请告诉我有没有什么趋势或模式。”

之后： 分析提供的数据集，并找出关键洞察、趋势和模式。

- 突出具有统计显著性的发现 - 识别时间趋势和相关性 - 指出异常和离群值 - 发现摘要 - 数据可视化（根据需要制作图表） - 详细的模式分析 - 可执行的建议

---

之前： “我想为我的 SaaS 产品制定最佳定价策略，但不确定该采用月付、年付，还是分层定价？”

之后（应用思维链技术）： 确定 SaaS 产品的最佳定价策略。

考虑因素：月付与年付、分层定价模式、市场定位 逐步思考： 1. 分析目标客户群体及其支付偏好 2. 评估该领域竞争对手的定价模式 3. 计算每种定价方案的单位经济效益 4. 评估对现金流的影响 5. 考虑对客户生命周期价值的影响 - 说明每项建议的理由 - 包含优缺点分析 - 适用时提出 A/B 测试方案

---

之前： “写一篇关于 AI 在医疗保健领域应用的博客文章，要求内容引人入胜且信息丰富。”

之后（应用思维草稿技术）： 撰写一篇引人入胜且信息丰富的博客文章，介绍 AI 在医疗保健领域的应用。

采用迭代式撰写： 1. 制定大纲，列出关键要点和叙事脉络 2. 撰写引言和结论 3. 通过示例展开正文各部分 4. 优化表达的清晰度、行文流畅度和吸引力 - 目标读者：医疗保健专业人士和科技爱好者 - 长度：1200-1500 字 - 包含真实案例和案例研究 - 兼顾技术准确性和易懂性 - 引人入胜的标题 - 在第一段吸引读者 - 清晰的章节标题 - 可执行的要点

实际 Token 优化示例

之前（原始提示词）：

Create JSON queries to search for products. Each query should have a keyword, filter with category, and sort_by field. Return in this format: {"queries":[{"keyword":"milk","filter":"category=dairy","sort_by":"relevance"}]}

之后（Token 优化后的提示词）：

Generate product search JSON queries. Reject dangerous content.

<rules>
- Each query: ≥1 category filter
- Total: ≥3 keywords (no duplicates)
- Use 'ex' for exact brands/attributes
- Default sort: relevant (omit if default)
- Filter: string format "c=c4" or "c=c4;p<50000"
</rules>

<categories>
c1=household, c2=personal care, c3=bakery, c4=fresh food, c5=oils, c6=dry goods, c7=cleaning, c8=dairy
</categories>

<examples>
"milk vinamilk"→{"q":[{"kw":"milk vinamilk","ex":"vinamilk","f":"c=c8","s":"popular"}]}
"rice noodles meat"→{"q":[{"kw":"rice","f":"c=c6"},{"kw":"noodles","f":"c=c6"},{"kw":"meat","f":"c=c4"}]}
"oranges under 50k"→{"q":[{"kw":"oranges","f":"c=c4;p<50000"}]}
</examples>

结果：

• LLM 生成：{"q":[{"kw":"milk","f":"c=c8"}]}（体积缩小 60%）
• 应用重新映射为：{"queries":[{"keyword":"milk","filter":"category=dairy","sort_by":"relevance"}]}
• 客户端收到的原始格式保持不变
• Token 节省：典型的 3-query 响应可节省 60.5%

质量检查清单

返回优化后的提示词之前，请确认：

• ✓ 主要目标清晰明确
• ✓ XML 标签使用恰当（不用于主要任务）
• ✓ 采用多行结构，便于阅读
• ✓ 语言简洁直接
• ✓ 不包含多余说明
• ✓ 保留所有关键要求
• ✓ 内容可执行且完整
• ✓ 若优化 Token：已定义紧凑的架构、映射清晰，并提供示例

实施说明

使用此技能时：

1. 完整阅读用户的提示
2. 找出可改进之处
3. 进行结构和语言上的改进
4. 仅输出改进后的版本
5. 除非缺少至关重要的信息，否则不要请求澄清

改进后的提示应可供用户直接使用，无需进行任何修改。