前言提示词Prompt是人与 AI 之间的合同。合同写得模糊执行就会走样合同写得精准AI 才能真正按你的意图行事。很多人写提示词的方式更像是聊天——用自然语言描述一个大概的意思然后期待 AI 能领会。这在简单单次对话上或许够用但一旦涉及以下场景这种写法就会频繁翻车复杂多步骤任务每一步的输入依赖上一步的输出任何一步走偏都会导致后续全部失效需要稳定复现的自动化流程同一套提示词今天跑和明天跑结果必须一致团队协作共用的提示词不同人使用同一份提示词必须得到相同质量的输出本文提炼了三条核心规范配合具体示例帮你写出真正工程化的提示词。注意这套规范针对的是工程化提示词场景。如果你只是随手问 AI 一个问题不需要这么严格——规范的价值在于复杂任务的稳定性而不是让所有对话都变得繁琐。三条规范的关系在进入具体内容之前先说清楚三条规范之间的关系——它们不是顺序执行的流程而是三个独立维度每一条都必须同时满足规范解决的问题作用层面明确结构AI 不知道该做什么、做完怎么验证骨架层提示词的完整性拒绝柔性表述AI 对模糊指令只能靠猜用词层指令的强制性拒绝模糊描述AI 无法将抽象要求转化为具体动作精度层描述的可执行性三条规范缺任何一条提示词都会有漏洞结构完整但全是柔性词AI 仍然会随机发挥用词强制但描述模糊AI 知道必须做却不知道做到什么程度。一、明确提示词结构每个步骤必须包含 8 个环节很多提示词失效的根本原因是结构缺失——只告诉 AI “做什么”却没说怎么验证、“出错了怎么办”、“最终交付什么”。一个完整的提示词步骤必须严格包含以下 8 个环节缺任何一环即视为不完整严禁跳过或省略环节说明① 前置条件检查确认执行本步骤所需的依赖全部就绪文件、数据、上下文等② 确定目标明确本步骤要达成的具体目标必须可量化、可验证严禁模糊表述③ 执行前要求列明所有规范、准入准出标准、约束条件④ 执行内容具体操作步骤每项动作必须精准可落地⑤ 输出规范规定输出内容的格式、字段、数量等硬性标准⑥ 输出检查对照输出规范逐项核对输出结果⑦ 自我修复检查不通过时立即修复修复次数上限必须明确⑧ 最终输出输出经全部检查通过的结果为什么需要自我修复和最终输出两个环节很多人写到输出检查就停了这里有一个逻辑漏洞检查发现问题之后呢如果没有自我修复环节AI 检查出问题后不知道该怎么办可能直接把有问题的结果交给你也可能陷入无限循环。自我修复环节的关键是限制修复次数——不设上限的修复会让 AI 反复尝试却无法收敛建议上限设为 23 次。“最终输出环节看似多余实际上是一个明确的交付信号”只有通过全部检查的结果才能进入最终输出。这防止了 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响应时间 ≤ 500ms2 项全部通过 通过任意 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 个环节都有但尽量、“建议”、“适当”、基本符合让每个环节都失去了约束力。结构是骨架柔性词是骨架上的漏洞。修复【执行内容】提取全部关键信息按重要性降序排列严禁保留与目标无关的内容。 【输出检查】逐项核对条目数量是否在 310 条范围内、是否按重要性降序排列、是否存在无关内容。错误模式 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. 条目数量是否在 315 条范围内 2. 要点类型是否在规定的 4 类范围内 3. 测试描述是否包含具体操作和预期结果 4. 对应需求原文是否为文档原文摘录不得为空 4 项全部通过 通过任意 1 项不符 不通过。 【自我修复】 任意核对项不通过立即针对不通过的条目重新生成修复次数上限为 2 次。 2 次修复后仍不通过保留当前结果并在对应行标注[待人工核查]。 【最终输出】 输出全部核对项通过的测试要点表格。总结三条规范各自解决一个独立问题必须同时满足规范解决的问题核心动作明确结构AI 不知道做完怎么验证、出错怎么办8 个环节一个不少拒绝柔性表述AI 对模糊指令只能靠猜黑名单词汇零容忍按场景替换强制用词拒绝模糊描述AI 无法将抽象要求转化为具体动作SMART 5W1H 量化每一个要求提示词工程的本质是把你脑子里模糊的期望翻译成 AI 能精确执行的指令。这三条规范就是这个翻译过程的操作手册。附快速自检清单写完提示词后对照以下清单逐项检查全部勾选方可使用结构完整性每个步骤是否包含全部 8 个环节前置条件检查、确定目标、执行前要求、执行内容、输出规范、输出检查、自我修复、最终输出自我修复环节是否明确了修复次数上限修复次数耗尽后是否有兜底处理如标注待人工核查用词强制性是否已清除全部柔性词建议、尽量、适当、酌情、视情况、通常、尽可能、最好、或许、也许流程推进用词是否为务必、必须、立即禁止行为用词是否为严禁、禁止、不得、不允许、杜绝描述精确性是否已清除全部模糊词正常、合理、相关、适当、一些、多个、较好数量要求是否有明确上下限输出格式是否有字段级规定字段名、数量、内容范围通过/不通过的判断标准是否明确每项关键要求是否附有包含输入条件、执行动作、预期输出的示例如果这篇文章对你有帮助欢迎点赞收藏。有问题或补充欢迎在评论区交流。