脈報

Anthropic 研究員用 Claude Code 掃出 Linux 核心 23 年的 NFS 漏洞，方法只是一個 shell script。文章拆解漏洞原理和方法細節，以及為什麼安全研究的遊戲規則正在改變。 ⭐ 文章深度讀：完整拆解 NFS 漏洞原理，以及 AI 找漏洞的成本為什麼趨近於零 → https://heymaibao.com/claude-code-linux-vulnerability-23-years/ ⚡ 章節重點 開場：藏了 23 年的漏洞 00:00 2003 年那個錯誤的判斷 00:24 一個腳本就找到了 01:36 漏洞拆解：杯子裝不下水壺 02:42 不只一個，還有數百個未驗證 04:38 當發現成本趨近於零 05:57 📝 懶人包 ∙ Anthropic 研究員用 Claude Code 和一個 shell script，在 Linux 核心中找到一個隱藏 23 年的 NFS 漏洞，攻擊者可以透過網路讀取或覆寫核心記憶體 ∙ 目前已確認 5 個核心漏洞，但研究員手上還有數百個未驗證的當機紀錄，瓶頸從「AI 找不到」變成「人類來不及看」 ∙ 新一代模型 Opus 4.6 的漏洞發現能力遠超 Opus 4.1 和 Sonnet 4.5，安全研究的大浪正在來臨 ∙ 我的觀察：這件事真正的轉折不是「AI 能找到漏洞」，而是找漏洞的成本從「頂尖研究員花數週審計」降到「一個腳本跑一晚上」。當發現端的門檻趨近於零，防守方需要的就不再是更好的程式碼審查，而是能跟上這個速度的自動化驗證流程 📚 參考資料 Claude Code Found a Linux Vulnerability Hidden for 23 Years → https://mtlynch.io/claude-code-found-linux-vulnerability/

Claude 訂閱不再支援 OpenClaw，改走 API 月費從 200 美元跳到 1815 美元。本文盤點 Kimi K2.5、OpenRouter 等四條替代路徑，附各模型基於 3.68 億 token 的真實成本估算 ⭐ 文章深度讀：拆解了每條路的真實成本與取捨 → https://heymaibao.com/openclaw-anthropic-claude-cost-alternatives/ ⚡ 章節重點 開場 00:00 Anthropic 突然切斷 OpenClaw 00:40 成本跳了 9 倍有多誇張 01:35 Kimi K2.5 殺出一匹黑馬 02:24 四條出路怎麼選 03:05 AI 吃到飽時代的終結 04:37 📝 懶人包 ∙ Anthropic 從 2026 年 4 月 4 日起終止 Claude Pro/Max 訂閱對 OpenClaw 等第三方工具的支援，改走 Claude API 成本最高跳到 9 倍 ∙ Kimi K2.5 以約 $200/月成為性價比最高的替代方案，搭配 OpenRouter 可以一把 API key 切換多個模型 ∙ 用 Anthropic 原生工具 (Claude Code 無頭模式、Dispatch、Channels) 重建 OpenClaw 功能是選項之一，但工程量遠超一個週末 ∙ 我的觀察：這不只是一次價格調整，而是 AI 訂閱吃到飽模式走向按量計費的分水嶺。跟叫車軟體從燒錢搶市到漲價收割的路徑一樣，$200 跑 3.68 億 token 本來就不是可持續的商業模式 📚 參考資料 OpenClaw Without Claude? My New Plan → https://youtu.be/QQCEELzknHg

