提示詞

內容目錄

很多人以為，AI 進入產品開發後，PM 最需要學的是提示詞工程(Prompt Engineering)。會下指令、會整理資料、會讓 AI 生 PRD、寫 User Story、列測試案例，聽起來的確很有效率。以前要花半天整理的會議紀錄、需求清單與競品資料，現在可能幾分鐘就有一版初稿。

但我覺得，未來 PM 更重要的能力，未必是「怎麼讓 AI 幫你寫得更快」。

而是：怎麼把一份規格書寫得足夠清楚，讓 AI 能執行，卻不會在關鍵地方替你做決定。

因為 AI 最危險的地方，往往不是它不會做事，而是它很會把一個模糊的問題，整理成看起來完整、順暢，甚至很有道理的答案。

你問它該優先做哪個功能，它會幫你列評估矩陣。
你問它目標客群是誰，它會生出幾個 Persona。
你問它要不要進入某個市場，它也能整理市場規模、競品定位與風險分析。

問題是，這些內容看起來像決策依據，卻不一定真的來自你的使用者、你的商業條件，或你所在公司的能力邊界。

如果 PM 沒有先定義問題、沒有先講清楚哪些事情已經決定、哪些事情仍待驗證，AI 很容易把空白補滿。最後團隊拿到的，不是一份更好的規格書，而是一份語言完整、責任卻很模糊的文件。

AI 可以協助產品團隊加快執行。

但產品要往哪裡走、什麼事情值得做、什麼風險可以承擔，這些仍然要由人決定。

問題不只是 AI 會不會取代 PM

「AI 會不會取代 PM？」這個問題其實有點太表面。

真正需要擔心的，不是 AI 把 PM 的職位拿走，而是 PM 因為太依賴 AI，慢慢失去自己定義問題與做判斷的能力。

產品經理的工作，從來不只是把需求寫成文件。

PM 要在資訊不完整、不同部門目標不一致的情況下，判斷什麼事情值得優先投入。要理解使用者說出口的需求，和他真正卡住的地方是否相同；也要在商業目標、技術限制、開發時程、成本、供應與售後風險之間，做出有取捨的選擇。

這些事情沒有標準答案。

AI 可以整理訪談逐字稿，卻不會自動知道受訪者說「我想要更多功能」背後，真正的不滿是操作太複雜。AI 可以幫你做競品比較，但不會自然理解某個競品功能雖然熱門，放進你的產品後可能會拉高成本、增加客服負擔，甚至讓品牌定位變得模糊。

更現實的是，AI 沒有真正承擔產品失敗的後果。

它不需要面對專案延遲，也不會處理使用者抱怨、退貨、毛利壓力、供應商交期，或跨部門對產品方向的爭論。它能提供很多可能性，卻無法替團隊承擔選擇其中一條路的責任。

所以，未來 PM 的角色不是「比 AI 更會產出文件」。

而是要成為那個能把模糊現實轉成清楚決策條件的人。

一份好的規格書，先把「誰能決定什麼」寫清楚

過去的 PRD 常被理解成開發文件：功能要做什麼、流程怎麼走、驗收標準是什麼。

AI 協作之後，規格書多了一個新用途：它也是一份工作邊界文件。

它必須讓 AI、工程、設計、測試與其他協作者知道，哪些內容是已經確認的決策，哪些內容可以被延伸，哪些只能提出選項，不能自行下結論。

我會把它簡單拆成三層：

層級	核心問題	主要負責者	AI 可以協助的事情
策略層	為什麼做、為誰而做、什麼不做	PM、產品負責人、核心決策者	彙整研究資料、整理競品、提出待驗證假設
產品層	要解決什麼問題、功能範圍與優先順序	PM、設計、工程共同定義	拆解 User Story、整理流程、補足邊界情境
執行層	如何完成、如何測試、如何交付	工程、設計、QA、營運	產生初稿、測試案例、格式化文件、追蹤差異

這種拆法的重點，不是讓每個角色各自畫地盤。

而是避免一個常見狀況：PM 只丟出一句「我們要提升留存」，接著讓 AI 自己延伸成一整套功能方案。AI 當然做得到，但它會根據通用模式生成答案，不會自動知道你們的使用者為什麼流失，也不會知道公司是否有能力維護那些功能。

策略層裡的內容，最好由人明確寫下來。

像是：

這次要解決的使用者問題是什麼？
目標使用者是誰，不包含誰？
這個專案和公司的產品方向有什麼關係？
目前已知的技術、成本、法規或時程限制是什麼？
哪些假設仍然沒有被驗證？
這一版刻意不做什麼？

這些看起來不像 AI 提示詞，卻比提示詞更重要。

因為沒有這些前提，AI 只會把大家沒有講清楚的地方，用一套看似合理的通用答案補起來。

