给 Agent 一个能运行代码的地方，往往比再加一段要求更有用。Simantic 把固件放进虚拟开发板，tinyworldformer 则让小型策略在模型生成的游戏里练习；它们都在降低反复尝试的成本。打砖块策略钻出虚假奖励的经历又提醒我们，测试环境本身也会出错。本期观察由此展开：反馈要足够快，也要能说明它与目标结果有什么关系。
这个问题不只存在于模拟器。Rachel Laycock 记录的开发实验中，功能快速出现，集成与维护的疑问仍在；经验丰富的人可以帮助把疑问变成具体检查，而不是只在赞成与反对自动化之间表态。先读这三条，可以看到从单次运行到持续迭代，验证需要补上哪些环节。
另外三项技术材料各自解决一种资源限制。SkyPilot 讨论故障机架如何继续贡献可用 GPU，Sleep 尝试把短期经验整理进长期参数，Mistral Large 4 的部署则展示长会话容量与响应速度的取舍。它们分别涉及调度、学习和推理，数字不能互换，实际使用也需要先确认瓶颈在哪里。
最后回到文字本身。Martin Fowler 的“LLM Voice”讨论保留了阅读疲劳、写作思考与辅助表达的不同需要。工具让产出更容易以后，读者仍需要知道作者在解决什么问题、凭什么这样判断。
本次补充的 X 讨论把反馈问题带到协作与使用体验。十五助手的介绍引出了具体交接建议，也引出了“到底产出什么”的追问；Mollick 推荐的组织能力视角进一步提醒我们，个体变强与一起做成事仍要分别观察。第二篇观察沿着这一区别，讨论怎样让下一位参与者真正接住工作。
另可读 Carbon 的试用兴趣与运行条件、Lambert 对答非所问的抱怨，以及 AI 回复究竟有没有形成真人交流的分歧。WONTFIX 则提供了一个新的创作例子：把工单叙事装进固定游戏空间。它们展示了可尝试的新用途，也保留了使用者提出的具体问题。
当日材料
- Simantic：让固件 Agent 在虚拟开发板上运行测试
- tinyworldformer：小模型能运行游戏，也会给玩家留下漏洞
- SkyPilot 的 27%：让故障机架继续贡献可用 GPU
- Sleep：把上下文里的短期经验转成参数中的长期知识
- Mistral Large 4 开放权重：稀疏计算之外，还要看缓存怎么放
- Rachel Laycock：资深开发者的顾虑，藏在持续运行的问题里
- Martin Fowler 的“LLM Voice”：写得顺，不等于想得清楚
- 15 个 AI 助手的讨论：交接建议之外，读者还想看到产出
- Gemini Carbon 引发试用兴趣，评测细节却要求重新拆开“更强”
- Nathan Lambert：模型忙着回避灰区时，可能漏掉用户真正的问题
- AI 回复让谁在和谁说话变得模糊：Mollick、Shah 与 Willison 的分歧
- Mollick 推荐组织能力视角：更聪明的个体，还要能一起做事
- WONTFIX：把工单改编成恐怖游戏，生成内容装进固定场景