小編精選 - 技術文章翻譯 · 07月12日

15年前的《アジャイルサムライ》，在 AI 時代中變得過時的只有「製作成本」這項教誨

前言

15 年前的經典書籍《Agile Samurai》的教誨，在 AI 也會寫程式的時代還適用嗎？讀完之後，我把書中的教誨分成「已經過時的」與「仍然有效的」兩類，結果正如標題所說，切得相當俐落。

《Agile Samurai》（Jonathan Rasmusson 著，原著 2010 年、日文版 2011 年）是敏捷開發入門書中的經典中的經典。只是出版至今已超過 15 年，開發現場已經有 AI Agent 滲入，進入了程式碼、測試、文件都能由 AI 撰寫的時代。

這篇文章就是那次分類的內容。我不打算把它當成書摘來看，而是希望你把它讀成：從與 AI Agent 一起開發的現場感受出發，對這本書的重新詮釋。

預想讀者：正在把 AI Agent（Claude Code / Codex 等）用於開發，並思考該如何組織開發流程的人。即使沒讀過《Agile Samurai》也能看懂，我會盡量這樣寫

前提：什麼是《Agile Samurai》

用 3 行來說明：

一本實踐敏捷開發的入門書，核心是「每週都要交付有價值、而且能正常運作的成果」
因推廣了 Inception Deck（專案啟動時用來對齊認知的工具）而廣為人知
前半段講專案啟動與規劃，後半段則是源自 XP 的工程實踐（單元測試、重構、TDD、CI）

過時的教誨——以「製作成本」為前提的內容

「不管怎樣先寫很多測試」→ 寫測試變得免費了，重點變成品質

本書反覆強調：「危險的地方全部都要測試」「測試要自動化」。在 2010 年，這是一項代價不低的投資。當時本書背後的潛台詞，應該是在打一場「爭取時間寫測試」的戰爭。

到了 2026 年，這場戰爭結束了。只要交給 AI，單元測試就能大量生成，幾乎等於免費。實際上，我的專案在 CI 裡設定了覆蓋率門檻，因此有大量 AI 產生的單元測試。

但新的問題也出現了。那些測試真的能抓到 bug 嗎？ 即使數字上滿足了覆蓋率，也可能只是堆了一堆照著實作走的測試。以體感來說，真正能幫忙把品質守住的，反而是從頭到尾驗證使用者操作流程的 E2E 測試。

「大量撰寫」這件事已經達成了。下一個課題是：如何衡量這些大量測試的偵測力。

「紙上原型」→ 讓 AI 做出可運作的原型

本書建議，為了與使用者對齊認知，可以先用紙畫出 UI 線框稿，試不同設計。目標是「便宜又快速地做出來，拿來當溝通材料」。

現在比起紙，AI 可以更快做出可運作的原型。目標（便宜大量產出溝通材料）不變，只是工具被替換掉而已，是很典型的例子。甚至因為可以直接讓對方摸到實際可用的東西，效果比當年還強。

「估算就是瞎猜」→ 讓 AI 先做一次瞎猜式初估

本書對估算的說法很直接：「估算本來就是瞎猜。」因此它主張用相對大小（Story Point）來估，不要太在意絕對值，並且要快速、輕鬆地做。

既然「反正都是瞎猜」，那把第一次的估算交給 AI 來做就很合理。把最近完成的任務當成基準故事丟給 AI，讓它做相對估算——這正是本書所說的三角測量。人類只要修正那些看起來怪怪的部分就好。

我們團隊也曾討論導入 Story Point，但一直沒真正動手；如果是「先讓 AI 大致估一個」，導入門檻應該會比當年低很多。

「Iteration Zero」→ 變成替 AI 整理流程的日子

書中提到，在正式開始開發前，會先有一段把前置作業完成的期間，稱為「Iteration Zero」。當年的內容主要是整理 repository、build、測試環境。

到了 2026 年版的 Iteration Zero，明顯多了新的項目。像是提供給 AI 的知識檔（CLAUDE.md）、用來固定作業步驟與規則的 skills / hooks、linter / formatter，以及把程式碼規範明文化。這些雖然也是給人看的，但更大的意義在於：它們是決定 AI 輸出品質的護欄。第一天就把這些整理好，後面所有任務都會順很多。

「持續整合」→ 時代追上了，變成標配

第 15 章談到「重視 build」「保持隨時可部署」，老實說現在讀起來會覺得理所當然。GitHub Actions 和 IaC 普及之後，CI 已經不是「努力導入的東西」，而是前提。

這不是書過時了，而是書中的主張完全勝利了。

反而更有效的教誨——「對齊認知」與「確認」

「能運作的軟體，才是進步最重要的衡量標準」

這原本是《敏捷宣言》原則中的一句，本書開頭也有引用。

AI 能瞬間產生大量程式碼。程式碼行數、commit 數、產生的檔案數——看起來像進度的東西暴增。也因此，「只有能運作的東西才算進步」這個標準更顯重要。

