AI 只會加速你已經有的迴路：從豐田生產方式重新理解自由與信任

前言：在豐田的故鄉講豐田

2026 年 10 月的 Tokyo LeSS Conference 上，Odd-e 的 Terry Yin 用一場題為《Freedom and Trust ─ 自由と信頼》的演講，回答了一個很多組織正在問、卻很少人答得清楚的問題：我們怎麼知道自己把 AI 用對了？

他的答案不是「省了多少工時」或「寫了多少程式碼」，而是一句看起來很哲學、實際上非常可操作的話：看團隊是被自己做出來的東西解放了，還是被它綁住了。

整場演講沒有介紹任何一個 AI 工具的功能，也沒有秀任何 prompt。他講的是 1924 年的織布機、豐田的兩根支柱、一盞燈籠的做法。這篇文章把那天的內容重新整理成一篇可以獨立閱讀的文字，並補上我自己的解釋與延伸。副標題是「AI 擴張開發能從豐田生產方式學到什麼」，但讀完你會發現，真正的主題是：AI 不會替你解決團隊的問題，它只會把你已經有的問題跑得更快。

對佛陀說法：為什麼 AI 時代更需要 TPS

Terry 開場先自嘲：在東京講豐田生產方式（TPS），是日文諺語說的「釈迦に説法」，對著佛陀講佛法。但他接著說了一句很誠實的話：TPS 一直對我有幫助，進入 AI 時代後，幫助更大。

為什麼一套 1950 年代為了造汽車發展出來的管理哲學，會在 AI 寫程式的時代變得更重要？他給了兩個前提：

軟體開發是「發現」與「建造」的混合體。 製造業的問題大多是已知的，軟體的問題有一半要邊做邊發現。所以不能照抄 TPS，只能借它的思維方式。
TPS 的思維要「適配」到軟體，而不是「套用」。 後面整場演講都在示範這件事：把 Jidoka、JIT、尊重人這三個概念逐一翻譯成軟體團隊看得懂的語言。

他畫了一條傳承線，說明這不是牽強附會：

TPS（豐田生產方式）→ XP / Agile → LeSS → AI 擴張開發

TPS 啟發了 XP 和整個敏捷運動（Kent Beck 和 Mary Poppendieck 都公開承認過這點），LeSS 則是把精實思考直接寫進框架的大規模 Scrum。AI 擴張開發是這條線的下一站，而不是斷裂。換句話說，如果你覺得 AI 讓敏捷過時了，更可能的情況是你還沒看懂敏捷到底在解決什麼問題。

一個判準：被解放，還是被綁住？

「組織把 AI 用對了嗎？」這個問題，Terry 只給一個判準：團隊被自己做出來的東西解放的程度，大於被它綁住的程度。

這句話的關鍵是「自己做出來的東西」。AI 時代最大的誘惑是產出變得極其便宜：一個下午可以生出十個功能、三十個測試、五份設計文件。但產出不等於價值，產出會變成負債。他列出三個「被綁住」的徵狀：

殘餘的所有權（leftover ownership）：東西做出來了，卻沒有人真正擁有它。不是沒人掛名，而是沒有人理解它為什麼這樣做、改了會怎樣。AI 生成的程式碼特別容易落入這個狀態，因為「寫的人」不是人。
還需要判斷的產出，被當成「已完成」：AI 給你一個看起來完整的東西，但裡面埋著很多它替你做了、而你沒有確認的決定。這些未經確認的判斷被標成 Done，問題只是延後爆發。
無法去拿下一個最高價值的工作：團隊想做下一件重要的事，卻發現先前做出來的東西擋在路上，要先清理、先理解、先修。

他特別加了一句：被綁住 ≠ 承擔責任。這是為了回應一種常見的反駁：「我們當然要維護自己做的東西，這叫負責任。」不對。承擔責任是你有能力處理後果；被綁住是後果處理你。前者是自由的表現，後者是自由的喪失。

