Claude Code全栈开发必知三点

Claude Code 用于全栈开发并不需要复杂的工作流。你真正需要的只有三个要素：

通过后台任务以及 Chrome DevTools MCP 等浏览器自动化工具，实现全栈调试可见性；

通过 llms.txt 访问对 LLM 友好的文档（上下文效率比 MCP 服务器高 10 倍）；以及

采用 Wasp 这样有明确设计主张的全栈框架，将样板代码减少 60%～80%，让 AI 能够更准确地构建更加复杂的应用。

如何高效使用 Claude Code？​

围绕使用 Claude Code 进行凭感觉编程，目前存在大量炒作。

好消息是，这些赞誉并非毫无根据。Claude Code 确实能够处理一些复杂得令人意外的编码任务。

坏消息是，它也被过度炒作了。例如，有人声称只用几个小时就能凭感觉编程做出惊艳的应用，或者使用复杂工作流，让 10 个并行子智能体循环运行，取代 5 名软件工程师的工作。

如果你还不是 Claude Code 的资深用户，这些炒作可能会让你怀疑自己是否真的掌握了高效使用它的方法。我没有采用这种疯狂的新工作流，是不是错过了生产力提升？针对我的使用场景，我是否应该使用子智能体、命令、技能或 MCP 服务器？如果应该，又该怎么用？

我当时也在问自己这些完全相同的问题，因此花了好几周时间研究和测试，最终得出了以下结论：

只需几个精心挑选的工具，再配合 Claude Code 的基础功能，就足以通过“凭感觉编程”构建出优秀的全栈应用。

你不需要使用它的所有功能​

看到这些复杂的 LLM 工作流和工具，感觉很奇怪。与此同时，我每个项目只使用一个持续进行的 Claude 对话……我从未使用过子智能体，也从未使用过 MCP……但我的效果好得离谱 ¯\(ツ)/¯
——Phoenix 框架创建者 Chris McCord

Claude Code 的能力确实令人印象深刻，但你很快就会意识到，它的许多功能彼此重叠。如果一开始就把几件关键事情做好，很多功能通常根本不需要频繁接触。下面我会先介绍这些关键点，然后在本文中逐一深入说明。

1. 为它提供全栈调试可见性

这样 Claude 才能真正看到自己编写的代码产生了什么结果，并作出响应，而不需要我们复制粘贴错误信息或描述问题。

2. 让 Claude Code 能够访问最新且对 LLM 友好的文档

当你使用的 LLM 可能掌握着过时的知识、虚构解决方案，或者受到未针对 LLM 优化的“嘈杂”文档干扰时，这一点至关重要。

3. 使用合适的技术栈或框架

这可能是三种方法中最容易被忽视的一种。选择合适的框架，能够为 AI 提供明确的模式供其遵循，并从一开始就消除大量复杂性。

有了这套基础，你主要使用 Claude Code 的默认工作流，再配合少量自定义命令或技能，就能轻松构建并部署全栈应用（我还把这些思路打包成了一个可以安装使用的简单 Claude Code 插件，不过稍后再详细介绍）。

这种方法之所以有效，是因为它为 AI 智能体提供了护栏以及可供遵循的正确模式，让你可以把更多时间用于实现业务逻辑，而不是费力制定规格和处理技术细节。

从本质上说，你可以和 AI 智能体一起专注于你想要什么，而不必解释你希望它如何实现。这让复杂的全栈应用也能拥有 AI 辅助编程带来的那种神奇体验。

让 Claude Code 获得全栈视野​

建立紧密的反馈循环​

我们典型的 AI 辅助编程工作流往往是这样的：输入提示词，然后等待，再检查生成的代码（也许会检查），接着在浏览器中查看效果。如果出现错误或前端设计看起来不理想，我们就把相关内容复制粘贴回来，并尝试（更清楚地）说明自己的需求。

更糟糕的是，我们可能不得不重复这个过程好几次，才能感到满意，或者让应用重新正常运行。

如果始终让自己参与循环中的每一步，就会大幅拖慢进度。有些时候，我们应该直接让开，让 AI 智能体在每次迭代中持续改进代码，直到完成，然后再检查结果。

但要做到这一点，我们需要给 Claude Code 一“双眼睛”。幸运的是，借助合适的功能和工具，这是可以实现的：它能够看到自己编写的代码产生的结果，并在技术栈中的任何位置遇到错误时，迅速自主修改代码。

将开发服务器作为后台任务运行​

