语文 · 应用写作

概念

应用文是处理事务、传递信息、解决实际问题而写的文章。与文学作品的根本区别在于：文学追求审美与多义，应用文追求效率与无歧义。

$$\text{应用文}=\text{明确的读者}+\text{明确的目的}+\text{规范的格式}+\text{可执行的结论}$$

一句话把握：文学作品让读者"感受"，应用文让读者"照做"。 一篇应用文如果读完后读者问"所以我要干什么"，它就是失败的。

原理

一、四个基本特点

特点	含义	反例
实用性	为解决具体问题而写	抒发感慨、铺陈辞藻
真实性	事实、数据、时间、人物必须准确	大概、差不多、估计
规范性	有相对固定的格式与惯用语	自创体例、随意发挥
时效性	在特定时间内有效	会后才发会议通知

二、写作流程：先想清楚再动笔

动笔前回答这四个问题，能省掉一半返工：

1. 写给谁？ 读者决定详略与术语密度（给领导 ≠ 给同事 ≠ 给客户）
2. 要他做什么？ 应用文只有一个核心动作：批准、执行、知悉、答复
3. 他需要知道什么才肯做？ 背景、依据、代价、时限、责任人
4. 用什么格式？ 组织通常有模板，优先用模板

写作顺序推荐先列要点再成文：把要点写成条目，排序（按重要性或按时间），再补连接词。这比一气呵成再改要快。

三、通用结构：结论先行

应用文最有效的组织方式是金字塔原理：

$$\text{结论}\to \text{理由（分点）}\to \text{事实与数据（支撑）}$$

先给结论，再给理由。读者（尤其决策者）通常先看结论，需要时才往下读细节。

• 一组要点按重要性或时间排序，不要混排
• 每点只说一件事，一段只讲一个要点
• 数字、时间、责任人写具体：不说"尽快"，说"9 月 30 日 18:00 前"

四、常用文种速查

文种	用途	关键格式
通知	发布要求、告知事项	标题 + 主送 + 正文（缘由 / 事项 / 要求）+ 落款与日期
请示	向上级请求批准	一文一事；结尾用"妥否，请批示"；事前行文
报告	向上级汇报	不得夹带请示事项；事中或事后行文
函	不相隶属机关之间商洽	平级用语，措辞对等；有"函复"格式
会议纪要	记载会议主要情况与决定	分"会议情况 + 议定事项"，决议要写明责任人与时限
计划	预先安排	目标 / 措施 / 步骤 / 时间表 / 责任人
总结	回顾工作	情况 / 成绩 / 问题 / 改进；用数据说话
求职文书	简历、自荐信	结果导向，用动词 + 数据写经历

请示与报告的区别是最常见的考点：请示要批复（事前），报告不需批复（事后）；报告里不能夹带请求事项。

五、语言要求

要求	做法
准确	用具体数字、专有名词全称；避免"大概""左右"
简洁	删掉可删的字；能用一句不用两句
平实	不用夸张修辞；形容词让位给事实
庄重	使用书面语与惯用语（"予以""特此""拟"）
得体	对不同对象用不同语气：上行文恭敬、平行文对等、下行文明确

示例

例 1：一份通知

关于启用新版代码托管平台的通知

各开发组：

为统一管理代码资产（缘由），自 10 月 8 日起启用新版代码托管平台，
现将有关事项通知如下（过渡句）：

一、10 月 8 日 00:00 起旧平台停止新建仓库，已有仓库只读。
二、10 月 15 日前完成本组仓库迁移，迁移方法见附件《迁移指南》。
三、迁移期间原有 CI 流水线同步切换，请各组组长于 10 月 12 日前
    确认本组流水线配置（要求：事项、时限、责任人齐全）。

联系人：平台组 张××（分机 8021）

                                            平台运维组
                                            2026 年 9 月 28 日

拆解：缘由 → 事项（分条）→ 要求（时限 + 责任人）→ 联系方式 → 落款。每一条都能被执行，读者不用追问"然后呢"。

例 2：技术文档的三段式（以故障报告为例）

【结论】9 月 27 日 20:10–21:35 接口错误率升至 7.2%，
        根因为连接池上限配置过小，已扩容并恢复。

【时间线】（事实，不夹杂判断）
  20:10 错误率从 0.3% 升至 7.2%
  20:15 确认非新版本发布引起（本次发布在 15:00，错误率未变）
  20:40 定位到连接池打满，等待队列积压
  21:00 将连接池上限由 50 调至 200
  21:35 错误率回落至 0.4%

【改进项】
  1. 全服务连接池上限纳入配置基线核查（负责人：李××，10 月 10 日前）
  2. 增加等待队列长度告警（负责人：王××，10 月 15 日前）

要点：结论在最前面；时间线只写事实，不写推测；改进项必带责任人与时限。

例 3：一份 README 的最小骨架

# 项目名

一句话说明它做什么。

## 快速开始
安装 → 运行 → 看到结果，三步内跑通。

## 用法
最常用的三个场景，各给一段可复制的命令或代码。

## 目录结构
顶层目录各是什么，一句话一行。

## 常见问题
报错 → 原因 → 解法，三栏式。

好的 README 判据很简单：新人照着它能不能在十分钟内跑起来。 跑不起来就是缺内容，多半缺的是前置依赖或配置说明。

例 4：邮件与即时消息

场景	写法
请求审批	主题写清事项与期限："【请于 9/30 前批复】服务器采购申请"
汇报进度	先状态（正常 / 有风险），再数据，再下一步
同步结论	直接给结论与责任人，过程放附件或会议记录
提出反对	先复述对方观点确认理解，再给依据，最后给替代方案

即时消息不等于随意：群里发结论时同样要带时间、责任人与行动项，否则等于没发。

要点

要点与常见误区

1. 请示与报告别混用：请示要批复（事前），报告不须批复（事后）；报告中不得夹带请示事项。
2. 一文一事：一份请示只请求一件事，多件事分多份，否则批复环节会卡住。
3. 结论先行：把结论埋在最后的应用文，等于让读者重读一遍。
4. "尽快""酌情""原则上"这类词尽量避免，换成具体日期与数字。
5. 责任人 + 时限是执行力的全部：议定事项少了这两项，会议纪要就只是记录。
6. 数字要写口径："错误率 7.2%"要说清统计窗口（哪一分钟、哪个接口）。
7. 上行文与平行文语气不同：给上级用"拟""妥否，请批示"；平级用"请予支持为荷"。
8. 技术文档的时间线只写事实，推测与判断单独放"分析"段，混在一起会让复盘失真。
9. 删掉形容词不会损失信息："系统严重崩溃"不如"系统不可用 85 分钟"。
10. 格式服从模板：组织有模板就用模板，格式本身就是专业度的一部分。

小结

• 应用文四特点：实用、真实、规范、时效；与文学的分界是"让读者照做"。
• 动笔前四问：写给谁、要他做什么、他需要什么信息、用什么格式。
• 组织方式一律结论先行（金字塔原理），要点按重要性或时间排序，不混排。
• 文种记忆点：请示要批复且事前，报告不须批复且事后；纪要必带责任人与时限。
• 技术写作同理：结论 → 事实时间线 → 改进项（责任人 + 时限）。

下一篇：语文 · 文字学