메뉴
当用户明确要求"优化 prompt"、"改进提示词"、"润色指令"或"将简陋 prompt 转换为最佳实践版本"时使用。基于 OpenAI 和 Anthropic 官方最佳实践，对用户提供的简陋 prompt 进行结构化优化，输出符合社区标准的高质量版本。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | better-prompt |
| description | 当用户明确要求"优化 prompt"、"改进提示词"、"润色指令"或"将简陋 prompt 转换为最佳实践版本"时使用。基于 OpenAI 和 Anthropic 官方最佳实践，对用户提供的简陋 prompt 进行结构化优化，输出符合社区标准的高质量版本。 |
| metadata | {"author":"Bensz Conan","keywords":["better-prompt","prompt optimization","prompt engineering","提示词优化"]} |
本 Skill 的新任务中间文件统一写入 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/。同一任务复用一个任务根目录；多 Skill 协作才创建 shared/。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。
bensz-collect-bugs 规范记录到 ~/.bensz-skills/bugs/，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。gh 上传新增 bug 到 huangwb8/bensz-bugs；不要 pull / clone 整个仓库。将简陋的 prompt 优化为符合社区最佳实践的高质量版本。
以下情况不建议使用本技能：
用户提供一个待优化的原始 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。
验证用户输入的有效性：
| 输入状态 | 判断标准 | 处理方式 |
|---|---|---|
| 空输入 | 字符数 = 0 | 拒绝，提示"请提供待优化的 prompt" |
| 过短 | 字符数 < 10 | 提示"prompt 过短，请提供更多上下文" |
| 已完善 | 评分 ≥ 8/10 | 提示"prompt 已足够完善，是否仍需优化？"，等待用户确认 |
| 有效 | 通过验证 | 继续 Step 1 |
识别 prompt 的：
根据任务特性判断目标模型类型：
| 模型类型 | 适用场景 | 优化策略 |
|---|---|---|
| GPT 模型 | 精确执行、格式化输出、代码生成 | 提供详细步骤和明确逻辑 |
| 推理模型 | 复杂推理、多步规划、开放性任务 | 给高层目标，保留灵活性 |
如果用户未指定，默认按 GPT 模型优化策略处理（更精确）。
以下是优化后 prompt 的标准结构模板：
# Identity（身份定义）
[描述 AI 的角色、专业领域、沟通风格]
# Instructions（核心指令）
[明确的任务说明]
- 规则 1
- 规则 2
- 约束条件（不做什么）
# Examples（示例）
<example id="1">
<input>示例输入</input>
<output>示例输出</output>
</example>
# Context（上下文）
[任务相关的背景信息、参考资料]
Examples 的使用规则：
- 对于复杂任务（复杂度 ≥ 3/5），Examples 是必需的
- 对于简单任务，Examples 可以省略
- 如原始 prompt 已有示例，优化时应保留或增强
输出包含三个部分（默认全部包含，可通过 config.yaml 调整）：
## 优化分析
| 维度 | 原始状态 | 优化措施 |
|------|---------|---------|
| 清晰度 | ... | ... |
| 完整性 | ... | ... |
| 结构化 | ... | ... |
| 示例性 | ... | ... |
| 约束性 | ... | ... |
## 优化后的 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 配置，针对不同场景有特定的优化重点：
配置引用：config.yaml:templates.code_generation.focus_areas
额外关注：
配置引用：config.yaml:templates.text_analysis.focus_areas
额外关注：
配置引用：config.yaml:templates.creative_writing.focus_areas
额外关注：
配置引用：config.yaml:templates.multi_turn_conversation.focus_areas
额外关注：
更多详细的最佳实践，参考 references/prompt-engineering-best-practices.md
根据用户描述生成高质量绘图 prompt，并按通用、roadmap、schematic 模式调用 gpt-image-2 或 Nano Banana/Gemini 图片模型 API；gpt-image-2 默认使用低画质、原生尺寸和 JPEG，第 2 轮起基于上一轮图片做保真微调。
当用户明确要求"测试代码"、"运行代码审查"或"进行代码自检"时使用。通过多轮 A 轮批判性代码审查 + B 轮代码质量原则检查，系统化发现、记录、修复程序代码中的问题，并将计划/过程/结果统一沉淀到目标代码根目录的 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/` 隔离工作区。⚠️ 不适用：用户只是想优化功能（应直接修改）、只是询问代码问题（应直接回答）、没有明确"测试代码"意图。
当用户明确要求"测试项目"、"运行 auto-test-project"或"进行项目级测试"时使用。对完整项目进行多轮 A 轮批判性测试 + B 轮质量检查，系统化发现、记录、修复问题。⚠️ 不适用：用户只是想优化功能（应直接修改）、只是询问项目问题（应直接回答）、没有明确"测试"意图。
当用户明确要求"测试技能"、"运行 auto-test"或"进行批判性测试"时使用。通过多轮 A 轮批判性测试 + B 轮质量原则检查，系统化发现、记录、修复问题，并沉淀可追溯的 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-skill/output/plans/` 与 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-skill/output/tests/` 文档。⚠️ 不适用：用户只是想优化功能（应直接修改）、只是询问技能问题（应直接回答）、没有明确"测试"意图。
后端开发专家。精通 Node.js/Python/Go/Rust 等后端技术栈，专注于 API 设计、数据库优化、认证授权、微服务架构和性能调优。用于后端服务开发、API 设计和系统架构。
当用户明确要求"使用 brainstorming"或"使用 awesome-code"时使用。⚠️ 不适用：用户只是想优化/改进某个功能（应直接修改）、只是询问技能问题（应直接回答）、没有明确使用 brainstorming/awesome-code 的一般性开发。