TL;DR — 114 篇文章 × 4 語言 = 447 個檔案，翻譯總花費 $5.99 美元。這篇記錄三條內容管線的工程實踐：Claude Sonnet 驅動的四語翻譯管線、Whisper + Haiku 驅動的 Wiki 知識圖譜、以及 llms.txt 雙層索引的 AEO 策略。每條管線的設計核心都是同一個原則：manifest 驅動的冪等性。

2026 年 5 月 14 日，我花了三個小時手動把一篇文章翻成英文、日文、簡體中文三個版本。翻完之後才發現，repo 裡早就有一支自動翻譯腳本。

更慘的是，我的日文版用了「です/ます」敬體，但腳本內建的指引是「だ/である」常體。跟過去已經翻好的一百多篇文章的語氣完全不一致。結果三個語言版本全部重翻。

三個小時的手工活，被一行 node scripts/translate-article.mjs 取代了。這個經驗讓我認真盤點了一次自己到底建了什麼——然後發現，不知不覺間，一套還算完整的內容基礎建設已經長出來了。

manifest 驅動的翻譯管線怎麼做到 $5.99 翻 447 篇？

paulkuo.tw 的每篇文章都有四個語言版本：正體中文（主版）、英文、日文、簡體中文。114 篇主版 × 4 語言 = 447 個檔案。全部由一支 400 行的 Node.js 腳本完成翻譯，背後用 Claude Sonnet 的 Messages API。

整套系統的核心是一個 manifest 檔案（data/translation-manifest.json），記錄每篇文章的 body hash 和各語言版本的翻譯狀態。腳本每次跑的時候，先算主版文章的 body hash，跟 manifest 裡的比對——hash 一樣就跳過，不一樣就翻。

這裡有一個刻意的設計決策：hash 只算文章正文，不算 frontmatter。改封面圖路徑、改 readingTime、加 tags，都不會觸發重翻。因為翻譯的目標是正文內容，metadata 改了不影響翻譯品質。這個小決定省了不少錢——我常常修 frontmatter 但不動正文，如果每次都重翻，成本會翻好幾倍。

三個語言版本各有自己的翻譯指引，寫在 API prompt 裡：

英文走 measured、philosophical 的語氣，保留神學術語原文（Logos, Sarx, incarnation）。日文指定「だ/である」調（常體），不用「です/ます」（敬體）——這個決定是踩了前面說的那個坑之後才變成硬性規則的。簡體中文以字符層繁簡轉換為主，加必要的用語調整（軟體→软件、網路→网络），不大幅改句式。

費用呢？67 次 API 呼叫，總共 $5.91 美元。英文最便宜（輸出 token 較少），日文最貴（輸出 token 較多）。平均一篇文章三個語言版本加起來 $0.27 美元，大約台幣九塊。

有一個 bug 差點造成嚴重問題：早期版本在翻譯迴圈裡，每翻完一個語言就更新 manifest 的 sourceHash。結果翻完英文後，manifest 已經標記「已翻」，日文和簡體版就被跳過了。修正後改成三個語言全部翻完才更新 hash，一個小小的時序問題差點讓三分之二的翻譯消失。

從筆記和 YouTube 到知識圖譜：Wiki ingest 管線做了什麼？

翻譯管線處理的是「已寫好的文章」。但內容的上游——那些還沒變成文章的筆記、YouTube 影片、web clips——需要另一條管線。

paulkuo.tw 有一套 Wiki 系統，靈感來自 Karpathy 的個人知識圖譜模式。目前 312 筆已入庫的知識節點，來自四個來源：得到 App 筆記（156 篇）、網站文章自身（93 篇）、YouTube 影片（38 篇）、web clips（25 篇）。另外還有 54 篇在待審區。

每筆知識節點都有 visibility 分級。公開的（public）可以直接進 Wiki；內部的（internal）需要去識別化；私人的（private）不進 Wiki。判定規則寫在 wiki_visibility.py 裡，有一條特殊規則：tags 帶有「录音卡笔记」的筆記是會議錄音轉寫，即使在公開資料夾裡也要降級。

