我的推荐:先装这套最小但够强的栈
如果目标是“边想边写、快速成型、别把项目写烂”,优先级应该是:项目上下文 > 可验证执行 > 外部系统连接 > 花哨插件。
CLAUDE.md / 项目 Skill
把项目架构、命令、约束、禁区、代码风格写进仓库根目录,让每次 vibe coding 都从同一套规则起步。
Playwright / Browser MCP
让 Claude 真实打开页面、点按钮、看 console、截图验证。做前端/全栈时这是质量分水岭。
GitHub MCP 或 gh CLI
Issue、PR、review、CI 状态、release 统一进入上下文。适合让 Claude 按 issue 开发并自检 diff。
Context7 / Docs MCP
查最新框架/API 文档,减少 Claude 用旧版本 API 幻觉。特别适合 Next.js、Cloudflare、LangChain、shadcn。
数据库 MCP
Postgres / SQLite / Supabase 等,让 Claude 能看 schema、写 migration、验证查询,但生产库必须只读或走 staging。
测试 + Lint + Typecheck
别让 vibe coding 变成“感觉能跑”。每轮结束必须跑测试、类型检查和最小浏览器验收。
必备 Skills:不是“提示词收藏”,而是项目操作规程
Claude Code 的 skill/记忆层建议分为 5 类。越靠前越应该放进仓库,越靠后越适合放在个人全局。
| Skill 类型 | 放哪里 | 应该写什么 | 为什么重要 |
|---|---|---|---|
| 项目宪法 | CLAUDE.md | 架构、目录、包管理器、启动/测试命令、环境变量、禁改文件、提交规范 | 防止每次都重新解释项目,也防止 Claude 乱猜命令 |
| TDD / 验收 Skill | 项目或全局 | 先写/更新测试,再实现;必须跑 lint、typecheck、test、关键 e2e | 把 vibe coding 拉回工程现实 |
| Debug Skill | 全局 | 复现 → 定位 → 最小修复 → 回归测试,禁止无证据重构 | Claude 很容易“顺手大改”,debug skill 用来收敛范围 |
| UI/Design Skill | 项目或全局 | 设计系统、组件使用规则、禁用 AI 味 UI、交互/响应式/无障碍要求 | 做前端时避免生成一堆渐变卡片和假数据 |
| Deployment Skill | 项目 | Cloudflare Pages/Workers、Vercel、Docker、数据库 migration、回滚步骤 | 让“能跑”变成“能上线、能回滚” |
MCP Server 推荐矩阵
原则:不要重复 Claude Code 已经擅长的本地读写;要补它看不到的外部世界。
| 优先级 | MCP 类别 | 推荐用途 | 链接 / 入口 | 注意事项 |
|---|---|---|---|---|
| P0 | Playwright / Browser | 打开本地/线上页面、截图、点击、读 console、跑冒烟测试 | 前端项目必装;比“凭代码猜 UI”可靠很多 | |
| P0 | GitHub | Issue → branch → PR → review → CI 状态闭环 | token 权限最小化;写权限最好只给 repo 级别 | |
| P1 | Docs / Context7 | 查最新版库文档和示例,减少旧 API 幻觉 | 对高速变化生态尤其有价值 | |
| P1 | Database | 查看 schema、解释慢查询、生成 migration、验证 SQL | 默认只读;写操作只连 dev/staging | |
| P1 | Cloudflare | Pages/Workers/D1/R2/KV 部署与配置查询 | 如果有 MCP 优先 MCP;没有再用 wrangler CLI | |
| P2 | Figma / Design | 读取设计稿、tokens、组件规范,生成更贴近真实设计的 UI | 产品 UI 项目很值;纯后端可不装 | |
| P2 | Notion / Linear / Jira | 读取需求、验收标准、任务状态 | 适合团队;个人项目可用 markdown issues 代替 | |
| 谨慎 | Filesystem MCP | 跨目录安全授权、本地知识库读取 | Claude Code 本身能读写项目文件;不要给它整个 Home 目录 |
别的辅助工具:真正提高产出的不是“更多聊天”
建议把工具分成:代码质量、运行环境、可视化验证、任务管理、知识管理。
Biome/ESLint + TypeScript strict + Vitest/Pytest
- 每次修改后自动格式化、lint、typecheck
- 让 Claude 看到红灯,而不是靠自然语言自信
- 为 bugfix 建最小回归测试
Playwright Test + Trace Viewer
- 关键路径 e2e:登录、表单、支付/提交、核心页面
- 失败时给截图、录像、trace
- 适合交给 Claude 反复修到绿
Docker Compose / devcontainer
- 数据库、Redis、队列等依赖容器化
- 代码可本地写,服务在容器跑
- 避免“本机能跑,部署爆炸”
Git Worktree + 小 Issue
- 一个任务一个分支/工作区
- 并行让多个 agent 做 spike/review
- 主分支只接收已验证 diff
Storybook / Ladle / shadcn registry
- 先做组件状态,再接业务
- 让 Claude 看到组件边界
- 减少整页乱写 CSS
权限与 secrets 管理
- 不给 Claude 生产密钥和真实用户数据
- MCP token 最小权限、分环境
- 高风险命令需要人工确认
推荐 vibe coding 工作流
把“灵感驱动”变成“短循环、可回滚、可验证”。
写一页 brief
目标、用户路径、非目标、验收标准、截图/参考、技术约束。不要直接说“帮我做个 XX”。
让 Claude 先读项目再计划
要求它先列出相关文件、风险点、测试命令,再给 5-8 个小任务。计划不对先改计划。
小步实现,每步可运行
每次只改一个闭环:组件、API、schema、测试、页面状态。禁止一次性全仓大改。
强制工具验证
跑 lint/typecheck/test/e2e;前端必须开浏览器看 console 和截图;后端必须打真实请求。
让第二视角 review
可用 Claude 自审、另一个模型、或人工 review:看 diff、边界条件、权限、迁移、性能。
合并前收敛记忆
把踩坑、命令、架构约束写回 CLAUDE.md 或项目 docs,别让下一轮重复犯错。
可复制配置片段
下面不是唯一正确配置,而是一个比较稳的起点。根据你的项目把命令换成真实命令。
# Project Rules for Claude Code ## Stack - Package manager: pnpm - App: Next.js / TypeScript / Tailwind - Tests: vitest + playwright - Deploy: Cloudflare Pages ## Commands - Install: pnpm install - Dev: pnpm dev - Lint: pnpm lint - Typecheck: pnpm typecheck - Unit tests: pnpm test - E2E: pnpm e2e - Build: pnpm build ## Working rules 1. Before editing, inspect relevant files and explain the minimal change plan. 2. Prefer small diffs. Do not rewrite unrelated modules. 3. Add or update tests for behavior changes. 4. After changes, run lint/typecheck/tests/build as appropriate. 5. For UI changes, use Playwright/browser to verify the page and console. 6. Never read or print secrets. Never modify production config without explicit approval. ## Design rules - Use existing components/tokens first. - No fake metrics, filler testimonials, or generic gradient SaaS cards. - Mobile hit targets >= 44px. - Respect loading/empty/error/success states.
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx_min_scope_repo_token"
}
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"]
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://readonly_user:pass@localhost:5432/app"]
}
}
}# package.json scripts 建议
{
"scripts": {
"dev": "next dev",
"lint": "biome check .",
"format": "biome check --write .",
"typecheck": "tsc --noEmit",
"test": "vitest run",
"e2e": "playwright test",
"build": "next build",
"verify": "pnpm lint && pnpm typecheck && pnpm test && pnpm build"
}
}
# 推荐给 Claude 的结束语
"完成后请运行 pnpm verify;如果改了 UI,再用 Playwright 打开页面,确认无 console error,并总结截图/路径/测试结果。"最终结论
Claude Opus 4.8 + Claude Code CLI 已经足够强,真正拉开差距的是项目规则、MCP 外部上下文、自动化验证、浏览器验收、权限边界。少装十个“看起来厉害”的 MCP,多写一个高质量 CLAUDE.md,收益通常更大。