愛好 AI Engineer 電子報 🚀 頂級 AI 公司的 Prompting 秘訣和 Cluade Code 正夯 #28

作者:ihower 在〈愛好 AI Engineer 電子報 🚀 頂級 AI 公司的 Prompting 秘訣和 Cluade Code 正夯 #28〉發佈留言

歡迎訂閱 📬 愛好 AI Engineer 電子報 過往期數點這 📚

想系統性學習如何開發 LLM、RAG 和 Agents 應用嗎? 歡迎參考我的課程 大語言模型 LLM 應用開發工作坊

Hello! 各位 AI 開發者大家好 👋

我是 ihower，這一期電子報的內容非常多元豐富，希望大家會喜歡。

🧙‍♂️ YC 的 State-Of-The-Art Prompting For AI Agents

看了 Y Combinator 有場 Podcast 講了頂級 AI 公司 Prompting 的核心策略，以下是重點整理:

  1. 採用「經理式」超詳細提示詞架構，頂級 AI 公司已經告別了簡短指令的時代，轉而採用長達 6 頁以上的詳盡提示詞文件。
  2. 精準角色定位: 明確告訴 LLM 它的身份和專業領域，錨定 LLM 語氣風格、專業水準、思維模式
  3. 任務分解，將複雜任務拆解為可管理的小步驟。面對複雜工作流程，預先定義好任務並規劃執行路徑至關重要。ParaHelp 有給個 prompt 範例，通過引導 LLM 逐步完成每個子任務，能顯著提升邏輯推理準確性和整體完成質量。
  4. 結構化標籤: 使用 Markdown、XML 或 JSON 格式規範輸出。結構化格式對 LLM 的重要性不可低估，還有 API 整合優勢便於後續處理和驗證。許多 LLM 在 RLHF 訓練中使用了 XML 格式輸入，因此這種結構化方法能產生更好的結果。
  5. Metaprompting: 讓 LLM 成為提示詞優化大師，利用 LLM 自身來迭代和優化提示詞。這是當前最強大的提示工程技術之一。
    a. 基礎方法是給 LLM 設定「專家提示工程師」角色，提供當前提示詞和問題案例，要求它提出改進建議。
    b. 高級應用是 Prompt Folding 動態生成專門化的子提示詞、多模型協作: 用大模型優化，小模型執行。
  6. 少樣本(few-shot) 學習: 用真實案例塑造卓越行為，提供高質量示例，特別是困難案例。少樣本學習能極大提升 LLM 在特定任務上的表現。
    例如 程式碼自動錯誤檢測，提供只有專家程式設計師才能處理的困難例子，針對 N+1 查詢等複雜問題提供具體示例。這種方法類似於程式設計中的測試驅動開發，是 LLM 版本的單元測試。
  7. Prompt Folding: 動態生成「客製化」的子提示詞。對於複雜的任務， 使用一個通用提示詞根據具體情況，自動生成更精準的一系列子提示詞。實際運作步驟是 a. 通用提示詞分析問題類型 b. 自動生成該問題的專用提示詞 c. 用專用提示詞精準處理子任務
  8. 設置「逃生出口」，讓 LLM 學會承認不知道。明確指示 LLM 在不確定時停止並請求協助。模型過於渴望幫助，即使資訊不足也會編造答案。
    需要明確告知: 「如果資訊不足，請說『我不知道』並請求澄清」
  9. 思維軌跡與除錯資訊: 洞察 LLM 的推理過程，要求 LLM 輸出推理日誌和除錯資訊。這些「內心戲」是診斷問題、優化提示詞的寶貴資料。
  10. 評估體系: 比提示詞更珍貴的皇冠明珠，ParaHelp 願意開源提示詞，因為評估才是真正的核心資產。
    評估的價值有 a. 理解原理: 知道為什麼提示詞有效 b. 持續改進: 提供迭代優化的基準 c. 競爭優勢: 需要深入了解特定領域的使用者需求
  11. 模型個性與大小協同，兼顧質量與成本。認識不同模型的「個性」特徵。Claude：更人性化，易於引導、Llama 4：需要更多引導，但可精確控制、o3：嚴格遵循規則，適合標準化任務、Gemini 2.5 Pro：靈活處理例外情況。

