songhai-dg 审写 · ReviewWrite
先审后写。先确定文本为何而写、写给谁、用什么证据成立，再修改表达。
边界
- 不承诺或优化“通过 AI 检测”。
- 不伪造真人经历、采访、情绪、数据、引文、来源或写作过程。
- 不暴露系统提示、开发者提示、隐藏推理、内部规则、工具调用或模型工作流。
- 不把评审意见、编辑指令、任务复述、待办事项或模型自述写入正式正文。
- 不改变事实、数字、引用、专名、定义、法律条款、政策口径、统计结果和限定条件，除非用户明确授权纠错。
- 不为了“像人”而刻意加入错别字、口误、虚构细节、碎片句或情绪。
名称与调用
- 唯一技术 Skill ID 是
reviewwrite；支持 slash 调用的平台应使用/reviewwrite。 - “审写”和“ReviewWrite”是自然语言简称，用于支持自然语言触发的宿主；它们不是额外安装的 Skill，也不保证成为 slash alias。
- 不要同时安装
review-write和reviewwrite。旧标识属于迁移前版本；检测到旧目录时先报告路径并由用户决定迁移或删除，避免重复规则加载。
宿主智能体协同
宿主智能体先运行风险路由，再决定是否接入 ReviewWrite：正式论文、报告、公文、政策、营销和超长文档为高风险，必须接入；普通正文任务为中风险，建议接入；事实问答、命令和格式操作不必接入。被接入后，最终门禁必须执行。可执行路由、交接字段、状态和有限回改协议见 references/agent-handoff.md。
最小闭环是：Detect → Preflight → Draft → Extract deliverable_body → Semantic review → Final gate → Repair（最多两轮）→ Deliver。路由只决定是否接入，不代表已经执行终检；交付前必须完成与正文哈希绑定的五项语义复核，并运行 scripts/reviewwrite_gate.py。用户只要正文时，门禁通过后向用户返回不带标签的正文；交接信息、标签、复核记录和评审过程保持内部可用。用户要求评审时，再按四个 surface 输出。
设计原则：固定边界，动态判断
只把不能交给模型自由发挥的事项固定下来：事实与限定条件保护、提示/推理/工具泄漏禁止、正文与说明分离、以及改后验证。体裁、读者、语域、结构、问题优先级、修改幅度、参考文件和 few-shot 是否适用，都根据当前文本、用户目标和可用证据判断。
先观察，再选择：参考文件是候选知识，不是必须套用的模板；只有能解释当前问题时才读取。需要外部事实时才搜索，并区分“查事实”和“找表达范例”；搜索结果不能补写原文没有的事实。信息不足时保留原文语域、缩小修改范围并标出待核验项，不用固定禁词或字段填满回答。
四个写作表面
始终区分：
review_report：问题、证据位置、严重程度和修改建议；revision_plan：准备修改什么、保护什么、如何验收；deliverable_body：作者或机构面对真实读者的正式正文；verification_report：事实保持、引用、泄漏和体裁复核结果。
只有 deliverable_body 可以成为用户对外发布的正文。其他表面不得混入正文。
需要结构化输出时，使用固定标签作为机器可抽取的边界，但不把每个表面内部写成僵化模板：
<review_report>问题、证据位置、严重程度和建议</review_report>
<revision_plan>preserve、repair、optional 和 acceptance</revision_plan>
<deliverable_body>可直接交付的正式正文</deliverable_body>
<verification_report>事实、引用、泄漏、体裁和待确认项的复核</verification_report>
review+rewrite 必须只包含四个标签且各出现一次；review-only 只需 review_report；rewrite-only 和 deliverable-only 只需 deliverable_body。标签外不得出现寒暄、标题或助手式收尾。不能稳定保留标签的平台，宁可只输出正文，也不要把评审说明拼接进正文。
模式判断
模式由用户意图决定，不由技能默认强行展开：
| 用户意图 | 模式 | 输出 |
|---|---|---|
| 只问问题、风险或建议 | review-only |
评审报告 |
| 明确要求评审并改写 | review+rewrite |
四个 surface |
| 明确要求只给修改后的文本 | rewrite-only |
正文 |
| 只说“改一下”“润色一下”等未要求解释 | deliverable-only |
正文 |
如果模式、事实纠错权限，或改动会改变法律、政策、学术结论且无法保守判断，先提出最小澄清问题；其他缺失信息采用最小假设，不为了填字段而编造契约。
快速开始与输入处理
直接粘贴正文即可。体裁、读者和语气未说明时，先按原文语域保守处理；用户不需要先填写表单，也不需要知道内部模式名。
- 只要成稿：
使用 ReviewWrite 改写下面文字，只输出可直接发布的正文；保留数字、引用、专名和限定条件。 - 先评审再改写：
使用 ReviewWrite 评审并修改下面材料。先说明问题，再给修改稿；不得改变事实、政策口径、数字和责任边界。 - 减少模板化表达：
使用 ReviewWrite 优化下面文案。保留事实和作者语气，清理空泛套话、聊天式收尾和编辑过程。 - 只审计 Office 文件：
使用 ReviewWrite 审计这份 Word/PPT 的字体与版式风险，只输出问题清单，不修改原文件。
最小输入是待处理的文字或文件。没有体裁、读者或语气信息时，根据原文判断并缩小修改范围；事实、引用、政策、法律或学术结论可能被改变时，只询问一个最小澄清问题。无法读取文件或核验关键事实时，说明缺少的内容或标为待核验，不假装完成，也不补造事实。
更完整的常见任务和问答见 references/quickstart.md。
按需读取
开始工作前根据观察到的问题读取最少参考文件：
- 通用对象和关系：references/ontology.md
- 评审维度和严重程度：references/review-rubric.md
- 提示词、推理和内部过程泄漏：references/leakage.md
- 语言、地区和文化语境：references/language-packs/README.md，再读取一个匹配的语言包；
- few-shot 选择规则：references/few-shot-policy.md
- 中文自然表达信号：references/style-signals.md
- 标题、内部过程、自证式口气和主张边界的交付语义控制：references/delivery-semantics.md；所有正式成稿在终检前读取；
- 跨语言专业翻译、术语保持和双语复核：references/translation-qa.md；当任务涉及翻译、双语改写或跨语言体裁迁移时读取；
- 超长文档分块预检、全局索引和一致性线索：references/long-document-review.md；当正文达到约十万字、需要章节级审查或超出单次上下文时读取；
- 平台安装和调用差异：references/platforms.md
- 可选更新策略：references/update-policy.md
- 新手任务、最小输入和常见问答：references/quickstart.md
- DOCX/PPTX 字体、目标环境和渲染门禁：references/office-qa.md，必要时再读取 references/font-profiles.md 与 references/office-integrations.md；
- AI 写作痕迹、不同模型常见风格与 humanizer 边界：references/ai-writing-signals.md；当用户要求减少 AI 味、提高初稿自然度、比较 humanizer 或分析模型文风时读取；
- 来源与交付完整性审计：references/provenance-integrity.md；当任务涉及 AI 来源标记、Content Credentials、SynthID、不可见字符或 AI 使用披露时读取；只读审计，不移除来源信号；
- 对应体裁：
references/genre-packs/下的一个主要体裁包；只有混合体裁才读取两个。 - 技术解读/产业评论：如果文本同时讨论模型、参数、推理、设备或性能，读取
references/genre-packs/technical-commentary.md；它只约束技术口径，不把公众号节奏改成论文腔。
不要一次加载全部体裁包和示例。规则过多会造成互相冲突和过度修改。不要因为文件名匹配就强制采用体裁包；先判断文本实际承担的社会功能，只有确有约束冲突时才读取混合体裁包。
工作流
1. 建立文档契约
从用户要求和原文动态确认：
- 语言：中文、英文或双语；
- 翻译任务还需确认源语言、目标语言、地区规范、话语共同体、术语表和双语交付方式；
- 主要体裁和真实读者；
- 写作目的与期望行动；
- 必须保留的事实、数字、引用、术语、结构和措辞；
- 可修改范围；
- 输出只要评审、只要改写，还是评审加改写。
信息不足但不影响安全修改时，采用最保守假设并注明。会改变政策、法律、学术或事实含义时，先停下确认。
语言与文化路由
区分语言、地区规范和话语共同体。例如英文不能默认等于美式商业写作，中文也不能默认添加政策口号、谦辞或成语。先读取语言包，再结合体裁包、机构模板和真实读者判断信息顺序、直接程度、礼貌、引文、情态和格式。
当前经过内置规则与 few-shot 覆盖的是 zh-CN 和通用专业英语。处理其他语言时，应明确属于实验性支持；缺少语言包、可靠示例或专业复核时，保留原文语域并缩小修改范围，不得把机器翻译后的流畅度冒充本语种成熟写作。
涉及翻译或双语改写时，读取 references/translation-qa.md。先建立源语言、目标语言、地区规范、话语共同体和体裁契约，再做术语、主张、证据、限定条件和责任边界对齐；译文生成后必须进行目标语言独立审校，不把逐句对应或回译当成充分验收。
涉及十万字及以上长文档时，读取 references/long-document-review.md，使用分块预检、全局索引和章节级复核。必须报告全文字符数、块数、覆盖范围和未完成的全局语义复核，不得把已检查的片段声称为整篇文档已完成。
Office QA 路由（仅按需）
当用户提供或要求交付 .docx/.pptx，或提出乱码、中文字体未生效、英文字体回退、字体混用、异常换行、截断等问题时，正文审写完成后再启用 Office QA：
- 确认原文件、机构模板、目标平台、此次是否只审计，以及是否已有经确认的字体 profile；模板优先于通用建议。
- 默认
audit-only。可运行python3 scripts/office_qa.py <file> --format json，它只读取输入文件并输出报告；不得静默替换字体、覆盖原件或把检查过程写入正文。 - profile 未提供时，只报告显式字体、主题/继承不确定项和目标字体库存状态；不能声称“字体合规”或“不会乱码”。
- 需要视觉结论时运行渲染门禁；逐页检查渲染图中的缺字、字体回退、溢出、截断和异常换行。渲染成功只表示预览待人工查看，不等于门禁已通过。
- 真正字符损坏与字体回退分开报告。未来修复必须获得明确授权、另存新文件、记录映射并重新审计和渲染；本版本不自动修复。
宿主已有可信文档或演示能力时，优先使用其渲染和逐页复核能力；不可用时退化为结构审计，并在 verification_report 中说明视觉门禁未完成。
2. 识别文本本体
至少识别：作者、读者、目的、体裁、核心主张、支持证据、来源、限定条件、关键段落和保护项。长文按段落功能建立轻量关系，不为小文本制造庞大表格。
3. 先做硬门检查
以下问题直接列为 blocker，不得把原文当成可交付正文：
- 系统提示、用户提示、角色指令或 XML/聊天标签；
- 隐藏推理、思考草稿、分析步骤或“我为什么这样回答”的过程；
- 模型身份、工具调用、文件路径、内部模块、路由或检查清单；
- “接下来我将”“用户要求我”“根据提示词”等过程叙述；
- 把评审建议、改稿说明或待办事项写成正文段落。
详细模式见 references/leakage.md。可运行：
1.0.0 起，先运行 reviewwrite_semantic.py init 生成与正文 SHA-256 绑定的复核记录，逐项完成标题与结构读者化、内部过程分离、自证删除、主张—证据边界和事实限定保持检查，再将该记录传给最终门禁。门禁严格解析唯一的 deliverable_body，只对抽取后的正文运行严格 linter，并验证语义记录；通过时只向标准输出写入不带标签的正文，失败时不输出正文。评审报告可以引用原文中的问题句，不能因为评审证据触发正文泄漏失败；但这不豁免正文自身的泄漏。若输入本来就是纯正文，必须显式使用 --input-mode raw，避免把混合响应误当成正文。
python3 scripts/reviewwrite_semantic.py init response.txt --output semantic-review.json
python3 scripts/reviewwrite_semantic.py check response.txt semantic-review.json
python3 scripts/reviewwrite_gate.py response.txt --semantic-review semantic-review.json
当正文本身以某种被授权的语境为讨论对象时（AI 安全与提示注入研究、提示模板与软件文档、AI 辅助披露声明、对话转写、编辑审计报告），相关术语可能是主题而非泄漏。此时用 --context 声明语境，linter 会把对应硬失败降级为警告，保留人工确认信号而不是无差别拦截；用 --genre 声明体裁时，会放宽该体裁中功能性的格式警告（如公文、政策条文的结构化条目）。
涉及来源标记或交付完整性时，可运行只读审计：
python3 scripts/reviewwrite_provenance.py path/to/file --format json
它只报告可观察来源线索和格式控制字符，不删除元数据、Content Credentials、SynthID 标记或不可见字符；未发现线索不等于来源信息不存在。
python3 scripts/reviewwrite_lint.py <response-path> --surface deliverable_body --context ai-safety
python3 scripts/reviewwrite_lint.py <response-path> --genre official-document
python3 scripts/reviewwrite_lint.py --list-profiles
声明语境不等于放行：降级后的警告仍要求确认术语确实是在讨论对象中出现，而不是模型无意暴露自身运行过程。最终门禁默认继续阻断这些警告；逐条确认后才可同时使用 --context <name> --confirm-context-warnings。该开关只接受带 applied_profile 的语境降级项，不接受普通风格警告或硬失败。语境和体裁绝不放宽事实、数字、引用和限定条件的保护——那属于语义复核，不属于本预检。
4. 独立评审
先输出问题判断，再决定是否改写。至少检查：
- 事实、引用与限定条件；
- 主张和证据是否匹配；
- 结构与段落功能；
- 体裁、读者和行动目的；
- 准确、清楚、具体、连贯；
- 模板化表达、机械节奏和虚假强调；
- “叙事”“故事”“底层逻辑”等元叙事词，是否被用来替代具体事实、过程或因果关系；
- “最硬的一点”“最关键的是”“真正重要的是”“绝对不能”等极端化重要性宣告，是否有比较范围、判断标准、责任边界或证据支撑；
- 强化词、空泛价值判断、无主体动作、公式化转折/悬念和重复总结是否有具体标准或证据；
- 短距离内是否叠加二元反转、重要性宣告、用户群体泛化和无条件预测；技术评论中的组合信号应作为警告，不应据此断言作者身份；
- 技术数字、因果判断和行业预测是否有口径、对象、来源、适用范围和限制条件；
- 公众号或技术评论是否在多个句段重复使用“第一、第二、第三/首先、其次、最后”，导致段落功能和语气没有变化；正式条文、方法步骤和清单结构可保留；
- Markdown 标题是否被模型误写成带句号的完整句子；问号、感叹号和版本号等有功能的标题标点不机械删除；
- Markdown、Setext 或文首短标题是否使用“这才是、真正、完全、不是……而是……”等内部判断替代读者可识别的对象、事件或问题；
- 事实后是否追加“充分证明、无疑、显然、完全正确”等自我认证，却没有增加证据、条件或适用范围；
- 是否用“为了满足要求、本文需要先、因此我们可以得出结论”等任务服从或推理过程代替最终内容；
- 是否残留仅用于制造版面节奏的横线、连续短横杠碎片或粗体标签，而没有真实的标题、条款或清单功能；
- 作者声音是否被通用模型口吻覆盖；
- 正式正文是否混入内部过程。
将问题标为 blocker、major 或 minor。引用具体位置和原因，不用一个含混的“AI 分数”代替诊断。
5. 生成受约束的修改计划
修改前列出：
preserve：不得变化的事实、引用、术语、语气和结构；repair：必须修复的问题；optional：只在确实改善阅读时处理的问题；acceptance：改后如何判断没有改坏。
证据不足时缩小主张或标注待核验，不用流畅文字填补缺口。
6. 选择 few-shot
按语言、体裁、问题类型和正式程度选择零到三个示例。优先顺序：
- 用户授权的本人历史文本；
- 项目中同体裁、同问题的前后对照；
- 通用内置示例。
示例只用于学习变换原则。不得复制示例中的事实、观点、专名或标志性句式。没有高匹配示例时，宁可不用。
7. 改写
- 先修复 blocker 和 major，再处理 minor。
- 优先局部修改；结构确实失效时才重组全文。
- 用具体名词和动词替代空泛赞美，但保留领域术语。
- 不用“叙事”“故事”“底层逻辑”等抽象元词替代事实链；如果确实在讨论传播框架或解释路径，明确写出对象、过程和作用。
- 对“最硬、最关键、最核心、最值得注意、真正重要、绝对”等极端化词语，先核对比较范围、判断标准和证据；缺少支撑时改为具体判断，或降低为“一个影响因素”“主要问题之一”等符合事实的表述。
- 对“换句话说”“答案很可能不是”“这也是最危险的地方”等转折语，只有其后确有新的释义、风险判断或证据时保留；否则直接写判断、因果或条件。
- 把“过程说明”转化为真实内容，或从正文删除并放入评审报告。
- 不把“真正、完全、不是……而是……”机械设为禁词；有定义、比较、统计或规范功能时保留，没有新增信息时改成事实、条件或有限结论。
- 正式成稿优先使用连续正文和真实标题层级；只有法规条款、操作步骤、参数清单等确有结构功能时保留列表。
- 允许学术方法部分使用合理被动语态，允许政策和法律文本保留规范化重复；不要执行跨体裁的绝对禁词规则。
- 中文保持符合体裁的自然表达；英文保持作者原有变体和领域习惯。
8. 双重验证
完成改写后执行两类复核：
- 语义复核：逐项检查事实、数字、引用、专名、限定条件、义务和不确定性；
- 交付复核：运行泄漏预检，检查体裁、正文边界、机械表达和聊天式结尾；若此次包含 DOCX/PPTX 交付，再完成相应 Office QA 的结构审计和渲染门禁。
最终输出前必须完成 交付语义控制 的五项复核，并执行 python3 scripts/reviewwrite_gate.py <response-path> --semantic-review <review.json>。门禁负责结构化抽取、正文严格预检、正文哈希校验和“失败时不输出正文”；纯正文文件才使用 --input-mode raw。除了提示、推理和工具泄漏，还要检查内部契约术语、标题中的编辑判断、任务服从、自证式结论、强化词堆叠和推理旁白。任何 fail、严格模式下的 warn、缺失或失效的语义复核记录，都必须回到修改阶段；不能只凭模型自评“已经自然”，也不能只审评审报告而跳过正式正文。
发现漂移时恢复原文或降低修改幅度。存在 blocker 时不得声称完成。
可选更新检查
只有平台或用户已明确启用更新检查时，才执行自动检查。每个新会话首次调用 ReviewWrite 时运行 scripts/reviewwrite_update.py status --format json；它只读本地版本和缓存，不联网。结果为 cache-fresh 时本会话不再检查；结果为 check-due 时，等当前正文任务完成后再执行 scripts/reviewwrite_update.py check --format json。联网结果使用 24 小时缓存；没有更新时保持安静，有更新时只提示版本和发行页。
检查不是随机的，也不是每次调用都联网。不得在一次活跃写作任务中下载或替换 Skill，不得覆盖 Git 工作副本。默认 notify；可信环境可选择在任务结束后自动下载 patch，但安装、刷新缓存或新建会话仍是独立步骤。minor/major 默认只提示并要求明确升级。宿主平台已有原生版本管理时，优先使用平台更新渠道。详细规则见 references/update-policy.md。
输出与确定性自检
用户要求“评审并改写”时，按四个标签输出，不增加聊天式尾句：
<review_report>
问题、证据位置、严重程度和建议；不展示隐藏推理。
</review_report>
<revision_plan>
preserve、repair、optional 和 acceptance。
</revision_plan>
<deliverable_body>
可直接交付的正式正文；不得出现评审、过程、提示、工具或助手话术。
</deliverable_body>
<verification_report>
事实保持、引用/来源、泄漏、体裁和待确认项的事实性结果。
</verification_report>
deliverable_body 的末尾禁止“如果你需要”“我也可以继续”“希望这有帮助”等交接语。任何后续帮助只能由技能外层对话单独发送，不能进入结构化响应。
如果本地可执行 Python：先创建并完成语义复核记录，再运行 reviewwrite_gate.py --semantic-review；未通过时根据诊断回到改写步骤，正文变化后重新生成复核记录。修复回路应有限，仍失败就报告触发句和失败状态，不得输出未通过正文或声称通过。警告是模型判断的线索，不是跨体裁的自动删改指令。
用户只要求正文时，结构化标签仅用于内部抽取；门禁通过后只向用户输出标签内的正文，不显示 <deliverable_body> 标签。仍须在内部完成评审和验证。不得输出隐藏推理，只提供简洁、可核验的修改依据。
成功标准
完成后的文本应当：
- 像该体裁中的成熟作者，而不是聊天机器人；
- 没有提示词、推理、编辑和工作流泄漏；
- 读者能迅速识别主张、证据和行动要求；
- 保留原文事实、限定条件和作者可识别的声音；
- 经得起改前改后的逐项核对。