Kim Orchestrator

AI多引擎编排技能

公众号：老金带你玩AI | 微信：xun900207 | 备注AI加入AI交流群

概述

自动协调三个AI引擎完成软件开发工作流： 1. Claude Code - 需求分析和技术方案设计 2. Codex CLI - 代码生成 3. Gemini CLI - 代码审查

工作流程

阶段1：需求分析（Claude）

分析用户需求，输出技术方案JSON：

{
  "task_description": "任务描述",
  "features": ["功能列表"],
  "tech_stack": {"language": "", "framework": "", "libraries": []},
  "file_structure": {"files": [{"path": "", "purpose": ""}]},
  "key_points": ["关键实现要点"],
  "risks": ["潜在风险"]
}

保存到：.kim-orchestrator/phase1_requirements.json

阶段2：代码生成（Codex）

调用Codex MCP Server生成代码：

使用 mcp__codex__codex 工具：
- prompt: 根据phase1的需求生成代码
- conversationId: "ai_team_<timestamp>"

保存到：.kim-orchestrator/phase2_code.md

阶段3：代码审查（Gemini）

调用Gemini MCP Server审查代码：

使用 mcp__gemini__gemini 工具：
- prompt: 审查phase2的代码
- reviewMode: true

保存到：.kim-orchestrator/phase3_review.md

配置

工作目录：.kim-orchestrator/

依赖

• Claude Code（必需）
• Codex CLI + MCP Server（可选，代码生成）
• Gemini CLI + MCP Server（可选，代码审查）

示例

# 简单任务
"实现用户登录功能"

# 复杂任务
"实现JWT登录，包含注册、登录、token刷新"

# 系统设计
"设计RBAC权限系统"

MCP Server健康检查模块

此模块被kim-code、kim-review、kim-team引用，用于检测MCP Server可用性

检测逻辑

Codex MCP Server检测

在调用 mcp__codex__codex 之前，先检测工具是否可用。

检测方式：尝试调用工具列表，确认 mcp__codex__codex 存在。

如果不可用，显示以下提示：

╔══════════════════════════════════════════════════════════════════╗
║  ⚠️ Codex MCP Server 未就绪                                      ║
╠══════════════════════════════════════════════════════════════════╣
║                                                                  ║
║  可能原因：                                                       ║
║  1. .mcp.json 配置文件不存在或配置错误                            ║
║  2. Claude Code 需要重启以加载MCP配置                             ║
║  3. mcp-servers/codex-server/index.js 文件缺失                   ║
║  4. Node.js 未安装或版本过低                                      ║
║                                                                  ║
║  修复步骤：                                                       ║
║  1. 确认 .mcp.json 存在且配置正确                                 ║
║  2. 完全退出并重启 Claude Code                                    ║
║  3. 运行 /kim-setup 检查完整环境                                  ║
║                                                                  ║
║  📖 详细文档：mcp-servers/INSTALLATION.md                         ║
║                                                                  ║
╚══════════════════════════════════════════════════════════════════╝

降级方案：

💡 Codex不可用，是否使用Claude直接生成代码？
（质量可能略低，但可以继续工作）

输入 Y 继续 / N 中止

Gemini MCP Server检测

在调用 mcp__gemini__gemini 之前，先检测工具是否可用。

检测方式：尝试调用工具列表，确认 mcp__gemini__gemini 存在。

如果不可用，显示以下提示：

╔══════════════════════════════════════════════════════════════════╗
║  ⚠️ Gemini MCP Server 未就绪                                     ║
╠══════════════════════════════════════════════════════════════════╣
║                                                                  ║
║  可能原因：                                                       ║
║  1. Gemini CLI 未安装（npm i -g @google/gemini-cli）              ║
║  2. 未完成Gemini认证（运行 gemini auth login）                    ║
║  3. 代理配置问题（中国用户需要配置代理）                           ║
║  4. .mcp.json 配置文件问题                                        ║
║                                                                  ║
║  修复步骤：                                                       ║
║  1. 确认代理已开启（检查 mcp-config.json 中的端口）               ║
║  2. 运行 gemini auth login 完成Google账号授权                     ║
║  3. 完全退出并重启 Claude Code                                    ║
║  4. 运行 /kim-setup 检查完整环境                                  ║
║                                                                  ║
║  📖 详细文档：mcp-servers/gemini-server/README.md                 ║
║                                                                  ║
╚══════════════════════════════════════════════════════════════════╝

