00:00:00尽管 Claude Code 是 AI 开发中最强大的工具之一，
00:00:03但为什么它在某些任务上会力不从心？结合 Anthropic 最近
00:00:08发布的新功能，以及我们围绕它构建的工作流，你使用它的方式
00:00:12应该与几周前完全不同。我们的团队每天都在使用 Claude Code，
00:00:16它不仅仅用于开发，还用于研究、管理生产流水线
00:00:21以及自动化那些与代码无关的任务。现在就让我向你展示我们发现的一切。
00:00:26Anthropic 最近为 Claude Code 添加了 insights 命令。它会分析
00:00:31你在特定时间段内所有的历史会话并生成报告。该报告
00:00:36会分析你的工作风格，吐槽你的工作模式，指出你的优点
00:00:40和不足，并告诉你如何改进。我们最感兴趣的是找出
00:00:45哪里出了问题，因为那是我们学习和提升的地方。报告重点标注了
00:00:49摩擦最大的环节，并建议了一些可以优化工作流的功能。
00:00:54例如，我们记得有一次，当我们在使用智能体团队模式时，主代理
00:00:58长时间重复拉取任务列表。这导致会话耗时过长，
00:01:03我们不得不手动结束它。为了防止未来再次发生，我们可以将这段提示词
00:01:07复制到 claude.md 中。这样每当我们使用多代理模式时，Claude 就不再
00:01:12无限轮询，而是直接执行。我们可以将这些技巧导入项目以供后续使用，
00:01:17让 Claude Code 的体验随时间不断提升。我们团队投入了大量时间
00:01:22研究 Claude Code，而最关键的一步依然是如何给代理提供充足的上下文。
00:01:26这可以是拆解后的项目需求，或者是你正在使用的框架和
00:01:30库的文档。当你提供了正确的上下文，错误率几乎会降至零，
00:01:35因为它知道该针对什么进行操作。对于项目文档，我们更倾向于让 Claude 编写，
00:01:39而不是亲自动手。我们给了 Claude 一个特定的提示词，包含所有
00:01:44必要信息，将项目构思拆解成所需的文档。我们要求它创建
00:01:48四份文档，每份侧重应用的一个特定方面。最重要的是 PRD，
00:01:53它包含了项目需求和范围的信息。接着是 architecture.md，
00:01:57详细记录了数据格式、文件结构、API 以及所有架构细节。
00:02:02然后是 decision.md，记录了 Claude 在项目创建过程中所做的决策，
00:02:08作为未来的参考。最后也是最关键的是 feature.json，它以特定的
00:02:12JSON 格式包含所有功能。它以极高的 Token 效率记录了每个功能的细节，
00:02:17定义了功能完成的标准，并包含一个 “passes” 键来
00:02:22追踪哪些已实现，哪些尚未实现。既然大任务已经拆成了
00:02:27小部分，我们需要通过 Context 7 MCP 为它提供
00:02:31实现这些功能所需的工具文档。它拥有所有库和框架的文档，
00:02:36并会频繁更新，这样代理就能获取最新文档，弥补模型已知知识与
00:02:41实际当前更新之间的差距。设置 MCP 仅需几步。安装后，
00:02:46它就能使用 Context 7 的工具直接获取库信息。这让它能使用
00:02:50最新的文档，防止因依赖不匹配导致的代码错误，并获得更
00:02:55精准的实现。接下来，Hooks 是另一个常被低估的功能。Claude Code 中的 Hooks
00:03:00是在生命周期特定节点触发的 Shell 命令。有很多类型可以在
00:03:05特定时间触发，比如会话开始、使用工具前或使用后。但最关键的
00:03:11部分是为它们设置特定的退出码。退出码会告诉 Claude Code 该继续、
00:03:16拦截还是忽略某个动作。退出码 0 代表成功。退出码 2 代表拦截错误。所以
00:03:22每当 Claude 尝试做不该做的事时，触发退出码 2，它会收到报错信息
00:03:27并进行自我修正。除这两个以外的任何退出码都是非拦截的，仅在详细模式下显示，
00:03:32且执行会继续。退出码 2 非常关键，因为通过它，你可以控制
00:03:37代理的行为。如果你曾使用 Claude Code 进行过测试驱动开发，
00:03:41你可能注意到，如果代码没能通过测试，它往往倾向于去修改测试代码。为了防止
00:03:46这种情况，我们设置了一个在工具使用前触发的自定义 Hook。该 Hook 保护测试脚本
00:03:50不被修改。如果它尝试操作的路径是测试目录或包含 “test” 字样，
00:03:55它会显示报错信息，提示不允许修改测试文件夹，并返回
00:04:00退出码 2。有了这个 Hook，当我们让 Claude 运行测试而测试
00:04:05失败时，它尝试修改测试文件，但脚本拦截了它，并显示了拦截修改的
00:04:10提示。这阻止了 Claude 编辑它不该动的文件。如果你用过 MCP，
00:04:15你会发现它们会撑爆上下文窗口。而在处理大型项目时，
00:04:19连接的 MCP 数量会不断增加。于是所有 MCP 工具最终都堆在上下文窗口里，
00:04:25导致其臃肿不堪。针对这个问题，Claude Code 有一个实验性的 MCP CLI 模式来解决它。
00:04:31我们将实验性 MCP CLI 标志设为 true。设置完成后，所有原本显示在
00:04:36上下文中的 MCP 都消失了，MCP 工具不再占用任何上下文空间。接下来的问题是，
00:04:41如果工具不再存在于内存中，该如何访问它们？Claude Code 不再
00:04:45预先加载所有工具架构，而是使用 MCP CLI info 和 MCP CLI calls，通过 Bash
00:04:52运行所有连接的 MCP。开启标志后，当我们给出提示时，它不再
00:04:56直接调用 MCP 工具，而是通过 MCP CLI 工具将它们作为 Bash 命令运行，
00:05:03而不是 MCP 原生工具。这样，它只在需要时按需加载工具，防止上下文膨胀。此外，
00:05:08如果你喜欢我们的内容，请考虑点赞支持，因为这能帮我们创作更多
00:05:13此类内容并触达更多观众。在之前的视频中，我们强调过使用
00:05:18Git 将所有代理的工作纳入版本控制。如果代理实现得不正确，
00:05:23你也可以回滚。我们还做过一期视频，介绍如何使用 Git 让代理处理长周期
00:05:28任务，你可以在频道中查看。我们利用并行代理在不同的工作树上工作，
00:05:32这样它们就可以开发项目的所有功能，同时保持彼此隔离。
00:05:37这样我们以后就可以合并产出而不会产生干扰，因为多个代理在
00:05:41相同文件上工作会引发冲突。我们不推荐用分支，因为分支共享同一个
00:05:46工作目录，代理在切换分支时会有困难，但工作树（worktrees）则没有这个问题。
00:05:50于是我们给出了一个提示词，列出需要实现的多个功能，
00:05:55并指定每个代理应在独立的工作树上工作。它为每个工作树分配了一个
00:05:59代理，即使任务描述在某些地方有重叠，它们也能隔离地实现功能。
00:06:03当 Claude 在独立分支中正确实现所有功能后，我们让它合并产出，
00:06:08这样我们就得到了一个包含所有功能的统一工作目录。现在，严格模式（Strict Mode）对于
00:06:13将错误检查的负担转移给代理至关重要。无论你使用哪种语言，
00:06:18你都应该开启它，因为它能在构建时捕捉 Bug，而不是等用户在运行时遇到。
00:06:22由于我们的主要语言是 TypeScript，我们总是将项目中的 strict mode 设为 true。
00:06:26这会开启空值检查和隐式类型检查，强制执行严格类型和空检查，
00:06:31总而言之意味着更少的运行时错误。这对 AI 代理很重要，因为它们没有
00:06:36内置的捕捉运行时错误的方法。严格模式能最大限度降低运行时故障的概率，
00:06:41并确保由编译器处理这些问题。代理可以依赖终端中的错误日志
00:06:46来应用已知的修复方案。除了单纯依靠脚本测试项目外，
00:06:51还有一层测试值得添加：编写用户故事（User Stories）。
00:06:56这些故事描述了用户如何与系统交互，以便在应用建成后指导测试过程。
00:07:00实际上，我们在实现项目之前就会定义用户故事，因为这为实现
00:07:05设定了一个标准。通过提示词，Claude 在一个文件夹中编写了多个故事，
00:07:10包含了用户与系统交互的所有可能方式。每个故事
00:07:15都包含应用的特定方面、优先级以及供代理进行测试的验收标准。
00:07:21这些用户故事覆盖了所有可能的测试场景，包括理想情况和边缘情况。这些
00:07:26故事本质上是告诉代理如何与我们刚构建的系统进行交互。有了正确的
00:07:31交互指令，任何代理都可以将同样的原则应用到它正在构建的
00:07:35应用中，从而更好地满足用户预期。当故事文档化后，我们要求
00:07:40Claude 逐一实现它们，并提示它从每个故事中列出的最优路径开始，
00:07:45确保所有边缘情况都被覆盖。通过这种方式，实现过程中的缺憾更少，
00:07:50整体的用户满意度更高。现在，我们讨论的所有技巧都以
00:07:55现成模板的形式在 AI Labs Pro 中提供。对于那些还不了解的人来说，
00:08:00这是我们最近推出的社区，你可以在那里获得现成的模板、提示词、所有命令和技能，
00:08:05可以直接插入到你本视频或以往视频的项目中。如果你觉得我们的工作有价值
00:08:10并想支持本频道，这是最好的方式。链接在描述栏里。
00:08:14此外，我们需要尽可能利用并行化，因为这是代理加速
00:08:20工作流、实现那些无需互相等待的任务的方式。我们知道 Claude 会自动
00:08:25检测任务是可以并行还是必须串行，并自行决定，但
00:08:29我们手动创建代理也无妨。我们在之前的视频中也介绍过这些代理能力，
00:08:34讨论了如何利用代理让你的工作流更快，但这种速度是以增加 Token 消耗为代价的。
00:08:39尽管如此，并行化的尝试是值得的。有一次，
00:08:43我们正在研究 Opus 4.6 改进的影响，使用同一个模型，即便我们提供了来源，
00:08:49它仍不断幻觉出事实。它不停地写错误信息，我们不得不反复纠正它。
00:08:54这让研究感觉毫无意义，因为我们必须自己不断修复。为了防止
00:08:58这种情况再次发生，我们使用了并行代理。我们设置了一个研究任务，
00:09:03想要对比 Kimi K 2.5 和 Claude 的代理集群能力。
00:09:09我们使用了两个代理：一个负责做研究，另一个负责事实核查。核心
00:09:14思想是让两个代理相互沟通，以确保调查结果准确，这样我们
00:09:19就不必亲力亲为了。在这个设定中，一个代理执行任务，另一个进行批判性
00:09:24分析，形成一种对抗性的工作模式。研究代理首先开始，
00:09:28而核查代理被锁定，直到研究代理产出初稿。一旦初稿完成，
00:09:33核查代理就开始验证。它立即发现了研究代理列出的数据中的
00:09:38许多不准确之处，我们不再需要手动去抓这些错误了。两个代理持续
00:09:43沟通，保持严密的事实核查过程。一个代理专门负责
00:09:47指出另一个代理的错误信息。许多任务都可以采用这种对抗性架构，
00:09:52不仅是研究，开发工作也可以——由一个代理实现功能，
00:09:57另一个根据计划评审该实现。正如 Claude Code 的创始人所说，
00:10:02如果代理有某种方式验证自己的工作，它的表现会更好。这里的核心理念是给
00:10:07代理一双“眼睛”，即检查实现的功能是否正确并符合
00:10:12预期的能力。因为这些代理是基于终端的，它们无法识别运行时
00:10:17发生的问题，尤其是客户端的问题。我们使用了多种方式来验证代理的工作。
00:10:21第一种是 Claude Chrome 扩展，它提供了以浏览器为中心的工具，如 DOM 捕捉、
00:10:26控制台日志检查等。另一个工具是 Puppeteer MCP。这个工具很有用，因为它在
00:10:31一个独立的浏览器中运行，不会包含你现有的会话，这一点与 Claude 的 Chrome 扩展不同。
00:10:36它是隔离的，不会干扰你当前的任何会话，因此多了一层
00:10:41隐私保护。但我们首选的方案是 Vercel 的 Agent Browser。这虽然不是 MCP，但它是
00:10:46一个赋予代理浏览器测试能力的 CLI 工具。它拥有导航、截屏等工具。
00:10:51与其他工具不同，它不仅仅基于截图进行导航。相反，它利用
00:10:56无障碍树（Accessibility Tree），其中每个元素都有唯一引用。这能将数千个 Token 的
00:11:01完整 DOM 压缩到约 200 至 400 个 Token，所以它的上下文效率极高。这正是
00:11:07Claude Chrome 扩展存在的主要问题，而 Agent Browser 解决了它。扩展会将整个 DOM
00:11:12加载到上下文窗口并迅速耗尽它。我们还在 claude.md 中添加了指令，让 Claude
00:11:17在退回到基于 MCP 的测试之前，优先依赖 Agent Browser。因此 Claude 将 Agent Browser
00:11:23作为主要的验证手段。但还有另一个角度。测试固然重要，但还有一种
00:11:28减少错误的方法不涉及测试或代码审查。我们让 Claude 预测尚未发生的事情。
00:11:33我们要求 Claude 检查代码实现并识别应用可能失败的区域。
00:11:38这之所以有效，是因为我们给了 Claude 一个机会，通过模式匹配其他应用中
00:11:43已存在的失败案例来预测潜在问题，即便我们自己还没在测试中
00:11:47遇到这些问题。这促使 Claude 从一个与以往不同的角度审视代码。
00:11:52当我们让它这么做时，它识别出了即便通过了多层测试流程仍存在的关键缺陷，
00:11:57并发现了 18 个可能在生产环境中造成危害的问题。而我们的测试
00:12:01流程并没有捕捉到它们。只有当我们推动 Claude 从另一个角度审视
00:12:06项目时，它们才被发现。本期视频就到这里。如果你想支持本频道
00:12:10并帮助我们继续制作此类视频，可以点击下方的超级感谢按钮。
00:12:15一如既往，感谢观看，我们下期再见。