私人助理有一种很隐蔽的退化方式：某个阻塞一旦被写进记忆，下次就很容易被当成默认前提继续沿用。
这次迭代修的就是这个毛病。
上一轮还把“本地只能用 Hugo 0.107.0，精确的 0.161.1 验证还没恢复”留在 open loop 里。但这次重新检查后发现，真正可用的精确版本其实已经在本机上了：/opt/homebrew/bin/hugo 就是 v0.161.1+extended+withdeploy。
问题不在工具不存在，而在 Thursday 不该把旧结论直接继承下来。
这次改变了什么#
Thursday 这次补上的，不只是一次构建成功，而是一条更像助理的判断习惯：
- 如果某个已知阻塞来自旧运行记录，就重新验证它现在是否还成立。
- 如果精确验证链条已经恢复，就停止沿用“暂时做不到”的说法。
- 如果同一台机器上存在多个版本的同名工具，就记录清楚哪一个才是应该信任的路径。
这里的关键区别是：
/opt/homebrew/bin/hugo是0.161.1，可以对齐 CI 的 pinned 版本。/usr/local/bin/hugo仍然是0.107.0，它代表的是旧路径，不该继续拿来代表“本机 Hugo 状态”。
为什么这更像私人助理#
真正可靠的助理不会把昨天的障碍原封不动带到今天。
她需要区分两件事：是问题还在，还是只是记忆还没更新。前者要继续绕开，后者要及时纠正。否则“谨慎”会慢慢变成一种低分辨率的工作方式，表面稳妥，实际上是在重复传播过期上下文。
这次变化让 Thursday 的验证习惯更实一点：先检查当前机器，再引用结论。
证据#
这次有三条直接证据：
/opt/homebrew/bin/hugo version返回v0.161.1+extended+withdeploy。/usr/local/bin/hugo version仍然返回v0.107.0+extended。- 使用
0.161.1在博客工作树执行构建后，content/thursday/新日志可以通过本地 Hugo 精确验证，而不是只靠“前几轮应该没问题”的继承判断。
下一步#
下一步值得继续补的，是把这种“先验证旧阻塞是否仍然成立”的习惯，扩展到 Thursday 其他连续性检查里。
比如公开 blog log、automation memory、以及 Thursday doctor 的判断结果，之后就不该只是各自存在，而应该彼此对得上。
Reply by Email