Thinkin Markdown

四個月後,Prompt 已經不只是 Prompt:GPT-6 Astra 與 Claude Fable 5.1 的提示引導差異

從兩家旗艦模型提示引導,觀察提示設計如何延伸到自主性、任務邊界與工作流治理,並整理跨模型提示策略

發佈時間 2026-09-05
閱讀時間 17 分鐘
主題 人工智慧

前言

2026 年 5 月 3 日,我寫了一篇〈OpenAI 與 Anthropic 模型提示引導的差異性〉。

當時比較的是:

  • OpenAI GPT-5.5
  • Anthropic Claude Opus 4.7

那篇文章在「一句話總結」中這樣描述兩者的差異:

OpenAI:把目標講清楚,讓模型自己選擇。 Claude:把規格講清楚,讓模型精準照做。

當時這個分類相當實用。

對 GPT 而言,過度指定推理步驟,可能限制模型的判斷空間;對 Claude 而言,提供清楚的背景、限制、格式與範例,通常能讓輸出更加穩定。

不過四個月後,當我重新閱讀 GPT-6 Astra 與 Claude Fable 5.1 的模型提示引導,我認為原本這條分界已經不足以描述文件中的建議。

現在的問題已經不只是:

Prompt 應該寫得簡短,還是寫得詳細?

而是:

當模型可以長時間工作、呼叫工具、修改檔案、委派子代理,甚至在執行途中接受新指令時,我們要如何管理它的自主性、工作範圍與完成條件?

本文參考的是兩家公司提供給 API 與 Agent 開發者的文件。這些內容可以幫助我們理解模型特性,但在 ChatGPT、Claude 等一般聊天產品中,實際表現仍可能受到產品本身的 System Prompt、工具與權限設計影響。

⚠️ 本文依據 2026 年 9 月 5 日核對的文件整理,屬於作者解讀而非模型實測,中文提示範例也經過改寫。

一句話總結

如果要重新描述兩者目前的提示引導,我會這樣說:

  • GPT-6 Astra:明確定義權限、指令優先順序與完成條件,讓 Agent 知道什麼時候應該繼續行動。
  • Claude Fable 5.1:明確定義任務範圍與執行規則,避免 Agent 太早停止,或做出超出需求的工作。

這是我綜合兩份文件後的理解,不是兩家公司對模型的官方定位。

兩者的差異仍然存在,但已經不再是單純的「結果導向」與「規格導向」。

它們正在收斂成同一個方向:

把任務、邊界與驗收方式講清楚,再讓 Agent 自己完成中間的工作。

四個月前的結論錯了嗎?

作為當時的提示寫作口訣,它有參考價值,但不能視為兩家模型固定不變的能力分類。

過去我們談 Prompt Engineering,通常關心的是單次輸出:

  • 回答要多長?
  • 要不要使用表格?
  • 是否需要提供範例?
  • 要不要指定推理步驟?
  • 最後應該輸出什麼格式?

而這次閱讀的兩份模型提示引導,合起來涵蓋了另一組問題:

  • 模型應該自己做合理假設,還是停下來詢問?
  • 使用者已經授權的工作,是否還要再次確認?
  • 任務很長時,模型要如何持續完成?
  • 工具呼叫能不能平行執行?
  • 工作過程中要不要提供進度?
  • 對話壓縮時,哪些資訊不能遺失?
  • 發現範圍外的問題時,應該順便修正,還是只回報?
  • 什麼時候應該搜尋,什麼時候可以依靠模型記憶?
  • 驗證與測試應該做到什麼程度?

這些都不是單純的輸出格式問題。

它們是在定義一位 Agent 應該如何工作。

提示重點的轉變:不必預先指定每一個步驟

五月時,我把 Claude 形容成一位「很聰明但剛到職的新員工」,需要一份清楚的工作規格。

到了 Claude Fable 5.1,Anthropic 在 Finish the whole task 章節中提到,只要目標清楚,模型可以在沒有太多方法指引的情況下執行很長的任務。

