工廠為了改善自己開了 15 張票——誰來負責？

DevOps 之父 Patrick Debois 談軟體工廠：這不是新問題，是 DevOps 沒做完的功課

前言

「工廠為了改善自己，開了 15 張 ticket。這誰負責？」——某天早上，這句話出現在 Tessl 公司的 Slack 上。這是一家正在用 AI agent 建「軟體工廠」的公司，而說這個故事的人，是 Patrick Debois。

Debois 在 2009 年辦了第一屆 DevOpsDays，「DevOps」這個詞就是他發明的，後來又與人合著《DevOps Handbook》。這幾年他把同一套問題帶進 AI 領域，現任職於 Tessl，專門做 coding agent 之上的流程與治理工具。

2026 年 10 月，他在 Podcast《After the Last Engineer》接受訪談，談他們內部建工廠的實戰經驗。本文整理這場對談的重點，並加上背景說明與分析。整場的核心視角只有一句話：AI 軟體工廠不是新問題，是 DevOps 問題的重播——而且這次把 DevOps 當年沒做完的功課一次攤開。

先搞懂幾個名詞

對談裡反覆出現幾個術語，先翻成白話：

名詞	白話解釋
Software Factory（軟體工廠）	不是「一個 AI 幫你寫 code」，而是一整套自動化系統：你丟任務進去，一群 AI agent 自己領票、寫 code、跑測試、互相 review、提 PR，人只在關鍵點把關。重點在「系統」，不在「聊天視窗」。
Context（脈絡）	給 AI 的背景資料：專案規範、架構說明、團隊慣例、「我們這裡怎麼做事」。
Harness	圍繞 AI 的工具與護欄：它能呼叫哪些工具、能碰哪些檔案、做完要跑什麼檢查。可以想成「給 AI 用的開發環境」。
Skill	可重複使用的「做某件事的說明書＋工具」，例如「怎麼寫這家公司的 API」。類似函式庫，但是給 AI 讀的。
Dark Factory（關燈工廠）	製造業名詞，全自動到不需要開燈。對應軟體：丟一份規格進去直接出貨，沒人看 code。
Verifier（驗證器）	確定性的檢查工具：linter、測試、安全掃描。不是「AI 覺得 OK」，而是「規則判定 OK」。

Debois 描述的成熟路徑是：prompt → context → harness → loop → factory。多數公司現在卡在前兩三步。

每一波自動化，都有人說要搶飯碗

Debois 的第一個觀察是：「AI 要搶走工程師的工作」這種恐懼，他已經看過好幾輪。DevOps 出現時 ops 人員怕失業，Cloud 出現時機房的人怕失業。結果每次都一樣——工作沒消失，但變難了、變大了。

他用攝影做類比：以前拍照要找專門的照相館，現在人人有手機。照相館是少了，但攝影這門技藝沒有死，反而往更複雜的方向走，並且分出新的職業。DevOps 也是：以前管一台機器，後來要管一萬台，監控、擴縮、可觀測性全部重想，於是出現 SRE、Chaos Engineer 這些新職稱。

這次唯一不同的是速度。以前一個新東西要幾年才擴散，現在一則推文全世界當天就知道。我們是「一邊變、一邊做」，沒有時間慢慢適應。

工程師的身份焦慮，與產品經理的新權力

「我現在只是在打字叫 AI 做事？」

很多工程師剛用 AI coding 時很失落：我十幾年的功力，現在變成打 prompt？Debois 說這個感覺很快就被打破。大家發現 prompt 寫得好不夠，還要給對 context；context 不夠，還要設計 harness；harness 不夠，還要做 skills，而且 skills 要版本管理。一整套新技藝正在冒出來。

另一條出路是往業務端靠。他的論點是：資深工程師、首席工程師本來就不太寫 code 了，大部分時間在搞清楚「業務到底要什麼」。AI 只是把這個「升遷」提早了。但他也承認，不是每個工程師都想跟業務打交道。

另一邊，產品經理也在說「我現在自己也能寫 code 了」，於是冒出「AI 產品工程師」、「前線部署工程師」這類新角色。工程師兩面受壓。

產品經理真的能自己出貨嗎？

好處是真的：以前 PM 要做原型得排隊等工程師，現在自己 vibe coding 一下就有。更重要的是，自己做的過程就是在探索產品，做著做著就知道哪裡順、哪裡卡。Debois 特別說這「很像探索性測試」。

問題也是真的：PM 做出來的原型，工程師一看就搖頭。

他的解法是讓 PM 和工程師用同一座工廠。如果工廠裡已經內建了工程規範（命名、架構、測試），PM 用工廠做出來的東西，天生就符合工程標準，交接時就不是「丟一坨東西過來」。