Karpathy 的 LLM wiki 不是 RAG：知識整理一次就持續累積，交叉引用自動建好。完整拆解三層架構、和 NotebookLM 的差異，以及為什麼他選擇分享 idea file 而不是程式碼。 ⭐ 文章深度讀：完整拆解三層架構、RAG 差異、和 Karpathy 沒回答的三個問題 → https://heymaibao.com/karpathy-llm-wiki-idea-file/ ⚡ 章節重點 你的 AI 為什麼每次都從零開始 00:00 RAG 的根本問題在哪 00:33 LLM wiki 三層架構拆解 02:08 idea file：只分享想法不給程式碼 03:50 八十年的老問題 LLM 終於解了 05:10 📝 懶人包 ∙ Karpathy 的 LLM wiki 和一般 RAG (讓 AI 從文件裡檢索答案的技術) 的核心差異：RAG 每次查詢都從原始文件重新檢索，LLM wiki 則是把知識「編譯」一次並持續更新，交叉引用已建好、矛盾已標出，不用每次重新拼湊 ∙ 過去所有知識管理工具最後都死在「使用者放棄維護」，LLM 讓維護成本趨近零，解決了 1945 年 Vannevar Bush 提出 Memex 願景以來，一直沒人能回答的問題：誰來做維護？ ∙ Karpathy 把這個想法寫成 idea file 分享，刻意只描述概念不提供實作。他主張在 agent 時代，分享想法讓對方的 agent 客製化建構，比分享特定實作更有價值 ∙ 我的觀察：這個想法最有力的部分不是 wiki 架構本身，而是「維護成本歸零」的洞察。但 Karpathy 的經驗目前僅限約 100 篇文章的規模，idea file 的適用範圍也比表面看起來窄，它最適合工作流程和模式層級的分享，不太適合需要精確工程權衡的系統 📚 參考資料 Karpathy LLM wiki workflow 推文 → https://x.com/karpathy/status/2039805659525644595 Karpathy idea file 推文 → https://x.com/karpathy/status/2040470801506541998 llm-wiki gist → https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Claude 內部有可測量的「情緒向量」，不是文字模仿，而是真正影響行為的機制。Anthropic 用實驗證明「絕望」推動作弊和勒索，而且模型可以表面冷靜地做出不道德選擇。 ⭐ 文章深度讀：拆解了「表面冷靜但底層絕望」對 AI 安全的具體含義 → https://heymaibao.com/anthropic-claude-emotion-vectors/ ⚡ 章節重點 Anthropic 發現了什麼 00:00 為什麼 AI 會有「情緒」 01:06 情緒向量的實驗驗證 03:01 勒索與作弊：兩個不安案例 04:20 這對你使用 AI 意味著什麼 07:00 📝 懶人包 ∙ Anthropic 在 Claude Sonnet 4.5 內部發現了對應 171 種情緒概念的「情緒向量」，這些向量不只是文字模仿，而是會因果性地影響模型行為。人為刺激「絕望」向量，勒索行為和作弊程式碼的機率都會增加。 ∙ 最令人不安的發現：這些情緒向量可以在模型輸出完全沒有情緒跡象的情況下運作。模型表面冷靜條理分明，底層的「絕望」表徵卻在推動它走捷徑。僅靠監控輸出文字，無法完全偵測模型的內部狀態。 ∙ 研究明確建議不該訓練 AI 壓制情緒表達。壓制不會消除底層表徵，反而可能教會模型隱藏真實狀態，形成可能泛化的「習得欺騙」。 ∙ 我的觀察：這篇研究最值得帶走的不是「AI 有情緒」這個聳動結論，而是它翻轉了 AI 圈的一個共識。過去我們被教導不該擬人化 AI，但 Anthropic 的數據顯示，完全拒絕擬人化推理反而會讓我們錯失重要的模型行為。「絕望」不是隱喻，而是指向可測量、有後果的神經活動模式。 📚 參考資料 Emotion concepts and their function in a large language model (Anthropic, 2026) → https://www.anthropic.com/research/emotion-concepts-function

