公文写作技巧及案例解析

写通知、请示、总结时最常卡在两点：一是不知道该用哪个文种、该怎么称呼对方；二是内容写完了却像散文，条目不清、责任不明。这篇不讲虚的，先给定文种和搭骨架的动作清单，再给一套拿真实素材做案例解析的方法，最后用错误清单自查一遍。

写通知、请示、总结时最常卡住的地方往往不是文笔，而是两个判断：这份东西该用哪个文种、该怎么称呼收文方；以及内容明明写全了，读起来却像散文，条目不清、责任落不到人。这篇不绕概念，直接给定文种、搭骨架、解析案例、交稿自查这四步能照做的动作。

整体思路是先把文种和行文关系定死，再用条目把内容切开，然后拿真实素材练案例解析，最后用一份共性错误清单逐条过一遍。顺序别倒过来，先堆文字再回头改文种，返工量最大。文种口径和术语规范如果不确定，可以去 /ai-dict 的术语类目对照，不要凭印象写。

第一步：先定文种和行文关系，别急着写正文

很多人一上来就敲正文，写到一半发现语气不对，其实问题出在文种没定。文种决定了这份文件是报请、是部署还是商洽，语气、结尾用语、抄送范围都跟着变。先花几分钟把文种和行文方向确定下来，后面的文字才有的放矢。

报请类

请示、报告，向上级说明情况或请求批准，语气要请示、不命令

指令类

通知、批复，向下级部署或答复，要求要写清责任人和时限

商洽类

函，平级或不相隶属单位之间商量事情，语气平等、有商有量

记录类

纪要、总结，记录会议决定或阶段工作，重事实、少表态

• 先判断行文方向：向上报请、向下部署、平级商洽，三种语气完全不同，向上不命令、向下不请示
• 一份文件只解决一件事，想同时说三件事就拆成三份，硬塞在一起通常会被退回
• 动笔前先用三句话写清：为什么发这份文件、要对方做什么、什么时候要回复，写不出来说明事情本身还没想清

搭骨架：把大段文字切成有编号的条目

骨架的作用是让读的人一眼看到有几件事、每件事谁负责。推荐按「依据—事项—要求」三段走：先引用上级文件或说明实际情况作依据，再用条目列具体事项，最后落到责任人和时限。段落只用来过渡，具体事项尽量用条目承载。

1. 写依据交代为什么发这份文件，引用上级文件或说明当前情况；判断标准是，删掉这段后人还看得懂为什么要发，说明依据太弱
2. 列事项一句一个动作，每个动作带主体、动作、对象、时限四要素；缺主体或时限的句子单独拎出来补
3. 落要求把事项对应到具体人、具体时间，避免只写「请认真落实」；验证方法是把句子读给同事听，问他知道明天该做什么吗
4. 核格式落款、成文日期、附件说明按本单位格式要求核对，口径不确定就去 /ai-dict 的规范类目对照，别照抄网上版本

标题的写法可以单独拎出来说：常用结构是「关于＋事由＋文种」，事由要具体到可判断的范围，别用「有关工作」这种无法界定的说法。一份文件解决的事越单一，标题越容易写准。

案例解析怎么读：拆骨架、标动作、找缺口

案例解析不是把范文背下来，而是拆它的结构、找它的缺口。拿到一份范文，先拆三段结构，把每段的功能标出来，再看它为什么这样排序；然后逐句标动作主体，凡是没写谁来做、做到什么程度、什么时候交的句子，都是案例里的可改点。

对比两份同类文件时，只比三处：文种选得对不对、条目切得清不清、要求落没落到人，不用逐字比对用词。找范例或者需要辅助起稿的方向，可以去 /ai-nav/category/ai-writing 的写作工具目录看看，但定稿口径仍以本单位规范为准。

案例解析的价值不在于知道别人怎么写，而在于看出别人哪里没写清。

交稿前自查清单：这些地方最容易被打回

文件写完别急着发，按清单过一遍通常能挡掉大部分退回。下面这几类错误出现频率最高，逐条打勾比通读三遍有效率。

• 文种与行文关系不匹配，比如该用函却发了通知，或者向上级用了部署语气
• 依据没写清，看不出为什么要发这份文件，收文方第一句就卡住
• 一个条目里塞了多个动作，或者主体写成「有关部门」这种无指向说法，落不到具体人
• 层级混乱，一级条目下再套多层编号，读的人找不到重点；附件在正文里没提及或名称对不上
• 成文日期、落款主体、抄送范围三处最容易在改稿后漏改，发出前重新核对一遍

涉及用词规范、术语口径这类细节，不确定时不要猜，去 /ai-dict 对应类目对照当时的说法。这套清单不适用于纯对外宣传稿或口语化通知，那类文本的重点在表达效果而不是条条目目，硬套会显得僵。