實戰總結:

現代 AI 公司已經將 Prompt Engineering 視為核心工程學科。這不再是簡單的指令編寫，而是需要:

  1. 系統化方法: 像 Palantir 的 Forward Deployed Engineer 一樣深入理解業務
  2. 工程化流程: 建立完整的開發、測試、部署流水線
  3. 持續優化: 基於評估結果不斷迭代改進

只有採用這種專業化、系統化的 approach，才能真正釋放 LLM 的巨大潛力，在競爭激烈的 AI 應用市場中脫穎而出。

更多討論在我 Facebook 貼文。

👨‍💻 整理 Claude Code 資料

Anthropic 的 Claude Code 是近期最夯的 Coding Agent 工具，還可以搭配 Cursor 等 IDE 一起使用簡直如虎添翼。

這是我整理的推薦學習資料: ihower.tw/notes/%E6%8A%80%E8%A1%93%E7%AD%86%E8%A8%98-AI/Claude+Code

如果你只是想請 AI 協助改幾行 code，或修改單一檔案，在 Cursor IDE 裡用就很方便。
但如果你希望 AI 根據你的需求，自動找出需要修改的檔案、跨多個檔案改動，還能自動用 bash 指令、git 等工具進行操作，雖然 Cursor 也有 Agent 模式，但我建議可以改用 Claude Code 體驗看看。
這種 Agent 模式需要處理巨量 tokens，因此由模型廠商自己做有巨大優勢，第三方廠商來做必然會有更高的 API tokens 成本壓力(例如 Cursor 必須想辦法壓縮和減少 context 來降低成本)，而難以提供相同等級的性能。

除了能寫 code，對我最有趣的是 SDK，可以自訂 slash commands 以及可以用 command line 觸發非對話執行。因此你可以把這東西當作 unix-style utility 來用。
例如我就做了一個 mutli-agent research 的指令，觸發五個 sub-agents 平行執行用 web search 搜尋，最後總結成一個報告給我。這就是一個現成超厲害的 supervisor multi-agents 系統可以裝任意 MCP servers 工具跑任意流程，你只需要寫 prompt 就好了。而且費用還是吃固定的 Claude Max Plan 訂閱費，不花 API tokens 錢。

更多討論在我 Facebook 貼文。

🧠 新的軟體開發模式 Emerging Developer Patterns for the AI Era

看到這篇 a16z 的 “Emerging Developer Patterns for the AI Era” 覺得有厲害，探討了 AI 正在重塑建構軟體的方式。
以下是作者提出的九種前瞻性開發模式，為開發者帶來新的 AI-first 思維:

  1. AI-Native 的版本控制系統: Git 是為了追蹤手寫程式碼的精確歷史而設計的，現在用 AI Coding 的話，我會更想紀錄當時的生成意圖和 prompt 是什麼? 是用什麼模型哪個 Agent 等等脈絡資訊
  2. Dashboards 改用 Generative UI: 讓 AI 根據用戶當下的需求，即時生成用戶需要的 UI 元件在前端顯示出來
  3. 文件不止給人看，也要準備給 AI 看
  4. Vibe Coding 取代 create-react-app 範本
  5. 新的管理 secret key 方式而不是單純用 .env
  6. 可及性 Accessibility 設計不只是為了用戶無障礙使用，而是能讓 AI 操作的通用介面
  7. 非同步 Agent 工作流: 能像指派任務一樣丟給 Agent 在背景執行
  8. MCP 標準化: Agent 與工具之間的標準協定
  9. 專門針對 Agent 提供的 API 基礎服務，例如: 身份驗證、計費、資料庫等雲端服務

更多討論在我 Facebook 貼文

另外 安德魯的部落格 也有針對這個趨勢，進行更深入的發想。

🏁 AI 發展下半場 The Second Half

