前言

在這系列的最後，我想分享這幾個月以來的心得。與 Cursor IDE 相處用過的指令，並將一些常用的指令與技巧統整起來，供大家快速上手，與 AI 的開發過程更加順暢！

最初與 AI 開發程式碼

一開始用 ChatGPT 3.5 開發程式碼的時候，已經覺得相當驚艷，「哇！ 終於有程式可以聽得懂人話，而且會幫忙寫程式了耶！」。話雖如此，但這時候只是偶爾拿來問一下程式怎麼寫，請 AI 幫忙重構看看，或是有個新功能，請 AI 幫忙打一下「程式碼草稿」而已。

生產力還沒有顯著提高，在某些「不熟」的情境下，比 Google 搜尋好用一點，但因為眾所皆知的「AI 幻想」相當嚴重，所以每次 AI 產出來的結果，幾乎都要拿去網路查證一番，才會使用在程式碼中。

接著 Copilot 出來了，這個使用了 OpenAI 的 LLM ，專門拿來輔助寫程式的 AI 工具推出後，同事們早已便如火如荼在使用（一個月 $10），提高了不少的開發效率，但我還是繼續觀望，心裡覺得這樣的開發體驗，還不是我想要的，還差一些些。

用了 AI 助理之後

直到 Cursor 這種「整合性高」的 AI 寫程式工具出現，試用了一陣子之後，發現與 AI 高階模型（尤其 claude-sonnet）一同進行開發，是前所未有的體驗。不只省去了很多複製貼上的功夫，而且還能快速為設計好的程式模型打程式碼草稿，可以快速驗證功能的可行性。

拿 Cursor 開發程式碼，這自然不用多提，而先前也介紹過幾個常用的功能，像是 Prompt 視窗、Cursor Tab 和 Inline Prompt。

尤其是在面對比較複雜的專案需求時，Cursor 的 Cursor Tab （智慧提示＋Auto Complete）功能讓我能夠更專注於邏輯設計，而不用在語法上的查找花太多時間。

此外，Cursor 的整合性使得我能夠輕鬆地在不同的開發環境中切換，無論是前端還是後端的開發，不用太怕因為不熟程式碼實作細節而卻步。以前常會因為卡在語法不熟，卡在某些實作太久（而且又不知道該怎麼問），導致開發門檻較高且效率不彰。現在不太會有這個問題了，這對於需要頻繁切換技術棧的我們來說，無疑是一大幫助！

也可以當「聊天機器人」來用

除了寫程式碼以外，Cursor 也可以作為一個強大的「聊天機器人」來使用。就如同使用 ChatGPT 或是 Claude 那樣，我們也可以直接在 Cursor 的 Prompt 視窗內，請它幫我們解答技術以外的問題。

當然也可以用它來解答各種技術問題，或是進行技術討論。這種互動性讓我在開發過程中感到更加靈活，能夠隨時獲得所需要的各種資訊。

Cursor IDE 開發小撇步

接下來進入本次正題，為大家統整以下幾個，工作上必用的 Cursor IDE 開發小技巧。

指定參考檔案

加上 @ ，讓 Cursor 知道你要用哪些檔案做為輸入的參考。先前有介紹過一次了，這邊統整起來為大家複習一下 👍。

• @資料夾 / @檔案 / @程式碼
  • 讓 AI 直接讀取 @檔案 的內容作為輸入的上下文。
  • 模板：

    • 參考並實作

      以 @檔案 的 OOO 作為參考，幫我實作新功能 XXX
      

    • 跨檔案調整。當我懶得找那些相關的檔案，請 AI 幫我一起調整

      我想要調整 OOO，請幫我在 @資料夾 找到相關程式碼，並一併調整。
      

• @codebase：
  • 把整個專案的程式碼作為輸入的上下文。通常我會用在「找程式碼」，用於回憶某些功能的程式碼時。而因為 LLM 可以輸入的 Token 數量是有限的，所以盡可能會在輸入指令時，限縮 Prompt 的查找範圍。
  • 模板：

    • 找關於某功能相關的程式碼

      @codebase ，幫我找 OOO 的相關功能
      

    • 一起改所有相關的程式碼（如果是可以請 IDE 內建功能就可以做到的，就不要用 AI，既不準又浪費時間）

      @codebase，幫我調整 @XXX 檔案中的 OOO，並幫我改所有相關的程式碼
      

精確指令

指令到底要多具體？ 怎樣才算具體？ 這樣講其實頗為「抽象」，講起來確實有點矛盾，要人家寫得很具體，但又沒有給明確的案例，也沒有講清楚規則，簡直是「自打嘴巴」。

於是這次整理歸納了一些常用的指令方法，將指令分為數種類型：

• 變化形：提供具體結果的「預期樣貌」。
  • 從 OOO 變成 XXX
  • 例如：將這段程式碼重構，變成更簡潔的寫法。
• 參考形：提供參考資料或範例。
  • 根據這個文件檔案，幫我實做其中的 OOO 功能。
  • 例如：根據提供的「數字相加」範例，撰寫一個數字相減的處理函數。
