项目周报自动汇编：三个系统的数据一张纸

当过项目经理的都懂周报的苦：周一上午全组交周报，项目经理拼了半天，进度在项目管理工具里、代码提交在代码库里、缺陷数据在测试系统里——三处数据手工抄到一张周报上，抄完还要跟各组长核对一遍数字。一上午就搭进去了，还常常有数对不上的时候。

我们今年把这个场景自动化了：云函数定时跑，三个系统的数据自动拉取、自动汇编成周报，周一早上九点，一张数据齐整的周报躺在群里。这篇讲实现——重点是怎么把三个数据源揉成一张口径一致的纸。

一、需求与架构

1.1 周报的构成拆解

先拆周报结构，这一步比写代码重要：我们的周报五块内容——本周进度概览（各任务线完成百分比）、关键里程碑状态（下月内节点的健康度：绿黄红）、代码活动量（提交数、合入数、评审数）、缺陷态势（新增、关闭、存量、超期未关）、风险与下周计划（这块保留人工写，机器不越界）。

拆解后明确了自动化边界：前四块全是数据汇编（机器的活），第五块是判断表达（人的活）。边界划清楚，方案就成了一半——自动化的失败案例，一半败在没划边界，什么都想自动，最后什么都自动不好。

1.2 架构：云函数定时拉数汇编

架构很轻：云函数定时触发（周一早八点），依次拉三个系统的数据，汇编成周报文档，推送到群里。没有常驻服务，没有新服务器——一个函数加定时器，全部家当。选云函数跑这个任务的理由：定时触发是原生能力、按次计费几乎免费、跟企业微信的推送通道现成。

二、实现要点

2.1 三源数据拉取

三个系统各有各的接口脾气，拉数代码要各显神通：

def collect(snapshot_date):
    """三源数据采集，输出统一中间格式"""
    # 项目管理工具：REST 接口，按项目拉任务线进度
    tasks = []
    for pid in PROJECT_IDS:
        r = pm_api.get(f"/projects/{pid}/progress", date=snapshot_date)
        tasks.append({
            "line": r["name"], "progress": r["percent"],
            "owner": r["lead"], "delta": r["week_change"],
        })
    # 代码库：提交合入统计（按成员与仓库两个维度）
    commits = code_api.stats(since=last_monday, to=snapshot_date)
    # 缺陷系统：按严重级别分桶，超期单单独标记
    bugs = []
    for b in bug_api.list(status="open"):
        bugs.append({
            "severity": b["level"],
            "age_days": (snapshot_date - b["created"]).days,
            "overdue": (snapshot_date - b["created"]).days > SLA[b["level"]],
        })
    return {"tasks": tasks, "commits": commits, "bugs": bugs}

三个系统接口风格不一，中间格式是关键设计：所有数据先转成统一的内部结构再进汇编层——中间格式隔开了接口的多样性和汇编的稳定性，某个系统换接口，只改采集层，汇编层不动。这个分层救过我们两次（缺陷系统升级换了接口版本，改动关在采集层里，周报没断一期）。

2.2 口径统一：最费劲的一环

三个系统的数据拼一张纸，最大的坑不是拉数，是口径。举两个真实的例子：进度的口径——项目工具里的完成百分比是任务数比值，各组长的体感是工作量比值，两个口径差出十个点，周报头一回发出去就被质疑数字不对；缺陷的口径——测试系统的新增缺陷按创建时间算，但有的测试周五录的周一才分派，周环比看着像暴增，其实是录入延迟。

解法是把口径定义写成显式规则，跟各组长开一次会对齐：进度按任务数口径（在周报里注明口径说明，免得歧义）；新增缺陷按分派时间算（更贴近真实节奏）。这次对齐会开了四十分钟，但价值极大——口径一致后，周报的数字再没被挑战过。教训沉淀成一句话：自动汇编前先人工对表，口径没对齐的自动化，是把分歧用机器的速度放大。

2.3 汇编生成：模板加模型摘要

数据齐了进汇编层：固定部分用模板直接渲染（表格、数字、状态标记——确定性内容用确定性手段）；进度概览的一段自然语言摘要用大模型生成（把中间格式的数据喂给模型，生成两三句概览：本周整体进度推进几个点、哪条线进展显著、哪个里程碑需要关注）。模型只做摘要不做评价——生成的内容里不允许出现建议和判断（那是人的部分），提示词里明确圈死。模板渲染占周报九成内容，模型摘要就开头一小段——比例设计成这样，是刻意的：机器管确定的事实，判断留给组长们的风险与下周计划。

