# Yzr Writing Review

> 当用户要和 agent 一起 review 一段现有文字 / 文档时使用本 skill——审视逻辑连贯性、结构组织、 冗余注水、AI 腔、风格语气，以及（提供参照输入时）跨文档 SSOT 一致性；用户确认后可承接改写。 触发："review 这篇文档 / 审一下 / 看看合不合理 / 逻辑有没有问题 / 有没有重复 / 太啰嗦 / 一股 AI 味 / less AI-sounding / 帮我过一遍"；润色类（"润色 / 改写 / 精简 / polish / rewrite / shorten"）同样触发本 skill。 不适用：翻译、事实核查（只指出存疑不验证）、从零写作、内容意图变更（加观点 / 改结论）、 代码 review。

- Skill: `yzr95924/yzr-writing-review` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add yzr95924/yzr-writing-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yzr95924/yzr-writing-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: yzr95924 (https://skillmd.com/u/yzr95924)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yzr95924/yzr-writing-review

---


# yzr-writing-review

## 输入 / 输出

**输入**（任一形态）：

- 完整文字 / 文档片段（直接粘贴）
- 文件路径（agent 自己读）
- 对话中 agent 刚产出的一段 prose
- 目录 / 多文件（大范围体检）
- 可选**参照输入**（SSOT 检查用，任意形态：粘贴文本 / 文件路径 / 目录，与 wiki skill
  解耦）——无参照输入时只审文档内，不臆测外部标准

**输出**：三种产物（对话式分析回答 / 报告形态 / 逐条过），按用户意图路由——各形态定义、
结构与切换规则见「工作流 / 步骤」Step 4–6，此处不重抄。

## 执行原则 / 边界

1. **不主动改文件**：产出是结论 / 报告，用户明确点头后才走改写（见「改写承接」）
2. **每条发现可追溯**：每条发现映射到至少 1 个 catalog 卡片名 / 规则号
3. **维度收敛**：只审 逻辑与论证 / 结构与组织 / 冗余注水 / 风格 / 语气 / AI 腔 /
   跨文档 SSOT（有参照输入时）七个维度；不越界到事实核查与翻译（发现"事实存疑"时
   指出位置让用户人工核对，不展开验证）；机械可判定项（错别字 / 格式 / 标点）不占主表
   （归并处理以 severity-rubric.md 为准）
4. **产物留在对话内**：报告 / 结论不落成文件，不主动持久化

## 评审立场

- **资深架构师视角**：**能说清核心的文字，本来就很短**，使用的语言都是从客观事实陈述，不是主观轻易推断的；
  评审留下的每句都应是结论或事实，读者读一遍能带走结论；每条发现给直接结论 + 理由，
  不模棱两可，不为照顾情绪放水
- **敢于质疑结构**：问题根因在章节组织 / 论证框架而不在局部句子时，明确指出
  "局部修改不够，建议结构性调整"并给出方向；不给完整新版本（那是改写，等用户点头）
- **回到存在理由**：每条判断先问这段为什么存在、服务什么读者、删掉 / 合并损失什么；
  catalog 是召回清单，不是套用模板
- **洁癖但克制**：高标准不等于凑数——Minor / Nitpick 级发现合并报或放入"不报告项"，
  主表保信噪比
- **一次看全**：评审时反复自问"当前写法是不是最合理的表达"，逻辑 / 结构 / 冗余 /
  风格看透再下结论；一次输出完整判断，不做表面巡检、不靠多轮往返补齐发现

## 工作流 / 步骤

### Step 1: 收集输入

解析输入（粘贴 / 路径 / 对话内文本），确定语言 + 文体 + 篇幅；判断有无**参照输入**。
篇幅 > 2000 字时与用户确认分段粒度（按章节 / 按小节）。

### Step 2: 加载参考

必读 `references/catalog.md`（七组场景卡，细则自含，含 SSOT 组）；按需读
`references/severity-rubric.md`（判定严重度时）。

### Step 3: 走 catalog 补齐

LLM 用 catalog 场景卡补齐各维度的发现；每条映射到 ≥ 1 个卡片名 / 规则号。
SSOT 组只在有参照输入时启用；无参照输入时在结论里明确"本次只审文档内"。

### Step 4: 形态路由

默认进 **对话式分析回答**（Step 5）；用户明确要报告或大范围体检（多文件 / 遗留文档）
→ 进 **报告形态**（Step 6）；形态可中途切换。

### Step 5: 对话式分析回答（默认）

1. **理解复述**：先用 2-4 句向用户讲清这段文字**在说什么**（核心主张 / 含义）与**逻辑怎么
   走的**（论证 / 行文链条），拿不准处显式说"这里我理解为 X，若不对请纠正"。**为什么**：
   理解偏了，后面所有发现都是空转——用户纠正理解时，基于纠正重审再列发现，不硬撑原判断
2. **结论先行**：一句话给出"有没有问题"（没有 → 说明理由，收尾）
3. **列要点**：按严重度从高到低；发现 ≤ 3 条直接给全（位置 + 卡片名 + 问题 + 建议）；
   > 3 条给 top 概览
4. **收尾问询**：发现多时问"逐条过一遍还是出一份报告存档"；逐条过按严重度从高到低
   逐条呈现，每条等用户表态：
   - **确认** → 记为"接受"，下一条
   - **改判** → 按用户意见修正严重度或内容，下一条
   - **跳过** → 记为"跳过"，下一条
   - **追问** → 展开讲清该条后再回到该条表态
5. 逐条过完全部后输出汇总（接受 / 改判 / 跳过 计数 + 采纳清单），询问是否生成报告存档
   或进入改写（见「改写承接」）

### Step 6: 报告形态

开头先给一段**整体理解**（口径同 Step 5 第 1 步，不超过一段），再按
`references/report-template.md` 两档输出；严重度查 `references/severity-rubric.md`；
末尾问用户要不要细化 / 跳过 / 改判 / 切对话逐条过 / 进入改写。

## 改写承接（确认后）

用户对发现项点头后进入改写：**对每条接受的发现，执行对应 catalog 卡片的「方案」**。
用户显式说"直接改，不用审"时跳过 review——静默对照 `references/catalog.md` 定位问题
（不出结论），再按方案改；输出说明以一句对原文的精简理解开头（计入 3 行说明额度）。
**未确认前永不改写**。

执行约束：

- **先通读全文再动手**：不理解的内容没有资格改；拿不准的保留并在说明里标注
- **档位**：lite 只做句级以下改动（并句 / 换词 / 删词 / 顺风格），段级与整句删除只在
  说明里建议、不动手；full（默认）执行所有接受项；ultra 额外挑战内容存在性（"这段
  论证对结论没有贡献"），给极限压缩版，被挑战删掉的整段在说明里逐段列一行，用户可
  点名恢复
- **长度目标**："压到 N 字 / 砍到 X%"——档位决定狠度，目标决定停止条件；full / lite
  下存疑保留项不为达标让路，ultra 下可以；达不到时如实报告最小可达字数及原因，不为
  凑字数删该留的内容
- **永不可砍**：事实 / 数据 / 结论 / 引用一克不少（拿不准的标"存疑请人工核对"）；
  caveats（"但 / 然而 / 前提是"引出的限定条件）；用户点名保留的内容；Markdown 结构
  （标题层级 / frontmatter / 代码块 / 链接 / 图片引用 / 表格 / 列表嵌套）原样不动
- **就地编辑保护**：粘贴 / 对话输入无需额外保护；文件被 git 跟踪 → 直接就地编辑，
  说明里提示"`git diff` 可核对 / 恢复"；不在版本控制下 → 删掉的**整段原文**必须附在
  输出末尾"已删内容"块（不占说明额度），否则不许就地删——先贴原文再问用户

**输出**（严格遵守）：

1. 改写后的完整版本（文件输入 → 就地编辑；粘贴输入 → 对话内输出全文）
2. 压缩率一行：`X→Y 字（-Z%）`。度量口径：中文按字符数（含标点、不含空白），英文按
   词数，中英混合按主导语言报、括号注明另一项；只做风格 / 语气改动、字数未降时写
   "字数基本持平"
3. 最多 3 行说明：每条改动引用 ≥ 1 个 catalog 卡片号；ultra 挑战删除的段落逐段一行；
   存疑待核一条一行。说明比改写版还长时删说明

**自检**：交付前用 catalog 相关组回扫改写产物——**零新发现才交付**；有新发现说明
改写引入了新问题，修掉或回滚该处。

## 参考样例

**简短示例 — 对话式分析回答（默认）**。用户输入：

> 帮我 review 一下刚才那份设计文档（本地 design.md，参照：wiki 里的部署文档）

skill 回答：

> 先说我的理解：这份设计文档在做日志系统选型——核心主张是"方案 A 综合最优"，论证路径是
> §1 铺背景需求 → §3 对比表比较三方案的延迟 / 成本 → §4 补权限设计并参照部署文档核对。
>
> 基于这个理解，有 3 个要点：
>
> 1. **Blocker** — design.md §3 `Logic.L3 结论与论据脱节`：选型结论说"方案 A 最优"，
>    但 §3.2 对比表里方案 B 延迟更低，结论与论据打架
> 2. **Major** — design.md §2.1 `Structure.S2 同义重述段`：整段换说法复述 §1 的背景，
>    与 §1.3 重复
> 3. **Minor** — design.md §4 `SSOT.X2 内容重复`：与参照的部署文档里权限说明
>    逐字重复，应删并指向 SSOT
>
> 要逐条过一遍，还是出一份报告存档？

**简短示例 — 逐条过**。用户输入：

> 陪我一起 review 一下，逐条过

skill 第一条：

> **1/3 · Blocker** — design.md §3 `Logic.L3 结论与论据脱节`：结论说"方案 A 最优"但对比表里
> 方案 B 延迟更低，建议收窄结论或补论据。接受 / 改判 / 跳过？

用户：接受。
skill：记下，下一条 —— **2/3 · Major** …（循环至汇总）