如何写出更好的 AI 提示词，起点是一份小型任务说明，而非神奇口令。告诉 AI 工具要做什么、可用哪些信息、必须保留什么，以及你如何判断结果。多数提示词只要收窄任务、让完成标准可见，就能改善。

关键要点

定义一个交付物，并写出可见的完成标准。

只添加相关且已脱敏的上下文。

让限制、格式、示例和复核步骤都可以检验。

在通过你的检查之前，把结果视为草稿。

**示例任务（截图中未显示）：**把一段公开帮助文字改写成面向初学者的说明，保留每一个产品名和数字，并把没有依据的主张标记为 [verify]。

**速记规则：**任务 + 上下文 + 限制 + 格式 + 复核。

1. 写清任务是如何写出更好的 AI 提示词的第一步

用一个动词说明交付物：

较弱：“帮我处理一下这封邮件。”
更好：“把这封客户邮件改写成冷静、专业的语气，控制在 120 字以内。”

说明你要的是草稿、比较、提纲、清单、翻译、信息提取还是批评意见。除非为每个交付物定义了顺序和格式，否则不要在同一轮要求几个无关的交付物。

2. 哪些上下文真正有用？

提供读者、目的、来源材料、截止时间和相关限制。不要加入密码、API 密钥、身份证件、客户记录或机密代码。用占位符替换敏感值，只描述数据的结构。

AI 工具隐私风险指南解释了为什么提示词本身就是一道数据边界。

3. 怎样把限制写成可检查的要求？

避免使用“好看”“专业”“完整”这类未加定义的词，把它们换成可以检查的条件：

含糊要求	可检验的限制
写短一点	100–130 字；保留列出的三项事实
语气友好	使用平实语言；不指责；以一个明确的下一步结尾
加上来源	每条时效性主张附一个来源；没有依据的主张标记 `[verify]`
修复代码	不改公开 API；为边界条件加一个测试用例

如果某项要求比文风更重要，就把它放在最前面，并在复核请求里再次强调。

4. 指定输出格式

明确告诉工具该怎样返回结果。例如：

“返回一张表格，列为 claim、evidence、risk 和 next check。不要编造引用。缺少证据时写 not verified。”

格式能让缺失的信息更容易被发现，也让不同轮次的答案更方便比较。

5. 谨慎使用示例

一个小示例就能展示你想要的细节程度或语气。把它标明为示例，而不是事实。如果示例里有姓名、数字或代码，一律使用虚构内容。不要要求工具模仿真实人物，或照抄受保护的文字段落。

6. 复核环节应该包括什么？

不要让工具默默地“把所有内容再检查一遍”，而要给它一份清单：

列出你所做的假设。
标出需要当前来源支持的主张。
把答案与每条限制逐一对照。
展示相对于所提供文本的改动。
说明哪些内容你无法核验。

这只是复核辅助，不是证明。你仍需亲自打开来源，检查有后果的输出。日期、数字或引用很重要时，按逐条核验主张与来源的方法检查。

7. 分小步迭代

采用三轮模式：

第 1 轮：提纲

要求给出小标题、假设和缺失的输入。在要求成稿之前先修正计划。

第 2 轮：草稿

一次只要求一个章节或一种转换，并把原文放在手边以便对照。

第 3 轮：评估

要求一份限制检查清单和未解决的问题。如果结果仍在编造细节，就停下来，提供更好的来源，或改为人工完成。

8. 把同一个提示词改写三次

看看这条请求：“写一份这次事故的总结。”它没有说明读者、来源边界、篇幅和敏感程度。更安全的第一版改写是：

“只使用下面已脱敏的事故笔记，为内部支持团队起草一份 150 字的总结。把已确认的事实和未解决的问题分开。不要写出客户姓名，不要推断根因，也不要添加笔记中没有的时间线。”

这一版让交付物和排除项变得可见。再加上格式，就能更容易检验：

“返回四个小标题：影响、已确认的时间线、当前缓解措施、未解决问题。每个小标题下使用要点。凡是来源没有回答的字段，在旁边写 [not in notes]。”

最后，加入一轮评估，而不是让模型默默自查：

“草稿之后，列出每一条事实陈述、支持它的笔记，以及任何属于解读的措辞。检查姓名、数字和时间戳没有被改动。”

三条提示词服务于不同阶段：快速头脑风暴不必用最复杂的版本；结果会指导重要决定时，也别只用最短的版本。

9. 让示例安全且有代表性

示例能展示细节程度和输出形状；风险是它可能含真实个人数据，或悄悄变成指令。使用虚构姓名、合成数字和公开文本。把示例标明为示例，并说明哪些事实必须保持不变。

翻译提示词可以附上一小段自编文字，并说明产品名、代码或法律术语是否必须原样保留。代码提示词应提供小型可复现输入和预期输出，而不是整份私有仓库。研究提示词可以提供两个公开来源，要求做一张比较表；不要让工具编造缺失的第三个来源。

模型过于照搬示例时，就缩短示例，用文字描述规则。它忽略某条限制时，把该限制移到单独清单，要求返回“通过 / 未通过”报告。提示词应当暴露失败，而不是用漂亮的演示把失败藏起来。

