Bölümler
-
Nerd Snipe 這集把 OpenAI / Microsoft 新協議、Anthropic 企業摩擦與 GPT 5.5 使用感串在一起，提醒我們 OpenAI 正在重新取得主動權。 YouTube 版：https://www.youtube.com/watch?v=ICvUc8rnXTA 文章：https://heymaibao.com/openai-gpt55-microsoft-anthropic-nerd-snipe/
-
Anthropic 最新文章把 direct API、CLI、MCP 放在同一張 agent integration 地圖上。這集整理 MCP 為什麼適合雲端 production agent，以及 server、client、skills 該怎麼設計。 ⭐ 文章深度讀 https://heymaibao.com/mcp-production-agents/ ⚡ 章節重點 00:00 Agent 為什麼需要碰到真系統 01:54 API、CLI、MCP 三種連接方式 03:15 MCP 的跨 client 槓桿 04:35 好的 MCP server 不只是 API 鏡像 07:21 OAuth 與 context efficiency 09:37 MCP 加上 skills 才是工作流 11:25 怎麼判斷你該不該用 MCP 📝 懶人包 ∙ Direct API 適合小範圍、單點整合，快，但容易長出一堆客製化邊角。 ∙ CLI 適合本地或 sandbox 環境，輕巧，但碰到 web、mobile、cloud-hosted agents 就會卡在部署和認證邊界。 ∙ MCP remote server 適合 production agents，因為同一個 server 可以被多個相容 client 使用，並把 auth、discovery、rich semantics 放進共同層。 ∙ 我的觀察：MCP 的護城河不是 tool 數量，而是 intent 設計、授權、context efficiency 和 skills 的組合。 📚 參考資料 Building agents that reach production systems with MCP https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
-
Eksik bölüm mü var?
-
Theo 認為 AI 正在改寫 SaaS 護城河：客戶不只想用產品，也想 fork、改造、補上自己的長尾需求。這篇整理開源風險、building block economy 與 `patch.md` 的產品啟示。 ⭐ 文章深度讀：看完整整理，理解 AI 時代 SaaS 公司該怎麼重新設計開源與可修改性。 → https://heymaibao.com/ai-open-source-saas-moat/ ⚡ 章節重點 AI 改寫 SaaS 護城河 00:00 舊護城河是長尾功能地獄 01:08 開源風險不能假裝不存在 01:58 T3 Code 的 fork 訊號 03:21 Building block economy 05:16 patch.md 與自我修復軟體 06:49 給科技公司執行長的問題 08:18 📝 懶人包 ∙ Theo 的重點不是「所有產品都該立刻開源」，而是 AI 正在改變開源的商業價值。 ∙ 舊 SaaS 靠長尾功能鎖住客戶，但 AI 讓客戶更容易自己補長尾功能。 ∙ 真正的新護城河，可能是讓客戶能 fork、改造，卻仍願意付費使用你的後端與核心服務。 ∙ 我的觀察：`patch.md` 這個概念最值得看，因為它把客製化、更新與商業化放進同一個產品問題。 📚 參考資料 A letter to tech CEOs → https://www.youtube.com/watch?v=G1xqTjoihfo
-
Naval 談 Vibe Coding：AI agent 讓軟體原型更容易，也讓創作者、工程師與創投重新面對同一個問題：當寫程式變便宜，真正稀缺的是願景、品味、驗證能力，還是分發？ ⭐ 文章深度讀：看懂軟體創作的瓶頸，正在從會不會寫 code 搬到能不能判斷、驗證與分發。 → https://heymaibao.com/naval-vibe-coding-software-creators/ ⚡ 章節重點 高牆倒下後誰會崛起 00:00 Vibe Coding 不是自動補程式碼 01:21 私人工具與原型會大爆發 02:39 創作者直覺不再被團隊磨平 04:10 Agent 會迎合你，判斷變更重要 05:43 純軟體護城河為什麼變薄 07:10 Apple 的入口稅會被重新定價 08:35 真正的瓶頸搬到品味與驗證 09:38 📝 懶人包 ∙ Vibe coding 不只是 AI 幫你補程式碼，而是你用自然語言指揮 agent 跑完整軟體生產迴圈。 ∙ 它最先改變的是原型、私人工具與長尾應用程式，不是一開始就取代成熟產品。 ∙ 它不消滅工程判斷，反而讓操作者的架構、除錯與品味責任更明顯。 ∙ 我的觀察：軟體護城河會從「寫得出來」移到「知道做什麼、怎麼驗證、怎麼分發」。 📚 參考資料 On Vibe Coding → https://www.youtube.com/watch?v=hTdSU7q5WCo
-
Ghostty 將離開 GitHub。這不是單次 outage 的情緒反應，而是開源維護者對 GitHub issues、PR、Actions 等工作流可靠性失去信任的訊號。 ⭐ 文章深度讀：用你的專案檢查一次 CI、PR、issue 和 mirror 依賴風險 → https://heymaibao.com/ghostty-leaving-github/ ⚡ 章節重點 Ghostty 為何搬家 00:00 不是情緒反應 01:36 Git 之外的工作流 02:55 每天卡住的代價 03:47 遷移是風險管控 04:34 你的團隊撐得住嗎 06:12 📝 懶人包 ∙ Ghostty 將離開 GitHub，但會用 incremental 的方式移除依賴，並保留目前 GitHub URL 的 read-only mirror。 ∙ Mitchell Hashimoto 說，問題不是 Git 本身，而是 issues、PR、Actions 等 GitHub 周邊基礎設施反覆影響工作。 ∙ 這不是單次 2026 年 4 月 27 日大型 outage 造成的決定。原文說，團隊已經討論和規劃了幾個月。 ∙ 作者個人專案和其他工作目前仍留在 GitHub，所以這不是全面撤離，而是先處理受影響最大的 Ghostty。 📚 參考資料 Ghostty Is Leaving GitHub → https://mitchellh.com/writing/ghostty-leaving-github
-
Karpathy 在 Sequoia 訪談中把 vibe coding、Software 3.0 和 agentic engineering 串起來：AI 會外包大量寫程式工作，但工程師仍要負責理解、規格、驗證與品質。 文章深度讀： https://heymaibao.com/karpathy-agentic-engineering/ 參考資料： Andrej Karpathy: From Vibe Coding to Agentic Engineering https://www.youtube.com/watch?v=96jN2OCOfLs
-
AI 讓做事變快，但不會替你決定什麼值得做。這篇整理 @karrisaarinen 對規劃、寫程式、設計和領域判斷的觀察，拆解為什麼方向感與專業判斷在 AI 時代更稀缺、更值得重視。 ⭐ 文章深度讀：用文字版補上完整脈絡，掌握導入 AI 時該先問的方向問題 → https://heymaibao.com/ai-judgment-direction/ ⚡ 章節重點 速度變快，判斷更重要 00:00 好做不等於值得做 01:15 規劃不是文件，是方向盤 02:23 專業悖論：越懂越看得見破綻 03:25 寫程式與設計：容量變大，判斷仍在人手上 04:46 領域脈絡決定 AI 用法 06:38 先問目標，再交給 AI 07:47 📝 懶人包 ∙ AI 不會取消規劃，只會讓規劃從固定文件變成更頻繁的方向校準。 ∙ AI 工具會帶路，它不只加速工作，也會改變我們覺得什麼容易、什麼重要。 ∙ AI 沒讓專業失效，而是把專業價值集中到方向、限制、品味和評估。 ∙ 我的觀察：導入 AI 時，最該問的不是它能不能做，而是它會讓我們更快靠近什麼。 📚 參考資料 Some Notes on AI by @karrisaarinen → https://x.com/karrisaarinen/status/2048267794924650791
-
Claude Code 過去一個月變笨：Anthropic 4 月 23 日 postmortem 拆出三條獨立 bug，從思考強度被降到一行 prompt 砍能力，三條全修，並重置所有訂閱者 usage limits。 ⭐ 文章深度讀：直接給你 Anthropic 自承的三層 QA 盲區清單 → https://heymaibao.com/claude-code-april-23-postmortem/ ⚡ 章節重點 Claude Code 為什麼變笨 00:00 第一條：預設思考強度被偷偷降級 01:53 第二條：每回合都清思考的 cache bug 02:55 第三條：一行 system prompt 砍掉 3% 分數 03:54 為什麼多重 review 與 dogfooding 都漏掉 04:49 Anthropic 用 Opus 4.7 反過來抓自家 bug 06:11 給 agent / coding tool 開發者的通用教訓 06:43 📝 懶人包 ∙ 過去一個月 Claude Code 變笨是真的，原因是三條完全獨立的工程改動：預設思考強度從 `high` 被降到 `medium`、一個讓 Claude 越聊越失憶的 cache bug、一行為了壓回應長度而上線的 system prompt 反而砍能力。三條問題分別命中 Sonnet 4.6、Opus 4.6 與最新的 Opus 4.7。 ∙ 三條都已在 4 月 20 日的 Claude Code v2.1.116 之前修好。 Anthropic 從 4 月 23 日對所有訂閱者重置 usage limits 作為補償。 ∙ 「usage limits 縮水更快」其實是上面那個 cache bug 連續快取沒命中的副作用，不是 Anthropic 獨立的計費動作。 ∙ 我的觀察：這份 postmortem 真正值得帶走的，不是這三條 bug 各自被修好，而是 Anthropic 親自寫出來的三層 QA 盲區。跨系統交界的 corner case 過了多層 review、員工用的內部 build 跟對外 ship 的 build 不一致、一行壓回應長度的 system prompt 沒跑夠逐行測試就上線。對任何在做 agent / coding tool 的人都是通用警告。 📚 參考資料 Anthropic - An update on recent Claude Code quality reports → https://www.anthropic.com/engineering/april-23-postmortem @ClaudeDevs 在 X 上的對應發文 → https://x.com/claudedevs/status/2047371123185287223
-
有人花六位數買下 30 個 WordPress 外掛，後門靜待 8 個月後引爆，波及數十萬個網站。解析惡意程式如何繞過站長視線、為何強制更新不代表清乾淨，以及你現在應該做什麼。 ⭐ 文章深度讀：整理了確認 wp-config.php 是否中招的自檢方法，以及 31 個受影響外掛清單 → https://heymaibao.com/wordpress-plugin-backdoor-supply-chain-attack/ ⚡ 章節重點 合法收購，引爆數十萬網站的起點 00:00 神秘買家如何拿下 30 個外掛 01:08 後門設計：為何潛伏 8 個月都沒人發現 02:25 確認中招：檢查你的 wp-config.php 03:55 WordPress 信任漏洞，2017 年就有人用過 05:17 📝 懶人包 ∙ 攻擊者合法收購外掛組合後，第一個程式更新就是後門，這筆交易直接換來數十萬個 WordPress 網站的控制權 ∙ 後門只對搜尋引擎機器人 (Googlebot) 顯示垃圾連結，站長用自己的瀏覽器根本看不出來，惡意程式靜伏了 8 個月沒人察覺 ∙ WordPress.org 沒有外掛所有權移轉審查機制，這套攻擊劇本 9 年前就執行過一次，平台機制從未改變 ∙ 我的觀察：WordPress 外掛的「信任」是歷史積累出來的，不是即時驗證的。一旦外掛換了主人，那份信任就跟著轉移了，使用者毫無感知。安裝量排名、多年在 WordPress.org 上架，這些都不能當成現在的安全保證。 📚 參考資料 Someone Bought 30 WordPress Plugins and Planted a Backdoor in All of Them (Austin Ginder，Anchor Hosting) → https://anchor.host/someone-bought-30-wordpress-plugins-and-planted-a-backdoor-in-all-of-them/ Millions of WordPress sites just got hacked… again (Code Report / NetworkChuck) → https://www.youtube.com/watch?v=piah4fV_o2Q
-
開發者常把 App Store 截圖寫成規格表。這篇整理 @PaulSolt 的截圖文案反思，說明為什麼截圖文字可能比 UI 更早影響下載，以及如何把每張截圖改成清楚的下載理由。 ⭐ 文章深度讀：看懂該刪掉哪些功能標籤，改成更像下載理由的截圖文案 → https://heymaibao.com/app-store-screenshot-copywriting/ ⚡ 章節重點 下載少可能不是產品問題 00:00 截圖不是作品集，是廣告 00:58 文字 overlay 為什麼影響成效 01:51 功能清單為什麼說服不了人 02:29 把截圖排成會轉換的故事 03:51 遮住 UI 的低成本測試 05:06 文案是產品承諾的壓力測試 06:17 📝 懶人包 ∙ App Store 截圖不要只列功能。用戶不是在問「這個應用程式有什麼功能」，而是在問「這跟我有什麼關係」。 ∙ 截圖要有順序。先講痛點，再講使用後的改變，再放證據，最後才交代功能怎麼做到。 ∙ 先寫文案，再設計畫面。若一句話說不清用戶得到什麼，UI 再漂亮也只是展示。 ∙ 我的觀察：這其實是產品定位測試。你寫不出好截圖文案，通常不是文案能力不夠，而是還沒把產品承諾想清楚。 📚 參考資料 原始 X 貼文：每天讓你少拿下載的截圖錯誤 → https://x.com/paulsolt/status/2037591726227902555 Theodora 關於 App Store 截圖文字的貼文 → https://x.com/designerants/status/1881033920323444947?s=20 DesignerAnts 案例頁 → https://www.designerants.com/work Super Easy Slides 的 App Store 頁面 → https://apps.apple.com/us/app/super-easy-slides/id6738591861?mt=12
-
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
-
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
-
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
-
整理 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
-
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
-
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
-
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
-
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
-
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/
-
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
- Daha fazla göster
