better-prompt
Better Prompt - Prompt 优化器
与 bensz-collect-bugs 的协作约定
- 因本 skill 设计缺陷导致的 bug,先用
bensz-collect-bugs规范记录到~/.bensz-skills/bugs/,不要直接修改用户本地已安装的 skill 源码;若有 workaround,先记 bug,再继续完成任务。 - 只有用户明确要求“report bensz skills bugs”等公开上报时,才用本地
gh上传新增 bug 到huangwb8/bensz-bugs;不要 pull / clone 整个仓库。
将简陋的 prompt 优化为符合社区最佳实践的高质量版本。
版本与兼容性
- 适用于:Claude 3.x/4.x、GPT-4/5、Gemini 等主流 LLM
- 最佳实践来源:OpenAI/Anthropic 官方文档(2026-02)
- 更新策略:官方文档重大更新时同步修订
不适用场景
以下情况不建议使用本技能:
- prompt 已经经过专业优化(评分 ≥ 8/10)
- 只需要诊断问题,不需要修改建议
- 超长 prompt(>10000 字)需要专业拆分
- 用户明确要求保持原始风格
输入要求
用户提供一个待优化的原始 prompt(可以是任意形式的简陋版本)。
优化框架
基于 OpenAI 和 Anthropic 官方最佳实践,采用五维度优化框架:
| 维度 | 检查点 | 优先级 |
|---|---|---|
| 清晰度 | 指令是否明确?是否存在歧义? | P0 |
| 完整性 | 是否缺少必要信息?上下文是否充分? | P0 |
| 结构化 | 是否使用 Markdown/XML 标签组织内容? | P1 |
| 示例性 | 是否提供输入输出示例(few-shot)? | P2 |
| 约束性 | 是否明确边界(做什么/不做什么)? | P2 |
注意:上表的 P0/P1/P2 表示"优化维度的重要性优先级",与 config.yaml 中的
dimensions数值(1-5)含义相同:P0=5(最高优先级)、P1=4、P2=3。
优化工作流
Step 0: 输入验证(前置检查)
验证用户输入的有效性:
| 输入状态 | 判断标准 | 处理方式 |
|---|---|---|
| 空输入 | 字符数 = 0 | 拒绝,提示"请提供待优化的 prompt" |
| 过短 | 字符数 < 10 | 提示"prompt 过短,请提供更多上下文" |
| 已完善 | 评分 ≥ 8/10 | 提示"prompt 已足够完善,是否仍需优化?",等待用户确认 |
| 有效 | 通过验证 | 继续 Step 1 |
Step 1: 分析原始 prompt
识别 prompt 的:
- 核心任务:用户想让 AI 做什么?
- 缺失要素:哪些关键信息缺失?
- 改进空间:哪些地方可以优化?
Step 2: 确定模型类型适配
根据任务特性判断目标模型类型:
| 模型类型 | 适用场景 | 优化策略 |
|---|---|---|
| GPT 模型 | 精确执行、格式化输出、代码生成 | 提供详细步骤和明确逻辑 |
| 推理模型 | 复杂推理、多步规划、开放性任务 | 给高层目标,保留灵活性 |
如果用户未指定,默认按 GPT 模型优化策略处理(更精确)。
Step 3: 应用优化模板
以下是优化后 prompt 的标准结构模板:
# Identity(身份定义)
[描述 AI 的角色、专业领域、沟通风格]
# Instructions(核心指令)
[明确的任务说明]
- 规则 1
- 规则 2
- 约束条件(不做什么)
# Examples(示例)
<example id="1">
<input>示例输入</input>
<output>示例输出</output>
</example>
# Context(上下文)
[任务相关的背景信息、参考资料]
Examples 的使用规则:
- 对于复杂任务(复杂度 ≥ 3/5),Examples 是必需的
- 对于简单任务,Examples 可以省略
- 如原始 prompt 已有示例,优化时应保留或增强
Step 4: 输出优化结果
输出包含三个部分(默认全部包含,可通过 config.yaml 调整):
- 优化分析:简要说明做了哪些改进
- 优化后的 prompt:符合最佳实践的高质量版本
- 使用建议:针对特定场景的调整建议
输出格式
## 优化分析
| 维度 | 原始状态 | 优化措施 |
|------|---------|---------|
| 清晰度 | ... | ... |
| 完整性 | ... | ... |
| 结构化 | ... | ... |
| 示例性 | ... | ... |
| 约束性 | ... | ... |
## 优化后的 Prompt
# Identity
...
# Instructions
...
# Examples(如适用)
...
# Context(如适用)
...
## 使用建议
- 适用于:[模型类型/场景]
- 调整建议:[如需针对特定场景调整的建议]
优化效果评估
对优化前后的 prompt 进行对比评估:
| 维度 | 优化前评分 | 优化后评分 | 改进说明 |
|---|---|---|---|
| 清晰度 | x/5 | x/5 | ... |
| 完整性 | x/5 | x/5 | ... |
| 结构化 | x/5 | x/5 | ... |
| 示例性 | x/5 | x/5 | ... |
| 约束性 | x/5 | x/5 | ... |
| 总分 | xx/25 | xx/25 | +xx |
评分标准:1=很差、2=较差、3=一般、4=良好、5=优秀
质量标准
优化后的 prompt 必须满足:
| 标准 | 要求 |
|---|---|
| 明确性 | 核心任务一句话能说清 |
| 可执行性 | AI 能直接理解并执行 |
| 完整性 | 不缺少必要信息 |
| 结构化 | 使用 Markdown/XML 清晰组织 |
| 可测试性 | 能判断输出是否符合预期 |
特殊场景处理
根据 config.yaml 中的 templates 配置,针对不同场景有特定的优化重点:
代码生成类 prompt
配置引用:config.yaml:templates.code_generation.focus_areas
额外关注:
- 明确编程语言和框架
- 指定代码风格规范
- 说明错误处理要求
- 提供边界条件示例
文本分析类 prompt
配置引用:config.yaml:templates.text_analysis.focus_areas
额外关注:
- 明确输出格式(JSON/表格/摘要)
- 定义分析维度和标准
- 提供分类/评估示例
创意写作类 prompt
配置引用:config.yaml:templates.creative_writing.focus_areas
额外关注:
- 定义风格和语调
- 说明目标受众
- 提供参考示例
- 设置长度约束
多轮对话类 prompt
配置引用:config.yaml:templates.multi_turn_conversation.focus_areas
额外关注:
- 定义对话角色和边界
- 说明状态管理要求
- 提供异常处理规则
参考资料
更多详细的最佳实践,参考 references/prompt-engineering-best-practices.md
More from huangwb8/skills
init-project
当用户明确要求"初始化项目"、"创建项目指令文件"或"生成 AGENTS.md"时使用。完全自动化:自动检测操作系统默认语言,分析项目目录结构(支持 Python/Web/Rust/Go/Java/数据科学/文档项目等),推断项目类型和用途,一键生成规范的项目指令文档。生成结果包括:AGENTS.md(跨平台通用项目指令,Single Source of Truth)、CLAUDE.md(Claude Code 特定适配,通过 @./AGENTS.md 引用)、README.md(项目介绍与使用方法)、CHANGELOG.md(项目变更记录)、.gitignore(Git 忽略规则,安全优先),并在完整初始化时自动补齐 `docs/` 与 `docs/plans/`。
9parallel-vibe
当用户明确要求"并行执行同一条 Vibe Coding 指令 / 多线程并行尝试多种方案 / 在多个独立工作区里同时推进"时使用。在用户当前工作目录创建 `.parallel_vibe/`,复制出多个独立工作区并按计划运行每个 thread 的 runner(默认串行、可选并行),最后在 `@main/summary.md` 汇总结果。⚠️ 不适用:用户只是想并行跑 shell 命令/单元测试/下载任务(应直接用并发工具或 CI)、没有明确"多工作区并行尝试/多方案对比"意图、要求强安全隔离或处理高度敏感数据(应使用容器/沙箱方案)。
7auto-test-skill
当用户明确要求"测试技能"、"运行 auto-test"或"进行批判性测试"时使用。通过多轮 A 轮批判性测试 + B 轮质量原则检查,系统化发现、记录、修复问题,并沉淀可追溯的 `plans/` 与 `tests/` 文档。⚠️ 不适用:用户只是想优化功能(应直接修改)、只是询问技能问题(应直接回答)、没有明确"测试"意图。
4auto-test-project
当用户明确要求"测试项目"、"运行 auto-test-project"或"进行项目级测试"时使用。对完整项目进行多轮 A 轮批判性测试 + B 轮质量检查,系统化发现、记录、修复问题。⚠️ 不适用:用户只是想优化功能(应直接修改)、只是询问项目问题(应直接回答)、没有明确"测试"意图。
4git-commit
当用户明确要求"提交 Git 改动"、"生成 commit 信息"或"创建 git commit"时使用。仅用 Git 分析改动并自动生成 conventional commit 信息(可选 emoji);必要时建议拆分提交,默认运行本地 Git 钩子(可 --no-verify 跳过),提交后默认自动 push(可 --no-push 跳过)。
3awesome-code
当用户明确要求"使用 awesome-code / 多代理协作 / 并行协调开发"时使用。通过脚本解析任务,推荐合适的子代理与协作策略,并输出可执行的下一步。⚠️ 不适用:用户仅需单一角色的简单修改或咨询、用户未明确表达多代理协作意图、用户只是了解技能概念。
3