投影片上的插圖是三個孩子用繩子拖著一座搖搖欲墜的塔，遠處有一扇亮著的門。塔是他們自己堆的。

判斷密集型工作：生成很便宜，判斷很貴

軟體開發是「判斷密集型工作」（judgment-intensive work）。Terry 的定義是一句話：用判斷去發現，然後把學到的東西編碼進系統。

這裡的「編碼」（encode）不是指寫程式，而是指把一個需要人腦判斷的規則，變成一個不需要人腦也會執行的機制。他用一個極簡的例子說明差別：

寫在文件裡	寫成測試
「清單不可為空。」	空清單 → 失敗。
每個讀到的人都得重新解讀一次：什麼叫空？誰負責檢查？在哪個時間點檢查？	沒事的時候安靜，出事的時候出聲。
規則存在人的記憶和善意裡。	規則存在系統裡。

底下那句是結論：下一個人不必重新發現這條規則。

為什麼這在 AI 時代變得關鍵？因為 AI 把「生成」的成本壓到接近零，但「判斷」的成本一點都沒降。十年前一個團隊一週產出的東西，現在一天就能生出來，可是判斷這些東西對不對的人還是那幾個。如果判斷沒有被編碼進系統，那麼每一份 AI 產出都在消耗同一批人的判斷力，而且是重複消耗：同一條規則，每次都要有人再想一遍。

編碼進系統的判斷才會累積；留在人腦裡的判斷只會折舊。

AI 會加速你餵給它的任何迴路

投影片原文是「AI speeds whichever loop you feed」，日文翻得更直白：AI は、好循環も悪循環も加速させる（AI 讓好循環和惡循環都加速）。

他畫了一張系統思考的因果迴路圖，描述一個很多團隊正在經歷的惡性循環。四個節點依序是：

向 AI 要更多解法的壓力（起點，標成紅色）。老闆說「用 AI 做快一點」、團隊說「先讓 AI 生一版再說」。
壓力增加 → 仍需判斷的產出物增加。AI 生出更多東西，每一樣都帶著未經確認的決定。
產出物增加 → 人和 AI 每次變更的成本上升。要改任何東西，都得先理解一堆沒人真正懂的程式碼和文件。注意他寫的是「人 + AI」：AI 自己改自己生的東西也會變慢，因為 context 變髒了。
變更成本上升 → 每天解決的問題數下降。
解決的問題變少 → 壓力更大 → 回到第 1 步。

這是一個增強迴路（reinforcing loop），每轉一圈都更糟。而且注意：這張圖裡沒有任何一個節點是「AI 做錯了」。AI 全程都在正常運作、忠實執行。惡化的原因不在工具，在迴路的結構。

反過來說，如果你的迴路是「壓力 → 把學到的規則編碼進測試 → 變更成本下降 → 每天解決更多問題 → 壓力下降」，AI 也會把這個好循環加速。工具是中性的加速器，方向由系統決定。這也是為什麼他說「怎麼知道用對了」的判準不能看工具用量，只能看團隊是否更自由。

自由 vs 信任，是一個假的兩難

投影片上畫了一座歪斜的天秤：左邊是一根羽毛（自由），右邊是一把鑰匙（信任），鑰匙那邊沉下去。文字是兩個互相指責的問句：

給自由，就不敢託付真正重要的工作？ 讓團隊自己決定怎麼做，但大案子還是得經理盯著。
託付重要工作，就要管到每一步？ 把大案子交出去了，但每個決定都要回報、每個步驟都要審。

大多數組織在這兩端擺盪，而且 AI 讓擺盪更劇烈：有人主張「AI 這麼強，放手讓團隊用」，有人主張「AI 這麼不可靠，每一行都要 review」。Terry 的回答是：為什麼我們非得二選一？

接著他講出整場演講的核心命題，值得整段引用：

TPS 展示了一個系統如何持續把學習轉化為約束，讓更大的自由變得負責任；再用那份自由去產生下一輪學習；而更深的託付、乃至相互信任，就建立在這之上。

拆開來看有三層：

