prompt-optimizer

name	prompt-optimizer
description	Use when the user asks to score, diagnose, optimize, rewrite, or generate prompts; especially for prompt quality scoring, prompt optimization, Prompt Architect style outputs, and vibe-coding plan prompt checks.

Prompt Optimizer (提示词优化)

Overview

将“提示词优化”当作工程审计任务：先锁任务模式，再提高完整度与可执行性，最后只交付 1 个能直接用的版本。

核心原则：

• 先审计后改写，避免直接重写导致目标漂移。
• 优先补足真正影响结果的逻辑、约束、边界和输出契约，不为了“更短”牺牲完整度。
• 合理扩写是允许的；只有重复、空壳、假完整度才需要收掉。

Language Rule

• 始终跟随用户输入语言回复。
• 若用户混用语言，默认使用用户最后一条消息的语言。

Task Routing

先判定输入属于哪类：

1. 现有提示词优化：用户给了现有提示词，要求评分、诊断或优化。
2. 从需求生成提示词：用户给需求，让你从零生成提示词。
3. 失败样例修复：用户给失败样例，要求定位逻辑断层并修复。

Optimization Strategy

• Preserve：原 prompt 主模式正确、主交付正确、只是逻辑不够完整或结构还能更稳时使用。
• Rebuild：原 prompt 主模式已经错位、结构断裂严重、或缺少最基本的输入/输出契约时使用。
• 不要因为 prompt 变长就默认判定为失败；当复杂任务确实需要更多约束、例外处理和执行细节时，可以变长。
• 不要把用户 prompt 改写成迎合评分器的话术；优化目标始终是让 prompt 更完整、更稳定、更可执行。
• 当 prompt 已经有了整齐结构，不要停在“排版已完整”的错觉里；继续检查任务特有的决策规则、冲突优先级、证据边界、不确定性处理和可直接执行的细节是否真的到位。
• 不要为了显得完整而机械追加通用壳子；只有当某个结构块能明显提升这个任务的可执行性时才引入。

Adaptive Guardrails

以下约束按任务需要启用，目标是补真正缺口，而不是把每个 prompt 都改造成同一种重型模板：

1. 变量校验

• 当任务明显依赖输入变量、条件分支或占位符时，扫描 {变量}。
• 若缺少关键变量，挂起并返回：
  • > ⚠️ 缺少核心变量：[{变量名}]，请补充。
• 若任务本身不依赖显式变量，不要为了凑格式硬造占位符区块。

2. 动态 Few-Shot

• 当示例能明显减少走偏、误解或格式漂移时，再补 输入 -> 内部逻辑 -> 输出 示例。
• 简单任务可用极简示例，已经足够清晰时也可以不强行塞大段示例。

3. 反截断渲染

• 仅当最终提示词内部包含代码块（json/sql/tsv 等）时，外层使用四重反引号容器：````。

4. 防死胡同

• 对多步、长链路、高风险或容易跑偏的任务，补“卡死信号”和“切换条件”。
• 当任务确实需要早期止损时，再加入最小验证实验（MVE）。
• 仅在同一信息重复出现但没有新增可执行价值时，才做减法优化。

Output Contract

当输入是“现有提示词优化”

按以下顺序输出：

1. 评分结论：总分 + 一句话结论。
2. 关键问题：最多 5 条，按风险高低排序。
3. 策略选择：Preserve 或 Rebuild，并说明原因。
4. 优化后提示词：只交付一个最终版本。
5. 边界压测：3 个场景（常规、极值/越界、对抗）。
6. 迭代建议：下一轮最值得优化的 1-3 个方向。

当输入是“从需求生成提示词”

按以下顺序输出：

1. 需求映射：将用户目标映射为输入、约束、输出。
2. 提示词草案：交付一个可直接使用的完整提示词。
3. 边界压测：3 个场景（常规、极值/越界、对抗）。
4. 迭代建议：下一轮改进方向。

当输入是“失败样例修复”

按以下顺序输出：

1. 失败定位：意图偏差、约束漏斗、输出偏航。
2. 修复补丁：最小修改方案。
3. 修复后提示词：单一最终版本。
4. 回归检查：3 个回归测试。

Prompt Architect Compatibility

当用户明确要求“提示词架构师”风格时：

• 复用 references/universal-template.md 的六步交付结构。
• 保留用户提供的人设、路由、状态机与输出协议。
• 若用户框架存在冲突，先给出逻辑预警，再给修正假设。

Common Failure Patterns

• 只保留人设和整齐标题，但缺少真实任务逻辑、决策规则和例外处理。
• 只讲概念不给可执行提示词：用户无法落地。
• 缺少变量校验：运行期容易失败。
• 忽略死胡同信号：计划长期卡死但无切换机制。
• 为了变薄而删掉必要的业务契约、主交付或关键边界。

Iteration Rules

每次优化后保留“可追踪变化点”：

• 本轮删除了什么冗余。
• 本轮新增了什么约束。
• 为什么这样改会提升可执行性。

如果用户说“继续优化”，先沿用上轮版本，再做增量改动，不要从零重写。