第三部分 写好提示词08
提示词不是咒语，是需求文档
入门20 分钟第 8 / 19 章
你没写清楚的地方，模型一定会自己补一个。这一章把提示词拆成背景、要求、限制、验收四个部件，再讲清系统提示与用户提示的分工。
学完本章你能做到
- 用「需求文档」的视角诊断一段烂提示词缺了什么
- 独立写出包含四个部件的完整提示词
- 判断哪些内容该放进系统提示，哪些留在当次对话里
学习与练习
从课程目录定位知识点，按章节完成练习，随时接着上次继续。
先理解
你没写清的地方，模型一定自己补一个
模型遇到模糊指令时的默认行为不是反问，而是按概率补全。你说「帮我写个总结」，它就要替你决定：给谁看？多长？什么口吻？保留哪些细节？
于是结果偏离时，多数情况不是模型不行，而是你的「需求文档」缺段落——它只好自己起草那些缺失的段落，而它猜的方向未必是你的方向。
这个视角的实用价值在于：结果不满意时，先别急着换模型、调参数，回头逐句检查自己的提示词——十次里有八九次，能找到一处「我没说，它替我定了」的地方。
先理解
四个部件：背景、要求、限制、验收
一份稳定的提示词，四个部件各就各位：
背景：你是谁、材料是什么、这份输出给谁看。「我是社区运营，以下是本周用户反馈原文，报告给产品团队看。」
要求：做什么、输出什么结构。「提炼三类问题，每类给出出现次数和一条原话引用。」
限制：不要做什么、边界在哪。「不要建议未在反馈中出现的新功能；总长不超过 300 字。」
验收：怎么算做好。「完成后自查：每个结论都能对应到至少一条原话。」
对照这四项检查任何一段提示词，缺哪段就在哪段上跑偏——这是本章最值得带走的一张核对表。
先理解
系统提示与用户提示：优先级不一样
同一个对话框里其实有两种话：
系统提示（system）：每次请求都随身携带，模型对它的服从优先级最高。适合放稳定不变的内容——角色设定、长期规则、输出格式约定、安全底线。
用户提示（user）：当次任务的具体内容。任务描述、材料、临时要求。
常见的坏习惯是把长期约定散落在聊天过程中：「对了，以后都用表格回复」「记住别用感叹号」。这些话隔着几十轮对话就会被稀释甚至遗忘。正确的做法是把它们升级进系统提示，一次声明，轮轮生效。
在网页版聊天产品里，你未必能编辑 system，替代方案是每次新会话开头先发一段「工作约定」，并在关键节点重申。
把烂提示词改成四部件齐全
从下面这段典型烂提示词开始，动手改写。
- 1列出这段提示词没说清的所有事项（受众、结构、长度、口径……）
- 2按背景、要求、限制、验收四部件重写一遍
- 3两版分别发给 AI，对比结果的差距
可直接使用的练习模板
# 背景
我是产品部周会的主持人，以下是本周产品周会的 40 分钟录音转写全文。
整理后的纪要将发给产品总监和各 PM 作为下周跟进依据。
# 要求
1. 按讨论议题分段，每段包含：议题标题、结论、待办事项（含负责人和截止日期）
2. 如果讨论中有分歧，简要记录双方观点和最终决定
3. 结尾列出全部待办清单，按截止日期排序
# 限制
- 不要添加录音中未提及的建议或评论
- 总长不超过 800 字
- 如果录音中某段讨论没有明确结论，标注「待定」
# 验收
- 每个待办事项都有负责人和截止日期
- 每个结论都能在原文中找到对应的讨论段落
---
（在此粘贴 40 分钟产品周会录音转写全文）验收清单
- 改写后的版本四个部件齐全
- 结果不再需要三轮返工才可用
- 能向别人解释「为什么第一版会跑偏」
常见问题
提示词是不是越长越好？
不是。长度本身没有价值，信息完整才有价值。四部件齐全的一段话，胜过堆满形容词的三百字。反过来，与任务无关的长篇背景还会稀释重点、增加费用。
学完后记得保存进度
完了マークはこのブラウザーに保存されます。ログインすると、前回の章と読書位置を記憶します。