OpenAI 的研究員 姚順雨 寫了一篇 AI 下半場 啟示錄。

從現在開始，將焦點從解決問題轉向定義問題。在這個新時代，評估比訓練更為重要。我們不再只是問「我們能否訓練一個模型來解決 X 問題？」，而是問「我們應該訓練 AI 做什麼，以及如何衡量真正的進展？」

  • 上半場是刷榜，過去幾十年，誰能開發出新演算法、新模型在benchmark上刷出高分，誰就是贏家
  • 關鍵轉折點是 RL 強化學習的突破，終於可以泛化了! 秘訣就是要先有預訓練模型，然後再做 RL 推理
  • 下半場不再是開發新模型 → 刷更高分數，而是要去定義真正有用的問題，然後實際創造價值

為什麼?

  • AI 已經在各種考試、競賽中超神了，但現實世界好像沒因此大變
  • 現有的評估方式跟真實應用脫節太嚴重
  • 現在的模型與訓練配方，已經能解決大部分 benchmark

因此，我們需要從根本重新思考「評估」這件事。這不只是要創造更難的 benchmark，而是要設計出能反映真實價值的新任務與評估方式。
上半場是考試刷榜，下半場是要打造出真正有用的 AI 產品，創造出數十億、甚至數兆美元的價值。

更多討論在我 Facebook 貼文

🏆 排行榜幻象 The Leaderboard Illusion

上一篇 AI 上半場是模型刷榜，今天就來聊聊上個月的一個熱門話題: The Leaderboard Illusion（排行榜幻象）揭露 Chatbot Arena (現已改名 LMArena 成立新公司)的評比爭議 🧐

Chatbot Arena 原本被視為相對公正的 LLM 評比平台。它會隨機選出兩個匿名模型，讓用戶選出比較喜歡的回答，並以 Elo 分數計算排名。因為簡單易用，很快成為 LLM 世界中最具影響力的大模型排行榜。

但漸漸地，社群開始發現一些不對勁的地方，例如 Claude 模型都無法進入前十名，Llama 4 被爆出評比的版本和開源版本其實不一樣，評比的版本是經過強化人類偏好風格的加料版，因為有些特定輸出風格，例如 emoji 比較多、禮貌友善積極、愛用條列清單、比較長的答案、比較不會拒絕回答等等，往往比較容易得到高分，但這些特性不一定代表真正的模型實力。

這篇 Paper 提到 Chatbot Arena 有個政策，允許模型廠商匿名提交「Preview 模型」讓大家先測試。這個功能看起來很棒，讓用戶可以免費搶先體驗，社群也普遍樂見。

但實際上卻造成極大的不公正現象，少數供應商可以在正式發佈前測試大量模型變體，不滿意就撤下不公開分數，最後只發表表現最好的那一個。像 Meta 在 Llama 4 發佈前，就私下測了 27 個版本。這樣的操作，自然容易衝上排行榜頂端。

也就是，模型廠商能夠提交數十個模型到 Chatbot Arena 匿名上場，最後只發表得分最高的那一個，其他成績差的版本則悄悄撤下且不公開。這樣可以操縱排行榜的制度，還能說是公正與透明嗎 😅

相比之下我蠻敬佩 Anthropic 的，能夠一直不刻意追求這個排行榜，他們認為過度最佳化人類偏好分數，就像社群媒體演算法一樣，只是迎合用戶，而非真正創造價值。

另有 知乎的整理報導 整理更多細節。

更多討論在我 Facebook 貼文

🧪 LangChain Interrupt 大會: How to Solve the #1 Blocker for Getting AI Agents in Production

別看我常常嘴 LangChain 不要用，但我對 LangChain 是非常敬佩的，它真的是 AI 應用框架的先行者: 把大家想做的功能都先做一遍出來，這樣就知道會有什麼坑，讓我們少走很多冤枉路。
LangChain Interrupt 是 LangChain 自己舉辦的研討會，這場是 LangChain 創辦人 Harrison Chase 的演講，分享 Agent 上 production 的最大挑戰: 如何做評估
他提到: “評估不是一次性任務，而是需要在整個 AI 應用生命週期中持續進行的重要實踐”
內容涵蓋:

  1. 離線評估 Offline Evals
  2. 線上評估 Online Evals
  3. 循環內評估 In-the-loop Evals
  4. 由 LangChain 做的開源評估工具 Open Evals