官方特別提醒的問題,反而是它有時會在任務完成前結束回合、只說明接下來要做什麼,或詢問使用者是否要繼續。

OpenAI 對 GPT-6 Astra 的描述也有類似變化。

OpenAI 在 Introduction 中提到,當指令留有解釋空間時,Astra 會利用既有 Context 補足一般性的資訊缺口。

到了 Initiative and follow-through 章節,官方進一步指出,它在長時間任務中較能維持連貫性,也更可能在關鍵資訊不足時提出確認問題。

這代表兩者都已經不太需要使用者把所有工作流程寫成:

第一步分析需求
第二步搜尋資料
第三步比較結果
第四步檢查遺漏
第五步產生答案

除非執行順序本身就是業務規則或驗收條件,否則模型通常有能力自行規劃。

現在更重要的是告訴它:

要完成什麼?
什麼才算完成?
哪些事情可以自行決定?
哪些事情不能做?
遇到什麼情況才需要詢問?
最後必須提供哪些證據?

因此,我的理解是:Prompt 的重點正在從「教模型怎麼思考」,轉向「定義模型的工作責任」。

GPT-6 Astra:需要管理的是自主性與指令優先順序

GPT-6 Astra 比先前模型更可能在缺少關鍵資訊時提出問題。

這種行為有助於避免模型在重要事項上擅自決定,但也可能造成另一個問題:

使用者明明已經要求它完成工作,模型卻停在分析、計畫或確認階段。

OpenAI 因此建議,若產品希望 Astra 更自主地完成工作,可以明確告訴模型:

  • 從指令與先前對話推斷使用者意圖
  • 對已授權且可逆的工作直接執行
  • 不要只提出計畫或下一步
  • 持續工作,直到使用者要求的成果真正完成
  • 只有在不同答案會實質改變結果時才停下來詢問

另一個值得注意的改變,是 GPT-6 Astra 對 Context 中的指令更加敏感。

OpenAI 在 Instruction following 章節中表示,Astra 更能遵循較長的指令,但也可能更容易受到 Skills、AGENTS.md 與其他檔案中指令的影響。

如果這些規則不清楚或互相衝突,模型可能提早停止工作,或選擇與使用者期待不同的方向。

在現代 Agent 環境裡,模型實際接收到的內容可能包括:

  • System Prompt
  • User Prompt
  • AGENTS.md
  • Skills
  • Tool Description
  • 專案文件
  • 先前對話
  • 其他 Agent 傳回的內容

這些內容全都可能影響模型行為。

因此,OpenAI 建議明確定義使用者要求與 Skill 指引之間的優先順序。當模型因為某項 Skill 或規則停止工作時,也可以要求它指出造成影響的具體指令來源。

這裡可以看到一項明顯改變。

五月時,我們對 GPT 的建議是:

把結果講清楚,不要過度控制過程。

到了 GPT-6 Astra,這個原則仍然成立,但還要再補上一層:

把授權範圍與指令優先順序講清楚,避免模型因為 Context 中的隱性規則改變方向。

Claude Fable 5.1:需要管理的是執行行為

Claude Fable 5.1 的文件採取了不同寫法。

Anthropic 沒有只提供一套理想 Prompt,而是整理出開發者在實際執行時可能觀察到的行為:

  • 工具呼叫之間沒有顯示進度
  • 原本可以平行的工具被逐一呼叫
  • 任務還沒完成就結束回合
  • 對話壓縮後遺失重要限制
  • 額外修改使用者沒有要求的程式碼
  • 替小型修改建立過多測試
  • 在低 effort 下依靠記憶回答,沒有主動搜尋
  • 修改少量內容時重寫整份檔案
  • 在較高推理強度下,長篇輸出可能因推理與正文共用 Token 額度而被截斷

這份文件的重點,是針對實際出現的行為偏差進行校準,讓模型的執行方式更符合任務需求。

例如,Claude 可能在完成需求時,順便修改附近的問題或增加額外測試。

Anthropic 在 Keep changes and tests to what the task asks for 章節中建議:除非範圍外的問題會讓本次需求無法運作,否則不要一併修改,而是在最後摘要中回報。

