為何我停止使用 AI 進行開發
身為一名高級開發人員，過去三年我幾乎每天都在使用 AI 進行編碼，大約編寫了 15 萬行代碼，並嘗試了各種 AI 工具和模型，包括 GitHub Copilot、GPT、Claude、Cursor、Windsurf 等，甚至還用過 Gemini，以找出最佳工具。
一開始，使用 AI 編碼感覺就像魔法一樣，我能快速完成代碼，開發 MVP 的時間縮短到原來的十分之一，一周的工作量相當於團隊過去一個月的成果。
然而，三個月前，我在開發一個重要功能時，因懶惰而讓 Windsurf 幫我解決問題。我將任務描述複製到 Windsurf 中，結果等了 15 分鐘，它隨機更改了七個文件，還引入了新的 bug。我讓它修復 bug，它又陷入了 10 分鐘的循環，如此反覆兩個小時，我最終決定自己動手。
這時我才發現情況有多糟糕，不得不刪除 AI 生成的所有代碼，從頭開始實現功能。這種情況並非首次發生，通常一開始添加一些代碼，AI 開始思考、修改文件，然後不斷循環，試圖解決錯誤，最終往往需要人為介入修復所有問題。大多數時候，我發現從頭開始自己做更快，之後再用 AI 補充一些細節。
我在網上看到一份備忘錄，提到解決一個問題通常只需要 5 秒，但人們卻習慣讓 Cursor 等工具來解決，結果陷入循環。我仔細檢查過去六個月構建的代碼庫，發現存在大量重複代碼，幾乎沒有組件可重用性，即使有也存在過度設計的問題。還有很多無用的文件是之前查詢留下並提交的，實現也存在冗餘，例如自己編寫防抖函數而不是使用外部庫。
此外，AI 還會帶來一些副作用，有時讓它修復 TypeScript 類型，它卻會在完全不相關的代碼部分進行更改。單元測試也存在問題，大多數測試用例冗餘，只是在測試相同的正常流程。代碼庫缺乏一致性和內聚性，即使添加了風格指南和配置，有時結果反而更糟。
我的代碼庫變得過度設計且臃腫，前端有不必要的自定義 hook，後端也有不需要的中間件，存在大量技術債。我估計仍有大約 60% 的代碼需要重構，目前正在手動修剪、清理、添加測試和消除雜亂。
這就是我停止使用 AI 的原因，我厭倦了等待 15 分鐘得到一個有 bug 的解決方案，厭倦了測試通過但實際應用中存在明顯 bug 的情況，也厭倦了 AI 編碼工具的「泵和轉儲」心態，就像 5 年前的 JavaScript 框架一樣，每周都有新的框架出現，聲稱比之前的更好。
從三年 AI 編碼中學到的三課
課程一：AI 做重複任務的神話
人們認為 AI 可以做重複性任務，開發人員可以專注於更複雜的系統設計、架構和深度編碼。但實際上，要做好大的事情，必須先精通小的事情。例如，要做微前端，就必須精通 CSS、盒模型、彈性佈局等基礎知識。
史蒂夫·喬布斯和沃茲尼亞克創辦蘋果時，沃茲尼亞克親手製作了第一台電腦，這種工程卓越的水平是建立偉大公司的基礎。如果不掌握基礎知識，就無法實現大的目標。
課程二：生產軟件中，少即是多
黑莓是早期的智能手機公司，但被 iPhone 擊敗。兩者的最大區別在於黑莓有很多按鈕，而 iPhone 只有一個。這說明優秀的設計是簡單的，這是自然和技術的規律。
在軟件領域也是如此，偉大的工程師會將複雜的問題簡化，而糟糕的工程師會寫出大量冗餘且難以維護的代碼。更多的代碼意味著更多的技術債、更長的代碼審查時間、更低的整體質量、更長的構建時間和更多無用的功能。
SpaceX 獵鷹火箭的猛禽發動機也是一個例子，最初的發動機很強大但有很多部件，經過不斷迭代，現在的發動機功率幾乎翻倍，同時更簡單、更易製造和維護，故障機會也更少。
課程三：有時自己做比解釋如何做更容易
要讓 LLM 給出好的解決方案，需要提供大量詳細的上下文，這通常比自己解決問題更費力。LLM 缺乏對世界的直覺理解，即使提供了上下文，它們也不能真正思考，例如在數學計算方面表現不佳，容易出現不精確和不穩定的情況。
此外，添加風格配置和指南並不一定能讓 AI 表現更好，有時反而會導致更不穩定的查詢。更多的上下文並不能解決問題，反而可能讓 AI 迷失方向。
我現在如何使用 AI
儘管我停止了依賴 AI 進行開發，但在工作中仍會使用它。首先要注意噪音與信號的區別，管理層可能會要求使用 AI，我們需要順應潮流，但不要被它吞噬，也不要因此停止提升自己的技能。
AI 在推理方面表現出色，例如有了第一版代碼後，需要創建第二版、第三版，或者有了一個接口，需要為測試創建幾個模擬對象，AI 可以快速生成這些內容。
當遇到文檔很差的包時，AI 可以幫助生成文檔。自動完成功能也很有用，但在接受每一行代碼之前，一定要仔細審查，避免在工作和面試中出現問題。
總之，問題越簡單，AI 給出準確解決方案的可能性就越大。如果大家希望我製作關於 AI 輔助編碼最佳實踐的視頻，請在視頻下方留言，若留言超過 10 條，我將製作相關視頻。