AI 開發者等級：從自動補全到自主開發

每一位使用 AI 工具的開發者都聽過同樣模糊的承諾：「AI 讓你更有效率。」幾乎沒有人解釋過這種進步實際上是什麼樣子——每一步會發生什麼變化、如何判斷自己處於哪個階段，以及要晉升到下一級需要具體做些什麼不同的事情。結果是，很多開發者「使用 AI」已經兩年了，卻沒有實質性地超越把它當作更快的自動補全工具來用。

Dan Shapiro 引入了一個名為「vibe coding」的框架，將這種進步映射為六個等級的階梯——從 AI 作為更智能的 Tab 鍵，到 AI 作為完全自主的構建和發布系統。Nate 結合 StrongDM 和 Anthropic 內部開發實踐的真實案例對其進行了擴展。在 Big Hat Group，我們將這一框架應用於企業客戶，幫助他們評估團隊的真實水準——並補充了缺失的部分：規範層。不只是「這是某個等級」，而是「這是晉升到下一級的具體方法」。

框架：快速概覽

這六個等級描述了人類與 AI 委託的一個連續譜。隨著你沿階梯上升，AI 承擔更多實作工作——開發者的角色從構建轉變為指導，再從指導轉變為定義規格，再從定義規格轉變為評估結果。

大多數閱讀本文的開發者處於第 1 級和第 3 級之間。以下是如何判斷你的位置，以及下一步該做什麼。

第 0 級——智能自動補全

日常體驗： 你在使用 GitHub Copilot、Cursor 或 Claude 的內聯補全，但互動方式大致是：建議出現，你忽略它，手動輸入接近建議的內容。也許 20–30% 的補全會被原樣接受。你把每個建議都當作需要編輯後才能信任的初稿。

你在這裡的跡象：

• 你重新輸入那些「差不多對」但不完全正確的建議
• 你關閉補全的速度比閱讀它們還快
• 你曾經關閉過自動補全，因為感覺像「噪音」
• 你每天使用 AI 的時間以分鐘計，而非小時

瓶頸所在： 在第 0 級，AI 帶來約 15–20% 的生產力提升——真實的，但有限。模型的品質受限於它接收到的上下文，而在這個等級，你提供的上下文幾乎只有當前檔案。你留下了 80% 未使用的潛在價值。

如何晉升：

1. 先接受，後編輯。 訓練自己先接受補全，然後修正錯誤的地方。目標是更快地評估補全，而不是繞過它們來寫程式碼。
2. 在命名上信任模型。 變數名、函式簽名、測試名——模型的建議通常和你的一樣好。停止過度質疑它們。
3. 使用多行補全。 如果你的工具支援（Cursor、Copilot Next Edit Suggestions），練習讓模型完成整個函式主體，然後再決定是接受還是丟棄。

第 1 級——程式設計實習生

日常體驗： 你已經開始使用聊天介面或 AI 編碼工具（Claude、Codex、Cursor agent 模式）來完成離散的編程任務。你給 AI 一個單一的、範圍明確的工作——「寫一個執行 X 的函式」或「修復這個檔案中的這個特定 bug」——然後在接受之前審查每一行。你的糾錯率很高。你對待 AI 輸出的方式就像對待一個你還不信任的初級開發者的程式碼一樣。

你在這裡的跡象：

• 你將整個檔案內容貼上到提示中，給 AI 提供足夠的上下文
• 你的提示包含詳細的逐步指令，因為你不相信 AI 能做出合理的選擇
• 你花在審查輸出上的時間與自己編寫程式碼的時間一樣多
• 單檔案範圍讓你感到安全；多檔案範圍讓你不安

瓶頸所在： 你就是瓶頸。每項任務都需要你大量的前期定義工作，然後才能編寫任何程式碼。AI 無法在會話中構建在之前工作的基礎上，因為每項任務都被當作孤立的。你在獲得真實價值，但受限於你寫提示和審查輸出的速度。

如何晉升：

1. 為你的專案創建 CLAUDE.md 或 agents.md。 這是一個上下文文件，一次性編碼你的約定、模式和約束——這樣你就不必在每個提示中重複它們。有了這個上下文，AI 在你程式碼庫上的準確性會顯著提升。
2. 練習任務分解。 將一個功能分解為 3–4 個順序任務，逐一移交，然後審查開始和結束狀態之間的差異——而不是每個中間步驟。
3. 將審查轉向差異。 不要從頭到尾閱讀輸出檔案，而是看什麼發生了變化。這更快，也能捕捉到真正重要的東西。