• 指令形：明確說明需要執行的操作。
  • 寫一個處理 OOO 的函式。
  • 例如：寫一個 Python 函式來處理使用者的數字加總。
• 質詢形：提出問題以獲得解答或建議。
  • 為什麼這段程式碼會這樣？
  • 例如：如何優化這個演算法的性能？ 提供我 3 種建議做法。
• 優化形：要求改進或優化現有的代碼或流程。
  • 優化某段程式碼，以提升執行效率 / 減少時間 / 增進用戶體驗等。
  • 例如：重構這個前端模組以減少加載時間。

除了以上 5 點以外，你可能還會有個疑問，問說指令到底要有多精確？

我把整段程式碼貼進總行了吧？ 還真的可以，其實程式碼片段可以貼整段沒關係，我自己發現這樣貼雖然「看起來」有點怪，因為 Prompt 輸入欄不會格式化其中的程式碼，但別怕，AI 看得懂的 👍。

不只看得懂，以此 Prompt 做法給出的指令結果也是頗為精準。如此一來，修改的程式碼會更貼近我們的需求，畢竟我要改哪段，到底改的結果長怎樣，都已經作為「上下文」提供給 AI 了，自然就會更為精準一些。

FollowUp

有用過 ChatGPT 應該也知道，FollowUp 是個蠻重要的下指令方式。

FollowUp 有點像是玩 RPG 遊戲時，在劇情對話中「選擇分支」，由我們決定接下來的劇情發展。向 AI 提指令就像如此，通常一個完整的需求會拆成數個小指令，先提供第一個指令，請 AI 幫忙生成答覆。

接著根據這個生成的答覆，再決定「下一步」怎麼走，要接續著 Follow up 做指示呢？ 還是直接往下個指令繼續進行？

以下統整了幾個 FollowUp 常見的情境與相對應的指令範例，我自己最常用的是前三個，在寫程式碼時蠻常請 AI 幫忙提供更進一步的答覆。

• 請求範例：如果 AI 的回應中提到了一些概念或方法，可以請求具體的範例來幫助理解。例如：「原指令：請幫我修改這個測試。FollowUp：你能給我其他使用這個做法的範例嗎？」
• 要求建議：在獲得初步解答後，可以請求對現有程式提供優化建議。例如：「原指令：請幫我實作遍歷取得值的功能。FollowUp：你能給我這段程式碼的優化建議嗎？ 可以用 .map 之類的方法來做嗎？」
• 探索替代方案：如果對初步回應不滿意，可以請求其他的解決方案或方法。例如：「原指令：請幫我修正這段程式碼。FollowUp：這部分重構得不對，少了 handleAdd() 的方法，請修正。」
• 確認理解：在獲得回應後，可以請求確認自己的理解是否正確。例如：「原指令：這個檔案的邏輯是什麼？FollowUp：所以說，這段程式碼可以處理使用者點擊按鈕做計算，但沒有驗證輸入格式，對嗎？」

Debug

以 Debug 來說，初始指令會使用「質詢形和優化形」，先請 AI 幫忙 Debug 看看。但通常都不會如此順利「一次就成功」，第一次的指令只是為 AI 提供個脈絡，讓它知道「問題出在哪」。

接著會不斷地用 FollowUp 指令「追問」下去，交替著用「探索替代方案」來請 AI 幫忙產出其他解法；或是用「要求建議」的方式，請 AI 發散式地產出可能的解法，再從中挑幾個解法下指令看看。

如果是比較困難的 bug，又不熟出錯的原因時，通常要問個好幾輪才有辦法 de 出 bug，才能把那隻「臭蟲」給挑出來。

當然也有比較順利的時候，這時候通常是 Error Log 很明確指出「因為什麼原因出錯」時，這種單一且沒有外部依賴可能的 bug ，就相對簡單很多，只要把錯誤訊息餵給 AI，請它參考這個錯誤訊息，幫忙 debug 看看，大致上都能給出還不錯的解法。再來根據 AI 的答覆去做細微調整，如果還不行，那再跑一次指令的循環，直到「逼問」出 debug 的解法。

總結

QA

最後綜合幾個常見問題，一次為大家解惑：

1. 指令要用中文還是英文？ 一定要用英文才夠準確嗎？
   • 實測下來，用中文也蠻準的，基本上 AI 都聽得懂我講什麼。但前提是指令要足夠具體。
   • 只是有時候簡單的轉換指令，打英文還蠻方便，就直接用英文輸入了。e.g. 把程式碼從 js 轉 tsx，下指令：「to tsx」
2. 怎麼根據指令挑模型？ Claude-sonnet 一個月只能用 500 次，好少呀！
   • 說真的 500 次真的不多，平常開發都是省省著用，畢竟平均一天只能用 16 次左右而已。
   • 如果是比較基本的修改小部分程式碼，先用無額度上限的 cursor-small 或是 gpt-4o-small 試試看。
   • 若為開發「新功能」，那也不用多想，也是先試試看 small 的 LLM 模型，反正又不會花費額度，不滿意再換高階的模型。但根據自己的經驗，若是比較複雜的需求指令，只有高階 LLM 模型才比較能勝任，生成的答覆才令人滿意。