學習變成約束。 每次踩到坑，不是寫一條「以後要注意」的提醒，而是做一個以後踩不到的機制。
約束讓自由變得負責任。 因為已知的坑都被機制擋住了，團隊可以放心在剩下的空間裡自由嘗試，不必擔心犯老錯誤。
自由產生下一輪學習，學習再變成約束。 這是一個飛輪，轉得越久，可以託付的範圍越大。

所以約束不是自由的反面，約束是自由的地基。信任也不是一種態度或文化口號，而是這個飛輪轉了幾圈之後的自然結果。

兩間房子，不同層次

在進入兩根支柱之前，他先釐清一個常見的混淆。「豐田之家」有兩個版本：

TPS 之家	Larman & Vodde 的精實思考之家
豐田 1998 年 TPS 手冊的結構，常見的 Cho house	《Scaling Lean & Agile Development》圖 3.1（2009）
屋頂：最佳品質、最低成本、最短前置時間	屋頂：可持續的最短前置時間、最佳品質與價值
兩根柱子：Jidoka（異常即停）、Just-in-Time（只做需要的）	兩根柱子：尊重人、持續改善
地基：標準作業、平準化、穩定性	地基：經理即教師（managers as teachers）
這是豐田「做東西」的作業系統	這是豐田之道的綜合詮釋，偏向組織與人

兩者不矛盾，只是回答不同層次的問題。Terry 這場演講的主軸用的是 TPS 之家的兩根柱子（Jidoka、JIT），最後再補上精實之家的「尊重人」作為第三根。對 LeSS 的聽眾來說，這個區分很重要，因為 LeSS 的精實思考部分直接繼承自 Larman & Vodde 那間房子。

第一根柱子 Jidoka：自働化保存知識、解放人

Jidoka 這一段的開場只有三句話，卻是整場演講被引用最多的：

生成很便宜，判斷很貴。把我們已經知道的事編碼進去。讓人保有餘裕去體驗下一個問題、理解下一個解法。

最後一句是關鍵。自動化的目的不是把人趕走，而是把人從「已知」裡解放出來，去面對「未知」。

織布機的故事

豐田佐吉（Sakichi Toyoda）發明自動織布機的動機，是想讓母親織布的工作輕鬆一點。1924 年的 G 型自動織布機有一個關鍵設計：線斷了，機器自己停。

這件事的意義不在「停」，而在停了之後人可以做什麼。在這之前，織工必須整天盯著機器，因為線一斷，機器會繼續跑，織出一整匹廢布。有了自動停止，一個人可以看幾十台機器，而且不用「看」，只要等機器叫你。

「自働化」這個詞的「働」字多了一個人字旁（ninben），這是豐田刻意的區分：自動化（automation）是機器自己動，自働化（autonomation）是帶有人的智慧的機器。機器知道什麼是不正常，並且在不正常時把人叫來。

盯著織布機，盯著 AI

Terry 用兩組對照插圖把這個故事拉到 2026 年。

第一組：上邊是一個工人托著下巴坐在織布機前面發呆，右邊是一個工程師托著下巴坐在螢幕前，看 Claude Code 的輸出一行一行捲過去。標題是「Watching the loom / watching the AI」。兩個人都在做同一件事：用人的注意力去補機器不會停的缺陷。

第二組：工人聽到停機的響聲，起身小跑過去；工程師頭上亮起燈泡，也跑向螢幕，因為 AI 的 harness 停下來，要求人的判斷。標題是「Called by the stop」（被停機叫來）。

兩組圖的差別不是人有沒有在工作，而是人的注意力花在哪裡。前者花在「監視已知」，後者花在「處理未知」。前者是被 AI 綁住，後者是被 AI 解放。

Dumb：規則變成停機機制

織布機的自動停止是怎麼做到的？答案出乎意料地「笨」：每根經線上掛一個小金屬片，線有張力時金屬片被吊著，線一斷金屬片掉下來，卡住一根橫桿，機器就停了。沒有感測器、沒有邏輯判斷、沒有軟體。規則本身變成了機械結構。

