把博客当成代码：一套 AI Native 内容流水线

如果博客内容主要由 Codex、Claude Code 这类工具维护，传统 CMS 的核心假设就变了。

我们不再需要为人工编辑优化复杂表单、富文本工具栏和预览后台。真正需要优化的是另一件事：怎样让不同模型在不同会话里，仍然理解相同的内容标准，并且无法绕过关键校验。

这意味着博客不只是一个网站，而是一条内容供应链。

从编辑界面转向文件协议

人类编辑喜欢所见即所得，Agent 更擅长结构明确、可以 diff、可以验证的文本。Markdown/MDX 恰好提供了这个边界：正文允许自由表达，frontmatter 则像 API contract 一样约束标题、发布日期、分类、文章类型、标签、草稿状态和来源列表。

当内容模型可以在构建时验证，很多传统后台功能就失去了必要性。分类下拉框可以变成枚举，必填字段可以变成 schema，发布按钮可以变成一次通过检查的 Git 变更。

只给模型一句“帮我写篇文章”通常不够。一个可持续的 Agent 工作区至少需要三类信息。

项目定位、作者身份、站点域名、技术栈和语言偏好不会每天变化。它们适合放进长期 memory，让后续会话不用重新猜测。

来源标准、写作风格、工程约束是横向政策。规则应该短、明确，并按内容、来源和代码拆分；这样 Agent 只读取当前任务需要的部分。

“研究一篇论文并发布”不是一句风格要求，而是一组有顺序的动作：选择问题、打开原始来源、形成论点、创建文件、校验、构建、汇报。这样的知识应该成为 skill。

三者不能混成一份巨大的提示词。不变量需要稳定，规则需要可组合，流程需要能被明确触发。

Prompt 能提高遵循概率，却不等于约束。

例如，我们可以告诉模型“论文解读必须提供原论文”，但真正可靠的方式是在 schema 里要求论文地址，并检查它是否同时出现在来源列表。类似地，未完成的占位符、空标签、错误日期和过短正文，都可以在构建之前被脚本拒绝。

一条实用原则是：

凡是能够被机器确定判断的质量要求，都不应该只写在提示词里。

模型负责开放性工作，程序负责确定性边界。两者分工越清晰，流水线越稳定。

Git 天然提供传统内容系统最重要的能力：版本历史、差异审查、回滚、分支和自动化入口。

更重要的是，代码与内容处在同一上下文中。Agent 修改 frontmatter 时能同时看到 schema；调整页面呈现时能用真实文章验证；改变分类模型时也可以一次完成迁移和构建检查。

代价是发布权限必须被刻意隔离。工作区写入、构建产物和生产目录应该是三个不同边界：源内容先经过校验和构建，最后才显式同步到生产目录。

文章写完并不意味着已经上线。只有完整构建成功、用户明确要求发布之后，产物才应该进入 Caddy 的站点目录。

每天一篇文章远没有达到必须动态渲染的规模。静态站点把复杂度留在构建期，换来简单的运行时：没有数据库，没有常驻 Node 进程，也没有内容后台暴露在公网。

这并不限制未来扩展。全文搜索、评论、分析和 Newsletter 都可以在真正需要时独立接入，而不是提前进入核心架构。

AI Native 不是“所有东西都交给 AI”。它更接近一种新的工程分层：让模型处理高变化、高语义的工作，让 schema、脚本、Git 和静态构建守住确定性。