與 AI 共存

開發，還是被開發？

跟 AI 一起開發程式，開發程式的同時，我們的大腦也「被開發」學習另一種開發方式。正如網路搜尋協同開發一樣，以前是「上網找 Google 和 StackOverflow」，看大家有沒有遇過類似的問題，而通常大多問題，確實都能在網路上找到答案。我都戲稱這是「網友協同」開發，很少有所謂的「獨立」開發者，幾乎不可能完全單靠個人之力完成開發。

現在除了網路搜尋，還多了 LLM 的幫助，可以更精準找到想要的答案。更加「客製化」且精準，不再是「被動接受」網路的資訊，而是可以「主動提問」取得想要的答案。

而這也如之前文章所提到，與 AI 協同開發的方式，現在我們不得不適應另外一種開發的方式，會「問 Google」只是基本，現在還要懂得「了解需求，拆解問題，具體提問」。

以前做開發可能是這樣的：先問「怎麼做部落格網頁」→ 再來「看大家推薦的做法」 → 「找到一篇適合的文章，依照步驟建立各種前置作業」 → 「開始自己手動開發」 → 「把程式碼複製貼上，試著改成自己想要的樣子」。

現在變成這樣，先下指令：「請幫我生成一個部落格網頁，頁面有 A, B 和 C 這些功能，並且可以 OOO 和 XXX」 → 「直接拿生成的程式碼來微調」。

缺點其實也不少，兩權相害取其輕

看到社群中有人分享説，把 AI 工具當成是下屬，這形容頗為貼切。因為是「叫他做事」，雖然我覺得更像是與另一名同事 Pair Programming，與一個腦中記得很多事情的資深工程師做事（尤其使用高階 LLM 時）。

然而，這個「工程師」做事不太可靠，雖然手腳很快，但有時候會被他「亂寫」的程式碼給氣到，最常見的是以下問題：

• 幻想問題：AI 會根據它所擁有的資料，想辦法「拼湊出」機率最高的可能答案。常常會發現 AI 根本是「一本正經」說幹話，實際上根本沒這一回事，卻說得煞有其事。
• 只能氣自己沒講清楚：指令不夠具體，結果 AI 生成的結果也一樣模糊，只好 follow up 追問三番二次，但最後會發現，這樣「修修補補」不如一次問清楚要來得好，再來微調，如此是更好的做法。
• 也是氣自己，沒有看清楚：AI 給的程式碼迅速生成之後，興高采烈地連看都沒看，就直接「複製貼上」，跑了測試或是看網頁畫面，才發現 AI 根本沒有寫好，程式碼東缺西漏的，但這也不能怪 AI 生成的結果，只能怪自己「沒做好 Code Review」就直接讓它通過。

雖然提到許多缺點，甚至有些讓人感到不爽的地方，但我仍然選擇使用生成式 AI 來寫程式碼。

這就像是對伴侶的感情，儘管有時會因為他「講不聽」氣得半死，覺得他「死性不改」，但仍然很愛他。因為在兩者之間取其輕，你會發現與他在一起的生活更美好。正如大家所說的「1 + 1 > 2」，優點所帶來的價值超過了缺點造成的損失，這就足夠了。

以前麻煩，有了 AI 就不太麻煩了

受到網友的啟發，回顧使用 Cursor 這一個月來的心得，在幾個方面頗有心得。

1. 為產品內外的細節加分

以前「嫌麻煩」的事懶得做，現在不太麻煩了。

產品看得到的外部細節：以前會「懶得寫」或是以沒時間來推託不寫，現在有 AI 幫助，寫起來輕鬆多了。分為產品外部（終端使用者感覺得到的）以及產品內部（開發人員才有所感覺）這兩部分，介紹使用了 AI 之後的心得。

• 外部產品細節
  • 樣式快速 Prototyping：只要提供設計稿給 AI，就可以針對設計稿產出還算可用的前端程式碼，頗有為程式碼「打草稿」（Sketch）的味道，這在開發初期打造產品雛型，相當有幫助！
  • Error Handling：以前會想說寫 error 轉換好麻煩，還要為每一個錯誤想錯誤的顯示，但現在只要用指令呼喚 AI 幫忙依照 http status 產出，眨眼之間就生成還算可用的錯誤處理了。
