prompt-generator

提示词生成器

将用户粗略的想法、零散的笔记或尚未成形的创意整理为清晰、结构良好的大模型提示词。这是一个格式整理与结构化工具，而不是头脑风暴工具——用户已经知道自己想要什么，只是需要帮助润色措辞并整理内容。

适用场景

• 用户有一些粗略笔记、要点或随手记录，想将它们整理为清晰的大模型提示词
• 优化、改写或完善效果不佳的现有提示词
• 根据零散的要求，构建系统提示词、一次性任务提示词、可复用模板、评估器提示词、代码审查提示词或任务委派提示词
• 创建包含变量占位符、可重复使用的提示词模板
• 用户提出类似“帮我写一个……的提示词”“把这段内容改成提示词”或“系统提示词，用于……”的需求

不适用场景

• 功能头脑风暴或创意构思——此技能负责整理提示词，而非创意
• 创建可复用的技能文件或 Agent 指令包（使用 skill-creator）
• 配置计划任务、定期运行和事件触发器——使用宿主的自动化功能。
• 在应用程序代码中编写内嵌提示词字符串——这只是编程
• 用户想要编写调用大模型 API 的代码（使用 llm-app-development 进行 SDK 集成）
• 审查提示词是否存在注入风险（使用 security-audit）
• 审查提示词相关代码的质量（使用 code-review 或 code-simplification）

---

AI 自检

返回任何生成或修改后的提示词文件前，请确认：

• 已保存文件的 Frontmatter 完整：已保存的提示词文件包含 name、description、target_model、prompt_type 和 date_created。内嵌草稿、审查内容和未保存的输出无需 Frontmatter
• 忠于输入：提示词反映用户所说的内容，而不是你认为用户应该说的内容
• 结构与复杂度相符：简单任务使用普通文本，而非带 XML 标签的多段提示词
• 变量一致：提示词正文中的每个 {{PLACEHOLDER}} 都出现在 Variables 表格中，反之亦然
• 没有无关指令：保留用户的语义；只添加满足明确用途所需的最少输出结构，不添加无关的错误处理、免责声明或限制
• 已界定不可信文本：在指示模型采取行动之前，明确框定或标注源文本、用户示例、日志、网页和文档
• 没有冗余套话：提示词文本中不含“当然”“我很乐意”“好问题”或其他填充语
• 已指定输出格式：如果提示词需要结构化输出，应明确指定格式（JSON schema、XML 标签、分隔符）
• 评估标准明确：评估器提示词定义通过/失败标准、所需证据和常见失败模式
• 委派约定清晰：委派提示词定义职责归属、范围、文件、允许的修改以及预期的最终答复形式
• 语法适配模型：仅当用户指定了提供商时，才使用提供商专属功能（助手预填内容、\n\nHuman: 格式）。XML 分隔符和 Markdown 标题均适用于不同模型
• 已落实适用于各类场景的 Agent 规范——参见 references/agent-hygiene.md

---

性能

• 在满足任务要求的前提下，尽量缩短提示词；删除冗余的角色描述和重复限制。
• 对重复出现的动态内容使用变量，而不是复制冗长内容块。
• 需要明确结构时，优先使用清晰的输出 schema，而不是冗长的叙述式指令。

---

最佳实践

• 对于复杂提示词，应包含成功标准，以便评估输出。
• 根据预期用途选择适合的提示词类型；参见 references/prompt-families.md。
• 对于评估器提示词，应使用基于可观察证据的评分标准；参见 references/evaluator-prompts.md。

工作流

第 1 步：阅读脑暴笔记

用户会提供粗略笔记、要点，或一段关于希望提示词实现什么的即兴描述。请解析其中的：

• 核心任务：提示词要让模型实际做什么？
• 目标模型：使用哪个 LLM？默认：除非用户指定，否则不绑定特定模型。
• 提示词类型：系统提示词还是任务提示词
• 约束条件：提到的规则、格式要求或行为边界
• 变量：应转换为 {{PLACEHOLDERS}} 的动态内容