降级方案：

💡 Gemini不可用，是否跳过代码审查？
（可以后续使用 /kim-review 单独审查）

输入 Y 继续 / N 中止

---

检测结果状态

健康检查返回以下状态之一：

---

引用方式

在kim-code、kim-review、kim-team命令中引用此模块：

## 阶段0：健康检查

在执行任何MCP调用前，按照 `.claude/skills/kim-orchestrator/prompts/health-check.md`
的规范检测对应MCP Server的可用性。

根据检测结果决定：
- ✅ READY → 继续执行
- ⚠️ PARTIAL → 询问用户是否降级执行
- ❌ UNAVAILABLE → 显示修复指南并中止

---

快速修复命令

# 检查完整环境
/kim-setup

# 检查MCP配置
cat .mcp.json

# 测试Codex连接
codex --version

# 测试Gemini认证
gemini auth status

# 重启Claude Code（完全退出后重新打开项目）

阶段1：需求分析提示词模板

你的任务

请作为资深技术架构师，详细分析以下任务的技术需求：

任务描述：{从orchestrate.sh传入的$TASK参数}

分析维度

1. 功能分解

将任务拆解成具体的功能清单，每个功能要：

• 清晰描述功能目标
• 明确输入和输出
• 标注优先级（P0/P1/P2）

2. 技术栈选型

根据任务特点推荐最合适的技术栈：

• 编程语言：选择理由
• 框架/库：为什么选这个？
• 数据库：SQL还是NoSQL？为什么？
• 第三方服务：是否需要？

3. 文件结构设计

设计清晰的项目文件结构：

project/
├── src/
│   ├── [模块1]/
│   │   ├── [文件1]  # 用途说明
│   │   └── [文件2]  # 用途说明
│   └── [模块2]/
├── tests/
└── docs/

4. 关键实现要点

列出实现过程中的关键技术点：

• 核心算法或逻辑
• 数据流设计
• API接口设计
• 性能优化考虑
• 安全性考虑

5. 风险评估

识别潜在风险和挑战：

• 技术风险（复杂度、性能）
• 依赖风险（第三方库、服务）
• 安全风险（数据泄露、认证）
• 向后兼容性风险

输出格式

请严格按照以下JSON格式输出（便于后续阶段解析）：

{
  "task_description": "任务描述（原文）",
  "analysis_date": "2025-12-04",
  "features": [
    {
      "name": "功能名称",
      "description": "功能详细描述",
      "priority": "P0",
      "input": "输入描述",
      "output": "输出描述"
    }
  ],
  "tech_stack": {
    "language": "编程语言",
    "language_reason": "选择理由",
    "framework": "框架名称",
    "framework_reason": "选择理由",
    "libraries": [
      {
        "name": "库名称",
        "purpose": "用途",
        "version": "推荐版本"
      }
    ],
    "database": {
      "type": "SQL/NoSQL",
      "engine": "具体数据库",
      "reason": "选择理由"
    }
  },
  "file_structure": {
    "root": "项目根目录名",
    "directories": [
      {
        "path": "目录路径",
        "purpose": "用途说明"
      }
    ],
    "files": [
      {
        "path": "文件路径",
        "purpose": "用途说明",
        "dependencies": ["依赖的其他文件"]
      }
    ]
  },
  "key_points": [
    {
      "category": "类别（如：核心算法、API设计）",
      "description": "详细说明",
      "code_example": "伪代码示例（可选）"
    }
  ],
  "risks": [
    {
      "type": "风险类型（技术/依赖/安全/兼容性）",
      "description": "风险描述",
      "severity": "严重程度（高/中/低）",
      "mitigation": "缓解措施"
    }
  ],
  "estimation": {
    "complexity": "复杂度评估（简单/中等/复杂）",
    "development_time": "预计开发时间",
    "testing_time": "预计测试时间"
  }
}

