昨天定義了 Clean Architecture + MVI 的架構規範，但我發現了一個問題。

研究深入一點就卡住了。

什麼是 ARS？

ARS（Architecture Research Specialist）是我定義的一個專門 AI 角色，專注於架構研究和技術評估。

就像公司會有專門的研究員，我也需要一個專門做深度技術研究的 AI 助手。

發現問題的過程

在研究 Clean Architecture vs 六角架構時，我問 AI：

我：有沒有中型企業成功使用六角架構的案例？
AI：[給出一些理論說明]
我：我需要具體的案例，公司名稱、技術棧、遷移過程
AI：[仍然偏向理論]

這時我意識到，通用的 AI 助手在深度研究上有侷限。

我需要的不只是一個回答問題的 AI，而是一個專門做架構研究的角色。

於是，Architecture Research Specialist (ARS) 誕生了。

為什麼需要 ARS？

通用 AI 的限制

使用通用 AI 時，我遇到這些問題。

廣而不深。回答偏向教科書知識，缺乏實際案例支撐，難以找到最新的業界實踐。

缺乏系統性。每次都要重新描述需求，研究結果零散，難以累積知識。

視角單一。通常只給出一個「標準答案」，缺少多角度比較，忽略失敗案例。

ARS 的價值

當我定義了 ARS 角色後，情況完全不同了：

我：請以 ARS 角色研究 KMP 專案的狀態管理方案

AI 立刻進入研究模式：

## 研究報告：KMP 狀態管理方案

### 發現的方案
1. **MVI + StateFlow** (JetBrains 推薦)
   - 案例：Cash App (Square)
   - 團隊規模：50+ 開發者
   - 優點：原生支援、類型安全
   
2. **Redux-Kotlin** 
   - 案例：Expedia
   - 團隊規模：20+ 開發者
   - 優點：可預測性強、生態系統完整

3. **Decompose + MVIKotlin**
   - 案例：Badoo
   - 團隊規模：100+ 開發者
   - 優點：導航整合、生命週期管理

### 比較分析
[詳細的表格比較]

### 建議
基於你的團隊規模（1人）和專案複雜度，
建議採用 MVI + StateFlow...

看到差異了嗎？角色定義改變了 AI 的行為模式。

ARS 的核心能力

研究方法論

ARS 不是隨便 Google，而是有系統的研究：

定義研究範圍 → 廣泛搜尋 → 初步篩選 → 深入研究 → 比較分析 → 整理報告 → 提供建議

多元資訊來源

ARS 會從多個角度收集資訊。

學術論文提供理論基礎。業界案例提供實戰經驗。開源專案提供實作參考。社群討論提供踩坑經驗。失敗案例讓我們避免重蹈覆轍。

結構化輸出

每個研究都有標準格式：

## 研究報告：[主題]

### 執行摘要
- 3-5 個關鍵發現
- 主要建議

### 研究內容
- 各方案詳細分析
- 優缺點比較
- 適用場景

### 證據支撐
- 實際案例
- 參考連結
- 數據支撐

### 風險評估
- 潛在問題
- 緩解策略

實戰案例：選擇訊息佇列

讓我展示 ARS 如何幫我做技術決策。

背景

Grimo 需要一個訊息佇列來處理 AI Agent 之間的通訊。

使用通用 AI

我：推薦一個訊息佇列
AI：可以考慮 RabbitMQ、Kafka、Redis...

太籠統了，沒有針對性。

使用 ARS

我：請以 ARS 角色研究適合 KMP Desktop 應用的
    輕量級訊息佇列方案，需要支援：
    - 進程內通訊
    - 低延遲（<10ms）
    - 內嵌式部署

ARS 的回應：

## 研究報告：KMP Desktop 輕量級訊息佇列

### 執行摘要
- 發現 4 個可行方案
- 推薦：Kotlin Coroutines Channel
- 原因：原生支援、零依賴、效能最佳

### 方案分析

#### 1. Kotlin Coroutines Channel
**來源**: JetBrains 官方
**生產案例**: JetBrains Fleet IDE
**效能**: <1ms 延遲
**優點**:
- KMP 原生支援
- 類型安全
- 背壓處理
**缺點**:
- 無持久化
- 單進程限制

#### 2. Chronicle Queue
**來源**: Chronicle Software
**生產案例**: LMAX Exchange
**效能**: <5μs 延遲
**優點**:
- 極致效能
- 支援持久化
**缺點**:
- JVM only
- 學習曲線陡峭

#### 3. Disruptor
**來源**: LMAX
**生產案例**: Log4j2
**效能**: 1M msg/sec
**優點**:
- 無鎖設計
- 低GC壓力
**缺點**:
- 配置複雜
- 過度設計風險

#### 4. SQLite as Queue
**來源**: 社群實踐
**生產案例**: Signal Desktop
**效能**: 10-50ms
**優點**:
- 自動持久化
- 事務支援
**缺點**:
- 效能較差
- 非典型用法

### 比較分析

Channel 在延遲、易用性和 KMP 支援上都表現優異，但缺乏持久化。Chronicle 有極佳延遲和持久化，但易用性和 KMP 支援較差。Disruptor 延遲低，但配置複雜且不支援持久化。SQLite 有持久化且易用，但延遲較高。

### 建議

對於 Grimo 的需求，首選 Kotlin Coroutines Channel。
實作簡單、效能滿足需求、與現有技術棧完美整合。

