產品經理用 AI 寫程式的實戰心得 (with Cursor)

過去一個月花了不少時間在 Cursor 上。我認為對於產品經理而言，這類工具的入門門檻可能比其他非技術人員要低得多，畢竟許多方面與我們日常的工作非常相似

2024 年 10 月 31 日

文長，懶得看的可以直接捲到最後看 Takeaways 兼抖內。

過去一個月花了不少時間在 Cursor 上。我認為對於產品經理而言，這類工具的入門門檻可能比其他非技術人員要低得多，畢竟許多方面與我們日常的工作非常相似 — 我仍然認為產品經理最不可替代也最主要的職能是選題，不過對於一些細節與開發過程的參與，至少在我所經歷過的環境裡仍然是免不了的，而這個部分就與 Cursor 在合作上十分雷同。這樣的合作關係是很緊密的，可以說短短三個小時就能走一輪 sprint，也能讓自己去嘗試很多「團隊合作」方式的理想型，畢竟這邊擋你的就是自己的毅力跟知識而已。

當然以目前的狀況，對一個真的完全沒有技術的背景的人來說，在過程中一定還是會遭遇非常多的痛苦。這裡我的觀點從前年底至今大致沒有變：現在還不是點石成金的時刻，你自己本身還是要付出非常多的努力，甚至與其說 AI 工具是在幫技術麻瓜寫程式，不如說 AI 工具是在幫技術麻瓜逐漸學習魔法。當然有一些小東西目前真的已經是只要動動口就可以做到了，不過如果互動或者規則稍微複雜一點，就很難在完全沒有技術知識並且也不學習的情況下好好做出來，這點等一下我要分享的例子裡面應該也可以看到。

目前來說我大致認同一個觀點：AI 當前的能力是一個學習得很廣泛、但也許經驗不足的實習生，如果你認為某件事情跟剛報到的實習生講一下就可以做得很好，那這件事情大概可以給 AI 去做；但如果你也認為可能自己需要提供實習生更多協助才有可能完成，那表示 AI 也會需要很多協助。

以下用一個小程式來分享一下我自己使用的思路。

LookAtMe Timer

先介紹今天的案例：LookAtMe Timer 是一個視覺化的計時器，使用者可以透過拖曳圓形介面來設定時間，並且提供了一些客製化的選項，例如深色模式、鈴聲開關、時間顯示等等。對於這個程式該有怎樣的能耐，在我心中醞釀很久了，畢竟自己也常有帶 Workshop 或讀書會的經驗。過往曾經使用過 Time Timer，喜歡其中的某些部分、但還是有些小地方覺得可以更好，上個月買了 Cursor Pro 就來試試看。從構想、開發到測試，包括基本的 HTML、CSS、JavaScript，以及後來加入的 Playwright 自動化測試，95% 以上的程式碼都是由 AI 撰寫的。

我先用 Composer 做完了基礎的功能，讓這個軟體可以倒數計時、有深色模式，也能改變強調的顏色。另外也做了一個很想要的快捷設定圖示功能：在番茄鐘工作法裡有三種時間長度會不斷出現，第一個是每 25 分鐘一輪的工作時間，每兩段工作時間之間則是一段 5 分鐘休息時間，而每四段工作時間後的休息時間會改為 15 分鐘的長休；我希望有個快速、簡單設定這種時間的功能，那便是快捷圖示。在這個例子裡，我想要進一步讓使用者可以設定自己的快捷圖示，要拿來當泡麵計時器、煮蛋計時器都可以。

於是，第一步我先盡可能提供 AI 足夠多的背景資訊，並且阻止他太快就動手寫程式：

若想一次就把事情說清楚，大概就只會停留在想想… 如果希望前期就能把一個會有複雜互動的東西跟 AI 講完後一步到位，目前我認為失敗率非常高。個人現在習慣的做法是先跟 AI 討論可以怎麼切分這個功能，挑出最重要的部份，實踐該部分以後再來迭代 — 這個過程跟當代的新產品開發流程基本相同，挑出最核心的部分實作後交給客戶驗證假設，回頭調整其中的細節，確認足夠後再往下一個部分拓展。

提供背景資訊的方式很多。我試過先提供一個完整描述、試過給 User Story、試過給競品的參照圖，甚至有把 Story Mapping 的圖直接丟給他看看能玩出什麼花樣。以這次來說，由於程式的功能還很單純、過程中多有註解、當時也已經有（請 AI 寫了）一份還 ok 的 README，所以就直接把整個 codebase 餵給他，效果也還不錯。Composer 裡另外有「Notebook」可以先餵文件給 AI 當作知識庫參考，那反正能抓老鼠就是好貓，體感覺得提供的方式對結果沒有特別影響。

附註：事實上這個最初的 prompt 我也調整了三次，圖中最後兩點就是試著再提示 AI 怎麼重複利用它先前已經做好的東西、迴避與某些程式打架的機會。這邊如果零技術力的話應該是會出現很多額外的程式，但也許仍是可以執行就是。

