用 AI 代理寫程式 (Agentic Coding) 時，有什麼重要的關鍵原則?

先前 E+ 製作了 Cursor 入門到實戰與 MCP 應用 線上課程，談如何透過 Cursor 等 AI 工具來協助提升生產力。在課程上線後，社群持續有許多關於這個領域的新洞見出現，因此在這一期的主題文，我們會進一步來談在課程中沒有涵蓋到，或者有延伸觀點的內容。

具體來說，我們會著重在 2025 年中開始逐漸成為主流用詞的 Agentic Coding (代理驅動的程式撰寫)上，來談在 AI 代理發展愈加成熟時，如何跟 AI 代理互動，能夠更有效地讓 AI 代理協助完成開發中所遇的不同任務。

人類工程師介入仍很重要

先前在 AI 代理是什麼? 一文中，我們有談到 AI 代理的定義是可以在不用人類介入的狀況下，根據指定目標，去完成相關任務 (Agents are autonomous and can act independently of human intervention, especially when provided with proper goals or objectives they are meant to achieve.)。

雖說 AI 代理的定義下，人類理論上不該介入，但是在過去兩年的 AI 代理發展中，相比於完全沒有人類介入的狀況，適時的人類工程師介入 (human-in-the-loop)，往往能夠獲得更好的成果。

以過去一年相信很多人都聽過的 AI 代理工具 Devin 為例，Devin 是在 2024 年初時，軟體工程師社群最多討論的話題之一。當時之所以討論度高，是因為 Devin 一推出時，就以「全球首個 AI 軟體工程師」來宣傳，能夠在人類指定目標後，就自動運行直到發出一個解決方案的 PR (pull request)。

然而，在 2025 年 Devin 進一步推出 2.0 時，卻從原本全自動化，轉為人機共同協作。在這個轉變發表的同時，Devin 的創辦人兼執行長 Scott Wu 在他的貼文提到，要把任務委派給 AI 代理，不會是一次性的過程 (not a single-shot process)。

換句話說，在目前的 AI 代理發展下，還讓 AI 代理完成任務，需要在過程中跟 AI 代理互動，然後讓代理迭代。相信讀到這邊，讀者可能會問，假如仍需要人類工程師介入，那麼具體來說，人類工程師的角色是什麼? 要做什麼? 以下幾點是我們認為人類工程師需要做的。

釐清好問題

首先，在 AI 代理能夠幫忙實作的時代背景下，寫程式 (或說生成程式碼) 的成本比起過去低很多；但是不變的是，「解決對的問題」仍是軟體工程最重要的事項之一。程式碼本身僅是解決方案，比起解決方案本身，有了這段程式碼是為了做到什麼事、解決什麼問題，會是比程式碼本身更重要的。

在《What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not》一文中，其作者談到，矽谷類公司在看待軟體工程師，跟許多傳統歐洲、亞洲公司看待的方式有很大的不同。其中一個關鍵差異在於，矽谷類公司把軟體工程師視為解決問題者，而不只是單純的按照指令寫程式的人；這樣的差異意味著，矽谷類公司會預期工程師去協助釐清、定義問題，確保解出來的問題是真正重要的。

畢竟，如果沒有解決對的問題，就代表花大量的工程資源，卻做出沒有實質影響力的事。即使 AI 代理讓生成程式碼解決方案的成本變低，解錯問題仍代表白花運算資源讓 AI 代理生成無用的程式碼。

對此，Cursor 團隊的工程師 Adam Hofmann 先前發文說 (連結)「在你足夠理解問題以及你想要的解決方案前，不要叫 AI 代理幫你做事 don't ask agent to do something until you understand the problem and solution that you want to see. 」。

