3-1 軟體開發不只是寫程式

在前面的兩個章節中，我們分別討論了 Cursor 最基本的設定，以及在使用 Cursor 時，不論是與 AI 的聊天視窗還是與 AI 代理，如何獲得更高品質的回覆。有了這兩個基礎後，進入這個章節，我們將從實際工作的實戰角度，探討如何使用 Cursor。

在這個章節的第一個單元，想先跟大家分享一個重要概念：軟體開發不只是寫程式。相信大多數人都會同意這句話，因為在軟體工程師的日常工作中，除了寫程式或測試程式碼外，還有很多其他重要任務需要完成。有了這個概念後，使用 Cursor 時就不必侷限於僅將它用來寫程式或測試，而是可以進一步拓展它的應用場景。

具體來說，當我們談到軟體開發生命週期 (Software Development Lifecycle 簡稱 SDLC) 時，除了實作與測試這些我們熟悉的部分外，整個週期還包括前期的規劃與設計，以及後期的部署與維護，這些在軟體工程中同樣不可或缺。如果只有實作與測試，軟體產品最終無法交付到使用者手中，也無法真正創造價值。從這個角度看，要成為一名優秀的軟體工程師，不僅要寫好程式碼與測試，還需要在各方面都表現出色。

因此，在這個章節中，我們不僅會談論如何在日常工作中利用 Cursor 來寫程式與測試，還會探討在實際寫程式前的設計階段，如何透過 Cursor 來做更完善。以及在寫完程式碼後，如何利用 Cursor 讓程式碼在未來更易於維護。

有 AI 幫忙，仍須自己承擔決策責任

不過，在正式進入本章節的內容前，還有一個同樣重要的概念，希望大家在使用 Cursor 時能牢記在心，AI 代理雖然能協助執行任務，但最終的決策與責任仍須由自己承擔。

舉一個極端的例子，之前在推特上，有人興奮地分享他如何用 Cursor 打造一個 SaaS 產品。過程中，他完全沒寫一行程式碼，並感嘆 AI 已不再只是輔助角色，而是能實際打造產品的主力。

然而，在他發布第一篇貼文不久後，他又發了一篇貼文，表示這個讓人願意付費的 SaaS 產品，在功能越開發越深入時，開始出現問題，例如 API Key 達到上限，或資料庫中出現未預料的錯誤。由於他沒有技術背景，即使有 Cursor 協助，他在解決這些問題時仍花了比別人更多的時間，這讓他感到非常挫折。

從這個例子可以看出，雖然 Cursor 在某些方面能提供很大幫助，但這並不意味著身為軟體工程師，我們就此停止精進自己的技術能力。比較推薦的做法是，即使有像 Cursor 這樣的 AI 代理協助，我們仍需不斷提升自己在技術上的深度與廣度。這樣才能在以下情況中做出正確判斷，包涵判斷 Cursor 生成的程式碼或技術設計建議是否合理、是否適用於當前情境；如果不適合，身為軟體工程師，我們需要提出更好的解決方案。

同樣地，當 Cursor 生成一段程式碼或對程式碼進行改動後，我們需要做 Code Review，判斷這些改動或新生成的程式碼是否理想。在發佈前，由我們負責把關，確保品質達到一定標準。

因此，雖然接下來的單元會展示一些使用 Cursor 的情境，但在每一個情境中，獨立的思考與判斷，以及承擔最終交付成果的責任，都是我們作為軟體工程師的重要工作，無法外包給 Cursor 或其他 AI 工具。

此系列文章為 《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》 搭配的教材。希望透過這系列文章，將過去協助導入 AI 工具及使用 Cursor 的經驗擴展並分享給想提升生產力的讀者。如果對課程感興趣的讀者，可以加入 E+ 成長計畫，觀看影片學習。