被退回的稿子，问题往往不在用词，而在结构件缺了、行文方向错了、结尾落点跑偏了。通知是对下布置任务，请示是对上请求批准，纪要是对内固定议定结果，这三件事的骨架不同，语气也不同。工具生成时如果只给一个主题、不给文体和行文方向，模型通常会用一套通用的「汇报腔」往下写，于是出现通知里塞进讨论过程、纪要里冒出请示语这类串味写法。
三种文体的差别不在措辞漂不漂亮，而在结构件和行文方向：通知对下布置任务，请示对上请求批准，纪要对内固定议定结果。判断有没有混用，看三处——该有的结构件是否齐全、语气是否对得上收文对象、结尾是否落在正确的动作上。报送前用同一份检查清单过一遍，多数退回原因能提前拦住。约束以本单位现行公文格式要求为准，工具生成的稿子只当草稿，落款、编号、密级仍需人工确认。
列出三种文体必须出现的结构件
先分清结构件，再谈措辞。通知、请示、纪要都有标题、主送、正文、落款这些公共部分，但各有一样东西不能被别的文体顶替：通知必须有事项和执行要求，请示必须有事项和理由，纪要必须有议定事项和待办分工。这三样一旦缺位，后面写得再顺也站不住。
| 文体 | 必须出现的结构件 | 行文方向与结尾落点 | 典型越界写法 |
|---|---|---|---|
| 通知 | 事项（做什么）、执行要求（谁来做、何时完成、按什么标准、怎么报送） | 对下；结尾落在执行要求或报送节点上 | 写会议讨论过程；用「妥否，请批示」收尾；只讲背景不给要求 |
| 请示 | 事项（请求什么）、理由（为什么需要）、拟办建议或方案、明确请求语 | 对上；结尾落在请求批准或请求指示上 | 写成工作汇报，只讲成绩不讲请求；用「请遵照执行」收尾；把请示写成通知口气 |
| 纪要 | 议定事项（已决定什么）、待办分工（谁在何时前完成什么）、时间地点与参会范围 | 对内；结尾落在责任分工上 | 出现「请予批准」这类请示语；把未形成结论的讨论原样搬进去；用通知口气下达新要求 |
「一点妙笔」在三种文体里的落点也不一样：通知里通常放在执行要求之前，用作强调；请示里通常放在理由段末尾，用来支撑请求的正当性；纪要里通常放在议定事项段，用来定调。同一句漂亮话放错文体或放错段落，读起来就是串味。判断方法可以很简单：把这句话删掉，看该文体的核心结构件是否还完整——如果删完结构件就缺了，那它本来就不是妙笔，而是被漏掉的结构件。
在工具输入里分别写明文体和行文方向
输入里最常见的错误，是一次把两个目的塞进去，比如「写一份关于调整值班安排的通知，并请领导批准」。工具没法在一条输入里同时收住两种语气，结果往往写成前半段像请示、后半段像通知。建议固定输入顺序：文体 → 行文方向 → 受众 → 结尾要求 → 禁止出现项 → 主题。顺序固定下来，模型不容易把两种文体的语气掺在一起。
文体：通知
行文方向：对下（职能部门 → 各科室）
受众：各科室负责人，不需要交代背景
必须包含：事项、责任单位、完成时限、报送方式
结尾要求：以执行要求收尾
禁止出现：讨论过程、“妥否，请批示”、“会议议定”
主题：____文体：请示
行文方向：对上（本单位 → 上级主管部门）
受众：分管领导及主管部门
必须包含：请求事项、理由、拟办方案、明确请求语
结尾要求：以请求批准收尾
禁止出现：“特此通知”、“请遵照执行”、通篇成果总结
主题：____文体：纪要
行文方向：对内（会议记录，供参会单位对照执行）
受众：参会单位与相关岗位
必须包含：议定事项、待办分工、完成时限、参会范围
结尾要求：以待办分工收尾
禁止出现：“妥否，请批示”、“请予批准”、未形成结论的讨论过程
主题：____结尾要求这一行建议同时写正向和否定两种约束。只写「正式一点」这类形容词，工具很难落到具体句子上；写成「以请求批准收尾」「禁止出现请示语」，生成后更容易一眼看出来对不对。
生成后检查有没有跨文体混用
生成完不要直接报送，先按下面的顺序过一遍。文本类文件可以直接在本地检索关键词，把明显的串味句子先挑出来。
- 在纪要稿里检索「请批示」「妥否」「请予批准」「恳请」——出现即改，纪要不出请示语。
- 在通知稿里检索「讨论」「研究认为」「与会人员一致」「会上强调」——这类内容属于纪要，通知里保留结论性要求即可。
- 在请示稿里检索「请遵照执行」「特此通知」「抓好落实」——出现即改，请示不对下布置任务。
- 把结尾段单独拿出来读，确认落在该文体的动作上：通知落在执行要求，请示落在请求批准，纪要落在责任分工。
- 确认「一点妙笔」那句话的位置，是否还在对应文体的段落里，而不是飘到了开头或结尾。
# 通用检索骨架，文件名按实际替换
grep -n -E "妥否|请批示|请予批准|恳请" 纪要草稿.md
grep -n -E "讨论|研究认为|与会人员一致" 通知草稿.md
grep -n -E "请遵照执行|特此通知|抓好落实" 请示草稿.md检索只能拦住显性串味，显性之外的判断仍需人工看：收文对象与语气是否匹配、请求事项是否只有一件、待办分工是否落到具体岗位。落款、发文字号、密级这些要素，按本单位现行要求核对，不要依赖工具自动生成。
把三种约束分别存成可复用的输入片段
高频文体没必要每次重新交代体例。把三份输入片段分别存成独立文本，放在工具的自定义预设里，或者放进团队共享的模板目录，用的时候只替换主题相关字段。片段里保留的是固定字段，每次只改主题字段。
| 类型 | 固定字段（片段里写死） | 每次替换的主题字段 |
|---|---|---|
| 通知片段 | 文体、行文方向、受众范围、必须包含的四项结构件、结尾要求、禁止出现项 | 标题事项、责任单位、完成时限、报送方式 |
| 请示片段 | 文体、行文方向、受众、必含结构件、结尾请求语、禁止出现项 | 请求事项、理由要点、拟办方案、期望回复时限 |
| 纪要片段 | 文体、使用场景、必含结构件、结尾分工要求、禁止出现项 | 会议名称与时间地点、议定事项、待办分工、责任人与时限 |
维护片段时注意两点：一是固定字段里的禁止项要与本单位格式要求同步，格式要求变了片段要跟着改，不然旧约束会把新要求挡在外面；二是主题字段不要写成一句话概括，把时限、责任单位、报送方式这类会被正文直接引用的信息填全，工具生成时才有东西可落。片段本身不产出成稿，它只是把体例部分固定下来，成稿仍需按上一节的检查顺序过一遍再报送。