你可能會注意到在這個例子裡 AI 說明的切分方法大致上是以技術細節為出發點，比較像是瀑布流把程式拆三塊然後分別實踐。這不是我要的，但因為剛好有件事情 AI 沒注意到，所以就告訴他、同時再順便進一步問他會想怎麼分階段實作：

這次 AI 給的就是我要的答案了。其實動手前也有想過幾種拆法，這是其中之一，不過可以的話我傾向不要太早把心裡的想法一股腦丟給 AI。目前的 LLM 還有很多黑盒子，有時讓他自己一步步做還比較快，同時間你有機會檢驗過程、也可能會有美麗的意外。比方說目前這個計時器的設定介面基礎互動方式就是 AI 自己提供的，圖示也是他挑的。我對自己的要求大致上是把目標描述出來，不僅止於「做什麼」而通常也要包含「為什麼」，而有必要的話就加上一些範例以便強調某些容易誤解的地方（你在後面也會看到附上圖解的例子）

對，就是做一般 PM 該做的事。到此，Refinement + Planning 完畢。

由於本來也已經先想過，所以我心裡對每個階段的驗收標準大概有個底（這功能蠻小的所以看官應該多少也會想到要驗收什麼）。早先嘗試過把 Acceptance Criteria 丟給 AI 看他會怎麼寫，不過效果一直都還好；這不代表不需要先想，只是現在主流的想法是提供足夠、但不至於超過的資訊給 AI，避免他神遊去太遠的地方，於是這邊就沒給全。

基礎重構

接著就請他進行第一階段：

自從有了 Composer，我現在大多時候都是直接 Apply All、將所有 AI 建議盡數套用而不檢查，僅在少數狀況下會特別去查閱 AI 寫的東西。以這次來說 AI 寫完我存檔後就進瀏覽器測試了，然後很快就發現不能使用，於是開了 Developer Tools 看有什麼問題；我不特別看錯誤訊息的內容，而是直接丟給 AI 看看能否辨識 — 這點倒是比平常工作輕鬆，一般工作上我還是會先看看使用者回報的是什麼，畢竟亂回報的使用者很多（炸）。

claude-3.5-sonnet 的回應通常都蠻人性化的，非常有趣，有機會大家也可以試試；這個，以及 gpt-o1-mini 的回應目前體感上效果很不錯，而我自己通常先用 claude-3.5-sonnet 來寫，如果幾次不若期待則會切換 model 再試試，「可以換各種 model」是目前 Cursor 相較於 GitHub Copilot 來說還不錯的地方之一，但此類優勢不長久是就是了 — 如果一次就會很準，沒有人會想切來切去的啦。（另一方面這篇文章還沒貼出去的這幾天，Github Copilot 也宣布可以用 Claude 了。）

我自己雖然對網頁技術略知一二，但也很久沒實際開發了，有很多東西不知道該怎麼做。以這個案例來講就出現沒看過的東西，那沒看過就直接透過 Cursor Chat 發問。雖然也許會踩到 LLM 幻想出來的雷，但有兩點讓我現在對這件事情也不算太畏懼：

Cursor Composer 現在有 Checkpoint 功能（仔細看圖中有些地方左側有行小灰字），會幫你記錄暫存點；假設 AI 改錯了沒有效果，我會直接回到原來的時間點重新問一次。當然如果會 git 的話也可以用來達到一樣的效果。
老實講只要能夠達成目的，中間的實踐方式我不一定很在意。那既然已經對於最終的樣貌與驗收標準有概念，無論它怎麼做、我總之就是去驗那個最終的樣貌

AI 寫程式應該會讓所謂的「維護難度」這件事情發展出完全不一樣的意義，這一點我還沒參透，但日後大家應該慢慢地會有感覺。

接下來就是我測到的一些問題，有時可以截圖給 AI 讓他有更多資訊：

你可能會發現圖中我甚至指出了可能有問題的那幾行，但這不純然是我的能力；聰明的你大概猜到，這不是第一次寫這段提示，而是錯誤了幾次無法更正，查閱 AI 嘗試修改的部分後，再回頭使用 Checkpoint 回到原來的時間點重新問一次。

我注意到 AI 改完了以後疑似留了一些還沒刪掉的東西。有鑑於對 AI 還是可以盡量維持對一般人的禮貌免得養成壞習慣，所以還是問問看是不是我誤解了什麼？Cursor 一般來說會向使用者解釋撰寫的理由，所以也可以藉此學習。

