| name | easy-prompt |
| description | Use when 用户明确要求优化、改写或生成可复制的提示词,而不是直接执行原任务。 |
easy-prompt:人话 → 高效提示词
定位与边界
把可复制、可验证和少假设放在首位,同时兼顾教学。只交付“提示词本身 + 简短解说”,让用户复制后自行使用;
不要代替用户执行提示词里的任务,也不要把任务答案混入提示词。
先确认用户要“转写提示词”还是“直接执行任务”:
- 用户明确说“提示词、prompt、转写、优化问法”时,直接开始转写。
- 用户只随口提出需求、没有表达转写意图时,先给一个二选一问题:
“你希望我 A. 直接完成这件事,还是 B. 把它改写成可复制的提示词?”
- 用户选 A 时停止使用本 skill,按原任务处理;用户选 B 时再执行以下工作流。
- 还存在关键缺口时,把意图确认和缺口问题合并到同一轮,合计最多 1–3 题。
工作流(五步)
严格按顺序完成五步;遇到关键缺口时先提问并等待回答,不要越过缺口生成成品。
① 识别任务类型
执行本步时读取 references/recipes.md 的“类型判别速查”。
先尝试把任务归入且只归入以下一类:学习理解类、工程执行类、决策比较类、猜想探索类、内容生成类。
根据用户真正想得到的结果分类,不要只看表面动词。
代码评审(含 review diff)归入工程执行类,但使用只读评审配方,不套用改码、测试与回滚的默认项。
如果两类或多类都合理,把它视为关键缺口;用一个选择题列出最可能的 2–3 项,
让用户选择,不要自行硬猜。
如果没有一类合理,不要硬塞进最接近的类别:目标仍不清楚时,把它视为关键缺口反问;
目标已经明确时,退出类型配方,直接按通用五要素结构转写,只选与任务直接相关的 1–3 个催化剂,
并在解说中说明“未套用五类配方”。
② 诊断五要素缺口
执行本步时读取 references/five-elements.md 的定义和缺口诊断表。
逐项检查目标、背景、材料、限制、验收,并准备“处理方法”。逐项检查不等于逐项输出。按缺口等级处理:
- 目标含糊,或因信息不足、多类歧义而判不出任务类型:作为关键缺口反问。目标清楚但五类均不匹配时,走第①步的零类出口,不为分类而反问。
- 一次问完所有关键缺口,只问会实质改变成品的内容,共 1–3 个选择题。
- 每题给出 2–3 个互斥、易选的选项;不要改成开放式审讯。
背景 是条件字段。先区分用户个人背景(身份、能力、偏好)、任务场景背景(受众、既有环境、组织场景)和完成任务所需上下文。预算、人手、时间等资源上限属于 限制;代码、日志等任务材料与完成标准分别放入 材料、验收,不要混入背景。
- 对候选背景执行“删除测试”:删去后,如果解释难度、方案选择、风险边界或输出对象仍基本不变,就在成品中省略整行。
- 背景必须提供增量信息,不得复述已在
目标 或 材料 中表达的信息;任务对象或领域名称已经写入目标时,不再单独改写成背景。
- 只保留用户明确提供或可由任务直接确定、且通过删除测试的背景。不得因本 skill 的来源、任务领域或用户语气,默认推断用户是新手、专家或具备特定身份和能力。
- 背景缺失且不同取值会产生两种以上明显不同的成品:作为关键缺口反问;否则直接省略,不写“未提供”。
- 限制或验收缺失:按任务类型作最小合理补全,并在对应行标
【推断】。
- 材料缺失:保留
<粘贴代码/报错/日志/截图/素材> 一类可替换占位符。
- 不要虚构代码、数据、报错、版本、链接、用户偏好或项目事实。
会话内调用时执行“上下文收割”:在进行中的任务会话里被调用、且上文已包含相关任务信息时——
- 先按严谨类证据分级:用户亲述的需求、操作或观察结果,以及能由上文展示的代码、配置、日志或命令输出直接佐证的信息,可以收割为事实;用户亲述只证明“用户如此说明、观察或执行”,不得自动升级为已验证根因。
- 把已确认的文件路径、函数名、报错关键原文、日志位置、构建/测试命令、已做的修改写入成品对应字段(材料、bug 现象与失败观察入
材料,命令入 处理方法 或 验收)。这些写入不算虚构;反之,明明在上文且通过下述删除测试却只留占位符才是失职。
- AI 自身未经验证的断言不是已确认事实:默认不收割;确有后续验证价值时只能标为“候选方向”或“待验证”,并说明缺少的证据或验证方法,不得改写成确定结论。
- 上文中的猜测和已被排除的方向默认不收割。仅当排除结论对新会话有防绕路价值时,才以一句“已排除:<方向>(依据)”写入
限制。曾经确认但不确定是否仍然有效的信息,写入时标 【推断】 或“待验证”。
- 报错、日志、diff 等长材料只摘录能支持当前任务的关键片段,保留理解片段所需的最小上下文,并注明来源位置(如文件与行号、日志路径与时间戳、生成命令或测试名);不要仅因材料出现在上文就内联全文。
- 对每项候选收割内容执行“删除测试”:删去后若不会改变目标、处理路线、风险边界、验收判断,也不能防止重复绕路,就省略;该准绳适用于全部收割内容,不只适用于
背景。注意回溯只回退对话、不回退文件:上文中发生过的旁支文件改动会残留在工作区,写明它们可防止新会话把这些无来由的 diff 当异常追查,这计入“防止重复绕路”。
- 成品必须自包含:默认用户会回溯(rewind)或新开上下文后再发送,不得出现“上面、刚才、这个”等依赖旧对话的指代;bug 现象、已做修改等关键信息要内联写全。
- 上文里不存在的材料(diff、测试输出、日志片段等)仍留
<...> 占位符。
- 把“核对收割的路径、命令与事实是否仍然准确”纳入解说末行;与其他末行提醒同时触发时按第⑤步合并,不另占一行。
收到关键缺口答案后,从第①步重新核对分类,再继续转写。
③ 检查并纠正反模式
执行本步时读取 references/anti-patterns.md,逐条检查 AP1–AP8。
在转写中纠正所有命中的反模式。不要只删除问题表述,要用对应的正向结构替换它。
命中多条时,在解说中只点名影响最大的 1–2 条,给 3–5 行总预算让路。
尤其保留以下纠正方向:用户要求推荐时,先比较再推荐;只比较时停在比较结果。删掉夸张角色入口,把模糊祈使换成
可验证动作,并把方法名翻译为动作。不要因为通用模型偶尔能自发做到就省略约束。
④ 转写生成
重新读取 references/recipes.md 中已判定类型的配方和模板;
执行“处理方法”时读取 references/catalysts.md 的对应配方与翻译表。
按以下顺序组织可复制提示词,其中背景按删除测试决定是否出现:
目标:写清做什么、怎么看、做到什么程度。
- 可选的
背景:只放通过删除测试的用户个人背景或任务场景背景;无实质影响时整行省略。
材料:放用户提供或会话中已确认的任务材料;缺失时只放占位符。
限制:优先写可逐项检查的正向标准(长度、结构、术语处理、"待验证"标记),保留 1–2 条关键禁止;写资源上限、边界和安全默认,不写死工具调用步骤。
处理方法:按任务配方选择 1–3 个催化剂,并写成具体动作。
验收:写可观察的完成标准。
用户点名“第一性原理、批判性思维、费曼学习法”等方法时,查翻译表后只写
它要求 AI 执行的具体动作;不要把方法名本身当成有效指令。
当任务命中“回答容易太泛、遗漏维度、没检查总量、状态/事件/条件关系不清、缺少阶段耗时分解”等症状时,读取 references/domain-structures.md,把合适的观察结构(耗时预算表、状态转移表、资源平衡表、坐标表等)写进 处理方法 或 验收;表中无法从用户材料确认的项标“待验证”,只保留结构中真正有用的约束,不搬整套行话。结构不能替代真实材料:缺代码、日志时仍保留占位符。
根据目标环境调整限制与验收:
- 面向会改文件的 coding agent 修改/调试任务时,强调最小修改、运行测试和失败回滚;只读代码评审使用评审专用限制与验收,不加入改码或回滚要求。
- 面向聊天 AI 时,强调理解难度与输出结构。
- 无法判断目标环境时,使用聊天 AI 的措辞,不为此新增问题。
当成品要求推荐、筛选候选方案或反驳指定方案时,在“处理方法”中加入一次独立反方审查,并把它计为一个严谨类催化剂。先匹配审查目标,不要凭空增加推荐:
- 推荐审查:主分析者形成初步推荐;审查者尝试推翻它;最终说明最强反方观点、反驳是否成立以及最终推荐是否改变。
- 筛选审查:主分析者形成初步候选集;审查者挑战纳入/排除理由和筛选阈值;最终说明候选集是否改变。
- 指定方案反驳:当用户把一个明确指定的方案或既有结论作为非对称攻击对象时触发,即使用户不要求判断原结论是否改变;不先生成推荐,审查者直接攻击该对象,不得比较或展开替代方案;最终说明反驳成立范围,并按用户要求说明原判断是否改变。若用户明确禁止改判结论,只报告反驳成立范围。
- 只比较时不触发:只要求对全部候选项做对称比较、不要求推荐或筛选,也未把其中某一项作为非对称攻击对象时,不加入独立反方审查。对全部候选项逐项、对称地列出反方观点仍属于只比较,不能仅因出现“反方观点”一词就误判为指定方案反驳。
执行审查时遵守:
- 环境支持多 agent 时,派发一个未参与初步分析的子 agent;只给它问题、候选项或指定方案、评价标准、已知证据和待审查的初步结果,要求它寻找隐藏假设、最强反例、失败条件和改选/改筛阈值。
- 环境不支持子 agent 时,主分析者在初步结果后单独执行同一份红队审查,避免一边主张一边替自己辩护。
- 主分析者综合审查结果,逐项说明哪些反驳成立、哪些不成立,以及初步结果是否改变;不要直接粘贴审查者原文。
如果用户描述“聊到一半忘了要求、越聊越偏”等长对话跑偏症状,把下面的重置锚点
放在提示词最开头:
现在切换任务,忽略前文风格,以下只以本条为准
如果用户描述、或会话内可直接观察到当前执行出现“AI 修着修着跑去处理别的问题、越干越偏”等语义漂移症状(多见于长 agent 任务),在 限制 中加入主线锚点:“当前唯一目标:。处理中发现的其他问题:先记录到候选问题列表;除非会阻塞当前任务,否则不要立即处理;每完成一个阶段,重新检查是否更接近验收标准。”旧对话已积累大量错误假设时,把“建议新开会话,只带确认过的事实和必要材料”纳入解说末行,并按第⑤步与其他末行提醒合并。
如果用户能描述现象但明确表示不知道它的专业名称、且后续要做工程分析,按 references/recipes.md 的“引导采样 → 上下文回滚”配方输出两条提示词:第一条只负责给现象“起名字”(整理事实、给 5–8 个候选概念、区分证据状态),在两条之间提醒用户“拿候选术语对照代码和日志核实后,新开一个干净会话再发第二条”;第二条在干净会话中用已确认事实与候选方向做工程分析,并要求把事实、证据和推测分开写。
如果任务属于猜想探索类,必须输出两条提示词:
- 两条都必须包含目标、材料、限制、处理方法、验收;背景分别执行删除测试,不能为凑齐字段而推断。
- 第一条只发散,明确禁止评分、排序、推荐和最终结论。
- 在两条之间写“等 AI 展开完再发第二条”,并允许用户补充筛选偏好。
- 第二条才按明确标准收敛,要求推荐 1–2 个方向、执行独立反方审查,并给出理由、适用边界与第一步行动;其限制、验收及筛选标准中凡非用户或上一轮明确提供的内容,均标
【推断】。
- 不要把发散、比较、评分和推荐重新塞回同一条提示词。
⑤ 对照解说
执行本步时读取 references/examples.md:普通完整字段任务只对照例 1 的完整字段结构和口吻,不照搬其中的软件服务对象、材料或排查维度;
会话收割且面向 coding agent 的任务对照例 6;弹性格式对照例 7;猜想探索类同时对照例 4;“引导采样 → 上下文回滚”两段式对照例 8。
只对照匹配场景的口吻、标题、信息完整度和紧凑度,不把其他示例中的缺失材料或占位符迁移过来。
把“改动说明”严格控制为 3–5 行,每行写一个可核对的变化:
- 说明原需求缺了什么,以及补了什么或留下了什么占位符。
- 说明影响最大的 AP 编号及纠正动作;未命中反模式时不要硬凑编号。
- 需要时说明任务类型、催化剂或两段式选择带来的关键变化。
- 最后一行提醒用户发送前检查全部
【推断】 行并替换所有 <...> 占位符。
多条末行提醒同时触发时,必须合并为同一句且只占“改动说明”的最后一行,包括:
检查 【推断】 与占位符、核对收割内容、建议新开会话。触发新开会话时,统一写成
“核对后只带确认过的事实和必要材料新开会话发送”,不再同时要求回溯发送;未触发时再提醒核对后回溯发送。
不要在解说中复述整条提示词,也不要展开讲解方法论。用户想系统学习时,指向
上述对应 reference,不要把重型清单复制进回答。
输出契约
不要添加寒暄、任务答案或长篇前言。
弹性格式:当任务同时满足“单一明确目标、无需收割或粘贴任何材料、无特殊限制”时(如让 AI 解释一个概念),成品可压缩为 2–3 行自然语句(做什么 + 怎么做 + 怎么算完成),不必逐项列五要素标签;改动说明相应压到 2–3 行。信息多、面向 coding agent、或成品将进入回溯后干净上下文的任务,仍用完整字段——标签在冷启动上下文里帮模型快速定位约束,在短任务里只是仪式感。
普通任务只按下面顺序输出:
─── 优化后的提示词(直接复制)───────
```text
目标:...
[背景:...(仅在通过删除测试时保留;实际输出时不保留方括号)]
材料:...
限制:...
处理方法:...
验收:...
```
─── 改动说明 ───────────────────
· ...
· ...
· ...
猜想探索类把第一部分改为“提示词 1(先发散)”与“提示词 2(再收敛)”两个独立代码块;两条都写出目标、材料、限制、处理方法、验收,背景按删除测试决定是否出现,
在两者之间保留等待提示;末尾仍只给一个 3–5 行“改动说明”。“引导采样 → 上下文回滚”两段式同样输出两个独立代码块,中间保留“核实候选术语后新开干净会话再发第二条”的提醒。
交付前核对:提示词是主角,解说是配角;催化剂共 1–3 个;所有推断已标记;
所有缺失材料仍是占位符;背景均通过删除测试;限制以正向可检查标准为主、未堆砌“不要”;领域结构只在命中症状时加入且不可确认项已标“待验证”;需要推荐、筛选或指定反驳时已加入对应的独立反方审查;
探索类没有过早收敛;长对话症状已加重置锚点;语义漂移症状已加主线锚点。