构建提示很快结束，手却还停在键盘上。此时最容易做的事，是立刻打开下一个需求；也可以先看一眼刚才改动的状态图，问一句：这次变化是否让问题更容易理解了？
工具缩短等待当然是好事。可“反馈更快”和“设计更清楚”是两条不同的线。前者能帮我们多试几次，后者决定每一次试验是否朝着正确方向。
不把旧等待美化成好习惯
过去编译慢，并不自动意味着代码更认真。有人利用等待讨论边界，有人被打断后再也接不上思路。今天构建快，也不意味着工程师必然浮躁。决定节奏的，仍然是团队如何安排工作。
因此，比“工具让人失去耐心”更值得问的是：一次改动完成后，我们有没有留下理解它的时间？失败分支有没有看过？新引入的缓存由谁清理？当生成式工具一口气给出多个文件时，审阅是否跟得上产出？
内图把机器反馈与人的复核分成两条线。上面一条追求及时，下面一条需要停顿。两者并行，才不会让“能运行”过早变成“可以交付”。
给一次修改留三行笔记
我更愿意把节省下来的时间用于写短说明：这次要解决什么现象，靠哪一个假设工作，遇到什么条件应该撤回。三行字未必写得漂亮，却能让后来的人继续判断。
例如，把一个流式卡片改成分阶段显示之后，可以记录：“先展示已确认字段；未闭合数据不进入提交态；服务端中断时保留可复制文本。”这比记下一句“体验显著提升”更有用。下一次遇到故障，笔记能直接指向行为，而不是一句难以反驳的赞美。
收笔之前，再读一遍
工笔画的层次来自多次观看：远处看整体，近处看接缝。代码也适合这样检查。第一次确认运行路径，第二次只看失败与取消，第三次尝试把它解释给不在场的同事。
不需要为每次修改举行仪式，更不需要故意拖慢工具。只是当反馈已经足够快时，我们终于有条件把一点时间用在作品本身。
工具的快，是一次把判断做细的机会。省下来的时间，至少分一些给设计，也留一点给下一次读代码的人。
