AI 工具鏈設計哲學：從 Harness 到 Skill 生態系
核心主張
個人 AI 工作流的成熟路徑不是「工具越多越好」，而是三層遞進：先設計 Harness（行為規格），再選 Skill（執行件），最後建立 生態系（可組織的能力網絡）。跳過任何一層，工具鏈就會退化成工具堆——看起來功能豐富，實際上每次都在重新協調。
FLUX Vault 的工具鏈就是這三層的具體實踐，不是偶然形成的，而是刻意設計的結果。
第一層：Harness 先行
規格決定工具，而非反過來。
大多數人建立 AI 工作流的順序是：看到一個有趣的工具 → 想辦法用它 → 在使用過程中摸索規則。這個順序產生的問題是：工具決定了你能做什麼，你的行為規格則永遠在追趕工具。
Harness 設計反轉了這個順序：先問「我希望 AI 在這個情境下做什麼」，再去找能交付這個行為的工具。具體說，好的 Harness 要能回答四個問題：
- 觸發條件：什麼情境下啟動？
- 輸入：需要哪些前置資訊才能執行？
- 輸出：完成後產出什麼？格式為何？
- 邊界：不碰什麼？止於何處？
FLUX Vault 的 規則檔 本質上就是一份 Harness 規格文件——它不描述工具，而是描述「在各種情境下，AI 應該表現出什麼行為」。Session 開始時的主動簡報、evergreen 筆記的修改授權流程、Codex 任務交接的觸發條件，都是 Harness 設計，不是工具設定。
這一層的核心洞見：在工具之前先有設計。設計是規格，規格是約束，約束讓 AI 的行為可預期、可校準、可傳承。
第二層：Skill 是 Harness 的執行件
找 skill 的正確問法不是「這個 skill 能做什麼」，而是「這個任務的期望行為是什麼，哪個 skill 能交付它」。
林彥廷的「公司組織圖」比喻把這層說清楚了：每個 skill 是一位有明確職責和觸發時機的員工。找 skill 就是招募對應職能的人；組合 skill 就是設計組織分工。這個視角讓選型決策有了清楚的框架——你不需要知道市面上所有 skill，只需要知道「這個任務需要什麼職能」。
Skill 和 Harness 的關係是：Harness 定義了「要有人負責 X」，Skill 是交付 X 的具體執行者。一個設計完整的 Harness 天然地告訴你應該找什麼 skill——例如 FLUX Vault 的 vault-session-handoff skill 就是從「每次 session 結束都需要產出固定格式交接文件」這個 Harness 規格反推出來的，不是先有 skill 再想用途。
FLUX Vault 的 Skill 選型邏輯也遵循這個原則：
| 任務期望行為 | 選用 Skill | 環境 |
|---|---|---|
| Session 結束產出交接文件 | vault-session-handoff | Cowork |
| 課程腳本轉音檔 | elevenlabs-voice-gen | Cowork |
| 知識庫定期清理 | schedule | Cowork |
| 程式碼完成前強制驗收 | verification-before-completion | Claude Code |
| 網頁內容入庫 | baoyu-url-to-markdown | Claude Code |
每一行都是從「期望行為」出發選到 skill，而非從「這個 skill 能做什麼」出發想用途。
superpowers 的 verification-before-completion 和 FLUX Vault 的 Gate Function 規則完全重疊，這不是巧合——兩者都是從同一個期望行為（「宣稱完成前必須執行驗收」）反推出的 Harness 元件，只是一個在 規則檔 裡以文字規則存在，另一個封裝成可安裝的 Skill。這個重疊說明了好的 Harness 設計和好的 Skill 設計遵循同樣的邏輯。
第三層：生態系思維
工具鏈成熟的標誌不是工具數量，而是工具之間的分工是否有組織原則。
生態系和工具堆的差別在於：工具堆是「我有很多工具」，生態系是「每個工具知道自己在整體中的位置，以及什麼情況下不該出手」。
FLUX Vault 的生態系設計體現在幾個地方：
工具分工有明確的角色邊界。Cowork 負責需要判斷與對話的工作，Claude Code 負責可明確描述的執行性工作，兩者不互相越界。這個分工不是能力的問題——技術上 Cowork 也能跑 bash，Claude Code 也能做對話——而是設計選擇，讓每個工具在最適合的情境下出現。
Skill 生態系有兩個層次。Cowork 的 Skill 是對話情境下的能力封裝（session 管理、入庫流程），Claude Code 的 Skill 是執行情境下的行為強化（驗收規則、多代理協作）。兩層各有職責，不混用。
生態系會自我診斷和修復。這是 FLUX Vault 最能說明生態系思維的地方：2026-06-03 診斷發現 58% 的 wiki 零概念連結，同日用 Python script 一次修復 38 篇。這個「診斷 → 識別問題 → 批次修復」的能力，是因為知識庫被設計成「可被機器處理的格式」（本地 markdown + 結構化 frontmatter），而不是人類閱讀用的靜態文件。生態系的健康可以被量化、可以被自動化維護，這是 Notion 等雲端工具做不到的根本原因。
護城河在生態系層，不在工具層。Claude 模型本身是商品，任何人都能用。真正難以複製的是「在你的 Harness 上跑得比預設配置好」的積累——經過校準的 規則檔、延伸方向 的踩坑記錄、跨 session 可傳遞的脈絡——這些是你的生態系，不是工具。
三層的演進路徑
這三層不是同時建立的，也不應該同時建立。
從 Harness 開始：在開始用任何 AI 工具之前，先寫下「我希望它在這個情境下做什麼」。哪怕只是三行文字，也比沒有規格強。
Skill 是 Harness 成熟後的自然產物：當你發現自己在每個 session 都重複解釋同一件事，那件事就應該被封裝成 Skill。Skill 不是「讓 AI 更聰明」，而是「把你已經知道的規格，轉移到工具裡，讓認知負擔降低」。
生態系是 Skill 積累後浮現的結構：當你有足夠多的 Skill，你會開始注意到哪些 Skill 在什麼情境下配合得好，哪些應該分工，哪些重疊了。這個時候你就在做生態系設計了——不是規劃出來的，而是從實踐中長出來的。
FLUX Vault 的工具鏈大約花了三到四個月走完這三層。不是因為技術難，而是因為每一層都需要真實使用的摩擦和失敗才能校準。
結語
「先有規格，再選工具，最後讓工具之間有組織原則」——這個順序在工程設計裡是常識，在個人 AI 工作流裡卻常常被跳過。大多數人從工具開始，而不是從問題開始。
FLUX Vault 的三層設計不是最優解，而是一個可以校準的起點。它的價值不在於現在的狀態，而在於這個設計讓它知道哪裡有問題、可以被診斷、可以被修復、可以持續成長。
這是「活的工具鏈」和「工具堆」的根本差別。