Incident-Driven Harness Engineering

Formosa ESG 2026 · 一個專案從零到 v4.8 的真實開發歷程

裸奔期

3 月中 — 3/30

「先讓東西能動」

做了什麼

Chat 規劃 → 口頭交代 Code 做事
Code 做完 commit，沒有 worklog
Cowork 偶爾幫忙更新 Issue
沒有交接協議，沒有狀態追蹤

累積的債

Paul 腦中是唯一的狀態同步機制
Code session 每次開場都要花 10 分鐘重建 context
已完成的事被反覆提醒
→ 還沒爆，但遲早

↓

事故驅動期

3/31 — 4/05 · v3.0 — v3.2

「每次出事就補一條規則」

連環事故

3/31 GitHub API 推 108KB 檔案截斷 main
4/03 刪 dead code 壞了打卡按鈕
4/03 誤診 root cause，信心滿滿但是錯的
4/04 formosa.js 2400 行被 MCP 截斷，誤判「不存在」
4/04 自己寫的報告拿來驗證自己另一份報告
4/05 deploy / LIFF Published 反覆催促已完成項目

長出來的東西

護欄 #1-#7 — 每條背後一個事故日期
worklog 機制 — Code 自動產出，Cowork 消化
驗證優先（v3.0）— 先查再提醒
儀表板 #155 — single source of truth
三原則（v4.2）— worklog 上游 / 線上真相 / 顯式宣告
這階段的特徵：被動反應，一事一護欄

↓

主動防禦期

4/12 · v4.3

「去看看別人踩過什麼坑」

做法轉變

不再只等事故，主動去找業界研究
Chat 搜尋 MAST、KAMI、LiveKit、DevOps.com 等
從 11 張護欄卡片篩選 4 條高 ROI 落地
再交給另一個 Chat session 點評補強
三個 session 分工：調查 → 篩選 → 點評

長出來的東西

護欄 #8 錯誤雪球效應 — 上游判斷預設未驗證
護欄 #9 善意過度幫忙 — 不確定就說不確定
護欄 #10 終止條件 — 連敗 2 次就停
護欄 #11 Propose-then-Commit — 不可逆四步走
不可逆操作清單 · 自我檢查第 4 問
從「出事才補」變成「預防尚未踩過的坑」

↓

結構化期

4/12 · v4.4 — v4.6

「光有護欄不夠，要有強制檢查點」

關鍵洞察

護欄是「應該怎麼做」，但沒有機制確保真的做了
護欄靠自律，機制靠結構
需要在流程的頭尾各裝一道閘門

長出來的東西

Exit Gate — 結案強制確認，防漏出
Reconciliation — 開場自動對帳，補漏進
Task Sizing S/M/L — 讓接手方知道要花多久
模型建議 — 告訴接手方用什麼模型做
Integration Checklist — 改動影響範圍檢查
從「規則集」變成「流程架構」

↓

自我治理期

4/12 — 4/13 · v4.7 — v4.8

「治理工具本身也需要被治理」

Meta 事故

4/12 SKILL.md 停在 v4.1 整整兩週
AI 的行為已經演進到 v4.6，但磁碟上的定義還是舊的
治理框架沒有治理自己 — 決策蒸發反模式

4/13 /track/sync 漏裝 geofence
新 endpoint 沒繼承舊 endpoint 的防護
防護不是共用 middleware，是 copy-paste

長出來的東西

護欄 #12 Skill 版本同步閉環
改行為 → 改檔案 → bump 版本 → exit gate 確認

護欄 #13 新 endpoint 防護繼承
Integration Checklist 強制檢查防護繼承

Harness 開始治理 Harness 自己
這是系統成熟的標誌

↓

自動化期

4/12 起 · Phase B-C

「人不該是最脆弱的環節」

下一步方向

batch-update.yml — Cowork 寫 JSON 觸發 GitHub Actions 批次更新 D1
reconcile.yml — 定時掃描 D1 vs GitHub，自動補齊不一致
Worker changed_by — 每筆狀態更新帶來源標記
D1 audit 欄位 — status_changed_at + status_changed_by

目標：把人從狀態同步迴圈中解放出來
Paul 只需要做「決策」和「不可逆操作」

終局形態

事故 → 護欄（行為約束）
護欄 → 機制（結構保證）
機制 → 自動化（降低人力依賴）
自動化 → 自我治理（系統治理系統）

人類從「狀態搬運工」退到「決策者 + 看門人」
這就是 Harness Engineering 的成熟曲線

迭代飛輪

事故發生

Postmortem

護欄 / 機制

寫入 Harness

所有 Session 繼承

↻ 每一輪讓整個系統比上一輪更難出同類事故

Harness 成熟度光譜

工具接線

Phase 0

MCP 接上、session 能跑

狀態管理

Phase 1

worklog + 儀表板 + 三原則

Context 品質

Phase 2

護欄 + 信心等級 + 不可逆清單

錯誤恢復

Phase 3

Exit Gate + Reconciliation 雙閘門

自我治理

Phase 4-5

版本同步閉環 + 自動化 + audit trail

這張圖在說什麼

Harness Engineering 不是一次設計完的。它是從事故裡長出來的有機體—— 每一條護欄背後都有一個日期、一個故事、一個「下次不要再這樣」的教訓。系統成熟的標誌不是「護欄很多」，而是「harness 開始治理 harness 自己」。終局目標是讓人類從狀態搬運的苦力退到決策者的位置—— 只在不可逆操作和方向性決策時介入，其餘全部由 harness 自動處理。