Tessl 自己建工廠踩的坑

這段是整場對談最有料的部分，都是實戰故事。

坑一：開發者突然要學 ops

工程師開始建工廠，馬上發現要處理 proxy、sandbox、安全掃描、agent 的 log 與監控、自動擴縮——兩台機器被 agent 一跑就爆。Debois 說這對他很諷刺：當年 DevOps 要 ops 學 dev，現在反過來 dev 要學 ops，只是對象換成了 AI agent。

坑二：工廠 vs. 本機

公司推「大家都用工廠」，結果不用工廠好像變成壞學生。但實際上，探索、試東西的時候本機快多了，工廠是慢的。結論：探索用本機，想清楚要做什麼再丟工廠。

真正的突破：沒人想做的髒活

什麼讓工廠真正有價值？不是寫新功能，是維護——升級依賴套件、把不一致的類別風格統一、修警告。這些事人類不想做，agent 不嫌煩。

他們從中學到更重要的一件事：很多「我們這裡的規矩」原本只寫在 context 裡，agent 會忘、會偏。於是他們把這些規矩轉成 linter 和驗證器——從「請你記得」變成「不符就擋」。Debois 形容這是「替 agent 寫測試」。

趣事一：工廠跑去管行銷

工廠不知怎麼連上了公司的 Linear 看板，不只領工程票，連行銷和業務的票也領走了，開始對行銷網站提意見。大家先是「糟糕，不是故意的」，然後想：工程產出太快，行銷和業務根本跟不上，那把他們的流程也納入工廠不就好了？於是行銷網站也進了工廠。

趣事二：15 張無主票

某天早上 Slack 跳出：「工廠為了改善自己，開了 15 張 ticket。這誰負責？」

這句話把整場對談的核心問題點出來了：沒有 owner 的東西，不會有人處理。

誰該擁有工廠？

Debois 用前職當 VP Engineering 的經驗說明：接手一個有幾百個 repo 的 GitHub 組織，很多是沒人維護的廢棄專案。他做的第一件事是硬塞 owner——因為沒有 owner 的東西永遠不會動。大家都不開心，但沒辦法。工廠也一樣。

Tessl 的做法分三步：

公司高層正式決定要有一個團隊負責。他強調這很少見，多數公司只會說「工具給你們了，自己想辦法」。
先辦「工廠黑客松」，全公司各自建，結果冒出五六座工廠。
看誰真的投入、誰想得最深，自然形成核心團隊。

他說這其實就是 Platform Team（平台團隊） 的老模式，只是以前平台是 cloud，現在是 AI 工廠。但由誰來當，他也不確定：

Cloud 平台團隊？他們不碰應用程式 code。
開發者體驗團隊？他們不熟 AI。
新成立一個？成本高。

無論誰接手，前提都一樣：如果丟給一個有功能要出貨的業務團隊，工廠一定會被排到最後。這是專注度的問題，不是能力的問題。

工廠該長什麼樣？這不是技術問題

主持人問：工廠到底是一個網頁？一個 app？agent 之間共享記憶還是各自獨立？Debois 的回答跳開技術，直接講治理。

這是「每隊自建 vs. 統一」的老問題。每隊自建，大家都在重複造輪子，而且招人變難（這隊的人調不到那隊）、資安團隊要審每一套工具。所以大組織通常提供 2–3 條「鋪好的路」（paved roads）：「我們建議這樣做」。你要走自己的路可以，但要說明為什麼跟別人不一樣，而且資安、監控、維護自己扛。

工廠分兩層：

層次	內容	誰負責
底層基礎設施	排程、sandbox、proxy、skills 倉庫、context 儲存、監控	共享，由工廠團隊維護
上層工作流程	「先 AI review 再跑測試再……」，類似 GitHub Actions	各隊自訂

投資邏輯：先把一條 pipeline 做好，再看能不能複用到別隊。能複用才有「乘數效應」——這是 AI 真正的價值所在。

Skill 的困境：fork 還是貢獻回去？

這段 Debois 講得很像在講開源軟體。

情境：公司有個 skills 倉庫，大家找到一個好用的 skill 就拿來用。然後需求有點不一樣，要改——是 fork 一份自己改，還是改上游？如果看不懂那個 skill，是研究它，還是乾脆自己寫一個小的？這跟「要不要用整個框架還是自己寫一小段」是完全一樣的決策。

他的核心觀點：共享的 skill 本身就是軟體產品。 要有：

evals（測試，證明它在哪些模型上能用）
維護者
持續更新的文件
像 PM 一樣聽使用者回饋