• 內部程式碼細節
  • 重構：異味重構，如同之前示範過的那樣，與 AI 一起做重構真的快很多。雖然 AI 做得可能不如預期，但如果當下本來就沒想法的話，至少 AI 會提供個「重構的方向」，再根據此方向做調整。
  • 寫測試：特別是準備測試用的假資料（mock data），以前做這件事「超級麻煩」，現在變得「超級輕鬆」，寫起測試變得相對輕鬆寫意，不必再被太多的資料準備細節所困擾。而寫測試變得不麻煩之後，產品就能更加可靠與穩固，不用太擔心因為改 A 壞 B，從而加快產品的開發週期呢！

2. 生成雛形快，但不太精準

最大優點：可以「超級快速」把設計稿轉換為程式碼，轉為大致可用的組件程式碼雛形，接著就可以用此程式碼為基礎，先來寫「整合測試」。

以我的經驗，且正如先前文章所提到的範例，要提供 AI 比較完整的設計稿，才能夠生成「比較像樣」的程式碼組件。

特別是網頁開發部分，AI 生成 RWD 版型會比較有障礙，AI 不會知道你這個版型，會需要在手機或平板的尺寸下長什麼樣子。AI 比較不會想那麼遠，想到還要支援「多裝置」的版型。

切版屬於 AI 中比較難「一步到位」的，需要在需求方面多花點功夫，將大塊的完整需求，切成細小的具體指令，再請 AI 幫忙寫細節實作的程式碼。接著根據生成的樣子，再去微調樣式細節，就像是之前示範過的那樣，AI 會「幻想」這邊應該要長這樣，而忽視原先的設計稿。

AI 會生成基本但比較醜的版型，但這沒關係，待會再來改。畢竟本來就有預期如此，反正細節本就該自己做調整。

但如果你只是想要產一個 Layout ，且對於該程式語言「切版」沒這麼熟悉，遇到像是垂直置中這種切版難題，以前常常要爬很多資料才知道「最適合這塊版面的作法」是什麼，現在 AI 可以根據上下文「猜」這裡應該做什麼，不出幾次就能給出還不錯的生成結果。

3. 跨語言與文檔的開發體驗

以前就想像過，如果可以用白話文的方式，在各種資料或程式碼之間，幫我做好複製貼上，可以做到「文字無痛轉換成程式碼」，那該有多好？

但現在用 AI 就辦得到，可以很迅速地幫我參考特定的程式碼檔案，模仿出類似結構的程式碼。不止省去了複製貼上的時間，還節省了許多腦力。不必先參考檔案 A 的程式碼，複製某幾行貼上到檔案 B ，接著根據檔案 B 的程式碼去修改。雖然不是很困難，但這樣一來一往的 Copy Paste 程式碼搬運，也是件挺累人的體力活。

如以上這張請 AI 生成的圖所示意，現在我們可以一個人就輕鬆在各種格式文檔之間轉換，節省許多「了解文件寫法」，以及降低轉換文檔之間脈絡的阻礙。

不僅如此，還可以參考非程式碼的文字檔案，如之前示範過的 feature 檔案，可以請 AI 幫我從純文字轉為程式碼實作。簡直就像魔法一樣，雖然轉換結果不盡正確，但生成之後只要調整就好，不必從頭都自己手寫，光是這樣就已經降低許多開工的「心理門檻」。

萬事起頭難，用 AI 可以大幅降低最初寫程式碼的障礙，更容易跨過不熟悉而綁手綁腳的那道檻。尤其在碰不熟悉的專案特別有感，以前都要在 IDE 切左右兩個分開的視窗。左邊是新寫的，右邊是舊的程式碼，一邊參考右邊的既有程式碼，左邊寫新的。先把可以用的直接複製貼上，不能直接用的，參考舊有寫法，按照新功能調整舊有程式…。

