Article Rewriter

Article Rewriter

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

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

三模式：

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

默认模式：standard

输入类型

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

默认值

模式

自动判断规则：

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

输出目录

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

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

平台与文风

平台、段落节奏、标题风格不要写死在主文件里。按需阅读：

• references/style-presets.md：公众号、知乎、Newsletter、通用版的文风和标题约束
• references/glossary-en-zh.md：英文原文或中英混排材料中的特殊译法
• references/quality-rubric.md：批评稿与最终质检时的固定检查维度
• references/expression-optimizer.md：最终表述优化时要清理的翻译腔、AI 腔和套话模式

选择逻辑：

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

术语处理

当任务包含以下任一情况时，必须先做术语统一，再进入改写：

• 原文是英文
• 原文是中英混排
• 原文涉及 AI、产品、商业、技术等高频专有名词
• 用户明确要求“翻译并改写”

处理顺序： 1. 优先读取内置术语表 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：检索范围、来源优先级、冲突处理、引用格式

执行原则：

• 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。

至少从以下维度逐项检查：

• 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。

这一步只处理表达层，不改论点和事实。核心目标：

• 去掉翻译腔、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 默认使用以下结构：

## 标题候选

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

---

## 正文

[改写后的完整文章]

---

## 参考来源

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

---

## 改写说明

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

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

## 参考来源

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

质量门槛

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

禁止事项

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

Expression Optimizer

用于 09-expression.md。

目标不是把文章改得“更像 AI 会模仿的人类”，而是把已经合格的稿子再收一遍，去掉翻译腔、AI 腔、套话和机械结构，让中文更自然、更像真实作者写出来的文字。

前提：

• 事实、结构、术语、标题已经基本稳定
• 这一步只改表达，不新增事实，不改核心判断

核心原则

1. 删除填充短语 2. 打破公式结构 3. 变化句式和段落节奏 4. 信任读者，不过度解释 5. 删除“像金句”的句子

重点清理模式

1. 空泛拔高和宏大叙事

警惕：

• 标志着关键时刻
• 体现了更广泛的趋势
• 具有深远意义
• 彰显其重要性
• 持续塑造着某种格局

处理：

• 改回具体事实、动作、结果
• 如果没有足够支撑，就不要拔高

2. 宣传和广告腔

警惕：

• 充满活力的
• 令人惊叹的
• 丰富的文化底蕴
• 开创性的
• 迷人的
• 至关重要的

处理：

• 用可验证的具体描述替代
• 少用夸张形容词，多写发生了什么

3. 模糊归因

警惕：

• 有观点认为
• 专家指出
• 业内普遍认为
• 一些观察者认为

处理：

• 能具体就具体
• 不能具体就改成保守表达，或直接删去

4. 连接词拐杖

警惕：

• 此外
• 值得注意的是
• 不仅如此
• 归根结底
• 从某种意义上说
• 不难发现

处理：

• 多数情况下可以直接删
• 真需要过渡时，用内容推进，而不是模板词推进

5. 否定式排比和口号句

警惕：

• 这不仅是……更是……
• 不只是……也是……
• 真正重要的是……
• 真正拉开差距的是……

处理：

• 直接说判断
• 如果一句话像海报文案，多半该重写

6. 三项并列和假完整感

警惕：

• 强行分成三点、三层、三类
• 连续出现三个近义短语
• “创新、效率与洞察”这类空泛并列

处理：

• 能压成两项就压成两项
• 能落到具体动作就落到具体动作

7. 翻译腔和欧化句法

警惕：

• 为了……而……
• 在……方面发挥着关键作用
• 对……产生深远影响
• 对于……来说
• 进行一个……

处理：

• 改成更短、更直接的中文动词结构
• 能用“是 / 有 / 会 / 让”时，不必绕复杂结构

8. 术语和主语漂移

警惕：

• 同一概念反复换近义词
• 为避免重复而把主语改得越来越远

处理：

• 允许适度重复关键术语
• 不要为了“文采”牺牲清晰度

9. 破折号、粗体和强调过量

警惕：

• 破折号过密
• 每段都用粗体强调
• 频繁出现“必须”“一定”“真正”

