大多数 Claude Code 用户在隔离中构建。他们写 prompt，Claude 生成代码，复制到编辑器，运行，带回错误，粘贴错误，Claude 修复。每一步都需要人类在中间搬运信息。
MCP servers 消除中间人。
当 Claude Code 通过 MCP 连接到你的全栈时，它不会等你粘贴错误——直接从终端读取。不会等你描述数据库 schema——自己查询。不会建议你复制 Git commit message——直接提交。
连接完整 MCP 栈的 Claude Code 不是代码助手，是直接在你环境中操作的全栈工程伙伴。
MCP 是什么
MCP = Model Context Protocol，Anthropic 开发的开放标准，定义 AI 模型如何连接外部工具和数据源。
对 Claude Code 来说，MCP 是代码生成能力和实际运行系统之间的桥梁。
无 MCP 的三大局限
上下文盲区。 Claude 只能推理你展示给它的代码。代码库有数千文件，数据库有几十张表，基础设施有几十个服务——Claude 对它们一无所知，除非你手动提供。
行动断连。 Claude 能告诉你运行什么命令，但不能运行。能建议数据库迁移，但不能执行。每个建议都需要你手动翻译成行动。
session 失忆。 每个 Claude Code session 从零开始。项目上下文、约定、当前 sprint——全部需要手动重建。
MCP 同时解决这三个问题。
五层 MCP 集成方案
第一层：代码层（Filesystem + Git）
Claude 读取实际代码库、直接写文件、管理版本控制。
Filesystem 配置：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
}
}
}
Git 配置：
"git": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-git"],
"env": { "GIT_REPO_PATH": "/path/to/project" }
}
验证：让 Claude 描述项目结构、读取最近 10 个 commit、基于 commit message 和 diff 判断上周最重要的变更。
第二层：数据层（Database MCP）
没有 database MCP 时，Claude 每次写数据库代码都在做假设。这些假设经常错误——代码需要调试不是因为逻辑 flawed，而是因为不知道实际数据模型。
有了 database MCP，Claude 在写一行数据库代码前先读取真实 schema。知道精确的表名、列名、类型和关系。产出的代码第一次就能工作的概率显著提高。
PostgreSQL 配置：
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://user:password@localhost:5432/dbname"]
}
Supabase 配置：
"supabase": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-supabase"],
"env": {
"SUPABASE_URL": "your-url",
"SUPABASE_SERVICE_KEY": "your-key"
}
}
数据库上下文 Prompt（每次数据库工作前运行）：
读取我的数据库完整 schema，包括：所有表名和列及类型、所有外键关系、所有索引、任何视图或函数。基于发现的内容描述数据模型，识别当前 schema 的潜在问题。
写迁移的完整工作流：
我需要添加新功能：[功能描述]。基于你已读取的当前 schema：1. 识别需要创建或修改的表 2. 写包含 proper up/down 方法的迁移文件 3. 识别可能受影响的现有查询 4. 写适配新 schema 的更新查询 5. 运行迁移并验证应用正确。全部直接做。
第三层：运行时层（Terminal MCP）
这是让 Claude Code 真正自主的连接。
没有终端访问时，每次 Claude 写代码你都要手动运行、复制输出或错误、粘贴回去、等 Claude 响应。涉及多次测试运行和迭代的开发工作流，这个循环耗费巨量时间。
有了 terminal MCP，Claude 自己运行代码。读取输出。如果有错误直接读取并修复，无需你在循环中。运行测试并读取结果。启动开发服务器并 hit 端点验证行为。
Terminal 配置（权限配置至关重要）：
"terminal": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-terminal"],
"env": {
"ALLOWED_COMMANDS": "npm,node,git,python,pip,curl,ls,cat,grep,find",
"WORKING_DIRECTORY": "/path/to/project",
"TIMEOUT_SECONDS": "30"
}
}
ALLOWED_COMMANDS 列表是关键。只包含开发需要的命令。不要包含能修改系统配置或访问敏感区域的命令。
TDD 完整循环：
实现以下功能：[功能描述]。严格按此流程：1. 读取相关文件的现有代码 2. 先基于功能需求写测试 3. 运行测试确认失败（红）4. 写实现 5. 再次运行测试确认通过（绿）6. 如需重构 7. 运行完整测试套件确认没破坏任何东西 8. 用描述性 message 提交。自主执行每一步，读写之间不要等我的输入。
Bug 修复循环：
有个 bug：[描述 bug 或粘贴错误]。修复它：1. 读取相关源文件 2. 运行产生错误的代码并观察输出 3. 从实际错误输出中识别根本原因 4. 修复代码 5. 再次运行代码验证修复 6. 运行完整测试套件确保没破坏其他东西 7. 提交修复。不要问我额外信息。直接读取需要的内容并修复。
这个 prompt 价值几十小时的来回调试 session。
第四层：基础设施层（Cloud + Deployment）
AWS 配置：
"aws": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-aws"],
"env": {
"AWS_ACCESS_KEY_ID": "your-key-id",
"AWS_SECRET_ACCESS_KEY": "your-secret",
"AWS_REGION": "your-region"
}
}
Vercel 配置：
"vercel": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-vercel"],
"env": { "VERCEL_TOKEN": "your-token" }
}
完整部署工作流：
将最新变更部署到生产环境。流程：1. 读取当前 git status 和 pending changes 2. 运行完整测试套件——有任何测试失败则中止 3. 构建生产 bundle 并验证完成 4. 检查当前生产部署状态 5. 先部署到 staging 环境 6. 对 staging 运行 smoke tests 7. 如果 staging 通过，部署到生产 8. 验证生产部署健康 9. 在 [跟踪系统] 中创建部署记录。任何失败步骤都不要继续。报告发生了什么，如果出错就停止。
第五层：协作层（GitHub + 项目管理）
GitHub MCP 配置：
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token" }
}
Linear MCP 配置：
"linear": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-linear"],
"env": { "LINEAR_API_KEY": "your-key" }
}
功能开发完整工作流：
我开始处理 Linear issue [ISSUE ID]。完整工作流：1. 读取 Linear issue 获取完整需求和验收标准 2. 读取 Linear 中任何相关 issue 或链接资源 3. 检查是否已有该 issue 的分支 4. 如需则创建新分支：feature/[issue-id]-[description] 5. 读取相关现有代码理解上下文 6. 按验收标准实现功能 7. 写覆盖所有验收标准的测试 8. 运行完整测试套件 9. 如果全部通过：创建 PR，包含——关联 Linear issue 的标题、构建内容摘要、验收标准清单、给 reviewer 的备注 10. 更新 Linear issue 状态为 In Review。全程不要停下来等输入。
CLAUDE.md：master context document
五层全连接后，CLAUDE.md 成为让 Claude Code 像一个已入职数月的高级工程师的 master context document。
核心结构：
- Project Overview：名称、技术栈、架构、部署位置
- Connected Systems：Filesystem/Git/Database/Terminal/GitHub/Linear/Cloud 的连接详情
- Development Standards：语言约定、文件命名、测试框架、覆盖率要求、commit message 格式
- Architecture Decisions：关键架构决策及原因（Claude 不应未经讨论就推翻）
- Current Sprint Context（每周更新）：sprint 目标、当前 focus、活跃 Linear issues
- Code Quality Rules：不直接 commit 到 main、所有 PR 需通过测试才能请求 review、数据库迁移必须有 up/down 方法等
- Deployment Rules：不通过 staging 测试不能部署生产、生产部署后必须创建部署记录、回滚流程
- Emergency Rules：遇到特定危险情况时该做什么、永远不要做什么
六周渐进式接入计划
Week 1：Filesystem + Git 安装两个 server。用 Claude Code 做代码审查、重构、文档。习惯 Claude 读取实际代码库后再加更多 server。
目标工作流：让 Claude 审查项目中任何文件并建议改进。让它实现一个改进，手动测试，提交。
Week 2：Database 添加 database MCP。每次数据库相关 session 开始时让 Claude 读取 schema。让它写一个你本来会手动写的迁移。
目标工作流：完整迁移周期。Claude 读取 schema、写迁移、应用、写使用新 schema 的应用代码、运行现有测试。
Week 3：Terminal 最大的能力跃迁。从受限的 allowed commands 列表开始。只有在对 Claude 的执行判断建立信任后才扩展。
目标工作流：一个小功能的完整 TDD 周期。Claude 写测试、运行、实现、再运行、提交。
Week 4：GitHub + Linear 添加协作层。开始用于 PR 创建和 issue 管理。
目标工作流：选一个 Linear issue，让 Claude 读取并实现——从 ticket 到 PR，无需你描述需求。
Week 5：Infrastructure 先以只读访问添加 cloud MCP。对 Claude 读取什么、如何行为感到舒适后，再扩展到部署的写访问。
目标工作流：非关键功能的完整部署管道。staging 到生产，所有 gate。
Week 6：Integration + Optimization 运行结合所有五层的复杂多系统工作流。识别剩余手动步骤并建立连接消除它们。
核心变化
当五层全连接、CLAUDE.md 配置正确时，开发体验在根本层面改变：
-
功能从需求到部署更快。 不是因为 Claude 生成代码比你打字快，而是因为拖慢开发的反馈循环——手动运行测试、手动检查数据库、手动管理 PR——都在同一个 Claude session 内发生，不打破 flow。
-
Bug 修复周期大幅压缩。 Claude 从运行系统读取实际错误，而非复制粘贴的错误消息。在上下文中读取相关代码。修复实际问题，而非描述的问题。
-
文档自动保持最新。 Claude 创建的每个 PR 都包含准确文档，因为它读取了要记录的代码，而非总结你告诉它的内容。
-
跨 session 上下文质量提升。 Claude 在每个 session 开始时读取 CLAUDE.md。架构决策、约定、当前 sprint 上下文在每个建议前就位，无需你问第一个问题。
构建这套设置的工程师不是在做更多工作。他们是在每一层用更少的摩擦做更好的工作。
终端不再是 Claude 和你的栈之间的边界。
栈就是 Claude 的环境。