脈報

By 思思主播

脈報... more

· Technology

Download on the App Store

Download on the App Store

Get it on Google Play

FAQs about 脈報:

How many episodes does 脈報 have?

The podcast currently has 338 episodes available.

脈報 episodes:

April 23, 2026 AI agent 為何重犯同樣的錯？skillify 10 步 workflow

Garry Tan 用兩個真實失誤拆解 AI agent 為何老是重犯同樣的錯，重點不在多寫 prompt，而是把每次失敗 skillify 成技能、腳本、測試、resolver 與稽核 workflow。

⭐ 文章深度讀：整理了 skillify 真正該抄走的修錯順序與長期護欄

→ https://heymaibao.com/skillify-agent-reliability-workflow/

⚡ 章節重點

為什麼 AI agent 老是重犯同樣的錯 00:00

兩個失敗案例，問題其實是同一種 01:51

Skillify 到底在修什麼 02:53

為什麼測試、路由與 DRY 稽核缺一不可 04:33

這其實是在建立新的工程紀律 05:49

最後該帶走的 3 個問題 06:26

📝 懶人包

∙ LangChain / LangSmith 已經給了很多測試 primitives，但沒有交付錯誤發生後該怎麼修、修到哪裡才算完成的 workflow。

∙ 原文用兩個失敗案例指出同一個 root cause，也就是 deterministic 工作沒有被拉回腳本與規則，而是還在交給模型現場推理。

∙ skillify 的本質，是把每次失敗升格成技能契約、腳本、測試、resolver 與稽核流程，讓同類錯誤之後難以重演。

∙ 這篇最值得抄走的，不是某個工具名，而是把 agent 的長期改進從口頭承諾改成工程制度。

📚 參考資料

@garrytan 的 X 貼文

→ https://x.com/garrytan/status/2046876981711769720
...more
8min
April 22, 2026 Google 做的 DESIGN.md，想解決 AI 寫 UI 最常見的失憶症

Google Labs Code 開源的 DESIGN.md，不只放 token，還能 lint、diff、export、spec。

當 AI 越來越常直接寫 UI，設計系統是不是也需要一份能被 AI 長期讀懂的單一檔案？

⭐ 文章深度讀：整理了 DESIGN.md 補上的 Why、CLI 工作流，以及什麼團隊適合現在試

→ https://heymaibao.com/google-design-md-ai-ui-memory/

⚡ 章節重點

設計語氣為什麼會慢慢飄掉 00:00

DESIGN.md 補上的不是 token，而是 Why 02:19

lint、diff、export、spec 為什麼關鍵 04:18

什麼團隊現在最值得試 05:40

設計系統正在變成 AI 契約 07:01

📝 懶人包

∙ `DESIGN.md` 不只是設計 token 檔，它把 token 和設計理由放進同一份文件。AI 代理不只知道數值，還知道為什麼要這樣用，設計語氣比較不會在第二輪就掉光。

∙ 真正讓這個專案成立的，是 `lint`、`diff`、`export`、`spec` 這組 CLI。設計系統因此不只是文件，而是可以驗證、比較、轉換的工作流產物。

∙ 這套格式不是要你丟掉現有工具鏈。`export` 可對接 `Tailwind` 和 `DTCG`，專案裡的範例也同時附 `DESIGN.md`、`tailwind.config.js`、`design_tokens.json`，更像中介層，不像封閉標準。

∙ 我的觀察：如果你的 UI 已經常常由 AI 直接產出，這份專案很值得試。但如果團隊還沒進入 AI 主導工作流，它現在更像值得觀察的方向，而不是所有人都要立刻重押的新標準。

📚 參考資料

google-labs-code/design.md

→ https://github.com/google-labs-code/design.md

DESIGN.md README

→ https://github.com/google-labs-code/design.md/blob/main/README.md

DESIGN.md spec

