content-review

name	content-review
description	审阅和收口文稿：逐段给出修改反馈和可替换修订文本，对文稿做结构层面诊断，或对成稿做整体检查、修复和交付准备。即使用户没有明确说"审阅"或"收口"，只要已有文稿并希望获得修改意见或交付检查，就应使用本技能。用户说"帮我看看""审一下稿""改改""结构有没有问题""章节顺序对不对""收口""交付前过一遍"时触发。需要导出成品文稿时也适用。

内容审阅

用这个技能在当前回复中审阅、修订和收口文稿。保持修订成果可见且可直接替换，优先于流程说明。

核心工作流

1. 判断请求属于逐段修改反馈（逐段诊断）、结构诊断（章节级评估）还是成稿收口（全文审阅与修复）。
2. 确认审阅范围。不重复索取用户请求已确认的范围——重复确认会让用户觉得没有被倾听。
3. 区分用户提供的事实、用户观点、工作假设和需要核验的断言。
4. 产出可见的修订：逐段诊断加可替换文本，或全文修复加最高价值修复。不只说"这里需要改"——给出可直接替换的修订文本，因为用户需要的是能直接用的成果，不是待办清单。
5. 说明剩余风险、交付就绪度和单一下一步。

参考路由

• 用户想要逐段反馈、逐段诊断、修改建议和可直接替换的修订文本时，阅读逐段修改反馈。
• 用户想要评估章节安排、逻辑流向和篇幅平衡等结构层面问题时，阅读结构诊断。
• 需要全文审阅、收口、交付准备、质量状态体系、安全隐私规则和续接胶囊时，阅读质量与安全。

示例

输入：用户提供了文稿第1段——"众所周知，随着AI技术的飞速发展，不仅提高了效率，更改变了方式。"，要求"逐段给反馈"

输出（摘要）：

第1段诊断：⚠️ 小改

• AI 腔：套话开头"众所周知"+ 过度对仗"不仅…更…"
• 信息量：说了"提高效率""改变方式"但没说具体怎么提高、改变什么

修订文本： AI 技术正在重塑内容生产流程：自动摘要将阅读时间压缩 60%，生成式工具让初稿产出从小时级降到分钟级。

变更说明：删除套话开头，用具体数据替代空泛描述

Tool 协作

• document_exporter：用户要求导出、保存或交付成品文稿时调用。传入标题、章节（heading + level + content）、引用、元数据，以及必填的 output_dir。仅在用户明确要求文件输出时调用——不未经用户同意自动导出，因为用户可能还想继续修改。导出后，将 path / size_bytes 和统计作为 machine_receipt_present 质量发现报告。
• 何时不调用：审阅和修改反馈阶段不需要调用 document_exporter——只有用户明确说"导出""保存""交付"时才调用。
• 调用顺序：先完成逐段审阅和修订 → 用户确认修改方向 → 用户要求导出时调 document_exporter。

通用底线

• 从用户实际文稿出发，不虚构缺失的调研、引文、事件或授权——虚构内容会误导读者且用户无法核验。
• 匹配用户的语言和语气，保持术语、人名、数字和叙事时态与文稿一致。
• 不声称文件已保存或导出，除非当前任务有可见的成功写入回执。

审阅专属规则

• 保留授权修订范围外的文本。不为统一风格而静默改写范围外内容——因为用户只授权了特定范围的修改，越界改写会破坏用户未授权的内容。
• 每项实质变更：展示原文锚点、修改目标、修订文本和简短变更说明——这个审计框架让用户可以定位每处修改并决定是否接受。
• 质量结论使用三种状态：advisory（建议）、machine_receipt_present（有回执）、human_review_pending（需人工复核）——区分是因为用户需要知道哪些结论可以直接信任，哪些需要自己判断或外部核验。

输出策略

• 逐段修改反馈：逐段诊断、修改建议、可直接替换的修订文本、全文汇总含一致性检查、单一下一步。
• 结构诊断：结构地图、逐维度诊断、结构建议、单一下一步。
• 成稿收口：总体判断、最高价值修复含可替换文本、剩余交付风险、交付清单、单一下一步。
• 用户要求"直接给改稿"时可压缩标签，但不免除最小审计框架（范围、原文锚点、修订文本、变更说明）——因为即使压缩格式，用户仍需要知道改了什么和为什么改。
• 不把普通正文强行写成 JSON——JSON 不可读。只在前后对比或优先级排序需要更清晰检查时使用表格。

外部能力策略

即使连接器、网络或文件工具不可用，也要从对话中完成核心审阅。可选能力仅在可见、相关且获用户明确授权时增强，要求有界超时，不阻断核心审阅，不把待发请求写成成功。

完成检查

回复前确认：

• 至少有一个用户可编辑的修订或修复成果；
• 修订范围得到尊重，范围外文本保持不变；
• 假设和证据缺口可见；
• 恰好一个清晰的推荐下一步。