前言

提示词（Prompt）是人与 AI 之间的"合同"。合同写得模糊，执行就会走样；合同写得精准，AI 才能真正按你的意图行事。

很多人写提示词的方式更像是"聊天"——用自然语言描述一个大概的意思，然后期待 AI 能"领会"。这在简单单次对话上或许够用，但一旦涉及以下场景，这种写法就会频繁翻车：

• 复杂多步骤任务：每一步的输入依赖上一步的输出，任何一步走偏都会导致后续全部失效
• 需要稳定复现的自动化流程：同一套提示词，今天跑和明天跑结果必须一致
• 团队协作共用的提示词：不同人使用同一份提示词，必须得到相同质量的输出

本文提炼了三条核心规范，配合具体示例，帮你写出真正工程化的提示词。

注意：这套规范针对的是"工程化提示词"场景。如果你只是随手问 AI 一个问题，不需要这么严格——规范的价值在于复杂任务的稳定性，而不是让所有对话都变得繁琐。

---

三条规范的关系

在进入具体内容之前，先说清楚三条规范之间的关系——它们不是顺序执行的流程，而是三个独立维度，每一条都必须同时满足：

规范	解决的问题	作用层面
明确结构	AI 不知道该做什么、做完怎么验证	骨架层：提示词的完整性
拒绝柔性表述	AI 对模糊指令只能靠猜	用词层：指令的强制性
拒绝模糊描述	AI 无法将抽象要求转化为具体动作	精度层：描述的可执行性

三条规范缺任何一条，提示词都会有漏洞：结构完整但全是柔性词，AI 仍然会"随机发挥"；用词强制但描述模糊，AI 知道"必须做"却不知道"做到什么程度"。

---

一、明确提示词结构：每个步骤必须包含 8 个环节

很多提示词失效的根本原因是结构缺失——只告诉 AI “做什么”，却没说"怎么验证"、“出错了怎么办”、“最终交付什么”。

一个完整的提示词步骤，必须严格包含以下 8 个环节，缺任何一环即视为不完整，严禁跳过或省略：

环节	说明
① 前置条件检查	确认执行本步骤所需的依赖全部就绪（文件、数据、上下文等）
② 确定目标	明确本步骤要达成的具体目标，必须可量化、可验证，严禁模糊表述
③ 执行前要求	列明所有规范、准入准出标准、约束条件
④ 执行内容	具体操作步骤，每项动作必须精准可落地
⑤ 输出规范	规定输出内容的格式、字段、数量等硬性标准
⑥ 输出检查	对照输出规范逐项核对输出结果
⑦ 自我修复	检查不通过时立即修复，修复次数上限必须明确
⑧ 最终输出	输出经全部检查通过的结果

为什么需要"自我修复"和"最终输出"两个环节？

很多人写到"输出检查"就停了，这里有一个逻辑漏洞：检查发现问题之后呢？

如果没有自我修复环节，AI 检查出问题后不知道该怎么办，可能直接把有问题的结果交给你，也可能陷入无限循环。自我修复环节的关键是限制修复次数——不设上限的修复会让 AI 反复尝试却无法收敛，建议上限设为 2～3 次。

“最终输出"环节看似多余，实际上是一个明确的"交付信号”：只有通过全部检查的结果，才能进入最终输出。这防止了 AI 在修复过程中提前输出中间结果。

示例对比

❌ 结构缺失的写法（只有执行，没有验证和修复）：

分析用户反馈，提取关键问题，输出一份报告。

✅ 8 个环节完整的写法：

【前置条件检查】
确认用户反馈文本已提供，字数不得少于 100 字。若不满足，立即停止并提示"缺少输入材料"。

【确定目标】
从用户反馈中提取问题类型，输出结构化报告 1 份，条目数量不得少于 1 条。

【执行前要求】
问题类型仅限以下 5 类：功能缺陷、性能问题、UI 问题、文案错误、其他。
严禁自行新增类型。

【执行内容】
逐句扫描反馈文本，识别问题关键词，归类至对应类型，每条记录原文摘录。

【输出规范】
输出 Markdown 表格，字段：问题类型 | 原文摘录 | 严重等级（高/中/低）。
条目数量不得少于 1 条，每个字段不得为空。

【输出检查】
逐项核对以下 3 项：
1. 字段是否完整（问题类型、原文摘录、严重等级均已填写）
2. 问题类型是否在规定的 5 类范围内
3. 严重等级是否为高/中/低之一
3 项全部通过 = 通过；任意 1 项不符 = 不通过。

【自我修复】
任意核对项不通过，立即按输出规范重新生成对应条目，修复次数上限为 2 次。
2 次修复后仍不通过，输出当前结果并标注"[待人工核查]"。

【最终输出】
输出全部核对项通过的报告。

---

二、拒绝柔性表述：把"执行感觉"变成"执行标准"

这是提示词工程中最容易被忽视、也最致命的问题。

