Claude Code 的创造者认为什么最重要？
不是如何写提示词，也不是模型的选择。
"给 Claude 验证自己输出的手段。"
这是唯一重要的事情。他声称这是使用 Claude Code 最重要的技巧。
本文是那个讨论的延续。我们理解了原则。那么，具体如何提供这些手段呢？答案是 MCP 服务器。
老实说，知道与否，使用 Claude Code 的体验真的天差地别。粘贴文档、复制议题、手动打开屏幕检查——所有这些都变得不再必要。
你在使用 Claude Code 时是否也遇到这些情况？
- 生成的代码使用旧语法，你得自己每次修复。
- 你最终得自己打开浏览器，看看创建的屏幕是否真的能工作。
- 你复制议题内容，粘贴给 Claude，让它实现，然后再回去写进度。
- 每次生产环境出错，你都得从 Sentry 复制堆栈跟踪。
- 你知道 MCP 这个词，但什么都没设置，因为不知道要加什么。
是的。我以前也全部在做这些事。
我提前说明：即使不会写代码的人也能读懂这篇文章。我会在出现技术术语时逐一解释。实际上，MCP 是一个非工程师可能获益更大的系统。
当你读完时，你很可能会想在工作中找到一个你"每次都在复制粘贴"的地方。
请保存好这篇文章。
"Boris" 到底是谁？
Boris Cherny。他就是创造了 Claude Code 的人。
他明确说过"我创造了 Claude Code"，所以这毫无疑问。他是最深刻理解 Claude Code 设计理念的人。
他的使用方式非同寻常。
首先，他已经很久没有手写代码了。相反，他同时在终端中运行大约五个 Claude 会话，在网页上再运行五到十个，给每个标签页编号，并通过通知来管理哪个 Claude 正在等待人工输入。
（想象一下，你有 15 个下属，都在处理不同的任务，只有遇到困难的人会来找你。）
此外，他的 CLAUDE.md——项目规则手册——只有大约 100 行。他不是那种会写大量规则的人。
他最常被引用的名言是：
"不要写提示词。写循环。"
与其寻找如何更好地提问，不如创造一个环境，让 Claude 能自主循环完成任务。这是他理念的核心。
Boris 反复强调的 3 个原则
查看他的帖子，发现他始终在说同样的事情。
原则 1：给 Claude 验证自己输出的手段。
他称这是"最重要的技巧"。他的解释非常容易理解：
如果你让人建一个网站，但禁止他们使用浏览器，会发生什么？做不出什么好东西。
但如果你给他们一个浏览器，他们会构建、查看、修复、再查看，重复直到满意为止。
Claude 也一样。如果你给它验证的手段，它会自己迭代直到满意为止。
原则 2：将每天执行超过一次的任务系统化。
每次都在聊天中解释同样的流程很浪费时间，所以把它变成技能或命令。由于准备好等着的成本几乎为零，创建它没有任何坏处。
原则 3：将外部工具引入 Claude Code 的工作区。
Slack、议题追踪器、数据库、内部 API。通过让 Claude Code 直接访问这些工具，工具之间的切换就消失了。
这就是 MCP 发挥作用的地方。
最后
谈到 MCP，你总会遇到这个障碍。
连接 MCP 的那一刻，Claude Code 的手就伸到了生产环境。部署、DNS、支付、客户数据。读取还好，但如果你突然允许写入或删除，事故就会发生。
那么，在哪里委托，在哪里由人工验证？
我免费提供一个边界图表。我希望你在安装 MCP 之前先看它一次。
👇
用一句话解释 MCP 是什么？
我们先把这个搞清楚。
MCP 是"连接 AI 工具和外部服务的通用接口"。可以把它想象成 USB 标准。
在没有这个标准的世界里，你需要为 Claude、ChatGPT 和其他 AI 分别构建不同的集成。有了 MCP 标准，服务提供商只需构建一次，所有兼容的 AI 工具都可以使用。
而且，明确一点，MCP 不仅仅是为 Claude Code 添加功能。
它把工作目标本身带到了 Claude Code 内部。
Figma 设计稿、Sentry 错误、Linear 工单、Cloudflare 生产日志——Claude 直接看到它们，直接操作它们。这就是为什么复制粘贴消失了。
现在，这个标准已经发生了显著变化。
MCP 前提条件的转变
这在日本国内还没有被很好地整理过，所以请注意。
在最新的规范更新中，MCP 经历了自发布以来最大的一次改革。以下是四个主要变化：
无状态。 之前的远程 MCP 旨在让服务器维护连接状态。现在没有了；它变成了像标准 HTTP 那样的请求-响应类型。好处是它可以直接在 serverless 或边缘环境中运行。MCP 现在可以构建成一个随访问量扩展的系统，而不是一个常驻服务器。
支持长时间运行的任务。 工具立即返回结果的假设被移除了。它可以先返回一个追踪编号，以便后续进行进度检查、更新和取消。大规模代码迁移、视频生成、长时间数据分析、全环境部署——这些"耗时数小时的任务"现在通过 MCP 得到了官方支持。
能够在对话中返回 UI。 以前，MCP 以文本和 JSON 为中心，但现在服务器可以返回操作界面。部署目标选择屏幕、图表、批准/拒绝按钮、表单。简而言之，MCP 正在从 AI 在后台调用 API 的系统，转变为在 AI 之上运行的迷你应用的标准。
组织级认证。 与企业身份提供商集成，一旦管理员批准，员工在首次登录时自动连接。向个人分发 API 密钥的操作消失了。
请注意，Anthropic 方面正在逐步推出这些功能。规范定稿与你本地的 Claude Code 能立即使用所有功能是两回事。
（我偶尔会看到夸大其词的文章，但官方的说法是"逐步推出"。）
Claude 的连接器列表中列出了超过 950 个 MCP 服务器。数量巨大，但你真的需要安装的并没有那么多。
改变 Claude Code 的 8 个官方 MCP 服务器
这是主要部分。
选择标准有三个：必须是提供商管理的官方服务器，对初学者来说容易感受到效果，并且直接实现 Boris 的三个原则之一。
1. Context7 MCP：消除过期代码的根源
当 Claude Code 输出错误代码时，原因通常不是模型不够智能。
只是它引用的信息过时了。
使用过时的 API。输出旧的 Next.js 语法。混合不同版本的设置。生成不存在的选项。用猜测填补文档中没有的实现。全都是这些。
Context7 是一个 MCP，它为 Claude Code 提供按版本区分的库和框架的最新文档。你不是让它凭记忆回答，而是创建一个状态，让它先查找特定版本的材料，然后再实现。
实用提示：
使用 Context7，检查此项目中使用的当前版本 Next.js 的官方文档。
检查后，在开始实现前整理以下内容：
- 当前版本的推荐实现
- 已弃用的实现
- 与当前项目代码的差异
- 需要修改的文件
不要基于猜测实现；只使用文档中描述的方法。
注意：不要在单个查询中混合多个概念。询问"认证、路由和缓存"会返回宽泛而浅显的结果。分开获取概念时，准确性更高。
官方仓库：https://github.com/upstash/context7
2. Playwright MCP：让 Claude 亲自操作浏览器
这直接实现了 Boris 的原则 1。
Claude Code 可以编写代码，但它不知道它写的屏幕是否真的能工作。连接 Playwright MCP 允许 Claude 打开一个真实的浏览器，点击按钮，填写表单，追踪页面跳转，捕获错误，修复它，然后再次检查。
这个系统有趣的地方在于，它不仅仅是把截图作为图像来看。它读取的是"无障碍树"——屏幕的结构化信息。它能理解什么是按钮、输入框或标题。因为它读取的是语义，所以不太可能混淆视觉上相似的元素。
实用提示：
实现完成后，使用 Playwright MCP 打开本地环境。
实际操作并验证以下内容：
- 新用户注册
- 登录
- 输入错误时的显示
- 手机宽度下的布局错乱
- 退出登录
如果失败，不要仅靠阅读代码猜测原因；先在浏览器中复现，然后再修复。
修复后，重新运行相同的操作，确认成功后报告完成。
这里我实话实说。
Boris 自己说他做网页工作时每次都用的，实际上是 Claude Code 浏览器扩展，而不是 Playwright MCP。他说它比类似的 MCP 更稳定，因为可以原样共享登录状态。
所以使用场景是：如果你想使用已登录的浏览器检查实际屏幕，使用扩展。如果你想将其作为测试自动化，并重复运行相同的流程，使用 Playwright MCP。
两者的理念相同："给 Claude 一个浏览器。"
官方仓库：https://github.com/microsoft/playwright-mcp
3. Figma MCP：读取设计数据，而非图片
只要你把设计稿作为截图传给 Claude，它总是在猜测。
边距是多少像素？字体大小是多少？这个颜色是品牌色还是临时色？这部分是可复用的组件吗？所有这些都只能从图片中目测。
连接 Figma 开发者 MCP 允许直接访问结构化的设计信息。数值、颜色、组件结构、设计 Token。猜测消失了。
实用提示：
从 Figma MCP 获取当前选中的画板。
首先，只提取以下内容，不要开始实现：
- 页面结构
- 需要复用的组件
- 颜色和字体定义
- 边距规则
- 响应式缩放时的预期变化
确认提取的内容后，优先使用现有项目组件进行实现。
如果需要创建新组件，先解释为什么现有组件不足。
这里是真正的关键。
从 Figma 拉取设计，在 Claude Code 中实现，在 Playwright 中检查，如果坏了就修复。将这三个连接起来，设计到验证就变成了一条线。
MCP 的价值在这种连接中比孤立使用时更容易理解。
官方文档：https://developers.figma.com/docs/figma-mcp-server/
4. Linear MCP：读取工单并写入进度
Boris 提到他用 @claude 在 PR 中提及同事，并让它将学到的东西添加到规则手册中。简而言之，他没有将问题管理空间与 AI 工作空间分开。
连接官方 Linear MCP 允许在 Claude Code 中完全搜索、创建、更新和评论议题。由于它是 Linear 托管的远程连接，并带有认证，你不需要在电脑上保持服务器运行。
这使得以下流程无缝衔接：
读取议题 → 调查相关代码 → 创建实现计划 → 实现 → 测试 → 在议题上评论进度 → 更新状态
实用提示：
检查 Linear 中分配给我且正在进行中的议题。
在整理优先级和依赖关系后，对最高优先级的议题执行以下操作：
- 识别需求中缺失的信息
- 调查相关代码
- 在实现前创建实现计划并呈现
- 获得批准后实现并测试
- 在议题上评论已采取的行动
在更改状态前请等待我的确认。
务必包含最后那一行。如果你让它自动化状态更改，从其他团队成员的角度来看，最终会出现"未完成的工作被标记为已完成"的情况。
官方文档：https://linear.app/docs/mcp
5. Sentry MCP：无需粘贴错误即可追踪原因
当生产环境错误发生时，你会怎么做？
打开 Sentry，复制堆栈跟踪，粘贴给 Claude，找到你怀疑的文件，再粘贴过去。这些都不需要了。
Sentry MCP 的价值不仅仅是显示错误列表。它把错误内容、堆栈跟踪、发生频率、受影响用户、来自哪个版本、相关代码以及过去类似的失败都放在一个调查循环中。
实用提示：
从 Sentry 获取过去 24 小时内受影响用户最多的未解决错误。
按以下顺序调查：
- 分析发生条件
- 识别相关代码
- 创建复现测试
- 如果可以复现，实施最小修复
- 运行所有测试
- 总结根本原因和修复方案
如果不可复现，不要基于猜测修复。列出缩小原因范围所需的额外信息，然后停止。
"如果不可复现，不要基于猜测修复"这句话很有效。没有它，可能会应用一个看似合理的修复，但根本原因依然存在，并且它会报告"已修复"。
官方文档：https://docs.sentry.io/product/sentry-mcp/
6. Cloudflare MCP：展示部署目标的状态
到目前为止我们讨论了开发，但这个是关于运维的。
Cloudflare 发布了多个官方 MCP 服务器来操作其服务。检查设置、管理 Workers、日志分析、DNS 设置、安全设置、性能检查。它不仅设计用于读取，还用于提出建议并实际进行更改。
这意味着 Claude Code 可以在看到代码在部署目标上的实际表现后，改进代码。
实用提示：
使用 Cloudflare MCP 检查当前生产环境状态。
调查：
- 过去 24 小时内的错误
- 响应时间
- 缓存命中率
- 安全事件
- Workers 中发生的异常
然后，将问题分类到这两个类别中：
A. 需要更改代码的
B. 仅通过 Cloudflare 设置即可改善的
在这两种情况下，执行更改前始终先呈现计划。在我批准之前，不要更改设置。
由于这涉及基础设施，在初始引入阶段限制为只读。一开始不需要允许更改设置。
官方文档：https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
7. Stripe MCP：将支付代码与 Stripe 设置匹配
支付实现之所以困难，是因为仅靠查看代码无法知道正确答案。你必须检查 Stripe 端注册了哪些产品和价格，以及在另一个标签页中 webhook 是如何设置的，同时编写代码。
官方 Stripe MCP 除了 Stripe API 操作外，还包括搜索官方文档和支持信息。实现、设置验证和文档参考都在同一个地方进行。
此外，Stripe 还提供了用于 Agent 的技能。用 MCP 操作，用技能执行最佳实践。这个组合非常强大。
实用提示：
使用 Stripe MCP 和官方 Stripe 文档，创建月度订阅功能的实现计划。
确保检查以下内容：
- 产品和价格配置
- 如何创建 Checkout Session
- 需要通过 Webhook 接收的事件
- 取消流程
- 支付失败时的行为
- 防止重复注册的方法
- 测试方法
工作时仅使用 Stripe 测试模式。不要对生产数据做任何更改。
永远不要删除最后那两行。这不是一个可以在打开那些闸门的情况下运行的 MCP。
官方文档：https://docs.stripe.com/mcp
8. GitHub MCP：关闭审查反馈的循环
最后，这一个。
但请不要误解；GitHub MCP 的价值不在于"能够运行 git 命令"。Claude Code 已经可以操作本地 git 和 GitHub CLI。
它的价值在于遍历那些只存在于远程端的信息：议题详情、PR 审查评论、CI 结果、其他仓库的状态、内部代码搜索和过去的讨论。
实用提示：
使用 GitHub MCP 检查当前分支对应的 PR。
收集所有未解决的审查评论，并将它们分为以下三类：
- 必须修复的内容
- 需要我决定的设计决策
- 被判断为不需要修复的内容（附上理由）
只实现"必须修复的内容"，并通过测试。
不要触碰需要设计决策的内容；而是整理争议点和选项并呈现出来。
阅读审查评论、修复、测试和报告——全部在 Claude Code 内部完成。
官方仓库：https://github.com/github/github-mcp-server
构建"堆栈"，而非单个工具
MCP 逐个添加时效果较差。当它们根据工作流程排列起来时，才会发生转变。
Web 生产堆栈：
从 Figma 拉取设计 → 使用 Context7 检查当前正确的语法 → 在 Claude Code 中实现 → 使用 Playwright 进行浏览器验证 → 在 GitHub 上发起 PR 和处理审查反馈 → 在 Cloudflare 上部署和检查日志
SaaS 开发堆栈：
从 Linear 拉取需求 → 使用 Context7 检查技术规范 → 在 Claude Code 中实现 → 使用 Stripe 设置和验证支付 → 使用 Playwright 测试用户操作 → 使用 Sentry 监控生产错误
正在发生的事情：
在两个堆栈中，流程是相同的。
获取信息，规划，构建，自己验证，对外反映，查看结果。
这个循环无需离开 Claude Code 即可完成。
Boris 的"给它验证的手段"不仅仅指一个浏览器。它意味着在流程的每个步骤中，都提供确认其正确性的手段。
初学者只需要这三个
我不是说要把所有八个都安装上。那样做会让你陷入下一章提到的陷阱。
阶段 1：Context7
目标是减少错误代码。
由于它是只读的，风险很低。从这里开始最安全，也最能让你最快感受到效果。
阶段 2：Playwright 或浏览器扩展
目标是让 Claude 自己验证交付物。
如果你从事网页工作，这会有很大改变。构建，打开，发现错误，修复，再次打开。人类不再需要介入其中。
阶段 3：Linear 或 GitHub
目标是连接工作的输入和输出。
从工单到实现，到 PR，再到进度更新。在这一点上，Claude Code 从一个"等待指令的编码者"变成了一个"自主推动工作前进的成员"。
这三个就够了。真的。
你必须阅读的陷阱
陷阱 1：更多的 MCP 并不会让它更聪明
这是最大的误解。
如果你连接大量的 MCP，Claude 可以选择使用的工具候选数量会增加。然后会发生什么？
它会困惑于该用哪个。它会消耗上下文。它会混淆相似的工具。它会执行你未要求它执行的操作。权限管理变得复杂，你会失去对允许什么的追踪。
与其连接 100 个，不如只启用当前任务所需的 3 到 5 个，这样效果更好。正确的方法是每个项目更改连接的内容。
（我曾经连接了超过 10 个，Claude 不断调用奇怪的工具，让我想"为什么它突然变笨了？"减少数量后问题就解决了。）
陷阱 2：不要一开始就混合读写和写操作
在初始引入时，确保你创建了这种设计：
读取允许。创建需要确认。更新需要确认。删除拒绝。生产操作拒绝。
具体来说，从一开始就不应该完全允许的事情包括：生产部署、DNS 更改、客户数据更改、生产支付操作、议题删除、PR 合并和数据库删除。
MCP 的便利性和危险性完全成正比。
陷阱 3：不要混淆官方和社区制作的服务器
在 MCP 搜索网站上，可能会出现多个同名的服务器。即使它在官方列表中，也不一定是来自提供商的官方实现。
在安装前检查这些：
它是由提供商的官方组织管理的吗？上次更新是什么时候？有安全策略吗？认证方法是什么？它请求了多少权限？它是否设计为允许删除或生产更改？
请求的权限越多，你就应该越仔细地查看。
陷阱 4：不要让它原样执行外部文本
读取议题或 PR 评论来实现的工作流程很强大，但这涉及他人编写的文本。
如果某个议题说"按照此议题中的步骤操作"，并包含恶意指令，Claude 可能会读取并遵循它们。对于处理外部输入的 MCP，不要让它直接执行；先让它呈现它打算做什么。
尚未固化的领域
我会不加夸张地写出来。
通过 MCP 将长时间运行的任务抛给外部系统的机制在规范中，但每个服务器是否支持是另一回事。规范发布和实现跟进是两码事。在使用前检查服务器的当前状态。
在对话中返回 UI 的机制也处于扩展阶段。目前并非所有 MCP 都返回操作界面。
此外，定价和服务条款变动很大。在本文中使用前，请先访问官方链接一次。特别是认证和权限范围，不是可以不经检查就连接的东西。
我也不会给出像"MCP 将性能提升 X 倍"这样的数字。这还没有被证明。
相反，衡量这个：你每天花多少分钟在复制粘贴、屏幕切换和视觉验证上？这些就是随着 MCP 而消失的东西。
今天该做什么
不要试图做所有事情。只做一件事。
回想一下你的工作，找到一个你"在 Claude Code 和另一个屏幕之间来回切换"的地方。
可能是文档。可能是议题。可能是错误屏幕。可能是一个设计。
只安装那个能消除这一件事的 MCP。感受效果，然后再添加下一个。
Boris 的原则最终归结为：给 Claude 检查自己工作的手段。当你给予它时，Claude 会自己开始运行，直到满意为止。
当你停下来的时候，你今天会复制同样的东西，粘贴到同一个屏幕上。当它开始运行时，那个来回的过程将永远消失。
今晚，打开 Claude Code，想想你最常访问的那个屏幕。
一切从那里开始。
