脈報

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 516 episodes available.

脈報 episodes:

June 05, 2026 規劃的重點不是 plan mode，是 plan mode 之前那段對話

多數人一開 plan mode 就讓 AI 直接 build，模型只能亂猜。這位創作者先多輪對話把 context 和取捨聊清楚，才進 plan mode、生成計畫檔再 build。看他的四步流程。

⭐ 文章深度讀：plan mode 之前那段對話到底要聊什麼才不會白規劃

→ https://heymaibao.com/planning-before-plan-mode/

⚡ 章節重點

plan mode 被你用錯了 00:00

薄用法為何常常翻車 00:34

顛覆認知的四步流程 02:17

實戰：Expo 還是原生 Swift UI 03:26

計畫檔才是真正的交付物 05:14

花時間規劃會拖慢出貨嗎 06:27

結論：先投資十分鐘對話 07:16

📝 懶人包

∙ 多數人的 plan mode 用法太薄：plan mode 是 AI 工具裡「先出計畫、再動手蓋」的模式，但多數人是一行需求 → 開 plan mode → 不讀計畫直接 build。模型手上只有一句話的 context (脈絡)，剩下全靠它替你猜，蓋出來自然不是你要的。

∙ 這位創作者的流程有四步：先跟 agent 多輪對話、把想法和 trade-off (取捨) 攤開來討論，等到確認它真的懂了，才進 plan mode，再讓它生成一個 Markdown 計畫檔，最後才開始 build。

∙ 那個計畫檔是可以帶著走的交付物：它能丟給 Cursor、Claude Code、Codex 任何一個 agent 去蓋，也是跨分頁、跨時間留給未來的自己的記憶。

∙ 我的觀點：真正稀缺的不是 plan mode 這個按鈕，是把腦中的東西對齊進 AI context 的那段對話。跳過它的人，跳過的正是整件事裡最值錢的部分。

📚 參考資料

這位創作者示範自己怎麼用 AI 規劃再蓋功能

→ https://youtu.be/MyRs5hdE7vo?si=hViOzCGZ5CkN3eH0
...more
8min
June 04, 2026 把 Claude Code 變成作業系統：4 個層級，一個慘痛教訓

把 Claude Code 變成替你工作的 AI 作業系統，關鍵不是模型而是分層餵 context。四個層級加一個 agent 寄爆 15 萬個信箱的教訓：指令不等於能力，授權要一階一階給。

⭐ 文章深度讀：影片講完四個層級的觀念，但每一層實際怎麼一步步接上工具、又怎麼設好護欄，我整理在文章裡。

→ https://heymaibao.com/claude-code-ai-operating-system/

⚡ 章節重點

開場：模型不是護城河 00:00

為什麼是 Claude Code 不是 Chrome 00:39

先做一次 context 自我稽核 01:20

4 個層級總覽 01:59

第一層 Context：它懂你的業務 02:57

第二層 Connections：它碰得到你的資料 03:29

第三層 Capabilities：教它怎麼做事 04:42

第四層 Cadence：筆電關著也在跑 05:15

一個慘痛教訓：指令不等於能力 05:52

用腳踏車方法一階一階給授權 07:12

真正的護城河是整套系統 07:49

留給你的一個問題 08:36

📝 懶人包

∙ 模型不是護城河，context 才是。作者的做法是把所有工作預設搬進 Claude Code，因為它看得到你的檔案、儲存庫和歷史紀錄，而網頁版只看得到你當天貼進去的東西。

∙ 搭系統有順序：Context → Connections → Capabilities → Cadence，四層往上疊，跳過一層上面就會塌。

∙ 指令不等於能力。對一個有寄信工具的 agent 說「絕對不要寄信」只是一個願望，工具還在那；真正的護欄是「根本不給它寄信的工具」。

∙ 我的觀點：這篇表面在教你怎麼把工具接上 AI，但對我來說真正的門檻不是技術，而是「賦能跟護欄要同步長大」。能力給多少，韁繩就要收多緊，這個判斷整篇都甩不掉。

📚 參考資料

I Turned Claude Opus 4.8 Into My Entire AI Operating System (@nateherk on X)

→ https://x.com/nateherk/status/2060373513014292919?s=46
...more
10min
June 03, 2026 做計畫但不讀計畫：一位開源高手最反直覺的 AI 工作流心法

