「做一個任務追蹤 App」是一句想法，不是可驗收的需求。每個人對任務、完成、篩選和保存的理解都可能不同。今天我會把想法縮成第一版 PRD，目的不是把功能列得越多越好，而是讓 Day 5 能有根據地選架構，Day 7 能拿到一個範圍清楚的小任務。

先定義誰的問題

這個系列先服務一位想管理個人待辦事項的使用者。使用者需要快速記下任務、看出哪些尚未完成，並能修改或刪除寫錯的內容。第一版不處理團隊協作、提醒、附件、標籤、行事曆同步或多裝置離線同步。這些不是不重要，而是目前沒有證據顯示它們比一條完整、可靠的基本流程更優先。

把需求寫成使用者故事會更容易檢查：作為每天需要處理數件小事的人，我想快速記下任務並知道哪些還沒完成，避免在訊息或便利貼之間來回尋找。這句話沒有指定框架，也沒有急著加提醒功能；它把注意力放在使用者要完成的工作。

第一版 PRD：功能與驗收

核心流程一是建立任務：輸入非空白標題後，任務出現在清單中；純空格標題被拒絕，並顯示可理解的訊息。核心流程二是管理任務：使用者可編輯標題、標記完成、恢復未完成與刪除任務；每次動作後，清單狀態應一致。核心流程三是找到任務：可切換全部、未完成、已完成，篩選結果與狀態一致。資料儲存方式由 Day 5 決定，但重新整理後不能無故丟失已提交的任務。

每個功能都要處理成功與失敗。例如刪除不存在的任務時，系統不應顯示「刪除成功」；儲存失敗時，畫面不能假裝新任務已寫入。介面至少要能用鍵盤操作，並在載入中、沒有資料及出錯時提供明確回饋。這些條件會在之後的測試與前端文章中逐一落地。

我會用幾個具體案例驗收：輸入「 買牛奶 」後，系統應依約定處理前後空白；輸入只有空白時，不能建立任務；完成一筆任務後切到「未完成」，它不應仍出現在結果中；編輯或刪除失敗時，畫面要提示錯誤並保持可理解的狀態。標題長度上限、刪除是否需要確認，暫列待決，不能在實作時由 AI 自行猜定。

優先順序也寫清楚：P0 是新增、查看、編輯、完成與篩選；P1 是改善操作回饋與例外情況；團隊共享、提醒、附件屬於這 30 天之外的候選需求。若進度緊張，先縮功能邊緣，不犧牲已承諾流程的正確性。

非功能需求與邊界

公開展示版本只使用測試資料，不要求訪客輸入敏感資訊；帳號系統先不列入第一版。展示環境的資料保存與重置方式，需要在部署前明確告知。程式應能在乾淨環境中依文件啟動，主要流程有自動化測試，且每次修改能從 Git diff 追蹤。這些要求沒有替產品增加畫面，卻直接影響它能否被信任。

今天給 ChatGPT 的 Prompt

「請把『個人任務追蹤 App』整理成一頁 PRD。先列出你需要澄清的問題，再依使用者、核心情境、MVP 功能、不做的功能、驗收條件、非功能需求與未決假設輸出。不要替我決定帳號、多人協作或部署平台；遇到資訊不足請標示假設。」我會逐項審核它提出的內容，刪掉沒有必要的功能，並把人類決定寫回 PRD。

今天的結果與待確認事項

目前確定的是第一版的使用者、三條核心流程與最基本的可靠性要求。仍待 Day 5 決定的是程式架構與資料儲存方式；仍待部署前決定的是展示資料的保存與重置政策。這份 PRD 是系列的工作基準，之後若修改需求，文章會說明原因，而不假裝一開始就想對了。

今天學到什麼？

AI 很會把一句話擴寫成一長串功能，但需求分析真正有價值的部分，是找出缺漏、說清邊界，並把成功條件寫到可以驗證。明天才輪到架構：有了這份 PRD，哪些技術選擇真的值得做？