→ https://github.com/google-labs-code/design.md/blob/main/docs/spec.md
...more
9min
April 21, 2026 Peekaboo v3 讓 AI 操作 Mac：從看見螢幕到真的點下去

Peekaboo v3 Beta 讓 AI 代理能看見 Mac 螢幕、取得 UI map，並透過 CLI 或 MCP 工具點擊、輸入、操作視窗。這篇整理它的核心用途、安裝門檻、風險邊界與適合場景。

⭐ 文章深度讀：整理 Peekaboo 適合哪些 Mac 桌面 agent workflow，以及該注意的權限與風險

→ https://heymaibao.com/peekaboo-mac-ai-agent/

⚡ 章節重點

AI 也想看見 Mac 00:00

桌面盲區在哪裡 01:18

Peekaboo 補上眼睛和手 02:12

UI map 讓操作可回指 02:53

什麼時候值得用 04:36

權限與 beta 風險 06:01

從亂點到有地圖 07:48

📝 懶人包

∙ Peekaboo v3 Beta 把 Mac 螢幕擷取、AI 分析、GUI 操作、CLI 與 MCP server 放進同一套工具鏈。

∙ 它的關鍵不是單次截圖，而是 `see` 產生 snapshot id、UI map 與可互動元素，讓後續點擊和輸入能回指同一個桌面狀態。

∙ 使用前要先接受 macOS 15.0+、Screen Recording、Accessibility 與 beta 穩定度這幾個前提。

∙ 我的觀察是，Peekaboo 適合 GUI 本身才是真相來源的工作，不適合取代更穩的 API、檔案或測試輸出。

📚 參考資料

Peekaboo GitHub repo

→ https://github.com/steipete/Peekaboo
...more
10min
April 21, 2026 Codex Computer Use 入門：什麼時候該讓 AI 操作桌面

整理 OpenAI Codex 應用程式的 Computer Use：它適合哪些 GUI 任務、需要哪些 macOS 權限，以及為什麼已登入瀏覽器、桌面應用程式與外掛選擇都會影響安全邊界與限制。

⭐ 文章深度讀：判斷哪些 GUI 任務值得交給 Codex

→ https://heymaibao.com/codex-computer-use/

⚡ 章節重點

先理解 Computer Use 的邊界 00:00

GUI 真相問題是什麼 01:01

什麼時候該用 Computer Use 02:05

權限與安全邊界 03:16

把它當 GUI 驗證者 05:14

用它省下心力的地方 06:19

📝 懶人包

∙ Computer Use 適合 GUI 才能驗證的任務，例如桌面應用程式測試、瀏覽器流程、應用程式設定與只在圖形介面出現的錯誤。

∙ 啟用前要安裝 Computer Use 外掛，並授權 macOS 的螢幕錄製與輔助使用。

∙ 如果目標應用程式有專用外掛或 MCP 伺服器，OpenAI 文件建議優先使用結構化整合，不要一開始就走視覺操作。

∙ 我的觀察是，Computer Use 最適合當「GUI 驗證者」，不適合當成日常資料存取或敏感帳號操作的第一選項。

📚 參考資料

Computer Use – Codex app | OpenAI Developers

→ https://developers.openai.com/codex/app/computer-use
...more
7min
April 20, 2026 Claude 使用者：覺得變笨不是錯覺，五個層次都在出問題

Claude 變笨不是錯覺。Theo Browne 拆出預期、Claude Code 殼、API、inference、模型五層，搭 Margin Labs 57% 掉 55%、AMD 80 倍硬數字，附三個自己能關的 workaround。

⭐ 文章深度讀：五層退化各自怎麼形成、3 個自己能關的設定，整理成一份可帶走的清單

→ https://heymaibao.com/claude-dumber-again/

⚡ 章節重點

不是錯覺：57% 掉到 55% + AMD 80 倍 00:00

Theo 的五層框架登場 01:27

第一、二層：使用者預期 + Claude Code 殼 02:01