2.4 推送与留档

生成的周报推到项目群，同时归档到文档库（按周次结构化存放，附原始数据快照）。留档快照这个不起眼的设计后来大有用处：季度复盘时，十六周的进度快照连起来就是现成的项目轨迹分析素材——不用再回头翻系统。

三、运行效果

运行三个多月的数据：周报产出时效从人工时代的一上午（约三小时）变成自动生成的三分钟；数字口径零争议（对表会议的功劳）；组长们的反馈最实在——原来每周一上午被周报占用，现在拿来过风险和计划，周一例会的质量肉眼可见地好了。

还有个计划外的收益：周报的准时性反过来带动了全组的数据纪律——代码提交规范了（数据要上周报，乱提交会显眼）、缺陷及时分派了（超期单每周晾在周报上，谁的责任一目了然）。一张诚实的周报，比十次数据治理会议都管用——这也是我们把这项目坚持做下来的原因之一：它顺便成了全组的数据文化教具，这个角色是当初没想到的。搭贝上其他项目组来抄方案时，我们把这句经验放在了交接文档的头一条。

四、踩坑与经验

经验一：先对口径再写代码。前文说了，补充实施建议：口径对齐会要拉上每个数据源的责任人，一条条过定义，形成的口径文档跟着代码一起进版本库——口径也是资产，会漂移，要有人管——我们的口径文档现在由项目助理兼任管理员，谁想改口径提申请、周会过一遍，仪式感不重，但足够让口径不被随手改坏。

经验二：自动化边界宁小勿大。第五块（风险与计划）我们动过自动化的念头（让模型根据数据编两句），试了一版就放弃了：编出来的风险提示全是正确的废话（建议关注缺陷超期情况——谁不知道呢）。真正的风险判断来自组长脑子里的上下文，机器够不着。砍掉自动化、保留人工，周报的这部分反而成了每周最有价值的段落。

经验三：留档数据要带快照。系统里的数据会变（任务后补录、缺陷状态回改），只有每周定格的快照才是当时的真相。我们的快照策略：原始数据加生成的周报一起存——三个月后回头看，快照的价值远超预期——季度复盘、年度总结、审计抽查，三次场景里它都立了功，一次都没让我们回头翻过系统。

常见问题

问：小项目组没有三个系统，只有一个表格，值得做吗？

答：数据源少更应该做，而且更简单：单一数据源的汇编连中间格式都能省了，云函数拉表格数据渲染模板，一个下午能写完。判断值不做的标准不是系统多少，是频率：每周都要干一次的汇编活，就值得自动化一次。我们隔壁小组就一个共享表格，也照这个思路做了个简版——省的时间不多（半小时），但数字再也没有抄错过，准确性的价值经常被低估。

问：模型摘要那一段，怎么保证不出错？

答：三重保险：提示词约束（只摘要数据、不推断、不建议）；摘要生成后做数字回检（摘要里出现的数字必须能在中间数据里找到，找不到就重新生成——这个校验代码十行，把数字幻觉基本清零）；摘要挂在周报开头，全组都盯着，真错了周一就会被指出来。三个多月里回检拦下过两三次数字张冠李戴——拦下来就是零事故，这十行代码是整个方案里性价比最高的部分。

问：数据接口经常变怎么办？

答：采集层隔离设计（前面说了）加两个运维动作：接口调用全带监控告警（拉数失败自动通知，周一八点半前修复，周报照发——三个多月断过零期）；中间格式加版本号（接口变了只动采集层和格式转换，汇编层无感）。还有个土办法很有效：跟三个系统的管理员搞好关系，接口要升级提前打个招呼——自动化的稳定性，一半靠代码，一半靠人际关系，这是实话。

问：周报自动化了，会不会没人看周报了？

答：恰恰相反——我们的阅读反馈变好了。原因想通了很简单：以前周报数字常滞后有错，大家扫一眼存档了事；现在数字准、口径清、周一准时出，周报成了全组对齐事实的锚点，例会直接拿它过风险。真正让周报没人看的从来不是自动化，是内容不值看——自动化把数据部分做实了，人写的风险部分反而是每周被讨论最多的段落。工具把机械的部分做好，人的部分才被认真对待。