AI
Loop Engineering：不再自己写 prompt，改为设计循环
Peter Steinberger 和 Claude Code 负责人 Boris Cherny 都说过类似的话：他们不再直接给 agent 写 prompt，而是写会去 prompt agent 的循环。Addy Osmani 把这件事拆成五个部件加一份记忆：
- Automations：定时触发，自己找活、做分诊。
- Worktrees：多个 agent 并行时各用各的工作目录，不会改到同一个文件。
- Skills：把项目约定写进
SKILL.md，agent 每轮读一遍，不用每次重新解释。 - Plugins / Connectors：基于 MCP 接入 issue、数据库、Slack，让循环能自己开 PR、更新工单。
- Sub-agents：写代码和检查代码的分开，避免自己给自己打分。
记忆可以是一个 markdown 文件或 Linear 看板，记录做过什么、下一步做什么。模型每轮都会忘，仓库不会。Codex 和 Claude Code 现在都具备这五样，名字不同，能力基本对应，所以设计好的循环换工具也能用。
文章后半段写的是风险：无人值守的循环也会无人值守地犯错，"完成"只是 agent 的声明；循环产出越快，你对代码的理解欠账越多。作者自己也说，如果不亲自 review，产品质量会往下掉。
上一篇 Agent Harness Engineering（5 月刊介绍过）讲的是单个 agent 的运行环境，loop 是在 harness 外面再加一层调度。
Claude Code 官方的循环入门
Claude Code 团队把 loop 定义为"重复工作直到满足停止条件的 agent"，按触发方式和停止方式分成四类：
| 类型 | 交出去的部分 | 适用场景 | 对应功能 |
|---|---|---|---|
| Turn-based | 检查 | 探索、需要你做判断 | 自定义验证 skill |
| Goal-based | 停止条件 | 你知道"完成"长什么样 | /goal |
| Time-based | 触发时机 | 定期任务、等外部系统变化 | /loop、/schedule |
| Proactive | prompt 本身 | 重复且边界清楚的工作 | 以上全部 + dynamic workflows |
几个可以直接抄的写法：
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
/loop 5m check my PR, address review comments, and fix failing CI
前端相关的一个例子：写一个 verify-frontend-change skill，要求改完 UI 后启动 dev server、点一下新按钮并截图对比、检查控制台零报错、用 Chrome DevTools MCP 跑一次 Core Web Vitals。检查越量化，agent 越能自己验证。
控制 token 的建议也很实际：确定性的步骤写成脚本，不要让模型每次重新推理；dynamic workflows 可能一次拉起上百个 agent，先拿一小部分任务试跑；定时任务的间隔跟着被观察对象的变化频率走。
前端
Bun 用 11 天从 Zig 迁到 Rust
5 月刊提过这次迁移的 PR，这篇是 Jarred Sumner 的官方复盘。
迁移原因是内存问题。Zig 需要手动管理内存，又要和 JavaScriptCore 的垃圾回收配合，use-after-free、double-free 一直修不完，仅 v1.3.14 就修了 12 个。Rust 的借用检查和 Drop 能在编译期挡掉大部分这类问题。
具体做法：用 Claude Fable 5 预览版跑动态工作流，约 50 个并行任务，高峰时 64 个 Claude 实例同时工作，按"1 个实现、2 个对抗审查、1 个修复"分组。5 月 3 日到 14 日，6,502 次提交，新增 100 多万行代码，API 费用约 16.5 万美元。
结果：Bun.build() 每次调用约 3MB 的内存泄漏降到 0，Linux 和 Windows 二进制体积小了 20%，性能提升 2%–5%，全平台测试通过。
TypeScript 7.0：Go 原生实现正式发布
用 Go 重写的 TypeScript 编译器正式发布，支持原生代码和共享内存多线程。
- 完整构建快 8–12 倍：VS Code 项目从 125.7 秒降到 10.6 秒，Sentry 从 139.8 秒降到 15.7 秒。
- 内存平均少用 6%–26%。
- 编辑器里打开项目到显示错误，从 17.5 秒降到 1.3 秒。
升级前要注意默认值变化：strict 默认开启，module 默认 esnext，types 默认空数组，rootDir 默认 ./；ES5 目标、AMD/UMD、经典模块解析不再支持。官方建议先升到 6.0 适应新默认值，再用 npm 别名让 6.0 和 7.0 并存。7.0 还没有稳定的编程 API，Vue、Angular 等框架的集成要等 7.1。
TanStack 官网撤掉 RSC，改回普通 SSR
We Stopped Using RSC on TanStack.com
TanStack 当初用 RSC，是为了把 Markdown 解析和代码高亮这些大依赖留在服务端，光高亮相关就约 358 KiB。
后来他们把客户端渲染器压到约 27 KiB，重新算了一遍：渲染器只下载一次，之后切页只拿 Markdown 原文；RSC 方案则每次切页都要接收服务端生成的组件树。网站访客平均每次浏览约 6 页，渲染器下载一次反复用更划算。
改成普通 SSR 负责首屏、server functions 返回内容数据之后，用旧站对比新站：博客文章页传输量从 1,101 KiB 降到 785 KiB，Lighthouse 分数从 52 到 74，Total Blocking Time 从 1,200ms 降到 260ms；文档页变化小一些，分数从 78 到 81。代码也少了专用文件、序列化和服务端边界的处理。