YouTube ingest 是技術上最有趣的一段。腳本追蹤 5 個頻道，用兩層轉錄策略：第一層用 yt-dlp 抓字幕檔（優先手動字幕，其次自動生成字幕）；如果沒有字幕，降到第二層——下載音訊檔，送 Groq 的 Whisper Large V3 Turbo 做語音轉文字。音訊超過 24MB 的話，先用 ffmpeg 壓成 mono 16kHz 32kbps opus 再送。

轉錄完的內容不直接進 Wiki。它先進 sources_pending/ 待審區，等人工確認後才晉升。晉升之後還有一道 enrichment——用 Haiku 4.5（最便宜的 Claude 模型）補上 summary、key points、quotes（帶時間戳）、concept links。這是刻意的模型選擇：enrichment 不需要 Sonnet 等級的推理能力，Haiku 做摘要和關鍵字提取綽綽有餘，成本是 Sonnet 的十分之一。

知識節點最終被 seed 到 Cloudflare KV，供 Wiki 的搜尋 API、知識圖譜視覺化、和 /api/wiki/ask 問答端點使用。

讓 AI 爬蟲讀懂你的網站：llms.txt 雙層索引和 robots.txt 策略

這是三條管線裡離「傳統內容經營」最遠的一條，但我認為它在 2026 年的重要性會越來越明顯。

paulkuo.tw 的 robots.txt 裡有 11 個被點名的 AI 爬蟲 user-agent：GPTBot、ChatGPT-User、Google-Extended、PerplexityBot、ClaudeBot、Applebot-Extended、cohere-ai、Bytespider、OAI-SearchBot、Claude-SearchBot、Perplexity-User。全部允許爬內容頁面，全部擋 /api/、/auth/、/ws/ 和管理後台。

分成兩個類別：訓練用爬蟲（GPTBot 等）和搜尋用爬蟲（OAI-SearchBot、Claude-SearchBot、Perplexity-User）。後面這組是 2026 年 5 月才新增的，因為 Answer Engine Optimization（AEO）的邏輯跟傳統 SEO 不同——你要讓 Perplexity、Google AI Overview、ChatGPT Search 能讀到你的內容，它們才會在回答使用者問題時引用你。

robots.txt 只是門票。真正的 AEO 基礎工程是 llms.txt 雙層索引，靈感來自 llms.txt 提案：

第一層 llms.txt 是輕量索引——按 pillar 分組的文章清單加上 Wiki 概念，AI 爬蟲掃一遍就能理解這個網站在講什麼。第二層 llms-full.txt 是完整全文——每篇文章的 markdown body 全部倒出來，讓需要深度理解的 AI 引擎可以一次讀完。

兩層都是 Astro build 時動態產生的。新文章上線、Wiki 新增概念，下次 build 就自動收錄。不需要手動維護索引。

這套系統在「AI 與人類秩序」這個主題裡代表一個很具體的立場：我選擇對 AI 開放，而不是封閉。11 個爬蟲全部 Allow，全站內容攤開來讓它們讀。因為在 AEO 的邏輯裡，被 AI 引用是流量來源，不是威脅。

三條管線共享的設計原則

回頭看這三條管線——翻譯、Wiki ingest、社群發布——它們看起來做的事情完全不同，但共享同一個設計地基：manifest 驅動的冪等性。

翻譯管線的 manifest 追蹤 body hash，確保同一篇文章不會被重翻。Wiki ingest 的 raw_note_id 比對確保同一篇筆記不會被重複入庫。社群發布的 social-logs/{slug}-*.json 記錄每篇文章的發布狀態，確保同一篇不會被重複排程。

冪等性為什麼重要？因為這三條管線全部可以中斷重跑。翻譯跑到一半斷了？重跑一次，已翻的會被跳過。Wiki ingest 的 cron 每天跑一次，不管前一天有沒有跑成功。社群排程如果 API 超時？重試機制自動 backoff 重送。

