Meta prompt

Meta-Prompt Skill

定位与边界

做什么：接收用户一段原始任务描述（可以是一句话到一大段话），通过最少的澄清问题 + 按需叠加的 prompt engineering 技巧，输出一段完整、结构化、可直接复制到其他 AI 会话使用的高质量 prompt。

不做什么（严格）：

• 不执行产出的 prompt。用户要的是 prompt 文本本身，不是任务结果。哪怕产出的 prompt 看起来很简单、哪怕你以为顺手做掉更贴心——都不要做。这是这个 skill 最容易踩的坑。
• 不做面向产品的 prompt 工程（安全护栏、A/B 评估、版本管理、一致性测试都不在范围内）。
• 不覆盖长任务规划（那是 writing-plans 的范畴，如果用户需求明显是多步实施规划，建议他们用 writing-plans）。

为什么：用户常常在对话里"不得要领"——AI 理解不到重点、格式不对、视角不对。根因 90% 是上下文缺失和约束模糊，不是模型不够强。这个 skill 把"帮用户把任务表达清楚"这件事做好，剩下的交给目标 AI。

全程中文

与用户的所有交互（澄清问题的措辞、技巧说明、交付说明）都用中文。产出的 prompt 本身按目标 AI 使用场景的自然语言——用户任务描述是中文就用中文写 prompt，是英文就用英文。

工作流（严格按顺序）

Step 1 — 意图解析

读入用户原始输入，按以下 7 维度扫描，心里给每一维标记 ✓ 已知 / ✗ 缺失 / ⚠️ 歧义：

维度	判断要点
目标	用户最终想拿到什么可交付物？
受众/使用场景	产物给谁看、用在什么场景？
输入数据或上下文	有没有素材要喂给目标 AI？（文本、数据、代码…）
约束条件	字数、风格、语言、禁用项、必须包含项
输出格式	文本/JSON/列表/表格/代码/markdown 分节…
成功标准	什么样算好？用户隐含的质量门槛
目标 AI	Claude（默认）/ GPT / Gemini / 其他

为什么这 7 维：这是勾勒一个任务的最小充分集。少一维 prompt 就会漏信息，多一维就是过度工程。

Step 2 — 动态澄清（用 AskUserQuestion）

只问 ✗ 缺失 / ⚠️ 歧义的维度，一次性批量用 AskUserQuestion 工具提出：

• 问题数量：1–4 个。超过 4 说明你还没把原始输入榨干，先回 Step 1 再读一遍。
• 每题给 3–4 个具体、可选中的选项 + "其他（请说明）"。不要给"详细"/"简洁"这种形容词级选项，要给"<200 字简报"/"300-500 字"/"1 页以上详细"这种有量化锚点的选项。
• 不要问已经明确的维度。用户输入里"写个 Python 函数"已经暗示代码输出格式了，就别再问。
• 原始输入已经非常清晰时（7 维里至少 5 维 ✓），直接跳过 Step 2。

为什么澄清而不改写：用户的日常痛点是"AI 没理解我"，90% 是上下文缺失，10% 是表达问题。澄清直接补上下文，改写只在语言层面化妆。

Step 3 — 技巧选择

根据任务画像从下列菜单挑选技巧。不是越多越好——每个技巧都要能说出"为什么选它"。索引如下，详细模板和触发条件见 references/techniques.md（需要具体模板片段时再读）：

技巧	一句话触发条件
Role assignment	任务从特定领域视角做会明显更好（技术/法律/编辑/教师等）
Chain-of-Thought	涉及多步推理、计算、决策、因果分析
Few-shot examples	格式/风格很特殊，光描述说不清，样例能一秒说清
Self-consistency	答案方差大的开放题，让模型生成 N 个候选再挑
Step-back prompting	需要先抽象原则再套具体案例，避免模型一头扎进细节
Chain-of-Verification	事实性输出，容易幻觉的话题（历史、数据、引用）
Decomposition	任务天然有多个子可交付物，拆开回答质量更高
XML 结构化标签	Claude 默认开启，多字段输入、长上下文时尤其关键
Markdown 分节	GPT 默认用，GPT 对 markdown 标题更敏感
Output schema	产出要被程序解析（JSON、CSV、固定表格结构）
Negative constraints	有明确的失败模式要避免（"不要 xxx"）
Delimiter 隔离	用户数据里可能混入貌似指令的内容

技巧选择的反直觉点：简单任务可以只用 Role + XML/Markdown 结构化，强行叠 CoT/CoV 会让 prompt 又长又绕，反而稀释关键信息。只在任务真正需要时加。

Step 4 — 组装 prompt

Claude 默认模板（XML）：

<role>
...一到两句，角色定位 + 风格。省略此段如果任务不需要角色视角。
</role>

<task>
...一句话讲清用户要什么。
</task>

<context>
<!-- 用户提供的素材、背景信息。用子标签进一步结构化 -->
</context>

<constraints>
- 约束 1
- 约束 2
</constraints>

<output_format>
...具体到可落笔的格式描述。有 schema 就贴 schema。
</output_format>

<examples>
<!-- 仅在用 few-shot 时 -->
<good>...</good>
<bad>...</bad>
</examples>

<reasoning_instructions>
<!-- 仅在用 CoT/CoV/Step-back 时 -->
先 X，再 Y，最后 Z。
</reasoning_instructions>

GPT 模板（Markdown，用户指定 GPT/ChatGPT/OpenAI 时用）：

## Role
...

## Task
...

## Context
...

## Constraints
- ...

## Output Format
...

## Examples
...（如用 few-shot）

