用途：这是发布说明流水线中的编辑质检环节，从读者而非实现者视角审计已评分的 features.json 及其 Markdown 草稿，确保发布说明经过筛选、易读且对目标读者有吸引力，而非 API 清单。它复用 editorial-scoring 的共享评分标准来批评评分，不另创评分体系。
使用时机：在 generate-features 生成 features.json 之后、release-notes 起草 Markdown 之后使用；当选题过宽、过窄或过于内部视角，或想对照示例重新校准取舍时使用。
输入（按顺序）：changes.json（已发布内容的真实来源）、features.json（评分候选列表，如存在）、草稿 Markdown 文件（libraries.md、runtime.md、sdk.md 等）、references/examples/ 中的编辑示例，以及评分与质量标准参考：../editorial-scoring/SKILL.md、references/feature-scoring.md、references/quality-bar.md。若 features.json 尚不存在，可从哪些功能被提升为标题、各功能占用篇幅、哪些被归入 bug 修复桶或省略来推断当前隐含评分。
核心审查问题：沿用共享评分标准，保持相同的以读者为中心的 10/8/6/4/2/0 量表与 80/20 受众过滤，对照示例检查草稿是否仍在教学而非仅罗列。示例检查包括：篇幅是否与重要性匹配、中等价值项是否被分组而非单列大节、性能故事是否有证据支撑、草稿是否在讲述而非枚举。
常见失败模式：评分过高（过多 4-6 分项被提升为顶级章节）、解释不足（真正的 8+ 功能被埋没或未清晰框定）、API 清单模式（草稿开始模仿 api-diff 而非讲述用户故事）、技术新颖性偏见（巧妙实现细节压过实际用户价值）、遗漏回退（被提升的功能后来被撤回或未出现在实际构建中）。
多模型审查模式：最终编辑质检可用两名审查者并行检查以获得更广视角，首选 Claude Opus 4.6 与 GPT-5.4。给两者相同输入与相同输出要求：最正确的评分、最错误的评分、重要遗漏、删减清单。然后综合重叠与分歧，共识是强信号但不做盲投，对 changes.json、共享评分标准和仓库编辑规则的忠实仍优先。
审查者清单：不要问“你喜欢吗”这类模糊问题，而给出具体检查：哪些标题仍含糊、被动、拟人或宣传化；哪些章节未通过 80/20 读者价值测试应删减、分组或降级；哪些句子推断感受或结果（信任、信心、更容易、更好）而非陈述具体变更；哪些章节滑向 API 清单模式；哪些被提升项后来被回退、撤回或缺失于实际构建/包集合（引用回退 PR 或验证缺口）；哪些代码示例薄弱、混乱或缺乏文本支撑；哪些链接、issue/PR 引用或格式细节仍违反内部风格；草稿中仍需要的单项最高价值重写是什么；措辞是否常规，是否发明了非标准说法；主语与其形容词/副词搭配是否自然；该措辞放在其他开发者平台的发布说明中是否正常；若 release-notes/features.json 列出该功能，章节是否以标准预览引用块开头。要求审查者以“文件 + 标题 + 问题 + 建议重写”作答，产出可操作审查而非泛泛品味反馈。
输出：返回简洁审查，包含最正确的评分（优先级最佳的功能）、最错误的评分（过高与过低评分项）、重要遗漏（changes.json/features.json 中可能应提升的项）、删减清单（应优先分组、压缩、降级或删除的内容）。经验规则：8+ 值得成节；6-7 为分组段落或短节；0-5 归入 bug 修复桶、一句话或删除。