第三、四層：API 分詞器 + inference 不穩 03:25

第五層：thinking redaction + 1M context 04:34

三招能自己關 + 真正的考驗：工程品質 06:08

📝 懶人包

∙ Margin Labs、AMD 內部分析、Matt Mau benchmark 等多組第三方數據都看到退化，體感不是錯覺。Margin Labs 在 Claude Code 上跑 SWE-bench 的加權平均，從 3 月以來從 57% 一路掉到 55%，大致是每週穩定往下，只有新 SOTA 模型上線時會小幅回升。

∙ Claude Code 這個 harness (模型外面那層包住它的程式) 可能是最大嫌犯。Matt Mau 的 benchmark 顯示同一顆 Opus 在 Cursor 裡比在 Claude Code 裡好 15%。Terminal Bench 上同樣搭 Opus 的 Claude Code 只拿 58%，Forge Code、Cappy 那類同類 harness 可以上 75% 到 82%。

∙ Anthropic 自己承認做了兩個大改動：Opus 4.7 換新 tokenizer 讓同樣一段輸入吃掉更多 token，三月把 100 萬 token 的 context window 預設打開。後者的時程和品質下滑最吻合，因為他們 2025 年 9 月的 postmortem 就寫過，被誤路由到 100 萬 token 版本的模型反應比較笨。

∙ 我的觀察：這部影片最有用的不是罵 Anthropic，而是把「感覺變笨」拆成五層這個框架。當你看懂哪層在出問題，就能先做幾個使用者自己決定的動作：把 100 萬 token context 關掉、把 effort 調成 high、少塞一堆自己裝上去的 MCP 與 skill (Claude Code 可以外掛的工具與能力模組)。這些今天就能動手，不用等下一版模型。

📚 參考資料

Theo Browne, Did Claude really get dumber again?

→ https://youtu.be/KFisvc-AMII
...more
8min
April 20, 2026 Claude Code 30 分鐘省 81%：prompt caching 的三條鐵律

Claude Code 一場 30 分鐘 session 省 81%、命中率 92%。這不是 API 開關，是三條 prompt caching 鐵律。拆 hash 折點「1+2=3 命中、2+1 miss」與三個 production 踩雷。

⭐ 文章深度讀：整理了 92% 命中率背後的紀律與 3 個 production 踩雷

→ https://heymaibao.com/claude-code-prompt-cache-discipline/

⚡ 章節重點

一場 30 分鐘 session 省 81% 的帳單 00:00

開 cache 為什麼不等於省錢 00:46

前段 vs 後段：指紋一字之差就 miss 01:43

三條鐵律與 2+1 為什麼 miss 03:18

幫你的 agent 做快取健檢 04:52

📝 懶人包

∙ Cache read 只要原價的 0.1 倍，但 prompt 的前段 (prefix) 只要被動到一個字，整段 20,000 tokens 就要以全價重新算一次。你想像的「開 cache 就等於省錢」是假的，真正省不省，看你能不能讓 prefix 完全不動。

∙ Claude Code 30 分鐘 session 可以做到 92% cache 命中率，2M tokens 從 $6 降到 $1.15，省 81%。這個 81% 不是 API 設定好就有，是每個產品決策 (subagent 只收摘要不收原始結果、用 reminder tag 取代改 system prompt、tool 定義一次載入完不再動) 都在保護同一個 prefix 的指紋。

∙ 三條鐵律：不要在 session 中途改 tools (會清空整份 cache)、不要中途切 model (cache 是綁 model 的)、不要為了更新 state 去改 prefix。想更新 state 的正確做法是在下一則 user message 後面掛一個 reminder tag (一段寫在對話裡的提示字串，不動 prefix 就能把訊息傳給模型)，讓 prefix 完全不動。

