写给工作的清晰表达

清晰的写作不等于漂亮的写作。它的标准是:一个很忙的人读完就能抓住重点、做出决定、动手去做,不用再打电话问你。别再追求“显得专业”。公文腔不是权威,它只是把活推给了读者。这篇讲的是我改邮件、方案和技术文档时真正动的那几刀,用在初稿没干好活的时候。

🎙️ 发布并录制于: ·

01写清楚读者是谁,要他做什么

动笔之前,先把两句话补完:“读者是……”和“读完之后,他应该……”。如果第二句的答案是“了解一下情况”,说明你还没做选择。他是要批准、要修复、要比较、要准备,还是要记住?一份文档可以服务好几类读者,但一个段落没法同时干五件事。

Weak brief
Audience: stakeholders
Goal: provide an update

Usable brief
Reader: Maya, who owns the launch decision
Action: approve the two-day delay by 3 p.m. Thursday
Evidence she needs: failed load test, repair estimate, customer impact
一次真实的失败

有位项目负责人发了一句:“最新的方案同步给大家看看。”没人回。到周五他反过来问,法务怎么还没批。那个请求从头到尾就没出现过。分三刀改。第一刀,点名法务是读者。第二刀,第一行写“请批准第 12 页”。第三刀,补上截止时间,以及批准之后会发生什么。别怪读者没能发现一个藏起来的任务。

02把结论放在最前面

在工作里卖关子,基本等于失礼。先给答案,再给理由,最后给细节。经理不该读完六段才知道上线有没有延期。先铺背景的写法让人觉得安全,因为它把表态往后推了。这段跑道,删掉。

Before
Over the past several weeks, the team has been evaluating a number
of vendors while also considering our changing operational needs.
Following those discussions, we wanted to share an update.

After
Choose Northstar. It is the only vendor that meets our June deadline
and audit requirement. It costs $8,000 more per year.

Decision needed: approve Northstar by Tuesday at noon.
Evidence: comparison table below.

拿第一句话当测试。如果读者在手机通知里只看到这一句,他能知道重点吗?“简单同步一下”不是重点。“迁移延后两天”才是。

03用读者能想出画面的词

把含糊的表扬、担忧和规模,换成可观察的事实。“显著”“尽快”“优化”“若干”,都是把猜的活推给读者。数字只有在回答读者关心的问题时才有用。“转化率提升了 4.2%”,如果读者需要知道时间区间和基准,这句话依然不完整。

Vague                           Concrete
We had several incidents.          Checkout failed 17 times on Monday.
Please respond soon.               Reply by 2 p.m. Friday.
The page is much faster.           Median load time fell from 3.1s to 1.4s.
We should optimize onboarding.     Remove the card step from trial signup.
A large group dislikes it.         8 of 12 interviewees could not find Save.
不要伪造精确

不知道数字,就说你观察到了什么,以及证据有多有限。写“本周有三通客服来电提到发票重复”。不要把它升级成“客户普遍不满”。清晰的写作会让薄弱的证据露出来,而不是替它做装饰。

04一句话只承担一件主要工作

短不自动等于清楚。一连串小短句读起来会显得幼稚。真正好用的规则是:一句话一个主要判断,并且把它讲够。当一句话里塞了三个“并且”、一个括号,末尾还补一个例外,就拆开它。例外要挨着它修饰的那个判断放。

Before: 54 words
We reviewed the rollout plan and, given the staffing constraints that
were discussed last week and the fact that the mobile build remains
in review, which may be resolved by Wednesday, we believe it would be
appropriate to move the launch, although the web release could still
proceed if leadership prefers.

After
Move the full launch from Tuesday to Thursday. The mobile build is
still in review, and support has two people out. We can release the
web version on Tuesday, but I recommend one coordinated launch.

把草稿念一遍。如果你自己都得回头重念某句话,读者大概也一样。长但顺的句子可以留下。语法挡住了决定的句子,砍掉。

05段落围绕判断来搭

一个好用的段落有判断、证据和后果。判断放最前面。证据跟着这个判断。结尾说清它为什么重要,或者接下来做什么。工作变了就换段。一大坨文字通常不是排版问题,而是四个想法从来没被分开。

Claim       The new search is not ready for public traffic.
Evidence    It times out on 6% of queries above 20,000 records.
Consequence Keep the beta flag on while we add the missing index.

Next claim  The fix is small and testable.
Evidence    It passed on a production-sized copy this morning.
Consequence Re-run the load test at 4 p.m.; release if errors stay below 0.1%.

小标题要把论点露出来。“建议:延后两天”胜过“下一步”。读者只扫小标题,就该能还原出整篇文档的骨架。

06删掉名词堆和不敢担责的被动句

商务写作爱把动词做成沉重的名词:做一次评估、进行一次审查、给出一个解释。把动作还给动词。当动作的执行方未知或者不重要时,被动语态可以用;它被用来藏责任时,就该拒绝。“出现了失误”并不中立,它抹掉了那个能把问题修好的人。