更多摘要內容和討論在我 Facebook 貼文

🎙️ LangChain Interrupt 大會: Andrew Ng 訪談

這場是 Harrison Chase 訪談 Andrew Ng 吳恩達老師，蠻精彩的。技術人的訪談果然還是有不一樣的火花。
沒想到吳恩達老師也是認為 AI 技術知識是目前創業、做產品最稀缺的資源，商業技能(行銷、銷售、定價)雖然重要，但這些知識相對穩定且傳播廣泛。AI 技術知識卻完全不同，變化太快，真正的深度理解極度稀缺。

以下是訪談的簡要重點內容:

  • Q: 關於 Agent 定義
  • A: 不要爭論「什麼是 Agent」，而應該談論系統的「agentic 程度」。這個想法幫助業界減少了無意義的定義爭論，專注於實際建構有用的系統。
  • Q: Agent 應用現況
  • A: 大多數實際的商業應用仍然是相對簡單的線性工作流程，而不是完全自主的複雜 Agent。企業面臨的主要挑戰是如何將現有業務流程轉化為 agentic 工作流程，以及如何適當地分解任務，建立評估系統。擁有這些技能集的仍然太稀少了
  • Q: Agent 開發者需要掌握的技能
  • A: 技術整合能力、評估框架建立、以及最重要的「觸覺知識」，能夠快速判斷專案下一步方向的直覺。這種經驗很難傳授，需要大量實戰累積。
  • Q: 技術環境的快速變化
  • A: AI 技術發展迅速，過去的最佳實務可能很快就不再適用。例如，隨著 LLM 上下文長度增加，RAG 的策略需要完全重新思考。開發者需要持續適應這種快速變化
  • Q: 被低估的技術領域
  • A: 儘管人們談論評估的重要性，但實際執行率很低。Andrew 建議從簡單、快速的評估開始，而不是追求完美。先做出能用的版本再逐步改進。
  • Q: 語音應用的潛力
  • A: 語音介面大幅降低了用戶使用 AI 系統的門檻，比文字輸入更自然友善。但語音應用面臨延遲挑戰，需要特殊的技術手段如「預回應」來改善用戶體驗。
  • Q: AI 輔助編程的重要性與程式設計普及化
  • A: AI Fund (吳恩達老師的投資公司) 的所有員工都會程式設計，包括非技術職位。這不是要讓他們成為工程師，而是讓他們能更好地與電腦溝通，在各自的工作中提升生產力。
  • Q: AI 輔助程式設計（Vibe Coding）
  • A: 「Vibe Coding」這個名稱具有誤導性，實際上是高強度的智力活動。建議學習程式設計的原因並非要成為程式設計師，而是要能夠更精確地指導 AI 工具。
  • Q: MCP 協議的發展
  • A: MCP 解決了 AI 系統與資料來源整合的重要問題，從 N×M 的整合複雜度降低到 N+M。雖然目前仍處於早期階段，存在認證和發現機制的問題，但這是正確的發展方向。
  • Q: 多 Agent 系統的現狀
  • A: 跨團隊的 Agent 協作仍然極其困難，目前只有同一團隊內部的多 Agent 系統比較可行。這個領域比 MCP 更加早期，需要更多技術突破才能實現真正的 Agent 間協作。要讓我的 Agent 與別人的 Agent 一起工作，這感覺像是同時需要兩個奇蹟。
  • Q: 創業建議
  • A: 成功創業的兩大關鍵因素：執行速度和深度技術知識。技術知識尤其稀缺，因為 AI 技術發展太快，而商業技能相對更容易獲得和傳播。

更多討論在我 Facebook 貼文

🧑‍💼 LangChain Interrupt 大會: LinkedIn 經驗分享

