Concise Summary简洁概述
When you generate multiple AI drafts (different models, runs, or prompts), each version tends to excel at something different and none is complete — the practical fix is to have an AI compare and merge them, rather than doing it by hand.
Manual merging works but doesn't scale with draft count; reasoning-capable models (Claude extended thinking, GPT-5 thinking) handle the compare-extract-merge task reliably because it requires judgment, not just text copying.
用 AI 生成多个版本（不同模型、不同次运行、不同提示词）时，每版各有亮点却没有一版完美——更实际的做法是让 AI 来比较、合并，而不是人工逐段拼接。
手动合并可行但随稿子数量增加会失控；带推理能力的模型（Claude 扩展思考、GPT-5 thinking）能可靠完成「比较-提取-合并」，因为这需要判断，不只是文本搬运。
Infographic信息图
The problem: no version is complete
问题起点：没有一份稿子是完整的
Running the same prompt across multiple models or prompt variants produces drafts that each nail different things — one has the best structure, another the best phrasing, a third the most complete information. None is usable as-is, and each has something worth keeping.
同一任务用不同模型或不同提示词各跑一遍，会得到结构最好、表达最好、信息最全但各有短板的多个版本。任何一版单独拿出来都不够用，但每一版都有值得保留的部分。
Manual merge: works, but doesn't scale
手动合并：能用但不划算
The author's original method — pick a base draft, copy over stronger passages from the others, then smooth the seams — works but is attention-heavy and error-prone: with three or four drafts, subtle standout details from any single version are easy to miss.
作者最初的做法是选一篇基础稿，逐段从其他稿子里搬运更好的表达，再统一润色接缝。效果不错，但费注意力，稿子一多就容易漏掉某个版本里的亮点细节。
Delegating comparison to AI
把「比较-提取-融合」交给 AI
The insight is that compare/extract/merge is exactly the kind of large-context, multi-document reasoning task LLMs handle well — provided the model has extended reasoning (Claude's extended thinking, GPT-5 thinking), because merging requires judgment calls, not copy-paste.
核心洞察是：比较多份文本、提取差异、执行融合，正是 LLM 擅长处理的大上下文多文档推理任务——但前提是用带推理能力的模型（如 Claude 扩展思考、GPT-5 thinking），因为合并需要判断取舍，不是简单复制粘贴。
Turning a repeated prompt into a Skill
把重复的提示词固化成 Skill
Once the merge prompt is being retyped every time, that's the signal to encode it as a Skill: a Markdown file with YAML trigger metadata and a step-by-step instruction body, invoked by natural phrases like "merge these drafts" instead of re-explaining the process.
当同一段合并提示词被反复重新输入，就是该固化成 Skill 的信号：一个带 YAML 触发元信息和分步指令正文的 Markdown 文件，之后一句「合并这几篇稿子」即可触发，无需每次重新解释流程。
Detailed Summary详细解读
The article opens from a familiar friction point: generating several AI drafts of the same piece (via repeated runs, different models, or different prompts) reliably produces drafts that are each partially good — one has the best overall structure but awkward sentences, another nails a few key passages but drops important information, a third is comprehensive but reads mechanically. The natural question, "how do you combine their strengths," frames the rest of the piece as a search for a better synthesis process, not just a better single generation.
The author's original manual method is described plainly: pick the strongest overall draft as base, go section by section comparing against the others, copy over better passages or missing information, then do a final polish pass to smooth the seams so the result reads as one voice. This works, but the piece is honest about its cost — it's attention-intensive, and scales poorly: with three or four drafts to cross-check, a standout detail buried in one version is easy to overlook during manual comparison.
The pivot is recognizing that compare/extract/merge across multiple long texts is exactly the shape of task LLMs are good at — feeding all drafts plus a structured four-step instruction (pick base, review others for gaps and highlights, fold them in, polish) into a single reasoning-capable model. The key caveat is explicit: this only works well with extended-thinking models (Claude's extended thinking mode, GPT-5 thinking), because merging is a judgment task — deciding which passage is better and how to integrate it naturally — not a mechanical copy operation, so it benefits from visible intermediate reasoning.
The second half shifts from "a better one-off technique" to "infrastructure": once you're retyping the same merge prompt repeatedly, that repetition is the signal to encode it as a Claude Skill — a Markdown file combining YAML trigger metadata (phrases like "合并稿子", "merge drafts") with a plain-language instruction body. Two creation paths are laid out: codify-after-doing (run the process manually once via /skill-creator, letting the AI extract a Skill from an observed successful execution) versus describe-upfront (directly specify the desired workflow to the Skill Creator without a prior manual run).
The concrete Skill example — merge-drafts — is broken into six steps (assess drafts, pick base, extract highlights from others, fold in via fusion not stitching, polish for seams/repetition/coherence, output a merge report explaining choices) and is shown composing with another Skill (writing-style) for tone control. The explicit rule "fuse, don't stitch — the result should read as written by one person" is flagged as the single most load-bearing instruction determining merge quality.
The piece closes by generalizing the pattern beyond draft-merging: any recurring AI interaction — fixed post-translation formatting, a self-review checklist, generating summaries and cover images before publishing — is a Skill candidate. The diagnostic test offered is simple and memorable: if you catch yourself pasting a previously-used prompt or re-explaining the same process to the AI, that's the trigger to formalize it, and doing so requires no code, just a clearly written step-by-step Markdown document.
文章从一个常见痛点切入：对同一篇内容反复用 AI 生成多个版本（多次运行、不同模型、不同提示词），几乎总会得到「各有优点但都不完整」的结果——A 版结构最好但个别段落生硬，B 版某几段特别出彩却漏了关键信息，C 版信息最全却读着像机器翻译。「怎么把这些优点合到一起」这个问题，把全文的重点定在了「更好的合并流程」上，而不是「更好的单次生成」。
作者原本的手动方法很直白：选一篇整体最好的做基础，逐段与其他版本比对，把更好的表达或缺失的信息搬进来，最后通读润色，消除拼接痕迹。文章坦承这个方法虽然有效但代价不小——非常消耗注意力，而且随着稿子数量增加（三四份互相比对）容易漏掉某个版本里藏着的亮点细节，这是人工比较的固有局限。
关键转折在于意识到「比较多份长文本、提取差异、执行合并」正好是 LLM 擅长处理的任务类型：把所有稿子和一段结构化的四步指令（选基础稿、审阅其他稿找亮点和缺失、融合进基础稿、通篇润色）一起交给一个带推理能力的模型。文中特别强调了一个前提：这只在扩展思考类模型（Claude 扩展思考模式、GPT-5 thinking）上效果好，因为合并本质是判断任务——判断哪段更好、怎么融合才自然——而不是机械复制粘贴，需要可见的中间推理过程支撑。
文章后半部分从「更好的单次操作」转向「基础设施」：一旦发现自己在反复重新输入同一段合并提示词，这个重复本身就是该把它固化成 Claude Skill 的信号——一个结合 YAML 触发元信息（如「合并稿子」「merge drafts」等触发短语）和自然语言指令正文的 Markdown 文件。文中给出两条创建路径：先手动走一遍再用 /skill-creator 固化（让 AI 从一次成功执行中提炼流程），或者直接向 Skill Creator 描述期望的工作流（无需先手动跑一遍）。
文中给出的具体 Skill 示例——merge-drafts——被拆成六步（评估各稿、选基础稿、提取其他稿亮点、以融合而非拼接的方式加入、检查拼接痕迹和重复内容并润色、输出说明各稿贡献的合并报告），并展示了它如何组合引用另一个 Skill（writing-style）来控制文风。文中特别标出「融合而非拼接，合并后要读起来像一个人写的」这条规则，认为它是决定合并质量的关键一条。
结尾把这个模式泛化到「多稿合并」之外：任何反复出现的 AI 交互——翻译后固定排版、写完按清单自查、发布前生成摘要和封面图——都是 Skill 的候选场景。文中给出的判断标准很简单也很好记：如果发现自己在复制粘贴以前用过的提示词，或者每次都要向 AI 重新解释一遍同样的流程，那就该固化了；而固化本身不需要写代码，只需要一份写清楚步骤的 Markdown 文档。
FAQ常见问答
Why does the AI-merge approach need a reasoning model specifically?为什么 AI 合并这一步必须用带推理能力的模型？
Merging requires judging which passage is better and how to integrate it naturally, not just copying text — that judgment benefits from visible intermediate reasoning, which extended-thinking models like Claude's or GPT-5 thinking produce and plain models don't.
合并需要判断哪段表达更好、怎样融合才自然，而不是简单复制文本——这种判断依赖可见的中间推理过程，只有 Claude 扩展思考、GPT-5 thinking 这类推理模型才能产出，普通模型难以胜任。
What's the actual difference between a Skill and just saving a prompt in a text file?Skill 和把提示词存在文本文件里有什么本质区别？
A Skill has YAML trigger metadata that lets Claude auto-invoke it from natural phrasing ("merge these drafts") without the user pasting anything, and can compose with other Skills (like referencing writing-style) — a saved prompt requires manual copy-paste and has no composition mechanism.
Skill 带有 YAML 触发元信息，能让 Claude 从自然语言（如「合并这几篇稿子」）自动触发，无需用户手动粘贴，并且可以组合引用其他 Skill（如引用 writing-style）；单纯存的提示词需要手动复制粘贴，也没有组合机制。
How does the author decide which creation path (codify-after vs. describe-upfront) to use?作者怎么决定用「先做后固化」还是「直接描述」这两种创建方式？
If the workflow is new or uncertain, do it manually once first so you learn which steps matter, then codify it; if you've already done it repeatedly and the process is clear, describe it directly to save the manual-run time.
如果流程还不熟悉或是第一次做，先手动走一遍摸清哪些步骤关键，再固化；如果已经反复做过很多次、流程很清楚，就直接描述需求给 Skill Creator，省掉手动执行的时间。
Does the piece give evidence that AI-merged drafts are actually better than manually merged ones, or just that they're faster?文章有没有证据证明 AI 合并的结果比人工合并更好，还是只是更快?
The claims are qualitative and anecdotal — "unexpectedly good," "more consistent style," "doesn't miss unique content" — based on the author's own use, with no comparative testing, benchmark, or third-party validation offered.
文章的评价是定性且基于个人经验的——「效果出乎意料地好」「风格更统一」「不会漏掉独特内容」——没有提供对比测试、基准数据或第三方验证，属于作者自己使用后的主观判断。
What happens if the drafts being merged actually contradict each other on facts, not just style?如果几份稿子在事实层面互相矛盾（而不只是风格不同），这个流程还适用吗？
The article doesn't address this — its examples are about structure, phrasing, and completeness, all compatible content. Factual contradictions between drafts (e.g. conflicting numbers) would need separate verification the described workflow doesn't cover.
文章没有涉及这种情况——所举例子都是关于结构、表达和信息完整度，属于内容相容的差异。如果稿子在事实层面（比如数字）互相矛盾，需要额外的核实步骤，而这不在文中描述的流程覆盖范围内。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece documents a concrete workflow shift: from manually reconciling multiple AI-generated drafts by eye, to delegating the comparison-and-merge task to an AI model, to finally packaging that workflow as a reusable Claude Skill. It's a case study in recognizing repeated manual labor and converting it into infrastructure.
这篇文章记录了一次具体的工作流演进：从人工逐段比对多份 AI 生成草稿，到把比较与合并任务直接交给 AI 模型执行，再到把整套流程固化成可复用的 Claude Skill。本质上是一个「识别重复劳动 → 转化为基础设施」的案例研究。
- Concrete, reusable artifact提供了可直接复用的具体产物The piece includes the author's actual production Skill file (six steps, trigger phrases, composition with a writing-style Skill), not just an abstract description — readers can copy and adapt it directly.文章附上了作者实际在用的 Skill 文件全文（六步流程、触发短语、与 writing-style Skill 的组合），而不只是抽象描述，读者可以直接复制改造使用。
- Names the specific mechanism, not just the outcome点明了具体机制而非只讲结果It doesn't just say "AI merging works better" — it identifies why: reasoning-capable models are needed because merge decisions require judgment, a specific and checkable claim rather than vague praise.文章没有止步于「AI 合并效果更好」，而是指出了原因：合并决策需要判断力，因此必须用带推理能力的模型，这是一个具体且可验证的论断，而非泛泛的夸赞。
- Generalizes to a transferable diagnostic提炼出了可迁移的判断标准The closing test — "if you're re-pasting a prompt or re-explaining a process, make it a Skill" — is a simple, memorable heuristic readers can apply well beyond the draft-merging example.结尾给出的判断标准——「如果在复制粘贴旧提示词或重复解释流程，就该做成 Skill」——是一条简单好记的启发式规则，读者可以套用到远超「多稿合并」本身的场景。
- Honest about manual-method trade-offs对手动方法的取舍很诚实The article doesn't strawman the manual approach — it credits it as workable and effective, just costly at scale — which makes the case for automation land as a practical upgrade rather than a dismissal of the old way.文章没有把手动方法塑造成稻草人，而是承认它确实有效，只是规模变大后成本太高——这让「转向自动化」的论证显得是务实的升级，而不是对旧方法的简单否定。
- No quantitative evidence缺乏量化证据All quality claims ("unexpectedly good," "more consistent than manual") are anecdotal impressions from one user's workflow, with no side-by-side comparison, error analysis, or third-party evaluation of merge quality.所有质量论断（「出乎意料地好」「比手动更统一」）都是单个用户的主观印象，没有并排对比、错误分析或第三方评估来支撑合并质量的说法。
- Tool-specific, may date quickly高度依赖特定工具，易过时The piece is built entirely around Claude's Skill mechanism and /skill-creator; the concepts (reasoning models, prompt-to-workflow) transfer, but the concrete instructions will need updating as Claude's Skill system evolves.文章完全围绕 Claude 的 Skill 机制和 /skill-creator 构建；核心理念（推理模型、提示词固化为流程）可以迁移，但具体操作指令会随 Claude Skill 体系的演进而过时。
- Doesn't address factual conflicts between drafts未处理稿子间的事实性冲突The workflow assumes drafts differ in style, structure, and completeness but agree on facts — it offers no guidance for merging drafts that contain contradictory claims or numbers, a common real-world case.整套流程默认各稿只在风格、结构、信息完整度上有差异，事实层面是一致的——对于稿子之间存在矛盾表述或数字冲突的常见情况，文中没有给出任何处理指引。
- Skips failure modes of AI merging回避了 AI 合并可能出错的情况There's no discussion of what happens when the merge model hallucinates a fusion, over-trusts a weaker draft, or silently drops a highlight — the piece presents the automated process as reliable without describing how to catch its mistakes.文章没有讨论合并模型出错的情况——比如融合时产生幻觉、过度信任较弱的稿子、或悄悄漏掉某个亮点——把自动化流程呈现为可靠的，却没说明如何发现和纠正它的错误。
A practical, tool-specific how-to rather than a research piece — useful for anyone already generating multiple AI drafts and drowning in manual reconciliation, especially Claude Code / Skill users. Read it for the workflow pattern and the reusable Skill file, but treat the quality claims as one practitioner's experience, not validated results.
这是一篇实操型的工具指南，而非研究论文——适合已经在用多个 AI 版本、又苦于手动比稿的读者，尤其是 Claude Code / Skill 用户。可以直接拿走其中的工作流思路和可复用的 Skill 文件，但文中的效果论断应视为一位实践者的个人经验，而非经过验证的结论。
Original Text原文
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
When translating or writing with AI assistance, I usually don't just generate a single version.
Sometimes it's the same model run multiple times, sometimes it's different models each run once, or even different prompts run separately. Once you compare several versions side by side, you notice something frustrating: no version is perfect, but every version has its own bright spots.
Version A has the best overall structure, but a few paragraphs read too stiffly; Version B shines in certain passages, but misses some key information; Version C has the most complete information, but reads like it was machine-translated.
How do you combine their strengths into one?
Manual merging: it works, but it's tedious
My previous approach was simple and crude:
First read through all the versions and pick the overall best one as the base. Then compare it against the other versions paragraph by paragraph, copying over any section that's written better, and filling in any information the base version is missing. Finally, read through it once more and polish the seams so it reads like it was written by one person, with no trace of stitching.
It worked reasonably well, but it took time. Especially when there were many drafts, comparing three or four versions against each other was very attention-draining. And manual comparison easily misses things — a great detail in one version could slip through unnoticed.
Letting AI do this instead
Since AI is good at handling large volumes of text, why not let it do this job?
I tried it — sending all the versions to AI together, along with instructions like this:
Read all the drafts, and pick the best one as the base
Review the other drafts one by one, identifying highlights and anything missing from the base version
Merge that content into the base draft
Do a polishing pass over the merged full text to eliminate any seams
The result was surprisingly good. AI is very reliable at this kind of task — "compare multiple texts, extract the differences, and execute the merge." It doesn't miss the unique content of any version, and the style of the merged result is more consistent than what I could stitch together by hand.
Here's a small tip: models that support reasoning work better — like Claude's extended thinking mode, or reasoning models like GPT-5 thinking. Because merging isn't simple copy-and-paste; it requires judging which passage is better and how to blend it naturally, and producing intermediate results — all of which require reasoning ability.
You can do this using a chat interface (like Claude AI) — just send all the drafts and the instructions together. If you use a command-line agent tool like Claude Code, you can directly specify the file paths, and it will read the files itself and carry out the merge — a more convenient way to operate.
Repeated work should be turned into a Skill
The method above works well, but there's one issue: you have to re-enter that prompt every time you do a merge.
If you frequently do this kind of multi-draft merging work, a better approach is to turn it into a Skill. A Skill is a capability-extension mechanism in Claude — you can write a workflow into a Skill file, and afterward you only need to tell Claude "merge these drafts," and it will automatically carry out the process you've defined. No need to re-enter the prompt each time, and no worry about missing a step.
There are two common ways to create a Skill.
Method 1: Do it manually once first, then have AI codify it
First walk through the full merging process manually in Claude AI. Send it the drafts, have it pick the base draft, extract the highlights, merge, and polish. Once it's done, check the result and make sure you're satisfied.
Then, in the same conversation, tell it:
/skill-creator Turn the process we just went through into a Skill.
Because AI has already gone through the complete process once, it clearly knows what needs to be done at each step and what to watch out for. A Skill distilled from actual practice is usually more accurate than one described from scratch.
The advantage of this approach is that you have a direct sense of the final result and can spot issues and adjust before codifying it. The downside is you have to spend time doing it once first.
Method 2: Describe your requirements directly and let AI create it
If you already know exactly what process you want, you can just tell Skill Creator directly. For example, in Claude Code you could write something like this:
/skill-creator Add a skill to the current project that can be used to merge multiple drafts into one. The process is as follows:
Read all the provided drafts
Pick the best draft as the base
Add valuable content from the other drafts, or important sections missing from the base draft, into the base draft
Polish the finished draft
Reference input (this example has only 2 drafts, but there are usually at least 2, and possibly more): posts/2026-03-01/jenny-wen-design-process/draft1.md posts/2026-03-01/jenny-wen-design-process/draft2.md
Skill Creator will generate a complete Skill file based on your description, including trigger conditions, input format, workflow, and output specification.
If you don't have skill-creator, you can install it from here: https://skills.sh/anthropics/skills/skill-creator
This approach is faster and suits cases where you've already thought through the process. The downside is that without a real example as reference, the generated Skill might need several rounds of tuning before it's satisfactory.
How to choose between the two approaches
If you're not yet sure about the process, or you haven't done this particular task before, use Method 1. Do it manually first, figure out which steps matter and which details are error-prone, then codify it.
If you've already done this many times and the process is clear, use Method 2. Describe your requirements directly and skip the time spent doing it manually.
The two approaches can also be combined: use Method 1 to produce an initial version of the Skill, then after using it a few times, notice where it can be improved, and use Method 2 to have Skill Creator help you adjust it.
What the merge Skill looks like
Below is the multi-draft merge Skill I'm actually using, for reference:
This Skill's description field lists several ways to trigger it, in both Chinese and English. That way, whether you say "merge these drafts" or "合并这几篇稿子," Claude knows to invoke this Skill.
The workflow is broken into six steps, each with a clear task and standard. The merging principle in step four is especially key: "blend rather than stitch — the merged result should read like it was written by one person" — this rule directly determines the quality of the merge.
A Skill can also reference other Skills. For example, this merge Skill references writing-style to control the writing style, so the merged article automatically follows your predefined style rules.
You can adjust this Skill to fit your own needs — for example, adding a word-count limit, specifying output filename rules, or adding a step to "have the user confirm the choice of base draft" (personally I prefer full automation, so I didn't add that).
The general approach to creating a Skill
Although this article uses multi-draft merging as the example, the approach to creating a Skill is general. Anything you find yourself doing repeatedly is worth considering turning into a Skill:
Need to format translations into a fixed layout every time? Make it a Skill. Need to self-check an article against a checklist after writing it? Make it a Skill. Need to generate a summary and cover image before every publish? Make it a Skill.
The criterion is simple: if you notice you're copy-pasting a prompt you've used before, or explaining the same process to AI every single time, that's when it should become a Skill.
A Skill file is essentially a Markdown document, containing YAML-format metadata (name and trigger description) and Markdown-format body instructions. No coding required — just describe the steps clearly.
If you want to make a Skill more powerful, you can have it reference other Skills, specify file management rules, or add scripts that run automatically within it. But at the starting stage, a clear workflow description is enough.
AI 翻译或者辅助写作的时候，我通常不会只生成一个版本。
有时候是同一个模型跑多次，有时候是不同模型各跑一次，甚至是不同的提示词分别跑一次。几个版本拿到手里一比较，你会发现一个很纠结的事情：没有哪个版本是完美的，但每个版本都有自己的亮点。
A 版本整体结构最好，但有几段翻译太生硬；B 版本某几段特别出彩，但漏掉了一些关键信息；C 版本信息最全，但读起来像机器翻的。
怎么把它们的优点合到一起？
手动合并：能用，但费事
我之前的做法很简单粗暴：
先通读所有版本，选一篇整体最好的当基础。然后对着其他版本逐段比较，看到哪段写得更好就复制过来替换，看到基础版本缺的信息就补进去。最后再通读一遍，润色一下拼接处，确保读起来像一个人写的，没有拼接的痕迹。
效果还不错，但费时间。尤其是稿子多的时候，三四个版本比来比去很消耗注意力。而且人工比较容易漏东西，某个版本里一个很好的细节可能就这么错过了。
让 AI 来做这件事
既然 AI 擅长处理大量文本，这个活儿为什么不让它来？
我试了一下，把所有版本一起发给 AI，配上这样的指令：
- 阅读所有稿子，从中选一篇最好的作为基础
- 逐一审阅其他稿子，找出亮点和基础版本缺失的部分
- 把这些内容融合到基础稿里
- 对合并后的全文做一遍润色，消除拼接痕迹
效果出乎意料地好。AI 在这种“比较多个文本、提取差异、执行合并”的任务上非常靠谱。它不会漏掉某个版本的独特内容，合并后的风格也比我手动拼接更统一。
这里有个小经验：用支持推理的模型效果更好，比如 Claude 的扩展思考模式，或者 GPT-5 thinking 这类推理模型。因为合并不是简单的复制粘贴，需要判断哪段更好、怎么融合才自然，需要输出中间结果，这些都需要推理能力。
用聊天界面（比如 Claude AI）就能做，把所有稿子和指令一起发过去。如果你用 Claude Code 这样的命令行 Agent 工具，可以直接指定文件路径，它会自己读取文件然后执行合并，操作上更方便一些。
重复的工作应该固化成 Skills
上面的方法好用，但有个问题：每次合并都要重新输入那段提示词。
如果你经常做这种多稿合并的工作，更好的做法是把它做成一个 Skill。Skill 是 Claude 的一种能力扩展机制，你可以把一套工作流程写成一个 Skill 文件，之后每次只需要告诉 Claude“合并这几篇稿子”，它就会自动按照你定义好的流程去执行。不需要每次重复输入提示词，也不用担心某次漏掉了某个步骤。
创建 Skill 有两种常见方式。
方式一：先手动做一遍，再让 AI 固化
你在 Claude AI 里先手动走一遍完整的合并流程。把稿子发过去，让它选基础稿、提取亮点、合并、润色，做完之后你检查结果，觉得满意。
然后在同一个对话里跟它说：
/skill-creator 把刚才的操作流程固化成一个 Skill。
因为 AI 已经走过一遍完整流程了，它很清楚每一步该做什么、要注意什么。从实际操作中提炼出来的 Skill，通常比凭空描述的更准确。
这种方式的好处是你对最终效果有直观感受，可以在固化之前就发现问题并调整。缺点是你得先花时间做一遍。
方式二：直接描述需求，让 AI 创建
如果你已经很清楚自己要什么流程，可以直接告诉 Skill Creator。比如在 Claude Code 里可以这样写：
/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-creator，可以从这里安装：https://skills.sh/anthropics/skills/skill-creator
这种方式更快，适合你已经想清楚流程的情况。缺点是没有实际案例做参照，生成的 Skill 可能需要多跑几次才能调到满意。
两种方式怎么选
如果你对流程还不太确定，或者这个任务你之前没做过，用方式一。先手动做一遍，摸清楚哪些步骤重要、哪些细节容易出错，再固化。
如果你已经反复做过很多次，流程很清晰了，用方式二。直接描述需求，省掉手动执行的时间。
两种方式也可以结合：先用方式一做出初版 Skill，用几次之后发现可以优化的地方，再用方式二让 Skill Creator 帮你调整。
合并 Skill 长什么样
下面是我实际在用的多稿合并 Skill，供参考：
---
name: merge-drafts
description: 多稿合并技能。将多份草稿合并为一份高质量文章。阅读所有稿子，选最佳稿为基础，融合其他稿子的亮点和缺失内容，最终润色输出。当用户要求"合并稿子"、"合稿"、"merge drafts"、"把这几篇合成一篇"、"综合这几份稿子"时使用此技能。
---
# 多稿合并技能
## 写作风格
本技能遵循 `writing-style` 技能定义的写作规范。
## 输入
接收 2 份或以上草稿文件路径。同时读取同目录下的 analysis.md（如有）作为素材参考。
## 工作流程
步骤一：阅读所有稿子，快速评估每份的结构、信息覆盖面、表达质量和独特亮点。
步骤二：选一份最佳稿作为基础。标准是结构最清晰、信息最全、表达最好、以它为基础改动最小。
步骤三：逐一审阅其他稿子，提取缺失内容、更好的表达、独特角度和数据案例。
步骤四：在基础稿上合并。补充缺失内容，替换更好的表达，融合不同视角，统一风格。原则是融合而非拼接，合并后读起来像一个人写的。
步骤五：润色。重点检查拼接痕迹、风格统一、重复内容、逻辑连贯。
步骤六：输出合并报告，说明基础稿选择理由、各稿贡献了什么、主要修改了哪些内容。
这个 Skill 的 description 字段里列了多种触发方式，中英文都有。这样不管你说“合并这几篇稿子”还是“merge these drafts”，Claude 都知道该调用这个 Skill。
工作流程拆成了六步，每一步都有明确的任务和标准。其中步骤四的合并原则很关键：“融合而非拼接，合并后读起来像一个人写的”，这条规则直接决定了合并质量。
Skill 还可以引用其他 Skill。比如这个合并 Skill 引用了 writing-style 来控制写作风格，这样合并出来的文章会自动遵守你预设的风格规范。
你可以根据自己的需求调整这个 Skill。比如加上字数限制、指定输出文件名规则，或者增加一个“让用户确认基础稿选择”的步骤（我个人喜欢全自动，所以没加）。
Skill 的通用创建思路
虽然这篇文章用多稿合并做例子，但创建 Skill 的思路是通用的。任何你发现自己在重复做的事情，都可以考虑做成 Skill：
翻译完要按固定格式排版？做成 Skill。写完文章要按检查清单自查？做成 Skill。每次发布前要生成摘要和封面图？做成 Skill。
判断标准很简单：如果你发现自己在复制粘贴之前用过的提示词，或者每次都要跟 AI 解释一遍同样的流程，那就该做成 Skill 了。
Skill 文件本质上就是一个 Markdown 文档，包含 YAML 格式的元信息（名字和触发描述）和 Markdown 格式的正文指令。不需要写代码，会写清楚步骤就行。
如果你想让 Skill 更强大，可以在里面引用其他 Skill、指定文件管理规则、添加自动执行的脚本。但起步阶段，一个清晰的工作流程描述就够了。
See all posts