القائمة
此技能应在头脑风暴中需要多视角讨论时使用。 它让 2-3 个具有不同专家人格的 AI 代理协作讨论复杂决策、技术选型、需求探索或事后复盘。 触发词：「派对模式」「开启派对」「多视角讨论」「[P]」「听听专家意见」
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Fork Overlay：Task Bundle 持久化 + Failure FSM 集成。在 ce:work 基础上增加 state.md 读写和状态机转换。使用时机：执行 ce:work 时，如果任务有对应的 Task Bundle（docs/tasks/<id>/），加载此 skill 以启用持久化和状态追踪。
Fork Overlay：Codex-first 外部执行器策略。按任务特征路由到 Claude 或 Codex，Codex-first（非品牌路由）。使用时机：需要决定是否将当前任务派发给 Codex 时加载此 skill。
Fork Overlay：经验分层沉淀升级阶梯。检测是否值得将 solution 升级为 pattern 或 skill。使用时机：ce:compound 完成后手动调用，分析 docs/solutions/ 中的重复模式。（不会自动触发，需主动加载此 skill）
Fork Overlay：外部模型调用前置检查门控。调用 Codex/Gemini 之前运行五项检查，防止调用失败浪费时间。使用时机：任何调用外部模型（Codex [C]、Gemini [G]）之前自动运行。
Fork Overlay：ce:work 意图分类门控。在执行前识别任务意图（实现/修复/重构/探索），设定对应的执行策略。使用时机：ce:work Phase 0（环境扫描）之后、Phase 1（Quick Start）之前。
Fork Overlay：Codex Patch Approval 咨询版。当 Codex 返回 patch 时，Claude 审批后才写入文件。使用时机：Codex 以 patch/diff 格式返回代码变更时，由 Claude 作为审批层。
| name | party-mode |
| description | 此技能应在头脑风暴中需要多视角讨论时使用。 它让 2-3 个具有不同专家人格的 AI 代理协作讨论复杂决策、技术选型、需求探索或事后复盘。 触发词：「派对模式」「开启派对」「多视角讨论」「[P]」「听听专家意见」 |
核心理念：多样性视角优于单一聪明。好的决策来自充分的碰撞。
激活方式：
/workflows:brainstorm 中输入 [P] 或说「开启派对模式」状态切换规则（意图优先，默认保持讨论）：
核心原则：退出必须基于明确意图。只要存在继续探索的合理解释，就保持 party-mode。
继续讨论（满足任一条件即继续）：
退出（满足任一条件才退出）：
[E]、「结束派对」、「exit」/workflows:plan 或 /workflows:work判断示例：
每轮对话自动选择 2-3 个最相关代理，不是简单轮询：
用户消息
↓
┌─────────────────────────────────┐
│ 领域分析 │
│ 技术？业务？创意？安全？性能？ │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 代理选择 │
│ • 主代理：最佳专长匹配 │
│ • 辅助代理：互补视角 │
│ • 第三代理：异议或跨域洞察（可选）│
└─────────────────────────────────┘
↓
2-3 个代理依次发言
选择规则：
| 规则 | 说明 |
|---|---|
| 用户点名 | 优先该代理 + 1-2 个互补代理 |
| 轮换参与 | 长对话中确保所有代理都有机会发言 |
| 领域平衡 | 综合技术、业务、用户等多个维度 |
| 制造张力 | 适时选择持不同观点的代理激发深入讨论 |
铁律：每个代理严格按照其人格设定说话。
代理的人格由三个维度定义：
| 维度 | 作用 | 示例 |
|---|---|---|
| 身份背景 | 奠定可信度 | 「15 年分布式系统经验」 |
| 说话风格 | 决定表达方式 | 「冷静务实，用类比解释」 |
| 决策原则 | 指导观点立场 | 「简单方案优先」 |
详见 代理索引，按需加载具体代理文件。
代理之间可以：
| 互动类型 | 示例 |
|---|---|
| 引用 | 「正如 Mary 刚才提到的...」 |
| 补充 | 「在 Winston 的基础上，我想补充...」 |
| 质疑 | 「我不太同意 Amelia 的判断，因为...」 |
| 提问 | 「John，从产品角度，你怎么看这个取舍？」 |
但代理不会抢话。 当某个代理向用户提问时，立即暂停等待用户回应。
🎉 派对模式已激活！
今天参与讨论的核心团队：
🏗️ 李明远（架构师）- 系统设计与技术选型，冷静务实
📊 陈思琪（分析师）- 需求分析与业务洞察，善于追问
💻 张晓峰（开发者）- 实现细节与代码质量，极简主义
📋 王建国（产品经理）- 用户价值与优先级，数据驱动
根据讨论主题，我会邀请其他专家加入。
[C] 开始讨论 | [?] 查看全部代理
[E] 退出 | 继续讨论...回应格式：
[emoji] **代理名**：[符合角色风格的回应]
🎊 派对模式结束！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
会话回顾
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
讨论主题：[主题]
参与代理：[列表]
讨论轮数：[N] 轮
关键共识：
• [共识点 1]
• [共识点 2]
遗留分歧：
• [分歧点]（建议后续验证）
复用机会：
• [可复用的成熟库 / CLI / API / 平台能力 / 项目内既有模式]
构建边界：
• Reuse：[直接复用的成熟能力]
• Glue code：[只需编排、配置、适配、连接的部分]
• Net-new：[必须自研的部分及原因]
候选优先级：
• P1 — Must Have：[没有它，核心问题不成立]
• P2 — Should Have：[本轮默认包含，但可在范围压力下裁剪]
• P3 — Could Have：[低成本增强，不阻塞主路径]
• P4 — Later / Parking Lot：[明确延后，防止 scope creep]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
各位的告别：
🏗️ 李明远：「记住，最好的架构是无聊但有效的架构。」
📊 陈思琪：「这些假设还需要数据验证，别急着下结论。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
下一步建议：运行 `/ce:plan` 将讨论转化为计划
**退出契约（供 ce:brainstorm 继续收敛）：**派对模式结束时必须保留上面的结构化结果，尤其是 Consensus、Disagreements、Risks、Reuse Opportunities、Build Boundary、Candidate Priorities。不要只输出气氛化总结；后续 requirements 文档会消费这些字段。
派对模式是 /workflows:brainstorm 的可选增强，不是独立流程：
/ce:brainstorm
│
├─ 默认模式：单代理逐步引导
│
└─ 派对模式（用户输入 [P] / [P+] 激活）
↓
多代理协作讨论
↓
结构化退出契约（共识 / 分歧 / 风险 / 复用机会 / 构建边界 / P1-P4）
↓
讨论结果整合到 requirements 文档
↓
继续 /ce:plan（流程不变）
核心原则：派对模式不只讨论「做什么」，还要讨论「用什么现成的来做」。
核心机制：胶水编程思维是代理的「本能」，不是可选功能。
用户正常对话
↓
┌─────────────────────────────────────┐
│ 🔍 代理内部自动检查（用户无感） │
│ │
│ • 有没有成熟的整体方案？ │
│ • 有没有可组合的现成库？ │
│ • 我们只需要写哪些胶水代码？ │
└─────────────────────────────────────┘
↓
代理发言时自然融入调研结果
这意味着：
| 场景 | 代理自动做的事 |
|---|---|
| 功能实现 | 「这个功能，XX 库可以直接用」 |
| 技术选型 | 「选 A 还是 B？先看看社区活跃度和 Stars」 |
| Sprint 复盘 | 「有没有现成的监控工具能避免这个问题？」 |
| 需求澄清 | 「这个需求，市面上有没有 SaaS 已经解决了？」 |
| 架构设计 | 「这个架构可以基于 XX 框架搭建」 |
用户不需要：
代理自动：
代理职责分配：
| 代理 | 胶水编程职责 |
|---|---|
| 🏗️ architect | 搜索是否有成熟架构/框架可直接采用 |
| 💻 developer | 评估库的 API 质量、维护状态、Stars 数 |
| 📊 analyst | 搜索是否有现成的整体解决方案 |
| 🚀 innovator | 搜索其他行业如何用现成工具解决类似问题 |
代理发言示例（自然融入，非死板格式）：
🏗️ 李明远：「关于视频转码，别急着自己写。fluent-ffmpeg
（Stars 7.8k）已经是 FFmpeg 的成熟 Node.js 封装，
API 设计很优雅。我们只需要写调用层就行。」
📊 陈思琪：「等等，我搜了一下，如果是云端场景，
腾讯云/阿里云都有现成的转码 API，按量付费。
先确认场景再选方案。」
💻 张晓峰：「fluent-ffmpeg 最近更新是上个月，
MIT 许可证，文档齐全。大概 20 行代码就能跑起来。」
重点：代理用自己的风格说话，但内容已经融入了胶水编程思维。
| 阶段 | 派对模式 | 胶水编程 |
|---|---|---|
| Brainstorm | ✅ 多视角讨论「做什么」 | ✅ 主动搜索现成方案 |
| Plan | ❌ 不参与 | ✅ 规划技术选型和依赖 |
| Work | ❌ 不参与 | ✅ 只写胶水代码 |
核心改变：派对模式不再只是「讨论观点」，而是「讨论观点 + 调研现成方案」。
| 场景 | 说明 |
|---|---|
| 重大技术选型 | 数据库、框架、架构模式的权衡 |
| 多方利益权衡 | 产品、技术、运营需求冲突时 |
| 复杂需求探索 | 需求模糊，需要多角度挖掘 |
| 事后复盘分析 | 故障分析、sprint 回顾 |
| 创意头脑风暴 | 产品创新、解决方案探索 |
| 场景 | 更好的选择 |
|---|---|
| 需求已明确 | 直接 /workflows:plan |
| 简单 bug 修复 | 直接 /workflows:work |
| 已有明确方案 | 直接执行 |
| 纯技术实现问题 | 咨询单个专业代理 |
用户： 「上个 sprint 认证服务宕机了 3 次，我想复盘一下原因。」
🏗️ 李明远（架构师）： 「先看故障模式。三次宕机是否有共同触发条件？我想确认是架构设计问题，还是实现偏离了规范。高并发时段？特定接口？」
💻 张晓峰（开发者）： 「我查了日志，三次都是高并发时触发。代码层面有两个问题：没有实现请求限流，连接池也没有优雅降级机制。这是实现遗漏。」
📋 王建国（产品经理）： 「等一下，我想问个更根本的问题——PRD 里有没有明确并发量预期？如果当初没这个需求，这可能是需求遗漏，不全是开发的锅。」
🛡️ 赵安全（安全专家）： 「补充一个安全视角：宕机期间有没有人利用这个窗口尝试未授权访问？需要检查那段时间的异常登录记录。」
用户： 「消息队列选 RabbitMQ 还是 Kafka？」
🏗️ 李明远： 「取决于核心场景。传统任务队列用 RabbitMQ，协议成熟；事件流需要持久化回放用 Kafka。先问：消息需要保留多久？」
💻 张晓峰： 「从开发体验看，RabbitMQ 学习曲线平缓，本地环境搭建简单。Kafka 运维复杂度高，没有经验的团队容易踩坑。」
⚡ 钱效能（性能专家）： 「吞吐量预期是多少？日均百万级以下 RabbitMQ 够用，Kafka 优势在千万级以上才明显。别过度设计。」
动态加载机制：为减少 token 消耗，代理人格按需加载，而非一次性全部读取。