用 Claude Code 管理完整项目：从需求到上线的开发工作流指南

很多人把 Claude Code 当成一个"高级代码补全工具"，打开就开始让它写代码。这是最常见的错误用法。Claude Code 真正的价值，是让它参与你从需求分析到项目上线的每一个阶段。这篇文章会给你一套完整的、可落地的项目开发工作流。

---

先理解一个核心原则

所有成功的 AI 辅助开发工作流都遵循同一个模式：

Research → Plan → Execute → Review → Ship

翻译过来就是：调研 → 规划 → 执行 → 审查 → 交付。

这不是什么新发明——这就是软件工程的基本流程。但 AI 时代的关键区别在于：Claude Code 可以在每个阶段扮演不同的角色，而不仅仅是"帮你写代码"那一步。

软件工程中有一个经典的 40-20-40 法则：40% 的时间应该花在规划和设计上，20% 花在编码上，40% 花在测试和部署上。大多数人用 AI 工具时，把 90% 的注意力放在了那 20% 的编码上，这就是问题所在。

---

全景地图：一个项目的完整生命周期

在展开每个阶段之前，先看一张全景图。后面的内容会逐一深入。

┌─────────────────────────────────────────────────────────┐
│                    第零步：项目初始化                       │
│              写 CLAUDE.md，搭好工程骨架                     │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  前期（40%）                                              │
│  ┌───────────┐  ┌──────────┐  ┌───────────┐            │
│  │ 需求分析   │→│ 可行性验证 │→│ 技术选型   │            │
│  └───────────┘  └──────────┘  └───────────┘            │
│  ┌───────────┐  ┌──────────┐  ┌───────────┐            │
│  │ UI/UX原型  │→│ 数据模型  │→│ API契约    │            │
│  └───────────┘  └──────────┘  └───────────┘            │
│  ┌───────────┐  ┌──────────┐  ┌───────────┐            │
│  │ 架构设计   │→│ 工程基建  │→│ 风险识别   │            │
│  └───────────┘  └──────────┘  └───────────┘            │
│  ┌───────────┐                                          │
│  │ 计划拆分   │                                          │
│  └───────────┘                                          │
│  工具：Plan Mode + 对话                                   │
│                                                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  中期（20%）                                              │
│  ┌───────────┐  ┌──────────┐  ┌───────────┐            │
│  │ 功能开发   │→│ 单元测试  │→│ 代码自检   │            │
│  └───────────┘  └──────────┘  └───────────┘            │
│  工具：Skill（implement、review）                         │
│                                                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  后期（40%）                                              │
│  ┌───────────┐  ┌──────────┐  ┌───────────┐            │
│  │ 集成测试   │→│ 安全审计  │→│ 性能优化   │            │
│  └───────────┘  └──────────┘  └───────────┘            │
│  ┌───────────┐  ┌──────────┐                            │
│  │ 文档编写   │→│ 发布上线  │                            │
│  └───────────┘  └──────────┘                            │
│  工具：Agent（可选）+ Skill + 对话                        │
│                                                         │
└─────────────────────────────────────────────────────────┘

---

第零步：项目初始化——搭好骨架再开工

在做任何事情之前，先完成两件事：创建项目仓库 和 写好 CLAUDE.md。

创建 CLAUDE.md

CLAUDE.md 是项目的"宪法"——每次你和 Claude Code 对话，它都会自动加载这个文件。所以里面应该放那些永远成立、每次对话都该遵守的信息。

一个真实项目的 CLAUDE.md 大概长这样：

# 项目：TaskFlow — 团队任务管理平台

## 技术栈
- 前端：Next.js 14 + TypeScript + Tailwind CSS + Zustand
- 后端：Node.js + NestJS + PostgreSQL + Prisma
- 测试：Vitest（单元）+ Playwright（E2E）
- 部署：Docker + AWS ECS

## 项目结构
- /apps/web — Next.js 前端应用
- /apps/api — NestJS 后端服务
- /packages/shared — 前后端共享的类型和工具函数
- /docs — 设计文档、架构决策记录、接口定义

## 开发规范
- 用中文交流
- Git 提交用 Conventional Commits 格式
- 新增功能必须有对应的测试用例
- 代码风格遵循项目 ESLint + Prettier 配置
- 组件使用函数式写法 + React Hooks
- API 路径遵循 RESTful 风格

