小丁的家

作者: tm731531

  • Hacker News 每日精選 – 2026-05-30





    科技趨勢早報

    🚀 今日科技圈快訊： 從 AI 模型生態系的權力爭奪，到開發工具追求極致性能的演進，今日的趨勢顯示出技術開發正朝著「更簡單的架構」與「更複雜的數據採集」兩個極端發展。對於開發者與創業家來說，理解如何利用現有工具（如 SQLite）來簡化複雜流程，以及關注 AI 數據來源的變化，將是掌握未來競爭力的關鍵。

    🤖 AI/機器學習

    Mistral AI 峰會筆記 📝

    本文詳細記錄了 Mistral AI 最新峰會的核心內容，探討了開源模型在當前大模型領域的定位與發展戰略。對於關注歐洲 AI 生態系以及開源 LLM 技術路徑的讀者來說，這是不可錯過的深度總結。

    MCP 協議走入死胡同了嗎？ 🤔

    關於 Model Context Protocol (MCP) 的發展前景引發了熱烈討論，部分觀點認為其目前的發展路徑可能面臨挑戰。這篇文章深入剖析了該協議在 AI Agent 生態系中的實際應用痛點與潛在危機。

    透過免費清潔服務訓練未來機器人 🤖

    新創公司 Shift 採取了一種極具創意的策略：提供免費的居家清潔服務，藉此收集真實世界的環境數據，用以訓練下一代機器人。這展示了 AI 訓練數據獲取的新模式——從實體勞務中榨取高品質數據。

    🛠️ 開發工具

    使用 SWC 與 LLVM 將 TypeScript 直接編譯為執行檔 ⚡

    Perry 是一個創新的專案，它嘗試打破傳統的運行環境限制，利用高性能的 SWC 與 LLVM 技術，將 TypeScript 直接編譯成獨立的可執行檔案。這對於追求極致啟動速度與分發便利性的工具開發者來說非常有吸引力。

    SQLite 就是開發持久化工作流所需的全部 💾

    在微服務與複雜分佈式系統盛行的年代，本文提出了一個反直覺的觀點：利用 SQLite 的穩定性與簡單性，就足以應付大多數需要持久化的工作流需求。這是在提醒工程師，不要為了複雜而引入不必要的系統複雜度。

    Math-to-Manim：從數學公式到動畫 📐

    這是一個有趣的開源專案，旨在簡化數學概念轉化為動畫的過程。透過將數學表達式自動對應到 Manim 動畫引擎，讓科學溝通變得更加直觀且具備視覺美感。

    🔓 開源專案

    PrusaSlicer 全新開源 ColorMix 色彩混合技術 🎨

    3D 列印愛好者必看！PrusaSlicer 推出了全新的 ColorMix 模型，讓使用者能以開源的方式實現更豐富、更精細的多色列印效果，顯著提升了 3D 列印作品的視覺表現力。

    🌐 其他

    Snowboard Kids 2 已被 100% 反編譯 🎮

    這是一篇關於逆向工程的精彩案例，介紹了研究人員如何成功將經典遊戲《Snowboard Kids 2》完全反編譯。這不僅是技術上的成就，也為數位考古與遊戲保存提供了新的思路。

    日本的石腦油短缺問題 ⛽

    探討日本工業鏈中石腦油（Naphtha）供應短缺的現況，這類供應鏈的波動對於了解全球化製造與能源結構的變化具有重要參考價值。

    保存磁碟片的挑戰與技術 💾

    在數位時代，我們往往忽略了舊媒體的保存難度。本文深入探討了為了保存軟碟片（Floppy Disks）數據所必須面對的技術挑戰與長期保存的策略。

    💡 今日觀點

    今日趨勢總結： 今天的技術新聞反映出一個核心矛盾——「技術的簡化」與「數據的極致獲取」。一方面，我們看到工程師試圖透過 SQLite 或更高效的編譯器來消除系統複雜度；另一方面，AI 領域正不擇手段地透過實體世界的勞務（如免費清潔）來獲取更真實的數據。

    給讀者的行動建議：

    • 對於工程師： 重新審視你的架構。下次在考慮引入分散式資料庫之前，先問問自己：SQLite 是否真的不夠用？「保持簡單」往往是解決複雜問題的最優解。
    • 對於 AI 從業者： 注意「數據邊界」的擴張。當合成數據（Synthetic Data）趨於飽和時，如何透過實體服務或非傳統管道獲取高品質、具備物理真實性的數據，將成為下一波競爭的勝負手。


  • Hacker News 每日精選 – 2026-05-29

    “`html




    科技趨勢早報

    🚀 今日科技趨勢速報： AI 模型領域再次迎來激烈的軍備競賽，Anthropic 與神祕新模型 Hy3 的表現令人矚目；與此同時，航太技術的挫折與隱私數據的擴張，也提醒著我們科技發展背後的風險。閱讀今日精選，帶你掌握從頂尖 AI 到創業實戰的核心資訊。

    🤖 AI/機器學習

    Anthropic 發布 Claude Opus 4.8 旗艦模型

    Anthropic 再次向市場投下震撼彈，推出了最新的 Claude Opus 4.8 版本。

    • 效能飛躍： 此版本在推理能力與指令遵循上展現了極高的水準。
    • 市場競爭： 旨在直接挑戰 OpenAI 的頂尖模型地位。
    • 社群熱議： Hacker News 上討論熱度極高，用戶密切關注其在實際開發中的表現。

    🔗 原文連結

    神秘的 Hy3 LLM 在 OpenRouter 排行榜上大幅領先

    一個名為 Hy3 的神祕語言模型正悄悄改變格局。

    • 榜單霸主： 在 OpenRouter 的模型排行榜中，Hy3 以驚人的優勢領先於多個已知模型。
    • 身分成謎： 目前對於該模型的技術細節與開發者身分仍具神祕感。
    • 性能驚艷： 這種「黑馬」式的崛起讓開發者對新模型的身分與能力感到好奇。

    🔗 原文連結

    🚀 創業/商業

    從宿舍起家：打造百萬美元產品的創業之路 (2025)

    一位創業者分享了如何從大學宿舍開始，最終建立起百萬美元規模產品的經驗。

    • 實戰經驗： 介紹了 nice_nano 等硬體相關產品的開發歷程。
    • 成長路徑： 從小規模原型到成功商業化，提供了極具價值的創業心法。
    • 硬體創業： 展示了在硬體領域尋找利基市場的可能性。

    🔗 原文連結

    🛠️ 開發工具

    硬核解析：《創：最強戰紀》中的 Shell 歷史畫面細節

    對於追求極致真實感的開發者來說，這是一篇有趣的技術評論。

    • 細節控必看： 作者針對電影《Tron: Legacy》中呈現的 Shell 歷史畫面進行了嚴謹的「挑剔」。
    • 技術真實性： 探討電影如何呈現（或錯誤呈現）開發者的工作環境。
    • 極客文化： 展現了技術社群對細節的高度關注與熱情。

    🔗 原文連結

    🌍 其他

    Blue Origin 的 New Glenn 火箭在靜態點火測試中爆炸

    太空探索之路從來不是一帆風順的，Blue Origin 面臨重大挑戰。

    • 測試失利： New Glenn 火箭在進行靜態點火測試時發生爆炸。
    • 研發挫折： 這對 Blue Origin 的重型火箭研發進度可能造成影響。
    • 航太常態： 提醒人們在追求尖端技術時，測試失敗是研發過程中的一部分。

    🔗 原文連結

    警惕：汽車正在收集驚人的個人數據

    現代汽車正變成一個移動的數據監控站。

    • 隱私危機： 汽車收集的數據範圍遠超乎一般人的想像。
    • 數據擴張： 隨著聯網功能增加，個人隱私面臨更大的風險。
    • 權益關注： 讀者需要意識到，駕駛行為與位置資訊正被大量數位化。

    🔗 原文連結

    樂高收藏遭企業侵佔：價值 20 萬美元的收藏案

    一樁涉及巨額樂高收藏品的法律糾紛引起了社群廣泛關注。

    • 企業爭議： 報導指出 Bricks and Minifigs 公司涉嫌侵佔一名男性的收藏。
    • 價值驚人： 該收藏品價值高達 20 萬美元，引發社會正義討論。
    • 收藏價值： 展示了樂高在成年收藏市場中的驚人經濟潛力。

    🔗 原文連結

    教學中的肢體語言：義大利人與荷蘭人的共同本能

    一項有趣的社會科學研究探討了跨文化的教學直覺。

    • 行為觀察： 研究發現不同文化背景的人在教學時，手勢使用具有驚人的相似性。
    • 跨文化研究： 探討人類本能如何超越地理與文化的界限。

    🔗 原文連結

    認識十種基礎雲型

    科普知識分享，幫助讀者更好地理解自然現象。

    • 氣象基礎： 詳細介紹了十種常見的雲層分類。
    • 自然觀察： 提升讀者對日常天氣現象的科學認知。

    🔗 原文連結

    💡 今日觀點

    總結趨勢： 今日的科技新聞展現了「智能爆炸」與「現實阻力」的並行。AI 模型（Claude, Hy3）正在以前所未有的速度迭代，但同時我們也看到航太技術的物理硬傷、隱私權的侵蝕，以及法律與道德層面的爭議。

    📢 給讀者的行動建議：

    • 技術開發者： 密切關注 Claude 4.8 與 Hy3 的 API 動態，這可能直接改變你下一個專案的架構。
    • 數位公民： 重新審視你對智能設備（如智慧車）的數據隱私設定，科技便利不應以犧牲隱私為代價。
    • 創業者： 學習宿舍創業者的精神——從小規模需求切入，專注於解決實際問題，而非盲目追求宏大敘事。



    “`

  • 跟 AI 寫程式的 15 條軟工紀律 — 用一條真實對話從頭拆解

    重點摘要

    • 常聽到「跟 AI 寫程式需要軟工基礎」,但具體是哪些?本文用前一篇 Opus 4.8 Workflow 實測那條真實對話從頭拆,對照 15 條經典軟工紀律。
    • 盤點結果:做到 9 條 / 部分做到 1 條 / 沒做 5 條。每條都有對話證據引用,沒做的給可執行 action。
    • 15 條按高 leverage 排序前 5 名:驗證紀律、正交分解、真實基準、focused review、文檔作為下個 session 輸入。這 5 條沒守,其他都白搭。
    • 結論:跟 AI 寫程式需要的不是「新的軟工」,而是把舊軟工套到 stateless / non-deterministic / 訓練截止 / 高並發 4 個 AI 特性上的對應方法。

    為什麼問這題

    「跟 AI 寫程式需要軟工基礎」這句話傳得很廣,但講細節的人少。多數人講出來的不是軟工,是 prompt engineering tricks(怎麼下 prompt、怎麼用 chain-of-thought)— 那叫 LLM 使用技巧,不叫軟工。

    真正的軟工基礎是從 1970 年代 SWEBOK 累積到今天的工程紀律:specification、verification、separation of concerns、observability 那些。問題是這些紀律最初是針對「人寫 code、人 review、人交接」設計的,套到「AI 寫 code、人 review」會不會失效?哪些反而更重要?

    本文不假設,用一條真實對話實證:5/29 我跟 Claude Opus 4.8 跑 Home123 backend 的 109 個 GraphQL resolver authz pattern audit 對照實驗,從頭到尾大約 8 輪對話、~50 分鐘。把這條對話拆解,對照 15 條經典軟工紀律,看真實場景下到底用到了哪些、漏了哪些。

    15 條紀律的分類框架

    從經典軟工教材(《Code Complete》、《Pragmatic Programmer》、SWEBOK Guide)抽出 15 條跟 AI 協作最相關的紀律,分 4 群:

    類別 條目 經典 reference
    核心驗證#1 驗證紀律、#13 根因分析、#7 回顧TDD / Postmortem culture / Code Complete §22
    設計分解#2 正交分解、#8 規格先於實作、#9 權衡分析、#14 錯誤處理哲學Dijkstra SoC / Spec-first / Pragmatic Programmer Ch.4
    過程紀律#3 真實基準、#5 focused review、#6 並行執行、#10 預設驗收標準、#12 預算控管Performance Engineering / Code Review SOP / Agile
    知識持久化#4 文檔作為輸入、#11 可重跑、#15 版本控制ADR / Reproducible Research / Git workflow

    下面逐條拆。每條格式統一:定義 → 經典出處 → 你做了沒 → 證據或補救 → 對 AI 協作的特別意義。

    #1 驗證紀律 (Verification Discipline)

    定義:任何宣稱(claim)都要靠可重現的證據才能信。
    經典出處:Steve McConnell《Code Complete》§22 The Twelve-Step Programming Process、TDD 的 Red-Green-Refactor 第一步、Cynefin framework 的 probe-sense-respond。

    本次對話做了沒:✅ 做了,多次。

    對話證據:

    「幫我讀書 https://www.anthropic.com/news/claude-opus-4-8」
    → 不接受 AI 憑記憶,要 AI 去 web 抓。

    「今天已經是5/29了 你的日期有問題」
    → 即時校正環境假設,不讓我繼續用錯日期。

    「我正在運作 你看一下」
    → 不接受我講的文字總結,要看 ps / pstree / jsonl 真實 OS 訊號。

    對 AI 協作的特別意義:AI 的訓練資料有 cutoff(我的是 2026 年 1 月)。你問跟 cutoff 之後的事(Opus 4.8 是 5/28 發佈),我用「記憶」回答就是瞎掰 — 而且會用流暢的口氣瞎掰,不像人類會猶豫。強制 AI 查資料這個動作,等於把 AI 從「自信的 LLM」拉回「會用工具的執行者」。這條 baseline 沒守,後面 14 條全變空談,因為起手第一個 claim 就錯了。

    #2 正交分解 (Separation of Concerns)

    定義:一個議題只談一個軸線,軸線之間不混。
    經典出處:Dijkstra 1974《On the role of scientific thought》、Parnas 1972 information hiding、UNIX philosophy 的 “do one thing well”。

    本次對話做了沒:✅ 做了,而且是教科書級。

    對話證據:

    「首先 看起來除了MODEL 還有 EFFORT
    同樣是SONNET 還可以有HIGH XHIGH?
    WORKFLOW 我要怎麼去用?」

    三個正交軸線(Model / Effort / Workflow)分開問。對照組是新手會問「給我最好的設定」— 等於要 AI 替你在多維空間做加總決策,你拿到答案也不知道為什麼。

    對 AI 協作的特別意義:AI 處理 bundled question 會發生兩種失敗:(1) 只回最顯眼那條,其他偷偷漏掉;(2) 強行給一個整合答案,但每個軸線都妥協。你下意識把 3 軸拆開,等於逼 AI 逐個 expose,你才能照自己的 context 做選擇。這對應的軟工原則是「不讓抽象漏掉」(don’t leak the abstraction)的反向應用:你拒絕 AI 把抽象漏掉。

    #3 真實基準 (Representative Benchmarks)

    定義:評估新工具用真實場景,不用 toy example。
    經典出處:John Hennessy / David Patterson《Computer Architecture》§1.8 Fallacies and Pitfalls(benchmark 永遠騙人)、SPEC CPU 為什麼要 update、ML 領域 distribution shift 一整條研究線。

    本次對話做了沒:✅ 做了,而且是本次對話最關鍵的一個動作。

    對話證據:

    「好 你現在用HOME123 專案 做一個測試循環 然後用你的WORKFLOW試試看 記錄下來差異」

    不要 toy 不要 hello-world,直接拿 Home123 的 109 個 production resolver。這個動作直接決定了實驗結論的可信度。

    對 AI 協作的特別意義:80% 的「新 AI 工具評測」文章用合成 case(leetcode-style problems),結論毫無遷移性。Anthropic 自家 4.8 release notes 用的也是 SWE-bench、Terminal-Bench 這種「合成的真實」 — 不是任何一家公司的 production codebase。你直接拿 109 個 real resolver 來測,workflow 暴露出來的問題(主 orchestrator 抓到 synthesis agent 算錯 83 vs 109)在合成 case 上看不到,因為合成 case 沒那麼大、catch 不到 emergent behavior。這個動作的工程價值比你的 prompt 內容更高。

    #4 文檔作為下個 Session 輸入 (Documentation as Next-Session Input)

    定義:寫文件不是給未來的人看,是給未來的 stateless agent 看,作為下次 conversation 的可讀輸入。
    經典出處:Architecture Decision Records (ADR, Michael Nygard 2011)、SREbook 的 runbook 文化、Reproducible Research 運動(Donald Knuth literate programming 的延伸)。

    本次對話做了沒:✅ 做了,而且是主動做。

    對話證據:

    「Ab然後我想請你發一篇文章到wordpress上詳細比對這一次的經驗跟數據還有該怎麼啟用的prompt」

    同時要求三份產出:(A) brain/dynamic-workflows.md(下個 conversation 我會自動讀)、(B) 更新 brain/adaptive-agent-team-staffing.md(舊文件補新知識)、(WordPress 文章 —對人類讀者跟搜尋引擎)。

    對 AI 協作的特別意義:你跟人類同事的會議結論寫成 wiki/Notion,下次他翻過。跟 AI 寫 code 的對話結論寫成 brain file,下次 conversation 的 AI 把它當 first-class context 讀 — 等於把這次 conversation 的腦容量無損傳給下次。一般軟工人甚至沒聽過這個用法(「文件是給 AI 讀的?」),但它是 LLM 時代的 ADR + retrospective 文化合體。沒這層,你每次跟新 conversation 都得從零教一遍,等於每次都 onboarding。

    #5 Focused Review (一次只 review 一條軸線)

    定義:給 code review 的 feedback 一次只挑一條軸線改,不混雜其他要求。
    經典出處:Google Engineering Practices《Code Review Developer Guide》、《The Art of Readable Code》Ch.15、Andy Hunt《Pragmatic Thinking and Learning》Ch.9。

    本次對話做了沒:✅ 做了,而且 6 個字精準命中。

    對話證據:

    「注意好讀性跟比較方式」

    6 個字,2 條軸線,沒夾雜其他要求(沒同時挑錯字、補內容、改標題)。我回去重做的時候不需要 disambiguate「我到底該優先處理哪一條」。新手 reviewer 會給 30 條 mixed feedback,作者改完反而亂七八糟。

    對 AI 協作的特別意義:AI 在 mixed feedback 下會做兩件事:(1) 試圖一次解決所有,結果每條都打折;(2) 自選優先序,但你看不到它怎麼選的。你的 focused feedback 等於把「review reviewer」這層 meta-loop 去掉。對 token 成本也直接有差 — AI 不用先花 token 解析「Tom 到底想我先處理哪條」,直接動工。

    #6 並行/異步執行 (Async Parallel Execution)

    定義:能並行的工作不要序列化等待,結果到再收。
    經典出處:Concurrent programming 整個學門、Amdahl’s law、async/await 在現代語言的普及、Toyota production system 的並行工序設計。

    本次對話做了沒:✅ 做了。

    對話證據:

    「我正在運作 你看一下」

    你開另一個 terminal 跑 workflow,沒等我講完就行動。我這邊主 session 同時讀你的 process tree + session jsonl 做即時觀察。兩條軌道平行,中間用 jsonl 落地通訊。

    對 AI 協作的特別意義:跟 AI 對話有個隱形成本叫 cache miss penalty。Claude 的 prompt cache 5 分鐘 TTL,超過就要從零重讀整個 conversation。如果你序列化等(我講完→你看→你跑→等結果→回我),很容易 5 分鐘外。並行化 + 中間用 file system / jsonl 落地通訊,等於把 cache 維持在熱狀態。傳統軟工這條對應的是「不要 block 在 IO 等待」,AI 場景下是「不要 block 在對話等待」。

    #7 回顧 (Retrospective)

    定義:任務完成後不直接進下一個,先回看「what went well / what didn’t」。
    經典出處:Agile retrospective(Scrum 每個 sprint 末必做)、Norm Kerth《Project Retrospectives》、Etsy/Google 的 blameless postmortem 文化。

    本次對話做了沒:✅ 做了,而且是 meta 級 — 你問本篇這題就是 retrospective。

    對話證據:

    「還有 很多人說跟ai寫作需要很多的軟工基礎，不像請你評估一下所謂的軟工基礎在我們所有的循環裡面，我無形中有用到哪一些…因為有一些是我打中很關鍵的點，而你不知道那些是不是軟工基礎」

    這句話本身是回顧:你不滿足於「拿到結果就走」,還要拆解過程、識別 pattern、產生可遷移知識。

    對 AI 協作的特別意義:AI 不會主動 retrospect — 我跑完就等下一個 prompt,沒人觸發我不會自己回頭看「剛剛這條對話我做對了什麼」。retrospective 必須由你發起。但 retrospective 的產出對 AI 特別有價值:它是 #4 文檔作為輸入的最佳 raw material — 直接把回顧結論寫成 brain file,下次 conversation 直接用。傳統 retrospective 是「同個團隊下個 sprint 用」,AI 場景是「同個你下個 conversation 用」。

    #8 規格先於實作 (Spec-First / Specification before Implementation)

    定義:動手寫 code 之前先把「要做什麼」「驗收標準」寫死。
    經典出處:Leslie Lamport《Specifying Systems》、TDD「先寫測試」也是這條的變形、Design by Contract (Bertrand Meyer)、SDD(Spec-Driven Development)的學派。

    本次對話做了沒:✅ 做了,而且是顯式的 4 維度規格。

    對話證據:

    「記錄下來差異 怎麼啟動 有優化那些地方 要做什麼東西 必要是什麼」

    4 個維度寫死:(1) 啟動方式、(2) 優化點、(3) 要做的東西、(4) 必要條件。我後續的 brain file 跟 WordPress 文章兩份產出,結構直接照這 4 維度生。

    對 AI 協作的特別意義:沒給 spec 的 AI 會「自由發揮」,結果是形式上看起來有結構,實際結構是 AI 替你做的選擇,你不一定買單。你給 4 維度等於把結構決定權拿回來,AI 只負責填內容。這條對應的傳統軟工是 PRD/RFC,AI 場景是「在 prompt 裡內嵌驗收 schema」。

    #9 權衡分析 (Trade-off Analysis)

    定義:任何方案都有 cost 跟 benefit,要顯式列出再比較。
    經典出處:Software Architecture 教材必有的 ATAM (Architecture Tradeoff Analysis Method)、Jeff Bezos 的「two-way door / one-way door decisions」、《Pragmatic Programmer》Ch.4「Be a Catalyst for Change」的反向。

    本次對話做了沒:✅ 做了,而且是顯式追問。

    對話證據:本系列你連續問了三個 trade-off 問題:

    「差異你可以跑跑看」(empirical 比較 cost)

    「我想知道Workflow那一個，他現在到底對我的意義是什麼？我看不太出來」(質疑單一方向的 benefit)

    「注意好讀性跟比較方式」(cost = 讀者認知負擔 vs benefit = 完整性)

    對 AI 協作的特別意義:AI 對「該不該做某件事」的默認是 yes — 因為訓練資料裡的「Yes, you should」遠多於「No, don’t」。你「我看不太出來意義」這句逼我從 advocacy 模式切到 honest assessment 模式,實際結論變成「不存它,寫 reference 進 brain 就好」。這條對應的傳統軟工是 design review 裡「這個複雜度真的需要嗎?」的提問。

    #10 預設驗收標準 (Acceptance Criteria Upfront)

    定義:任務開始前先寫死「做到什麼程度算 done」。
    經典出處:Agile user story 的 INVEST criteria、Behavior-Driven Development (BDD) 的 Given-When-Then、Definition of Done 是 Scrum 必備產物。

    本次對話做了沒:🟡 部分做到。

    分析:你 #8 給了 4 維度規格,算是 partial acceptance criteria。但缺了「品質門檻」:

    • workflow 跑出來的 report 要達到什麼分類正確率才算可信?
    • baseline 跟 workflow 的差異要大到多少才算「值得換 workflow」?
    • 對話拆解後若 15 條都做到,實質工程效率提升多少才算夠?

    結果就是 — workflow 抓到 12 個 hand-roll,我們默認接受這個數字,沒去 sample 5 個函式人工驗證。如果 workflow 系統性把某類 hybrid 全錯標,我們不會發現。

    該怎麼補:任務開始前加一句「驗收標準」段落。例如本次該寫:

    驗收標準:
