好的提示词不是“咒语”，而是一份清楚的任务说明。把模糊需求拆成目标、上下文、要求和检查标准，通常更容易得到可用的初稿。
一个可复用的结构
- 目标：我要得到什么成果？
- 背景：给出必要资料，说明哪些信息可以使用。
- 约束：受众、语气、篇幅、格式与禁止事项。
- 核对：要求标出不确定之处，而不是编造来源。
示例：整理会议纪要
请根据下方会议记录整理纪要。
受众：没有参会的项目成员。
格式：决定事项、待办任务、负责人、截止日期。
只使用原文信息；没有写明负责人或日期时标注“待确认”。
会议记录：[粘贴已脱敏的内容]与“帮我写个会议纪要”相比，这个版本更容易检查是否漏掉关键信息。仍需由人对照原始记录复核。
进阶：让结果更可用
可提供一两个期望输出示例，但应避免在示例中泄露敏感数据。复杂任务先拆成提取、整理和润色几个阶段；如果要求模型引用来源，应提供可核实的原文并逐项核对引用。
别忽略数据边界
未经授权，不要上传客户信息、账号凭据或商业秘密。使用第三方服务时先查阅其数据处理条款，必要时对输入做脱敏处理。
把“大而全”的需求拆开
先提取事实，再检查缺失信息，最后生成给特定受众的文本。每一步都能与原文对照，出了问题也更容易定位。一次性要求生成十种成果，往往让核对成本上升。
例子：结构化提取
从下方通知提取标题、时间、地点。
只输出 JSON，字段名为 title、time、location。
没有出现的值使用 null，不推测。
通知：项目复盘会将于周五在三楼会议室召开。这里“周五”仍是相对日期，不能在没有基准日期时自动改成具体年月日。程序应验证 JSON 是否能解析、字段类型是否正确；重要日期还应人工确认。
收到错误回答怎么办？
指出具体错误并补足依据，要求只修订相关部分。若多次重试仍不正确，调整任务或更换方案，不要不断追加夸张角色设定。用于自动化时，提示词之外还要有代码验证与人工复核。