公文初稿生成器

公文起草中的具体痛点

把零散材料整理成一份能提交审核的公文，问题往往不在“不会写”，而在这几处：

• 事实错位：文号、发文机关、日期、数据在正文中被改写或漏掉，审核时需要回头核对原始材料。
• 格式不稳定：不同单位对版头、主体、附件、版记的要求不一，通用模板经常与本单位现行细则冲突。
• 模型输出不可控：宿主模型可能追加背景、目的、意义等材料里没有的内容，产生“看起来很完整”的空话。
• 隐私边界不清：有些工具会上传用户文件，或者让用户手动跑脚本，使用门槛和数据风险都高。

技能的工作流与核心机制

@user_b0802705/gongwen-writer-personal 把写作拆成一套先锁事实，再写成稿的流程，核心交付是经过结构校验的可编辑 Word 初稿，而不是直接签发。

• 零门槛读取偏好：首次使用只创建空的本地偏好文件，不要求注册、手机号、单位信息或历史范文。只有用户明确表达“以后都这样”时，才保存一条简短的表达偏好，且不保存姓名、单位或原始材料。
• 整理事实锁定卡：在本地生成 request.json，把 task_mode、document_type、format_mode、user_request、materials.facts、materials.document_metadata、materials.sections、preferences、must_include 和 must_not_include 显式列出。缺失的关键事实进入待补项，而不是用臆测内容占位。
• 结构化候选稿：按文种读取 references/notice.md、references/request.md、references/report.md、references/letter.md 或 references/minutes.md，再按 assets/schemas/document.schema.json 生成 candidate.json。材料不足时，根对象使用 needs_clarification，document 设为 null，只列真正阻断起草的 missing_fields。
• 本地内容校验：通过 python scripts/validate.py request.json candidate.json --report report.json 检查数据协议、文种与模式、已知文号/发文机关/日期归位、材料分项标题、必须保留句、禁止补写句、材料外数字和明确个人偏好。校验失败时按“问题—原因—处理办法—文件状态”的顺序向用户解释，而不是直接返回原始 JSON。
• 先交付概要：校验通过后，先展示标题、发文目的、正文结构、关键事实和待确认项。用户未明确确认前不生成 Word；确认后才执行 python scripts/generate_docx.py document.json --output output.docx，如实报告 generated 与静态结构检查的结果。

支持 draft、rewrite、review 三种模式：起草时根据材料生成初稿，改写时保留事实、数字、对象、结论和行文目的，只调整结构与表达；审阅时只报告文种、事实、逻辑、语气和格式问题，用户没有明确要求代改时不重写全文。

适用边界与注意事项

• 当前只支持通知、请示、报告、函和纪要，不生成真实印章、电子签章、OFD、OA 流程或正式发文。
• 正文默认使用连续论述和公文标题层级，不使用项目符号列表。body_draft 使用常用字体和干净编辑排版；只有材料字段完整且用户明确要求正式文件时，才使用带 22 行×28 字网格的 formal_file。函和纪要必须分别使用专用信函、纪要版式。
• 本 Skill 不训练或微调模型，也不把模型兼容性等同于正文可以直接签发。默认使用 WorkBuddy 或 TRAE Work 的官方模型完成理解与起草；在 TRAE Work 等允许自定义模型的宿主环境中，兼容 OpenAI 兼容模型接口。使用云端 API 时，材料仍会按宿主平台和模型服务商的规则发送到云端，本 Skill 不会额外增加数据上传链路。
• 自定义模型必须稳定遵守中文指令、结构化 JSON 和工具调用协议。输出不合格时，以本地校验报告为准并停止生成 Word；不要要求用户手动执行 Python 命令，只有宿主环境确实无法执行时，才用中文说明最小替代操作。