06 · 约束与验收：不许做什么怎么写才生效
五要素里的最后一格。它治的是幻觉和"自由发挥"，也是最多人从来没写过的一格。写法有讲究——光写"不要编造"效果有限，得给它一条"不知道的时候该怎么办"的出路。
一条铁律：每个禁止，都要配一个替代动作
这是本章最重要的一句。
text
❌ 不要编造材料里没有的信息。这句话本身没错，但它只堵死了一条路，没给新路。模型走到"材料里没写负责人"这一步时，面前是空的——而它必须往下写，于是还是编了一个。
text
✅ 不要编造材料里没有的信息。
人名、日期、金额只能来自材料原文；材料里没有的，一律写「待确认」。现在它有路可走了。"待确认"这三个字，就是那条替代动作。
再看几组：
| 只有禁止（弱） | 禁止 + 出路（强） |
|---|---|
| 不要用专业术语 | 不要用专业术语；必须用时，第一次出现后面加一个括号解释 |
| 不要太长 | 每条不超过一句话；说不完的拆成两条 |
| 不要下结论 | 不要替用户下结论；只陈述数据，并在末尾列出"需要人工判断的地方" |
| 不要遗漏 | 处理完后列一份清单，对照材料逐条打勾，漏掉的补上 |
| 不要瞎猜格式 | 拿不准格式时，按上面模板的第一条示例的样子写 |
去看你现在提示词里所有以"不要"开头的句子。每一条后面，都补上一句"那该怎么办"。
这是本篇里改动量最小、提升最明显的一条。
四类值得写死的约束
一、事实边界（最重要）
text
- 只能基于我给的材料，不要引入材料之外的知识；
- 人名、机构名、日期、金额、数字一律照抄原文，不要补全、不要换算、不要推算；
- 材料里没有的，写「待确认」，不要猜；
- 如果材料里有互相矛盾的地方，两个都列出来并标注「原文冲突」，不要替我选一个。最后一条很多人没写过，但它抓到的问题往往最要命——材料自相矛盾时，模型默认会帮你"抹平"，抹平之后你就再也看不见那个矛盾了。
二、范围边界
text
- 只处理我给的这段材料，不要联想到别的项目；
- 只回答我问的这一个问题，不要顺带给建议；
- 不要输出与任务无关的内容（问候、免责声明、后续建议）。三、口径与立场
text
- 「偏差为负」只如实展示，不要自动标注为"节约"——也可能是少下单或未下单；
- 涉及承诺（工期、价格、责任）的表述，一律用材料原话，不要改写、不要加强、不要弱化；
- 不确定的地方，明说"我不确定"，并指出需要补充什么信息。第一条是从真实场景里长出来的：当界面或文档替用户下了一个它不该下的结论，损失是实打实的。 你所在行业一定也有这类"看似合理但不能替用户判断"的口径，把它写死。
四、格式硬边界
text
- 输出必须是合法 JSON，不要用代码块包裹，不要有任何解释文字；
- 表格必须是三列，列名固定为「事项 / 负责人 / 截止」；
- 不使用 Markdown 加粗和标题。把验收变成一张它要交的表
比"你要遵守以下规则"更硬的做法：让它自己交一份检查结果。
text
输出分两部分：
一、正文
【按上面的要求写】
二、自查表（正文写完后填）
| 检查项 | 结果 | 说明 |
| --- | --- | --- |
| 所有人名均来自原文，无补全 | 是 / 否 | 若否，指出在哪 |
| 无原文之外的日期和金额 | 是 / 否 | |
| 待办均有负责人与截止（或标"待确认"） | 是 / 否 | |
| 三个章节齐全 | 是 / 否 | |
自查表里出现「否」，就直接改正文再提交，不要交带问题的版本。两个好处：它在写的时候就知道会被查什么；你拿到输出后，先扫这张表就知道该重点看哪儿。
自查表不能替你核事实
它自查"人名有没有补全"是可靠的（这是格式性判断）。它自查"这个数字对不对"是不可靠的——它编的时候就觉得那是真的。
自查表管格式和完整性，事实还是得你自己核。这条在 04 章 也说过，值得重复。
一个反常识：约束不是越多越好
一条提示词里塞二十条禁止，效果会开始下降——它的注意力被摊薄了，而且长约束列表里靠中间的几条最容易被忽略。
实践中的分配方式：
| 放哪 | 放什么 |
|---|---|
| System Prompt | 通用约束（语气、不要开场白、拿不准要说不确定）——设一次，永久生效 |
| 提示词正文 | 这个任务特有的约束，控制在 5 条以内 |
| 材料之后的收尾 | 其中最重要的 2 ～ 3 条，再重复一遍 |
| Skill | 这类任务每次都要的整套规矩——写一次，以后一句话触发 |
约束超过五条又都必要，通常是信号：这件事该做成 Skill 了。