我在深度使用 Claude Code 的过程中，逐渐意识到一个核心问题：直接让 AI 写代码，虽然快速，但往往缺乏系统性。
它会跳过架构设计、跳过需求澄清，甚至不问你实际想要什么，直接"猛干"。结果是代码能跑，但质量参差不齐。
直到发现了 Anthropic 官方的 Feature-Dev 插件，我才明白——这才是专业的功能开发应该有的样子。
为什么需要结构化工作流？
传统的 Claude Code 使用方式存在明显瓶颈。
以添加"OAuth 登录功能"为例：
- 直接硬塞逻辑到现有代码里，不考虑架构兼容性
- 不问支持哪些 OAuth 提供商、Token 存储策略等关键细节
- 忽视向后兼容性和集成风险
- 最终代码能运行，但充满技术债
Feature-Dev 则提供了完全不同的工作方式：并行分析代码库架构 → 提出澄清性问题 → 设计多种实现方案 → 等待确认后再编码 → 质量审查 → 决策文档化。
Feature-Dev 的架构基础
1. Code-Explorer（代码探索者）
职责是深度理解现有代码库。它会：
- 追踪代码执行路径（从入口到数据存储）
- 分析架构层次和设计模式
- 定位类似功能的实现方式
输出示例：找到现有的 JWT 认证机制、Redis 会话管理、API 限流策略等关键组件，并精确指向源文件位置。
2. Code-Architect（架构设计师）
基于代码探索结果，提出 2-3 种实现方案，各有权衡：
- 最小改动方案 — 快速但耦合度高
- 清晰架构方案 — 优雅但改动大
- 务实平衡方案 — 折中选择（通常被推荐）
关键是它不给"唯一答案"，而是让你做知情决策。
3. Code-Reviewer（质量审查员）
并行启动 3 个评审器，分别关注：
- 代码简洁性和优雅度
- 逻辑错误和功能正确性
- 项目规范和抽象一致性
重要创新：使用"置信度过滤"机制（只报告置信度 ≥80 的问题），避免 AI 过度挑剔。
七阶段工作流详解
| 阶段 | 核心任务 | 关键点 |
| Phase 1: Discovery | 确认需求范围和目标 | 描述得越清楚，后续越顺畅 |
| Phase 2: Codebase Exploration | 并行启动多个探索智能体分析现有代码 | 这是决定代码质量的关键——真正理解你的项目 |
| Phase 3: Clarifying Questions | 列出所有需要澄清的细节（边界情况、错误处理、集成点等） | 形成问题清单，等待你逐一回答 |
| Phase 4: Architecture Design | 综合多个架构方案，展示权衡分析 | 确认方案后才进入编码阶段 |
| Phase 5: Implementation | 严格遵循设计方案编写代码 | 不会自动开始，需明确批准 |
| Phase 6: Quality Review | 多维度审查代码质量，识别高优先级问题 | 你决定修复、稍后处理还是接受 |
| Phase 7: Summary | 文档化所有决策和修改，便于后续回顾 | 几个月后回看决策依据时价值巨大 |
插件系统技术实现
插件的四大组件：
- Slash Commands — 快捷操作（如 /feature-dev）
- Subagents — 专门的开发任务智能体
- MCP Servers — 通过 Model Context Protocol 连接外部工具和数据源
- Hooks — 在工作流关键点自定义行为
标准插件目录结构：
my-plugin/
├── .claude-plugin/
│ └── plugin.json # 插件元数据（必需）
├── commands/ # 斜杠命令
│ └── my-command.md
├── agents/ # 专门智能体
│ └── specialist.md
├── skills/ # Agent 技能库
│ └── my-skill/SKILL.md
├── hooks/ # 事件处理器
│ └── hooks.json
└── README.md
每个 Agent 本质上是一个 Markdown 文件，包含 Frontmatter（名称、工具、模型配置）和 Prompt（具体指令），Claude Code 会根据这些指令启动并行智能体。
实践建议
最佳使用场景：
- 中等复杂度功能开发（非平凡但不超出上下文范围）
- 需要架构设计和权衡决策的功能
- 涉及多个文件修改的功能
- 需求描述不完全清晰的情况
不适合的场景：
- 简单 bug 修复（一行代码级别）
- 超级复杂功能（易耗尽上下文）
- 已有详细设计文档（直接编码即可）
关键最佳实践：
- 编写 CLAUDE.md 文件 — 在项目根目录定义你的技术栈、架构约定、命名规范。架构师智能体会读取此文件确保代码符合你的风格。
- 保持上下文精简 — 不在单一会话里做太多不相关任务，定期开新会话，保持 CLAUDE.md 最小化。
- 善用迭代 — 第一版可能还不错，经过 2-3 轮迭代（特别在 Phase 6 审查阶段）通常质量显著提升。
- 明确决策点 — Phase 4 的架构设计必须明确确认，不要模糊同意。
社区生态
Feature-Dev 只是开始。整个插件生态已形成：
- PR Review Toolkit — 专门的代码审查工作流
- Security Scanner — 安全漏洞扫描
- Full-Stack Orchestration — 全栈开发协调
任何人都可以创建并共享插件。通过打包工作流和最佳实践，可以让整个团队或社区受益。这是 Claude Code 生态真正强大的地方——从工具的"表演舞台"变成了"协作平台"。
个人总结
经过几周的深度使用，我对 Feature-Dev 的核心价值有了清晰认识：它把功能开发从"随机过程"转变为"结构化协作"。
最直观的感受是心态转变——以前用 Claude Code 时，我是在"看 AI 表演"；现在用 Feature-Dev，我是在"与 AI 协作"。我做架构决策，AI 执行设计；我审视实现方案，AI 持续优化。每个环节都透明、可控、可预测。
当然，它也有明确的适用边界。太简单的功能用它会显得"杀鸡用牛刀"，太复杂的功能可能会在 Phase 2 就因上下文耗尽而困难。但恰好在"中等复杂度"这个广泛的实际工作区间，Feature-Dev 表现得接近完美。
如果你也在用 Claude Code，我的诚恳建议是：花 30 分钟尝试一次 /feature-dev 工作流。我敢说，你会重新理解什么叫"人机协作"的编程体验。
Claude Code 插件系统：https://github.com/anthropics/claude-code/tree/main/plugins
Feature-Dev 插件仓库：https://github.com/anthropics/claude-code/tree/main/plugins/feature-dev