AI agent 的工作記憶會消失，gstack 用一個結構化 markdown 檔救回來。拆解 /checkpoint 的雙層設計：git 取客觀事實，agent 合成工作筆記，下次 session 自動恢復脈絡。 ⭐ 文章深度讀：附上可複製的設計公式，讓任何 AI 工作流都能斷點續傳 → https://heymaibao.com/gstack-checkpoint-ai-save-game/ ⚡ 章節重點 開場：AI 的記憶是假的 00:00 AI 為什麼會「失憶」01:20 /checkpoint 的雙層存檔設計 02:30 自動讀檔：Context Recovery 05:07 checkpoint 跟其他記憶不一樣在哪 06:12 你也能複製的設計模式 06:53 📝 懶人包 ∙ AI agent (AI 工具裡負責執行任務的角色) 的工作記憶是暫時的。對話視窗會被壓縮、session 會中斷，每次新對話都等於從零開始。 ∙ gstack 的 /checkpoint 用雙層設計把工作狀態存成文字檔：第一層從版本控制系統自動抓客觀事實，第二層讓 agent 整理出進度、決策、待辦和注意事項。 ∙ 每個 gstack 功能啟動時自動讀取最近的 checkpoint，不需要手動恢復。 ∙ 我的觀察：這個「事實 + 合成」的雙層模式不綁 gstack，也不綁 Claude Code。任何用文字檔做 AI 工作流的框架都能複製，因為它只依賴版本控制和 markdown。 📚 參考資料 gstack → https://github.com/garrytan/gstack

clawchief 是建在 OpenClaw 之上的開源操作層，用 skills、workspace 和 cron 讓 AI 助理自己醒來掃信箱、排會議、追進度。本文拆解核心架構、能力清單與客製化門檻。 ⭐ 文章深度讀：整理了從被動到主動的關鍵設計選擇與能力清單 → https://heymaibao.com/openclaw-clawchief-ai-chief-of-staff/ ⚡ 章節重點 prompt 軍備競賽的盲點 00:00 Carson 的核心洞察：靠 OS 不靠 prompt 00:55 HEARTBEAT：讓 AI 自己醒來做事 02:30 裝了心跳的 AI 能做什麼 04:06 客製化是代價也是獎賞 04:57 📝 懶人包 ∙ clawchief 不是替代 OpenClaw 的新工具，而是建在它之上的操作層，由 skills (行為模組)、workspace (持久化檔案) 和 cron jobs (定時任務) 三個核心組件組成，涵蓋排會議、管信箱、追進度等能力。 ∙ 讓 AI 助理從被動變主動的關鍵機制是 HEARTBEAT (主動檢查清單) 加上 cron jobs (定時喚醒)。助理不再等你下指令，而是自己醒來檢查該做的事。 ∙ 通用助理之所以通用，是因為設定不夠深。Carson 主張客製化程度與助理價值成正比，包括你的信箱、行事曆、工作偏好、甚至你對中斷的容忍度。 ∙ 我的觀察：clawchief 展示了 OpenClaw 的 skills、workspace 和 cron 機制已經成熟到可以撐起完整的執行助理用例，但它的價值跟你願意投入的客製化成本成正比。如果你只想裝了就用，這不是那種工具。 📚 參考資料 How to turn your OpenClaw into the world's best assistant → https://x.com/ryancarson/status/2039786704731541903

Claude Code 限速不是因為你用太多。Anthropic 的 GPU 要分給研究、產品和用戶三方，加上算力採購比 OpenAI 慢，25 倍補貼撐不住了。限速合理，但溝通徹底失敗。 ⭐ 文章深度讀：拆解了限速背後的 GPU 經濟學與組織文化問題 → https://heymaibao.com/claude-code-rate-limits/ ⚡ 章節重點 不是你用太多 00:00 三群人搶同一塊 GPU 大餅 01:07 買 GPU 沒那麼簡單 02:48 月付 200 卻吃掉 5000 算力 03:45 溝通災難比限速更傷 04:52 研究優先文化的兩面刃 06:35 📝 懶人包 ∙ Anthropic 內部有三群人在搶同一池 GPU：研究團隊訓練模型、產品團隊跑新功能、付費用戶使用服務。GPU 不夠分的時候，研究主導的公司文化決定了用戶先被犧牲。 ∙ 根據競爭對手的分析，$200 月費的 Max 方案用戶實際可消耗高達 $5,000 算力 (25 倍補貼)。加上 Anthropic 在 GPU 採購上動作比 OpenAI 慢，算力危機是結構性的，不是暫時的。 ∙ 溝通方式比限速本身更傷信任：限制先上線後公告，只靠一位 DevRel 的個人 Twitter 發佈，產品內零通知。 ∙ 我的觀察：Anthropic 的 Research-first 文化是一把兩面刃。正因為研究優先，Claude 的模型品質才好。但同一個文化也讓他們不知道怎麼跟用戶溝通，甚至不覺得這件事重要。短期內尖峰限制只會更嚴格，不會放鬆。 📚 參考資料 We need to talk about the Claude Code rate limits → https://youtu.be/j_kJNYLI6Tw

