Sitrep
情况报告是写给没在现场的人看的。 请为他们而写。
情况报告不是活动日记。它是一份浓缩的、可行动的状态快照。回答三个问题：已完成什么、被什么阻塞、下一步做什么。任何不能回答这三个问题之一的内容都不应出现在情况报告中。
何时使用
- 每日站会总结（从工作日志、提交记录或工单状态中综合）
- 给利益相关者的冲刺总结
- 事件期间或之后的事件情况报告
- 切换上下文或将工作移交给其他代理或人员时的交接总结
- 当利益相关者问“我们现在到哪了？”而诚实的答案是“情况复杂”时
流程
-
收集当前工作状态 — 从可用来源读取：
- 打开的和最近关闭的 issue / 工单
- 最近的提交（站会用过去24-48小时；冲刺总结用上一个冲刺）
- 项目状态和路线图文档（例如
docs/operating-model/PROJECT-OPERATING-PROFILE.md、docs/ROADMAP.md或项目结构中的等效文件） - 任何阻塞标记、风险登记记录或升级说明
-
将条目分类 到三个桶中：
- 已完成 — 已完成且可验证关闭（测试通过、工单关闭、已部署）
- 受阻 — 因特定未解决依赖而无法推进的工作（精确指明阻塞项）
- 下一步 — 接下来将要处理的最优先级项（按优先级排序）
-
编写情况报告 — 结构如下：
## 情况报告 — <日期> [<范围: sprint / 事件 / 交接>] **已完成** - <条目> — <一句话说明交付内容及其证据> **受阻** - <条目> — 阻塞于 <具体依赖 / 负责人 / 已知预计完成时间> **下一步** - <条目> — <优先级顺序，最重要的放在最前面> **风险 / 标志**（可选 — 仅在重要时使用） - <风险> — <如果未解决的潜在影响> — <负责人> -
应用压缩测试 — 对每一行：如果删除后不会改变读者需要采取行动的内容，就删掉它。
-
精确命名阻塞项 — “后端阻塞”不是阻塞条目。“阻塞于
/v2/orders的 API 契约 — 等待 @owner，预计完成时间未知”才是。 -
不要对进度进行编辑性评论 — “取得了良好进展”是噪音。“交付了 X，从而解除了 Y 的阻塞”才是信号。
输出
- 上述格式的情况报告
- 可选：一段面向需要更少信息的利益相关者的执行摘要
护栏
- 无活动记录。 “处理了认证模块”不是情况报告条目。“认证模块：JWT 验证完成，令牌刷新在负载下失败 —— 正在调查”才是。
- 受阻就是受阻。 如果某事进展缓慢但并未实际受阻，它应放在“下一步”中并附上备注，而不是“受阻”中。
- 完成就是完成。 “完成了95%”不是完成。如果它无法验证为完整，就应放在“下一步”中。
- 长度不是质量。 一个五行的情况报告若回答了三个问题，也好过一个二十行但未回答的报告。