那天在天瓏聽 Denny 講 Harness，回家想了很久。

昨天去了 GDG Taipei 的六月月會，講題有點挑釁：「AI 世代，有了 Harness，還需要軟體工程嗎？」我是衝著這句去的。

先講我自己。做前端十五年，主力 Vue，從 jQuery 寫到 Composition API。工具換了一輪又一輪，我早就習慣一直追新的。但這兩年 AI coding 起來，我說實話，心裡是有點毛的。如果 AI 連整個專案都能生出來，那我這十五年累積的東西，到底還剩多少價值？我沒答案，去之前也沒有。

講者是 Denny Huang，GDG Cloud Taipei 的 Organizer，也是 SITCON 的共同發起人。他沒有空談，就拿自己做的一個專案——SITCON Flickr Photo Finder——從頭講到尾。聽完我大概有底了：軟體工程不只還需要，在 AI 這個時代搞不好更需要。

Harness 是什麼，他的比喻我記到現在

💡 Harness 是什麼？

字面上是「馬具／駕馭套組」——套在馬身上讓騎手能控制方向的那整組東西：韁繩、鞍具、護欄。

放到 AI 開發這個情境，Harness 就是「讓你能真正駕馭 AI、不被它帶著亂跑的那整套工程實踐」，包含：清楚的需求文件、測試與 lint 規則、明確的設計邊界、可追溯的決策記錄。

白話一句：AI 是馬，Harness 是讓你坐得穩、踩得準、出了事還能回頭看的整套韁繩。

他說 AI 像一匹跑超快的馬。跑得快是好事，但牠也可能更快地把你拖去撞牆，而且常常是那種你當下根本看不出來的錯。Harness 就是套在這匹馬身上的那一整套東西：講清楚邊界的護欄、看得到現在跑到哪的儀表、能把過程記錄下來的感測器，還有一個人坐在裡面隨時可以拉韁繩的中控室。

重點不是把 AI 關起來，是讓人還能駕馭牠。而打造這套東西要靠什麼？不是什麼黑魔法，就是我們從學生時代就在念的那些——需求、設計、寫扣、測試、維護。差別只在於，這個 DevOps 的圈現在轉得比以前快太多，所以每一段的文件跟說明都得寫得更細，AI 才接得住。

他那個專案，我邊聽邊在筆記上記「這個我下週就能用」

痛點很真實。SITCON 在 Flickr 上有兩萬多張活動照片，每次小編要找一張配某個議程的圖，就得一頁一頁往下翻，翻到懷疑人生。所以他做了個 Photo Finder，讓 AI 去標、去搜這兩萬張。

過程裡他怎麼讓 AI 不要亂跑，這幾招我印象最深。

第一，文件先寫，而且分對象。 README 給人看，Documents 給人跟 AI 一起看，agent.md 專門寫給 AI。而且 agent.md 他堅持用英文，因為中文太會被誤讀了——「好喜歡這場趣味喔」到底是真心還是反諷？這點我超有感。我們前端常常 .vue 一開就直接刻，規格全在腦袋裡，從來沒落地過。要交給 AI，那些腦袋裡的東西就得先變成字。

第二，講話要精準，不准模糊。 不准講「新版」「舊版」「現在」，要用版本號。他甚至搞了個類似 Fact Check 的把關，專門擋這種含糊的字，再用 ADR 把「為什麼當初這樣決定」記下來。前端最容易死在哪？就死在「那個欄位」「之前那版」這種話，AI 一聽就歪掉。

第三，需求是逼出來的。 他不真的去訪談一堆使用者，而是叫 AI 換位子——你現在是小編、你現在是設計師、你現在是贊助商、你現在是工程師，各自會吵著要什麼。結果 AI 自己長出一個「購物車式分享清單」的功能，讓小編能挑一批圖丟給別人討論。需求不是想出來的，是被問出來的。

設計階段他用 Mermaid 直接讓 AI 畫流程圖跟狀態圖，不用手刻 UML（他還順便婊了一下學校軟工課，整天叫人畫 UML 畫到飽）。我們前端的元件互動、Pinia 的資料流，其實都很適合這樣畫一畫。

還有一個點戳到我。AI 很愛把重複的東西堆在一起，懶得收斂成共用元件。所以你得在 agent.md 裡白紙黑字寫「請複用既有的元件」。這根本是在講前端的痛——滿地複製貼上的元件我看太多了。AI 不會自己幫你抽 composable，你不講牠就不做。

