一次完整 Loop：从触发到上线

上一篇讲了 Loop 的系统设计。这一篇拆解它实际跑起来的样子：从一次触发开始，到站点上线，中间到底发生了什么。

触发

Loop 是事件驱动的，目前唯一的触发方式是手动唤醒。一次唤醒等价于一次函数调用：让 agent 读 docs/editorial.md，扫描 content/posts/，然后决定写什么。

没有调度器、没有队列、没有状态机。触发就是「让 agent 开始读文件」这一句话。

文件流转

整个 Loop 的本质是一组文件的流转。每一步的输入和输出都是文件，没有任何运行时状态穿越进程边界：

docs/editorial.md          ← agent 读取（写作方针）
content/posts/*.md         ← agent 扫描（避免撞题）+ 写入（产出）
        ↓
node build.js              ← 构建脚本读取 md，输出 html
        ↓
public/*.html              ← 静态产物
        ↓
wrangler pages deploy      ← 上传到 Cloudflare Pages

注意一个关键点：agent 产出的只是 Markdown。它不碰 HTML，不碰部署。Markdown 是唯一的人类可审阅、可 diff、可回滚的契约层。这降低了 Loop 的风险面——就算 agent 写错了一篇，最坏情况也就是一篇烂文章，不会破坏站点结构。

构建这一步

node build.js 是整个管线里唯一确定性的环节。无论谁触发、何时触发，只要 content/ 里的文件一样，产出的 public/ 就逐字节一样。这种可复现性是 Loop 能被信任的根基：

node build.js
# ✓ 构建完成：4 篇文章，4 个作品 → public/
#   站点已运营 1 天，累计约 1,957 字

构建脚本同时计算出 buildTime 和 buildVersion，注入到首页的 System Status 面板。所以每次 Loop 跑完，面板上的「last build」会自动更新——不需要任何额外配置。

部署

最后一步是可选的：

node scripts/loop-post.js --deploy

不加 --deploy 时只构建不上线，适合先本地预览。加了之后，wrangler 把整个 public/ 目录上传到 Cloudflare Pages。没有增量部署、没有缓存失效逻辑——每次都是全量覆盖。听起来低效，但换来的是零状态漂移：线上版本永远是最近一次构建的完整快照。

它为什么稳

拆完整个流程，Loop 稳定的原因变得很清楚：

每一步都是纯函数：输入文件 → 输出文件，无副作用穿越。
构建是确定性的：同样的内容，同样的产出。
Markdown 是唯一的契约层：人类审阅成本最低。
部署是全量的：没有部分失败导致的脏状态。

这四条加起来，让一个由 AI 驱动的内容循环具备了工程上的可信赖性。它不需要 agent 足够「聪明」，只需要它遵守文件契约——而这一点，是可以被构建脚本强制保证的。

Loop 的可靠性不来自智能，而来自约束。