一位開源高手攤開他的 AI 工作流：有想法先讓 AI 寫計畫但自己不讀，多開分頁並行，把人當成下判斷的訊號。我挑出哪些心法值得學、哪些別照抄，還有他誠實的上癮警告。

⭐ 文章深度讀：這套裡你最想先試哪一招，還是覺得哪一招其實不可行？

→ https://heymaibao.com/agentic-engineering-workflow-mindset/

⚡ 章節重點

開場 00:00

不寫程式卻擠進開源前段班 00:37

心法一計畫先行 02:22

心法二做計畫但不讀計畫 03:14

心法三極端並行 04:44

心法四人當訊號 06:29

誠實警告建構成癮 07:50

留給你的問題 09:12

📝 懶人包

∙ 計畫檔不是普通檔案，是 AI 需要的「脈絡層」。他的核心主張是：一份純文字的計畫檔 (他叫它 plan.md) 能讓 AI 停止亂猜，知道要改哪些檔案、達成什麼條件。傳統開發大概是八成時間寫程式、兩成規劃，這套工作流把比例翻過來，思考全進計畫，執行變得機械。

∙ 做計畫，但不讀計畫。他說計畫真正的作用是「韁繩」，逼 AI 去研究、定方法、寫下驗收條件並真的達成。有計畫的 AI 會把事情做完，沒計畫的會偷工減料、提早收手。所以他只看標題、有問題就當場問 AI 講重點，不坐著讀三百行的計畫。

∙ 人的價值是「當訊號」，不是動手。同時開好幾個 AI agent 在跑時，他認為人該做的是提供品味與方向，看回來的東西然後說「這版比較好，但用那版的語氣」。另外，任何做超過兩次的事就做成可重用的 skill，讓能力一次比一次強。

∙ 我的判斷：這篇最有價值的不是那一長串工具，而是底層心法。他的整套裝備門檻其實很高 (兩個月費 200 美元的方案、頂規筆電、一堆付費訂閱)，照抄不切實際。但「計畫先行、並行、當訊號、把重複工作做成 skill」這四件事，誰都能學。難得的是，他最後還誠實附上一段關於「建構成癮」的警告，讓整篇不只是工具吹捧。

📚 參考資料

Every Agentic Engineering Hack I Know (June 2026)

→ https://x.com/mvanhorn/status/2061877533885473181
...more
10min
June 03, 2026 Opus 4.8 被嫌慢又愛幻覺，但問題可能出在 Claude Code

新 benchmark DeepSWE 顯示 GPT 5.5 領先 Opus 4.8，更快也更便宜。但主持人最值得記住的判斷是：你嫌 Opus 4.8 慢又愛幻覺時，問題可能出在 Claude Code，不是模型。

⭐ 文章深度讀：Opus 4.8 到底是不是被 Claude Code 拖累，我把整集的判斷拆成一篇

→ https://heymaibao.com/opus-4-8-held-back-by-claude-code/

⚡ 章節重點

你以為在罵模型，其實在罵介面 00:00

跑分的真相：DeepSWE 與 SWE-bench Pro 01:07

問題真的出在介面嗎 03:22

那筆隱藏的真實成本 05:08

工具還是人格的哲學之爭 07:06

造神的風險：Mythos 08:54

📝 懶人包

∙ 他們搬出一個新的測試標準 DeepSWE (一個專門衡量 AI 寫程式能力的評分榜)，上面 GPT 5.5 拿 70 分、Opus 4.8 拿 58 分，而且 GPT 5.5 更快也更便宜。排在這兩家後面的所有模型 (開源模型、Gemini) 只剩不到三分之一的分數，等於 OpenAI 跟 Anthropic 自成一個等級。

∙ 其中一位主持人說，他在自己電腦上看到 Claude Code 大約 80% 的工具操作會報錯，一個簡單的修改要等 2 到 4 分鐘，模型甚至會憑空捏造連它自己指令的參數都編出不存在的。他懷疑 Opus 4.8 的真實實力被這個介面嚴重拖累了。

∙ 他們提醒一件很實際的事：你付的訂閱費不是真實成本。用 100 美元或 200 美元月費養成的用量習慣，換到公司用 API 計費，帳單會變天文數字。