寫扣的時候，他把規則鎖死。只准 pnpm，不准 npm 跟 yarn，而且要讓 AI 知道為什麼。Linting 這件事他講得最起勁，說超有效，AI 會犯語法錯、會學人類的壞習慣，但只要 lint 一報錯，牠自己就乖乖回去補符號、自己修。對我們來說，ESLint、Prettier、vue-tsc 從此不只是規範，是餵給 AI 的即時回饋。

測試的觀念也變了。以前是人去判斷對或錯，現在你得把「為什麼錯」講清楚，AI 才知道怎麼改。與其浪費 token 讓牠自己翻整包 code，不如把錯誤訊息寫好。他還示範一招統計式抓偷懶：標照片的時候如果一百張都剛好五個人，那大概就是 AI 把好幾張拼在一起一次看完省 token，用報表一抓就抓到，再逼牠重做。後面再接一個 Validator 自動複查，人只要抽樣看那些可疑的就好。換成前端，就是 Vitest 跟 Playwright 的失敗訊息要寫到人跟 AI 都看得懂。

最後一段他講維護，那句話我到現在還在想。他說每開一個新 Session，其實就是在做一次交接。上一段沒好好寫下來，下一個 agent 接手就會一頭霧水，搞不好還把你之前的設計整個推翻重來。以前我們靠 code 自己會說話，讀懂程式就懂在幹嘛；現在 AI 寫 code 快得要命，反而是文件變成最值錢的東西。這個我太懂了，十五年來我接過多少沒人看得懂的舊專案，那種痛不用人教。

他打算怎麼教，我覺得偷學起來放

Denny 要在 SITCON 夏令營辦一場軟體工程日，方法蠻壞的，但我喜歡。第一個小時他只給痛點，不給需求、不給解法，但塞給你一個 AI coding agent，讓你在一團亂裡硬幹。為什麼要先製造混亂？他說人沒痛過就不會覺得一件事重要。等到第二個小時才回頭帶大家反思「剛剛到底發生了什麼」，再講軟體工程。後面繼續加功能，甚至兩組互換專案接著做，逼你面對看懂別人的設計、接別人的爛攤子。

這套搬到團隊裡完全可行。與其一開始立一堆規矩沒人鳥你，不如先讓大家用 AI 裸奔踩一次坑，痛完再導入 Harness，這時候誰都不會反對。

那我呢，十五年前端接下來怎麼辦

聽完最大的感覺是鬆一口氣。我累積的東西沒白費。那些設計模式、邊界怎麼切、錯誤怎麼處理、CI 怎麼接、命名跟規格的龜毛——以前常被當成資深工程師的職業病，現在剛好就是 Harness 的燃料。AI 把打字這件事變便宜了，價值就往上挪：挪到設計、挪到怎麼把話講清楚、挪到能不能把一個含糊的需求翻成 AI 真的跑得對的規格。

所以我給自己列了幾條，下週開始做：

• 開新專案先寫 spec 跟 agent.md，再碰 .vue。把元件契約、資料流、哪些要複用，先寫成 AI 讀得懂的東西。
• ESLint、vue-tsc、Vitest、Playwright 我要當成 Harness 的感測器在養，不是擺著好看的 lint 規則。
• 能用 Mermaid 講的就不要用嘴講。
• 需求階段我要逼自己用換位提問，把使用者、設計、PM 的觀點先吵出來。
• 還有，文件當成第一順位——每開一個新對話，我就當它是一次交接。

過去我說「持續學新東西」，指的是學新框架、新語法。這場聽完我才想通，真正該升級的，是把這十五年的直覺，變成可以驗證、可以追蹤、可以回溯的流程跟文件。讓 AI 站在我肩膀上跑，而不是把我甩在後面看牠的車尾燈。

回到那個問題

AI 世代，有了 Harness，還需要軟體工程嗎？

我的答案是需要，而且更需要。馬跑得快是 AI 的事，跑得對是工程的事。對一個做了十五年、還想再做很多年的前端來說，這不是壞消息，反而是我最近聽到最安心的一句話。

（對了，那天還有個神秘嘉賓講雲端資安、零信任跟資安監控。我本來以為跟主題沒關係，後來想想，AI 跑越快護欄越不能省，其實也是 Harness 的另一面。）

🛠️ 課程精華已濃縮成 Skill 工具，一鍵安裝即可使用，歡迎取用：github.com/HarryFan/harness-engineering-skill