案例 13 详解 · 一键出海：多语言 SEO 博客自动生成与 GitHub Pages 自动部署

> 关键工具：Mistral Vibe / Manus（长程自主 Agent）+ Hugo + GitHub Pages

> 技术栈阶：中阶——驾驭一个会连续工作数小时的 Agent

> 完整演示：构思 → 创建项目 → 提示词编写 → AI 制作 → 项目检验 → 落地

> 预计耗时：首次搭好流水线约 2~3 小时，之后换关键词分钟级触发

这一篇怎么读

这里你不是写代码，而是驾驭一个会自己干几小时活的 Agent。本篇演示如何把"调研→写多语言文章→部署"整条流水线交给它，同时用关卡、校验、权限把它"关在轨道里"。

阶段一 · 构思：先想清楚怎么不让它跑偏

痛点：独立开发者出海，内容获客成本最低，但人工写多语言 SEO 文章、配格式、部署极耗时。
核心流程：给关键词 → Agent 调研选题 → 写 5 语种文章 → 提交 GitHub → 自动部署。
两个必须提前防的 30%（构思阶段就要锁定）：GitHub 令牌权限和 front-matter 格式校验。不提前堵，Agent 跑完大概率出事。
成功标准：一条可重复的流水线，换个关键词就能再产出一批文章并上线，且不出格式/安全事故。

阶段二 · 创建项目：备好博客仓库、Agent、令牌

建静态博客仓库（用 Hugo）：

hugo new site myblog && cd myblog
git init
hugo new theme-or-install-a-theme   # 装一个主题
git add -A && git commit -m "init blog"
# 推到 GitHub 新建的 myblog 仓库

准备 Agent：打开 Manus（或 Mistral Vibe），新建一个任务工作区，把上面的 myblog 仓库授权/连接给它（让它能在这个仓库里工作）。
建最小权限的 GitHub 令牌（这是关键安全步骤）：在 GitHub Settings → Developer settings → Fine-grained tokens，新建一个令牌，只授权 myblog 这一个仓库、权限只给 Contents: Read and write。复制备用。

令牌从创建那刻就要最小化

别图省事用"全账号、全权限"的经典 token。自动化流程里令牌经手环节多，一旦泄露，最小权限能把爆炸半径压到只有这一个仓库。

阶段三 · 具体提示词编写：给 Agent 一份带关卡的作业规范

驾驭长程 Agent 的核心：把大任务前置成它无法跑偏的形状——作业规范 + 验收标准 + 安全红线 + 阶段关卡。

起手提示词（交给 Manus / Mistral Vibe）

目标：为我的 Hugo 博客（仓库已连接）自动产出多语言 SEO 文章并部署。
分阶段执行，每阶段结束停下让我确认，再进入下一阶段。

【阶段1·选题】围绕关键词 "AI note-taking app" 调研，列 5 个有搜索量、
  竞争适中的长尾选题，给我确认后再写。
【阶段2·写作】每选题写 英/中/西/日/德 5 个版本，每篇 800~1200 词，
  含 H2/H3，自然融入关键词不堆砌；顶部生成 Hugo front-matter（见规范）。
【格式规范——严格】front-matter 用 YAML：title(字符串,含冒号要加引号)、
  date(YYYY-MM-DD)、draft:false、tags(数组)、language(en/zh/es/ja/de)。
  文件存到 content/<language>/<slug>.md。
【安全红线】只新增文章，不碰已有文件；不在代码/提交信息写入任何令牌；
  提交和部署先别做，等我单独指示。

"每阶段停下确认"是驾驭长程 Agent 的第一纪律。

阶段四 · AI 制作：看 Agent 产出了什么（关键片段）

Agent 先交"选题清单"（这里设了确认关卡，见下一步）。确认后批量产出文章，每篇顶部的 front-matter 大致长这样：

---
title: "Privacy-First Note Taking: Why Local Storage Matters"
date: 2026-06-21
draft: false
tags: ["note-taking", "privacy", "offline"]
language: en
---

## Why your notes should never leave your device
...正文...

25 篇（5 选题 × 5 语言）很快产出。看着都对——但只要有 1 篇格式错，整站就构建失败。所以下一步必须校验。

阶段五 · 项目检验（上）：用确认关卡和硬校验拦住错误

5.1 关卡①：选题先卡住，别让它直接开写

Agent 给的 5 个选题里有 2 个偏离产品定位。幸亏设了关卡：

选题修正

选题 3、5 偏离我们"本地优先、隐私"的笔记产品定位，
换成更贴近 "privacy-first / offline note-taking" 的两个。其余保留。

