# Article Rewriter

> 深度改写中文文章的技能。用户要求“重写”“改写”“润色重构”“扩写”“翻译并改写”“改成公众号/知乎风格”“把这篇文章写得更适合发布”“优化这篇文章的表达或结构”时必须触发。支持 inline text、文件路径、URL 三种输入；支持 quick、standard、publish 三种模式；可按需要补充最新资料并生成 5 个标题候选。即使用户只说“把这篇改一下”“翻成中文后重写”“帮我整理成一篇可发布文章”，也应使用此技能。

- Skill: `zuoa/article-rewriter` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds add zuoa/article-rewriter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zuoa/article-rewriter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zuoa (https://skillmd.com/u/zuoa)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/zuoa/article-rewriter

---


# Article Rewriter

面向“翻译 + 改写 + 发布”的文章处理技能。

它不是纯翻译器，也不是只做措辞润色的改稿器。遇到外文原文、混合语言原文、需要重组结构、需要适配公众号/知乎/Newsletter、或用户要求成稿级输出时，都要把“理解原文”和“生产成稿”拆开做。

三模式：
- `quick`：轻量翻译或轻量改写，不主动外查，尽量少留中间文件
- `standard`：分析原文，必要时补充少量资料，走一轮显式草稿和批评修订
- `publish`：分析、核验、重组、批评、修订、抛光、表述优化、质检，产出可直接发布版本

默认模式：`standard`

## 输入类型

- `inline text`：用户直接粘贴正文
- `file path`：读取本地文件
- `URL`：抓取正文后再处理(优先 WebReader，失败尝试用 `https://r.jina.ai/{url}` 读取，仍失败则尝试使用 `https://defuddle.md/{url}` ，如果都失败则明确说明无法获取内容)

## 默认值

| 设置 | 默认值 | 说明 |
|------|--------|------|
| 输出语言 | `zh-CN` | 最终统一输出中文 |
| 模式 | `standard` | 用户未指定时使用 |
| 平台 | `generic` | 若用户提到公众号/知乎/Newsletter，则改用对应预设 |
| 标题数 | `5` | 用户未指定时提供 5 个标题候选 |
| 调研范围 | `2-4` 个主题 | `publish` 模式可扩展到 `4-6` 个 |
| 输出目录 | `rewrites/{slug}-{timestamp}/` | 所有中间文件和最终稿统一放在这里 |
| 长文阈值 | `> 2500` 英文词或 `> 4000` 中文字 | 超过后优先采用分块写作与统一审校 |

## 模式

| 模式 | 触发词 | 核心步骤 | 适用场景 |
|------|--------|----------|----------|
| Quick | “简单润色”“快改一下”“不要查资料” | 约束确认 → 术语统一（如需要）→ 直接成稿 | 短文、轻量润色、用户明确不要外查 |
| Standard | 默认 | 分析 → 选择性调研 → Prompt 快照 → 草稿 → 批评 → 修订 → 表述优化 → 成稿 | 大多数文章改写需求，尤其是“翻译并改写” |
| Publish | “深度改写”“公众号成稿”“适合发布”“补充资料并重写” | 分析 → 核验 → 重组 → Prompt 快照 → 草稿 → 批评 → 修订 → 抛光 → 表述优化 → 质检 → 成稿 | 要发布、事实敏感、风格要求高或长文任务 |

自动判断规则：
- 用户明确说“不用查资料”“只改表达”时，用 `quick`
- 用户明确要“发公众号/知乎/Newsletter”“深度改写”“补资料”“像一篇正式文章”时，用 `publish`
- 只要任务包含明显翻译难点、长文、或用户要“成稿级中文”，至少用 `standard`
- 其他情况默认 `standard`

## 输出目录

为每次任务创建输出目录：`rewrites/{slug}-{timestamp}/`

| 文件 | 何时需要 | 说明 |
|------|----------|------|
| `source.md` | 全部 | 落盘后的原始内容 |
| `00-brief.md` | 全部 | 任务约束、平台、受众、篇幅、检索边界、是否允许重组 |
| `01-analysis.md` | `standard` / `publish` | 主题、结构、受众、保留项、难点、理解障碍、改写策略 |
| `01-terms.md` | 有翻译或术语密集时 | 本次任务的术语表、推荐译法、禁用译法、待确认译法 |
| `02-research.md` | 做了外查时 | 外部资料、事实核验、冲突信息、可引用要点 |
| `03-outline.md` | `publish` 或重组明显时 | 新结构、大纲、标题角度、叙述顺序 |
| `04-prompt.md` | 非平凡任务默认产出 | 写作指令快照，供草稿、分块和后续修订复用 |
| `05-draft.md` | `standard` / `publish` | 初稿；必要时带 translator notes |
| `06-critique.md` | `standard` / `publish` | 诊断问题，不直接改文 |
| `07-revision.md` | `standard` / `publish` | 吃掉批评意见后的修订稿 |
| `08-polish.md` | `publish` | 中文化、节奏、标题、平台适配后的抛光稿 |
| `09-expression.md` | `standard` / `publish` 的非平凡任务 | 去除翻译腔、AI 腔、套话和机械连接感后的表述优化稿 |
| `qa.md` | `publish` 或事实敏感任务 | 最终质检清单与残余风险 |
| `rewrite.md` | 全部 | 最终交付稿 |

如果用户只要求聊天里直接返回结果，仍然默认保存 `rewrite.md`，并在回复里给出路径。

## 平台与文风

平台、段落节奏、标题风格不要写死在主文件里。按需阅读：
- [references/style-presets.md](references/style-presets.md)：公众号、知乎、Newsletter、通用版的文风和标题约束
- [references/glossary-en-zh.md](references/glossary-en-zh.md)：英文原文或中英混排材料中的特殊译法
- [references/quality-rubric.md](references/quality-rubric.md)：批评稿与最终质检时的固定检查维度
- [references/expression-optimizer.md](references/expression-optimizer.md)：最终表述优化时要清理的翻译腔、AI 腔和套话模式

选择逻辑：
- 用户明确指定平台时，优先使用对应预设
- 用户未指定平台时，先根据原文类型和目标受众判断；仍不明确则使用 `generic`
- 技术、商业、社会议题都可以有叙事感，但不要强行“鸡血化”或“爆款化”

## 术语处理

当任务包含以下任一情况时，必须先做术语统一，再进入改写：
- 原文是英文
- 原文是中英混排
- 原文涉及 AI、产品、商业、技术等高频专有名词
- 用户明确要求“翻译并改写”

处理顺序：
1. 优先读取内置术语表 [references/glossary-en-zh.md](references/glossary-en-zh.md)
2. 从原文额外提取专有名词、缩写、产品名、方法论名词
3. 形成本次任务的会话术语表，写入 `01-terms.md`
4. 标出推荐译法、禁用译法、保留原词、待定项
5. 后续草稿、批评、修订都以 `01-terms.md` 为准，不得随意漂移

执行原则：
- 常见且约定俗成的词，直接用标准中文
- 容易误译、风格差异大的词，优先遵循内置术语表
- 首次出现时，可使用 `中文（English）` 或 `中文（英文原词，简短解释）`
- 如果术语存在多种合理译法，选择最适合目标平台和受众的一种，并全文保持一致
- 改写允许重组句子，但不要把关键术语“改丢”或改成过度口语化的说法

## 工作流

### Step 1: 获取约束并写入 `00-brief.md`

优先从当前对话提取，不要为了默认值反复追问。至少确认：
- 输入来源：文本、文件、URL
- 用户目标：润色、扩写、翻译并改写、发文成稿、平台适配
- 是否允许外部检索
- 是否要保留原文结构
- 是否要控制篇幅
- 目标平台与受众
- 事实敏感度：普通 / 中 / 高

如果用户没有说明：
- 默认允许“必要时补充少量资料”，但不要为静态内容滥搜
- 默认允许重组结构，但要保留原文核心论点
- 默认提供 5 个标题候选

`00-brief.md` 建议记录：
- Source type
- Goal
- Platform
- Audience
- Length target
- Research boundary
- Preserve structure: yes / no / partial
- Fact sensitivity
- Output promise

### Step 2: 落盘原文并创建输出目录

1. 将输入内容统一落盘到 `source.md`
2. 创建输出目录 `rewrites/{slug}-{timestamp}/`
3. 检测原文语言
4. 如果原文不是中文，先加载内置术语表并提取会话术语，写入 `01-terms.md`
5. 如果原文很长，先确定分块边界和合并策略，再进入草稿

要求：
- URL 输入优先抽取正文，避免导航、推荐位、评论区污染
- 文件或 URL 抽取失败时，明确说明阻塞点；如果仍可继续，退回到用户已提供的正文
- 分块时按语义边界切，不要机械按字数均分

### Step 3: 分析原文并写入 `01-analysis.md`

`standard` 和 `publish` 模式必须产出 `01-analysis.md`。至少包含：
- 原文主题、核心论点、作者意图
- 目标受众推断
- 原文结构拆解
- 必须保留的事实、数字、案例、引用
- 关键术语及建议译法
- 读者理解障碍：背景知识缺口、代词指代、长句、跳步论证
- 比喻与文化映射：哪些隐喻应保留、转译、解释或降级
- 语气目标：克制 / 叙事 / 评论 / 方法论 / 发布稿
- 可优化点：过长、重复、跳跃、空泛、事实老旧、结论太早或太晚
- 改写策略：保守重写 / 结构重组 / 翻译后二次创作

如果原文已经写得很好，分析里要明确“以增量和可读性优化为主”，不要强行颠覆。

### Step 4: 调研与事实核验

何时需要做 `02-research.md`：
- 用户明确要求补充资料、最新信息、案例、数据
- 原文含有明显时效性内容
- 原文中的数字、研究、公司信息可能已经过期
- 主题本身需要最基本的事实校验

按需阅读：
- [references/research-rules.md](references/research-rules.md)：检索范围、来源优先级、冲突处理、引用格式

执行原则：
- `quick` 模式默认不主动外查
- 用户明确禁止检索时，跳过外查，并在最终结果里注明“本次基于原文改写，未补充外部资料”
- `standard` 模式只查能显著提高文章可信度的关键信息
- `publish` 模式要把“外部事实”“作者观点”“你的推断”分开
- 调研文件只记录“事实与来源”，不要把语言问题混写进去

### Step 5: 规划新结构

以下情况必须写 `03-outline.md`：
- `publish` 模式
- 原文结构明显混乱
- 用户要求平台适配且风格变化较大
- 需要从翻译转为“适合中文发布的成稿”

至少包括：
- 标题方向：洞察型 / 利益型 / 反常识型 / 场景型 / 提问型
- 开头策略：故事、场景、反差、问题、结论先行
- 主体段落顺序
- 每段要完成的作用
- 结尾动作：总结、提醒、方法、下一步建议

`standard` 模式可以不单独落盘大纲，但心里必须先确定结构再写。

### Step 6: 组装 Prompt 快照并写入 `04-prompt.md`

非平凡任务默认产出 `04-prompt.md`。它不是给用户看的终稿，而是给后续草稿、分块、修订复用的统一指令。

至少写清楚：
- 任务目标
- 输出语言与平台
- 目标受众
- 必保留信息
- 允许重组的程度
- 术语约束
- 禁止事项
- 调研结论或时间边界
- 文风要求
- 标题要求

如果任务需要分块：
- 每个 chunk 都复用同一份 `04-prompt.md`
- 每个 chunk 只处理自己的正文，不自行发明全局结论
- 合并后必须再做一次整体批评和统一修订

### Step 7: 生成 `05-draft.md`

`05-draft.md` 是初稿，不追求一次成稿，但必须把原文的骨架和信息先落稳。

执行原则：
- 原文是外文时，初稿先保证信息完整、关系准确、术语稳定
- 允许带简短 translator notes，专门记录难点、歧义、取舍
- 不在初稿阶段强行抖机灵或堆修辞
- 如果是分块任务，先得到所有 chunk 的初稿，再合并成统一 `05-draft.md`

### Step 8: 生成 `06-critique.md`

`06-critique.md` 只做诊断，不直接改文。优先读取 [references/quality-rubric.md](references/quality-rubric.md)。

至少从以下维度逐项检查：
- Accuracy：是否误译、漏译、过译、关系错位
- Completeness：关键限定条件、事实、例子是否丢失
- Natural Chinese：是否有欧化句法、硬译、别扭搭配
- Terminology：术语是否一致，首次解释是否合理
- Structure：段落顺序和因果链是否清楚
- Register / Platform Fit：是否符合公众号、知乎、Newsletter 或正式文风
- Fact Boundary：推断和事实是否混淆，时效信息是否处理得当
- Title / Framing：标题、开头、正文承诺是否一致

写法要求：
- 逐项点出问题和影响
- 优先说“哪里不对，为什么不对，应该往哪改”
- 不要在批评稿里顺手重写全文

### Step 9: 生成 `07-revision.md`

把 `06-critique.md` 的问题逐条吃掉，得到结构和表达都更稳定的修订稿。

执行原则：
- 先修准确性、完整性、逻辑，再修语言和节奏
- 如果批评中有互相冲突的建议，优先保事实与清晰度
- 修订时不得引入新事实，除非这些事实已在 `02-research.md` 中核实

### Step 10: 生成 `08-polish.md`

`publish` 模式必须做抛光，`standard` 模式在用户要求“像成稿”“可直接发”时也应做。

抛光只解决以下问题：
- 把翻译腔改成自然中文
- 拉顺段落节奏和过渡
- 调整标题、开头、结尾的抓力与克制感
- 清理重复表达、空泛修辞、解释过度
- 统一小标题、标点、格式和篇章密度

抛光阶段不要：
- 重新发明观点
- 引入未核实事实
- 因为追求“顺”而删掉关键限定词

### Step 11: 生成 `09-expression.md`

在结构、事实、节奏都已经稳定后，再单独做一次“优化表述”。优先读取 [references/expression-optimizer.md](references/expression-optimizer.md)。

这一步只处理表达层，不改论点和事实。核心目标：
- 去掉翻译腔、AI 腔、宣传腔
- 删掉空泛拔高、机械连接词、公式化三段式
- 把模糊归因改成具体归因，或改成保守表达
- 收紧过度修辞、口号句、像摘抄金句的句子
- 让段落更像真实作者写出来的中文，而不是“很会写的模型”

重点排查：
- 过度强调意义、历史地位、宏大趋势
- “此外 / 值得注意的是 / 不仅如此 / 归根结底”这类连接拐杖
- “不仅……而且……”“这不仅是……更是……”等否定式排比
- 生硬的三项并列、假完整感
- 模糊归因，如“专家认为”“业内普遍认为”“有观点指出”
- 过度使用破折号、粗体、抽象名词和口号化结尾
- 为显得不重复而频繁换同义词，导致术语或主语漂移

执行原则：
- 保留原意，不借“人味”之名擅自加观点
- 平台越正式，越要克制；不要把正式文风硬改成社交媒体口吻
- 允许自然的节奏变化，但不要故意“演”出松弛感
- 如果原文本来就是高度克制的技术或正式文体，优化目标是去机械感，不是加情绪

### Step 12: 质检并保存最终稿

`publish` 模式和事实敏感任务必须写 `qa.md`，至少包含：
- 是否有漏译、误译、过译
- 是否有未经核实的新事实
- 术语是否前后一致
- 标题是否准确反映正文
- 是否保留了原文最重要的事实、数字、案例、引用
- 是否仍有需要保守表述的地方
- `09-expression.md` 是否只改表述，没有偷改事实和判断

最终稿始终保存到 `rewrite.md`。

如果做了 `09-expression.md`：
- `rewrite.md` 基于 `09-expression.md`

如果没有单独做表述优化，但做了 `08-polish.md`：
- `rewrite.md` 基于 `08-polish.md`

如果没有单独抛光：
- `rewrite.md` 基于 `07-revision.md`

### Step 13: 生成标题候选

默认提供 5 个标题，优先覆盖不同角度，而不是只换几个词：
- 洞察型
- 利益型
- 反常识型
- 场景型
- 提问型

标题规则：
- 必须准确反映正文核心价值
- 不伪造数字，不夸大结论，不制造不存在的紧迫感
- 平台越正式，标题越克制
- 同一组标题之间角度要明显不同

如果用户明确说“不需要标题”，则跳过。

## 长文与分块策略

长文不要直接硬翻到底。采用“统一约束、局部分块、整体复核”的方式。

执行顺序：
1. 先完成 `00-brief.md`、`01-analysis.md`、`01-terms.md`、`04-prompt.md`
2. 按语义边界分块，不按字符数机械切块
3. 每个 chunk 共享同一术语表和 Prompt 快照
4. 合并所有 chunk 初稿到 `05-draft.md`
5. 对合并后的完整稿统一做 `06-critique.md`
6. 统一修订后再决定是否进入 `08-polish.md`
7. 无论是否单独抛光，最终都要对合并稿做一次表述优化，再输出 `rewrite.md`

特别注意：
- 分块只解决上下文窗口问题，不意味着每块都能独立定调
- 所有全局性的判断、标题、开头、结尾，都应该在合并后统一处理
- 合并稿必须检查术语漂移、重复解释、前后口径不一致
- 表述优化必须在合并后的全文上做，不能每个 chunk 各自“人性化”

## 最终输出格式

`rewrite.md` 默认使用以下结构：

```markdown
## 标题候选

1. 标题一
2. 标题二
3. 标题三
4. 标题四
5. 标题五

---

## 正文

[改写后的完整文章]

---

## 参考来源

- [来源标题](链接)
- [来源标题](链接)

---

## 改写说明

- 模式：standard
- 平台：wechat
- 是否补充外部资料：是
- 是否使用术语表：是
- 是否经过批评修订：是
- 是否经过表述优化：是
```

如果未外查，把“参考来源”改为：

```markdown
## 参考来源

- 本次基于用户提供原文改写，未补充外部资料
```

## 质量门槛

- 信息密度应高于原文，而不是仅仅换说法
- 如果扩写，新增内容要么解释关键概念，要么补足案例/数据/边界
- 事实敏感内容应优先核验，不确定时宁可保守表达
- 风格要有人味，但不要表演式抒情
- 如果原文质量本来很高，应以“精修”代替“重写”
- 有翻译成分的任务，至少要做一次显式批评与修订
- 长文或分块任务，必须对合并后的全文再做统一审校
- 非平凡任务在最终交付前，必须再做一次独立的表述优化

## 禁止事项

- 不要把未经核实的信息包装成“最新研究表明”
- 不要为了制造传播感而扭曲结论
- 不要照搬大段原句，只做词语替换
- 不要堆砌空泛修辞、套话或过量感叹句
- 不要默认所有文章都适合“爆款标题”
- 不要在 `06-critique.md` 里顺手重写全文，混淆诊断和修订
- 不要让 `08-polish.md` 变成又一轮无边界改写
- 不要让 `09-expression.md` 借“优化表述”之名偷改事实、立场或信息密度