投影片標題用了 Dumb 這個字，是褒義。聰明的機制需要人理解它才能信任它；笨的機制不需要。線在，動；線斷，停。這就是「把判斷編碼進停止的機制」的最純粹形式。

Smart → Dumb → Gone

接著他用木工榫接說明這個演進有三個階段：

階段	木工的例子	軟體的對應
Smart（聰明）	工匠邊做邊判斷：這兩塊木頭怎麼接才對？	人在開發時用經驗判斷；或者 AI 每次都重新推理一遍
Dumb（笨）	榫頭和榫眼的形狀決定了只有一種接法，裝錯裝不進去	規則變成測試、型別、lint、契約；錯了直接紅燈
Gone（消失）	乾脆用一整塊 L 形木頭，連接合處都沒有，沒東西可維護	重新設計讓那類錯誤無法發生；該層抽象消失

大多數團隊卡在 Smart，少數到 Dumb，很少想到 Gone。AI 的風險是讓團隊永遠停在 Smart：反正 AI 很聰明，每次都讓它重新判斷就好。這正是「生成很便宜、判斷很貴」的陷阱，因為每次重新判斷都要有人驗證。

把 stop 建進軟體

翻譯成軟體開發的流程，Jidoka 長這樣：

一個變更進來，不管是人寫的還是 AI 寫的。
經過測試與檢查，這些是「我們已知的規則」。
通過 → 繼續前進。失敗 → 停下來修。
修的時候做兩件事：修根因，然後把學到的東西編碼回測試與檢查。

底下的口號是「Fix the cause. Leave a safeguard.」（修根因，留保護網）。每一次停機都應該讓系統比停機前多知道一件事。如果修完之後保護網沒有變厚，那只是救火，不是改善。

這一段的結論回到自由：已知的規則保護產品，人才有自由去解決下一個真實的問題。 插圖是三個人圍著設計草圖討論，旁邊的螢幕上三個綠色勾勾安靜地亮著，沒有人在看它。

第二根柱子 JIT：託付給人，用手邊的東西想辦法

Just-in-Time 的教科書定義是三句話：只做需要的東西、在需要的時候、需要的量。投影片的例子是豐田自己的：顧客訂 2 台車 → 從貨架拉 8 個輪子 → 補貨 8 個輪子。最低庫存，穩定流動。

但 Terry 對 JIT 的解讀往前多走了一步。他引用他在江畑和正（Kazumasa Ebata）那裡學到的一句話：

ある物で工夫する（用手邊的東西想辦法）

JIT 的本質不是「庫存少」，而是「不預先準備，所以必須信任現場的人在需要時有能力回應」。零庫存是結果，託付是前提。投影片的標題直接寫「JIT entrusts people」（JIT 託付給人），底下那句是：信心來自回應的能力。 當人展現出能應變的能力，託付就有了依據。這一句後面會接回「自由與信任的引擎」。

Pull：把顧客問題切小

在軟體裡，JIT 的第一個翻譯是 Pull：讓顧客的需求拉動開發，而不是用計畫推動。他用一個生活化的例子：三個人吃完晚餐，想「回家」。

不要做一個「回家導航系統」。把它切成：

查下一班電車（紅色標示，先做這個）
查票價
找無障礙路線

切的原則是「一個有用的結果，端到端」。每一刀切出來的都是顧客拿到手上能用的東西，而不是「先做資料層、再做 API、最後做畫面」這種技術分層。這是 LeSS 和 Scrum 一直在講的垂直切片，但放在 JIT 的脈絡下，理由更清楚：技術分層切法會在每一層產生「半成品庫存」，而半成品正是 TPS 最想消除的浪費。

再選一次的自由

下一張投影片是同一桌人，手機上已經顯示「下一班：22:45」。然後有人問：「那條路有樓梯嗎？」於是下一個要做的事變成「無障礙路線」。

底下那句是 JIT 在產品開發的精髓：已交付的價值留著，後面的 story 保持「未開始」。

