改變之處：訊號散落各處——Slack 討論串、客服工單、銷售紀錄、Jira 議題都有，團隊在不同工具間切換時，脈絡也隨之流失。重要原因：漏掉需求背後的「為什麼」，會讓衝刺白費。受影響對象：必須判斷該解決哪些問題的產品經理、研究主管與客戶成功團隊。實務建議：設定連接器，讓探索代理匯入逐字稿、文件與工單。使用以證據為本的痛點看板，評估問題的頻率與嚴重程度、呈現具代表性的客戶引言，並標示互相矛盾的訊號。風險／限制：雜訊可能扭曲評分；應加入人工驗證步驟，以修正抽樣偏差。

改變之處：現在排定優先順序時，除了商業影響，也必須評估代理實作的可行性。重要原因：編碼速度加快，開發成本降低；真正的瓶頸變成如何選對方向。受影響對象：需要權衡價值、風險與可行性的產品經理、設計主管及業務利害關係人。實務建議：使用雙重評分矩陣——一套 0 到 10 分的標準評估 LLM／工具適配度與營運準備度，另一套評估影響、投入與法規因素。讓優先排序代理產出排名式評分矩陣，並附上可追溯的證據及各項分數的簡短理由。風險／限制：評分權重反映策略方向，應事先設定並記錄；有新證據出現時重新評分。

改變之處：設計產出現在必須同時是交給編碼代理執行的依據。重要原因：明確列出驗收標準的規格能減少模糊空間，加快端到端交付。受影響對象：UX 團隊、產品經理，以及接收規格的工程主管。實務建議：運用 Working Backwards 代理產生 PR/FAQ，再由規格產生器將其轉化為使用者流程、人物誌、驗收標準及設計交接簡報。確保每項需求都能連回來源痛點與優先排序的脈絡。風險／限制：規格過度僵化可能限制工程團隊的創意；加入「限制條件與設計意圖」一節，讓實作者提出效果相當的取捨方案。

改變之處：設計代理能在協調器使用的同一個工作區中，產生線框圖、使用者旅程圖與可互動的 HTML 原型。重要原因：快速原型讓利害關係人與客戶能在撰寫程式碼前推翻假設。受影響對象：研究人員、UX 團隊，以及工程團隊投入開發前必須簽核的利害關係人。實務建議：熟悉的領域使用快速推進模式，新問題則採用深入探索模式。針對可互動原型進行短期易用性測試或禮賓式測試，記錄指標與引言，再將結果回饋至痛點看板。風險／限制：原型可能造成過度逼真的錯覺；設計實驗應明確強調學習目標與驗收門檻。

改變之處：Kiro 或 Claude Code 等編碼代理能透過 Agent Client Protocol (ACP) 讀取結構化規格並快速產出可運作的程式碼，但前提是規格必須是明確、無歧義的合約。重要原因：具備驗收測試、可直接投入開發的規格，能縮小產品意圖與實作之間的落差。受影響對象：工程經理、SRE 與安全審查人員。實務建議：將需求、資料模型、驗收標準與測試案例彙整成單一檔案 prototype_spec.md；使用相容 ACP 的轉接器進行交接，並設置必須由人工審查、核准或退回規格的關卡。風險／限制：自動化開發也可能加速錯誤結果；應針對隱私、法規遵循與架構一致性保留明確檢查點。