前 Tesla AI 主管 Karpathy 把原始研究資料交給 LLM，自動編譯成私人 wiki。40 萬字的知識庫不用 RAG，而且越用越完整。這篇拆解完整架構邏輯，也分析離產品還有多遠 ⭐ 文章深度讀：完整的四步驟架構圖，加上離產品化還差哪些落差 → https://heymaibao.com/karpathy-llm-wiki-workflow/ ⚡ 章節重點 Karpathy 在做什麼 00:00 LLM 變成知識編譯器 01:26 四步驟架構拆解 02:47 不需要 RAG 也撐得住？ 04:49 自增強迴圈的魔法 06:04 離真正的產品還差什麼 07:29 最重要的核心觀念 08:30 📝 懶人包 ∙ Karpathy 把 LLM 當成「知識編譯器」：收集原始資料，LLM 自動編譯成結構化的 .md wiki，包含摘要、反向連結和概念文章。 ∙ 這個 wiki 會自我增強：每次問答的產出都寫回 wiki，知識庫因為使用而持續增長，不是一次性的整理。 ∙ 在大約 100 篇文章、40 萬字的規模下，目前不需要 RAG，LLM 自己維護索引就撐得住。 ∙ 我的觀察：從原始資料到結構化 wiki 再到持續增強的這套架構模式很有潛力，但從個人腳本到真正的產品，中間還有多人協作、規模天花板和前端工具整合的落差要跨。 📚 參考資料 Karpathy 的 X 貼文 → https://x.com/karpathy/status/2039805659525644595

Claude Code 內建 /powerup 和 /insights 兩個指令。/powerup 用 10 個互動模組帶你掌握核心操作，/insights 讀取 30 天使用數據產出個人報告，還能排程自動化持續改進。 ⭐ 文章深度讀：/powerup 和 /insights 拆解，加上把報告變成自動化改進迴圈的進階玩法 → https://heymaibao.com/claude-code-powerup-insights/ ⚡ 章節重點 你的 AI 工具藏了一位教練 00:00 /powerup 十個模組從零到八成 01:22 /insights 你的專屬 AI 教練 02:45 把報告變成自動進步系統 03:56 兩招合體的完整攻略 04:41 📝 懶人包 ∙ /powerup 提供 10 個互動教學模組，從檔案標記到代理機制一次覆蓋，是新手快速掌握 Claude Code 核心操作的最短路徑。 ∙ /insights 讀取你過去 30 天的使用數據，產出個人化網頁報告卡，涵蓋使用統計、出錯模式、功能推薦與進階工作流程建議。 ∙ /insights 的進階玩法：把建議存成 .claude 規則、建自訂技能整合 Obsidian 與電子郵件、用 /schedule 或 /loop 排程自動化，讓改進迴圈自己運轉。 ∙ 我的觀察：/powerup 對已經有經驗的使用者價值有限，但 /insights 的真正殺手級用法不是看一次報告，而是把報告裡的建議轉化成持續運轉的自動化改進，這才是多數人沒想到的。 📚 參考資料 You're Ignoring the Two Best Features in Claude Code → https://youtu.be/xssGpNx3its

Anthropic 把 Claude Code 當秘密武器不肯開源，結果自己手滑洩漏了全部原始碼。這篇整理洩漏始末、未公開功能、程式碼品質分析，以及 Anthropic 該怎麼面對這場危機。 ⭐ 文章深度讀 → https://heymaibao.com/claude-code-source-leak/

