當 AI 大力稱讚你的草稿時，如何獲得真正有用的回饋

為什麼讚美往往是個薄弱的起點

讚美往往只描述籠統的印象，例如：「清晰」、「引人入勝」、「結構良好」。這些詞彙無法告訴你哪些部分該保留、哪些地方令人困惑，或是讀者讀完後下一步該做什麼。模型也可能只是在附和你提詞中的預設觀點。Anthropic 關於[語言模型阿諛現象的研究](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)指出，研究人員在五款助理模型和四種自由文本任務中都發現了阿諛迎合（sycophantic）的行為，且人類的偏好判斷往往傾向於符合使用者自身觀點的回應。這項發現正是我們要尋求依據與獨立檢查的原因；但它並不代表每一句讚美都是虛假的，也不代表當今所有模型的行為都完全一致。

在實務上，我們必須區分「單純認可」與「可操作的批評」。「這個開頭很吸引人」是認可；而「這個開頭點出了問題，但沒有告訴初次閱讀的讀者這份指南能幫助他們做什麼」則是可供評估的診斷。有用的回饋應該將草稿的具體特徵與讀者的明確需求連結起來，進而提出可行的下一步建議。

五步驟回饋工作流程

1. 設定目標讀者與其任務。

在提供草稿之前，先寫一句話描述這篇文章是給誰看的，以及該讀者在閱讀後應該能夠完成什麼。目標要比單純的「理解這個主題」更明確。例如：「讓第一次擔任志工協調員的人能夠寫出一份清楚的單日活動提醒。」如果你對受眾或預期成果不確定，可以要求模型指出模糊之處，而不是讓它默默臆測讀者身分。

2. 要求提供草稿中的具體依據。

要求模型提出錨定在確切文本段落或章節說明的觀察。詢問目前有哪些內容已對讀者有所幫助，以及草稿在哪些地方讓讀者必須自行猜測遺漏的步驟。這樣你才能對照真實文本進行驗證。一個實用的約束條件是：「如果你無法指出具體段落，請將該意見標註為疑問或推論，而非既定事實。」

3. 找出影響最大的不確定因素。

要求模型指出最有可能阻礙目標讀者完成任務的單一核心問題，並簡短說明其後果。「語氣可以更溫暖一些」通常不如「提醒中從未說明抵達時間，導致志工無法規劃何時到場」來得具操作性。如果模型列出了多個問題，請依照設定的任務排定優先級，而不是試圖一次解決所有問題。

4. 要求進行小幅度、可驗證的修改。

要求提供一個修改方向和簡短範例，而不是自動重寫整篇文章。範例應該在保留既有事實、語氣與限制的前提下展示改動效果。如果範例中引入了新細節，請將其標記為待驗證或待刪除的佔位符。將建議與你的草稿進行比對：只保留那些既能解決既定問題、又不會衍生新問題的修改。

5. 對照原始任務重新檢查。

修改完成後，詢問讀者現在是否能夠完成設定的任務，並要求指出仍存在的阻礙及其依據。你也可以使用簡短的檢查清單親自比對修改前後的版本：關鍵資訊是否存在？是否容易找到？下一步行動是否明確無誤？如果模型在看到修改後的草稿時改變了評估結果，請將其視為另一種參考意見，而非客觀驗證。你始終要為文本的準確性以及是否符合受眾需求承擔最終責任。

可直接套用的提詞範本

貼上目標與草稿，然後提出以下要求：

回饋請求範例：我正在為 [特定讀者] 撰寫內容。讀者在閱讀後應該能夠 [具體任務]。請針對這個目標審閱這篇草稿。首先，找出兩個已經有助於實現該目標的地方，並分別指出對應的段落或具體特點。接著，找出一個最大的阻礙，解釋它對讀者的影響，並指出相關段落。請提出一個聚焦的修改建議，並僅使用草稿中已有的事實提供簡短範例。請將直接觀察與主觀推測區分開來。如果讀者身分、目標或依據不明確，請直接提出疑問，不要自行腦補。請勿重寫整篇草稿，也不要進行籠統的讚美。