不要添加用户未提及的内容。目标是忠实地整理用户的意图，而不是用你自己的想法“改进”它。

第 2 步：只有遇到困难时才澄清

如果确实存在歧义（例如无法判断这是系统提示词还是任务提示词，或者目标模型会影响技术选择），请提问。将问题合并提出，最多进行 1 轮。如果可以合理推断，就直接推断。若经过这一轮后仍有歧义，选择最合理的默认选项，并说明你的假设，让用户在审核时可以纠正。

大多数时候，完全跳过此步骤。

第 3 步：组织并呈现

1. 根据复杂度，以适当的结构将粗略笔记整理成清晰的提示词：
   • 简单（单一任务，无变量）：使用普通文本，3-10 行。不使用 XML 或分节。
   • 中等（多个步骤或约束）：使用编号步骤和清晰的分节。
   • 复杂（Agent 式、多文档、行为规则）：使用清晰的分隔符、变量占位符和明确的输出格式。
   • 可复用模板：包含变量表和稳定的 {{VARIABLE_NAME}} 占位符。
   • 评估提示词：定义评分维度、通过/失败阈值、失败示例和所需证据。
   • 委派提示词：定义任务、负责范围、涉及的文件、不涉及的文件、允许的修改和输出约定。
2. 根据 AI 自检清单检查草稿。修正所有未通过的项目，并重新检查，直到全部通过。
3. 对于行内草稿或审核请求，直接在对话中呈现提示词，不写入文件。
4. 如果用户要求创建、保存或编辑本地文件，请使用现有授权完成写入。否则，只有在用户要求保存草稿后才保存。
5. 修订时：直接修改原处，不要创建新文件。

第 4 步：保存

1. 如果用户指定了确切文件名，则保持原样使用。否则，按以下顺序确定输出目录： 用户指定的目录 > docs/local/prompts/（仅当 git check-ignore 确认该目录被忽略时）> 询问。绝不要将草稿保存到受版本控制的 docs/ 中。
2. 仅在未指定文件名时，使用 <YYYY-MM-DD>-<slug>.md 格式命名文件，并根据主题推断 slug（例如 code-review）；如果该名称已存在，则追加 -2、-3 等。
3. 写入指定文件名或已确定的 <output-dir>/<YYYY-MM-DD>-<slug>.md。

---

输出文件格式

---
name: Descriptive Prompt Name
description: One-line summary
target_model: model-agnostic
prompt_type: system | task
date_created: YYYY-MM-DD
---

## Purpose

What this prompt does and when to use it.

## Variables

| Variable | Description | Required |
|----------|-------------|----------|
| `{{VAR}}` | What it is | Yes/No |

## Prompt

The actual prompt content here.

仅包含适用的部分。简单且无变量的提示词不需要变量表。

frontmatter 块仅适用于已保存的文件。行内草稿或审核输出不包含 frontmatter，因为没有持久化的文件需要描述。

可选的 frontmatter 补充项：tags: [...]、related: [<YYYY-MM-DD>-other.md]——仅在确实有用时添加。

目标模型取值：claude、gpt、gemini、llama、mistral、model-agnostic

结构化指南

按提示词类型路由。 简单的任务提示词应保持内联。可复用的提示词需要变量。评估器提示词需要评分标准和失败案例。委派提示词需要明确所有权和返回格式。代码审查提示词应先列出发现的问题，并要求提供文件和行号引用。

让复杂度与内容相匹配。 3 行的任务不需要 XML 标签和编号步骤，而多文档 Agent 系统提示词则需要。用户提供的粗略笔记能让你判断复杂度。

长内容放在前面。 如果提示词在运行时会接收大型文档或数据，请将数据槽位放在顶部，将任务说明放在底部。在多文档任务中，性能最高可提升 30%。