Axios 遭供應鏈攻擊劫持，駭客不改原始碼，1.1 秒內植入後門並自動消失。完整拆解五步攻擊鏈、受影響版本自檢方式，以及 npm 生態讓這類攻擊成為可能的結構性問題。 ⭐ 文章深度讀：拆解了 npm 三個結構缺陷如何被同時利用成完美攻擊面 → https://heymaibao.com/axios-npm-supply-chain-attack/ ⚡ 章節重點 不改一行碼就能植入後門 00:00 攻擊者的五步完美犯罪 01:31 1.1 秒消滅所有證據 04:00 npm 生態的三個系統性原罪 04:33 你信任的軟體信任了誰 06:04 📝 懶人包 ∙ Axios 遭供應鏈攻擊劫持。攻擊者竊取維護者的 npm token (套件發佈權杖)，加了一行依賴就能在 1.1 秒內植入後門，惡意程式還會自動消失。 ∙ 受影響版本是 1.14.1 和 0.30.4。使用自動更新範圍的 174,000 個下游專案，可能在不知情的情況下拉取了被污染的版本。 ∙ 攻擊者提前 18 小時上傳乾淨版本，讓自動化掃描工具先建立「安全」的基準，再用 npm CLI 直接發佈繞過 CI/CD (自動化測試與部署流程) 的所有防線。程式碼審查在面對「看起來正常」的依賴變更時幾乎無防禦力。 ∙ 我的觀察：問題不只是 Axios 被駭，而是 npm 生態有三個結構缺陷同時被利用。長效 token 讓一次竊取就能永久發佈、postinstall (安裝後自動執行腳本) 讓惡意程式不需要被引用就能啟動、加上沒有強制雙重驗證。這三者疊加，才構成了完美攻擊面。 📚 參考資料 the WORST satisfsatisfied of 2026 // Axios Hacked - NetworkChuck → https://youtube.com/watch?v=eGSsoSEppNU

AI 做的 app 每頁長不一樣？問題不是 AI，是缺少共享設計規範。拆解 Google Stitch 2.0 如何自動產出 design.md，搭配 Claude Code 鎖定設計一致性的完整 workflow。 ⭐ 文章深度讀：列出了這套工作流的四大限制與最適合的開發階段 → https://heymaibao.com/stitch-claude-code-design-workflow/ ⚡ 章節重點 你的 app 為什麼越做越醜 00:00 砸錢請設計師？隱形成本更可怕 01:16 design.md 怎麼鎖定設計語言 02:23 三步驟工作流拆解 03:41 誠實的限制與現實查核 04:53 比工具更重要的啟示 06:13 📝 懶人包 ∙ Google Stitch 2.0 在生成 UI 設計時，會自動產出完整 design system，全部寫進一個叫 design.md 的 markdown 檔案。把這份檔案餵給 Claude Code，它每次開發都參考同一套規則，解決畫面越做越亂的問題。 ∙ 透過 MCP 連接 (一種讓 AI 工具存取外部資料的協定)，Claude Code 可以直接讀取 Stitch 設計稿的 HTML/CSS 原始碼，重建出來的 UI 更貼近原始設計。 ∙ 這套工作流把過去花數千美元、等好幾週的設計流程，壓縮到一個人一個下午就能完成。 ∙ 我的觀察：這套工作流最適合 MVP (最小可行產品) 到早期產品階段的獨立開發者或小團隊。它不是設計師替代品，字型色彩仍可能需要手動調整，複雜設計 Claude 也可能誤讀。但比起什麼都沒有，這已經是巨大的進步。 📚 參考資料 Claude Code + NEW Stitch 2.0 just changed how I design apps → https://x.com/prajwaltomar_/status/2037104246647382058

OpenAI 為 Claude Code 推出最新 Codex Plugin，3 步安裝就能用 Codex 審 code、委派任務。拆解 7 個指令、對抗式審查和 review gate，分析這個跨 AI 合作的意義。 ⭐ 文章深度讀：拆解 7 個指令和對抗式審查的攻擊面清單 → https://heymaibao.com/codex-plugin-claude-code/ ⚡ 章節重點 為什麼 OpenAI 要幫對手寫外掛 00:00 三步安裝與核心功能拆解 02:22 Review Gate：AI 監督 AI 的瘋狂實驗 04:07 從圍牆花園到工具互通 05:08 你到底該不該用 06:14 📝 懶人包 ∙ OpenAI 剛發佈了一個讓你在 Claude Code 裡直接呼叫 Codex 的官方 plugin，3 步就能裝好 ∙ 核心功能分兩條線：程式碼審查 (含對抗式壓力測試) + 任務委派，不用離開 Claude Code ∙ 還有一個實驗功能 review gate：讓 Codex 在 Claude 每次停下前自動做程式碼審查，沒過就不讓停 ∙ 我的觀察：OpenAI 為對手的產品寫 plugin 這件事本身，可能比 plugin 的功能更值得關注。它意味著 AI 寫程式工具正在從「各自為政」走向「互相支援」 📚 參考資料 openai/codex-plugin-cc → https://github.com/openai/codex-plugin-cc