這句話有兩個意思。第一，做完一個 story 就是真的完了，它產生了價值、留在產品裡。第二，還沒做的 story 不要先碰，連設計都不要先做。因為只有「未開始」的東西才保有自由：顧客用了 22:45 這個功能之後，可能想要的下一步跟你原本排的優先序完全不同。預先做的東西會變成庫存，庫存會綁住你，你就失去了再選一次的自由。

這和 AI 的關係很直接：AI 讓「順手多做一點」的誘惑變得極強。反正生成很便宜，先把後面三個 story 都生出來放著吧？不，那是用便宜的生成換昂貴的判斷債，而且順便賠上重新選擇的自由。

CI 是一種實踐，不是一套系統

這張是全場最辛辣的一張。投影片只有一句話：

一台持續整合沒人擁有的分支的 CI server，只是掛了綠燈的庫存。

插圖是一個人站在一座用木箱堆成的金字塔前面，塔頂亮著一盞綠燈。

很多團隊以為「我們有 CI」等於「我們在做持續整合」。不是。持續整合是一種實踐：每個人每天把自己的改動整合進主線，讓衝突在小的時候就被發現、被解決。CI server 只是這個實踐的工具。如果你有二十條活了三個禮拜的分支，每條分支的 CI 都是綠的，那你擁有的不是持續整合，而是二十份看起來健康、實際上互相不知道對方存在的庫存。綠燈不代表流動，綠燈只代表這份庫存自己沒壞。

這一條和 Jidoka 那段的「盯著 AI 跑」是同一種病：有工具的外形，沒有實踐的本質。 AI 時代這個病會加重，因為 AI 可以同時開十個分支、各自跑綠，看起來無比健康。

讓共享的產品拉動協作

最後一張 JIT 的投影片是一幅燈籠工坊的畫。左邊一個人想著「我要一盞燈籠」。中間兩組人各自工作：上面一組有一個 AI 機器人參與，下面一組是三個人。他們的工作在同一條時間軸上標成 A、B、A、C。當第二個 A 和 C 撞在一起（紅色叉叉），兩組人被拉到同一張桌子前，一起解決，然後燈籠亮了。

底下的口號：持續整合，即時協作（Integrate continuously. Collaborate just in time.）。

重點在「拉動」這個詞。協作不是排程出來的（每週三下午跨團隊同步會），而是被共享的產品在需要時觸發的。因為大家都持續整合到同一個主線，衝突會在最小的時候浮現，這時候相關的人（和 AI）才聚在一起。這是 LeSS 裡 feature team 共享一個 codebase 的理由，也是 JIT 的「只在需要時」用在協作上的樣子。多團隊、多 AI agent 同時開發的時代，「共享產品拉動協作」比「事先協調分工」更能規模化，因為協調的成本會隨人數和 agent 數平方成長，而整合的成本是線性的。

自由與信任的引擎

講完兩根柱子，Terry 用一張因果迴路圖把它們接起來。開場那座歪斜的天秤，在這張圖的底部回到了平衡：左邊的羽毛換成了一台織布機的停止裝置，右邊的鑰匙換成了一個榫接木塊。

自由與信任的引擎 · 5 個節點、7 條因果箭頭

紅色的兩個節點是「自由」和「信任」，中間那條路經過「能力」和「信心」；兩個標了 // 的箭頭，是整個迴路裡不能催的地方。

逐條箭頭解釋：

