痛點場景：手動撰寫 PRD 耗時過長
傳統系統分析流程中，將業務需求轉化為完整 PRD 常需耗費數個工作日。系統分析師需處理大量排版、介面構思與邊界條件定義。導入 Antigravity 等 AI Agent 後，文件建置的基礎文書處理階段可壓縮至數分鐘。AI 代理能快速盤點既有系統功能並產出初稿，讓系統分析師將時間集中在業務邏輯校對與系統邊界收斂，整體交付時間可縮短至 2 小時內。
溝通過程我遇到的問題
【問題一】業務限制校準落差
AI 模型運作基於通用邏輯。當指示其規劃「管理介面」時，AI 預設會提供標準的 CRUD（新增、讀取、更新、刪除）操作。然而，企業內部系統通常具備嚴格的領域特定規則。若 SA 未在初期明確定義資料的關聯性與排他性限制，AI 產出的規格將允許非法操作，導致開發團隊實作後必須大幅重工。
【舉例】 在設計「期滿作業責任區設定」功能時，AI 初版草案直接配置了實體的「刪除」按鈕，並且在分配邏輯上，未限制單一單位（如：課級單位）的負責人數。實務上，為避免權責不清，單一課別同一時間僅能由一名承辦人負責（唯一負責人限制）。此外，在涉及大量單位的批次操作介面中，保留實體刪除按鈕極易造成使用者誤觸，引發大範圍資料遺失風險。
【解法】 SA 必須以負面表列與明確約束的指令介入。首先，要求 AI 在系統後台與防呆邏輯章節中，強制寫入「一對一限制」，確保資料庫與前端介面皆阻擋重複派發。其次，指令 AI 拔除所有實體刪除按鈕，改採「隱性刪除」機制——即定義使用者「取消勾選」該單位的動作，即等同於後台執行解除綁定與刪除負責人紀錄。此舉能確保 PRD 貼合企業真實的資料治理邏輯。
【問題二】介面互動設計不符操作效益 AI 缺乏對人類使用者面臨高頻、大量重複性操作時的同理心。其生成的 UI 規格通常優先考量視覺結構的單純性，而非實際操作的效率。當系統面臨資料量擴展（如：一次需調整數十筆狀態）時，AI 預設的基礎表單元件會成為嚴重的操作瓶頸。
【舉例】 面對全公司 38 個課級單位的業務負責人批次改派需求，AI 最初提出的 UI 方案是在 38 個單位旁各配置一個獨立的下拉式選單。在被判定效率過低後，AI 又提出透過點擊變更顏色的「刷色模式」。前者會造成使用者點擊次數過多，後者則帶來極高的認知負擔與誤操作風險，兩者皆不具備企業級系統的實用性。
【解法】 在此情境中，明確描述痛點大量修改情境，讓 AI 發想出「雙欄穿梭框」的設計。規範左欄顯示未分配單位，右欄顯示已分配單位，頂部配置承辦人選單。此設計可利用元件本身的左右位移邏輯，直接取代傳統的「新增」與「修改」視窗，將冗長的步驟整併為單一介面操作，極大化批次處理效能。
【問題三】測試情境與驗收標準（AC）顆粒度過粗 若未加約束，AI 生成的驗收標準，往往流於功能描述的同義反覆（如：使用者可以成功儲存資料）。這種缺乏顆粒度的規格無法有效涵蓋邊界案例、狀態轉移機制，也無法提供 QA 與 RD 撰寫測試案例的具體依據。
【舉例】 初版 PRD 的 AC 完全遺漏了批次修改的驗收項目。在 SA 提醒補上後，AI 產出的測試情境依然含糊，並未針對「將無人負責的單位派給某人」以及「將別人正在負責的單位搶過來派給某人」這兩種截然不同的系統底層行為，提供區別性的防呆與驗證標準。
【解法】 強制規範 AI 必須使用的「Given / When / Then」結構來撰寫 AC。要求 AI 針對核心功能產出對比式情境。以改派為例，需明確拆分兩套標準：
- 無衝突的基本設定：當單位無人負責時，系統直接儲存成功，不干擾使用者。
- 衝突改派：當單位已由他人負責時，系統必須觸發二次確認防呆警告（明確寫出提示文案），待使用者確認後，系統方可在後台執行解除舊關係並建立新關係的轉移邏輯。
【問題四】知識庫平台語法解析相容性 透過 Agent API 自動將 PRD 寫入企業內部知識庫（如 your-domain.atlassian.net）時，常因平台 Markdown 解析標準不同導致排版錯誤。
【舉例】 將文件寫入 Confluence 時，列表與段落擠壓在一起，排版塌陷並顯示出原始的星號標記。
【解法】 向 AI 植入明確的排版規則：所有列表前必須保留空行、標題與內文分離、子項目需嚴格執行縮排，確保自動發佈的文件具備高可讀性。
主旨：結尾：改變協作心態，讓 AI 協作更順暢
將 AI 視為執行器，系統分析師必須從規格撰寫者轉變為規則制定者。
- 收斂邊界：提供明確的業務術語與組織架構限制，避免 AI 自行發散邏輯。
- 提供使用情境：提供確切使用者操作的情境，讓 AI 針對痛點自由發揮解法。
- 聚焦例外：審閱 AI 初稿時，專注尋找衝突情境，並要求 AI 補充對應的防呆邏輯。
- 固化規範：將平台寫入規範與文件格式整理為規則，於後續專案中重複套用，維持產出品質。
附錄：標準化 PRD 規格大綱模版
- 功能概述 (Feature Overview)
- 系統目標與預期效益。
- 欲解決之核心業務痛點。
- 目標受眾與使用情境 (Target Audience & Use Cases)
- 操作角色定義與權限限制。
- 日常維護場景與批次/極端操作場景。
- UI/UX 介面佈局建議 (UI/UX Layout)
- 畫面區塊劃分（如：查詢條件區、操作按鈕區、資料列表區）。
- 核心互動路徑說明。
- 功能詳細說明 (Detailed Feature Requirements)
- 具體欄位定義與資料來源。
- 指定之前端互動元件（如：雙欄穿梭框、標籤化清單）。
- 系統後台與防呆邏輯 (Backend & Business Logic)
- 資料唯一性與排他性驗證。
- 隱性刪除機制與權責轉移邏輯。
- API 存取或跨系統整合限制。
- 驗收標準 (Acceptance Criteria)
- 採用 Given/When/Then 格式。
- 明確區分「正常操作情境」與「衝突防呆情境」。
- 匯出與報表規格 (Export Specifications) (若適用)
- 檔案格式要求（如：.xlsx, .csv）。
- 欄位扁平化定義與資料排序規則。