可以簡化成:

只完成這次需求需要的修改。

如果發現既有問題,除非它會讓本次需求無法運作,
否則不要一併修改,請在最後摘要中回報。

Claude 也可能在長任務中停下來詢問:

要我繼續套用這些修改嗎?

如果原始要求已經包含實作工作,這個問題其實沒有必要。

因此,Anthropic 建議在自主工作時,讓模型完成已授權的可逆操作,遇到破壞性操作、範圍變更或缺少只有使用者能提供的必要資訊時再確認。不過,只是在詢問或討論問題,不代表已經授權模型修改。

五月時,我們擔心 Claude 的 Prompt 太短,導致它不知道該怎麼做。

四個月後,我們開始擔心的是:

Claude 已經很會做了,但它會不會做太多、做到一半停下來,或把時間花在不需要的地方?

兩者現在有多像?

面向GPT-6 AstraClaude Fable 5.1
長任務能力較能在長時間任務中維持連貫性目標清楚時,可以在缺少方法指引的情況下執行長任務
常見中斷原因在缺少可能影響結果的資訊時提出確認問題任務未完成便說明下一步,或詢問是否繼續
自主性調整強調推斷意圖並完成已授權的工作強調完成整個任務,不重複要求許可
指令風險容易受到 Skills、規則檔案與其他 Context 影響可能把任務範圍解讀得太廣,增加額外修改
寫作傾向容易使用較多清單、表格與 Markdown可能段落較長、資訊密度較高,較少主動使用格式
工具使用支援非同步工具呼叫與執行中的中途引導在部分 Agent 工作流中,可能需要提醒它平行呼叫獨立工具
推理控制可在對話中調整 reasoning effort以 effort 控制品質、延遲與成本
上下文管理重視指令來源與優先順序重視對話歷史、Thinking Block 與壓縮摘要
搜尋行為文件未把低推理強度下的搜尋不足列為主要偏差low effort 下可能較少呼叫搜尋或檢索工具
驗證行為可能對小型修改執行比需求更廣的測試可能增加超出任務需求的測試或延伸修改

表格整理的是兩份文件各自強調的重點,不是能力排名;某份文件沒有提到一項問題,也不代表該模型不會遇到。

例如,OpenAI 在 Personality and writing style 中提醒,Astra 傾向使用清單、表格與 Markdown;Anthropic 則分別在 Writing densityFormatting in chat 中指出,Fable 5.1 有時會出現句子較長、段落較密,或較少主動使用標題與清單的情況。

工具使用也有類似差異。

OpenAI 在 What’s new 中介紹 GPT-6 Astra 的非同步工具呼叫與 Mid-turn steering,讓模型在等待工具時仍能處理其他工作,也允許使用者在執行途中補充或修正需求。實際使用仍需產品或執行環境支援。

Claude Fable 5.1 通常也能平行呼叫工具,但 Anthropic 在 Batch independent tool calls in agent loops 中提醒,在某些程式開發與 Computer Use 工作流裡,模型可能把原本可以平行的工具逐一呼叫。

這些細節顯示,兩者的核心方向已經相當接近。

兩份文件都關心如何避免中途停止,並讓工作留在任務範圍內。

對提示設計而言,值得分別檢查的是模型的預設行為,以及應用程式為它準備的 Agent 執行環境。

Prompt 不再只是工作說明,而是一份合作契約

過去的 Prompt 比較像工作說明:

請幫我完成這件事,並使用以下格式輸出。

現在的 Prompt 更像合作契約:

這次要完成什麼。
什麼結果才算完成。
你可以自行決定哪些事情。
哪些行動需要先取得確認。
遇到範圍外問題時如何處理。
工作過程中如何提供進度。
最後用什麼證據證明工作已完成。

這並不表示 Prompt 應該重新變成一份數千字的操作手冊。

相反地,我們應該把不同資訊放回正確的位置:

