A 版本结构最好，但有几段翻译太生硬；B 版本某几段特别出彩，但漏了关键信息；C 版本信息最全，但读起来像机器翻的。
怎么把它们的优点合到一起？
手动合并：能用，但费事
最直觉的做法：先通读所有版本，选一篇整体最好的当基础，然后逐段比较其他版本，看到更好的就替换，看到缺失的就补进去，最后通读润色，消除拼接痕迹。
效果还行，但费时间。三四个版本比来比去很消耗注意力，而且人工比较容易漏东西——某个版本里一个很好的细节可能就这么错过了。
让 AI 来做合并
AI 擅长处理大量文本，这种"比较多个文本、提取差异、执行合并"的任务其实非常适合它。
把所有版本一起发给 AI，配上这样的指令：
- 阅读所有稿子，选一篇最好的作为基础
- 逐一审阅其他稿子，找出亮点和基础版本缺失的部分
- 把这些内容融合到基础稿里
- 对合并后的全文做一遍润色，消除拼接痕迹
说实话效果出乎意料地好。它不会漏掉某个版本的独特内容，合并后的风格也比手动拼接更统一。
这里有个小经验：用支持推理的模型效果更好，比如 Claude 的扩展思考模式，或者 GPT-5 thinking 这类推理模型。因为合并不是简单的复制粘贴，需要判断哪段更好、怎么融合才自然，这些都需要推理能力。
用聊天界面就能做，把所有稿子和指令一起发过去。如果你用 Claude Code 这样的命令行 Agent 工具，可以直接指定文件路径，它会自己读取文件然后执行合并，操作上更方便。
重复的工作应该固化成 Skill
上面的方法好用，但每次合并都要重新输入那段提示词。
如果你经常做多稿合并，更好的做法是把它做成一个 Skill。Skill 是 Claude Code 的一种能力扩展机制——你可以把一套工作流程写成一个 Skill 文件，之后每次只需要说"合并这几篇稿子"，它就会自动按照你定义好的流程执行。不用重复输入提示词，也不用担心某次漏掉步骤。
创建 Skill 的两种方式
方式一：先手动做一遍，再固化
在 Claude Code 里先手动走一遍完整的合并流程。稿子发过去，让它选基础稿、提取亮点、合并、润色，做完检查结果，觉得满意后在同一个对话里说：
/skill-creator 把刚才的操作流程固化成一个 Skill。
因为 AI 已经走过一遍完整流程了，它很清楚每一步该做什么。从实际操作中提炼出来的 Skill，通常比凭空描述的更准确。
优点：对最终效果有直观感受，能在固化之前就发现问题。缺点：得先花时间做一遍。
方式二：直接描述需求，让 AI 创建
如果你已经很清楚流程，可以直接告诉 Skill Creator：
/skill-creator 为当前项目添加一个 skill，可以用来把多份稿子合并成一份稿子。流程如下：
阅读所有提供的稿子
选一份最好的稿子作为基础
将其他稿子中有价值的内容或者基础稿子缺失的重要部分加入到基础稿
对完成后的稿子润色
参考输入（这个例子只有 2 份稿子，通常至少 2 份，也可能超过 2 份）：
posts/2026-03-01/jenny-wen-design-process/draft1.md
posts/2026-03-01/jenny-wen-design-process/draft2.md
Skill Creator 会根据描述生成完整的 Skill 文件，包括触发条件、输入格式、工作流程、输出规范。
这种方式更快，适合流程已经想清楚的情况。缺点是没有实际案例参照，生成的 Skill 可能需要多跑几次才能调到满意。
怎么选？
- 流程不确定、任务没做过 → 方式一，先手动做一遍再固化
- 反复做过很多次、流程很清晰 → 方式二，直接描述需求
- 两种也可以结合：方式一做出初版，用几次发现优化点后，再用方式二调整
一个实际在用的合并 Skill
下面是一个多稿合并 Skill 的完整示例：
---
name: merge-drafts
description: 多稿合并技能。将多份草稿合并为一份高质量文章。阅读所有稿子，选最佳稿为基础，融合其他稿子的亮点和缺失内容，最终润色输出。当用户要求"合并稿子"、"合稿"、"merge drafts"、"把这几篇合成一篇"、"综合这几份稿子"时使用此技能。
---
# 多稿合并技能
## 写作风格
本技能遵循 `writing-style` 技能定义的写作规范。
## 输入
接收 2 份或以上草稿文件路径。同时读取同目录下的 analysis.md（如有）作为素材参考。
## 工作流程
步骤一：阅读所有稿子，快速评估每份的结构、信息覆盖面、表达质量和独特亮点。
步骤二：选一份最佳稿作为基础。标准是结构最清晰、信息最全、表达最好、以它为基础改动最小。
步骤三：逐一审阅其他稿子，提取缺失内容、更好的表达、独特角度和数据案例。
步骤四：在基础稿上合并。补充缺失内容，替换更好的表达，融合不同视角，统一风格。原则是融合而非拼接，合并后读起来像一个人写的。
步骤五：润色。重点检查拼接痕迹、风格统一、重复内容、逻辑连贯。
步骤六：输出合并报告，说明基础稿选择理由、各稿贡献了什么、主要修改了哪些内容。
几个设计上值得注意的地方：
- description 字段列了多种触发方式，中英文都有，不管你说"合稿"还是"merge drafts"，Claude 都能识别
- 步骤四的合并原则是关键："融合而非拼接，合并后读起来像一个人写的"——这条规则直接决定了合并质量
- Skill 可以引用其他 Skill，比如这里引用了
writing-style来控制写作风格，合并出来的文章会自动遵守你预设的风格规范
你完全可以根据自己的需求调整：加字数限制、指定输出文件名规则，或者增加一个"让用户确认基础稿选择"的交互步骤。
不只是合并——任何重复工作都可以 Skill 化
多稿合并只是一个例子。判断标准很简单：如果你发现自己在复制粘贴之前用过的提示词，或者每次都要跟 AI 解释一遍同样的流程，那就该做成 Skill 了。
翻译完要按固定格式排版？做成 Skill。写完文章要按检查清单自查？做成 Skill。每次发布前要生成摘要和封面图？做成 Skill。
Skill 文件本质上就是一个 Markdown 文档，包含 YAML 格式的元信息（名字和触发描述）和 Markdown 格式的正文指令。不需要写代码，会写清楚步骤就行。想更强大的话，可以在里面引用其他 Skill、指定文件管理规则、添加自动执行的脚本——但起步阶段，一个清晰的工作流程描述就够了。