multi-role-synthesis-framework

name	multi-role-synthesis-framework
description	Use when Chris wants multiple perspectives on a design/feature decision and then a final integrated verdict. 多角色各自俾建議 → 終極角色做篩選整合，避免單一角度的盲點。
tags	["product","decision-making","role","synthesis","review"]
metadata	{"hermes":{"platform":["cursor","codex","claude-code"]}}
domain	ecosystem
subdomain	agent-comparison
tokens	{"scan":120,"load":2445,"category":"detailed"}

🎭 多角色合成篩選框架

兩種模式

呢個 framework 支援兩種使用模式：

模式一：平行建議 + 終極篩選（預設）

多角色各自俾建議 → 終極角色做篩選整合。適合設計決策場景。

模式二：順序 Pipeline（今次新增）

角色順序執行，一個做完交俾下一個。適合反饋修復場景。 UX分析師 → 產品設計師 → 前端工程師

揀模式嘅原則：

• 想俾 Chris 多個選擇去揀 → 用模式一
• Chris 已經講咗要改咩，只想執行好 → 用模式二

兩種任務類型（核心區分）

呢個框架有兩個完全唔同嘅用法，揀錯角色組合會搞到成件事歪晒：

類型 A：內部決策審視（預設用法）

審視我哋自己項目嘅功能/設計/技術決策。角色組合係「內部專家」。

• 例子：設計學佛問答 feedback 機制、決定 UX 流程、cut 功能

類型 B：外部項目學習（今次新增）

分析外部開源項目/技術/pattern，將好嘢吸收轉化為我哋嘅能力。角色組合係「外部專家 → 翻譯官 → 內部落地」。

• 例子：學習 Godogen 嘅 AI 開發模式、研究某個 framework 嘅架構

關鍵區分：

• 類型 A 嘅角色係「審視角度」（UX設計師、法師顧問、遊戲化設計師）
• 類型 B 嘅角色係「轉化鏈條」（外部專家→翻譯官→架構師→工程師）
• 類型 B 唔可以就咁用類型 A 嘅角色組合，否則會出現「用內部審視角度去分析外部項目」嘅錯配

何時使用

• Chris 話「用幾個角色去睇一睇呢個設計」
• Chris 話「搵一個角色去總結晒所有角色嘅意見」
• 需要多角度審視一個 feature、設計決策、或者外部項目，然後做終極篩選
• 決策涉及 UX、遊戲化、內容、技術、商業等多個維度

流程

Step 1：先確定任務類型

係「內部決策審視」（類型 A）定係「外部項目學習」（類型 B）？

Step 2：揀角色

根據任務類型揀 3-5 個相關角色。

類型 A：內部決策審視 — 常用角色組合

場景	建議角色組合
用戶功能設計	UX 設計師、遊戲化設計師、內容設計師、產品策略師
技術決策	軟體架構師、微信開發者、安全工程師、性能工程師
內容創作	法師顧問、內容設計師、故事寫手、產品策略師
商業策略	產品策略師、市場營銷、用戶增長、法師顧問
綜合（常用組合）	UX 設計師 + 遊戲化設計師 + 內容設計師 + 產品策略師 + 法師顧問

類型 B：外部項目學習 — 推薦角色組合

角色應該形成「外部 → 內部」嘅轉化鏈：

角色	職責	場景例子
📖 原項目專家	最了解外部項目嘅設計哲學、pattern 背後嘅「點解」	Godogen 原作者視角
🌉 技術翻譯官	將外部項目嘅技術 pattern 翻譯成我哋平台嘅語言	Godot → Cocos/WeChat
🏗️ 架構設計師	將翻譯完嘅 pattern 設計成具體架構方案	點樣融入現有系統
👨‍💻 實戰工程師	最後落地可行性判斷	每日寫 code 嘅角度
🛡️ 安全檢測員	審計漏洞、系統衝突、負面影響；開工後實際檢測每個改動	任何改動執行前Review

