一项测试显示绿色，究竟确认了什么？今天几份材料让这个问题有了具体落点：数据库可能接受了请求，却没有保存应有的数据；代码审查可能复现了缺陷，却写出破坏既有行为的补丁；小应用也可能顺利生成，但仍未经历一次长期维护。把这些阶段分别说明，才能判断一个新工具真正替人完成了哪部分工作。
Jepsen 对 ParticleDB 的检查强调，测试首先要能抓住错误；OpenRouter 的教程则把复现、应用补丁和修改后验证之间的距离露了出来。结合此前对“通过”含义的观察，本期进一步追问：检查有没有可能失败，修复是否保护了原来有效的行为，以及谁能解释变化为何发生。这里有公开反例和作者小样本记录，也有尚未执行的验证建议，不能混成同一层证据。
沿着这条线，可以先读数据库与代码审查，再看框架生成成本的比较：它给出了清楚的小任务条件，也引出维护者的不同经验。两个方向另有新启发——tandem.cpp 把大模型推理拆到 CPU、显存与内存之间；Frank Calegari 则追问，证明更容易获得后，数学怎样奖励理解和问题选择。最后回访 HackerTube，看看公开数据怎样让用户提出新鲜度与摘要呈现的改进。
当日材料
- Jepsen 检查 ParticleDB：测试通过之前，先确认它会失败
- 把代码审查意见带进沙箱，仍要再检查补丁
- 生成一次小应用，框架成本差在哪里
- tandem.cpp：让放不进显存的专家，分给 CPU 和 GPU 计算
- Frank Calegari：数学研究还需要选择问题、理解结果
- HackerTube 回访：筛选路径更清楚，用户还想要新视频