當然，釐清問題這件事本身，也可以運用 AI 來協助，例如可以寫下你目前對問題的理解，然後問 AI 是否還有遺漏沒有想清楚的面向、或者問能否點出潛在的假設漏洞。這邊特別推薦，在問題釐清階段可以使用推理模型 (對推理模型不熟的讀者，推薦複習 提示詞基礎：傳統模型 vs. 推理模型，什麼時候選哪一個? )。

建置好讓 AI 能夠成功完成任務的基礎

在釐清完目標後，還有一件事是需要讓 AI 開始執行任務前，工程師需要先做的事 — 建置好讓 AI 能完成任務的基礎。

試想，假如今天一個剛加入團隊的新成員，即使這位新成員很聰明，但假如該成員不知道團隊的程式碼庫風格、不能使用團隊平常有在用的工具，這位成員可能如預期發揮自己百分百的水準嗎? 相信會很困難。

對 AI 代理來說也是一樣的，因此，務必要在讓 AI 代理開始執行任務前，先準備好以下的文件與工具

團隊程式碼庫風格指南 (style guide)
過去不同功能的設計文件 (design doc)
靜態檢查工具 (例如 linter)
在執行任務時會用到的外部工具 (MCP)

假如有提供程式碼風格指南，AI 才不會生成出風格不一致的程式碼；如果有提供設計文件，AI 在生成程式碼時，才能夠先理解原本的設計脈絡，進而讓程式碼更符合設計初衷。另外，如果有提供靜態檢查工具，這樣如果 AI 生成出的程式碼不符合團隊的規範，也能夠獲得立即的回饋，讓 AI 代理能夠進一步調整。

上面這些建置，都意味著能夠讓 AI 更精準地完成我們期望 AI 完成的任務，這樣將能夠有效減少後續人類的介入與改動。

與此同時，如果有提供外部工具，也將能夠進一步拓展 AI 的用途。例如提供 Jira 或 Linear 的 MCP，Cursor 就能自動從 Jira 中抓取相關規格或需求描述，工程師甚至不需要手動輸入需求，只需告訴 Cursor「根據 Jira 的某張 ticket 來實作功能」，即可完成任務。

又或者，當我們提供功能描述和規格後，Cursor 可以根據這些內容自動撰寫端到端的測試案例。如果我們進一步將 Cursor 與 Playwright 這樣的端到端測試工具對接，Cursor 不僅能撰寫測試案例，還能透過 Playwright 直接開啟瀏覽器，根據自己生成的測試案例逐步執行測試並完成程式碼，來確保 E2E 的測試案例有寫對。

任務拆小 + 適時給予回饋

如開頭提到，對比起從頭到尾的全自動化，目前業界摸索出比較有效的方式，是人與 AI 的共同協作。而要有效做好這件事，先把任務拆小，讓 AI 能夠去執行不同的子任務，並在子任務的進行途中持續給予回饋，這樣獲得的效果會比較好。

Atlassian 先前發表的一篇研究《Human-In-the-Loop Software Development Agents》(連結) 就把完整的開發流程拆成以下四個階段，然後每個階段都由人類工程師的指示搭配 AI 代理去完成，在他們的研究發現，比起一次要求 AI 完成完整的任務，這種拆小的方式，得出來的品質比較好。

Cursor 團隊的工程師 Adam Hofmann 先前也提過一個 Goldilocks 原則，所謂的 Goldilocks 原則是指「剛剛好」，也就是不要太多，也不要太少。他推薦可以透過反覆調整，來測試當前 AI 代理能完成的任務複雜度。如果發現無法一次成功做好，那就試著把任務拆小；反之，如果發現目前能夠一次成功完成，那就試著把任務範圍加大。這樣反覆測試，直到找到那個「剛剛好」的邊界。

閱讀更多

如果以上的內容對你有幫助，ExplainThis 製作的《Cursor 入門到實戰》線上課程有更多更深入的討論，讓讀者們能夠用最高效的方式使用 AI 程式工具。

感興趣的讀者，歡迎加入 E+ 成長計畫觀看 (連結)。