提示词语法是什么？一套中文提示词结构与写法
简答：提示词语法不是固定编程语法。先写清任务，再补充上下文、约束和输出格式；涉及 API 或绘图工具时，必须按对应接口或界面的规则填写，不能把括号权重等写法直接套用。
定义：提示词语法是人向 AI 表达任务、输入内容和输出要求时使用的结构与格式规则，但不同模型、接口和绘图工具支持的写法并不完全相同。
先看结论：提示词语法不是一套统一规则
如果你搜索“提示词语法”，最容易混淆的是把三种不同内容当成了一种语法：普通对话中的自然语言结构、程序调用时的 API 消息格式，以及某些 AI 绘图界面的专属写法。
| 类型 | 主要写法 | 能否直接通用 | 先检查什么 |
|---|---|---|---|
| 文本对话 | 任务、背景、输入、约束、输出格式 | 通常可以迁移，但仍需复核效果 | 模型是否理解任务和格式要求 |
| API 调用 | 按接口要求组织消息、字段和数据 | 不能跨接口直接套用 | 官方接口文档中的字段和消息角色 |
| AI 绘图 | 正向词、负向词、权重、界面专属标记 | 不能跨工具默认通用 | 当前界面、模型和扩展的语法说明 |
OpenAI 将提示定义为触发模型响应的输入，并建议使用清晰、具体、包含必要上下文的表达；AWS 也把指令、上下文、输入数据、输出格式和角色设定列为常见组成部分。OpenAI 提示工程最佳实践、AWS 提示词组成说明
最稳妥的判断：自然语言提示词没有像编程语言那样固定的关键字和标点；只要换成 API 或绘图工具，就要以对应官方文档、界面提示或项目说明为准。
一条中文提示词的通用结构
普通文本任务可以按下面的顺序组织。不是每次都要写满六项，但任务越复杂，越需要补充背景、边界和输出要求。
- 角色：说明回答应采用什么视角，例如“你是一名技术文档编辑”。角色不是必需项，只有当专业范围或表达风格需要固定时才加入。
- 任务：用动词说清楚要完成什么，例如“把下面的会议记录整理成待办清单”。
- 上下文：提供受众、场景、已有资料、限制条件或判断标准。
- 输入：明确哪些文字、数据或代码需要处理。
- 约束：规定不能做什么，以及长度、语言、语气、范围等要求。
- 输出格式：说明要返回表格、清单、JSON、分段文本，或指定字段。
可直接复制的通用模板：
你是【角色】。任务：请完成【具体任务】。背景：使用场景是【场景】，读者是【受众】，已知信息有【背景】。输入：```【待处理内容】```要求：1. 使用【语言和语气】。2. 控制在【长度】以内。3. 不要补充输入中没有依据的事实。输出格式：按【字段、步骤或表格列】返回。OpenAI 建议提示词清晰具体，并通过查看结果后继续调整；这意味着模板的作用是减少遗漏，不是要求每个任务都使用固定句式。OpenAI：如何为 AI 模型创建好的提示
Markdown、XML、三反引号和 JSON 怎么选
这些符号大多首先是分隔内容，是否会被特殊解析，要看具体模型、接口或应用。不要因为某个示例使用了 XML 标签，就推断所有工具都会把标签当成正式语法。
| 写法 | 适合做什么 | 注意事项 |
|---|---|---|
| Markdown 标题和列表 | 组织任务、步骤、规则和输出要求 | 主要提升可读性，不等于新增模型能力 |
``` 三反引号 | 隔离代码、日志、长文本或待处理数据 | 输入内容内部如果出现相同围栏，要改用其他分隔符 |
| XML 风格标签 | 区分背景、资料、要求和输出区域 | 标签名称应保持一致，是否有特殊解析能力要以工具说明为准 |
| JSON | 要求结构化字段，或向支持 JSON 的接口提交数据 | 必须遵守合法 JSON 格式；文本对话中写 JSON 不代表一定能得到合法 JSON |
例如，处理用户提供的日志时，可以写成：
任务：找出日志中的错误原因。<日志>```text【粘贴日志】```</日志>输出：返回“错误现象、可能原因、下一步检查”三列表格。如果后续程序要读取结果，应进一步规定字段和类型，例如“只返回包含 error、cause、next_step 三个字段的 JSON，不要添加解释文字”。但能否严格保证格式，仍取决于所用模型和调用方式，不能只靠提示词作绝对保证。
三组错误提示词与可复制改写
示例一：任务太模糊
原写法：帮我写一下这篇文章。
改写：
请把下面的产品说明整理成一篇给初学者看的中文教程。要求：先给一句话结论，再写 4 个步骤；每步包含操作、目的和注意事项；不要编造输入中没有出现的参数。输入：```text【产品说明】```示例二：没有指定输出格式
原写法：分析这份销售数据。
改写：
请分析下面的销售数据，只根据输入内容回答。输出四部分：1. 总体变化；2. 增长或下降明显的项目；3. 可能原因；4. 还需要补充的数据。其中第 2 部分使用表格，列为“项目、变化、依据”；无法判断的内容标记为“信息不足”。示例三：把多个任务混在一句话中
原写法：帮我改写、总结、翻译并判断这段内容有没有问题。
改写：
请按顺序完成以下任务：1. 用 80 字以内总结原文；2. 将总结翻译成英文；3. 指出原文中需要核对的事实，不要直接判断为错误；4. 最后给出一版语气正式的中文改写。原文：```text【原文】```改写的核心不是增加形容词，而是把“做什么、依据什么、输出什么”拆开。任务复杂时，也可以先让模型只完成第一步，再根据结果发出下一条指令。
零样本、少样本和角色设定怎么用
| 策略 | 写法 | 适用情况 | 常见问题 |
|---|---|---|---|
| 零样本 | 直接描述任务和要求，不给示例 | 摘要、改写、翻译、普通分类等规则较直观的任务 | 特殊格式或风格不稳定 |
| 少样本 | 先给一到数个输入与期望输出示例 | 固定标签、特定语气、特殊字段排列 | 示例之间不一致会造成混淆 |
| 角色设定 | 声明视角、受众或工作身份 | 需要统一专业深度、表达风格或审查标准 | 角色不能代替事实资料和明确任务 |
少样本示例要尽量保持输入、输出结构一致；角色设定则应配合具体任务和判断标准。不要只写“你是专家”，却不说明要检查什么、输出什么。
提示词相关内容可以继续参考本站的陌生概念讲解提示词、代码审查提示词和报错排查提示词，观察同一套“任务—输入—约束—输出”结构如何用于不同场景。
AI 绘图中的括号、权重和正负向词不是通用文本语法
部分 AI 绘图界面会提供正向提示词、负向提示词和注意力权重等写法。例如，AUTOMATIC1111 的项目说明和功能文档记录了括号强调、数值权重、负向提示词以及使用 AND 分隔多个提示片段等功能。项目 README、项目功能文档：Attention/Emphasis
因此，像 (主体:1.2)、((主体)) 或负向提示词，只有在当前绘图界面支持时才有对应含义。它们不能直接复制到普通聊天提示词中，也不能据此推断其他绘图工具采用相同数值规则。
使用前检查三项：
- 当前使用的界面是否明确支持括号、权重或负向提示词。
- 当前模型或扩展是否改变了提示词解析方式。
- 保存示例时是否同时记录界面、模型、参数和原始提示词。
提示词不生效时，按这 5 步排查
- 先确认任务：把“帮我处理一下”改成一个可检查的动作，例如总结、分类、提取或改写。
- 再确认输入：检查待处理文本是否真的放进提示词，长文本是否被截断或分隔不清。
- 补充输出标准：明确字段、顺序、长度、语气和无法判断时的写法。
- 删掉冲突要求：例如同时要求“极其简短”和“完整展开”，应说明优先级。
- 一次只改一个变量：保留原提示词，逐次调整任务、上下文或格式要求，比较结果后再继续。
官方实践建议从初始提示开始，查看响应后迭代优化；所以排查时不要一次修改所有内容，否则很难判断是哪一项改变产生了影响。OpenAI 提示工程最佳实践
常见问题
提示词一定要使用固定格式吗？
不一定。普通对话可以使用自然语言，但复杂任务最好显式写出任务、输入、约束和输出格式。固定模板的价值在于减少遗漏，而不是提供唯一正确语法。
提示词越长，效果一定越好吗？
不一定。缺少背景会导致任务模糊，过多无关内容也可能分散重点。应保留完成任务所需的信息，并删除与目标无关的说明。
Markdown 和 XML 标签哪个更好？
没有适用于所有模型的固定答案。Markdown 更适合人阅读和组织层级，XML 风格标签适合区分多个内容区块；实际选择应以可读性、输入复杂度和测试结果为准。
括号加权能不能用于普通聊天？
不能默认这样认为。括号加权通常是某些 AI 绘图界面提供的专属解析方式，普通聊天模型一般不会因为出现括号就自动提高对应词的重要性。
怎样让模型严格返回 JSON？
同时指定字段、数据类型、是否允许空值和禁止额外文字，并确认所用接口是否提供结构化输出能力。仅在普通文本中写“返回 JSON”，不能保证每次都是合法 JSON。
常见问题
提示词一定要使用固定格式吗？
不一定。普通对话可以使用自然语言，但复杂任务最好明确写出任务、输入、约束和输出格式。
提示词越长，效果一定越好吗？
不一定。应补充完成任务所需的背景，删除无关内容，并避免互相冲突的要求。
Markdown 和 XML 标签哪个更好？
没有统一答案。Markdown 便于阅读，XML 风格标签便于区分内容区块，最终应以实际测试结果为准。
括号加权能不能用于普通聊天？
不能默认这样认为。括号加权通常是部分 AI 绘图界面的专属解析方式，普通聊天模型未必支持。