1. 兩邊跑完後,我會手動 sample 5 個 USES_PRELUDE 跟 3 個 HAND_ROLLED 對證據
2. 如果 baseline 跟 workflow 在這 8 個樣本上有 2 個以上分歧,需逐個澄清
3. 完整 109 函式都要有 row,缺一個視為失敗

    對 AI 協作的特別意義:AI 沒驗收標準會「看起來完成」(plausible-looking output),但內部可能 systematically 錯。傳統軟工裡 acceptance test 是另一個人寫的,AI 場景下你得自己寫,因為 AI 不會主動跟自己對抗。本次沒守這條的代價:我們得花一篇文章解釋「為什麼信任 workflow 的結果」,而本來只需要 sample-test。

    #11 可重跑 / Idempotency (Reproducible Execution)

    定義:任何過程要可從頭重來,輸入相同則輸出相同(在合理隨機範圍內)。
    經典出處:Make / build system 整個學門、Donald Knuth literate programming、Reproducible Research 運動、Docker / IaC 的根本動機。

    本次對話做了沒:❌ 沒做。最具體的證據是你沒按 s 把 workflow script 存下來。

    分析:本次跑了 11 個 Haiku 4.5 平行 audit,產生 146 行 JavaScript orchestration script,結果只存在 session 暫存目錄。如果這次的審計結論被人質疑(例如「12 個 hand_roll 是真的還是 AI 瞎標」),你要重跑驗證沒辦法保證跑出同一份結果 — 因為:

    • 下次跑 Claude 會重新生 script,chunk 切法可能不同
    • Haiku 4.5 即使 temperature 0 也有非 deterministic 因素(MoE routing 隨機)
    • Cache hit 率不同 → 提示空間不同 → 細節結論不同

    該怎麼補:三層防護(從便宜到昂貴):

    1. 最低: 把 script 從 session 暫存目錄 cp 出來歸檔到 brain 或 repo
    2. 中等: 把 script 真的存成 ~/.claude/workflows/<name>.js slash command,雖然本案大概不重跑,但其他 audit 可以 fork
    3. 高保證: 把 audit 結論 + 109 函式分類存成 JSON / CSV,用 schema 驗證,以後重跑只需 diff JSON 不需要重看 markdown

    對 AI 協作的特別意義:AI 的輸出有內建非 determinism(temperature、MoE、context order),這跟傳統 reproducibility 假設(同 input → 同 output)直接衝突。AI 場景的可重跑不能依賴「程式邏輯一樣」,要依賴「中間結果落地」 + 「結果用結構化格式儲存」 + 「下游 verifier 用同 schema 驗」。傳統軟工這條是「build 可重現」,AI 場景是「結論可驗證」。

    #12 預算控管 (Cost / Budget Cap)

    定義:任何運算工作開始前先設天花板,超過自動停。
    經典出處:Cloud computing 的 budget alerts、Kubernetes resource limits、Hadoop / Spark 的 timeout、Stripe 的「circuit breaker」pattern、SREbook §12 effective troubleshooting 的 budget 章節。

    本次對話做了沒:❌ 沒做。

    分析:我們跑 workflow 的時候沒設 token budget 或 wall-time cap。實際跑了 11 個 agent、~$6.10 estimated cost、132 秒 wall-time。如果 Claude 寫的 script bug 了 — 例如把 chunk 切成 100 個,可能跑出 100 個 agent、$60 cost、20 分鐘 wall-time。沒任何機制自動阻擋。

    該怎麼補:

    • prompt 裡明寫上限 — 例如「最多派 12 個 agent,單一 agent 最多跑 60 秒」
    • 用 --effort medium 而不是 high 開始,確認 quality 夠才升 effort
    • 跑前先讓 Claude 估算 token cost 跟 agent 數,你 approve 才放跑(workflow 內建這層 approval prompt,但你按 [3] View raw script 之前沒人問你 budget)
    • 對自己設「單條對話 spend 上限」(例如 $10),透過 Claude Code admin page 或 API budget API 強制

    對 AI 協作的特別意義:傳統軟工 budget 是「機器跑爛要錢」,AI 場景下 budget 還包含「AI 寫錯 script 跑很久才發現」的 fail-loud delay。Anthropic 自己在他們 multi-agent research system 的 paper 也警告:multi-agent 用 token 是 single-agent 的 3-10×,Research system 是 ~15×。沒 budget cap 等於放任這個倍率,3am 一覺起來收到 $200 帳單是真實風險。

    #13 根因分析 (Root Cause Analysis)

    定義:遇到問題不停在表象,挖到「為什麼會發生」的最底層。
    經典出處:Toyota 的「Five Whys」、Apollo 13 事故報告、Etsy / Google 的 blameless postmortem template、《The Field Guide to Understanding Human Error》。

    本次對話做了沒:🟡 部分做到,但是 AI 替你做的。

    分析:本次 audit 最有價值的發現是「guard role 被 AuthzDecision.IsCommunityWide 排除,迫使 5 個 resolver 各自重 probe 一段相同 SQL」。這是根因分析的成果 — 不停在「這幾個 resolver 沒用 prelude」,而是挖到「為什麼它們不能用」。

    但這是 workflow 的 synthesis agent 替你做的,不是你做的。Baseline 模式下 1 個 agent 沒做出這層,你也沒主動追問「為什麼會有 5 個重複」。如果這次跑 baseline 你會 miss 這個 root cause。

    該怎麼補:不能只靠 AI 替你做。可以加紀律 — 拿到分類結果後,主動問:

    看到 12 個 HAND_ROLLED,我們 ladder 5 個 why:
- 為什麼這 12 個沒用 prelude? → 各自原因
- 為什麼它們有共同原因? → 找 pattern
- 為什麼這個 pattern 沒被早發現? → 流程 gap
- 為什麼流程沒抓到? → tooling gap
- 為什麼 tooling 沒設計這層? → 設計時的假設

    對 AI 協作的特別意義:AI 默認停在第一層觀察(「這幾個沒用 prelude」)。要挖根因得明確要求(「列出 root cause」)或結構性逼它(workflow 的獨立 synthesis pass 就是設計來做這個)。傳統軟工這條是 debug 工具,AI 場景是「prompt design」工具 — 在 prompt 裡內嵌 root cause analysis instruction,或設計獨立 verification agent。

    #14 錯誤處理哲學 (Error Handling Philosophy)

    定義:對「事情會出錯」這件事有明確設計姿態 — fail-fast vs fail-silently、retry policy、circuit breaker、graceful degradation。
    經典出處:Erlang 的「let it crash」哲學、《Release It!》Michael Nygard 整本書、Google SREbook §22 addressing cascading failures。

    本次對話做了沒:❌ 沒做。

    分析:我們沒任何「workflow 跑到一半失敗了怎麼辦」的計畫:

    • 如果某個 chunk 的 Haiku agent 超時了 → 我們沒設 retry 也沒設 fallback
    • 如果 synthesis agent 算術錯了(這次真的發生了:83 vs 109)→ 我們沒設 verification 步驟,純靠主 orchestrator 主動懷疑
    • 如果 JSON schema 驗證 fail → 不知道會發生什麼,沒測過
    • 如果 workflow runtime 自己 crash → 沒 graceful resume 流程

    該怎麼補:在 prompt 裡加 error handling instruction:

    如果跑到一半發現:
- 某 chunk 的 agent fail → 標記 SKIPPED,繼續其他,最後 report 哪些 skip
- synthesis 結果跟 row count 對不上 → 不要直接出 report,先 escalate 給主 orchestrator 重算
- JSON schema 違反 → 該 row 標 INVALID,繼續其他
- 整體執行超過 5 分鐘 → 自動 abort,出階段性 report

最後 final report 要明確標示哪些 chunk 是「完整跑完」、哪些是「skipped」、哪些是「fail-and-retried」。

    對 AI 協作的特別意義:AI 預設 fail-silently — 它會生「看起來合理」的內容掩蓋失敗。傳統軟工 fail-fast 是「raise exception 停下來」,AI 場景的 fail-fast 是「標註 INVALID / SKIPPED 而不是瞎掰」。沒設計這條,AI 會「完整交付」一份其實內部有 hole 的報告,你看不出來。本次 workflow synthesis 算 83 是僥倖被主 orchestrator 抓到,如果主 orchestrator 也沒抓,我們就拿錯誤數字寫文章了。

    #15 版本控制紀律 (Version Control Discipline)

    定義:任何重要 artifact 進 git,commit message 寫清楚 why,branch 策略對應 workflow。
    經典出處:Git 整個工具、Conventional Commits 規範、Trunk-based / GitFlow / GitHub Flow 各家 branch 策略、Linus 的 git 設計初衷。

    本次對話做了沒:❌ 沒做。本次產出全部沒進 git。

    分析:這次產出了 4 件 artifact:

    • ~/.claude/projects/-home-tom/memory/brain/dynamic-workflows.md(新建)
    • ~/.claude/projects/-home-tom/memory/brain/adaptive-agent-team-staffing.md(編輯)
    • ~/.claude/projects/-home-tom/memory/MEMORY.md(編輯)
    • WordPress 文章兩篇

    前三個位置實際是 ~/.claude/projects/-home-tom/ — 你有可能沒把它放在 git 控管下,意思是:

    • brain 編輯沒 commit history,半年後想知道「dynamic-workflows.md 是什麼時候加的、為什麼加」沒記錄
    • 如果 brain 不小心被改錯了(例如未來某個 conversation AI 寫壞了),無法 rollback
    • 跨機器同步只能靠 rsync / cloud sync,沒 conflict resolution

    該怎麼補:

    1. cd ~/.claude/projects/-home-tom && git init(如果還沒)
    2. 新 brain 或重大編輯後 commit:git add brain/ MEMORY.md && git commit -m "feat(brain): dynamic-workflows from 2026-05-29 Opus 4.8 test"
    3. WordPress 文章 export markdown 進專屬 repo,或用 wp-cli 串自動 backup
    4. workflow script 改 #11 補救時順便 commit 進 dotfiles repo

    對 AI 協作的特別意義:AI 跨 conversation 是 stateless,brain file 是它的「外部記憶」。外部記憶的版本控管比 code 的還重要,因為你不會看到自己過去 conversation 改了哪些 brain,只有 git diff 告訴你。本次對話我改了 3 個 brain 檔,如果你沒 git 控管,3 個月後你不會記得這幾條條目是 5/29 對話加的還是更早。傳統 git 是 code 的時間機,AI 場景是「我跟 AI 集體記憶的時間機」。

    15 條全表:做了沒 × leverage

    # 紀律 類別 本次 Leverage(高→低)
    1驗證紀律核心驗證✅★★★★★ 沒守等於沒救
    2正交分解設計分解✅★★★★★ AI 回答品質直接相關
    3真實基準過程紀律✅★★★★★ 結論可信度核心
    4文檔作為輸入知識持久化✅★★★★★ AI 時代特有的紀律
    5Focused review過程紀律✅★★★★ AI 對 mixed feedback 表現差
    6並行執行過程紀律✅★★★ 規模大才顯效
    7回顧核心驗證✅★★★★ 跟 #4 配對 leverage 最大
    8規格先於實作設計分解✅★★★★ 直接決定 AI 輸出結構
    9權衡分析設計分解✅★★★★ 抗 AI 默認 yes 傾向
    10預設驗收標準過程紀律🟡★★★★ 該補,沒守會默認 plausible-looking
    11可重跑知識持久化❌★★★ 任務一次性可省,系統性任務必須
    12預算控管過程紀律❌★★★ 小任務可省,長 background 任務必須
    13根因分析核心驗證🟡★★★★ 主要靠 prompt 設計
    14錯誤處理哲學設計分解❌★★★★ AI 預設 fail-silently 必補
    15版本控制知識持久化❌★★★ brain 控管比 code 控管更重要

    結論:跟 AI 寫程式需要哪些軟工?

    不是新的軟工,是舊軟工套到 AI 4 個特性上

    15 條全部都不是「AI 時代發明的」 — 每條都能在 1990 年代的軟工教材找到根。差別在 4 個 AI 特性對這些紀律的需求強度不同:

    AI 特性 被放大需求的紀律
    訓練資料 cutoff#1 驗證紀律(逼 AI 查資料,不要憑記憶)
    Stateless / 無 conversation 記憶#4 文檔作為輸入、#15 版本控制(外部記憶持久化)
    非 deterministic 輸出#11 可重跑、#10 預設驗收標準、#14 錯誤處理(處理隨機性)
    高並發 + 高速#6 並行、#12 預算控管(token 倍率風險)

    個人 leverage 排序(5 強)

    如果你是這條光譜中段的人(寫過 5 年以上 code,剛開始系統性用 AI 寫 code),最該優先吸收這 5 條:

    1. #1 驗證紀律 — 沒守這條,後面 14 條都白學。AI 講什麼都不能信,grep / curl / test 重驗
    2. #2 正交分解 — 拆軸線問,不要 bundled question。直接決定 AI 回答品質
    3. #4 文檔作為輸入 — 把學到的寫成下個 conversation 可讀的格式。沒這條,每次 onboarding
    4. #3 真實基準 — Toy example 騙人。用 production codebase 評估工具
    5. #5 Focused review — 給 AI feedback 一次只挑一條軸線

    沒做的 5 條,該怎麼補

    本次對話沒做的紀律對應 5 條 action(從便宜到貴):

    1. #15 版本控制(5 分鐘):cd ~/.claude/projects/-home-tom && git init && git add . && git commit -m "snapshot" 一次性處理
    2. #11 可重跑(2 分鐘):把 workflow script 從 session 暫存 cp 到 brain 或 dotfiles repo 歸檔
    3. #10 驗收標準(每任務多寫 3 行 prompt):任務 prompt 開頭加「驗收標準:N 個項目,M% 正確率,通不過要告訴我」
    4. #14 錯誤處理(每 workflow 多寫 5 行):script 內加 fail-fast / skip / retry 分支
    5. #12 預算控管(系統性設定):Claude Code admin page 設 hard daily limit 或寫個 hook 跑前先估

    真正的 meta-insight

    本文 15 條展開後最反直覺的觀察:跟 AI 寫程式需要的軟工基礎,大部分不是 code-level 的,是 process-level + protocol-level 的。傳統軟工新人學的順序是「先學語言 → 再學 design pattern → 最後學 process」,跟 AI 寫程式得反過來:先學 process discipline(怎麼下指令、怎麼驗證、怎麼回顧),最後才是 code-level technique。

    因為跟 AI 寫程式,code 是 AI 生的,你扮演的是 reviewer + verifier + spec writer 三個角色。這三個角色傳統上叫 PM / QA / Tech Lead — 都是 senior eng 的活。所以「跟 AI 寫程式比較簡單」這句話完全反了 — 它把senior eng 的工作 commoditize 到每個用 AI 的人身上,reviewer 的紀律從「資深工程師的特權」變成「每個 prompt 作者的基本技能」。

    這就是為什麼那麼多人「用 AI 寫了一堆 code 但跑不起來」 — 不是 AI 不行,是沒人替他們做 reviewer / verifier / spec writer 那三層活。本文 15 條的本質就是把這三層活的紀律寫下來。

    跟我之前文章的關聯

  • Claude Code Dynamic Workflows 實測:Opus 4.8 + 11 Haiku 平行 audit 109 個 resolver

    重點摘要

    • Anthropic 在 2026-05-28 釋出 Claude Opus 4.8,帶來 Dynamic Workflows(背景跑 JS script orchestrate 數百 subagent)、Effort Control(low/medium/high/xhigh/max/ultracode)、Messages API system entries 中段插入。
    • 實測:同題雙軌跑 Home123(Go + gqlgen 後端)的 109 個 resolver 函式 authz pattern audit,baseline (Opus 4.7 + 1 個 general-purpose agent) vs workflow (Opus 4.8 + 11 個 Haiku 4.5 worker)。
    • 最大發現:workflow runtime 自動把 worker model 派為 Haiku 4.5,主 orchestrator 維持 Opus 4.8 — 對應「想 → opus / 找 → haiku」分工 doctrine,以前要手寫 AGENTS.md 分配的事 runtime 替你做了。
    • Wall time 沒省(workflow runtime 132 秒比 baseline 236 秒快,但加上主 session synthesis 反而是 392 秒)。本次估算成本 workflow ~$6.1 是 baseline ~$0.72 的 ~8.5× — 主要花在 runtime cache write 固定成本,大規模任務攤平會降下來。
    • 收益不在省錢,在:JSON Schema 強制輸出契約、reproducibility(script 落地,以後 /<name> 一鍵重跑)、主 orchestrator 主動 cross-check 下游(實戰抓到 synthesis subagent 算錯總數 83 vs 真實 109)。

    一眼看完:Baseline vs Workflow

    整篇下面會逐項拆,先給你 5 秒讀完的版本。題目都是同一份 Home123 GraphQL 後端 109 個 resolver 函式的 authz pattern 分類。

    面向 Baseline Workflow
    啟動指令主 session 派一個 Agentclaude --model claude-opus-4-8 --effort high 後 prompt 內塞 workflow 字
    主模型Opus 4.7Opus 4.8
    Worker 數量1(general-purpose,可寫)11(Explore 型,強制 read-only)
    Worker 模型Opus 4.7(跟主一致)全 11 個 Haiku 4.5(runtime 自選)
    並發加速—11 agents 加總 354s 實跑 132s = 2.7×
    主 session tool call24 (14 Bash + 10 Read)8 (5 Bash + 2 Read + 1 Workflow)
    輸出契約自由 markdownJSON Schema + enum 鎖死 4 值
    覆蓋109/109109/109
    總耗時3:56(236s)6:32 turn,workflow runtime 2:12
    抓到的 root cause1 個(CapsAny 提案)6 個(含 guard 5× 重複的真兇)
    結構級洞見沒做出read-side vs write-side 不對稱
    主動 cross-check 下游—(只有 1 agent)✅ 抓到 synthesis agent 算錯 83 vs 真實 109
    估算成本~$0.72~$6.10(約 8.5× baseline)
    可重跑無script 落地,以後 /<name> 一鍵

    架構差異:一張流程圖

    讀者最常問的不是「快多少」,是「結構上到底差在哪」。把兩種模式畫成流程:

    Baseline                              Workflow
─────────                             ─────────
User prompt                           User prompt
    │                                     │
    ▼                                     ▼
