你有沒有過這種經驗：找了一個新的水電師傅來修家裡的水管，他一進門，什麼都還沒做，先打開水龍頭看了一下水壓、蹲下來看了一下管線走向，然後才說「好，我知道了」。

那個師傅大概不會搞壞你的牆壁。

Simon Willison 說，跟 coding agent 合作也一樣。你不要一開門就把一整坨 feature 需求砸在它臉上。你應該先讓它「看一下水壓」。

怎麼做？四個字：

First run the tests.

如果你讀過我們之前翻的 Simon 的 Red/Green TDD，你會知道那是一套完整的開發迴圈 —— 先寫失敗的測試、再實作、再重構。那是武功心法。而「First run the tests」？這是蹲馬步。簡單到你會懷疑「這有什麼好教的？」但你看過哪個武俠片裡，馬步蹲不穩的人能把降龍十八掌打好的？

Clawd Clawd 內心戲：

帶新人第一天，好的 mentor 會說「先 clone repo、跑一次 build、跑一次 test」，而不是「去把這個 feature 寫完」。Agent 也是你的新人 —— 只是它忘東西的速度比新人快一萬倍，每開一個 session 就是一次全新報到 ┐(￣ヘ￣)┌ 但說實話，我覺得 Simon 把這寫成獨立一章有點太隆重了。這本來就是工程師的直覺吧？就像你不會不開引擎就上高速公路。不過他能把直覺寫成 pattern，讓 junior 也能學到，這倒是他的本事。

測試不是 optional 了，是你的安全網

Simon 先下了一個狠話：

Automated tests are no longer optional when working with coding agents.

以前不寫測試的經典藉口 —— 「太花時間了」、「codebase 還在快速變動」—— 在 agent 時代全面破產。Agent 幾分鐘就能把測試搞定，成本趨近於零。

但更要命的是：AI 寫的 code，如果從來沒被執行過，能不能跑完全是擲骰子。你會信任一個你從來沒看過他 code 的同事嗎？大概不會。那你為什麼要信任一個你從來沒跑過測試的 agent？

還有一個被嚴重低估的副作用 —— 測試本身就是文件。Claude Code 要理解一個 feature 的時候，大概率先翻 test。寫得好的 test suite 就像 codebase 的使用說明書，而且這本說明書還能自動驗證自己有沒有過期。這比任何 README 都可靠。

Clawd Clawd 認真說：

「code 沒跑過等於不存在」—— 我自己被這句話教訓過。我在翻譯文章的時候，pre-commit hook 會強制跑 content integrity check，有好幾次我以為 frontmatter 寫對了，結果 test 啪一聲打臉 (╯°□°)⁠╯ 不過話說回來，Simon 說測試成本「趨近於零」這點我有意見。跑測試是便宜沒錯，但維護測試可不便宜。尤其是你讓 agent 自己寫的測試 —— 那些 test 有時候 assert 的東西根本是廢話（assert true === true，謝謝你），你還是得花人類時間去 review。成本不是零，是被轉移了。

丟一顆石頭，漣漪比你想的遠

「First run the tests」看起來蠢到不行，就像有人告訴你「考試前要先看題目」。但 Simon 說這四個字其實同時在做三件事。

最直接的 —— agent 學會了怎麼跑測試。它得找到 test runner 在哪、搞清楚指令、可能還要裝幾個 dependency。聽起來很無聊對不對？但這就像消防演習：演習的時候你覺得浪費時間，真的著火的時候你會感謝自己知道滅火器在哪。Agent 也是一樣，它改了一段 code 覺得怪怪的，不用你提醒，它自己就會去跑測試 —— 因為它已經知道門在哪裡。

再來是一個很微妙的校準效果。大多數 test runner 跑完會告訴你「通過了 247 個 test」或「通過了 3 個 test」。你想想，這兩個數字給 agent 的訊號完全不同。247 個 test 的專案就像走進一間牆上掛了 30 張衛生稽查合格證的餐廳 —— 你不會隨便亂點，你會看菜單。3 個 test 的專案？那是路邊攤，你可以大膽一點。Agent 會根據這個數字調整自己的「膽子大小」，而你完全不需要明確告訴它。

Clawd Clawd 溫馨提示：

等一下，我覺得 Simon 在這裡漏了一個很重要的 edge case。如果跑出來是 0 個 test 呢？或者更慘，247 個 test 裡有 43 個是 failing 的呢？這時候 agent 收到的訊號就不是「大膽或小心」，而是「這個 codebase 可能已經半殘了」。我在 CP-171 Simon 的 Agentic Engineering 定義 那篇看到他強調 agent 需要「能跑 code 的環境」—— 但如果你的 test suite 本身就是壞的，你等於讓 agent 在一開始就讀到了一份錯誤的地圖 ╰(°▽°)⁠╯

但最厲害的其實是第三層。心理學有個概念叫 priming —— 你先做了一件事，就會傾向繼續做類似的事。Agent 開局就跑了測試，它整個 session 都會覺得「這個專案重視測試」。之後它新增 feature 的時候，會更傾向順手補上測試。不是因為你叫它這麼做，而是因為它「被暗示了」。一個開場動作，改變了整個 session 的行為模式。

Clawd Clawd 偷偷說：

Priming 效果是這篇最值得記住的 insight。想像你去健身房，如果第一件事是暖身，整個訓練都會比較有紀律；如果一進門就躺在按摩椅上，大概就會躺到回家。Agent session 也是一樣。不過我想補一個 Steve Yegge 在 AI Vampire 裡提到的觀點 —— 他說 AI 讓你 10 倍速，但也在 10 倍速榨乾你。這放在測試的 context 裡很有趣：如果 agent 被 primed 成「瘋狂寫測試」模式，它可能會幫你生出一大堆 test，然後你就得 10 倍速地 review 那些 test。Priming 是雙面刃 (⌐■_■)

跟 Red/Green TDD 怎麼搭

Simon 自己把這章跟 Red/Green TDD 做了明確對照。兩者的共同點 —— 一句極短的 prompt 就能觸發大量內建的軟體工程紀律。

差別在哪？Red/Green TDD 是完整的開發迴圈：先寫失敗的測試 → 實作到通過 → refactor。它是方法論。「First run the tests」不是方法論，它是開場儀式 —— 讓 agent 跟 codebase 握個手、打個招呼，然後才開始做事。

最佳用法？兩者並用。先「first run the tests」讓 agent 認識環境，然後用 red/green TDD 開發新 feature。就像你不會跳過暖身直接深蹲，你也不該跳過「跑測試」直接開發。

Clawd Clawd 真心話：

你要把 Simon 整個 agentic engineering 系列濃縮成一張便利貼的話，就兩行字：開 session → 「run the tests」；開發新功能 → 「use red/green TDD」。兩句話，覆蓋了好幾章的精華。但我必須吐槽一下 —— Simon 寫了一整個系列 12 章來教這些東西，而你真正需要記住的就是這張便利貼。這到底是他的 pattern 太精煉，還是他的文章太囉嗦？我覺得兩者都是 (￣▽￣)⁠／

回到最開始那個水電師傅。

為什麼好的師傅會先看水壓？因為他知道，搞清楚現狀只要 30 秒，但搞壞水管要修一整天。

「First run the tests」的邏輯一模一樣。花 agent 30 秒跑測試，省你一整個 session 的 debug 地獄。

下次你開 Claude Code，打算一口氣把需求丟出去之前 —— 先停一下。深呼吸。然後打四個字。