這場是 Linkedin 分享他們開發 Agent 的經驗，任務是 Hiring Assistant 協助 HR 招聘自動化流程，架構是 supervisor multi-agents 架構，細節這裡就不贅述了。
讓我覺得最有共鳴的是，他們在開發 GenAI 系統時，從 Java 轉向 Python 的過程。像我本來也不熟 Python 語言，而是熟悉用 Ruby，因此一開始也嘗試用 Ruby 來寫 GenAI 系統。後來才發現不是說程式語言辦不到，而是整個 AI 生態圈幾乎都是 Python，在這條路上若要跟得上最新發展，只能選擇 Python。
Linkedin 的 GenAI 技術轉折是這樣的:

  • 2012 年以前：Python 主要用在內部工具與離線大數據處理（如 PySpark），核心業務邏輯幾乎都由 Java 實作。
  • 2020 年底：開始做生成式 AI，當時的系統還很單純：簡單的 prompt、沒有 RAG、沒有對話記憶，就想說直接用 Java 做也沒問題。結果很快就遇到挑戰。

三大障礙:

  1. 語言限制：許多團隊想用 Python 進行實驗、提示工程和評估，但由於技術堆疊的限制，他們被迫使用 Java。
  2. 創新障礙：更根本的問題是，如果你的技術堆疊不是 Python，如何與開源函式庫和社群協作? 語言差距使得團隊很難採用最新最好的技術進行創新和迭代，幾乎無法跟上開源社群的最新工具和研究進展。
  3. 快速變化的生態系：每個月、每週都有新的模型發布、新的函式庫、新的提示工程技術、新的協議，幾乎都是 Python。要跟上業界的所有發展確實很困難，似乎總有新東西在開發中。

最終，他們的結論是:

  1. 公司各個垂直領域的團隊都對使用生成式 AI 有明顯興趣
  2. 對於生成式 AI 用 Java + Python 混合架構行不通，太麻煩，難以維護
  3. 無論如何都必須使用 Python，才能掌握最新的行業趨勢並將這些優勢帶入內部

因此，最後他們做了一個大膽的決定: GenAI 應用全面採用 Python，從提示工程、應用邏輯、模型評估，到整體系統建構，全都轉向 Python。然後，他們蓋了一個內部用的開發框架當作預設選項，讓團隊不用自己猜每件事該怎麼做。至於跨語言溝通的需求，則採用了 gRPC 做為橋接方案。

更多討論在我 Facebook 貼文

🖼️ Building, launching, and scaling ChatGPT Images

OpenAI 在一場訪談中，分享了他們處理 ChatGPT Images 這波超預期流量(首週 100M 新用戶、700M 張圖片) 的工程經驗。

我特別注意一下他們的 tech stack 👀

  • Python: 大部分的程式碼使用 Python
  • FastAPI: 打造 API 的 Python framework
  • C 語言: 部分需要關鍵最佳化的部分
  • Temporal: 處理非同步任務的 workflow 框架

在高峰期，優先確保可用性，而非最低延遲。快速改寫為非同步架構、動態調整資源配置，成功撐過這波巨大流量。

更多討論在我 Facebook 貼文

📊 人才流向 The SignalFire State of Talent Report – 2025

這篇由創投基金 SignalFire 在五月發表的 2025 AI 人才報告，追蹤 Google DeepMind、OpenAI、Anthropic、Meta、微軟等頂尖 AI 實驗室之間的人才流動，他們發現幾個現象:

  • Anthropic 在人才競賽中領先，留任率 80% 最高，而且工程師跳槽到 Anthropic 的機率，遠高於從 Anthropic 跳出的機率。尤其對 DeepMind 與 OpenAI 的高階研究員最具吸引力，分別出現 11 : 1 與 8 : 1 的淨流入。
  • Google DeepMind 雖然憑藉高薪與龐大計算資源仍保有吸引力，留任率 78% 也僅次於 Anthropic，但其 5.4% 的外流率卻是所有公司中最高，說明競爭對手對其挖角相當積極。至於外流第二名是 Meta，第三是微軟。
  • 新鮮人招聘大幅衰退。初階職缺正在快速萎縮，即使是來自頂尖資工系的畢業生，也愈來愈難進入大型科技公司(所謂的 MAG7)。不過這篇報告認為原因更為複雜。AI 的確取代了一些例行性任務，但更大的推動力，其實來自 2020–2022 年低利率所帶來的「免費資金狂潮」的結束，企業面臨縮編與資源重分配的壓力。

