Patrick Debois Maps the Patterns of AI-Native Dev

Patrick De Bois 從網際網路、cloud、敏捷、DevOps 時代就觀察新技術如何改造企業。AI 編碼浪潮來臨時，他觀察到兩個現象：一是行業資訊碎片化、火爆資訊淹沒深思熟慮，二是企業普遍困惑「現在該學什麼」。

為此他建立了 Tessla.io/patterns 網站，透過持續監聽社交訊號、會議演講、新想法，再用自己的品味和curation 篩選，整理出一份「AI 編碼模式地圖」。這比問卷調查更快——因為組織級別的問卷調查滯後，等你問出結果時，行業思想已經往前走了。

他把 AI 編碼的演進分成五個層次。最底層是個人開發者，從最簡單的 prompt 最佳化，到寫更好的 specification，再到深入理解 harness（工具層最佳化），最終到 dive factory（程式碼工廠模式）——這是漸進式的學習曲線，也是行業自然演進的路徑。但大多數企業只關注這一層，導致每個團隊各自為政、重複造輪子。

第二層是平臺能力，這塊最被忽視。好的平臺應該提供集中化的 eval 系統（所有代理都用同套標準驗證），共享元件登錄檔，MCP 代理池等。如果一個團隊最佳化了某個 prompt，平臺應該讓全組織複用。如果一個 harness 被證明有效，應該成為平臺提供的標準工具。大企業恰恰在這塊最落後，反而成了突破口。

第三層是質量與安全。過去的問題是「程式碼對不對」，現在升級了：「代理能證明它做對了嗎」。要從單純讓 LLM 判斷，升級到有驗證流程、自定義工具、人類能清晰看到證據的階段。有意思的是，IDE 的角色在轉變——從「寫程式碼的地方」逐漸演變成「驗證程式碼的地方」，因為驗證需要看程式碼、看截圖、看操作錄影等多維資訊，CLI 裡顯示一個 checklist 不夠。

人的問題最硬。好工程師過去是「程式碼優雅」的個體手藝人，現在需要系統思維者：不只懂程式碼，還要理解架構、可靠性、跨越不同技術棧的能力。他們需要持續學習、不怕切換語言、願意協作改進共享元件。這意味著招聘標準改了、職業發展路徑改了。Skeptic 不是要消滅，而是讓 TA 自己去寫 context 和 build harness，會發現「原來這樣我可以讓 AI 更好地工作」。有人喜歡寫 spec，有人喜歡調 harness，有人喜歡做 review——角色自然分化，但都是技術貢獻。

組織擴充套件是最後一層，也是最難的。採用策略的秘訣很簡單：別浪費力氣勸抗拒者，先讓最快的團隊跑得飛快。這些團隊會示範成果，吸引其他團隊自發學習。就像 DevOps 時代一樣，快速團隊掌握持續交付，做出漂亮成績，其他團隊看到 ROI 就會跟進。同時，不要讓快速團隊被平均拖累——反而應該給 TA 們最重要的業務專案，確保能看到 ROI。

成本管理方面，很多 VP 的困境是「預算吃緊，要不要關閉 AI 預算」。答案是不要簡單關閉，因為這樣組織就學不到東西。正確做法是建立 observability：清楚看到每個團隊在哪裡盲目燒 token、用最大模型、重複做同樣的事情。然後驅動最佳化——有時候改個 context、改個 harness 能省 80% 的 token 成本。這是學習雲時代的教訓：初期每個系統都是 VM 很貴，後來學會最佳化分配（多個服務共享一個例項等）才降低成本。AI 也一樣，約束應該驅動效率，不是簡單限制。

最後，衡量指標要改。從「誰用了最多 token」轉向「人工還需干預多少次才能讓代理把活兒做對」。這個指標很聰明——如果平臺最佳化了一個共享 context，所有用這個 context 的團隊的指標都會改善。這激勵團隊投資平臺、共享最佳化，而不是各自為政。這樣的話，對組織真正有幫助的人，就不是「token 金牌得主」，而是那些持續改進共享系統的人。