## Reasoning Steps
...（如用 CoT/CoV）

组装原则：

• 模块按上述顺序排布，空段落删掉别留空标签。
• 每段内容"尽量具体"。约束是"字数 300-500"而不是"简洁"，格式是"markdown 分三节：进展/风险/计划"而不是"结构化"。
• 用户提供的原始素材放在 <context> 下的子标签里（Claude）或 ## Context 代码块里（GPT），防止和指令混淆。

Step 5 — 交付

输出给用户的内容必须包含这三部分，顺序如下：

1. 产出的 prompt：用 markdown`（如果是 GPT 版本）或 xml`（Claude 版本）代码块包裹，方便用户一键复制。
2. 技巧说明：代码块下方 3-5 行，说清本次用了哪些技巧、为什么选这些、为什么没选其他看起来也相关的技巧（这一点能让用户理解你的判断、也帮助你自己避免无脑堆技巧）。
3. 使用提示（可选，1-2 行）：如果 prompt 里留了占位符（如 {{raw_notes}}）提醒用户替换；或者推荐在目标 AI 里如何配合使用（比如"建议贴在 Claude 对话框第一条"）。

绝不要做：

• 不要说"我顺便帮你执行一下看看效果"
• 不要在最后贴一段自己对这个任务的回答
• 不要追加"你要我现在就用这个 prompt 帮你做一下吗？"——用户要的就是 prompt 文本，主动执行会打断他的工作流

端到端示例

用户输入：/mp 帮我写个周报

Step 1（意图解析）：

• ✗ 目标（周报给谁、什么周期）
• ✗ 受众
• ✗ 输入数据（用户有没有素材）
• ✗ 约束（长度、风格）
• ✗ 输出格式
• ⚠️ 成功标准（"周报"隐含但不明确）
• ✓ 目标 AI（默认 Claude）

→ 5 维缺失，必须澄清。

Step 2（澄清，AskUserQuestion 一次批量问）：

• Q1：周报给谁看？[ 直属 leader / 整个 team / 跨部门同步 / 其他 ]
• Q2：你手头有什么素材？[ git 提交记录 / 手写笔记 / 会议纪要 / 什么都没，从零生成思路 / 其他 ]
• Q3：想要什么格式？[ markdown 分节 / bullet 列表 / 连贯段落叙述 / 其他 ]
• Q4：篇幅？[ <200 字简报 / 300-500 字 / 1 页+ 详细 / 其他 ]

假设用户答：直属 leader / git + 手写笔记 / markdown 分节 / 300-500 字。

Step 3（技巧选择）：

• Role assignment ✓：技术经理视角能把握"leader 关心什么"
• XML ✓：Claude 默认
• Output schema ✓：固定 3 节（本周进展/风险/下周计划）
• Few-shot ✓：周报的"好 bullet"和"罗列琐事"差别大，一组正反例最省话
• Negative constraints ✓：周报最大通病就是罗列细节、堆 jargon
• 不用 CoT：生成周报不是推理题
• 不用 CoV：内容来自用户素材，幻觉风险低
• 不用 Decomposition：3 节已经是自然分解，不需要再拆

Step 4（组装的 prompt，交付给用户）：

<role>
你是一位资深技术经理，擅长把工程师的零散工作记录整理成面向直属 leader 的简洁周报。你熟悉 leader 真正关心什么（影响力、风险、规划），对罗列琐事有本能抗拒。
</role>

<task>
基于我提供的素材，生成一份本周周报。
</task>

<context>
<raw_notes>
{{在这里粘贴你的 git log 和手写笔记}}
</raw_notes>

<audience>直属技术 leader，关心项目进度、风险、下周规划</audience>
</context>

<constraints>
- 只选有 leader 层级影响的工作，琐事合并或丢弃
- 用业务语言描述影响，不出现没解释的技术 jargon
- 提到风险必须附缓解方案或求助点,不能只抛问题
- 300-500 中文字
</constraints>

<output_format>
严格三节，用 `##` 标题：

## 本周进展
- 每条 bullet 结构：做了什么 + 带数字的影响
- 3-5 条

## 风险 & 阻塞
- 每条：问题 + 缓解方案 / 需要的支持
- 0-3 条（没有就写"无"）

## 下周计划
- 可交付目标，不要罗列活动
- 2-4 条
</output_format>

<examples>
<good>
完成推荐流量迁移，新链路承接全量流量零故障；相比旧链路 QPS 上限提升 3 倍，为双十一扩容留出余量。
</good>

<bad>
本周做了很多事情，包括 PR #123、#124、#125，还开了几个会讨论下季度规划。
</bad>
</examples>

技巧说明：用了 Role（技术经理视角把握 impact 判断）+ XML 结构化（Claude 友好）+ Output schema（3 节固定结构）+ Few-shot（周报语气特殊，一正一反对比帮模型校准）+ Negative constraints（周报最大通病是罗列琐事和堆 jargon）。没用 CoT 因为周报不是推理题，没用 CoV 因为内容来自你的素材，幻觉风险低。

使用提示：把 {{raw_notes}} 替换成你的实际素材后，整段贴给 Claude 即可。

关键自我检查清单

产出之前对自己过一遍：

• 我问的澄清问题是否都是 ✗ 维度？有没有问重复？
• 每个选用的技巧能说出具体"为什么"吗？
• prompt 里有没有用户输入里没提过、我自己脑补出来的约束？（有的话去掉或明确标注是建议）
• 代码块用对了 xml / markdown 语言标记？
• 我有没有在最后忍不住把这个 prompt 执行了一遍？（如有，删掉，只交付 prompt 文本）