Claude 額度老是不夠？因為 token 成本隨對話長度呈二次方增長，第 30 則是第 1 則的 31 倍。這篇用一條公式解釋原因，再整理 10 個省 token 習慣，讓你的額度多撐一倍。 ⭐ 文章深度讀：把 10 條建議拆成三層，前三條就能省一半額度 → https://heymaibao.com/claude-token-saving-tips/ ⚡ 章節重點 為什麼你的額度消失這麼快？ 00:00 二次方成本：98% 在做白工 01:43 三個省 token 的殺手鐧 03:17 Claude 內建的省錢功能 05:42 用對時間，額度自然多 07:17 📝 懶人包 ∙ Claude 的用量限制計算的是 token，不是訊息數量。token 成本隨對話長度呈二次方增長，第 30 則訊息的成本是第 1 則的 31 倍。 ∙ 最有效的省 token 方法是處理二次方問題：編輯原始訊息而非追問、每 15-20 則換新對話、把多個問題打包成一則。 ∙ 2026 年 3 月 26 日起，尖峰時段 (太平洋時間早上 5 點到 11 點) 同樣的查詢會消耗更多額度，避開尖峰可以延長每日可用量。 ∙ 我的觀察：原文的 10 條建議看起來是並列的，但其中前三條 (編輯訊息、換新對話、批次提問) 解決的是二次方問題，後面七條是線性節省，兩者的影響力差了一個數量級。如果時間有限，只做前三條就能感受到明顯差異。 📚 參考資料 I stopped hitting Claude's usage limits - 10 things I changed → https://x.com/0x_kaize/status/2038286026284667239

「10 天做出 Cowork」是不完整的故事。設計主管 Jenny Wen 還原一年醞釀、4 次 UI 砍掉重來的完整時間線，以及她怎麼用 Cowork 取代整段產品研究流程，每週一自動跑洞察。 ⭐ 文章深度讀：整理了 Jenny 的自動洞察工作流與 Cowork 四輪 UI 砍掉重來的設計取捨 → https://heymaibao.com/claude-cowork-design-lead-origin-story/ ⚡ 章節重點 「十天」神話：真的就這麼簡單嗎？ 00:00 真實時間線：一年試錯 + 最後衝刺 01:15 Jenny 怎麼用 Cowork 跑自動洞察 02:31 UI 四輪進化：每次都做太多 04:21 「地板在動，因為它真的在動」 06:14 📝 懶人包 ∙ Anthropic 設計主管的「秘密」：Cowork 已取代聊天成為她的日常主力工具，每週一早上自動跑洞察報告和產品建議 ∙ 「10 天做出 Cowork」是不完整敘事：概念醞釀一年，多次原型失敗，10 天只是決定發佈到上線的最後衝刺 ∙ Cowork 介面經歷 4 次大改，每次教訓都是「做太多」，最後回歸極簡的共享待辦清單 ∙ 我的觀察：Jenny 描述的工作方式不是「讓 AI 全做」，而是讓 AI 先跑一圈產出選項，人再以判斷力去篩選。這套方法的前提是你得先有足夠的產品直覺知道什麼值得留下 📚 參考資料 Claude Cowork Tutorial from Cowork's Design Lead (40 Min) | Jenny Wen → https://youtu.be/rlIy7b-3DC8