处理：

• 回到正常中文停顿
• 让信息本身承担重点，不要靠排版吼出来

适度保留人味

“更自然”不等于“更口语”。按平台决定表述力度：

• formal / 技术稿：重点去机械感，不额外加情绪
• zhihu / newsletter：允许更直接的判断和更短的句子
• wechat：允许更强的节奏，但不要鸡血化

如果原文适合保留一点作者感：

• 可以保留克制的判断
• 可以承认复杂性
• 可以让句长有变化

但不要：

• 凭空加第一人称
• 故意制造“松弛感”
• 把正式稿写成情绪随笔

自检清单

在完成 09-expression.md 前，逐项确认：

• 有没有删掉 30% 以上其实没必要的连接词
• 有没有去掉空泛拔高和口号句
• 有没有把模糊归因收紧
• 有没有保住术语一致和事实边界
• 有没有让句子更短、更直接，但信息没变薄
• 有没有避免把文章改成“另一种腔”

English → Chinese Glossary

用于“翻译并改写”场景的特殊译法参考。目标不是覆盖所有英文词，而是提前固定那些容易误译、前后不一致、或在中文语境里存在明显风格差异的词。

使用原则

• 只在英文原文或中英混排材料中启用
• 词表是优先参考，不是机械替换
• 如果目标读者偏技术，可保留更多英文原词
• 如果目标读者偏大众，优先给自然中文，并在首次出现时补英文原词

推荐格式：

• 中文（English）
• 中文（English，简短解释）

Core Terms

Rewrite Notes

• 同一个词如果在“技术解释”和“传播表达”里有两种自然说法，优先在正文统一一种，在必要处补充另一种解释。
• 不要把术语翻得过满。比如 AI Agent 在技术文章里通常直接保留为 AI 智能体，不需要每次展开解释。
• 不要把商业俚语一律写得很硬。比如 moat 用“护城河”比“竞争壁垒”更自然，但正式分析文中可按语境替换。

Quality Rubric

用于两处：

• 写 06-critique.md 时，按此 rubric 做结构化诊断
• 写 qa.md 时，按此 rubric 做最终验收

它的目标不是把文章挑刺挑到面目全非，而是确保“准确、完整、自然、可发布”。

1. Accuracy

检查：

• 是否误解了原文论点、事实关系、时间顺序、因果关系
• 是否把假设写成事实
• 是否把限定条件、省略条件或语气强弱改坏

常见问题：

• 把可能性写成确定性
• 把作者的评价写成客观事实
• 把例子误当结论

2. Completeness

检查：

• 关键事实、数字、案例、引用是否被漏掉
• 反例、边界、限定词是否丢失
• 标题、开头承诺的内容是否在正文兑现

常见问题：

• 只留下大意，丢掉支撑细节
• 为求顺畅删掉关键限定词
• 省略造成结论比原文更激进

3. Natural Chinese

检查：

• 是否有明显欧化句法、翻译腔、硬译
• 是否存在中文不自然的搭配、词序、代词指代
• 是否存在连续多句相同节奏、机械连接词

常见问题：

• “进行一个……”式僵硬表达
• 过度保留英文抽象名词结构
• 滥用“首先/其次/最后”

4. Terminology

检查：

• 同一术语是否前后一致
• 首次出现时是否需要解释
• 是否把关键术语口语化到失真

常见问题：

• 一个概念出现三种译法
• 产品名、方法论名词、缩写在不同段落漂移
• 为了顺口把术语改得不专业

5. Structure And Logic

检查：

• 开头是否迅速建立问题、主题或结论
• 段落顺序是否更利于中文读者理解
• 因果链、对比关系、递进关系是否清楚

常见问题：

• 信息顺序照搬原文，中文读者读起来吃力
• 结论出现太早或太晚
• 段落之间缺少过渡，像拼接

6. Register And Platform Fit

检查：

• 是否符合目标平台的密度、节奏、口吻
• 是否过度营销、过度鸡汤、过度学术
• 是否与用户指定的受众匹配

常见问题：

