等待 AI Code Assistants 时该做什么
I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content of the article (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you’ve requested.
AI 辅助编码：将等待时间转化为高效的微休息
AI 编码助手在开发工作中创造了一种奇特的新节奏。你发出提示，然后等待——三十秒、两分钟，有时甚至十分钟。工具帮你完成工作，你却不必亲自动手，但在此期间你会做什么？
两个常见陷阱
| 陷阱 | 会发生什么 | 为什么不好 |
|---|---|---|
| 上下文切换 | 检查 Slack，打开 Twitter，浏览邮件。 | 当助手完成时，你已经进入了全新的思维上下文，失去了原本正在构建的内容的线索。 |
| 盯着加载动画 | 焦虑地盯着待输出的结果，完全没有恢复。 | 你浪费了宝贵的时间并增加了压力。 |
这两种做法都浪费了本可以用于扩散性思考的时间——大脑在无焦点的期间进行的无意识处理（Baird et al.，2012）。
为什么 AI 等待不同
- 不确定的时长 – 简单的重构可能在 30 秒内完成；复杂的多文件编辑可能需要五分钟；代理任务可能运行 20 分钟甚至更久。
- 等待的心理学 – 不确定的等待比已知的等待感觉显著更长（Maister, 1985）。没有 ETA 的加载动画会引发焦虑，并产生“快去快速检查别的东西”的冲动。
对 attention residue 的研究表明，即使是短暂的自我中断也会产生真实的成本。Gloria Mark 对工作场所中断的研究发现，员工通常需要 >20 分钟 才能完全回到被中断的任务（Mark et al., 2005）。
Solution: 选择以下活动
- 不向工作记忆加载新上下文。
- 提供真实的微恢复。
- 可以立即放弃，且不会有损失。
- 匹配不确定性，而非实际的等待时长。
Physical Micro‑Breaks (Best for Any Wait Length)
| 活动 | 为什么有效 | 近似时间 |
|---|---|---|
| 20‑20‑20 规则 – 目视20 ft（约6米）外20 s | 放松眼部肌肉；对抗屏幕导致的眼睛疲劳。 | 20 s |
| 姿势检查 – 向后转动肩膀，放松下巴 | 释放积累的紧张感。 | 5 s |
| 站立并伸展 – 髋屈肌伸展，颈部滚动 | 打破久坐姿势；不增加心理负担。 | 30 s |
| 补水 – 拿一杯水 | 即使轻度脱水也会削弱认知能力（Ganio et al., 2011）。 | 10 s |
| 三次深呼吸 – 缓慢呼吸激活副交感神经系统 | 将状态从压力转为休息‑消化。 | 15 s |
研究: Henning et al. (1997) 发现，短暂且频繁的轻度伸展休息能提升舒适度和工作效率。
轻度思维活动（适用于 1–5 分钟等待）
- 重新阅读你的提示 – 加强你对助手要执行任务的要求；为对输出进行批判性评估做好准备。
- 浏览周围代码 – 快速查看当前文件上下的函数；在不建立新思维模型的情况下刷新上下文。
- 起草下一条指令 – 写下或在脑中构思后续查询；当当前输出到达时可以立即放弃。
- 审查最近的更改 – 滚动查看
git diff或最近的编辑；在逻辑仍然新鲜时捕捉问题。 - 心理走查 – 想象待实现更改的预期行为；在没有外部输入的情况下保持参与感。
- 草拟测试场景 – 快速记下笔记：“处理空输入”、 “如果 API 挂掉则优雅失败”、 “边缘情况：用户没有权限”。AI 稍后可以将这些转化为真实测试。
工作记忆洞察： Cowan（2010）显示我们在工作记忆中大约能保持 四个项目。重复使用相同槽位的活动（例如审查自己的提示） 不会与主要任务竞争，而加载新上下文（例如阅读 Slack 线程）会产生干扰。
反模式： 在 AI 等待期间审查他人的 PR 会加载完全不同的代码库上下文。将代码审查留到专门的时间块进行。
当没有活动是最好的
有时最有成效的事情是 什么都不做。大脑在空闲期间（孵化）仍然继续处理问题。Baird et al.（2012）证明，短暂休息的参与者往往在之后更快地解决创意问题。
快速参考清单
- ☐ 身体：20‑20‑20，姿势检查，站立伸展，补水，深呼吸。
- ☐ 心理（1–5 分钟）：重新阅读提示，扫描附近代码，草拟下一条指令，回顾最近的更改，心里走一遍，草绘测试场景。
- ☐ 避免：新的上下文切换（Slack、Twitter、无关的 PR）。
- ☐ 记住：将活动匹配到 不确定性，而不是精确的等待时长。
参考文献
- Baird, B., 等（2012）。创意问题解决中的孵化。Creativity Research Journal。
- Cowan, N.（2010）。短时记忆中的神奇数字 4。Trends in Cognitive Sciences。
- Ganio, M. S., 等（2011）。基于证据的液体摄入方法。Journal of Athletic Training。
- Henning, R. A., 等（1997）。微休息与生产力。Human Factors。
- Maister, D. H.（1985）。等待的心理学。Harvard Business Review。
- Mark, G., 等（2005）。中断工作成本。Proceedings of the SIGCHI Conference on Human Factors in Computing Systems。
使用等待时间的有效方法
为什么“低需求”任务很重要
- 进行低需求活动的休息（例如，快速伸展）相比继续工作或什么都不做，会带来显著的绩效提升。
- 低需求 ≠ 刷社交媒体——后者仍然占用注意力，阻碍恢复。
促进扩散思考的技巧
| 技巧 | 操作方法 | 为什么有帮助 |
|---|---|---|
| Window gazing | 向窗外看，让眼睛停留在远处的物体上。 | 让思维在不强迫的情况下回到问题上。 |
| Walk to the kitchen | 去厨房拿咖啡或水 不 查看手机。 | 身体活动 + 环境变化为默认模式网络提供工作空间。 |
| Doodle or fidget | 进行无意识的手部动作。 | 占用产生焦虑的大脑部分，尤其适用于较长的等待。 |
| Close your eyes briefly | 30‑60 秒的空白（不是冥想）。 | 短暂的脱离可刷新精神能量，特别是疲劳时。 |
| Sanity‑check assumptions | 问自己： • 哪项假设可能错误？ • 更简化的版本会是什么样？ • 如果规模扩大10倍会出现什么问题？ | 安静的元认知在你过度信任生成代码前捕捉问题。 |
| “Shower insight” in micro‑doses | 当长任务运行时，在心理上放手，相信大脑会继续工作。 | 突破常常在无焦点的时刻出现。 |
适合不可预测等待的事务性任务
| 活动 | 适合原因 |
|---|---|
| 更新笔记或待办事项 | 将新想法外化，而不引入新上下文。 |
| 记录工作时间 | 只需几秒；像 Super Productivity 之类的工具让它毫不费力。 |
| 记录阻塞或问题 | 立即捕捉；稍后再处理。 |
| 清除一条通知 | 回复一条 Slack 私信，然后停止。设定硬性边界以避免连锁反应。 |
| 稍后收藏 | 保存文章或库链接而不阅读（阅读 = 新上下文）。 |
规则： 如果活动 需要阅读或吸收新信息，则 不是 等待时的活动。你是在组织，而不是在消费。
Source: …
破坏流动的活动
| 活动 | 问题 |
|---|---|
| 检查 Slack/Teams | “只看一眼”会触发残留的思绪（注意力残留）。 |
| 社交媒体（Twitter、Reddit、HN） | 多巴胺激增让后续的专注工作显得乏味。 |
| 开始做其他任务 | 导致两个半成品任务；你需要为上下文切换付出两次代价。 |
| 强迫性刷新 | 等待输出并不会加快速度；只会让你陷入焦虑的等待状态。 |
| 邮件回复 | 加载他人的上下文并组织回复本身就是工作，而不是休息。 |
| “生产性拖延” | 转移后再回来会产生双倍开销，抵消完成的单个任务。 |
**例外情况：**如果等待时间真的很长（10 分钟以上），请重新考虑该 AI 工具是否是合适的选择。将工作拆分为更小的块（例如，三个 5 分钟的步骤并设立检查点）。
按等待时长建议的活动
| 等待时长 | 不确定性 | 最佳活动 |
|---|---|---|
| 30 秒 – 1 分钟 | 低 | 检查坐姿，深呼吸，遵循 20‑20‑20 眼部规则 |
| 1 – 3 分钟 | 中 | 重新阅读提示，快速浏览周围代码，补充水分 |
| 3 – 5 分钟 | 中 | 起草下一步指令，进行思维走查，伸展身体 |
| 5 分钟以上 | 高 | 进行发散性思考，更新笔记，短暂散步 |
| 未知 / 较长 | 高 | 设定思维检查点，然后进入发散模式 |
当不确定时，默认选择低承诺的活动。 如果等待时间继续，你可以随时延长伸展时间。你无法“撤回”已阅读的 Slack 消息。
Context: AI‑Tool Waits vs. Traditional Waits
- 开发者一直在等待——编译器、构建、测试、部署。
- AI‑tool waits 是 更短、更频繁且不可预测 的。
- 编译可能稳定在 3 分钟；Claude 可能在 30 秒内完成，也可能在类似任务上耗时 10 分钟。
这种不可预测性改变了计算方式：
- 你无法在 30 秒的等待期间启动有意义的副任务。
- 也不能在可能延长至 5 分钟的等待中随意发呆。
上述策略正是为这种不确定性而设计的。
掌握等待时间的好处
- 精神焕发 – 减少疲劳，提升专注。
- 降低上下文切换成本 – 减少碎片化的注意力峰值。
- 利用扩散思维 – 让潜意识继续进行问题解决。
等待并不是失去的时间。它是你不知道自己需要的功能。