結構往往比確切用詞更關鍵：讀者與任務在先，依據次之，接著是優先問題，最後是受約束的具體行動。OpenAI 現行的 [API 提詞工程指南](https://developers.openai.com/api/docs/guides/prompt-engineering) 將提詞工程定義為編寫能夠產出符合需求之回應的指令，並指出模型的輸出具有非確定性（non-deterministic）。這些建議主要針對 API 的使用情境，因此無法保證在所有消費級聊天介面中都完全適用。儘管如此，這項通用的編輯思維依然簡潔且實用：明確列出審核標準，並依據標準檢驗回應，而不是指望單一提示詞就能產生始終如一的評估結果。

實戰範例：改進活動提醒通知

假設草稿內容為：「我們非常高興歡迎大家參加週六的公園清潔活動！帶上你的熱情，一起讓社區煥然一新。現場將提供手套和垃圾袋。期待見到大家！」作者的目標是讓第一次參加的志工清楚知道何時何地集合、該帶什麼，以及流程概況。

如果只問模糊的問題——「這樣寫好嗎？」——可能會讓模型隨聲附和，誇讚這段訊息溫馨且精煉。這或許是事實，但它並不能檢驗志工是否能據此採取行動。依照工作流程所設計的提詞則讓任務變得明確。一個有用的回應會指出，熱情的語氣以及提及提供手套和垃圾袋能減少不確定感；接著點出核心問題在於缺少集合時間與確切集合地點。它應該指出缺乏的關鍵資訊：訊息中只提到了「週六」和「公園」，卻沒有給出抵達時間或公園內的具體位置。

修改時應使用由主辦方確認過的真實細節。此處僅作示範說明，假設主辦方確認時間為上午 9:00、地點在北側入口，並要求志工穿著包頭鞋。作者可以將提醒修改為：「誠邀您於週六上午 9:00 在公園北側入口集合。現場將提供手套與垃圾袋；請穿著包頭鞋。我們將用整個上午沿著標示步道撿拾垃圾。期待您的加入！」這裡的時間、地點和鞋著要求僅為示範輸入，並非真實活動的事實。如果主辦方尚未確認這些資訊，絕不能將其作為事實文案呈現。

現在對照原始任務評估這項修改：抵達時間與集合地點一目了然；所需攜帶的物品已做說明；簡短的描述建立了清楚的預期。如果活動並未規劃標示步道或長達整個上午的行程，就應該修改或刪除該句子。這種檢核能避免模型流暢的建議在不知不覺中將捏造的細節帶入最終草稿。

何時接受、質疑或忽略一項建議

當你能夠將建議回溯至目標讀者的任務、核實其事實依據，並清楚看出提議的修改如何解決問題時，即可採納該建議。如果建議聽起來合理但建立在假設之上——例如聲稱「讀者會希望看到地圖」，而你根本沒有該受眾偏好的依據時——就應該提出質疑。詢問對方有哪些文本段落或任務需求支持這個論點，或者自行判斷是否值得找真實讀者進行驗證。

如果建議與已驗證的事實、既定風格語氣、無障礙需求或文章目的相衝突，請直接忽略或重寫。模型可能擅長產生替代方案，但仍可能誤解上下文脈絡。切勿僅僅因為捏造的數據、引用、引言、截止日期、政策或後勤細節出現在修飾得體的回應中，就將其視為事實。請務必向原始資料查證所有陳述。對於專業內容，請尋求具備該領域專業知識的審核者；泛泛的寫作評論無法確保事實的正確性。

保持修改範圍的小巧集中。集中精力解決與任務最相關的核心阻礙，通常比審閱長長一串逐行修改建議更容易評估。如果你事後希望進行更大範圍的文字潤飾，請將其拆分為單獨的步驟，這樣你才能明確判斷每一處修改究竟是有助於清晰度、語氣還是正確性。

局限性：模型只是審查者，不是你的真實讀者

模型給予的回饋深受提詞影響，且可能前後不一致。它可能會忽略漏洞、提出看似自信卻毫無根據的反對意見，或者偏好某句雖然潤飾得很好但改變了你原意的句子。[OpenAI 提詞指南](https://developers.openai.com/api/docs/guides/prompt-engineering)明確警告，內容生成具有非確定性；沒有任何一種提詞措辭能夠保證提供絕對可靠的評論。前文引用的阿諛現象研究僅針對作者所測試的特定模型與任務，並非對當前所有系統的普遍衡量。

善用模型來激發問題並產生候選修改方案，接著運用人類的判斷力進行裁決。當讀者需求不明確時，找一位特質貼近目標受眾的真實人員進行簡短測試，看看這些說明在實務上是否合理。對於記實類寫作，請核對一手來源。對於涉及真實時程或承諾的訊息，請與負責人確認執行細節。有價值的 AI 審閱能幫你縮小檢查範圍，但它無法為你的草稿背書。

值得銘記的簡單法則

當模型稱讚你的草稿時，要求它將一項優勢和一個主要劣勢與設定的讀者任務及文本中的具體證據連結起來。要求一次進行一項有克制的修改，核實所有新引入的事實，並親自對照任務評估修改成效。讚美可以指引哪些地方奏效，但只有依據、驗證以及具體的讀者目標，才能讓回饋發揮真正的價值。

繼續探索這個主題