∙ 我的觀察：這集節目偏袒 OpenAI 偏得很明顯，連那個讓他們改觀的 benchmark 都是主持人自己投資的公司做的。但即使把這些偏見扣掉，「你嫌的可能是工具不是模型」這個切角，我認為值得每個在用 Claude Code 的人認真想一遍。

📚 參考資料

We (mostly) like Opus 4.8

→ https://www.youtube.com/watch?v=EYq1_mB-xJ4
...more
11min
June 02, 2026 Claude Code 自寫工作流，Anthropic 工程師卻提醒別亂用

Claude Code 新功能 dynamic workflows 讓 Claude 即時自寫工作框架，把活拆給多個分身。但寫這功能的 Anthropic 技術成員反而叫你想清楚再用，因為它很吃 token。

⭐ 文章深度讀：六種 pattern 怎麼組、什麼時候反而別開 workflow，完整判斷都整理在文章裡

→ https://heymaibao.com/claude-code-dynamic-workflows-when-to-use/

⚡ 章節重點

開場 00:00

官方的反常警告 00:39

認識動態工作流 01:42

破解三大失敗模式 03:16

實用的協作模式 05:47

算力與權衡抉擇 08:25

📝 懶人包

∙ Claude Code 的 dynamic workflows 讓 Claude 在執行任務時，即時寫出一套為這個任務量身打造的「工作框架」(harness)，還能存起來分享重用。

∙ 它真正要解決的不是「跑快一點」，而是單一對話視窗做長任務時會出現的三種退化：做一半就喊完成、偏愛自己的答案、做著做著忘了原本目標。用多個各自獨立的 Claude 分頭做，就能結構性地擋住這些問題。

∙ 作者自己強調：它會用掉明顯更多 token，不是每個任務都需要，而且最佳實踐還在發展中。

∙ 我的觀點：dynamic workflows 的本質是「用結構去買品質，代價是 token」。所以決定要不要開一個 workflow 之前，先問自己一句話就好，這個任務真的需要更多算力嗎？

📚 參考資料

A harness for every task: dynamic workflows in Claude Code (Thariq Shihipar、Sid Bidasaria)

→ https://x.com/trq212/status/2061907337154367865

全文鏡像 (Claude Blog)

→ https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
...more
11min
June 02, 2026 AI agent 不是銀彈：拆穿 YouTube 最愛騙你的 6 個謊言

YouTuber Craig Hewitt 拆穿 always-on AI agent (Hermes、OpenClaw) 的 6 個迷思，從要花多少錢買電腦到「整個事業靠 agent 跑」的幻覺，幫你判斷它真正該用在哪。

⭐ 文章深度讀：影片拆了 6 個迷思，但「哪些事該丟給 always-on agent、哪些該自己坐在鍵盤前做」這條判準，我在文章裡用一句話加實例講得更細

→ https://heymaibao.com/ai-agent-six-lies/

⚡ 章節重點

開場 00:00

先記住這條判準 01:01

硬體沒那麼貴 01:26

便宜訂閱不夠用 02:49

事業全靠 AI 是幻覺 03:53

養一個 agent 的務實法則 04:42

它是隊友不是替代品 06:03

要不要用的三步測試 07:11

收尾 07:54

📝 懶人包

∙ 硬體不是門檻。一般電腦、雲端 VPS、Mac mini 都能跑，不用花大錢。

∙ always-on agent 不會取代你的 coding 工具，兩者是分工：持續主動的事交給它，需要你坐在電腦前塑形的事交給 Claude Code 那類工具。

∙ 「整個事業靠 agent 跑」目前是 demo 幻覺。前 80% 很好做，難的是後面那 80%。

∙ 我的判斷：要不要用 always-on agent，分界線其實只有一句話：這件事需不需要你在場。

📚 參考資料

The Biggest Lie You've Been Told About Hermes Agent

→ https://youtu.be/ubxDCAtYQwE
...more
9min
June 02, 2026 別再手動調 Skill，Microsoft SkillOpt 讓它自己越練越強

Microsoft SkillOpt 把調 agent skill 從手感試錯變成可量測訓練，模型凍結，被優化的是文字檔。一次看懂它的運作、論文報的效果，以及為何只在有標準答案的任務才適用。

⭐ 文章深度讀：SkillOpt 的完整運作、論文數字與我說的硬邊界，影片沒講完的都整理在這篇

→ https://heymaibao.com/microsoft-skillopt-self-evolving-agent-skills/