Claude Code 推出了后台任务功能，使其能够在一旁执行应用开发服务器（例如 npm run dev）等长时间运行的任务，同时不阻塞 Claude 继续处理其他工作。更方便的是，在你工作期间，Claude 可以持续读取并响应该任务的输出。

要在后台运行命令，可以采用以下任一方式：

• 提示 Claude Code 在后台运行命令，例如：“在后台运行我的应用开发服务器”

• 按下 Ctrl+B，将普通的 Bash 工具调用移至后台，例如输入“运行开发服务器”，并在服务器启动时按下 Ctrl+B

尽管 Claude 可以读取后台任务的输出，但有时你可能想亲自检查任务状态，这同样可以做到。只需使用向下方向键选中后台任务消息，然后按下回车键。

这非常有用，因为 Claude 现在可以对构建和提供代码服务时出现的问题作出响应。遗憾的是，它仍然无法响应应用在浏览器中运行时发生的错误。

不过，有一种很巧妙的方法可以解决这个问题。

浏览器自动化工具​

目前缺失的环节，是让 Claude 真正看到自己编写的代码所产生的结果，最常见的就是 UI 的实际外观。

只有应用在浏览器中运行后才会显现的问题，例如设计缺陷和运行时错误，AI 智能体仍然无法看到。因此，通常需要由人类介入并反馈：“按钮没有对齐”“尝试登录时出现 404 错误”“控制台提示了与 undefined 有关的问题”。

幸运的是，我们可以为 Claude Code 配备浏览器自动化工具来解决这个问题。这些工具能够以编程方式控制浏览器，例如加载页面、点击按钮、检查元素、读取控制台日志，甚至截取屏幕截图。

这为整个技术栈闭合了反馈循环，让 Claude 获得足够的自主能力，可以完全独立地完成规模更大的功能任务。

Chrome DevTools MCP server 是目前最优秀的选择之一，不过也存在许多替代方案。它安装简单，并且专注于浏览器调试和性能分析。

要安装它，请在终端中运行以下命令，将其添加到当前项目：

claude mcp add chrome-devtools --scope project npx chrome-devtools-mcp@latest

然后启动一个新的 Claude 会话，并向它输入类似下面的提示词：

Verify in the browser that your change works as expected.

你应该会看到一个由 Claude 控制的独立 Chrome 实例打开。接下来，可以继续交给它更多任务，例如：

• 对测试用户进行身份验证

• 检查网站的 Lighthouse 性能评分（例如加载速度）

• 针对如何改进应用设计提供反馈

将所有环节结合起来​

现在，当你在应用中实现全栈功能时，可以要求 Claude 通过检查开发服务器中的日志以及使用 Chrome DevTools MCP 在浏览器中进行检查，来验证该功能是否正常工作。

或者，如果你希望 Claude 始终自动使用 DevTools MCP 在浏览器中验证变更，而不必每次明确提出要求，可以在 CLAUDE.md 文件中向 Claude 的记忆添加一条规则。

让 AI 智能体访问正确的文档​

版本问题​

你可能经历过这种情况：正在使用某个库的 API 进行凭感觉编程，而 AI 信心满满地写出了一段本可以完美运行的代码……但那是在两个版本之前。又或者，它针对一个文档中已有简单解决方案的已知问题，设计出某种疯狂且过度工程化的变通方案。

这是因为模型的训练数据存在截止日期。除非你让 LLM 和 Claude 之类的工具访问当前文档，否则它们无法知道更新后的代码模式。

然而，正如 Andrej Karpathy 所观察到的，大多数文档都包含与 LLM 无关的内容：

99% 的库仍然采用这样的文档形式：渲染成一些漂亮的 .html 静态页面，并假设人类会逐页点击浏览。到了 2025 年，文档应该是一个 your_project.md 文本文件，专门用于放入 LLM 的上下文窗口。

研究也支持他的说法：当 HTML 语法或面向人类的冗长说明等无关内容被添加到上下文中时，会分散模型对任务的注意力并降低准确性，从而导致 LLM 的表现下降。

换句话说，上下文窗口中的每一个非必要 token，都会让 AI 的工作表现略微变差。

因此，我们需要为 Claude Code 提供正确类型的文档。

解决方案：经过筛选的文档访问​

解决方法很简单：让 AI 智能体能够获取并阅读与你所用工具相关、针对 LLM 优化过的文档。

开发者主要通过以下两种方式实现这一点：

