Shiina Labs
图片：Marketing Online / Unsplash
让「回去睡觉」这件事难一点
我的作息在休息日特别容易散掉。经常睡到十一点，有时候睁眼已经快中午。洗漱完就该吃午饭。午饭后的困意一上来，感觉刚开机就又要关机了。除非那天有明确要去的地方，我大概率会刷一会儿手机，然后爬回床上。
我以前把这归咎于作息不好，或者自制力不够。过了很久才意识到，环境也是问题的一部分。我在同一间卧室里工作、放松、睡觉，书桌和床之间只有几步。写代码、看视频、打游戏都在同一个位置。累了只要站起来走两步就能躺下。本该占据生活不同部分的活动，被压缩在同一个房间里。
卧室不给我一个清晰的信号，告诉我该做什么。坐在电脑前可能是工作也可能是放松；一离开桌子，床就在旁边。哪怕我打算午饭后做点事，一旦开始犯困，睡觉立刻变成最省事的选择。这种省事是很字面意义上的。只需要三个动作：站起来、转身、躺下。
而开始工作要费更多力气。我得压着困意坐回桌前，打开项目，想起来上次做到哪，慢慢把注意力拉回来。整个过程里床一直在视野内，提醒我还有一个容易得多的选项。大多数时候，我并不是仔细比较了两个选项然后有意识地决定偷懒。我只是往阻力最小的那个方向漂过去。睡觉几乎不费力，娱乐也不用费多少力。工作是唯一需要额外推一把的选项。
那天我决定换个环境，把 Mac 带到楼下的咖啡店。我并不觉得咖啡店是理想的工作场所，也不是想扮演那种整天泡在咖啡里写代码的独立开发者。抱着笔记本下楼，点完东西一个人坐很久，还是让我有点不自在。我的目标简单得多：我只是想让自己离床远一点。
去咖啡店意味着要换衣服、装电脑和充电器、下楼、找位置、点东西。表面上看，在外面工作显然比待在卧室里麻烦。但这些摩擦都发生在开始之前。一旦已经坐在店里，情况就反过来了。电脑开着，东西点了，我不太可能几分钟后就收拾走人。就算累了，旁边也没有床可以倒下去。回家睡觉意味着合上电脑、收拾东西、离开店、再走回楼上。原本只需要三个动作的事，变成了一整套流程。
我并没有突然变得更有自制力。我只是把摩擦力挪到了另一个方向。在卧室里，停下工作太容易。在咖啡店里，提前结束这段要费更多力气。环境没有逼我专注，也没有把我送进什么神奇的心流状态。它只是让「待在那里做点什么」在那一刻成为更自然的选择。
咖啡店当然有它自己的问题。有人说话，音乐不一定合我口味，桌椅不一定舒服，而且待着要花钱。坐太久我还会开始琢磨自己是不是占着桌子太久了。这不是一个可以长期依赖的方案，也当然不意味着我每个休息日都该去咖啡店工作。但那次经历让我注意到，环境不只是在影响我的心情。它一直在改变每一个可行动作所附带的努力量。
我以前关注的是减少摩擦。电脑放在手边，需要的东西都在卧室里。那确实让开始工作更容易，但也让娱乐和睡觉同样容易。到最后每个选项都没有多少摩擦，我就只能依赖当时碰巧处于什么状态。那天我做了相反的事。我没有再去优化卧室里的工作流，而是让「回去睡觉」稍微不方便了一点。仅仅是离床远一些，就足以改变那个下午最可能发生的事。
我到现在也不知道在咖啡店工作会不会变成固定习惯。也许我以后会找到别的空间，或者重新布置卧室，让工作和休息有更清楚的边界。但至少在那一天，我午饭后没有回去睡。我坐在楼下，打开电脑，准备做点事。
然后咖啡店的网络出问题了。
咖啡店的网络
我的 Mac 连 Wi-Fi 没有任何问题。即时通讯照样收发消息，但网页打不开。Twitter、ChatGPT，还有我常用的另外几个站点，全都没响应。也不是完全断网，这让情况显得有点奇怪。macOS 显示 Wi-Fi 已连接，有些应用显然还在通信。我刷新了好几次页面，又试了几个不同的网站，结果都一样。
我一时判断不出问题在哪。可能是浏览器，可能是 DNS，可能是残留的系统代理配置，也可能是咖啡店网络本身的问题。继续排查通常意味着把这几样一个一个试过去。巧的是，我前几天刚给 WiFi Lens 做出 Network Self-Check 的第一个版本，所以想起来可以跑一下。
Network Self-Check 把方向指向了 DNS。它没有找出完整原因，但给了一个有用的起点。
这个功能当时还非常基础。界面刚做到能用的程度，检查项只覆盖当前网络路径、DNS 解析，以及 macOS 的系统代理设置。当显式配置了 HTTP、HTTPS 或 SOCKS 代理时，它还会尝试连接对应的地址和端口。它没法分析 VPN 连接或复杂路由。它能识别出系统正在使用 PAC 配置，但不会去下载或执行那个脚本，更不会自动修改任何网络设置。
我最初的意图只是覆盖几个基础且相对常见的问题。我并不确定它在真实场景里有多大用。实际上我怀疑，等我真的遇到网络问题时，它可能什么都查不出来。不过功能已经在我电脑里了，我就跑了一下。结果显示 DNS 解析失败。
我去看了 DNS 设置，发现我手动配置的其中一个解析器，从咖啡店的网络里访问不到。它在我平时用的网络上一直没问题，所以我从来没在意过这个设置。我加了一个备用解析器，再打开浏览器，网页正常加载了。
这不代表那个 DNS 服务本身有什么问题。更准确地说，是我配置的那个解析器在那个特定的时间、从那个特定的网络访问不到。换一个网络，结果可能完全不同。Network Self-Check 也没有找出根本原因。它没法判断解析器不可达是因为咖啡店的网络策略、两者之间的路由，还是路径上的别的东西。它只能确认 DNS 查询失败了，并把这个结果显示出来。我还是得自己去查配置、自己改。
不过那个提示恰好有用。跑检查之前，我只知道消息能发、网页打不开。看到结果之后，我第一件事是去查 DNS，而不是把浏览器和代理设置一个个试过去。它没有完整解释问题，只是帮我省了几步。
这也是我第一次在开发和测试之外用这个功能。我一直觉得它的范围太小。网络问题可以很复杂，而第一个版本只检查了少数几个基础组件。但我第一次遇到真实问题时，它恰好抓住了相关的那一个。这不代表这个功能已经完善了。换一种故障，它可能只是报告当前网络看起来正常，或者停在一个没有多少实际指导意义的结果上。
那天下午的问题跟 DNS 有关，但这个工具能确定的只是「有一次查询失败了」。它不知道原因。这后来成了我修改结果措辞时格外注意的一点。网络检查很容易把一个异常观测当成最终诊断呈现出来，但这两者不是一回事。DNS 失败可能来自本地配置、当前网络、到解析器的路由，或者上游服务。代理端口不可达也不一定意味着代理应用坏了。如果界面把自己的发现说得太肯定，可能会把用户带向错误的方向。
后来我把 Network Self-Check 放进了 WiFi Lens 1.5.0，在那里它仍标着 Preview。这是它的第一个公开版本，检查项、结果措辞和界面都会继续变。诊断结果和 Wi-Fi 扫描数据都留在设备本地。DNS 检查做的是一次正常查询，显式代理检查只测试到所配置地址和端口的 TCP 可达性。它们不读取代理的用户名或密码。
我去咖啡店只是为了离床远一点。我没打算在那里测 WiFi Lens。只是那家店的网络恰好出了问题，而我的电脑里恰好装着一个刚做出来的诊断功能。
于是我跑了一下，而那一天，它恰好有用。
说明：Network Self-Check 包含在 WiFi Lens 1.5.0 中，开源版和 Pro 版都有。
GitHub：https://github.com/ShiinaLabs/wifi-lens 官网：https://wifi-lens.shiinalabs.com