10. 用输出判断提示词

每次运行后，按事先写明的验收条件给结果打分：

覆盖度： 是否处理了每一个必填字段？
忠实度： 是否保留了事实、姓名、单位和来源边界？
格式： 其他人能否快速检查结果？
不确定性： 是否标出了缺失或有争议的信息？
安全性： 是否避开了秘密、无依据主张和未经授权的操作？

把失败的输出脱敏后保存为测试用例。在友好示例上表现良好、遇到缺失字段就失败的提示词，还不能复用。保留一小组边界案例：空输入、互相冲突的指令、带例外条款的来源，以及一个应当被拒绝的请求。工具、模型或来源格式发生变化时，重新运行这些案例。

11. 使用模板但不要制造虚假的确定感

模板可以把你记得要问的问题标准化，却无法保证答案正确。把“来源”“假设”“复核人”这类字段视为必填输出，而不是它们准确无误的证明。让工具在缺少证据时返回 unknown，并由人类复核人负责判断结果能否使用。

模板要短到同事真的会去读。把任务和风险最高的限制放在最前面。删除不会改变输出的指令，也绝不要求用户粘贴密码、恢复代码、未脱敏的记录或机密源材料。共享模板时，写明它的目标读者、数据边界和停止条件。

12. 把起草和批准分开

再好的提示词也无法授予权限。如果输出将被发布、发给客户、合并进代码或用于某项决定，就把批准作为单独的一步。让工具生成草稿和复核清单，再由人把草稿与来源对照，并批准相应操作。这种分离也让更换工具更容易：即使界面或模型变了，验收条件依然不变。

草稿被拒绝时，用平实语言记录原因；这种失败可能再现，就补一个小测试用例。久而久之，提示词会成为精炼的规格说明，附带可接受和不可接受输出的示例。这份记录比巧妙措辞更有价值，尤其是之后需要别人复核时。

把验收测试放在提示词旁边。

在小样本上测试提示词

复用提示词之前，用几个有代表性的输入测试它，包括一个空字段、一条互相冲突的指令，以及一个应当被拒绝的情况。检查输出是否保留了必需事实、遵循了格式、标出了缺失证据，并且没有编造细节。示例中不要包含秘密和个人数据。小型评估集能在你更换模型、来源格式或读者时暴露退步，比假设一次漂亮的首答能推广到所有情况更有用。

可复用的 AI 提示词模板

任务：[一个交付物和完成标准]
读者：[谁会使用这个结果]
上下文：[相关、不敏感的事实]
限制：[必须保持不变或必须排除的内容]
输出：[格式、长度和顺序]
证据：[可使用的来源；标出缺少支持的地方]
复核：[假设、改动和未解决的问题]

把模板当作起点，而不是仪式。删除不影响任务的字段。

常见失败方式

范围太宽： 答案面面俱到，却什么也没解决。收窄交付物。
读者不明： 语气和细节都不对。写明读者是谁。
不可信输入： 提示词里夹带了来自网页或文件、与你的目标相冲突的指令。把它们当作数据，并重新说明你的任务。
虚假精确： 因为你要求给出数字，工具就编造了一个。要求它在缺少证据时返回 unknown。
没有验收检查： 一份润色得很好的草稿，没满足一项你从未说出口的要求。加一份检查清单。

总结

把提示词写成小而可复核的规格说明：说明任务，加入安全的上下文，定义限制，选择格式，并要求不确定性清晰可见。然后把答案与提示词对照，亲自核验重要主张。

上述提示词模式以所引用的提示词设计、隐私和风险管理指南为依据。［1］［2］［3］

常见问题

提示词越长越好吗？

不是。多余的上下文可能分散工具的注意力，或暴露敏感数据。只放入会改变结果的信息。

应该要求 AI 一步一步思考吗？

需要时，可以要求它给出简洁的理由、假设或检查清单。你不必要求它展示隐藏的推理过程，重点放在可以核验的输出上。

一套提示词能适用于所有 AI 工具吗？

通用原则可以迁移，但各工具的能力、上下文上限、隐私控制和输出格式都不同。请查看供应商当前的文档。

答案出错时该怎么办？

找出第一条错误的主张，提供可靠来源或缺失的限制，然后重新运行一个更小的任务。如果错误持续出现，就停止使用这份输出。

VPN 能改善提示词吗？

不能。VPN 可能保护网络路径，但它不会提升推理能力，也不会改变供应商的账户和产品规则。

免责声明：本文仅供一般信息参考，不构成专业建议。不要向公共 AI 服务发送秘密或未经脱敏的个人、医疗、财务、客户或专有数据。

来源：

Google — Prompt design strategies — https://ai.google.dev/gemini-api/docs/prompting-strategies
OpenAI — Prompt engineering — https://platform.openai.com/docs/guides/prompt-engineering
NIST — Generative AI Profile — https://www.nist.gov/itl/ai-risk-management-framework

Sources checked 2026 年 8 月 22 日。

延伸阅读：

如何写出更好的 AI 提示词：把含糊请求改成可验收的任务说明