06 · 約束與驗收：不許做什麼怎麼寫才生效
五要素裡的最後一格。它治的是幻覺和"自由發揮"，也是最多人從來沒寫過的一格。寫法有講究——光寫"不要編造"效果有限，得給它一條"不知道的時候該怎麼辦"的出路。
一條鐵律：每個禁止，都要配一個替代動作
這是本章最重要的一句。
text
❌ 不要編造材料裡沒有的資訊。這句話本身沒錯，但它只堵死了一條路，沒給新路。模型走到"材料裡沒寫負責人"這一步時，面前是空的——而它必須往下寫，於是還是編了一個。
text
✅ 不要編造材料裡沒有的資訊。
人名、日期、金額只能來自材料原文；材料裡沒有的，一律寫「待確認」。現在它有路可走了。"待確認"這三個字，就是那條替代動作。
再看幾組：
| 只有禁止（弱） | 禁止 + 出路（強） |
|---|---|
| 不要用專業術語 | 不要用專業術語；必須用時，第一次出現後面加一個括號解釋 |
| 不要太長 | 每條不超過一句話；說不完的拆成兩條 |
| 不要下結論 | 不要替使用者下結論；只陳述資料，並在末尾列出"需要人工判斷的地方" |
| 不要遺漏 | 處理完後列一份清單，對照材料逐條打勾，漏掉的補上 |
| 不要瞎猜格式 | 拿不準格式時，按上面模板的第一條示例的樣子寫 |
去看你現在提示詞裡所有以"不要"開頭的句子。每一條後面，都補上一句"那該怎麼辦"。
這是本篇裡改動量最小、提升最明顯的一條。
四類值得寫死的約束
一、事實邊界（最重要）
text
- 只能基於我給的材料，不要引入材料之外的知識；
- 人名、機構名、日期、金額、數字一律照抄原文，不要補全、不要換算、不要推算；
- 材料裡沒有的，寫「待確認」，不要猜；
- 如果材料裡有互相矛盾的地方，兩個都列出來並標註「原文衝突」，不要替我選一個。最後一條很多人沒寫過，但它抓到的問題往往最要命——材料自相矛盾時，模型預設會幫你"抹平"，抹平之後你就再也看不見那個矛盾了。
二、範圍邊界
text
- 只處理我給的這段材料，不要聯想到別的專案；
- 只回答我問的這一個問題，不要順帶給建議；
- 不要輸出與任務無關的內容（問候、免責宣告、後續建議）。三、口徑與立場
text
- 「偏差為負」只如實展示，不要自動標註為"節約"——也可能是少下單或未下單；
- 涉及承諾（工期、價格、責任）的表述，一律用材料原話，不要改寫、不要加強、不要弱化；
- 不確定的地方，明說"我不確定"，並指出需要補充什麼資訊。第一條是從真實場景里長出來的：當介面或文件替使用者下了一個它不該下的結論，損失是實打實的。 你所在行業一定也有這類"看似合理但不能替使用者判斷"的口徑，把它寫死。
四、格式硬邊界
text
- 輸出必須是合法 JSON，不要用程式碼塊包裹，不要有任何解釋文字；
- 表格必須是三列，列名固定為「事項 / 負責人 / 截止」；
- 不使用 Markdown 加粗和標題。把驗收變成一張它要交的表
比"你要遵守以下規則"更硬的做法：讓它自己交一份檢查結果。
text
輸出分兩部分：
一、正文
【按上面的要求寫】
二、自查表（正文寫完後填）
| 檢查項 | 結果 | 說明 |
| --- | --- | --- |
| 所有人名均來自原文，無補全 | 是 / 否 | 若否，指出在哪 |
| 無原文之外的日期和金額 | 是 / 否 | |
| 待辦均有負責人與截止（或標"待確認"） | 是 / 否 | |
| 三個章節齊全 | 是 / 否 | |
自查表裡出現「否」，就直接改正文再提交，不要交帶問題的版本。兩個好處：它在寫的時候就知道會被查什麼；你拿到輸出後，先掃這張表就知道該重點看哪兒。
自查表不能替你核事實
它自查"人名有沒有補全"是可靠的（這是格式性判斷）。它自查"這個數字對不對"是不可靠的——它編的時候就覺得那是真的。
自查表管格式和完整性，事實還是得你自己核。這條在 04 章 也說過，值得重複。
一個反常識：約束不是越多越好
一條提示詞裡塞二十條禁止，效果會開始下降——它的注意力被攤薄了，而且長約束列表裡靠中間的幾條最容易被忽略。
實踐中的分配方式：
| 放哪 | 放什麼 |
|---|---|
| System Prompt | 通用約束（語氣、不要開場白、拿不準要說不確定）——設一次，永久生效 |
| 提示詞正文 | 這個任務特有的約束，控制在 5 條以內 |
| 材料之後的收尾 | 其中最重要的 2 ～ 3 條，再重複一遍 |
| Skill | 這類任務每次都要的整套規矩——寫一次，以後一句話觸發 |
約束超過五條又都必要，通常是訊號：這件事該做成 Skill 了。