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

這份內容是把投影片文字整理成比較口語的講稿版本，保留原本的論述順序，但改成更適合朗讀與簡報講述的語氣。 來源投影片保留在 raw/articles/denny-huang-harness-engineering-2026-06-18.md。

開場

今天我想談一個問題：如果 AI 讓寫 code 變得更快，那我們還需要軟體工程嗎？ 我的答案是：不但需要，而且更需要。

因為 AI 真的把產出速度拉高了，但也同時把判斷、邊界、交接、驗證這些事情放大成更重要的問題。

為什麼要教 SDLC

先說一個教學上的觀察。以前在教軟體工程的時候，學習者常常技術能力有限，沒辦法真正參與完整專案。 結果就很容易變成照本宣科，UML 畫很多、文件寫很多，可是學生不知道文件是寫給誰看、到底為什麼要這樣做。

所以在 AI 時代，我反而會想反過來教： 先給一個痛點，讓學生直接用 Coding Agent 開工，先體驗沒有軟體工程方法時的混沌。 等他真的卡住了，再回頭讓他感受到 SDLC、CI、測試、維護這些方法的價值。

用真實痛點帶出問題

我這份案例的出發點很簡單： 身為活動主辦者，我常常要找合適的照片，這件事其實很花時間、也很花心力。 像是志工招募貼文要配圖、要展示會議廳空間、要讓照片可以被分享與討論，這些都不是單純「搜圖」而已。

所以我做了一個 SITCON Flickr Photo Finder，讓 AI 幫忙標記照片，讓整個找圖流程變成可用的系統，而不是一堆散亂的人工操作。

CI 其實是跨階段的 Harness

很多人一講 CI，就只想到 push code、run tests、deploy。 但在 AI Native 開發裡，我覺得 CI 更像是一個跨階段的 harness： 它把人的判斷、AI 的產出、系統的邊界，轉成可檢查的工程契約。

所以我會把 CI 放進整個 SDLC 來看，而不是只把它縮成測試。

Request and Analysis

需求與分析階段的 harness，不是幫你寫需求。 它保護的是「問題定義」。

文件入口不能漂移，文件要給對的閱讀者；像 AGENTS.md、README.md、docs 這些地方，要讓人知道這個專案到底在解什麼問題。 另外，重要決策也要有地方可追蹤，像 ADR，後來的人才知道當初為什麼這樣做。

Design

設計階段的 harness，是把架構判斷變成可檢查邊界。

例如：誰是資料權威？哪些值可以跨模組共用？哪些東西可以部署？哪些行為不能放到公開端？ 這些都可以用 schema、validation、artifact boundary、permission boundary 這類方式守住。

Coding

到了 Coding 階段，重點是讓變更進入系統時，不要靠個人環境運氣。 所以執行環境要固定、套件管理工具要固定、依賴版本解析要固定。 先抓語法錯誤和載入階段錯誤，CLI 也至少要能清楚說明自己怎麼使用。

Testing

Testing 階段，我會把它理解成在替產出建立「採用邊界」。 不是每個候選結果都可以直接進到人類使用流程裡。

我們要先確認資料格式規則是不是對的、受控字彙是不是對的；AI 產出的候選能不能進人工審查；哪些檢查不該自動跑，因為它可能會寫遠端、需要權限、或成本太高。

好的測試 harness，會同時定義什麼可以自動通過，什麼必須停下來讓人判斷。

Maintenance

維護階段的 harness，則是把未來會反覆發生的維護行為流程化。

像依賴更新要有固定節奏，變更合併要先驗證再進主線，正式寫入要跟試跑與審查分離，權限交接也要有清單、驗證順序和疑難排解入口。

這樣未來的人才接得住系統。

一個簡單但有用的觀察

AI 讓產出變快，這是事實。 但也因為它變快，所以判斷、邊界、交接、驗證變得更重要。

所以我會說：AI 時代不是不需要軟體工程，而是更需要把軟體工程做對。

收尾

最後我想留下這句話： CI 不只是 testing；它是把整個軟體生命週期裡「應該要做的事」，變成可重複、可檢查、可維護的回饋機制。

這就是我理解的 Harness Engineering。 sha256: 43961e49a9ce9799893f825989fc95fbe55a8dbbdf46f400eed4f70786791d22

原始投影片摘錄見：raw/articles/denny-huang-harness-engineering-2026-06-18.md