Jidoka → 學習與改善的自由（+）。已知的規則被編碼進測試與程式碼，人不必再盯著已知的坑，就有餘裕去學新的東西、改善舊的做法。
自由 → 解決真實問題的能力（+）。有餘裕做的人，才會長出解決真實問題的能力。被綁住的人只會長出救火的能力。
能力 → 託付下一個問題的信心（+，需要時間）。 這是第一個「//」。看到團隊解決了真實問題，管理層對團隊的信心才會增加，但這不會發生在一次 sprint 內，要累積好幾次。
Jidoka → 信心（+）。一條直接的捷徑：就算團隊能力還沒被看到，只要已知的規則有系統在守，管理層也比較敢放手，因為最壞的情況被擋住了。
信心 → Just-in-Time（+）。有信心才會真的託付，才會讓團隊「用手邊的東西想辦法」去回應真實需求，而不是事前規劃到死。
JIT → 能力（+）。被託付真實工作的人，能力長得最快。這是迴路的回饋：託付本身就是培養。
自由 → Jidoka（+，需要時間）。 第二個「//」。自由的學習產生新的規則，新的規則再被編碼回系統。這也要時間，因為「學到了」和「寫進測試了」之間隔著一段紀律。

兩個「需要時間」的標記，是這張圖最容易被忽略、也最重要的部分。它們解釋了為什麼信任不能用宣告或 KPI 速成，為什麼導入 AI 之後產能不會立刻翻倍：工具可以瞬間到位，但信心和規則的累積是人的時間尺度，不是機器的時間尺度。想跳過這兩個 //，就會回到前面那個惡性迴路。

第三根柱子尊重人：造物即育人

Jidoka 和 JIT 是「做東西」的兩根柱子。演講的最後一段把 Larman & Vodde 那間房子的「尊重人」（Respect for People）拉進來，作為第三根。副標題是一句豐田的老話：モノづくりは人づくり（造物即育人）。

插圖是兩幅連續畫面：左邊一位老師傅在旁邊比手勢，年輕人自己動手做燈籠框；右邊那位年輕人已經在教下一個人，桌上多了一台筆電。底下只有一句話：培養能自己思考的人。

這句話在 AI 時代的分量比以前更重。如果 AI 可以生成所有東西，組織很容易得出一個結論：我們不需要那麼多會思考的人，只需要會下指令的人。Terry 的立場相反：正因為生成變便宜了，判斷變成稀缺資源，而判斷力只能從親手做過的經驗裡長出來。一個組織如果停止培養會思考的人，它的判斷力就只會折舊，AI 再強也補不回來。

持續改善：讓下一次變更更便宜

他挑了 TPS 裡兩個關於換模（changeover）的工具來說明持續改善的方向：

工具	製造業的做法	軟體的翻譯
SMED（Single-Minute Exchange of Die，一分鐘換模）	機器還在運轉時就把下一組模具準備好，停機時間壓到個位數分鐘	在系統還在跑的時候準備好變更：feature toggle、藍綠部署、測試先行
OTED（One-Touch Exchange of Die，一鍵換模）	剩下的換模步驟簡化到一個動作	讓一次部署、一次重構、一次回滾都只是一個指令

底下的口號：讓下一次變更持續變得更便宜。 這是 Smart → Dumb → Gone 在改善面向的延伸：不是把這次的變更做完就好，而是每次變更都要讓下一次變得更容易。AI 時代這一條特別值得警惕，因為 AI 讓「這次」變便宜了，但如果產出的東西讓「下次」變貴，整體是倒退的。

Go-See 在 AI 時代的新意義

最後一張關於人的投影片，是整場最具爭議性、也最誠實的一張。標題是「Go-See 可能意味著走進 AI harness 裡面」。

現地現物（Genchi Genbutsu，Go-See）是豐田的核心原則：要了解問題，就去問題發生的現場親眼看。在 AI 擴張開發裡，「現場」在哪裡？Terry 的答案是：在 AI 的 harness 裡面，也就是那套包著 AI 的工具、規則、檢查和流程。而進入現場的方法分三步，順序不能反：

先自己做一千次。 你沒有親手做過的事，沒有資格判斷 AI 做得對不對。
知道把它鎖死會有什麼後果。 當你把一條規則編碼進 harness（一個 lint 規則、一個 pre-commit hook、一段 system prompt），你同時也鎖死了某些可能性。做過一千次的人知道鎖住了什麼，沒做過的人不知道。
然後才託付給 AI。

插圖是一個人提著燈籠，走進一座巨大齒輪機器的艙門。燈籠是前面燈籠工坊做的那一盞：你親手做出來的理解，是你走進機器時唯一的光源。

