Git原生发布2026：编码代理让CMS变得可选

2026年8月，两件看似无关的事同时发生：Check Point Research 披露近 2,000 个被入侵的 WordPress 站点沦为恶意软件基础设施；OpenAI 宣布 Codex 通过开放代理 harness、SDK 和 CLI 成为「运营整个流程的基础设施」。64 Labs 在 8月27日的文章《AI Isn't Just Writing Blog Posts. It's Making the Blog Platform Optional》中把它们连成一个问题：当 AI 代理能创建内容、更新站点、遵循约定、验证结果并准备部署时，传统博客平台还有多少是必要的？答案是：内容管理不会消失，它被重新分配了。

1. 仪表盘是为人类设计的

传统 CMS 解决的是真问题：大多数人不愿意编辑 HTML、操作仓库、管理模板或运行部署命令。WordPress 和 Substack 用可视化界面把这一切包装起来，仪表盘成为发布发生的地方。但 AI 编码代理改变了人与网站之间的接口：发布者不再需要学会平台把 SEO 字段、图片设置、分类器或主题控件放在哪里，只需要描述期望结果——「加这篇文章，用现有结构，保持站点风格，检查链接，更新索引，验证站点还能构建」。

// Content lives in files, not database rows.
// Structure lives in front matter; presentation lives in templates.
// ---
// title: "Git-Native Publishing: The CMS Is Now Optional"
// date: 2026-08-28
// author: "Evergreen Team"
// tags: ["publishing", "coding-agents", "hugo"]
// locale: en
// draft: false
// ---
// The article body is just Markdown next to the site itself.
// Revision history comes from version control, not an admin panel.

// The agent's job description lives in the repo too (AGENTS.md):
# Repo rules for AI agents
- Articles live in content/posts/<slug>/index.md
- Use the site's existing front-matter schema (see archetypes/post.md)
- Preserve the site's style: no inline HTML, semantic Markdown only
- Update content/posts/_index.md and the sitemap when adding posts
- Run "hugo build" and fix every warning before committing
- Never touch theme files without human review

2. 内容即文件，部署即发布

在静态的、由代理管理的发布体系里，文章不需要以数据库记录的形式存在于远程管理后台。它是与网站本身放在一起的文件。站点现有的代码和约定决定这个文件如何变成页面。CMS 的职责没有消失，只是被重新分配：内容在文件里，结构在元数据和仓库约定里，呈现在模板里，修订历史来自版本控制，验证来自构建检查，部署成为发布按钮。结果不是「没有内容管理」，而是「没有传统 CMS 应用的内容管理」。

// The publishing step is a build, not a button.
// Validation comes from build checks; deployment is the publish button.
name: publish
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: "0.140.0"

      - name: Validate content
        run: |
          hugo --printPathWarnings --templateMetrics
          test -f public/index.html

      - name: Check links
        run: npx linkinator public --recurse --skip "^(https://example.com)"

      - name: Deploy
        if: github.ref == 'refs/heads/main'
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

3. 代理的工作循环：创建、验证、diff、提议

公开项目 AIM-blog 记录了一套可复制的流程：Codex 添加双语文章和相关站点内容、运行 Hugo 生产构建与 diff 检查、支持本地审查、准备好 pull request；批准后 GitHub Actions 构建并发布。仓库里甚至包含项目特定的 Codex skills，让代理遵循出版物的现有结构。这套循环的核心是把「内容改动」变成「代码改动」，让版本控制、CI 和代码审查这些成熟机制接管内容质量。

// The agent's loop: create, verify, diff, propose.
// The AIM-blog workflow: Codex adds bilingual articles, runs a Hugo
// production build + diff checks, supports local review, and prepares
// a pull request. Humans approve; CI publishes.
#!/usr/bin/env bash
set -euo pipefail

SLUG="$1"

# 1. Agent creates the post from the archetype
hugo new "posts/${SLUG}/index.md"

# 2. Agent fills content, then validates
hugo --printPathWarnings --templateMetrics

# 3. Diff check: only expected files changed?
git diff --stat
git status --porcelain

# 4. Prepare the pull request
git checkout -b "post/${SLUG}"
git add "content/posts/${SLUG}"
git commit -m "post: add ${SLUG}"
gh pr create --fill --label content

4. 构建检查就是内容验证器

动态平台靠数据库约束和插件保证一致性，Git 原生发布靠构建检查。Hugo 的路径警告、模板指标、linkinator 的链接检查、JSON Schema 的 front matter 校验——每一个都是自动化的质量闸门。代理写完文章后必须通过全部检查才能进入 PR；CI 拒绝合并，直到每个框都打勾。这比人类在仪表盘里肉眼检查可靠得多。

// Human approval is the only "dashboard" left.
// The CMS responsibilities don't disappear — they are redistributed:
//   content    -> files
//   structure  -> metadata + repo conventions
//   presentation-> templates
//   revisions  -> version control
//   validation -> build checks
//   deployment -> the publish button (CI)
// Review checklist for a content PR:
export interface ContentReview {
  frontMatterValid: boolean;    // schema check via JSON Schema
  buildClean: boolean;          // hugo build exits 0
  linksValid: boolean;          // linkinator passes
  imagesOptimized: boolean;     // no >200KB assets
  sitemapUpdated: boolean;      // index reflects new post
  humanRead: boolean;           // an actual person read the draft
}

// A tiny CI gate: refuse to merge until every box is checked.
const gate = (review: ContentReview) =>
  Object.values(review).every(Boolean) ? "mergeable" : "blocked";

5. 人工审批是最后剩下的「仪表盘」

这套模式没有消灭人类，而是把人类放到最擅长的位置：阅读和判断。代理负责起草、格式化、验证、diff 检查；人类负责读草稿、审 PR、批准合并。安全收益也很直接——2026年8月 Check Point 报告的 2,000 个被入侵 WordPress 站点提醒我们，动态发布平台的维护面是持续的攻击面；而静态、构建验证、Git 托管的站点没有数据库、没有插件、没有登录后台可打。

// Schema for front matter — agents validate against it, humans trust it.
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["title", "date", "author", "locale", "draft"],
  "properties": {
    "title": { "type": "string", "minLength": 4 },
    "date": { "type": "string", "format": "date" },
    "author": { "type": "string" },
    "locale": { "enum": ["en", "zh"] },
    "tags": { "type": "array", "items": { "type": "string" } },
    "draft": { "type": "boolean" }
  }
}

// Run: npx ajv-cli validate -s schema.json -d "content/**/index.md"
// (convert YAML front matter to JSON first)

6. 迁移路径

第一步：把内容导出为 Markdown + front matter 文件。第二步：用 Hugo 或 Next.js 重建站点，CI 负责构建。第三步：写 AGENTS.md 让代理遵循现有结构，从「代理帮你写文章」升级到「代理帮你运营整个发布流程」。第四步：把 SEO 元数据、sitemap、索引更新全部变成构建时生成。每一步都在缩小对传统 CMS 的依赖，直到仪表盘只剩一个东西：merge 按钮。