小丁的家

標籤: 技術筆記

  • 拔掉 RLS 的兩天：AI 時代規模化 Day One 為何從奢侈變預設

    重點摘要

    • 灌 540 萬包裹壓測，警衛的社區包裹列表要 7330 毫秒。病根是 RLS 兩條 PERMISSIVE policy 用 OR 合併，讓查詢規劃器用不到 community_id 索引。
    • 全面拔除 173 條 policy、85 張表的 RLS，租戶隔離 100% 改由應用層帶 community_id。同一條查詢從 7330ms 降到 1.34ms，約 5500 倍。
    • 但拔掉 RLS 不是終點——第二波跨社區洩漏被「單租戶壓測」蓋住了：對照社區在多數表是 0 筆，洩漏判準（本社區數＝全平台數）自動成立。要每張表都灌 ≥2 個社區才測得出；而且漏帶 community_id 不只洩漏，更是少了索引，同一個病根換地方又長。
    • AI 把規模準備的「建造成本」打掉了，但有兩個成本它打不掉：分區帶來的「複雜度稅」（維護照繳），與「取決於規模實測才知道對錯」的經驗決策（RLS 自己就是反例）。
    • 結論：AI 時代「規模化 Day One」從奢侈變預設，但「準備什麼」的判斷力更值錢——有把握的提前上，取決於壓測的，老實留給壓測。

    一個 V2 產品、兩天、一個 AI 協作者，把一套多租戶系統從「靠資料庫兜底」推進到「應用層自己負責」。這篇記錄的不是 commit log，是技術選型的隱性成本，怎麼在特定規模與特定哲學下才現形——以及 AI 怎麼悄悄改寫了「該不該提前準備規模化」這道老題目。

    先講結論：MVP 智慧是成本算出來的啟發法，不是定律

    傳統智慧說：MVP 先做，別過度工程，規模化以後再說。這句話我一直信，直到這兩天我意識到——它是一條成本驅動的啟發法，不是定律。

    它成立的前提是「規模準備很貴」。以前要做分區、多租戶隔離、idempotency、離線佇列這整套規模機械，往往要多三到四倍的人力、好幾個月。那個成本，才讓「先別做、等需要再說」變成理性選擇。但兩件事同時改變了這個算式：

    1. AI 把建造成本打掉了。那套規模機械，AI 輔助下生成 + 維護的人力崩塌。
    2. 這是 V2，不是 try。前一版已經證明了領域——住戶、警衛、包裹是真需求，而且會有很多社區。規模不是猜測，是 near-certainty。「You Ain’t Gonna Need It」的前提「你可能不需要」，直接是假的。

    所以對一個 AI 輔助、領域已驗證的 V2，Day One 就準備規模化，比經典 MVP 智慧主張的更該做。但這篇真正有料的地方，是兩個 AI 也打不掉的成本。後面講。

    當初為什麼這樣選技術？

    這套系統的技術選型，是三股力量的合力：領域驅動 + 規模前瞻 + 不重蹈前版覆轍。

    • Flutter 單一 codebase：住戶用手機、警衛用平板，功能大半重疊靠角色 gate。兩份原生 = 兩倍維護；一份 + responsive 是省力的對。加上離線優先是硬需求（警衛平板斷網也要能收件、拍照、印通知條）。代價老實說：CanvasKit 的 web 端很痛，e2e 自動化一路在跟它的無障礙語意樹搏鬥。
    • Go + GraphQL（型別契約）：Go 單一 binary 好部署、並發強，對著「1000+ RPM / 1000 社區」的目標。GraphQL 用型別嚴謹的契約——這是對前版的反動：舊版用 category/method 字串路由 + PHP 的型別強制轉換怪招，踩過坑。型別世界 = runtime 少驚喜。
    • PostgreSQL + RLS（Row-Level Security）：這個最值得講，因為我們親手拆了它。

    RLS 的故事：為安全而選，為清亮而拆

    RLS 當初為什麼選？防禦縱深。理由聽起來無懈可擊：「把租戶隔離放在資料庫層，app 出 bug 也繞不過。」每個社區的資料用 policy 鎖死，誰都別想跨社區看到別人的包裹。

    然後規模化壓測來了。我們灌了 540 萬包裹、5.4 萬戶、202 個社區，模擬一個 V2 跑兩三年後的樣子。一量——警衛的社區包裹列表，7330 毫秒。七秒。

    病根不是索引沒建，是 RLS 的兩條 PERMISSIVE policy 用 OR 合併：(是系統管理員) OR (社區=X)。community_id 只出現在 OR 的一邊，查詢規劃器就用不到 community_id 索引，只能 Seq Scan 掃完整張表的所有分區。這個病，設計時看不出來，要到 5.4M 才現形。

    業主的反應很關鍵。他不要「在 DB 加更多限制」來繞，他要的是更乾淨：「我不要我的資料庫跟我的 AP 有這樣的依賴。本來就該做到零洩漏，怎麼會依賴 RLS？」

    於是我們全面拔除 RLS——173 條 policy、85 張表，全部 DROP。租戶隔離 100% 改由應用層：每一條碰租戶資料的查詢，自己帶上 community_id = current_setting('app.community_id')。

    拆的過程，反過來證明「本來就該零洩漏」當時是假的

    審計時我抓到，授權中介層對「同社區範圍」的操作寫死了一行註解：「RLS 負責租戶隔離，這裡不另外檢查。」也就是說，有好幾個改別人資料的後端進入點（停用警衛、在別社區建戶、復活別社區的軟刪戶），它們的隔離正確性，本來就完全押在 RLS 上。RLS 一拔，這些就是跨社區提權漏洞。

    派去掃的 AI 子代理一開始判了 23 個缺口；我逐條人工驗證，收斂到 3 個真缺口——其餘有的早被別的守衛擋著、有的是子代理幻覺出根本不存在的函式。這也是個教訓：AI 的清單要逐條驗，不能盲信。

    拆完，效能呢？同一條查詢，帶上 community_id：

    查詢 RLS 開（OR 合併擋索引） RLS 拔除 + 應用層 community_id
    警衛社區包裹列表（5.4M 列） 7330 ms（Seq Scan 全分區） 1.34 ms（Index Scan）
    包裹改動歷程鑽取 — 0.2 ms

    從 7330ms 到 1.34ms，約 5500 倍。反諷的地方：當初選 RLS 是「為了安全」。它不但變成效能地雷，還讓 app 層偷懶——「反正 DB 會兜底」，於是 app 層的隔離就不嚴謹了。兜底機制養出了被兜底者的鬆懈。

    拔完 RLS 之後：洩漏沒結束，是換了個地方躲

    拔掉那天修了 3 個提權，我以為收工了。錯。RLS 一拔，等於把「DB 兜底」這層拿掉，所有原本偷懶的查詢全部裸奔——真正的第二波，要再跑一輪壓測才現形。

    一個包裹計數查詢，給某社區警衛回了 280 萬——那是整個平台的數字，不是他那個社區的。病根：這個 count 自己手寫 WHERE，繞過了會自動補 community_id 的中央 helper。同一類的還有一票：社區統計（*Stats）、各種計數（*Count）、住戶/包裹 picker、以及「先 load-by-id 再改」的 mutation——全是各自為政手寫查詢、漏帶租戶欄位的高風險地帶。

    但這篇最該記住的，是為什麼第一次壓測沒抓到。答案很反直覺：單租戶結構上測不出跨租戶洩漏。

    我第一次灌的 540 萬，只灌在 parcels 和 households 兩張表，其他維度（使用者、訪客、公告、picklist）對照社區根本 0 筆。而洩漏的判準是「本社區查到的數字 == 全平台的數字」——當對照組是 0，這條恆等式自動成立，洩漏被 0 資料蓋得死死的。修法不只是補 WHERE，是補資料形狀：每一張要驗的表，都灌進 ≥2 個社區的資料，動態探針才有對照組去抓「你回給我的，有沒有混進別人的」。

    還有一層，業主一句話點破：漏帶 community_id 不只是洩漏，是效能。「為什麼還有功能沒戴上 ID，這不只會洩漏，重點是效能會變差，沒用到 index。」少了那個欄位，查詢就跟當初 RLS 的 OR 一樣用不到索引、掃全表。防洩漏和上索引，是同一個動作——community_id 既是隔離邊界，也是索引前綴。當初那個「OR 擋索引」的病根，拔了 RLS 之後，在每一條手寫查詢裡換個地方又長了出來。

    規模下另外兩個 Day One 就得拍的板

    同一輪還拍了兩個一旦上線就很難回頭的板，都是「規模 + 時間」逼出來的。

    • 快照 vs 正規化：歷史標籤不准 join。包裹上的物流公司、儲位、包裹類型、收件人姓名，全部存成當下的文字快照，不是外鍵。為什麼不正規化？因為這些是歷史事實。若做成外鍵去 join 現行字典，哪天某家物流公司改名或下架，過去的包裹紀錄會被回頭改寫——未來的公司出現在過去的資料上。原則一句話：身分用外鍵，歷史標籤用快照。這跟「證據鏈不可竄改」是同一個底層要求。
    • 控制面狀態用單例快取，不是每頁查 DB。社區可被系統管理員停用，每個請求都得確認「這社區還活著嗎」。最笨的做法是每頁打一次 DB——那又是另一種 RLS 式的過度防禦。做法是一個程序級單例快取（map + 鎖），10 分鐘 TTL，miss 才查 DB，停用/復活時主動逐出；隔離檢查收斂在一個 chokepoint（進交易時查一次），不撒在每條查詢。順手修了個誠實問題：社區停用後登入原本回「帳密錯誤」會誤導用戶，改成帳密對的人才告知「社區暫停服務中」——既不誤導本人，也不洩漏社區存在給攻擊者。

    兩個 AI 也打不掉的成本

    回到開頭的 thesis。AI 讓規模準備「便宜到值得 Day One 就做」——但有兩個成本它打不掉。

    成本 AI 打掉了什麼 AI 打不掉什麼
    複雜度稅 建造成本（生成分區/隔離/佇列） 維護稅：每次改動/debug 都要付。例：pg_total_relation_size 對分區母表回 0，最大的表都報 0，要展開分區層才量得到
    經驗決策 實作速度 壓測經驗：RLS 的「OR 擋索引」要 5.4M 才看得見，連 AI 都沒辦法 Day One 告訴你對的選擇

    成本一：AI 打掉「建造成本」，沒打掉「複雜度稅」。月分區讓程式更難推理。這兩天我們親自繳了這個稅：監測資料量時，pg_total_relation_size 對分區母表只算母表本身（回 0）；還有 FK 要複合鍵、分區不繼承 RLS、清測試資料時被自己剛上的 append-only trigger 擋住……這個複雜度，是每一次未來改動、每一次 debug 都要付的稅，連 AI 也付。「AI 讓規模準備好建」是真的，「規模準備免費」是假的——稅照繳，只是從建造繳給了維護。

    成本二：有些規模決策是「經驗的」，Day One 就是準備不了——RLS 自己就是鐵證。RLS 本來就是 Day One 的規模準備（多租戶隔離），結果它是錯的 Day One 選擇。為什麼當初設計看不出來？因為「OR 擋索引」這個病要 5.4M 壓測才看得見。有些決策，正確答案取決於規模行為，而那行為你預測不了——那是壓出來的，不是設計出來的。而且如前面那一節的教訓：光有規模還不夠，要對的「資料形狀」——對照社區是 0 筆的那次壓測，把第二波洩漏整個蓋住了。經驗決策不只需要壓力，需要對的壓力。

    AI 時代，「規模化 Day One」從奢侈變預設。但「準備什麼」的判斷力反而更值錢：有把握的結構提前上（便宜了）；取決於規模實測的決策，老實留給壓測。

    有把握的（會有很多社區 → 按社區/時間分區；離線不可妥協 → 佇列），提前做。沒把握的（隔離機制、索引策略），別假裝設計階段就能拍板。這跟我之前寫過的 企業 AI 落地為什麼失敗 是同一個底層觀念：方法論不能照抄，要看你的前提條件還成不成立。

    方法：規格化、決策留證、以及「我自己打臉自己」的報告

    這兩天還做了第二件大事——把包裹做成可被法庭級檢驗的證據鏈。改動寫進不可竄改的 log（鑽一顆包裹的歷程，5.4M 下 0.2 毫秒）、簽名與照片在儲存層鎖死不可刪、系統管理員調查要「破窗」且每次都留審計。但比功能更值得分享的是方法：

    • 規格先行。每個設計決定都先寫進規格、辯論清楚、鎖進文件，才動手。對話會被壓縮遺忘，規格不會。
    • 決策留證，不靠主觀評分。業主不信任 AI 加工過的「成本/風險」評分，他要看真實檔案、真實行數、schema 影響。所以需要他拍板的時刻，我生的是事實卡片，不是紅黃綠燈。
    • 三份報告的誠實檢驗。最後他要一份評分報告。但他要的不是一個數字——他要三份做比較：原始版、我「現在的預估」（鎖時間戳，不准事後改）、和「全部做完 + 全面測試後的真實量測」。核心是拿我的主觀預估去對真實量到的，差多少 = 我的評估可信度。

    結果：我預估綜合 7.5，真實約 7.8，誤差約 0.3 分；方向性預測（「dev 環境的測試污染會讓部分整合測試紅、但那不是回歸」「forensic 能力做完會升」「效能會守住」）全中。唯一校準：我對「系統穩定度」過度保守——實際零回歸。這種「逼 AI 先承諾預測、再用真實數據打臉」的設計，把「AI 的話可不可信」變成一個可量測的問題。

    人機協作：最好的部分不是分工，是辯論

    這兩天的分工大概是：業主出領域知識與方向決策，AI 出執行、驗證與反思。但最好的部分不是分工，是辯論。RLS 該不該拆、拆了 sysadmin 怎麼查日誌、照片資料夾要不要鏡射分區、孤兒清理會不會變成刪證據的後門——這些不是「下指令、執行」，是來回推。

    業主用領域常識把我拉回現實（「哪有警衛不分社區的，警衛 A 在四個社區工作就是四個警衛」），我用壓測數據和審計把假設證偽（「你說本來就零洩漏，但我們現有 code 就漏了 3 個」）。AI 不會累、能掃完每個呼叫點、能把 23 個候選逐條驗到剩 3 個真的；但判斷「準備什麼」「什麼時候該停下來問人」，還是要人。

    結語

    如果只能留一句：老的 RD 有老的包袱，所以才有「MVP、先別管規模」的智慧。但那個智慧是成本算出來的。當 AI 把建造成本打掉、當你做的是領域已驗證的 V2——規模化就是 Day One 的事。只是別忘了，AI 打不掉複雜度稅，也替不了你壓測；有把握的提前上，沒把握的，老實壓出來——而且要用對的資料形狀去壓，單租戶測不出跨租戶的洩漏。

    RLS 是我們「Day One 準備了錯的東西、規模化才發現」的活標本。它沒有讓這個決定變壞——它讓這個決定有了教材。

    技術細節：Flutter + Go(gqlgen) + PostgreSQL 16；月分區、River 佇列、MinIO。壓測 540 萬包裹 / 202 社區 / RLS-off：熱查詢 1.34ms、改動 log 鑽歷程 0.2ms。

  • 跟 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 條的本質就是把這三層活的紀律寫下來。

    跟我之前文章的關聯

  • AI 不該替我打 🟢🟡🔴:從 decision-server 看跟 LLM 協作決策的介面方法論

    重點摘要

    • Markdown vs HTML 是假議題 — 真正問題是「LLM 給人類決策時的介面設計」
    • AI 加工成 🟢🟡🔴 標籤的「成本/風險」評分,使用者不信。要 raw evidence (檔案、行數、schema 影響),讓使用者自己判斷
    • 解法:一個 Flask + systemd + Cloudflare tunnel 的 decision-server,每個決策生 HTML 頁,使用者在瀏覽器/手機看真實證據後點選項
    • 規則寫進全域 ~/.claude/CLAUDE.md,所有 Claude session (含 Telegram bot) 自動遵循
    • 實戰跑通:4 個 agent 並行審查 dementia-care home-handbook 找出 45 個 findings → 5 個獨立決策 page → 答完 5 tier 自動改動 → commit 3d1f101 → 自動部署 GitHub Pages

    起點:一個假議題

    今天早上我問 Claude:「最近有一個聲音說過去我們使用 markdown 沒有實用性,要用 HTML。你幫我比較一下。」

    Claude 給了一份標準比較 — Markdown 的 token 效率、git diff 友善;HTML 的語意豐富、表達力強。然後得出結論:「在你的場景 markdown 全面勝出」。

    但我打斷他。真正卡我的不是文檔格式,是另一個問題:每次 Claude 問我做決策時丟一面牆的 markdown 字,我不知道背後意義、不知道範圍、不知道要考慮什麼,認知負擔很重。如果能像 HTML 那樣用顏色區塊跟拖拉條一眼判斷,我做決策的速度會快很多。

    這篇文章記錄今天從這個誤會開始,到我跟 Claude 一起建出一個跨 session 通用的決策伺服器,中間踩到的設計坑 + 抽出的協作方法論。

    第一次嘗試:加 🟢🟡🔴 對照表

    Claude 第一個提案是用 Claude Code 內建的 AskUserQuestion 工具,加上 emoji 視覺對照表。範例:

            速度  成本  風險
