一个 Bug 改了一上午，我才明白：AI 编程最耗人的，是注意力被切碎

AI 编程真正耗人的，往往不是写需求，也不是等 AI开发工具出结果，而是注意力被切碎之后的反复调试。前几天我被一个页面跳转 Bug 来回折腾了整整一个上午，最后才发现，问题根本不在跳转逻辑，而在字段语义：服务端给的是任务类型名称，前端却把任务 id 当成了任务类型 id。

不是等结果累，是等结果时切走更累

我长期用 Trae，国内版、国际版都会用，平时也习惯用 solo 模式，再配合 spec 规范推进开发。按理说，这已经是比较顺手的一套方式了。真正的问题，出在我另一个习惯上：总喜欢同时开几个项目。一个窗口在跑，一个窗口在生成，一个窗口在看结果，谁卡住了，我就切去另一个。

看起来像并行，实际上是在不断重启自己。

Trae 官方介绍 SOLO 时，强调的是把 IDE、终端、浏览器、文档和工具统一到同一个连续工作流里。工具在帮我攒上下文，我自己却在不停拆上下文。多开项目看起来像并行，实际是在不断把自己的注意力打碎。

Gloria Mark 团队关于数字分心的研究里提到，人如今在单一屏幕上的平均注意时长大约只有 47 秒，而一次打断之后，回到原来的任务可能需要长达 25 分钟。以前我总觉得“等结果的时候顺便做别的”很划算，现在越来越明白，那不是节省时间，而是在预支后面的恢复力。

这个 Bug 卡住的，不是跳转逻辑，而是字段语义

最折磨我的，不是一个复杂的大系统问题，而是一个看上去再普通不过的页面跳转逻辑。

需求非常清楚：必须根据对应的任务类型进行页面跳转。逻辑并不绕，分支也不多。我一开始真以为是条件判断没写对，于是让 AI 一版一版改。它也确实一直在改，改得还挺像那么回事，可就是改不到点上。

后来我只能自己去扒代码，才看见真正的问题：

服务端只提供了任务类型名称，没有提供任务类型 id；可前端这边却默认“任务 id 就等于任务类型 id”。

一旦这个前提错了，后面所有修改都会失焦。你以为自己在处理一个“跳转逻辑问题”，实际上是在处理一个“字段语义错位问题”。AI 最擅长放大确定性，也最容易在错误前提里高效绕圈。

写得再清楚的 spec，也救不了错误的前提

这次经历让我真正接受了一件事：spec 很重要，但 spec 不是免死金牌。

spec 能解决的是“目标描述是不是清楚”，比如页面应该怎么跳、输入输出是什么、验收标准是什么。但 spec 解决不了“系统事实是不是已经对齐”，比如这个字段到底代表什么、哪个层负责转换、前后端对同一个词是不是说的是同一件事。

所以我现在越来越认同一句话：写得再清楚的 spec，也救不了错误的前提。

很多时候，我们把问题归咎于提示词不够详细。可真正的问题，往往不是提示词长度，而是你交给 AI 的事实本身就不对。你以为自己在给它任务，它其实只是接过了一个错误坐标系。

古语有言“名不正则言不顺，言不顺则事不成”。放到开发里，这句话特别贴切。任务类型名称、任务类型 id、任务 id，如果这三个概念没有先被正名，后面的协作、联调、修改只会越来越乱。

AI 最适合放大确定性，不适合替你核对事实

我现在对 AI 编程最大的感受是，它最适合放大那些已经清楚的东西，但并不擅长替你重新核对事实。

2025 年 METR 针对经验丰富开源开发者做过随机对照研究，结果很反直觉：在他们测量的真实任务里，使用当时 AI 工具的一组平均反而多花了 19% 时间。我不觉得这说明 AI 没价值，反而觉得它提醒了一个更真实的问题：真正吃时间的，从来不是打字，而是定位、验证、回滚和重建心智模型。

2026 年关于 Troubleshooting 的研究也指出，调 Bug 的过程本质上是认知问题求解，需要持续占用注意力、工作记忆和系统建模能力。说得再直白一点，真正累的从来不是手，而是脑子里那张系统地图被反复推翻之后，还要再一块一块拼回来。真正拖垮人的，不是等待 30 秒，而是一次次重建脑中的系统地图。

所以，工具越强，人越不能把“事实核查”外包出去。提示词、spec、agent 都很重要，但它们的前提永远是：你得先知道系统现在到底在说什么。

我后来给自己的 4 条调 Bug 规则

第一，等待期只做同一项目里的低切换工作。

比如整理字段、补一条复现路径、写验收说明、列待确认项。不要一等结果就切去另一个项目，因为你以为自己在“顺手干点别的”，其实是在给自己增加一次心智恢复成本。

第二，调 Bug 之前先写“事实表”。

现象是什么，预期是什么，接口真实返回了什么，每个字段的真实语义是什么，哪一层负责转换。只要这几条还没写清，我就尽量不让 AI 直接开始改。

第三，如果连续两轮还在原地绕，就先停下来自己扒代码。

不是因为人一定比 AI 强，而是因为到了这个阶段，问题往往已经不是生成能力，而是前提识别能力。你必须先把事实核对出来，再把核对后的事实重新交给 AI。

第四，把字段语义和不变量写进 spec。

spec 不只是任务清单，也应该写明什么不能被误解。比如“页面跳转依据是任务类型名称，不是任务 id”，这种话就应该直接写进 spec 和验收条件里。

这次一个 Bug 改了一上午，我反而想明白了一件事：AI 编程真正拖垮人的，不是代码量，也不是工具速度，而是注意力被切碎之后，那种反复验证、反复推翻、反复重建的消耗。

工具越来越强，人就更不能把系统理解外包出去。