這是個人專案跟企業系統最大的差別：我沒有 SRE 團隊幫我顧管線，所以管線必須設計成「隨時可以壞、壞了重跑就好」。manifest 就是這個設計的核心——它讓每一步都知道自己上次做到哪裡。

另一個共享原則是模型分層。翻譯用 Sonnet（需要語言品質）、enrichment 用 Haiku（只需要摘要能力）、封面圖用 gpt-image-1（視覺生成）、轉錄用 Whisper（語音辨識）。不是所有任務都需要最強的模型。$5.99 的總成本，很大程度上是因為在每個環節都選了「剛好夠用」的模型，而不是一律用最貴的。

六美元和一個還在長的系統

把三條管線的成本加起來：翻譯 $5.91 + 封面圖 $0.08 = $5.99 美元。大約台幣 195 元。

這個數字涵蓋了 114 篇文章的三語翻譯（447 個檔案）、封面圖生成、還有所有相關的 API 呼叫。Wiki 的 Haiku enrichment 和社群發布的 freeimage 圖床是另外算的，但金額更低。Cloudflare 的 Workers、KV、R2、Pages 全部在免費額度內。

我不覺得 $5.99 這個數字本身有什麼了不起。了不起的是管線設計讓這個成本可預測、可追蹤、可控制。每一筆 API 呼叫都記錄在 costs.jsonl 裡：時間戳、模型、token 數、美元成本、台幣成本。任何一天的花費突然異常，我能在 JSONL 裡一眼看到是哪條管線、哪篇文章造成的。

這套系統還在長。Wiki 的 38 筆概念頁面還遠遠不夠（目標是 200+），YouTube ingest 才追蹤 5 個頻道，社群發布只有 X 和 Threads 真正接通了 API。但基礎建設已經在那裡——manifest、cost tracker、visibility 分級、冪等性——新增一個來源或一個平台，接上去就好。

我在 autoresearch 那篇文章裡說過，個人 IP 場景的 autoresearch 不是讓網站自己懂機器，是讓 agent 們一起懂你。這套內容基礎建設就是「一起懂你」的具體載體：翻譯管線讓四種語言的讀者懂你，Wiki 管線讓你自己的知識結構被系統化，llms.txt 讓 AI 引擎懂你。

六美元。447 篇文章。還在長。

常見問題

Q: 用 AI 翻譯文章品質夠嗎？不需要人工校對？

看語言和用途。英文版品質穩定，因為 Claude Sonnet 的英文輸出本來就強。日文版是最大的坑——腳本指定用「だ/である」常體，但手動翻譯時很容易滑進「です/ます」敬體，兩者混用讀起來很怪。簡體中文版主要做字符層繁簡轉換加用語調整。Paul 會掃一眼翻譯品質但不逐句校對，靠 manifest 系統確保源頭改了就重翻。

Q: llms.txt 是什麼？為什麼要做兩層？

llms.txt 是一個新興的標準，讓 AI 爬蟲能快速理解網站內容結構。paulkuo.tw 做了兩層：llms.txt 是輕量索引（按 pillar 分組的文章清單 + Wiki 概念），llms-full.txt 是完整內容（每篇文章的全文 markdown）。兩層都是 Astro build 時動態產生的，新文章上線自動收錄。

Q: Wiki 知識圖譜的 ingest 來源有哪些？

目前四個來源：Paul 的得到 App 筆記（156 篇）、paulkuo.tw 文章本身（93 篇）、YouTube 頻道（38 篇，5 個頻道自動追蹤）、以及 web clips（25 篇）。加上待審區 54 篇，總共 366 筆知識節點。每筆都有 visibility 分級（public / internal / private）和 sensitivity 標記。

Q: 整套管線的維運成本是多少？

截至 2026 年 5 月：翻譯 $5.91 + 封面圖 $0.08 = $5.99 美元（約 NT$195）。這是 447 個翻譯檔案 + 封面圖生成的總成本。Wiki enrichment 用 Haiku 4.5（最便宜的模型），社群發布用 freeimage（免費圖床）+ OneUp（排程工具）。Cloudflare Workers/KV/R2 在免費額度內。