今天在 autoDL 上装依赖，pip 跑了一个多小时还没完。我先跟人吐槽了两句，然后做了个决定：换成 uv，听说它快。换完继续忙别的，又等了一个小时，还是慢。
到这时候我才想起来去问 AI：它到底慢在哪。AI 说，先看源。我把包的源换掉，速度立马上来了。整体仍不算快，但至少知道大头是源，剩下慢的部分是另外的事，该往哪看心里有数了。
事后算账，这件事最贵的不是那两个小时，是那两个小时里我一直在等。第一次等 pip，第二次等 uv。等待给人一种事情在推进的错觉——进度条在动嘛。其实什么都没推进，我只是把判断往后推了。一条 pip -v 就能看见的东西，我用了两个小时去等它。
换 uv 这一步也有意思。当时是碰运气，想着换个工具也许就快了。事后看，pip 慢、uv 也慢，两个都慢，问题大概率不在工具身上，而在它们共用的东西上——网络，或者说源。等于无意中做了一次排除法。只是这个认识是复盘时才有的，当时纯粹是撞大运。
所以今天记两条。
一是发现困惑要立刻去探。困惑不会自己变清楚，放一放只会让你为它多付等待的时间。等不是排查，等是拖延的一种体面说法。
二是快速识别是快速解决的前提。识别不出问题在哪，动手就是盲动。先花两分钟问一句「我到底在等什么」，比先花两小时换工具划算得多。
今天还捡到一个写技术文章的框架，九步：发现困惑、尝试解决、遇到障碍、不断探索、发现新思想、动手验证、理解边界、连接今天、与我何用。看着像清单，其实是把一次真实的踩坑过程按顺序摆出来。学习本来就是这么发生的，只是写文章的时候常常忘了，上来就「定义、原理、示例、总结」。
这篇就是按它写的：困惑是依赖装不完，尝试是换 uv，障碍是还慢，探索是去问 AI，验证是换源，边界是快了但仍不算快，连接今天是把这段写下来。与我何用——下次进度条再卡住，先问「我在等什么」，再决定是动手，还是接着等。