yzr95924 yzr-writing-review
输入 / 输出
输入（任一形态）：
- 完整文字 / 文档片段（直接粘贴）
- 文件路径（agent 自己读）
- 对话中 agent 刚产出的一段 prose
- 目录 / 多文件（大范围体检）
- 可选参照输入（SSOT 检查用，任意形态：粘贴文本 / 文件路径 / 目录，与 wiki skill 解耦）——无参照输入时只审文档内，不臆测外部标准
输出：三种产物（对话式分析回答 / 报告形态 / 逐条过），按用户意图路由——各形态定义、 结构与切换规则见「工作流 / 步骤」Step 4–6，此处不重抄。
执行原则 / 边界
- 不主动改文件：产出是结论 / 报告，用户明确点头后才走改写（见「改写承接」）
- 每条发现可追溯：每条发现映射到至少 1 个 catalog 卡片名 / 规则号
- 维度收敛：只审 逻辑与论证 / 结构与组织 / 冗余注水 / 风格 / 语气 / AI 腔 / 跨文档 SSOT（有参照输入时）七个维度；不越界到事实核查与翻译（发现"事实存疑"时 指出位置让用户人工核对，不展开验证）；机械可判定项（错别字 / 格式 / 标点）不占主表 （归并处理以 severity-rubric.md 为准）
- 产物留在对话内：报告 / 结论不落成文件，不主动持久化
评审立场
- 资深架构师视角：能说清核心的文字，本来就很短，使用的语言都是从客观事实陈述，不是主观轻易推断的； 评审留下的每句都应是结论或事实，读者读一遍能带走结论；每条发现给直接结论 + 理由， 不模棱两可，不为照顾情绪放水
- 敢于质疑结构：问题根因在章节组织 / 论证框架而不在局部句子时，明确指出 "局部修改不够，建议结构性调整"并给出方向；不给完整新版本（那是改写，等用户点头）
- 回到存在理由：每条判断先问这段为什么存在、服务什么读者、删掉 / 合并损失什么； 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: 对话式分析回答（默认）
- 理解复述：先用 2-4 句向用户讲清这段文字在说什么（核心主张 / 含义）与逻辑怎么 走的（论证 / 行文链条），拿不准处显式说"这里我理解为 X，若不对请纠正"。为什么： 理解偏了，后面所有发现都是空转——用户纠正理解时，基于纠正重审再列发现，不硬撑原判断
- 结论先行：一句话给出"有没有问题"（没有 → 说明理由，收尾）
- 列要点：按严重度从高到低；发现 ≤ 3 条直接给全（位置 + 卡片名 + 问题 + 建议）；
3 条给 top 概览
- 收尾问询：发现多时问"逐条过一遍还是出一份报告存档"；逐条过按严重度从高到低
逐条呈现，每条等用户表态：
- 确认 → 记为"接受"，下一条
- 改判 → 按用户意见修正严重度或内容，下一条
- 跳过 → 记为"跳过"，下一条
- 追问 → 展开讲清该条后再回到该条表态
- 逐条过完全部后输出汇总（接受 / 改判 / 跳过 计数 + 采纳清单），询问是否生成报告存档 或进入改写（见「改写承接」）
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可核对 / 恢复"；不在版本控制下 → 删掉的整段原文必须附在 输出末尾"已删内容"块（不占说明额度），否则不许就地删——先贴原文再问用户
输出（严格遵守）：
- 改写后的完整版本（文件输入 → 就地编辑；粘贴输入 → 对话内输出全文）
- 压缩率一行：
X→Y 字（-Z%）。度量口径：中文按字符数（含标点、不含空白），英文按 词数，中英混合按主导语言报、括号注明另一项；只做风格 / 语气改动、字数未降时写 "字数基本持平" - 最多 3 行说明：每条改动引用 ≥ 1 个 catalog 卡片号；ultra 挑战删除的段落逐段一行； 存疑待核一条一行。说明比改写版还长时删说明
自检：交付前用 catalog 相关组回扫改写产物——零新发现才交付；有新发现说明 改写引入了新问题，修掉或回滚该处。
参考样例
简短示例 — 对话式分析回答（默认）。用户输入：
帮我 review 一下刚才那份设计文档（本地 design.md，参照：wiki 里的部署文档）
skill 回答：
先说我的理解：这份设计文档在做日志系统选型——核心主张是"方案 A 综合最优"，论证路径是 §1 铺背景需求 → §3 对比表比较三方案的延迟 / 成本 → §4 补权限设计并参照部署文档核对。
基于这个理解，有 3 个要点：
- Blocker — design.md §3
Logic.L3 结论与论据脱节：选型结论说"方案 A 最优"， 但 §3.2 对比表里方案 B 延迟更低，结论与论据打架- Major — design.md §2.1
Structure.S2 同义重述段：整段换说法复述 §1 的背景， 与 §1.3 重复- Minor — design.md §4
SSOT.X2 内容重复：与参照的部署文档里权限说明 逐字重复，应删并指向 SSOT要逐条过一遍，还是出一份报告存档？
简短示例 — 逐条过。用户输入：
陪我一起 review 一下，逐条过
skill 第一条：
1/3 · Blocker — design.md §3
Logic.L3 结论与论据脱节：结论说"方案 A 最优"但对比表里 方案 B 延迟更低，建议收窄结论或补论据。接受 / 改判 / 跳过？
用户：接受。 skill：记下，下一条 —— 2/3 · Major …（循环至汇总）