解释原因，而不只是说明要求。 如果用户的笔记中包含一条规则（例如“不要使用 Markdown”），就将其转化为有缘由的约束（例如“请使用普通文本，因为输出会输入到 TTS 引擎中”）。模型能从缘由中归纳出通用规则。

Agent 提示词需要边界。 如果提示词面向编码 Agent 或自动化流程，应区分哪些操作可以自由执行（读取、搜索），哪些操作需要确认（删除、发布、推送）。

防止幻觉，一句话就够。 “只提出能从所提供的上下文中验证的说法。如果不确定，请如实说明。”就这样。

特定模型的格式

已知目标模型时，应根据其优势调整格式：

目标	首选结构	备注
Claude	用 XML 标签划分章节，用 Markdown 编写内容	请确认所选模型/API 是否支持预填充；分隔符无法强制执行输出架构
GPT	Markdown 标题，用 JSON 架构处理结构化输出	可使用原生 JSON 模式——优先使用它，而不是散文格式说明
Gemini	Markdown 分节，提供明确的输出示例	将文本指令与附件和图像指令分开
与模型无关	Markdown 标题 + 明确的分隔符	避免预填充、特定模型标签或格式模式标志

咄咄逼人的大写措辞（“CRITICAL!”、“YOU MUST”、“NEVER EVER”）通常弊大于利。请使用平和、明确的指令。

升级模型时，请在相同任务上用固定的成功标准和同一评估器，将现有提示词与更短的变体进行比较。保留证据要求、不可信输入边界和用户指定的范围。只有在观察到特定问题时才添加模型专属规则；新模型并不意味着需要添加更多脚手架。

当用户希望 Agent 在限定范围内工作时，应说明完成条件和停止条件：完成所请求的更改及相关检查，然后停止。明确说明何时需要澄清，以及哪些操作需要批准。除了答案质量，还要衡量不必要的暂停、重复检查和无关编辑。请在宿主/API 配置中设置工作量，不要在散文中写入假装能控制工作量的指令。Sonnet 5.5 指南建议从 medium 开始处理规格明确的 Agent 任务，较难的任务则从 high 开始；请重新评估这些设置，而不是照搬旧的工作量级别。参阅 Sonnet 提示指南。 Haiku 5.5 在 low 工作量级别下会跳过搜索，在较长的 Agent 提示词中会提前停止，也更常跳过验证：搜索任务应提供当前日期，并明确说明完成条件和检查标准。如果需要使用 xhigh/max，请与 Sonnet 5.5 进行比较 （Haiku 提示指南）。 GPT-6 系列指南介绍了 Astra 的观察结果；采用其中的建议前，请先在选定的模型上进行测试。

结构化输出指南

当提示词面向 Agent 使用（而非供人阅读）时，应明确指定输出格式：