Corporate fog                    Direct version
We conducted an evaluation of X.     We evaluated X.
Implementation will be undertaken.   Priya will implement it Monday.
A decision was made to postpone.      I postponed the release.
There was a failure in delivery.      The courier lost the package.
We are in alignment on the need to…   We agree to…
那句引发追责的话

一份事故记录写着:“生产数据库被意外修改。”几位领导花了一个小时追问到底是谁干的。按顺序重写。点名执行方:“我们的迁移任务改了生产库。”点明具体动作:“它删掉了 customer-status 索引。”点明影响和修复:“查询变慢了 11 分钟,Ana 在 10:42 把索引恢复了。”写清责任,这份记录才有用。

07写出真能起作用的邮件主题和请求

主题行是一个路由标签。把动作和日期放进去。正文前两行就把请求说出来,只给回答所需的背景,再规定回复的形式。当你要的是批准,一句“看看?”就是偷懒。

Subject: Follow-up
Hi all, circling back on the below. Any thoughts would be appreciated.
It would be great if we could get this finalized ASAP.

Subject: Approve homepage copy by Thu 2 p.m.
Mina, please reply “approved” or mark changes in the doc by Thursday
at 2 p.m. We send the page to translation at 3 p.m.

Review only the headline and first paragraph:
https://example.com/doc

If I do not hear back, I will keep the current copy and move translation.
一个没写时区的截止时间

伦敦的编辑写:“请在今天下班前发终稿。”旧金山的作者在编辑下班八小时后交付,印刷档期没了。把请求补齐:日期、时间、时区。“请在 5 月 14 日英国夏令时下午 5 点前发终稿。”然后写清后果:“过了这个点,这一期就不带这篇文章了。”

08技术说明要从故障往外写

技术写作要让一个累坏了的读者自己爬出来。开头写结果和前置条件。命令写准确。给出预期结果。把真实报错原文放进去,因为大家搜的就是那串字。解释放在修复之后,不要放在前面。

Goal
Run the app locally on port 3000. Requires Node 22 and npm 10.

Steps
1. npm ci
2. copy .env.example .env
3. npm run dev
4. Open http://localhost:3000/health

Expected result
HTTP 200
{"status":"ok"}

Real failure
Error: listen EADDRINUSE: address already in use :::3000

Fix
1. Windows: netstat -ano | findstr :3000
2. macOS/Linux: lsof -i :3000
3. Stop the stale process, or run PORT=3001 npm run dev.
4. Open the health URL again on the chosen port.

永远别写“按需配置好环境即可”。写清文件名、配置项、可接受的取值和重启步骤。“应该就能跑起来了”不算预期结果。给出状态码、界面上能看到的文字,或者能证明成功的输出。

09分轮修改,别边写边改

写草稿是为了把事情说对。改稿是为了读者。一边摸索论点一边打磨句子,两件事都会更慢。用五轮。第一轮,确认结论。第二轮,把结论挪到最前。第三轮,删掉读者不需要的。第四轮,把含糊的名词换成执行人、动词、日期和数量。第五轮,念出来,并且把每个请求都试一遍。

PASS 1  Point: can I state the conclusion in one sentence?
PASS 2  Order: answer → reasons → evidence → action
PASS 3  Cut: throat-clearing, repetition, history nobody needs
PASS 4  Specify: who, does what, by when, measured how
PASS 5  Test: read aloud; open every link; follow every instruction

Search and challenge:
very · really · significant · leverage · facilitate · in order to
it was decided · going forward · at this point in time · thoughts?

删减不等于把文字变冷。礼貌、背景和人的判断都要留。要去掉的是那些装成礼貌的客套。“方便的时候能麻烦你看一下吗?”其实不如一个带着现实截止时间的明确请求更善意。

10清晰写作速查表

凡是要让别人花时间、做决定或者承担风险的东西,发出去之前先过一遍这张表。

BEFORE DRAFTING
□ Name one primary reader.
□ Name the action or decision.
□ List the minimum evidence they need.

WHILE EDITING
□ Put the answer in the first sentence.
□ Give each paragraph one claim.
□ Replace vague scale with observed facts.
□ Turn noun phrases back into verbs.
□ Name the actor when responsibility matters.
□ Split sentences with competing jobs.

FOR REQUESTS
□ Action + date in the subject line.
□ Owner, deadline, timezone, response format.
□ State what happens if nobody responds.

FOR INSTRUCTIONS
□ Prerequisites, exact steps, expected result.
□ Real error text and a tested recovery.

FINAL TEST
Could the reader act correctly without asking me what I meant?

我的规矩很硬:“显得专业”不是写作目标。一句清楚的“不行,因为压测没过”,比三段藏着答案的漂亮文字更专业。真尊重读者,就去做选择、给具体、然后停笔。

Tell me what missed

A correction is more useful than a compliment. This goes straight to the person who writes SwiftGrasp.

Was this page useful?
0/1000

Please do not include passwords, private keys, or personal information.