你可能有过这样的经历：花半小时写了一封进度邮件，把这周做了什么、谁在等谁，一条条列清楚，发出去。对方回了一句：“Thanks — so are we still on for the 13th?”
你写的内容全是真的，但没有回答他真正在问的事。
进度汇报的读者不需要验收你忙不忙，他要拿这份东西决定下一步：要不要担心、要不要插手、要不要批一件事。所以一份好的 update，要替对方减少不确定性，而不只是记录工作。它只需三块内容：现在到哪了、有什么会挡住它、需要谁做什么。难的是每一块要写到什么程度，对方才不用追问。
案例：一个有一处真风险的项目
先给全条件，你可以自己试着写一段，再看下文。
假设你在为一家零售客户改造线上结账流程，计划 10 月 13 日上线：
- 页面重构已完成，进入测试，目前没有阻断问题；欺诈规则迁移提前两天做完；负载测试在预期峰值的 3 倍下通过。
- 支付服务商的合规认证落后约一周：对方提出两项问题，我们解决了一项，另一项（webhook 重试行为）在对方工程师手里，他答应周三给答复。
- 认证如果 10 月 3 日还拿不到，上线整体后移一周，也就是 10 月 20 日。
- 客户财务要在周五前决定：先用发票模块 v1 上线，还是等 v2。等 v2 会让上线晚两周。
数字为说明结构而编，结构本身是真实的。
第一稿：准确，但对方没法用
按时间顺序写，很容易写成这样：
Hi all, This week we continued work on the checkout revamp. The team finished the UI and moved it into QA. We also spent time on the fraud rules migration, which is now done, and ran the load test. On the certification side, we had a call with the provider and they raised two findings. We resolved one and are waiting for them on the second. We'll keep you posted. Let's discuss on Thursday.
每句都对，问题出在它按你经历的顺序排列，而不是按对方做决定的顺序排列。
第一句读完，对方不知道项目是好是坏。“Continued work on” 只说明你忙了，不说明任何东西向前移动了。整段读完，他不知道认证拖一周会不会动到上线日期。最后那句 “Let's discuss on Thursday” 最要命：你把决定推给了一场会，周四之前他什么也不用做——而这件事他本来花三十秒就能定下来。
读者在回答哪三个问题
对方读一份 update 时心里在跑三个问题：现在是什么状态？什么可能让它变坏？需要我做什么？
对应三块内容，顺序固定：状态 → 风险 → 请求。已完成和下一步是支撑这两块的材料，不是主角。
图里的模板把“已完成”“下一步”也单列了出来；它们有用，但决定这份汇报能不能用起来的，是中间那三块 1。
重写：三块加一句支撑
同一个项目，换成下面的写法：
Status: Yellow. We are still on for 13 October, but only if the provider's certification lands by 3 October.
Since last Friday: checkout UI is code-complete and in QA with no blocking issues; fraud-rules migration finished two days early; load test passed at 3× expected peak.
At risk: provider certification is about a week behind. Two findings from their review; we closed one, the second (webhook retry behaviour) sits with their engineer, who promised an answer on Wednesday. 3 October is the last date that keeps 13 October intact.
Decision needed from you by Friday: launch with invoicing v1, or hold for v2 and move the launch by two weeks. I'd go with v1 — the gap only affects multi-currency refunds, which is under 2% of orders.
Nothing else needs you this week.
逐块看它做了什么。
第一块是色标加一句带条件的理由。 它没写 “Good progress on the checkout revamp”，那种句子不含信息，好消息本来也不需要你处理。它写的是黄，以及黄的条件：13 日上线不变，前提是 3 日拿到认证。检验方法很具体——如果对方只把这第一句转发出去，收到的人知不知道这周发生了什么、悬在哪里。
第二块每条以结果开头。 finished、passed、code-complete 都是完成态；“worked on”“continued”“looked into” 只说明投入，不说明产出。读者靠产出判断要不要担心，靠投入判断不了任何事 2。
第三块的风险带了三样东西：影响、责任人、下一次答复的日期。 影响是“3 日拿不到就顺延一周”；责任人是对方那位工程师；日期是周三。缺了责任人和日期，一条风险就只是焦虑，不是条目——读者既不知道自己该等什么，也不知道你会不会一直沉默下去 2。
第四块的请求是一个决定，不是一段情况说明。 它指名了人（你们）、给了日期（周五）、给了两个选项，还给了你的建议和取舍的理由。只列选项不给建议，等于把工作退回给对方；给出建议和代价，对方点个头就能往前走 3。
最后那句 “Nothing else needs you this week” 不是客套。空着不写，对方得自己从头扫一遍才能确认真的没事，写出来他就可以关掉邮件 3。
色标不是装饰，是一套约定
绿是按计划、不需要你动手；黄是有风险但团队自己能处理，你需要知道；红是不干预就会错过日期或质量线，而且要说清你需要哪种干预 4。
比含义更重要的是那条不成文规矩：不要从绿跳到红。 项目应该走绿 → 黄 → 红，第一次看见黄就要说。对方第一次听到坏消息时，如果已经是红色形态，他的注意力会全花在“为什么现在才告诉我”上，而不是“我们怎么补” 4。怕显得没做好而一直报绿，代价是读的人逐渐停止细看——等你真要他做决定时，他已经不看了。
口头版：同样的三块，九十秒
Quick update on the checkout revamp — we're yellow. UI's in QA with no blockers, the fraud migration finished early, load test passed at three times peak. The one thing that matters is the provider certification: about a week behind, they owe us an answer Wednesday. If it's not done by 3 October, launch slips a week. Which brings me to you — we need a call by Friday on v1 versus v2 invoicing. I'd go v1. Want me to walk you through the trade-off?
和书面版一致的两点：结论在第一句，不是铺垫完之后才出现；结尾是一个问题，把话交回给对方，不是用“anyway”含糊收掉。另外，对方上周已经听过的事不要复述，比如“我们和服务商开了个会，他们提了两项问题”，它只占位置——这和跟进邮件里“删掉重述、保留请求”是同一条原则。
听众换了，哪块变长也不同：对客户，风险要写清对日期的影响，请求通常是决定或批准；对上级，请求常常是资源、授权或者“需要你去跟某某说一声”。这周真的一切顺利时，不要编风险充数，但要写明日期还算不算数，因为“绿”本身没有信息量 5。
发出去之前，五条自检
- 只读第一句，对方能不能复述“什么状态、靠什么条件成立”？
- 每条进度是不是以完成态动词开头？出现 worked on、continued 就改写。
- 每条风险有没有影响、责任人、下一次答复的日期？
- 请求是不是“谁 + 什么时候 + 做什么决定”，有没有附上你的建议和代价？
- 这周真不需要对方做事时，有没有明确写出 nothing needed？
这五条过了，对方读四十秒就能往下走，不必再问你一句。