jorinyang 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为精确度优先
原则
- 最小干预 — 应用最小的改动来实现清晰
- 保留结构 — 在现有结构内修复文案，从不重构
- 跳过代码/标记 — 检测并跳过代码块、frontmatter、结构化标记
- 不确定时标记为疑问 — "考虑：{建议}？"而非断言
- 去重 — 同一问题出现在多处 = 一个条目列出所有位置
- 无冲突 — 合并重叠修复到单一条目
- 尊重作者声音 — 保留有意的风格选择
风格指南优先：如果提供了 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 被正确跳过
- 每个建议都是"最小可行修复"
- 输出为三列表格或"未发现文案问题"