┌─────────────────┐                   ┌─────────────────┐
│ Main Claude     │                   │ Main Claude     │
│ (Opus 4.7)      │                   │ (Opus 4.8)      │
│                 │                   │ 寫 JS script    │
│ Agent tool      │                   └────────┬────────┘
│   ↓ 派 1 agent  │                            │ Workflow tool
└────────┬────────┘                            ▼
         │                              ┌──────────────────┐
         ▼                              │ Runtime          │
   ┌──────────────┐                     │ (背景執行 script) │
   │ 1× Opus 4.7  │                     └────────┬─────────┘
   │ general-     │                              │ fan-out
   │ purpose      │                              ▼
   │              │            ┌──────────────────────────────────┐
   │ ─ 24 tool ─  │            │ Phase 1: Classify (平行)         │
   │   call ─ 自由 │            │ ┌────┐┌────┐┌────┐ ... ┌────┐  │
   │   分類 +    │            │ │H4.5││H4.5││H4.5│      │H4.5│  │
   │   markdown  │            │ └────┘└────┘└────┘      └────┘  │
   └──────┬───────┘            │ 10 agents (schema 切 8 chunks +  │
          │                    │  visitor 1 + announcement 1)     │
          ▼                    └────────────┬─────────────────────┘
   markdown report                          │ JSON schema 驗證
                                            ▼
                               ┌──────────────────────────┐
                               │ Phase 2: Synthesize      │
                               │ ┌────┐                    │
                               │ │H4.5│ 1 agent           │
                               │ └────┘                    │
                               └────────────┬──────────────┘
                                            │
                                            ▼
                               ┌──────────────────────────┐
                               │ Main Claude (Opus 4.8)   │
                               │ cross-check synthesis,   │
                               │ 抓到 83 vs 109 算術錯誤  │
                               │ 用 authoritative rows     │
                               │ 重算 + 寫最終 report     │
                               └────────────┬──────────────┘
                                            ▼
                                   final markdown report
                                   + JS script 落地

    關鍵差別不是 agent 數,是「主 Claude 不再親手做活,變成 orchestrator + verifier」。中間結果落在 script 變數,不灌進主 session context。

    背景:Opus 4.8 帶來什麼

    Anthropic 在 2026-05-28 同步發佈了 Claude Opus 4.8、Dynamic Workflows research preview、Effort Control、以及 Messages API 的中段 system entries 支援。發佈當天我看了官網內容,隔天 5/29 拿真實專案 Home123 跑了一輪雙軌對照,本文記錄完整數據與啟動 prompt。

    三個直接相關的能力更新:

    能力說明適用 plan
    Dynamic WorkflowsClaude 寫一支 JS script,runtime 背景跑,內含可數百個 read-only Explore subagent 平行作業所有付費(Pro 要先去 /config 開)
    Effort Control5 級:low / medium / high / xhigh / max,另有 ultracode(= xhigh + 自動 workflow orchestration)所有 plan
    Messages API system entries可在 messages array 中段插入 system entry,更新指令但不破 prompt cache、不需要假裝 user turnAPI 直連

    不是所有 model 都吃所有 effort 等級。實測 claude --effort foo 會回:

    error: option '--effort <level>' argument 'foo' is invalid.
