在 KS3 计算机课里，调试并不是一项独立于问中学之外的技术技能——它恰恰是问中学最清晰的范例：一门就程序行为提出越来越具体问题的学问，而不是随手乱改代码、指望它能跑起来。 这是问中学在计算机学科的具体体现，无论这段「代码」是一段 Python 脚本、一个 Scratch 项目，还是一条返回结果不对的电子表格公式，都同样适用。
为什么调试是这套理论最纯粹的形式
大多数学科都把「问出一个好问题」和「得到正确结果」之间的联系藏起来了。计算机不会——一段程序要么如你所愿，要么不如你所愿，而这两者之间的落差，只要你问对了问题去找它，永远能追溯到一个具体的点上。一个随手改动代码、每改一次就重新运行看看是否「行了」的学习者，并不是在调试——他是在瞎猜，而侥幸猜对了，对下一次也没有任何帮助。
把提问阶梯套用到一个出错的程序上
以一个常见的 KS3 场景为例：一段程序能跑，但输出结果不对，或者报错了。提问阶梯给出了五级台阶：
- 定位型 ——「这条报错信息到底在说什么？」这是最低的一级，也是最常被跳过的一级：很多学习者一看到红色文字就不往下读了，而这条信息往往已经精确指出了具体是哪一行、哪种类型的问题。
- 澄清型 ——「这行代码本来应该做什么？」不是它实际做了什么——而是它本该做什么。这个问题暴露的是意图和实现之间的落差，而这正是大多数 bug 真正藏身的地方。
- 诊断型 ——「程序的实际行为是从哪里开始偏离我预期的？」这是 KS3 阶段最有用的单个调试问题——它能把「跑不通」这种笼统的说法，缩小到一个具体、值得深入调查的点，而不是整段程序。
- 生成型 ——「如果我把这一部分单独拿出来测试，会发生什么？」这是通过控制变量来拓展调查——把一个可疑的函数单独拿出来，用已知的输入运行一下，看它单独运作时是否符合预期。
- 迁移反思型 ——「我以前见过这种 bug 吗？」这是在识别一种模式——比如差一错误（off-by-one）、变量在重置前被重复使用、一个本该是
and却写成了or的条件——这些错误会在不同项目里反复出现，直到它被识别成一个类别，而不是一次性事故。
一览表
| 提问阶梯层级 | 调试示例问题 |
|---|---|
| 定位型 | 这条报错信息到底在说什么？ |
| 澄清型 | 这行代码本来应该做什么？ |
| 诊断型 | 实际行为是从哪里开始偏离预期的？ |
| 生成型 | 把这部分单独拿出来测试会怎样？ |
| 迁移反思型 | 我以前见过这种 bug 吗？ |
计算机学科的答案陷阱：「直接帮我修好」
计算机学科里的答案陷阱有一种非常眼熟的现代形态：把跑不通的代码粘贴进 AI 工具，叫它「帮我修好」，然后把修好的版本原样粘贴回去，也不去看到底改了什么。代码现在也许能跑了。但完全没弄明白它为什么之前跑不通，这意味着同一类错误——同一个差一错误、同一个被误用的变量——会在下一个项目里再次发生，而学习者到时候只会再次伸手用同一句「帮我修好」的提示词，而不是认出这是一个模式。
这正是为什么把「调试是一门提问的学问」明确说出来才有必要，而不能想当然地以为它不言自明。AI 时代的默认做法是直接跳到一个能用的答案；而计算机恰恰是这种默认做法对真正技能养成造成最明显伤害的学科，因为这门学科的技能，本身就是找出偏离点这个过程。
「问、试、再问」套用到代码上
问、试、再问循环几乎可以原样套用到调试上：
- 问一个具体的问题：「这个循环为什么可能多跑了一次？」——而不是「我的代码为什么跑不通」。
- 试根据答案去尝试修复，并且真正运行一遍。
- 再问一个根据结果更犀利的追问：如果修复只解决了一半问题，就问「循环次数现在对了，但输出还是不对——还有什么可能造成这个问题？」
每一轮循环都在收窄搜索范围。一次性把整个文件粘贴进去、再把出来的东西原样抄回来，跳过了这三个步骤，得到的正是计算机版答案陷阱最纯粹的形式。
为什么「我以前见过这个吗」在这门学科里格外重要
计算机 bug 出奇地容易重复出现——同样那几类错误（比较运算符用错、变量作用域、差一循环、忘记更新计数器）占据了 KS3 阶段错误里相当大的一部分。这让迁移反思型问题在这门学科里格外有价值：一个已经问过三四次「我以前见过这种 bug 吗」的学习者，会在正式学到这个概念的名字之前，就已经能一眼认出这种模式。这也和把算法画出来这个更广泛的理念相关联——一步一步地把程序实际在做的事情可视化出来，这往往正是生成型层级「单独拿出来测试」这个问题最终需要落实的东西。另可参见五个 KS3 计算机核心概念，了解更广的课纲背景。
关于 Professor Turing 的说明
在 aitutors.me，计算机目前还不像数学、英语或理科那样有可预约的真人导师课——但上面这套提问纪律，无论学习者是在用哪种资源、哪位老师或哪个 AI 工具来调试，都同样适用。提问阶梯不需要有导师在场；它需要的是学习者自己对自己提出这些问题。
常见问题
计算机学科里的答案陷阱具体是什么样的？
代码跑不通时直接叫 AI 工具「帮我修好」，而不先问一问这段代码本来该做什么、它的实际行为究竟是从哪里开始偏离预期的。修复也许有效，但学习者并没有调试自己的理解，所以同一类 bug 下次还会再出现。
KS3 阶段最有用的单个调试问题是什么？
「程序的实际行为是从哪里开始偏离我预期的？」这是诊断型问题，它能把一句笼统的「跑不通」缩小到一个具体、值得深入调查的行或步骤。
调试真的更多是关于提问，而不是修代码本身吗？
是的——一旦真正找到偏离发生的那个点，修复往往是最简单的部分。大部分「调试」得不顺利的时间，其实都花在了随手乱改代码上，而不是先问出一个足够具体的问题。