AI 可以補細節，但不能替你定義問題

假設 PM 收到一句需求：「使用者希望有 AI 報表功能。」

如果直接丟給 AI，請它規劃功能，很可能得到一份看起來不錯的規格：

自動彙整數據
生成洞察摘要
提供趨勢預測
推薦下一步行動
以儀表板呈現重點指標

問題是，這些功能可能都很合理，卻未必是使用者真正需要的東西。

「想要 AI 報表」背後，有可能是：

使用者沒有時間整理資料。
現有報表太多，找不到真正重要的指標。
管理者需要對外報告，但不知道怎麼解讀數字。
團隊資料散落在不同系統，手動整併很痛苦。
使用者不是缺報表，而是缺少能採取行動的判斷依據。

這些問題的解法可能完全不同。

如果痛點是資料分散，先做 AI 摘要可能只是把混亂變成一段更漂亮的文字；如果痛點是指標太多，產品可能需要的是更好的資訊架構，而不是更多生成內容；如果使用者最在意的是決策風險，系統就必須能回溯資料來源，不能只給一個看似自信的結論。

AI 很適合在問題已經被定義後，協助把工作拆細。

但「問題是什麼」，不能直接外包。

這也是 PM 和單純文件管理者最大的差別。

規格書應該保留「不可由 AI 決定」的欄位

如果要讓 AI 參與產品規格書，我認為最實用的做法，不是要求 AI 永遠不能提出建議。

AI 可以提建議，也可以協助發現遺漏。

真正重要的是：規格書裡要清楚標示，哪些欄位只允許 AI 依據已知內容整理，不能自行推論或改寫決策。

以下是一個可以直接使用的結構。

一、決策背景：由人撰寫，不讓 AI 自行補完

這一段不是摘要，而是讓所有協作者理解「這個產品為什麼存在」。

可包含：

使用者問題與具體情境
已完成的研究與證據來源
商業目標與衡量方式
產品定位與目標客群
已知限制：預算、時程、法規、技術、供應或資安條件
不在本次範圍內的事情
已做出的關鍵決策與原因

這裡最重要的一句，往往是：我們決定不做什麼。

因為產品失控，通常不是團隊不知道要做什麼，而是每個人都覺得「這個也可以順便加進去」。

二、可交給 AI 協助的執行任務

當策略與範圍已經明確，AI 可以幫很多忙。

例如：

根據既有需求整理 User Story
把流程描述轉成驗收條件
依照指定格式產生測試案例初稿
從客服紀錄或訪談內容中歸類重複問題
比對規格版本，找出需求變更
將會議紀錄整理成待確認事項
提醒文件中可能遺漏的例外情境

這些任務的共同點是：AI 在協助處理資訊與執行細節，不是在替團隊選方向。

三、必須回到人類審核的決策點

即使 AI 已經產出內容，以下項目仍應由 PM 或跨部門決策者確認：

功能優先順序
使用者問題是否真的成立
KPI 是否合理
目標客群與市場定位
是否投入開發資源
是否接受特定技術、資安、隱私或法規風險
上線時程與商業承諾
產品下線、轉向或停止的判斷

這些不是因為 AI 完全不能碰，而是它不該有最後決定權。

AI 能夠協助列出選項與風險，但不能替公司承諾一件做不到的事。

Prompt (提示詞 / 指令)的重點，不是寫得像咒語

很多人開始研究 Prompt Engineering 後，會希望找到一個萬用公式。

角色、情境、任務、格式、限制條件，這些確實有用。但對 PM 來說，更重要的不是把提示詞寫得多華麗，而是讓 AI 知道自己的工作範圍。

如果這樣說也是可以….

請你幫我規劃一個提升使用者留存的 AI 功能。

但在詳細一點會更好…

以下內容是已確認的產品決策，請勿修改、延伸或重新排序。

目標使用者：使用產品超過三個月，但每週使用頻率持續下降的既有客戶。
已知問題：使用者無法快速找到與自己工作相關的功能，因此只使用最基本流程。
本次目標：提升首次完成核心任務的比例，不以增加使用時數為唯一指標。
限制條件：第一版不得蒐集新的敏感個資；開發時程為八週；不可新增付費第三方模型服務。
不在範圍：社群功能、推薦廣告、遊戲化機制。

請根據以上條件，產出三種功能流程草案。每一種草案需包含：使用者觸發情境、操作步驟、預期價值、可能風險與待驗證假設。
不要評估商業優先順序，不要自行增加未提供的使用者需求。若資訊不足，請列出問題，不要自行假設。

這段提示詞 / 指令的重點，不是它很長。

而是它把「AI 可以做什麼」和「AI 不可以決定什麼」分開了。

AI 最適合的角色，不是被交代「幫我想答案」，而是被交代「在這些已知條件下，幫我把可執行的選項整理出來」。