前言：第二次 AI 協作 PRD 實驗——改用「分段 Prompt」策略
承接第一篇的實驗結果，本次為第二次透過 AI Agent（如 Antigravity）輔助撰寫 PRD 的實戰紀錄。系統分析師與產品經理在日常交付中，將抽象商業需求轉化為包含 UI 互動、資料庫 Schema、API 邏輯與驗收標準（AC）的規格書往往極度耗時。
本次實驗的核心差異在於調整 Prompt 策略：不再要求 AI 一次性產出完整 PRD，而是改採「分段進行」的逐步討論模式。本文將復盤這段歷時約 2 小時的「工單派發與大批次移交系統」PRD 產出過程，驗證分段協作對架構收斂的實際成效，解析過程中遇到的問題。
介面設計：解決大規模移交導致的操作癱瘓
在規劃大量資料移轉的介面時，傳統的表單設計會導致操作效率低落。
【遭遇問題】 當發生組織重組，主管需要將數十個客戶群組重新分配給不同客服人員時。若系統僅提供「逐筆點擊下拉選單 ➔ 尋找人員 ➔ 儲存」的介面，單次作業的時間成本極高且易出錯。
【實際範例】 客服專員 Bob 負責的 20 個「企業級客戶群組」需全數打散，分別移交給 Alice 和 Charlie 接手。
【解決方案】 全面捨棄傳統列表與彈出視窗，改採「單一頁面看板拖曳式（Kanban Drag & Drop）」介面。主管直接將代表「企業級客戶群組」的卡片，用滑鼠拖曳至目標人員的直欄中。畫面上必須即時重新計算並顯示兩人目前負擔的「總工單數、技術問題單、帳務問題單」，提供即時的視覺化負載回饋。
資料庫關聯：解決離職人員導致的歷史懸案黑洞
通用系統的預設防呆機制，有時會與真實商業的歷史追溯需求產生衝突。
【遭遇問題】 當員工離職，人資系統將其帳號停權。若主管切換至「上個月」的系統畫面，試圖將該離職人員「尚未處理完的歷史工單」抓出重新派發時，因系統預設過濾停權帳號，導致該離職人員與其名下工單從畫面上消失，形成無法指派的系統黑洞。
【實際範例】 Alice 在 4 月底離職。5 月時主管開啟 4 月的歷史面板，準備將 Alice 留下的 10 張未處理工單轉交給新人，但畫面上無 Alice 的直欄與資料。
【解決方案】 導入「資料庫動態聯集 (Union)」架構。歷史面板的渲染名單，必須由「該查詢月份 DB 的配置快照（Snapshot）」加上「當前人事系統的在職名單」共同組成。即使人員已離職，只要快照紀錄中負責過該區域，直欄與卡片就必須如實顯示，確保未結案工單可被拖曳移交。
業務邏輯防呆：防止改派未完成工作時，意外竄改歷史業績
大批次資料更新若未做好狀態隔離，將嚴重破壞歷史資料正確性。
【遭遇問題】 主管為處理離職人員的未完成工作，將整個客戶群組移交給新人。若系統未做狀態限制，此移交動作會將該群組內「過去已經解決的工單」負責人一併替換，抹殺前員工的歷史業績並導致報表失真。
【實際範例】 將「企業客戶 A」從 Alice 移交給 Bob。Alice 上個月為此客戶解決了 5 張單，留下 3 張未處理。移交後，系統若全數更新，會變成 Bob 解決了 8 張單。
【解決方案】 在 API 規格與驗收標準中，強制寫入「條件式改派 (Conditional Reassignment)」。規定資料庫 UPDATE 語法必須嚴格帶入狀態鎖定（例：WHERE status != 'CLOSED'），確保永遠只有「處理中」的工單被轉移，已結案的歷史資料不受影響。
系統架構：解決未來月份缺乏預估基準點的問題
前端即時運算未來資料，會導致效能與狀態不穩定。
【遭遇問題】 主管提早規劃「兩個月後」的人力配置時，切換至未來月份，因系統尚未有任何指派規則，所有預計進件的工單皆顯示為「未指派」。主管缺乏基準點，必須從零手動分派。
【實際範例】 5 月 1 日時，主管查看 7 月的預估工作量。系統因無 7 月的分配規則，導致 500 張未來的預估工單全部堆疊在「無主區」。
【解決方案】 建立「自動化背景排程 (Cron Job)」。系統定於每月 1 號凌晨執行，自動「複製最近一個月的分派規則，作為未來的初始基準」。主管開啟未來面板時，已有依據現狀分配好的基準盤面，僅需針對特定異動進行微調。
工具整合限制：第三方系統的程式碼嵌入限制
AI 產出的高擬真產出物，需考量企業內部工具的相容性。
【遭遇問題】 團隊嘗試將 AI 產出的高擬真前端介面原型（HTML/CSS 程式碼），直接嵌入公司內部的 Wiki 文件平台（如 Confluence）中。但 Wiki 平台基於資安政策，封鎖未經授權的自訂程式碼渲染，導致畫面顯示原始碼或亂碼。
【實際範例】 將帶有互動效果的卡片版型 HTML 透過 API 寫入規格書網頁，存檔後無法渲染 UI，僅顯示純文字代碼。
【解決方案】 遇到資安規則阻擋後果斷停損。改由 AI 重新生成「文字與欄位精確對齊」的靜態 UI 示意圖檔。放棄互動原型，將重點拉回後端規格與 AC 驗收標準的制定，確保 PRD 順利發佈。
實戰心得：Top-Down 拆解、快速疊代與 Token 消耗控管
本次協作採用 Top-Down（由上而下） 的策略，將 PRD 拆分為獨立段落（UI/UX ➔ 資料邏輯 ➔ 系統架構 ➔ AC 驗收標準）逐一與 AI 討論。實測證明，分段討論的品質遠勝於要求 AI 一次性產出整份規格。
在向下展開技術細節時，常會發現前述情境定義不夠明確（例如制定歷史改派時，才發現 UI 面板缺少離職人員的處理機制）。此時透過 AI 快速疊代更新前面段落，能達到「越辯越明」的效果，且無須耗費人力重新打字排版。
關於 Token 消耗與工具使用的策略調整： 隨著段落增加與反覆修正，若頻繁依賴 AI 的 MCP 工具（如 Atlassian API）去讀取並完整覆寫 Confluence 頁面，Token 會迅速耗盡。
為控管 Token 消費，後期策略調整為：由 AI 讀取與產出規格文字，人工手動複製貼上至 Confluence。雖然增加了人工貼上的動作，但省下的 Token 額度能維持 AI 高品質的邏輯推演。此作法適用於「從零規劃、需反覆修正的全新功能」；若是範圍明確的既有功能小改版，則可完全依賴 AI 透過 API 自動完成文件更新。
