通知写作助手

解决什么问题

通知是公文里最常见、但也最容易写散的文种。材料堆在面前时，容易产生两类错误：一类是「补全过度」——为了让通知看起来完整，擅自补上通知对象、时间节点、责任单位、报送要求、监督机制；另一类是「占位符拼凑」——用一堆 〔待填〕 拼出表面完整的稿子，实际没有任何可用信息。这个技能的约束是反向的：材料里没有的，一个字不加。

工作流与关键约束

整个流程是线性的：先构建事实底座，再进入写作与修订，最后渲染 DOCX。

步骤 0：事实清单先行。 每次任务开始时，原始材料先原样落盘，再由 create_notice_facts.py 读取原始字节计算 source_sha256，生成独立的 notice_facts.json。规则明确禁止 LLM 手工填写哈希、禁止把历史任务事实复用到新任务、禁止在脚本里硬编码业务事实。

步骤 1-3：初稿 → 复核 → 修订。 初稿 draft_v1 只在材料内做排序、去重、正式化表达和结构调整，不得补写通知对象、时间节点、责任单位、报送要求或监督机制。随后以复核员身份独立审查四项内容：用户任务、特殊要求、原始材料、初稿。修订阶段最高依据是原始材料和用户任务，复核意见只是参考；只允许删除无依据内容、补回遗漏信息、修正错别字、恢复被改变的时态或主体，不允许新增事实、日期、措施或结论。

步骤 4-5：误报过滤与静默检查。 复核意见若要求补写材料外信息、把正常结语误判为新增、或把 AI 建议写成已确定的措施，一律不采纳。最终稿生成后还要过 9 项检查：通知事项是否明确、日期数量是否准确、是否残留 Markdown 格式等。

步骤 6-9：排版与交付。 V1.1 把内容解析和渲染拆开了：notice_model.py 是唯一的内容解析层，负责 Markdown → NoticeModel JSON；fill_tongzhi_docx.py 是纯 Renderer，只负责 NoticeModel → DOCX；排版底层 notice_document_factory.py 已冻结。统一交付脚本串起完整管道：环境预检、source_sha256 一致性校验、Markdown 与 DOCX 两轮事实复核、结构校验，最后输出 ARTIFACT_READY 和 DOCX 路径。

适用边界

• 只处理「通知」文种，请示、报告、函、纪要不在范围内。
• 材料不足时会停下来问最少的必要问题，不会用占位符拼稿，也不会自行选择通知事项。
• 最终交付物必须是真实 .docx 文件；Markdown 只是内部中间格式，不作为默认交付。
• 不会自行添加红头、发文字号、版记、印章或密级，也不声称已完全符合所有单位的正式发文规范。
• 主送对象和日期未确定时统一使用 〔主送机关〕 和 〔日期〕 占位符，不会推定具体内容。