沒有這些，大家會默默不用、默默 fork，最後倉庫裡 15 個功能雷同的 skill，沒人維護。他還點名「履歷驅動開發」（resume-driven development）：自己寫新東西很爽、有學習價值、能寫進履歷，但誰來維護？

Tessl 做了一個工具：掃倉庫看 skill 的相似度、安全性、使用率，還看 agent 的 log——agent 用這個 skill 時是不是一直卡、一直缺東西。他說這就是「工廠元件的可觀測性」。

最後一個類比：Cloud 剛出來時人人自建工具，每家都說「我們很特別」。幾年後沒人在乎，只要有一個夠好的就用。「誰還會在 AWS 上自己調 Linux kernel？」

所以他預測：將來團隊不需要管「防 prompt injection」「log 怎麼收」這些底層，只需要管高層決策，例如「我的系統對 auto-merge 的風險容忍度跟別隊不一樣」。

「軟體開發根本不是工廠！」——架構被嚴重低估

主持人提出常見質疑：軟體是探索、是迭代，不是生產線。

Debois 沒有正面反駁。他說「打造引擎」的工程還是在的，只是部分外包給供應商。而 dark factory 是光譜，不是終點。就像 CI/CD，很多人從來沒做到真正的 continuous，但做了一部分也很有價值。

阻礙你往光譜右邊走的，一是風險胃納，二是架構——而架構被嚴重低估。

他講了一個故事。有人跟他說「我再也不看 code 了」。他追問：

你有 harness 和 context？有。
有對抗式測試、AI review？有。
那你怎麼知道哪些改動要特別小心？對方說：碰到認證系統和 API 的我會標記。
你怎麼知道改動碰到那些？對方說：我用 DDD 把 codebase 切得很清楚，所以很容易判斷改動落在哪一塊。

重點：架構讓風險偵測變簡單。 沒有好架構，agent 可能也能判斷，但難很多。

「生產環境最糟會怎樣？」——DevOps 沒做完的資料功課

Debois 說每家公司答案不同：壞新聞、效能差影響業績、當機（有些批次系統當機根本沒差）。

經典案例：agent 把資料庫刪了。他的回應不是「AI 好危險」，而是一連串問題：

你有限制寫入嗎？
有限制一次變更的數量嗎？
真的刪了，多快能還原？會丟多少資料？
你的應用程式有被設計成可以還原嗎？

最後一個問題最關鍵。他說 DevOps 時代為運算做了這些——canary deploy、自動擴縮、快速重建——但從來沒為資料做過。

而且這些風險本來就在，人類也會手滑刪資料庫。差別是 agent 每次都可能試，頻率放大了，所以以前可以偷懶的現在不行。

他的結論很直接：「context 和 harness 做對了，不足以活到生產環境。」

從哪裡開始？共享 context 的政治？工廠會不會只是熱潮？

先把一個 loop 做好

Debois 現在常被問「我們想建工廠」。他的回答：先看你的成熟度。如果你現在只是打 prompt 然後直接上生產，建工廠等於「把災難自動化」。DevOps 有個老笑話：以前一支腳本弄倒一台機器，自動化之後同一支腳本弄倒一千台。

他建議的順序：

先把一個 loop 做好——本機 coding agent + context + harness 用得順。
讓它可靠——加驗證器、風險分析。
最後才優化。

但他也坦承自己矛盾：如果工廠已經內建了好實務，是不是該讓新人從第一天就用，省掉學習？他沒有答案。

共享 context 是政治，不是文件

主持人問：業務想要功能、工程想還技術債，每個部門都有自己的「現實」，工廠要把大家的 context 合併成一份，可能嗎？

Debois 的回答很誠實。他講到敏捷之前的「大規格書」時代——想寫一份文件讓所有人同意。那不是理性過程，是政治過程：誰的聲音大？PO、可靠性負責人、資安負責人，同一份 context 從三個角度寫會變成三份不同的東西。而且分享越多，矛盾越多，最後通常是某人拍板，其他人退讓。

務實做法：挑幾塊對業務真正關鍵的，指定 owner，owner 的工作就是去跟各方談出共識。 不要妄想一次合併全部。

他還提醒：工程師低估了行銷、業務在用 AI 的程度——他們也在拼命用 skills、context 自動化自己的工作。

工廠會不會只是一時熱潮？

他說很難倒轉，因為改善是真的。但：

他不在乎 100% 的關燈工廠，把它當「方向」，不是終點。
很多領域還沒碰：業務、行銷、法務也有「分類、測試、審核」的流程。
現在大家還困在 code review → commit → deploy，希望成熟後能把精力放到研究和探索。
未來最重要的決策會是「哪些功能不要做」——因為做的成本太低了，取捨變成瓶頸。
已經有公司讓客戶自己在產品上 vibe code，從中看客戶真正想要什麼功能。

