⛰️AI 時代，四件更值得追求的事情

AI 工具的普及正在改變軟體開發的遊戲規則。有些事情，以前因為麻煩而不做，現在因為有了 AI 的協助，變得更容易達成，也更值得去做了。

今天想分享四個我認為在 AI 時代，特別值得重新檢視的事情。

寫測試：從時間限制變成必要實踐

資深工程師都明白在軟體開發中，測試的重要性。好的測試覆蓋以及測試關鍵邏輯，對於程式的維護和後續修改都有很好的保障。寫好的測試，可以在後續無數次運作中確保當初程式的行為保持一致。就成本效益來說，是非常划算的投資。

但是在實務上，人們就是不愛寫測試，原因很簡單：寫測試要多花時間。

今天花一個小時寫測試，也許未來可以拯救無數小時解 bug 的時間。但問題是，現在連一個小時都沒有就要交付程式碼了。在時間壓力下，寫測試往往被犧牲。

現在有了 AI，這不再是問題。

AI 寫測試非常快，而且寫完測試也可以叫 AI 工具去執行。寫測試這件事從之前的「因為沒有時間或麻煩所以不寫」，變成了「不叫 AI 寫測試是一種浪費」。

我認為，真正懂軟體工程的人應該會善加利用 AI 來做好測試工作。不管是用測試驅動的方式開發，或是撰寫測試程式碼來補強覆蓋。

我現在用 AI Agent 開發 app 時，都會先確保有設定好讓 AI 能夠呼叫測試的指令。不管是透過 MCP，還是直接下指令（比如說 xcodebuild test 指令）。一定要讓 AI 可以執行測試，並讀到測試結果。

這樣一來，Agent 就可以不斷反覆地自動修正。他們可以先寫測試，然後再實作，並且在過程中，如果測試失敗，可以根據測試失敗的結果來修正。不管是開發一項新功能，或是修復既有的 bug，我們總是能夠讓 Agent 執行測試，來確保沒有影響到既有的行為。

這會讓 AI 去開發變得安心，因為知道寫出來的東西是有測試覆蓋。只要看得懂、且同意那些測試程式碼，就可以知道程式有照著希望的行為去實作。

所以，我鼓勵讀者，如果過去對測試並沒有很追求，或是不曾真正認知到測試的價值，那在 AI 時代這變成了軟體工程師不可不懂、不可不用的技能。

我已經說明了「為什麼要寫測試」。而工程師要學習的是：

• 怎樣維護測試環境
• 瞭解哪些東西值得測試
• 審查 AI 的測試程式碼（你可以不自己寫，但是 AI 寫的一定要讀）

做計畫與文件：從維護負擔變成方向指引

許多工程師不喜歡寫文件，或者會聲稱「程式碼本身就是文件」。

用過 AI 工具的人都能看到，它們在寫文件或分析規格、進行程式碼閱讀和理解方面的能力十分優秀。可以寫出各式各樣的文件，不管是規格文件、開發計畫或補充資料。

以往我們會覺得寫文件要花工程師許多額外的時間，而且最可怕的是，如果程式碼修改了，但文件沒有跟著修改，文件就失去意義了。所以維護文件是曠日廢時且吃力不討好的事情。

但就如同測試一樣，現在 AI 在文書處理方面的速度非常快，而且可以做得很好。甚至你的英文寫作不夠好，都可以靠 AI 來幫你寫。

所以在適當的時候，完全可以透過 AI 來產生與更新文件。比如說你今天開發的是一個 Library，裡面可能會有些 Sample Code、教學或上手步驟、使用方法。這些東西以前要自己寫可能比較麻煩，但現在 AI 都可以幫你做得很好。

文件也是讓 AI 寫出來的程式碼更符合我們需要的必要手段。各家 Agent 都有所謂的 rule file，用來指引 AI 依照特定方式去開發。其實，跟人類工程師加入新團隊要遵循的 onboarding 文件，並沒有本質上的區別。

許多人都從經驗中發現，要讓 AI 寫出好的程式碼，建立文件來指引開發計畫是不可或缺的步驟。導入 AI 輔助開發的起手式，可以先讓 AI 分析專案的現況並寫成文件，就可以判斷 AI 的技術掌握能力。接著，再根據需求，與 AI 討論開發計畫，這也是一種不斷更新的文件。

總之，AI 很會寫文件。身為人類，我們應該要善加利用。並且去學習：

• 要有哪些文件、目的是什麼
• 文件應該要放哪些內容
• 要求 AI 更新文件的時機

Code Review：維持軟體品質不可犧牲的工作流程

不知道你有沒有待過有良好 Code Review 文化的開發團隊？（我會這麼問是因為，許多 iOS 工程師任職的公司，可能只有一兩位工程師。）

有好的 Code Review 文化的團隊，工程師寫完功能或修 Bug 會有其他工程師去確認，並且回覆需要修改的意見，或是趁機交流一些技巧、互相切磋學習。Code Review 對於追求專案的品質，以及團隊慣例的一致性，是不可或缺的流程關卡，也是團隊一起成長的好方法。

Code Review 也是團隊管理者的重要工具。自從當我擔任 team lead 後，動手寫 code 的比例越來越少。不過在 Code Review 時，往往能抓到同事程式的一些問題，比如架構方面的，或是可能沒有注意到的細節。也很常趁機分享幾招寫法。閱讀程式碼並提供回饋，對於提升專案品質是有重大意義的。

不過，既然 Code Review 是流程關卡，就需要相當的時間，而且往往會有互相等待的情況。

比如我以前帶的團隊，除了 Pull Request 的作者之外，需要至少兩個人看過並且 Approve 才可以 Merge。為了維護專案的品質，這個要求十分合理，但要徹底落實的話，就需要每個人在做手邊任務的同時，又要花時間去看別人的程式碼。所以往往會在開發週期的後半段，大家在 Slack 上互相提醒與拜託別人幫自己看 PR，不然會來不及 merge。

在 AI 能夠寫程式的時代，我認為 Code Review 變得更重要了。一方面，為了追求軟體品質的高標準，需要透過人類工程師 Code Review 來把關，這點與人類工程師團隊合作時並無不同。

有的人 Vibe Coding 的做法是連看都不看 AI 寫什麼，這在某些情況下是可以的。但如果這份程式碼，是你要交出的工作成果，那麼不管是自己寫，還是 AI 來寫，都是你的責任。你可以不寫程式，但一定要閱讀並親自確認 AI 寫的程式，因為 AI 不會幫你負責任何事。

另一方面，AI 也能夠 Code Review，所以人類工程師或 AI 交付的 PR，也應該讓 AI 來審查。

我現在大量使用 AI 來做 Code Review。一人開發的專案，沒有同事可以幫我 Code Review，但我開放權限給 Cursor BugBot、Claude Code，以及 GitHub Copilot 。它們都有讀取 GitHub Pull Request 的能力，可以在模型上直接閱讀 PR 內容然後提供意見。

AI Reviewer 使用的模型雖然跟實作的 AI 差不多，但是視角不同，所以還是常常能抓出問題來。

總之，一方面我叫 AI 寫程式、自己審查。另一方面我也用 AI 來審查 PR。換作是跟人類工程師組成開發團隊的話，我的工作流程也是一樣的。

如果你所屬的團隊過去沒有堅持 Code Review 的好習慣，現在是加強這方面的好時機。