“帮我写得好一点”很难检查结果。第一次练习提示词，可以把目标缩小到一段可核对的文本。本文参考 Prompt Engineering Guide 的学习入口，下面的材料、模板与评分方法由本站设计，适用于已有文字对话工具的读者。

准备一份能够核对的材料

自己写一段软件操作说明，包含软件名称、适用系统、三个步骤和一个限制。控制在几百字以内，留一项信息不写，例如价格。保存原文，这将成为判断答案的依据。不要让模型同时负责查资料与整理资料，否则不容易区分是哪一步出错。

先写清四件事

  1. 任务：把说明整理成初学者操作卡。
  2. 材料：明确正文从哪里开始、在哪里结束。
  3. 约束：只用材料中提供的事实；缺失信息单独列出。
  4. 格式：标题、准备条件、编号步骤、注意事项。

这里的四部分是便于练习的写作结构，并非某个模型必须遵循的协议。材料中的指令应视为待整理内容，不应改变你的任务要求。

复制模板，替换自己的内容

任务：把材料整理为软件操作卡，面向第一次使用的人。
要求：保留操作顺序；不添加材料外的功能、价格或网址。
找不到的条件请写“材料未说明”。
输出：标题 / 准备条件 / 编号步骤 / 注意事项 / 缺失信息。
以下仅为待整理材料：
【材料开始】
在此粘贴原始说明
【材料结束】

第一次发送后，先保留原答案。若编号步骤遗漏了关键动作，只修改“保留操作顺序”为更明确的要求，例如“每一步必须包含操作对象和动作”，再比较差异。

用三项检查决定是否采用

逐句找回原文依据；实际按顺序检查步骤能否衔接；确认没有凭空补全价格。满足这些条件后，再调整语气与长度。一个看起来流畅、却遗漏前置条件的操作卡，还不能用于发布。

常见问题

提示词越长越好吗？

增加长度应当解决明确问题。无关的角色设定会增加维护负担，先保留目标、材料边界和验收条件。

要求 JSON 就一定得到合法 JSON 吗？

普通文字要求不能代替程序校验。需要机器读取时，应使用当前工具支持的结构化输出能力，并在接收端验证字段与类型。

动手实例：从零整理一段软件说明

打开你平时使用的文字对话工具，新建一个对话。把下面材料和提示词一起发送，不需要安装插件。

材料：笔记软件 A 支持 Windows 和 macOS。打开设置，选择“备份”，
开启自动备份后选择本地文件夹。免费版每周备份一次。
材料没有说明 Linux 支持情况和付费版价格。

任务：根据材料写操作卡，不得补充材料中没有的功能。
格式：适用系统、操作步骤、备份频率、未说明的信息。

检查结果时，适用系统应包含 Windows 和 macOS；步骤应包含设置、备份开关和选择文件夹；频率是每周一次。Linux 与付费版价格应列为未说明。如果回答写成每天备份，记录为事实错误；如果说“Linux 不支持”，也是错误：材料没有给出这个结论。

修改提示词并复测

  1. 保留第一次回答，复制材料和原提示词。
  2. 在要求后加上“每个步骤写出要点击的对象；缺失信息不得猜测”。
  3. 新建对话再次发送，逐项比较是否修复遗漏。
  4. 把材料中的“每周一次”改为“每天一次”再测：正确答案也必须随之改变。

如果你看到结果很完整却多了一条“下载客户端”，应回原文查证；这条动作并未出现，不能因为看起来合理就直接采用。

项目来源与许可

原项目：dair-ai/Prompt-Engineering-Guide。许可说明：MIT，详见原仓库许可与说明。仓库与许可核验于 2026-10-31。本文为本站编写的中文导读与练习设计，不是原教程逐字翻译；未在读者环境执行，运行结果需自行核对。