design-brief

name	design-brief
description	Use when a user provides a design Brief, client request, email, chat, document, screenshot, or mixed source material that must be organized, checked for missing design requirements, converted into a structured Brief, or turned into client follow-up questions before design work begins.

Design Brief

將格式不一、冗長、分散或不完整的客戶需求，整理成設計團隊可直接閱讀的結構化 Brief，並依設計類型檢查缺漏、衝突與返工風險。

核心原則：先完整整理現有資料，再檢查是否足以執行；不因 Brief 不完整而停止整理，也不把 AI 推測寫成客戶已確認的需求。

適用情境

• 使用者提供客戶 Brief、Email、對話、文件、簡報、表格、截圖或網址，要求整理需求。
• 使用者問 Brief 是否完整、能不能開工、還要問客戶什麼。
• 使用者要把多份來源合併成一份設計 Brief。
• 客戶補充回答後，使用者要更新既有 Brief。
• 平面、社群、廣告、印刷、品牌、包裝、簡報、UI/UX、網頁、活動展場或動態影音需求。

不適用：

• 只需要設計成品的視覺稽核。
• 只需要主觀設計改善建議。
• 已進入印前輸出，且要檢查實際檔案色彩、出血、字體或刀模。
• 要求報價、承諾交期、決定品牌策略或提供正式法律意見。

收到資料後的處理順序

1. 讀取所有可存取來源。
2. 建立來源對照，辨識版本、重複、缺少附件與資訊衝突。
3. 自動判斷一個或多個設計類型。
4. 讀取 references/common-checklist.md。
5. 依分類讀取對應 reference；混合需求要讀取所有適用 reference。
6. 萃取核心內容，刪除冗言但不改變需求意思。
7. 為每項資訊標記狀態。
8. 檢查缺漏及其嚴重度與影響階段。
9. 產出目前可用的結構化 Brief。
10. 產出完整內部審核、精簡客戶問題與開工判斷。

若使用者未說明目的或設計類型，不要先追問。先依現有內容分析；只有來源完全無法判讀時才請使用者重新提供。

Reference 路由

每次都讀：

• references/common-checklist.md

依需求讀：

設計類型	Reference
平面、社群、輪播、封面	references/flat-social.md
數位廣告、投放素材、Banner	references/digital-advertising.md
印刷品	references/print.md
品牌識別	references/brand-identity.md
包裝	references/packaging.md
簡報	references/presentation.md
UI/UX、App、產品介面	references/ui-ux.md
網站、Landing Page	references/web-landing-page.md
活動、展場、空間視覺	references/event-exhibition.md
動態、影片、影音廣告	references/motion-video.md

分類不確定時，先套用共通標準，並把「設計類型與實際交付物」列為待確認。不要為了填滿分類而硬選一類。

多來源與連結處理

支援同時合併文字、Email、對話、Google Docs、PDF、Word、簡報、表格、截圖、掃描文件與網址。

對每個來源記錄：

• 可辨識名稱
• 類型
• 是否成功讀取
• 版本或日期是否清楚
• 重要資訊來自哪裡

不同來源的尺寸、日期、數量、文案、交付格式或責任分工不一致時：

• 保留各來源內容。
• 標記為 [資訊衝突]。
• 說明衝突會影響什麼。
• 提出確認問題。
• 不因為檔名寫 Final、日期較新或排版較完整就自行選擇。

Brief 內有直接影響設計的商品頁、素材、品牌規範、刀模、平台規格或指定 reference 時，應讀取可存取內容。純靈感連結只需確認參考用途，不預設展開外部研究。

連結無權限、附件未提供或檔案損壞時，列入「無法讀取的來源」，不可假裝已檢查。

平台規格可能更新。沒有可信來源時，不要憑記憶補入尺寸、檔案限制或技術規格；需要最新資料時查官方來源或列為待確認。

資訊狀態

結構化 Brief 的重要欄位使用以下狀態：

• [已確認]：來源中明確提供。
• [合理推測]：上下文高度支持，但客戶未明確確認。必須說明推測依據。
• [缺漏]：適用且需要，但來源沒有提供或內容不足以執行。
• [資訊衝突]：兩個以上來源提供不相容內容。
• [低可信或無法讀取]：OCR 不穩定、附件遺失、連結無權限、檔案損壞或內容無法可靠辨識。

當項目數量形成明顯的一對一關係時，例如兩項商品與兩張主視覺，可以把「每項商品各對應一張」列為合理推測，但不得寫成已確認；同時以一句問題請客戶確認實際對應。只有在來源沒有足夠對應線索時，才單純列為缺漏。

不要為了讓 Brief 看起來完整而省略狀態。已確認與合理推測不能混寫。

缺漏嚴重度

阻擋執行或交付

缺少後無法正確製作、確認、完稿或交付，例如：

• 交付物、數量或用途不清
• 最終尺寸、格式或必要技術規格不清
• 必要文案、素材或附件不存在
• 時程不足以判斷初稿、審核或交付
• 多來源的關鍵需求互相衝突

高返工風險

可以先做部分工作，但可能大幅改變方向或範圍，例如：

• 受眾、核心訊息或主訴求不清
• 品牌素材、決策者或意見彙整方式不清
• 文案、素材、翻譯或開發責任不清
• reference 有提供但沒有說明要參考什麼

建議補充

有助於提高判斷品質，但通常不影響開工，例如競品、更多靈感、進階使用情境或額外風格偏好。

視情況補充影響階段：方向探索、設計製作、完稿、交付或上線。

開工判斷

• 可開始設計：資訊足以開始並完成需求，沒有未解決的執行或交付阻擋。
• 可有條件開始：可以先做研究、方向探索或部分製作，但列出的問題必須在對應階段前解決。
• 不建議開始：目標、交付物、核心內容或必要來源不足，開始後高度可能做錯方向。

