00:00:00如果你正在使用 Claude Code 开发 Web 应用程序，那么你一定要了解一下 GSD，
00:00:04这是一个开源的规范驱动开发（Spec-Driven Development）框架，专门负责
00:00:08编排不同的子代理，按照规范驱动开发框架来完成项目。
00:00:12与我们频道之前介绍过的传统规范驱动开发框架不同，
00:00:15比如 Beemap Method、SpecKits、Taskmaster 等等，所有传统的
00:00:20规范驱动开发框架都必须遵循严格的规则，即所有工作都必须在
00:00:24单个上下文窗口中完成。例如：规划、调研、开发、校验，
00:00:29全部都需要在一个上下文窗口中进行。但这会带来一个非常关键的问题，
00:00:33那就是“上下文膨胀”，这意味着单个上下文窗口中的 Token 消耗越高，
00:00:38准确度就越低。而解决这个问题的方案就是使用子代理，
00:00:42将规划、调研、开发、校验分别委派给各自的子代理，
00:00:47每个子代理都会拥有全新的上下文来逐一完成任务。
00:00:51GSD 在这里本质上扮演了一个编排者的角色，遵循规范驱动开发，
00:00:55引导 AI 逐步将粗略的想法转化为可投入生产的应用。
00:01:00这意味着，虽然我们会消耗更多的 Token，
00:01:04但与把所有东西挤在一个上下文窗口中相比，我们获得的准确性要高得多。
00:01:07所以在本视频中，我将向大家展示
00:01:11如何在 Claude Code 上配置 GSD 框架。我会演示
00:01:15如何根据一个创意，在现有应用或新应用的基础上进行构建，
00:01:19如何利用它内置的调研代理和规划代理来打磨你的创意。
00:01:23一旦我们确定了方案，就可以进入实施阶段，
00:01:27它有专门的执行器，可以通过多个并行代理同时运行来执行任务。
00:01:32每个代理都有自己独立的上下文窗口，并会提交它完成的每一项任务。
00:01:37此外，每当完成一项任务，它还会启动另一个代理
00:01:41根据设定的目标来校验该任务。最重要的是，当我们完成一个阶段的任务后，
00:01:45我会向你展示如何循环执行各个阶段，
00:01:49比如讨论、规划、执行以及校验，一步步循环往复，直到
00:01:55整个里程碑自主完成，无需人工介入。这就是我们本期视频要涵盖的内容。
00:02:00如果你感兴趣，那我们就开始吧。在开始之前，先给新朋友做个简单的自我介绍，
00:02:04我叫 Eric，曾在 Amazon、AWS 和微软担任过多年的高级软件工程师。
00:02:09我创办这个 YouTube 频道是为了分享
00:02:15我在 AI 编程、自动化、Web3、职业发展等方面学到的所有知识，
00:02:22并将它们拆解成大家都能上手的实操教程。所以，如果你准备好提升自己，
00:02:27记得关注我的频道并点击订阅。现在，让我们回到正题。
00:02:32我们要做的第一件事就是访问 GSD 的代码仓库。
00:02:36这里详细介绍了如何将其安装到你的本地机器上。我会直接复制这条命令，
00:02:40回到当前项目的终端，
00:02:44粘贴并运行该命令将其安装到本地项目中。
00:02:49点击确认安装。这里你可以看到，
00:02:53我们要选择是使用 Claude Code、Open Code 还是两者都用。本次演示我先选择 Claude Code。
00:02:57接着它会问，你想把它安装在哪里？
00:03:02我喜欢全局安装，以便在所有项目中都能使用。好的。
00:03:07选择好之后，可以看到 GSD 包含了一个状态栏，显示模型名称、
00:03:12当前任务以及上下文窗口的使用情况。它是询问要保留现有的，
00:03:17还是替换成 GSD 的状态栏？其实我还没见过 GSD 的状态栏长什么样，
00:03:22所以我选择第二个选项。我们来看看
00:03:26GSD 状态栏的样子。我现在打开 Claude Code 会话，
00:03:31这里显示的就是 GSD 当前的状态栏。当然，如果你不喜欢这个版本，
00:03:37想用我那个版本的，可以去看我之前的视频，
00:03:41我在那里教过大家如何自定义状态栏。不过，
00:03:46如果你想直接用 GSD 的，就保持这个选项即可。
00:03:49安装好 GSD 后，只需输入 gsd 即可。你可以看到
00:03:54Claude Code 终端里已经有了所有的自定义命令。好的。
00:03:58GSD 安装完毕，下一步就是尝试初始化我们的项目。
00:04:02如果你是开始一个新项目，只需运行 gsd new project。但
00:04:06如果你已经有现成的项目了，我们需要先运行这条命令。
00:04:10它会启动多个子代理来分析技术栈、架构、规范和疑虑。
00:04:15然后我们运行该命令来熟悉整个代码库，并根据你打算添加的功能
00:04:20和规划来提出问题并设计应用。在这个例子中，
00:04:24我会先运行这条命令，尝试映射整个代码库。在这里
00:04:28你可以看到，它会启动四个并行的代码库映射代理，尝试对整个代码库进行映射，
00:04:32去理解技术栈、架构、约定、疑虑等所有内容，
00:04:38尝试为应用分析一切。现在，让我们稍微等一下，
00:04:42直到这四个并行运行的映射代理完全完成工作。好的。
00:04:46现在映射器已经完成了对整个代码库的分析。接下来
00:04:50我会重置一下 Claude Code 会话，因为当前的上下文窗口
00:04:54已经用了一半了对吧？所以我要先终止它，然后清理终端，
00:04:59重新运行 Claude Code 会话。这样我们在映射完成后就能从零开始，
00:05:04但不用担心，映射结果已经保存了状态。你可以看到
00:05:09有一个 .planning 文件夹。在 .planning 里面有一个 codebase.md 文件。
00:05:13它总结了应用中的所有信息，比如架构、
00:05:17疑虑、约定、集成等所有内容都存储在
00:05:23这个文件夹中，这样我们就不会丢失当前的映射状态。好的。
00:05:28完成全量代码库映射后，现在是时候初始化我们的项目了。
00:05:32接下来它会问我一系列深入的问题，
00:05:36以了解我的想法。我们要添加哪些新功能？然后它会
00:05:39派出多个并行的子代理去调查我们要构建的领域。
00:05:43它还会帮你提取需求以及路线图，明确
00:05:47实现目标具体需要哪些阶段。这就是我们接下来要做的，
00:05:51复制这条命令并粘贴。它会尝试
00:05:56初始化我们当前的项目。可以看到，这是一个现有项目（Brownfield），
00:06:00拥有现成的代码库且已完成映射。Git 仓库已存在，
00:06:05但还没有 project.md 规划文件。所以它问了我一个问题：
00:06:10“我看到你已有映射好的代码库。查看 cloud.md 文件，我了解了
00:06:14业务背景。”接着它问：“接下来你想让我构建什么？”好的。
00:06:18因为我心里已经有了要构建的功能，那就是为一个管理系统
00:06:23构建一个仪表盘，这是我用 AI 起草的一个非常简短的 MD 文件，
00:06:29旨在构建一个最小化的管理面板，它是现有仪表盘侧边栏的一个新选项卡，
00:06:34提供管理用户和处理支持问题的必备工具。
00:06:39你可以看到我要求的一些功能，包括 MVP 功能、
00:06:42UX 原型框架等等，非常详细。
00:06:47我强烈建议大家利用 Claude 这种 AI 来
00:06:52审视应用，并起草一份你想构建内容的详细计划。
00:06:56至少要列出 UX 变更或功能点，这样
00:07:00我们才能让 Claude 有清晰的计划去执行实施。现在，
00:07:04虽然我可以拿这份计划直接让 Claude 去实现，但我更想
00:07:08让 GSD 接手并进行一些调查或研究。通过
00:07:13启动多个子代理代表我们进行调研，并将这个大任务拆解成
00:07:20更易于实施的小任务。在这种情况下，我会打开终端并告诉它，
00:07:25这就是我们要构建的内容。我会引用这个文件。
00:07:28我会说：“我计划接下来构建这个。”然后
00:07:33按下回车，让 GSD 来协助我们进行规划。
00:07:40你可以看到，它正在阅读我们想要在这个应用中实现的积压任务项。
00:07:44接着它触发了用户提问环节，向我提出一些严肃的问题
00:07:48来确认具体规范。它说这个
00:07:52规范包含了四个功能：用户列表、积分、等级、身份模拟，是想
00:07:58一次性全部构建，还是在第一次迭代中先优先处理一部分？
00:08:02你可以看到，它开始将这个巨大的四项功能拆分成更小的功能。
00:08:07我会说：“那先从简单的功能开始吧，比如用户列表和积分。”
00:08:11我回答：“好的，就这样办。”它又问：“你想如何校验管理面板运行正常？”
00:08:16目前因为这个项目还很新，我主要是做手动测试，但你可以看到
00:08:21它在询问测试覆盖率。比如我们可以做集成测试，比如为端点添加 API
00:08:25路由测试。或者全量覆盖测试，包括单元测试、
00:08:30集成测试和端到端测试。我打算先专注于手动测试，
00:08:34以后再逐步增加测试覆盖率。所以我回答说
00:08:38目前先做手动测试，并提交了答案。让我们来看看 GSD
00:08:43接下来会做什么。你可以看到它根据我的回答继续追问。
00:08:46“你什么时候需要管理面板上线？”因为在当前的应用中，我有一份
00:08:50业务分析文档，里面规划的时间线提到 1 月 30 日是实际发布日期。
00:08:56所以它问我第一个问题，是否需要在 V2 发布前完成，
00:09:01也就是 1 月 30 日。我会回答：“是的，我肯定希望在 1 月 30 日之前完成。”
00:09:05接着它询问是否要继续生成 project.md 文件。
00:09:10我想继续探索并多问几个问题。好的。我问的其中一个问题是
00:09:14尝试找出我们的规范中缺失的差距，以及我们接下来要做什么。
00:09:19你可以看到，我派出了多个子代理去进行
00:09:22关于安全性、UX、最佳实践以及当前规范中可能遗漏的
00:09:28技术实现差距的调研。这里有一个表格，
00:09:32基本上涵盖了所有的差距。例如：缺少管理中间件保护、
00:09:37Cookie 缺失。还有频率限制是基于内存的，以及用户删除时的
00:09:43管理操作。此外，其他用户的 isAdmin 函数也存在问题。所以我们要确保
00:09:49在当前要实施的项目中解决这些差距。在这里，
00:09:52你可以看到这是它建议我们修复的列表。我们可以
00:09:57仔细查看这些内容，看看这些差距是否合理。一旦确认没问题，
00:10:02我们就可以继续创建 project.md 文件并着手实施。它会继续问我一些问题：
00:10:06“调研发现了关键的安全漏洞，你希望我如何处理？”
00:10:11我会说：“修复那些关键的”，这也是我的建议。
00:10:15我输入并让 Claude Code 确保我们的计划和规范
00:10:20在进入 project.md 文件之前没有任何遗漏。一切就绪后，
00:10:24我们现在可以创建 project.md 文件了。我说：“好的，开始生成吧。”
00:10:29你可以看到，Claude Code 正在为整个项目创建 project.md 文件。
00:10:33我们稍等片刻直到它完全完成。在进入下一节之前，
00:10:38我想特别感谢今天的赞助商 Testbrite。
00:10:42Testbrite 是专门为软件测试构建的 AI 代理。随着
00:10:46Testbrite MCP 的发布，你现在可以直接在常用的 IDE 中使用它，
00:10:51比如 Cursor、Windsurf、Claude Code 等。设置非常简单，
00:10:57只需在 MCP 设置中添加配置即可。我非常喜欢 Testbrite 的一点是，它不是盲目地运行测试。
00:11:02它会先通读你的整个代码库，理解文档，并验证
00:11:07AI 代理产生的结果。它会根据 PRD 自动生成测试计划、
00:11:11创建测试用例、确保测试覆盖率，所有这些都无需手动干预。
00:11:16之后它会执行测试并向你发送详细报告，清晰地展示哪里出错了
00:11:21以及哪里需要注意。目前大多数编程代理的平均准确率在 42% 左右，
00:11:26但通过使用 Testbrite MCP，团队的功能交付准确率最高能提升到 93%。
00:11:32如果你感兴趣，可以去看我专门为它做的视频，或者点击下方描述栏的链接
00:11:38获取更多详情。回到视频。好的，一旦我们完成了项目范围划定并创建了
00:11:42project.md 文件，就会看到模式选择提示。我们可以选择
00:11:47“YOLO 模式”，它会自动批准并直接执行，或者
00:11:52选择更具交互性的模式。这样每当它完成一个步骤，我们都可以确认
00:11:56它所做的更改，然后再继续。我这里选择 YOLO 模式，尝试
00:12:01完全放手让它去完成一切。我直接按回车选择 YOLO 模式。
00:12:04接着它询问规划深度，也就是规划要有多详尽。我们可以选择
00:12:09快速交付模式，大约 3 到 5 个阶段，每个阶段 1 到 3 个计划。
00:12:14或者选择标准模式，范围更平衡，包含 5 到 8 个阶段，
00:12:18每个阶段可能有 3 到 5 个计划。这里我选择标准模式，
00:12:22因为这种范围更平衡，我们不追求极致的交付速度，而是希望
00:12:26规划更全面。我选择 2 号选项。
00:12:30现在提交答案。好的，结果显示
00:12:34我们进入了执行环节。我们可以选择并行运行计划，
00:12:38这意味着独立的计划会同时运行，或者
00:12:42按顺序逐一执行。我的建议是，如果时间不赶，
00:12:46强烈建议使用顺序执行模式。因为我们会一个接一个地处理计划，
00:12:51而不是同时进行。假设在并行模式下你的额度用完了，
00:12:57你可能会被卡在两个都没完成的任务上。但如果是顺序模式，你至少能
00:13:01完成一些任务。即使额度用完了，你也可以选择等待
00:13:06或者明天再来继续按顺序执行任务。至少
00:13:10你的项目计划不会全都处于半途而废的状态，对吧？
00:13:14所以我选择顺序模式，因为我想稳扎稳打。关于
00:13:18Git 追踪，是否要将规划文档提交到 Git？是的，
00:13:22我肯定希望在 Git 中保留规划文档。所以我选择“是”并点击提交。
00:13:27好的，它又问了一些额外的问题，比如是否在规划前进行调研？
00:13:31我选了“是”。还有在执行前是否校验计划能达成目标？
00:13:35我也选了“是”。关于校验器，即是否在每个阶段结束后
00:13:40校验工作是否符合需求？我也选了“是”。最后是模型偏好。
00:13:46我选择“质量优先”。即在调研和路线图阶段使用 Opus 模型，
00:13:52虽然成本更高，但分析更深刻。好了，你可以看到
00:13:58它已将所有这些配置存入了 config.json 文件中。这就是
00:14:03配置文件，以后我们随时可以直接修改它。
00:14:07为了不让视频太长，GSD 现在带我们进入了调研阶段。你可以看到
00:14:12GSD 启动了调研合成器，它会先派出多个子代理
00:14:16去进行调研。当所有调研员完成工作后，它会
00:14:21综合所有的调研成果，并尝试根据我们要开发的项目
00:14:26创建出一份调研报告。一旦我们认可这些内容，
00:14:30GSD 就会开始为整个项目创建详细的、循序渐进的路线图。
00:14:34好的，现在你可以看到它已经生成了完整的路线图，
00:14:39共分为 5 个阶段，映射了 36 项需求，涵盖了所有 V1 阶段的需求。
00:14:43例如数据库、Schema、后端，然后是用户体验。它在询问：
00:14:49“这个路线图结构你觉得可以吗？”你可以仔细查看
00:14:54是否有遗漏。如果一切正常，我直接回复“批准”并开始实施。
00:14:59好的，项目初始化完成后，你可以看到这就是它生成的全套 MVP 交付物。
00:15:03它们都在 .planning 文件夹里。5 个阶段、36 项需求都已准备就绪。
00:15:08接下来如果没有问题，我们将开始第一阶段的任务，一步一个脚印。
00:15:13它都在 planning 文件夹里，对吧？所有 5 个阶段和 36 个需求都准备好构建了。
00:15:18接下来，如果我们没意见，我们将开始第一阶段，
00:15:21逐一执行。一旦你为第一阶段创建了计划，
00:15:25你可以看到这里还启动了多个子代理，来为第二阶段、
00:15:29第三阶段创建计划，全部一气呵成，对吧？你可以拥有所有的子代理来清理、
00:15:34创建新计划，或者为我们拥有的每个阶段创建一个计划，对吧？一旦你创建了一个阶段，
00:15:38你现在可以做的就是基本上进入实施阶段。就像我们提到的，对吧，
00:15:41我们希望在全新的上下文中按顺序运行，我不希望它完成
00:15:46一个计划后就要求我验证，对吧？我希望它在那之后完成所有工作，
00:15:52然后我们再统一验证所有内容，对吧？我不希望在每个阶段都进行验证。
00:15:55我希望在所有阶段完成后再验证。现在你可以做的是与 Claude 沟通
00:15:59并告诉它，好的，我希望在全新的上下文中按顺序执行 GSD 阶段。
00:16:03基本上它接下来要做的是逐一执行每个阶段，
00:16:08为每个计划提供新鲜的会话上下文。基本上你可以看到，接下来会发生的是，
00:16:13它将使用 GSD 执行器启动全新的子代理。然后这里的每个代理
00:16:18都会获得 200K 的干净上下文。这样它就不会与另一个子代理完成的上一个计划混淆。
00:16:23然后接下来会发生的是，它将利用 GSD
00:16:27自主执行全部 13 个计划。所以我们有了数据库架构、后端、UI、积分管理，
00:16:34还有审计日志查看器，好吗？所有这些都集成在一起，逐一执行。在这里，我只是
00:16:39打算清除上下文并跳过权限，然后逐一执行。好了，现在你
00:16:44可以看到它正在执行管理仪表板实施的第一阶段。
00:16:48让我们稍等片刻，直到所有内容都完全实现。好了，在我们使用 GSD
00:16:53实现了所有阶段之后，这就是结果的样子。现在，你可以看到我在
00:16:57“管理”标签页中，这里是“用户管理”标签页。在这里我们可以查看
00:17:03我们当前平台中的所有用户。我可以搜索用户。例如，如果我输入
00:17:07"test"，你可以看到第一个结果就显示在这里。假设如果我
00:17:12删掉这个，你可以看到它又会显示整个列表。我还可以根据
00:17:17层级进行筛选。比如哪些人在使用免费版？我可以查看到这些信息，
00:17:21我还能看到积分使用情况、上次注册时间，并且还能调整积分，
00:17:25对吧？我可以查看账户详情，如你所见，或者我也能
00:17:29调整积分，就在这里，好吗？我可以帮助人们调整事件，
00:17:33设置积分，设置自定义积分限制，以及纠正
00:17:38使用量，并给出理由。在审计日志中，我们实际上可以追踪这些操作。
00:17:42例如，假设我选择所有层级，目前我以这个用户的身份登录，
00:17:48身份设为管理员。假设如果我点击这个，尝试调整积分，
00:17:52假设我要增加积分额度，例如增加到 50 个积分，对吧？所以
00:17:57从我们现在的 510 个积分，一直增加到 560 个积分。我们在这里要做的
00:18:03就是在下面添加一个理由。例如，我直接写 "test"，基本上
00:18:07这就是理由，然后我点击应用调整。接下来发生的是，你可以看到
00:18:11我们收到一个通知，显示积分已从 510 增加到 560，并且还触发了
00:18:17该组件的重新渲染。你可以看到在表格中，这也反映了出来，
00:18:21从 510 变成了 560，也就是我们现在的数值，好吗？所以我们可以验证这个功能
00:18:27完全正常工作。我们还可以查看管理分析部分，在那里我们可以
00:18:31看到应用程序中所有内容的分析数据。你可以看到上次
00:18:36更新的时间，以及应用程序的所有统计数据，如总用户数、付费用户数，
00:18:40以及不同的层级、不同的积分使用情况，还有最活跃的用户。此外，我们
00:18:46还能看到审计日志，这基本上意味着我们为了调整用户积分
00:18:51所做的所有事件和操作，我们实际上都可以在这个
00:18:55审计日志中看到。例如，调整积分、同步积分，以及目标用户是谁，
00:19:00以及我们操作的细节。我们可以在审计日志追踪里看到。所以
00:19:05基本上这就是你如何使用 GSD 遵循这一系列开发流程来完成一个功能。
00:19:09如果你觉得这个视频有帮助，请务必给视频点个赞。当然，
00:19:13如果你好奇我是如何让这个组件在积分应用后
00:19:16无需刷新页面就重新渲染的，简短的回答是，我使用了 Zustand，这是一种
00:19:21状态管理工具，用来集中管理我们整个应用程序的状态，这样每当
00:19:26组件的一个部分更新时，它也会在当前状态下触发更新。
00:19:30所以如果你好奇如何在你当前的应用程序中
00:19:34添加这种状态管理，我强烈建议你看看这门 7 小时的课程，它是我制作的，关于
00:19:38如何循序渐进地构建一个完整、可扩展且生产就绪的 NestJS 应用程序。
00:19:44话虽如此，如果你觉得这个视频有价值，请务必点赞。
00:19:47考虑订阅一下，因为在未来，我会分享所有的经验和技巧，
00:19:51教你如何利用 AI 编写代码，从而构建
00:19:55像这样生产就绪的应用程序。话虽如此，我们下个视频再见。