SoloAI｜水電工阿水
最近讀到一個詞，讓我停下來想了很久。
那個詞叫 Harness——馬具。
2026 年 2 月，HashiCorp 創辦人 Mitchell Hashimoto 在一篇名為〈My AI Adoption Journey〉的部落格文章中，首次使用了「Harness Engineering」這個詞。他的意思很簡單：每次 AI 犯錯，不要只修結果，要修系統，讓同樣的錯不再發生。
隨後，OpenAI 的 Codex 團隊發了一篇文章，描述他們如何用 AI agent 寫出超過一百萬行程式碼，全程沒有一行是人手打的。Martin Fowler（軟體工程界的教父級人物）在 Thoughtworks 網站上發表了分析文章，認為 Harness Engineering 是 AI 輔助開發中最關鍵的框架。Anthropic 也發了一篇〈Effective Harnesses for Long-Running Agents〉，討論如何讓 AI 在多輪對話中保持穩定。
所有人都在講同一件事：決定 AI 能不能可靠交付成果的，不是模型本身，是模型外面包著的那套系統。
讀完之後我才意識到——我一直在做的事，終於有了名字。
先說我是誰
我叫建明，朋友都叫我阿水。我的第一份工作是水電工，後來轉做廚具經銷，現在是一間 AI 數位服務公司的創辦人。公司叫 SoloAI（壹智科技），團隊組成是：1 個人類（我）＋ 6 個 AI 成員。
沒有員工、沒有辦公室、沒有投資。就我一個人，加上 Claude、Gemini Pro、NotebookLM，還有一套每天跑著的工作流程。
聽起來可能有點荒謬，但這套架構真的在接案、在交付、在運轉。不是實驗，是生意。
我的七人制架構，就是一套 Harness
Harness 的概念可以拆成六層。讀完定義的時候，我把自己的團隊一層一層對上去，發現幾乎完全吻合。
第一層，迴圈（Loop）。 我的工作流程是：PM 提需求 → CTO（Claude）分析設計 → Developer（Claude Code）執行 → 監督層驗收 → PM 最終確認。每一個任務都走這個迴圈，不跳步驟。
第二層，工具（Tools）。 六個 AI 成員各有專屬工具：Claude.ai 做架構、Claude Code 寫程式、Gemini Pro 一個帳號做策略研究、另一個帳號做視覺設計、NotebookLM 處理大量資料、Cowork 負責任務管理和瀏覽器測試。
第三層，上下文（Context）。 這是我花最多時間維護的東西。我有一份「憲法檔」，記錄了整個專案的狀態、技術棧、每個 AI 成員的職責邊界、近期待辦。每次開新對話，第一件事就是把這份文件餵給 AI。沒有這份文件，再聰明的模型也不知道自己該做什麼。
第四層，持久化（Persistence）。 AI 沒有記憶，每次對話都是全新開始。所以我把所有決策紀錄、任務指令、驗收結果都存在 Google Drive 上，形成一套跨對話的知識庫。任何一個 AI 成員「死掉」（對話結束），下一個接手的都能從文件中恢復脈絡。
第五層，驗證（Verification）。 我有一個專門的「執行監督層」，負責瀏覽器測試、Build 確認、圖片尺寸核對。開發完成不等於任務完成，通過驗收才算。
第六層，限制（Constraints）。 每個 AI 成員都有明確的職責邊界。CTO 不做商業決策，視覺設計不碰策略研究，Developer 不跳過監督層直接交付。兩個 Gemini Pro 分開帳號運作，避免上下文互相污染。限制不是束縛，是讓系統穩定運轉的基礎。
沒有 Harness 的時候，發生過什麼事？
舉幾個真實的例子。
我讓 AI 設計 LINE 圖文選單，後台要求圖片尺寸是 2500×1686 像素。AI 很有自信地交出成品，但輸出的是 1024×765——Gemini 的預設尺寸。如果我沒有驗收機制，這張圖就直接上傳到客戶的 LINE 後台了。
後來我怎麼處理？不是每次提醒 AI「記得用正確尺寸」——那是症狀修復。我把尺寸規格寫進憲法檔和任務指令模板，變成系統的一部分。這就是 Hashimoto 說的 Harness Engineering：每次犯錯，修系統，不修人。
還有一次，我讓兩個不同職責的 AI 共用同一個 Gemini 帳號。結果策略研究的上下文跑進了視覺設計的對話裡，AI 開始在設計稿裡討論商業模式。從那之後，我把兩者拆成獨立帳號，用物理隔離確保上下文不會交叉污染。
這些教訓都不是模型的問題。模型夠聰明，但沒有正確的系統包在外面，聰明就是一匹沒有韁繩的馬。
先設計系統，再選模型
如果你正在用 AI 工作——不管是寫文案、做設計、還是寫程式——我想分享一個最重要的心得：
不要花時間比較 GPT 和 Claude 哪個比較強。把同樣的時間花在設計你的工作流程、建立你的上下文文件、定義你的驗收標準。這些東西加起來，就是你的 Harness。
Harness 不需要寫程式才能建。一份 Google 文件記錄你的工作脈絡，一個固定的工作流程確保每次都走同樣的步驟，一個檢查清單確保交付品質——這些都是 Harness 的一部分。
模型會一直進化，但你的系統才是真正的護城河。
我是一個水電工出身的 AI 創業者。我不會寫程式，但我會設計系統。而 2026 年的 AI 圈告訴我們，設計系統的人，才是真正駕馭 AI 的人。
延伸閱讀與出處
- Mitchell Hashimoto,〈My AI Adoption Journey〉(2026/02) — 「Harness Engineering」一詞的原始出處
- OpenAI,〈Harness Engineering: Leveraging Codex in an Agent-First World〉(2026/02)
- Birgitta Böckeler / Martin Fowler,〈Harness Engineering〉@ martinfowler.com (2026/02)
- Anthropic,〈Effective Harnesses for Long-Running Agents〉(2025/11)
- Aakash Gupta,〈2025 Was Agents. 2026 Is Agent Harnesses.〉@ Medium