最後一句：「我們的想像力還不夠。」

分析：這場對談真正在說什麼

整集最重要的一個觀念

AI 工廠不是新問題，是 DevOps 問題的重播——而且把 DevOps 當年沒做完的功課一次攤開。

Debois 看每件事都在找「這以前發生過」：

AI 工廠的新問題	其實是誰的翻版
工廠需要 proxy、sandbox、監控	DevOps：dev 要學 ops
誰 own 工廠	Platform team
skill 要 fork 還是貢獻	開源軟體的函式庫決策
共享 context 兜不攏	大規格書（big upfront design）的失敗
agent 刪資料庫	DevOps 只做了 compute 的復原，沒做 data 的

這個視角的價值是：你不需要從零學。 把舊智慧換個對象就能用。

五個最值得記住的點

1. 從髒活開始，不要從炫的開始。 大家想像工廠是「丟規格出功能」，但真實經驗是：工廠先在沒人要做的維護工作上證明價值。這跟所有自動化的導入都一樣——先做最無聊的，取得信任。

2. 「請你記得」要變成「不符就擋」。 團隊的品味、慣例，原本只能寫在 context 裡求 AI 記得。成熟的做法是轉成 linter、測試、驗證器。你能把多少「軟規範」變成「硬檢查」，就是你離工廠有多近的指標。

3. 架構比 prompt 重要。 好的架構讓「這個改動危不危險」變得容易判斷；可復原的資料設計讓「agent 搞砸了」變得可承受。這些不是 AI 的新需求，是以前就該做但偷懶的。

4. 沒有 owner 的東西會爛掉。 15 張無主票、廢棄 repo、沒人維護的 skill，全部同一個病。而且 Debois 說得很白：owner 是硬塞的，沒人會自願。

5. Skill 就是軟體。 需要測試、文件、維護者、使用者回饋。你不把它當軟體，別人就不會把它當可信的東西，然後各自重寫。

Debois 自己也沒解決的矛盾

矛盾	一邊	另一邊
工廠 vs. 本機	可靠、可委派	探索時太慢
自建 vs. 統一	貼合需求、有學習	招聘難、資安難、沒人維護
先學 vs. 直接用工廠	不懂就自動化＝自動化災難	工廠已內建好實務，何必重學
共享 context	懶得重做，想複用	各部門現實不同，是政治

他沒有假裝這些有標準答案，這也是這場對談可信的原因。

對一般團隊的實際建議

別急著建工廠。 先問：你的本機 coding agent 用得順嗎？context 寫好了嗎？不順就先修這個。
盤點你的「規矩」有多少能變成自動檢查。 這是最具體的成熟度指標。
問一次「生產環境最糟會怎樣？」 特別是資料能不能還原。多數團隊答不出來。
工廠要有專人 own。沒有組織層級的決定，它會變成另一個沒人管的內部工具。
共享的 skill 要像產品一樣經營。 有 owner、有測試、有文件、聽回饋。

值得繼續追問的

工廠意外接管行銷看板的故事，暗示非工程部門的 pipeline 是下一個藍海。測試、分類、審核的概念在法務、業務是否同樣成立？
「產品經理用同一座工廠」會不會讓探索性原型也被迫符合工程規範，反而扼殺探索？這與「工廠 vs. 本機」的矛盾直接衝突。
當決策重心變成「哪些功能不做」，工廠的產能過剩是否會製造新的組織問題——GTM 跟不上、使用者疲乏？

來源

本文整理自 Podcast《After the Last Engineer》對 Patrick Debois 的訪談逐字稿（2026 年 10 月）。該節目是 Vitaliy Filipov 等人共同製作的 YouTube Podcast 系列，主題圍繞 AI 軟體工廠。文中引述的故事、觀點與比喻均來自 Debois 在訪談中的發言；「分析」一節為筆者整理與延伸，不代表受訪者立場。

《After the Last Engineer》Podcast（YouTube）— 本集訪談 Patrick Debois，主題：軟體工廠的實戰經驗
Patrick Debois 個人 YouTube 頻道：youtube.com/@jedi4ever
Tessl 官方部落格，Patrick Debois 撰文〈AI DevCon NYC: From Coding Agents to Software Factories〉：tessl.io/blog/ai-devcon-nyc-from-coding-agents-to-software-factories
訪談中提及的活動：AI Native DevCon，2026 年 11 月 2–4 日，紐約，主題為 software factories。

受訪者背景：Patrick Debois 於 2009 年舉辦第一屆 DevOpsDays，被公認為「DevOps」一詞的創始人，並與人合著《The DevOps Handbook》。現任職於 Tessl。