MCP 服务器——一种让外部系统向 AI 智能体提供数据的标准。Vercel 等热门开发工具会提供这类服务器，其中包含文档搜索工具。

llms.txt 和文档索引——一种在约定俗成的 URL 上发布对 LLM 友好的文档的标准，例如 https://wasp.sh/llms.txt。AI 智能体可以获取专为 LLM 上下文窗口优化的结构化文档。

用于获取文档的 MCP 服务器

模型上下文协议（Model Context Protocol，MCP）是一项开放标准，用于将 AI 应用（即 AI 智能体、LLM）连接到外部系统。Claude Code 可以与 MCP 服务器通信，从而访问专用工具和信息。

目前，Supabase、Jira、Canva、Notion 和 Vercel 等热门工具已经拥有大量 MCP 服务器。Claude Code 的文档中有一个专门的章节，列出了这些 MCP 服务器以及更多其他服务器。如果你感兴趣，其中也提供了相应的安装说明。

Supabase 和 Vercel 这类开发者工具的 MCP 服务器提供了一些工具，可以根据查询为 AI 智能体获取文档。不过，这种方式有利有弊。

优点：

• 可以在返回文档前对其进行预处理
• 可以检查版本、筛选内容，并从多份文档或指南中获取相关片段
• 可以返回结构化输出，而不是原始文本

缺点：

• MCP 服务器会自行判断哪些内容相关，可能忽略一些有用的信息
• 它的所有工具（不只是文档获取工具）都会被加载到 LLM 的上下文窗口中，并很快占满窗口，从而降低 AI 智能体的性能
• AI 智能体需要承担更多开销：评估提示词 → 找到正确的 MCP 工具 → 调用工具 → 等待 MCP 服务器响应 → 评估响应 → 执行操作

由于 LLM 并没有真正的记忆，因此每次启动新会话时，它们都必须把信息重新加载到上下文中，例如它们可以使用哪些工具。单个 MCP 服务器可能会向上下文中添加大约 15～30 个工具；如果使用多个服务器，那么在你还没开始工作之前，就很容易消耗 LLM 上下文窗口的 10%～20%，甚至更多。

如果想查看上下文窗口已经使用了多少，可以在活跃的 Claude Code 会话中运行 /context 斜杠命令。上面的示例显示，仅一个 MCP 服务器就占用了上下文窗口的 2.5%。

而且，随着 LLM 的上下文窗口逐渐填满，其性能会下降。一些开发者甚至建议，当上下文使用率达到 75% 时就启动新会话，以避免这种问题。在 Claude Code 中，可以使用 /clear 命令实现这一点。你还可以运行 /compact 命令，它会为当前会话的上下文生成摘要，并将其传递给下一个会话。

幸运的是，如果你使用 MCP 服务器的主要原因只是搜索文档，那么还有另一项开放标准可供选择，它可能更适合这种场景。

对 LLM 友好的文档 URL——LLMs.txt

LLMs.txt 已迅速成为一种标准做法：网站通过 /llms.txt 路径，为 LLM 提供适合放入上下文的版本。

你可以在一些自己喜欢的开发者工具网站上试试，例如：

• supabase.com/llms.txt

尽管不同 llms.txt 文件所呈现的内容可能差异很大，但它们始终遵循同一种格式：一个简单的 Markdown 文件，其中包含网站标题和一些链接。仅此而已！这样一来，LLM 就能获取准确的信息，而不必处理所有无关内容。

使用 llms.txt 获取文档也有一些优缺点：

优点：

• 为 LLM 和 AI 智能体整理了最相关的信息列表
• 极其简单，任何能够获取 URL 的 AI 智能体都可以使用
• AI 智能体可以自行决定访问哪些链接，并查看完整的源文本
• 对上下文窗口的利用效率很高

缺点：

• 原始文档或 Markdown 文件可能会传输超出实际需要的信息
• AI 智能体可能会获取不兼容的链接或文件
• AI 智能体可能需要更多指导或规则，才能正确地与文档交互

在我看来，通过 llms.txt URL 获取文档是更好的方式，因为它能更高效地利用上下文。例如，一份典型的文档文件约为 100 个 token，而仅一个 MCP 服务器就需要 5,000～10,000 个 token。

这意味着上下文使用量减少了 10 倍。

Claude Code 也非常擅长浏览文档索引，只获取最相关的信息。此外，llms.txt 文件对人类来说也更容易查阅，这也是一个额外的好处。

Claude Code 在内部获取自己的文档时采用的也是这种方式。因此，当你询问与其自身功能有关的问题时，它会先获取自己的文档索引 Markdown 文件 URL，以找到正确的指南。

