導讀：人人都說 AI 讓開發效率飛升。但 METR 研究發現了一個令人尷尬的真相：資深開發者用了 AI 之後，實際上慢了 19%——偏偏自己覺得快了 20%。這 40 分的感知落差，正在改寫我們對「AI 輔助」的理解。
數字不會說謊
2025 年 METR 追蹤資深開發者在有 AI / 無 AI 兩種條件下完成相同任務：使用 AI 組平均慢了 19%，但主觀評估自己快了 20%。
原因：AI 瞬間吐出大段程式碼產生「進度感」，但理解、驗證、修改這些產出所花的時間，往往超過從頭自己寫。這個認知偏差會自我強化——越相信 AI 讓你更快，就越不去驗證這個假設。
另一組數據：470 個 Pull Request 分析顯示，AI 共寫程式碼的安全漏洞率是純人工的 2.74 倍，其中 45% 的 AI 生成程式碼引入安全弱點。
不過，這些數據有其邊界——METR 的受試者都是對自身專案高度熟悉的資深開發者，任務也偏向既有代碼庫。如果你是剛上手某個新專案的開發者，AI 的效益可能截然不同。這裡的 -19% 是特定場景下的結果，不是對所有 AI 輔助開發的死刑判決。
PEV 迴圈：真正有效的協作模式
Plan：不要說「幫我建完整的認證系統」，而是「下一步我需要一個 email 格式驗證函數——先推理你打算怎麼做，再寫程式碼。」每步只定義一個目標。
Execute：讓 AI 執行那一小步。範圍越小，出錯機率越低。
Verify：跑測試、看 diff、給具體回饋。「第 23 行的錯誤處理缺少 null 檢查」才是有效回饋；「看起來不錯」讓下一輪品質不升反降。精確的回饋關閉迴圈，模糊的回饋製造迴圈。
Context Engineering 比 Prompt Engineering 更重要
給 AI 的環境資訊——專案結構、技術棧、命名慣例、安全規範——影響力遠大於提示詞本身。一份好的 CLAUDE.md 讓 AI 從一開始就在正確軌道上。
另一個被低估的習慣：context 衛生——每個獨立任務開新 session，長對話定期清理。Context 汙染是 AI 產出品質漂移的主因之一。
結論
不要追求「讓 AI 替你寫更多」，要追求「讓每一行 AI 產出都被充分驗證」。
真正的 AI 高手不是打字最少的人，而是驗證最勤的人。
References
- METR (2025). Measuring the Impact of AI on Developer Productivity. METR Technical Report.
- Pachaar A. (2026). How to Vibe Code: A Developer's Playbook. Mistral AI Blog.
- GitClear (2024). Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality. GitClear Research Report.