第 2 級——初級開發者

日常體驗： 你在移交多檔案更改。你給 AI 一個跨越多個檔案的功能或 bug 修復，它產生一個 PR。你在合併之前逐行審查該 PR。你的 AI 使用量已經越過了一個門檻——你產出的程式碼比自己能寫的多——但審查正在成為新的瓶頸。

你在這裡的跡象：

• 你經常給 AI 涉及 5–10 個檔案的任務
• 你在接受 PR 之前仍然逐行閱讀每個差異
• 你發現自己在糾正那些並不錯誤、只是與你的做法不同的東西
• 你的產量提升了，但審查負擔也同步增加

瓶頸所在： 審查時間隨產量擴展。AI 比你快，你的瓶頸已從編寫轉向了審查。逐行審查 AI 輸出通常是多餘的——模型的錯誤是結構性和架構性的，而不是語法性的。逐行閱讀成本高昂，卻在捕捉錯誤的錯誤類型。

如何晉升：

1. 轉向語義審查。 問「這個 PR 是否完成了規格中說的內容？」而不是「每一行都正確嗎？」結構和架構上的差距才是重要的；模型能可靠地處理語法。
2. 添加 AI 程式碼審查步驟。 使用 Claude 的 /code-review 命令或 PR 審查 agent。讓 AI 審查 AI 的輸出——在不需要自己逐行閱讀的情況下捕捉結構性問題。
3. 現在就投資測試覆蓋率。 晉升到第 3 級需要信任測試作為你的主要安全網。如果你的覆蓋率太薄，無法捕捉迴歸，那就是你在晉升之前需要修復的先決條件。

第 3 級——開發者如經理

日常體驗： 你在功能級別而不是程式碼行級別進行審查。你編寫的規格足夠清晰，讓 AI 可以在沒有你監督的情況下執行。你是架構師；AI 是實作者。你的大部分時間花在規格撰寫、架構決策和高級程式碼審查上——而不是實作。

你在這裡的跡象：

• 你在實作過程中很少查看單個檔案內容——你等待 PR 摘要
• 你的提示描述結果，而不是步驟
• 你開始更關心測試覆蓋率，而不是具體的實作方式
• 當出現問題時，你的本能是修復規格，而不是手動糾正程式碼

瓶頸所在： 品質現在直接取決於規格品質。模糊或不完整的規格導致返工。你仍然是主要審查者，這在規模化時限制了產量。瓶頸再次轉移：不再是閱讀程式碼，而是評估交付的功能是否真正符合意圖。

如何晉升：

1. 構建規格模板，強制你在移交任務之前定義驗收標準、邊緣情況和測試要求。模板的紀律性使 AI 的輸出保持一致。
2. 將自動化程式碼審查 agent 整合到 CI 中。 在每個 PR 上運行的第二個審查者在你審查之前捕捉結構性問題——並捕捉你在快速移動時可能錯過的內容。
3. 在規格中定義測試要求。 「當[特定測試場景]通過時，此功能完成」將品質門從你的判斷轉移到客觀、可稽核的標準。

第 4 級——開發者如產品經理

日常體驗： 程式碼是黑盒。規格和測試是你與它的介面。你撰寫需求和驗收標準；AI 構建功能並根據它們進行驗證。你檢查測試是否通過，而不是程式碼看起來是否正確。你的主要產物是規格和測試計劃。

你在這裡的跡象：

• 你在任務執行過程中很少（或從不）開啟實作檔案
• 你的規格讀起來更像產品需求，而不是技術設計
• 你對「完成」的定義是「測試通過且需求滿足」，而不是「我審查了 PR」
• 你透過功能驗收標準衡量 AI 輸出，而不是程式碼品質指標

瓶頸所在： 在第 4 級，測試覆蓋率就是一切。你在測試中的盲點成為你發布功能中的盲點。沒有全面的覆蓋——包括邊緣情況、整合場景和效能基準——品質是無法衡量的，而不是高的。第二個風險：架構漂移。AI 做出局部正確的決定，這些決定累積成你看不到的系統性問題，因為你沒有在閱讀程式碼。

如何晉升：

1. 投資全面的自動化測試套件——單元測試、整合測試和端到端測試。突變測試在這裡很有價值：它發現覆蓋品質的差距，而不僅僅是覆蓋數量。
2. 為功能定義結果指標——錯誤率、效能基準、面向用戶的成功率。這些為第 5 級的結果評估模型做好準備。
3. 添加架構審查檢查點。 即使在第 4 級，也要定期審查系統的架構狀態，在漂移累積之前捕捉它。

