落地案例：用 AI Agent 自动写周报，2 小时变 10 分钟

先讲一个真实场景。团队每周五要出周报，汇总十几个项目的进展，信息散落在项目管理工具、工作群和代码仓库里。过去靠人逐个翻：这个项目这周关了哪些任务、群里拍了什么板、代码提交到哪了——一个负责人整理一遍要两三个小时，还经常漏。

后来我们做了一套自动化流程，现在每周五下午自动跑，10 分钟出一份结构化周报初稿，负责人只做审核和背书。这篇把它拆开讲，重点不是“Agent 多聪明”，而是怎么设计才能让它真的靠谱落地。

一、需求拆解：周报到底在做什么

信息来源有三处，格式完全不同：

1. 项目管理工具（Jira / 飞书项目 / Linear）：任务的状态变更、新增、关闭；
2. 群聊记录：关键讨论、决策、风险暴露；
3. 代码仓库：本周的 Git commits、合并的 PR。

产出要求是一份结构化周报：每个项目一段「本周进展」，单列「风险项」和「下周计划」，控制篇幅、不注水、不编造。

这里有个关键判断：整个流程里，只有“提炼和写作”需要智能，其余都是确定性的数据搬运。 这个判断直接决定了架构。

二、架构：固定流水线 + 局部用模型

我们没有让一个自主 Agent “自由发挥”去写周报，而是设计成一条固定流水线——流程路径完全写死，LLM 只在两个节点上干活。

flowchart TB
    T["定时触发 · 周五下午"] --> Fetch
    subgraph Fetch["① 数据采集（确定性代码，不用模型）"]
        F1["拉 Jira 任务"] --- F2["拉群聊记录"] --- F3["拉 Git commits"]
    end
    Fetch --> Clean["② 规则清洗 + 小模型摘要<br/>去噪、分项目归组"]
    Clean --> Split["③ 按项目分片"]
    Split --> LLM["④ LLM 逐项目生成<br/>进展 / 风险 / 下周计划"]
    LLM --> Merge["⑤ 汇总成 Markdown 周报"]
    Merge --> Human["⑥ 发到负责人群 · 人工审核修改"]
    Human --> Archive["⑦ 确认后归档"]

核心原则就一句：数据收集用代码，提炼和写作交给模型。

为什么不让 Agent 自己决定调哪个工具、调几次？因为周报是每周重复、输入输出完全固定的任务。自主 Agent 的价值在于处理“事先无法预知步骤”的开放任务（见 Agent 模式篇）；而这里步骤是死的，让模型自由发挥只会引入不必要的不确定性——它可能漏调一个工具、可能对某个项目过度解读。固定流水线把每一步都变成可预期、可测试、可重试的，可靠性天差地别。

三、数据采集层：脏活用代码干

三个采集器都是普通脚本，通过各平台 API 拉数据：

• Jira：按项目、按时间范围查本周状态变更的 issue；
• 群聊：调 IM 的消息导出 API（企业微信/飞书/钉钉都有），拉本周消息；
• Git：用 git log --since 或平台 API 拿本周 commits 和 PR。

采集层做的事 100% 确定：拉全、拉对、带上时间和来源。这一层绝不让模型参与——模型不适合做“确保一条不漏”的事。

四、降噪与分片：喂给模型前先收拾干净

原始数据直接丢给模型是灾难，尤其是群聊。两个关键处理：

1. 规则清洗 + 预摘要。 群聊里 90% 是噪音：表情刷屏、机器人通知、“收到”“好的”。先用规则过滤掉这些，再用一个便宜小模型对每个群的消息做第一轮摘要，把几千条压成几十条要点。用小模型干这步，成本极低。

2. 按项目分片。 十几个项目的材料塞不进一个 Prompt，也容易串味。改成每个项目独立处理：这个项目的任务 + 相关群聊摘要 + 相关 commits 组成一份材料，单独生成一段，最后再拼起来。

flowchart LR
    Raw["全部原始数据"] --> F["规则过滤噪音"] --> S["小模型预摘要"]
    S --> P1["项目 A 材料"] --> G1["LLM 生成 A 段"]
    S --> P2["项目 B 材料"] --> G2["LLM 生成 B 段"]
    S --> P3["项目 C 材料"] --> G3["LLM 生成 C 段"]
    G1 --> M["汇总"]
    G2 --> M
    G3 --> M

