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 在免费额度内。