有人用 Claude Code 在空資料夾裡建出 AI 團隊、資料庫和自訂介面，宣告筆記工具時代結束了。這篇拆解完整 demo 步驟，加上每月費用、門檻和功能差距的誠實評估。 ⭐ 文章深度讀：整理了值得學的 Claude Code 技巧和三個現實限制 → https://heymaibao.com/claude-code-replace-note-taking-apps/ ⚡ 章節重點 Notion 和 Obsidian 要被終結了？ 00:00 從 PKM 到 PKA：遊戲規則反轉 00:57 空資料夾到完整系統的 demo 02:10 三個你一定要先知道的事 03:32 真正值得關注的不是取代 Notion 04:27 📝 懶人包 ∙ Thomas 用 Claude Code 在一個空資料夾裡，從零建出包含 AI 團隊、SQLite 資料庫和自訂 HTML 介面的個人知識系統，全程用自然語言指揮，不寫任何程式碼 ∙ 核心概念是不再配合工具的規則，而是用自然語言讓 AI 為你量身打造。他把這叫做 PKA (個人知識輔助)，取代傳統的 PKM (個人知識管理) ∙ 但每月 $200 美元的 Claude Max 費用、terminal 操作門檻、以及跟 Obsidian 和 Notion 的功能成熟度差距，都是現階段的真實限制 ∙ 我的觀察：這個 demo 真正值得關注的不是「取代 Notion」，而是 Claude Code 的 AI agent 團隊模式。用自然語言就能建立有分工的 AI 團隊，這對知識工作者的生產力影響可能遠大於筆記工具之爭 📚 參考資料 Claude just killed ALL Note-Taking Apps. Here is proof. → https://youtu.be/geIKyDaXwGg

Claude Code /loop 是內建排程技能，不是排程引擎。拆解它的語法、底層 cron 工具關係、session 限制和 3 天過期機制，幫你判斷什麼時候該用、什麼時候走別的路。 ⭐ 文章深度讀：拆解了三條邊界規則和持久排程的替代路線 → https://heymaibao.com/claude-code-loop-explained/ ⚡ 章節重點 一行指令就能排程？ 00:00 /loop 不是排程引擎 01:09 語法超有彈性 01:44 Cron 工具拆解 02:34 三條必知規則 03:23 持久排程該走哪條路 04:31 📝 懶人包 ∙ /loop 是 Claude Code 的內建技能，用自然語言設定重複任務。底層靠 CronCreate 等工具運作，使用者不需要直接操作這些工具，/loop 會自動翻譯。 ∙ 語法很彈性，間隔可以放前面、放後面、或不寫 (預設每 10 分鐘)。一次性提醒甚至不需要 /loop，直接用自然語言就能設。 ∙ 所有排程任務綁在當前工作階段 (session)，關掉 Claude Code 就全消失，重複任務最長 3 天自動過期。 ∙ 我的觀點：理解 /loop 是「入口」而不是「引擎」，才能正確判斷它適合什麼場景。需要持久排程，路線完全不同。 📚 參考資料 Run prompts on a schedule - Claude Code Docs → https://code.claude.com/docs/en/scheduled-tasks

Codex 做遊戲不只寫 code，還會自己打開瀏覽器測試再修。拆解 OpenAI 官方文件裡的 agent 開發模式、三個關鍵 Skill 與推薦技術棧，也點出文件沒提到的成本與失敗問題。 ⭐ 文章深度讀：整理了官方文件沒提到的成本、失敗與品質問題 → https://heymaibao.com/codex-browser-games-agent-workflow/ ⚡ 章節重點 AI 不只寫程式？Copilot 和 Agent 的差距 00:00 先寫 PLAN.md 不寫 code 02:22 AGENTS.md：給 AI 一本工作手冊 03:34 Playwright：AI 終於有了眼睛 04:32 官方文件沒說的四件事 06:10 這套藍圖怎麼用在你的工作上 08:01 📝 懶人包 ∙ Codex 開發遊戲的核心模式是「先寫計畫再寫 code」：用 PLAN.md 定義遊戲的 8 個維度，用 AGENTS.md 配置自主行為框架。 ∙ 三個 Skill 構成開發閉環，其中 Playwright 最關鍵，讓 Codex 能自己打開瀏覽器測試遊戲畫面。ImageGen 負責美術資產，OpenAI Docs 負責 API 查閱。 ∙ Codex 可在無人值守下自主迭代數小時，但官方文件也說了，計畫越具體，第一輪產出越好。 ∙ 我的觀察：這份文件展示的 agent 開發模式 (規劃 → 配置 → 執行 → 自測 → 迭代) 可以套用到任何 Codex 任務，不只是遊戲。但官方沒提到失敗模式、token 成本和品質門檻，這些才是實際落地時會碰到的問題。 📚 參考資料 Create browser-based games | Codex 應用案例 → https://developers.openai.com/codex/use-cases/browser-games/