现在，你已经知道如何让 Claude Code 访问最新文档了。接下来需要回答的问题是：你可能需要为哪些工具提供文档？

最显而易见的答案，就是你在构建全栈应用时使用的技术栈或框架。

选择合适的技术栈或框架

这可能是三大支柱中最容易被忽视的一项。

从一套 AI 容易推理的技术栈开始，会让构建目标应用的工作变得容易得多。可供选择的方案很多，但幸运的是，其中有不少可靠的选择，例如：

• NextJS（React、NodeJS）
• Ruby on Rails（Rails）
• Wasp（React、NodeJS、Prisma）

到了 2026 年，使用 Claude Code 配合上面列出的任何框架，你都可以完成相当多的工作。不过，尽管这些框架都提供了良好的约定，并负责将技术栈中最重要的部分组合起来，其中大多数仍然需要某种额外的集成。

应该选择哪一个？

对于更侧重客户端的 NextJS，你必须自行选择并连接数据库层。对于统一了后端和数据库的 Laravel 与 Rails，你则需要决定使用哪个客户端，以及客户端将如何与后端通信。

因此，许多开发者会选择包含这些框架的热门技术栈或组合，例如：

• NextJS + tRPC + Prisma + NextAuth（又称 T3 Stack）
• Laravel + Inertia.js + React

你可能还注意到，T3 Stack 是其中唯一包含身份验证库 NextAuth 的技术栈。这是因为，以后端为中心的 Laravel 和 Rails 已经提供了为应用添加身份验证的约定式方案，而 NextJS 没有。

另一方面，Wasp 是这些框架中唯一统一了技术栈所有部分——客户端 ↔ 后端 ↔ 数据库——同时又对功能实现方式有明确主张的框架。

这些听起来都很好，但最终应该选择哪一个呢？

主张越明确，效果越好

框架的主张越明确，就越适合与 AI 一起凭感觉编程。

如果一个框架有明确主张，通常意味着代码只有一个显而易见的存放位置，也只有一种通用模式需要遵循。AI 不必猜测。框架已经提前作出了决定，因此你和你的 AI 智能体都不必再做这些决定。它通过约定编码了架构智慧，选定了要使用的库、身份验证的接入方式，以及应用应有的结构。

因此，当需要作出的决定更少、需要编写的样板代码更少、需要拼接的工具更少时，开发过程就会变得更加可靠。

随着应用变得更加复杂，AI 也不容易失去重点，因为框架承担了大量底层复杂性。你还可以更轻松地理解和检查生成的内容，避免把自己困在混乱且难以脱身的局面中。

请考虑这样一点：有明确主张的框架可以将样板代码减少 60%～80%。例如，Wasp 的身份验证声明可以用一份 10～15 行的配置，替代通常超过 500 行的身份验证代码。需要生成和审计的代码减少了 97%！

在这些框架中，Wasp 无疑是主张最明确的一个，但它也是其中最新的成员。紧随其后的可能是并列第二的 Laravel 和 Rails，不过它们分别构建于 PHP 和 Rails 之上，各自拥有独特的生态系统，因此你很可能还得将它们与 React 之类的前端 JavaScript 框架搭配使用。NextJS 是其中最受欢迎但主张最少的框架，这意味着你和 AI 需要处理更多复杂性，并在前期作出更多选择，但从长远来看，它也提供了更高的灵活性。

因此，最终如何选择，很大程度上取决于你想实现什么、熟悉什么，以及需要多大的灵活性。

只需记住：框架提供的结构和默认设置越多，AI 就越容易生成能够正确融入项目的代码，而你花在修复混乱或不一致输出上的时间也越少。

这对 Claude Code 意味着什么？

好。现在我们已经明确，使用有明确主张的框架，意味着它会替你管理大量复杂性。

但在实践中，将它与 Claude Code 搭配使用时，这究竟意味着什么？

需要用子智能体来规划架构？框架已经决定了架构。

需要制定复杂的计划来确定代码应该放在哪里？约定已经给出了答案。

需要来回沟通才能就模式达成一致？模式早已确定。

需要把应用的各个部分粘合起来？这些代码由框架管理。

需要通过上下文解释应用结构？它已经内嵌在框架中。

从某种意义上说，框架就像一份大型规范，你和 Claude 都已经理解并认同它。

你不再需要通过多轮对话来确定应该「如何」构建，只需要说明你想构建「什么」。

