技能介绍

状态更新、周报和 QBR 文本看似简单，真正难的是把杂乱的项目笔记，压缩成让 CEO、VP 或跨团队同事能 30 秒看懂、并能据此决策的文档。原始资料里反复出现四个具体痛点：信息密度不可控（“工作了一天” 和 “上线了功能” 混在一起）；受众校准缺失（给 CEO 和给工程组的内容没区分）；坏消息遮遮掩掩（被埋在最后才说）；决策请求不完整（只提问题不给建议）。对工程师和 PM 来说，这意味着每次写状态都要在脑子里同时跑好几套标准，稍有不慎就会写出“看起来进展顺利、实际无人能推动下一步”的废话。

一、解决了什么问题

这个技能不负责美化语言，而是先对齐五个必须明确的输入：Who 受众是谁、What cadence 更新频率、What is the declared status （On Track / Off Track / Blocked）、What is the one thing 对方必须知道或行动的事、What was actually shipped 真正交付了什么。如果这五个问题无法回答，技能会先要求追问，而不是靠猜。它还强制区分“进展”与“活动”——只有 shipped 的结果才算进展，“我们正在研究”“我们讨论了方案”这类动词一律不计入。

二、核心能力与关键步骤

技能内置了一套 70 分制加权决策规则：质量（30%）、效率（25%）、准确性（25%）、安全性（20%）。分数 ≥85 才可继续，70–84 需要带监控条件推进，低于 70 直接停。它要求必须被执行的四阶段工作流也相当具体：

Phase 1: Assessment：收集需求、分析缺口，确认利益相关方已签字。
Phase 2: Planning：制定方案、评估资源和风险，明确缓解计划。
Phase 3: Execution：按计划执行，持续监控进度，根据反馈调整。
Phase 4: Review & Validation：对照成功标准验证，输出经验教训和交接文档。

在输出层面，技能强制每个状态更新包含 2-sentence TL;DR（可独立成立）、显式状态声明、shipped 结果、障碍项（含 likelihood + impact + mitigation）以及决策请求（含 owner + deadline + recommendation）。它拒绝被动语态、模糊主语和一切不通过 “so what?” 测试的句子。

三、适用边界与注意点

这个技能不是用来写营销文案或新闻稿的。它不会编造指标、不会把 0% 的完成度包装成“稳步推进”、也不会为同一个受众复制同一套模板。如果你手头只有零散的会议记录、Git 提交信息和几个零散的里程碑，它可以帮你提炼；但如果你连“谁是受众”或“真正的交付物是什么”都说不清，它不会替你猜——你必须先补上这些信息。另外，技能要求所有内容对不同受众做校准，给董事会写的 QBR 和给小组写的日报，深度、篇幅和决策请求完全不同。忽略这一点，输出就会退化成通用模板，这正是它最想避免的失败模式。