第 5 級——暗工廠

日常體驗： 你撰寫一個規格，另一端輸出一個經過驗證的、可部署的產物。人類不在正常操作的實作或審查循環中。系統根據自動化品質門構建、測試和發布。你評估結果並調整系統；你不在構建過程中與單個功能互動。

何時適合——何時不適合： 暗工廠在具有深度現有測試覆蓋率和清晰、可衡量結果指標的狹窄、定義明確的領域中有效。它不適合驗收標準不明確的新功能、沒有自動合規驗證的受監管環境，或任何失敗在到達生產環境之前無法被測試捕捉的領域。配置不當的第 5 級系統的失敗模式不是慢速交付——而是快速交付錯誤的東西。

不可妥協的要求：

• 可觀測性。 如果你看不到系統構建了什麼以及它的效能如何，你就完全失去了回饋循環。日誌、追蹤和告警是前提條件，而不是附加功能。
• 自動回滾。 沒有自動回滾的自動化部署是負債，而不是效率提升。
• 結果衡量。 在第 5 級，規格到結果的循環是你唯一的品質信號。如果沒有對其進行儀器化，系統就是在盲目飛行。

大多數企業團隊應以第 3–4 級為目標。第 5 級是具有重大基礎設施要求的特定領域投資。在先決條件就位之前晉升到它，比留在第 3 級更糟糕。

這對工程領導者意味著什麼

團隊結構在每個等級都會發生變化。 在第 0–1 級，團隊組織方式變化不大——開發者擁有實作，AI 輔助。在第 2 級，你需要投資測試基礎設施和審查工具。在第 3 級，能力組合開始改變：你需要能夠撰寫清晰、完整規格的開發者，就像需要能夠編寫乾淨程式碼的開發者一樣。在第 4 級，你在招募產品思維技能——驗收標準撰寫、測試架構、結果定義。在第 5 級，你在運營一個系統。

招募影響是真實的。 隨著團隊從第 2 級向第 4 級推進，需要較少的純實作者，更多在規格和架構方面強的開發者。在 AI 原生組織中，能夠撰寫 AI 可以完美執行的規格的開發者，比能夠手動實作該規格的開發者更有價值。這不是關於裁員——而是關於能力組合和招募方向。

沒有測試基礎設施的第 4–5 級是負債，而不是效率提升。 在沒有相應測試覆蓋率投資的情況下將人類工作流推進到第 4 級的團隊，是在沒有添加替代品質門的情況下將審查者從循環中移除。結果是產量更快，但品質無法衡量。這比第 1 級更差，而不是更好。

複合生產力差距是真實的。 今天處於第 1 級的組織面臨相對於第 3 級 AI 原生團隊的複合劣勢。這個差距不是線性的——它會複合，因為更高級別的團隊以更快的速度承擔更大的任務，投資更好的基礎設施，並進一步推進。每個季度差距都在擴大。現在是縮小差距的時候了。

你的 30 天晉升計劃

1. 誠實地評估你當前的等級。 使用上面的「你在這裡的跡象」描述，而不是自我報告的估計。這些跡象是行為性和可觀測的；使用它們。
2. 從當前等級的「如何晉升」部分選擇一個習慣，堅持練習兩週。一個執行良好的習慣勝過三個半途而廢的習慣。
3. 對你的審查流程進行儀器化。 追蹤每個 PR 花費的時間，以及其中多少百分比是程式碼行級別與功能級別的審查。資料將清楚地顯示你卡在哪裡。
4. 找出你的測試覆蓋率差距。 這是阻止大多數團隊從第 2 級晉升到第 3 級的隱藏瓶頸。在覆蓋率真實之前，你無法信任測試作為安全網。
5. 獲取路線圖。 Big Hat Group 幫助企業工程團隊評估其當前的 AI 開發水準，找出阻止晉升的原因，並構建使過渡可持續的工具、測試基礎設施和治理框架。

獲取企業 AI 開發諮詢

Big Hat Group 與企業工程團隊合作，推進他們的 AI 開發實踐——從評估團隊的當前水準，到實施使晉升持久的 AI 編碼工具、規格模板和測試基礎設施。

聯繫我們，開始你的 AI 開發評估 →

相關文章： Claude Code vs Codex vs Gemini CLI：企業指南 · 企業 AI 程式設計的 agents.md 標準