Iterative Prompting

迭代提示和「從頭重問」有什麼本質差別？為什麼迭代更有效？

這兩種方式的根本差別在於是否保留和利用前一次的上下文。

當你從頭重問，Claude 對你上一次的輸出、你不喜歡的地方、以及你已經傳達的背景資訊完全沒有記憶。你要重新建立所有的背景，而且你往往不清楚「這次要怎麼問才不會又出現一樣的問題」，結果往往是：新的輸出有些舊問題解決了，但又出現了新問題。

迭代提示的核心優勢是漸進式精化：Claude 記得你說了什麼、已經做了什麼修改，所以每一個追加指令都是在前一個版本的基礎上建立的，不會改了一個地方又退回到另一個問題。這就像和一個人反覆討論同一份草稿，而不是每次都讓他重新寫一份新的。

另一個實用的優勢：在迭代過程中，你能更清楚地理解自己真正要什麼。第一次輸出可能不完美，但它讓你能說「我不要這樣，我要更像這樣的感覺」——這個「看到具體的東西之後才能說清楚的表達」，是讓迭代比一次性提示更有效率的重要原因。

有沒有什麼「好的追加指令」的公式？怎麼說才能讓 Claude 知道要改哪裡？

好的追加指令有一個核心原則：說清楚「什麼地方」有「什麼問題」，以及你要改成「什麼樣子」。三個要素不需要全部都有，但越多越能幫助 Claude 做出精準的修改。

最有效的追加指令格式（從高效到低效）：

「[具體位置] + [問題描述] + [期望方向]」 例：「第三段太學術感，請改成更口語、更直接的語氣，像在和業務夥伴說話」——這三個要素都有，修改方向非常清楚。

「[問題描述] + [期望方向]」 例：「整體語氣太正式，請改成半正式風格，大概是聰明的朋友在提建議的感覺」——缺少位置，Claude 會全面調整，有時候有點過頭。

「[只有期望方向]」 例：「請改得更簡潔一點」——Claude 能猜你的方向，但可能猜錯要簡潔哪裡、簡潔多少。

常用的高效追加指令範例：

• 「第二段字數超過 100 字，壓縮到 50 字以內，保留核心觀點」
• 「開頭太制式，改成用一個具體的問題或情境開場」
• 「結尾沒有行動指引，加一個清楚的下一步建議」
• 「數字和數據的部分不需要解釋，讀者有背景知識，直接呈現就好」
• 「太像 AI 寫的——加入一兩個具體的例子或比喻，讓它更有人味」

一個對話裡應該迭代幾次？有沒有「迭代太多反而沒效果」的情況？

理論上沒有固定的次數限制，但實際上有幾個信號告訴你「這次迭代的方式需要調整了」：

迭代 3-4 次後還是不對的可能原因：

• 你的「期望結果」本身還沒有想清楚——如果你自己都不確定想要什麼，每次追加指令都是在試探，效率就會很低。解法：先花 2 分鐘想清楚你要的最終版本長什麼樣，再回來繼續迭代。
• 問題出在提示詞的結構（例如你給的角色設定和輸出格式有根本矛盾），不是靠追加指令能修復的。解法：開一個新對話，從頭重新設計提示詞結構。
• 你的追加指令每次都在修正不同的部分，沒有累積性——改了語氣，下一次又改結構，再下一次又改語氣。解法：先決定最重要的一個問題，把它修好，再繼續。

迭代「足夠了」的判斷標準： 你拿到輸出後，只需要 30 秒以內的手動修改（加幾個字、換一個詞）就能直接使用，就代表迭代已經完成了。

什麼時候應該開新對話而不是繼續迭代： 當對話已經很長（20 輪以上）、當你發現輸出品質開始下滑（Claude 可能開始受到 Context Window 限制的影響）、或者當你的任務方向完全改變時，開新對話更有效率。

迭代提示適合用在哪些任務？哪些任務反而不適合？

迭代提示和其他提示技巧不同，它是一個過程導向的方法，而不是一個一次性的技術。最適合和最不適合迭代的任務類型：

最適合迭代的任務： 任何「你知道好壞，但說不清楚確切規格」的任務——寫作和文字潤飾（語氣、風格、語氣拿捏）、提案和報告的結構（整體架構是否清楚）、視覺或創意性任務（用 Claude 生成描述，然後逐步調整）。這類任務的好壞通常要「看到了才知道」，所以迭代是最自然的工作方式。

次適合迭代的任務： 有明確格式規範的任務（例如固定模板的填寫）——這類任務更適合用好的 System Prompt 或 Few-Shot 提示詞一次完成，不需要多輪迭代。但如果第一次輸出不完全符合格式，迭代仍然比從頭重問有效率。

不適合迭代的任務： 需要「全部或全無」正確性的任務，例如數學計算、程式碼（邏輯錯誤了就是錯，迭代改語氣沒用）、以及需要實時資訊的查詢（迭代不會讓 Claude 知道它訓練資料截止後的事情）。這類任務如果第一次輸出有根本性的錯誤，應該補充正確資訊、開新對話，而不是用追加指令「修飾」一個根本上就不對的輸出。