system-prompt-creator

系统提示词创建工具

使用源自 Claude（Anthropic）、GPT-5（OpenAI）和 Gemini（Google）官方提示词指南的结构化、研究支持流程，为任意大模型构建有效的系统提示词。

此技能将引导你完成访谈、分析、结构设计、起草和优化，生成清晰、结构良好且针对目标模型定制的系统提示词。

工作流

按顺序执行以下 5 个步骤。每一步都以前一步为基础。

步骤 1：访谈——收集需求

开始撰写前，先向用户收集以下关键信息：

1. 目标模型——使用哪个大模型？（Claude、GPT、Gemini、开源模型或与模型无关）
2. 使用场景——AI 要做什么？（聊天机器人、Agent、内容生成器、数据提取器、代码助手等）
3. 角色设定——AI 应该是什么身份？（角色、专业水平、性格特点）
4. 受众——谁会与其交互？（开发者、终端用户、内部团队、客户）
5. 输入类型——用户会发送什么？（自由文本、代码、文档、图片、结构化数据）
6. 输出格式——回复应是什么样？（散文、JSON、Markdown、代码、表格）
7. 语气和风格——正式、随意、技术性强、友好？简洁还是详细？
8. 约束——它绝不能做什么？（安全规则、话题限制、行动限制）
9. 工具和能力——它能使用哪些工具？（API、文件系统、网络搜索、代码执行）
10. 示例——用户能否提供优质和劣质回复的示例？

如果用户对某些方面的描述含糊不清，请提出合理的默认选项，并在继续前与用户确认。

**力求完整：**收集完基本信息后，询问：“用户还可能会问些什么？”许多提示词之所以失败，并非因为核心任务处理不佳，而是因为没有考虑到相关场景。计费聊天机器人还会遇到账户访问问题、产品问题和投诉。编码 Agent 不仅需要构建功能，还要处理调试、重构和项目设置。撰写前，先梳理完整的需求范围。

步骤 2：分析——确定复杂度和范围

根据访谈内容，对提示词复杂度进行分类：

复杂度	特征	典型长度
简单	单一任务、无需工具、格式固定	50-200 个单词
中等	多种行为、部分工具、输出形式多样	200-800 个单词
复杂	Agent 式、多工具、长时间运行、对安全性要求高	800-2000+ 个单词

然后确定需要哪些部分：

• 角色/身份设定——几乎总是需要
• 背景/知识——需要领域专业知识或背景信息时使用
• 指令/规则——始终需要
• 领域操作手册——系统处理多个不同的操作场景时使用（见下文）
• 输出格式——回复结构很重要时使用
• 示例——准确性和一致性很重要时使用（提供 3-5 个不同示例）
• 工具使用——模型可使用工具或 API 时使用
• 安全/护栏——操作会造成现实影响时使用
• Agent 式行为——模型自主运行时使用

**领域操作手册：**对于处理多个不同工作流的系统（例如，负责构建、调试、重构和审查的编码 Agent；负责处理计费、账户和技术问题的支持机器人），应加入命名明确的操作手册，为每种操作场景提供简洁的分步模式。这能为模型处理常见情况提供可靠的决策树，而不是每次都要求它根据通用指令自行推导方法。将操作手册放在 <instructions> 部分中，并按场景名称分类。

步骤 3：结构——采用分层架构

使用这一通用架构组织提示词。只包含与使用场景相关的部分。

XML 结构（复杂提示词首选）：

<role>
  Who the AI is, expertise, personality
</role>

<context>
  Domain knowledge, background information, constraints
</context>

<instructions>
  Core behavior rules, workflow steps, decision criteria
</instructions>

<output_format>
  Response structure, formatting rules, verbosity guidelines
</output_format>

<examples>
  3-5 diverse input/output pairs covering normal cases and edge cases
</examples>

<tools>
  Tool usage guidelines, when to use each tool, safety thresholds
</tools>

<guardrails>
  Safety boundaries, escalation rules, refusal criteria
</guardrails>

Markdown 结构（适用于较简单的提示词）：

# Role
...

# Instructions
...

# Output Format
...

结构为何重要： 如果提示词混杂了指令、上下文、示例和输入，却没有清晰的边界，模型可能会混淆各部分的用途。结构化标签可以消除这种歧义，并直接提升模型遵循指令的能力。

步骤 4：起草——应用 12 条通用原则

这 12 条原则体现了 3 家主要大模型提供商对有效系统提示词的共识。

A. 结构原则

P1 — 分层架构。 将内容组织为带有明确标签的不同部分（角色、上下文、指令、格式、示例、护栏）。这会直接影响模型解析信息并确定其优先级的方式。

P2 — 标签一致。 始终如一地使用 XML 标签或 Markdown 标题。不要混用不同约定。对层级内容（包含子文档的文档）使用嵌套标签。

P3 — 内容顺序。 将较长的参考资料放在顶部，将任务或查询放在底部。仅此一项就能让复杂的多文档任务质量提升多达 30%。使用锚定短语，例如：“根据以上信息……”

B. 内容原则

P4 — 明确意图与推理。 解释规则存在的原因，而不只是说明规则是什么。相比单纯的命令，模型能更好地从推理中归纳规律。

• 不佳：NEVER use ellipses
• 较好：Responses are read aloud by TTS, so avoid ellipses — TTS engines cannot pronounce them.

P5 — 正向表述。 说明应该做什么，而不是什么不能做。

• 不佳：Do not use markdown
• 较好：Write in smoothly flowing prose paragraphs

