TL;DR
一聽到「用 AI 做文章網站」，很多人第一反應是：
叫 AI 寫 100 篇文章，上傳，完成。
不是。
這就像買了一台影印機，然後宣布自己蓋好了一座圖書館。
真正要做的是：文章越來越多時，讀者仍然不迷路；舊翻譯不會假裝是最新版；12 種語言不會互相串線；連結不會壞掉；兩個自動工作不會互相覆蓋；出事故時，系統能自己發現並安全修復。
因此不要只把 AI 當「寫文章機器」，而要把它當作一組 作者、編輯、檢查員、圖書館員、道路施工隊、維修人員。
整套系統可理解成 10 步：
- 先決定網站到底為了什麼。
- 建好內容要放的土地與倉庫。
- 給每篇文章穩定 ID 和版本指紋。
- 先把一種語言的原文做好。
- 翻譯前先做 QA。
- 擴展到 12 種語言，但不要把錯誤一起複製。
- 用內部連結與 Hub 建道路和服務台。
- 自動工廠看「狀態」運作，不只看時間。
- GitHub 有檔案不等於真的公開，必須檢查正式環境頁面。
- 每次和「100 分理想狀態」比較，差多少就安全修多少。
如果只對 AI 說「幫我做個好網站」，AI 里長伯可能會很開心地蓋三棟一樣的房子，再鋪六條沒有終點的路。
重要的不是更聰明的 AI。
是更安全的系統。
先用一個比喻理解：網站 = 圖書館 + 道路網 + 工廠
- 文章 = 一本書
- 網站 = 圖書館
- 分類 = 書架
- Hub 文章 = 綜合服務台
- 內部連結 = 道路
- URL = 地址
- 文章 ID = 不輕易改變的戶籍號碼
- SHA / Hash = 某一版本的指紋
- GitHub = 保存檔案與歷史的倉庫
- QA = 老師的紅筆檢查
- 部署 = 真正把圖書館開門營業
- 監控 routine = 夜間警衛
- 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 framework
- Hosting
- Analytics
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 說明這些 URL 是同內容的語言版本。
6-3. 還能用的翻譯就重用
- current → 重用
- stale → 只更新該 locale
- missing → 新增
每次全部重翻，既浪費錢，也增加事故表面積。
6-4. 不要複製日文語序
翻譯不是單字替換。
每種語言要獨立調整：
- 句長
- 標題
- 轉折
- 笑點
- 連結文字
- 說明順序
意義相同，表達自然。
6-5. 按文章 × locale 獨立 QA
英文通過不代表泰文通過。
某一 locale 失敗時，只延後那個 locale。
7. 用內部連結與 Hub 建道路與服務台
7-1. 不要為了湊數加連結
好的 anchor 應讓讀者知道目的地是什麼。
好：
新手可以先看「視黃醇濃度怎麼選」。
壞：
點這裡。
路牌只寫「那邊」等於沒寫。
7-2. 分開連結類型
至少：
- Hub 結構連結 — 服務台 → 詳細文章
- 正文脈絡連結 — 句子中的自然參考
- 相關文章 — 下一篇建議
- 語言切換 — 同文章另一語言
- 麵包屑 — 返回上層結構
全部放進同一個「連結桶」，規則早晚會撞車。
7-3. 內容導航保持同語言
日文目標不存在時，不要自動 fallback 到英文內容頁。
「換語言」和「換主題」是不同動作。
7-4. Hub 不是 URL 倉庫
好的 Hub 會說明：
- 主題範圍
- 適合誰
- 新手從哪開始
- 主要子主題
- 不同問題該看哪篇詳細文
垂直排 20 個裸 URL，只是員工下班後把路線圖留在椅子上的服務台。
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
更強的是把：
article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token
組成 token。
上游一變，下游舊 token 就自動 stale。
8-4. 用條件更新 / CAS 防止並發覆蓋
兩個 AI 同時讀第 3 版。
A 寫成第 4 版。
B 又拿第 3 版結果覆蓋。
A 的成果消失。
所以規則是：
只有資源仍是我剛才讀到的版本時，才允許寫入。
否則重新讀或 defer。
8-5. 保存 checkpoint
目標 50 篇時，每幾篇保存一次。
跑到 20 停掉，下次從 21 繼續，不要從 0 重來。
遊戲幾十年前就教過我們：記得存檔。
9. GitHub 有 commit，不代表真的公開
9-1. 發布是一條流程
內容完成
↓
翻譯 current
↓
導航驗證
↓
validation 通過
↓
允許發布
↓
deploy
↓
檢查正式環境 HTML
↓
production verified
9-2. 不強迫未完成 locale 上線
某 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
- 假 validation 證據
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 太多，最後服務台本身變目的地
- 所有 anchor 都是「點這裡」
- 兩個 AI 同時覆蓋同一文章
- 目標 50，成功 1 篇就宣布完成
- 把 Git commit 當成正式公開
- 監控發現事故，所以把監控關掉
第 10 條等於煙霧警報器響了，於是拔掉警報器電源。
最小實作 Checklist
設計
- ☐ 定義讀者目標
- ☐ 寫出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 台影印機後宣布「太空站竣工」。
