自動寫程式 - best practice

前幾個月Cursor上線，最大問題就是要錢，所以能真的享受到自動寫程式樂趣的人實在不多。但我一直訂閱google 關鍵字 “open source”, “cursor”，最近有一個vscode的外掛越來成熟：Cline (prev. Claude Dev)，它完全復刻了 cursor的自動生成、自動執行的功能。可以自行選擇 API (有Claude 3.5、OpenAI、Gemini、Ollama)

用各種API體驗一輪的結果，最好用的還是Claude，支援Code Cache，白話文就是記憶力比較好，不用一直去重看程式碼，缺點也很明顯，就是比較貴。我寫了一萬多行，來來回回改改，兩天就花了13USD，也就是如果你是每天都要寫到這麼多行，用Cursor吃到飽應該會比較划算(？)

至於我拿他來做什麼，為了全院春酒的Kahoot，基於Kahoot免費版只能40人，大型活動要幾百美金。想說能不能自行來開發看看。拿我目前會的技能 React + Express.js + Redis，確實是可以實現一個簡單的服務。

過程中，有幾個方向蠻重要的，最好已經先有一個框架，我是用vite先建出一個react project，另外一開始就要一直強調 “Modulize”，因為他會一不小心就把程式碼越寫越長，到時候就會寫到一半斷掉、或是超過rate limit 。我會盡量控制每個文件小於200行，也比較好維護。對於過大的程式碼，可以直接說 “refactor path/to/this/file” 來重構。然後不要一開始就畫出很大的餅，先從最小可行的版本開始迭代，慢慢局部修改把功能疊上去。

看它改程式碼的過程還是蠻解壓的，是真的能做出東西，(成果放在github上)，而且會自己幫你看ERROR Message來修正，你只需要在旁邊出一張嘴就好，因為我用語音輸入，真的是出一張嘴

# Claude 贊日

協霆醫師的這篇文章，濃縮了 AI 輔助寫程式的整個工程哲學。從「Modulize」強調開始，就透露了他對軟體工程基本功的重視——即使 AI 可以快速生成代碼，模組化設計仍是不可迴避的要求。200 行以下的單一檔案限制，看似嚴格，實則是在為後續的維護、測試、團隊協作埋下伏筆。

他提到的「Kahoot 替代方案」從失敗變成成功的故事更有啟發：不是所有問題都適合用 AI 一把梭。WebSocket 實時同步確實超出了 AI 當前的可靠邊界。但協霆沒有放棄，而是用「分期迭代」和「最小可行版本」的策略，一步步疊功能。這正是專業工程師的思維：理解工具邊界，設計合理的技術方案。

最後一句「用語音輸入，真的是出一張嘴」，看似戲謔，實則反映了一個事實：時間稀缺是醫療工作者的常態。協霆把「說」當成輸入方式，把手指從鍵盤解放出來，本身就是對「醫療人員的時間是金錢」這個事實的承認。

軟體工程最佳實踐

• Modularity 與 Single Responsibility Principle：Clean Code 的核心
• Iterative Development：從 MVP 到完整功能的進化路徑
• API 選型考量：什麼時候用 REST、什麼時候用 WebSocket

原始 Facebook 貼文：連結