而現在與 AI 協同開發，只要用「請幫我參考 @OOXX 和 @OOXX 這些程式碼，想要實作以下 … 功能」這樣的指令，就可以按照參考檔案的程式碼，轉瞬之間（喝口咖啡）就生成類似架構寫法的新功能程式，省下不少人工比對與參考的時間。

小結

Cursor IDE 整合性高

雖然生成程式碼品質的部分，Cursor 沒有比其他 AI 工具的競爭對手強太多，但我用了一個月下來，整體開發體驗還算不錯，在日常開發的「微調校正」方面的體驗特別好。

總結開發體驗最絲滑的幾個點：

1. Inline Prompt：有時候只想要針對某部分程式碼做修改，特別是做「重構」的時候會用到，這時候只要在該程式碼區塊下指令，尤其是調整 class 內 method 內的情境，特別好用。
2. Cursor Tab：如同 Copilot ，按一下 Tab 就能自動完成。AI 會「預判」接下來應該會出現的程式碼，Copilot 通常是只有預判這一行或是下一行的程式，但 Cursor Tab 可以預判更多（預判你的預判），可以說是「Two steps ahead」，甚至可以預判到自動完成整份程式碼的類似之處。

Cursor 的整合性讓我可以更輕鬆在「不同的開發環境」中切換，無論是前端還是後端的開發，都能夠享受到一致的使用體驗。這對於需要頻繁切換技術棧的開發者來說，無疑是一大福音。

Debug 不用太期待

AI 無法超出「指揮家」的能力太多，你解決不了的 bug，AI 通常也無能為力。

雖然一開始用 AI Debug 會讓你很興奮，帶來滿滿的成就感，因為只要把錯誤訊息作為 Prompt 來問 AI，都可以得到看似蠻有用的答覆，以為「終於」可以有更好的 debug 體驗。

但實際上，AI 在協助 Debug 時，往往只是提供相關的資料和建議。真正能夠解決問題的機會並不多。Debug 並不僅僅是找出程式碼中的錯誤，更需要深入理解程式邏輯和運行環境，而這部分正是 AI 較為不擅長的部分，難以從「大局觀」來檢視整個軟體系統的運作。AI 可以作為輔助工具，幫助我們蒐集資料和提供潛在的解決方案，但最終的問題解決仍依賴開發者的專業判斷和經驗。

所以說，要說不久的未來軟體開發者都會失業？ 危言聳聽，聽聽就好。至少還要一大群人來維護舊系統，用「工人智慧」來 debug 呢。

生成的程式碼，得先過自己這一關

當 AI 協助生成程式碼時，這些程式碼並非直接可以投入生產環境的成品。開發者必須對生成的程式碼進行嚴格的檢查和測試。要說極端一點的話，以我的經驗來說，得逐行檢查 AI 生成的程式，才能確保符合需求並且沒有潛在的問題。

AI 生成的程式碼可能在最佳化、可讀性或架構規劃等方面，仍然不足以直接成為生產環境程式碼，因此我們「人類」的參與還是很重要的。透過對程式碼的理解和調整，善用追加提問（FollowUp）的指令技巧，將程式碼打磨到最佳化。將 AI 的成果轉化為實際可用的解決方案，確保軟體的穩定性、效能及易於維護。

截然不同的開發體驗

單打獨鬥、埋頭苦幹的開發時代已經一去不復返。

在不久的未來，程式開發所需的能力將不再僅僅是計算機科學的知識，更重要的是能夠提出問題並設計有效的解決方案。

特別是，能夠問對問題至關重要，這不僅能提升 AI 生成程式碼的品質和精準度，還能促進更有效的合作。此外，良好的溝通能力和問題分析能力也是不可或缺的。開發者需要能夠清晰地定義問題，並以簡單扼要且具體的語句表達出來。如此一來，所提供的指令才能有效率地引導 AI ，生成可靠且高品質的程式碼，最終實現效率更好的開發流程！

最後，希望大家能找到最適合自己的 AI 協同開發方式，從而提升開發效率。無論怎麼說，只有準時交付和早早下班，才是我們真正要的。