書裡的「完成就是完成」也是同樣道理。AI 就算說「已經實作好了」，沒經過實際驗證之前都不算完成。只要你平常就常看到 AI 的說法和實際結果有落差，就會懂這句話的份量。

「不做清單」

在 Inception Deck 裡，我覺得最實用的就是這個。它只是把事情分成要做的、不做的、之後再決定的簡單框架，但到了 AI 時代，卻有了新的意義。

因為製作成本下降了，反而更容易做出多餘的東西。 在 AI 可以一晚生出功能的時代，控制範圍的能力，正變得比實作能力還稀缺。先決定並明文化「不做什麼」，不只是為了人類，也是為了 AI。如果在 Issue 或任務說明裡寫上「不做什麼」，就能避免把實作範圍交給 AI 後，範圍自己膨脹起來。

使用者故事是「對話的約定」

當想到需求時，不急著把細節全寫滿，而是只先寫下大方向，作為「之後再一起談」的約定——這就是本書對使用者故事的看法。

在 AI 已經能大量產出像規格書的文件時，這種做法看起來像反其道而行，但我認為它其實更接近本質。寫得很詳細的文件只會營造「已經達成共識」的感覺，但真正的對齊認知，只能透過對話發生。我自己做副業時，曾經跟實際使用者面對面討論需求、再邊做邊修，結果用這種粗略討論、快速修改的循環，就能做出很不錯的東西。即使到了 AI 能寫文件的時代，面對面溝通的價值也沒有下降。

「在修 bug 之前，先寫一個會失敗的測試」

這是本書修 bug 的做法：①能證明你理解了 bug 的本質 ②能自信地說自己修好了 ③能保證不會再發生。

這一套可以直接當成給 AI 的指示。AI 被要求修 bug 時，很容易在沒真正理解原因的情況下，直接補一個「看起來能動」的 patch。我把這套流程做成了 skills（讓 AI 在處理特定工作時讀取的作業手冊），讓 AI 在處理修 bug 的 ticket 時，必須先調查根本原因，再先寫出會失敗的測試，最後才提出修正方案。只要把流程綁住，AI 修正的品質就會明顯不同。

2010 年是給人類的紀律，到了 2026 年，則可以直接拿來當 AI 的護欄。這是我讀這本書時覺得最有趣的發現。

統一語言

這一章在講：為專案中的用語下定義，並把會話、文件、程式碼、資料庫欄位名稱都統一起來。雖然看起來很不起眼，但在 AI 時代效果會翻倍。

因為只要把術語表放進提供給 AI 的知識裡，AI 的輸出就會立刻變得像這個專案的一部分。 如果用語不夠明確，AI 會用一般用語來命名，結果程式碼庫裡就會累積大量不一致的寫法。和只有人類團隊的時代相比，定義用語的回報變得更大了。

總結：分類結果一覽

教誨2010 年的意義2026 年的意義大量寫測試代價很高。是在爭取時間免費撰寫。重點變成偵測力紙上原型用紙便宜快速做出來溝通用用 AI 大量做出「可運作的東西」來溝通估算（Story Point）由人來做的瞎猜式初估交給 AI 先做一次初估Iteration Zero整理 repository / build / 環境整理 CLAUDE.md、skills、hooks持續整合需要努力導入的東西標配（主張完全勝利）能運作的軟體是進步標準進度管理的紀律防禦 AI 說「我已經實作好了」不做清單範圍管理的工具防止 AI 的範圍暴走使用者故事＝對話的約定比起文件更重要對話在 AI 大量產文的時代依然是核心修 bug 要先寫會失敗的測試人類的紀律把它做成 skills 來約束 AI 流程統一語言團隊共通語放進 AI 知識裡，效果倍增分類完之後，界線非常清楚。

過時的，只有以「製作成本」為前提的教誨。寫測試、做原型、做估算——這些作業成本都被 AI 迅速抹平了。甚至像 CI 這種「主張已經勝利到變成理所當然」的東西，也沒有任何教誨是真的輸了
「對齊認知」與「確認什麼才是真的」的教誨，全都還在一線。能運作的東西才是標準、完成就是完成、對話的約定、不做清單——AI 反而讓這些變得更重要了

而我最大的發現是，本書那些「給人類團隊的紀律」，很多都可以原封不動寫成給 AI Agent 的護欄。先寫會失敗的測試、統一用語、決定不做什麼。這本 15 年前的書，如今仍然很適合拿來當 CLAUDE.md、skills、Issue 說明內容的靈感來源。

帶著「如果是 AI 來做會怎樣？」這個問題重新閱讀經典書籍，比我原先想像的更有收穫。你書架上那些 15 年前的名著，也不妨用同樣的問題再讀一次。下一句該補進 CLAUDE.md 或 skills 的內容，說不定就會因此浮現。