不要再修復 Agent 產出的代碼了，去修復那個產出代碼的系統。文章作者、來源：InfoQ
如果一名開發者怎麼都用不好 Agent，問題可能並不在此開發者，而在公司根本沒有為 Agent 準備好一套能運作的系統。
許多企業所謂的 AI 轉型，仍停留在為開發者購買 Cursor、Claude Code 等工具，舉辦幾場培訓，再讓大家自行摸索。如果最終 Agent 效果不佳，責任又落回使用者身上。
但 DevOps 一詞的提出者 Patrick Debois 認為：「開發者需要完成一個重要的思維轉變：當 Agent 沒有按你的預期完成任務時，不要再去修改它生成的代碼，而要去改進整個系統，而不是只改 Prompt。」
在 Debois 看來，這是軟體工程從確定性系統轉向非確定性、概率性系統和工作流程時必須經歷的變化。它不僅涉及技術，也會重塑開發者、團隊和整個組織的工作方式。但這種變化不可能只靠某一個工程師，也無法僅停留在單個團隊層面。它和 DevOps 一樣，只有在規模化落地後，才能真正實現。
問題的核心不僅在於開發者是否會使用 Agent，而在於公司能否圍繞 Agent，重新組織團隊、平台和協作方式。
核心觀點如下：
- 不要再修復 Agent 產出的代碼了，去修復那個產出代碼的系統。
- 如果你團隊裡還有人用那種「YOLO（先跑通再說）」的野路子搞 vibe coding，你應該立刻制止。工程實踐不僅對你維護系統至關重要，對 Agent 自身持續變好也至關重要。
- 暗工廠可能並非完全黑暗，而是保留了一點微光（dim factory），這意味著你必須決定對哪些功能承擔多少風險，並非所有功能都適合完全自治。
- 能極致運用 AI、具紮實工程功底、願意分享與協作，將這三點結合，才是你要找的人。
- 你的護城河，在於掌握那些沉澱下來的知識，那些你現在注入到 skill、Context，甚至 Harness 約束中的業務上下文。
為開發者配備 Claude Code，企業就能轉型？
In 2009, a lot of people told me that the idea of continuous delivery was crazy.
譯者註：2009 年，行業普遍採用數月一次的大版本集中上線模式，大家普遍認為發布次數越多風險越高，加上開發與運維壁壘森嚴，容器與雲等自動化基礎設施尚未成熟，缺乏標準化的 pipeline 工具，同時傳統測試與變更審批機制追求在上線前盡可能清除缺陷，而持續交付則提出高頻、增量、隨時可發布的思路，顛覆了大眾對軟體上線風險與流程管控的固有認知，因此在大多數企業看來簡直是天方夜譚、極其瘋狂。
而現在，暗工廠又遇到了完全相同的阻力。
Translator's note: The Dark Factory refers to an AI-driven autonomous software production model, where humans only input SPECs, and AI autonomously completes coding, testing, and deployment without requiring human reviewers to examine code line by line, differing from traditional software factories that still require substantial engineer involvement in the process.
我曾在各種場合反覆聽到同一句話：「這東西在我們這兒行不通。」但這句話真正傳達的訊息並非技術不可行，而是「我們還未準備好」。他們並非不想實現這項功能，而是目前整個組織的架構尚無法支持這種模式。
現在很多人都在討論如何用迴圈優化 Agent、如何搭建 Harness，這些都很好。但我想要說的是，最終我們都會達到那個技術水平，總有一天它們會變成某種標準商品，甚至被某個前沿實驗室打包成服務提供出來。到了那一天，技術上就沒有壁壘了。真正的差異化，在於你的組織如何圍繞這東西重構協作方式。
所以我假設我們都在朝著暗工廠的方向前進。我在 Tessl 以及其他公司觀察到的是，當人們開始採用這些技術時，協作的動態關係會徹底改變。如果你熟悉康威定律，就會知道組織方式和工具之間存在一種相互塑造的關係——你如何組織人，就會打造出什麼樣的系統。但我今天不想談論如何讓你的 Agent 更好，我要談的是這如何改變你的團隊動態、你的平台以及你的整個組織。
我猜在座大部分人都在某個團隊裡工作，而不是單打獨鬥，團隊協作和一個人對著 Claude Code 敲東西是完全不同的兩碼事。
現在大家都喜歡說一個說法：開發者最終會變成一名指揮家、一名 Agent 的編排者。我覺得這個說法沒錯，這確實是我們正在走的路徑。我們越來越像 Agent 的管理者，需要處理與 Agent 之間的關係。
但問題是，我聽到很多開發者私下說：我們當初入行可不是為了幹這個的，我們沒想過要花大量時間去優化 Prompt、去寫更好的 SPEC。我們是工程師，我們搞的是技術，這讓我們有一種身份上的摩擦感，會不斷問自己：這真的是我想做的角色嗎？
後來出現了一個名為「Context engineering」的概念，算是給開發者一個台階下。它指的是，這不僅僅是調用 Prompt，你還需要測試、評估、分發和優化 Prompt，因此確實帶有一點工程的意味。但說實話，許多開發者仍覺得只與 Prompt 和 SPEC 打交道很空虛，感覺自己從工程師變成了「提示詞管理員」。
但我實際觀察到一個有趣的轉折點：當我們開始引入 Harness、迴圈，甚至推動整個組織走向更高程度的自治時，一條全新的技術路徑被打開了。突然間，開發者需要為 Agent 建造工具，這一下子重新點燃了一批人的熱情。那些之前覺得「這不是我該幹的」的開發者，瞬間就來勁了。他們說：沒錯，我們能幹這個！我們掌握這種知識！我們可以用編程的方式讓這個系統變得更好。因此，這很有趣——當我們一直強調「抽象、抽象、再抽象」時，「手藝」感卻在另一個位置重新浮現，為更硬核的工程工作開闢了新的空間。
不要修程式碼，修產生程式碼的系統
經常有人問我：該如何處理那些持懷疑態度的人？我的回答永遠是：這些人其實是你的寶貝。因為他們腦中蘊含大量的隱性知識與判斷力，你需要將這些東西灌入 Agent 中。你可以告訴他們：「請把你的所有知識與挑剔都拿出來」，這能讓 Agent 和 Harness 變得更好。如果你遇到那些抗拒、天天抱怨「這玩意兒生成的代碼品質太差」的人，你可以把他們當作燃料，將這股憤怒與懷疑，轉化為改進系統的動力。
現在，讓我給公司的開發者們提一個建議：我們需要進行一場巨大的心態轉變——不要再修復 Agent 產出的程式碼，而是去修復那個產出程式碼的系統。就像幾年前有人說過的一句話：別造那個東西了，去造那個能夠造那個東西的東西。我們現在就處於這個抽象層級，透過 Context、Harness、迴圈來打造「能造東西的東西」。許多還停留在「Human in the Loop」、自動補全、調整 Prompt 階段的人，需要思考如何提升自己至系統思維的層次。
我們真正要做的，是透過良好的工程實踐來最小化人類的干預次數。一開始，大家都覺得「vibe coding」很爽，丟個 Prompt，出個結果，管它呢，繼續往下跑。但現在越來越清楚的是，我們不只是透過 Prompt 給 Agent 下指令，我們其實是在說：請帶測試一起寫、請更新文檔、請遵守程式碼規範。原來我們對優秀工程師說的那些話，現在全部原封不動地搬給 Agent。如果你團隊裡還有任何人用那種「YOLO（先跑通再說）」的野路子搞 vibe coding，你應該立即制止。工程實踐不僅對你維護系統至關重要，對 Agent 自身持續進步也至關重要。
我在一些領先的團隊中開始看到一種新的儀式，他們仍然舉行計劃會和回顧會，但討論的內容徹底改變了。在回顧會上，不再說「代碼出了什麼問題」，而是問「系統出了什麼問題？」
在計劃會上，我也看到一個有趣的分工：那些定義清晰、範圍明確的任務，可以直接交給 Agent 處理，因為 Harness 越來越好，能夠處理這種明確的任務；而邊界模糊、需要協商的事項，則仍由人類負責。因此，計劃會上自然形成了分工：這些卡片直接進入 Agent 流水線，那些卡片我們來討論。
開發者通常會經歷一個學習週期：先學習 Prompt，然後是更好的 SPEC，接著是 Context、Harness 和迴圈，整個行業也在這個週期中逐步提升。但團隊 Lead 可以做的，是為這個進程設定節奏與約束，例如告訴他們：「別再調整 Prompt 了，把 Context 做成可重用的。」「好，這一步完成了，我們進入下一步。」團隊 Lead 的價值就在於設定這樣的節奏，如果你只是丟下一句「自己去摸索」，那是行不通的。
還有一個連帶效應：一旦你們團隊的生產力開始暴增，下游的人，例如負責 GTM（Go to Market）的人會跟不上，甚至用戶也會跟不上。因此，你需要透過自動化來協助他們，你的框架不能只停在編碼這一步，必須延伸到他們那邊。同樣的道理也適用於上游的需求輸入，如果需求來得太慢，團隊就會被卡住，這些環節也需要被納入這個新的工作流程中。
目前市面上有許多指標，例如 Token 花費之類的。但我開始越來越相信兩個真正能衡量生產力的指標。第一個：你數一數，要讓 Agent 做對一件事，你還需要多少次人工干預？這個數字應該持續下降。你的 Harness 越好，Context 越好，指南越清晰，這個數字就越低。第二個指標是，當你從單兵作戰轉向共享系統時，會產生乘數效應。你在一個地方修好了某個東西，所有人都跟著受益。這不是說一個人的效率變成十倍，而是對 Agent 系統的一次優化，能在所有人身上產生乘數效應，
你可以在一個倉庫內、一個小團隊中先啟動，共享 Context，共同改進 Harness。但你真正想做的，是將這種效應擴展至整個組織。這時，我們就不得不談到平台團隊了。
別讓每個團隊都自建一套 Harness
平台團隊是典型的共享型組織，現在他們可能正在處理基礎設施、雲服務、MCP 網關之類的東西，對 Agent 這塊關注較少。但一堆新東西正在湧現，需要他們接手，例如技能註冊中心（不能讓每個人都在自己的角落裡發明同一套技能）、Context 的評估系統（這段 Context 到底有沒有用？能不能量化？）、專門針對 coding agent 的護欄和身份管理（Agent 以誰的身份提交代碼？權限邊界在哪？）。因此，平台團隊需要有人拉一把，幫助他們成長為這個新的核心角色。
這件事很難，你必須有一個明確的負責人來推動。但這個人該是誰？平台團隊？開發者體驗團隊？前者通常不接觸開發層面的事務，後者又很少接觸基礎設施，因此需要某種融合，但這種融合不會自動發生。你必須確保有一個負責人來推動這項中心化工作，否則你的團隊只會在自己的小範圍內打轉，無法出現「Paved Road（鋪裝路）」。
為什麼我們每個團隊都要各自發明一套認證系統的對接方式？這是共享組件，應該放進註冊中心。為什麼要各自搭建自己的 Harness？如果我們都使用同一個 linter、同一套安全掃描工具，那這就是可重用的組件。我認為這會像當年雲基礎設施的鋪路一樣，逐步集中到平台註冊中心裡。
但問題是，如果任何人都能隨意往這個中心倉庫裡丟東西，就會迅速野蠻生長（becomes a sprawl）。例如，一個 skill 上去了，誰在維護？另一個人又 fork 了一個類似的 skill，那我該選哪個？所以必須有人明確擁有某個領域，他要確保這個東西是可測試的、是模組化的，別人能在這個基礎上擴展 Context 或 Harness 裡的安全掃描部分。你得用集中化的方式來做，而不是在組織內部隨便傳。
建立共識很難。這不像 tabs 和 spaces 的爭議那麼出名，但有時感覺差不多。如果你讓兩個開發團隊就工作方式達成共識，那需要大量的溝通和調停工作。所以最後你很可能不是只有一條鋪裝路，而是三條、四條，他們可以從中選擇。如果他們非要自己搞一套，也可以，但那是他們自己的預算。集中維護的才是「輕鬆路徑」，用來吸引大家走上去。
如果大家盲目地使用這些共享能力，你必須讓他們看到成本。只要你把花費可視化出來，他們自然就會想去優化。這是平台團隊的分內之事，讓花費透明化：花了多少？幫到了什麼程度？如果我能減少 Agent 的迭代次數，那就是優化。但如果我看不到這個指標、只看到最終結果，那我就沒法下手，可視化是一切優化的前提。
因此，我的核心主張是：我們要從單打獨鬥的開發者，走向團隊層面的共享上下文與共享組件，最終邁向整個組織內部的「多人遊戲系統」。乘數效應將在那裡爆發，因為你擁有一個飛輪，改進可以同時向多個方向輻射。
超級個體救不了 Agent 時代的組織
再往上一層，VP 工程部會怎麼思考這件事？我差不多能預測你們組織裡會發生的故事：黑客松或午餐分享會、分享成功案例、建立一個共享的 Slack 頻道、推動一個 champions program。這些都是通用的轉型套路。當年 Agile 轉型這麼做過，DevOps 也這麼做過，沒什麼新鮮的。
另一方面，我們也知道，「發許可證、搞培訓、讓大家自由發揮、讓一千朵花綻放」這個策略從未成功過。一千朵花的結果通常是一千根雜草，百花齊放卻沒有一朵能結果。因此，我主張，在組織層面應明確授權，讓團隊 Lead 和平台團隊來推動這件事。這不是單靠某個超級個體就能完成的，必須有人被正式授權去推動。
找人幫忙也是一件煩心的事。現在的職位名稱亂七八糟：AI 產品工程師、forward deployed engineer、agentic 工程師、AI 工程師……這些詞其實沒有什麼實質意義。你無法透過頭銜判斷一個人的成熟度，因為整個行業都還不成熟。不過，你在發布招聘需求時，這些詞確實能傳遞一些訊號，吸引有意向的人投遞，但它本身並不代表對方一定具備相應技能。我還聽過一些更離譜的故事，有的候選人在面試時用 AI 在耳機裡即時提供答案，面試官一問問題，AirPods 裡就傳來 AI 的建議。
所以我聽到越來越多公司採用這種面試方式。第一步，給一個練習，讓他們放手使用 AI 來解題，盡量用。如果 AI 能幫他們解決問題，這恰恰說明他們善於利用 AI。第二關，請他們檢查自己的方案，解釋「你為什麼選擇這個方案？你如何驗證它是正確的？」，這時你測試的是測試能力和工程判斷力。前半段考驗 AI 利用能力，後半段考驗工程功底。第三，還要觀察他們如何協作，是否願意分享，是開放型還是單幹型。有些人技術很強，但什麼都非要自己掌控，這種人在 Agent 時代反而會成為瓶頸。
能極致運用 AI、具扎實工程功底、願意分享與協作，將這三點結合，才是你要找的人。不是僅僅學過 ML 或 AI 的人，也不是什麼解碼專家，而是一種混合體。你很可能找不到三點都完全符合的人，但這沒關係，例如某位候選人在某方面特別強，但在另一方面需要指導。同時，別把這些技能混為一談並貼上「初級」或「高級」的標籤，它們是不同的技能維度，一個人的 AI 利用能力可能是「高級」，但協作意願卻是「初級」。
工程部的高層還得向上級交代。我們買了這麼多授權，能證明投入產出嗎？交付變快了？可能有承諾，但很難證明。品質變好了？同樣很難說。但回到我之前提到的兩個指標，你可以展示干預次數減少了多少、改進了多少，以及重用率提升了多少。這比比較「有 Agent 和沒 Agent 的編碼生產力」要容易得多，也更有說服力。
因此，當有人抱怨 Agent 太能花錢，主張限制預算時，你的直覺反應不應該是「我們把所有開支都砍掉」，而應該是「我們如何優化開支」。最簡單的做法是選對模型——並非所有任務都需要最強大的模型，有些任務用便宜的模型就足夠了。教育開發者在什麼情境下使用什麼模型，更進一步地，為他們提供更好的 Context 和 Harness，這將讓 Agent 少走彎路，大幅降低成本。
還有一個關於團隊規模的話題。一個全能型人才包辦所有工作，那是最終夢想。但你仔細算一下：這個人通常需要搭配互補技能，例如產品經理或設計師。然後你還得考慮備用人員（backup），萬一有人休假呢？這又回到了三個人。接著可能還需要有人監控生產和工單，如果你真的極度高效，可能是同一群人兼職處理。但你一旦要修 bug，開發新功能的速度就會下降。最後還有新人，你需要為他們鋪路，讓他們知道「好」是什麼樣子。因此，我仍然認為，在組織中我們不可能真的讓每個團隊變成一兩個人。
最後，暗工廠可能並非完全黑暗，而是保留了一點微光（dim factory），這意味著你必須決定對哪些功能承擔多少風險，並非所有功能都適合完全自治。你可以在審計方面投入更多，例如追蹤來源：誰修改了代碼？是人還是 Agent？加入驗證器檢查代碼是否真正有效，並在自動流程失敗時投資於情境感知能力。從完全微觀管理（每行代碼都需人工審閱）到完全自主審批（假設 Agent 的輸出都是正確的），這是一整個光譜。你需要做的，是根據風險水平為不同類型的變更選擇不同的自動化程度。
而我認為你的護城河，在於抓住那些沉澱下來的知識，那些你現在注入到 skill、Context，甚至 Harness 約束中的業務上下文。對我來說，這實際上將持續交付轉變為持續學習。問問自己：我們能多快地將一個新東西引入系統，再將一個舊東西移除？這就是你的反應能力。如果你能持續提升這種能力，關鍵問題就不再是「我要讓整個系統更可靠」，而是「我能否在不斷改變系統的更多部分的同時，保持其可靠性？」
If you take away only one sentence, it should be: The winners will not be the lone super players, but those who understand how to improve organizations on multiple levels.