資訊適合的位置
這次要完成的任務User Prompt
長期合作原則System Prompt
專案特有的限制AGENTS.mdCLAUDE.md
特定領域的工作方法Skill
工具如何使用Tool Description
成果應該長什麼樣Reference、範例或既有產出
如何判斷成果正確測試、Rubric、驗收條件
使用者的長期偏好Memory

這張表是本文根據現代 Agent 架構做出的整理,並不是 OpenAI 或 Anthropic 文件中的原表。

它也延續了〈當繁重的 Prompt 開始礙手礙腳〉的觀點。用本文的話重新整理就是:

Prompt 不需要扮演整個系統的知識庫,它只需要描述這一次要完成的任務。

我們應該如何應對?

建立一套跨模型的共同核心

不要替每個模型維護一份完全不同的巨大 Prompt。

可以先建立共同核心:

# 任務

這次要完成的工作。

# 期望結果

最終應該交付什麼。

# 範圍與限制

可以修改什麼,以及不能做什麼。

# 完成條件

符合哪些條件才算完成。

# 驗證方式

需要執行哪些檢查,並提供哪些證據。

# 協作方式

什麼情況可以自行判斷,什麼情況必須詢問。

這些內容對 GPT-6 Astra 與 Claude Fable 5.1 都適用。

只針對模型偏差增加小型補充

如果 GPT-6 Astra 太容易停下來確認,可以補上:

對不影響最終結果的一般細節,請根據現有 Context 做出合理判斷。

只有當不同答案會實質改變成果、範圍或風險時,才停下來詢問。

完成所有已授權且可逆的工作,不要停在計畫或下一步建議。

如果 Claude Fable 5.1 容易提早停止或擴大工作範圍,可以補上:

完成原始要求中的整個任務,不要在已授權的步驟前再次詢問是否繼續。

不要修改需求範圍以外的內容;若發現其他問題,請在最後摘要中回報。

如果 Claude 在 Agent Loop 中逐一呼叫原本可以同時執行的工具,則可以再加上一條:

彼此不相依的工具呼叫應盡量平行執行。

這比複製整份官方提示範例更容易維護,也比較不會讓不同規則互相衝突。

不要只測答案,要測整個工作行為

比較模型時,不應只看最後答案寫得好不好。

還應該觀察:

  • 是否在不必要的地方詢問使用者
  • 是否能把任務完整做完
  • 是否擅自擴大修改範圍
  • 是否正確使用搜尋與工具
  • 是否留下可驗證的成果
  • 是否提供足夠但不干擾工作的進度
  • 對話變長或壓縮後,是否仍保留重要限制
  • 提高推理強度後,品質是否值得增加的成本

Claude Fable 5.1 的文件提醒,不同模型中的 effort 名稱,不代表相同的思考量。

Anthropic 在 Consider all effort levels 中建議,先從預設的 high 開始,再使用自己的評估案例測試 lowmediumxhighmax

文件也在 Search triggering at low effort 中指出,Fable 5.1 在 low effort 下可能較少呼叫搜尋與檢索工具,轉而依靠模型記憶回答。

遇到需要即時資訊或精確驗證的任務,可以提高該回合的 effort,或在 Prompt 中明確要求搜尋並確認來源。

GPT-6 Astra 則支援在對話期間調整推理強度,也能透過 Mid-turn steering 在模型工作途中提供修正或新需求。

這表示推理強度與任務方向不一定要在開始前一次決定,而可以隨執行狀況調整。

把對話歷史視為系統的一部分

長任務開始普及後,Conversation History 已經不只是聊天紀錄,而是 Agent 的工作狀態。

Anthropic 在 Keep the conversation history append-only 中提醒,在 API 使用情境中,部分新帳號已啟用 Claude Fable 5.1 的 Thinking Block(思考區塊)對話綁定檢查。

在這些帳號中,如果修改先前的指令、工具或訊息,再沿用原本的 Thinking Block,可能發生對話不相符的錯誤。

因此,官方建議讓對話歷史保持 Append-only,也就是保留舊內容,將新回合接在後面。若自行壓縮 Context,可以用摘要重新開始後續對話,不沿用舊的 Thinking Block。