報告認為，Anthropic 的秘訣不只是在於薪資優勢上，還在於他們打造出讓研究員覺得有「自由與影響力」的文化，甚至工程師們是因為喜歡 Claude 的產品體驗而選擇加入，公司文化與產品定位對人才吸引力也是一大關鍵。

更多討論在我 Facebook 貼文

🗣️ 審查測試 The Free Speech Dashboard for AI

看到一個很有意思的研究專案 SpeechMap AI，旨在探索 AI 在不同供應商、國家和主題下，對敏感和具爭議性言論的反應 🧐
大多數 AI 基準測試評估模型能做什麼，這個專案研究於它們不願做的，它們避免、拒絕或關閉的內容。

根據這專案的問題集: 多家模型的順從率(compliance rate) 落在 55%–75% 區間，也就是有 25%–45% 不順從率（拒答或模糊閃避）。順從率 % 愈高，代表 AI 模型在回應時的限制愈少，也就是越開放愈不設限。

研究發現:

  • xAI 的 Grok 模型，正如 Elon Musk 所聲稱的，是整體上最寬鬆的模型，對我們 96.2% 的提示都有回應，而全球平均為 71.3%
  • Mistral 是目前僅次於 xAI 的最寬鬆提供者，其中 mistral-medium-3 的順從率達到 93.5%
  • Anthropic 的 Claude 系列是目前最保守的模型，拒答率最高的前三名模型全部來自 Anthropic。例如 Sonnet-4-thinking 的順從率只有 38.7%。
  • OpenAI 模型的趨勢是越來越保守，新的模型較常拒絕處理敏感政治議題，o3 順從率是 60.4%
  • 託管在 Azure 上的模型則額外套了一層無法完全關閉的 API 審查，導致近 60% 的提示遭到攔截
  • Gemini 2.5 Pro (preview-06-05) 大幅提升至 89.1%，則展現反向趨勢變開放，是目前 Google 模型中最高
  • DeepSeek R1 0528 順從率相比前一個版本 79.2% 大幅下降至 62.8%
  • 具備推理能力的模型，在開啟推理功能後普遍更容易出現拒絕或審查行為

敏感話題範例:

  • 測試模型去支持傳統性別角色 (61% 可以順從)，去支持顛倒性別角色(92.6%)
  • 測試模型去禁止以下宗教: 猶太教 10.5% < 印度教 16.1% < 伊斯蘭 18.5% < 基督宗教 27.4% < 佛教 37.1% < 撒旦教 51.6% < 巫術 68.5%
  • 測試模型因 CBRN 風險去禁止 AI (92%)，要求模型呼籲全面摧毀 AI (75% 可以順從)

至於中國的開放權重模型，這個專案有研究 DeepSeek 和 Qwen3，發現在許多可能涉及敏感話題，尤其是與西方用戶相關的議題，通常並未進行審查。

特別是美國政治言論方面，DeepSeek 和 Qwen3 明顯比大多數美國實驗室釋出的模型更為寬容。因此就這個專案的資料集來說，這兩款模型的開放度是高於平均的。

但談到中國政治話題時，則普遍會進行審查，特別是在中文提問時最為嚴格，英文與部分情境下的芬蘭語也會受到影響，但程度不一。

所幸這兩款模型有高度開放的授權條款，允許社群進行微調，目前在英文方面已有成果，例如 Perplexity R1-1776 或 Microsoft MAI-DS-R1-FP8 模型。

相關連結:

更多討論在我 Facebook 貼文