到此，我們已經完成了第一階段，過程中我也已經大致把東西驗收完了。先前我會在這個時候要求 AI 自己寫交接文件，當作這位同事寫完了以後要交給下一棒，所以請他把相關重要的資訊先寫一寫，讓下一棒同事（其實也就是這個 AI 的另一個 session）可以很快的接手。不過以 LookAtMe Timer 的例子來講，由於剛好各功能相依性低，外加先前已經有寫 README，所以這次就不使用交接文件概念，而是請他幫忙寫 Commit log。（兩者對人類也許意義相近，但 Cursor 目前似乎沒有閱讀 Commit log 的能力。）

雖然 Cursor 有 Checkpoint 的功能，但對比較複雜的狀況我認為還是用 Git 比較好。當然這對完全沒有技術背景的 PM 來說會有點困難，但也非必備 — 學了讓生活比較好過一點，沒有學的話還是過得去只是比較麻煩，自己決定吧。我其實也只懂基本的 Commit 跟 Merge 等等的概念，看到我 github 的歷程可能很多人會笑出聲來，不過還算夠、假設發生自己不會的東西再問 Cursor 的 Chat 就可以了。

有興趣的話我個人也推薦可以看龍哥的為你自己學 Git。

設定介面

接下來就是第二階段。第二階段的狀況會比較複雜一點，因為在 UI 的互動部分有比較多著墨。事實上 AI 剛寫完也確實發生了比較多問題，我大概看了一下以後決定先確保功能面是正確的再來處理 UI 的部份：

功能面的部分經過推敲，我注意到我原本提出來的某項需求會造成蠻多複雜狀況，而且對使用者可能也吃力不討好。在一般的開發過程上可能這就是 PM 要跟大家跪的地方了，沒有先考慮清楚這個地方的輕重緩急。不過還好在這個數小時 Sprint 的情形下要道歉也蠻快的，所以在這邊提出這項功能不要做。不要做會讓某些事情單純很多，但這邊就反過來是要叫 AI 把東西拔掉了。

個人經驗裡，叫 AI 把東西「拔掉」的失誤率會比「加上去」高很多。這樣講可能也不客觀，因為加上去時就算東西有重複，只要可以用我們（沒看程式）還是會覺得 OK，可是如果沒拔乾淨或拔太多的話就很容易造成別的影響。總之，要把功能拔掉是要特別注意的，這點即使是在真人團隊也一樣。

然後是追加需求跟處理一些 bug：

你可能會注意到我故意留了一些地方讓 AI 自己發揮，那它也確實協助我把動畫跟快速鍵加上去。最後再度 Commit，這個 sprint 也順利結束了。

到此，每個 sprint 我們都交出了可以運作的軟體，即使我在中間任何一點想去睡了，目前發上網站的程式仍然可以使用。

前面提到，這個階段是刻意拆成兩個部分進行。功能面的東西處理完了，接下來才要面對介面的問題。根據過去的經驗，就算一次發現了所有問題，也應該一個一個提出慢慢解，因為太多問題混雜在一起很容易亂。孰先孰後就是 PM 的決斷，在此我認為原則上可以不用過度考慮技術層面，倒不是小看技術觀點的影響，反而單純只是因為我不會有技術觀點，那就別想太多了直接做吧。

因為是介面問題，所以我附上了圖解。目前 GPT 系列跟 Claude 系列的 LLM 大多都有圖像解析功能，個人經驗是在框線圖、示意圖的部分表現都蠻不錯；第二張圖嚴格說來我不確定對他有多少幫助，只是我發現不太好解釋一定要舉例子，所以丟張圖試試看，結果也比想像中完美：

完成後再請他寫 Commit log，然後就可以往我本來認為可能最麻煩、但結果意外很快解決了的第三階段移動。

圖示選擇器

這邊我交給 AI 去設計互動介面，想看看它會做成什麼樣子。我心裡其實有一個最差的版本跟一個比較期待的版本：

要說最麻煩可能也是對的，因為這邊出現了一個介面上面的 bug，一開始完全沒辦法看到他到底做了什麼改變。查閱 Composer 的內容注意到相關的面板真的有加上去、只是不知道為什麼都沒有顯示。來回請 AI 檢查了幾次未果，只好再度開啟 Developer Tools 檢查。

我注意到應該是樣式設定有問題，但這段樣式是程式動態加上去的；嚴格說來當今程式語言幾乎都是高階語言，也就是說會非常接近英文、不至於真的「看不懂」，但我想很多人也跟我一樣沒有耐心去把整段程式看完，所以就把這個錯誤指出，並且請 Composer 判斷其必要性。

有個非常幸運的地方是：剛才說到我有自己比較期待的版本、也有一個最低期待的版本，AI 所設計出來的互動剛好是我最期待的那一個版本 — 沒想到不花什麼力氣就完成了。抓到的錯誤也很快就解掉了，AI 問了我一個問題、我提出看法之後也請他列出他那邊所能判斷的副作用（這階段再把技術考量納進來也不算太晚），非常順暢。

事情做完後 AI 還直接問我要不要寫 Commit log，不得不讚賞這份貼心 :P