本课概览
大家可以关注我的公众号🌟（或联系：lanyijianke1992），后台私信"cc资源包"，领取我为大家整理的课外资源💼，持续更新中✅
系统化的调试方法
到目前为止，我们已经学会了如何快速掌握代码库并实现功能，以构建稍微更强大的体验。现在让我们考虑一下，距离我们上次使用这个应用程序已经有一段时间了，我们回来后想要重新开始使用它。
让我们跳回到我们的应用程序，询问第5课的详细内容。我们可能期望看到一个包含相关信息的响应，但现在出现了问题。
虽然直接复制这个错误、粘贴到Claude中、截个图并希望它能解决问题可能很诱人，但我们要采用一种稍微不同的方法。我们不会让Claude进行一些毫无头绪的搜索，而是要采取更加系统化的方法。
我们知道应用程序出了问题，但我们也知道这里没有太多的测试来以编程方式验证这种情况。因此，我们要做的是输入一个提示，不仅提到错误是什么，还指定我们需要在哪里编写测试。
回到代码库，我们发现错误可能来源于几个关键的Python模块。首先是AI生成器模块，它负责处理与Anthropic API的交互逻辑，提示设计或相关逻辑实现中可能存在问题。
其次是RAG系统模块，作为检索增强生成的核心协调器，在这里也可能出现异常。此外，搜索工具模块定义了底层工具的具体实现，同样可能是潜在的问题源头。
这种测试驱动的调试方法具有显著优势，它不仅能为代码库的后续扩展建立稳固的基础，更重要的是能够帮助我们深入理解系统故障的根本原因，从而实现精准的问题定位和解决。
现在打开Claude Code并输入相应的提示指令。考虑到任务的复杂性，我们需要激活Claude的深度思考模式，这样它会分配更多的token资源用于思维分析过程。同时我们可以实时观察整个处理过程，必要时可以随时中断并调整。
我们将确保计划模式开启，因为首先，我们希望在Claude开始编写测试之前，确保它理解需要做什么，我们可以批准这个过程。
当我们开始阅读必要的文件时，我们将看到Claude的思考过程。我们不仅会看到我们正在阅读的文件，还会看到它需要检查什么以及应该做什么。
让我们看看Claude的计划显示了什么。看起来存在某种配置问题，可能是一些复杂的工具调用失败点，以及组件之间有限的错误传播。因此，错误可能只是在某个地方被捕获了。
然后它将基于这些文件提出测试结构，这对我们来说看起来不错。使用pytest框架，并模拟ChromaDB中需要的任何内容，以使一些单元测试和集成测试启动并运行。
你可以看到现在它开始为我的测试创建一个文件夹，我将在其中编写这些测试。这是一个很好的开始。我们将确保也通过UV添加任何必要的依赖项。
接下来安装依赖项，确保pytest能够按预期工作。我们还会在这个过程中观察Claude的思考部分，确保它在编写这些特定测试时遵循正确的方向。
我们可以开始探索为我们编写的代码。在这里可以看到核心搜索工具的测试，包括我们需要制作的fixtures和mocks。这确实是一个很好的开始。
现在我们已经创建了这些测试，让我们使用UV运行它们。我们需要确保所有正确的依赖项都已安装，以便测试能够按预期运行。
从Claude的发现来看，问题似乎出现在max_results参数上，也就是我们在执行向量搜索时返回的块数。让我们检查一下max_results的实际值是什么。
这证实了我们遇到的问题。由于某种原因，这个值恰好是零。一旦我们修改这个值，不仅我们的测试应该按预期工作，而且返回的结果也应该是完整的。
我们可以通过查看并确保我们得到预期的5个结果来验证这一点🕐️。现在Claude Code正在总结整个过程，它可以提供其发现的全面摘要。我可以等着看完整的总结，或者如果我现在感觉良好，也可以随时停止Claude的工作。但我想看看它会给我什么样的总结。
验证修复效果
它已经完成了调试工作，找到了关键问题，创建了一些测试以及相应的基础设施，以便我们能够持续运行测试。让我们看看这是否按预期工作。
回到浏览器，我将开始一个新对话，让我们再次询问同样的问题，看看我们是否得到预期的结果。现在不再是查询失败，我们应该能够看到关于课程的信息，这正是我们在这里看到的情况。
因此，我们不仅成功修复了bug，还为自己建立了强大的基础设施来持续运行应用程序。这确保了当我们进行新的更改时，能够及时发现问题所在，而不是在不知不觉中破坏功能。
重构工具调用机制
现在我们已经让应用程序正常工作了，让我们来讨论一个我想在代码库中进行的小重构。首先清除当前内容并重新开始新功能的开发。
在我们的AI生成器模块中，我们当前指定每个查询最多只需要一次搜索。虽然这种设计对于相对简单的搜索能够产生预期的行为，但当我们想要开始执行更复杂的查询时，比如比较不同的课程或者对比它们的大纲，我们就需要不止一个工具调用了。
因此，我们需要某种能够迭代地遍历所有必要工具的环境，或者说是一个能够递归解决问题的机制。
如果你熟悉这个代码和生态系统，我们可以看看当前的类实现。这是一个相对简单的方式，直接使用我们的SDK与Anthropic模型对话，设置基本参数并生成响应。
但是我们可以看到，当我们构建系统提示、确定必要的消息和任何工具时，缺少迭代机制。换句话说，我们无法进行来回的工具累积和多轮对话，也无法在单个查询中使用多个工具。
规划重构方案
让我们来重构这个部分。我这里有一个相当长的提示，所以我准备创建一个新的markdown文件，称之为backend_tool_refactor.md。
在这个文件中，我想详细描述我的提示内容。我将要求Claude重构后端AI生成器模块，以支持两次调用的单独轮次。我会明确说明当前的行为是什么样的，以及我期望的行为应该是怎样的。
虽然这些详细信息可能不是完全必需的，但正如我们在之前的经验中看到的，给Claude提供尽可能多的信息通常是有帮助的，特别是当任务稍微复杂一些的时候。
我们还会给Claude提供一个示例流程，比如搜索讨论与另一门课程相同主题的课程，这样可以让Claude更好地理解需要做什么。请注意，这个示例中涉及几个不同的工具需要使用。
正如预期的那样，我们会给Claude一些具体要求，同时也会给出一些注意事项，以确保我们采用正确的方法。我们要确保编写的测试是验证外部行为的，而不是过分关注内部状态的细节。
我们还希望Claude做的是找出几个不同的重构方案，但不要立即实现任何代码，而是派遣两个子代理来头脑风暴各种潜在选项。
在这种情况下，我不确定最优的重构方案是什么，所以我实际上不会让Claude Code只选择一个方案，而是给它机会并行地探索多个选项。
让我们使用这个特定的提示，我会关闭自动接受功能，以确保在进行过程中我可以确认所需要的更改。
我们应该期待看到通过task工具派遣的两个并行子代理。当我们看到这些代理被派遣时，我们将开始看到解决这个问题的两个不同计划。然后由我们来决定实施哪一个方案。
我们可以看到这两个子代理都在并行操作（Task），正在读取文件并探索这个重构问题的两种不同解决方法。
看起来它们返回了一些关于如何最好地解决这个问题的建议。一种方法是迭代式的，另一种则更加全面。我们可以看到Claude实际上为我们提供了选择，要么选择选项B以获得更好的长期可维护性，要么选择选项A以获得更安全的实现。
如果我向上滚动查看更多内容，可以获得一些关于它试图实现什么的详细信息。一个选项支持工具的迭代处理，另一个则用于实现稍微复杂的多轮逻辑，其中包含该过程的不同辅助方法。
从第一眼看，方法A似乎更简单一些，所以让我们从这个开始。我要选择方法A，同时我现在也要启用计划模式，以确保我有一个全面的计划，并且可以在进行想要的更改之前进行确认。
让我们实施方法A并获得更详细的计划来验证这正是我们想要做的。我们知道需要修改我们调用这些工具的方式，但让我们确保这一切都在正确的地方完成，然后Claude Code为我们编写解决方案。
实施选定方案
现在让我们看看实施过程中正在做什么。我们将为最大轮数更新方法签名，更新系统提示，最关键的是在handle tool execution中完成核心的重构工作。
如果按预期完成，我们应该能看到用户查询的处理流程：首先是多个工具被调用，然后生成最终响应。这个重构不应该修改其他任何内容，并且应该能为我们解决问题。
我们可以看到这是向后兼容的，我们没有更改内部RAG系统或任何API端点。所以让我们继续进行，看看这是否能为我们解决问题。
当我们观察正在实施的内容时，可以看到对现有方法的更改。最重要的是，我们可以看到正在更新测试并运行测试来验证实施是否正确工作。
我可以在Claude Code内部的终端中完成所有这些操作，而不需要在上下文之间切换到浏览器或者要求其他人来进行测试。
验证重构效果
我们将在这个过程中看到系统提示的更新，确保测试符合预期。接下来我们会添加一个测试，以确保顺序工具调用能够按预期工作。让我们运行测试，确保它们能够按预期通过。
让我们在浏览器中验证这个重构是否能够实现我们的目标。首先询问课程的详细信息。在这里我们可以看到，我们不仅获得了这些信息，而且还获得了相关的标题。
按照预期，我们获得了关于这个课程的信息，以及涉及的一些部分和主题。现在让我们尝试一些稍微复杂的查询。
这里的标题显示如此特别的原因在于，我们不会仅通过一个工具调用就获得这些结果。第一个工具调用只给我们课程的大纲，第二个工具调用才给我们那个特定课程的详细信息，在我们的例子中正是标题。
现在让我们询问是否有其他课程涵盖与MCP课程第5课相同的主题。为了实现这一点🕐️，我们需要进行多个工具调用来获取关于这个特定MCP课程和大纲的信息，然后获取其他课程及其大纲的信息，以便检查是否有任何重叠。
不幸的是，看起来没有其他课程涵盖构建MCP客户端的内容，但这个结果确实看起来是准确的。
小结与预告
在这节课中，我们看到了如何使用Claude Code不仅仅是修复bug，更重要的是在整个过程中编写测试。我们为自己建立了坚实的基础，这样可以继续在此之上进行编码工作。同时，我们还进行了一个出色的重构，使系统能够适当地处理更复杂的查询并提供准确的答案。
在下一课中，我们将通过运行多个Claude Code会话来提高我们的生产力，并确保我们在并行工作时没有重叠或覆盖的问题。我们将使用Git工作树来实现这一点🕐️。我们下节课见！
课代表学习笔记
📖 本节课核心内容
🎯 重点掌握
测试驱动调试策略：优先建立测试基础设施而非直接修复问题，通过编写针对性测试用例来验证各个组件的工作状态，建立可持续的质量保证体系，为后续开发奠定坚实基础。
深度思考模式应用：在处理复杂任务时激活Claude的深度思考模式，分配更多token资源用于思维分析，同时开启计划模式确保在实施前制定完整方案并获得确认。
向后兼容重构设计：在重构工具调用机制时确保不破坏现有功能，通过迭代式的方法扩展系统能力，支持多轮工具调用而不影响单次调用的现有逻辑。
⚠️ 难点解析
测试覆盖范围的确定：容易忽略关键组件的测试覆盖，或者过度关注内部实现细节而忽略外部行为验证。
解决思路：重点关注核心模块（AI生成器、RAG系统、搜索工具）的功能测试，使用pytest框架和适当的mock机制，确保测试验证的是实际业务行为而非内部状态。
配置参数的调试定位：在复杂系统中配置错误往往隐藏很深，通过表面现象很难直接定位到根本原因。
解决思路：通过系统性的测试运行来暴露配置问题，重点检查关键参数（如max_results）的实际值是否符合预期，避免假设配置的正确性。
重构方案的选择权衡：面对多种重构方案时容易陷入选择困难，不知道如何平衡复杂性和功能性。
解决思路：使用并行子代理探索多个方案，根据长期可维护性和实施风险来评估，优先选择向后兼容且实施相对安全的方案。
💡 实践要点
- 启用深度思考模式处理复杂调试任务，通过更多token分配获得更全面的分析
- 使用pytest框架建立标准化测试体系，配合适当的fixtures和mocks确保测试环境的一致性
- 重点验证外部行为而非内部状态，确保测试用例的有效性和长期价值
- 通过UV工具管理依赖项，确保测试环境的完整性和可重现性
- 在重构前使用并行子代理探索多种方案，避免单一思路的局限性
- 实施测试-修复-验证的闭环流程，确保问题得到彻底解决且不会引入新问题
大家可以关注我的公众号🌟（或联系：lanyijianke1992），后台私信"cc资源包"，领取我为大家整理的课外资源💼，持续更新中✅
我是蓝衣剑客，谢谢你看我的文章。
这节课将带你深入了解Claude Code的系统化调试方法，学习如何通过测试驱动的开发方式来修复复杂的
