设计日报/周报自动生成流水线：多数据源到成稿

定时任务每天拉取各个数据源的数据，做清洗和归一化，按人和项目聚合，然后把聚合结果喂给模型，用固定的模板 prompt 生成结构化的日报，最后推送到群里或邮件。可以让用户配置模板和关注的项目。

流程完整，及格。但它默认了「把数据给模型，模型自然会写好」——事实上这一步生成出来的东西读起来会像流水账，因为筛选逻辑没有设计，模型只能对着一堆同等重要的事件平铺直叙。

① 先问四个问题：这份报告给谁看——写给自己留档、给主管看、还是给跨部门同步？三者要的内容完全不同。读者最想知道什么——进度、风险、还是需要他决策的事项？数据源有哪些、各自的可靠性如何？以及一个很实际的问题：现在没有这套系统时，人是怎么写的、花多久——这就是基线。

② 基线：一个不含模型的版本。 定时拉数、按人和项目聚合、按固定模板填空、推送。这套东西已经能解决「忘了写」和「格式不统一」两个问题，而这往往是需求的一大半。先摆出来，是为了让后面「加模型」这件事必须自证价值——如果加了模型只是把结构化列表改写成句子，那就是负收益。

③ 加挂，每样说代价：

• 多源对齐（这是最重的脏活，也是最容易被低估的）。三件事：身份对齐（同一个人在代码平台、任务系统、日历里三个 ID，要有一张映射表，且要处理离职与改名）；事件去重（一次改动在代码平台有提交、在任务系统有状态流转、在群里有一条消息，是同一件事，要合并）；时间对齐（时区、跨天边界、以及「昨天下班后提交的算哪天」）。代价：这层没有任何智能可言，就是持续维护的规则；但它决定了上限——对齐做不好，后面模型再强也是垃圾进垃圾出。
• 筛选层（本题的真正难点）。把两百条事件压到五条，筛选规则要显式而不是交给模型：优先级来自「是否阻塞他人」「是否偏离计划」「是否是首次出现的风险」「是否需要读者做决定」。代价：规则要按团队调；为什么不交给模型——模型缺少「读者关心什么」这个外部信息，它只能按文本显著性排序，而文本显著性和业务重要性经常相反。
• 生成层：模型只负责把已经选好的事实写成人话，并且严格约束不得引入未在输入中出现的内容。代价：文风受限；收益：可控、可审计。这里的一个关键设计是**「无内容就不写」**——某个板块没有值得说的事，就应该空着或省略，而不是硬凑一段。
• 批处理：这类任务对延迟不敏感，天然适合走批处理接口，价格通常是标准价的一半左右。代价：结果不是实时的；这个场景恰好完全不在意。这是这道题里性价比最高的一条。
• 隐私边界：明确列出可进与不可进的数据源与字段；私聊、他人未公开的任务、人事相关一律不进。代价：覆盖面变小；必须付——内部工具的一次越界，足以让整个项目下线。

④ 评测：这类系统没有标准答案，评测要换思路：

• 对照评测：让人写一份、系统写一份，双盲让读者选哪份更有用——比任何自动指标都直接。
• 零成本信号优先：打开率、阅读完成率、以及「被引用到其他场合」的次数（有人把它复制到别的文档里，说明真有用）；反向信号是编辑率——收到后被大幅改写的比例。
• 负向断言：不得出现输入中不存在的事实、不得出现被标记为不可进的数据源内容、不得出现具体人员的负面评价。这一层是发布闸门。
• 不要花力气去做「文本质量打分」，那个分数和有没有人看几乎无关。

⑤ 演进：出现「读者反复问同一个补充问题」→ 把那个字段加进模板，而不是让模型自由发挥；出现「多个团队想要不同视角」→ 从一份报告变成同一份事实的多个视图；出现「筛选规则越来越复杂且频繁变」→ 才考虑用模型做筛选，并且必须先有对照数据。退路：如果打开率长期低迷，砍掉生成层退回结构化列表——没人看的漂亮文字不如有人扫一眼的清单。