柔性词是指那些听起来有道理、但实际上无法被精确执行的词。AI 遇到柔性词，只能靠"猜"——而 AI 的猜测不可信、不可控、不可复现。

原因很简单：柔性词把"执行标准"变成了"执行感觉"。“尽量保证格式正确"和"格式必须正确”，对人来说差别不大，对 AI 来说是完全不同的指令——前者给了 AI 偷懒的空间，后者没有。

柔性词黑名单（严禁出现）

建议、可以考虑、尽量、适当、酌情、视情况、一般来说、通常、尽可能、最好、或许、也许

遇到这些词，不是"改一改"，而是直接删除并替换。

替换规则

不同场景有对应的强制性用词：

使用场景	仅限使用
流程推进	务必、必须、立即
禁止行为	严禁、禁止、不得、不允许、杜绝
数量边界	不得低于、不得超过、上限为、下限为
范围限定	仅限、严格限制
核查验证	逐项核对、严格校验、强制验证、零容忍
执行强度	严卡

示例对比

❌ 柔性写法（AI 可以随意解释"尽量"和"适当"的边界）：

尽量保证输出格式正确，建议包含标题和正文，适当添加示例。

✅ 强制写法（每项要求都有明确边界，没有解释空间）：

输出格式必须包含：标题（不得超过 20 字）、正文（不得少于 200 字）、示例（不得少于 1 个）。
3 项全部满足方可输出，任意 1 项不满足，立即重新生成，重新生成次数上限为 2 次。

---

三、拒绝模糊描述：用 SMART + 5W1H 量化每一个要求

模糊词识别标准：凡是无法对应具体数值、具体操作、具体对象的词，一律视为模糊词，严禁保留。

常见的模糊词：正常、合理、相关、适当、一些、多个、较好、简洁……

注意：模糊词和柔性词是两类不同的问题。柔性词是"执行强度不够"（尽量 vs 必须），模糊词是"描述精度不够"（正常返回 vs 状态码 200）。两者都要消灭，但消灭方式不同：柔性词靠替换用词，模糊词靠量化描述。

量化方法：SMART 原则 + 5W1H

维度	含义	模糊表述	量化替换
S（具体）	描述必须指向明确对象	输入正确的账号密码	输入用户名「test001」、密码「Aa123456」，点击「立即登录」按钮
M（可衡量）	结果必须可度量，通过/不通过标准必须明确	检查是否正常登录	接口返回状态码 200，响应时间 ≤ 500ms；2 项全部通过 = 通过，任意 1 项不符 = 不通过
A（可达成）	操作必须有明确的执行依据，不能是抽象判断	合理处理异常	捕获到异常时，记录错误码和错误信息，返回统一错误响应格式 {"code": 500, "msg": "系统异常"}
R（相关）	内容必须与本步骤目标直接挂钩，不得引入无关要求	适当调整提示文案	错误提示字段不得少于 1 个，不得超过 3 个，内容仅限描述当前错误原因
T（有时限）	必须有明确时间或次数边界	多试几次	单条用例执行上限为 2 分钟，修复次数上限为 3 次
Who	明确执行主体	需要处理	由测试人员对登录接口执行功能验证
What	明确操作对象	正常返回	页面跳转至首页，URL 变更为 /home，顶部显示用户名「test001」
When	明确触发时机	出错时	任意核对项不符时，立即记录缺陷
Where	明确作用范围	相关位置	仅限登录页面的「立即登录」按钮
How	明确执行方式	检查一下	逐项核对以下 3 项，全部通过方可标记通过

示例规范

每项要求须附精准可复用示例，示例必须包含以下三要素，缺一不可：

• 输入条件：触发该步骤的具体前提（对应 When + Where）
• 执行动作：逐项列明的具体操作（对应 What + How）
• 预期输出：可验证的具体结果（对应 M）

示例：

【输入条件】
用户提交了一段不少于 200 字的产品反馈文本。

【执行动作】
1. 识别文本中的情感倾向，仅限：正向 / 负向 / 中性，三选一
2. 提取核心诉求，数量不得超过 3 条，每条不得超过 20 字
3. 按优先级排序：高 > 中 > 低，每条必须标注优先级

【预期输出】
- 情感倾向：负向
- 核心诉求：
  ① 加载速度慢（高）
  ② 搜索结果不准确（高）
  ③ 界面字体偏小（低）

---

四、常见错误模式

理解了三条规范之后，再看几个典型的"半对半错"案例——这类提示词表面上看起来没问题，实际上仍然有漏洞。

错误模式 1：结构完整，但全是柔性词

【执行内容】尽量提取所有关键信息，建议按重要性排序，适当过滤无关内容。
【输出检查】检查输出是否基本符合要求。

问题：8 个环节都有，但"尽量"、“建议”、“适当”、"基本符合"让每个环节都失去了约束力。结构是骨架，柔性词是骨架上的漏洞。

修复：