∙ 我的觀察：這套紀律比多數 agent 框架的預設做法都嚴格。很多框架會把 session state 塞進 system prompt、用 timestamp 當 prompt 一部分、根據情境動態增減工具，這些做法會讓 cache 命中率悄悄崩潰，成本不是線性增加，是階梯式飆升。讀完建議回頭檢查自己的系統有沒有中這些陷阱。

📚 參考資料

Daily Dose of Data Science - LLMOps Crash Course Part 1

→ https://www.dailydoseofds.com/llmops-crash-course-part-1/

Avi Chawla 在 X 的 prompt caching 串文

→ https://x.com/_avichawla/status/2044670188998803855
...more
7min
April 19, 2026 Garry Tan 回應 LLM 批判：模型是引擎，harness 是車

Garry Tan 回應 Jepsen 作者 Kingsbury 的 LLM 批判：不可靠是工程問題不是哲學問題。用 harness、skill file、resolver、deterministic code，把幻覺變可 debug 的 bug。

⭐ 文章深度讀：拆好 harness 四件組與 Kingsbury 四案例的工程修法清單

→ https://heymaibao.com/garry-tan-llm-harness-is-the-car/

⚡ 章節重點

引擎還是整台車？AI 新思考框架 00:00

Kingsbury 32 頁宣判 LLM 是胡扯機器 00:36

Garry Tan 一句話反駁：觀察對，結論錯 01:59

harness 四件組：skill file、resolver、deterministic code 02:50

從幻覺哲學題變成工程 bug 04:43

模型是引擎，去造那輛車 06:43

📝 懶人包

∙ Kingsbury 文章裡的四個 LLM 失敗案例 (Gemini 把浴室 3D 圖的馬桶弄不見、ChatGPT 把白補丁畫錯位置、Claude 做 image-to-image 產出一堆亂七八糟的多邊形、某個 LLM 宣稱下載了股價資料但其實是亂數圖) 都是真的失敗。但每個案例都是「一個人坐在生模型前打字」，沒有 skill file 指導流程、沒有 deterministic tool 處理精準部分、沒有 resolver 路由、沒有 harness 管 context。

∙ Garry 的正面主張是 thin harness + fat skills：判斷推上 skill file (結構化的 markdown 程序文件)，執行推下 deterministic code (固定輸出的程式)，中間由 resolver 路由，外層由 harness 薄薄地 orchestrate。連 Anthropic 自己都包了 512,000 行程式碼在 Claude 外面，這是做最強模型的人也不信任生模型的工程證據。

∙ 這套架構不會讓 LLM 變聰明，但會把失敗模式從「模型幻覺」改成「skill 寫錯 / tool 有 bug」。前者是哲學絕望，後者是可 debug 可修復的工程問題。

∙ 我的觀察：這場辯論對 AI 使用者的意義，不在判決誰對誰錯，在於換一個診斷框架。下次手邊的 LLM 又幻覺了，該問的問題不是「AI 不行」，而是「我的這個工作流裡，少了哪一層 harness、哪一個 deterministic tool、哪一條 skill」。把失敗當工程 bug 去修，而不是當成判決書。

📚 參考資料

Garry Tan: The Future of Everything is Lies (Response)

→ https://x.com/garrytan/status/2045798603059548364
...more
9min
April 19, 2026 9 秒語音訊息：OpenClaw 創辦人 Peter Steinberger 的 TED

OpenClaw 創辦人 Peter Steinberger 在 TED 的 17 分鐘演講整理：從 Marrakech 9 秒語音訊息，到 60 歲釀酒師用手機做網站，agent 真正改變的是誰能 build 這件事。

⭐ 文章深度讀：把 Peter 在 TED 攤開的 agent 風險姿態與 access 轉捩點，整理成可帶走的判斷

→ https://heymaibao.com/openclaw-peter-steinberger-ted/

⚡ 章節重點

9 秒語音訊息，為什麼改寫了 AI 的定義 00:00

Peter 是誰：賣掉公司後的 3 年空白 00:57

Marrakech 的 9 秒：agent 和 chatbot 真正的差別 02:33

