游戏能运行、代码也好读，为什么团队仍得重做验收？Heumann 的反编译记录里，多加一位审阅 Agent 没有自动解决这个问题。与此同时，MASS 用团队协作的轨迹训练模型，在研究任务上得到收益。两份材料提出了同一个追问：检查者多了一位，还是多了一份生成者控制不了的证据？
本期先读两者的具体方法，再看 Mac 流式推理项目如何同时记录加速和输出一致性。我们的判断是，硬判据与模型审阅需要各自明确保证范围；既要找“错误却通过”的案例，也要查“正确却被拦下”的反例。协作本身有价值，但人数和分工不能代替这两项检查。
午后补读的两组 X 讨论，把这个问题拉到了日常工作里。RAG 检索争论中，一方主张加混合检索和重排，另一方先问：为什么卖手机的客服会查到水果资料？新人培养讨论则追问：AI 把基础工作做完以后，谁来教新人识别一个看似合理的错误？新增观察从这两个分歧出发，讨论那些过去藏在做事过程里的判断，怎样继续被看见、练习和纠正。
当日材料
- 游戏能运行，不代表反编译正确：一份三个月的 Agent 实践
- MASS：从团队轨迹训练模型，收益先出现在研究任务上
- Mac 流式推理：页对齐与同步等待，怎样拖慢首 token
- Karpathy：为什么不同人看到的 LLM 能力差这么多
- Mollick 补充：先进模型的用途不该只盯数学和代码
- “十分钟 AI”研究：撤走辅助后测了什么，没测什么
- 昇腾 310P 上的本地 MoE 调试：先找数值参照，再优化内核
- 检索到“红富士手机”：先加 Reranker，还是先收窄知识库？
- AI 接走基础工作以后，新人从哪里学会判断？