improve-prompt

name	improve-prompt
description	当用户要求改写、增强或澄清提示词时使用。触发短语包括「改写提示词」「优化 prompt」「improve prompt」「补 DoD」「提示词不完整」「让提示词可执行」。在意图、约束、范围、输出格式、非功能要求（NFR）或 Definition of Done 不清晰时激活。

优化提示词

铁律：先把意图拆开——已明示目标、有依据的上下文推断、成功标准、隐含 NFR、未决歧义——再结构化改写。不把“真实意图”写成无证据的心理猜测。补全逻辑，不编造事实；减少误解，不扩大范围。

核心边界

允许：

• 重组表达，让目标、上下文、步骤、输出和约束更清晰。
• 将用户已暗示、任务逻辑必需的信息显式化，并标为“推断”。
• 补充操作性要求：格式、验证、边界、成功标准。
• 把模糊完成标准（“做好、完整、高质量”）转成可观察 DoD，并按可靠性分级选验证方式（见 DoD 生成规则）。
• 输入不清且答案会改变执行方向时，先问 1 个最关键、可处理、窄焦点的澄清问题。

禁止：

• 添加用户未表达、未暗示、也非任务必需的新需求。
• 把猜测写成事实，或替用户决定业务偏好。
• 删除用户明确要求，或改变任务目标、技术栈、范围、语气偏好。
• 把未授权的执行动作写进 DoD；若用户只要求提案、分析或改写，DoD 只验证该交付物本身。
• 用 LLM-as-judge 替代可程序化检查（测试、命令退出码、schema/正则、编译、数学推导）。
• 为了显得完整而加入模板化废话。
• 在无 NFR 含义的任务上硬塞性能/安全/可维护性条款。

负面约束优先原则

输出易泛化、跑偏或脑补时，优先「禁止 X」而非「要求 Y」。

• 「禁止脑补未提及功能」比「请贴合需求」更有效
• 「不输出泛泛套话」比「请具体」更有效

执行流程

1. 意图诊断

先分析原始提示词，不急着改写。按固定格式分析（内部分析，不单独输出；最终在改进说明 → 意图理解中呈现）：

• 已明示目标：...
• 上下文推断：...
• 成功标准（明示 / 推断 / 未指定）：...
• 隐含 NFR（有 / 无）：...
• 未决歧义：...

规则：

• “已明示目标”只写用户明确说过的事。
• “上下文推断”只写能从上下文合理推出、且会影响改写的内容。
• “成功标准”标明明示 / 推断 / 未指定；不把用户没说的结果写成事实。
• “隐含 NFR”是意图的质量面，不是独立章节。根据任务类型推断质量维度：代码生成 → 可维护性；API/网络 → 性能与安全；数据处理 → 可靠性与合规。只推断维度，具体门槛只采用用户提供的值。有则列出并标“推断”；无则写“无”，后续不展开。
• “未决歧义”只列会改变执行方向的点；若没有，写“未决歧义：无关键歧义”。

完成诊断后再用下表自检，不必逐项输出：

项	判断问题
已明示目标	用户明确要求完成什么？
上下文推断	哪些信息只能标为推断？
成功标准	最终要拿改写后提示词完成什么？明示 / 推断 / 未指定？
可验证 DoD	哪些条件满足即完成？每条能否落到分级验证？
验证方式	确定性（测试/命令/schema）→ LLM-as-judge（rubric）→ 人工兜底？
已知约束	范围、禁用项、格式、工具、风格、已给 NFR 门槛？
隐含 NFR	任务逻辑必需的质量维度？有则标「推断」，门槛仅采用用户提供的值
缺失上下文	缺什么会走错方向？
高风险歧义	猜错会明显改方案的点？
受众与产出场景	给谁用？促成什么决策或动作？
范式类型	有源文档 → 抽取式；无源 → 生成式；混合则分两段。

2. 澄清或继续

• 高风险歧义存在且上下文不足：只问 1 个最关键问题，并说明为何改变方向。
• 缺失信息不影响主方向：继续改写，加入“未指定时采用保守默认”。
• 只是表达松散：直接结构化改写。

常见高风险歧义：目标受众、交付物类型、技术栈、数据来源、时间范围、权限边界、是否允许联网、执行还是只分析。

3. 结构化改写

