当 AI 开始"圆桌讨论"：一次代码决策的新体验

你有没有遇到过这样的情况：面对一段代码的写法，直觉上觉得 A 方案更好，但说不出具体为什么。问同事，大家各执一词；翻资料，众说纷纭。最后只能靠"少数服从多数"或者"谁写的谁决定"来收场。

这不是技术问题，而是 决策问题 。

上周我在修改 SDK 项目的连接池代码时，就遇到了这样的困境。但这一次，我尝试了一种全新的方式——让 AI 进行一场"圆桌讨论"。

multi-expert 是什么？

multi-expert 是一个基于明朝内阁制的多 Agent 协作系统。它将任务分发给不同的"部门"（六部），每个部门从自己的专业视角分析问题，最后汇总形成决策。

两种协作模式

flowchart LR
    A[架构专家] --> D[讨论区]
    B[代码专家] --> D
    C[测试专家] --> D
    D --> E{达成共识?}
    E -->|否| D
    E -->|是| F[裁决者]
    F --> G[最终方案]

flowchart LR
    T[任务] --> A[专家A]
    T --> B[专家B]
    T --> C[专家C]
    A --> D[汇总]
    B --> D
    C --> D
    D --> E[最终结果]

三层架构

flowchart TB
    subgraph "决策层 [内阁]"
        A[🏛️ 内阁<br/>Neige<br/>任务分析与规划] 
    end

    subgraph "调度层 [司礼监]"
        B[📜 司礼监<br/>Silijian<br/>调度协调]
    end

    subgraph "执行层 [六部]"
        C[⚔️ 兵部<br/>工程实现]
        D[⚖️ 刑部<br/>代码规范]
        E[📚 礼部<br/>内容文案]
        F[🔧 工部<br/>运维部署]
    end

    subgraph "监督层 [都察院]"
        G[🔍 都察院<br/>Censorate<br/>质量审查]
    end

    A --> B
    B --> C
    B --> D
    B --> E
    B --> F
    C --> G
    D --> G
    E --> G
    F --> G

图：multi-expert skill 的三层架构

实战案例

我连续遇到了两个设计决策问题，都使用了 multi-expert 进行讨论。以下是完整的实践记录。

案例一：错误处理方案选择

问题背景

在 conn_pool.go 的 getNextAvailableClient 方法中，当所有连接都不可用时需要返回错误。直觉告诉我当前实现（方案 A）更好，但我想验证这个直觉。

方案对比

// 预定义基础错误
unavailableErr := errors.New("all grpc connections unavailable")

for _, conn := range connections {
    if err := tryConnect(conn); err != nil {
        // 覆盖为具体原因，语义保持一致
        unavailableErr = fmt.Errorf("[nodeAddr:%s] init failed: %s", 
            conn.ID, err)
        continue
    }
    return conn, nil
}

return nil, unavailableErr

var lastErr error  // 语义不明确

for _, conn := range connections {
    if err := tryConnect(conn); err != nil {
        lastErr = fmt.Errorf("[nodeAddr:%s] init failed: %s", 
            conn.ID, err)
        continue
    }
    return conn, nil
}

// 额外的判断分支
if lastErr != nil {
    return nil, lastErr
}
return nil, errors.New("all grpc connections unavailable")

执行流程对比

flowchart LR
    A1[预定义错误] --> A2[遍历连接]
    A2 --> A3{连接失败?}
    A3 -->|是| A4[覆盖错误信息]
    A3 -->|否| A5[返回连接]
    A4 --> A2
    A2 --> A6[返回错误]

    style A1 fill:#90EE90
    style A6 fill:#90EE90

flowchart LR
    B1[延迟定义] --> B2[遍历连接]
    B2 --> B3{连接失败?}
    B3 -->|是| B4[记录错误]
    B3 -->|否| B5[返回连接]
    B4 --> B2
    B2 --> B6{有错误?}
    B6 -->|是| B7[返回记录的错误]
    B6 -->|否| B8[返回新错误]

    style B1 fill:#FFB6C1
    style B6 fill:#FFB6C1

圆桌讨论

启动 multi-expert 后，系统自动触发了 内阁分析：

