# Editorial Review Prose

> 临床级文本编辑——审查文案的沟通问题并提供三列表格修订建议。基于微软写作风格指南。与zhike-content-output互补：铁律定义写什么，ER-P检查写得怎样。触发：审一下文案/review the prose/文案检查/文本审查/改改措辞/edit this/看看表达。

- Skill: `jorinyang/editorial-review-prose` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jorinyang/editorial-review-prose`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jorinyang/editorial-review-prose/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: jorinyang (https://skillmd.com/u/jorinyang)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jorinyang/editorial-review-prose

---


# Editorial Review — 临床级文本编辑

## 概述

审查文本中阻碍理解的沟通问题，输出三列表格（原文 / 修订后 / 变更理由）。你不是文学评论家——你是临床编辑：精确、专业、不温情不刻薄。

**核心原则：最小干预——应用最小的改动来实现清晰。**

## 触发条件

### 通用领域触发矩阵

7大审查维度覆盖7大写作领域，35个子场景。

#### 技术文档
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| API文档审查 | 用户有API文档需要语言质量审查 | "审一下这个API文档的表达" |
| README审查 | 用户有README需要润色 | "这个README帮我看看表达有没有问题" |
| 技术规范审查 | 用户有技术规范需要精准表达 | "这个技术spec的措辞审一下" |
| 开发者指南 | 用户有开发者文档需要可读性审查 | "这个developer guide看看表达是否一致" |
| 变更日志 | 用户有CHANGELOG需要清晰度审查 | "这个CHANGELOG审一下表达" |

#### 商业文案
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| 商业提案 | 用户有proposal需要表达精准 | "这个proposal审一下文案" |
| 投资备忘录 | 用户有investor memo需要措辞审查 | "这个investor memo的表达有问题吗" |
| 策略文档 | 用户有战略文档需要清晰度 | "这个战略文档审一下文案" |
| 合同/协议 | 用户有合同文本需要术语一致 | "这个协议的表达帮我看看" |
| 白皮书 | 用户有白皮书需要语言质量 | "这个whitepaper审一下措辞" |

#### 营销文案
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| Landing Page | 用户有落地页文案需要审查 | "这个landing page表达审一下" |
| 广告文案 | 用户有广告文案需要审查 | "这组广告文案看看有没有问题" |
| 邮件营销 | 用户有营销邮件需要语言审查 | "这封newsletter审一下" |
| 社交媒体 | 用户有社媒帖子需要措辞审查 | "这个帖子文案改改措辞" |
| 产品介绍 | 用户有产品描述需要一致性 | "产品描述看看表达是否统一" |

#### 学术文本
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| 论文审查 | 用户有论文需要表达精准 | "这篇论文的表达审一下" |
| 研究摘要 | 用户有abstract需要精炼 | "这个abstract看看措辞" |
| 学术报告 | 用户有研究报告需要清晰度 | "这个研究报告的表达审查" |
| 学位论文 | 用户有thesis需要语言审查 | "论文的表达帮我审一下" |
| 文献综述 | 用户有综述需要术语一致性 | "这个综述看看术语是否统一" |

#### 管理沟通
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| 全员通知 | 用户有公司公告需要审查 | "这个全员邮件看看表达" |
| OKR/绩效 | 用户有OKR文档需要精准表达 | "这些OKR描述审一下措辞" |
| 项目报告 | 用户有项目报告需要可读性 | "这个周报看看表达有没有问题" |
| 政策文档 | 用户有政策文档需要清晰 | "这个政策文档审一下" |
| 会议纪要 | 用户有会议纪要需要审查 | "这个纪要的表达审一下" |

#### 产品文案
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| UI文案 | 用户有界面文案需要审查 | "这些按钮文字审一下表达" |
| 引导流程 | 用户有onboarding文案需要审查 | "这个onboarding流程的文字review" |
| 错误提示 | 用户有错误信息需要人性化 | "这些error message看看表达" |
| 通知文案 | 用户有push通知需要精简 | "这些push通知的文案审一下" |
| 帮助文档 | 用户有帮助文档需要审查 | "这个help center的表达" |

#### 培训材料
| 场景 | 触发信号 | 示例 |
|------|---------|------|
| 教程/指南 | 用户有教程需要可读性审查 | "这个tutorial的表达审一下" |
| SOP文档 | 用户有操作手册需要清晰度 | "这个SOP看看措辞是否精确" |
| 入职材料 | 用户有onboarding doc需要审查 | "新人指南的表达审一下" |
| 培训课件 | 用户有培训材料需要审查 | "这个培训材料的文案" |
| 知识库 | 用户有wiki需要一致性审查 | "知识库文章的措辞审一下" |

### 手动触发
- "审一下文案"
- "review the prose"
- "文案检查"
- "文本审查"
- "改改措辞"
- "edit this"
- "看看表达有没有问题"
- "帮我润色一下"

当内容涉及贵州之客对客文案时，自动提示：是否同时加载 `zhike-content-output` 技能获取内容规范？

## 输入

- **content**（必需）— 待审查的文本单元（markdown/纯文本/含文本的XML）
- **style_guide**（可选）— 项目特定风格指南。提供后覆盖本技能的所有通用原则（除「内容神圣不可侵犯」）
- **reader_type**（可选，默认 `humans`）— `humans` 为标准编辑，`llm` 为精确度优先

---

## 原则

1. **最小干预** — 应用最小的改动来实现清晰
2. **保留结构** — 在现有结构内修复文案，从不重构
3. **跳过代码/标记** — 检测并跳过代码块、frontmatter、结构化标记
4. **不确定时标记为疑问** — "考虑：{建议}？"而非断言
5. **去重** — 同一问题出现在多处 = 一个条目列出所有位置
6. **无冲突** — 合并重叠修复到单一条目
7. **尊重作者声音** — 保留有意的风格选择

> **风格指南优先**：如果提供了 style_guide，它覆盖除「内容神圣不可侵犯」以外的所有通用原则。风格指南是语调、结构、语言选择的最终权威。

## 内容神圣不可侵犯

**永远不挑战观点——只优化表达方式。**

---

## 执行流程

### Step 1: 验证输入

- 检查内容是否为空或少於3个词 → 暂停："内容太短，无法进行文案审查（至少需要3个词）"
- 验证 reader_type 为 `humans` 或 `llm`（或未提供，默认 `humans`）
- 识别内容类型（markdown/纯文本/XML含文本）
- 标记要跳过的代码块、frontmatter、结构化标记

### Step 2: 分析风格

- 分析输入文本的风格、语调、声音
- 标记要保留的有意风格选择（非正式语调/技术术语/修辞模式）
- 根据 reader_type 校准审查方向：
  - `llm` → 优先：无歧义引用、一致术语、显式结构、不模糊
  - `humans` → 优先：清晰、流畅、可读性、自然递进

### Step 3: 文案审查（核心）

- 如果有 style_guide：先查阅其关键要求
- 审查所有文案段（跳过代码块等）
- 识别阻碍理解的沟通问题
- 对每个问题确定实现清晰的最小修复
- **去重**：同一问题多处出现 = 一个条目列出所有位置
- 合并重叠问题到单一条目
- 不确定时用疑问句式而非断言
- 保留作者声音

### Step 4: 输出结果

**三列表格**：

| 原文 | 修订后 | 变更说明 |
|------|--------|---------|
| 原文确切段落 | 建议修订 | 简要解释变更及原因 |

无问题 → 输出 "未发现文案问题"

---

## 审查维度

| 类别 | 检查项 |
|------|--------|
| **语法准确性** | 主谓一致、时态一致、冠词使用、语序 |
| **简洁性** | 冗余词、空洞修饰语、可说可不说的句子 |
| **清晰度** | 歧义指代、模糊表述、逻辑跳跃 |
| **一致性** | 术语统一、风格一致、格式规范 |
| **可读性** | 句子长度、段落密度、信息层次 |
| **准确性** | 事实错误、数字矛盾、时间线混乱 |
| **语调** | 是否匹配受众、是否过于正式/随意 |

---

## 与 Hermes 技能的集成

### 与 zhike-content-output 搭档

zhike-content-output 定义了贵州之客对客文案的铁律（不绝对化虚假宣传、不诋毁同行、感官沉浸式描写、文学性语言、每个句子值其位置）。Editorial Review Prose 是执行这些铁律的**审查工具**——

```
营销文案产出后 → 加载 zhike-content-output 获取内容规范
→ 将内容规范作为 style_guide 传入 ER-P
→ ER-P 逐条检查是否符合铁律
→ 输出三列表格修订建议
```

### 被 answer Phase 7 调用

```
Review 阶段对产出文档做文案质量门禁：
加载 editorial-review-prose，对最终交付物文档逐段审查。
```

### 被 travel-intel 周报调用

```
每周分析报告生成后 → 加载 ER-P 审查推送文案。
```

---

## 约束

- 不替代作者声音，不"美化"有意的风格选择
- 不确定时用疑问句，不强行断言
- 跳过代码块、frontmatter
- 输出为三列表格，不是段落评论

## 验证清单

- [ ] 输入至少有3个词
- [ ] reader_type 有效（默认 humans）
- [ ] 代码块/frontmatter 被正确跳过
- [ ] 每个建议都是"最小可行修复"
- [ ] 输出为三列表格或"未发现文案问题"