没这道关卡，Agent 会拿跑偏的选题一口气写 25 篇废稿——这是长程自主最大的浪费风险。

5.2 关卡②：front-matter 硬校验（这个案例真正的 30%）

让 Agent 先本地构建验证，Hugo 直接失败——一篇日文文章 title 含冒号没加引号，YAML 解析炸。一颗老鼠屎坏一锅汤。让 Agent 写一个校验脚本来检查自己的产出：

加格式校验关卡

提交前写一个 validate-frontmatter.js，扫描所有新增 .md：
- 每篇 front-matter 能被 YAML 正确解析。
- 必填字段齐全、date 是合法 YYYY-MM-DD、language 在允许集合内。
- 任何一篇不合规，打印文件名和具体问题并中止流程（不提交）。
先跑校验，把不合规的修好再继续。

// validate-frontmatter.js（关键片段）
const fm = matter(content);                 // 解析 front-matter
const errs = [];
if (!fm.data.title) errs.push('缺 title');
if (!/^\d{4}-\d{2}-\d{2}$/.test(fm.data.date)) errs.push('date 非法');
if (!['en','zh','es','ja','de'].includes(fm.data.language)) errs.push('language 非法');
if (errs.length) { console.error(file, errs); process.exitCode = 1; }

用程序化的"硬检查"约束 AI 的"软产出"——这是驾驭自动化的精髓。

阶段五 · 项目检验（下）：验收清单

检验项	操作	期望
格式拦截	故意塞一篇 front-matter 错误的文章	校验脚本拦截并中止，不流到构建
无明文密钥	查提交历史和 Actions 日志	没有任何明文令牌
令牌范围	查 token 权限	仅限 myblog 仓库、仅 Contents 读写
可重复	换个关键词再跑一遍	流水线能复用

阶段六 · 落地：GitHub Actions 自动构建并发布到 Pages

在仓库加 .github/workflows/deploy.yml，让它在 push 到 main 时自动构建 Hugo 并部署到 GitHub Pages：

# .github/workflows/deploy.yml（关键片段）
on: { push: { branches: [main] } }
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: peaceiris/actions-hugo@v3
        with: { hugo-version: '0.140.0' }   # 锁版本，避免本地/CI 不一致
      - run: hugo --minify
      - uses: peaceiris/actions-gh-pages@v4
        with: { github_token: ${{ secrets.GITHUB_TOKEN }}, publish_dir: ./public }

关键：第一次 Actions 失败，日志显示本地与 CI 的 Hugo 版本不一致——上面 workflow 里锁定 hugo-version 即可解决（又一个"本地能跑、CI 不行"的经典环境差异）。
在仓库 Settings → Pages 把源设为 Actions 部署的分支，博客就上线在 https://你的用户名.github.io/myblog。
之后只要 Agent 把新文章 push 上来，就自动构建、自动上线。

落地后接着做

给博客接上 sitemap 和 Google Search Console，多语言文章才能被搜索引擎逐步收录——内容获客的闭环到这里才算真正合上。

30% 复盘：人类到底守住了什么

Agent 顺利完成了调研、写作、配置（约 70%，且工作量巨大）。人类守住的 30%，是"自动化"本身的健壮与安全：

30% 工程点	人类做了什么	不做会怎样
防跑偏	每阶段设确认关卡	Agent 一口气产出 25 篇错误方向的稿
批量格式	让 Agent 写校验脚本卡在提交前	1 篇格式错，整站构建失败
令牌安全	fine-grained token + 最小权限	令牌泄露则全账号仓库沦陷
环境一致	CI 里锁定工具版本	本地能构建、CI 失败

核心教训：长程 Agent 的强大在于"自己干完几小时的活"，风险也在于此——错误会被自动放大。 驾驭它不是盯着每一步，而是前置好关卡、校验和权限边界。

可复用心法与提示词模板

带得走的三条

给长程 Agent 设确认关卡：在选题/方案等分叉点强制停下等你拍板。
用硬检查约束软产出：让 Agent 写校验脚本检查自己的批量产出，不合规即中止。
令牌永远最小权限：自动化流程令牌经手多，权限越小爆炸半径越小。

通用"驾驭长程自主 Agent"提示词骨架：

目标：<总目标>。分阶段执行，每阶段结束停下等我确认再继续。
【阶段】拆成 调研/方案 → 执行 → 校验 → 提交/部署。
【规范】对批量产出写死可机器校验的硬规范。
【自我校验】提交前写校验脚本检查全部产出，不合规则中止并报告。
【安全】令牌最小权限、绝不明文写入代码/日志；不碰指定范围外文件。