TL;DR
一听“用 AI 做文章网站”，很多人会想：
让 AI 写 100 篇文章，上传，完成。
不对。
这就像买了一台复印机，然后宣布自己建成了一座图书馆。
真正要做的是：文章越来越多时，读者仍然不会迷路；旧翻译不会冒充最新版；12 种语言不会串线；链接不会烂掉；两个自动任务不会互相覆盖；出现事故后，系统还能自己发现并安全修复。
所以不要只把 AI 当成“写作机器”，而要把它当成一组 作者、编辑、检查员、图书管理员、修路队和维修人员。
整套方法可以压成 10 步：
- 先决定网站到底为了什么。
- 搭好内容存放的土地和仓库。
- 给每篇文章稳定 ID 和版本指纹。
- 先把一种语言的原文做好。
- 翻译前先 QA。
- 扩展到 12 种语言，但不要复制错误。
- 用内部链接和 Hub 建道路与服务台。
- 自动工厂看“状态”运行，而不是只看时间。
- GitHub 有文件不等于已经公开，必须验证真正的线上页面。
- 每次都和“100 分理想状态”比较，发现差距就安全修复。
如果只对 AI 说“帮我做个不错的网站”，AI 居委会很可能开心地盖三栋一模一样的房子，再修六条没有目的地的路。
最重要的不是更聪明的 AI。
而是更安全的系统。
先记住一个比喻：网站 = 图书馆 + 道路网 + 工厂
- 文章 = 一本书
- 网站 = 图书馆
- 分类 = 书架
- Hub 文章 = 总服务台
- 内部链接 = 道路
- URL = 地址
- 文章 ID = 不轻易变化的户籍号
- SHA / Hash = 某个版本的指纹
- GitHub = 放文件和历史记录的仓库
- QA = 老师的红笔批改
- 部署 = 真正把图书馆开门营业
- 监控任务 = 夜间保安
- CAS / 条件更新 = “如果现在还是第 3 版，才允许替换”
- 阶段 Token = “这个准确版本已经通过本阶段检查”的印章
理解这些比喻后，后面的技术词就只是交通规则。
1. 决定网站究竟要解决什么问题
1-1. 不要把文章数量当目标
坏目标：
每天发布 100 篇。
如果这 100 篇都在回答同一个问题、链接坏了、翻译又旧，你没有生产知识。
你只是高速生产了 100 袋垃圾。
更好的目标是描述读者能做什么：
- 很快找到答案
- 新手知道从哪里开始
- 可以自然进入更深入的文章
- 能看懂同主题文章之间的关系
- 用自己的语言也能到达同样的信息
1-2. 先写下 AI 永远不能违反的规则
例如：
- 不泄露个人信息
- 不擅自改日期和数字
- 不编造来源
- 不把旧翻译当最新翻译
- 不公开坏 URL
- 不因为日语目标不存在就把读者扔进无关英语页
- 不允许两个 worker 静默覆盖同一份工作
- 不把“AI 说完成了”当完成证据
这些就是工厂护栏。
1-3. 写出“100 分理想状态”
一旦理想状态具体化，AI 就可以回答：
现在几分？
哪些地方扣分？
哪些可以安全修？
修完后再打几分？
这就是 QC，也就是质量管理的基本循环。
2. 搭好内容的土地和仓库
2-1. 最小配置
初学者先准备：
- 域名
- GitHub
- Web 框架
- 托管
- 分析工具
Astro、Next.js、Eleventy 等都可以。品牌不重要，重要的是：
把文章数据和负责显示页面的程序分开。
2-2. 原始内容和生成结果分层
不要让所有自动任务直接修改原文。
最好分开保存：
- 原始文章
- AI 编辑版本
- 翻译
- 内部链接 Overlay
- QA 证据
- 发布状态
这就像厨房不会让所有厨师直接在冰箱里的生肉上乱倒酱汁。
备料、烹饪、摆盘、检查要分开。
2-3. 把 Git 历史当时间机器
自动化应该：
- 每次改动小而明确
- 记录为什么改
- 禁止强制覆盖
- 长批次保存 checkpoint
出问题时才能回看之前的状态。
3. 给每篇文章固定身份和版本指纹
3-1. 不要只靠 URL 识别文章
URL 和标题都可能变。
逻辑文章应有稳定 ID，例如：
articleFamilyId = article_000123
如果日语、英语、韩语是同一篇逻辑文章，它们共享 family ID。
3-2. locale 单独作为一个维度
article_000123 + ja
article_000123 + en
article_000123 + ko
这样系统就能精确表示：
- 英语旧了
- 韩语缺失
- 日语今天刚更新
- 法语还是 current
3-3. Hash 是版本指纹
正文变化，指纹也变化。
于是可以回答：
这份英语翻译到底是根据哪个日语版本做的？
日语更新了，而英语仍指向旧指纹，那么英语就是 stale。
不需要听 AI 解释心情，证据已经说明问题。
3-4. 给文章明确状态
例如：
- 草稿
- 原文 QA 通过
- 翻译中
- 翻译 QA 通过
- 导航验证完成
- 可发布
- 已发布
- 已过期
状态机是后面自动化的骨架。
4. 先把一种语言的原文真正做好
4-1. 不要翻译坏原文
坏原文一旦翻成 11 种语言，就是把 bug 国际化。
恭喜，错误拥有了全球发行渠道。
先把一个源语言版本完成。
4-2. 好文章的最低标准
- 标题清楚说明解决什么
- 开头快速回应读者问题
- 只看标题也能理解文章流程
- 难词马上解释
- 有具体例子
- 保留数字、日期、专有名词和不确定性
- 区分事实与观点
- 需要时有来源
- 没有个人信息
- 少重复
- 少“AI 模板腔”
4-3. 笑点应该帮助理解
例如：
把坏原文翻成 11 种语言，就像把一栋歪房子再复制 11 栋。
好笑，但也能记住规则。
与正文完全无关的段子太多，就变成了在道路施工中央表演节目。
5. 翻译之前先 QA
5-1. “生成了”不等于“完成了”
AI 输出只是交作业，不是拿到满分。
至少检查：
- 标题与正文一致
- 事实没变
- 日期、价格、单位正确
- URL 存在
- 引用和来源没坏
- Markdown / HTML 正常
- 标题层级合理
- 个人信息已移除
- 没新增危险断言
- 没和已有文章严重重复搜索意图
5-2. 保存证据，不只保存绿灯
记录：
- 文章 ID
- 原文指纹
- 输出指纹
- QA 结果
- 改了什么
- 根据哪条规则通过
“作业写了吗？”
“写了。”
证据很弱。
“把本子拿出来。”
这就强多了。
5-3. 一篇失败不要停掉整个工厂
100 篇里有 1 篇不能安全处理：
- 延后那 1 篇
- 保存原因
- 继续别的 eligible 项目
少一颗螺丝不需要全城停电。
6. 扩展到 12 种语言
6-1. 固定支持的 locale
例如：
ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de
固定集合能让 URL、QA、hreflang、sitemap 和内部链接更一致。
6-2. 每种语言使用独立 URL
/ja/articles/...
/en/articles/...
/ko/articles/...
再使用 hreflang 告诉搜索引擎这些页面是同一内容的不同语言版本。
6-3. 还能用的翻译就复用
- current → 复用
- stale → 只更新这个 locale
- missing → 新建
每次全部重翻不仅浪费钱，还会制造更多事故入口。
6-4. 不要复制日语语序
翻译不是替换单词。
各语言要独立调整：
- 句子长度
- 标题
- 转折
- 笑点
- 链接文字
- 说明顺序
意义保持一致，表达形式要自然。
6-5. 按文章 × locale 独立 QA
英语通过不代表泰语通过。
一个 locale 失败时，应只延后那个 locale。
7. 用内部链接和 Hub 建道路和服务台
7-1. 不要为了凑数量加链接
好链接文字应该告诉读者目的地是什么。
好：
新手可以先看“视黄醇浓度怎么选”。
坏：
点击这里。
路牌上只写“那边”，基本等于没写。
7-2. 区分链接类型
至少分为：
- Hub 结构链接 — 服务台到详细文章
- 正文上下文链接 — 句子里的自然参考
- 相关文章 — 下一篇建议
- 语言切换 — 同一文章的另一语言
- 面包屑 — 返回上层结构
全部塞进一个“链接”桶里，规则早晚会打架。
7-3. 内容导航保持同语言
日语目标不存在时，不要自动 fallback 到英语内容页。
“换语言”和“换主题”是两件不同的事。
7-4. Hub 不是 URL 仓库
一个好的 Hub 会解释：
- 主题范围
- 适合谁
- 新手先看哪里
- 主要子主题
- 不同问题该读哪篇详细文章
竖着放 20 个裸链接，只是员工下班后把路线图留在椅子上的服务台。
7-5. 先看能否把已有大文章升级为 Hub
否则很容易出现：
- 完整指南
- 终极指南
- 总指南
- 全部都懂指南
一起争抢同一个搜索意图。
这不是信息架构，是站内 SEO 大逃杀。
7-6. 机器候选 + 语义审核
大规模网站可以使用：
- 文章语义
- 链接图
- 用户实际移动
- 搜索意图
- 重复风险
来生成候选。
但正式应用前，应返回人能理解的“为什么相关”证据，而不是神秘分数。
8. 自动工厂按状态运行，不只按时间
8-1. Schedule 只是闹钟
可以安排：
- 02 分 Hub
- 07 分原文
- 27 分翻译
- 37 分内部链接
- 58 分发布
但是不能因为到了 27 分就假设原文一定完成。
时间负责叫醒 worker。
状态负责授权工作。
8-2. 查看上游印章
翻译前检查：
- 原文 current
- QA current
- ID 一致
- 指纹一致
内部链接前检查：
- locale 正文 current
- route current
- 质量 current
发布前还要看 SEO 和验证证据。
8-3. 使用内容寻址 Stage Token
不要只存：
done = true
更强的是把这些内容组成 token：
article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token
上游变化后，下游旧 token 自动变 stale。
8-4. 用条件更新/CAS 防止并发覆盖
两个 AI 同时读到第 3 版。
A 写成第 4 版。
B 又拿第 3 版结果覆盖。
A 的成果没了。
所以规则是：
只有资源仍然是我刚才读到的版本时，才允许写入。
否则重新读取或 defer。
8-5. 保存 checkpoint
目标 50 篇时，每完成几篇就保存。
跑到 20 停了，下次从 21 继续，不要从 0 重来。
游戏几十年前就教会我们的强技术：存档。
9. GitHub 有提交，不代表已经公开
9-1. 发布是一个链条
内容完成
↓
翻译 current
↓
导航验证
↓
validation 通过
↓
允许发布
↓
deploy
↓
检查线上 HTML
↓
production verified
9-2. 不强行公开未完成语言
一个 locale stale 时，可以只让它等待。
其他可发布 locale 是否继续，由正式发布政策决定。
9-3. 检查 SEO 管道
- title
- description
- canonical
- hreflang
- sitemap
- robots/indexability
- structured data
- 404/redirect
- internal links
多语言 URL 很容易接错线。
9-4. 实际抓取生产 URL
有 commit、build 通过、deploy 成功，仍然不够。
实际 URL 要确认：
- HTTP 200
- 最新正文
- 正确语言
- title/meta
- canonical/hreflang
- 内部链接正常
不要把饭盒放在自己家门口就宣布“送餐完成”。
10. 让网站不断回到 100 分
10-1. QC 循环
观察
↓
评分
↓
找差距
↓
分根因
↓
安全修复
↓
重新测试
↓
重新评分
10-2. Hard Gate 防止刷分
即使加权得分是 100，只要存在以下一项，也不能说 100 分：
- broken link
- cross-locale 内容误链
- stale 翻译当 current
- 不存在的 Hub member
- formal success 重复计算
- lost update
- 假验证证据
10-3. 重复事故要修工厂，而不只是修产品
同类问题反复出现时检查：
- contract 不足？
- validator 不足？
- state 模型不足？
- 并发保护不足？
- schedule 冲突？
- 外部基础设施？
目标从“修坏掉的产品”升级成“让工厂更少生产坏产品”。
10-4. 100 分也不能关闭监控
今天 100 分，明天新文章加入后可能变 98。
没问题。
自动巡检再把 98 修回 100。
昨天没小偷，不代表今天可以把门锁扔掉。
30 秒看懂全系统
人类定义目标和禁区
↓
100分理想状态
↓
AI制作原文
↓
QA + 证据
↓
扩展11种语言
↓
locale独立QA
↓
内部链接 + Hub
↓
状态/指纹/token检查
↓
验证
↓
发布政策
↓
部署
↓
真实URL/HTML验证
↓
用户行为测量
↓
与100分比较
↓
安全修复
└────→ 循环
AI 文章网站最常见的 10 个事故
- 做了 100 篇，30 篇在回答同一问题
- 错原文被翻译成 12 种语言
- 翻译文件存在，但已经 stale
- 日语页突然跳进英语相关文章
- Hub 太多，最后“服务台”本身成了目的地
- 所有锚文本都是“点这里”
- 两个 AI 同时覆盖同一文章
- 目标 50，完成 1 个就宣布结束
- 把 Git commit 当成生产公开
- 监控发现问题，于是把监控关掉
第 10 条相当于烟雾报警器响了，于是拔掉报警器电源。
最小实现检查表
设计
- ☐ 定义读者目标
- ☐ 写出100分理想状态
- ☐ 写出绝对禁止规则
- ☐ stable article ID
- ☐ locale 独立维度
- ☐ content hash
内容
- ☐ 原文 QA
- ☐ 隐私去除
- ☐ 事实/数字/URL保护
- ☐ 具体例子
- ☐ 减少AI模板腔
多语言
- ☐ 每种语言独立URL
- ☐ hreflang
- ☐ 记录源文指纹
- ☐ 只更新stale locale
- ☐ locale独立QA
- ☐ 禁止cross-locale内容fallback
链接/Hub
- ☐ Hub结构链接与正文链接分离
- ☐ 描述性anchor
- ☐ orphan audit
- ☐ broken/self/duplicate/cross-locale audit
- ☐ 新建Hub前检查已有文章能否升级
- ☐ duplicate Hub audit
自动化
- ☐ state/hash/token控制下游
- ☐ claim/CAS
- ☐ checkpoint
- ☐ exactly-once formal success
- ☐ 单个失败不停止全体
发布
- ☐ validation
- ☐ canonical/hreflang/sitemap
- ☐ 发布政策
- ☐ 实际线上URL
- ☐ 实际线上HTML
运维
- ☐ 定期100分审计
- ☐ hard gate
- ☐ 重复事故修根因
- ☐ 达到100分后继续监控
最后的结论
最强的 AI 文章网站，不是用了最贵模型的网站。
而是当 AI 出错、内容过期、任务并发、外部服务故障时，仍然能发现错误并回到正确状态的网站。
人类负责：
- 目标
- 理想状态
- 边界
- 最终责任
AI负责：
- 生成
- 比较
- 检查
- 修复
- 记录
真正的完成证据交给：
- Hash
- Test
- Git 历史
- 真实 URL
- 真实 HTML
- 读者行为
做到这里，“博客”已经变成一个放在 Git 仓库里的小型出版社 + 图书馆 + 道路管理局 + QC 工厂。
从一篇文章开始就行。
先给它固定 ID。
再做 QA。
再加一种语言。
再安全地加链接。
再记录状态。
一层层搭。
第一天不需要造空间站。
但也不要买 100 台复印机后宣布“空间站竣工”。