因此，当你告诉 Claude「为 Comments 添加一个新模型」或「添加用户账户设置功能」时，Claude 会确切地知道这意味着什么，以及所有内容应该放在哪里。此外，具体实现还会遵循最佳实践，并以框架背后经验丰富的专业人士所做的决策为基础，而不是由某个 LLM 基于错误假设匆忙实现功能。

这并不是说，你不再需要制订良好的计划、编写完善的规范，或者创建产品需求文档供 AI 智能体遵循。在凭感觉编程（或实践「规范驱动开发」）时，这仍然可能是非常重要的一步。

但这确实意味着，有了约定明确的全栈框架，你在规划阶段需要投入到架构与技术实现细节讨论上的精力会少得多。

将这种方法封装到插件中

如果你想把上面讨论的理论方法付诸实践，我建议试试我们为 Claude Code 创建的 Wasp 插件。

这个插件由我们这些 Wasp 框架的创建者负责维护，因此已经结合 Wasp 经历了充分的实战检验。此外，我们的社区响应非常迅速，也一直在倾听反馈并持续改进它。

下面是开始使用的方法：

npm i -g @wasp.sh/wasp-cli

安装 Claude Code 插件：

# add the Wasp marketplace to Claudeclaude plugin marketplace add wasp-lang/wasp-agent-plugins# install the plugin from the marketplaceclaude plugin install wasp@wasp-agent-plugins --scope project

创建一个新的 Wasp 项目：

# create a new projectwasp new# change into the project root directorycd <your-wasp-project>

在 Wasp 项目目录中启动 Claude Code 会话：

claude

运行 init 命令来设置插件：

/wasp:init

接下来，你可以让 Claude「启动开发服务器」，它会引导你按照前文介绍的方式建立全栈可见性。你也可以要求它实现某个 Wasp 功能，然后看着它为你获取与当前版本匹配的文档指南！

更重要的是，由于 Wasp 使用中央配置文件来定义应用，因此作为框架，它进入了比其他框架更加 AI 原生的领域。

这个主配置文件就像应用的蓝图。Wasp 会读取这些声明，并替你管理相应功能的代码。

以下面的身份验证配置片段为例：

app TaskManager {  wasp: { version: "^0.21.0" },  title: "Task Manager",  auth: {    userEntity: User,    methods: {      email: {},      google: {}    },    onAuthFailedRedirectTo: "/login"  }}

这就是 Wasp 中身份验证的完整实现。仅此而已。

这 8 行配置可以生成通常需要 500～800 行代码才能实现的内容：组件、会话处理、密码哈希、OAuth 流程以及数据库模式。Claude 只需要知道你想使用哪些身份验证方式。

Claude 无须费心选择使用哪种身份验证实现，也无须生成任何粘合代码。它可以直接开始构建功能。

什么时候确实需要那些高级功能

整篇文章中，我一直在论证：对于全栈应用开发，你可以忽略 Claude Code 的许多功能。但我不希望给你留下这些功能毫无用处的印象。

当你需要按照一致的标准反复执行同一项任务时，自定义子智能体、命令和技能就能大放异彩，例如：

测试——一个专门的测试运行子智能体，了解你的测试模式，能够运行测试套件、分析失败原因并提出修复建议。

代码审查——使用代码审查命令或子智能体，在每次开发完成后运行测试、修复错误并审查代码。

运行脚本——如果你经常执行确定性的任务，技能会非常有用，例如运行部署脚本，或者使用 CLI 工具将博客图片转换为 WebP。可以在 Skill 中定义这些任务并关联相应脚本，Claude Code 会在判断它们适合当前任务时运行这些脚本。

对于这类任务，你希望每次都遵循相同的流程，因此配置完善、拥有明确规则的子智能体非常合适。

大多数情况下，只有当简单方法不再奏效时，才应该引入复杂性。

我认为，凭借以下三个要素，大多数全栈应用开发者无须借助更多复杂功能，就能完成绝大部分工作：

• 一个约定明确、能够处理架构和样板代码的框架，让 Claude 无须操心这些事情

• 与版本匹配的文档，让 Claude 掌握最新的实现细节

• 全栈可见性，让 Claude 能够看到正在发生的情况并自行修复问题

具备这些条件后，仅凭 Claude Code 的基础工具集——探索、规划、读取、编写和运行命令——就足以构建真正复杂的全栈应用。子智能体、钩子、插件以及复杂配置随时可供使用，但坦白说，大多数时候你并不需要它们。