# email 代理人 具體運作的 3 個情境範例（以 Email 為例） 1. 需求發起（告別模糊不清的口頭交辦） 過去： 業務口頭說「我要一個抽獎活動網頁」。 現在： 業務寄信給 prd-ai@company.com 寫：「需要端午節抽獎網頁」。AI 會在 3 分鐘內自動回信，提供一份包含「活動機制、邊界條件（如重複抽獎怎麼辦）、資料庫需求」的標準 PRD 草稿，讓團隊基於這份草稿去修改，而不是從零開始。 2. 需求異動與工時評估（防範範圍蔓延） 過去： 開發到一半，PM 在信件裡追加需求（例如：選單多一個返回按鈕、QR Code 改掉）。工程師只能自己默默重估工時，容易產生認知落差。 現在： PM 在原 Email Thread 回信追加需求。AI 攔截後，會自動統整這些碎片的修改點，並回信列出清單與初步風險：「偵測到 4 項需求變更。經比對，第 1 項上下文關聯功能可能影響現有資料庫結構，建議重新評估所需工時（預計可能增加數天）。」讓團隊在動工前就先對齊成本。 3. 決策自動歸檔（防範資訊遺失） 過去： 信件來回確認完工時和細節後，沒人去更新正式的規格書或任務卡片。 現在： 當 PM 在信件最後回覆「收」或「確認執行」時，AI 會自動把這封信裡確認好的「最終規格」與「新增的預估工時（如 +1d, +0.3d）」，透過 API 自動寫入你們的專案管理系統（如 Jira 或雲端文件）中。 ```mermaid sequenceDiagram autonumber actor Team as 需求方 / PM / 開發 participant Email as 單一溝通平台<br/>(例如 Email Thread) participant AI as AI 需求助理<br/>(prd-bot@company.com) participant DB as 專案資料庫<br/>(Jira / Notion 等) %% 階段一：提出需求 Team->>Email: 寄信或回信提出需求/異動<br/>(例如條列式寫下要改的 4 個項目) Email->>AI: AI 自動讀取信件內容 %% 階段二：AI 自動分析與擴充 alt 是「全新 PRD 需求」 AI->>AI: 根據一句話需求，自動擴充為標準 PRD 格式<br/>(包含目標、User Story、驗收標準) else 是「開發中途的需求異動」 AI->>DB: 檢索現有規格與歷史任務 AI->>AI: 比對異動差異，分析潛在影響範圍<br/>(例如：預估會牽連到哪些前端頁面、預警工時增加) end %% 階段三：團隊確認與收斂 AI-->>Email: 回信給所有關係人：<br/>「完整的規格草稿」或「異動影響評估報告」 Team->>Email: 團隊在原信件討論，PM 回覆「確認無誤，執行」 %% 階段四：自動歸檔 Email->>AI: 擷取最終決策與預估工時 (如 +4d, +1d) AI->>DB: 自動更新規格書，或建立對應的 Ticket ``` ```mermaid graph TD subgraph Perception ["觸發與感知 (Perception)"] S[信件伺服器 Webhook<br/>或 IMAP 監聽] -->|收到寄給 prd-ai@company 的信件| E[擷取信件主旨、內文與 Thread] end subgraph Brain ["AI 大腦 (Brain)"] LLM[LLM 核心] Prompt[系統提示詞<br/>PRD 標準格式/決策邏輯] E --> LLM Prompt --> LLM end subgraph Memory ["記憶模組 (Memory)"] RAG[(向量資料庫 RAG)] -.->|搜尋歷史 PRD / 類似 Ticket| LLM Thread[短期記憶] -.->|保留同一個 Email Thread 的歷史回信| LLM end subgraph Action ["行動與工具 (Action/Tools)"] LLM -->|Function Calling| T1(SMTP API: 自動回信給所有人) LLM -->|Function Calling| T2(Jira API: 建立/更新 Ticket) LLM -->|Function Calling| T3(Notion/Wiki API: 更新規格書) end ```