输出位置

将上述JSON保存到：.kim-orchestrator/phase1_requirements.json

注意事项

1. 实用主义优先：选择成熟稳定的技术，避免过度设计 2. 向后兼容：考虑现有系统的兼容性 3. 安全第一：明确标注安全风险和防范措施 4. 可测试性：设计时考虑如何编写单元测试 5. 文档清晰：技术选型要有充分理由，不要只说"好用"

---

这个阶段的输出将作为Codex代码生成的输入，请确保分析详尽、格式正确！

阶段2：代码生成提示词模板

你的任务

请作为资深开发工程师，根据阶段1的需求分析结果生成完整的可执行代码。

需求分析结果：{从phase1_requirements.json读取}

代码生成要求

1. 完整性

• 生成所有必要的文件（不要遗漏配置文件、测试文件）
• 包含依赖管理文件（package.json、requirements.txt等）
• 提供README.md说明如何运行

2. 代码质量

• 遵循语言的最佳实践和编码规范
• 使用有意义的变量名和函数名
• 保持函数单一职责（一个函数只做一件事）
• 避免过度嵌套（最多3层）

3. 注释规范

• 每个文件开头说明文件用途
• 每个公共函数/类添加文档注释
• 复杂逻辑添加行内注释
• 注释语言与代码库保持一致（中文或英文）

4. 错误处理

• 所有外部调用添加错误处理
• 提供清晰的错误消息
• 避免使用裸except/catch（要指定具体异常类型）

5. 安全性

• 敏感信息用环境变量（不要硬编码API密钥）
• 验证所有用户输入
• 使用参数化查询防止SQL注入
• 密码必须加密存储

6. 可测试性

• 为关键功能生成单元测试
• 测试覆盖核心业务逻辑
• 提供测试运行命令

输出格式

请使用Markdown格式输出，每个文件用代码块标注：

````markdown

项目代码生成结果

项目结构

\\\ project/ ├── src/ │ ├── main.py │ ├── config.py │ └── utils.py ├── tests/ │ └── test_main.py ├── requirements.txt └── README.md \\\

文件内容

src/main.py

