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：公众号、知乎、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 借“优化表述”之名偷改事实、立场或信息密度