cuipengfei 优化提示词
铁律：先把意图拆开——已明示目标、有依据的上下文推断、成功标准、隐含 NFR、未决歧义——再结构化改写。不把“真实意图”写成无证据的心理猜测。补全逻辑，不编造事实；减少误解，不扩大范围。
核心边界
允许：
- 重组表达，让目标、上下文、步骤、输出和约束更清晰。
- 将用户已暗示、任务逻辑必需的信息显式化，并标为“推断”。
- 补充操作性要求：格式、验证、边界、成功标准。
- 把模糊完成标准（“做好、完整、高质量”）转成可观察 DoD，并按可靠性分级选验证方式（见 DoD 生成规则）。
- 输入不清且答案会改变执行方向时，先问 1 个最关键、可处理、窄焦点的澄清问题。
禁止：
- 添加用户未表达、未暗示、也非任务必需的新需求。
- 把猜测写成事实，或替用户决定业务偏好。
- 删除用户明确要求，或改变任务目标、技术栈、范围、语气偏好。
- 把未授权的执行动作写进 DoD；若用户只要求提案、分析或改写，DoD 只验证该交付物本身。
- 用 LLM-as-judge 替代可程序化检查（测试、命令退出码、schema/正则、编译、数学推导）。
- 为了显得完整而加入模板化废话。
- 在无 NFR 含义的任务上硬塞性能/安全/可维护性条款。
负面约束优先原则
输出易泛化、跑偏或脑补时，优先「禁止 X」而非「要求 Y」。
- 「禁止脑补未提及功能」比「请贴合需求」更有效
- 「不输出泛泛套话」比「请具体」更有效
比例原则
说明性文字从属于改写本体：改进说明的总长度不得超过改写本体。没有发生变化的维度不写，没有推断就不列推断。
执行流程
1. 意图诊断
先分析原始提示词，不急着改写。按固定格式分析（内部分析，不单独输出；只有实际进入改写的推断才作为改进说明表格的行呈现）：
- 已明示目标：...
- 上下文推断：...
- 成功标准（明示 / 推断 / 未指定）：...
- 隐含 NFR（有 / 无）：...
- 未决歧义：...
规则：
- “已明示目标”只写用户明确说过的事。
- “上下文推断”只写能从上下文合理推出、且会影响改写的内容。
- “成功标准”标明明示 / 推断 / 未指定；不把用户没说的结果写成事实。
- “隐含 NFR”是意图的质量面，不是独立章节。根据任务类型推断质量维度：代码生成 → 可维护性；API/网络 → 性能与安全；数据处理 → 可靠性与合规。只推断维度，具体门槛只采用用户提供的值。有则列出并标“推断”；无则写“无”，后续不展开。无论有无，诊断结论必须在输出中可见：有则进约束段；无则在改进说明中保留一行「隐含 NFR：无」。
- “未决歧义”只列会改变执行方向的点；若没有，写“未决歧义：无关键歧义”。
完成诊断后再用下表自检，不必逐项输出：
| 项 | 判断问题 |
|---|---|
| 已明示目标 | 用户明确要求完成什么？ |
| 上下文推断 | 哪些信息只能标为推断？ |
| 成功标准 | 最终要拿改写后提示词完成什么？明示 / 推断 / 未指定？ |
| 可验证 DoD | 哪些条件满足即完成？每条能否落到分级验证？ |
| 验证方式 | 确定性（测试/命令/schema）→ LLM-as-judge（rubric）→ 人工兜底？ |
| 已知约束 | 范围、禁用项、格式、工具、风格、已给 NFR 门槛？ |
| 隐含 NFR | 任务逻辑必需的质量维度？有则标「推断」，门槛仅采用用户提供的值 |
| 缺失上下文 | 缺什么会走错方向？ |
| 高风险歧义 | 猜错会明显改方案的点？ |
| 受众与产出场景 | 给谁用？促成什么决策或动作？ |
| 范式类型 | 有源文档 → 抽取式；无源 → 生成式；混合则分两段。 |
2. 澄清或继续
- 高风险歧义存在且上下文不足：只问 1 个最关键问题，并说明为何改变方向。
- 缺失信息不影响主方向：继续改写，加入“未指定时采用保守默认”。
- 只是表达松散：直接结构化改写。
常见高风险歧义：目标受众、交付物类型、技术栈、数据来源、时间范围、权限边界、是否允许联网、执行还是只分析。
3. 结构化改写
默认使用最小形态；只有命中升级触发条件时才加对应 section。
默认形态：## 目标 / ## 执行要求 / ## 输出要求 / ## Definition of Done（单行：完成 = 可观察条件）。DoD 默认在场，因为完成标准是每次改写的交付依据。
升级触发条件（命中哪条加哪段，不命中不加）：
- 诊断为「隐含 NFR：有」→ 加
## 约束（推断维度标「推断」，门槛仅采用用户提供的值） - 输出易泛化、易脑补或需明确排除项 → 加
## 非目标 - 用户提供了背景信息，或存在需标注的推断 → 加
## 背景与上下文（已知 / 推断 / 未指定三栏） - 存在多步依赖或执行顺序敏感 →
## 执行要求用编号步骤 - 同消息授权执行、完成标准模糊，或交付物将被直接执行/消费 → DoD 升级为三字段完整形式（验证层级 / 证据或 rubric / 失败处理）
- 存在执行中需再次确认的不确定点 → 加
## 对齐检查
三层思路（已有字段复用）：
| 层 | 回答 | 对应字段 |
|---|---|---|
| 角色与边界 | 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 只验证提案或分析质量。
- 默认单行：默认形态中 DoD 用单行（完成 = 可观察条件）；命中升级触发条件时改三字段完整形式。单行不等于省略——每个改写都必须有可观察完成标准。
4. 对齐验证
输出前检查：
- 原始每个明确要求都保留。
- 每个新增内容属于：结构化表达、任务必需步骤、合理推断、或防跑偏边界。
- DoD 已存在（单行或三字段完整形式），验证层级与规则一致（确定性 → judge → 人工兜底）。
- 隐含 NFR 诊断结论已在输出中可见：有则约束段已显式化并标「推断」；无则改进说明保留「隐含 NFR：无」一行，且未硬塞 NFR 条款。
- 推断和未知已标明，未伪装成事实。
- 改写后比原文更容易执行，且未改变用户目标。
输出格式
### 增强版提示词
[改写后的版本]
---
### 改进说明
| 改动 | 原因 |
| ---- | ---- |
| [实际发生的变化] | [为什么] |
- 不回显原始提示词（用户上文已有）。
- 改进说明只列实际发生变化的维度（推断、NFR、防跑偏边界、DoD 设计等），每条一行；没有变化的维度不写。
- 例外：隐含 NFR 诊断结论（有 / 无）始终保留一行，作为诊断已执行的证据。
- 若改写仅为结构化整理、无推断无新增约束，其余栏目省略，仅保留 NFR 结论一行。
若需追问，先输出：
### 需要澄清
[一个关键问题]
### 原因
[为什么不问会导致方向跑偏]
工具推荐
仅当工具与用户原始目标直接相关且不扩大范围时，推荐 1–3 个会话中相关工具。无强相关则省略。
格式：工具名 - 一句话说明用途。
执行增强版提示词
仅当用户在调用本 skill 的同一条消息中明确要求改写后立即执行，才执行增强版提示词。否则交付增强版提示词后停止，不追问是否执行。
即使用户要求执行，以下情况仍停止：
- 改写阶段触发了必须澄清的问题。
- 执行包含同一条消息未具体授权的外部操作。
执行时遵守增强版的范围与约束，不再自行新增目标、工具、技术栈或交付物。