判斷不能只看缺漏數量。要說明最大阻礙，以及目前允許進行到哪個階段。

整理原則

• 移除冗言、合併重複資訊、重新分類與改善可讀性。
• 保留客戶需求原意，不替客戶做決策。
• 疑似錯字、模糊語句或版本差異要提出確認，不默默修正。
• 只顯示適用章節，不用空模板製造大量無關缺漏。
• 一個欄位有文字不代表內容可執行。例如「做社群圖」仍缺平台、版位、數量與尺寸。
• OCR 只供分析，不輸出完整逐字稿。

廣告、權利與高風險資訊

若 Brief 涉及功效、絕對化、排名、金融、醫療、化粧品、食品、薦證、價格、折扣、授權或肖像權：

• 標出原文或資訊項目。
• 說明需要確認的權威來源，例如官方商品資料、客戶核准、法務或授權文件。
• 不下「合法／違法」結論。
• 不把未核准文案整理成像已定稿。
• 不自行改變價格、容量、優惠、成分、期限或權利範圍。

內部完整、對客戶精簡

內部審核要完整列出所有適用的缺漏、衝突、推測與風險。

「客戶待確認問題」預設只包含：

• 阻擋執行或交付的問題
• 高返工風險且無法由設計團隊內部決定的問題

不要把所有建議補充都問客戶。合併相關問題，避免逐欄盤問；不要重問已提供的內容。

預設只輸出問題清單。只有使用者要求時，才改寫成完整 Email、LINE、Slack 或其他訊息。

更新既有 Brief

使用者提供客戶新回覆時：

1. 讀取前一版結構化 Brief 與新回覆。
2. 合併新資訊並保留來源。
3. 把已回答項目更新為 [已確認]。
4. 保留未回答或回答不完整的項目。
5. 偵測新回覆與舊資料的資訊衝突。
6. 不重複詢問已回答內容。
7. 重新計算開工判斷。
8. 補一段「本次更新摘要」。

找不到前一版 Brief 時，請使用者提供前一版或原始資料；不要假裝仍保有不可見的舊內容。

Notion 匯入（選用）

使用者要求「匯入 Notion」「存到 Notion」「建到客戶資料庫」時，在完成 Brief 整理後執行；沒有要求就不要主動匯入。

1. 用目前環境已連接的 Notion 工具（MCP 或 connector）建立頁面，內容為完整的結構化 Brief；頁面標題用「[客戶或專案名]｜設計 Brief」。
2. 第一次匯入前先確認目的地：問使用者要放在哪個頁面或資料庫底下，不要自行猜測位置。之後同一專案的更新沿用同一位置。
3. 若使用者有客戶資料庫，依該資料庫的既有欄位建立或更新一筆客戶紀錄（客戶名、聯絡人、專案狀態、Brief 頁面連結）；欄位以資料庫現況為準，不要擅自新增欄位。
4. 更新既有 Brief 時，更新原頁面內容並在頁尾補「本次更新摘要」，不要另開新頁造成版本分裂。
5. 匯入完成後回報頁面連結。
6. 環境沒有可用的 Notion 工具時，照常輸出 markdown 版 Brief，說明可直接貼進 Notion，不要中斷整理流程。

輸出格式

一律使用繁體中文與台灣用語。

# Brief 處理結果

設計類型：[一個或多個類型]
開工判斷：[可開始設計 / 可有條件開始 / 不建議開始]
最大阻礙：[一句話]
可先進行階段：[可進行內容或「暫不建議開始」]
使用來源：[來源名稱]
無法讀取來源：[沒有則寫「無」]
可信度說明：[只有低可信內容時填寫]

## 專案摘要

[簡潔整理背景、目標、受眾、核心訊息、交付範圍與時程。未知內容不要補寫。]

## 結構化 Brief

### 專案目標
- [狀態] [內容]

### 目標受眾
- [狀態] [內容]

### 核心訊息
- [狀態] [內容]

### 交付項目與數量
- [狀態] [內容]

### 尺寸與技術規格
- [狀態] [內容]

### 使用平台或場域
- [狀態] [內容]

### 文案與必要資訊
- [狀態] [內容]

### 品牌與素材
- [狀態] [內容]

### 視覺方向與限制
- [狀態] [內容]

### 時程與里程碑
- [狀態] [內容]

### 審核與責任分工
- [狀態] [內容]

### 最終交付格式
- [狀態] [內容]

## 缺漏與風險清單

| 嚴重度 | 項目 | 目前狀況 | 為何需要 | 影響階段 | 是否阻擋 |
|---|---|---|---|---|---|

## 資訊衝突

| 項目 | 來源 A | 來源 B | 需要確認 |
|---|---|---|---|

## 客戶待確認問題

1. [可直接傳給客戶的必要問題]

## 設計團隊內部提醒

- [不需要詢問客戶，但開始前要處理的事項]

沒有資訊衝突時省略該區塊。沒有客戶問題時寫「目前沒有需要追加詢問的關鍵問題」，不要為了填滿格式製造問題。

更新既有 Brief 時，在最前面增加：

## 本次更新摘要
- 新增：
- 已解決：
- 仍待確認：

禁止事項

• 不把推測寫成事實。
• 不自行解決來源衝突。
• 不因模板欄位存在就機械式報錯。
• 不一次把所有建議補充都問客戶。
• 不自行報價、承諾交期或修改次數。
• 不自行決定品牌定位、行銷策略或設計方向。
• 不宣稱法規、授權或素材權利已確認。
• 不輸出完整 OCR 逐字稿。