🔧 Feature-Dev 插件深度分析报告

作者：Alex（PM）｜日期：2026-03-31｜数据来源：CSDN、GitHub、Claude 官方插件文档

一、插件概述

1.1 是什么

1.2 一句话定义

把资深工程师从”需求分析 → 代码探索 → 架构设计 → 代码实现 → 质量审查 → 文档总结”的完整工作方法论，产品化成了一个插件。

1.3 解决的问题

二、核心工作流：七阶段详解

Discovery ──▶ Exploration ──▶ Clarifying ──▶ Architecture ──▶ Implementation ──▶ Quality ──▶ Summary  需求发现       代码探索        问题澄清       架构设计       代码实现        质量审查       总结文档

阶段一：Discovery（需求发现）

核心目标：确认”到底想做什么”，而不是听到笼统需求就开写。

工作内容：

• 分析需求的核心诉求
• 识别关键功能点
• 确定范围边界（什么做 / 什么不做）
• 明确成功标准

实际输出示例（“增加用户登录功能”→ Discovery 输出）：

## 功能需求确认### 核心功能添加用户身份认证系统，支持用户登录和会话管理### 关键需求1. 用户通过邮箱 + 密码登录2. 登录成功后创建会话3. 会话有效期 7 天4. 支持"记住我"功能5. 登录失败3次后锁定账户15分钟### 范围声明**包含**：登录页面 UI、登录 API、会话管理、基础安全措施**不包含**：第三方OAuth、多因素认证、SSO、用户注册### 成功标准- 用户可以成功登录- 会话正确管理- 通过基础安全测试- 响应时间 < 200ms

阶段二：Codebase Exploration（代码库探索）

核心目标：系统性理解现有代码，而不是漫无目的地翻目录。

工作内容：

• 启动多个 code-explorer Agent 并行探索
• 识别相关现有代码
• 梳理调用链和依赖关系
• 找出可复用组件
• 标记需修改的文件

实际输出示例：

## 代码库探索结果### 关键文件- src/auth/auth.service.ts — 现有认证服务（仅用于JWT验证）- src/users/users.service.ts — 用户数据访问层- src/database/entities/user.entity.ts — 用户实体定义### 可复用组件✅ 用户实体已定义（email, password字段存在）✅ 密码哈希工具已实现（bcrypt）✅ JWT工具类已存在⚠️ 会话管理需从零构建### 潜在冲突- auth.service.ts 当前仅处理JWT验证，需扩展登录逻辑- 环境变量需添加：SESSION_SECRET, SESSION_EXPIRY

阶段三：Clarifying Questions（澄清问题）

核心目标：挖掘边界条件、错误处理、兼容性等隐藏需求。

工作内容：

• 系统化提问：错误处理策略、边界条件、性能要求、兼容性、安全性
• 用户回答后确定实施细节

实际输出示例：

## 澄清问题（请逐项回答）### 1. 错误处理Q: 登录失败时返回什么信息？- [ ] A. 详细信息（"密码错误"/"用户不存在"）- [x] B. 通用信息（"邮箱或密码错误"）—— 更安全### 2. 会话管理Q: 会话存储方式？- [ ] A. 内存（简单但不支持多服务器）- [x] B. Redis（推荐，支持分布式）- [ ] C. 数据库（性能较差）Q: 同一用户多设备登录时？- [x] A. 允许多会话并存- [ ] B. 新登录踢掉旧会话- [ ] C. 限制最多N个会话### 3. 安全性Q: 密码复杂度要求？- [x] A. 至少8字符，包含大小写和数字- [ ] B. 至少12字符，包含特殊符号Q: 是否需要 HTTPS only cookie？- [x] A. 是（生产环境强制）

阶段四：Architecture Design（架构设计）

核心目标：提供多个架构方案，对比优缺点，给出推荐。

工作内容：

• 启动 code-architect Agent
• 设计 2-3 个可行方案
• 分析每个方案的优缺点
• 评估实施复杂度
• 给出推荐方案和理由

实际输出示例：

## 架构方案对比### 方案A：JWT + Redis Session（推荐）**设计**：登录成功生成JWT（15分钟）+ Redis存储Session（7天）+ Refresh Token续期✅ 优点：  - Stateless + Stateful 混合，兼顾性能和控制力  - 支持分布式部署  - 可主动踢用户（删除Redis Session）  - 支持"记住我"延长Session⚠️ 缺点：  - 依赖Redis（需额外运维）  - 实现复杂度中等📊 实施复杂度：⭐⭐⭐### 方案B：纯 JWT（无服务端Session）✅ 优点：完全Stateless，易于扩展❌ 缺点：无法主动踢用户，Token签发后无法撤回### 方案C：传统 Session-Cookie✅ 优点：实现简单❌ 缺点：不支持分布式，存在安全风险## 推荐方案**方案A**：JWT + Redis Session理由：兼顾安全性与可扩展性，支持主动会话管理

阶段五：Implementation（代码实现）

核心目标：按选定方案写代码，遵守现有代码风格和实践。

工作内容：

• 按架构方案逐步实现
• 遵守项目现有约定
• 每步记录改动内容
• 持续集成测试

阶段六：Quality Review（质量审查）

核心目标：多维度自动 Code Review，确保质量。

工作内容：

• 启动 3 个 code-reviewer 并行工作
• 从正确性、安全、性能、可维护性四个维度审查
• 基于置信度评分（默认 80 分以上才显示）
• 减少误报

阶段七：Summary（总结文档）

核心目标：自动生成面向未来维护者的总结文档。

输出内容：

• 改了哪些文件
• 为什么要这样改
• 下一步建议做什么
• 已知限制和风险

三、完整功能对比表

四、feature-dev + ralph-loop 组合：AI 编程完全体

这是最强大的使用方式，两个插件分工明确：

组合工作流

① /feature-dev 跑完7阶段       ↓② 产出文档：   - docs/feature/DESIGN.md（架构设计）   - docs/feature/IMPLEMENTATION_PLAN.md（实施计划）   - docs/feature/QUALITY_CRITERIA.md（质量标准）       ↓③ /ralph-loop 接管执行   - 读取上述文档作为任务书   - 持续迭代直到所有标准达成   - 产出：代码 + 测试 + 文档 + BLOCKERS/ATTEMPTS 记录

实际命令示例

# 第一步：feature-dev 规划/feature-dev 为API添加速率限制功能# 第二步：feature-dev 产出文档后，ralph-loop 执行/ralph-loop "实现API速率限制功能阅读 docs/rate-limiting/DESIGN.md阅读 docs/rate-limiting/IMPLEMENTATION_PLAN.md完成标准：所有测试通过 + 覆盖率 > 80% + 文档更新输出: FEATURE_RATE_LIMITING_COMPLETE" \--max-iterations 40 \--completion-promise "FEATURE_RATE_LIMITING_COMPLETE"

五、feature-dev 在 Claude Code 官方插件体系中的位置

Anthropic 官方共发布 13 个核心插件，feature-dev 是其中最复杂的一个：

六、适用场景 vs 不适用场景

✅ 适合用 feature-dev 的场景

❌ 不适合用 feature-dev 的场景

七、总结：一句话

feature-dev = 把”资深工程师开会讨论需求、设计方案、Code Review、写文档”的完整流程，产品化成了一个 Claude Code 插件。

它不帮你写代码，它帮你想清楚再写、写完了检查清楚、最后留下文档。

搭配 ralph-loop 使用 = 规划交给 feature-dev，执行交给 ralph-loop = AI 编程的完全体闭环。