最近公司的一個新專案的其中一個子專案實驗了新的開發方式：嘗試絕大部分的程式都使用 AI (Cursor) 編寫，盡可能地減少人為介入，希望透過進行小範圍的嘗試來理解未來可能的軟體開發模式。
我們也希望透過 AI 的協助可以讓我們大幅度的縮短開發時程，達到以下的效果：
如果你也嘗試過在稍微大的專案這麼做，你可以猜到我們初期的結果是這樣：
只要想要讓 AI 多做一點事情時，就經常會無法照著預想做。大部分可以一次就完成的工作，通常都是簡潔明瞭，不容易有疑義的任務，這個通常一次就可以做得很好。
當然我們不會因為這樣就不用 AI 進行開發了。就自己來說，現在有超過八九成的程式碼都是用 AI 開發的了，其中大量地使用對話的方式進行開發。而由於 AI 有深厚的軟體開發能力，而我可以認真地當一個監工，確保他的工作能夠如預期的完成。
但到底要怎麼樣達到這一步？實際在專案導入 AI 前，得先回到平常在團隊裡面是怎麼開發軟體專案的。
以往的軟體開發討論
在以往的軟體開發流程當中，團隊內經常會透過從產品面向進行策略上的討論，到工程團隊之後開始討論技術解決方案，經過了開會討論以及文件記錄，最終大家取得共識之後，在一次次的開發迭代之後，逐漸開發出產品。
所以軟體開發流程裡面很重要的是團隊的共識以及脈絡，當我們只靠著幾句話就期待 AI 可以透過他所學習到的軟體工程師常識做出我們心目中理想的系統，缺乏的就是傳遞最重要的共識與脈絡給它。
因為它不是你的蛔蟲，不會從短短的幾句對話知道這些脈絡。
團隊之間可以透過開會以及文件來凝聚共識與梳理脈絡，那我們怎麼樣給 AI 這樣的資訊呢？有幾件事情可以嘗試看看。
用規則 (Rule) 定義方向
在 Cursor 裡面可以定義規則，雖然說要寫優質的規則還是需要花很多時間推敲與改善，但規則還是可以為 AI 訂定一個大致上的方向，讓行事作風可以更接近團隊。
比如說要不要寫測試？要寫到什麼程度？偏好怎麼樣的 git commit message？元件的撰寫慣例、命名規則與採用的技術堆疊是哪些？這些沒有交代時，他經常就會隨心所欲，就像是一個剛加入團隊還沒適應開發文化的軟體工程師。
切分規格 (Spec)，逐步前進
實作前先寫一份功能規格（當然是請他寫），並且先充分的閱讀與討論規格，確保他想做的事情跟你想做的事情一樣，確定之後再請他實作。
至於功能規格不用全部都自己寫，我們的狀況是通常會先把任務在專案管理服務（比如說 Asana）先開出來之後，我會先把我所知道這個任務要做什麼告訴它，並且請它寫出規格，然後就它展開的這份規格進行討論與更新，完成規格之後再開一個新的 Chat Context 請他按照這份規格實作。
如果覺得規格寫得不好，那就修訂產生 spec 的 rule，讓團隊之後要生成 spec 都可以有更好的文件品質。
至於規格的篇幅長短會依照團隊習慣有所不同，但是小一點的話閱讀起來比較容易，同時也比較可以按照我們的意思開發，這也有助於我們更好的達成目標。
前面有提到沒有脈絡或共識，會很難讓它做出我們想要的產品。除了透過 Rule 建立脈絡與共識外，另外避免這個問題的方法是訂出目標之後，先不要一次把所有規格寫出來，而是只寫你正要完成的那個功能的規格。
由於我們會根據它寫的 spec 來矯正它想前進的方向，所以在每一次撰寫與實作一份 spec 時都能修正偏差，這樣就能讓專案從想法往實際產品的路上可以朝著預期的方向。
規格最好有驗收條件
規格的內容會跟著每個團隊的不同而有差異，但會建議有驗收條件 (Acceptance Criteria)，這個驗收條件是用來明確的告訴 AI 怎麼樣才是完成了，這樣明確的條件可以讓 AI 更具體地知道它到底要完成到什麼程度。
而驗收條件有很多方式，從工程師的角度來說可以用自動化的測試或是檢驗來代替，比如說單元測試或是整合測試。另外如果是在進行網頁應用程式的開發，可以用 microsoft/playwright-mcp 跟 AI 說直接打開瀏覽器看目前的結果是什麼，讓他直接開啟網頁操作來驗證。
當它可以更好的判斷目前的成果時，就更容易地可以判斷完成度並且採取後續行動。
如果沒辦法自動化檢測，那也可以請他列出手動測試的方式，由開發者自行驗證，然後再跟他說結果。不過當然還是可以由他自行檢驗、自行修正會更好。
到目前為止…
因為我們也還在嘗試這樣的開發模式，在這樣的過程中也很有多需要調整的地方。目前覺得從 rules -> spec -> implementation 這樣的工作流程運作起來還行，寫 spec 時就有機會跟 AI 討論以及更新計畫，這樣就可以在開始動工前，先調整成我們想要完成的樣子。
但我們也遇到了 Cursor 不太擅長遵守規則的問題。雖然說隨著時間這些問題應該會慢慢地被修正，或是累積出更好的實踐方式。不過在那天到達前我們大概都要經常得修改規則，目前確實覺得規則寫太長就會開始忘東忘西，明確並且短一點會更好，另外規則的敘述也很重要，因為會影響 AI 什麼時候會想要套用特定規則。
另外，最近也滿多人談論 Vibe Coding，也就是用近乎直覺的方式用對話進行開發，不太管實作細節。
但其實所謂的「直覺」很大一部份都是你在一個領域已經有了深厚的背景知識與經驗，所以才能讓你看起來毫不費力地的用「直覺」完成，實際上並不是每個人都可以做到，更何況在還牽涉到表達能力。
要達到這個程度，還是得看操作的人對於這個產品的領域是否有足夠深入的看法，以及具備足夠細緻清晰的表達能力。
我會覺得每個人應該都從自己的角度切入，看自己適合用怎麼樣的方式跟 AI 一起協作開發軟體專案。身為軟體工程師與一個好奇的人，再加上自己在經年累月的寫作有累積了一定的表達能力，就會採取適合我的方法跟 AI 協作，更精準的描述自己的需求、切分工作、設定驗收條件與軟體開發偏好，甚至用自動化測試的方式來讓 AI 可以做得更好。
我只是從我的角度出發，了解自己喜歡與擅長什麼，然後訂製了跟 AI 的工作流程，而也在這個互動時發現到了比起寫程式，我更喜歡打造產品。與 AI 互動時才有機會把這兩件事情拆得更開，回過頭來理解自己。
而每個人都不同，我的建議是回過頭審視自己喜歡什麼、擅長什麼，再找到一個適合的方式跟 AI 協作，理解自己這件事情是沒有捷徑的，每個人就是要花很多時間探索。
甚至如果你的興趣就是自己撰寫程式，這個過程讓你感到快樂的話，那或許不用 AI 對你才是最好的。溥澤直樹的專訪中提到了對 AI 繪圖的看法，他說：「因為我覺得繪畫是很快樂的事情，像我可以在工作中找到樂趣的人來說，交給 AI 做不就太可惜了嗎？」。
大眾都在追求的東西，不見得就是適合你，還是得回過頭來理解自己是怎樣的人，對什麼事情充滿熱情，用屬於自己的觀點邁出下一步。
AI 聽不懂人話沒關係，你嘗試著理解你自己更重要。