## 分支策略
- main：生产分支，只接受 PR 合并
- develop：开发分支
- feature/*：功能分支，从 develop 创建

进阶技巧：分层 CLAUDE.md。 你可以在子目录放更具体的 CLAUDE.md。比如 /apps/web/CLAUDE.md 写前端专属规范，/apps/api/CLAUDE.md 写后端专属规范。Claude Code 会同时加载所有层级的 CLAUDE.md。

搭建工程基础设施

这一步很多人会推迟到"开发阶段再说"，但提前搭好会让后面所有阶段都更顺畅。你可以直接让 Claude 帮你做：

帮我初始化这个 monorepo 项目：
1. 用 pnpm workspace 管理 /apps/web、/apps/api、/packages/shared
2. 配置 ESLint + Prettier，统一代码风格
3. 配置 Husky + commitlint，规范提交信息
4. 创建基础的 GitHub Actions CI：push 时执行 lint + test + build
5. 写一个 docker-compose.yml 用于本地开发（PostgreSQL + Redis）

产出物：一个干净的、开箱即用的项目骨架。后面的每一步都建立在这个基础上。

---

前期：花 40% 的时间想清楚（写代码之前）

前期是整个项目中投入产出比最高的阶段。这个阶段的所有工作，都在 Claude Code 的 Plan Mode 中完成——只读、只分析、不改代码。

进入方式：Shift+Tab 按两次。

环节一：需求分析

目标：把模糊的想法变成清晰的功能清单。

怎么做：不要自己写需求文档给 Claude 看，而是让 Claude 来"面试"你。这样做的好处是，Claude 会追问你没想到的细节。

我要做一个团队任务管理平台。请用 AskUserQuestion 工具来面试我，
帮我澄清需求。每次只问一个问题。
重点了解：目标用户、核心功能、业务流程、非功能需求。

Claude 会像产品经理一样逐步追问：

• “任务有几种状态？转换规则是什么？”
• “需要支持多少人的团队？并发量预期？”
• “有没有权限管理需求？不同角色能做什么？”

面试结束后，让 Claude 输出一份结构化的需求文档：

根据刚才的讨论，帮我输出一份需求规格文档到 /docs/requirements.md，
包含：功能需求清单、非功能需求、用户故事、MVP范围界定（必须有 vs 可以后做）

产出物：/docs/requirements.md

环节二：可行性验证

目标：确认关键技术路径走得通，不要写到一半发现方案不可行。

这一步容易被跳过，但非常重要。它不是让你写完整的原型，而是针对最不确定的技术点做快速验证（spike）。

在我们的需求中，实时协作编辑任务描述是一个核心功能。
帮我调研以下方案的可行性：
1. 用 WebSocket + CRDT（如 Yjs）实现
2. 用 Server-Sent Events + 操作锁实现
3. 用第三方服务（如 Liveblocks）实现

从技术复杂度、成本、维护难度、延迟表现四个维度对比。
如果推荐方案 1，帮我写一个最小 spike 原型验证连接和冲突解决。

产出物：/docs/feasibility.md（调研报告）+ 可选的 spike 原型代码

环节三：技术选型

目标：确定技术栈并记录选型理由。

如果你在项目初始化时已经确定了技术栈，这一步可以简化为"验证和记录"。关键是要记录为什么选这个，而不仅仅是"选了什么"——半年后你忘了决策原因时会感谢自己。

帮我创建一份技术选型决策记录（ADR）到 /docs/adr-001-tech-stack.md。
记录我们选择 NestJS + Prisma + PostgreSQL 的理由，
以及我们排除 Express + TypeORM 和 Fastify + Drizzle 的原因。
格式用标准 ADR：背景、决策、理由、后果。

产出物：/docs/adr-001-tech-stack.md

环节四：UI/UX 原型

目标：在写前端代码之前，先验证界面逻辑和用户流程。

低保真原型的价值在于：花 1 小时画草图发现的问题，写了代码之后要花 1 天去改。

你可以用 Figma 画线框图，也可以直接让 Claude 帮你用文本描述：

根据需求文档，帮我为以下核心页面设计文本线框图：
1. 任务看板页（拖拽排序、筛选、快速创建）
2. 任务详情页（描述编辑、评论、附件、状态流转）
3. 团队设置页（成员管理、角色权限）

每个页面包含：布局结构、关键交互、组件列表。
输出到 /docs/wireframes.md

如果你有 Figma 的设计稿，可以截图拖拽到 Claude Code 终端中。Claude 能识别截图中的 UI 结构，后续开发时就能参照设计图来实现。

产出物：/docs/wireframes.md 或 Figma 设计稿

环节五：数据模型设计

目标：定义核心实体、关系和表结构。

这一步很多人混在"架构设计"里一笔带过，但它值得单独花时间。改表结构的成本远高于改业务逻辑——一旦有了线上数据，改表就意味着写迁移脚本、处理数据兼容、可能还要停机。

根据需求文档，帮我设计数据模型：
1. 画出实体关系图（用 Mermaid erDiagram 格式）
2. 定义 Prisma schema 的初始版本
3. 标注哪些字段需要索引、为什么
4. 考虑软删除、审计字段（created_at、updated_at）、多租户隔离

输出到 /docs/data-model.md，Prisma schema 写到 /apps/api/prisma/schema.prisma

产出物：/docs/data-model.md + prisma/schema.prisma

环节六：API 契约设计

目标：定义前后端通信的"合同"，让前后端可以并行开发。

这是前后端分离项目中最容易被忽略、却最影响效率的一步。没有 API 契约，前端就得等后端接口写好才能开始调用，后端也不知道前端到底需要什么字段，最后联调时互相返工。

根据需求文档和数据模型，帮我设计 RESTful API：
1. 列出所有接口：路径、方法、请求体、响应体、错误码
2. 用 OpenAPI/Swagger 格式输出到 /docs/api-spec.yaml
3. 同时生成一份人类可读的接口文档到 /docs/api-design.md
4. 在 /packages/shared/types 中定义前后端共享的 TypeScript 类型

遵循以下约定：
- 分页用 cursor-based pagination
- 错误响应格式：{ code: string, message: string, details?: object }
- 认证用 Bearer Token

有了 API 契约后，前端可以用 Mock Service Worker（msw）根据 spec 生成 mock 数据先行开发，后端按照契约实现接口。两边互不等待，联调时只需要把 mock 切换成真实 API。

产出物：/docs/api-spec.yaml + /docs/api-design.md + 共享类型定义

环节七：架构设计

目标：确定系统组件如何组织、数据如何流转、如何部署。

根据需求和技术选型，帮我做系统架构设计：
1. 画系统组件图（Mermaid flowchart 格式）：前端、后端、数据库、缓存、消息队列、第三方服务的关系
2. 描述核心数据流：用户创建任务、任务状态流转、实时通知的完整路径
3. 设计部署架构：本地开发 → staging → production 的环境区别
4. 记录关键架构决策（ADR 格式）

输出到 /docs/architecture.md

产出物：/docs/architecture.md

环节八：风险识别

目标：在问题发生之前就想好应对方案。

根据我们目前的设计，帮我做风险评估：
1. 技术风险：哪些功能的实现难度最不确定？
2. 依赖风险：如果某个第三方服务挂了怎么办？
3. 进度风险：如果时间不够，按什么优先级砍功能？
4. 安全风险：有哪些需要特别注意的安全问题？

每个风险给出：概率、影响程度、应对策略。
输出到 /docs/risk-assessment.md

产出物：/docs/risk-assessment.md

环节九：计划拆分

目标：把宏大的设计拆成可执行的小任务。

根据所有前期文档，帮我制定开发计划：
1. 定义 3-4 个里程碑，每个里程碑是一个可交付的版本
2. 每个里程碑下拆解具体任务（粒度：1-4小时可完成）
3. 标注任务间的依赖关系
4. 给出时间估算（乐观/悲观/最可能）
5. 标记关键路径上的任务

里程碑建议：
- M1：核心数据模型 + API框架 + 基础认证
- M2：任务CRUD + 看板视图 + 拖拽排序
- M3：实时协作 + 通知系统
- M4：权限管理 + 性能优化 + 部署

输出到 /docs/project-plan.md

产出物：/docs/project-plan.md

前期总结

到这一步，你的 /docs 目录应该有这些文件：

/docs
├── requirements.md          # 需求规格
├── feasibility.md           # 可行性验证报告
├── adr-001-tech-stack.md    # 技术选型决策
├── wireframes.md            # UI 线框图
├── data-model.md            # 数据模型设计
├── api-spec.yaml            # API 规范（OpenAPI 格式）
├── api-design.md            # API 可读文档
├── architecture.md          # 架构设计
├── risk-assessment.md       # 风险评估
└── project-plan.md          # 项目计划

所有这些都在 Plan Mode 中完成，不需要任何 Skill 或 Agent。 Plan Mode 本身就是前期阶段最好的工具。

---

中期：集中精力写代码（20%）

现在你有了清晰的需求、完整的设计文档和详细的任务清单。是时候动手了。

配置开发阶段的 Skill

中期的核心诉求是固化重复的开发流程。你不希望每次写功能都重新描述一遍"先写测试、再写代码、最后跑测试"。把它们做成 Skill，一次定义、反复使用。

推荐创建 2-3 个 Skill 就足够了：

Skill 1：implement（功能实现）

# .claude/skills/implement/SKILL.md
---
name: implement
description: 实现一个功能特性。按照 TDD 方式，先写测试再写代码。当需要开发新功能或修复 bug 时使用。
---

## 实现流程

按以下步骤实现功能：

### 1. 理解需求
- 阅读 /docs/requirements.md 中的相关需求
- 阅读 /docs/api-design.md 中的相关接口定义
- 如果有不确定的地方，先问我确认

### 2. 编写测试（Test First）
- 根据需求编写失败的测试用例
- 覆盖正常路径、边界条件和错误情况
- 运行测试，确认测试**失败**（红）

### 3. 编写实现
- 写**最少**的代码让测试通过
- 不要提前优化，不要添加需求之外的功能
- 运行测试，确认测试**通过**（绿）

### 4. 重构
- 在测试通过的基础上优化代码结构
- 消除重复、改善命名、简化逻辑
- 再次运行测试，确认仍然**通过**

### 5. 验证
- 运行完整测试套件，确认没有破坏其他功能
- 检查 TypeScript 编译无错误
- 检查 ESLint 无报错

### 6. 总结
- 给出简短的变更摘要（涉及哪些文件、做了什么）
- 如果发现了需求文档中的遗漏或矛盾，指出来

Skill 2：review（代码审查）

# .claude/skills/review/SKILL.md
---
name: review
description: 审查代码的质量、安全性和规范性。在提交 PR 前自检，或被要求做代码审查时使用。
tools: Read, Grep, Glob
---

## 审查维度

对代码进行以下维度的审查：

### 1. 正确性
- 逻辑是否正确？有无边界条件遗漏？
- 空值/undefined 处理是否到位？
- 异步操作的错误处理是否完善？

### 2. 安全性
- 是否有 SQL 注入、XSS、CSRF 风险？
- 敏感数据（密码、token）是否正确处理？
- 权限检查是否到位？

### 3. 性能
- 是否有 N+1 查询问题？
- 是否有不必要的重复计算或内存泄漏风险？
- 数据库查询是否利用了索引？

### 4. 规范性
- 是否符合 CLAUDE.md 中定义的项目规范？
- 命名是否清晰、一致？
- 代码结构是否合理？

### 5. 测试覆盖
- 关键逻辑是否有测试？
- 边界情况和错误路径是否被覆盖？

## 输出格式

按严重程度分类：
- 🔴 **必须修复**：会导致 bug、安全漏洞或数据丢失
- 🟡 **建议改进**：影响可维护性或性能
- 🟢 **可选优化**：代码风格或细微改进

每条反馈包含：问题描述、所在文件和位置、改进建议（附代码示例）。

Skill 3：commit（提交变更）

# .claude/skills/commit/SKILL.md
---
name: commit
description: 提交代码变更，生成规范的 commit message。
disable-model-invocation: true
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git commit:*)
---

## 提交流程

1. 运行 `git status` 和 `git diff` 查看变更内容
2. 根据变更内容生成 Conventional Commits 格式的提交信息
3. 格式：`type(scope): description`
   - type：feat / fix / refactor / test / docs / chore
   - scope：受影响的模块（web / api / shared）
   - description：简洁描述变更（中文）
4. 如果变更涉及多个不相关的改动，分成多个 commit
5. 执行 git add 和 git commit

每日开发的实际工作流

配置好 Skill 后，你的日常开发流程大概是这样的：

1. 开始新任务：先开个新会话

/clear

长时间的对话会让上下文越来越大，Claude 会逐渐"忘记"早期的指令。每个独立任务用一个干净的会话。

2. 进入 Plan Mode 了解任务

[Shift+Tab × 2 进入 Plan Mode]

我要实现"任务看板的拖拽排序"功能。
请阅读 /docs/project-plan.md 和 /docs/api-design.md 中的相关部分，
告诉我实现方案和涉及的文件。

Claude 分析后给出计划。你可以用 Ctrl+G 编辑计划，或者直接讨论。

3. 确认方案后退出 Plan Mode，开始实现

[Shift+Tab 切回正常模式]

/implement 任务看板拖拽排序

Claude 按照 implement skill 定义的 TDD 流程工作：写测试 → 写代码 → 重构 → 验证。

4. 完成后自检

/review

Claude 按照 review skill 检查刚写的代码，给出改进建议。

5. 修复问题后提交

/commit

6. 如果上下文变大了

/compact

这个命令会压缩对话历史，释放上下文空间。在长会话中定期使用。

上下文管理：中期最重要的技巧

Claude Code 的上下文窗口是有限的（约 200K token，Opus 4.6 可达 1M）。长时间的会话中，上下文会被逐渐填满，Claude 开始"忘记"早期的对话内容。这就是为什么中期开发需要注意以下几点：

每个任务一个会话。 完成一个功能后用 /clear 清空，再开始下一个。不要在一个会话里连续做十个功能。

善用 /compact。 如果一个任务本身比较复杂，需要较长的对话，中途用 /compact 压缩历史。你可以附带指示：“保留关于认证模块的上下文，压缩其他内容。”

让 Claude 参考文件而不是记忆。 与其指望 Claude 记住之前讨论的架构决策，不如让它直接读 /docs/architecture.md。文件是持久的，对话记忆不是。

---

后期：测试、审计和发布（40%）

集成测试

单元测试应该在中期开发中就跟着写了（implement skill 保证了这一点）。后期的重点是集成测试和端到端测试。

根据 /docs/api-design.md 中的接口定义，帮我编写 API 集成测试：
1. 测试完整的用户注册 → 登录 → 创建团队 → 创建任务 → 更新状态的流程
2. 测试权限边界：普通成员尝试删除他人的任务
3. 测试错误情况：无效输入、未认证请求、资源不存在
4. 使用测试数据库，每个测试用例前后做清理

然后帮我编写前端的 E2E 测试（Playwright）：
1. 测试看板页面的核心交互：拖拽排序、创建任务、筛选
2. 测试登录/注销流程
3. 测试响应式布局（桌面/平板/手机）

安全审计——Agent 的最佳使用场景

这是整个工作流中最适合引入 Agent 的环节。原因有三：

1. 安全审计需要扫描大量代码文件，会消耗大量上下文——用 Agent 隔离
2. 审计应该只读不写——用 Agent 限制工具权限
3. 审计需要最强的推理能力——用 Agent 指定 Opus 模型

# .claude/agents/security-auditor.md
---
name: security-auditor
description: 安全审计专家。扫描代码中的安全漏洞和不安全实践。
tools: Read, Grep, Glob
model: opus
---

你是一位资深安全审计工程师。对整个代码库进行全面的安全审查：

## 审查范围

1. **认证与授权**
   - JWT 实现是否安全？token 过期、刷新、吊销逻辑
   - 权限检查是否在每个需要保护的接口上都有
   - 密码存储是否使用了适当的哈希算法（bcrypt/argon2）

2. **输入验证**
   - 所有用户输入是否经过验证和清洗
   - SQL 注入、NoSQL 注入防护
   - XSS 防护：输出编码是否到位

3. **敏感数据处理**
   - 是否有硬编码的密钥、token、密码
   - 日志中是否会泄露敏感信息
   - 环境变量和配置文件是否安全

4. **依赖安全**
   - 检查 package.json 中是否有已知漏洞的依赖
   - 是否有不必要的依赖

5. **API 安全**
   - 是否有速率限制
   - CORS 配置是否合理
   - 是否有适当的错误处理（不泄露内部信息）

## 输出

输出结构化的审计报告到 /docs/security-audit.md，包含：
- 发现的问题列表，按严重程度排序（Critical / High / Medium / Low）
- 每个问题的具体位置、影响分析和修复建议
- 总体安全评分和改进优先级

使用方式：直接告诉 Claude “用 security-auditor agent 做一次全面安全审计”，或者 Claude 在合适的时候会自动委派。

性能优化

帮我检查以下性能问题：
1. 数据库查询：有没有 N+1 问题？哪些查询缺少索引？
2. 前端性能：bundle 大小分析、不必要的重渲染
3. API 响应时间：哪些接口可能在数据量增长后变慢？
4. 给出具体的优化建议和预期改善幅度

文档编写

项目文档不止是给用户看的，也是给六个月后的自己看的。

帮我编写以下文档：
1. README.md：项目介绍、快速开始、开发指南
2. /docs/deployment.md：部署流程、环境变量说明、回滚方案
3. 为所有公共 API 接口补充 JSDoc/TSDoc 注释
4. 在 /docs/architecture.md 末尾补充"已知的技术债和改进方向"

发布上线

Claude Code 原生支持 Git 操作和 PR 创建。

帮我准备发布：
1. 检查所有测试是否通过
2. 更新 CHANGELOG.md（基于 git log）
3. 检查是否有未提交的变更
4. 创建一个 PR 到 main 分支，标题为"v1.0.0: TaskFlow 首次发布"
   包含变更摘要和测试结果

---

完整的工具选择速查表

项目阶段	用什么工具	为什么
项目初始化	CLAUDE.md + 直接对话	定规矩、搭骨架
需求分析	Plan Mode	只需讨论，不需要改代码
可行性验证	Plan Mode + 对话	调研方案，可选写 spike
技术选型	Plan Mode	对比分析，记录决策
UI/UX 原型	Plan Mode	设计线框图和用户流程
数据模型	Plan Mode	设计 ER 图和表结构
API 契约	Plan Mode	定义前后端通信合同
架构设计	Plan Mode	画组件图、数据流
风险识别	Plan Mode	分析和记录
计划拆分	Plan Mode	拆任务、估时间
功能开发	Skill（implement）	TDD 流程标准化
代码自检	Skill（review）	PR 前质量把关
提交代码	Skill（commit）	规范化提交信息
集成/E2E测试	直接对话	按需编写
安全审计	Agent（只读权限）	隔离上下文、限制权限
性能优化	直接对话	按需分析
文档编写	直接对话	按需生成
发布上线	直接对话	Claude 原生支持 PR

---

避坑指南：从真实经验中总结的教训

1. 不要跳过前期

“我需求很清楚，直接写代码吧”——这几乎总是错觉。即使你觉得需求很清楚，让 Claude 在 Plan Mode 中帮你过一遍也只需要半小时，但它能发现你没想到的边界情况、接口遗漏、数据模型缺陷。这半小时能帮你省掉后面好几天的返工。

2. 不要过度配置

最有效的工作流避免过度工程化。不要一开始就创建 10 个 agent + 20 个 skill。Vanilla Claude Code + 一个好的 CLAUDE.md，能覆盖绝大部分场景。从痛点出发，感到哪个地方在重复操作了再做成 Skill，感到上下文不够了再引入 Agent。

3. 每个任务一个会话

不要在同一个会话里连续做多个不相关的任务。上下文会混乱，Claude 会把上一个任务的思路带到下一个任务里。/clear 是你最好的朋友。

4. 文件是最好的记忆

不要指望 Claude 在长对话中记住所有细节。把重要的决策、设计、约定写到 /docs 目录的文件里。需要时让 Claude 去读文件，而不是依赖对话记忆。

5. 定期 /compact

长会话中，每完成一个阶段就用 /compact 压缩一下。你可以指定保留哪些上下文：“保留关于数据模型和 API 设计的讨论，压缩掉调试过程。”

6. 不要让 Claude 一次做太多

“帮我把整个后端写了"这种指令的效果远不如"帮我实现用户注册接口，包含输入验证、密码哈希和 JWT 返回”。任务越具体，Claude 的输出质量越高。

7. Plan Mode 不是万能的

简单的 bug 修复、小的代码调整，直接让 Claude 做就行。Plan Mode 适合的是需要思考和调研的复杂任务。不要养成"什么都先 plan 一下"的习惯——那只是在浪费时间。

---

总结

用 Claude Code 管理完整项目的核心思路可以用三句话概括：

前期用 Plan Mode 想清楚，中期用 Skill 固化流程，后期按需引入 Agent。

不要把 Claude Code 当成一个只会写代码的工具。它在需求分析时可以当产品经理面试你，在架构设计时可以当架构师和你讨论方案，在开发时帮你执行 TDD 流程，在后期帮你做安全审计和性能分析。

关键是要在正确的阶段用正确的工具，并且永远记住 40-20-40 法则——把大部分精力放在写代码之前和之后，而不仅仅是写代码本身。

---