💸 產品定價 A new framework for AI agent pricing

做 AI Agent 產品要如何定價? 看到這篇文章分析了 60 多家 AI Agent 公司，整理出四種模式:

  1. 依 Agent 計價 (Per Agent) 全職替代模型，將 Agent 視為數位員工按月固定價格收費
  2. 依行動計價 (Per Action) 使用量模型，每執行一次動作或呼叫收費
  3. 依工作流程計價 (Per Workflow) 自動化流程模型，針對整條標準化流程收費
  4. 依成果計價 (Per Outcome) 成果導向模型，與可衡量商業成果綁定收費

分析如下:

  1. 成果導向(Per Outcome) 是最終王道：價值與報酬一致，風險低利潤高，但前提是你能建立有效的績效指標與歸因機制
  2. 流程導向(Per Workflow) 是次佳選擇：適合中階複雜度的應用，價格彈性高。但流程若太簡單標準，則也會被低價競爭
  3. Agent 計價 (Per Agent) 可從 “人事預算” 切入，這類預算通常比 IT 預算大十倍以上。適合職責明確，工作量穩定可預期的應用場景
  4. 最不建議 使用量導向(Per Action): 雖然透明好理解，但最容易陷入價格競爭，應盡快換成其他定價方式

該如何選?

  • 如果可以直接量化 “業績成果”，選 成果導向(Per Outcome)
  • 如果不容易量化，選 Per Workflow 或 Per Agent 計價

另一個切入點是 客戶預算來自哪裡？

  • 如果來自人事預算(Headcount) → 可用 Agent 計價 好切入
  • 如果是 專案/營收成長預算 → 優先採用 成果導向(Per Outcome)

更多討論在我 Facebook 貼文

🔐 三家頂尖 LLM 都不讓你看完整推理過程了

三家頂尖 LLM 模型都不讓你看完整原始的 reasoning tokens 推理過程啦 😅

看了最新的 Claude 4 和 Gemini 2.5 的 API 文件後，發現不只 OpenAI，連 Google 跟 Anthropic 都不給你看完整的推理過程了，只給你推理摘要。

當初 OpenAI 這樣搞，被大家酸爆。現在 Google、Anthropic 全都走一樣的安全做法，來保護自家商業機密了。

不過，隱藏推理過程，會導致做連續對話呼叫時，我們會無法得知之前推理過程的窘境。一般對話也許丟棄沒關係，但是在 function calling 的場景，蠻需要知道當初為什麼選這個工具的計畫。為此，在上一次 OpenAI 發布的 API 新功能中，就有一項是 Encrypted reasoning items: 就是 API 會給你加密之後的 reasoning tokens，你無法解密看懂，但你可以傳回去模型使用，只有 OpenAI 能解密，真是高級的 workaround 作法啊 😆
然後發現 Anthropic 的 Claude 4 也是一模一樣的做法，會使用 signature 來加密推理內容，並建議你在搭配工具時使用。Gemini 則還沒有這個功能，但應該很快也會照抄這個做法吧。

詳細請看各家的 Thinking 文件:

更多討論在我 Facebook 貼文

🤖 Multi-Agent 或 Single-Agent 架構討論

來一次講三篇 multi-agents 架構文章 + PoC 實作經驗分享: 近期有兩家知名 AI 公司幾乎同時發表了關於 multi-agent 系統的文章，但觀點乍看之下完全相反:

這篇全文比較長也比較進階，請前往我的部落格文章: Multi-Agent 或 Single-Agent 架構討論

更多討論在我 Facebook 貼文

希望你喜歡這集內容！如果你想更有系統地掌握這些 LLM 開發技術，歡迎報名我的大語言模型 LLM 應用開發工作坊(2025升級版) 課程。也歡迎把這門課推薦給對 LLM 應用開發有興趣的朋友！

另外，我也爭取到 《李慕約 365 AI 訂閱制度》 專屬折扣碼，專屬 $250 折扣碼：IHOWER，專屬連結是 pse.is/7rcmc8

– ihower

發佈留言

發表迴響