正在学习
14.1 概述：为什么食谱很重要
错误：循环重新赋值了 total，而不是累加。
def calculate_sum(numbers):
total = 0
for num in numbers:
total += num
return total
print(calculate_sum([1, 2, 3])) # 输出：6
说明：Claude 不仅能准确定位逻辑错误的具体行数，还能简洁地解释原因——这是一种常见的调试提示模式，有助于培养代码审查自动化的直觉。
澄清表：测试与调试提示策略
| 目标 | 提示结构 | 结果 |
|---|---|---|
| 单元测试 | "使用 [框架] 编写完整可运行的测试" | 生成有效的测试文件 |
| 集成测试 | "包含 API 调用、设置和拆卸步骤" | 添加真实的工作流覆盖 |
| 错误诊断 | "分析此回溯并解释原因" | 返回原因 + 修复后的代码 |
| 错误复现 | "模拟此问题并展示如何复现" | 提供可复现的步骤 |
| 修复验证 | "验证修正后的代码通过所有测试" | 添加确认消息 |
| 性能问题 | "识别运行缓慢的部分并提出优化建议" | 提供可衡量的代码重构 |
| CI 集成 | "生成用于测试的 GitHub Actions 工作流" | 生成自动化就绪的流水线 |
Claude Code 不仅仅是代码生成器——它是维护代码质量的智能伙伴。结构良好的测试和调试提示能让 Claude 像 QA 工程师一样进行推理，捕捉逻辑错误并确保每个输出都可靠且可复现。
关键要点：提示的具体性等同于可靠性。通过指定框架、错误上下文和覆盖标准，你可以让 Claude 的测试输出与资深工程师的输出别无二致。
在下一节中，我们将从本地验证扩展到 CI/CD 和 DevOps 集成提示，展示 Claude 如何自动生成流水线、测试运行器和部署配置，以实现完整的开发自动化。
练习题
给定 calculate_sum 函数中的主要错误是什么？
A. 该函数返回
None 而不是总和。B. 循环重新赋值
total 而不是累加。C. 该函数不处理空列表。
D. 该函数使用了不正确的变量名。
calculate_sum 函数的修正版本应该使用 total = total + num 而不是 total += num，这样更清晰。
在循环中替换 total = num 的正确代码行是 ___。
解释为什么原始的 calculate_sum 函数无法计算出正确的总和。
以下哪些是修复 calculate_sum 函数的有效方法？（选择所有适用的）
A. 将
total = num 替换为 total += numB. 将
total 初始化为 1 而不是 0C. 将
total = num 替换为 total = total + numD. 在循环之前添加空列表的检查
E. 使用
while 循环代替 for 循环如果将循环替换为累积和的递归实现，calculate_sum 函数将能正确工作。
在澄清表中用于单元测试的提示结构是什么？
A. "包含 API 调用、设置和拆卸步骤"
B. "使用 [framework] 编写完整可运行的测试"
C. "分析此回溯并解释原因"
D. "模拟此问题并展示如何复现它"
单元测试提示的结果是一个 ___。
在单元测试提示中指定测试框架为什么很重要？
澄清表中用于集成测试的提示结构是什么？
A. "使用 [framework] 编写完整可运行的测试"
B. "包含 API 调用、设置和拆卸步骤"
C. "分析此回溯信息并解释其原因"
D. "验证修正后的代码通过所有测试"
集成测试提示应避免包含 API 调用，以保持测试简洁。
集成测试中设置和拆除步骤的目的是什么？
澄清表中用于错误诊断的提示结构是哪一个？
A. "Write complete runnable tests using [framework]"
B. "Include API calls, setup, and teardown steps"
C. "Analyze this traceback and explain the cause"
D. "Simulate this issue and show how to replicate it"
错误诊断提示的结果包括___和修复后的代码。
为什么在错误诊断提示中提供修复后的代码很重要？
澄清表中用于错误复现的提示结构是什么？
A. "使用 [framework] 编写完整可运行的测试"
B. "包含 API 调用、设置和拆卸步骤"
C. "分析此回溯并解释原因"
D. "模拟此问题并展示如何复现"
错误复现提示应仅包含问题的高级描述，而非具体步骤。
为什么可复现步骤在缺陷复现提示中很重要？
修复验证在澄清表中使用了哪种提示结构？
A. "使用 [framework] 编写完整可运行的测试"
B. "包含 API 调用、初始化和拆解步骤"
C. "验证修正后的代码通过所有测试"
D. "为测试生成 GitHub Actions 工作流"
修复验证提示的结果包括一条 ___ 消息，以确认修复有效。
为什么在修复验证提示中运行测试很重要？
在澄清表中，用于性能问题的提示结构是什么？
A. "使用 [framework] 编写完整可运行的测试"
B. "包含 API 调用、设置和拆卸步骤"
C. "识别缓慢部分并建议优化"
D. "为测试生成 GitHub Actions 工作流"
性能问题提示应仅关注理论优化，而不考虑衡量其影响。
为什么可衡量的重构在性能问题提示中很重要？
在澄清表中，哪种提示结构用于 CI 集成？
A. "Write complete runnable tests using [framework]"
B. "Include API calls, setup, and teardown steps"
C. "Identify slow parts and suggest optimizations"
D. "Generate GitHub Actions workflow for tests"
CI集成提示的结果是一个用于测试的___管道。
为什么自动化在 CI 集成提示中很重要？
修复 calculate_sum 函数的问题考查了哪些知识点？（可多选）
A. Bug：循环重新赋值 total 而不是累加 - 示例代码
B. 澄清表：测试和调试提示策略 - 单元测试
C. 澄清表：测试和调试提示策略 - 错误诊断
D. 澄清表：测试和调试提示策略 - 修复验证
E. 关键要点：提示的具体性等于可靠性
提示的具体性如何提高测试和调试提示的可靠性？请举例说明。
将测试策略和错误修复的知识相结合，有助于提高整合概念和解决实际问题的能力。
在调试以下代码片段时，澄清表中的哪种测试策略最适合用于识别错误输出的根本原因？
def calculate_sum(numbers):
total = 0
for num in numbers:
total = num # 错误：重新赋值而不是累加
return total
A. 单元测试
B. 集成测试
C. 错误诊断
D. 性能问题
澄清表中的哪些提示策略有助于确保 calculate_sum() 的修正版本产生可靠的输出？（选择所有适用的）
A. 单元测试
B. 修复验证
C. CI 集成
D. 性能问题
关键要点"提示的特异性等于可靠性"意味着在调试提示中指定错误上下文将始终在单次迭代中产生代码的修复版本。
要在 calculate_sum() 中复现这个 bug，___ 策略将涉及创建类似 calculate_sum([1, 2, 3]) 的测试用例，并将输出与预期结果 6 进行比较。
登录后解锁笔记、知识点解析、AI 问答
立即登录