【执行内容】提取全部关键信息，按重要性降序排列，严禁保留与目标无关的内容。
【输出检查】逐项核对：条目数量是否在 3～10 条范围内、是否按重要性降序排列、是否存在无关内容。

错误模式 2：用词强制，但描述模糊

必须确保输出格式正确。
必须保证内容质量达标。
严禁输出低质量结果。

问题：用词很强硬，但"格式正确"、“质量达标”、“低质量"都是模糊词——AI 不知道什么叫"正确”、什么叫"达标"。强制的用词配上模糊的标准，等于"必须做到一个我说不清楚的事"。

修复：

输出格式必须满足：Markdown 表格、3 列（字段名：问题类型 | 原文摘录 | 严重等级）、不得少于 1 行。
严禁输出纯文本段落，严禁省略任意字段。

错误模式 3：量化了数字，但没有通过/不通过标准

输出内容不得少于 200 字，不得超过 500 字。

问题：数量边界有了，但没说"如果不满足怎么办"。AI 可能输出了 150 字，然后认为"差不多够了"就交给你了。

修复：

输出内容不得少于 200 字，不得超过 500 字。
字数不满足时，立即重新生成，重新生成次数上限为 2 次。
2 次后仍不满足，输出当前结果并标注"[字数不达标，请人工审核]"。

---

五、完整综合示例

下面是一个把三条规范全部落地的完整提示词示例，场景是"从需求文档中提取测试要点"：

【前置条件检查】
确认需求文档已提供，文档字数不得少于 300 字。
若不满足，立即停止并输出："缺少输入材料，请提供需求文档后重试。"

【确定目标】
从需求文档中提取功能测试要点，输出结构化列表 1 份，要点数量不得少于 3 条，不得超过 15 条。

【执行前要求】
1. 测试要点仅限以下 4 类：功能验证、边界值、异常场景、性能指标
2. 严禁提取与功能无关的内容（如 UI 样式、文案措辞）
3. 每条要点必须对应需求文档中的具体描述，不得凭空推断

【执行内容】
1. 逐段阅读需求文档，识别功能点
2. 针对每个功能点，分别判断是否涉及以上 4 类测试要点
3. 将识别到的要点记录为结构化条目，每条包含：要点类型、测试描述、对应需求原文

【输出规范】
输出 Markdown 表格，字段：序号 | 要点类型 | 测试描述 | 对应需求原文。
- 序号：从 1 开始连续编号
- 要点类型：仅限功能验证 / 边界值 / 异常场景 / 性能指标，四选一
- 测试描述：不得超过 30 字，必须包含具体操作和预期结果
- 对应需求原文：摘录原文，不得超过 50 字

【输出检查】
逐项核对以下 4 项：
1. 条目数量是否在 3～15 条范围内
2. 要点类型是否在规定的 4 类范围内
3. 测试描述是否包含具体操作和预期结果
4. 对应需求原文是否为文档原文摘录（不得为空）
4 项全部通过 = 通过；任意 1 项不符 = 不通过。

【自我修复】
任意核对项不通过，立即针对不通过的条目重新生成，修复次数上限为 2 次。
2 次修复后仍不通过，保留当前结果并在对应行标注"[待人工核查]"。

【最终输出】
输出全部核对项通过的测试要点表格。

---

总结

三条规范，各自解决一个独立问题，必须同时满足：

规范	解决的问题	核心动作
明确结构	AI 不知道做完怎么验证、出错怎么办	8 个环节一个不少
拒绝柔性表述	AI 对模糊指令只能靠猜	黑名单词汇零容忍，按场景替换强制用词
拒绝模糊描述	AI 无法将抽象要求转化为具体动作	SMART + 5W1H 量化每一个要求

提示词工程的本质，是把你脑子里模糊的"期望"，翻译成 AI 能精确执行的"指令"。这三条规范，就是这个翻译过程的操作手册。

---

附：快速自检清单

写完提示词后，对照以下清单逐项检查，全部勾选方可使用：

结构完整性

• 每个步骤是否包含全部 8 个环节（前置条件检查、确定目标、执行前要求、执行内容、输出规范、输出检查、自我修复、最终输出）？
• 自我修复环节是否明确了修复次数上限？
• 修复次数耗尽后是否有兜底处理（如标注待人工核查）？

用词强制性

• 是否已清除全部柔性词（建议、尽量、适当、酌情、视情况、通常、尽可能、最好、或许、也许）？
• 流程推进用词是否为：务必、必须、立即？
• 禁止行为用词是否为：严禁、禁止、不得、不允许、杜绝？

描述精确性

• 是否已清除全部模糊词（正常、合理、相关、适当、一些、多个、较好）？
• 数量要求是否有明确上下限？
• 输出格式是否有字段级规定（字段名、数量、内容范围）？
• 通过/不通过的判断标准是否明确？
• 每项关键要求是否附有包含输入条件、执行动作、预期输出的示例？

---

如果这篇文章对你有帮助，欢迎点赞收藏。有问题或补充，欢迎在评论区交流。