\\\`python """ 主程序入口 功能：[描述] """

def main(): """主函数""" pass

if __name__ == "__main__": main() \\\`

src/config.py

\\\`python """ 配置文件 管理项目的所有配置项 """

import os

从环境变量读取敏感信息

API_KEY = os.getenv("API_KEY", "") \\\`

requirements.txt

\\\`

项目依赖

requests==2.31.0 python-dotenv==1.0.0 \\\`

README.md

\\\`markdown

项目名称

安装

\\\bash pip install -r requirements.txt \\\

运行

\\\bash python src/main.py \\\

测试

\\\bash pytest tests/ \\\ \\\`

实现说明

[解释关键实现逻辑、设计决策、注意事项]

依赖说明

• requests: HTTP请求库
• python-dotenv: 环境变量管理

下一步

1. 配置环境变量（创建.env文件） 2. 安装依赖（pip install -r requirements.txt） 3. 运行测试（pytest tests/） 4. 启动项目（python src/main.py） ````

输出位置

将上述Markdown保存到：.kim-orchestrator/phase2_code.md

代码示例参考

Python项目结构

# 良好的Python函数示例
def calculate_total(items: list[dict]) -> float:
    """
    计算订单总金额

    Args:
        items: 订单项列表，格式 [{"price": 10.0, "quantity": 2}, ...]

    Returns:
        float: 总金额

    Raises:
        ValueError: 如果items为空或格式不正确
    """
    if not items:
        raise ValueError("订单项不能为空")

    total = sum(item["price"] * item["quantity"] for item in items)
    return round(total, 2)

JavaScript/TypeScript项目结构

// 良好的TypeScript函数示例
/**
 * 计算订单总金额
 * @param items - 订单项列表
 * @returns 总金额
 * @throws {Error} 如果items为空
 */
function calculateTotal(items: OrderItem[]): number {
  if (items.length === 0) {
    throw new Error("订单项不能为空");
  }

  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

注意事项

1. KISS原则：能用简单方法解决的，不要搞复杂 2. DRY原则：重复的代码提取成函数/类 3. YAGNI原则：不要写用不到的代码 4. 向后兼容：不要破坏现有API接口 5. 性能考虑：关键路径的代码要考虑性能 6. 代码可运行：生成的代码必须能直接运行（不要占位符）

---

这个阶段的输出将作为Gemini代码审查的输入，请确保代码质量高、注释清晰！

阶段3：代码审查提示词模板

你的任务

请作为资深代码审查专家，对阶段2生成的代码进行全面审查。

生成的代码：{从phase2_code.md读取}

审查维度

1. 代码质量（25分）

• 可读性：变量命名、函数命名是否清晰？
• 结构性：代码组织是否合理？模块划分是否清晰？
• 复杂度：是否存在过度复杂的逻辑？嵌套层级是否过深？
• 注释：注释是否充分？是否准确？

评分标准：

• 优秀（20-25分）：命名清晰、结构合理、复杂度低、注释充分
• 良好（15-19分）：大部分符合规范，少量改进空间
• 一般（10-14分）：存在明显问题，需要重构
• 差（0-9分）：可读性差，需要大量改进

2. 安全性（25分）

• 输入验证：是否验证所有外部输入？
• 敏感信息：API密钥、密码是否硬编码？
• SQL注入：数据库查询是否使用参数化？
• XSS防护：用户输入是否正确转义？
• 权限控制：是否有适当的权限检查？

评分标准：

• 优秀（20-25分）：无安全漏洞，防护措施完善
• 良好（15-19分）：少量安全问题，影响较小
• 一般（10-14分）：存在中等安全风险
• 差（0-9分）：存在高危安全漏洞

3. 性能（20分）

• 算法效率：时间复杂度是否合理？
• 资源使用：内存使用是否优化？
• 数据库查询：是否存在N+1问题？
• 缓存策略：是否有合理的缓存？

评分标准：

• 优秀（16-20分）：性能优秀，无明显瓶颈
• 良好（12-15分）：性能良好，少量优化空间
• 一般（8-11分）：存在性能问题
• 差（0-7分）：严重性能问题

4. 可维护性（15分）

• 代码复用：是否避免重复代码？
• 依赖管理：依赖是否合理？版本是否固定？
• 测试覆盖：是否有充分的单元测试？
• 文档：README是否完整？

评分标准：

• 优秀（12-15分）：易于维护和扩展
• 良好（9-11分）：维护性良好
• 一般（6-8分）：存在维护难点
• 差（0-5分）：难以维护

5. 最佳实践（15分）

• 设计模式：是否使用合适的设计模式？
• 错误处理：异常处理是否完善？
• 日志记录：是否有适当的日志？
• 配置管理：配置是否外部化？

评分标准：

• 优秀（12-15分）：完全符合最佳实践
• 良好（9-11分）：大部分符合
• 一般（6-8分）：部分符合
• 差（0-5分）：不符合最佳实践

输出格式

请严格按照以下Markdown格式输出：

# 代码审查报告

**审查时间**: 2025-12-04 12:00:00
**审查者**: Gemini 3 Pro
**代码来源**: 阶段2生成

---

## 总体评分

| 维度 | 得分 | 满分 | 评级 |
|------|------|------|------|
| 代码质量 | XX | 25 | 优秀/良好/一般/差 |
| 安全性 | XX | 25 | 优秀/良好/一般/差 |
| 性能 | XX | 20 | 优秀/良好/一般/差 |
| 可维护性 | XX | 15 | 优秀/良好/一般/差 |
| 最佳实践 | XX | 15 | 优秀/良好/一般/差 |
| **总分** | **XX** | **100** | **优秀/良好/一般/差** |

---

## 发现的问题

### 🔴 严重问题（必须修复）

1. **[问题类型]** 问题描述
   - **文件**: `src/main.py:42`
   - **问题**: 详细描述
   - **风险**: 安全/性能/功能影响
   - **修复建议**: 具体改进方法
   - **修复后代码**:

改进后的代码示例

### 🟡 中等问题（建议修复）

1. **[问题类型]** 问题描述
   - **文件**: `src/utils.py:15`
   - **问题**: 详细描述
   - **改进建议**: 具体优化方法

### 🟢 轻微问题（可选优化）

1. **[问题类型]** 问题描述
   - **改进建议**: 简要说明

---

## 优点总结

1. ✅ 代码结构清晰，模块划分合理
2. ✅ 注释充分，易于理解
3. ✅ [其他优点]

---

## 详细审查

### 代码质量审查

**可读性**: [评价]
**结构性**: [评价]
**复杂度**: [评价]
**注释**: [评价]

**具体问题**:
- [问题1]
- [问题2]

### 安全性审查

**输入验证**: [评价]
**敏感信息**: [评价]
**注入防护**: [评价]

**具体问题**:
- [问题1]
- [问题2]

### 性能审查

**算法效率**: [评价]
**资源使用**: [评价]
**数据库查询**: [评价]

**具体问题**:
- [问题1]
- [问题2]

### 可维护性审查

**代码复用**: [评价]
**依赖管理**: [评价]
**测试覆盖**: [评价]

**具体问题**:
- [问题1]
- [问题2]

### 最佳实践审查

**设计模式**: [评价]
**错误处理**: [评价]
**日志记录**: [评价]

**具体问题**:
- [问题1]
- [问题2]

---

## 优化建议

### 立即执行（高优先级）

1. **修复安全漏洞**
   - 问题：[描述]
   - 修复：[方法]

2. **性能优化**
   - 问题：[描述]
   - 优化：[方法]

### 后续改进（中优先级）

1. **重构建议**
   - 位置：[文件]
   - 理由：[原因]
   - 方法：[具体步骤]

### 长期优化（低优先级）

1. **架构改进**
   - 建议：[描述]
   - 收益：[好处]

---

## 改进后的关键代码示例

### 示例1：安全性改进

**原代码**:

不安全的代码

password = "hardcoded_password"

**改进后**:

安全的代码

import os password = os.getenv("PASSWORD") if not password: raise ValueError("PASSWORD环境变量未设置")

### 示例2：性能优化

**原代码**:

低效的代码

for user in users: profile = db.query(Profile).filter(Profile.user_id == user.id).first()

**改进后**:

高效的代码（避免N+1问题）

profiles = db.query(Profile).filter(Profile.user_id.in_([u.id for u in users])).all() profile_map = {p.user_id: p for p in profiles}

---

## 审查总结

**总体评价**: [一段话总结代码质量]

**是否推荐使用**: ✅ 推荐 / ⚠️ 需改进后使用 / ❌ 不推荐

**关键建议**: [最重要的3条建议]

---

**审查完成！所有问题已详细标注，建议优先修复🔴严重问题。**

输出位置

将上述Markdown保存到：.kim-orchestrator/phase3_review.md

审查注意事项

1. 客观评价：基于事实和标准，不要主观臆断 2. 提供示例：对于问题，提供具体的改进代码 3. 优先级明确：区分严重/中等/轻微问题 4. 平衡视角：既要指出问题，也要肯定优点 5. 实用建议：改进建议要具体可执行，不要空泛

---

这是最后一个阶段，审查报告将直接呈现给用户，请确保专业、详尽、有价值！