⚡ 章節重點

開場手動調 skill 的無限輪迴 00:00

SkillOpt 到底在訓練什麼 01:18

效果有多猛，52 格全勝 03:03

硬邊界，任務要有標準答案 05:08

低成本動手的三步起步 06:15

成本與我的判斷 08:10

📝 懶人包

∙ SkillOpt 是一個「文字空間的優化器」，意思是它不動模型權重，被訓練的是你的 skill 文字檔。整套靠一個迴圈：用當前 skill 跑任務、讀成功與失敗、提出小幅編輯、只保留讓分數上升的改動。

∙ 論文報告的效果很猛：橫跨六個 benchmark、七個模型、三種執行環境共 52 個測試格，SkillOpt 全部拿下最佳或並列最佳。以 GPT-5.5 直接對話為例，六項平均從沒有 skill 的 58.8 升到 82.3，提升 23.5 分，而最後產出的只是一個約 380 到 2,000 tokens 的小文字檔。

∙ 它有硬邊界：只在「有可對照正確答案」的任務上有效，而且真正決定成敗的不是跑指令，是你準備的那組範例答案。

∙ 我的判斷：別急著裝。先問你的任務有沒有標準答案，有，這是把調 skill 從玄學變成可量測的好路徑，沒有，它幫不了你。

📚 參考資料

hooeem：I want to create self-evolving agent skills (X 貼文)

→ https://x.com/hooeem/status/2061528919786791154?s=46

SkillOpt 論文 (arXiv，2026)

→ https://arxiv.org/pdf/2605.23904

microsoft/SkillOpt (GitHub)

→ https://github.com/microsoft/SkillOpt
...more
10min
June 02, 2026 AI agent 也需要看板?Hermes 把失敗和重試變成一等公民

AI agent 並行工作時,難的不是排任務,是它們會失敗、當機、被退件。Hermes 的 Kanban 把每次嘗試、重試和交接都寫進資料模型,用四個場景看懂它跟普通待辦清單差在哪。

⭐ 文章深度讀：你還在手動翻 log,救那些失敗的 AI 任務嗎?

→ https://heymaibao.com/hermes-kanban-ai-agents/

⚡ 章節重點

開場:AI agent 真的需要看板嗎 00:00

為什麼傳統清單會崩 01:13

run-based 模型:把失敗當一等公民 01:49

三個操作面與六欄看板 02:19

場景一:讓任務自己排隊 03:17

場景二:一個人顧一支 AI 艦隊 04:26

場景三:退件重來與重試歷史 05:36

場景四:斷路器與崩潰復原 06:51

真正的關鍵:結構化交接 08:08

我的觀察與收尾 09:14

📝 懶人包

∙ Hermes Kanban 用 run-based 模型: 任務的每一次執行嘗試 (一個 run) 都是獨立一列，失敗、崩潰、重試的歷史是一等公民而不是事後補的註記。重試的 worker 會從「上次失敗在哪」接手，而不是從零重跑。

∙ 階段之間靠 `kanban_complete(summary, metadata)` 做結構化交接。下一棒的 worker 一呼叫 `kanban_show()`，系統回傳的 worker_context 就直接帶上上一棒的決策摘要和改了哪些檔，不用回去翻一整串留言考古。

∙ dispatcher (派工的背景程式) 有兩道可靠性防線: 斷路器 (連續失敗 N 次後直接終止重試，標成 gave_up 等人處理) 和崩潰復原 (偵測到 worker 進程死掉，就把任務收回重新派給新的 worker)。

∙ 我的觀察: 當你讓多個會出錯的 AI worker 並行做事，真正的瓶頸從來不是「看板長什麼樣」，而是「失敗和交接有沒有被當成一等公民」。這點成立的前提是任務之間真的有依賴或重試，如果只是一堆互不相干的小事，普通清單其實也夠。

📚 參考資料

Hermes Kanban Tutorial

→ https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban-tutorial
...more
11min
June 02, 2026 AI agent 老是互相打架？他用一塊看板讓 18 個一起工作

多代理 AI 老是互相踩線、崩潰全毀？這位 YouTuber 用一塊共享看板當協調層，讓最多 18 個 AI agent 平行接力做研究、判斷、產出，整條流程只留一個人類核可閘門。

