我終於把第一個 Edge AI Use Case 定下來：

Unmanned Area Monitoring。

接下來就是 PM 最熟悉、但也最容易寫到失控的東西：PRD。

很多人想到 PRD，可能會覺得就是：

「把需求寫清楚。」

但當你的 Team 只有：

1 PM + 1 Engineer

而且還沒有 GPU、沒有完整 AI Team 時，

我反而覺得 PRD 更重要。

因為工程師的時間非常有限。

我寫錯一個需求，浪費的不是文件時間，而是工程時間。

第一個問題：PRD 到底要寫多細？

如果今天我要做一個大型產品，我可以寫非常完整的 PRD。

但現在只有一位 Engineer。

如果我花兩週寫了一份 50 頁 PRD，工程師看到可能會先問：

「所以第一版到底要做什麼？」

所以我反而要求自己：

PRD 不一定要長，但一定要讓工程師知道 Priority。

我會先回答五件事情：

Why？

為什麼要做？

Who？

誰會使用？

What？

第一版到底要做什麼？

How？

大概怎麼運作？

How do we know it works？

怎麼判斷 PoC 成功？

我的第一版 PRD，其實沒有想像中複雜

以 Unmanned Area Monitoring 為例。

User Problem

工廠在非工作時間仍需要監控特定區域，但不希望一直安排人員盯著 Camera。

Use Case

當有人進入指定區域時，系統自動產生事件並通知管理者。

MVP Flow

Camera　-> Person Detection -> Geofence Rule -> Intrusion Event -> Alert / Recording

這時候工程師其實已經可以開始拆工作了。

但 AI Product 的 PRD，有一個特殊地方

一般 Software PRD 可能會寫：

「系統需要偵測人員。」

但 AI Product 不能只寫這一句。

因為 AI 有一個很麻煩的特性：

它不是 100% 正確。

所以 PM 必須開始定義：

什麼叫「成功」？

例如：

• Confidence Threshold
• Detection Latency
• FPS
• 支援幾路 Video Stream
• Edge Device CPU / NPU 使用率

這些東西以前可能是 Engineer 的技術問題。

但在 AI Product 裡， 它們會直接變成 Product Requirement。

例如 Confidence Threshold

假設 AI 偵測到一個 Person。

Confidence：

0.52

到底算不算？

如果我們設定：

Confidence > 0.5 → Event

可能會抓到很多誤判。

如果設定：

Confidence > 0.9 → Event

又可能漏掉真正的人。

所以 PM 不能只寫：

「支援 Person Detection。」

還需要跟 Engineer 一起定義：

什麼條件下，我們認定 AI 的結果足以觸發 Business Event？

這就是 AI PRD 跟一般 Software PRD 很不一樣的地方。

所以會變成 Confidence > 0.9 + Time > 20s → Event

第二個問題：哪些功能現在不要寫？

這可能才是我這次最重要的 PRD 經驗。

因為資源只有一位 Engineer，

所以我必須非常清楚地寫：

MVP 要做

• Video Source
• Person Detection
• Model Selection
• Confidence Threshold
• Class Filter
• Geofence
• Intrusion Event
• Alert
• Recording

MVP 不做

• 自己訓練 Model
• 複雜行為辨識
• 大規模 Cloud Management
• 多租戶
• 完整 Dashboard
• 所有 Camera 型號支援

這些功能不是「不重要」。

而是：

現在不是 Priority。

AI PM 很容易犯的錯，就是把「未來可能需要」全部放進第一版。

但對兩個人的 Team 來說，

每增加一個 Feature，就代表另一個 Feature 可能做不完。

我也開始把需求分成三層

在資源這麼有限的情況下，我發現 不是所有需求都值得同時做。

所以我開始把需求分成三層：Must Have、Should Have、Could Have。

① Must Have｜沒有它，PoC 就無法驗證

這一層只放「一定要做，而且做完才能證明 Use Case 成立」的功能。

例如：

Person Detection + Geofence + Event

也就是先回答最核心的問題：

AI 能不能在 Edge 上偵測到人，判斷他有沒有進入指定區域，並且產生一個事件？

只要這條鏈跑通，PoC 就成立。

② Should Have｜讓 Demo 更完整

第二層是「不是 PoC 成立的必要條件，但有了之後，Demo 會完整很多」。

例如：

Recording + Event History

這些功能可以讓我們不只是「看到 AI 偵測到了」，而是能夠：

• 回看事件發生的畫面
• 查看歷史事件
• 讓使用者更容易理解整個 Use Case

所以它們會增加 Demo 的完整度，但不應該阻礙第一階段驗證。

③ Could Have｜產品化再做

最後一層，就是「現在做了很好，但現在不做也不影響 PoC 成功」。

例如：

更多 Model、更多 Action、Cloud Management、AI Agent

這些其實都是未來產品化很重要的能力。

但如果一開始就全部做，很容易變成：

想做一個完整產品，結果連 PoC 都還沒跑起來。

所以我的原則變成：

先把 Must Have 做到可以證明價值，再逐步往 Should Have、Could Have 擴充。

這也讓我第一次真正感受到：

PM 的價值，不只是把需求列出來，而是知道什麼現在不能做。

這樣 Engineer 可以很清楚知道：

如果時間不夠，先砍哪裡。

PRD 最後一定要有 Acceptance Criteria

我不希望最後 Demo 做完，大家才開始討論：

「這樣算成功嗎？」

所以我會在一開始就定義：

例如：

Scenario：Person enters restricted area

Given：

Camera 正在監控指定區域。

When：

AI 偵測到 Person，且 Person 進入 Geofence。

Then：

System should generate an Intrusion Event.

並且：

• 顯示 Event
• 發送 Alert
• 保存影像

這樣 QA 可以測，

Engineer 可以開發，

PM 也可以知道：

我們到底有沒有完成。

這次讓我重新理解 PRD

以前我覺得：

PRD 是把需求寫完整。

現在我更認為：

PRD 是把「不確定性」變小。

尤其是 AI Product。

因為我們同時面對：

Customer Uncertainty -> 客戶到底需要什麼？

AI Uncertainty -> Model 到底準不準？

Hardware Uncertainty -> Edge Device 到底跑不跑得動？

Product Uncertainty -> 這個 Use Case 到底有沒有價值？

所以好的 PRD，不是寫得越厚越好。

而是讓 Team 可以用最少的資源，

快速驗證最重要的假設。

這也是我這次做 AI PoC 的一個原則

因為我們沒有：

GPU

沒有：

AI Research Team

只有：

1 Engineer + 1 PM + 1 QCS6490

所以我們的 PRD 也必須符合現實。

我不會寫：

「我們要打造一個世界級 AI Platform。」

我會寫：

「我們先用一個可控的 Use Case，驗證 Edge AI 能不能真正解決客戶問題。」

如果成功，

再擴充。

如果失敗，

也能快速知道問題在哪裡。

Day 5 的結論

所以現在回頭看，我覺得：

AI PRD 最重要的不是 Feature List。

而是把這四件事情串起來：

1.Customer Problem

2.Use Case

3.AI / Technical Constraints

4.Measurable Acceptance Criteria

最後再加上一個非常重要的東西：

Scope。

因為在資源有限的情況下，

知道什麼不做，跟知道什麼要做一樣重要。

而當 PRD 終於寫完之後，

真正的挑戰才開始。

因為我們不能只靠文件證明這個產品可行。

我們必須真的把它跑起來。

而第一個撞上的問題就是：

QCS6490 到底能不能真的把 AI Inference 跑在 NPU 上？