baoyu-translate 适合将已有文章转换为另一种语言，同时保留 Markdown 结构和术语一致性。它把目标读者、表达风格与翻译模式分开设置，长文还能分块处理；最后仍需要检查事实、数字与原文限定条件。
安装与调用
在项目目录的终端运行下面的命令，只安装这个 Skill 到 Claude Code：
npx skills add jimliu/baoyu-skills --skill baoyu-translate -a claude-code
需要 Node.js 和可用的 npx。若使用 Codex，把 -a claude-code 换成 -a codex；在对话里明确要求使用 baoyu-translate 并附上材料，不把终端安装命令当成任务提示。其他客户端应使用自身的技能选择入口。
首次先把偏好说明白
没有配置时，工作流会先询问目标语言、模式、读者、风格和保存位置，再写入 EXTEND.md。项目级配置是 .baoyu-skills/baoyu-translate/EXTEND.md，优先于用户目录配置。普通技术文档最好明确选择准确、简洁的风格，不让默认叙事语气改变原稿感觉。可以这样输入：
使用 baoyu-translate 翻译 guide.md 到 en，采用 refined 模式。
读者是开发者，style 选 technical，术语表使用 glossary.md。
保留代码、URL、数字和原文的不确定性，解释性补充需与原文区分。
先完成首次偏好配置，然后输出译文和审校记录。
快速模式直接翻译，常规模式先分析再译，精修模式还会产生批评、修订与润色步骤。选择取决于稿件用途，不是所有短消息都需要精修，也不能把模式名称当成质量已经保证。
找到正确的输出并检查重点
最终文件固定叫 translation.md，位于原文件旁以目标语言结尾的目录中。常规与精修会保存分析和共享提示，精修还保留 03-draft.md、04-critique.md、05-revision.md，便于比较哪些地方被改过。
长文常规或精修模式达到阈值后会按 Markdown 结构分块，并使用共享术语与上下文；快速模式不自动分块。脚本的 main.ts 主要负责切分，不能把单独运行它理解成已经完成翻译。分块完成后尤其要核对段落衔接、重复标题和术语是否一致。
检查数字、单位、否定、条件句、链接和代码，确认自然表达没有扩大原文结论。图片引用虽然保留，图内的标题与标签可能仍是原语言，需要单独处理，不能让英文正文配一张未检查的中文关键步骤图就认为本地化结束。分享时选择最终译文，审校文件留作修改依据；若后续原稿更新，应明确翻译对应的版本。
一个技术更新公告的翻译检查法
假设原文说“新接口可能在下季度开放，当前仅在测试环境可用”。给出读者是开发者、语言方向和 technical 风格后，要求译文保持“可能”“下季度”“仅测试环境”三个限定词；精修模式也不能把谨慎表述改成已正式上线。把产品名、命令行参数和错误码放进术语表，并指明遇到未定译法时保留原词与注释。译完先读最终 translation.md，再抽查这些高风险句子与源文是否一一对应。
如果常规模式完成后只少数段落别扭，可以在原输出上继续 review 与 polish，不需要从头重翻整篇。长文分块时，用开头、中间和末尾各一段检查术语、代词指向与衔接；章节之间重复的小标题可从最终文件中发现。审校文件有助于追踪改变，但不能让“润色”引入来源没有的数据。原文改版时记下使用的源文件版本，否则几个月后很难判断某个译句是笔误还是旧信息。
长文先确认分块成功
长文翻译先确认分块真的完成，再审译文。一个使用者在旧版环境中给 Obsidian 摘录 Markdown 分块时，Bun 启动了却因 unist-util-visit-parents/do-not-use-color 依赖解析失败，没有生成预期的 chunks/。遇到类似报错，先记下 Bun、Node 和 Skill 版本，检查是否确实产生分块文件与 frontmatter；不要把“命令开始运行”当作翻译已开始。该问题记录已关闭，当前版本应先按最新安装说明重试；若仍复现，再隔离原始文件并按错误模块排查。