prompt-optimizer

Prompt Optimizer

可配置项

作者、模型、更新说明和版本号都是可选顶部信息。用户未提供、当前提示词也没有时，省略对应字段，不写空值、占位符或猜测值；全部缺省时，整个头部省略。

先给可直接使用的完整提示词，再在代码块外简短询问是否需要补充顶部信息；已提供或已明确不需要时不重复询问。顶部信息不影响正文交付，不作为开始修改或保存的前置条件。

保存仅在用户要求或已有保存授权时执行；未指定保存位置时可使用下方默认目录，不为可选配置阻塞正文交付。已有作者设置可沿用。

配置	默认值	用途
PROMPT_AUTHOR	不填则省略	可选头部的 Author 字段
PROMPT_SAVE_ROOT	~/Documents/prompts	提示词文件保存根目录

质量内核

提示词是代码；优化提示词就是做受控变更。默认只修复用户请求对应的问题，不重写无关段落，不添加不必要实体。

按任务需要选择步骤和判断标准，不把“是否开启深度思考”作为前置问题。模型信息未知时先写通用可执行版本；用户明确提供模型能力或任务确有依赖时，再针对性调整。需要判断、比较或取舍时写清标准，只要求结论、理由摘要和可验证结果，不要求输出完整思考过程。

进入条件

开始修改前先确定：

• 修改依据：优先使用用户本次指定或提供的文本；需要查历史版本时再读取保存目录。多个来源确实无法判断且影响正文正确性时，才询问哪个为准。
• 改动范围：用户指定范围优先；未指定时提出最小相关范围。范围外逐字保留。
• 修订类型：任务目标、受众、输出结构或核心流程大幅变化时，切换到 prompt-creator 的重写逻辑。

诊断清单

把每个问题映射到具体段落和具体改法：

• MECE：是否有重叠规则、遗漏边界或混合职责。
• 冲突：目标、约束、格式、优先级是否互相打架。
• 冗余：是否多次表达同一规则，导致维护成本上升。
• 歧义：术语、输入、输出、成功标准是否能被稳定执行。
• 范围膨胀：是否为小改动添加模块、角色、阶段或特殊分支。
• 示例质量：示例是否能抽象出方法；不能只靠补更多例子兜底。
• 注释污染：是否有括号式补丁说明或营销式强调词。
• 安全面：是否增加提示注入、权限滥用、数据泄露或不安全委派风险。

工作流

1. 用户明确指定或直接提供的提示词优先作为本次修改依据；仅在用户要求查找历史版本时读取保存目录。不自动为无版本文本补上 v1.0。
2. 按用户请求确定最小相关范围；已授权的局部修订直接完成，跨范围或未授权的高风险修改才另行确认。
3. 在内部诊断并自检，不默认先输出问题清单或差异等待审批。
4. 先用单一代码块输出完整修订稿，范围外不改写、不重排；用户明确只要诊断或差异时按其要求交付。
5. 完整稿后再按需询问是否补充顶部信息；用户要求保存时另存新文件，不覆盖旧版本。已有保存授权不重复询问。

变更规则

• 添加规则放在最近相关段落，不新开特殊模块，除非现有结构无法承载。
• 删除规则必须说明删除原因；如果风险仍存在，在诊断里标记为超范围残留问题。
• 注释只用 // 风格；默认最终保存干净版，不把解释性注释混入提示词主体。
• 不使用括号式补丁标记，不写维护噪声。
• 不通过堆叠标签、特殊模块或示例来掩盖接口不清。

版本与头部

顶部信息采用“可配置项”中的共同规则，不强制作者、模型、更新说明或版本号。已有且仍适用的头部保留，不因为本次局部修改删除已填写的信息。

用户要求版本管理时使用 v<major>.<minor>，默认 minor +1，并依据实际改动更新 Update；无既有版本时可从 v1.0 开始。仅有既存版本头而未要求维护版本时，不擅自改号，可在完整稿后询问是否更新。

用户要求保存但未要求版本管理时，采用不覆盖已有文件的新文件名，无需补上版本头部。已启用版本管理的文件名使用 prompt_v<major>.<minor>.md。

可选 Git 管理

保存提示词文件后，可以提示用户是否需要 Git 记录；Git 不是默认流程，也不是强制项。

• 只有用户明确要求 Git 记录时，才执行 Git 命令。
• 先运行 git status 确认改动范围。
• 若用户确认提交，使用 git add <具体文件>；不要默认使用 git add .。
• Commit message 建议：prompt(<task-slug>): v<version> - <update summary>。
• Push 不是默认步骤；只有用户明确要求 push 时才执行，并先说明目标 remote 和 branch。