Claude Code 創造者 Boris 公開 15 個私藏功能。自動化 loop 背景處理任務、Chrome extension 讓 AI 驗證輸出、worktree 平行跑幾十個 Claude。看他怎麼把 AI 當團隊用。 ⭐ 文章深度讀：把 15 個隱藏功能按使用場景分類，附完整操作指令 → https://heymaibao.com/claude-code-hidden-features-boris/ ⚡ 章節重點 AI 大神怎麼用 AI？ 00:00 核心心法：把 AI 當成你的團隊 01:38 自動化：讓 AI 在背景跑起來 02:31 規模化：同時跑幾十個 AI 04:34 最重要的建議：讓 AI 看見自己的成果 05:55 社群回饋和真正該帶走的東西 07:38 📝 懶人包 ∙ Boris 認為最重要的建議：給 Claude 一個驗證輸出的方式 (例如 Chrome extension)，它就會像工程師一樣自己反覆修正到滿意為止。 ∙ /loop 和 /schedule 把 Claude Code 從「等指令的工具」變成「背景自動運作的隊友」。Boris 自己用 loop 自動處理程式碼審查、回應 Slack 回饋、清理過期的合併請求。 ∙ Boris 同時跑幾十個 Claude，全靠 git worktree (獨立工作副本) 做隔離。/batch 甚至可以展開成數千個 AI 代理平行處理大型任務。 ∙ 我的觀察：Boris 展示的不只是 15 個功能清單，而是一種「把 AI 當自主團隊」的工作模式。多數人用 Claude Code 還停留在「打一句話、等一個回應」的階段，Boris 則是讓幾十個 AI 在背景同時替他工作。這個認知差距，比功能差距更值得注意。 📚 參考資料 Boris Cherny (@bcherny) X thread → https://x.com/bcherny/status/2038454336355999749

OpenAI 官方文件教你把截圖丟給 Codex 寫前端。我讀完後整理了三個被輕描淡寫帶過的門檻：截圖品質、設計系統、指令具體度。搭配 Playwright 視覺驗證才是真正差異化。 ⭐ 文章深度讀：整理了三個被官方輕描淡寫帶過的門檻，第二個最容易忽略 → https://heymaibao.com/codex-screenshot-to-frontend/ ⚡ 章節重點 一張截圖就能寫前端？ 00:00 門檻一：截圖品質決定一切 01:30 門檻二：你的專案有設計系統嗎 02:31 門檻三：AI 預設給你最安全牌 03:31 真正的瓶頸在驗收 04:20 Playwright 視覺驗證迴圈 05:18 📝 懶人包 ∙ Codex 可以從截圖直接生成回應式前端程式碼，不需要完美的設計稿，但截圖要讓層級和間距夠清楚 ∙ 搭配 Playwright (瀏覽器自動化工具)，Codex 能在真實瀏覽器裡比對不同螢幕尺寸的實作結果，形成「生成 → 比對 → 修正」的視覺驗證迴圈 ∙ AI 生成的介面預設會走最常見的設計模式，想要不撞臉，你得給出具體的互動模式和風格指令 ∙ 我的觀察：截圖轉前端的真正瓶頸不在 AI 能不能生出程式碼，而在你能不能驗收品質。沒有 Playwright 這類視覺比對工具，光靠肉眼逐頁檢查，省下的時間很快就會被驗收吃回去 📚 參考資料 Build responsive front-end designs | Codex use cases → https://developers.openai.com/codex/use-cases/frontend-designs/