Claude Opus 4.8 + Claude Code CLI · Vibe Coding 栈

不要只加模型,给 Claude Code 装一套“施工现场”。

最佳配置不是塞满 MCP,而是让 Claude Code 拥有:项目记忆、可验证工具链、外部事实源、设计预览、测试护栏和任务拆分机制。

我的推荐:先装这套最小但够强的栈

如果目标是“边想边写、快速成型、别把项目写烂”,优先级应该是:项目上下文 > 可验证执行 > 外部系统连接 > 花哨插件。

必备

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项目或全局先写/更新测试,再实现;必须跑 linttypechecktest、关键 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 类别推荐用途链接 / 入口注意事项
P0Playwright / Browser打开本地/线上页面、截图、点击、读 console、跑冒烟测试前端项目必装;比“凭代码猜 UI”可靠很多
P0GitHubIssue → branch → PR → review → CI 状态闭环token 权限最小化;写权限最好只给 repo 级别
P1Docs / Context7查最新版库文档和示例,减少旧 API 幻觉对高速变化生态尤其有价值
P1Database查看 schema、解释慢查询、生成 migration、验证 SQL默认只读;写操作只连 dev/staging
P1CloudflarePages/Workers/D1/R2/KV 部署与配置查询如果有 MCP 优先 MCP;没有再用 wrangler CLI
P2Figma / Design读取设计稿、tokens、组件规范,生成更贴近真实设计的 UI产品 UI 项目很值;纯后端可不装
P2Notion / 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
UI 组件

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,收益通常更大。