「What is a machine?」

我第一次被這句話砸到，是大一第一堂《程式語言》。 我原本以為第一堂課會從變數、迴圈、Hello World 開始——結果老師一上來就在黑板上寫了這句話。

全班很自然往硬體想：電腦、CPU、洗衣機、工廠機具。 但那堂課的重點其實不是要我們背一個定義，而是要我們開始用「工程師的眼睛」看世界：你在打造的東西，到底是什麼？

多年後，我又在《三個傻瓜》（3 Idiots）裡再次撞到類似的提問（而且那種「像第一堂課一樣」的氛圍特別強）。那一刻我突然頓悟：

這句話不是哲學題，它是工程的地基。

因為一旦你回答得出「什麼是 machine」，你就能開始做真正重要的事：把混亂的問題，變成可控、可驗證、可組裝的系統。

1) 我後來最愛用的 machine 定義（很無聊，但很強）

我現在最常用的定義其實超樸素：

Machine = 一個有邊界的東西，吃進 input，吐出 output。

這個定義之所以強，不是因為它漂亮，而是因為它會逼你追問「契約」：

• 哪些 input 是允許的？哪些不允許？
• output 應該長什麼樣？至少要符合哪些條件？
• 出錯時會發生什麼？會明確告訴你嗎？
• 你要怎麼檢查它是不是照規則運作？

拿日常的 machine 來說，咖啡機之所以「可靠」，不是因為它很聰明，而是因為它很守規矩：你按濃縮（input），它就出濃縮（output）；沒水就亮燈或停機；不會突然開始跟你聊天。

守規矩，才是系統能擴張的原因。

2) 為什麼這句話在 AI 時代突然變成生存技能？

因為很多人用 AI 的方式其實像在許願：

• 「我說清楚了，你應該懂吧？」
• 「你這麼強，應該不會亂掰吧？」

但 AI 最麻煩的是：它就算不確定，也可以「講得很像真的」。

所以真正的問題不是 AI 會不會產出，而是：

它的 output 能不能被限制？能不能被驗證？能不能回歸？

如果不能，你就很難放心把 AI 放進任何需要長期運作的流程：客服回覆、財務整理、內容發布、甚至自動化工作流。

3) SDD：Spec-driven development（規格驅動開發）

我把這種做法叫做 SDD：Spec-driven development。

它的核心想法很簡單：

• 先寫清楚規格（spec）：你要的 input/output 是什麼、邊界在哪裡、什麼情況算失敗
• 讓系統圍繞規格運作：不符合規格就不要往下走

很多人以為規格只是文件，但在 SDD 裡，規格更像「方向盤」或「交通號誌」：

• 綠燈：符合規格 → 允許通過
• 紅燈：不符合規格 → 拒絕、重試、或請人處理

你不靠感覺放行，你靠規格放行。

4) TDD：把規格變成測試，讓 machine 的邊界變硬

如果 SDD 是「規格驅動」，那 TDD（測試驅動開發） 就是把規格變成可執行的守門員。

你可以把 TDD 想成：我不跟 AI 辯論「你懂不懂」，我只問你「有沒有通過條件」。

對一般人來說，這很像餐廳出餐的檢查清單：

• 這道菜是不是我點的？
• 有沒有漏配料？
• 有沒有放到我明確說不能放的東西？（例如過敏）
• 如果缺料，能不能清楚告訴我「做不了」，而不是硬做一個假菜端上來？

把它套到 AI 上，意思就是：你可以要求 AI 的輸出至少要符合幾個「不可妥協的條件」，例如：

• 必須用固定格式（例如三點摘要 / 表格 / 條列）
• 必須只回答你允許的範圍（不越權、不亂承諾）
• 必須標註不確定時的處理方式（不知道就說不知道、或要求補資料）

TDD 不是拿來證明 AI 很神；TDD 是拿來限制 AI，讓它變得可控。

5) 精密系統不是一台超級機器，是很多台可控 machine 的組合

很多人直覺會想：「那我是不是需要一個更聰明的 AI？」 但工程上更可靠的方向通常是反過來：

把大問題拆成很多台小 machine，每台只做一件事，input/output 清楚、能驗證。

例如同樣是「幫我完成一件事」，你可以拆成：

• 一台 machine：負責把需求整理成結構化清單（輸出格式固定）
• 一台 machine：負責檢查清單是否缺關鍵資訊（缺就退回問問題）
• 一台 machine：負責產生可執行的步驟（步驟需要符合規則）
• 一台 machine：負責執行（只能做白名單允許的動作）
• 一台 machine：負責審核結果（不合格就回滾或停止）

你最後得到的「縝密精細」，不是靠一個巨大又不可控的腦袋，而是靠一堆小 machine 的組合——每一台都守規矩、每一步都可驗證。

結尾：我現在看 AI 的方式

我越來越不把 AI 當成「靈感之神」，而是把它當成 machine 製造機： 與其求它每次都神來一筆，我更在意它能不能穩穩地幫我量產「守規矩的小機器」。 先用規格把 input/output 定清楚，再用測試把邊界鎖住，最後把很多台小 machine 組起來——系統就會變得又細、又穩、又可回歸。

如果你也對這種「把 AI 變工程、把不確定變可控」的思路有興趣，我會在這個 blog 持續寫下去。你可以先把本站加書籤；之後我也會把相關系列整理成一套可直接套用的框架。