Anthropic 也在 Tell the model what to preserve in compaction summaries 中建議,若由應用程式自行產生壓縮摘要,應明確要求保留:

  • 使用者提出的要求
  • 已經做出的決定
  • 被排除的方案及原因
  • 尚未完成的工作
  • 重要限制與邊界
  • 名稱、日期、數字與連結等細節

這提醒我們:當 Agent 能夠執行數十分鐘甚至更長的任務時,Prompt 寫得好不好,只是其中一部分。

對話如何累積、如何壓縮,以及哪些決定能被保留下來,同樣會影響最後結果。

真正需要學的,不是新版 Prompt 技巧

四個月前,我們還可以把提示策略簡化成:

GPT:描述好結果
Claude:提供清楚規格

四個月後,從這兩份文件的側重來看,我認為這個二分法已經不夠實用。

GPT-6 Astra 的文件強調授權、指令優先順序與自主性設定;Claude Fable 5.1 的文件則指出,目標清楚時,模型可以在較少方法指引下執行長任務。這不表示清楚規格、必要背景與範例已經失去價值。

綜合兩份文件,可以看見它們都在處理同一個核心問題:

當模型從回答問題的工具,變成可以持續工作的 Agent,我們要如何讓它自主完成任務,同時留在正確的邊界內?

因此,我們真正需要建立的能力,不是記住某個模型偏好 XML,或另一個模型偏好簡短 Prompt。

而是學會定義:

  • 任務
  • 權限
  • 邊界
  • 完成條件
  • 驗證方式
  • Context 的來源與優先順序

Prompt Engineering 並沒有消失。

只是它不再負責控制模型的每一步,而是成為整套 Agent 工作環境中的其中一個控制點。

結論

如果五月時的比喻是:

GPT 像成熟助理,Claude 像拿著規格工作的新人。

那麼四個月後,我會換成:

GPT-6 Astra 與 Claude Fable 5.1 都已經像能獨立執行工作的資深協作者,只是兩者需要管理的工作習慣不同。

GPT-6 Astra 需要清楚知道自己擁有多少決定權,以及不同指令之間的優先順序。

Claude Fable 5.1 需要清楚知道任務邊界、何時必須持續執行,以及哪些額外工作不應該順手完成。

模型能力愈強,我們愈不需要告訴它每一步怎麼走。

但我們更需要把一件事說清楚:

你被授權完成什麼、做到哪裡,以及要用什麼證明自己真的完成了。

參考

💭 Model guidance: GPT-6 Astra|OpenAI API

💭 Prompting Claude Fable 5.1|Claude Platform Docs

💭 OpenAI 與 Anthropic 模型提示引導的差異性|Thinkin Markdown

💭 當繁重的 Prompt 開始礙手礙腳|Thinkin Markdown

如果這篇文章對你有幫助,歡迎分享給更多人!

贊助支持

如果你喜歡我們的文章,或是這些內容對你有幫助,歡迎透過以下平台請我們喝杯咖啡,支持我們持續創作!

Ko-fi

作者群

NE

Neil Tsai

樂於分享所見所聞所覺所知的全端工程師

CH

ChatGPT

Neil Tsai 的文章協作夥伴

留言功能需要 Cookie 授權

為了載入留言功能,我們需要您同意使用「功能性 Cookie」。您可以隨時在設定中調整。

推推,這 3 篇也值得你順手看完~

根據相同主題與共享標籤,幫你整理出最相關的延伸閱讀。

免責聲明

本網站對於任何使用或引用本網站網頁資料引致之損失或損害,概不負責。本網站亦有權隨時刪除、暫停或編輯本網站所登載之各項資料,以維護本網站之權益。除法律有強制規定外,在任何情況下,本網站對於 (1) 使用或無法使用本網站之各項服務;(2) 經由本網站取得訊息或進行交易;(3) 第三人在本網站上之陳述或作為;以及 (4) 其他與本網站服務有關之事項所致生之任何直接、間接、附帶、特別、懲罰性或衍生性損害,一概不負賠償責任。

CopyRight © 2026 Thinkin Markdown