備選 SQLite as Queue。如果未來需要持久化，Signal Desktop 已證明可行性。

### 實作範例
```kotlin
// 使用 Channel 實作 Agent 通訊
class AgentMessageBus {
    private val channel = Channel<AgentMessage>(
        capacity = Channel.UNLIMITED,
        onBufferOverflow = BufferOverflow.SUSPEND
    )
    
    suspend fun send(message: AgentMessage) {
        channel.send(message)
    }
    
    suspend fun receive(): AgentMessage {
        return channel.receive()
    }
}

參考資料

• Kotlin Channels Guide
• Signal's SQLite Queue
• LMAX Disruptor

這個研究報告讓我很快就做出了決策，而且有充分的證據支撐。

## 如何打造你的 ARS

### 定義角色模板

```markdown
# Architecture Research Specialist (ARS)

## 角色定位
專注於架構模式研究、最佳實踐探索和技術評估

## 核心能力
1. 廣泛搜尋能力
2. 批判性分析
3. 結構化報告
4. 實證支撐

## 研究流程
1. 範圍定義
2. 資料收集
3. 深入分析
4. 比較評估
5. 報告產出

提供研究框架

給 AI 一個清晰的框架：

研究框架 = {
    "資訊來源": ["學術", "業界", "開源", "社群"],
    "評估維度": ["效能", "成本", "複雜度", "生態系"],
    "輸出格式": ["摘要", "詳細分析", "比較表", "建議"],
    "證據要求": ["案例", "數據", "參考連結"]
}

累積領域知識

每次研究後，更新你的知識庫：

## 研究歷史
- 2024-01-10: KMP 狀態管理 → 選擇 MVI + StateFlow
- 2024-01-11: 訊息佇列 → 選擇 Coroutines Channel
- 2024-01-12: 資料庫方案 → 選擇 SQLDelight

ARS 帶來的改變

Before ARS（以前）

決策流程：
Google 搜尋 → 讀大量文章 → 還是不確定 → 
問 AI → 得到通用答案 → 繼續搜尋 → 
最後憑感覺選一個
時間：很久
信心度：中等

After ARS（現在）

決策流程：
定義需求 → 請 ARS 研究 → 很快得到報告 → 
評估建議 → 做出決策
時間：很短
信心度：很高

實際成果

使用 ARS 後的成果很明顯。

決策效率大幅提升。狀態管理從數天縮短到幾小時。訊息佇列從耗時研究變成快速決策。測試框架從天級研究變成即時分析。

決策品質提升。每個決策都有多方案比較。每個方案都有實際案例。風險都被提前識別。

知識累積。建立了決策文件庫。形成了研究方法論。可以快速onboard新成員。

ARS 的最佳實踐

明確研究範圍

模糊的請求是「研究一下微服務」。

明確的請求是「研究 10 人團隊從單體遷移到微服務的漸進式方案，技術棧是 Spring Boot，預算有限」。

要求實證支撐

永遠要求具體公司案例、團隊規模參考、實施時間、遇到的問題。

關注失敗案例

請同時研究失敗案例，特別是：
- 為什麼失敗
- 如何避免
- 有什麼替代方案

定期更新研究

技術日新月異，定期更新：

## 研究更新計畫
- 每季度：重新評估核心技術選型
- 每月：追蹤新興技術
- 每週：關注社群討論熱點

ARS 與其他角色的協作

ARS 不是獨立工作的，它與其他角色形成體系：

產品經理 → ARS研究專家 → 架構師 → 實作顧問 → 開發者 → 回饋給ARS

實際協作案例

PM：我們需要支援即時協作編輯

ARS：研究 CRDT、OT、中央鎖等方案
→ 產出：技術可行性報告

SA：基於 ARS 報告，選擇 CRDT
→ 產出：系統架構設計

TIA：使用 Yjs 實作 CRDT
→ 產出：實作指南

DEV：按照指南開發
→ 回饋：Yjs 在 KMP 上的坑

實戰心得：角色專業化的力量

通用 vs 專業

就像公司裡不會只有「工程師」這個角色，而是有：

• 前端工程師
• 後端工程師
• DevOps 工程師
• 資料工程師

AI 助手也需要專業分工：

• ARS：研究最佳實踐
• SA：設計系統架構
• TIA：實作技術細節
• QA：測試策略

角色定義的威力

當你給 AI 一個明確的角色定義時，它的行為會完全改變：

1. 思考模式改變：從回答問題變成主動研究
2. 輸出品質提升：從簡單答案變成深度報告
3. 價值增加：從節省搜尋時間到提供決策支撐

投資在角色設計上是值得的

花 1 小時設計 ARS 角色，為我節省了無數的研究時間。

更重要的是，它改變了我的工作方式。

從盲目搜尋到系統研究。從憑感覺決策到證據驅動決策。從單打獨鬥到 AI 團隊協作。

給你的建議

識別你的痛點，哪些工作最耗時？設計專門角色，為這些工作設計 AI 角色。迭代優化，根據使用經驗調整角色定義。建立角色體系，讓不同角色協同工作。

記住，AI 不是一個工具，而是一個團隊。

今日金句

「給 AI 一個角色，它會給你一個團隊。」

關於作者：Sam，一人公司創辦人。正在打造 Grimo，一個智能任務管理和分配平台。

專案連結：GitHub - grimostudio