現在用 AI 寫 PRD，真的很快。
給它：
URD
+
Meeting Notes
+
現有 System Context
幾分鐘就可以生成：
Background
User Scenario
User Flow
Business Rule
Exception
Acceptance Criteria
甚至連我沒寫到的地方，它都會很「貼心」地補完整。
所以如果把 PM 的工作理解成：
把 Requirement 整理成一份 PRD。
那這件事情，確實正在快速被 AI 壓縮。
但我自己真的做 Project 時，感受反而很明顯：
PRD Draft 可以很快生成，但真正的 Product Detail，還是得靠近 Business 一層一層摳出來。
例如我之前做一個申請 System。
其中有個很普通的 Requirement：
User 可以把申請資料 Export 成 Excel。
丟給 AI，它很容易寫成：
User 點擊 Export
↓
System 取得篩選後資料
↓
產生 Excel
↓
User Download
完全合理。
但真的開始對 Requirement，問題才出現：
Excel 到底要有哪些欄位？
申請人？申請時間？目前狀態？審核人？歷史紀錄？
再聊下去才發現：
User 要這份 Excel，不只是自己看，而是要拿去跟另一個單位溝通。
那真正的 Requirement 就變成：
誰拿這份資料？
下一步要做什麼？
另一方需要什麼？
哪些資訊可以被看到？
雙方現在怎麼溝通？
這些 Context 很多根本不在原始 Requirement 裡。
它存在不同人的腦袋裡。
另一個例子是交通預約 System。
如果只看大方向，其實很標準：
選日期
↓
選路線
↓
選班次
↓
預約
↓
查看 / 取消
現在讓 AI 參考成熟產品，很快就能生成 User Flow、PRD，甚至 Prototype。
但真的放進公司裡，問題會變成：
不同職位可以預約什麼？
不同職責有沒有不同 Rule？
特殊時間怎麼辦？
Policy 調整後，哪些 User 一起受影響？
這些不是：
「交通預約產品通常怎麼設計？」
可以回答的。
因為它屬於這家公司自己的：
Policy × Organization × Workflow × Exception。
企業 Product 真正難的，往往也不是 Happy Path，而是：
Rule
Boundary
Exception
Dependency
Permission
Risk
Trade-off
真正的問題不是 AI 不夠聰明。
而是：
很多 Organization Context，根本還沒有進到 AI 的 Context 裡。
第一層是：
Structure
Summary
Wording
Formatting
First Draft
這一層，我很放心交給 AI。
第二層是：
Behavior
Business Rule
Boundary
Exception
Dependency
Risk
Trade-off
AI 出現之後，我反而希望把更多 PM 的時間，從第一層移到第二層。
寫到這裡，我其實很好奇：
這只是我自己的工作感受，還是外面的公司對 PM 的期待真的正在改變？
所以我去看了一些最近的 Product Manager JD。
我刻意不只看 OpenAI、Anthropic 這種 AI-native Company。
因為如果本來就在做 Model / Agent，PM Technical 一點很合理。
我更想知道的是：
像 Microsoft 這種大型 Software Company，對一般 Product Management 的工作方式有沒有開始改變？
結果滿有意思。
Microsoft 最近一個 Microsoft 365 Core Platform 的 Principal Product Manager 職缺，直接把這個 Role 稱為：
AI-first Product Management
它要求 PM 在原本的 Product Management 工作之外，使用：
AI Agents
Automation
AI-driven Analysis
AI Prototyping
去做：
分析 Telemetry
找問題
Model Trade-off
Prototype Solution
加速 Decision
也就是說，AI 不只是：
「幫我把 PRD 寫快一點。」
而是開始進入：
Discovery → Analysis → Prototype → Decision
整條 PM Workflow。
Reference：
Microsoft｜Principal Product Manager - Microsoft 365 Core Platform
另一個 Microsoft 的 Principal Product Manager JD，開頭甚至直接問：
Are you a Product Manager who builds?
這個 Role 要求 PM：
日常使用 AI Tools
自己 Prototype Product Concept
快速 Experiment
用 Data 驗證 Judgment
跟 Engineer 一起做 Trade-off
其中有一句我覺得非常值得注意：
Use AI tools to prototype workflows, validate product ideas, or directly shape what got built, not just to draft documents faster.
翻成 Product 工作語言，大概就是：
不要只拿 AI 來把文件寫快，而是拿 AI 直接驗證 Product Idea。
Reference：
Microsoft｜Principal Product Manager - Agentic Engineering Platform
因為它不是：
PM 要變成 Engineer。
而是：
PM 被期待可以自己多走幾步。
以前：
有 Idea
↓
寫 Requirement
↓
找 Designer
↓
找 Engineer
↓
看到第一個可以操作的版本
現在：
有 Idea
↓
AI Research / Analysis
↓
自己做 Prototype
↓
找 User 驗證
↓
帶著更成熟的問題
跟 Designer / Engineer 討論
PM 跟真正 Product 之間的距離正在縮短。
以前 PM 花很多時間：
PRD
User Story
Acceptance Criteria
Meeting Summary
現在這些工作 AI 都可以大幅加速。
PM 可以把更多時間移到：
Priority
Trade-off
Boundary
Decision
真正的問題不再只是：
「PRD 有沒有寫完整？」
而是：
「我們做的 Product Decision 對不對？」
以前：
「我寫給你看。」
現在：
「我先做一版，我們一起操作看看。」
PM 不一定需要寫 Production Code。
但 Prototype 能力開始變成一種新的 Product Literacy。
因為有些 Requirement：
操作一次，比寫三頁 PRD 更容易發現問題。
以前一個問題可能要：
找 Analyst 拉 Data
找 Designer 畫 UI
找 Engineer 看 API
現在 PM 可以先：
AI + Data 做 First Analysis
AI + Prototype 驗證 Flow
AI 幫忙理解 API / Technical Context
不是不需要 Analyst、Designer、Engineer。
而是：
PM 可以減少低價值 Handoff，再帶著更成熟的問題去找專業角色。
這一點反而是我覺得 AI 時代更重要的。
因為當 Build 越來越容易，
另一個風險會出現：
每個人都可以很快 Build 自己想要的東西。
假設：
HR 自己 Build 一套
Finance 自己 Build 一套
Operation 自己 Build 一套
每一套單獨看，都解決 User Problem。
但放到公司層級可能開始出現：
同一份 Data 有三個版本
同一個 Capability 做三次
不同 System Rule 不一致
Permission 各自設計
Sensitive Data 被不同 Tool 使用
System 彼此無法整合
所以 Build Cost 越低，
PM 反而越需要問：
這件事情放進 Whole System 後會發生什麼？
我覺得這個 Distinction 很重要。
如果今天你做的是：
E-commerce
Fintech
HR System
SaaS
Internal Tool
你的 Product 不一定突然要變成 AI Product。
但你做 Product 的方式，很可能已經開始被 AI 改變。
從 Microsoft 最近的 PM JD，也已經可以看到一些訊號：
AI-assisted Analysis
Rapid Prototyping
Technical Fluency
Data-driven Validation
Systems Thinking
開始進入 PM 的工作方式。
所以真正的變化可能不是：
「每個 PM 都要轉型成 AI PM。」
而是：
「AI 正在提高一般 PM 的能力基準線。」
我會把它畫成：
← 更靠近 User / Business
PM
更靠近 Data / Technology →
一邊更靠近 User：
Context
Workflow
Problem
Business
另一邊更靠近 Technology：
Data
API
Prototype
Technical Constraint
而中間那一段：
整理資訊
寫文件
傳遞 Requirement
正在被 AI 大幅壓縮。
這不代表這些事情不重要。
而是：
它們可能慢慢從 PM 的核心差異化能力，變成基本能力。
我現在其實很樂意讓 AI 幫我寫：
PRD
Summary
Flow
First Draft
因為當這些事情變快之後，
我可以把更多時間留給：
Context
Judgment
System Thinking
Technical Fluency
Validation
Communication
所以我不覺得答案是：
PM 不用寫 PRD 了。
而是：
「會寫 PRD」，越來越不足以定義一個好的 PM。
AI 不一定把每個 PM 變成 AI PM，但它正在提高一般 PM 的能力基準線：少一點只負責描述，多一點自己探索、驗證與判斷。
以前我們可能一直問：
「PM 會不會被 AI 取代？」
但現在我反而覺得，更值得問的是：
如果 AI 已經讓一個 PM 可以自己多走兩三步，那未來公司期待一個 PM 能走到哪裡？
iThome鐵人賽
看影片追技術