• 公众号稿写得像学术摘要
• 知乎稿写得像促销文案
• 正式稿里混入过多口语和感叹

7. Fact Boundary

检查：

• 新增事实是否有来源支撑
• 时效信息是否标注时间边界
• 推断、解释、判断是否与已核实事实分开

常见问题：

• 引入未核实的新数据
• 用陈旧资料支撑“最新趋势”
• 把“公开资料显示”写成笃定断言

8. Title And Framing

检查：

• 标题是否准确反映正文主张
• 标题与开头是否和正文承诺一致
• 是否为了传播性过度放大冲突或收益

常见问题：

• 标题承诺过大，正文无法兑现
• 开头过猛，正文支撑不足
• 标题只换近义词，没有角度差异

使用方式

写 06-critique.md 时：

• 先抓 Accuracy、Completeness、Fact Boundary
• 再看 Natural Chinese、Terminology、Structure
• 最后看 Platform Fit 和 Title

写 qa.md 时：

• 只保留最终仍有风险或已经确认通过的项
• 用简洁结论表述，例如 passed / fixed / watch

Research Rules

外部调研的目标不是“把文章写长”，而是补足缺失信息、核验易错事实、提高可信度。

何时检索

满足任一条件就应考虑检索：

• 用户明确要求补充资料、数据、案例、来源
• 原文涉及“最新”“今年”“目前”“最近”等时效表达
• 原文包含可疑数字、机构结论、公司动态、政策变化
• 主题本身对事实准确性要求高

以下情况通常不必检索：

• 用户明确要求只改表达，不补新信息
• 原文是纯个人随笔、文学表达、个人经历
• 所有关键事实都稳定且用户没要求扩展

来源优先级

优先顺序： 1. 官方文档、原始研究、公司/机构公告 2. 权威媒体、专业数据库、学术机构 3. 高质量二手综述

尽量避免：

• 搬运号、标题党、自媒体拼贴文
• 没有原始出处的数据二传文章
• 只给观点不给证据的评论帖

记录方式

02-research.md 建议至少包含以下表格：

补充说明：

• verified：原文说法可保留
• updated：原文有旧信息，需改写为新版本
• unclear：没找到可靠依据，正文里避免写成确定事实

冲突处理

如果外部资料与原文冲突：

• 优先采用更高质量、更新的来源
• 正文里自然改写，不要无端“打脸原作者”
• 如果差异对结论影响很大，可以用保守表达，例如“截至 2026 年 3 月，公开资料更支持……”

引用策略

• 正文中优先把资料“转译”为清楚的人话，不要机械堆链接
• 只有关键数字、结论或争议点需要显式归因
• 最终统一在“参考来源”里列链接
• 不确定的推断要用“更像是”“可以理解为”“公开资料显示”这类边界表达

写作边界

• 不杜撰研究、案例、用户反馈、行业共识
• 不为了凑“信息增量”而塞无关背景
• 如果没有可靠资料，就明确保守，而不是硬写

Style Presets

平台预设不是模板套壳，而是帮助你决定开头力度、段落长度、论证方式和标题风格。

Platform Presets

Angle Presets For Titles

优先从不同“角度”出标题，不要只换近义词：

• 洞察型：告诉读者真正发生了什么变化
• 利益型：告诉读者读完能获得什么
• 反常识型：指出直觉上容易错的地方
• 场景型：把内容放进真实工作或生活场景
• 提问型：用一个关键问题引出全文

Tone Guidance

技术 / 产品 / 商业

• 保留专业度
• 用具体场景解释术语
• 情绪可以有，但不能掩盖逻辑

社会议题 / 趋势观察

• 允许更强的张力和反思
• 不靠夸张措辞制造深刻感
• 尽量给出因果链，而不只是态度

方法论 / 教程 / 经验文

• 让读者尽快知道“学完能做什么”
• 主体尽量拆成清晰步骤或判断框架
• 结尾最好给可执行建议

Anti-Patterns

• 不要所有文章都写成“震惊体”
• 不要所有开头都用“你有没有发现”
• 不要所有结尾都用“真正拉开差距的是……”
• 不要把标题写成空泛口号