在實際動手之前，能夠有清晰的思路知道接下來要做的事有什麼，是一件相當重要的事！
有的時候靈感一來，就打開電腦開始寫 Code，做到一半發現卡住要 Debug、有個功能一直做的沒有很好，也卡住，原本有個全局的開發思路，放著放著也就忘了。
這時候我會做的事就是把所有想過的重點記錄下來，列成一份待辦事項，草稿大致就長
如果要更方便釐清需求、排開發時程、記錄每項的細節，甚至是溝通和如何驗收，我們便可以把這份草稿轉換成一份 PRD，這一講就來聊聊它！
所謂的 PRD，全稱為 Product Requirements Document，是一份用來定義產品功能和需求的文件，通常會包含以下要素：目標、使用者與情境、範圍、功能需求、非功能需求、驗收標準、里程碑。
我認為 PRD 是一個幫助我們不斷明確需求和驗收方式的模板，也並沒有、不需要很制式的章節。說白一些，PRD 就是一份 Check list 讓我們看看有沒有什麼東西忘記考量了。
所以就部落格的開發來講，我們可以定義清楚誰會在什麽情境瀏覽，例如「程式新手通勤的路上用手機閱讀技術科普文章」，這樣所謂的 User Story 可以幫助我們在定義需求時聚焦在 RWD 的設計、排版成更圖文並茂。
又或是比較常被忽略的非功能需求（Non-functional requirements），提醒我們要注意一些效能、維運上的指標，例如前面提到的 LCP 要小於 2 秒、100 篇文章的建置時間要小於 1 秒等等。
而現在（2025），我覺得最最重要的事情就是，這個大 AI 的時代有了這樣一份文件，完全可以實踐 Vibe Coding 的精神，餵下這份 PRD 來產出一個初版的部落格，經過不斷次與 AI 問答迭代後就能有個一定品質的部落格！
因此，寫 PRD 的重點就會在，讓我們自己的思路清晰，知道全局的方向；如果要搭配 AI 服用，如此也才能更精準的讓 AI 幫我們做出符合期待的產品。
接下來分享我在建構部落格時寫的 PRD，由於部落格是屬於個人開發，因此我更著重一些細節上的定義，主要提醒我自己想過架構具體長什麼樣子，功能有什麼、怎麼驗收，並且時刻維持文件的精簡。
那麼就來看看我的目標吧：
建立個人部落格，作為技術內容、個人見解的分享平台，同時提供實用的互動小工具
而我要開發的範圍則包含以下內容：
一份需要給整個團隊，甚至是跨團隊看的 RPD 可能會寫得很詳細，定義的清清楚楚，然而當開發者只有一個人，也是自己，若定義的太複雜反而會為了寫 PRD 而寫，反而讓複雜度提升、開發效率降低。
所以我覺得手刻部落格的這樣的小型專案，所寫 PRD 的大方向就是「當未來的自己看了能快速進入狀況」而寫的簡潔內容。
同樣道理，下面要分享的「需求」和「驗收標準」也是以同樣的方向撰寫。
首先是功能需求（Functional Requirements），也就是把網站上什麼功能是看得見、摸得著的寫下來，像是頁面有什麼按鈕、點擊會發生什麼事。
我習慣在每個需求上加上標號，例如 FR-1-2、FR-3-4 來表達某個需求（FR 即表示 Functional Requirements），方便整理有哪一些需求已經開發完了，也比較好在最後寫測試驗證的時候，用標號來對應哪些需求有被測項覆蓋。
下面為功能需求的部分節錄：
## 1. 首頁
- **FR-1-1**: 在 Header 提供連結至所有四個主要區塊（專題、工具、隨筆、關於）
- **FR-1-2**: 顯示主要專題（例如：網路通訊輕鬆聊、全端網站開發）
- **FR-1-3**: 顯示每週最熱門文章及總閱讀量最多的文章（各前 5 名）
- **FR-1-4**: 顯示兩個精選工具
- **FR-1-5**: 顯示最新的 5 篇技術文章、5 篇非技術文章
- **FR-1-6**: 在 Footer 列出四個主要區塊、法律相關連結（隱私權政策、版權聲明、免責聲明）
## 2. 專題
- **FR-2-1**: GitBook 風格佈局，左側有 Sidebar（手機版自動隱藏）
- **FR-2-2**: 顯示各個專題連結在最上方，以 Menu 方式呈現（網站 Header 下方）
- **FR-2-3**: 在專題區塊下包含 Design System 定義
## 3. 隨筆
- **FR-3-1**: 按時間順序顯示文章（由新到舊）
- **FR-3-2**: 兩大主要分類：技術、非技術，兩個進入點，預設顯示為技術首頁
- **FR-3-3**: 標籤系統，每篇文章可選零至多個標籤
- **FR-3-4**: 標籤列表，顯示所有被使用的標籤
- **FR-3-5**: 個別標籤頁面顯示相關文章
- **FR-3-6**: 文章列表分頁功能，每頁預設 10 篇文章（技術及非技術首頁、個別標籤頁面）
- **FR-3-7**: 彙整頁面，一句年月分組顯示文章
## 4. 單篇文章
- **FR-4-1**: 專題及隨筆共用相同文章模板
- **FR-4-2**: 文章顯示：標題、建立時間、更新時間、分類、標籤、內文
- **FR-4-3**: 每篇文章右側顯示目錄 (ToC)
- **FR-4-4**: 注釋懸浮功能，在文章內可置入 ^1、^2 字樣，Hover「註?」時會顯示簡短內容
- **FR-4-5**: 手機版文章右下角顯示「向上箭頭」按鈕，能快速回到頁面頂端
上述就是要刻出這個部落格的主要功能，列出每個功能的時候，我其實不會寫的太細，也沒有必要寫的太細。
例如 FR-2-1 定義的「GitBook 風格佈局，左側有 Sidebar」這個功能需求，所謂 GitBook 風格到底如何、Sidebar 的具體規格又是什麼？
我們雖然可以把風格明確定義成：「左側 Sidebar：寬度 300px，背景顏色 #F8F9FA，字體大小 14px」、「主標題 24px、700 weight，次標題 20px、600 weight，…」等等，然而，在真的動手做之前，我們其實並不知道怎麼做比較好，這份 PRD 是隨著時間而迭代變得更完整的。
因此，我只會在列需求的時候，記錄重點的內容，並且一邊開發一邊修改。也因如此，這裡的需求要寫得簡潔，才能應對隨時更動的需求。
再來談到一些比較「看不見、摸不太著」的需求：非功能需求（Non-functional requirements）：通常會用來定義我們希望整個產品的品質到達怎麼樣的水準，包含效能、安全性、維護性等等，例如頁面載入時間、網站建置時間等等，就屬於非功能需求。
同樣的，我也習慣加上前綴，取非功能需求的首字母當 NFR 成標號開頭，下面為部分節錄：
## 1. 效能
- **NFR-1-1**: 首頁與文章頁面在 CWV 皆達到 Google 推薦門檻
- **NFR-1-2**: Lighthouse SEO 分數維持高標準
- **NFR-1-3**: 100 篇文章的建置時間 ≤ 2 秒
## 2. 法規遵循
- **NFR-2-1**: 開源授權合規（僅使用寬鬆授權之套件）
- **NFR-2-2**: 基本 GDPR 相容
上述的「非功能需求」在只有一個人的開發流程上，也是維持較為精簡的形式。
例如 「NFR-1-1 的 Google 推薦門檻」究竟是什麼門檻？或是「NFR-1-3 的 100 篇文章的建置時間 ≤ 2 秒」，的 100 篇文章長什麼樣子，在什麼機器上跑，也暫時沒有明確定義。
並不是不定義，而是在保持精簡的原則下，寫的剛好夠用，能起到記錄重點和提醒的作用即可，避免為了把文件寫完整而寫。
那這些量化、更具體的內容是否要寫呢？當然，一些重點項目我還是會定義清楚，以便在自我驗收的階段能夠真的照著執行，這些驗收項目的定義，就是接下來要談的 Acceptance Criteria。
所謂驗收標準（Acceptance Criteria，簡稱 AC）就是在定義完需求後，確認需求是否有達成的一份標準。我認為一則好的 AC，就是一份 Step-by-step 的測試文件，說明在什麼條件底下做了什麼事，最終可以達到什麼結果。
舉例來說：「NFR-1-1 首頁與文章頁面在 CWV 皆達到 Google 推薦門檻」這個非功能需求的 AC 就可以定義成「使用 Lighthouse 驗證網站 5 次，平均值需滿足 LCP ≤ 2.5s、INP ≤ 200 ms、CLS ≤ 0.1」。
更嚴格一些的話，我們還可以制定分別在手機、電腦的頁面下來測試，裝置的規格要幾核 CPU、RAM 多大等等，但有時候這就有點過度設計了，基本上在我常用的電腦、虛擬機器的環境下驗證即可，否則為了滿足這個標準，我們還得特別準備一台測試機，雖完善，但對於個人開發來講 CP 值便不太高了。
以下為部分節錄的驗收標準：
| AC ID | 驗收標準 | 滿足需求 |
|---|---|---|
| AC-F3-1 | 條件：至少有 12 篇「隨筆」文章，創建日期跨越 12 個月在無 Cache 的 Chrome 中載入「隨筆」頁面，前十筆文章最上方（第一篇）須為最新文章，往後日期依序遞減 | FR-3-1 按時間順序顯示文章（由新到舊） |
| AC-F4-1 | 條件：一篇 Markdown 含 [^1] 及 [^1]: 測試註釋 在結尾，測試電腦版網頁當滑鼠滑過「註1」標記，於 200 ms 內彈出 Tooltip，顯示「測試註釋」，滑鼠移出時 Tooltip 於 300 ms 內消失 |
FR-4-4 注釋懸浮功能，Hover 時會顯示簡短內容 |
| AC-F4-2 | 條件：同 AC-F4-1，但測試手機版網頁當手指點擊「註1」標記，於 200ms 內彈出 Tooltip，顯示「測試註釋」，當手指點擊頁面其他區域，Tooltip 於 300 ms 內消失 | FR-4-4 注釋懸浮功能，Hover 時會顯示簡短內容 |
| AC-N1-1 | 條件：產出 100 篇 1000±50 字元的 Markdown 測試文章（包含標題、列表、連結、程式碼區塊），將已存在之文章 Cache 移除執行 npm run build 三次，平均值在 2 秒內完成、單次建構時間不得超過 2.5 秒 |
NFR-1-3 100 篇文章的建置時間 ≤ 2 秒 |
這張表格呈現的是每個 AC 的實際內容，以及對應的需求是什麼，其中 AC ID 的命名也有一定的意義，可以自己定義，目的只是讓 AC 和需求的 Mapping 更直覺一些而已。
例如我在這邊的定義方式是 AC+ F 或 N（表達 Functional 或 Non-functional）的章節，所以 AC-F4-X 就代表功能需求的第 4 章節「單篇文章」的部分。
至於為什麼不直接制定成後面的數字和需求的數字一模一樣，是因為有時候一個需求要驗證是否完成，可能對應到的 AC 會不只一個，如上表的 AC-F4-1、AC-F4-2 都是「FR-4-4 注釋懸浮功能」這個需求的驗收標準，要同時滿足才算是這個需求開發完成。同理，其實一個 AC 也可能同時滿足不止一個需求，所以在 ID 的制定上我只按照章節來區分而已（比較不會有需求需要跨章節的 AC 來驗證）。
另外值得一提的是，並非所有的需求都需要特別撰寫 AC 來量化、標準化的驗證。
像是在寫「功能需求」的時候我們會列出「FR-4-2 文章顯示：標題、建立時間」、「FR-2-1 GitBook 風格佈局，左側有 Sidebar」這樣的項目，可是這些項目需要如何驗證呢？很多關於「有某些元件」、「長某種樣子」的需求都是主觀、看了便知有沒有的需求。
如果硬要寫測項，長的反而就會和需求本身非常雷同，像是：「文章中存在標題、建立時間」，有寫和沒寫差不多；而「GitBook 風格佈局」這種需求，除非是在驗證不同設備下長得樣子有沒有跑版，不然美觀上的需求還是得做出來了才知道合不合自己的胃口。
iThome鐵人賽
看影片追技術