Harness 工程化的學習曲線：從工具選擇到工程思維

工具本身不是起點

看到 walkinglabs 的這個教程時，我注意到它的副標題是「from 0 to 1」。這個措辭很有意思——不是「入門」，而是「從無到有」。入門教程通常假設你已經知道自己要什麼，只是不知道怎麼用工具。但 Harness 這類 CI/CD 編排平台的學習曲線不一樣。

真正的難點不在 UI 怎麼點，而在於你需要先理解「工程化」本身在解決什麼問題。Harness 是一個結果，不是起點。

工程化的層次

這個教程隱含了三個認知層次：

• 工具層：Harness 的 pipeline 怎麼配，stage 怎麼串，artifact 怎麼傳。這是最表面的部分，也是大多數教程停留的地方。
• 流程層：為什麼要這樣分階段？什麼時候該並行，什麼時候必須串行？approval gate 放在哪一步才合理？這需要對你的發佈流程有明確的想法。
• 決策層：rollout 策略怎麼選？canary 還是 blue-green？什麼條件下自動回滾？這涉及對風險和業務目標的權衡。

官方教程通常把工具層講清楚，順便示範一些常見的流程模式。決策層的東西沒人能替你做。

學習的真正成本在哪

我後來決定換一個問題：看完這個教程之後，你的團隊能不能自信地做出工程化決策？

答案取決於你是否真的理解了自己的部署風險。如果你不清楚「現在每次發佈有多少概率出問題」，再好的教程也教不會你怎麼用 Harness。你只會把工具當成一個漂亮的按鈕面板。

這不是 Harness 的問題，也不是教程的問題。你需要選擇：是想學會用工具，還是想建立工程化的思維。前者可以速成，後者需要在實際發佈中積累判斷。

實用的切入點

如果我要推薦怎麼用這個教程：

• 先不要全部跟著做。挑一個你現在最痛的發佈問題——比如說「每次發佈都要手動驗證」或「回滾流程太慢」——然後看教程裡對應的部分怎麼解決。
• 邊做邊問自己：這一步我為什麼要這樣配？有沒有其他方式？成本和收益是什麼？

把你的決策寫下來。不是寫配置，是寫「我們為什麼選擇 X 而不是 Y」。這個文檔比任何教程都更有價值。官方教程提供了一套已驗證的做法，但驗證它是否適合你的團隊，這部分工作沒人能替代。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。

原始來源：https://github.com/walkinglabs/learn-harness-engineering