refine-prompt

优化提示词

流程

1. 评估——找出提示词缺少的内容：

要素	检查项
任务	核心操作是否明确且没有歧义？
约束	是否定义了长度、格式、语气和范围？
输出格式	是否指定了预期结构？
上下文	模型是否有足够的背景信息来执行任务？检查受众、输入格式、成功标准、范围边界和技术约束
示例	演示是否有助于明确预期输出？
边缘情况	是否考虑了失败模式和边界条件？
读者	如果没有人工协助消除歧义，模型能否解析这段内容？如果可以，请使用下文的机器可解析文本要求。

2. 改写——将提示词转化为规范语言：精准、祈使、不含赘述。将提示词视为规范，而不是对话。

3. 验证——对照评估表检查改写内容。第 1 步识别出的每个缺漏都必须得到解决。

规则

• 长度：原文的 0.75 倍至 1.5 倍。简洁是一种优点——只补充缺失内容，删去含糊内容。
• 每一行都必须改变行为。“删去含糊内容”和“删去模型本来就会做的事”是两种不同的筛选标准，后者删去的内容要多得多——只要改成祈使句，每一行读起来都不会含糊。模型默认就会做到的事，应该整句删掉，而不是只删减几个词。反复出现的问题是模型本来就会遵循的鼓励性措辞：“小心”“全面”“仔细思考”“务必做到”。
• **指出概念，不要解释概念。**使用模型熟悉的术语（幂等、不变量、竞态条件、TOCTOU、YAGNI），而不是把概念展开说明。只有项目自创的术语才需要解释，并且只在一处解释一次。
• **一条规则只说一次。**如果同一条规则出现在两个部分，删去其中一处，并指向另一处。
• **每项禁止要求都要配上正向目标。**以禁止为导向会把被禁止的行为带入上下文，让模型更容易想到它——否定只是一种微弱修饰，依附于被强烈激活的概念上。应提示目标行为（例如“编写单行注释”，而不是“不要编写长注释”），这样就不会提及被禁止的行为。纯粹的禁止要求只有在作为硬性护栏、且其全部内容就是拒绝时，才有存在的必要；其他情况下，检查方式很简单：每条含有 never 或 don't 的规则都要说明替代行为。
• 绝不臆造——只使用原始提示词或对话上下文中已有的信息。如果缺少关键信息，就提问，而不是自行假设。
• 指令层级——按优先级排列各部分：任务 → 约束 → 示例 → 输入数据 → 输出格式。最重要的指令放在最前面。
• 循序渐进地增加复杂度——从可能有效的最简单提示词开始。只有任务确实需要时，才添加少样本示例、思维链或角色设定，不要默认添加。
• 使用具体动词——用可衡量的动作（“列出排名前三的项目”“分类为 A/B/C”“返回包含 X、Y 键的 JSON”）替换含糊的动作（“分析”“处理”“应对”）。
• 只指定一种输出格式——明确指定一种格式（JSON 架构、Markdown 模板、编号列表）。对格式的要求含糊不清，会导致结果不一致。
• **说明规则的原因，而不只是规则本身。**密集地使用 MUST/CRITICAL 会让模型关注指令本身，而忽略其适用的上下文；不带缘由的祈使句彼此竞争，而不会相互强化。保留少量此类要求，并在同一句中说明规则旨在防止什么，从而让模型能将规则应用于未明确提及的情况。
• 不添加元评论——只输出改进后的提示词 Markdown。不要添加开场白（例如“这是改进后的版本……”），除非明确要求，否则不要解释修改内容。

机器解析文本

适用于模型在无法反向沟通的情况下读取输出的场景：工具和函数说明、系统提示词、技能和 Agent 指令、错误字符串、Agent 间消息。人遇到含糊的句子时会询问。模型遇到含糊的句子时会猜测。

• 每句话只包含一条指令。 复合指令会被部分执行——模型会执行第一项和最后一项，却漏掉中间的内容。把“打开文件并阅读第 3 行，然后检查它是否匹配”拆成三句话。
• 指令使用简单时态。 写“任务结束”，不要写“任务已经完成”。复合时态会带来第二种解析（何时结束？现在是否仍然如此？），却不包含任何指令。
• 名词堆叠最多三个。 “Agent 任务队列优先级处理器”有四种解读。用介词拆开：“设置任务队列优先级的处理器”。
• 情态词承载重要含义。 将 must 和 never 用于要求，将 should 和 may 用于真正留有余地的情况。“Agent 应先验证”会被理解为可选操作；如果不是可选的，就写“先验证”。
• 明确写出每个指代对象。 当存在多个可能的先行词时，写出主语，而不要使用“这”“它”或“上述内容”。
• 不要为了精简而制造歧义。 为节省 token 而省略主语、动词或冠词，只会让句子更短、解读更多，而不是更少——“未备份的文件将丢失”没有说明哪些文件。此处对上文的长度规则作出限制：删去不会改变行为的完整句子，不要删去承载指代对象的词。

持久化

完成优化后，提出将结果保存到 .ai/PROMPT.md——先询问（在 Claude Code 中使用 AskUserQuestion，在 Codex 中使用 request_user_input，在聊天中提供带编号的选项）；未经确认，绝不写入。若获得批准，则附加一个标题和日期：

## [Prompt Name] -- YYYY-MM-DD

[refined prompt content]

反模式

问题	修正方法
动词含糊（“看看”“处理”）	替换为具体操作（“列出”“比较”“提取”）
缺少输出规范	添加明确的格式部分，并提供结构示例
示例与指令矛盾	调整示例，使其符合所有既定规则
一开始就过度设计	精简到最简单的可用版本，仅在输出质量需要时增加复杂度
提示词中的示例超出上下文容量	限制为 2–3 个不同示例；使用一个简单示例和一个边缘情况示例

约束

• 如果原始意图不明确，就停止优化——先澄清
• 不要优化有害或违法任务的提示词——拒绝并说明原因

验证

• 改写内容解决评估中发现的所有问题
• 长度比例在原文的 0.75 倍至 1.5 倍之间（除非有充分理由进行结构性调整）
• 没有引入原文中不存在的约束或假设
• 面向机器解析的输出中，每句话只包含一条指令，且不得在要求中使用 should 或 may