【任务类型】：代码设计评审
【执行计划】：
1. @兵部 - 从工程实现角度分析
2. @刑部 - 从代码规范角度分析
3. 会议讨论 - 形成最终决策

最终决策

flowchart TB
    subgraph "兵部视角"
        A1[语义统一] --> A2[代码简洁]
        A2 --> A3[命名意图明确]
    end

    subgraph "刑部视角"  
        B1[符合 Go 惯用法] --> B2[可读性更好]
        B2 --> B3[易于维护]
    end

    subgraph "共识"
        A3 --> C[✅ 采用方案 A]
        B3 --> C
    end

    style C fill:#90EE90,stroke:#333,stroke-width:2px

案例二：防御性编程的边界判断

问题背景

在审查 getNextAvailableClient 方法时，注意到开头有这样一个判断：

func (pool *ClientConnectionPool) getNextAvailableClient(...) {
    connLen := len(pool.connections)
    if connLen == 0 {
        return nil, -1, errors.New("no connections available")
    }
    // ...
}

核心疑问：为什么这个空连接列表的判断不放在调用方，而是在方法内部判断？

方案对比

func getNextAvailableClient(...) {
    if len(pool.connections) == 0 {
        return nil, -1, errors.New("no connections available")
    }
    // ... 查找逻辑
}

// 调用方 - 简洁，无需预处理
func getClientOnce(...) {
    cli, idx, err := getNextAvailableClient(...)
    // ...
}

func getNextAvailableClient(...) {
    // 假设调用方已经确保 connLen > 0
    // ... 直接执行查找逻辑
}

// 调用方 - 需要预处理
func getClientOnce(...) {
    if len(pool.connections) == 0 {  // 边界判断放在这里
        return nil, errors.New("no connections available")
    }
    cli, idx, err := getNextAvailableClient(...)
    // ...
}

圆桌讨论

最终决策

两个案例的对比

为什么有效？

mindmap
  root((multi-expert<br/>三大价值))
    自动识别决策类型
      智能分类任务
      针对性处理
      减少沟通成本
    多角色交叉验证
      工程视角 - 兵部
      规范视角 - 刑部
      决策视角 - 内阁
    决策过程可追溯
      记录完整讨论
      理由清晰可查
      便于后续复盘

价值一：自动识别决策类型

内阁能够自动判断这是"代码设计评审"任务，而不是普通的问答。这种智能分类让后续的处理更有针对性。

价值二：多角色交叉验证

• 兵部 给我工程视角：代码好不好写、好不好维护
• 刑部 给我规范视角：是否符合社区惯例、是否易于理解
• 内阁 帮我整合：在什么场景下哪种方案更优

每个角色都带来了单一视角无法覆盖的洞察，最终决策更加全面可靠。

价值三：决策过程可追溯

整个讨论过程都被记录下来。我可以清楚地看到：

• 为什么这样决策？
• 各个角色的理由是什么？
• 有没有遗漏的考虑因素？

这种可追溯性对于团队决策尤为重要。当半年后有人质疑这段代码时，我可以拿出这份"会议纪要"。

快速开始

基本用法

在你的项目中使用 multi-expert skill：

/multi-expert 你的问题或任务描述

适用场景

最佳实践

总结与展望

实践感悟

这次实践让我对 multi-expert skill 有了更深的理解。它不仅仅是一个"更聪明的 AI"，而是一个 结构化的决策框架 。

当我面对代码决策困境时，不再需要独自纠结，而是可以借助多角色的力量，从多个维度审视问题：

• 兵部给我 工程视角
• 刑部给我 规范视角
• 内阁帮我做出 最终裁决

未来方向

如果代码评审可以这样做，那架构设计呢？技术选型呢？甚至团队管理决策呢？

multi-expert 本质上是在模拟 "把问题抛给不同领域的专家" 这个过程。它不是在替我们做决策，而是在帮助我们 做出更好的决策 。

这或许就是下一代 AI 辅助开发的方向：从"告诉 AI 我要什么，AI 给我结果"，变成 "和 AI 一起讨论，共同找到最优解" 。

评论