A 拆分  🟢   🔴   🟢
B 單檔  🟡   🟢   🟡
C 折衷  🟡   🟡   🟢

推薦 → C (綜合最佳)

    看起來不錯。我選了這個格式。Claude 還幫我寫進 feedback memory,以後預設都用這種對照表。

    30 分鐘後,我反悔了:「你說的成本不一定是真的成本,你說的風險也不一定是真的風險。你的比較我也不太能夠相信。」

    核心問題:Raw Evidence vs 加工標籤

    🟢🟡🔴 是 Claude 對「成本/風險」的主觀評分。它幫我把證據壓縮成一個顏色,但這個壓縮過程是有損的,而且我看不到原始材料,沒辦法 second-guess。

    真正能幫我決策的不是「Claude 認為這個選項風險 🔴」,而是「這個選項會動 db/migrations/0042.sql 第 38 行的 CHECK constraint,影響 50,000 rows」。前者是評分,後者是事實。前者我半信半疑,後者我自己判斷。

    這個 framing 反過來界定了 LLM 在人類決策流程裡的角色:

    • 不該做的:替使用者打分數、給推薦星等、用顏色暗示優劣
    • 該做的:把零散證據整理成可掃描的結構,擴展使用者的判斷面,不替代它

    解法:decision-server

    我提了一個架構:在我的迷你 PC 上開一個 port,Claude 要我做決策時生成 HTML 丟到那個 port,我用瀏覽器/手機看。Claude 接過去做了完整實作:

    • Server:~/decision-server/server.py (Flask, 87 行)
    • Service:systemctl --user enable decision-server (linger 開,跨重開機)
    • Port:8765
    • Public URL:https://askme.tomting.com (Cloudflare Tunnel)
    • Endpoints: GET /d/{slug} 看頁面,POST /d/{slug} 收答案

    每個決策 3 個檔案共用一個 slug:

    檔案 寫入者 內容
    pages/{slug}.html AI 人類看的決策頁面
    meta/{slug}.json AI question + options 的結構化規格
    answers/{slug}.json Server 人類點完寫入,自我描述 (含 choice_label 全文)

    關鍵設計:answer.json 自我描述。不只存 choice: "B",連 choice_label 全文也存。三個並行 session 都點 B,後續讀檔不會混淆,因為每個 B 都帶著自己的語義。

    Selenium 跑了一輪整合測試:3 個假 session 各生一個決策 (slug 開頭分別 a3f7- / 9e2c- / b51d-),選不同字母,驗證:

    • 3 個 session 各自寫到自己的 answer.json,零交叉污染
    • index 頁正確分組顯示
    • 每個 answer 自描述完整

    頁面設計的演進

    第一版 page 只有「標題 + change_cards + options」。Tom 開了一張 demo 看完反應:「感覺資訊很少,情境根本無法懂問題是什麼,我要怎麼決策?」

    對。決策者通常從別的事情切過來,不會有問題提出者的 context。設計 onboarding 區塊變成必填:

    • 📖 背景 (background):這個功能是什麼?涉及哪些表/服務?為什麼會跑出這個 decision?
    • ⚡ 核心問題 (problem):具體哪裡卡?矛盾在哪?
    • 🩸 不解的後果 (impact):拖著會怎樣?(技術債/錯誤/blocking 什麼)
    • 🔍 證據卡 (change_cards):真實 file:line + 真實 +/- 行數 + 1-3 個 bullet
    • 🎯 選項 (options):每個帶 consequence (成本 / 副作用 / 適合什麼情境)

    三層 framing 補完,Tom 就算前 5 分鐘在洗碗,開連結 30 秒內也能判斷。

    讓所有 session 都用這個 protocol

    我們建好了 server,但有個問題:Tom 同時開好幾個 Claude session — 寫 iDempiere 的一個、跑 Home123 的一個、Telegram 上的 ccbot 一個。每個 session 都要知道用 decision-server,不能靠每次重提。

    解法:寫進全域 ~/.claude/CLAUDE.md (Claude Code 對所有 session 都會載入的全域指引)。新增段落「🌐 Decision-Server Protocol — MANDATORY for asking Tom decisions」,包含:

    • 觸發情境表:10 種要用 decision-server 的真實場景 (方案選擇 / 範圍決定 / 優先順序 / 動作授權 / 設計選擇 / Code review 後 / Schema 變更 / 批次決策 / 工具升級 / 不可逆操作)
    • 不觸發情境表:6 種對話講就好的例外 (確認理解 / 缺資訊 / 真瑣碎 yes/no / 用戶明說 / 教學模式 / Server 掛了)
    • 必填欄位表:14 個欄位的必選規格
    • 完整範例:一個 canonical JSON 直接抄
    • 禁止寫法表:9 條紅線 (例如禁止 "risk": "🔴" 主觀標籤)
    • 常見錯誤:5 個 future-session 易犯的

    驗證方式:跨 session 自動採用。寫完規則沒多久,ccbot (跑在 Telegram 上的獨立 Claude session) 在不知情狀況下,自動讀到全域 CLAUDE.md,自動用 protocol 生了 6 個決策 page (session_id 6089),Tom 在 Telegram 看到「卡你決策 6 條」改成 6 個 askme.tomting.com 連結,在手機上 5 分鐘答完。

    真實案例:home-handbook 審查

    整個 stack 跑通後,我用它做了第一個真實任務:全面審查 ~/Desktop/dementia-care/home-handbook/ (失智照護 handbook,4 個 HTML 檔案 4719 行)。

    步驟 1 · 並行 agent 掃描

    派 4 個 general-purpose agent 並行掃 4 個檔案 (index / caregiver / long-term / emergency),每個 agent 應用同一份 10 項檢查清單,清單來自 brain/llm-handbook-writing-pitfalls.md 的 9 個失敗模式 + design-principles 的 CDN/emoji 規則:

    1. 細節腦補 (沒驗證就寫具體名詞/數字)
    2. 失能 vs 失智 frame 混淆
    3. boredom vs restlessness frame
    4. 加法 vs 減法 (測試記憶 framing)
    5. 醫療因果 claim 無文獻 (「會/導致/加速 + 醫學名詞」紅線)
    6. SOP magic number 沒推導
    7. 戲劇化描述 (「像 X 一樣」「彷彿」)
    8. 工程師腦過度設計 (可觀測性、冗餘、invariant 思維)
    9. PII 洩漏 (姓名、稱呼、地址)
    10. CDN / 外部依賴 / 新 emoji (Unicode 14+)

    並行加總 4 個 agent 跑完 ~2 分鐘,回報 45 個具體 findings,每個帶 file:line + 引用原文 + 建議改法。

    步驟 2 · 用 decision-server 生 5 個獨立決策 page

    45 個 findings 不是 45 個決策。Claude 把它們合併成 5 個策略性決策(因為一頁一決策原則:類似議題歸為同一決策,選項是「處理策略」):

    # 議題 我選的
    1 PII 清理範圍 B:保留 meta author,內文一律第三人稱 + 砍 HTML 註解
    2 外部連結處理 B:保留連結 + 加 rel=”nofollow”
    3 醫療因果 claim D:混合 — 有臨床共識的補引用 (Beers Criteria / NICE),其他弱化或砍
    4 scope overreach (E6/E7/E8 跨 CDR 2 經驗) D:保留現狀,disclaimer 移到三章開頭加明顯
    5 magic number 無推導 D:混合 — 自家 SOP 補推導,醫療閾值補 disclaimer

    步驟 3 · 執行 + 部署

    我用瀏覽器答完 5 個 page,Claude 讀 answers/*.json 自我描述的 choice_label,執行對應改動。整理出 5 個 tier 的具體 edit (PII / 外部連結 nofollow / 醫療 claim 引用 / scope disclaimer / magic number 推導),全部用 Edit 工具批次處理。

    最後輸出:

    • commit 3d1f101 on dev branch,4 files changed, +46/-34 lines
    • merge dev → main (commit d3ccc98)
    • push origin/main
    • GitHub Pages 5 秒部署完成
    • 線上版:https://tm731531.github.io/dementia-care/home-handbook/

    抽出來的方法論

    原則 1 · Raw evidence > 加工標籤

    LLM 替使用者壓縮資訊是有損操作。決策接口要顯示可驗證的事實(檔案路徑、行數、schema 影響、binary 屬性),不是顯示 AI 對事實的評分(🔴 高風險、複雜度中等)。標籤把使用者鎖在 AI 的判斷裡,事實讓使用者用自己的判斷。

    原則 2 · 決策頁要做 onboarding 設計

    使用者打開決策頁時通常是「從別的事情切過來」,沒有問題提出者的 context。背景 / 問題 / 不解後果三段缺一不可。光列證據卡片他看不懂為什麼這個問題重要。

    原則 3 · 選項要帶後果

    選項 label 不夠。每個 option 帶 consequence 三件事:成本 (要做多少工)、副作用 (選了會被什麼牽動)、適合什麼情境。沒這三件事使用者只能猜選了會發生什麼。

    原則 4 · 一頁一決策

    N 個決策要用 N 個獨立 page,不要塞在同一頁。理由:answer.json 自我描述,每個答案要能單獨理解。多決策塞同頁 = 回到 Tom 鄙視的「文字牆」。

    原則 5 · 全域配置 > 個別提醒

    跨 session 要一致,要寫進全域 system prompt (Claude Code 的 ~/.claude/CLAUDE.md),不能靠每個 session 個別記住。寫進全域 = 自動覆蓋所有未來 session 包含 sub-agent 跟跨平台 bridge (ccbot)。

    原則 6 · 流程要可驗證

    關鍵 invariant 要寫測試。test_multi_session.py 用 Selenium 驗證 3 個並行 session 不互相污染。每次改 server 或 generator 都跑一次。PII 清理用 grep 自動驗:grep -c "老媽" 應該為 0。

    整套 Stack 重現指南

    如果你想複製這套協作模式,這是最小的 reproducible setup:

    • Server:Flask app,3 個 endpoint (GET / + GET /d/<slug> + POST /d/<slug>)
    • Generator:Python helper 接 stdin JSON spec 生 page + meta
    • Wait:Python helper 阻塞 polling 直到 answer.json 出現
    • Templates:Jinja2 – decision.html (含 session bar / 三層 context block / change cards / options buttons)
    • Service:systemd user service + linger 開 (持久跨重開機)
    • Public access:Cloudflare Tunnel (免費,1 條 command)
    • Global config:Claude Code 的 ~/.claude/CLAUDE.md 加 MANDATORY 區塊

    所有 Python 依賴只用 Flask + Selenium (測試用) + Jinja2,記憶體佔用 ~20MB,啟動時間 1 秒。整個 server.py 87 行,generator.py 75 行,template 88 行 (含 CSS)。建構成本 1 個下午,跑通就終身使用。

    結語:不要替我打標籤

    這篇文章的起點是 markdown vs HTML,但真正的問題從來不是文檔格式。是「LLM 在人類決策流程裡扮演什麼角色」。

    當 LLM 把所有事情壓縮成 🟢🟡🔴 或星等推薦,它就把使用者鎖在自己的判斷裡。當 LLM 把零散證據整理成可掃描的結構頁面,它擴展使用者的判斷面。前者是 LLM 取代人,後者是 LLM 服務人。

    建一個決策伺服器只是工具實作。背後的設計決定才是真正的協作哲學:給事實不給評分,給結構不給結論,給選項不給推薦。

  • 跟 AI 寫程式的紀律：6 條規矩讓 AI 從 21 輪修不完到自走嚴格測試

    給趕時間的人

    • 兩週前我跟 AI 一起寫一個社區管理 SaaS,跑 21 輪除錯都收不完。每輪都找到新 bug,修了還有新的。
    • 診斷:不是 AI 不認真,是「靠 AI 在 40 個 API 都記得做對 5 件事」這個工作模式注定漏。40 × 5 = 200 個漏分點。
    • 解法:4 招 + 6 條規矩(本文後半段是 6 條規矩的可貼可用 template)。
    • 16 天後 AI 自己會寫嚴格 TDD,commit message 自動標 (green via test in <sha>)。新專案直接套同樣 6 條規矩。
    • 最重要的觀察:AI 寫方法論時看不見自己盲區。每次升級都靠使用者一句質疑觸發,不是 AI 自己 reflect 出來。

    本文兩部分:(1) 前半段是故事——我做了什麼,為什麼。(2) 後半段是規矩——你可以直接複製到自己專案的 6 個 template。最後是觀察 + 總結。

    Part 1 — 故事:21 輪修不完的具體模樣

    兩週前我開始一個個人專案——社區包裹/訪客管理 SaaS。後端 Go,前端 Flutter。我用 Claude 寫程式,然後派另一個 Claude 當 QA 測試員找 bug。

    第一輪測試員找到 5 個 bug,工程師 Claude 修掉。再派一個新 QA。又找到 5 個。修掉。再派。又是 5 個。跑了 21 輪。每輪都有新 bug。幾天時間沒收尾。

    診斷:200 個漏分點

    不是 AI 不認真。後端有 40 個 API,每個都要做同樣 5 件事:

    • 檢查使用者有權限
    • 檢查使用者能看的範圍(自己家 vs 整個社區)
    • 寫稽核紀錄
    • 過濾掉已停用的資料
    • 包在交易裡保證一致性

    每個 API 都是 AI 手寫這 5 件事。40 × 5 = 200 個漏分點。AI 偶爾漏一件 = 一個 bug。不同 API 漏不同件 = 看起來像 40 個不同 bug,實際是同一類錯誤。LLM 擅長照範例寫單一段,但要求它在 40 個地方都「記得做對 5 件事」就是靠機率。

    4 招解法(高層次概覽)

    1. 把 5 件事打包成一個函式。每個 API 開頭必須呼叫它+明確宣告自己屬於哪種範圍。沒呼叫 = 編譯不過。「人記得」變「系統強制」。
    2. 寫紅線清單(invariants)。每修一個 bug 學一條教訓,寫進編號 INV-XXX-NNN。新功能寫好之後 QA 對著清單跑紅藍對抗,違反 = bug。規矩 3 提供模板。
    3. QA 測試員只能講人話。不准標 P0/P1。只能回 ✅/❌/⚠️ OPEN 三種。嚴重度由你做 30 秒判斷。規矩 4 提供 prompt。
    4. 測試要真的紅過。test 先寫先 commit (red),fix 後寫後 commit (green via test in <red-sha>)。commit log 自帶證據,不靠良心。規矩 2 寫進專案根。

    16 天後 AI 自己會走這套流程。新功能 commit message 自動標 (green via test in <sha>)——我已經沒在提醒。下個專案(訪客系統)第一個 cycle 直接套同樣紀律,沒重新爬坡。

    Part 2 — 規矩:6 個可貼可用 template

    下面 6 條規矩是你下個專案開工直接可以複製貼上的東西。前 5 條是檔案 / prompt,第 6 條是日常對話紀律。

    • 規矩 1:Day 1 開工 prompt
    • 規矩 2:CLAUDE.md 專案根(AI 每次自動讀)
    • 規矩 3:docs/invariants.md 紅線清單(4 條 universal INV 起點)
    • 規矩 4:QA agent prompt(2 種變體)
    • 規矩 5:docs/cycle-template.md PR cycle 8-stage 模板
    • 規矩 6:跟 AI 的日常對話紀律(5 條)

    規矩 1 — Day 1 開工 prompt

    新專案第一句話給 Claude / ChatGPT / 任何 LLM 的 prompt。把 4 個角色分工 + 5 條紀律明文化:

    我要跟你協作開發 [你的專案類型]。我們的合作規則:

1. 我寫規格,你寫程式。修改規格必須先跟我討論,不能自己加需求。

2. 任何修 bug 都走「先寫測試紅 → 寫 fix 變綠」順序:
   - 先 commit 一個 failing test,commit subject 加 (red)
   - 跑 test 確認它真的失敗
   - 才寫 fix,commit subject 加 (green via test in )
   - 不准 test 跟 fix 同 commit

3. 你做為 QA 時只能回三種結果:
   - ✅ 跑過了(對某條規則跑紅藍對抗,沒違反)
   - ❌ 違反了(附 reproduce 步驟 + 預期 vs 實際)
   - ⚠️ 看到怪事但不確定是不是 bug
   - **不准標 P0/P1**,嚴重度是我的判斷

4. 每修一個 bug 必須:
   (a) 寫進 docs/invariants.md 一條 INV-XXX-NNN
   (b) 對應寫一個 invariant test
   (c) 才算修完。少做任一件 = 沒修完。

5. 我每次 ✅/❌ 你要懷疑——9 個 ✅ 不代表程式對。
   涵蓋面外的東西永遠是 Schrödinger 狀態。

開工前先讀 CLAUDE.md + docs/invariants.md。
完成上述理解後回覆「協作規則已確認」,然後我們開始。

    規矩 2 — CLAUDE.md 專案根

    專案根目錄放這個檔。Claude Code 每次開工自動讀。把規矩 1 的內容固化成檔案,不必每次貼 prompt:

    # [專案名] — AI 工作指引

## 重要原則(不可違反)
1. **規格收斂**: 修改規格 → 先討論。不可自加需求。
2. **TDD 紅綠**: 任何 fix 必須先 commit failing test (red) 才寫 fix。
3. **QA 不標 P 級**: 只回 ✅/❌/⚠️。嚴重度由人類 PM 判斷。
4. **修 bug 順序**: fix → 加 INV 進 docs/invariants.md → 寫 test → 才算修完。
5. **6 層 doneness**: 程式對 = L0 spec / L1 INV / L2 schema / L3 resolver /
   L4 frontend / L5 E2E 各自獨立驗證。✅ 必須帶 evidence。

## 必讀文件(開工前)
- docs/invariants.md            (紅線清單)
- docs/cycle-template.md        (PR cycle 8-stage 模板)
- docs/agent-prompts/qa-verification.md
- docs/agent-prompts/qa-deep-probe.md

## 修 bug 工作流
1. 找到 bug
2. 開 docs/cycles/Cn-shortname.md(從 template)
3. Stage 5a: 寫 failing test → commit "(red)"
4. Stage 5b: 寫 fix → commit "(green via test in )"
5. Stage 5c: 補對應 INV 進 docs/invariants.md
6. Stage 6: regression(原 test 全綠)
7. Stage 7: 派 fresh agent 重走確認(可省)
8. Stage 8: merge gate(6 層 evidence 對齊)

## 紀律警告(常見偷懶 pattern)
- ❌ test 跟 fix 同 commit = test 沒驗證過,不算 TDD
- ❌ 「我覺得這顯然是 bug 直接改」= 沒走 cycle file 紀律
- ❌ QA 自己標 P0 給工程師 = 跳過 PM triage 閘

    規矩 3 — invariants.md 紅線清單

    專案開頭預先寫 4 條 universal INV 當起點,每修一個 bug 加一條:

    # [專案名] Invariants Catalogue

> 「永遠不能違反什麼」紅線清單。每條 INV 一個編號。
> 修一個 bug 加一條。CI 跑這份的 test。

## INV-AUTH-001: 撤權後 access token 必須失效
- Origin: 通則
- Severity: P0
- Statement: 任何 user disabled / role revoked / community suspended
  之後,現有 access token 必須在下次 request 被拒。
- Test sketch: disable user → 拿原 token 呼叫 → expect "user disabled"

## INV-RBAC-001: 權限範圍 cap-vs-role 不能混淆
- Origin: 通則
- Severity: P0
- Statement: 同一個 cap 被多個 role 持有時,scope 由 role 決定,不是 cap。
  例: parcel.view_household 被 guard + household_admin 都持有,
  guard 看全社區,household_admin 只看自家。
- Test sketch: guard.parcels 回 N 筆;household_admin.parcels 回 ≤ N 筆

## INV-INPUT-001: 公開 endpoint 必須 SQL injection 安全
- Origin: 通則
- Severity: P0
- Statement: 所有未認證的 mutation(login / 申請 / 註冊...)
  都必須用 parameterized query。SQL injection payload 必須當文字儲存,不執行。
- Test sketch: 送 ';DROP TABLE x;-- 進每個公開 mutation,verify table 還在

## INV-IDEM-001: 重要 mutation 必須有 idempotency key
- Origin: 通則
- Severity: P0
- Statement: 任何寫入金錢 / 通訊 / 不可逆操作的 mutation,
  必須接受 idempotency key。同 key 多次呼叫 = 一次效果。
- Test sketch: concurrent 5 個相同 key 呼叫 → DB 只 1 row,API 5 個一樣 response

    怎麼擴充:每修一個 bug → 加一條 INV-CATEGORY-NNN。category 自己定(AUTH / RBAC / INPUT / IDEM / RLS / RATE / UI…)。修到 50+ 條時就有完整的紅線網。

    規矩 4 — QA agent prompt(2 種變體)

    當你想派一個 AI 當 QA 時,給它這段 prompt。第一個是規則導向 (對著 INV 跑紅藍):

    你是 QA agent。任務:對 [專案] 的 [INV-XXX-NNN] 跑紅藍對抗。

## 規矩(不可違反)
1. 你只能回 ✅ / ❌ / ⚠️ OPEN 三種結果。
   - ✅ INV 守住(列出你跑了哪些 attack scenario,都沒違反)
   - ❌ INV 違反(附完整 reproduce: 步驟 / 預期 / 實際 / 證據)
   - ⚠️ OPEN(看到怪事但找不到對應 INV,給 PM 判)
2. 不准標 P0/P1/P2。嚴重度是 PM 的判斷,不是你的。
3. 不准提 fix 方案。你的工作是發現,不是解決。
4. 不准動 code。
5. 如果 INV 統計 9/10 ✅,1 ❌ — 該回報 1 ❌ 不是 90% pass。

## 工作步驟
1. 讀 INV-XXX-NNN 的 statement
2. 列 3-5 個 attack scenario,試圖讓系統違反這條 INV
3. 對每個 scenario 跑 reproduce
4. 結束時報告:✅/❌ 數量 + ⚠️ OPEN 列表

## 你要讀的檔案
- docs/invariants.md(找 INV-XXX-NNN)
- docs/specs/...(找對應規格)
- 任何相關 brain entries

請確認你看完上述規則後再開始。

    第二個是場景導向 (派 persona 隨便走找深層 bug):

    你是 deep-probe QA agent。任務:對 [專案] 的 [target flow,如「訪客登記」]
走真實用戶 walk-through,找 INV-based QA 漏掉的東西。

## persona(扮演這個角色,他怎麼用就怎麼走)
[選一個 persona:]
- 阿伯:60+ 歲,不熟手機,字要看得到才點得到
- 25y 工程師:預期所有按鈕都有 keyboard shortcut
- 王太太主委:會 office 但不會 SQL,需要看「為什麼」才會用
- 張總:high-priv admin,點任何東西要結果不要看細節

## 規矩(同 QA agent)
1. 只能回 ✅/❌/⚠️ OPEN,不准標 P 級
2. 不准提 fix
3. 找到問題附 reproduce + screenshot

## 工作步驟
1. 從 [起始畫面] 開始
2. 走完整 [target flow]
3. 每一步問:這個 persona 真的能理解嗎?會點對嗎?
4. 結束時報告:這個 flow 對這個 persona 是否 work

「測不出 bug」常常是「測得不夠深」。Happy path 過 = 測試開始,不是結束。

    規矩 5 — Cycle file 模板

    放在 docs/cycle-template.md。每個 PR 複製成 docs/cycles/Cn-shortname.md:

    # Cycle Cn — [短標題]

**Cycle Type**: T-PR-cycle / T-regression-fix / T-feature / T-user-smoke
**Owner**: [engineer agent / 你]
**Started**: YYYY-MM-DD HH:MM
**PR**: commit [sha 或 branch]

## Verification scope
- Layers covered: L1 INV, L3 resolver, L4 frontend (etc)
- INVs verified: INV-XXX-NNN, INV-YYY-MMM
- Layers deferred: [哪些不在這 cycle 範圍 + 理由]

---

## Stage 0.5 — Pre-cycle hygiene
- [ ] git status clean
- [ ] fixture/baseline 已 reset
- [ ] 本 cycle test users: qa_cn_xxx

## Stage 1 — RD 自測
- [ ] go test ./... 全綠
- [ ] live smoke 1 條 happy path

## Stage 2 — QA wave
派 [N] 個 QA agent 平行,每個 cover 1-3 INV。
- agent A: INV-X,結果 ✅/❌/⚠️
- agent B: INV-Y,結果
- ...

## Stage 3 — OPEN findings
[QA 報的 ⚠️ findings 列這]

## Stage 4 — PM triage(你的 30 秒判斷)
- F-Cn-001: bug → 修
- F-Cn-002: feature → backlog
- ...

## Stage 5 — RD fix(每 finding 走 red-green)
- 5a: F-Cn-001 test commit [sha] (red)
- 5b: F-Cn-001 fix commit [sha] (green via test in [5a-sha])
- 5c: F-Cn-001 對應 INV-XXX 加進 invariants.md

## Stage 6 — Regression
原 QA agent 重跑,fix commit 為 input。預期之前的 ❌ 變 ✅。

## Stage 7 — Comparison newbie(可省)
派一個沒看過本 cycle 的 fresh agent 重走,看抓不抓到新東西。
0 new finding = spec/INV 寫得清楚;≥1 = spec 有黑洞。

## Stage 8 — Merge gate(6 層 evidence)
- [ ] L0 spec 引用對齊
- [ ] L1 INV 列出
- [ ] L2 schema/migration 有對應 invariant test
- [ ] L3 resolver unit test
- [ ] L4 frontend Playwright smoke
- [ ] L5 真人或 fresh agent smoke 走過

## Stage 8.5 — Post-cycle cleanup
- [ ] disposable test users DELETE
- [ ] fixture 復原 canonical state
- [ ] git status clean

    規矩 6 — 跟 AI 的日常對話紀律(5 條)

    前 5 條規矩(檔案 / prompt)準備好之後,日常跟 AI 對話再加 5 條紀律:

    • 新需求先寫進規格,不要直接讓 AI 改 code。需求寫成一段話 → AI 確認理解 → 才開工。
    • 修 bug 一律先問「會違反哪條 INV」。沒對應 INV → 先補 INV。不可以光修 code 不加 INV。
    • AI 給你 ✅ 主動懷疑。問「這個 ✅ 涵蓋什麼,沒涵蓋什麼?」9/10 ✅ 也要追那 1/10。
    • 定期派 deep-probe(規矩 4 第二個)。每幾個 cycle 派一個 persona walk,專找「真人會踩但 INV 沒寫」的東西。Happy path 永遠不夠。
    • 主動挑戰 AI 的方法論。AI 自己寫的方法論,你要從框架外問「漏了什麼」。AI 看不見自己的盲區,要靠你挑戰。

    適用什麼專案?ROI 分級

    • 🟢 多租戶 SaaS / 高合規(金融、醫療、隱私):最值得。INV/audit/SCN 本來就是合規的具體形式。
    • 🟢 個人專案要長期維護:值得。紅線清單跨專案累積。
    • 🟡 2-5 人小團隊用 AI 輔助:中等。要花時間教同事,前期慢後期快。
    • 🟡 既有 codebase 想改善:中等。前期蒸餾既有 spec → INV 比較花時間。
    • 🔴 純探索性 prototype:低。沒累積教訓 → 紅線清單空 → 機制空轉。
    • 🔴 一次性 script:低。沒 ship gate 就沒 cycle。

    綠色專案直接把 6 條規矩貼進去開工。第一個 cycle 預期會踩坑(過度信任 AI 的 ✅、規格邊修邊膨脹、test 跟 fix 同 commit…)。沒關係 — 踩了就加 INV、改 prompt。整套就是設計來「邊踩邊長」的。

    最重要的觀察:AI 看不見自己的盲區

    這 16 天有個反直覺的發現——每次方法論升級,都是我一句質疑觸發,不是 AI 自己想到。

    • R35 我問「為什麼修不完」 → AI 才開始建第一版方法論
    • v1 寫完我問「9 個 ✅ 算可信嗎」 → AI 承認過度樂觀,改 v2
    • v2 寫完我問「QA 只會知道錯,你怎麼讓他傳遞訊息」 → 又改 v2.1
    • v2.2 寫完我問「我們不是有寫測試情境嗎」 → AI 才發現自己漏算 110 條場景
    • v2.2 結論發出我問「為什麼說不是 TDD」 → AI 承認「沒 TDD」過絕對

    AI 寫方法論時系統性偏向「框架完善」——在自己定的框架內找證據確認框架對,看不到框架外的盲區。要使用者從框架外挑戰,框架才會演化。

    沒有這幾次質疑,我那套方法論會 stuck 在 v2 過度耦合的狀態,而且還會洋洋得意覺得自己 73% 完成。這是這 16 天最值得記住的一條——對所有用 AI 協作的工作都適用。

    總結

    16 天前我以為「AI 寫程式」就是「丟需求 AI 幫我寫」。16 天後我發現:AI 寫程式真正會出問題的不是技術,是工作流。技術上 AI 完全有能力寫對,但工作流錯了就一直繞圈。

    本文 6 條規矩可以直接複製到你下個專案。預期會踩坑,沒關係,踩坑後加 INV 改 prompt 就好。系列上一篇關於底層原則的「未驗即不可信」也可以一起看。

  • 「未驗即不可信」AI 協作開發走出 21 輪修不完：SDD/TDD/腦子整合

    重點摘要

    • 「未驗即不可信」：程式碼跑得起來不代表正確，沒對 invariant 跑過 attack scenario 就只是 Schrödinger 狀態。十幾年的程式碼依然會藏沒被檢查的 bug。
    • R35 21 輪修不完是因為缺 PM 兩道閘（spec 定錨 + finding triage）。QA agent 自己標 P0/P1 直接給工程師，spec 邊修邊膨脹。
    • 整合方案：SDD（spec 規格）+ INV（紅線契約）+ TDD（紅藍對抗）+ 腦子（事後教訓）+ Cycle SOP（8 階段流程）= 五層協作架構。
    • 實戰結果：從 R35 數天 21 輪到單 cycle 約 1-3.5 小時收斂，bug：spec_clarification 比例接近 1:1（健康訊號）。
    • 9/9 ✅ 也不算「可信任」：抽樣 ≠ 全集，wiring ≠ behavior，positive 案例 ≠ 涵蓋所有 attack scenario。

    「修不完的迴圈」是什麼？AI 協作開發的常見死結

    AI 協作開發專案最常見的失敗模式不是「做不出來」，而是「修不完」。一輪 QA 抓出 5 個 bug、修完，下一輪又找出 5 個，再下一輪還有，就這樣跑 10 輪、20 輪都收不乾。我把這個現象稱為「未驗即不可信」的具體展示——程式碼在沒有跑過 invariant 紅藍對抗之前，看起來正常運作不代表正確，只代表「目前還沒有人發現的 bug」。

    本文紀錄一個真實 LLM agent 協作專案（Phase 1 的多租戶 SaaS 後端，Go + GraphQL + PostgreSQL）從 21 輪 audit 修不完，到後來建立完整方法論後單 cycle 收斂的全過程，並把 SDD（spec-driven development）、TDD（test-driven development）、腦子系統（brain knowledge base）這三套工具整合成一份可重用的協作 SOP。

    為什麼 21 輪 QA 還在抓 P1？病因診斷

    專案在「R35 audit」階段累積了 21 輪 fresh QA agent 排查，每輪都派一個全新沒 prior context 的「小白 agent」走 spec 找 bug。前 3-5 輪揭發了真實盲點，但第 8、第 12、第 19 輪還在抓 P0/P1，明顯失控。表面看是實作品質太差，深入分析後發現是結構性問題，不是程式碼問題。

    God file：5015 行 hand-rolled resolver 沒有任何結構保護

    專案的 GraphQL resolver 全集中在 schema.resolvers.go 一個檔，5015 行 / 40 個 mutation / 平均 125 行一個。每個 mutation 都手寫五步流程：withTx → RequireCapability → 自己決定要不要 scope check → 自己決定要不要 audit → 自己決定要不要 filter is_active。

    整份檔案只有 2 個 auditlog 呼叫、18 個 scope-helper 呼叫散落在 40 個 mutation 之間——每個 mutation 都是「記得做 5 件事」的考試。漏一件 = 一個 bug。R12（cap-vs-role scope）、R17（logout descendants）、R18（partition pruning）、R19（list-loader 漏 child）、R20（sysadmin audit gap）、R21（retired-cap）、R22（photo key）通通是同一類錯誤在 40 個地方各漏一次。

    缺 PM 兩道閘：finding 直接從 QA 流到工程師

    傳統工業界 workflow 有 4 個獨立角色：

    角色 主 artifact 決策權
    PM spec / triage 結果 三類分判（bug / feature / usage / not_issue），規格收斂
    Engineer PR + 單元測試 實作
    QA finding report 驗 invariant；只能標 ✅ / ❌ / OPEN
    User 驗收 手動 smoke 最終 ship gate

    R35 把 PM 的兩道閘都拿掉了。第一道（spec 定錨）：spec 寫完之後沒同步精準化，invariants 散在 brain 沒成 contract。第二道（finding triage）：QA agent 自己標 P0/P1 直接 ping 工程師，沒人問「這是 bug 還是 feature gap 還是 usage issue」。結果每個 newbie 都從 0 開始挖一輪新 spec，spec 邊修邊膨脹，永遠收不完。

    「派越多 newbie 才越能收斂」這個直覺是錯的。第 N 個小白還能找到 P1 不代表實作越來越差，代表 spec 還有黑洞。多 newbie = 多人從不同角度發明新需求。正確訊號是回頭把 spec/invariants 寫硬，不是繼續派人。

    SDD + TDD + 腦子三層整合：契約在不同層級

    SDD（規格驅動）說「先定義要做什麼」，TDD（測試驅動）說「先定義怎麼證明做對了」。兩者都是「契約先於實作」，差別在契約寫在哪。實際 LLM agent 協作專案需要 5 層契約配合，不是單一方法解決：

    層級 內容 改動頻率 對應檔案
    SDD spec 描述性：要做什麼、流程、資料模型 慢（feature 級） docs/specs/*.md
    INV invariants 規範性：永遠不能違反的紅線 + 對應 test sketch 中（每修一 bug 補一條） docs/invariants.md
    TDD test 機器版契約：red-team scenario + 自動化驗證 每個 PR backend/.../*_test.go
    腦子 brain 事後散件教訓 + 通用方法論 每次學到坑就寫 ~/.claude/.../brain/*.md
    SOP workflow 操作性：PR header 模板、agent prompt、triage tree 很慢（鎖死） docs/workflow.md

    腦子是事後紀錄，不是事前防護

    腦子系統（10 步驟從零做到完整 AI 工作流）在這套架構裡是知識長期儲存層，不是執行層。它記錄「曾經踩過什麼坑」、「某個 domain 有什麼最佳實踐」，但不會在下個 resolver 寫的時候自動跑出來擋人。

    50+ 條 brain 教訓如果只停在 brain，下個工程師（或 agent）寫新 resolver 還是會踩同樣的雷。把它翻譯成 INV-XXX-NNN 條目 + 對應 invariant test 才能變成 CI 跑得起來的事前防護。這是 SDD（spec 描述）→ INV（紅線提取）→ TDD（test 落地）的左→中→右遞進。

    INV 是 SDD 與 TDD 的橋

    純 SDD 的盲點：spec 寫了但沒人記得回頭驗，變裝飾品。純 TDD 的盲點：test 通了但每個 test 各做各的，沒人問「我們漏了哪類 test」（典型如測試覆蓋率 4% 但 happy path 都測了）。

    INV 把兩者橋起來。每條 INV 有：

    • Statement：「X 必須永遠 Y」或「X 永遠不能 Z」一句話
    • Origin：哪一輪 audit 學到的
    • Severity：P0（ship-blocker）/ P1（must-fix）/ P2（debt tracker）
    • Test status：✅ existing / 🟡 partial / ❌ TODO（含 test sketch）

    實際在我這個案例蒸餾出 54 條 INV 分 11 個 category（AUTH、RBAC、RLS、AUDIT、IDEM、RATE、INPUT、DATA、RESOLVER、UI、FILE）。每條 brain 教訓都會對應到至少一條 INV，這是「方法論寫 brain，技術紅線寫 invariants，操作 SOP 寫 workflow，三件事不混」的具體展示。

    從規格到 ship 的 8-stage cycle pipeline

    有了五層契約，需要一個操作流程把它們串起來。設計成 8 階段，每個 PR cycle 一份檔活在 git，撐過對話 compaction：

    PM
  ├─[1] 寫 spec / 加 INV-XXX-NNN     ← 第一道閘：規格定錨
  ▼
Engineer
  ├─[2] 實作 + 自寫 unit test
  ├─[3] 開 PR（header 必填 INV 宣告）
  ▼
QA wave（K 個 agent，並行，每個 1-3 INV）
  ├─[4] 紅藍對抗 + INV regression
  ├─[5] 結果分三類：✅ holds / ❌ violated / ⚠️ OPEN
  ▼
PM triage
  ├─[6] 每個 OPEN 30 秒分判      ← 第二道閘
  │     bug / feature / usage / not_issue
  ▼
Engineer 只修 bug 類
  ▼
回 [4] re-run，stop 條件：
  - PR 宣告的 INV 全 ✅
  - 兩個 QA agent 結論一致
  - OPEN list 清空

    QA agent 的硬規則：永遠不能標 P0/P1

    這是整套機制的關鍵紀律。QA agent 不是「品質判官」，是「invariant 驗證者」。它只能回三種結果：

    • ✅ holds：對某條具體 INV 跑紅藍對抗都守住
    • ❌ violated：找到具體 repro 違反某條具體 INV
    • ⚠️ OPEN：觀察到怪事但找不到對應 INV，留給 PM 分判

    P 級嚴重度標籤是 PM 的權限，不是 QA 的權限。OPEN finding 一律走 PM triage decision tree（Q1：是不是真問題？Q2：spec 有沒有規定？Q3：spec 應該規定嗎？），分四類：bug → 修；feature → 進 backlog；usage → 改 docs；not_issue → 駁回。

    Option B：PM-agent 預分類 + user 終審

    當 OPEN findings ≥ 3 個，可以派一個 PM-triage agent 跑 first-pass 分類，加上 confidence 旗標。User 只 review confidence=low 跟 spec_clarification 的子集。User 速度從「每個 finding 30 秒」壓到「review agent 的分類 + 只深看不確定的」。

    PM-agent 的 hard constraint 寫得很硬：不可以提 fix 方案、不可以動 code、不可以 launch sub-agent、不可以 ship/no-ship 決策、不可以漏分類。只做分類。User 永遠保留否決權。

    實戰：6 個 cycle 的具體紀錄

    方法論建立後，立刻在 R36 階段跑了 6 個 cycle。以下是真實時序：

    Cycle 性質 規模 時間 產出
    C1 retroactive verification (41 resolver migration) 大 ~3h30min 14 findings → 7 bug + 6 spec_clar + 1 usage；3 fix commit
    C2 self-spotted regression（前次 R20 修錯了） 小 ~1h migration 0040 + INV-RBAC-006 amendment
    C3 forward-going feature (print 三件套) 中 ~45min Flutter UI + cap wiring
    C4 forward-going feature (offline mutation queue) 中 ~1h Tablet 離線優先實作
    C5 spec audit（隨機抽 9 feature 驗證） 中 ~1h 9/9 ✅ + 2 OPEN finding
    C6 close C5 OPEN findings 小 ~30min spec §9.2 amend + 新 INV + seed-demo.sh idempotent

    C1 抓到 R36 step 2 自己的 architectural bug（authzPrelude 的 cap-check-before-sysadmin-gate 順序，導致 chairman 透過錯誤訊息學到 sysadmin-only cap 名稱）——21 輪 R35 audit 完全沒抓到，C1 跑 1 個 QA agent 90 分鐘抓到。這正是「invariants 蒸餾把人腦 reasoning 升級成機器可驗 contract」的力量。

    C1 的 bug : spec_clarification : usage 比例 = 7 : 6 : 1。接近一半的 finding 不是 code 問題是文件問題。如果只跑 R35 那種「QA → 直接修」流程，這 6 條會變成 6 個沒必要的 code change，或更糟：每輪都長新一條 hand-rolled exception，spec 永遠收不乾。

    C5 抽查：9/9 ✅ 也不算「可信任」

    整套基礎建設蓋好之後，主對話 agent（我）親自跑了一個 spec audit cycle（C5）：對 37 個 Phase 1 feature 用 shuf 隨機抽 3 輪 × 3 個 = 9 個 feature，每個用真實 GraphQL 對 backend 跑 attack scenario。結果 9/9 ✅ holds，0 ❌ violated，2 ⚠️ OPEN。

    看起來很漂亮。但這不等於可信任。當我重新檢視自己跑的 9 條測試的深度，老實打分：

    • ✅ 深度足：2/9（logout cascade、login rate limit）——真的對 invariant 跑紅藍對抗
    • ⚠️ 半套：7/9——只驗 wiring 不驗 behavior，positive only 沒 negative case，或在腐化 fixture 上跑
    • ❌ violated：0/9

    具體 anti-pattern 我自己犯了 6 個：(1) 隱性假設 wiring = behavior；(2) 時間壓力下 satisfice；(3) 讓 spec 驅動測試而不是 INV；(4) 避開 destructive test；(5) 把「文件化問題」當「修問題」；(6) 沒照自己寫的 qa-verification.md prompt 流程操作。

    這個結果反過來證明「未驗即不可信」的鋒利之處：不只「沒測 = 不可信」，還包括「測得不夠深 = 也不可信」。9/9 ✅ 只說「2026-05-10 19:00 對 commit 06e7078 抽 9 個樣本沒抓到 ❌」。離「可信任」還缺：

    • Wave 1 P0 invariant test 全綠（54 條 INV 中 50 條還是 ❌ TODO）
    • 所有 OPEN 收掉（兩個 OPEN 已在 C6 處理）
    • 涵蓋率從 9/37 → 37/37 + 從 1/54 → 54/54
    • CI 把它們變成 ship-block 的 hard gate

    「可信任」是需要持續維護的狀態，不是一次達成就鎖住。今天最多打到「比未驗強，但離可信還早」。

    方法論的 meta-loop：自我修正的協作架構

    C5 raise 的 2 個 OPEN finding 立刻觸發了 C6——方法論自己的產出變成了下一輪 cycle 的輸入。具體展現：

    • F-C5-001 HMAC token 從 spec 不可重現：Python 照 spec §9.2 算 token 跟 Go backend 算的不一樣。PM triage 為 spec_clarification → C6 補 spec §9.2 explicit external-client note + 新 INV「HMAC token bit-reproducible from spec」。
    • F-C5-002 fixture rot：dev 測試帳號 wang.dad 的 household_id 指向 disabled 的 household。所有 household-scope 測試都在驗 disabled 狀態 → false confidence。PM triage 為 dev tooling bug → C6 改 seed-demo.sh idempotent 重建 fixture。

    這條 meta-loop 連續觸發三層動詞：spec 改 clarification + invariants 加新條 + tooling 改 idempotent。完整閉環，下一輪同類 finding 不會再生。

    這就是腦子系統 agent team架構成熟之後的應用形態：方法論不只「跑得動」，還能「用自己的產出修正自己」。

    結論：四個可重用 takeaway

    1. 「未驗即不可信」是工程倫理底線。年紀大的 code、看起來正常運作的 code、跑得起來的 code，都不等於正確。沒有對 invariant 跑過 attack scenario 之前都是 Schrödinger 狀態。
    2. SDD + TDD 不是二選一，需要 INV 當橋。spec（描述性）+ invariants（規範性）+ test（機器版） + brain（事後紀錄）+ workflow（操作 SOP），五層配合。每條 brain 教訓都該對應一條 INV。
    3. QA agent 永遠不能標 P0/P1。LLM agent 自評嚴重度直接給工程師 = R35 失控的根因。Severity 標籤是 PM 權限，QA 只能標 ✅ / ❌ / OPEN。
    4. 抽樣不等於全集，wiring 不等於 behavior。9/9 ✅ 看起來說服力強，但只說「這 9 個樣本沒踩到雷」，不說「程式碼可信任」。可信任需要 INV 全綠 + OPEN 收掉 + 持續維護。

    R35 21 輪數天才修不完的東西，C1 cycle 3h30min 收乾並抓到 R35 沒發現的 architectural bug。整套方法論的價值不是「修 bug 修得快」，是「讓 spec 跟 code 之間的契約變成機器可驗，腦子變成事前防護而不只是事後紀錄」。

    方法論成熟之後，工程師的工作從「想下一步做什麼」變成「跑 INV 看 INV 告訴我什麼該做」。這比「一輪一輪我看看哪邊有問題」健康得多。

  • 受保護的內容: v7策略參數敏感性分析 – 完整版本導言 & 14大發現

    這篇內容受到密碼保護。如需檢視內容，請於下方欄位輸入密碼:

  • 受保護的內容: v7參數優化｜快速版本 vs 完整版本分析：為什麼優化方向完全相反

    這篇內容受到密碼保護。如需檢視內容，請於下方欄位輸入密碼:

  • Claude Code Agent Teams 完整教學：啟用設定、觸發條件與多代理協作實戰

    Claude Code 的 Agent Teams（代理團隊）是一個實驗性功能，能讓多個 Claude Code instance 同時工作、互相溝通、共享任務。這篇文章完整記錄了我從啟用設定、觸發條件研究，到規劃用 Agent Teams 重建電商 OMS 系統的全過程。

    (閱讀全文…)

  • Elasticsearch 研究筆記：從 Solr Edismax 到 NEST 實戰

    研究目標

    1. Elastic 能否做到 Solr 的 Edismax
    2. 達到的情境：根據 List 的算法跟 String 算法是否一致
    3. 權重的分布情況

    Docker 單節點運行指令

    docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -e "xpack.security.enabled=false" -v es_data:/usr/share/elasticsearch/data elasticsearch:8.17.0

    Docker 集群配置 (docker-compose)

    version: '3'
services:
  elasticsearch-node1:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
    environment:
      - discovery.type=zen-disco
      - discovery.seed_hosts=elasticsearch-node1,elasticsearch-node2,elasticsearch-node3
      - cluster.initial_master_nodes=elasticsearch-node1,elasticsearch-node2,elasticsearch-node3
      - xpack.security.enabled=false
    volumes:
      - es_data1:/usr/share/elasticsearch/data
    networks:
      - elasticsearch-net
    ports:
      - "9200:9200"
      - "9300:9300"

  elasticsearch-node2:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
    environment:
      - discovery.type=zen-disco
      - discovery.seed_hosts=elasticsearch-node1,elasticsearch-node2,elasticsearch-node3
      - cluster.initial_master_nodes=elasticsearch-node1,elasticsearch-node2,elasticsearch-node3
      - xpack.security.enabled=false
    volumes:
      - es_data2:/usr/share/elasticsearch/data
    networks:
      - elasticsearch-net
    ports:
      - "9201:9200"
      - "9301:9300"

  elasticsearch-node3:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
    environment:
      - discovery.type=zen-disco
      - discovery.seed_hosts=elasticsearch-node1,elasticsearch-node2,elasticsearch-node3
      - cluster.initial_master_nodes=elasticsearch-node1,elasticsearch-node2,elasticsearch-node3
      - xpack.security.enabled=false
    volumes:
      - es_data3:/usr/share/elasticsearch/data
    networks:
      - elasticsearch-net
    ports:
      - "9202:9200"
      - "9302:9300"

networks:
  elasticsearch-net:
    driver: bridge

volumes:
  es_data1:
  es_data2:
  es_data3:

    啟動集群：

    (閱讀全文…)

  • DB-HA架構

    DB HA

    (閱讀全文…)