分片带来三个好处：上下文不超长、单个项目质量更高、某段失败可以单独重跑。

五、生成节点的 Prompt 设计

每个项目的生成 Prompt 长这样：

你是项目经理助理。以下是【项目X】本周的原始材料：
【任务列表】{jira_issues}
【群聊摘要】{chat_summary}
【代码提交】{commits}

请生成该项目的周报片段，要求：
1. 进展只写有实质内容的事项，不要凑字数、不要套话；
2. 风险项单独列出，注明阻塞原因；
3. 每条陈述必须能在材料中找到依据，找不到依据但似乎重要的，
   用【待确认】标出，绝对不要编造；
4. 下周计划只列材料中有明确信号的事项；
5. 正文控制在 300 字以内。

几个刻意的设计：

• “只写有实质内容、不要凑字数”：模型默认倾向把空格填满，必须明确压制；
• “必须有依据，否则标【待确认】”：这是防幻觉的核心，给模型一个体面的退路，而不是逼它硬写；
• 给结构化字段（进展/风险/计划），输出稳定、好汇总。

六、人机分工：人做判断和背书

流程最后两步刻意留给人：生成的初稿发到负责人群，负责人快速过一遍、改几处措辞、确认【待确认】项，然后才归档。

这个分工很重要：

• 机器负责收集、搬运、起草这些“信息体力活”；
• 人负责判断、定调、背书——风险怎么定性、某件事要不要上报，这些需要上下文和责任；
• 人不再是“写周报的人”，而是“审核周报的人”，从生产者变成把关者。

七、踩过的三个坑

坑 1：群聊噪音淹没有效信息。 早期把几千条原始消息直接喂进去，模型抓不住重点，输出一堆“团队积极沟通”这种废话。改成规则过滤 + 小模型预摘要后才好转。喂给模型前的数据清洗，比换大模型重要得多。

坑 2：模型会脑补进展。 出现过“项目顺利推进中”这种材料里根本没有的话。根因是模型倾向于写“看起来完整”的周报。加上“每条必须有依据、否则标【待确认】”的硬约束后基本消失，审核时专门盯【待确认】标记即可。

坑 3：上下文超长 + 项目串味。 全塞一个 Prompt 时，模型会把 A 项目的事安到 B 头上。按项目分片处理后解决，还顺带解决了 token 超限。

八、效果与成本

• 耗时：人工 2~3 小时 → 审核约 10 分钟；
• Token 成本：每周约 2~3 元人民币（大头是群聊预摘要，用的便宜小模型）；
• 初稿可用率：约 80%，负责人通常只改几处措辞、补几个【待确认】；
• 漏报率：因为采集是代码做的、比人翻得全，反而比人工时代更少遗漏。

九、可复制的方法论

这个案例能成，靠的不是模型多强，而是三条可迁移的原则：

flowchart TB
    A["① 选对任务<br/>高频 · 输入输出固定 · 规则清晰"] --> B["② 确定性的活交给代码<br/>采集/搬运/校验不依赖模型"]
    B --> C["③ 智能的活才用模型<br/>提炼/写作/归纳"]
    C --> D["④ 人机分工<br/>机器起草，人审核背书"]
    D --> E["⑤ 容错兜底<br/>【待确认】标记 + 人工卡点"]

1. 挑流程固定的任务先做：每周/每天重复、输入输出明确的，最适合自动化；开放、需临场判断的才考虑自主 Agent；
2. 能确定的别交给概率：数据采集、格式校验、规则过滤用代码，把模型用在真正需要“理解和表达”的环节；
3. 给模型退路而不是逼它硬答：【待确认】机制把幻觉变成可见的待办，而不是藏在通顺文字里的错误；
4. 人始终在环里：自动化的目标是把人从信息搬运中解放出来去做判断，而不是把人完全踢出去。

小结

这个周报系统本质是一条工作流（Workflow），而不是一个自主 Agent——这恰恰是它可靠、便宜、敢上线的原因。它把“确定性”和“智能”分得很清：代码保证不漏不重，模型负责把杂乱材料变成通顺文字，人负责最后的判断和责任。

办公场景里最靠谱的 AI 落地，往往不是追求“全自动”，而是找准那些重复、繁琐、规则清晰的环节，让人从搬运工变成审核者。周报如此，报表、巡检、工单分诊、会议纪要也都同理。

本文由 AI 辅助创作，所有内容仅供交流与参考。