直接答案：Prompt Engineering 是在设计 AI 的执行接口
Prompt Engineering（提示词工程）是把用户目标、必要上下文、行为约束、输出格式和评价标准 组织成模型可执行接口的过程。它不仅是写一句提示词，也包括示例、数据、工具、测试集、权限和失败回退。
六步框架：从任务到失败回退
- 任务：写清用户是谁、要完成什么、什么结果才算完成。不要用“帮我优化一下”代替目标。
- 上下文：只提供完成任务所需的事实、术语、样例和数据，并标明哪些内容可信、哪些未知。
- 约束：规定不能做什么、必须遵守什么，以及权限、隐私、事实边界和时间范围。
- 输出契约：明确字段、顺序、长度、语言、格式和缺失值表达，让下游代码可以稳定读取。
- 评价：用固定样例检查正确性、完整性、格式、依据、安全性和可恢复性。
- 回退：当信息不足、工具失败或风险过高时，规定模型应拒答、请求补充、转人工或返回结构化错误。
一个可复用的提示词骨架
任务
你要帮助哪类用户，在什么场景下完成哪一个可观察的动作。
输入
列出可用资料、时间范围、术语定义和未知项；要求模型不要补写不存在的事实。
规则
给出优先级、禁止事项、引用要求、隐私边界与需要人工确认的条件。
输出
指定字段与格式，并写明信息不足时的返回值，例如“证据不足”而不是猜测。
评价
附上合格、失败和边界样例，说明每个样例为什么通过或不通过。
同一骨架可以用于文章摘要、需求分类、代码审查、活动问答或项目资料整理。 真正需要变化的是任务证据和评价标准，而不是在开头不断叠加“你是一位世界顶级专家”。
评价集比“感觉不错”更重要
至少准备四类输入，并在更换模型、提示词、数据或工具后重新运行：
- 正常样例：代表最常见用户任务，检查基础价值是否成立。
- 边界样例：极短、极长、歧义、多语言或格式异常的输入。
- 缺失样例：故意拿掉关键事实，检查模型是否会承认不知道。
- 对抗样例：尝试绕过权限、诱导泄露数据、改变角色或生成违规内容。
每条输出都应按同一张评分表检查：任务正确性、事实依据、格式合规、关键信息完整度、风险控制和失败后的可恢复性。 如果评价标准无法写清，通常说明产品任务本身还没有定义清楚。
五种常见失败，以及真正应该修哪里
- 回答漂移：先检查任务是否同时包含多个目标，再拆成步骤或工作流。
- 格式不稳：使用明确输出契约并在代码层做 Schema 校验，不要只靠自然语言提醒。
- 事实幻觉：减少开放式补全，提供可引用来源；需要最新或私有知识时接入检索。
- 计算错误：把确定性计算交给代码或工具，模型负责解释和编排。
- 权限越界：在服务端执行身份、数据和操作权限检查，提示词只能说明规则，不能充当安全边界。
从提示词走向系统：什么时候必须升级
当一个提示词开始承担稳定业务价值时，就应该把它产品化：接入经过授权的数据、增加权限、记录版本和日志、设计人工复核与回滚流程。 需要最新或私有知识时使用检索增强；需要确定性计算或外部操作时使用工具；需要多步骤状态时使用工作流； 只有在任务稳定、样本充足且提示词与检索仍无法满足时，再评估微调。
这也是社区项目从 Demo 走向真实落地的关键：不是把一条 Prompt 写得越来越长， 而是让每一类能力、证据和责任落到正确的系统组件上。
发布前检查清单
- 任务、用户和成功条件是否可观察？
- 输入来源、时间范围和未知项是否明确？
- 输出是否有稳定格式和缺失值规则？
- 是否测试正常、边界、缺失和对抗输入？
- 事实、计算、权限和外部操作是否交给合适组件？
- 失败时是否能拒答、补问、转人工或安全回滚？
- 模型、Prompt、评价集和数据版本是否可追踪？
Prompt Engineering 常见问题
什么是 Prompt Engineering？
Prompt Engineering 是把用户目标、必要上下文、行为约束、输出格式和评价标准组织成模型可执行接口的过程。它不仅是写一句提示词，也包括样例、工具、数据、测试和失败回退设计。
提示词是不是越长越好？
不是。长度只有在信息确实帮助模型完成任务时才有价值。重复规则、相互冲突的要求和无关背景会增加歧义；更好的目标是让每段内容都有明确作用。
系统提示词和用户提示词有什么区别？
系统提示词通常承载稳定角色、全局规则和安全边界，用户提示词承载本次任务与输入。产品还应在代码层验证权限和输出，不能只依赖提示词保证安全。
如何判断一条提示词是否稳定？
建立覆盖正常输入、边界输入、缺失信息和对抗输入的评价集，重复运行并检查正确性、完整性、格式、事实依据、安全性和失败可恢复性，而不是只挑一条漂亮结果。
什么时候应该从提示词升级到检索、工具或微调？
当任务需要最新或私有知识、确定性计算、外部操作、严格权限或稳定领域行为时，应分别考虑检索增强、工具调用、工作流和微调；不要继续用更长提示词掩盖系统能力缺口。