每个周五下午，你的团队在做同一件事：打开空白文档，回忆这周干了什么，凑出一份周报。
这件事的荒谬之处在于——周一到周五，你们已经开了 10 次站会，讨论了 50 个问题，做了 20 个决策。所有信息都已经存在了，只是散落在会议录音、聊天记录、任务系统里。周报不是「写」出来的，应该是「长」出来的。
这篇文章用一个 War Room Scrum 的完整案例，说明怎么用 AI 原生思维重构日报和周报流程。核心转变： 不是让 AI 帮你润色周报，而是让 AI 从日常运转的数据中自动聚合出周报。
先搞清楚问题在哪
传统周报流程：
周五下午 → 回忆这周干了啥 → 写成流水账 → 提交
问题不是「写得慢」，而是 信息在生产端就已经丢失了：
| 信息源 | 产生时间 | 信息量 | 周报利用率 |
|---|---|---|---|
| 站会发言 | 每天 2 次 | 高 | 几乎为 0 |
| 任务系统更新 | 实时 | 高 | 手动搬运 |
| 会议讨论 | 不定时 | 中 | 凭记忆 |
| 群聊记录 | 实时 | 低信噪比 | 几乎为 0 |
AI 原生思维的第一步： 不要想着「怎么写周报」，先想「信息已经在哪里了」。
案例：War Room 的一天
War Room 是一个技术支持团队的作战模式。每天早上站会对齐目标，晚上站会更新进展。数据天然结构化：
┌─────────────────────────────────────────────────────┐
│ War Room Daily Flow │
├─────────────────────────────────────────────────────┤
│ │
│ 早会 (9:30) │
│ ├── 听记录音 → ASR 转写 │
│ └── 每人汇报今日目标 │
│ │
│ 白天 │
│ ├── 任务系统：接单、处理、评分 │
│ └── 群聊：实时讨论 │
│ │
│ 晚会 (17:30) │
│ ├── 听记录音 → ASR 转写 │
│ └── 每人汇报今日进展 │
│ │
│ 产出 │
│ ├── 日报：结构化数据（自动聚合） │
│ └── 周五：周报（自动聚合 5 天日报） │
│ │
└─────────────────────────────────────────────────────┘
War Room 日报模板
团队需要的日报长这样：
# War Room 日报 2026-05-25
## 1. 今日问题处理概览
今天 5 位用户总共处理了 23 个问题
其中：
- 90 分+ 任务数：12
- 60-90 分任务数：8
- <60 分任务数：3
## 2. Harness 规则沉淀
今天沉淀了 4 条 harness 规则：
| 任务类型 | 规则 | 提出人 |
|----------|------|--------|
| K8s OOM | 先看 request/limit → 再看 node memory pressure → 最后看 heap dump | 张三 |
| 数据库慢查询 | EXPLAIN 分析 → 检查索引 → 检查数据分布 → 考虑分区 | 李四 |
| Redis 超时 | 检查连接池 → 检查大 key → 检查网络抖动 | 王五 |
| 接口 5xx | 看 error log → 检查下游超时 → 检查自身资源水位 | 赵六 |
## 3. 任务类型满意度汇总
| 任务类型 | 处理数 | 平均满意度 |
|----------|--------|------------|
| K8s 问题 | 8 | 4.2 |
| 数据库问题 | 6 | 4.5 |
| 网络问题 | 5 | 3.8 |
| 应用问题 | 4 | 4.0 |
关键观察：这份日报的数据 没有一个需要人手动写。
三层数据，三种采集策略
| 数据层 | 示例 | 采集方式 | 人工介入 |
|---|---|---|---|
| 硬数据 | 任务数、分数分布、满意度 | API 直接拉取 | 零 |
| 半结构化 | 每人今日目标/进展 | 听记 ASR → AI 提取 | 2 分钟校对 |
| 软知识 | Harness 规则沉淀 | 会议讨论 → AI 提取 | 5 分钟校准 |
第一层：硬数据直接拉
任务系统有 API，分数和满意度都是现成字段：
from dataclasses import dataclass
from collections import defaultdict
from datetime import date
@dataclass
class DailyMetrics:
total_users: int
total_tasks: int
score_90_plus: int
score_60_90: int
score_below_60: int
type_satisfaction: dict[str, float]
def collect_daily_metrics(day: date) -> DailyMetrics:
"""从任务系统拉取当日硬数据"""
tasks = task_system.query(date=day, team="war_room")
users = {t.assignee for t in tasks}
score_buckets = {"90+": 0, "60-90": 0, "<60": 0}
for t in tasks:
if t.score >= 90:
score_buckets["90+"] += 1
elif t.score >= 60:
score_buckets["60-90"] += 1
else:
score_buckets["<60"] += 1
# 按任务类型聚合满意度
type_scores: dict[str, list[float]] = defaultdict(list)
for t in tasks:
if t.satisfaction is not None:
type_scores[t.type].append(t.satisfaction)
type_avg = {
k: round(sum(v) / len(v), 1)
for k, v in type_scores.items()
}
return DailyMetrics(
total_users=len(users),
total_tasks=len(tasks),
score_90_plus=score_buckets["90+"],
score_60_90=score_buckets["60-90"],
score_below_60=score_buckets["<60"],
type_satisfaction=type_avg,
)
# generated by hugo AI
这一步没有任何 AI 参与的必要。用 AI 去「总结任务系统数据」是浪费——SQL 聚合比 LLM 又快又准。
第二层：听记 ASR → 结构化提取
早晚会用钉钉听记录音，ASR 转写后丢给 AI 提取。但 ASR 文本有三个坑：
- 口语化：「那个…审批流那边，灰度放到 50% 了，目前看没啥问题」
- 多人混合：没有明确说话人标记
- 早晚混合：同一段录音里可能既有目标又有进展
提取 Prompt 要针对这三个坑设计：
从以下站会 ASR 转写中提取每人的日报信息。
提取规则：
1. 忽略口语填充词（那个、就是、嗯、啊）
2. 根据内容推断说话人（如提到「我负责的审批流」→ 审批流 owner）
3. 区分「计划」（早会）和「结果」（晚会）
4. 只提取可验证的事实，忽略情绪表达
输出格式（每人一条）：
姓名｜目标/进展｜任务描述｜状态（✅/⚠️/❌）｜卡点（如有）
ASR 文本：
"""
{听记转写内容}
"""
为什么不用听记自带的 AI 总结？ 因为听记的总结是面向「会议纪要」的，而你需要的是面向「日报字段」的结构化数据。目标不同，提取逻辑不同。
第三层：Harness 规则沉淀
这是最有价值也最难自动化的部分。War Room 会议中经常有这样的讨论：
「刚才那个 K8s Pod OOM 的问题，我们发现通用的排查步骤应该是先看 request/limit 配置，再看 node memory pressure，最后才看应用 heap dump。以后遇到 OOM 都可以按这个顺序来。」
这句话就是一条 Harness 规则。但它混在 30 分钟的会议录音里，如果不刻意提取，下周就没人记得了。
提取 Prompt：
从以下 War Room 会议 ASR 中提取可复用的 Harness 规则。
判断标准（必须同时满足）：
1. 描述的是通用排查步骤或解决方案模式
2. 不是针对单个问题的临时 fix
3. 有人明确提出了「以后遇到这类问题应该...」的意图
输出格式：
| 任务类型 | 规则（用 → 连接步骤）| 提出人 |
如果没有符合条件的规则，输出：无新增规则
ASR 文本：
"""
{听记转写内容}
"""
人工校准点：AI 提取的规则需要人花 5 分钟确认——有些规则看起来通用但实际上只适用于特定场景，有些口语化的表达需要改写成标准格式。
日报自动化流程
把三层数据拼起来：
import json
from pathlib import Path
def generate_daily_report(
day: date,
asr_morning: str,
asr_evening: str,
) -> str:
"""生成 War Room 日报"""
# 第一层：硬数据（API 拉取）
metrics = collect_daily_metrics(day)
# 第二层：AI 提取每人目标/进展
personal_updates = ai_extract_updates(asr_morning, asr_evening)
# 第三层：AI 提取 Harness 规则
harness_rules = ai_extract_harness_rules(asr_evening)
# 组合成日报 markdown
report = f"""# War Room 日报 {day}
## 1. 今日问题处理概览
今天 **{metrics.total_users} 位**用户总共处理了 **{metrics.total_tasks} 个**问题
其中：
- 90 分+ 任务数：**{metrics.score_90_plus}**
- 60-90 分任务数：**{metrics.score_60_90}**
- <60 分任务数：**{metrics.score_below_60}**
## 2. Harness 规则沉淀
今天沉淀了 **{len(harness_rules)} 条** harness 规则：
{format_rules_table(harness_rules)}
## 3. 任务类型满意度汇总
{format_satisfaction_table(metrics.type_satisfaction)}
"""
return report
# generated by hugo AI
然后通过 dws report 提交到钉钉日志系统：
dws report create --template "War Room 日报" --content "$(cat daily_report.md)" --format json
每天投入时间： 2 分钟校对 AI 提取结果。
从日报到周报：周五聚合
5 天日报已经在钉钉日志系统里了，周五只需要做一次聚合：
# 拉取本周日报
dws report inbox --start-date "2026-05-25" --end-date "2026-05-29" --format json > weekly_raw.json
然后用 AI 聚合，关键是告诉 AI 怎么合并：
基于本周 5 天 War Room 日报，生成周报。
聚合规则：
1. 问题处理：计算本周总量、日均、峰值，对比上周趋势
2. 分数分布：90+ 占比是否提升，<60 分任务有什么共性
3. Harness 规则：本周累计条数，按任务类型分类
4. 满意度趋势：哪些类型在提升，哪些在下降
5. 下周改进：基于 <60 分任务的共性原因给出建议
输出格式：
## 本周关键数据
## Harness 规则沉淀（本周累计）
## 满意度趋势
## 未解决的卡点
## 下周优先级
周报长什么样
AI 聚合后的周报：
## 本周关键数据
- 总处理问题：**112 个**（日均 22.4，峰值周三 28 个）
- 较上周 +15%
分数分布变化：
- 90+ 占比：**55%**（上周 48%，提升 7pp）
- <60 分任务 **11 个**，共性原因：新上线的微服务缺少文档
## Harness 规则沉淀（本周累计 18 条）
| 任务类型 | 规则数 | 代表性规则 |
|----------|--------|------------|
| K8s 问题 | 6 | OOM 排查三步法 |
| 数据库问题 | 5 | 慢查询 EXPLAIN 四步法 |
| 网络问题 | 4 | DNS 解析超时排查 |
| 应用问题 | 3 | 5xx 快速定位法 |
## 满意度趋势
| 任务类型 | 本周均值 | 上周均值 | 趋势 |
|----------|----------|----------|------|
| K8s 问题 | 4.3 | 4.1 | ↑ |
| 数据库问题 | 4.5 | 4.4 | → |
| 网络问题 | 3.6 | 4.0 | ↓ |
| 应用问题 | 4.0 | 3.8 | ↑ |
网络问题满意度下降，主因：2 个 DNS 相关问题处理时间过长。
## 未解决的卡点
- 新微服务缺少文档，导致 <60 分任务集中在第一周（张三跟进）
- DNS 排查工具不统一，效率低（王五跟进）
## 下周优先级
1. 新微服务文档补全（解决 <60 分任务根因）
2. DNS 排查 SOP 沉淀（基于本周 4 条 Harness 规则）
3. 满意度回访：针对本周 <60 分的 11 个任务
管理者要做的事：花 5 分钟 review，删掉 AI 生成的套话，补充只有你知道的判断（比如「网络问题满意度下降是因为某某人的 DNS 经验还没沉淀」）。
投入产出对比
| 传统方式 | AI 原生方式 | |
|---|---|---|
| 每人每天写日报 | 10 分钟 × 5 人 = 50 分钟 | 0（站会就是日报） |
| 管理者每天 review | 15 分钟 | 2 分钟（校对 AI 提取） |
| 周五写周报 | 30 分钟 | 0（自动聚合） |
| 周五 review 周报 | 15 分钟 | 5 分钟（校准） |
| 周总投入 | 7.5 小时 | 1.2 小时 |
但省时间不是重点。重点是 信息保真度——周报里的每个数字都可以追溯到当天的站会录音和任务系统记录，不是靠记忆「编」出来的。
写在最后
AI 原生写周报的核心不是「用 AI 写」，而是 让数据在生产过程中自然结构化，然后让 AI 做聚合。
三个层次：
- 硬数据用 API——任务系统里已有的数据，不要让人再抄一遍
- 半结构化用 ASR + AI——站会发言用听记录音，AI 提取结构化字段
- 软知识用 AI 提取 + 人校准——会议中的经验沉淀，AI 初筛，人做最终判断
日报是周报的子集，站会是日报的子集。信息从站会开始，每天聚合一次成日报，每周聚合一次成周报。没有额外的「写」的动作，只有「确认」的动作。
这才是 AI 原生的工作方式——不是替代你写，而是让「写」这个动作变得不必要。
你在用什么方式写周报？还是周五补作业？欢迎分享你的实践。