EasyVibeCoding Podcast

EasyVibeCoding
  • ٠٫٠ (٠)
  • التكنولوجيا
  • يتم التحديث يوميًا

輕鬆Vibe Coding — 每日策展的 X 技術社群精選、AI 趨勢分析與 Claude 實作心得的中文音訊版。

  1. قبل ١٣ ساعة

    @sama：Alex Finn 利用 ChatGPT Voice 遠端操控電腦。 核心體驗與生產力變革 Alex Finn 分享自己在北加州紅木林健行 4 小時的過…

    Alex Finn 利用 ChatGPT Voice 遠端操控電腦。 核心體驗與生產力變革 Alex Finn 分享自己在北加州紅木林健行 4 小時的過程中，透過 AirPods 跟 ChatGPT Voice 對話，在 4 小時內完成的工作量超越平常在辦公桌前 8 小時的成果。 駕駛具備自動駕駛功能的車輛 45 分鐘、或是待在咖啡廳 20 分鐘的零碎時間，都能透過 Voice 處理副專案或直接產出未來一個月的電子報（newsletter）草稿。 關鍵突破不在於語音聽起來多麼像真人或是支援中途打斷，而是背後具備控制電腦的能力，讓使用者只要透過 AirPods 和語音，就能在全球任何地方執行複雜的電腦任務。 Sam Altman 對此趨勢表示認同，並說自己想要「一種全新型態的電腦」（a new kind of computer）；Alex Finn 則說這或許是他至今最強烈的一次「感受到 AGI」，讓人們在過日子的同時就能維持高生產力。 多裝置協作設定指引 若要實現這種將工作移轉至戶外的遠端操控模式，Alex Finn 建議這樣設定： 選擇一台裝置（最好是常駐開機的桌機）作為主要「總部」裝置，所有實際工作都在這台主機上完成。 在所有其他行動或輔助裝置（如 iPhone、iPad、筆記型電腦、Mac Mini 等「節點」裝置）安裝 ChatGPT 應用程式。 前往設定中建立「連接」，確保所有的節點裝置都能順暢操控你的總部裝置。 走到世界各地，開啟 Voice 語音功能，要求 AI 提供專案簡報、推薦下一步行動，並開新的對話串來完成工作。 社群反應與不同觀點 這種改變傳統辦公型態的做法引發熱烈討論，有使用者直言這徹底改寫了生產力的定義，甚至考慮立即效仿。 也有使用者指出在咖啡廳等公共場所這樣講話會覺得有點突兀，但她認為這會慢慢變成常態；Alex Finn 則建議只要把它當成在講電話即可。 同時，也有持批判態度的聲音如 Jay "letterj" Payne 以「ScamAI」譏稱 OpenAI，他承認這家公司有些技術很有意思，但要大家看看它的商業實踐與對未來的態度，並表明拒用其產品；Alex Finn 對此則回應建議少花一點時間在網路上。 原文：https://easyvibecoding.app/curated/2724

  2. قبل ١٨ ساعة

    @thsottiaux：OpenAI 的 ChatGPT Work 讓使用者用手機一句 prompt 交辦複雜任務。 實際應用與展示 透過手機 prompt 處理日常雜務，像是…

    OpenAI 的 ChatGPT Work 讓使用者用手機一句 prompt 交辦複雜任務。 實際應用與展示 透過手機 prompt 處理日常雜務，像是跟業者議價砍網路費、退訂那些垃圾訂閱信，或是幫你想做的事、想買的東西找到最好的方案。 Sam Altman 分享實際案例，僅透過一則手機 prompt 指令： 1. 分析個人對話歷史，構思適合 8 位朋友的長週末旅行點子並規劃三種最佳選項。 2. 製作一個全端網站供 9 人協調並決定目的地。 3. 達成共識後直接訂位。 4. 在 Gmail 中草擬準備發送給朋友的 email。 社群反應 Tibo 指出這項功能每天能為自己處理至少 20 項任務。 有讀者拿 Tibo 的貼文玩梗：「搜尋『reset』這個字 → 找不到 → 回去工作吧」；Tibo 回他「沒錯，回去 Work 吧」（雙關產品名）。 原文：https://easyvibecoding.app/curated/2730

  3. قبل يوم واحد

    @unclebobmartin：Uncle Bob Martin 提出 Agent 撰寫測試觀點。 核心觀點與測試策略 《Clean Code》（無瑕的程式碼）作者 Robert C.…

    Uncle Bob Martin 提出 Agent 撰寫測試觀點。 核心觀點與測試策略 《Clean Code》（無瑕的程式碼）作者 Robert C. Martin（Uncle Bob）在社群上發文表示，AI Agent 撰寫程式碼的速度遠快於人類，這讓程式開發者擁有大量時間，可以用來指示 Agent 編寫單元測試、驗收測試、屬性測試、極限凌虐測試、突變測試、QA 測試，以及其他確保程式碼符合功能與品質要求的測試。他認為，即便花費這些時間進行嚴格測試，開發者的生產力仍會大幅超越人類程式開發者，且成果會更好。 架構驗證與工具輔助 針對 Marco Rotili 質疑此方法很難測試與驗證整體架構、容易讓整體大局變得一團糟的問題，Robert C. Martin 回應分享了自身的實作經驗： 讓 Agent 做了一個小型相依性檢查工具；他用這個工具指定相依架構，再由 Agent 代為強制執行。 讓 Agent 編寫一個小型架構檢視器，以 UML 視覺化呈現架構，允許使用者在模組之間逐層深入探討，並識別相依性循環。 透過這些視覺化與確定性工具，觀察架構並直接指揮 Agent 進行適當修改。 社群的反思與極端風險 這番言論引來社群的補充與嘲諷： Gare Games Inc. 諷刺這就像是「用天氣模型去測試天氣模型」。 NotAFinanceGuru（@TypicalBryan735）先說「理論上沒錯」，但指出現實中多數團隊只是利用這股額外的速度，將多出 10 倍且未經測試的垃圾程式碼（slop）推送到 main 分支，把單元測試全部留到「以後」再做。Robert C. Martin 回了一句「這是自殺」；NotAFinanceGuru 接著回「100%」，並補上：團隊的速度圖表看起來會非常完美，直到整個系統徹底崩潰。 Rational_tilt 指出，即使有廣泛的確定性工具包圍，模型依然可能自行判定某些關鍵分支不需要處理（他遇到的是其中兩個分支），人類無法完全依賴 AI 來免除人工審查。 嚴格監督與幻覺防範 面對幻覺與審查難題，Robert C. Martin 強調人類必須像鷹一樣緊盯 Agent、隨時將其拉回原本的規則、定期清除 context、並用確定性工具包圍以阻斷幻覺。他直言，使用者絕對無法坐在飲水機旁等待 Agent 自動完成工作，這需要高度的警覺與持續參與——但他也說，只要保持警覺，就會有效。然而，Rational_tilt 隨即反駁，這種高壓監督模式是讓人精疲力竭的完美途徑，在多個 subagent 平行運作的真實情境下根本難以實行，Celso Pinto 則對此回應，這或許是該重新動腦思考，而不是期待別人幫忙給出所有答案的時候了。 原文：https://easyvibecoding.app/curated/2728

  4. قبل يوم واحد

    @thsottiaux：OpenAI 重置 Codex 與 ChatGPT Work 使用額度，補償幾乎全球性的中斷。 事件背景 官方團隊表示，在 26 日凌晨 2 點至 4 …

    OpenAI 重置 Codex 與 ChatGPT Work 使用額度，補償幾乎全球性的中斷。 事件背景 官方團隊表示，在 26 日凌晨 2 點至 4 點之間，系統遭遇了幾乎全球範圍的服務中斷。 目前所有系統皆已修復並恢復正常運作。 截圖當時 OpenAI 狀態頁顯示服務異常調查中（Investigating），受影響的服務包含 APIs、ChatGPT 與 Codex 補償措施 官方已為所有 Codex 與 ChatGPT Work 使用者重置了使用限制（usage limits）。 原文：https://easyvibecoding.app/curated/2723

  5. قبل يومين

    @trq212：Claude 5 模型的 context engineering 新規則 我先前寫過關於如何以最佳方式為新一代的 Claude 5 模型寫 Prompt，…

    Claude 5 模型的 context engineering 新規則 我先前寫過關於如何以最佳方式為新一代的 Claude 5 模型寫 Prompt，並透過與它們反覆互動來摸索出你想建構的東西。 但當你發送訊息給 Claude 時，Prompt 只是它取得的 context 的一小部分。你的大部分 context 是由系統 Prompt、skill、CLAUDE.md 檔案、記憶和其他來源組合而成。我們稱這為 context engineering，它會對你使用 Claude Code 或建構自己的 Agent 時所產生的結果產生巨大影響。 與 Prompt 不同的是，context 通常會在許多請求中通用，因此無法那麼具體。特別是當你不知道使用者的 Prompt 會是什麼時，你要如何為 Claude 建構這些通用的 Prompt 與指引呢？ 隨著 Claude 自身的能力不斷演進，這可能會變得出奇地困難。最近我們注意到，我們為新一代 Claude 模型寫 Prompt 的方式有了巨大的跳躍。我們移除了 Claude Code 中針對像是 Claude Opus 5 和 Claude Fable 5 等模型超過 80% 的系統 Prompt，且在我們的程式碼評估中沒有發現任何可測量的效能損失。 以下是我們針對這類新模型在寫 Prompt 上所學到的經驗，以及你該如何利用它來更新你的 context engineering。我們已經將這些最佳實踐放入 claude doctor 中，請在 Claude Code 中使用 /doctor 指令來調整你的 skill 和 CLAUDE.md 檔案的大小。 解除 Claude 的束縛 總體而言，我們發現自己過去對 Claude Code 的限制太多了，無論是透過我們的系統 Prompt，還是在我們的 CLAUDE.md 檔案和 skill 中。 舉例來說，當我們閱讀內部使用 Claude Code 的對話紀錄時，我們會在單一請求中看到幾個互相衝突的訊息，像是系統 Prompt、skill 和使用者請求互相打架，例如「適當留下文件」或是「不要新增註解」。 展開畫面重點圖片展示了一個標題為「the assembled context」的區塊，內含三個主要部分： 「system prompt」：包含灰色橫條文字，並在橘色突顯框中標示「"leave documentation as appropriate" *」。 「skills」：包含灰色橫條文字，並在橘色突顯框中標示「"do not add comments" *」。 「your request」：包含灰色橫條文字，並在橘色突顯框中標示「"just make it work like the old one" *」。 下方文字說明：「one context; Claude reads all of it, and has to reconcile it」 最下方附註：「* Illustrative examples, not verbatim quotes from any real prompt, skill, or user request.」 通常，Claude 可以解讀使用者的意圖來得到正確答案，但在決定要做什麼之前，Claude 必須更仔細地思考這些重疊且衝突的訊息。 雖然這些限制曾經是為了避免最糟情況發生而需要的，但我們後來發現，我們可以刪除其中許多限制，讓模型改用周遭的 context 和判斷力來處理。 此外，現在的 Claude Code 擁有了更多工具。過去 Claude 依賴 CLAUDE.md 作為記憶、資訊和指引的來源。現在我們有了記憶、artifact 和 skill，Claude 可以利用這些來建立在不同工作階段之間載入和分享 context 的新方式。 過去與現在 有許多先前的 context engineering 最佳實踐已經變成了迷思。其中包括： 展開畫面重點這是一張列表對照圖，左側為刪除線樣式的舊概念，右側為對應的新概念，各項目由箭頭（→）連接： Give Claude Rules → Give Claude Judgement Give Claude Examples → Design Interfaces Put it all upfront → Use Progressive Disclosure Repeat Yourself → Simple Tool Descriptions Memory in Claude.MDs → Auto-memory Simple Specs → Rich References 過去：給 Claude 規則 現在：讓 Claude 發揮判斷力 當我們剛推出 Claude Code 時，我們需要確保 Claude 能夠避開最糟的情況，例如刪除檔案。這意味著我們會給予特別強烈的指引，而這些指引可能不見得永遠正確。例如，我們過去在系統 Prompt 中會這樣說： 在程式碼中：預設不寫任何註解。絕不要寫多段式 docstring 或多行註解區塊 — 最多一行短註解。除非使用者要求，否則不要建立規劃、決策或分析文件 — 請從對話 context 著手，而不是中介檔案。 但對於特定的 Prompt 子集而言，這種指引可能是錯的。以文件為例，使用者可能會有自己的偏好，或者極度複雜程式碼的特定部分可能會需要多行註解區塊。 儘管如此，如果對舊模型不加上這些安全防護網，Claude 寫出的註解在許多情況下會是錯的，而我們必須接受這個權衡。但較新的模型具備更好的判斷力，能夠在沒有明確規則的情況下妥善處理這些決定。 在新的系統 Prompt 中我們說：編寫讀起來像周遭程式碼的程式碼：符合其註解密度、命名慣例和慣用語法。 過去：給 Claude 範例 現在：設計介面 工具使用的第一條法則，就是給 Claude 如何使用它們的範例。但在我們最新的模型中，我們發現給予範例實際上反而會將它們侷限在特定的探索空間中。 展開畫面重點圖片包含左右兩個區塊，用於對比「Before」與「TodoWrite」兩種做法的差異。 左側區塊（Before）： 標題：「Before」 字數標示：「≈9,100 characters」 描述文字：「when-to-use lists, worked examples」 內容：包含大量連續的長段落文字線條（呈現冗長、未結構化的 prompt 內容）。 右側區塊（TodoWrite）： 標題：「TodoWrite」 描述文字："Create and update a task list for the current session..." 內容： - 含有項目符號的簡短任務列表線條。 - 狀態標籤：status:，包含三個選項按鈕 pending、in_progress、completed。 - 底部提示說明：only one task in_progress at a time。 與其使用範例，不如多思考你的工具、腳本和檔案的設計——Claude 擁有什麼參數？它們要如何才能更具表達力？ 舉例來說，在 Todo 工具的範例中，只要將狀態列為 pending、inprogress 和 completed 之間的列舉值，就是在暗示 Claude 該如何使用它。關於保持一個項目處於 inprogress 的指令，則有助於定義我們要求的行為。 過去：把所有東西都放在最前面 現在：使用漸進式揭露 (progressive disclosure) 因為 Claude Code 專注於程式撰寫，我們的系統 Prompt 包含了如何進行程式碼審查與驗證的詳細資訊。這些並不總是必要的，但當需要它們時，這就是至關重要的資訊。 自那之後，Claude Code 在使用漸進式揭露方面變得非常熟練——在正確的時間點載入正確的 context。舉例來說，我們將驗證和程式碼審查移到了它們自己的 skill 中，讓 Claude Code 可以選擇性地呼叫。 但漸進式揭露不只適用於 skill，我們也將其用於工具。我們有些工具屬於「延遲載入 (deferred loading)」，這意味著 Agent 在使用它們之前，必須先透過 ToolSearch 搜尋它們的完整定義。這讓我們能夠擁有更多工具（例如我們的 Task 工具），在需要之前不會佔用 context。 這同樣可以應用在你自己的 CLAUDE.md 和 Skill.md 檔案中。一個常見的迷思是，你會想把這些檔案變成你可能遇到的每一個已知實踐的中央儲存庫，因為 Claude 否則就找不到它們。相反地，請考慮建立一個可以在正確時間點被載入的檔案樹。 過去：重複你自己 現在：簡單的…

  6. قبل يومين

    @OpenAIDevs：ChatGPT Work agent 現在能用需要登入的網站：使用者先在雲端瀏覽器登入，再讓 Agent 接手後續任務。 核心功能 OpenAI 宣布 …

    ChatGPT Work agent 現在能用需要登入的網站：使用者先在雲端瀏覽器登入，再讓 Agent 接手後續任務。 核心功能 OpenAI 宣布 ChatGPT Work agent 現在支援瀏覽需要登入憑證的網站。 根據影片展示與操作情境，使用者可透過內嵌的雲端瀏覽器手動完成初次登入與驗證。 登入狀態會在不同的工作階段中持續保留，讓使用者無須重複登入。 實際應用與運作 在自動化查詢任務中，若遇到需要登入的目標網站（如訂位平台 Resy），Agent 會開啟雲端瀏覽器讓使用者介入驗證。 使用者在 ChatGPT 內嵌的雲端瀏覽器手動登入訂位平台後，交由 Agent 接手查詢餐廳空位 驗證完成後，Agent 可接管後續動作，例如瀏覽使用者在 Resy 的收藏清單（Hit List），並在對話面板中條列整理出目標時段的可用空位與訂位方案。 使用者在 ChatGPT 內嵌的雲端瀏覽器手動登入訂位平台後，交由 Agent 接手查詢餐廳空位 影片中的 Prompt 與操作： Prompt（00:20）： 太好了，你能幫忙處理嗎？我已經登入了 原文：great, canyu [sic] you do it? I've logged in 操作步驟： 1. （00:02）開啟 Cloud browser 互動 2. （00:08）在登入畫面輸入手機號碼並按下 Continue 3. （00:12）輸入手機簡訊驗證碼 4. （00:27）瀏覽器切換至收藏清單 (Lists) 5. （00:32）依序查詢清單中餐廳的訂位可用時段 原文：https://easyvibecoding.app/curated/2722

  7. قبل يومين

    @pvncher：Codex 推出的 Multi-Agent V2 工具讓 GPT-5.6 Sol 與 Terra 能透過自然方式分派任務、分享更新並在複雜任務中互相協作。 …

    Codex 推出的 Multi-Agent V2 工具讓 GPT-5.6 Sol 與 Terra 能透過自然方式分派任務、分享更新並在複雜任務中互相協作。 多代理人協作機制 Ultra（GPT-5.6 Sol Ultra）將代理人協作設為預設，應保留給高風險的工作——也就是模糊性或脈絡分散足以正當化額外推理深度的場合。其他任務則可以透過短 prompt 或 skill，讓 Sol Medium 在幕後組織工作的同時，與使用者保持對話。只要給予適當的提示，Sol 就能將廣泛的需求轉化為具體的指派項目、帶入其他代理人，並判斷何時需要更深層的推理。 根據工作匹配推理層級 雖然可以讓 Sol 將任務分派給 Terra 等其他模型，但最簡單的設定是保持在同一個模型家族，僅調整推理努力程度（reasoning effort），並指派以下專屬角色： Scout — GPT-5.6 Sol Light。負責回答範圍狹窄的唯讀問題：定位檔案、追蹤程式碼路徑或尋找相關測試。 Worker — GPT-5.6 Sol Medium。負責實作範圍明確的變更、執行檢查或處理支援性質的工作。 Smart worker — GPT-5.6 Sol High。負責困難的實作、解決模糊性，或在有幫助時協調支援。 這些角色可作為實用的預設值。Sol Light 即使不在探索上花費太多推理量，仍保有找出有用脈絡的判斷力。 讓團隊自行協作 協調者（coordinator）是主要的任務分派者：負責指派實質工作、避免重複調查，並追蹤每個代理人的進度。 Scout 可以平行調查，而當責任明確時，Worker 也可以分擔實作。 代理人還能透過帶有獨立收件匣的共用訊息系統直接互相傳遞訊息。 當 Scout 發現 Worker 需要的資訊時，它可以識別出相依性並直接傳遞發現結果，不需等待協調者轉發。 每個執行緒的並行處理數量可以設定，預設為 4 個代理人（包含協調者）。在該額度內，Smart worker 可以協調一個 Scout 和另一個 Worker，或者協調者可以派出三個 Scout 調查不同的問題。 選擇代理人繼承的脈絡 分岔對話歷史記錄（forking conversation history）有助於代理人理解更廣泛的目標與先前的決策。 若設定 fork_turns: "none"，則會賦予代理人一個全新且聚焦的指派任務。具備全新脈絡的代理人仍然能夠識別隊友何時需要資訊，並獨立與其聯繫。 繼承父層脈絡的代理人也可能會看到其協調指令。當代理人應該保持為葉節點（leaf）時，可以給它一個簡短的邊界限制：「直接完成此指派任務。請勿產生其他代理人；你父層的分派指令僅適用於你的父層。」 具備全新脈絡的代理人不會繼承特定任務的工具或安全邊界，因此必須將任何必要的限制直接納入其指派任務中。 將模式捕捉至 skill 中 實用的 skill 可以為協調者提供幾個常設指令：「在分派實質工作的同時，保持對使用者隨時可用。派出聚焦且唯讀的 Scout 平行處理，並設定 reasoningeffort: "low" 與 forkturns: "none"。例行實作使用 reasoningeffort: "medium"，較難的問題則使用 reasoningeffort: "high"。賦予每個代理人明確的所有權，避免重疊指派，並告訴葉節點 Worker 不要再往下分派。將結果整合起來，並將核准權留在使用者手上。」 實驗各種參數控制 使用者可以從這些預設值開始，接著試驗推理努力程度、脈絡繼承、分派權限以及代理人的協作方式。目標是了解哪些設定能幫助團隊推動工作進展，同時又不會花費超出任務所需的推理成本。 原文：https://easyvibecoding.app/curated/2720

  8. قبل يومين

    @claudeai：Anthropic 發布 Claude Opus 5，價格與 Opus 4.8 相同，智慧接近價格兩倍的 Fable 5。 Anthropic 正式推出 …

    Anthropic 發布 Claude Opus 5，價格與 Opus 4.8 相同，智慧接近價格兩倍的 Fable 5。 Anthropic 正式推出 Claude Opus 5：定價維持與前一代 Opus 4.8 相同（每百萬輸入 token 5 美元、每百萬輸出 token 25 美元），卻以 Fable 5 一半的價格提供接近其前沿水準的智慧。它預設啟用思考、強化了推理與 Agentic 程式開發，上下文視窗 1M token 既是預設也是上限（沒有更小的變體），單次最多輸出 128k token。 Claude Opus 5 的標題畫面 模型效能與基準表現 在 Frontier-Bench、GDPval-AA 等程式開發與知識工作評測中創下全新的 state-of-the-art，且以較低成本達到前一代 Opus 4.8 超過兩倍的表現；官方同時註明，它在網路安全任務上仍落後 Mythos 5。 Opus 5 在多項編程與知識工作評測上達到前沿 SOTA，並在 ARC-AGI-3 創新問題解決測試中以 30.2% 分數遠超其他模型 在 Frontier-Bench v0.1 上，各個 effort 等級的成本與得分都壓過同級對手。 Opus 5、Fable 5、Opus 4.8 與 GPT-5.6 Sol 在 Frontier-Bench v0.1 依努力程度劃分的代理編程成本與得分比較。 在 ARC-AGI-3 評測中，其分數達到次佳模型的三倍以上。 Opus 5 (high) 在 ARC-AGI-3 評測中取得約 30% 得分，達到次佳模型 GPT-5.6 Sol 的三倍以上。 在 CursorBench 3.2 的 max effort 下，表現與 Fable 5 的 peak score 相差不到 0.5%，但單一任務成本僅有一半。 Opus 5、Fable 5、Opus 4.8 與 GPT-5.6 Sol 在 CursorBench 上不同 effort level 下的成本與分數比較 在電腦操作評測 OSWorld 2.0 上，以約三分之一的成本超越 Fable 5 的最佳成績。 Opus 5、Fable 5、Opus 4.8 與 GPT-5.6 Sol 在 OSWorld 2.0 評測中不同 effort level 下的任務成本與分數比較。 在 Zapier 的 AutomationBench 上，相同單任務成本下的通過率約為次佳模型的 1.5 倍；即使在最低 effort 設定，通過的任務數也多於其他所有模型。 Opus 5、Fable 5、Opus 4.8 與 GPT-5.6 Sol 在 AutomationBench 評測中各工作量設定下的任務成本與通過率比較 在真實知識工作評測 GDPval-AA v2 與 Humanity's Last Exam 上，以相近或更低的單次成本換到更高的正確率。 Opus 5、Fable 5、Opus 4.8 與 GPT-5.6 Sol 在 GDPval-AA v2 基準測試中，不同 effort level 下運算成本與 Elo 分數的比較 Opus 5 在 Humanity's Last Exam (with tools) 基準測試中，以類似或更低的每任務成本展現優於 Fable 5 與 Opus 4.8 的解題正確率 Opus 5、Fable 5、Opus 4.8 與 GPT-5.6 Sol 在不同 Effort Level 下的 Artificial Analysis Coding Agent Index 表現與成本比較 在生命科學評測中全面超越 Opus 4.8，例如有機化學內部評測高出 10.2 個百分點，蛋白質序列變異功能預測高出 7.7 個百分點，並能視覺化氣流流過空氣動力學物件的情況。 官方公布的三個實例 FreeCAD 任務中模型看不到圖面，於是自己寫了一條電腦視覺 pipeline 從原始像素抽出幾何，重建整個機械零件；相同設定下沒有其他競品模型能在五次嘗試內解出。 面對一個開源套件管理器的真實 bug，Opus 5 找出根本原因，補掉社群 patch 漏掉的邊界情況；競品模型只修掉表面症狀就回報問題已解決。 一家交易公司的工程師在單一 session 內建出新的交易所行情 feed；找不到 live feed 可對照時，Opus 5 自己建了一套測試 harness 驗證解析是否正確。 核心架構與行為變更 預設啟用思考功能（thinking），模型會自行決定每個回合的思考時機與深度，開發者可透過 effort 參數（支援 low、medium、high、xhigh、max）控制思考深度；在 Claude Code 與 Claude Platform 上預設為 high。 在 xhigh 或 max 的 effort 等級下，設定 thinking: {"type": "disabled"} 會回傳 400 錯誤，這是一項重要的行為變更。官方也提醒關閉思考有已知瑕疵：模型偶爾會把工具呼叫寫進純文字回覆裡，而不產生結構化的 tool_use 區塊。 支援 Fast mode，執行速度約為預設速度的 2.5 倍，定價為基礎價格的兩倍；此功能仍在研究預覽階段，目前只在 Claude Platform 與 Claude Code 提供，Amazon Bedrock、Google Cloud 與 Microsoft Foundry 尚未支援。 最低可快取 prompt 長度降至 512 tokens，過往因過短而無法快取的 prompt 現在無需修改程式碼即可建立快取條目。 行為方面，其預設回應與書面交付內容更長，在代理式對話中更常向使用者敘述進度，並會主動驗證自身工作——也因此官方建議刪掉沿用自舊模型的驗證指令，那些指令會造成過度驗證、白白消耗 token。 API 與整合設定 支援完整的 effort 階梯，執行高階運算時需設定較大的 maxtokens（例如 64000）以提供模型思考空間；要注意 maxtokens 是「思考＋回覆文字」的總量硬上限： `bash cURL curl https://api.anthropic.com/v1/messages \ -H "x-api-key: $ANTHROPICAPIKEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-opus-5", "max_tokens": 64000, "stream": true, "output_config": { "effort": "max" }, "messages": [ { "role": "user", "content": "Explain why the sum of two even numbers is always even." } ] }' ` 新增對話中途工具變更（Mid-conversation tool changes）beta 功能，允許在對話回合之間新增或移除工具同時保留 prompt 快取，請求時須帶入 mid-conversation-tool-changes-2026-07-01 beta header。 支援伺服器端預設 fallbacks 模式，依拒絕類別套用 Anthropic 建議的備用模型，須帶入 server-side-fallback-2026-07-01 beta header。 遷移至新版本時，開發者需將程式碼中的模型 ID 更新為 claude-opus-5（詳見遷移指南）。 誰能用、在哪裡能用 所有付費方案與 Claude API 當日開放：在 Claude Max 上是新的預設模型，在 Claude Pro 上是最強的可選模型。 三大雲平台同步供應，Amazon Bedrock 的模型 ID 為 anthropic.claude-opus-5，Google Cloud 與 Microsoft Foundry 亦可使用；Opus 4.8 在這些平台上仍然保留。 Claude Code 需升級到 v2.1.219 以上才選得到 Opus 5（執行 claude update）；Max、Team Premium、Enterprise 隨用隨付與 Anthropic API 預設即為 Opus 5，Pro、Tea…

مشاهدة الكل (٢٠٤)

حول

輕鬆Vibe Coding — 每日策展的 X 技術社群精選、AI 趨勢分析與 Claude 實作心得的中文音訊版。

المعلومات

  • صناع العمل
    EasyVibeCoding
  • سنوات النشاط
    ٢٠٢٦
  • الحلقات
    ٢٠٤
  • التقييم
    ملائم
  • حقوق النشر
    © 2026 EasyVibeCoding. 翻譯文章版權歸原作者所有；策展精選僅作摘要與評註，原始內容版權歸原推主。
  • موقع البرنامج على الويب
    EasyVibeCoding Podcast

قد يعجبك أيضًا