AI Coding 心得

發表於 更新於 分類於 ，

分享關於 AI Coding 的一些心得和經驗。

自從 ChatGPT 問世以來，AI Coding 工具經歷了多次疊代，從 Claude Code、Gemini CLI 到現在，AI Coding 已經逐漸成熟，成為工程師日常可用的利器。

這段期間，我嘗試過各式各樣的 AI 應用工具，從最基礎的 chatgpt、claude 聊天模式，到 IDE 版本的 Agent（如 cursor、copilot、augment），甚至是瀏覽器端的擴充功能（如 sider）等。在這些工具不斷進化的過程中，我也逐漸從專注於程式邏輯，轉變為更重視使用者應用體驗。現在，我不再需要過度關注程式碼品質或複雜邏輯，只需聚焦於前端體驗與成果驗收，並持續優化專案，最終完成一個 project。

我的體悟是：如果 AI 能寫得比我更好、更快，那我就能將更多時間投入在專案架構與可行性思考上，而非程式碼撰寫本身。這種感覺很奇妙，也就是所謂的 vibe Coding。

然而，Vibe Coding 也有其風險。AI 經常會根據需求隨意新增 function，或採用過時的 API 文檔寫法。經過多次踩坑與深入理解 AI 上下文原理後，我逐漸克服了這些問題。

1. 幻覺問題

這是所有 AI 都會遇到的狀況，即使是目前公認最強的 claude code 也不例外。AI 在產生程式碼時，可能因上下文錯誤或資訊不完整而產生錯誤的程式碼。

解決方法：將任務切分為小區塊。身為工程師，我們理解程式運作架構、API 串接流程與邏輯，知道任務必須分段執行。例如串接 API 時，需先理解 API 文檔，再測試 API 是否正常，最後才整合進程式碼。這時要明確提供 API 介面、傳遞參數、回應參數等必要資訊給 AI，並且每次只執行一項任務後就清空上下文。上下文過長容易讓 AI 罷工，或產生幻覺與不必要的額外 TOKEN 開銷。

2. 鬼打牆

AI 有時會陷入鬼打牆，反覆產生錯誤程式碼。常見原因包括上下文錯誤、資訊不完整，或是引用了過舊的 API 文檔。

解決方法：這時可以利用 MCP context7，讓 AI 先理解最新文檔與 API 呼叫方式，再根據最新文檔進行程式碼修改。

3. 驗證

可以同時運用兩個 AI，各自負責不同任務。例如：我常用 Gemini CLI 根據專案需求撰寫計畫，讓 Claude Code 執行修改與撰寫，最後再由 Gemini CLI 驗證程式碼是否符合預期。這種相互檢驗的方式，可減少單一 AI 過於自信而產生的錯誤。

近期我也用 AI 完成了公司的前端專案，不僅大幅縮短開發時間，根據需求調整各種功能與小細節也變得非常快速高效。