Anthropic 最近才釋出了他們在 2025/5/22 開發者大會的完整影片，當時的重頭戲是 Claude 4 模型發布。其中有兩場關於 prompting 教學的演講內容很不錯，這兩場演講從基礎 Prompt 到針對的 Agent 的 prompting ，展現了 prompt engineering 的不同層次，推薦大家一看。以下是我的解讀整理。
第一場: Prompting 101
從 Prompting 基本結構到 Agent Prompting 設計原則
OpenAI GPT-5 API 更新重點整理
OpenAI 於 2025/8/7 推出 GPT-5，包括 ChatGPT 和 API 都同時上線，這裡針對 AI 開發者快速解惑與整理重點。
ChatGPT != API 平台的模型
首先，ChatGPT App 的模型與 API 平台上的模型，並非一一對應，這點常讓開發者搞混。讓我說清楚。在 ChatGPT App 裡，其實是一個系統，包含:
- GPT-5 模型 (這沒有 thinking)
- GPT-5 Thinking 模型
- 內部的 Router 路由模型，會依據用戶問題動態切換不同模型與推理程度
選 GPT-5 時，預設沒有 thinking，但如果你明確要求它 think more 或類似的指示，就會自動改用 GPT-5 Thinking。
選 GPT-5 Thinking 會進行推理，但如果用戶點了「快速取得回答」，則會跳回沒有推理的 GPT-5。
用 GPT-5 Thinking 時，它也會根據問題動態決定 reasoning_effort 推理強度。
另外，在 Introducing GPT-5 公告中的評測文字:
- with thinking 對應 API 平台的 gpt-5 模型 reasoning_effort: high
- without thinking 對應 API 平台的 gpt-5-chat-latest 模型 (注意，這個模型在 API 平台僅供評測用，不建議上 production 使用，因為被閹割掉很多功能包括 function calling 跟內建工具都不支援)
還有個 GPT-5 System Card 又冒出稍微不同的模型名稱有點討厭，System Card 文件中沒有寫清楚對應，以下是我的推測:
- gpt-5-main 對應 gpt-5-chat-latest 模型
- gpt-5-thinking 對應 gpt-5 模型 reasoning_effort 參數是 high
開發者 API 更新重點
模型大小
跟上回 GPT-4.1 一樣，GPT-5 有提供三種模型大小: gpt-5、gpt-5-mini、gpt-5-nano，價錢不同。至於 context window 輸入上限是 400k，輸出是 128k。
reasoning_effort 參數
參數 reasoning_effort 可以控制推理程度，有分 low, medium, high 以及這次新推出的 minimal 可以輸出非常少或甚至沒有推理 tokens，這是專為開發者推出的，注意：這和 ChatGPT App 裡的 GPT-5 (without thinking 那個) 不一樣!
這適合低延遲場景、不需要解釋的確定性任務。OpenAI 甚至直接建議: 原本用 gpt-4.1 可升級為 gpt-5 搭配 reasoning_effort: minimal 使用，成本跟性能上是接近的，prompt 寫法也和非推理模型類似，建議可參考 cookbook: gpt-4.1 prompting guide 對於思考步驟要寫比較詳細。
另外要強調，推理模型的 reasoning tokens 也是算 output tokens 費用的，因此你光看廠商價格表，覺得推理與非推理模型單價 tokens 接近是不實際的，因為推理 tokens 實際上會多好幾倍，例如用 reasoning_effort: high 的話會多達 20 倍以上。
因此對開發者來說，我認為 minimal 可能是更常用的設定，比較好控制成本，有點像是你自己手動 prompt 控制要如何推理的模式。
verbosity 參數
新推出 verbosity 參數(low, medium, high) 可控制 GPT-5 回答的預設長度，ChatGPT 介面上也有對應調整選項。若用戶 prompt 與 verbosity 衝突，會以明確指令為優先。
Function Calling 新功能
1. Custom tools: 使用 function calling 但可以讓輸出不用是 JSON 結構化輸出了! 可以是任意 raw text。
JSON 的疑慮就是會影響模型性能，有時候是多餘的，例如就是要產生 SQL，你再包一層 JSON 就多餘麻。這個新功能將彈性都交給開發者了。對於開發框架設計會有很大的影響。
這還可搭配 context-free grammar 限制格式，讓模型輸出特定 DSL 或結構化語言，超厲害。
2. Tool choice 新增 allowed tools 參數: 可限制模型只能呼叫工具清單中的子集，更好控制用戶可以使用的工具。這設計的主要理由其實是配合 prompt 快取! 如此就不會修改到一開始傳入的工具清單，提升快取命中率。
3. 工具呼叫前的 Preambles 前言輸出: 在呼叫工具前輸出用戶可見的前言，幫助用戶明白模型正在做什麼，特別是在很長的 agent 執行過程中可以提供更好的互動體驗，這會出現在 reasoning tokens 之後，工具呼叫之前。對於 reasoning_effort: minimal 情況下，也可特別增加工具呼叫的準確性。
這個可在 prompt 中調整工具前言的頻率、風格和內容，是要詳細還是簡短皆可。這個功能我認為也將影響開發框架，因為目前絕大多數的範例 code 都假設模型呼叫工具時不會同時有用戶可見的文字輸出，因此我猜有些框架將會有 bug: 要麻是誤判不需要工具呼叫，要麻是不會顯示這個前言。
更多 API Cookbook
Agent 讓 RAG 過時了嗎? 談 AI Coding 的檢索策略
看了一場 Augment Code (也是一家做 AI IDE 的廠商) 來講 “Agentic 檢索” 對比 “傳統 RAG 檢索” 的演講，蠻有啟發的。
在 AI Coding 領域，簡單的工具正在擊敗複雜的 RAG 系統。
AI Coding 的演進歷程
AI Coding 的演進是這樣:
- 2023: Code completion 補全時代，例如 Github Copilot
- 2024: 出現側欄 chatbot 來寫這個檔案的 code
- 2025: 進到 Agent 時代，例如 Claude Code 可以跨多個檔案寫 code
隨著每次演進，IDE 底層檢索的複雜度越來越高。我們知道 LLM 需要正確的 context 才能良好運作(也就是 context engineering)，因為需要設計一套檢索系統，找出當下模型所需要參考的程式碼。
像 code completion 只需要超低延遲的簡單檢索即可，chatbot 時代需要理解更複雜的抽象問題，而 agent 就必須理解整個專案的許多不同部分。
他們對 AI Coding 領域的驚人發現是: 簡單的工具就夠了，Augment 團隊在 SWE-Bench 拿下第一名，論文中寫道:「我們探索了新增各種基於嵌入的檢索工具，但發現對於 SWE-Bench 任務來說，這並不是瓶頸。用 grep 和 find 工具就足夠了」。
近期很夯的 Claude Code、OpenAI Codex、Gemini CLI 也通通沒有用 embedding 模型來做檢索。
程式碼檢索為什麼 grep/find 就夠用? 因為程式碼有很多高訊號的關鍵字詞彙，這些結構化的關鍵字讓 grep 搜尋變得非常有效。
如何管理 AI 專案? AI PM 從確定性工程到應用研究
最近看了幾篇討論 AI 產品經理和 AI 專案管理的內容，最有感的是這句話:「傳統軟體開發是確定性的，但 AI 開發本質上是應用研究」，這根本性的差異改變了一切。
為什麼傳統路線圖 (Product Roadmap) 會失敗？
傳統 PM 會說「我們 9/21 要發布這個 AI 功能」，但問題是：你怎麼為還沒被發現的東西制定 Roadmap？這就像在地圖還沒畫出來的時候就規劃路線一樣荒謬。
AI 開發更像科學研究：
- 進度不是線性的（可能好幾週沒進展，然後突然有突破）
- 成功不是保證的（有時數學本身就不支持你的產品目標）
- 關鍵指標是學習速度，而非開發速度
舉個例子：你想做一個「減少模型幻覺」的功能。在傳統開發中，這可能是個明確的工單。但在 AI 開發中，這是個開放性研究問題，你甚至不知道是否能完全解決。
閱讀全文〈如何管理 AI 專案? AI PM 從確定性工程到應用研究〉愛好 AI Engineer 電子報 🚀 什麼是 AI Evals 錯誤分析 #30
Hello! 各位 AI 開發者大家好 👋
我是 ihower，不知不覺這是第 30 期啦，感謝你一路以來的訂閱與支持 🙏
如果喜歡輕鬆交流和分享最新消息，歡迎加入 Telegram 討論群！
🧭 A Field Guide to Rapidly Improving AI Products
Hamel Husain 分享了真正成功的 AI 團隊的六個評估迭代策略:
- 錯誤分析才是王道，別沈迷漂亮的 dashboard 通用指標
- 最重要的投資：客製化的數據檢視介面
- 讓領域專家直接寫 Prompt
- 用合成數據起步
- 保持評估系統的可信度，用二元判斷取代模糊分數
- 路線圖要數實驗，不是數功能
先建評估基礎設施，再考慮具體功能。聽起來很慢，實際上是最快的路。
❓ AI Evals 課程的 FAQ
Hamel Husain 和 Shreya Shankar 整理了他們 AI Evals 課程 的 FAQ，收集了教 700+ 工程師和 PM 後最常被問的問題。包括:
- 錯誤分析 (Error Analysis) 是王道
- 自建評估介面比現成工具好
- 二元評估 > 李克特量表(1-5分)
- RAG 沒死，只是要用對方法
- 別用現成的通用指標，這些指標對大部分 AI 應用都沒用
🕵️♀️ 什麼是錯誤分析 Error analysis ?
上兩篇都重點提到錯誤分析，我整理了一篇文章來講什麼是 AI 應用評估的錯誤分析。文長請直接看我 blog 文章。
針對沒有標準答案的問答評估(對比有標準答案的是指單選、多選等有固定答案)，這裏不同於常見的 G-Eval 評估方式採用正面表列，根據你的 Criteria 做評估量測打分(例如1~5分有多符合)。
這裏教的方法是先做錯誤分析，拿到具體的負面表列後，後續再針對 “每一種” 失敗模式都來做評估量測和改進。
什麼是 AI 應用評估的錯誤分析 Error Analysis?
最近在上 Hamel + Shreya 的 AI Evals For Engineers & PMs 課程，這應該是市面上最深入探討 AI 應用評估的課程了。以下根據網上有公開的內容，整理一篇精華內容(大約是課程的前1/4內容)。
如果你正在開發 AI 應用，應該都遇過這種情況：產品做出來了，看起來還行，但總覺得哪裡怪怪的。使用者抱怨一些奇怪的問題，但你不知道從何改起。這篇文章要介紹的就是評估和錯誤分析 Error Analysis 系統性方法。
閱讀全文〈什麼是 AI 應用評估的錯誤分析 Error Analysis?〉