Claude Code 进阶实战：项目上下文、MCP、批量任务与验证流程

Claude Code 上手很快，但真正拉开差距的是流程：你是否让它先理解项目、是否限制权限、是否要求验证、是否能复用常见任务。

导读：你可以把这篇当成 Claude Code 进阶工作流指南来用。本文不写“效率提升多少倍”这类无来源断言，而是给出项目上下文、MCP、批量任务、Git、验证和回滚的实践框架。

官方来源与核验规则

涉及 Claude Code 能力、模型、命令和计费时，优先看官方来源：

核验规则：

新功能以官方文档和当前 CLI 输出为准；
不把个人体验写成固定效率百分比；
每个工作流都要有验证命令；
写文件前看 diff，提交/推送必须人工确认；
涉及 MCP、数据库、网络工具时先在测试环境验证。

进阶能力总览

能力	解决什么问题	验证方式
CLAUDE.md	让 AI 知道项目规则	新会话询问项目约束是否识别
Plan Mode	降低复杂改动误解	先看计划再执行
MCP	接入外部工具和数据	单工具调用测试
Slash Command	复用固定流程	多次运行结果是否一致
Git 流程	保留 diff 和回滚	`git diff`、测试、review
`/compact`	长会话保持重点	压缩后复述当前状态

用 CLAUDE.md 做项目入职文档

CLAUDE.md 是 Claude Code 的项目上下文入口。它应该写清楚三件事：

项目是什么；
代码应该怎么写；
禁止做什么。

示例：

# Project Rules

## Stack
- Next.js + TypeScript
- Prisma + PostgreSQL

## Code Style
- New components go under src/components
- API routes use App Router route.ts
- Do not use any

## Safety
- Do not add dependencies without approval
- Do not edit migrations unless asked
- Run tests before saying done

验证方式：新开一个会话，让 Claude 总结项目规则。如果它说不出关键约束，说明 CLAUDE.md 还不够清楚。

Plan Mode：复杂任务先规划

复杂任务不要直接让 Claude 写。推荐流程：

1	描述目标 → 进入 plan → 审查计划 → 删除不该改的范围 → 执行 → 跑测试 → review diff

适合 Plan Mode 的任务：

改动超过 3 个文件；
涉及数据结构、权限、支付、认证；
需要迁移或重构；
你不确定它会不会理解错。

不适合：改 typo、加一行配置、补一个简单测试。

MCP：给 Claude Code 接工具，但要先设边界

MCP 的价值是让 Claude Code 能访问外部工具，例如文件系统、数据库、搜索、内部 API。但工具越强，风险越高。

接入 checklist：

检查项	合格标准
权限范围	只开放当前项目或测试数据库
工具输出	不把敏感凭证打印给模型
错误处理	工具失败时有清晰错误
写操作	默认需要人工确认
日志	能追踪调用了什么工具

接入后先跑最小测试：

1	请只读取 README，并总结项目结构。不要写文件，不要执行命令。

确认读权限正常后，再逐步开放更高权限。

批量任务：一次处理多文件前先定义验收标准

批量任务最容易失控。不要只说“把这些文件优化一下”，要给列表、动作和完成标准。

你要处理以下 5 个文件。
每个文件只做三件事：
1. 补充错误处理；
2. 保持现有 API 不变；
3. 添加一个最小测试。

每处理完一个文件，输出：文件名、改动摘要、验证命令。

批量任务公式：

1	可控性 = 明确文件列表 + 单一改动类型 + 验证命令 + 分步反馈

如果任务类型不一致，拆成多轮做。

Slash Command：把重复流程固化

适合做成 Slash Command 的任务：

code review；
测试失败排查；
生成 changelog；
SEO 内容检查；
安全审查前置清单。

示例 review.md：

请审查当前 diff。
只关注 correctness bug、安全风险和测试缺口。
输出表格：severity / file / evidence / fix。
如果没有确定问题，明确说没有发现。

好处是每次 review 的标准一致，不会因为临时提示不同导致结果飘。

Git 工作流：让 AI 改，但不要让它擅自发布

推荐流程：

开始前确认 git status；
复杂任务使用分支或 worktree；
每轮改完看 git diff；
跑测试；
需要提交时再明确要求 commit；
push、部署、发布都必须人工确认。

这不是保守，而是工程基本盘。AI 改得越快，越需要 Git 给你兜底。

验证清单

任务类型	验证方式
前端组件	构建 + 浏览器检查
API 改动	单元/集成测试 + curl
数据库改动	测试库迁移 + 回滚方案
内容改动	SEO 检查 + 构建
批量重构	全量测试 + diff review

Claude Code 的完成标准不应该是“它说完成了”，而是：命令跑过、结果看过、diff 可解释。