Discord 那一夜：800 則訊息與他誠實攤開的姿態 03:52

NVIDIA、龍蝦、他差點把整個專案刪掉 04:43

60 歲釀酒師與 access 才是真革命 05:26

Heartbeat：再恐怖一點點的功能 06:43

龍蝦跑出來了，這扇門不會再關上 07:54

📝 懶人包

∙ Peter Steinberger 是 OpenClaw (一個讓 agent 幫你處理日常任務的開源 AI 工具) 的創辦人。他帶著自己寫的 WhatsApp agent 去摩洛哥 Marrakech，錄了一則語音訊息傳給它 — 他從沒寫過語音支援。9 秒後 agent 自己把轉檔、找翻譯工具、呼叫 OpenAI API 一整串接起來，回覆他。他說這就是他看懂「chatbot 放棄，agent 即興發揮」的那一刻。

∙ OpenClaw 今年變成成長最快的開源 agent 專案之一，轉捩點不是技術有多新，而是過去從沒寫過程式的人 — 像 60 歲釀酒師 Gerhard、São Paulo 青少年、深圳獸醫 — 都可以靠手機讓 agent 做完 90 分鐘釀酒、架網站、加付款。Peter 在 TED 上直接講：「真正的轉變不是技術，是 access。」

∙ Peter 自己把 agent 放進公開的 Discord，一晚上收到 800 則訊息。早上他拔掉插頭，逐則讀完，確認沒洩漏隱私。他在 TED 上說的不是「你看多厲害」，而是「什麼都沒發生，但可能發生」。這是整場演講最誠實的一句話。

∙ 我作為編者的觀察：Peter 最值得被注意的不是 OpenClaw 這個工具，而是他願意把 agent 時代的風險和興奮感同時攤開講。這是有法務部門的大公司做不到的姿態，剛好留給一個沒有法務部門的奧地利 builder。

📚 參考資料

Peter Steinberger 的 TED 演講原片：How I Created OpenClaw, the Breakthrough AI Agent | Peter Steinberger | TED

→ https://youtu.be/7rzYDM6vMtI
...more
9min
April 19, 2026 Gemini 3.1 Flash TTS 發佈，prompt 長得像一份電台劇本

Gemini 3.1 Flash TTS 發佈，prompt 從挑 voice preset 變成寫五層劇本。Simon Willison 實測改地名就換口音。這篇拆解 audio tags、導演椅設計與 TTS 工作流的分界線。

⭐ 文章深度讀：拆解五層 prompt 結構與 Simon 改地名的三次實測

→ https://heymaibao.com/gemini-3-1-flash-tts-prompt-like-script/

⚡ 章節重點

為什麼這次 TTS 不只是升級 00:00

導演椅：從工程師變成導演 00:48

prompt 變成五層劇本 01:30

Simon 改地名就換口音的實驗 01:58

Elo 1,211 之外，真正的訊號是 SynthID 03:34

寫提示詞就是新的劇本寫作 04:24

📝 懶人包

∙ Gemini 3.1 Flash TTS 的 prompt 不是幾行參數，而是一份五層的電台劇本結構：`AUDIO PROFILE`(角色檔，連節目副標一起寫)、`THE SCENE`(場景，連燈光時間都寫)、`DIRECTOR'S NOTES`(導演註記，底下再分 Style、Pace、Accent 三個子節，Style 裡還包含 Vocal Smile 與 Dynamics 兩條)、`SAMPLE CONTEXT`(這角色適合做什麼)、`TRANSCRIPT`(正式台詞，含 inline tags)。Simon Willison 對整份官方提示指南的評語是：說它驚人，都還算是保守的說法。

∙ 口音靠文字描述裡的地名驅動。Simon 把範例裡「Jaz 來自 Brixton，London」的地名，先改成 Newcastle，再改成 Exeter，Devon，三次都拿到對應口音的輸出，完全不是靠選取語音 ID。

