周报救星·3分钟出稿

为什么需要这样一个技能

写周报的常见困境不是「没干活」，而是干了活却讲不清楚。你在一周内修了多个缺陷、重构了模块、推进了项目，但落到文档里只剩一句「改了几个 bug、处理了一些问题」。这类表述在评审会上没有记忆点，也无法回答管理者真正关心的问题：做了什么、影响有多大、风险在哪里、下周要什么。

另一个现实问题是视角错位。同一份工作成果，结果导向的管理者想先看数字，过程管理型的管理者想看风险和卡点，宏观叙事型的管理者想看与战略的对齐关系。一份模板打天下，往往哪头都讨不到好。

这个技能如何工作

它的解法可以拆成三块核心能力：

STAR 改写引擎。 把口语化的流水账逐条重写为「动作 + 规模 + 结果 + 价值」句式。例如「改了几个 bug」会被翻译为「修复 X 个线上缺陷，故障率下降 Y%」。这个过程不是套话术，而是先向你追问 2–3 个关键数字（规模、耗时、效果），实在拿不到精确值时，用「约 / 预计」标注的范围估算兜底。

三种老板模板。 在改写前先问一句：你的汇报对象更看重结果、过程还是战略对齐？据此匹配三种结构之一——结果导向型先抛数据，过程管理型先摆风险，宏观叙事型先讲对齐。

固定四段式骨架。 输出统一遵循「本周成果 → 数据/进度 → 风险与求助 → 下周计划」。其中「风险与求助」被当作独立段落，引导你写出至少一条风险提示或资源请求——这是周报里真正产生向上管理价值的部分，而不是被动等老板来问。

具体工作流分六步：收集素材（口语倾倒或读取待办/日志文件）→ 追问量化（最多 3 个问题）→ 选模板 → STAR 改写 → 引导风险与求助 → 交付可直接粘贴的 Markdown 周报正文，可选 HTML 精排版。每条成果控制在 2 行以内，数据加粗，例如：

完成支付模块重构：拆分 3 个核心接口，压测 QPS 从 1200 提升至 3400，为大促扩容扫清瓶颈。

适用边界

这个技能只做一件事：把已有的工作事实整理成结构化文本。它不会替你编造不存在的数据或成果——凡是估算都会明确标注「约 / 预计」，你需要在发送前确认这些数字站得住脚。

它也不代你发送周报。产出物是文本，粘贴、抄送、提交的主动权仍在你手里。

如果你本周的工作本身就没有可量化的产出（比如纯探索性研究、外部依赖阻塞），强行套数据模板只会得到一份空洞的周报。那种情况下，如实写清阻塞原因和下周推演，反而比硬凑数字更有说服力。