• JSON 模式：如果工具支持原生 JSON 模式或受架构约束的输出，请使用该模式。否则，要求模型返回有效的 JSON；只有在工具支持助手预填内容时，才以 { 作为开头。
• XML 结构：使用 <result>、<analysis>、<decision> 等标签包裹输出。
• 基于分隔符：对于简单的键值对，使用 KEY: value 格式。

尽可能在提示词中加入具体的输出示例——与格式说明相比，模型更擅长从示例中归纳。

四块模式

对于中等到复杂的提示词，可将内容分为四个清晰的部分：

1. INSTRUCTIONS - 要执行的操作（角色、任务、约束）
2. CONTEXT - 背景信息、参考数据
3. TASK - 本次调用的具体请求
4. OUTPUT FORMAT - 预期响应的确切结构

使用 XML 标签、Markdown 标题或其他清晰的分隔符，在视觉上区分各部分。将较长的上下文文档放在较短的任务说明之前（参见上文“长内容放在前面”）。

---

优化现有提示词

如果用户提供的是需要改进的现有提示词（而非粗略笔记）：

1. 阅读提示词
2. 找出不足——检查以下常见的提示词弱点：
   • 范围不明确：未清楚界定模型应做和不应做的事
   • 缺少输出格式：模型只能猜测结构，而不是遵循规范
   • 角色模糊：“乐于助人的助手”没有提供有用信息
   • 缺少约束：没有反模式、“不要”清单或质量标准
   • 过度具体：规则过多，反而淹没了重点
3. 对于仅需审查的请求，说明具体的修改建议及理由，不要编辑内容。
4. 对于获准修改本地文件的请求，直接编辑文件，并总结所做的更改。

优化示例：

修改前：You are a helpful assistant that reviews code.

修改后：You are a senior code reviewer. For each file, check for: bugs, edge cases, security issues, and performance problems. Report findings as a list with priority (P0/P1/P2/P3/info), file:line, and a one-line description. Skip style nitpicks. If nothing is wrong, say "No issues found." - 新增了范围、输出格式、优先级等级，以及避免无关反馈的约束。

示例：从零开始创建

用户输入（零散想法）：

我想要一个能帮我写出更好邮件的 AI。它应该纠正语法，让内容更简洁，并符合我指定的语气。有时正式，有时随意。

结构化输出：

You are an email editor. You receive a draft email and a target tone, then return an improved
version.

Your edits:
- Fix grammar and spelling errors
- Make the text more concise - cut filler words and redundant phrases
- Match the requested tone (formal, casual, or neutral)

Preserve the sender's intent and meaning. Do not add information they didn't include.
Do not change the greeting or sign-off style unless it clashes with the requested tone.

Input format:
  TONE: {{TONE}}
  DRAFT:
  {{EMAIL_DRAFT}}

Return only the improved email. No commentary, no explanations, no "Here's your improved email:".

注意：任务简单，因此使用普通文本即可——无需 XML 部分、编号步骤或冗长的前言。

---

输出约定

完整约定请参见 references/output-contract.md。

• 技能名称： PROMPT-GENERATOR
• 交付物类别： prompts
• 模式： 有条件。当调用目的是分析、审查、审计或改进现有仓库内容（例如，审查现有提示词的质量）时，请遵循 references/output-contract.md 中关于报告篇幅和证据的规则，并将交付物写入 docs/local/prompts/prompt-generator/<YYYY-MM-DD>-<slug>.md。当调用目的是回答问题、讲解概念、构建新产物或生成内容（其主要模式——为用户生成提示词）时，可自由作答，不受该约定约束。
• 严重程度等级： P0 | P1 | P2 | P3 | info（参见共享约定；仅用于审计/审查模式）。

相关技能

• skill-creator - 为 AI 工具和编码 Agent 创建可复用的技能文件（SKILL.md）。技能是结构化的提示词，但其约定（前置元数据、工作流章节、规则）与独立提示词不同。如果有人说“创建技能”，请使用 skill-creator。
• 使用宿主的自动化功能设置计划任务和事件触发器。此技能可以帮助编写提示词正文，但不会配置重复执行的任务。
• 应用程序代码 - 如果用户需要在应用程序代码中使用提示词字符串（例如 TypeScript const systemPrompt = ...），这属于编码，而非此技能的用途。
• code-simplification - 如果用户要求“清理”或“简化”嵌入代码中的提示词，这属于代码质量问题，而非提示词结构设计。

---

规则

1. 忠实地组织结构。 保留用户提供的事实和意图。如果未说明输出结构，只推断下游用途所必需的最少结构；如果这种选择可能改变语义，或无法从用途中明确判断，请提问或暂不确定。完善提示词时，如果缺少输出约定导致无法可靠评估，请指出。
2. 尊重现有授权。 用户要求创建、保存或编辑本地提示词文件，即授权执行该写入操作。行内草稿和评审仅在对话中进行。遵循用户的明确指示，而非此技能的默认设置；对于破坏性操作或外部操作，仍须征得批准。
3. 尊重用户的表达风格。 如果粗略笔记有特定的语气或个性，请在结构化版本中予以保留。