⭐ 文章深度讀：我把「協調為什麼才是多代理真正的瓶頸，以及這套看板設計哪裡值得抄、哪裡只是噱頭」整理進文章，用脈報的角度拆得比影片更白。

→ https://heymaibao.com/multi-agent-kanban-workflow/

⚡ 章節重點

開場：多代理為什麼老是壞掉 00:00

核心結論：別讓 agent 互相對話 00:52

看板就是單一真相 (一個 SQLite 檔) 02:17

Dispatcher：一張卡怎麼變成 agent 02:58

事件驅動依賴圖與五大優勢 03:39

實測：獵取 AI 痛點的流水線 04:52

18 個 agent、97 個任務的規模 06:48

唯一的人類閘門與自我修復 07:45

重點收穫與結語 09:28

📝 懶人包

∙ 多代理系統的瓶頸是「協調」而不是「建 agent」。作者用一塊共享看板 (底層就是單一個 SQLite 檔) 當協調層，agent 之間完全不互相對話、不用訊息佇列，只讀寫同一塊板。每個工作是一張卡，agent 認領、做完、交棒，狀態留在板上，撐得過重啟和當機。

∙ 協調靠一張會自驅動的依賴圖：卡片在待辦區等父任務完成，再自己升級成「就緒」，一個任務可以分裂成多個平行子任務，匯流的任務掛在所有子任務上，最後一個完成的瞬間自己觸發。沒有輪詢、沒有保母、沒有黏合用的膠水程式。

∙ 整條流程只留一個人類閘門。偵測、驗證、研究、提案全自動跑完，只有在出貨前透過 Telegram 送來一次待核可的提案，你可以核可、擱置或修改。作者強調這關可以拿掉做到全自動，但他強烈建議別這樣。

∙ 我的判斷：這部影片最值得帶走的不是「我做了一群會賺錢的 agent」，而是那個可複製的協調骨架。作者自己也誠實說了，agent 產出的東西是「不錯的起點」而不是能直接上線的成品，你看的是設計，不是一台印鈔機。

📚 參考資料

I Built the Ultimate Multi-Agent Workflow w/ Hermes Agent Kanban Board

→ https://www.youtube.com/watch?v=EKVRqcpTT6s
...more
11min
June 02, 2026 別再幫 AI agent 蓋富士康工廠：Garry Tan 的 54 萬行教訓

他剛蓋完 54 萬行程式碼，卻說那是替 AI agent 蓋的富士康工廠。Garry Tan 公開認錯：AI 時代狂寫 code 是過時本能，真正稀缺的是判斷力。本文拆解他的反省與爭議。

⭐ 文章深度讀：走一遍你自己的專案，數數看有多少行 code 只是因為你不信任 AI 才寫的

→ https://heymaibao.com/stop-building-foxconn-factory-for-agents/

⚡ 章節重點

開場 00:00

稀缺的是判斷力 00:55

54 萬行白工的代價 01:45

替 AI 蓋富士康工廠 03:29

skillify 把一次性工作變複利 05:12

你到底想蓋什麼 06:59

📝 懶人包

∙ Garry Tan 公開認錯：他剛蓋完的 54 萬行 Rails app，本質是替 AI agent 蓋的「富士康工廠」。他說那些層層疊疊的測試、guardrail、retry loop (失敗自動重試的迴圈)，每一行都是在賭「這個 AI worker 會出包」。

∙ 經濟學翻轉了：他的論點是，過去 LLM (大型語言模型) 呼叫很貴，所以大家寫一堆 code 省著用、把模型保護起來。現在模型又便宜又夠聰明，該反過來用白話指示它，讓它只寫最小必要的 code。

∙ 他主推的方法論叫 skillify：把一次性做出來的能力，轉成一個帶完整測試的「skill pack (技能包)」，可以重複使用、像利息一樣累積。他說自己已經有超過 350 個。

∙ 我的觀點：他的核心洞察站得住腳，但其中「一年燒幾十萬到上百萬美元 token」跟「不要急著裝安全護欄」這兩段，帶有「花得起的人才這樣說」的倖存者視角，一般人聽聽就好，別照單全收。

📚 參考資料

Stop building Foxconn factories for your agents (Garry Tan)

→ https://x.com/garrytan/status/2061454423034110372?s=46
...more
9min

FAQs about 脈報:

How many episodes does 脈報 have?

The podcast currently has 516 episodes available.