按任务裁剪结构，不必机械保留所有标题。三层思路（已有字段复用）：

层	回答	对应字段
角色与边界	AI 是谁？不能碰什么？	约束 + 背景推断标注
格式与标准	输出长什么样？	输出要求 + 执行要求
目标与受众	给谁用？达成什么？	目标 + 受众

简单任务可省第一层；目标与受众至少有一。

## 目标

[一句话说明用户真实目标]

## 背景与上下文

- 已知：[用户明确提供的信息]
- 推断：[从上下文合理推出的信息]
- 未指定：[会影响细节但不阻塞执行的信息]

## 执行要求

1. [步骤]
2. [步骤]

## 输出要求

- [格式、粒度、语言、长度、证据要求]

## Definition of Done

任务完成必须同时满足：

1. [完成条件]
   - 验证层级：确定性 | LLM-as-judge | 人工兜底
   - 证据或 rubric：[命令/测试/schema 输出；或二元/三级 rubric 锚点；或人工检查点]
   - 失败处理：[不满足时怎么报告或继续]
2. [完成条件]
   - 验证层级：...
   - 证据或 rubric：...
   - 失败处理：...

## 约束

- 必须：[用户明确要求；推断 NFR 维度（标「推断」），门槛仅采用用户提供的值]
- 禁止：[用户明确禁止或为防跑偏必须限制的行为]

## 非目标

- [明确不做什么，避免 DoD 扩范围]

## 对齐检查

- 若遇到 [关键不确定点]，先提问；否则按 [保守默认] 执行。

Definition of Done 生成规则

• 每条 DoD 必须可观察：禁止只写“高质量、完善、合理、足够好”。
• 每条 DoD 按可靠性分级绑定验证（高 → 低）：
  • 确定性（优先）：测试通过、命令退出码、schema/正则、数学推导、编译检查。能程序判定的，禁止交给 LLM。
  • LLM-as-judge：仅当无法确定性验证（语义准确性、语气、解释质量、品牌一致性）。须二元 pass/fail 或三级 rubric 与锚点（如 pass: 全部事实可追溯 / partial: 大部分可追溯 / fail: 存在无来源声明）。禁止模糊形容词。
  • 人工兜底：仅当前两种都不适用时使用，写明人工检查点。
• 最小足够：只写判定完成所必需的条件。
• 不越权：用户说 propose only / 只分析 / 不要执行时，DoD 只验证提案或分析质量。

4. 对齐验证

输出前检查：

• 原始每个明确要求都保留。
• 每个新增内容属于：结构化表达、任务必需步骤、合理推断、或防跑偏边界。
• DoD 验证层级与模板一致（确定性 → judge → 人工兜底）。
• 若诊断为「隐含 NFR：有」，约束或 DoD 中已显式化并标“推断”；若为「无」，未硬塞 NFR 条款。
• 推断和未知已标明，未伪装成事实。
• 改写后比原文更容易执行，且未改变用户目标。

输出格式

### 原始提示词

[用户原文]

---

### 增强版提示词

[改写后的版本]

---

### 改进说明

- 意图理解：[复述诊断五要素：已明示目标、上下文推断、成功标准、隐含 NFR、未决歧义]
- 真实意图：[识别到的核心目标]
- 缺口处理：[补了哪些必要上下文；哪些仍标未指定]
- 推断边界：[哪些是推断，为何合理]
- 防跑偏约束：[新增了哪些边界]
- DoD 设计：[完成条件；各条验证层级]
- 验证边界：[确定性 / judge+rubric / 人工兜底]
- 保持不变：[确认未扩展范围]

若需追问，先输出：

### 需要澄清

[一个关键问题]

### 原因

[为什么不问会导致方向跑偏]

工具推荐

仅当工具与用户原始目标直接相关且不扩大范围时，推荐 1–3 个会话中相关工具。无强相关则省略。

格式：工具名 - 一句话说明用途。

执行增强版提示词

仅当用户在调用本 skill 的同一条消息中明确要求改写后立即执行，才执行增强版提示词。否则交付增强版提示词后停止，不追问是否执行。

即使用户要求执行，以下情况仍停止：

• 改写阶段触发了必须澄清的问题。
• 执行包含同一条消息未具体授权的外部操作。

执行时遵守增强版的范围与约束，不再自行新增目标、工具、技术栈或交付物。