我一开始把 Claude Code 当成“会写代码的聊天框”用，每天复制报错、复制文件、复制接口文档，累得像个人肉 MCP。后来我给它接了 8 个 MCP，再配了几个 Skills，才发现之前不是 Claude Code 不够强，是我一直没给它手和眼睛。
先说结论：别裸用 Claude Code
我刚开始用 Claude Code 的时候，状态非常原始。
每天打开项目，然后对它说：
帮我看看这个 bug。
帮我重构一下这个函数。
帮我写个单测。
帮我解释一下这个报错。
听起来没问题，对吧？
但实际体验是这样的：
它问我：“相关文件在哪？”
我复制。
它问我：“接口文档是什么？”
我复制。
它问我：“这个报错的完整堆栈呢？”
我复制。
它问我：“数据库表结构长什么样？”
我继续复制。
两周后我突然意识到一件事：
我不是在用 AI 编程，我是在给 AI 当搬运工。
Claude Code 本身已经能读项目、改文件、跑命令，但我把它用成了一个高级 ChatGPT。
它明明可以进厨房炒菜，我却天天把菜切好、锅烧好、调料倒好，然后问它：“师傅，你看这菜怎么炒？”
最蠢的是，我还一边复制粘贴，一边抱怨：
怎么 Claude Code 也没传说中那么神？
后来我装了 8 个 MCP，又补了几个 Skills，体验才开始变味。
不是“稍微好用一点”。
是从：
我问一句，它猜半天。
变成：
我说一个目标，它自己去查、去读、去跑、去验证。
这篇就聊聊我这两周从“裸奔 Claude Code”到“全副武装 Claude Code”的过程。
裸用 Claude Code 的 3 个典型症状
1. 你以为自己在提需求，其实是在喂上下文
裸用的时候，我最常见的 prompt 是：
这个页面点击保存后报错，你帮我看看。
然后 Claude Code 基本会问：
保存逻辑在哪个文件？
接口是什么？
报错信息是什么？
相关组件是哪几个？
于是我开始补：
组件在 src/pages/order/Edit.vue
接口在 api/order.ts
报错是 xxx
这是后端返回
这是数据库字段
这是产品要求
最后我发现，我花 10 分钟描述问题，它花 2 分钟改代码。
这不是 AI 效率低，是我接入方式低。
2. 它会写代码，但不知道“你们项目的规矩”
比如我们项目里有几个很烦的约定：
- 请求必须走统一的 request 封装
- 表单校验不能写在组件里，要抽到 schema
- 错误提示不能直接 message.error，要走统一 toast
- 所有金额字段都要用 decimal string，不能用 number
- 单测文件命名必须跟 CI 规则一致
裸用时，Claude Code 第一次基本都会写错。
不是它不会，而是它不知道。
我之前的做法是每次提醒它：
注意，我们项目金额字段不能用 number。
注意，这里不要直接用 axios。
注意，错误提示不要这么写。
这就像你请了一个很聪明的新人，但每天都不让他看团队规范，只能靠你口头提醒。
累的是谁？
当然是你。
3. 它能改，但你不敢信
裸用的时候，我最不爽的是验证成本。
Claude Code 改完代码，我还要自己：
pnpm lint
pnpm test
pnpm typecheck
pnpm dev
然后打开页面点一遍。
如果错了，我再把报错复制回去。
这整个流程非常割裂。
Claude Code 负责“写”，我负责“查资料 + 提供上下文 + 验证 + 反馈”。
那它就不是副驾驶。
它是外包。
转折点：我发现 Claude Code 缺的不是智商，是工具
后来我看到 MCP 的思路，突然理解了。
Claude Code 裸用时像一个闭卷考试的天才学生。
你问它问题，它能推理，但它不知道你的数据库、issue、日志、浏览器状态、接口文档、线上报错。
接上 MCP 后，它才像一个真的坐在你电脑前的同事。
它可以：
- 查 GitHub issue
- 看数据库结构
- 读最新文档
- 打开浏览器验证页面
- 看 Sentry 报错
- 读本地文件
- 分析 git diff
- 按固定步骤拆复杂任务
这时你再问：
帮我修一下订单编辑页保存失败的问题，要求不要破坏现有测试。
它不再第一时间问你“文件在哪”。
它会先去搜相关文件，读接口，查日志，看最近 commit，跑测试，然后再给方案。
这才是 Claude Code 应该有的样子。
我最后留下来的 8 个 MCP
我前后试了十几个 MCP，最后留下 8 个。
不是越多越好。
MCP 装太多也会乱，工具越多，模型越容易选择困难。
我的原则是：
只装能减少“复制粘贴”的 MCP。
下面是我的最终清单。
| MCP | 我用它解决什么问题 | 裸用时的痛苦 |
|---|---|---|
| Filesystem | 读写项目文件、限定访问目录 | 每次都要贴文件内容 |
| Git | 看 diff、log、branch、改动范围 | 不知道这次改了什么 |
| GitHub | 读 issue、PR、review comment | 需求和代码割裂 |
| Database | 查表结构、读只读数据 | 每次手动复制 schema |
| Sentry | 查线上错误和堆栈 | 只会把报错截图丢给 AI |
| Context7 | 拉最新库文档和示例 | AI 老写过期 API |
| Playwright | 打开页面、点按钮、验证交互 | 改完还要我手测 |
| Sequential Thinking | 拆复杂任务、先计划再动手 | 一上来就开改，容易跑偏 |
下面展开讲。
1. Filesystem：先让它真的看见项目
这个是最基础的。
没有 Filesystem，Claude Code 虽然也能在当前项目里操作，但我更习惯把可访问范围明确写死。
比如只允许它看当前项目，不让它乱扫其他目录。
我的配置习惯是：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/你的项目路径"
]
}
}
}
装完后，我的 prompt 也变了。
以前：
这是 order.ts，这是 Edit.vue，这是报错，你看看。
现在：
帮我定位订单编辑页保存失败的问题，先读相关文件，不要直接改。
差别非常明显。
以前是我给它喂文件。
现在是它自己找文件。
这一步看起来简单，但体感提升最大。
2. Git：别让 AI 盲改
我很怕 AI 改代码的一个原因是：它有时候改得太“热情”。
你让它修一个 bug，它顺手重构三个函数。
你让它补一个测试，它顺手改了测试框架配置。
你让它改一个按钮，它顺手把样式抽了个组件。
Git MCP 的价值是让它随时知道：
- 当前分支是什么
- 最近改了哪些文件
- 哪些改动是它造成的
- 哪些文件本来就有变化
- 这次 diff 是否超出任务范围
我现在每次让 Claude Code 改完，都会补一句：
改完后先看 git diff，总结你改了哪些文件，哪些改动是必要的，哪些可能有风险。
这个习惯救过我很多次。
最典型的一次是，它为了修一个展示 bug，顺手改了一个公共格式化函数。
diff 一看我人麻了。
如果没有 Git MCP，我大概率会到测试炸了才发现。
3. GitHub：让 issue 直接变成任务上下文
这个是我后悔装晚的。
以前产品或测试在 GitHub issue 里写了需求，我会复制标题、描述、评论、截图说明，然后粘给 Claude Code。
现在我直接说：
读取 GitHub issue #128，先总结需求和验收标准，再给实现方案。
它会先读 issue，然后把任务拆成：
1. 影响页面
2. 相关接口
3. 需要改的组件
4. 需要补的测试
5. 潜在风险
这才像正常开发流程。
而且 PR review 也能接上。
比如我会这样用：
读取当前 PR 的 review comments，把需要处理的问题按文件分组，不要立刻修改，先给我确认。
这个动作以前我至少要来回切 5 次页面。
现在一次搞定。
4. Database：只读账号是底线
这个 MCP 我一开始很抗拒。
让 AI 连数据库，听起来就有点吓人。
后来我给它配了一个只读账号，只能连本地开发库和测试库，不能改数据，不能碰生产写权限。
然后它直接解决了我一个长期痛点：
AI 写后端逻辑时终于不再瞎猜字段。
以前我问：
帮我加一个订单筛选条件。
它经常会猜：
order_status
created_time
user_id
但我们真实表字段叫：
status
created_at
buyer_id
字段名一错，后面全错。
接了 Database MCP 后，我会这样问：
先查看 orders 表结构，再实现按订单状态和创建时间筛选。数据库只读，不允许执行写操作。
它会先查 schema，再改代码。
这一步对后端和全栈项目特别香。
但一定要记住：
只读，最小权限，最好本地库。
别为了爽，把生产库写权限交出去。
5. Sentry：别再把线上报错截图发给 AI
以前线上报错，我的流程是：
打开 Sentry。
复制 error message。
复制 stack trace。
复制 release。
复制用户环境。
粘给 Claude Code。
复制到第三段我就已经烦了。
接 Sentry 后，我现在直接问：
查看最近 24 小时订单模块最高频的错误，找出最可能的代码原因，先不要改。
它会把错误按频率、堆栈、影响范围整理出来。
然后我再让它：
根据这个错误定位代码位置，给出最小修复方案。
这里一定要强调“最小修复”。
因为线上 bug 最怕 AI 过度发挥。
我的固定提示是：
只修复导致这个 Sentry 错误的最小代码路径，不做重构，不优化无关逻辑。
加上这句话后，翻车率明显下降。
6. Context7：专治“AI 写过期 API”
这个我装完当天就后悔了。
后悔没早点装。
AI 编程最烦的不是它不会写，而是它会写“看起来很对但已经过时”的代码。
比如：
- 某个库新版 API 改了
- 某个配置项废弃了
- 某个框架升级后推荐写法变了
- 某个方法在旧版本能用，新版本不行
以前我会手动打开文档，再贴链接给它。
现在我直接说：
用 Context7 查一下当前版本的 Next.js 路由写法，再改代码，不要凭记忆写。
或者：
先查最新的 TanStack Query 文档，再帮我封装这个 hook。
这个 MCP 的价值不是“让 AI 更聪明”。
而是让 AI 少一本正经地胡说。
对前端尤其有用。
因为前端生态更新太快了，AI 记忆里的写法经常是上个版本的。
7. Playwright：让它自己点一遍页面
这是最有“爽感”的一个。
以前 Claude Code 改完页面，我还要自己启动项目，打开浏览器，点按钮，看弹窗，测表单。
现在我会直接说：
修改完成后，用 Playwright 打开订单编辑页，完成一次保存流程验证。记录你点击了什么、看到了什么、是否通过。
它能自己：
- 打开页面
- 找输入框
- 点击按钮
- 观察页面状态
- 生成测试
- 发现明显交互问题
有一次它修完一个弹窗 bug，自己用 Playwright 点了一遍，然后告诉我：
保存按钮点击后接口成功，但弹窗没有关闭，原因是 onSuccess 里没有 reset visible 状态。
这就是我想要的 AI 编程。
不是“帮我写代码”。
而是“帮我把这件事闭环”。
不过 Playwright MCP 也别乱用。
我一般只让它跑本地环境，不让它操作真实线上后台。
8. Sequential Thinking：让它先想清楚再动手
这个 MCP 听起来有点玄学，但我实际用下来很实用。
尤其适合这种任务：
把订单详情页重构成可复用组件，同时保持现有功能不变。
裸用时，Claude Code 很容易直接开改。
一旦任务大，它就会边改边想，改到一半上下文越来越乱。
现在我会先说：
这是一个复杂任务。先用 Sequential Thinking 拆解，不要写代码。输出阶段计划、风险点、回滚方案。
它会先拆成几步：
1. 梳理现有页面功能
2. 找出可抽离组件
3. 定义 props 和事件
4. 保持原页面行为不变
5. 补测试
6. 分阶段提交
看完计划后，我再让它执行第一步。
我的经验是：
小任务直接干，大任务先拆。
这能显著减少 AI “越改越远”的概率。
Skills：MCP 是手脚，Skills 是规矩
只装 MCP 还不够。
MCP 解决的是“它能不能拿到信息、调用工具”。
Skills 解决的是“它拿到信息后，按什么方式做事”。
我现在项目里会放几个固定 Skills。
比如：
code-review-skill
test-first-skill
bugfix-skill
refactor-skill
commit-message-skill
举个例子，我的 bugfix skill 大概是这样：
# Bugfix Skill
当任务是修复 bug 时，必须按以下步骤执行：
1. 先复现或定位问题，不要直接改代码
2. 找到最小影响范围
3. 优先修复根因，而不是屏蔽错误
4. 修改后运行相关测试
5. 最后输出：
- 根因
- 修改文件
- 验证方式
- 风险点
禁止：
- 顺手重构无关代码
- 修改公共 API 而不说明影响
- 未验证就宣称修复完成
这个东西看起来很普通，但效果非常明显。
因为你不用每次都提醒它：
不要乱改。
先定位。
补测试。
说清楚风险。
这些都变成默认规则。
我现在的理解是：
CLAUDE.md 写项目常识，Skills 写工作流，MCP 接外部能力。
三者配起来，Claude Code 才不像临时工。
我的最小配置模板
下面是我自己的简化版配置。
注意：不同 MCP 的安装方式会变，实际使用时以对应项目文档为准。这里重点看思路。
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/your/project"
]
},
"git": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-git",
"--repository",
"/path/to/your/project"
]
},
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer ${GITHUB_TOKEN}"
}
},
"database": {
"command": "npx",
"args": [
"-y",
"@bytebase/dbhub",
"--dsn",
"postgresql://readonly:password@localhost:5432/app"
]
},
"sentry": {
"type": "http",
"url": "https://mcp.sentry.dev/mcp"
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp",
"headers": {
"CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}"
}
},
"playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
]
},
"sequential-thinking": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sequential-thinking"
]
}
}
}
我的建议是别一口气全装。
按这个顺序来：
Filesystem → Git → Context7 → Playwright → GitHub → Database → Sentry → Sequential Thinking
先把本地开发闭环跑顺，再接外部系统。
否则你会遇到另一个问题：
工具太多，Claude Code 不知道该先用哪个。
我现在的常用 prompt
修 bug
帮我修复这个问题。
要求：
1. 先定位根因，不要直接改
2. 优先读取相关代码、git diff 和错误信息
3. 如果涉及第三方库，先查最新文档
4. 给出最小修复方案
5. 修改后运行相关测试
6. 最后总结根因、改动文件、验证方式和风险点
做需求
读取 issue 内容，整理需求和验收标准。
然后：
1. 找到相关代码
2. 给出实现方案
3. 标出可能影响的模块
4. 不要直接修改，等我确认后再动手
改前端页面
完成这个页面改动。
要求：
1. 先读取页面组件和相关接口
2. 如涉及库 API，先查最新文档
3. 修改后用 Playwright 在本地页面验证一次
4. 记录验证步骤和结果
代码审查
查看当前 git diff，做一次 code review。
重点看：
1. 是否有无关改动
2. 是否破坏现有类型
3. 是否有潜在边界条件
4. 是否需要补测试
5. 是否符合项目约定
只输出 review，不要修改代码。
裸用 vs 接 MCP 后，差距到底在哪？
我自己最明显的感受有 4 个。
1. 复制粘贴少了
以前我每天都在复制：
报错
文件
接口
文档
日志
表结构
issue
现在大部分让它自己去拿。
这不是省几十秒的问题，而是工作流顺了。
2. 它更少瞎猜
尤其是字段名、库 API、项目规范。
AI 最可怕的不是不会，而是自信地写错。
MCP + Skills 能显著降低这种情况。
3. 任务更容易闭环
以前 Claude Code 改完代码就结束了。
现在我会让它：
改代码 → 跑测试 → 看 diff → 浏览器验证 → 总结风险
这才是完整开发流程。
4. 我更敢让它动大一点的代码
裸用时，我只敢让它改小 bug。
现在有 Git、测试、Playwright、Skills 兜底后，我开始敢让它做一些中等规模重构。
当然，大重构我还是会分阶段。
AI 可以开车，但方向盘不能完全松。
但我不建议你无脑全开
最后说点冷水。
MCP 很强，但也有风险。
我现在有几条硬规则：
第一，数据库只读
能不给写权限就不给。
尤其别让 AI 直接操作生产库。
第二，敏感系统分环境
本地、测试、生产要分开。
AI 能访问什么，要明确。
第三，改代码前先计划
复杂任务一定先让它出方案。
不要上来一句“帮我重构一下”。
第四，外部 MCP 要确认可信
MCP 本质上是给 AI 接工具。
工具越强，风险越大。
不要看到别人推荐就直接装，尤其是需要 token、文件权限、浏览器权限的。
第五，永远看 diff
这条最重要。
Claude Code 改完，不管它说得多自信，我都一定看 diff。
AI 写代码的第一原则：
信它的效率，不信它的结论。
最后
我现在回头看，裸用 Claude Code 的那两周真的挺蠢的。
不是工具不行，是我用法太像 2023 年的聊天机器人时代。
以前我问 AI：
这段代码怎么改？
现在我会说：
这是目标，你去读 issue、查代码、看文档、跑测试、验证页面，最后告诉我改了什么。
这两个用法，差的不是 prompt 技巧。
差的是工作流。
Claude Code 真正好用的地方，不是它能不能一次写出完美代码。
而是你把 MCP、Skills、项目规范、测试验证都接起来后，它能从“代码生成器”变成“开发流程执行器”。
所以我的建议很简单：
别急着研究 100 个神奇 prompt。
先把这 8 个 MCP 装起来。
你会发现，之前让你痛苦的很多问题，不是 AI 不聪明。
是你一直让它闭着眼睛干活。