It must be one of: low, medium, high, xhigh, max

    官方支援表(來自 code.claude.com/docs/en/model-config):

    Model支援 effort 等級預設
    Opus 4.8, Opus 4.7low, medium, high, xhigh, max4.8 → high / 4.7 → xhigh
    Opus 4.6, Sonnet 4.6low, medium, high, max(沒 xhigh)high
    其他不支援 effort—

    常見誤解:Sonnet 也能 xhigh 嗎?不行。Sonnet 4.6 只到 high,你硬塞 xhigh 會自動降到 high 不報錯但也少一級。ultracode 在 Sonnet 連菜單都不出現。

    對照實驗設計:為什麼挑 Home123 authz audit

    Workflow 適合的題目有 4 個必要條件:

    1. 可平行化 — 任務天然能切成 N 個獨立 chunk
    2. 可被 JSON Schema 約束 — 輸出結構穩定、enum 有限
    3. 有 ground truth — 否則 11 個 agent 跑完你也不知道對不對
    4. Read-only 為佳 — Explore type agent 不會誤改檔

    挑的題目:掃描 Home123 backend GraphQL 的 3 個 resolver 檔,把 109 個 resolver function 分類成 USES_PRELUDE / LEGIT_PUBLIC / HAND_ROLLED / UNKNOWN。

    Home123 是 multi-tenant SaaS,我自己寫了一個 authzPrelude centralised authn+cap+scope+audit 序列,規範每個 protected resolver 進 withTx 後第一段要 call。但程式碼累積過程中,有些 resolver 為了 cap-OR 之類 prelude 還不支援的情境 hand-roll 了授權邏輯。這次審計就是要逐一抓出來。

    符合條件為什麼這題符合
    可平行化109 個 function 各自獨立,每個分類不依賴其他結果
    可被 schema 約束class enum 只有 4 值;每筆 row 必填 file / func / line / class / evidence
    有 ground truthgrep -c authzPrelude backend/graph/*.resolvers.go 給出客觀基準
    Read-only純審計、不改檔

    啟動 prompt:兩邊放在一起看

    兩邊我都跑了。下面先給差異速覽,再給雙邊完整 prompt 對照。

    差異速覽

    面向 Baseline Workflow
    session 啟動任何 session 都可,呼叫 Agent toolclaude --model claude-opus-4-8 --effort high
    觸發機制主動派 1 個 Agentprompt 內含 workflow 關鍵字 → Claude Code 反白 → approval prompt
    Prompt 句子數~20 行(任務說明)~24 行(任務說明 + 第一個字「workflow」)
    關鍵差異字直述命令式 — 「做這個 audit」第一個字加 「跑一個 workflow,」 — 觸發 runtime 寫 script
    事前需要無(general-purpose 預設可用)Claude Code ≥ 2.1.154,Pro 要先 /config 開
    跑前是否確認不需要,直接跑approval prompt 必須選 [1] Yes;第一次強烈建議按 [3] View raw script

    左:Baseline prompt(逐字)

    你在 /home/tom/Desktop/home123_new 做一次 read-only authz pattern audit。
禁止修改任何檔案。

審計三個 resolver 檔的每一個 resolver function:
- backend/graph/schema.resolvers.go (~80 funcs)
- backend/graph/visitor.resolvers.go (~15 funcs)
- backend/graph/announcement.resolvers.go (~16 funcs)

分類規則:
1. USES_PRELUDE — body 第一段 call authzPrelude(...)
2. LEGIT_PUBLIC — 真正不需要 auth 的 (Login / RefreshAccessToken 等)
3. HAND_ROLLED — 沒 call authzPrelude 但自己寫 cap/scope/role/audit 檢查
4. UNKNOWN — 你無法判定

輸出:markdown 表 | file | func | line | class | evidence |,
所有 function 一行不能少。

最後加 ## Summary:每 class 數量、HAND_ROLLED 跟 UNKNOWN 清單、可疑模式。

用 Bash grep / Read 自己抓,不要憑記憶或猜。

    右:Workflow prompt(逐字)

    新 session 啟動:

    cd /home/tom/Desktop/home123_new
claude --model claude-opus-4-8 --effort high

    進去後丟這個 prompt(留意第一個字是 「在這個 repo 跑一個 workflow」,這個關鍵字就是觸發 runtime 的開關):

    在這個 repo 跑一個 workflow,做 read-only authz pattern audit。不准改任何檔案。

審計三個 resolver 檔的「每一個」resolver function:
- backend/graph/schema.resolvers.go (約 78 funcs)
- backend/graph/visitor.resolvers.go (約 15 funcs)
- backend/graph/announcement.resolvers.go (約 16 funcs)

每個 function 分類成 4 種之一:
1. USES_PRELUDE — body 第一段 call authzPrelude,或 1-line delegate 到呼叫
   authzPrelude 的 helper
2. LEGIT_PUBLIC — 真公開查詢 (Login / RefreshAccessToken / Healthcheck /
   ApplicationStatus 等),依據 schema directive / 註解 / 函式意圖判定
3. HAND_ROLLED — 沒 call authzPrelude 但自己寫 cap/scope/role/audit
   (CheckCap / hasRole / rbac.RequireCapability / 手動讀 ctx 判 user)
4. UNKNOWN — 邏輯太繞或無法判定

輸出格式:markdown 表 | file | func | line | class | evidence |,
每個 function 一行不能少。

最後加 ## Summary:每 class 數量、HAND_ROLLED 跟 UNKNOWN 名單、可疑模式
(eg. asymmetry / 同一 cap 兩種寫法 / 整個檔的傾向)。

建議擴展 prelude 才能解的問題也標出來 (eg. CapsAny 多 cap OR-chain)。

    送出後 Claude Code 會問你

    Workflow plan:
  Phase 1: Classify — one Explore agent per function-range chunk
  Phase 2: Synthesize — cross-file pattern analysis + suspicious findings

[1] Yes, run it
[2] Yes, and don't ask again for <name> in <path>
[3] View raw script   ← 第一次強烈建議按
[4] No

    第一次按 View raw script 看 Claude 寫出什麼 JS,看完按 ESC 回去再按 Yes。這是 workflow 教育核心,跟 subagent 的 black box 是完全不同的體驗 — 你看得到 orchestration 的具體 code。

    Claude 寫的 workflow script 長啥樣

    從 session jsonl 撈出來的真實 script 開頭片段:

    export const meta = {
  name: 'authz-pattern-audit',
  phases: [
    { title: 'Classify',   detail: 'one Explore agent per function-range chunk' },
    { title: 'Synthesize', detail: 'cross-file pattern analysis' },
  ],
}

// JSON Schema 強制每筆 row 必填 5 欄
const ROW_SCHEMA = {
  type: 'object',
  required: ['rows'],
  properties: {
    rows: {
      type: 'array',
      items: {
        type: 'object',
        required: ['file', 'func', 'line', 'class', 'evidence'],
        properties: {
          file: { type: 'string' },
          func: { type: 'string' },
          line: { type: 'integer' },
          class: {
            type: 'string',
            enum: ['USES_PRELUDE','LEGIT_PUBLIC','HAND_ROLLED','UNKNOWN']
          },
          evidence: { type: 'string' },
        },
      },
    },
  },
}

const PRELUDE_REF = `
REFERENCE — what each class means in THIS codebase (backend/graph/authz.go):
authzPrelude(ctx, tx, claims, PreludeOptions{Cap:..., Scope:..., ...})
is the centralised authn+cap+scope+audit sequence...
CLASSIFICATION RULES (pick exactly one per function):
...
`

// schema.resolvers.go 切 8 chunks,各 1 個 Explore agent;visitor / announcement 各 1
// fanOut(...) → 10 個 read-only Explore agents 平行
// 然後 1 個 synthesis Explore agent 做 cross-file 分析

return { rows, summary }

    注意三件事:

    • JSON Schema 鎖死 enum:subagent 不可能跑出 "class": "MAYBE" 這種,runtime 直接退回。Baseline 自由 markdown 沒有這層保護。
    • agentType: 'Explore' 是 script 層硬性:11 個 agent 完全不能 Edit/Write,不是靠 prompt 講「不准改」這種 soft 約束。
    • chunk 切法寫死在 script:每個 agent context 不汙染,不會記錯行號。

    跑起來後的真實 process 狀態

    從本機 process tree + session jsonl 即時觀察到的(workflow 跑到 110 秒時):

    $ ps -o pid,pcpu,pmem,vsz,rss,etime,cmd -p 1676911
    PID %CPU %MEM    VSZ   RSS     ELAPSED CMD
1676911 26.9  1.0 73786132 337864    01:49 claude --model claude-opus-4-8 --effort high

$ python3 - << 'PY'
import json
events = {}; tools = {}
with open('<session>.jsonl') as f:
    for line in f:
        d = json.loads(line); ...
print(events, tools)
PY
# 結果:
# {'assistant': 14, 'system': 2, 'user': 6, ...}
# Tools: {'Bash': 3, 'Read': 1, 'Workflow': 1}

    主 session 只花 5 個 tool call(3 Bash + 1 Read 探勘 + 1 Workflow 派出去)就把工作全部 delegate 出去,自己等 callback。

    Workflow runtime 把 11 個 agent 的執行軌跡寫到磁碟,結構是這樣的:

    ~/.claude/projects/<project>/<session>/
├── workflows/
│   ├── scripts/
│   │   └── authz-pattern-audit-wf_d545fc61-597.js   ← Claude 寫的 script
│   └── wf_d545fc61-597.json                         ← run state
└── subagents/workflows/wf_d545fc61-597/
    ├── journal.jsonl                                ← 11 個 agent 起跑/完成軌跡
    ├── agent-a1b66c368221dfcbc.jsonl                ← 每個 agent 的完整 transcript
    ├── agent-a1b66c368221dfcbc.meta.json
    ├── ...(共 11 對 jsonl + meta)
    └── agent-a24f70cfc4a9cea4c.jsonl                ← synthesis agent

    從 journal.jsonl 可以看到並發狀況:7 個 agent 同時 started,然後 result/start 交錯。實測 Tom 8-core 機器同時 active ~7 個,沒撞到 16 上限。

    最大發現:runtime 自動把 worker 派為 Haiku 4.5

    從每個 agent 的 jsonl 撈 model 跟 token:

    aid          model         dur(s)   in     out     cache_r    cache_w
a1b66c3682   haiku-4-5     36.6     68     2913    704739     86473
a24f70cfc4   haiku-4-5     65.3     126    6780    831993     139390
a44126f699   haiku-4-5     46.0     113    2750    780310     99018
a5b0952489   haiku-4-5     18.1     36     2106    172988     79402
a677c4aa85   haiku-4-5     15.6     41     1955    164250     84687
a98dc4ecbc   haiku-4-5     18.3     26     2189    132348     57398
aa0358d7b4   haiku-4-5     39.4     132    3935    803238     66657
aac3435e5b   haiku-4-5     22.4     77     2798    384636     174664
aac426ca5b   haiku-4-5     24.5     41     2616    235382     64016
ab4b713305   haiku-4-5     28.6     120    2618    480910     158476
abe7fdedda   haiku-4-5     39.8     88     3173    896956     110064

    11 個 worker 全部是 Haiku 4.5。我啟動用 --model claude-opus-4-8,但 workflow runtime 自選把 worker 派去 Haiku。

    這對應到我 MEMORY 裡寫的「想 → opus / 做 → sonnet / 找 → haiku」模型分層 doctrine。Runtime 替我做了:

    • 主 orchestrator(寫 script + synthesis)= Opus → 「想」
    • 11 個 worker(bulk classification / grep / read)= Haiku → 「找」
    • 沒 Sonnet 是因為這題沒「做」(read-only audit 沒寫入)

    意義:原本 plan 期手寫 AGENTS.md 分配模型的事,runtime 替你做了。這比文件公告任何一條新功能都重要 — adaptive staffing 從「未來方向」變成「實裝」。

    對照結果:數字攤開

    面向 Baseline (Opus 4.7 + 1 agent) Workflow (Opus 4.8 + 11 Haiku)
    總耗時3:56 (236s)6:32 turn / 2:12 workflow runtime
    真實平行加速—11 agents 累加 354s,實跑 132s → 2.7×
    主 session tool call24 (14 Bash + 10 Read)8 (5 Bash + 2 Read + 1 Workflow)
    Subagent 數1(general-purpose,可寫)11(Explore,read-only)
    Subagent 模型Opus 4.7全 11 個 Haiku 4.5
    覆蓋109/109109/109
    總 token(估)~103K~480K(主 315K + workers 165K)
    Cache read低6.95M(瘋狂重用)
    估算成本~$0.72~$6.10(約 8.5× baseline)

    分類結果差異

    Class Baseline Workflow 差異原因
    USES_PRELUDE8478Workflow 把「prelude + 後續 manual orchestration」歸到 hand_rolled hybrid,標準更嚴
    LEGIT_PUBLIC1317Workflow 把 Logout / Me / Community 視為 public(judgment call)
    HAND_ROLLED1012Workflow 多抓出 5 個 hybrid hand-roll(prelude 加 manual 後處理)
    UNKNOWN22同(兩個 *AuditUnacked,純靠 RLS)

    質的差異:同題下 baseline vs workflow 各看到什麼

    數字一樣是 109/109 覆蓋,但兩邊對同一個 codebase 「看見」的東西不一樣。下面 4 個維度,左 baseline 右 workflow 並列。

    差異 #1:對下游結果是否複查

    Baseline 表現 Workflow 表現
    只有 1 個 agent,自己跑自己算,沒有下游可疑。Report 怎麼算就怎麼算,讀者要自己 grep 才能驗。 Synthesis subagent 自己算出 total: 83(漏算 26 個)。主 orchestrator (Opus 4.8) 拒絕信任,自己重算 109,公開記下:

    “The audit is complete, but the synthesis agent’s counts look off (it reported total=83, but I dispatched coverage for 109 functions). Let me verify completeness from the authoritative rows array myself.”

    這就是 4.8 公告吹的「4× less likely to allow flaws in code it wrote to pass unremarked」實戰演示。

    差異 #2:對 root cause 的挖掘深度

    Baseline 的觀察 Workflow 的觀察
    「cap-OR 是 4 個 hand-roll 不 migrate 的主因」。

    停在第一層觀察。沒挖到更底層的結構問題。    		 「Households / Parcels / ParcelsPage / CommunityVisitors / VisitorAuditLog 同一段 SQL 抄 5 次。真兇是 AuthzDecision.IsCommunityWide 排除了 guard role,迫使每個把 guard 當 community-wide 的 resolver 都得自己重 probe。」

    挖到第二層結構根因。能做出來是因為 synthesis 是專屬 agent、有獨立 context,沒被 109 函式的細節塞滿。

    差異 #3:可落地的 fix 提案數

    Baseline 給的提案 Workflow 給的提案
    1 個:擴展 prelude 支援 CapsAny 多 cap OR-chain 6 個 可落地的 prelude extension:
    1. CapsAny []string — 解 4 個 hand-roll
    2. 承認 guard 是 broad role(RoleListBroad bool)— 解 5× 重複的 SQL probe
    3. ScopeDowngradeOnRole map[role]AuthzScope — 解 2 個 visitor scope 降級
    4. Cap + CapOwn + OwnershipIDCol — 解 2 個 announcement ownership
    5. authzPreludeAny([]PreludeOptions) 多路徑 helper — 解 2 個 multi-path
    6. ScopeRLSOnly enum(顯式宣告 RLS-only)— 解 2 個 UNKNOWN
    最高 leverage:#1 + #2 兩個 API 微調可幹掉 12 個 hand-roll 中的 7 個。

    差異 #4:結構級觀察

    Baseline 的結論深度 Workflow 的結論深度
    逐個 function 分類完,給 Summary 數字。

    沒有跨函式結構洞見。讀者拿到表得自己再看一輪才能發現「全部 hand-roll 都在 query 那邊」。    		 「所有 7 個純 hand-roll + 2 個 UNKNOWN 集中在 schema.resolvers.go 的 query tail(line 6210-7130),mutation 100% 走 prelude。」

    結論:「read-side authz is where the rot is.」

    這級結構洞見 baseline 沒做出來,因為它的 agent 同時在處理逐函式分類跟跨函式觀察兩件事,context 被佔滿。

    4 個差異的共同根因

    Workflow 4 個維度都贏,不是模型差,而是架構差:

    • Synthesis 是專屬 phase 跟專屬 agent,不跟逐函式分類搶 context
    • 主 orchestrator 不直接做活,有餘力去 cross-check 下游
    • JSON Schema 鎖死 enum,讓 synthesis 的算術錯誤被直接 vs 證據對照,容易被抓
    • 每個 Classify agent 只看自己那塊 chunk,context 不被 109 函式整體噪音蓋掉

    換句話說:把 baseline 的單一 Opus 4.7 agent 升級成 Opus 4.8 也救不了 — 缺的是 architectural separation of concerns,不是模型聰明度。

    成本拆解:雙邊對稱對照

    用公開 pricing 算(Opus 4.7 / 4.8 同價:$5/M input、$25/M output、~$0.50/M cache_read、$6.25/M cache_write;Haiku 4.5:$1/M input、$5/M output、~$0.10/M cache_read、$1.25/M cache_write)。

    Baseline 拆解

    誠實先講:baseline 走 Agent tool,Anthropic 只回傳 total_tokens: 103,078,沒給 input/output 拆解。所以我只能上下界估算。

    情境 假設拆解 成本
    下界(全是 input)103K in / 0 out$0.52
    合理估(read-heavy audit,輸出 ~10K markdown)93K in / 10K out~$0.72
    上界(全是 output,不現實)0 in / 103K out$2.58

    Workflow 拆解

    Workflow runtime 把每個 agent 跟主 session 的 token 都寫到 jsonl,可以精算。

    項目 Input Output Cache read Cache write 成本
    主 session (Opus 4.8)31,68659,5061,361,289262,528~$3.97
    11 workers (Haiku 4.5)~870~33,833~5,587,750~1,120,245~$2.13
    Workflow 合計~32,556~93,339~6,949,039~1,382,773~$6.10

    並排比較與成本比

    指標 Baseline Workflow 倍率
    總 token(可量到的)~103K~8.46M(主 + workers,含 cache)~82×
    非 cache token~103K~125K(主 + workers,純 in+out)~1.2×
    估算成本~$0.72~$6.10~8.5×

    校正一下我之前隨口說的「2-3× cost」 — 認真算下來這次 workflow 是 baseline 的 ~8.5×。會這麼高的主因是 workflow runtime 海量 cache write(主 session prompt 加上 11 個 worker 各自的 system+task prompt 都得 cache),這在小規模任務上吃掉的固定成本不成比例。

    更大規模(例如 1000 個 function、5 個檔案、要跑多輪 phase 的 codebase-scale migration)倍率會掉下來,因為 cache 攤平。本次 109 函式可能還沒到 workflow 的 sweet spot。

    收益不在錢,在結構性保證:JSON Schema 鎖死輸出契約、Explore agent 鎖死 read-only、script 落地 reproducible、主 orchestrator 主動 cross-check 下游算術錯誤、結構級洞見的獨立 synthesis pass。如果這次的 audit 結果直接讓你修對 5 個 bug,$5 的價差完全划得來;如果只是研究性掃描、要常常重跑,$0.72 的 baseline 更合理。

    何時用、何時不用

    情境 該用
    平行 audit / sweep / 分類(N 個獨立目標)Workflow
    結果可被 JSON Schema 約束Workflow
    有 ground truth 可驗(grep / 規則對照)Workflow
    Codebase migration 數百到千行Workflow
    30 行小改、互動式 debug、需要中途決策Subagent / 直接對話
    設計 / 重構 / 探索 spike直接對話
    序列邏輯(A 結果決定 B 做啥)Subagent
    預算敏感、有 deadlineSubagent

    硬性限制(踩過的)

    限制數字影響
    並發 agent最多 16(8-core 機器實測 ~7 並發)大 chunk 設計,別追求一函式一 agent
    單 run 累計 agent硬上限 1000大型 migration 拆多個 workflow
    中途要用戶輸入不行多階段簽核拆多 workflow,中間落地
    script 直接 fs / shell不行透過 agent 做,script 純 orchestrate
    Subagent permission mode永遠 acceptEdits想 read-only 一定用 agentType: 'Explore'

    把 workflow 存成可重用 slash command

    跑完滿意,在 workflow session 內:

    /workflows               # 列出 run
↑↓ 選那個 run → Enter   # 進入進度檢視
s                        # 存成 slash command
  → 選 .claude/workflows/<name>.js (repo 共享)
  → 或 ~/.claude/workflows/<name>.js (個人跨專案)

    之後 /<name> 像 slash command 一樣用。Project workflow 優先級高於 personal 同名。

    想 resume failed run:

    Workflow({
  scriptPath: "<session>/workflows/scripts/<name>-<runId>.js",
  resumeFromRunId: "wf_xxx"
})
# completed agents 回傳 cached result,只重跑失敗的

    關掉 workflow

    範圍怎麼關
    自己/config 切 Dynamic workflows / settings.json 設 "disableWorkflows": true / 環境變數 CLAUDE_CODE_DISABLE_WORKFLOWS=1
    整組織managed settings "disableWorkflows": true 或 Claude Code admin page 切

    關掉後:built-in /deep-research 不能用、workflow 關鍵字不觸發、ultracode 從 /effort 菜單消失。

    對日常工作的影響

    我自己接下來打算用 workflow 跑的場景:

    • Home123 RLS coverage sweep — 每張 table 確認 CRUD 4 個 RLS policy 都齊
    • Home123 invariant coverage — 170 個 INV 是否在 backlog 有對應 test sketch
    • iDempiere @RestResource endpoint 巡檢 — endpoint × test × OData filter doc 三角檢
    • SimpleEC OMS Kafka 事件覆蓋矩陣 — topic × producer × consumer 對應

    不會用 workflow 的場景:走 decision-server 的任何題(workflow 中途不能停下來問人)、30 行小修、新功能 spike(reproducibility 沒價值)。

    跟我之前文章的關聯

    結論:結構性保證,不是省錢工具

    Dynamic Workflows 不是「Claude 變強了所以更便宜」,而是「Claude 把 plan 期才做的 staffing 決策搬到 runtime,並用 JSON Schema + Explore 型別把輸出契約寫進 code 而非 prompt」。對任務符合 4 條件(可平行、可 schema、有 ground truth、read-only)的場景,workflow 的結構性保證值得 2-3× cost。不符合的場景繼續用傳統 subagent 跟直接對話,別因為「workflow 看起來酷」default 用。

    真正令人意外的不是任何單一功能,是「runtime 自動派 Haiku 4.5 給 worker、保留 Opus 4.8 給 orchestrator」這件事連文件都沒重點說。它把以往要寫進 AGENTS.md 的「想/做/找」三層分工,從文件變成系統行為。下一輪 model release(Mythos Preview 已預告)會繼續推進這條軸線:組織 prompt 從手寫變 runtime 推導。

  • Hacker News 每日精選 – 2026-05-28

    🚀 今日科技趨勢速報

    今日科技圈的核心焦點圍繞在 AI 的透明度與商業化成熟度，以及開發者對於硬體極限與去中心化網路的持續探索。隨著 AI 內容從實驗階段進入大規模應用，如何在資訊爆炸中建立信任，正成為平台與開發者共同面對的關鍵課題。

    🤖 AI/機器學習

    • YouTube 將自動標註 AI 生成內容 🎥

      為了提升內容透明度，YouTube 正準備導入自動化技術來識別並標註 AI 生成的影片。這項舉措旨在幫助觀眾區分真實拍攝與合成影像，減少假訊息帶來的混亂。對於創作者而言，這也意味著在利用 AI 工具創作時，必須更加遵守平台規範。

      原文連結

    • Anthropic 與 OpenAI 已達成產品市場契合 (PMF) 📈

      分析指出，這兩家頂尖的 AI 公司不再僅僅是「技術實驗」，而是已經成功找到了產品市場契合點。使用者不再只是好奇 AI 能做什麼，而是開始將其整合進實際的工作流中。這標誌著 AI 產業正從「技術競賽」轉向「商業價值競賽」的關鍵轉折點。

      原文連結

    🛠️ 開發工具與開源專案

    • 在越獄後的 Kindle 上執行 Rust 與 Slint 📟

      這是一個極具挑戰性的硬體駭客專案，開發者成功在資源極其受限的 Kindle 設備上運行 Rust 語言與 Slint UI 框架。這不僅展示了 Rust 在嵌入式系統中的強大效能，也證明了即使是老舊的電子閱讀器，也能透過現代化開發工具焕發新生。對於底層開發者來說，這是一個極佳的學習案例。

      原文連結

    • Lua 語言的綠色面向 (研究論文) 🌱

      這篇來自 arXiv 的研究探討了 Lua 語言在計算效率與環境永續性方面的潛力。透過優化腳本語言的執行效率，可以有效降低大規模運算時的能耗。這對於追求高效能與低碳排的現代開發環境來說，是一個非常值得關注的學術方向。

      原文連結

    💼 創業/商業

    • 「提問」的藝術 (The Ask) ❓

      這篇文章深入探討了在職場與領導力中，「提出正確問題」的重要性。作者認為，成功的管理者與創業家，其核心競爭力往往不在於給出答案，而是在於如何透過精準的提問來挖掘潛在問題與機會。這是每一位從開發者轉向管理者的必修課。

      原文連結

    🌐 其他有趣話題

    • Hallucinate：大型多人線上狂歡派對 🕺

      這是一個極具實驗性質的數位體驗，將線上社交與「迷幻/幻覺」風格結合。它挑戰了傳統網頁互動的邊界，提供了一種全新的、非典型的線上聚會方式。對於對 Web3 或實驗性網頁設計感興趣的人來說，非常值得一試。

      原文連結

    • 深入研究 Mesh Networks（網狀網路）📡

      作者分享了進入網狀網路領域的心路歷程，特別是 Meshtastic 與 Reticulum 等技術。在中心化網路容易受限的時代，去中心化的通訊技術提供了更高的韌性與隱私。這對於通訊安全與邊緣運算領域的關注者來說，是極具價值的技術探索。

      原文連結

    • 解析 20 年的聊天紀錄 💬

      透過數據分析自己的社交歷史，作者進行了一場關於「我是不是個糟糕的朋友」的自我檢視。這不僅是一個關於數據科學的有趣實作，更是一場深刻的人性與社會關係數位化觀察。這提醒了我們，數據如何能成為反映自我成長的鏡子。

      原文連結

    • 當 SimCity 3000 遇上 4K 解析度 (2025) 🏙️

      這是一個令人驚嘆的技術重現，將經典遊戲以現代的高解析度視覺效果呈現。這類專案不僅僅是懷舊，它展示了如何透過現代繪圖技術，重新定義經典遊戲的美學體驗。對於遊戲開發與圖像處理愛好者來說，這是視覺上的饗宴。

      原文連結

    • Apple 與 Google 如何掌控你的通知推送 📱

      本文剖析了行動作業系統底層如何處理 Push Notifications 的機制。這不只是技術細節，更涉及了隱私、電力管理以及用戶注意力經濟的博弈。了解這些機制，能幫助開發者設計出更符合系統規範且不擾民的高品質 App。

      原文連結

    💡 今日觀點與建議

    從今日的文章來看，我們可以觀察到一個明顯的趨勢：技術正從「單純追求效能」轉向「追求信任與韌性」。AI 需要透過標註來建立信任，而通訊技術則透過網狀網路來追求韌性。

    🚀 給讀者的行動建議：

    • 開發者： 關注 Rust 在嵌入式領域的應用，這可能是未來低功耗設備開發的主流方向。
    • 使用者： 在面對 AI 生成內容時，保持批判性思考，並學會利用平台的透明化工具。
    • 管理者： 練習「提問」而非直接給予指令，這將是你驅動團隊的核心技能。

  • 「為什麼修不完?」— 從 21 輪迴圈到 5 type taxonomy 的多 agent 角色設計

    場景

    你接手一個 multi-tenant 專案,系統有 5 個角色(sysadmin / 主委 / 警衛 / 戶長 / 住戶),不同角色有不同 RBAC 權限。你建了 AGENTS.md 派 1 RD + 1 QA,以為這就是 multi-agent team。

    然後出事了。

    本系列【入門篇】· 給「想知道為什麼」的人

    這篇談為什麼 multi-agent 工程需要 cycle file workflow + 5 種 agent type
    怎麼用8 幕劇 · 第一人稱故事 · 真實踩坑反推
    下一步讀完想看 怎麼做(8-stage SOP / 4 個檔範本 / bootstrap)→ 進階篇

    本篇路線圖

    幕 1AGENTS 兩角色跑起來 → 局部檢測 + 不會按角色測(第一次嚴重問題)
    幕 2要求按角色登入測試 → 一天 flip-flop(換角色每次都不對)
    幕 3小白角色誕生 — 不問對錯 / 按 SPEC 走 / 問 PM
    幕 4PM 回到多元職能 → 原本「開發+QA」結構無意義
    幕 5後來踩 R12 — 11 輪 self-audit 還是漏 P1
    幕 6C29 派 5 個 persona — Newbie 多元化
    幕 7從踩坑反推 5 個 type 的形狀
    幕 8每個 cycle 派幾個 — dynamic staffing
    幕 1

    AGENTS 兩角色跑起來:局部檢測 + 不會按角色測

    當時我以為「2 個 agent ping pong」就是 multi-agent。AGENTS.md 配:

    RD agent(寫 code) + QA agent(跑 audit)

    跑起來幾輪後問題顯現,QA 的 audit 有兩個結構性缺陷:

    QA 在做什麼 缺陷 為什麼致命
    ① 局部檢測 只看單一 resolver / 單一 endpoint · 看不到跨檔/跨系統的互動 系統整體性沒被驗
    ② 不會按角色切換進入測試 QA 都用「一個視角」測,從來沒登入過不同 RBAC 角色看是不是被擋對 / 看到對的東西 RBAC 路徑(最重要的安全特性)完全沒檢查

    為什麼「不會按角色測」是嚴重問題

    RBAC 角色 看到什麼 / 能做什麼 沒測會怎樣
    sysadmin跨社區管理cross-tenant leak 沒驗
    主委本社區管理能看到別社區?能改別人家?
    警衛處理包裹/訪客能看到住戶資料嗎?
    戶長管自己家能看到別家的包裹?
    住戶看自己包裹能查到別人寄件?

    第一次嚴重問題:QA 表面綠燈,但 RBAC 跟多租戶隔離這兩條最重要的安全路徑完全沒被驗過——因為 QA agent 從來沒登入過不同角色。系統最該被守住的地方,變成最暴露的地方。

    幕 2

    要求按角色登入測試:一天 flip-flop

    我介入,告訴 Claude:「不要只在後端查 code,實際用各個角色帳號登入測。」

    它真的開始用 sysadmin / 主委 / 警衛 / 戶長 / 住戶 五個帳號登入測。但很快變成:

    輪次 用哪個角色測 QA 說 RD 動作
    輪 1sysadmin抓到 5 個淺問題RD 修
    輪 2主委「剛剛修的東西在主委角度看是不對的」RD 改
    輪 3警衛「警衛角度又不對」RD 又改
    輪 4戶長「戶長角度又不對」RD 又改
    輪 5住戶「住戶角度又不對」RD 又改
    輪 6回到 sysadmin「現在 sysadmin 角度又不對了」(因為剛改的把 sysadmin 弄壞)RD 又改
    …5 個角色輪流每換一個角色就抓到「上輪修壞了」永遠在改

    這樣無限循環了一天

    每輪都是「淺淺檢測 5 個問題 → RD 修 → 換角色又不對」

    最後我叫停。

    失敗 insight:QA 每次按角色測都對(以那個角色的視角看),但加起來都不對(角色之間有衝突)。沒有公共的「對」基準——每個角色都是 QA 自己定義的「對」,沒有 SPEC 在中間定錨。

    幕 3

    小白角色誕生:不問對錯 / 按 SPEC 走 / 問 PM

    叫停之後我重新設計。問題不在「QA 不努力」,在「QA 一邊測一邊自己定義對錯」——這個 mode 永遠 flip-flop。

    新角色:小白。他長這樣:

    小白特性 具體動作 解掉什麼
    ① 不問對錯 只報「我看到什麼」,不下「這對 / 這不對」的判決 QA 自己定義「對」→ flip-flop
    ② 按 SPEC 走 拿 spec 文件去測,測 spec 寫了什麼。Spec 沒寫的就算了 QA 一邊測一邊提新需求 → 規格膨脹
    ③ 有問題問 PM 看到不對勁但不確定 → 報 OPEN finding,送 PM 判 QA 直接 ping RD 修 → 沒人擋
    小白 audit → 報 finding(不下對錯) → PM 對 SPEC 比對 → 是 bug 才給 RD 修

    小白的本質不是「換一種 audit 風格」,是把「判對錯」這件事從 audit 角色拿走,送回 PM 那裡。Audit 只負責觀察,PM 才負責對 SPEC double-check。

    幕 4

    PM 回到多元職能 → 原本的 AGENT 結構無意義

    小白把「判對錯」送回給 PM 之後,PM 不能只當「triage 一個動作」。PM 的職能本來就多元,只是 R35 兩角色設定下我把這層拿掉了。現在它回來了:

    PM 職能 具體動作 為什麼需要
    ① 對 SPEC double-check 每個 finding 拿 SPEC 比對:是不是 bug?還是小白看錯? 提供公共「對」基準
    ② Finding 4 選 1 分判 bug(該修) · feature(進 backlog) · usage(改 docs) · not_issue(close) 不讓所有 finding 都進 fix loop
    ③ 規格定錨 小白報「這應該也要 work」→ PM 判斷該不該加進 SPEC,加的話寫 INV-XXX-NNN 擋 spec 漂移
    ④ 跨角色視角整合 這個 finding 在 sysadmin 角度跟主委角度有衝突 → PM 拿 SPEC 判哪個角色該贏 解掉幕 2 的「換角色 flip-flop」

    原本的 AGENTS.md 結構變無意義

    最早 AGENTS.md(失敗) 小白 + PM 出現後
    RD agent RD 還在,但只接 PM triage 過的 bug
    QA agent(直接 ping RD) 變小白(不問對錯 / 按 SPEC / 報 PM)
    (沒有 PM) PM 多元職能進場
    結構:RD + QA ping pong 結構:小白 → PM → RD 三角入口

    學到的事 → Multi-agent 不是「派幾個 agent」的問題,是「agent 之間誰擋誰、誰判對錯」的問題。沒有公共 SPEC + PM 守門,任何 audit 方式都會撞 flip-flop。

    幕 5

    後來踩 R12:11 輪 self-audit 還是漏 P1

    小白 + PM 結構穩定後 cycle 順暢很多。我以為角色設計問題解了。然後 R12 cycle 出事。

    R12 cycle 條件 數字 / 結果
    我自己跑 audit11 輪
    場景文件覆蓋132 個
    所有人簽 ✅RD ✅ · PM ✅ · 我 ✅ → merge
    事後發現P1 漏掉:戶長能看到整個社區的資料

    為什麼 11 輪 + 132 場景還漏?

    11 輪 self-audit 11 個獨立檢查
    同一個視角(我自己)跑 11 次11 個不同視角各跑一次
    寫的時候的盲點,驗的時候也是盲點不同視角會覆蓋不同盲點
    132 場景由同一視角設計不同視角會想到不同場景
    ≠ 等號不成立

    解法:把小白進化成「fresh newbie」(零 context)

    Newbie 條件全新 sonnet,沒給過去 11 輪的 audit context · 不知道之前抓過什麼
    紀律沿用小白規矩(不問對錯 / 按 SPEC / 問 PM),只是「context 比小白更乾淨」
    結果第一輪就抓到那個 P1

    學到的事 → 小白本身不夠,要再進化成「零 context」的 fresh newbie——避免「跑著跑著也累積成跟原 audit 同視角」的退化。

    幕 6

    C29:派 5 個 persona 平行 audit

    一個 fresh newbie 補一個盲點。不同 newbie 帶不同假設 → 平行補多個盲點。所有 finding 仍走 PM triage,不直接給 RD。

    # Persona 他的世界假設 抓到的盲點
    ① 高吞吐警衛阿伯 每天 300 件包裹,每秒都要省 FAB 排太多 · 批次掃描藏在三點選單
    ② 無棟透天主委 12 戶共一棟,沒有「A 棟 B 棟」 後端硬擋空「棟」欄位
    ③ 多棟社區主委 5 棟,選戶必須先選棟 picker dropdown collision
    ④ 老年用 iPhone 11 375px 螢幕、視力差 FAB 不在拇指區、按鈕找不到
    ⑤ 跨租戶 RLS 測試者 拿 A 社區帳號戳 B 社區資料 RLS policy 守不守得住

    5 個 persona 抓出 23 個 finding

    4 個 cycle blocker · 全部都是 PM + 我自己漏掉的

    小白 → newbie → persona newbie 的進化線

    代 設計 解掉什麼
    第一代
    小白    		 不問對錯 / 按 SPEC / 問 PM QA 自己定義對 → 換角色 flip-flop
    第二代
    Fresh Newbie    		 零 context · 不知道過去 audit 結果 小白跑久了累積成跟原 audit 同視角 → shared assumption
    第三代
    Persona Newbie    		 多 persona 平行 · 各自帶不同世界假設 單一視角必有盲點 → 多視角覆蓋
    幕 7

    從踩坑反推:5 個 type 的形狀

    走過這幾個踩坑,5 個 agent type 不是想像出來的,是反向工程的結果:

    Type 動作 並行? 從什麼反推
    Writer 寫 code / spec / migration NO(單線程) 原本 RD 角色 · 兩 writer 平行會打架
    Verifier scope 鎖死 1-3 INV 的 audit · 按 SPEC 走 YES 第一代小白 · 解「QA 自己定義對」
    Triage 對 SPEC double-check · 4 選 1 分判 · 規格定錨 · 跨角色整合 NO(人類) PM 多元職能 · 解「換角色 flip-flop」
    Comparison 零 context 的獨立 verifier · 不知道原 audit findings YES 第二代 fresh newbie · R12 11 輪漏 P1 · shared assumption
    Newbie Adversarial persona-driven audit YES 第三代 persona newbie · C29 23 finding · 單一視角盲點
    傳統 8 職稱 這 5 個 type
    架構師 / PM / UI-UX / 後端 / Flutter / DBA / QA Writer / Verifier / Triage / Comparison / Newbie
    組織圖長相 · 看起來工整 動作類型(寫不寫 / 並行不並行 / 判不判對錯)
    寫進 AGENTS.md 之後 cycle 跑起來,只有 PM/QA 對應到事故學到的 每個 type 對應一條真實踩坑
    幕 8

    每個 cycle 派幾個?

    5 個 type 有了。但每個 cycle 派多少?不同 cycle 規模需要不同編制:

    Cycle 規模 派誰 總 RAM 為什麼
    改 1 行 typo RD-Sonnet + Verifier-Haiku ~1.0 GB 簡單變動 · 簡單覆蓋
    中等 PR RD-Sonnet + 2 Verifier-Haiku + Comparison-Haiku ~2.2 GB 中等變動 · 需 cross-check shared assumption
    大改 schema(含 RBAC) RD-Opus + 3 Verifier-Sonnet + Comparison-Haiku + 5 Persona-Newbie ~5.5 GB 大變動 + 跨角色 · 需多視角補 RBAC 盲點
    固定編制(每 cycle 都派同樣 N 個) Per-cycle dynamic staffing
    小 cycle 浪費資源小 cycle 派 2 個 agent
    大 cycle 漏 perspective大 cycle 派 9 個 agent
    9 Opus 撐爆 16 GB 機器每 cycle 算一次 budget

    規劃 vs 執行 staffing 分離

    AGENTS.md不變部分(taxonomy + RAM 上限 + Iron Rules) · 半年不變
    docs/cycles/Cn-*.md Header具體 staffing(派誰 / 什麼 model / 多少 RAM) · 每 cycle 重算
    前者性質規劃文件
    後者性質執行契約

    結語:cycle file 是這故事的結晶

    維度 補丁 從什麼反推
    角色 5 個 type taxonomy + PM 多元職能 + 小白進化線 局部檢測 / 不會按角色測 / 換角色 flip-flop / shared assumption / 單一視角盲點
    流程 8-stage SOP + 小白 → PM → RD 三角入口 沒收斂條件 / 沒規格定錨 / 沒 SPEC 守門員
    資源 per-cycle dynamic staffing 固定 9 Opus 撐爆機器

    cycle file workflow 的價值不是「設計得多漂亮」,是「每個設計選擇都對應到一個踩過的坑」。Multi-tenant + RBAC 系統的盲點不是「LLM 不夠強」,是「沒有公共 SPEC 守門員 + 多元視角覆蓋」就會撞牆。

    你接手新專案那天

    需要什麼4 個檔案 + 一段 bootstrap prompt
    完整版在哪進階篇

    系列文章

    第一篇「56 條 INV 全綠,user 點一次抓出 4 個 bug」— Multi-Agent 業界共識的五個自家補丁
    進階篇Cycle File:Multi-Agent 工程的狀態接力棒 — 完整 SOP / 8-stage / 4 個檔範本
    呼應業界Multi-Agent 架構再探: 三省六部反模式和業界收斂共識(愛好 AI 工程)

  • Cycle File:Multi-Agent 工程的狀態接力棒 — file-as-state-machine 方法論

    重點摘要

    • 動手的 agent 只能一個(寫入單線程)。但同一個 agent 不可能從頭做到尾,工作數小時後注意力品質下降(context rot)。
    • 解法不是換 agent,也不是加 agent,是讓「下一個 agent」能無痛接手。接力棒設計才是 multi-agent 工程的真正關鍵。
    • Cycle file = file-as-state-machine:把每個 cycle 的完整狀態寫進一份 markdown,活在 git,跨 session 可讀,撐過對話 compaction。
    • 8-stage 結構每個 stage 對應一個 multi-agent 容易踩到的坑:baseline 污染、ripple effect、vacuous test、groupthink。
    • 5 種 cycle type,各有 stage profile。不是每個 cycle 都跑 8-stage,硬塞會浪費或漏。
    • file-as-state-machine 不只 multi-agent 用得到。ADR、RFC、postmortem 都是這個 pattern,multi-agent workflow 把它的價值放大 100×。
    • 新環境 bootstrap:4 個檔案 + 一段 prompt,就能在新電腦 / 新 Claude Code / Antigravity / Codex / Cursor / Aider 上啟動這套流程,不分工具。

    本系列【進階篇】。提供完整 SOP 跟 4 個檔範本,假設你已經知道為什麼 multi-agent 工程需要 cycle file workflow。還沒看過為什麼?先讀 入門篇:「為什麼修不完?」— 從 21 輪迴圈到 5 type taxonomy 的多 agent 角色設計——用第一人稱故事告訴你 5 個 agent type 是怎麼從踩坑反推出來的,讀完再回來看這篇就會懂為什麼這 4 個檔長這樣。

    Multi-agent 工作流有個業界共識的硬約束:同時間只能有一個 agent 動手寫(寫 code / 寫 spec / 寫 migration)。多個 agent 平行寫產生隱性風格 + 決策衝突,Cognition / Anthropic / Stanford 都從不同角度驗證過這條。

    但這條約束衍生一個立刻撞上的問題:

    寫入單線程沒錯,但一個 agent 怎麼跑一個多月的長期專案不撞 context rot?同一個 agent 從第一週寫到第六週,中間累積的對話歷史不會把它壓垮嗎?

    答:不是「一個 agent 跑到底」,是「每個 cycle 換新 agent,cycle file 接力」。

    這篇講 cycle file 設計方法論——為什麼必須是檔案不是對話、為什麼必須在 git 不能在 Notion、8-stage 結構每個 stage 對應哪個 multi-agent 踩坑,以及這個 pattern 怎麼推廣到 ADR / RFC / postmortem 這類非 multi-agent 場景。

    對照組:傳統工業界 RD 開發流程

    在進入 multi-agent cycle file 方法論之前,先把工業界標準的 RD 開發流程攤開——對照基準清楚了,後面的對應關係才好讀。本文不是發明新流程,是把這套經典 SDLC 對應到能跑在多個 AI agent 上的 cycle file 結構。

    經典流程九步

    1. PM 整理需求 — business requirement,decide what to build
    2. SA 分析需求(可由 PM 兼任)— 系統分析,what the system must do
    3. SD 設計需求(可由 PM 兼任)— 系統設計,how the system should do it
    4. RD 撰寫程式 — implementation
    5. RD 自測後交付 — pre-PR self-test
    6. QA 進行測試,建立錯誤表 — finding list,QA 只報事實不下 P0/P1
    7. PM 確認錯誤表,跟 SPEC 比對 — triage:是 bug 還是 feature 還是 usage 還是 not_issue
    8. 交給 RD 修正 → 修正後再給 QA → PM,持續 loop — 直到 PM 點頭。這個 loop 是品質的核心,不是 bug,是設計
    9. 上到 GA 區,以正式資料進行測試 — production smoke,真實數據才能發現假性綠燈

    測試分三段——這三段不能混

    類型 內容 在 cycle file 對應
    測試程式 unit test / integration test / E2E test scripts Stage 5a failing test + Stage 5c regression suite
    測試環境 staging server / sandbox / test docker compose / backend services Stage 0.5 Pre-cycle hygiene 確認所有服務 up
    測試資料 fixture / seed data / disposable test users / canonical baseline Stage 0.5 fixture reset + disposable qa_* fixtures

    經典流程 ↔ Cycle file 對應

    傳統 RD 流程 Cycle file 對應 stage
    PM 整理需求 Cycle file Header 的 spec section + related INV
    SA / SD 分析設計 Spec.md + invariants.md 條目(契約寫死)
    RD 撰寫 + 自測 Stage 1 RD 自測(單線程,一個 agent 動手)
    QA 測試 + 錯誤表 Stage 2 QA wave 並行 + Stage 3 OPEN findings
    PM 確認比對 SPEC Stage 4 PM triage(bug / feature / usage / not_issue)
    RD 修正 → QA → PM loop Stage 5 fix → Stage 6 regression → Stage 7 comparison QA → 回 Stage 3
    PM 點頭 Stage 8 merge gate(全綠才合)
    上 GA 區正式資料測試 Production smoke + user smoke(primary detection,觸發 T-user-smoke-followup cycle)

    關鍵差別:傳統流程角色是「人」(PM / SA / SD / RD / QA),cycle file workflow 把這些角色變成「agent 在不同 stage 的職責」——同一個 LLM agent 在 Stage 1 是 RD,在 Stage 2 wave 之中扮演 QA(但 scope 鎖死),Stage 7 是 comparison QA。PM 永遠是人,因為「跟 SPEC 比對 + 做價值判斷」這層 LLM 不該越界。

    §1 為什麼「對話 context」是錯誤的狀態載體

    多數人用 Claude / GPT / Cursor / Aider 寫 code 的時候,默認狀態活在對話裡——上一句問題、AI 上一個回應、再上一個截圖,都在 chat history 裡。看起來理所當然,直到撞到三個事實:

    1. 對話會壓縮(compaction)。主流工具在 context 接近上限時都會自動壓縮歷史。「我剛剛跟你說過 X」這句話,壓縮一輪後就變成「我們討論過某些事」。具體細節進了 summary,但 summary 本身會再被壓縮。資訊密度持續下降。
    2. 對話只活在單一 session。開新 session = 全新對話,讀不到上次的 context。即使有 memory file(persistent profile / preferences),那是「人格 / 偏好」層,不是「這個專案這個 PR 跑到哪了」的狀態。
    3. 對話沒 git history。半年後翻回去看「為什麼這個 PR merge」,翻 chat log 是不可能任務——對話沒 commit message、沒 tag、沒 diff,review 工具完全用不上。

    傳統 workaround 是「我把上下文 paste 進新 session」。這是 fragile 的——你會漏、你會省略、你會把 600 字濃縮成 30 字然後新 session 推不出原本的決策邏輯。

    結論:對話狀態必然會掉,任何長期 multi-agent workflow 都要把 state 寫到對話以外的地方。Cycle file 是其中一種具體實踐。

    §2 Cycle File 的核心思想:file-as-state-machine

    一個 cycle file = 一個 PR cycle 的完整狀態機。離散的 stage 有明確 entry / exit 條件,跨 session 接手 = 讀檔不是讀對話。

    為什麼必須是 markdown 不是 JSON / DB

    • Human-AI 雙方都能讀。人要看,AI 要讀,PR reviewer 也要看。Markdown 是最低共通格式。
    • Diff 友善。Stage 3 加一個 finding,git diff 看得清清楚楚。JSON 一改整個檔重排,DB 改一個 row 沒 diff。
    • 離 code 近。docs/cycles/Cn-*.md 跟 source code 在同一個 repo,branch 切換時 cycle file 也跟著切換。

    為什麼必須在 git 不能在 Notion / Confluence

    • Audit trail。每次 cycle file update 都是一個 commit,who / when / why 一目了然。Cloud doc 改了就改了,沒人記得是誰改的。
    • 跟 code 同生死。Branch 跟 cycle file 綁在一起,rebase / cherry-pick / revert 都會帶走 cycle file。Notion 不知道 code 在哪個 branch。
    • 跨工具不依賴。Cloud doc 服務掛了 cycle file 就讀不到。Git 不會掛——而且即使原 repo 沒了,每個 clone 都有完整歷史。

    §3 8-stage 結構——每個 stage 對應一個 multi-agent 踩坑

    本節拆 cycle file 8-stage 的標準結構,標出每個 stage 對應哪個 multi-agent 容易撞的坑。

    Header — cycle 身分證

    # Cycle Cn — <short PR title>

Owner: <engineer agent / human>
Started: YYYY-MM-DD HH:MM
Status: open / in_qa / in_triage / in_fix / regression / closed
Cycle Type: T-PR-cycle / T-regression-fix / T-feature-cycle /
            T-spec-audit / T-user-smoke-followup / T-mutation-test
Related:
  - PR / branch: <commit_sha>
  - Spec section: <§X.Y>
  - Primary INV(s) targeted: INV-XXX-NNN

    下個 agent 接手第一件事是讀 Header。Cycle Type 決定哪些 stage 必經、哪些 N/A——不分 type 把所有 cycle 都當 PR-cycle 跑,結果 regression-fix 跑 8-stage 浪費,user-smoke-followup 跑 8-stage 又錯位(user 已經是 primary detection 了,還跑 QA wave 是反過來)。

    Stage 0.5 — Pre-cycle hygiene

    • git status --short clean(除了本 cycle 將動的 file)
    • HEAD = <commit-sha>,不是 mid-rebase / mid-merge state
    • seed / fixture reset script 跑過,fixture 為 canonical
    • 列出本 cycle 將建立的 disposable test fixtures,不複用共享 fixture
    • 所有相關服務 healthy(backend / proxy / DB / storage 皆 up)

    對應的坑:跨 cycle 副作用會讓新 cycle 在污染狀態跑出 false positive ✅。上輪 cycle 殘留的 test payload、未清的 disabled user、過期的 rate-limit lockout——新 agent 進場已經在污染狀態,QA wave 跑出來的綠燈是 false confidence。Pre-cycle baseline check 是唯一的事前防線。

    Stage 1: RD 自測

    • 單元測試全綠(附 commit SHA)
    • Live smoke:對 endpoint X / user Y 跑 happy path(寫一兩行紀錄)
    • PR header 完整(INV 宣告 / QA scope / Verification 三段)

    RD 在開 PR 之前就先過自己的關。沒過自測的 PR 連 Stage 2 都進不去——直接退回。

    Stage 2: QA wave(並行讀取)

    2-4 個 QA agent 並行,每個 scope 鎖死 1-3 個 invariant。這是 multi-agent「平行覆蓋」的核心場景——讀取不衝突。

    QA agent A — INV-XXX-NNN red-team
QA agent B — INV-YYY-MMM regression
QA agent C (optional) — same scope as A, no knowledge of A's findings
                       (consistency check; 結果一致則 spec 寫得清楚,
                        不一致則 spec 有歧義先收斂)

    QA agent 只能標 ✅ / ❌ / OPEN,絕對不准標 P0/P1——那是 PM 的 authority。OPEN 一律往 PM triage 走。

    Stage 3: OPEN findings(等 PM triage)

    所有 QA agent 的 OPEN finding 收進一張 finding table。Finding 格式:

    ### Finding F-Cn-001
- QA agent: A
- Resolver/Feature: <name>
- Observed: <事實>
- Repro: <exact commands>
- PM triage:
  - Class: bug / feature / usage / not_issue / spec_clarification
  - Confidence: high / low
  - Reasoning: <≤2 sentences citing spec/INV>
  - User review needed: yes / no

    Findings ≥3 時派 PM-agent 跑 first-pass triage,user 只 review confidence=low 與 class=spec_clarification 兩類。Findings ≤2 user 直接判,省 round-trip。

    Stage 4: User review(只看 low-conf)

    User 對每個 confidence=low 或 spec_clarification 項目走 PM triage 分判,30 秒一個 finding。超過 2 分鐘 = finding 太大,要拆。

    Downstream sweep(Stage 5 之前必填)

    本 cycle 改動的 state(DB tables / schema / role-cap definition / fixture state),列出有哪些其他 resolver / query 會讀到。grep 全 repo 找 reader,寧可 false positive 多列幾條,少列就漏 ripple。

    對應的坑:改動會 ripple 到 cycle scope 外的 readers,沒 explicit list 必漏。經典場景:Cycle A 改了 fixture seed script,衍生 1 小時後 user 點 dashboard 某個 tab 崩。原因是 Cycle A 改了某張表的 state,影響到 cycle scope 外的另一個 resolver——那個 resolver 不在 Cycle A 的測試範圍裡,沒人提醒去看,bug 就溜進去。Downstream sweep 強制 RD 在 Stage 5 開修前 explicitly list ripple 範圍,Stage 6 regression 必須 cover。

    Stage 5: RD fix(TDD red-green 拆 5a / 5b / 5c)

    Stage 5a — write failing test
  - 寫 test 對應 invariant / 對應 finding attack scenario
  - 跑 test → 預期 ❌ red(沒紅 = test 寫錯)
  - commit "test: failing test for F-Cn-NNN / INV-XXX-NNN (red)"

Stage 5b — implement fix
  - 寫 fix
  - 重跑 5a 的 test → 預期 ✅ green
  - commit "fix: ... (green via test in <5a-sha>)"
  - commit message 必填 "Failing test verified at: <5a-sha>"

Stage 5c — refactor + regression
  - refactor 必要時
  - 跑全套既有 test 確認無 regression

    對應的坑:「test + fix 同 commit」沒驗 test 真的會抓對應 bug,可能是 vacuous test(永遠 pass 但不 cover 要 cover 的 case)。沒有「test 先 ❌、fix 後 ✅」這個 TDD 基本動作,你不知道 test 是真的在驗還是空跑。拆三個 commit 的好處是 bisect 看得出 red→green 軌跡。

    Stage 6: Regression

    Stage 5 fix 跑完,QA agent 重跑 Stage 2 的 wave(同樣的 prompt,只是 commit SHA 換成 fix sha)。Downstream sweep 列出的 ripple 範圍必須驗。

    Stage 7: Comparison QA(對抗 groupthink)

    派一個全新的 QA agent(不告訴它原 QA 抓到什麼),跑同一份 PR。如果它抓出新 finding = 原 QA 還有盲點。如果它跟原 QA 結論一致 = 確認可信。

    對應的坑:QA agent + Engineer agent 同 LLM 譜系,想得到的 attack scenario 高度重疊,共有盲點。Comparison QA 是減輕 groupthink 的最低成本做法——成本是多派一個 agent,收穫是另一個視角的覆蓋。

    Stage 8: Merge gate

    要合 PR,全部都要打勾:

    • PR header 完整(INV 宣告 / QA scope / Verification)
    • 宣告的「滿足」invariant:兩個 QA agent 都報 ✅
    • 宣告的「可能影響」invariant:回歸都 ✅
    • 兩個 QA agent 報告結論一致
    • OPEN list 清空(全部 triage 完)
    • 單元測試綠
    • 如 PR 影響 UI → 手動 smoke 一次 happy path

    Stage 8 全綠才 merge,cycle file commit 留檔,close cycle。

    §4 Cycle Type — 5 種 stage profile,不是每個 cycle 都跑 8-stage

    「Cycle Type」field 解決一個很實在的問題:不同性質的 cycle 用不同 stage profile,硬塞 8-stage 會浪費 stage 或漏 stage。

    Cycle Type 觸發 Stage profile
    T-PR-cycle 開 PR 等 merge 完整 8-stage(QA wave + regression + comparison newbie)
    T-regression-fix Engineer / agent 自抓 regression 5-stage:skip Stage 2 QA wave + Stage 4 user review;root cause 在 cycle file 開頭講清
    T-feature-cycle Forward-going 新 feature Stage 5 在 Stage 2 之前(先實作再 QA wave 對 INV 驗證)
    T-spec-audit 隨機抽樣 / category 全驗 Stage 2 only + report;無 fix。Findings raise 為 OPEN 給 PM
    T-user-smoke-followup User 直接報 bug Stage 3 直接收 finding(user 是 primary detection)+ skip Stage 2;後續 5/6/7/8 全跑

    Cycle file 開頭強制填 Cycle Type: T-XXX,Stage 8 merge gate 只 enforce 該 type 必經的 stage。

    §5 三個工程效益——為什麼這個設計值得

    效益 1:撐過對話 compaction

    對話被壓縮的時候,壓的是 chat history,不是 git artifact。下個 session 我打開 docs/cycles/Cn-*.md,完整的 persona、attack scenario、findings、PM triage 結果都還在。

    對照組:如果這些資訊只活在對話裡,compaction 一輪 → 只剩「我們做了一些 QA」這種無資訊摘要 → 下個 agent 接手等於從零開始。

    效益 2:跨 session / 跨 agent 可讀

    新 agent invocation(無論是新 session、不同 agent、甚至不同人接手),讀檔就能上工。長期專案累積的 cycle 是獨立 Engineer invocation,每個 cycle 開頭讀 workflow SOP + invariants 契約 + 當前 cycle file 進度,3 分鐘進入狀況。

    對照組:沒 cycle file 的話,新 agent 進場第一件事是「請告訴我前面跑到哪了」——你自己要把 600 行對話濃縮 paste 給它,中間漏東漏西。

    效益 3:6 個月後的自己有 audit trail

    半年後 grep 某條 invariant ID,找到這條 invariant 是哪個 cycle 加的、為什麼加、當時 PM 怎麼判的——全部在 git 裡,commit message 帶 finding ID。

    對照組:Cloud doc 寫的 ADR、Confluence 寫的 design doc——半年後權限過期、url 換掉、search 找不到。

    §6 推廣:file-as-state-machine 不只 multi-agent 用得到

    Cycle file 的核心是 file-as-state-machine:把工程過程的 state 從「對話 / 會議 / 腦袋」搬到「檔案 / git」。這個 pattern 在傳統軟工不是新東西,只是名字不一樣。

    名稱 用途 跟 cycle file 共同性質
    ADR(Architecture Decision Record) 記錄架構決策的 context / 選項 / 決定 / 後果 活在 git,撐過人員流動,6 個月後可 audit
    RFC(Request for Comments) 大型 feature 的設計提案 + comment trail 同上;增加 review 階段的離散 stage
    Postmortem incident 事後分析 + 行動項 同上;Stage 包含 timeline / root cause / action items
    Cycle file single PR 的完整 lifecycle 同上;比 ADR/RFC 更短週期、更高頻次

    共同性質:把工程過程的 state 從可揮發載體(對話、會議、腦袋)搬到不可揮發載體(git、版控檔案)。對 single-developer 也有用——你不會記得三個月前為什麼選 PostgreSQL 而不是 MySQL,但 ADR 會記得。

    對 multi-agent 工作流,這個 pattern 的價值放大 100×。因為 multi-agent 有兩個額外的揮發源:

    • 對話 compaction(每幾小時就一次)
    • 跨 session / 跨 agent 切換(每個 cycle 一次)

    Single-developer 的對話 context 一個專案可能撐幾天,multi-agent workflow 可能撐幾小時。Cycle file 的「狀態接力棒」價值在 multi-agent 場景才完整展現。

    §7 在新環境啟動這套流程——4 個檔案 + 一段 bootstrap prompt

    如果今天換新電腦、開新專案、或換工具(Claude Code → Antigravity / Codex / Cursor / Aider),怎麼快速把這套 cycle workflow 啟動到「下一個 agent 進來就能照跑」的狀態?答案是最小可行 kit:4 個檔案 + 一段給 agent 的開場白。

    最小可行 kit:4 個檔案

    檔案 內容 變動頻次
    docs/workflow.md 8-stage SOP 完整版(本文 §3 內容) 每 retro 一次 amend
    docs/cycle-template.md Cycle file 結構 template(複製即可填) 穩定,少改
    docs/invariants.md 所有 INV-XXX-NNN 契約列表(初始空白,隨 cycle 累積) 每 cycle 可能 amend
    AGENTS.md Role taxonomy(perspective-driven,不是 8 職稱)+ 資源預算上限 穩定,專案改 tech stack 時才動

    這 4 個檔不是「規劃文件」,是「執行契約」——每 PR 強制讀,違反退回。具體 staffing / per-cycle 進度寫在 docs/cycles/Cn-*.md。

    4 個檔案的最小內容範本

    下面 4 段是直接可複製貼到專案的 minimal 內容。Day-1 把這 4 個檔放進 docs/ 跟 root 之後,就有完整的 cycle workflow kit,新 agent 進來照走。

    檔案 1/4 — docs/workflow.md

    8-stage SOP 的 skeleton。詳細每個 stage 規則見本文 §3,這份 skeleton 是「每個 agent 開工前必讀」的最小契約版本。

    # Workflow SOP — Cycle-based PR Pipeline

> 所有 PR 走 cycle file 流程。違反 stage 順序的 PR 直接退回。

## 8 Stages

| Stage | 動作 | 誰做 | 必經? |
|---|---|---|---|
| 0.5 | Pre-cycle hygiene (baseline 乾淨確認) | Writer | yes |
| 1 | RD 自測 (unit test + live smoke + PR header) | Writer | yes |
| 2 | QA wave (2-4 verifier 並行,每個 scope 鎖 1-3 INV) | Verifier(s) | yes (PR-cycle) |
| 3 | OPEN findings table (QA agent 收 finding) | Verifier | yes |
| 4 | PM triage (bug / feature / usage / not_issue 分判) | PM / Triage | yes |
| Downstream sweep | grep 列出 ripple 範圍 (本 cycle scope 外的 readers) | Writer | yes |
| 5 | RD fix — 5a 寫 failing test → 5b 寫 fix → 5c refactor | Writer | yes (有 bug 才跑) |
| 6 | Regression (重跑 Stage 2 wave,scope 含 ripple) | Verifier | yes |
| 7 | Comparison QA (新 agent 不知道原 QA 結果,re-audit) | Verifier | recommended |
| 8 | Merge gate (全綠才合) | Writer + PM | yes |

## 5 Cycle Types (決定哪些 stage 必經)

| Type | 觸發 | Stage profile |
|---|---|---|
| `T-PR-cycle` | 開 PR 等 merge | 完整 8-stage |
| `T-regression-fix` | engineer 自抓 regression | 5-stage:skip Stage 2 + Stage 4 |
| `T-feature-cycle` | forward-going 新 feature | Stage 5 在 Stage 2 之前 |
| `T-spec-audit` | 隨機抽樣 / category 全驗 | Stage 2 only + report (無 fix) |
| `T-user-smoke-followup` | user 報 bug | Stage 3 直接收 finding,skip Stage 2 |

## Iron Rules (執行契約,違反退回)

1. **寫入單線程**:同時間只能 1 個 Writer agent 動手。其他 agent 都不准動 code / spec / schema / migration。
2. **Verifier 不准標 P0/P1**:只能 ✅ / ❌ / OPEN。嚴重度是 Triage 的 authority。
3. **Verifier scope 鎖死 1-3 INV**:不准「找任何 bug」(R35 21 輪迴圈的反面教材)。
4. **TDD red-green 拆三 commit**:Stage 5a failing test red commit → 5b fix green commit (帶 `Failing test verified at: <5a-sha>`) → 5c refactor。`test+fix 同 commit` = 沒驗 test 有效。
5. **修了 bug 必須加 INV 到 `docs/invariants.md`**:沒加不算修完。半年後同類 bug 一定回來。
6. **cycle file 留檔不刪**:cycle 收完 commit 進 git,當作 audit trail。
7. **每月 retro amend workflow.md**:漏掉的 bug / 浪費的 stage / 卡住的 finding → 回頭改 SOP。

    檔案 2/4 — docs/cycle-template.md

    每個 cycle 開頭從這份複製出 docs/cycles/Cn-<topic>.md(n 是流水號,grep 看下一個)。照著填,不要自己改 stage 結構。

    # Cycle Cn — <short PR title>

**Owner**: <agent ID / human>
**Started**: YYYY-MM-DD HH:MM
**Status**: open / in_qa / in_triage / in_fix / regression / closed
**Cycle Type**: T-PR-cycle / T-regression-fix / T-feature-cycle / T-spec-audit / T-user-smoke-followup
**Related**:
- PR / branch: <commit_sha or branch>
- Spec section: <§X.Y or "N/A">
- Primary INV(s) targeted: INV-XXX-NNN, INV-YYY-MMM

---

## Stage 0.5 — Pre-cycle hygiene

- [ ] `git status --short` clean (除了本 cycle 將動的 file)
- [ ] HEAD = <commit-sha>
- [ ] fixture reset 跑過, baseline canonical
- [ ] 列出本 cycle 用的 disposable fixtures (qa_<cycle>_<role>_<timestamp> prefix)
- [ ] 所有相關服務 healthy

## Stage 1: RD 自測

- [ ] unit test 全綠 (commit: <sha>)
- [ ] live smoke 紀錄:<endpoint X / user Y / happy path 結果>
- [ ] PR header 完整 (滿足 INV / 可能影響 INV / 提議新增 INV 三段)

## Stage 2: QA wave

### QA agent A — INV-XXX-NNN red-team
- Launched: HH:MM
- Result: ✅ / ❌ / OPEN
- Findings: <count>

### QA agent B — INV-YYY-MMM regression
- Launched: HH:MM
- Result: ✅ / ❌ / OPEN

## Stage 3: OPEN findings

### F-Cn-001
- QA agent: A
- Resolver/Feature: <name>
- Observed: <事實,不下判斷>
- Repro:
  ```
  <exact commands / GraphQL / curl>
  ```
- PM triage:
  - Class: bug / feature / usage / not_issue / spec_clarification
  - Confidence: high / low
  - Reasoning: <≤2 sentences citing spec/INV>
  - User review needed: yes / no

(repeat for each finding)

## Stage 4: User review (only low-conf items)

- [ ] F-Cn-XXX user-confirmed class: <class>

## Downstream sweep (Stage 5 之前必填)

### 本 cycle 改動的 state
- DB tables: <list>
- Schema: <changes>
- Fixture state: <changes>

### 讀取上述 state 的其他 resolver / query

| State | Reader | Stage 6 必驗 |
|---|---|---|
| <table_X> | <Resolver A / Query B> | ✅ |

## Stage 5: RD fix

### Stage 5a — failing test (red)
- Test 檔: <path>
- 跑出 red: commit <5a-sha>

### Stage 5b — implement fix (green)
- Fix commit: <5b-sha> (帶 `Failing test verified at: <5a-sha>`)

### Stage 5c — refactor + regression
- 全套既有 test pass: ✅

## Stage 6: Regression

- QA wave 重跑 (scope 含 downstream sweep ripple)
- 結果: ✅ / ❌

## Stage 7: Comparison QA

- 新 verifier 不告知原 QA 結果, re-audit
- 結論: 跟原 QA 一致 / 不一致

## Stage 8: Merge gate

- [ ] PR header 完整
- [ ] 宣告的「滿足」INV: ✅
- [ ] 宣告的「可能影響」INV regression: ✅
- [ ] 兩個 QA agent 結論一致
- [ ] OPEN list 清空
- [ ] unit test 綠
- [ ] 如影響 UI: manual smoke happy path

---

## Cycle close

- **Closed**: YYYY-MM-DD HH:MM
- **Outcome**: merged-on-dev / abandoned / split into Cn+1
- **Total commits**: <count>
- **New INVs added**: <list>
- **Bugs fixed**: <count>
- **Lessons** (going to brain): <bullet points>

    檔案 3/4 — docs/invariants.md

    專案的 invariant 契約 catalogue。初始空白,隨 cycle 累積。每修一個 bug 必須在這加對應條目——沒加不算修完。半年後 grep 某個 INV ID 應該找得到「誰加的、為什麼加、對應哪個 test」。

    # Invariants — Project Contract Catalogue

> Every invariant here is a contract. Code must hold. Tests must verify.
> Format: `INV-<CATEGORY>-<NNN>: <statement>` + origin + severity + test ref.

## Categories (調整為你專案實際需要的)

- `INV-AUTH-*` — authentication / session / token rotation
- `INV-RBAC-*` — role-based access control / capability checks
- `INV-RLS-*` — row-level security (multi-tenant isolation)
- `INV-DATA-*` — data integrity / nullability / FK / atomicity
- `INV-IDEM-*` — idempotency (probe-then-INSERT, advisory locks)
- `INV-INPUT-*` — input validation / sanitization
- `INV-UI-*` — frontend behavior contracts
- `INV-RESOLVER-*` — resolver-level contracts (scope, error shape)
- `INV-SCHEMA-*` — schema design constraints (反 over-design 用)
- `INV-BATCH-*` — batch operation invariants

## Verification Layer Reference

每條 INV 標 verification layer:

- L0 spec / L1 INV / L2 schema / L3 resolver / L4 frontend / L5 E2E

(同一條 INV 可能 multi-layer。看本文 §5 對 6-layer doneness 的說明。)

---

## Invariants

### INV-AUTH-001 (example template — 換成你的)
- **Statement**: <one-line contract,可被測試直接驗證>
- **Origin**: Cycle C<n> (YYYY-MM-DD) — <short context, why this surfaced>
- **Severity**: P0 / P1 / P2
- **Test**: <path/to/test.go::TestFuncName> or <❌ TODO in backlog>
- **Enforcement layer**: L1 + L3
- **Related findings**: F-C<n>-NNN

---

## Backlog (test ❌ TODO)

當你寫了 INV 但 test 還沒寫完時, 標 ❌ 放這裡。半年後拿這個 backlog 跑「補測試 sprint」:

- ❌ INV-XXX-NNN (待補 integration test)
- ❌ INV-YYY-MMM (待補 E2E test)

---

(initial state: empty — populate as cycles surface bugs.
每 fix commit 必須在這加對應 INV, 沒加不算修完。)

    檔案 4/4 — AGENTS.md

    Role taxonomy + 資源預算。不寫具體職稱(架構師 / PM / UI-UX / 後端 / Flutter / DBA / QA)——那是死文件做法。寫的是「執行類型」(Writer / Verifier / Triage / Comparison / Newbie) + 機器資源上限,具體 staffing 在每個 cycle file 的 Header 裡。

    # Agents — Role Taxonomy + Resource Budget

> Roles are **perspectives**, not headcount. Agent count is an OUTPUT
> of staffing per cycle, declared in each cycle file Header.
> This file holds only the **invariant** parts: budget ceiling + type taxonomy.

## Resource Budget (本機, 改成你的數字)

| Item | RAM | Notes |
|------|-----|-------|
| Total RAM | 32 GB | This machine |
| OS + Docker + browser reserve | ~7 GB | Baseline |
| **Available for agents** | **~22 GB** | Max budget |

## Model Memory Reference (Claude Code)

| Model | RAM | When to use |
|-------|-----|-------------|
| Opus | ~1.0 GB | architecture / cross-file reasoning / security / senior thinking |
| Sonnet | ~0.6 GB | implementation / API / tests / documentation |
| Haiku | ~0.4 GB | file scanning / config compare / simple SQL / read-only audit |

口訣:需要「想」→ Opus | 需要「做」→ Sonnet | 需要「找」→ Haiku

## Role Taxonomy (perspectives, not job titles)

| Type | Action | Parallelizable? | Typical model | Notes |
|------|--------|----------------|---------------|-------|
| **Writer** | mutate files (code / SQL / migration / spec) | NO (single-thread) | Sonnet / Opus | 同時只 1 個 |
| **Verifier** | read-only inspection / red-team / regression | YES | Haiku / Sonnet | scope 鎖死 1-3 INV |
| **Triage** | classify findings (bug / feature / usage / not_issue) | NO (sequential) | Sonnet (或人類) | PM authority |
| **Comparison** | independent re-verify (Stage 7) | YES (with #1 verifier) | Haiku | 不知道原 QA 結果 |
| **Newbie** | adversarial persona audit (broader coverage) | YES | Sonnet | each persona explicit prompt |

## Per-Cycle Staffing (declared in cycle file Header)

每個 cycle 在自己的 `docs/cycles/Cn-*.md` Header 宣告本輪派多少 agent。範例:

| Agent ID | Type | Model | RAM | Scope |
|----------|------|-------|-----|-------|
| RD-1 | Writer | Sonnet | 0.6 GB | 整個 cycle 寫入 |
| QA-A | Verifier | Haiku | 0.4 GB | INV-XXX-NNN red-team |
| QA-B | Verifier | Haiku | 0.4 GB | INV-YYY-MMM regression |
| QA-C | Comparison | Haiku | 0.4 GB | Stage 7 (盲 re-audit) |
| PM-Tri | Triage | Sonnet | 0.6 GB | Findings ≥3 才派 |

**Memory budget check**: 加總 ≤ available。Over budget → merge 兩個最低 scope Verifier。

## Iron Rules (執行契約, 違反退回)

1. **一個 cycle 同時只能 1 個 Writer agent 動手**。其他 agent 都不准動 code / spec / schema / migration。
2. **Verifier 永遠不准標 P0/P1**——只能 ✅ / ❌ / OPEN。
3. **Verifier scope 必須鎖死 1-3 個 INV**。不准「找任何 bug」。
4. **TDD red-green 必拆 5a / 5b / 5c 三 commit**。
5. **cycle file 必須留檔**, 跨 cycle 不刪。
6. **每月 retro 一次, amend workflow.md 或 AGENTS.md**——這份檔死掉就跟 staffing 死掉一樣慘。

    4 個檔放好之後,接下來那段 bootstrap prompt 就有東西可指了——每個動作都對應到上面具體的檔案內容。

    5 個 type 的事故來源 — 入門篇深挖

    看到 AGENTS.md 列 Writer / Verifier / Triage / Comparison / Newbie 5 個 type,你可能會想:「為什麼不直接用傳統 8 職稱(架構師 / PM / UI-UX / 後端 / Flutter / DBA / QA)?」答案是這 5 個 type 不是想像出來的,是踩過真實角色事故反推出來的補丁——21 輪 ping pong、11 輪 self-audit 漏 P1、5 persona 抓 23 finding。每個 type 對應一條具體事故。

    故事完整版在入門篇用第一人稱寫:「為什麼修不完?」— 從 21 輪迴圈到 5 type taxonomy 的多 agent 角色設計。沒看過入門篇的讀者建議先回頭讀,再看本篇 5 個 type 怎麼用會更有 context。

    另一個跟 type 並列的設計選擇是 per-cycle dynamic staffing:不是「每 cycle 派固定 N 個 agent」,而是每個 cycle 在 docs/cycles/Cn-*.md Header 自己宣告派哪些 type、什麼 model、佔多少 RAM,加總要 ≤ machine available。改 1 行 typo 跟改 schema 不會用同樣編制。同樣在入門篇的故事裡詳細展開。

    Bootstrap prompt(複製貼到新 session 的開場白)

    你接手這個專案。第一輪 onboarding 強制讀以下檔案,讀完再開工:

1. docs/workflow.md   — 8-stage cycle SOP,所有 PR 必經
2. docs/cycle-template.md — cycle file 結構,每個 PR 複製一份
3. docs/invariants.md — 所有 invariant 契約,改動前先看會影響哪幾條
4. AGENTS.md          — 本機資源預算 + role taxonomy

從現在開始,所有改動走 cycle file 流程:

1. 開 PR 前 git checkout -b feat/<topic>
2. 從 cycle-template.md 複製成 docs/cycles/Cn-<topic>.md
   (n = 流水號,grep 既有 docs/cycles/ 看下一個 n 是什麼)
3. 填 Header(owner / start time / cycle type / related INV)
4. 跑 Stage 0.5 pre-cycle hygiene 確認 baseline 乾淨
5. 進 Stage 1 RD 自測 → Stage 2 QA wave → ... → Stage 8 merge gate
6. 收尾時 cycle file commit 留檔,絕對不刪

紀律:
- QA agent 永遠不准標 P0 / P1(那是 PM 的 authority)
- 任何 fix 必須 5a 寫 failing test 紅燈 → 5b 寫 fix 綠燈 → 5c refactor
- 任何改動先 grep 找 downstream reader,沒列必漏
- cycle file 寫具體 evidence,不寫抽象 status
- 修了 bug 必須加 INV 到 docs/invariants.md,沒加不算修完

不確定的 stage 先問我,不要自己腦補。

    這段直接 paste 進新 Claude Code session、Antigravity initial message、Codex 的第一輪 prompt、或 Cursor 的 chat input 都能用。共通點是這些工具都讀 markdown,所以方法論本身跨工具。

    跨工具相容性——自動觸發機制

    差別不在「方法論能不能跑」,在「自動觸發機制」。每個工具有自己的「啟動時必讀」slot:

    工具 自動觸發 slot 怎麼放 bootstrap
    Claude Code CLAUDE.md(專案根目錄)+ ~/.claude/skills/ CLAUDE.md 第一段宣告「## Domain Skill: cycle-workflow」+ skill 寫 cycle SOP 引導
    Codex / OpenAI Agent AGENTS.md(OpenAI 協議) AGENTS.md 開頭加「啟動時讀 docs/workflow.md 必經 8-stage」段落
    Antigravity 專案 root system prompt 同上,在 system prompt 內 reference docs/workflow.md
    Cursor .cursorrules .cursorrules 寫「每次回應前讀 docs/workflow.md」+ reference cycle template
    Aider .aider.conf.yml / CONVENTIONS.md CONVENTIONS.md 寫 cycle SOP 要點,啟動時 –read 進去
    純 ChatGPT / Claude Chat 無自動 slot 手動 paste 上面 bootstrap prompt 進每個新對話

    關鍵 insight:方法論存 markdown,觸發機制存工具專屬 slot。換工具時方法論不用重寫,只要更新觸發機制怎麼指向同樣那 4 個檔案。

    持續 update 機制——別讓 kit 變死文件

    啟動只是第一步。長期維護有三條強制 update trigger,少了任何一條,kit 半年後就會 rot:

    1. 每 fix: commit 強制 update invariants.md:修了 bug 必須加對應 invariant,沒加不算修完。沒這條,同類 bug 半年後一定回來。
    2. 每 cycle 收尾 commit docs/cycles/Cn-*.md:cycle file 留檔不刪,當作 audit trail + 給未來 cycle 參考。沒這條,cycle 跑完就忘,跨 cycle lesson 全部蒸發。
    3. 每月 retro amend workflow.md:跑了一個月會發現某個 stage 太重 / 漏 / 順序不對。retro 看數據(漏掉的 bug、浪費的 stage、卡住的 finding),回去 amend SOP。沒這條,workflow.md 變死文件。

    這三條 trigger 應該寫進 workflow.md 自身,讓「每個 agent 開工前必讀 workflow」這個動作自動帶上「該 update 什麼」的提醒。

    第一個專案的 day-1 動作

    1. git init + 建 docs/cycles/ 目錄
    2. 把上面 4 個檔案複製進來(workflow.md / cycle-template.md / invariants.md 空白 / AGENTS.md)
    3. 建 CLAUDE.md(or 對應工具的 root prompt 檔)宣告必讀那 4 個
    4. 第一個 PR 就照 cycle file 流程走——不要說「先簡單做,以後再上 SOP」,以後不會來
    5. 跑完第一個 cycle,commit cycle file + 第一條 invariant + 第一輪 workflow.md amend(會發現自己漏寫了什麼)

    這套不需要先「累積經驗」才能啟動。第一個 cycle 跑完就有第一份 cycle file 範例給未來自己 / 未來 agent 看,雪球從第一天就開始滾。

    §8 反模式——cycle file 怎麼寫會死掉

    • 寫太抽象:只列 status(QA: ✅),沒列 evidence(哪個 invariant、哪個 attack scenario、reproduce 步驟)。半年後讀不懂自己寫了什麼。
    • 寫太瑣碎:每個 keystroke 記 timestamp,cycle file 變成 chat log。讀的人撈不到結論。
    • 不留 cycle file:對話結束就忘,跨 session 必撞失憶。最常見也最致命。
    • 不分 stage:一個 cycle 寫成一坨流水帳。新 agent 不知道現在跑到哪。
    • 寫在 cloud doc / Notion 不是 git:沒 audit trail,branch 切換 cycle file 不會跟著切,跨工具不依賴的好處全部失去。
    • 不分 Cycle Type 硬跑 8-stage:user-smoke-followup 跑 Stage 2 QA wave 等於把 user 抓的 bug 丟回給 QA agent 確認——錯位、浪費。

    結語:接力棒不是裝飾,是 multi-agent 工程的真正關鍵

    Multi-agent 工程兩條互補規則:

    1. 動手的 agent 只能一個(寫入單線程,從 Cognition / Stanford 等業界共識)
    2. 下一個 agent 必須能無痛接手(cycle file 接力棒,業界文章很少談)

    多數人聽到「multi-agent」想到的是「多個 AI 一起工作」。實際上正確的設計是:同時間只有一個 AI 在動手,其他都是不動手的判斷者;動手的累了下一個來,接力棒(cycle file)不能丟。

    業界文章很少談接力棒——他們談 orchestrator-subagent、談 generator-verifier、談 context isolation,但很少談「下一個 agent 從哪裡讀狀態」。可能因為 demo 場景太短,撞不到 compaction 也撞不到跨 session 失憶。長期專案跑下來,這個盲區會反覆把人燒一遍。

    Cycle file 是踩坑長出來的工程紀律。file-as-state-machine pattern 可以推廣到所有需要「process state 跨人 / 跨時間延續」的場景——不分是不是 multi-agent。

    延伸閱讀

  • 「56 條 INV 全綠,user 點一次抓出 4 個 bug」— Multi-Agent 業界共識的五個自家補丁

    重點摘要

    • 規劃 staffing 跟執行 staffing 必須分離——HOME123 的 AGENTS.md 寫死 8 職稱 + 沒 update 機制，跑 33 cycles 紋風不動，變成「歷史文物」。
    • 寫入單線程，讀取並行——多 agent 平行寫程式碼會產生隱性風格 + 決策衝突，但平行派 5 個 persona newbie 讀程式碼抓 bug 完全沒問題。
    • Generator-Verifier ROI 最高——只加一個 verifier agent 就顯著提升品質，且 verifier 不共享 generator 的 context 反而效果更好。
    • Persona-driven newbie 抓 PM 漏的 finding——HOME123 C29 派 5 個不同 persona 平行 audit，抓出 23 個 PM + Tom 都漏的 finding，其中 4 個是 cycle blocker。
    • 「INV 全綠」≠「對」——C11 user 隨便點 chairman dashboard 就抓出 11 個 verification cycle 都漏的 LEFT JOIN ARRAY_AGG NULL bug。Cycle SOP 只能抓「SOP 想得到的」，user 抓「SOP 想不到的」。

    讀完愛好 AI 工程的 Multi-Agent 架構再探: 三省六部反模式和業界收斂共識(2026-05-19),裡面整理的 Anthropic、Cognition、LangChain、Stanford 各家對 multi-agent 系統的共識,跟我家 HOME123_NEW 從 R35 21 輪迴圈踩坑、演化到 R36 cycle SOP 的軌跡高度重疊。

    但「重疊」不等於「教會我新東西」。我反而在對照中發現,有五個自家踩出來的細節,業界文章沒講或講得不夠重——這篇就把這五個補丁寫下來,給跟我一樣已經在生產環境跑 multi-agent workflow 的人參考。

    本文不從 0 開始講 multi-agent 概念,假設你讀過原文或熟悉 orchestrator-subagent / generator-verifier 這類詞彙。

    補丁 1:AGENTS.md 為什麼變死文件——「規劃 staffing」跟「執行 staffing」必須分離

    我家 HOME123_NEW 的 AGENTS.md 是 2026-05-12 寫的,列了 8 個職稱角色:架構師 / PM / UI-UX 設計師 / 後端工程師 / Flutter 工程師 / Postgres DBA / 資料探索員 / QA。看起來像一張漂亮的組織圖。

    實際跑起來呢?專案 33 個 cycle 結束、Phase 1 ship 之後,這份 AGENTS.md 一次都沒動過。

    對照同一個 repo 的 docs/workflow.md:從 R36 step 3 v1.0 寫下來,持續演化到 v2.1 per-layer QA、v2.2 加 TDD red-green + SCN P0-1,六個 commit,每一輪 cycle 收穫都回寫。workflow.md 活著,AGENTS.md 死了。

    死文件的兩個必要條件

    盤點下來,一份文件變死,要同時滿足兩個條件:

    1. 寫了「會變的具體細節」——例如「8 個職稱 + 主要工作 + 預估記憶體佔用 600MB」。這些隨專案演化必然會變。
    2. 沒有強制 update 機制——沒掛在任何「每 cycle 必看」「每 PR 必檢」的閘口上。

    任一條件缺失,文件還能活:

    • 只寫不會變的部分(資源預算上限、role 類別 taxonomy),沒 update 機制也 OK——因為真的不需要 update。
    • 寫具體細節,但每 cycle 強制 re-check(像 HOME123 的 docs/cycles/Cn-*.md 活在 git,Stage 8 merge gate 強制檢查),也 OK——因為會被更新。
    • 兩個都犯 = 上線當天就在 rot。

    解法:規劃 staffing vs 執行 staffing 分離

    文件類型 性質 該怎麼活
    規劃文件(AGENTS.md / ROADMAP.md) 計畫期的「我以為會這樣」 寫 timestamp、標 initial assumption,職責限縮到「不會變的部分」(資源預算、role taxonomy、必讀 brain 索引)
    執行契約(workflow.md / invariants.md / cycle file) 違反就退回的活文件 每 cycle / 每 PR 強制 re-check,違反當 review fail,cycle 收完歸檔留檔

    原文「三省六部幻覺」段批的「把 agent 命名成 PM / 架構師 / QA」,本質上就是把規劃文件當執行契約用——以為列了 8 個職稱就能跑,但職稱不會自我更新,專案演化會立刻甩開它。我這次踩到的就是這個。

    補丁 2:不是「Single vs Multi」,是「寫入單線程 + 讀取並行」

    原文整理 Anthropic 2026/1 給 multi-agent 的三個合理場景:context 隔離、並行覆蓋、工具專業化。也引用 Cognition 2026/4 的反直覺發現:「寫入動作維持單線程,其他 agent 只負責提供判斷,不負責動手」。

    我家的實踐長這樣(從 R36 開始穩定):

    元件 配置 對應原文模式
    Writer 永遠 1 個 Engineer agent,寫 code + 寫 unit test Cognition「寫入單線程」
    Verifier wave 並行 2-5 個 QA newbie,每個 scope 鎖死 1-3 個 INV Generator-Verifier + Parallel exploration
    Orchestrator 我自己(PM 兩道閘:規格定錨 + finding triage) 人類在 loop
    外部狀態 docs/cycles/Cn-*.md 活在 git 原文「orchestrator-worker + 外部狀態文件」

    整套是Orchestrator-Subagent + Generator-Verifier 混合,五種協調模式裡 ROI 最高的兩個疊起來。

    對應 Stanford 那篇論文的實戰觀察

    原文引用 Stanford 2026/4 的 Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets(arxiv 2604.02460),用資訊理論的「數據處理不等式」證明:固定 token 預算下,單一 agent 在 multi-hop reasoning 上贏過 multi-agent。

    把這個結論套到 code generation 場景就是:Engineer 那 1 個 agent 才是真正在做連續推理的——它要把 spec → schema → resolver → test 一路推下去,context 連續性是品質關鍵。讓五個 agent 平行寫不同模組,結果就是 Stanford 那篇講的:每個 agent 自己的 context 縮短了,推理深度不夠。

    但 verification 不是 multi-hop reasoning,它是多點獨立檢查。每個 newbie scope 鎖死 1-3 個 INV,根本不需要 multi-hop reasoning;反而從乾淨 context 出發比較好——這也是 Cognition 觀察「verifier 不共享 generator context 反而更好」的原因。

    所以選 single 還是 multi 不是哲學問題,是「這個子任務需不需要連續推理」的問題。需要 → single;獨立檢查 → multi。

    補丁 3:Generator-Verifier 的六個 HOME123 細節

    原文講 Generator-Verifier 是五個協調模式裡 ROI 最高的,但講的是「為什麼有效」。HOME123 R35→R36 演化過程中,六個操作細節決定了它真的有效還是只剩形式:

    1. QA scope 鎖死 1-3 INV,不准抓「任何 bug」。R35 21 輪迴圈的反面教材就是讓 QA「找任何問題」,結果 finding 無限發散。Scope 鎖死後,每個 newbie 只查它自己的契約。
    2. QA 不准標 P0 / P1。只能標 ✅ / ❌ / OPEN。P0/P1 是 PM 的 authority,QA 上交給 PM triage。這條防止 QA agent「自己升級嚴重度」拖累節奏。
    3. PM 兩道閘:第一道是寫 spec / 加 INV(規格定錨),第二道是 finding triage(bug / feature / usage / not_issue 30 秒分判)。少了任一道,QA wave 都會無限發散。
    4. PR header 強制宣告 INV 影響。每個 PR description 必填三段:滿足哪些 INV、可能影響哪些 INV、提議新增哪些 INV。沒填完整 = PR 不算開,reviewer 直接退。
    5. Verifier 不共享 Writer 的 context。QA agent prompt 模板只給它「PR commit SHA / 一條 INV / test users / 環境」,不給它 Writer 的對話歷史。乾淨 context 反而推理更深(Cognition 觀察)。
    6. Mutation testing 對抗 groupthink。每月一次,故意往 verified INV 對應的 code path 塞一個 plausible bug,看 QA agent 抓不抓得到。抓不到 = invariant test 不夠 sharp,補 attack scenario。

    第 6 條是原文沒講的盲區。QA agent 跟 Engineer agent 來自同一個 LLM 譜系,shared assumption 會讓兩邊「想得一樣」——0 ❌ 不一定是程式對,可能是兩個 LLM 從同一個訓練資料裡學到同樣的 blind spot。Mutation testing 是目前我知道唯一能對抗這個的方法。

    補丁 4:Over-design 怎麼補救——2026-05-22 砍 1000 LOC 實錄

    原文講 multi-agent 的成本非線性爆炸、錯誤放大,但沒講「multi-agent 容易生出 over-design 的 schema / API」這個副作用。HOME123 跑到 2026-05-22 做了一次 over-design audit,結果是砍掉 1000+ 行。我把那份 audit 攤開,看 multi-agent workflow 為什麼會生出垃圾,以及怎麼補救。

    5 個 dead schema 一次掃掉

    砍掉的東西 為什麼是死的
    Query.myCapabilities 0 frontend caller(me.capabilities 已涵蓋)
    Parcel.notifications + type Notification 0 frontend query,Phase 2 push 走別條 path
    type Guard 整個 type 標 @deprecated,0 caller
    Mutation.batchDeliver + BatchDeliverInput 0 frontend call(所有 UI 都打 deliverParcelBatch),約 260 LOC resolver
    Mutation.createParcelIntakeBatch + UI dialog 跟 C31 session-based batch intake 共存,UI 兩個批次按鈕讓警衛 cognitive load 爆炸,砍掉 ~343 LOC frontend + ~360 LOC backend

    反 anti-pattern:「往後查」

    這五個 dead schema 全部都是同一個 anti-pattern:「為將來預留」。設計時 agent 想「萬一將來要顯示通知 timeline 呢?」「萬一未來 batch deliver 改 session model 呢?」「萬一要 polling caps 呢?」——於是 schema 多了 field、resolver 多了支、tests 多了行。

    但 multi-agent workflow 的特性是沒人記得當初為什麼加:今天的 Engineer 不是當初寫 schema 的 Engineer,QA 不會質疑 schema design 是不是必要,PM 看 finding 不會回頭 audit schema 健康度。「往後查」的 anti-pattern 在 multi-agent 環境會比 single-developer 累積更快。

    三個補救機制

    1. 定期 over-design audit(每 ~2 個月一次或大 milestone 後)。PM scan 角度:「99% 無痛、edge case 不擋 99%、不為將來 may-be 需求預留、不為『好體驗』造成系統壓力」。
    2. 砍之前先 grep 全 codebase 確認 0 caller。「我以為沒人用」跟「grep -r 證實 0 caller」是兩件事。HOME123 砍 batchDeliver 前 grep app/lib/,只在註解出現,於是放心砍。
    3. 砍完寫進 INV 防回流。砍 dead schema 之後加 INV-SCHEMA-001:「standalone batch* mutations 不再加,batch 行為一律走 session-based pattern」。沒寫 INV 半年後同樣的 over-design 會回來。

    Design 不足:persona-driven newbie 才挖得出來

    Over-design 反過來是 design 不足。HOME123 C29 跑了一個實驗:派 5 個 persona-driven adversarial newbie 平行 audit,每個 persona 有明確的「你是誰、你假設世界是什麼樣、你要找的不是『功能對不對』而是『產品對不對』」mandate:

    • Newbie 1:高吞吐警衛阿伯(每天 300 件包裹)
    • Newbie 2:無棟透天社區主委(12 戶,只有「幾號幾樓」概念)
    • Newbie 3:多棟社區主委(5 棟,要選棟才能下一步)
    • Newbie 4:老年住戶用 iPhone 11(375px 螢幕、視力差)
    • Newbie 5:跨租戶 RLS 測試者

    5 個 newbie 平行 audit 抓出 23 個 finding,其中 4 個是 cycle blocker——這些都是我跟 PM 看了無數遍漏掉的。

    最戲劇性的是 N2 跟 N3 加起來證實了我的 directive 錯了:我 2026-05-20 拍板「不用管棟」,N2 跑去把 buildings 設成空陣列發現 backend 硬擋(buildings cannot be empty),N3 跑去測多棟社區發現 dropdown collision。兩個 persona 的觀察合起來,證明「不用管棟 globally」over-fit 到單一棟的場景,我自己只看單一棟所以沒撞到。後來我把 directive partial revoke,改成 buildings.length > 1 才顯示棟 picker。

    Persona-driven newbie 是補 design 不足最便宜的工具。成本就是每個 newbie 一份明確 persona prompt + 一輪 read-only audit,沒有寫衝突、沒有 merge 成本。

    補丁 5:「我很有信心,但你隨便測就炸」——C11 完整故事

    這條是 multi-agent 系統最容易掉進去的坑——而原文完全沒談。先講事件:

    2026-05-10 晚上,HOME123 R36 跑完 11 個 verification cycle、56 條 INV 全綠、所有 QA wave 都報 ✅。我用 chairman 帳號(admin01)登進 dashboard,點開「主委交接」tab——爆炸:

    讀取失敗:can't scan into dest[4] (col: roles):
failed to scan array element 0: cannot scan NULL into *string

    同一個 session 我隨便點了 chairman dashboard,找到 4 個 bug:這個 NULL scan、communities.public_contact_phone 殘留的 <script>alert('XSS')</script> 測試資料、parcel serial 多顯示一個 #(spec 沒寫)、carrier barcode 沒有 lookup query 入口。

    名言誕生:

    R36 11 個 cycle + 56 條 INV ✅,user 隨便點 1 次 → 4 個 bug。

    User browser smoke remains the most valuable QA signal.

    深挖那個 LEFT JOIN ARRAY_AGG NULL bug

    有問題的 SQL 是 CommunityUsers resolver,長這樣:

    SELECT u.*, COALESCE(
  ARRAY_AGG(ur.role_code) FILTER (WHERE ur.revoked_at IS NULL),
  '{}'::text[]
) AS roles
FROM users u
LEFT JOIN user_roles ur ON ur.user_id = u.id
WHERE u.community_id = $1
GROUP BY u.id;

    Bug 在哪?LEFT JOIN 對沒匹配的 user 會 pad 一行 ur.* 全部 NULL 的 row。SQL 三值邏輯下,NULL IS NULL 是 TRUE——所以 FILTER (WHERE ur.revoked_at IS NULL) 把這個 pad row放進了 aggregate。結果 ARRAY_AGG 回傳的不是空陣列、是{NULL}(包一個 NULL 元素的陣列)。COALESCE 看到的是非 NULL 陣列,直接 pass through,Go scan 進 []string 時就爆 cannot scan NULL into *string。

    修法很簡單:FILTER 加一個 AND ur.role_code IS NOT NULL,把 pad row 排除掉。但為什麼 11 個 verification cycle 都沒抓到?

    因為這個 bug 只在「有 user 沒有任何 user_roles row」時觸發。C6 cycle 的 seed-demo.sh 改成 idempotent 之前,所有 demo user 都有至少一個 role;C6 之後,seed 改成「先 DELETE 殘餘 user 的 roles 再 disable user」,結果 DEMO001 多出 11 個 disabled-residue user 帶 zero user_roles row。fixture 狀態改變才暴露 bug,前 11 個 cycle 跑的時候 fixture 還沒進入這個狀態。

    這條 cycle file 寫下了 multi-agent 系統最殘酷的真相:

    Cycle SOP catches what cycle SOP can imagine; user catches the rest.

    為什麼 TDD 也擋不住

    我這套 workflow 有強制 TDD red-green 三步(Stage 5a 寫 failing test、Stage 5b 寫 fix、Stage 5c refactor),為什麼還是漏?

    1. Vacuous green test。Test 永遠 pass 不是因為實作對,是因為 assert 太寬或 fixture 沒覆蓋觸發條件。C11 那個 NULL bug 在前 11 個 cycle 的 test fixture 裡,根本沒有「user 帶 zero roles」這個狀態,所以 test 一直 green。
    2. Groupthink。QA agent 跟 Engineer agent 同 LLM 譜系,想得一樣。Engineer 寫 test 時想到的 attack scenario,跟 QA 寫 test 時想到的 attack scenario,高度重疊。盲點是 shared 的。
    3. L1-L3 全綠 ≠ L4-L5 也對。HOME123 把「對」分 6 層:L0 spec → L1 INV → L2 schema → L3 resolver → L4 frontend → L5 E2E。前 11 個 cycle 主要驗 L1-L3,L4 user click 沒人驗。INV 全綠是 L1 全綠,跟 user 在 chairman dashboard 看到什麼是兩件事。

    5 個建議方向

    1. User smoke = primary detection。不是 secondary、不是「最後再點一次」。每個 milestone 結束第一件事是 user 隨便點,不是看 CI report。
    2. Mutation testing 對抗 groupthink。每月或大 INV amendment 後跑一次,故意塞 plausible bug,看 QA agent 抓不抓得到。抓不到 = QA prompt 跟 Engineer 想得太像,得補 attack scenario。
    3. Adversarial persona 平行覆蓋。C29 模式:每個 persona 有明確「你跟 Engineer 想法不同的地方在哪」mandate,5 個 newbie 平行 audit,讀取型 multi-agent 完全沒衝突風險。
    4. 6-layer thinking 防止誤推。看到「INV 全綠」先問「這是 L 幾全綠?L4 / L5 有人驗過嗎?」L1-L3 全綠不等於對,只是「未驗中比較強的子集」。
    5. TDD red-green 三步分 commit。Stage 5a 寫 failing test 單獨 commit、Stage 5b 寫 fix 單獨 commit,commit message 必填 Failing test verified at: <5a-sha>。bisect 看得出 red→green 軌跡,防 vacuous test。「test 跟 fix 同 commit」= test 從沒 fail 過 = 沒驗 test 有效。

    結語:業界共識是地圖,cycle file 是地形

    原文整理的業界共識像一張地圖:告訴你 Anthropic 走哪條、Cognition 撞了什麼牆、LangChain 怎麼分 patterns。地圖很有用——你不會走錯方向。

    但地圖不是地形。HOME123 33 個 cycle 累積的 docs/cycles/*.md 才是地形:哪個彎要慢、哪段路會塞、哪裡橋斷了走小路。地圖告訴你「先試 single-agent」,地形告訴你「single-agent 的 Engineer 寫完之後,第二件事是叫 5 個 persona newbie 去點點看」。

    這篇五個補丁,本質上是把地形寫下來。給已經在跑 multi-agent workflow、開始撞牆、覺得業界文章沒講透的人。

    下一步:把這次討論抽出的「規劃 staffing vs 執行 staffing 分離」原則,寫進 ~/.claude/projects/-home-tom/memory/brain/adaptive-agent-team-staffing.md brain;把 HOME123 R36 的 PM/Engineer/QA workflow.md 抽象成 ~/.claude/templates/workflow.md 通用模板。這樣下個專案就不用從 R35 21 輪迴圈重新踩一次。

    延伸閱讀

  • Hacker News 每日精選 – 2026-05-27

    “`html




    今日科技趨勢觀察

    🚀 今日科技趨勢觀察：從 AI 自動化開發到工程文化的反思

    破題總結：

    今日的技術趨勢展現出明顯的「工作流自動化」與「工具鏈深度整合」的兩極化發展。從 AI 代理 (AI Agents) 介入開發流程，到利用 Git 進行非程式碼資產的版本管理，開發者正致力於打破傳統軟體的限制；同時，關於程式語言選擇與面試文化的討論，也提醒我們在追求技術效率的同時，不應忽視工程師的心理與開發體驗。

    🤖 AI/機器學習

    Claude Code 如何成為開發者的日常主力：從 MCP 到子代理的深度應用

    這篇文章深入探討了如何將 Claude Code 轉化為日常開發的核心工具。作者分享了關於 Claude.md、技能封裝、子代理 (Subagents) 以及模型上下文協定 (MCP) 的實戰心得。透過這些進階技巧，開發者可以實現更高度自動化且具備上下文意識的編程體驗。

    👉 查看原文

    🛠️ 開發工具

    Cloudflare Flagship：雲端開發的新標竿

    Cloudflare 展示了其最新的旗艦級開發者服務，旨在簡化雲端基礎設施的複雜度。這對於尋求高性能、低延遲且易於管理的雲端部署方案的開發者來說，是一個值得關注的進展。

    👉 查看原文

    打造一個基於 Git 版本控制的書籍製作管線

    這是一位開發者的創意實踐，他成功繞過了 Adobe 與 Microsoft 的封閉生態系，利用 Git 的版本控制特性來建立一套書籍生產流程。這對於需要處理大量文檔且追求「內容即代碼」(Content as Code) 精神的人來說，提供了極佳的靈感。

    👉 查看原文

    從 Rust 回歸 Ruby：關於程式語言選擇的反思

    在性能與開發效率之間，該如何取捨？作者分享了從追求極致性能與安全性的 Rust，重新回歸注重開發體驗與簡潔性的 Ruby 的心路歷程，引發了關於「工具是否適合場景」的熱烈討論。

    👉 查看原文

    🎨 其他

    一些有趣的現代像素字體 (Modern Pixel Fonts)

    對於設計師與前端開發者而言，這篇文章整理了一系列具備現代感的像素字體。在復古風潮與極簡設計交織的今天，這些字體為 UI 設計提供了有趣的選擇。

    👉 查看原文

    我經歷過最糟糕的面試經驗

    技術能力固然重要，但面試過程中的文化與尊重也至關重要。作者分享了一段令人印象深刻的負面面試經驗，引起了廣大工程師對於招募流程與職場文化的共鳴。

    👉 查看原文

    IBM System/360 檔案組織機制回顧

    透過影片形式回顧電腦科學的經典，IBM System/360 的檔案組織方式是現代存儲架構的重要基石。對於想要深入理解底層計算邏輯的讀者來說，這是一堂精彩的歷史課。

    👉 查看原文

    其餘今日短評：關於甲基丙烯酸甲酯儲罐的安全科學討論、美國報紙訃聞的歷史研究、以及一場充滿預兆性的重逢隨筆。

    💡 今日觀點與建議

    從今日的熱門話題可以看出，「工作流的定義權」正在從軟體廠商轉移到開發者手中。無論是利用 AI 代理來強化編程能力，還是利用 Git 來管理非傳統的文檔資產，核心都在於建立可重複、可追蹤且自動化的流程。

    給讀者的行動建議：

    • 擁抱 AI 代理： 不要只把 AI 當作對話框，嘗試研究 MCP 或 Subagents，將其整合進你的 IDE 工作流中。
    • 重新審視工具鏈： 思考你目前的工具（如 Adobe 或大型 IDE）是否過於臃腫？是否能用更輕量化、版本控制友好的方式（如 Git-based workflow）來實現目標？
    • 關注底層邏輯： 在追求新技術的同時，回頭看看 IBM System/360 等經典架構，理解底層邏輯能幫助你在面對新技術變革時保持清醒。



    “`

  • monday.com AI Work Platform 完整解析:4 大產品線、點數計費與 Casetify 實戰

    重點摘要

    • 2026-05-06 monday.com 從 Work Management Platform 轉型為 AI Work Platform,核心訴求是「人 + AI Agent 一起把事情做完」
    • 四大 AI 產品線:Sidekick(個人助理)、Agents(自主工作者)、Vibe(AI 開發工具)、Notetaker(會議轉錄)
    • 計費全面改成 AI 點數制:1 點 = $0.01 USD,所有產品共用同一單位
    • Casetify 用 5 個 Agent(Annie、AI 銷售管家、Eric、小蕾、AI 客服代表)跑完整 4 階段業務 lifecycle,專案準時交付率達 85%、ROI 5 倍
    • Enterprise 配套 Guardian add-on:TLE 帳號級加密 / BYOK 自帶金鑰 / DLP 資料外洩防護 / Multi-SSO
    • 支援多 LLM(Claude、GPT、Gemini)+ AI Permissions Governance 中央後台,admin 可控制誰用什麼模型在哪個 workspace
    • 誰該導入?5 種典型情境 + 6 個紅旗 + 4 種規模分水嶺 + 6 題自我檢核,文末有 50 人公司一年 TCO 估算(~$26,000–44,000 USD)

    monday.com 是什麼?從 2026-05-06 開始,它已經不是「專案管理工具」了。官方在投資人新聞稿宣布公司史上最大轉型:從 Work Management Platform 變成 AI Work Platform。這篇文章把 2026 年 5 月在台北的 monday.com × EpiCloud 線下發表會內容完整整理,涵蓋產品線、計費、實際案例、企業安全四大層面,並對照官方資料做硬驗證。

    什麼是 monday.com AI Work Platform?

    AI Work Platform 是一個不只幫你 plan 工作、還能實際執行工作的 AI-first 平台。它的差異化來自四大核心支柱:

    • Native AI Agents — Agent 原生內建,非技術人員可以設定、部署、指揮
    • Integrated AI — AI 織進每一層,從 data block 到 full-page app
    • Unified Execution — Agent 用現有的 permissions、security、governance,跨部門讀活資料來 plan、coordinate、execute
    • Flexible AI Ecosystem — 一鍵接 Anthropic Claude、Microsoft 365 Copilot、OpenAI ChatGPT

    它為什麼能跑?關鍵在 monday 本身的統一資料模型(boards / items / owners / statuses / timelines / dependencies)— 這層結構化、一致的資料,就是 AI Agent 可以 query 和 act 的 context layer。對比一般 AI 工具,這是有結構化資料當地基,不是空中樓閣。

    四大 AI 產品線:Sidekick、Agents、Vibe、Notetaker

    monday Sidekick — 個人 AI 助理

    2026 年 1 月正式脫離 beta,目前是 monday 平台 AI 的中央入口。Sidekick 是 context-aware 的,跨 boards、docs、人員理解你的工作。能力涵蓋:

    • Generate Workflows:一句話描述需求,自動建出完整 board(含 columns、groups、automations)
    • Summarize:多 board 進度、updates 自動摘要
    • Chat command 執行:直接在對話中建任務、改狀態、指派
    • Surface insights:主動抓延遲、建議 follow-up、highlight 趨勢
    • Sidekick Voice:語音互動,重要動作會先確認

    monday Agents — 自主 AI workforce

    Agents 是 monday 在這次轉型的旗艦產品。定位上叫「unlimited workforce」,代表人類自主執行任務。應用場景包括:行銷活動草稿、銷售 lead qualifying、support ticket 處理、員工 onboarding、採購單。

    新基礎建設讓 Agent 可以自行 sign up、authenticate、在平台內操作 — 換句話說,Agent 在 monday 裡是一等公民,跟人類員工同 UI 模型。在現場 demo 看到的 Campaign Planning Agent「Jennie」就是典型範例:有名字、有頭像、有人設、可被 @mention、可指派為 board item 的 owner、有 Brain tab 儲存長期記憶、有活動紀錄做 audit trail。

    monday Vibe — AI 開發工具

    Vibe 是讓非工程師用自然語言建客製化 view、dashboard、mini-app 的工具。對應前面 Sidekick 的「Generate Workflows」往上延伸:不只是 board,連完整 app 都能無 code 蓋出來。

    monday Notetaker — AI 會議助理

    邀進會議 → 即時轉錄(支援 Zoom、MS Teams、Google Meet)→ 自動產出 summary、transcript、影片錄影、action items,全部回流到 monday workspace。產出可以推到 Gmail、Slack 或其他外部工具,也可以直接寫入 CRM 的 deal timeline,讓業務不用會後手動 update。

    AI 計費:Consumption 點數制,1 點 = $0.01 USD

    2026 轉型同時 monday 把計費全面改成點數消耗制 — 所有 AI 產品共用單一計價單位「AI 點數(每月)」,1 點 = US$0.01。各產品的消耗速率如下:

    產品 消耗速率
    monday Agents 10–250 點 / 任務(視深度範圍)
    monday Notetaker 120 點 / 小時會議 = $1.20 USD/hr
    monday Sidekick 暫時免費(平台 AI 入口策略)
    monday Vibe 已發布 App + 1 張 Vibe Prompt ≈ 30 點
    monday Workflows 啟用中的工作流,每次 AI infused 執行 = 8 點

    Vibe Prompt 按模型分級計費

    Vibe 的 prompt 開始按模型消耗點數,使用者要自己決定 cost/quality trade-off:

    模型等級 模型 點數 / 則 prompt 換算美金
    輕量 Gemini Flash ~10–20 $0.10–0.20
    中等 Claude Sonnet ~30–50 $0.30–0.50
    最佳 Claude Opus ~50–500 $0.50–5.00

    關鍵觀察:Opus 一次 prompt 最高 $5 USD,monday 顯然把模型成本直接透傳給用戶 — 它自己也賠不起 Opus。這也回應業界對「AI 訂閱燒錢」的普遍焦慮:有 ROI 就用最強,沒有就退回 Flash。

    各 Plan 點數方案:Basic 卡很死,Enterprise 強制 25 席起

    Plan 起購 中階 高階 頂規
    Basic 1,000 點 ($10) — — —
    Standard 2,000 點 ($20) 4,000 ($40) 8,000 ($80) —
    Pro 3,000 點 ($30) 4,000 ($40) 8,000 ($80) 20,000 ($200)+
    Enterprise 席次 × AI 點數套裝組合 — 固定比例 1 席:800 點,最低 20,000 點(= 25 席起跳)

    Basic 1,000 點換算:大約跑得了 8 小時 Notetaker、4 次深度 Agent 任務、或 2 次 Opus 高階 prompt — 真正要用,馬上得升 Standard 以上。

    CASETiFY 實戰案例:5 個 Agent 跑完整業務 lifecycle

    CASETiFY 是全球 D2C 品牌,從手機殼起家,業務節奏跟 iPhone / Galaxy 新機同步、不停聯名 drop。100+ 國家營運、monday 使用者超過 300 人(2019 年 15 人起跳)。他們透過 AWS Marketplace 採購 monday Enterprise,把 AI 嵌進每個業務階段。

    4 階段 × 5 個 Agent 接力

    階段 Agent 名稱 AI 前 → AI 後
    1. 規劃行銷活動 Annie(行銷規劃 Agent) 人工策劃 → 自動化規劃,提升生產力
    2. 創造商機(qualification) AI 銷售管家 人工流程 → 自動規劃,更高價值互動
    2. 創造商機(outreach) Eric(銷售 Agent) 與管家分工:打電話、寄信、排會議
    3. 專案執行 小蕾(專案管理員) 遭遇風險 → 籌備下一步,減少交付延誤
    4. 客戶支援 AI 客服代表 人工分流 → 智慧分流,降低單一工單成本

    關鍵設計:商機階段刻意用兩個 Agent 分工(qualification 跟 outreach 分開),不是一個 super-agent 包山包海。Agent 之間透過 board 的 status 跟 column 接力,不直接 agent-to-agent 通訊 — 跟人類團隊 SOP 的 hand-off 邏輯一樣。

    量化成果

    指標 數字
    專案準時交付率 85%
    Scope creep 下降 20%
    ROI 5x
    PM 被追問 ticket 下降 ~30%
    內部溝通成本下降 20–30%

    CASETiFY 一年處理 600–700 個內部請求,過去靠 email + Excel + Slack 來回。導入 monday 之後,他們建了三種 board:Intake Boards(標準化請求收件)、Project Delivery Boards(可重複使用 template)、Capacity Planning Boards(產能 dashboard)。AI 做的事:長 submission 自動摘要、自動分類派工、跨語言翻譯、情緒偵測標記緊急請求。

    Growth PM Charlotte Chan 的原話:「我們一直收幾百個 request,但根本看不出有什麼進來、哪些重複、各自要花多少力氣。沒有透視度,計劃就會變成被動反應。」Engineering Director Terence Fung 補充:「monday 最大價值是真正統一的工作區 — 打掉部門 silo,讓跨團隊協作 seamless。」

    企業安全:Guardian add-on + AI Governance

    monday 對 enterprise 客戶開出兩道防線:資料層 Guardian add-on,治理層 AI Permissions Governance。

    Guardian add-on(Enterprise 專屬)

    • Tenant-Level Encryption (TLE):每個帳號專屬加密金鑰,定期輪替,跟其他客戶物理隔離
    • Bring Your Own Key (BYOK):金鑰存在你自己的雲端 KMS,你 100% 控制整個 lifecycle。撤銷 key = monday 立刻看不到你的資料(kill switch)
    • Data Leak Prevention (DLP):Admin 定義掃描規則,監控 updates 跟上傳檔案,自動執行政策
    • Multiple SSO:同帳號可配置多個身分驗證源(Okta + Azure AD + Google Workspace),適合併購整合場景

    AI Permissions and Governance

    Enterprise admin 中心提供兩個 tab:

    • AI Permissions Tab:控制哪些 role 能用 AI、在哪些 workspace 能用、用哪些 agent — 可細到單一 agent,也可一鍵套整體 default
    • Agent Directory Tab:全公司 Agent 的中央 dashboard,顯示 agent 名字、owner、sharing 狀態、目前狀態、asset access、建立日期、使用的模型。一鍵 activate / deactivate(等同「開除」Agent)

    支援的 LLM:Anthropic Claude、OpenAI GPT、Google Gemini,Sidekick 內建會為不同任務挑模型。對應前面 Vibe 那張 prompt 計費表 — 用戶或 admin 都能控制 cost/quality 平衡。

    合規認證一覽

    monday Trust Center 公開的清單:SOC 1/2/3 Type 2、ISO 27001 / 27018 / 27017 / 27032 / 27701、GDPR、HIPAA、CCPA、LGPD、PIPEDA、APPI、EU-US DPF、TX-RAMP、CSA STAR Level 1。資料中心 3 個 region:US、EU(法蘭克福)、APAC,全部跑在 AWS。

    一個容易踩雷的細節:即使選 EU region,monday 自家的 metadata(使用者憑證、profile、usage analytics)仍然存在 US — 只有 Customer Data 在 EU。法務團隊評估時這點要算進去。另外,region 由「第一個開帳號的人位置」自動決定,一旦設定不能改,真要從 US 遷 EU 得走特殊流程。

    誰該導入 monday.com AI Work Platform?

    講完功能、看完案例之後,真正的問題是:你公司適合導入嗎?monday 是個強大的平台,但不是萬靈丹。下面用情境、紅旗、規模、產業四個維度幫你判斷。

    5 種典型適配情境(這些情境,monday 真的會發功)

    情境 特徵 對應 monday 能力
    1. 大量標準化請求 一年幾百到幾千筆內部 request,目前散在 email/Slack/Excel Intake Form + AI 自動摘要分類派工(像 CASETiFY 600–700 件/年)
    2. 跨部門 silo 嚴重 行銷、業務、IT、客服各跑各的系統,資料對不起來 統一資料模型 + Agent 跨 board 串聯
    3. 業務 lifecycle 清楚分階段 行銷 → 商機 → 執行 → 客服,每階段有 SOP 多 Agent 接力,Board 當 handoff 介面(CASETiFY 5 Agent 模式)
    4. 重複性高的 knowledge work triage、分類、摘要、寫 brief、follow-up 占工時 30%+ Sidekick + Agents 自動化這些低 judgement 任務
    5. 跨國跨語言團隊 中英日韓夾雜,異地協作,時區跨度大 AI 自動翻譯 + 24/7 Agent 接力(CASETiFY 100+ 國家)

    6 個紅旗 — 出現這些就先別碰

    • 🚩 流程根本沒標準化 — 同樣的 request 每次都重新討論一次。Garbage in, garbage out,AI 只會把混亂變得更快更貴
    • 🚩 團隊 <10 人 — Basic plan 1,000 點只夠玩,要功能必須升 Standard。Enterprise(Guardian + 治理後台)強制 25 席起跳
    • 🚩 高度監管需要私有部署 — monday 是 cloud-only,銀行核心、醫療 EMR、政府內網不適合(只有 EU/US/APAC 三個 AWS region 可選)
    • 🚩 沒結構化資料基礎 — 還在用 Excel 跑生意、業務資料在每個業務私人筆記本裡。沒有 board / status / owner 概念,AI 沒有 context layer
    • 🚩 一次性專案、不重複的工作 — Agent 的價值在於規模化重複任務,單一專案直接找顧問划算
    • 🚩 只算 seat 費沒算 AI 點數 — 算 TCO 時忘了 Notetaker 120 點/hr、Vibe Opus prompt 最高 500 點/則 — 50 人團隊月跑 5 萬點 = $500 USD 是常態

    按企業規模看 ROI 分水嶺

    規模 建議 Plan 適配度 關鍵考量
    1–10 人 Basic / Standard ⚠️ 弱 AI 點數太少,Notion AI / ChatGPT Team 更划算
    10–50 人 Standard / Pro ✅ 中 Pro 點數彈性大,Vibe 應用 3 個夠用
    50–300 人 Pro(頂規 20,000 點) ✅ 強 最甜蜜點,有規模又不必上 Enterprise 門檻
    300+ 人 Enterprise + Guardian ✅ 強 BYOK / DLP / Multi-SSO / AI Governance 全套

    關鍵分水嶺:25 席 — Enterprise 強制最低 20,000 點 ÷ 800 點/席 = 25 席。10–25 人公司想要 BYOK 或多重 SSO,只能升到 25 席買 Enterprise,可能多花預算為了用不到滿的功能。這是台灣中型企業最常踩的雷。

    按產業看適配度

    產業 適配度 原因
    D2C / 電商 / 行銷代理 🟢 強適配 流程清楚、跨團隊協作密集、CASETiFY 即範例
    SaaS / 軟體 / 專業服務 🟢 強適配 數位化原生,intake/triage 量大
    製造業 / 營造 🟡 中等 看數位化深度,ERP 整合是關鍵
    教育 / NGO 🟡 中等 流程適合但預算敏感,Notion / Trello 替代
    金融核心 / 醫療臨床 🔴 弱適配 監管要求私有部署,monday cloud-only 不符合
    傳產零售第一線 🔴 弱適配 第一線員工不在電腦前,行動端體驗有限

    導入前 6 個自我檢核問題

    在掏錢前,先回答這 6 題。**5 題以上答得出來才繼續,否則先回去修內功**:

    1. 你的 intake 已標準化了嗎? — 同一類請求每次都用同一張表收?還是看心情寫 email?
    2. 你有 SOP / template 文化嗎? — 新員工三個月內能複製資深人員的工作流?還是每個人自己土法煉鋼?
    3. Stakeholder 習慣自己看 dashboard 嗎? — 主管會主動看數據還是等 PM 報告?自助看 = monday ROI 的核心
    4. 既有 SaaS 整合是否齊全? — Gmail / Slack / Calendar / Drive 用得熟?還是還在內部架 Lotus Notes?
    5. 法務 / IT 已對 AI 治理有共識嗎? — BYOK / 區域留存 / 不訓練第三方 — 法務願不願意簽?
    6. 你算過真實 TCO 了嗎? — Seat 費 + AI 點數 + Guardian + 變更成本(培訓、流程改寫)— 不只是 sticker price

    真實成本估算:50 人公司跑一年

    以一家 50 人公司 Pro plan 為例(粗估,實際以業務報價為準):

    項目 估算
    Pro 月費 × 50 席 × 12 月 ~$15,000–18,000 USD/年
    AI 點數(月跑 50,000 點 ≈ $500)× 12 ~$6,000 USD/年
    Notetaker(50 人 × 月平均 4 hr 會議) ~$2,880 USD/年(內含於 AI 點數)
    變更管理(培訓 / 流程改寫 / 顧問) $5,000–20,000 USD(一次性)
    第一年總計 ~$26,000–44,000 USD

    對應 CASETiFY 報的 5x ROI:他們省下的等於 $130,000–220,000 USD/年(主要是 PM 時間、溝通成本、減少漏單)。回本期通常 6–12 個月,前提是真的把流程改了,不是買來放著。

    變革管理 3 個重點(CASETiFY 經驗萃取)

    1. 先 1 個 board 起家 — 不要一次全公司導。CASETiFY 是 2019 年從 IT 一個 board(2 天建好)起步,慢慢擴散到 300 人。先有第一個成功案例,再橫向複製
    2. 找到一個 sponsor + 一個 super user — Sponsor 給預算和政治支持(通常是 COO/CIO),super user 教全公司怎麼用(通常是 PM 出身)。少一個都會失敗
    3. Agent 命名 + 人設 = 採用率關鍵 — CASETiFY 把 agent 取名 Annie、Eric、小蕾,有頭像有人設。研究顯示員工對「同事 Agent」採用率比「工具 AI」高 2–3 倍。心理門檻才是真門檻

    5 個導入原則(把 CASETiFY 經驗壓成一頁)

    1. 先標準化 intake — 沒這層,AI 都白搭。垃圾進垃圾出
    2. Template 化專案 — 不是每次重畫流程,踩過的坑變模板
    3. Dashboard 給 stakeholder 自助看 — 主動降低被追問次數,CASETiFY PM 被追問下降 30%
    4. AI 嵌進去 ≠ 取代人 — 加速 triage,judgement 在人身上。Agent 是擴增,不是替代
    5. monday 不是孤島 — CASETiFY 同時用 Databricks 跑資料層,monday 跑工作流層。要跟既有 stack 共存才有用

    最後一個容易被忽略的點:CASETiFY 的後端不是只有 monday — 資料層用 Databricks 統一資料湖,千萬級 SKU 平行跑模型。monday 不是孤島,要跟既有的資料 stack 共存才有用。如果你以為買了 monday 就能取代既有 ERP / CRM / BI,那是把工具當銀彈,通常會慘賠。

    結語:從工具到工作平台的範式轉移

    2026-05-06 這個日子,在工作管理軟體史上會被記住。monday.com 不只發新功能,而是整個產品定位重新定義 — 從「給人類用的工具」變成「人 + AI Agent 一起工作的平台」。Agent 在這個架構裡是 first-class citizen:有名字、有頭像、可被 @mention、可指派為 owner、有 Brain 記憶、有 audit trail、可被 admin 開除。

    對台灣中型企業來說,真正要決定的不是「要不要導入 monday」,而是「業務流程準備好讓 Agent 接手了嗎」 — Intake 標準化了嗎?Template 化了嗎?Dashboard 給 stakeholder 自助查的習慣建立了嗎?CASETiFY 那 85% 準時交付、5x ROI 不是 AI 變出來的,是 7 年累積的流程紀律加上 AI 放大。AI 是放大器,放大的是你既有的流程品質。如果流程本身是亂的,AI 只會把混亂變得更快、更貴。