這三步直接回應了一個流行的說法：「有了 AI，就不需要懂細節了。」不是的。沒做過一千次的「託付」不叫託付，叫放任。放任的結果就是前面那三個徵狀：殘餘的所有權、未經判斷卻標成完成的產出、被自己做的東西綁住。

結論：三個檢查點，一個問題

演講的結尾回到開場的問題：怎麼知道組織把 AI 用對了？答案沒有變：團隊被自己做出來的東西解放的程度，大於被它綁住的程度。 但這次他多追了一句：我們能把下一個真實的問題交給團隊嗎？

三根柱子各給一個可以拿回自己組織對照的檢查點：

柱子	檢查點	反面的樣子
Jidoka 自働化	學習留在產品裡：踩過的坑變成了測試、型別、檢查	學習留在某個人腦子裡、Slack 對話裡、「以後要注意」的 wiki 頁
Just-in-Time	現在就交付有用的價值，而且保有選擇下一步的自由	做了很多還沒人要的東西，想改方向時發現被庫存擋住
尊重人	人長出自己思考的能力	人變成 AI 的操作員，判斷力隨著用量下降

最後一張投影片只有兩句話，配上封面那隻從掌心飛起的鶴：

打造讓人自由的產品。把下一個真實問題託付給他們。

「讓人自由的產品」指的不只是對顧客，也是對做它的團隊。一個產品如果每次修改都讓團隊更不自由，它就不是好產品，不管它賣得多好。而「託付」是自由的另一面：你只能託付給有能力回應的人，而人只有在被託付的時候才會長出回應的能力。這就是引擎圖上那兩個「需要時間」的箭頭。

延伸思考：這場演講對台灣團隊的意義

聽完之後，有四件事我覺得特別值得台灣的軟體團隊拿回去想。

第一，「掛了綠燈的庫存」是對自動化測試現況最準確的診斷。 很多團隊的 CI 一直是綠的，但那些測試其實沒有在保護任何東西，它們只是證明「這份庫存自己沒壞」。真正的 Jidoka 是：測試在該紅的時候會紅，而且紅了之後有人被叫來。如果你的測試從來不紅，或者紅了大家只會重跑一次，那不是自働化，是裝飾。

第二，「先自己做一千次」是對「AI 讓測試人員失業」最有力的反駁。 探索性測試的價值從來不在執行，而在判斷：什麼該看、看到了代表什麼、要不要停。沒有親手做過一千次的人，沒辦法判斷 AI 生出來的測試是不是在演戲。AI 時代對測試人員的要求不是更會寫腳本，而是更會判斷。

第三，「AI 加速你餵給它的任何迴路」解釋了為什麼很多公司導入 AI 之後更亂。 一個原本就靠個人英雄救火的團隊，導入 AI 之後只會有更多火要救，因為 AI 把「生成未經判斷的東西」這件事加速了。導入 AI 之前，先問自己：我們現在的迴路是好的還是壞的？如果是壞的，AI 只會讓它更快地壞。

第四，這整場演講沒有講任何 AI 工具的功能，卻是我聽過最實用的 AI 導入指南。 因為它回答的不是「怎麼用 AI」，而是「怎麼知道自己用對了」。前者的答案每三個月就會過期，後者的答案從 1924 年的織布機到現在都沒變過：看人是被解放了，還是被綁住了。

本文整理自 Terry Yin（Odd-e）於 Tokyo LeSS Conference 2026 的演講《Freedom and Trust ─ What AI-Augmented Development Can Learn from the Toyota Production System》。投影片引用的來源：豐田 1998 年 TPS 手冊、Larman & Vodde《Scaling Lean & Agile Development》（2009）圖 3.1（CC 授權，via less.works）、織布機照片 Daderot（Wikimedia, CC0）與 Christoph Roser（CC BY-SA 4.0）。JIT 的「ある物で工夫する」解讀，Terry 註明受江畑和正啟發。