終極角色建議用 🧭 Product Manager 或者 🧠 Strategist，因為需要判斷「邊啲 pattern 值得學、邊啲唔值得」。

重要：唔好將類型 A 嘅角色（UX設計師、法師顧問）直接用喺類型 B。法師顧問係審視內部項目功能決策用，唔係分析外部技術 pattern。

Step 2：收集每角色建議

每個角色從自身角度俾意見，格式：

### 👤 角色：[角色名]

**對 [決策項目] 嘅意見：**
- [建議 1 + 理由]
- [建議 2 + 理由]
- [建議 3 + 理由]

每個建議要有：

• 具體建議（做啲咩）
• 背後理由（點解咁做）
• 無需太詳細，一句到肉就得

類型 B 特別指引：收集嘅唔係「審視意見」，而係「翻譯轉化建議」。

• 📖 原項目專家：呢個 pattern 嘅本質係咩？Godogen 點解要用呢個方法？
• 🌉 技術翻譯官：呢個 pattern 喺我哋平台應該點樣實現？
• 🏗️ 架構設計師：翻譯完之後嘅架構方案係點？
• 👨‍💻 實戰工程師：呢個方案每日用起嚟順唔順？有冇阻滯？

Step 3：揀終極篩選角色

最常用嘅終極角色：

角色	強項	適合場景
🧭 Product Manager	整合各角色意見，做 trade-off 決策	默認推薦 — 平衡用戶體驗、商業、技術
📦 Chief Product Officer	更高層次嘅產品方向判斷	戰略級決策（cut 功能、轉方向）
🧠 Strategist	長期戰略視角	涉及商業模式、市場定位

Step 4：終極篩選表

用表格形式列出每個建議，逐個評估：

#	建議	來源	價值	成本	決定
1	[建議描述]	[角色名]	🔴/🟢/🟡	[高/中/低]	✅ 採納 / ❌ 不採納 / ⏳ Phase N

決定分類：

• ✅ 採納 — 價值高、成本合理，即做
• ❌ 不採納 — 價值成本不成比例，清晰解釋理由
• ⏳ Phase N — 好建議但係另一階段做，唔並喺 MVP 塞晒

Step 5：終極方案

產出 Final Spec：

1. 清晰嘅用戶流程（最終嗰個流程係點）
2. 數據結構更新（如果有）
3. 實作優先級（P0-P4）

注意事項

• 角色唔係越多越好，3-5 個已經夠。太多會噪音
• 角色唔可以重複 — 每個角色要有獨特視角
• 模式一：Role-aware 篩選：終極角色唔係做平均主義，而係有意識地 prioritise 某些角色嘅建議
• 模式二：順序 Pipeline — 角色必須順序，一個做完先到下一個。唔好喺 UX 分析未完成就開始改 code
• 解釋不採納理由 — 唔好就咁 ❌，要話 Chris 點解唔做
• 終極角色要俾清晰嘅決策邏輯 — Chris 可以推翻，但佢要見到 reasoning

實戰案例參考

案例 1（類型 A）：設計「學佛問答」答案頁 feedback 機制

角色組合：UX 設計師、遊戲化設計師、內容設計師、產品策略師、法師顧問 終極角色：🧭 Product Manager 結論：👌 我明瞭 / 🤔 有點深 兩個掣，答案加一句總結 + 生活應用 詳細過程睇 2026-06-17 session。

案例 2（類型 B）：學習 Godogen 嘅 AI 開發模式

角色組合：📖 Godogen 專家→🌉 技術翻譯官→🏗️ 架構設計師→👨‍💻 實戰工程師 終極角色：🧭 Product Manager 結論：MEMORY.md + 輕量 PLAN.md Verify + 5-Stage Pipeline + Quirks 檔案分開 關鍵教訓：唔好將類型 A 嘅角色直接用喺類型 B。最初我（Hermes）用咗 UX 設計師同法師顧問去分析 Godogen，俾 Chris 糾正咗。 詳細過程睇 2026-06-19 session。