任务场景
周四下午。你 owner 一个跨职能项目——设计、工程、数据、一家外部 vendor——周报要在周五 EOD 前发出去。leadership 想要一份 60 秒能读完、RAG 颜色打对了的 update。团队想看到你注意到这周 spec 改了两次、也没人在装作 API slip 没发生。Slack 往上翻 200 条，Notion 里堆着半打写了一半的草稿。你需要一份能同时对两边讲真话、又不会引来晚上 11 点紧急 ping 的文档。
什么时候适合让 AI 来做
AI 擅长把散乱笔记压成 RAG（Red / Amber / Green）结构，把你随口提过但没正式 flag 的风险显化，把”基本上还好”这种模糊措辞改成 leadership 能据此行动的句子。它也擅长把”变了什么”和”还在原状”分开——周报最常被忽略的原因，是它在重复上周的状态，而不是高亮 delta。
AI 做不到：替你打颜色。这要看 leadership 上个季度的容忍度、VP 是不是已经为 launch 紧张、你的 skip-level 期望你高估风险还是低估。AI 也分不清”真的被卡住的决策”和”只是推进慢的决策”。这些是 judgment call。
常见失败模式：AI 默认输出对称结构——3 个 win、3 个 risk、3 个 decision——哪怕真实情况是 1 个 win、1 个大 risk、0 个待决策。要明说：“不要为了凑结构而硬填；这周没有 decision needed 就写’本周无，下周一再 pull’。“
需要先给 AI 的信息
- 上周的 update 原文（让模型知道哪些算”变了”）
- 本周原始笔记——做出的决策、slip、亮点、风险、scope 变更、vendor 延期
- 你自己对 RAG 的判断（Green / Amber / Red）+ 一句话理由
- 本周最重要的那个里程碑日期（模型用它做 anchor）
- 每条 workstream 的 owner 姓名 + 角色（让风险有人接，不会变孤儿）
- leadership 当下的敏感度——是为 launch 紧张，还是这个季度本身就低注意力？
- 你最希望 leadership 知道、但他们大概率还不知道的那一句话（buried lead）
- 自上次 update 以来的 scope / budget 变化（这种必须放在 fold 之上）
可直接复制的 Prompt
帮我写一份 {项目名} 的 status update。
读者：{leadership + 团队}。
上周 update（原文粘贴）：{paste}
本周笔记：{paste}
我的 RAG 判断：{Green / Amber / Red}，因为 {一句话}。
Anchor 里程碑：{日期 + 交付什么}。
Leadership 大概率还不知道的 buried lead：{一句话}。
结构：
1）标题——一句话，含 RAG 颜色和 anchor 里程碑日期。
2）相比上周变了什么——只写 delta，不复述还在原状的部分。
3）风险——每条要有具体 mitigation、owner、by when。没 owner 的降级为 watch-item。
4）需要拍板的事——写明决策点、选项、决策人、延误代价。本周没有就写"无，下周 {day} 再 pull"。
5）未来 2 周——3-5 条，每条标注 workstream 和负责人。
总长 250 字以内。不要为了对称硬填。Buried lead 必须出现在前 3 行。短版本——只给 leadership 看的 80 字标题段
帮 {项目} 写 80 字的 leadership 版段落。
RAG：{颜色}。Anchor 里程碑：{日期}。
他们最需要知道的一句：{句子}。
格式：1 句 RAG + anchor。1 句变化。1 句最大风险 + owner。1 句我们需要他们做什么（或"本周无需"）。
不要 bullet。不要废话。输出示例
一个好的标题：“Amber，直到 11/14——设计在计划上，工程支付 API 滞后一个 sprint；恢复计划已落地，目前未动 scope。Buried lead：fraud check 的 vendor SLA 11/8 到期，续签本周要走 Legal sign-off。”
一条好的风险 bullet：“支付 API 滞后一个 sprint（owner：Maya，eng）。Mitigation：v1 砍掉 analytics，重新 baseline 到 11/14 上线。如果想在 v1 保留 referral code，11/1 之前必须拍板；否则默认 defer。”
一条好的”决策需求”行：“无，下周一再 pull。两项在等 vendor 回复，下周浮出来或升级。“
怎么改输出
- 每条风险必须有 owner 和日期 —— “每条风险必须有具名 owner 和 by when。两者都没有就降级到 watch-item，从主 risks 区移走。”
- 删掉重复的背景 —— “删掉任何上周 update 也写过的句子。Update 只是 delta，背景读者自己往回翻。”
- Buried lead 提前到前 3 行 —— “把 leadership 最需要知道的那句重排到第一句，不是第三段。”
- 预答会被问的那一句 —— “每条风险后面加 1 句回答 leadership 一定会问的问题：‘这条要怎么样才变 Red’或’为什么还不是 Red’。”
- 砍到 250 字 —— “砍到 250 字。剩下来的就是真 update。某个 section 消失也没关系——对称不是目标。“
容易踩的坑
- 永远 Green，掩盖 slip——一旦 leadership 注意到 update 和现实之间的 gap，之后每份 update 都会被打折读
- 把每张 Jira 工单、每个 merge 的 PR 都列上——leadership 要信号，团队想看细节自己开 board
- 没具体日期——“快了”、“很快”、“这季度”都不是 status；选一周写出来，下周修就修
- 风险跟上周一字不差地复述——没动就写”无变化，仍 Amber”，别再解释一遍
- 风险没 owner——孤儿风险被当装饰品，没人接，报告变成 theater
- Buried lead 埋太深——leadership 最该知道的那句不能放第 4 段
- 满篇”我们”——明确写谁 owner 什么；“我们”是 accountability 死掉的地方
- 放任 AI 编出你笔记里没有的风险——只 ship 你真信的风险；幻影风险会快速侵蚀可信度
FAQ
- leadership 和工程团队同一份模板吗？ —— body 一致，标题不同。工程要看”变了什么”在前，leadership 要看 RAG 颜色和 anchor 日期在前。同一份正文出两个 headline 就行。
- Amber 什么时候变 Red？ —— 当 mitigation 需要 leadership 才能批的资源或 scope 变更时。团队哪怕痛苦也能自救——Amber。Red 是求救信号，不是描述”感觉有多糟”。
- AI 一直把风险写软怎么办？ —— Prompt 里加：“如果某条风险删了 leadership 的行动不会变，那就应该写得更响、而不是更软。模糊风险会被忽略，被忽略的风险会变 Red。“再跑一次。
- 真的本周没东西可 update 怎么办？ —— 写一份 60 字的 steady state——anchor 日期、RAG、下个 checkpoint 一句话。跳一周比短一份更糟。
- update 应该在全员会前发还是会后发？ —— 会前。Update 是 leadership 没法参加时读的那份 artifact；全员会是团队就着它提问的地方。