| name | prompt-optimizer |
| description | Systematically optimize user-provided prompts with formal verification at every stage: quantitative 12-dimension scoring (0-5 scale), anti-pattern detection, cross-dimension dependency mapping, formal optimization primitives with pre/post-conditions, counterfactual reasoning, conflict resolution protocol, and regression verification (re-analyze optimized output through the same framework). Each optimization is grounded in explicit logical inference with measurable quality metrics — never arbitrary modification. Supports 12+ domain-specific strategies with composable optimization operations. Triggered by: "优化提示词", "优化prompt", "提示词优化", "prompt优化", "rewrite prompt", "improve prompt", "改进提示词", "prompt改写", "逻辑推断优化", "精准提示词", "领域优化", "优化指令", "prompt engineering", "提示词工程". |
| version | 3.0.0 |
Prompt Optimizer
Purpose
根据用户提供的理论方向(提示词的用途领域/场景)和原始提示词,运用系统的分析框架和提示词工程最佳实践进行优化。每项优化必须有明确的逻辑依据,禁止无据脑补或扭曲原意。优化后的提示词直接返回给用户,附带逐条优化说明(含推理链)。
When to Use
- 用户要求"优化提示词"、"改进prompt"、"重写提示词"、"优化指令"、"提升提示词质量"
- 用户提供了一个提示词,希望提升其质量和效果,且拥有明确的领域/场景上下文
- 用户有明确的领域/场景(如数学解题、代码生成、创意写作、数据分析、角色扮演、客服对话等),需要该领域针对性的提示词优化方案
- 用户希望了解提示词工程最佳实践并应用到自己的提示词编写中
- 用户提供了较为粗糙的初版提示词,需要系统性地分析其缺陷并给出可操作的改进
When NOT to Use
- 用户没有提供原始提示词 —— 必须先要求用户提供,不能凭空生成优化方案
- 用户只要求翻译提示词(不涉及优化) —— 应使用翻译工具而非优化
- 用户要求生成全新的提示词而非优化已有的 —— 这是"生成"行为,超出了优化的范畴
- 用户需求过于模糊,无法确定理论方向和优化目标 —— 应先引导用户明确需求
Workflow / Steps
Step 0: 输入验证与预处理(Input Validation)
在进入解析和分析之前,先对用户输入进行形式化验证。此步骤确保后续所有分析建立在合法、可处理的输入之上,避免"垃圾进垃圾出"。
0a. 输入完整性检查
| 检查项 | 判定标准 | 不通过时的处理 |
|---|
| 非空检查 | 用户消息去除首尾空白后非空 | 提示用户提供输入 |
| 最小长度检查 | 至少包含 10 个有效字符(排除纯符号/表情) | 提示用户提供更完整的输入 |
| 语言识别 | 自动检测输入语言(中文/英文/混合),用于后续风格匹配 | 标注检测结果,Step 3 策略选择时参考 |
| 提示词类型检测 | 判断是 system prompt 还是 user prompt(system prompt 包含角色/规则描述,user prompt 是单次指令) | 标注类型,影响 Step 3 处理策略 |
0b. 输入结构识别
对用户输入进行结构分析,识别以下模式:
| 结构模式 | 识别特征 | 标记 |
|---|
| 单段式 | 仅一段文字,无明确分隔 | structure: monolithic |
| 显式分段 | 使用分隔符(` | 、---、:理论方向、原始提示词:`等)明确分隔理论方向和原始提示词 |
| 隐式混合 | 理论方向与原始提示词混在同一段落中,需推断 | structure: implicit-mixed |
| 多轮对话 | 包含对话历史或多轮指令(如"上一次你说…现在请…") | structure: multi-turn |
| 带参数模板 | 包含占位符(如 [name]、{date}) | structure: parameterized |
对每种结构模式采用不同的解析策略:
explicit-segmented → 直接提取,高置信度
implicit-mixed → 推断提取,标记推断依据
multi-turn → 仅优化最后一轮指令,保留对话上下文
parameterized → 保留所有占位符不变,仅优化非参数部分
0c. 输入质量预检
在进入深度分析前,进行快速预检,标记明显的质量问题:
| 预检项 | 检查方法 | 发现时的标记 |
|---|
| 空提示词 | 提取到的原始提示词部分是否为空或仅含标点 | precheck: empty-prompt → 要求用户提供 |
| 超长提示词 | 原始提示词是否超过 2000 tokens(约 1500 英文词或 3000 中文字) | precheck: overlong → Step 2 重点关注冗余分析和精简约简 |
| 全大写/咆哮体 | 超过 70% 的字符为大写字母或无标点长句 | precheck: shouting → Step 4 中调整为正常语气 |
| 矛盾指令 | 同一提示词内存在相互矛盾的指令(如"详细分析"+"一句话总结") | precheck: contradictory → Step 2 维度关联分析重点标记 |
| 多语言混杂 | 一条指令中无规律切换 2+ 种语言 | precheck: code-switched → Step 4 统一为单一主语言 |
| 无动词指令 | 整段不含任何动作指向(如仅有关键词堆砌) | precheck: no-verb → Step 2 任务明确性维度标记 P0 |
0d. 验证输出
Step 0 完成后,生成一份内部验证摘要(不输出给用户):
[Step 0 验证摘要]
- 完整性:通过
- 结构模式:explicit-segmented
- 语言:中文(简体)
- 提示词类型:user prompt
- 预检结果:overlong, contradictory
- 后续影响:Step 2 重点关注冗余+矛盾,Step 4 关注精简+消解
此摘要作为 Step 1-Step 4 的约束参数传递,确保后续步骤根据预检结果调整行为。
Step 1: 解析与结构化输入
从用户消息中提取两个关键部分,并处理边界情况:
A. 提取理论方向(Domain):
- 识别用户描述的领域/场景关键词,如"物理学概念解答"、"Python 代码审查"、"创意故事写作"、"数据分析报告"、"客服对话"、"角色扮演"
- 如果用户只笼统描述了场景(如"帮我优化这个提示词"),主动询问具体用途领域
- 如果理论方向中包含多个子领域(如"用 Python 做数据分析并生成报告"),分解为复合类型供 Step 3 选择策略时参考
B. 提取原始提示词(Original Prompt):
- 从消息中识别出需要优化的提示词原文
- 如果原始提示词包含多个指令或子任务,标记其结构层次以便后续分析
C. 边界情况处理:
| 情况 | 处理方式 |
|---|
| 只提供了理论方向,未提供原始提示词 | 明确要求用户提供原始提示词,说明没有后者无法执行优化 |
| 只提供了原始提示词,未提供理论方向 | 根据提示词内容推断可能的理论方向,在输出时标注推断依据并请用户确认 |
| 两者的界限不清晰 | 以合理推断进行划分,在输出时向用户说明划分逻辑并请用户确认 |
| 输入为空或过于模糊(如"帮我优化一下") | 说明需要理论方向和原始提示词两部分,引导用户补充完整 |
Step 2: 系统性分析原始提示词
对原始提示词进行多维度系统分析。每项分析结论必须有可引用的文本依据(即从原始提示词中引用具体词句作为分析证据),禁止仅凭主观感受下判断。
分析维度框架(12 维度):
| # | 维度 | 分析子项 | 判断依据示例 |
|---|
| 1 | 角色设定 | ①是否指定了 AI 的角色/身份?②角色是否与任务匹配?③角色描述是否过于空泛? | 包含"你是一位…"类表述 → 有角色设定;仅"请帮我…" → 无角色设定 |
| 2 | 任务明确性 | ①任务目标是否单一且无歧义?②是否有可衡量的成功标准?③是否将多个子任务混在一起? | "分析数据并写报告" → 复合任务需拆分;"帮我看看这个" → 目标模糊 |
| 3 | 上下文完整性 | ①是否提供了任务所需的全部背景信息?②是否假设了 AI 知道某些未提供的信息?③是否有隐含的前提假设需要显式化? | 引用"这个项目"但未定义项目背景 → 上下文缺失 |
| 4 | 输出格式规范 | ①是否指定了输出格式(JSON/Markdown/表格/列表/段落)?②是否指定了输出长度或粒度?③如果有格式要求,是否清晰到可直接解析? | "列出来" → 未指定格式;"输出 JSON 格式,包含 name 和 count 字段" → 格式明确 |
| 5 | 约束条件完备性 | ①是否设定了必要的边界限制(如不能做什么、必须在什么范围内)?②是否遗漏了对输出质量的底线要求?③负面约束(禁止什么)和正面约束(应该怎样)是否平衡? | 无任何限制词 → 约束缺失;"不要超过 200 字" → 有长度约束 |
| 6 | 示例与引导 | ①对于格式/风格敏感的任务,是否提供了示例?②对于复杂任务,是否有输入/输出对作为参考?③示例是否具有代表性且无歧义? | "像这样:输入X→输出Y" → 有示例;只有抽象描述 → 无示例 |
| 7 | 推理引导 | ①对于推理类任务,是否引导了逐步思考?②是否需要添加 chain-of-thought 或分步指令?③是否需要引导多角度分析? | "请逐步分析" → 有推理引导;"回答这个问题" → 无推理引导 |
| 8 | 语言与表达 | ①语言风格是否与使用场景匹配?②是否有歧义表达或模糊措辞?③指令是否以动词开头,简洁明确? | "你可以考虑…" → 语气偏弱;"请生成…" → 语气明确 |
| 9 | 输入数据处理 | ①输入数据的格式和范围是否已说明?②数据量或参数边界是否明确?③是否有对异常输入的防御要求? | "传入一个列表" → 未说明元素类型;"传入正整数 n" → 输入明确 |
| 10 | 前置知识与假设 | ①是否假设 AI 具备特定的领域知识?②需要引用的外部知识是否已提供或可访问?③专业术语是否已定义? | 使用"API endpoint"未解释 → 假设技术背景;定义术语 → 友好 |
| 11 | 安全与伦理边界 | ①提示词是否可能引导生成不安全/不适当的内容?②是否需要添加安全护栏?③是否涉及个人信息或敏感数据? | "如何破解…" → 需安全拦截;涉及客户信息 → 需脱敏说明 |
| 12 | 可迭代性 | ①输出是否便于进一步迭代优化?②是否有后续追问的空间或指引?③输出的结构是否支持自动化后处理? | 结尾无追问指引 → 迭代性弱;"如果还需要调整请告诉我" → 有迭代空间 |
分析方法论:
2a. 逐句标注与缺陷定位
- 逐句标注:对原始提示词的每个句子/短语,标注其在上述维度中的归属类别
- 缺陷定位:对每个标注的片段,判断该片段是否存在改进空间,并引用原文作为证据
2b. 定量评分(0-5 量表)
对每个维度,基于原文证据给出 0-5 分的定量评分。每个分数必须有文本依据,不得凭感觉打分。
通用评分量表:
| 分数 | 含义 | 通用标准 |
|---|
| 0 | 严重缺陷 | 该维度相关要素完全缺失,且缺失将导致输出不可用 |
| 1 | 明显不足 | 有少量要素但严重不完整,无法支撑任务需求 |
| 2 | 较弱 | 有基本要素但存在明显缺口或表达模糊 |
| 3 | 可接受 | 要素基本齐全,但存在可改进空间(粒度、精确度不足) |
| 4 | 良好 | 要素齐全且表达清晰,仅需微调即可达到最佳 |
| 5 | 优秀 | 该维度无需任何修改,已达到理论最优 |
各维度具体评分锚点:
| 维度 | 0 分锚点 | 3 分锚点 | 5 分锚点 |
|---|
| 1 角色设定 | 无任何角色描述 | "你是专家"(有角色但泛化) | "你是拥有 10 年经验的前端架构师,精通 React 和 TypeScript"(领域+经验+技能明确) |
| 2 任务明确性 | 无动作指向或完全歧义 | 有单一清晰任务但无可衡量标准 | 任务明确、子任务拆分清晰、有可验证的成功标准 |
| 3 上下文完整性 | 无任何背景信息 | 提供了基本背景但缺少关键细节 | 背景、范围、限制、假设全部显式化 |
| 4 输出格式 | 完全未指定格式 | 指定了格式类型但细节不足(如"用表格") | 格式类型+字段定义+示例+边界(如"JSON,包含 name:string 和 age:number") |
| 5 约束条件 | 无任何限制 | 有基本约束但覆盖率不足 | 长度+范围+风格+质量+安全约束完备且精确 |
| 6 示例引导 | 无任何示例 | 有 1 个示例但不够典型 | 2-3 个覆盖边界情况的典型示例 |
| 7 推理引导 | 无语推理引导 | 有"逐步思考"但无具体框架 | 推理框架明确(分步指令+每步依据要求+中间输出格式) |
| 8 语言表达 | 严重歧义或错乱 | 表达清晰但存在弱语气或少量歧义 | 动词开头的祈使句、无歧义、术语统一、风格匹配场景 |
| 9 输入数据处理 | 未定义输入 | 定义了输入类型但无边界说明 | 输入类型+格式+边界值+异常处理要求 |
| 10 前置知识 | 大量未定义术语 | 术语使用正确但未给定义 | 术语首次出现时定义、外部引用提供来源 |
| 11 安全伦理 | 缺乏安全防护且任务有风险 | 有基本防护但覆盖不全 | 内容过滤+伦理边界+隐私保护+合规说明完备 |
| 12 可迭代性 | 无迭代空间设计 | 输出结构可二次处理但无指引 | 结构化输出+追问机制+版本标注+迭代建议 |
评分输出格式(内部使用,不出现在用户输出中):
[维度评分]
| 维度 | 分数 | 关键证据 |
|------|------|---------|
| 1 角色设定 | 0 | 原文全文无角色相关词汇 |
| 2 任务明确性 | 3 | "帮我写一个客服回复" — 目标明确但缺成功标准 |
| 3 上下文完整性 | 1 | 未说明客户问题类型、产品信息、公司政策等 |
| ... | ... | ... |
| 总分 | 24/60 | 平均 2.0 — 存在显著优化空间 |
2c. 反模式检测(Anti-Pattern Detection)
对原始提示词进行结构化和语义层面的反模式扫描。反模式是经过验证会导致输出质量下降的常见提示词写法。每个检测到的反模式自动标记为对应等级的缺陷。
反模式目录:
| # | 反模式名称 | 检测规则 | 严重等级 | 对应的维度 | 修复方向 |
|---|
| AP1 | 万能提示词 | 单条指令包含 3+ 个不相关的子任务 | P1 | 维度2 | 拆分为多条独立提示词 |
| AP2 | 假客气 | 包含"请""麻烦""能否""如果可以的话"等过度礼貌用语 3+ 次 | P2 | 维度8 | 简化为直接祈使句 |
| AP3 | 信息过载 | 单句超过 80 词或整段超过 500 词无分段 | P1 | 维度2/4 | 拆分句子,添加结构化格式 |
| AP4 | 假设知识 | 使用"显然""众所周知""不言而喻"等跳过解释 | P1 | 维度10 | 显式化假设或提供定义 |
| AP5 | 冲突约束 | 同时要求"详细"和"简短",或"创新"和"遵循模板" | P0 | 维度5 | 消解矛盾或明确优先级 |
| AP6 | 幽灵输出 | 要求生成模型不可能做到的事情(如"保证 100% 准确""获取实时数据"但未提供工具) | P0 | 维度2/11 | 替换为可行的表述或说明限制 |
| AP7 | 提示词注入漏洞 | 原始提示词中包含未转义的用户输入占位符或直接拼接外部内容 | P0 | 维度11 | 添加输入转义和边界标记 |
| AP8 | 隐式偏见 | 使用带有文化/性别/年龄偏见的假设(如"程序员=男性") | P1 | 维度11 | 中性化表述 |
| AP9 | 过度具体 | 给模型指定了不可能知道的内部细节(如"使用第 3 层的第 5 个神经元") | P1 | 维度10 | 替换为模型可理解的抽象描述 |
| AP10 | 格式幻觉 | 要求输出格式但该格式与任务本质不兼容(如要求"情感分析结果用 JSON 数组,包含角度制和弧度制") | P1 | 维度4 | 校验格式与任务匹配度 |
| AP11 | 雪崩式追问 | 在一条提示词中连续抛出 5+ 个问题,且后面的问题依赖前面未确定的答案 | P0 | 维度2 | 拆分为多轮对话 |
| AP12 | 默认值陷阱 | 未指定参数时依赖模型的默认行为,但默认行为可能在不同版本间变化 | P2 | 维度5/9 | 显式指定期望行为 |
| AP13 | token 陷阱 | 要求输出极短(如"5 字以内")但任务本身需要详细解答 | P0 | 维度5 | 调整约束使任务可完成 |
| AP14 | 角色混淆 | 在 system prompt 和 user prompt 中分别指定了不同角色/规则 | P0 | 维度1 | 统一角色定义 |
检测流程:
- 对每个反模式,逐一扫描原始提示词文本
- 命中的反模式记录其:名称、命中位置(原文引用)、严重等级、关联维度
- 将反模式检测结果合并到维度分析中:如果某维度已通过常规分析发现缺陷,反模式命中作为额外证据;如果某维度常规分析未见缺陷但反模式命中,补充该缺陷
2d. 跨维度依赖分析(Cross-Dimension Dependency Mapping)
提示词的 12 个维度并非独立——某些维度的缺陷会级联影响其他维度,某些优化操作会产生连锁反应。在分析阶段识别这些依赖关系,可避免优化后引入新问题。
依赖矩阵(D = 直接影响,I = 间接影响):
影响→
被影响↓ D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12
D1 角色 - D I I I - I D - - - -
D2 任务 D - D D D D D D D D I D
D3 上下文 I D - D D - I - D D - -
D4 格式 - I I - D D - I - - - D
D5 约束 I D I D - I I I D - D I
D6 示例 - D I D I - I D I - - -
D7 推理 - D - I - - - - - - - -
D8 表达 I D I I I D I - - I - -
D9 输入 - D D D D D - - - - - -
D10 知识 I D D - - - - D - - - -
D11 安全 I I - - D - - I - - - -
D12 迭代 - I - D - - - - - - - -
使用规则:
- 如果维度 X 存在 P0/P1 缺陷,检查其影响的所有维度(行方向),标记为"关注维度"
- 如果维度 X 将要被优化,检查哪些维度会影响 X(列方向),确保上游维度的优化不会破坏 X 的效果
- 例:维度2(任务明确性)存在 P0 缺陷 → 行方向影响 D3/D4/D5/D6/D7/D8/D9/D12,这些维度即使当前评分正常,也要在回归验证中重点检查
2e. 优先级排序
将发现的缺陷按影响程度 × 依赖广度分为三个等级:
- P0 — 阻塞性缺陷:必改问题(如任务目标缺失、关键上下文缺失、格式要求完全未定义、AP 检测命中 P0 级反模式)
- P1 — 重要优化点:建议修改(如角色设定可更精准、约束可更完善)
- P2 — 锦上添花:可选优化(如示例可更丰富、表达可更精炼)
同一维度内不同缺陷可以有不同等级。如果某维度总分 ≤ 2,该维度下所有缺陷自动提升一级(P2→P1, P1→P0)。
分析输出:
将分析结果整理为结构化清单,包含:
## 分析结果
### 已确认的优化点
- P0:[维度] 引用原文 → 问题描述 → 优化方向
- P1:[维度] 引用原文 → 问题描述 → 优化方向
- ...
### 已确认的保留项
- [维度] 引用原文 → 该部分已完善,无需修改
- ...
### 维度覆盖总结
- 已覆盖的维度:[列出已检查的维度编号]
- 缺失但不需要的维度:[如"角色设定不适用于纯工具类提示词,跳过"]
这份分析结果不会直接输出给用户,而是作为 Step 3 和 Step 4 的内部决策依据。在 Step 6 输出时,从中提取最重要的优化点写入优化说明。
Step 3: 根据理论方向与维度分析结果选择优化策略
基于 Step 1 提取的理论方向和 Step 2 的分析结果,选择针对性的优化策略。策略选择必须有双重依据:理论方向决定了"方向性策略",Step 2 的维度缺陷分析决定了"针对性策略"。
A. 方向性策略(基于理论方向):
| 理论方向类型 | 核心优化目标 | 推荐技术组合 | 必须包含的要素 | 应避免的误区 |
|---|
| 通用对话/客服 | 角色一致性 + 语气温度 + 边界安全 | 角色设定 + 输出格式约束 + 兜底回复规则 | 角色身份、语气要求、知识范围、不可回答场景的兜底回复 | 过于刻板失去温度;过度承诺做不到的事 |
| 学术/教育/解题 | 分步推理 + 概念精确 + 难度渐进 | 角色设定 + CoT + 示例引导 + 输出结构约束 | 分步推理指令、关键概念定义、示例说明(含常见错误)、难度递进 | 一步到位跳过中间推理;假设学生已有背景知识 |
| 代码/技术开发 | 精确性 + 可执行性 + 安全性 | 角色设定 + 输出格式约束 + 约束条件 + 示例 | 技术栈说明、输入/输出约束、错误处理要求、性能考量、安全注意事项 | 忽略边界条件;给出不可运行的伪代码;遗漏依赖说明 |
| 创意/写作 | 风格匹配 + 结构清晰 + 约束适度 | 角色设定 + 示例 + 输出结构 + 语言风格控制 | 受众定位、风格样例(或风格描述)、内容结构框架、创意自由度说明 | 过度约束扼杀创意;结构过于死板 |
| 数据分析/报告 | 结构化输出 + 方法论透明 + 结论可验证 | 角色设定 + CoT + 输出格式 + 约束条件 | 数据描述(含字段说明)、分析方法论要求、假设说明、结论提炼框架、可视化建议 | 忽略数据来源局限性;结论过度泛化;未说明不确定性 |
| 决策/分析 | 多角度权衡 + 证据分级 + 不确定性说明 | 角色设定 + CoT/ToT + 输出格式约束 | 分析框架(如SWOT/成本收益/多标准决策)、证据来源与可信度分级、利弊权衡方法论、不确定性声明 | 单一视角分析;忽略反面证据;确定性表述过强 |
| 角色扮演/模拟 | 角色深度 + 交互规则 + 记忆一致性 | 角色设定 + 语言风格 + 约束条件 + 上下文控制 | 角色背景(人格/知识/经历)、交互规则(何时说话/何时倾听)、行为边界、对话风格说明 | 角色行为不一致;超出角色知识范围回答 |
| 代码审查/质量评估 | 标准化 + 多维度 + 严重程度分级 | 角色设定 + 输出格式 + 约束条件 + 示例 | 审查维度(正确性/性能/安全/可读性/可维护性)、严重程度分级标准、每个问题的改进建议格式 | 只有批评没有改进建议;不同维度标准混为一谈 |
| 知识问答/信息检索 | 来源可靠 + 置信度透明 + 长尾处理 | 角色设定 + 约束条件 + 输出格式 | 知识范围边界、信息时效性要求、置信度声明机制、不确定时的处理策略 | 超出知识范围编造答案;未标注信息时效性 |
| 指令执行/自动化 | 精确理解 + 容错 + 反馈机制 | 角色设定 + CoT + 约束条件 + 输出格式 | 指令解析步骤、参数验证规则、执行确认机制、错误处理和回滚策略、结果确认格式 | 忽略参数边界检查;无执行确认步骤;错误处理缺失 |
| 头脑风暴/创意发散 | 广度的量 + 深度的质 + 可操作性 | 角色设定 + 约束条件 + 输出格式 | 发散方向指引、数量要求(如"至少 10 个")、收敛筛选标准、可操作性评估 | 只有数量没有质量;缺乏评估筛选标准 |
| 摘要/提炼/改写 | 信息保真 + 长度精确 + 风格匹配 | 角色设定 + 输出格式 + 约束条件 + 示例 | 信息来源范围、忠实度要求(禁止添加/忽略)、目标长度、目标风格/受众、关键信息保留清单 | 添加原文没有的信息;遗漏关键信息;风格偏离目标要求 |
B. 针对性策略(基于 Step 2 维度分析结果):
对于 Step 2 中识别的每个 P0/P1 缺陷点,选择对应的优化操作:
| Step 2 分析发现 | 对应的优化操作 | 操作的逻辑依据 |
|---|
| 角色设定缺失(维度1) | 添加与领域匹配的角色描述 | 角色设定能引导模型调用对应的专业知识库,提升输出质量 |
| 任务目标模糊(维度2) | 分解为具体子任务,补充"5W1H"要素 | 模糊指令导致输出发散,具体化后输出方差显著降低 |
| 上下文信息缺失(维度3) | 识别缺失的上下文类型,提示用户补充或提供合理默认值 | 上下文不足时模型会自行猜测,可能导致输出与预期偏离 |
| 输出格式未定义(维度4) | 根据任务类型推荐最合适的输出结构 | 无格式约束时输出结构随机,降低可用性和自动化处理能力 |
| 约束条件缺失(维度5) | 追加必要的边界限制和护栏 | 无约束时输出可能偏离目标范围或包含不适当内容 |
| 复杂任务无示例(维度6) | 补充 1-3 个典型示例作为格式/风格参考 | 示例引导比抽象描述更有效地校准输出格式和风格 |
| 推理任务无分步引导(维度7) | 加入 chain-of-thought 或分步指令 | CoT 在推理任务上可提升 40-80% 的准确率(来源:NextAgile.ai 2026 Enterprise Guide) |
| 语言风格不匹配(维度8) | 调整措辞以匹配场景需求 | 语言风格影响输出的语境适配度,专业场景需正式术语,创意场景需灵活表达 |
| 输入数据未说明(维度9) | 补充数据格式、范围和边界定义 | 数据描述不完整导致模型错误处理输入或忽略边界情况 |
| 术语未定义(维度10) | 添加术语表或在首次使用时给出定义 | 专业术语未定义可能导致理解偏差,尤其是跨领域使用时 |
| 安全护栏缺失(维度11) | 添加内容过滤规则和伦理边界约束 | 安全约束缺乏可能导致不当内容生成 |
策略组合规则(基础):
- 每个优化操作必须同时标注其依据的来源(来自方向性策略 OR 针对性策略 OR 两者),确保用户理解每项改动的逻辑链条
- 如果 Step 2 分析发现原始提示词在某维度已完善,该维度不可强加修改
C. 冲突检测与解决协议(Conflict Resolution Protocol)
当方向性策略(A)与针对性策略(B)之间、或不同针对性策略之间出现冲突时,按以下协议消解:
冲突类型与解决规则:
| 冲突类型 | 示例 | 解决规则 | 解决依据 |
|---|
| 方向 (A) vs 针对性 (B) | A 要求"创意写作应保留自由度" vs B 发现维度4 P0 需加输出结构 | B 优先,但采用最松版本:用引导性而非强制性格式(如"建议按…结构"而非"必须按…结构") | B 基于原文证据,A 为领域通用;但 B 的执行力度应让步于 A 的方向性原则 |
| B vs B(同维度内部) | 维度4 要求"用 JSON 输出"vs 维度8 语言检测为"学术中文"→JSON 的 key 应该用中文还是英文? | 下游优先:以对用户最友好的选择为准(中文用户 → key 用中文;英文用户 → key 用英文) | 以最终使用者为中心的决策原则 |
| B vs B(跨维度矛盾) | 维度5 要求"+长度限制"vs 维度2 任务需要"详细说明" | 显式约束优先:如果用户明确写了"详细",则不加强制性长度限制;如果未明确,添加"建议不超过 X 字" | 保留用户显式意图,在不冲突范围内追加约束 |
| P0 vs P0 互斥 | AP5(冲突约束)检测到同时要求"详细"和"简短" | 询问用户(唯一需要中断流程的冲突):标注冲突,向用户确认优先级 | 两个 P0 互斥时无法自动消除,需外部决策 |
| 优化 A vs 优化 B(操作层面) | 添加"角色设定"可能引入新术语 → 维度10 评分可能下降 | 预判+回填:先执行 A,再对 B 做补偿优化。如添加"专家角色"时同时定义角色涉及的术语 | 级联效应通过 2d 依赖矩阵预判 |
冲突消解流程:
- 列出所有计划执行的优化操作(Ops = [op1, op2, ..., opN])
- 对每对操作 (op_i, op_j),检查是否存在冲突(互斥、矛盾、上下游不一致)
- 对每个冲突,按上表规则消解,记录消解日志
- 如果冲突需要用户决策(P0 vs P0 互斥),暂停优化流程,向用户展示冲突并请求决策
- 消解后重新排列操作执行顺序:上游操作先执行,有补偿关系的操作配对执行
冲突日志格式(内部使用):
[冲突消解日志]
冲突 1:方向(A=创意写作:保留自由度) vs 针对性(B=维度4 P0:加输出结构)
→ 消解:"建议按[结构]组织,但可根据创意需要灵活调整"
冲突 2:无更多冲突
最终操作顺序:op_role → op_task → op_format → op_constraint → op_example → op_language
Step 4: 执行优化(基于逻辑推断的精确改写)
综合 Step 2 的分析结果和 Step 3 的策略,对原始提示词进行逐项优化。每项修改必须有明确的逻辑推理链,格式为:
问题[原文引用] → 分析[Step 2 维度分析结论] → 策略[Step 3 选择的策略] → 优化[具体的修改内容]
4a. 优化操作形式化定义
每个优化操作(Optimization Primitive)必须包含以下结构化信息,确保操作可验证、可回退:
操作原语结构:
操作 #N: [操作类型]
- 前置条件 (PRE):执行此操作前必须满足的条件
- 原文位置:原始提示词中的目标文本片段
- 操作内容:具体的文本级修改(替换/插入/追加/删除)
- 后置条件 (POST):执行后应达到的状态
- 验证方法:如何检验后置条件是否满足
- 反事实推理:如果不执行此操作,优化后提示词会在哪些方面表现不佳
- 副作用分析:此操作可能对其他维度产生的影响(参考 2d 依赖矩阵)
- 回退方案:如果此操作引入新问题,如何撤销或修正
操作类型目录:
| 操作类型 | 操作描述 | 典型 PRE 条件 | 典型 POST 条件 |
|---|
add-role | 在开头插入角色描述 | 维度1评分≤2 | 维度1评分≥3,角色与任务匹配 |
refine-task | 细化任务描述(拆分/具体化动词/添加成功标准) | 维度2评分≤3 | 维度2评分≥4,每个子任务有明确产出 |
add-context | 补充背景信息或显式化隐含假设 | 维度3评分≤2 | 维度3评分≥3,无不明确的外部引用 |
specify-format | 将笼统格式转换为精确规范 | 维度4评分≤2 | 维度4评分≥3,输出结构可机械解析 |
add-constraint | 追加边界/风格/安全约束 | 维度5评分≤3 | 维度5评分≥3,约束列表覆盖所有必要类别 |
add-example | 补充输入/输出示例对 | 维度6评分≤2 | 维度6评分≥3,示例覆盖典型+边界情况 |
add-cot | 插入 chain-of-thought 推理引导 | 维度7评分≤2 且任务为推理型 | 维度7评分≥3,推理步骤明确 |
refine-language | 调整措辞/语气/术语统一 | 维度8评分≤3 | 维度8评分≥3,无歧义、术语统一 |
specify-input | 明确输入数据格式和边界 | 维度9评分≤2 | 维度9评分≥3,输入描述完整 |
define-terms | 添加术语定义或外部知识引用 | 维度10评分≤2 | 维度10评分≥3,所有专业术语首次出现有定义 |
add-guardrail | 添加安全护栏和伦理约束 | 维度11评分≤2 | 维度11评分≥3,覆盖安全/伦理/合规 |
add-iteration-hook | 添加迭代追问机制 | 维度12评分≤2 | 维度12评分≥3,输出结构支持二次处理 |
fix-anti-pattern | 修正检测到的反模式(AP1-AP14) | 对应 AP 命中 | AP 标记移除,关联维度评分恢复 |
restructure | 重新组织提示词结构(段落顺序/格式) | 存在结构性问题(AP3/AP11命中或评分≤2) | 结构清晰、逻辑顺序合理 |
4b. 反事实推理(Counterfactual Reasoning)
每项优化操作必须附带反事实分析——如果跳过此优化,优化后的提示词会出现什么具体问题。这确保每项优化都有可验证的价值,而非为了优化而优化。
反事实推理模板:
如果不执行此操作 → [具体后果描述] → 用户可能遇到的问题是:[可观测的问题] → 此问题在优化后已消除
反事实推理示例:
- 不添加角色设定 → 模型以通用助手身份回答,缺乏领域专业术语和思维框架 → 用户收到的物理概念解释可能是科普水平而非大学物理水平
- 不拆分复合任务 → 模型可能只完成部分子任务或混淆优先级 → 用户可能只得到数据分析而遗漏报告生成
- 不添加安全护栏 → 模型可能生成带有偏见的建议或泄露敏感信息 → 在实际生产环境中可能导致合规风险
反事实强度分级:
| 强度 | 定义 | 示例 |
|---|
| C0 灾难性 | 不执行此操作,输出完全不可用 | 不定义输出格式 → 代码审查结果散乱无结构,无法按优先级处理 |
| C1 显著降质 | 输出可用但质量明显下降 | 不添加角色 → 回复缺乏专业深度 |
| C2 次优 | 输出良好但可通过此操作进一步提升 | 不添加示例 → 输出正确但格式可能不完全符合预期 |
4c. 优化层面与推理规则:
1. 角色设定优化
| 原始状态 | 推理过程 | 优化方案 |
|---|
| 原文中完全没有角色设定 | 原文无角色描述 → 维度1(P0) → 角色缺失会导致输出通用化 → 策略:需根据理论方向添加相应的角色 | 添加:"你是一位[领域]专家,擅长[核心能力]" |
| 有角色但过于泛化(如"你是专家") | "专家"未说明领域 → 维度1(P1) → 角色粒度不够 → 策略:细化角色领域 | 细化:"你是一位[具体领域]专家,专注[具体方向]" |
| 角色与任务不匹配 | "诗人"角色用于"写代码" → 维度1(P1) → 角色与任务冲突 → 策略:替换为匹配角色 | 替换为与技术任务匹配的角色 |
2. 任务描述优化
- 模糊动词替换:定位原文中的模糊动词("处理""分析""看看"),替换为具体动词("提取""计算""分类""生成""验证")。推理链条:模糊动词 → 维度2(P0) → 输出不可预测 → 需具体化
- 复合任务拆分:如果原文将多个子任务混为一谈(如"分析数据并生成报告并发送邮件"),拆分为独立的子步骤。推理链条:复合任务 → 维度2(P1) → 逻辑混淆 → 需分解
- 成功标准补充:如果原文缺乏成功判断标准,补充可衡量的质量要求。推理链条:无标准 → 维度2(P1) → 输出质量无法评估 → 需添加标准
3. 上下文补充
- 背景缺失识别:从原文中找出所有假设 AI 已知道的隐含前提。推理链条:隐含假设 → 维度3(P0/P1) → 模型自行猜测可能导致偏离 → 需显式化
- 合理默认值提供:如果无法从用户处获得补充上下文,根据理论方向设立合理的默认假设,并在优化说明中标注"此处为基于[理论方向]的合理推断,请确认是否符合预期"
4. 输出格式规范
- 格式精确化:将笼统的输出要求("列出来""整理一下")转换为精确的格式描述。推理链条:输出格式模糊 → 维度4(P0) → 结构不可控 → 需精确化
- 结构模板提供:对于复杂输出,提供具体的结构模板。示例:
- JSON:指定字段名、类型、是否必填
- Markdown:指定标题层级、列表格式、表格结构
- 列表:指定排序规则(按重要性/按时间/按分类)
5. 约束添加
- 约束清单匹配:对照 Step 2 的约束检查结果,为每个 P0/P1 约束缺陷添加对应的约束语句
- 约束类型:
- 长度约束:"回复限制在 [N] 字以内"
- 范围约束:"仅基于提供的上下文回答"
- 风格约束:"使用 [正式/口语化/技术性] 语言"
- 安全约束:"不得生成 [具体禁止内容]"
- 质量约束:"每个论点必须提供证据或引用"
- 推理链条示例:原文无限定 → 维度5(P0) → 输出可能偏离预期 → 追加长度/范围约束
6. 示例或推理引导
- 示例生成:为复杂任务补充 1-3 个输入/输出对。推理链条:复杂任务无示例 → 维度6(P1) → 格式和风格不确定 → 补充示例
- CoT 引导:为推理类任务添加逐步思考的指令。推理链条:推理任务无分步引导 → 维度7(P1) → 推理过程不可控 → 添加 CoT
- 引导方式选择:
| 任务类型 | 推荐引导方式 | 逻辑依据 |
|---|
| 数学/逻辑推理 | CoT:"请逐步推理,每步说明依据" | 分步推理减少错误累积 |
| 对比/权衡分析 | 多角度框架:"从 X、Y、Z 三个角度分析,每个角度列出利弊" | 结构化框架覆盖全面 |
| 创意生成 | 约束引导:"在[具体约束]范围内,生成[数量]个方案" | 适度约束提升产出质量 |
7. 语言与表达优化
- 弱语气强化:将"你可以考虑…"替换为"请…"或"必须…"。推理链条:弱语气 → 维度8(P1) → 指令执行力不足 → 强化语气
- 歧义消除:对原文中可能产生多种理解的表达进行精确化。推理链条:歧义表达 → 维度8(P0) → 输出不稳定 → 消除歧义
- 术语统一:同一概念在原文中使用不同术语 → 统一术语。推理链条:术语不一致 → 维度8(P1) → 理解混淆 → 统一
不可执行的优化操作列表:
以下操作不得执行,无论 Step 2/3 如何建议:
| 禁止的优化操作 | 禁止原因 |
|---|
| 添加与原始目标无关的新任务 | 违反"保留核心意图"原则,属于扭曲原意 |
| 删除用户明确指定的约束或要求 | 违反"保留关键信息"原则 |
| 将单步简单任务拆分为不必要的多步骤 | 过度工程化,降低实用性 |
| 为简单查询添加 CoT(如"现在几点") | 技术误用,增加不必要的 Token 消耗 |
| 用自己的知识补充原文没有的事实信息 | 属于"脑补",信息可能不准确 |
| 改变指令的语义方向(如将"分析"改为"批评") | 改变原意,扭曲用户意图 |
| 添加用户未要求的格式要求(如非必要时强制 JSON) | 过度修改,增加使用复杂度 |
4d. 过优化检测与防护(Over-Optimization Guard)
优化不是越多越好。过优化(Over-Optimization) 指添加了不必要的复杂度、约束或结构,导致提示词变得臃肿、难以维护或限制了模型的合理发挥空间。在每次执行优化操作后,检查以下过优化信号:
过优化信号清单:
| 信号 | 检测方法 | 触发阈值 | 修正方式 |
|---|
| 长度膨胀 | 优化后提示词长度 / 原始长度 | > 3.0 倍 | 审查每个新增片段是否必要,移除非 P0/P1 的 P2 级优化 |
| 约束过密 | 新增约束语句数量 | > 原始约束数 × 2 | 合并同类约束,移除重叠或冗余的约束 |
| 过度拆分 | 单步任务被拆分的子步骤数 | > 5 个子步骤(对于简单任务) | 合并回父步骤,保留 3-5 个关键子步骤 |
| 示例冗余 | 新增示例数量 | > 3 个(对于简单任务) | 保留最典型的 1-2 个示例 |
| CoT 误用 | 为查询/翻译/简单分类任务添加了 CoT | 任何命中 | 立即移除 CoT,这些任务不需要推理引导 |
| 角色过度具体 | 角色描述超出必要领域范围 | 包含与任务无关的技能描述 | 精简为仅包含与任务相关的技能 |
过优化检查流程:
- 优化操作全部执行完毕后,运行过优化信号检测
- 对每个命中信号,标记对应的优化操作
- 将过优化操作降级(如 P2→删除,P1→P2 并标注为可选)
- 移除降级后的操作,重新生成优化后提示词
- 在 Step 6 输出时,在优化说明中注明"以下优化因过优化风险被降级/移除"
Step 5: 回归验证(Regression Verification)
这是 v3.0 新增的关键步骤——优化完成后,将优化后的提示词重新输入 Step 2 的 12 维度分析框架,确保优化没有引入新的缺陷(回归)。
5a. 回归分析
对优化后的提示词执行与 Step 2 相同的分析流程(2a-2e),生成:
[回归分析]
| 维度 | 优化前分数 | 优化后分数 | 变化 | 验证 |
|------|-----------|-----------|------|------|
| 1 角色设定 | 0 | 4 | +4 ✅ | 新增角色描述,与任务匹配 |
| 2 任务明确性 | 3 | 4 | +1 ✅ | 动词具体化、成功标准补充 |
| 3 上下文完整性 | 1 | 3 | +2 ✅ | 隐含假设已显式化 |
| ... | ... | ... | ... | ... |
| 总分 | 24/60 | 42/60 | +18 | 平均分 2.0 → 3.5 |
5b. 回归缺陷检测
检查优化后的提示词是否引入了新问题:
| 检查项 | 判定方法 | 处理方式 |
|---|
| 维度分数下降 | 任何维度优化后分数 < 优化前分数 | 严重回归:撤销导致下降的操作,用替代方案重新优化 |
| 新增反模式命中 | 优化后命中 Step 2c 中未命中的反模式 | 中度回归:分析反模式来源,修正对应的优化操作 |
| 原有优点被覆盖 | 优化前的 4-5 分维度在优化后降至 ≤3 | 轻度回归:恢复该维度的原始状态,仅对 P0 问题做最小修改 |
| 依赖维度未同步 | 参考 2d 依赖矩阵:优化维度 X 后,其影响维度(Y)未相应调整 | 级联遗漏:对 Y 维度执行补偿优化 |
| 可读性下降 | 优化后提示词出现语句不通、逻辑跳跃、过度模板化 | 可读性修复:调整措辞以恢复自然表达,移除过度模板化的结构 |
5c. 迭代修正循环
如果 5b 检测到回归缺陷:
- 定位根源操作:从 Step 4 的操作原语列表中找出导致回归的操作
- 撤销或修正:对根源操作执行回退方案(4a 中预定义的回退方案)
- 重新生成:修正后重新生成优化后提示词
- 重新验证:再次执行 5a-5b,直到满足以下退出条件:
- ✅ 所有维度分数 ≥ 优化前分数(无下降)
- ✅ 无新增 P0/P1 缺陷
- ✅ 总分提升 ≥ 原始总分的 10%(即优化有意义)
- ❌ 已达到 3 次迭代(超出则标注"可能过优化"并采纳当前最佳版本)
迭代修正日志(内部使用):
[迭代修正]
第 1 轮回归:维度8 从 4 → 2(新增角色使措辞冗长)
→ 根源:add-role 操作的角色描述过于详细
→ 修正:精简角色描述到 1 句
→ 第 2 轮回归:通过 ✅
最终采纳:第 2 轮修正版本
5d. 原意保存验证
对照原始提示词,逐项验证核心意图未被改变:
| 验证项 | 检查方法 | 不通过处理 |
|---|
| 核心任务目标 | 提取优化后提示词的核心动词和目标,与原始对比 | 出现偏离 → 回到 Step 4 修正 |
| 用户明确指定的约束 | 列出优化前后所有约束,检查是否有缺失或弱化 | 有缺失 → 恢复原始约束 |
| 语义方向 | 优化前后的指令方向是否一致(如"分析"→"分析",非"分析"→"批评") | 方向改变 → 撤销导致改变的优化 |
| 关键术语 | 用户使用的领域特定术语是否被保留(即使它们不是标准术语) | 被替换 → 恢复原始术语 |
Step 6: 输出优化结果(原 Step 5)
将优化结果直接通过文本返回给用户,包含以下四部分:
第一部分 — 优化后的提示词(完整版):
以代码块格式输出完整的优化后提示词,确保用户可以直接复制使用:
[优化后的完整提示词]
第二部分 — 推理链摘要:
展示从原始提示词到优化后提示词的核心推理过程,让用户理解每项改动的逻辑链条:
## 优化推理摘要
### 核心推理路径
原始输入 → [Step 0 验证] → 输入合法性确认 → [Step 1 解析] → 理论方向 & 原始提示词 →
[Step 2 分析] → 12维度评分+反模式+依赖矩阵(缺陷清单) → [Step 3 策略] →
方向性策略+针对性策略+冲突消解 → [Step 4 执行] → 形式化操作原语+反事实推理+过优化检测 →
[Step 5 回归] → 重过12维度+迭代修正 → [Step 6 输出] → 优化后的提示词+质量对比报告
此部分帮助用户理解本技能的工作方式,建立对优化结果的信任。
第三部分 — 优化说明(逐项标注推理链):
每项优化改动必须包含完整的推理链,格式如下:
## 优化说明
### 主要改动
1. **[改动类型]** 改动描述
- **原文引用**:"[原始提示词中的对应片段]"
- **维度分析**:[Step 2 中的维度编号和结论]
- **逻辑依据**:[为什么做这个改动,对应的策略依据]
- **优化后**:"[优化后的对应片段]"
- **预期效果**:[这个改动带来的改善]
2. ...
### 已确认无需改动的方面
- **[维度]** [原文引用] → 已完善,无需修改
- **[维度]** 当前状态下此维度不适用,跳过
### 改动等级统计
- P0(必改):N 项
- P1(建议):N 项
- P2(可选):N 项
注意: 优化说明中不得出现无法追溯的改动(即未在 Step 2 中分析、未在 Step 3 中决策的改动)。如果某处改动纯粹基于风格偏好,必须在说明中标注"此改动为风格性调整,不影响功能,可根据偏好决定是否采纳"。
第四部分 — 质量对比报告(新增):
将 Step 5 回归验证的结果以可视化对比形式呈现给用户:
## 📊 质量对比
| 维度 | 优化前 | 优化后 | 提升 | 说明 |
|------|--------|--------|------|------|
| 1 角色设定 | 0 | 4 | +4 ⬆️ | 从无角色到领域专家 |
| 2 任务明确性 | 3 | 5 | +2 ⬆️ | 补充成功标准 |
| 3 上下文完整性 | 1 | 3 | +2 ⬆️ | 显式化 3 个隐含假设 |
| ... | ... | ... | ... | ... |
| **总分** | **24/60** | **42/60** | **+18 (+75%)** | **平均 2.0 → 3.5** |
报告说明:
- 只输出有变化的维度 + 总分行,评分无变化的维度省略(避免冗余)
- 提升以箭头标注趋势(⬆️ 提升 / ➡️ 不变 / ⬇️ 下降)
- 如果 Step 5 中发现回归(有维度分数下降),在报告中以 🔴 标记并在报告下方追加"⚠️ 回归警告"区块
第五部分 — 使用建议与迭代方向(可选):
如果适用,提供 1-2 条使用优化后提示词的建议,包括:
- 参数调整建议:如 temperature、max_tokens 等参数推荐值
- 迭代方向:在第一轮优化结果基础上,用户可如何进一步迭代提示词
- 注意事项:优化后提示词中可能存在依赖用户补充信息的部分(如[需要你填写的参数])
- 过优化警告:如果 Step 4d 中检测到过优化信号并做了降级处理,在此说明
Constraints
核心约束 — 逻辑严谨性
- Always 每项优化必须可追溯完整的推理链:原文引用 → 维度分析 → 策略选择 → 优化执行 → 反事实推理 → 回归验证,缺一不可
- Always 在 Step 2 分析中,每项判断必须引用原始提示词的具体词句作为依据,禁止仅凭主观感受下结论
- Always 对每个维度给出 0-5 定量评分并引用原文证据,不得凭感觉打分
- Always 在 Step 2c 中扫描全部 14 种反模式,不得跳过
- Always 在 Step 2d 中使用依赖矩阵标记受影响的维度
- Always 如果某项优化无法通过逻辑推断论证其必要性,则不得执行该优化
- Always 在 Step 4 中为每项优化操作提供完整的操作原语(PRE/POST/验证方法/反事实/副作用/回退方案)
- Always 每项优化的反事实推理必须具体描述"不执行此操作的后果",禁止笼统表述
- Always 在 Step 4d 中检查过优化信号,防止过度优化
- Always 在 Step 5 中完整执行回归验证(5a-5d),不得跳过
- Always 如果回归验证发现任何维度分数下降,必须执行迭代修正
- Always 在优化说明中明确标注 P0(必改)、P1(建议)、P2(可选)的等级区分,以及反事实强度(C0/C1/C2)
- Always 对于未在 Step 2 分析中发现的维度,不得在优化中添加相关内容
- Always 先充分理解理论方向再开始优化,避免使用不匹配的优化策略
- Always 如发现原始提示词存在歧义或缺失关键信息,在优化说明中明确指出
核心约束 — 原意保护
- Never 改变原始提示词的实质目标或用途方向
- Never 添加用户原始提示词中不存在的新任务或新指令目标
- Never 删除或弱化用户原始提示词中明确指定的约束或要求
- Never 用自己的知识补充原始提示词中没有的事实性信息(如具体数据、案例、定义等),除非用户明确要求
- Never 将原始提示词中明确写明的指令替换为含义不同的表述
- Never 拆分或合并原始提示词中的步骤导致逻辑顺序改变
核心约束 — 禁止行为
- Never 将优化后的提示词写入任何文件
- Never 添加与理论方向无关的冗余内容
- Never 对简单任务过度工程化(如为"现在几点"添加 CoT)
输出格式约束
- Always 将优化后的提示词以代码块形式输出,方便用户直接复制
- Always 优化说明中的每项改动必须包含完整的推理链(原文引用 → 维度分析 → 逻辑依据 → 优化后)
- Always 如果修改了原始提示词的结构(如拆分子步骤),在优化说明中提供结构对比图
- Always 在输出末尾提示用户可以进一步迭代的方向
Examples
✅ Do This — 通用对话类提示词优化(含完整推理链)
用户输入:
理论方向:客服场景中的礼貌回复生成
原始提示词:帮我写一个客服回复,客户说产品有问题
Step 2 分析结果(内部决策依据):
已发现优化点:
- P0:[角色设定] 原文无任何角色描述 → 角色缺失 → 需添加客服角色
- P0:[输出格式] 原文未指定回复结构 → 输出结构不可控 → 需定义回复要素
- P1:[约束条件] 无长度/语气约束 → 输出可能不符合客服场景 → 需添加
- P2:[示例引导] 简单任务,可不加示例
保留项:
- [任务明确性] 任务目标清晰(生成客服回复)
- [语言表达] 语言直接,符合指令风格
输出结构:
[优化后的提示词]
你是一位经验丰富的客服专员,擅长以专业、同理心的态度处理客户投诉。
客户反馈产品存在问题,请你生成一个回复方案,包含以下要素:
1. 对客户遇到的问题表示理解和歉意
2. 简要说明可能的解决方案(退换货、维修、退款等)
3. 告知客户下一步行动指引
4. 提供联系渠道供进一步沟通
语气要求:专业、耐心、积极解决问题
长度:不超过 200 字
## 优化推理摘要
原始输入 → 解析 → 理论方向:客服场景 → 12维分析 → 选择策略:通用对话类 →
执行优化(角色+格式+约束) → 优化完成
## 优化说明
### 主要改动
1. **[角色设定-P0] 添加客服专员角色**
- **原文引用**:"帮我写一个客服回复"
- **维度分析**:维度1,原文无任何角色描述
- **逻辑依据**:角色设定引导模型调用客服沟通的知识库;原始提示词未指定任何角色,输出可能过于通用或偏离客服场景
- **优化后**:"你是一位经验丰富的客服专员"
- **预期效果**:输出将更具专业性和针对性,自动采用客服行业标准话术结构
2. **[输出格式-P0] 补充回复结构要素**
- **原文引用**:"写一个客服回复"(未指定回复内容结构)
- **维度分析**:维度4,输出格式完全未定义
- **逻辑依据**:无结构约束时输出格式随机,可能出现不完整的回复
- **优化后**:要求包含致歉、解决方案、下一步指引、联系渠道四要素
- **预期效果**:回复将结构完整,覆盖客户关切的各个方面
3. **[约束条件-P1] 添加语气和长度约束**
- **原文引用**:无任何限制性表述
- **维度分析**:维度5,约束条件完全缺失
- **逻辑依据**:客服回复的语气和长度直接影响客户体验
- **优化后**:要求"专业、耐心"语气,限制"不超过200字"
- **预期效果**:输出在风格和篇幅上符合客服场景要求
### 已确认无需改动的方面
- [任务明确性] 任务目标已清晰
- [语言表达] 直接指令风格适合
### 改动等级统计
- P0:2项|P1:1项|P2:0项
✅ Do This — 代码类提示词优化(含完整推理链)
用户输入:
理论方向:Python 代码审查
原始提示词:检查这段代码有什么问题
def calc(a,b):
return a/b
Step 2 分析结果(内部决策依据):
已发现优化点:
- P0:[角色设定] 原文无角色描述 → 代码审查需专业知识背景 → 需添加专家角色
- P0:[输出格式] "有什么问题"未指定审查维度和输出结构 → 需定义审查框架
- P1:[约束条件] 无审查标准 → 严重程度需分级 → 需添加分级标准
- P1:[示例引导] 审查类任务可加示例提升效果 → 可选
保留项:
- [任务明确性] 核心目标明确(检查代码问题)
输出结构:
[优化后的提示词]
你是一位资深的 Python 代码审查专家,擅长发现代码中的 bug、性能问题和安全隐患。
请审查以下 Python 函数,从以下维度进行分析:
1. **正确性**:是否存在逻辑错误或边界情况
2. **安全性**:是否存在安全隐患(如除零错误、注入风险等)
3. **可读性**:命名、注释、代码风格是否规范
4. **性能**:是否存在性能优化空间
需要审查的代码:
```python
def calc(a, b):
return a / b
请以列表形式输出发现的问题,每个问题包含:严重程度(高/中/低)、问题描述、改进建议。
优化推理摘要
原始输入 → 解析 → 理论方向:代码审查 → 12维分析 → 选择策略:代码审查类 →
执行优化(角色+格式+约束) → 优化完成
优化说明
主要改动
-
[角色设定-P0] 添加代码审查专家角色
- 原文引用:全文无角色描述
- 维度分析:维度1,角色缺失
- 逻辑依据:代码审查需要结构化知识框架;角色设定能引导模型调用代码审查方法论而非随意评论
- 优化后:"资深的 Python 代码审查专家,擅长发现 bug、性能问题和安全隐患"
- 预期效果:审查结果将更系统深入
-
[输出格式-P0] 定义四维审查框架
- 原文引用:"检查这段代码有什么问题"(未指定审查维度)
- 维度分析:维度4,输出格式未定义
- 逻辑依据:无审查框架时输出可能遗漏重要维度或结构混乱
- 优化后:正确性、安全性、可读性、性能四个维度 + 结构化输出格式
- 预期效果:覆盖全面,不遗漏关键审查维度
-
[约束条件-P1] 添加严重程度分级
- 原文引用:无任何质量标准表述
- 维度分析:维度5,约束缺失
- 逻辑依据:所有问题平等列出不利于确定处理优先级
- 优化后:每个问题标注严重程度(高/中/低)
- 预期效果:用户可以按优先级处理发现问题
已确认无需改动的方面
- [任务明确性] 核心目标明确
- [上下文完整性] 代码即上下文,足够
改动等级统计
### ✅ Do This — 学术类提示词优化(展示多领域覆盖)
**用户输入:**
理论方向:物理学概念解答(大学水平)
原始提示词:解释一下什么是量子纠缠
**Step 2 分析结果(内部决策依据):**
已发现优化点:
- P0:[角色设定] 无角色 → 大学物理概念解答需要专业背景
- P0:[输出格式] 未指定解释的层次和结构 → 输出深度不可控
- P1:[上下文完整性] 未说明受众水平 → 可能过深或过浅
- P1:[推理引导] 概念解释可加入类比引导 → 可选
- P1:[约束条件] 无字数/复杂度限制
保留项:
**输出结构:**
[优化后的提示词]
你是一位大学物理教授,擅长用清晰易懂的方式解释量子力学概念。
请以大学物理专业本科生的水平,解释"量子纠缠"概念,回答应包含以下结构:
- 精确定义:给出量子纠缠的物理定义和数学表示
- 核心原理:叠加态原理、测量塌缩、非定域性
- 关键实验证据:贝尔不等式违反实验
- 常见误解澄清:如"超光速通信"等
- 实际应用:量子通信、量子密钥分发
要求:
- 使用专业但可理解的表述
- 包含至少一个类比帮助理解
- 标注任何存在学术争议的论点
- 控制在 500 字以内
优化推理摘要
略
优化说明
主要改动
-
[角色设定-P0] 添加大学物理教授角色
- 原文引用:全文无角色
- 维度分析:维度1,角色缺失 → 大学物理概念需专业知识框架
- 逻辑依据:教授角色引导模型调用物理学教学知识库
- 优化后:"大学物理教授"
- 预期效果:提升解释的专业性和教学适配度
-
[输出格式-P0] 定义5段式解释结构
- 原文引用:"解释一下什么是量子纠缠"(未指定解释结构)
- 维度分析:维度4,输出格式未定义
- 逻辑依据:无结构时输出可能遗漏关键部分或结构随机的;物理概念解释需要从定义到应用的递进逻辑
- 优化后:定义→原理→证据→误解→应用
- 预期效果:解释全面,逻辑递进清晰
-
[上下文完整性-P1] 指定受众水平
- 原文引用:未指定受众
- 维度分析:维度3,上下文缺失 → 难度不可控
- 逻辑依据:大学物理与科普的解释深度截然不同
- 优化后:"大学物理专业本科生的水平"
- 预期效果:解释深度与受众匹配
改动等级统计
### ❌ Not This — 错误做法
**错误做法 1:直接改写而不说明理由**
优化后:请检查以下 Python 代码...
→ 没有说明改了什么、为什么改,用户无法学习优化思路,且无法验证改动的合理性
**错误做法 2:改变原始目标(扭曲原意)**
原始:帮我写一个客服回复
优化后:请你以产品经理的身份撰写一份客户调研问卷...
→ 改变了原始提示词的意图方向,"客服回复"≠"调研问卷",属于扭曲原意,严重违反核心约束
**错误做法 3:优化过于冗余**
原始:检查这段代码
优化后:尊敬的 AI 助手,我恳请您以一位拥有 20 年经验的 Python 架构师的身份...(200 字铺垫)
→ 添加了与任务无关的冗余内容,降低可用性
**错误做法 4:将优化结果写入文件**
→ 用户明确要求直接输出,不应写入任何文件
**错误做法 5:添加没有逻辑依据的修改**
优化说明:
→ 没有使用 Step 2 的维度分析,没有引用原文,没有逻辑推理链,纯属主观偏好
**错误做法 6:用自己的知识补充原文没有的信息**
原始:解释量子纠缠
优化后定义中包含了"EPR佯谬"和"贝尔不等式"的详细数值
→ 如果原文未要求这些细节,添加它们超出了优化的范畴,属于"脑补"
**错误做法 7:合并多个优化点的推理链为一条笼统说明**
优化说明:
改进了这个提示词,使其更好用。
→ 每个优化点必须独立标注推理链,笼统概括使用户无法理解具体的改动逻辑
## Notes
- **v3.0 新增特性**:输入验证 (Step 0)、定量评分 (0-5 scale)、反模式检测 (14 种)、跨维度依赖矩阵、冲突解决协议、操作原语形式化 (PRE/POST)、反事实推理 (C0/C1/C2)、过优化防护 (Step 4d)、回归验证 (Step 5)、质量对比报告
- 本技能不依赖任何外部工具或 API,纯靠 Claude 的提示词工程能力完成优化
- 理论方向越具体,优化策略越精准。建议用户提供尽可能详细的理论方向描述(包括具体任务、目标受众、使用场景等)
- 如果用户对优化结果不满意,可要求进一步优化或提供更多上下文信息
- 对于有争议的优化选择(如是否添加 chain-of-thought),在优化说明中标注"可选建议"而非强制改动
- 输出中的"优化说明"部分可以帮助用户理解提示词工程原理,长期提升用户的提示词编写能力
- 12 维度分析框架覆盖了提示词质量的核心方面,但不是所有维度在每个优化任务中都需要(如纯工具类提示词可能不需要角色设定)
- Step 2 的分析结果(缺陷清单和优先级)不直接输出给用户,而是作为 Step 3 策略选择和 Step 4 执行优化的内部决策依据,用户看到的是 Step 6 中提炼后的优化说明
- 部分优化操作依赖于对理论方向的合理推断(如为客服场景推断"同理心"语气),这类推断在优化说明中标注"基于[方向]的合理推断",让用户决定是否采纳
- 如果用户对"P0/P1/P2"的分级方式不认同,可以在后续对话中调整优先级
- 提示词工程是一个迭代过程,单次优化可能无法覆盖所有改进空间,建议用户在实际使用后再回来进行第二轮优化
- **技术引用**:"Chain-of-Thought 在推理任务上可提升 40-80% 准确率"引用自 NextAgile.ai 2026 Enterprise Guide;12 维度分析框架基于 "Anatomy of a Prompt" 学术框架(DOI: 10.5281/ZENODO.18527762)和 GOLDEN 检查清单(PromptBuilder.cc 2025),结合 Anthropic 官方提示词工程最佳实践(platform.claude.com)扩展