在目前的軟體開發流程中，工程師經常陷入所謂的 Toil（瑣碎且重複的勞務），例如更新測試案例、修復瑣碎的 Bug 或審核單調的程式碼變更。Meta Reality Labs 的 Ian Thomas 分享了他們如何將開發團隊從單純的 Builder（建造者）轉型為 Explorer（探索者）與 Innovator（創新者），將 AI 深度整合進工程文化中，這就是所謂的 AI Native Engineering（AI 原生工程）。
AI 原生工程的核心目標並非單純地在 IDE 中安裝一個 AI 插件，而是重新思考整個軟體開發生命週期（SDLC），將 AI 視為協作夥伴，從而將人類的創造力釋放在更具價值的高層次問題上。
工程成熟度模型：Assess and Grow 框架
許多團隊在導入 AI 工具時會遇到一個陷阱：嘗試用同一個工具解決所有問題，或者期待透過一次性的 Prompt（提示詞）就能直接獲得完美結果（Zero-shot），這往往導致產出品質低下且挫折感強。
為了克服這個問題，Meta 引入了 Assess and Grow 框架，這是一個基於 DORA（DevOps 研究與評估）概念的成熟度模型，旨在讓團隊自我診斷 AI 整合的現況。該框架定義了六個維度，包括工作流整合、提示詞技巧與共享、信任與品質等。每個維度分為五個等級，從 SIT（完全不使用）到 LEAP（AI 已經無縫整合並從根本上改變工作方式）。
這個框架的重要性在於它採取團隊驅動（Team-driven）而非由上而下的強制指令。透過回顧工作坊（Retrospective Workshop），工程師可以討論團隊目前處於哪個階段，並找出真正的痛點。例如，有些頂尖工程師可能是 AI 懷疑論者，透過這種對話，團隊能共同定義 AI 應在哪些環節介入，而非盲目追求工具採納率。
AI 原生開發的實務應用與成效
在實踐 AI 原生工程後，Meta 團隊在幾個關鍵領域取得了顯著成效：
自動化提升測試覆蓋率 一名工程師利用 AI Agent（智能體）分析哪些檔案最重要且缺乏覆蓋率，隨後讓 AI 自動生成測試案例並平行執行。原本預計需要 20 小時的人力工作，最終僅花費 3 小時的審核時間，便將測試覆蓋率提升至 90% 以上。
精準的舊程式碼遷移 在處理對效能極其敏感的 VR 環境（如 Unity MonoBehaviours 遷移）時，採取人機協作模式：人類擔任建築師（Architect）決定方向，AI 擔任打字機（Typewriter）執行機械性遷移。這將原本一整天的工作量縮短至 4 小時，且維持了高品質。
domain-specific 領域知識整合 透過 MCP（Model Context Protocol，一種讓 AI 能與外部數據源溝通的協議），工程師能讓 AI 直接查詢 VR 世界的狀態、資產與 API 使用情況。這解決了開發者在非 Windows 環境下無法輕鬆檢查 3D 環境狀態的痛點。
對抗 Code Slop（程式碼垃圾）與品質挑戰
AI 提升速度的副作用是產生 Code Slop（指 AI 生成的雖然能跑但缺乏品質、冗長且難以維護的程式碼）。這會導致 Review Fatigue（審核疲勞），因為審核者必須面對數千行 AI 生成的冗長 Diff。
為了應對這個問題，Meta 採取了反垃圾（Anti-slop）策略： 建立 AI 審核 Agent：由資深工程師定義高品質測試的規則，將其編碼進 Prompt 中，讓 AI Agent 在程式碼提交時先進行第一輪嚴格審核。 定義責任歸屬：明確 AI 僅是作者的工具，最終程式碼的品質與穩定性仍由人類作者負責。 從量化轉向質化：不再追求週活躍使用者（WAU）等虛榮指標，轉而關注任務節省的時間、功能交付的穩定度以及工程師的信心指數。
給工程領袖與開發者的建議
對於想要推動 AI 轉型的團隊，可以參考以下 Playbook：
建立安全空間：允許實驗失敗，鼓勵分享學習過程而非僅僅是成功案例。 自下而上啟動，自上而下支持：由熱情的工程師先建立社群並證明價值，隨後由管理層提供資源與授權，讓團隊有時間經歷學習曲線的陣痛期。 關注工作流而非工具：工具會快速更迭，但工作流（Workflow）的優化才是長久之計。優先解決有明確邊界（Bounded tasks）的重複性任務。 維持高品質門檻：AI 會放大既有的習慣。如果團隊原本的開發實踐就很糟糕，AI 只會讓你更快地做出更糟糕的產品。
來源：infoq.com - AI Native Engineering (Presentation by Ian Thomas)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。