「為什麼不直接用 OOO？」

每次跟同事介紹「鼠勾以」的時候，幾乎都有類似：

「為什麼不直接用 ChatGPT 就好？」
「GitHub 上一堆很強的 Skill，幹嘛不直接拿來用？」
「Cursor、Claude Code 都這麼強了，拿來直接開寫不就好？」

每個問題都很合理，我當時也都認真想過。所以今天就把那些選項全部攤開來講：商業工具、通用 LLM、開源工具、IDE 裡的 AI 助手。看完，大概就知道我為什麼最後還是自己動手做了一個。

如果你也在想做類似的東西，可以順便當參考。但你不一定要做 Custom GPT，選你的公司能用、你能維護、同事學得會（大重點） 的那一個就好。

陣營一：商業工具

PRD 模板（Word / Notion）

最常見、最便宜的選項，每家公司應該都有一份。

優點：免費、結構清楚、零學習成本。

缺點：

• 靜態文件：告訴你「要寫使用者旅程」，但沒告訴你怎麼推導；叫你「列出例外情境」，但你根本不知道有哪些可以列。
• 不會挑戰：你寫「目標是降低客服進線」+「不做自助查詢功能」，模板照單全收，沒人會跳出來問「那客服進線要怎麼降」。
• 依賴填寫者經驗：寫得好的人本來就不需要模板，寫不好的人填到一半就會卡住。

太多份「填到 30% 就被擱置」的模板躺在共用資料夾裡，沒人想接手。

共編文件（Confluence / Google Docs）

優點：協作好、版本好追、留言串永遠熱鬧。

缺點：跟 PRD 模板的根本問題一樣，只是個盛裝結果的容器，沒辦法引導用戶怎麼想。

陣營二：通用 LLM

通用 ChatGPT / Claude / Gemini

優點：能對話、能追問、可以用 System Prompt 簡單客製。

缺點：

• 沒有專屬知識庫：不認識你公司的術語、流程、限制。
• 太順從：你說什麼它就同意什麼，不會 push back。
• 沒有結構化的問題庫：每次對話從零開始，沒有題目順序。
• 沒有評分機制：你寫到一半完全不知道完整度走到哪，沒辦法判斷「這份夠不夠拿去找 SA」。結果隨便寫一寫就拿來找，又再開一場澄清會。
• 產出格式不一致（給模板也救不了）：你可能會說：「那我給它一份模板要求對齊不就好了？」格式對齊只是表象，它仍然不會挑戰你模糊的回答、會用流暢句子把空洞包起來、還會自己腦補你沒提的功能。漂亮的空殼。

對方曾經拿 ChatGPT 測試跑過一次需求整理。文字流暢、看起來很專業，結果AI貼心的幫補了一段「AI 個人化推薦引擎」。他從來沒提過，當他開心地把整份貼給 SA，SA 看了五分鐘抬起頭：「請問這個 AI 推薦引擎是哪來的？」

需求釐清要的是一個會跟你 push back 的對手；漂亮的代筆只會幫倒忙。

陣營三：開源工具

這個陣營是開發朋朋最常推薦的：

Skills SDK / OpenAI Assistants API

優點：技術上真的很強：Tool Use、RAG、多輪推理、外部 API 都能串。

缺點：

• 需要工程資源：Python 或 TypeScript、API 串接、部署、監控。
• 要會 prompt engineering 與 evaluation：寫得好不好差很多。
• 內部落地關卡多：要打通 IT、資安、預算、SRE。
• 使用門檻：做完之後還要替內部同事做一個 UI，不然你不會要需求方PM 去用 curl 吧。

最重要的是，我自己也不會ＸＤ

askme / askyourdoc / RAG 套件（LangChain / LlamaIndex / Haystack）

優點：能載入大量文件、根據文件回答。

缺點：

• 本質是檢索增強，不是引導對話：擅長「回答你問的」，不擅長「主動來問你」。
• 沒有結構化的問答節奏：預設使用者會一次丟一堆資訊進來，不是一題一題引導。
• 需要工程維護：embedding、vector store、retrieval pipeline 每一層都要顧。

它們解的問題是 Q to A。我要解的是 empty mind to structured Q&A。根本不是同一條路。

Agent 框架（AutoGen / CrewAI / LangGraph）

優點：可以做複雜的多 Agent 協作。

缺點：

• 過度設計：我要的只是一個會問問題的助手
• 不穩定：Agent 越多，意外越多，抓問題也越難。
• 公司不會買單：成本估下來應該是會爆炸

陣營四：IDE 內的 AI 助手（Claude Code / Codex）

這幾年最強的一波。在 IDE 裡跑、能讀整個 repo、能改檔、能 commit。對工程師來說真的香。

但對「需求方PM」這個目標用戶來說，問題很現實：你要他先學 git，以及 會編輯Markdown格式文件 。

• 「git clone」是什麼意思
• 「branch」是什麼
• 「我剛剛改了什麼可不可以還原」
• 「為什麼我的東西不見了，是不是按錯了」

這跟努不努力無關，學習曲線真的太陡了。
ps. 但在此衷心的感謝團隊工程師願意教學我，講解到我聽得懂，以及推薦 為你自己學git 這本書，讚讚！

更現實的問題是：大部分需求方PM 對到使用git時都是「伸手牌」，不是貶意，是分工。他們的工作本來就是「描述需求、跟業務 align、追廠商」，不是用 terminal。要他們連問 AI 都還要先學 git、學 prompt、學怎麼看 diff，這條路在第一步就會勸退九成的人，也無法強迫對方使用

但我的目標，是要服務的是那些本來就不需要會 IDE 的人，讓需求方PM 在自己熟悉的 ChatGPT 介面裡，被一個工具一題一題引導，就能產出跟資深 PM 寫得差不多的 PRD。

畢竟，PRD 是整個 SDLC 導入 AI 的第一步。如果第一步就把人擋在門外，後面所有的AI開發、自動化測試、AI code review 都是滾不起來。

對我來說，「公司能否落地」是評估時的第一順位，再來是「使用者是否真的會用、願意用」。

為什麼還是需要鼠勾以

把上面這些攤開來看，我要做的事其實沒那麼複雜：讓不會寫需求/想不明白需求的PM，被一個耐心的工具一題一題引導，完成一份 PRD。

商業工具能落地，但不會引導也不會挑戰。通用 LLM 會聊天，但沒結構也沒專屬知識。開源工具技術上最強，但落地成本太高，而且大多解的根本是別的問題。IDE AI 助手對工程師是神，對需求方PM 是高牆，但我服務的就是需求方PM。

目前的理念是「賦能」，不是「增強」。也就是說，我的目標用戶是「原先沒辦法做到」，但是搭配工具之後，「就有了可以做到這件事情的能力」。

這樣的情境會需要什麼呢？需要的是一份結構化的問題庫、一個會挑戰的助手、一套讓使用者知道自己寫到哪了的評分機制、還有一個固定的產出模板。

Custom GPT 把這四件事都能做到。雖然不是最強的工具，但對這個情境來說夠用，而且現在能使用，也獲得使用者的正向好評回饋。

總結

如果你也在想做類似的東西，我想分享的是：選型不要被資源限制住想像，但要被資源限制住範圍。

你公司能用什麼、你能維護什麼、你同事學得會什麼，這三件事框出了你的可選範圍。在這個範圍裡，找一個剛好夠用的就好。

Day 4 我會把「鼠勾以」的設計目標完整講一次：手把手、低門檻、有挑戰、能落地，還有在「公司只有 Custom GPT」這個限制下，怎麼把這四件事各自做到極致。

這是 iThome 鐵人賽系列文章。明天見。