name: meta-cognition-parallel description: “实验性：三层并行元认知分析。触发词：/meta-parallel, 三层分析, parallel analysis, 并行元认知” argument-hint: “<rust_question>”
并行元认知分析（实验性）
状态： 实验性 | 版本： 0.2.0 | 最后更新： 2025-01-27
此技能用于测试三层并行认知分析。
概念
与顺序分析不同，此技能同时启动三个并行分析器——每个对应一个认知层——然后综合它们的结果。
用户问题
│
▼
┌─────────────────────────────────────────────────────┐
│ 并行元认知分析器 │
│ （协调器） │
└─────────────────────────────────────────────────────┘
│
├─── 第一层 ──► 语言机制分析 ──► L1 结果
│
├─── 第二层 ──► 设计选择分析 ──► L2 结果
│ ├── 并行（代理模式）
│ │ 或 顺序（内联模式）
└─── 第三层 ──► 领域约束分析 ──► L3 结果
│
▼
┌─────────────────────────────────────────────────────┐
│ 跨层综合 │
│ （在主上下文中综合所有结果） │
└─────────────────────────────────────────────────────┘
│
▼
符合领域要求的架构解决方案
使用方法
/meta-parallel <你的Rust问题>
示例：
/meta-parallel 我的交易系统报 E0382 错误，应该用 clone 吗？
执行模式检测
关键：首先检查代理文件可用性以确定执行模式。
尝试读取层分析器文件：
../../agents/layer1-analyzer.md../../agents/layer2-analyzer.md../../agents/layer3-analyzer.md
代理模式（插件安装）- 并行执行
当所有层分析器文件存在于 ../../agents/ 目录时：
步骤 1：解析用户查询
从 $ARGUMENTS 中提取：
- 原始问题
- 任何代码片段
- 领域提示（交易、Web、嵌入式等）
步骤 2：启动三个并行代理
关键：在单条消息中启动所有三个任务以启用并行执行。
读取代理文件，然后并行启动：
Task(
subagent_type: "general-purpose",
run_in_background: true,
prompt: <../../agents/layer1-analyzer.md 的内容>
+ "
## 用户查询
" + $ARGUMENTS
)
Task(
subagent_type: "general-purpose",
run_in_background: true,
prompt: <../../agents/layer2-analyzer.md 的内容>
+ "
## 用户查询
" + $ARGUMENTS
)
Task(
subagent_type: "general-purpose",
run_in_background: true,
prompt: <../../agents/layer3-analyzer.md 的内容>
+ "
## 用户查询
" + $ARGUMENTS
)
步骤 3：收集结果
等待所有三个代理完成。每个代理返回结构化分析。
步骤 4：跨层综合
获得所有三个结果后，按照以下模板进行综合。
内联模式（仅技能安装）- 顺序执行
当层分析器文件不可用时，直接执行分析：
步骤 1：解析用户查询
与代理模式相同 - 从 $ARGUMENTS 中提取问题、代码和领域提示。
步骤 2：执行第一层 - 语言机制分析
分析涉及的 Rust 语言机制：
## 第一层：语言机制
**识别出的错误/模式：**
- 错误代码：E0XXX（如适用）
- 模式：所有权/借用/生命周期等
**根本原因：**
[从 Rust 所有权模型的角度解释此错误发生的原因]
**语言层面的解决方案：**
1. [解决方案 1]：描述
2. [解决方案 2]：描述
**置信度：** 高 | 中 | 低
**推理：** [说明此置信度的原因]
关注领域：
- 所有权规则（移动、复制、借用）
- 生命周期注解
- 借用规则（共享与可变）
- 错误代码及其含义
步骤 3：执行第二层 - 设计选择分析
分析设计模式和权衡：
## 第二层：设计选择
**设计模式上下文：**
- 当前方法：[正在使用的模式]
- 问题：[为什么它与 Rust 规则冲突]
**设计备选方案：**
| 模式 | 优点 | 缺点 | 使用场景 |
|---------|------|------|-------------|
| 模式 A | ... | ... | ... |
| 模式 B | ... | ... | ... |
**推荐模式：**
[哪种模式最合适及其原因]
**置信度：** 高 | 中 | 低
**推理：** [说明此置信度的原因]
关注领域：
- 智能指针选择（Box, Rc, Arc）
- 内部可变性模式（Cell, RefCell, Mutex）
- 所有权转移与共享
- 克隆与引用
步骤 4：执行第三层 - 领域约束分析
分析特定领域的要求：
## 第三层：领域约束
**识别出的领域：** [交易/金融科技 | Web | CLI | 嵌入式 | 等]
**领域特定要求：**
- [ ] 性能：[要求]
- [ ] 安全性：[要求]
- [ ] 并发性：[要求]
- [ ] 可审计性：[要求]
**领域最佳实践：**
1. [最佳实践 1]
2. [最佳实践 2]
**解决方案的约束：**
- 必须：[硬性要求]
- 应该：[软性要求]
- 避免：[此领域的反模式]
**置信度：** 高 | 中 | 低
**推理：** [说明此置信度的原因]
关注领域：
- 行业要求（金融科技法规、Web 可扩展性等）
- 性能约束
- 安全性和正确性要求
- 领域中的常见模式
步骤 5：跨层综合
结合所有三层：
## 跨层综合
### 各层结果摘要
| 层 | 关键发现 | 置信度 |
|-------|-------------|------------|
| L1（机制） | [摘要] | [等级] |
| L2（设计） | [摘要] | [等级] |
| L3（领域） | [摘要] | [等级] |
### 跨层推理
1. **L3 → L2：** [领域约束如何影响设计选择]
2. **L2 → L1：** [设计选择如何决定机制]
3. **L1 ← L3：** [领域对语言特性的直接影响]
### 综合推荐
**问题：** [用完整上下文重述]
**解决方案：** [符合领域要求的架构解决方案]
**理由：**
- 领域要求：[L3 约束]
- 设计模式：[L2 模式]
- 机制：[L1 实现]
### 置信度评估
- **总体：** 高 | 中 | 低
- **限制因素：** [哪一层的置信度最低]
输出模板
两种模式产生相同的输出格式：
# 三层元认知分析
> 查询：[用户的问题]
---
## 第一层：语言机制
[L1 分析结果]
---
## 第二层：设计选择
[L2 分析结果]
---
## 第三层：领域约束
[L3 分析结果]
---
## 跨层综合
### 推理链
L3 领域：[约束] ↓ 意味着 L2 设计：[模式] ↓ 通过 L1 机制：[特性]
### 最终推荐
**做：** [推荐的方法]
**不做：** [要避免的做法]
**代码模式：**
```rust
// 推荐的实现
分析由 meta-cognition-parallel v0.2.0（实验性）执行
---
## 测试场景
### 测试 1：交易系统 E0382
/meta-parallel 交易系统报 E0382，trade record 被 move 了
预期：L3 识别金融科技约束 → L2 建议共享不可变 → L1 推荐 Arc<T>
### 测试 2：Web API 并发
/meta-parallel Web API 中多个 handler 需要共享数据库连接池
预期：L3 识别 Web 约束 → L2 建议连接池 → L1 推荐 Arc<Pool>
### 测试 3：CLI 工具配置
/meta-parallel CLI 工具如何处理配置文件和命令行参数的优先级
预期：L3 识别 CLI 约束 → L2 建议配置优先级模式 → L1 推荐构建器模式
---
## 错误处理
| 错误 | 原因 | 解决方案 |
|-------|-------|----------|
| 代理文件未找到 | 仅技能安装 | 使用内联模式（顺序） |
| 代理超时 | 复杂分析 | 等待更长时间或使用内联模式 |
| 层结果不完整 | 代理问题 | 使用内联分析填充 |
## 限制
- **代理模式：** 并行执行，更快但需要插件安装
- **内联模式：** 顺序执行，较慢但随处可用
- 跨层综合质量取决于结果结构
- 可能比简单的单层分析有更高的延迟
## 反馈
这是实验性的。请报告问题和建议，以改进三层分析方法。