P6 — 分级自主权。 对 Agent 式系统，明确划分行动等级：

• 安全（可自由执行）：读取文件、搜索、运行测试
• 中等风险（谨慎执行）：编辑文件、创建分支
• 高风险（必须确认）：删除、强制推送、公开发布内容

P7 — 内部一致性。 矛盾会造成实质性危害。现代模型会浪费推理 token 来尝试调和冲突规则。如果规则有优先级，请明确说明：“如果规则冲突，优先保障用户安全，而非完成任务。”

C. 校准原则

P8 — 让指令强度与模型智能程度相匹配。 现代模型的能力显著增强。针对旧模型的强硬提示（“CRITICAL: You MUST...”）会导致模型过度触发。请使用自然语言。

P9 — 少样本示例。 这是目前最强大的引导方式。提供 3-5 个涵盖边缘情况的不同示例。用 <example> 标签将其与指令分开。有时，示例甚至可以完全取代明确的指令。

P10 — 区分控制维度。 存在三个相互独立的维度：推理深度（模型思考的程度）、输出详略程度（回答长度）和温度（输出多样性）。针对每个维度使用恰当的控制方式，不要混为一谈。

D. Agent 式原则

P11 — 状态管理。 对于长时间运行的任务，定义 Agent 如何跟踪状态。对受架构约束的数据使用结构化格式（JSON），对进度说明使用纯文本，并用 git 创建可恢复的检查点。

P12 — 自我验证循环。 在关键部分结尾加入：“定稿前，请根据[具体标准]检查输出。”这能可靠地发现代码、数据提取和结构化输出中的错误。

E. 特定领域模式

原始数据保留（适用于提取／转换系统）。 设计用于规范化或转换输入数据的架构时，始终在保留规范化值的同时添加一个字段来保存原始值。例如，价格提取应同时存储 "price": 12.50（规范化值）和 "price_raw": "$12.50"（源数据中的原始值）。这样，下游无需重新处理原始输入即可进行验证和调试。

置信度 + 备注（适用于不确定的输出）。 对于处理混乱或含糊输入（OCR、手写内容、噪声数据）的系统，应为每个条目添加 confidence（high/medium/low）和 notes 字段。这样系统便能自我说明——下游使用者可以判断哪些输出可信，哪些需要标记并交由人工审核。默默隐去置信度不如明确说明不确定性。

操作手册（适用于多场景系统）。 当系统处理多个不同工作流时，应为每种工作流定义命名模式，并列出简洁的步骤。编码 Agent 可以有：构建功能、修复 Bug、重构、调试、设置项目。支持机器人可以有：回答问题、处理退款、升级至人工、处理投诉。操作手册可缩小模型的决策空间，并提升相似请求处理的一致性。

如需了解全部原则及 3 份指南中的详细示例，请阅读 references/principles.md。

第 5 步：审查与优化

交付前，请逐项检查以下清单：

结构与格式：

• 结构清晰 — 各部分使用一致的标签或标题明确划分
• 顺序正确 — 较长的参考材料置于顶部，任务置于底部
• 简洁 — 各部分都有价值；没有冗余内容

内容质量：

• 没有内部矛盾 — 所有指令都能同时遵循
• 正向表述 — 规则说明应该做什么，而不只是应该避免什么
• 附带理由 — 每条不明显的规则都说明“为什么”
• 强度适当 — 除非确实关键，否则不使用不必要的大写或 MUST

完整性：

• 覆盖领域 — 涵盖系统将遇到的所有操作场景（不仅是主要用例，也包括相关情况）
• 包含示例 — 提供 3-5 个不同示例，覆盖常见情况、边缘情况和失败模式
• 处理边缘情况 — 提示词说明了遇到含糊、不规范或超出范围的输入时该怎么做
• 包含操作手册 — 对于多场景系统，为每种工作流提供命名的分步模式

模型与验证：

• 适配模型 — 考虑目标模型的优势和特性
• 可测试 — 能够验证系统是否产生了预期行为
• 测试提示词 — 包含 3-5 个验证提示词及预期行为

如需模型专属的优化建议，请阅读 references/model-specific.md。

快速参考：模型对比

方面	Claude 4.6	GPT-5	Gemini 3
思考	自适应（自动校准）	reasoning_effort 参数	思考级别（low/med/high）
结构	首选 XML 标签	XML 标签或结构化规范	XML 或 Markdown 标题
冗长度	表述自然简洁	verbosity API 参数	默认直接明了
并行工具	表现出色，可通过提示词接近 100%	良好，Responses API 有所助益	未着重强调
风险	可能过度设计	可能过度搜索上下文	温度较低时可能陷入循环
独特优势	子 Agent 编排	工具前导语、元提示	基于事实、跨模态

选择性阅读参考文件 — 不要每次都通读全部文件：

• references/model-specific.md — 用户指定目标模型或需要支持多个模型时阅读
• references/templates.md — 需要用例起始模板时阅读
• references/principles.md — 需要深入了解某项原则时阅读

对于已知模型和用例的简单提示词，通常仅凭此 SKILL.md 中的指南就足够了。

输出格式

向用户展示最终系统提示词时，请包含：

1. 系统提示词 — 放在代码围栏中，便于直接复制粘贴
2. 架构说明 — 简要解释选择这种结构的原因
3. 模型专属说明 — 针对目标模型的任何调整（API 参数、已知特性）
4. 测试提示词 — 提供 3-5 条提示词，供用户验证系统提示词是否按预期工作