∙ 硬規格與通路快照：第三方 Artificial Analysis TTS leaderboard 在發佈當天的盲測給出 Elo 1,211，被放進「最佳象限」(高品質 + 低成本)；走標準 Gemini API，model ID 是 `gemini-3.1-flash-tts-preview`，首日同時在 Google AI Studio、Vertex AI、Google Vids 三條管道開預覽；所有生成音訊都帶 SynthID 浮水印。

∙ 我的觀察：這次 TTS 的分界線不是誰的音質更像真人，而是心智模型的切換。從挑一個 voice preset，變成幫配音演員寫一份角色設定。這件事會改寫整個 AI 語音工作流，而不只是多了一款可換的引擎。

📚 參考資料

Gemini 3.1 Flash TTS

→ https://simonwillison.net/2026/Apr/15/gemini-31-flash-tts/

Gemini 3.1 Flash TTS: the next generation of expressive AI speech

→ https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-flash-tts/

官方 prompting guide

→ https://ai.google.dev/gemini-api/docs/speech-generation#transcript-tags

Google AI Studio 生成語音

→ https://aistudio.google.com/generate-speech

Simon Willison 的測試 UI

→ https://tools.simonwillison.net/gemini-flash-tts

Artificial Analysis TTS leaderboard

→ https://artificialanalysis.ai/text-to-speech/models

DeepMind Gemini 3.1 Flash Audio model card

→ https://deepmind.google/models/model-cards/gemini-3-1-flash-audio/
...more
6min
April 18, 2026 Opus 4.7 變笨了嗎？真相是 4.6 幫你做的 prompt 被拿掉

Opus 4.7 不是變笨，是 4.6 替你補意圖的那層被拿掉。Every 團隊五人親測，Anthropic 的 Alex Albert 在 livestream 解釋你的 prompt 為何失靈、這週該怎麼重寫。

⭐ 文章深度讀：拆解了哪些工作流該留 4.6、哪些換 4.7

→ https://heymaibao.com/opus-4-7-vibe-check/

⚡ 章節重點

真的變笨了嗎？你不是一個人 00:00

4.6 的「提示詞小精靈」被 4.7 裁員了 00:33

一年四次擺盪，不是意外是策略 01:22

4.7 的硬核新功能：自我驗證到視覺三倍 02:16

Every 五人實測：誰該留 4.6、誰能換 4.7 03:04

這週怎麼適應 4.7：四步行動計劃 05:43

📝 懶人包

∙ **Opus 4.7 不再替你讀字裡行間**：它更字面、更精確，指令明確時在 Every 自家內部的 coding benchmark 拿到有史以來最好的成績，但指令模糊時就會停下來等你說清楚，或直接猜錯。

∙ **4.6 默默幫你做的 prompt engineering (幫你補意圖)，4.7 交回給你**：Alex Albert 在 livestream 上確認，4.6 會替使用者補足缺漏的意圖，4.7 只聽明確指令。所以你過去兩個月調好的 prompt 庫，換到 4.7 預設會有一段不順期。

∙ **這是 Anthropic 刻意的來回調校，一年四次**：Sonnet 3.7 太急躁、Opus 4 收斂、Opus 4.6 做太多、Opus 4.7 再次收斂。Alex 把這個節奏稱為 `perpetual back-and-forth`，是政策不是意外。

∙ **我 (這篇的轉譯者) 看完 Every 原文，覺得對我們最實用的判斷是，別急著把所有工作流升級到 4.7**。需要明確規格配合的工作 4.7 值得換，靠 Claude 不請自來發現問題的場景，4.6 或 Sonnet 可能還要再留一陣子。

📚 參考資料

Vibe Check: Opus 4.7 Stopped Reading Between the Lines

→ https://every.to/vibe-check/opus-4-7
...more
8min

FAQs about 脈報:

How many episodes does 脈報 have?

The podcast currently has 338 episodes available.