项目管理智能体：周报、纪要、风险跟踪交给它，决定留给你

系列第五篇。选型见 智能体不只是聊天，派活顺序与验收清单见 派活与验收。前两篇深写的是研发和测试，这一篇换到项目经理的视角。

问一个项目经理一周的时间去哪了，答案通常是三块：

1. 收集信息：翻工单、翻群聊、问进度、看日历。
2. 对齐口径：同一件事，对研发说一套，对业务说一套，对老板再说一套。
3. 写东西：周报、纪要、风险清单、复盘、延期说明。

真正需要项目经理判断的事，比如排期怎么调、资源给谁、风险要不要上报，往往被挤到最后。

智能体在项目管理里最合适的位置是 信息员：把散落的信息收齐、整理、写成初稿。决策者 仍然是你。这一篇的所有场景都按这个分工来写。

---

项目管理里什么叫「验收」

研发的验收看测试和代码改动，项目管理的交付物是文档，验收看四件事：

第二条最容易出问题。智能体为了让文档「完整」，会自然地把模糊的说法补成确定的说法。「讨论过」和「已决定」之间的差别，必须由你来把关。

---

先解决数据：信息散在哪，怎么交给智能体

国内团队的项目信息通常散在这些地方：

两条建议：

1. 先用导出文件，不要一上来就接口直连。 每周五把四五个导出文件放进一个固定目录，比如 项目A/本周材料/，让智能体只读这个目录。这样你清楚它看到了什么、没看到什么。跑顺了再考虑用连接器自动拉取。
2. 敏感信息不要喂。 薪酬、绩效、人事变动、客户合同金额、未公开的融资信息，不要放进材料目录。公司对 AI 工具有使用规定的，先看规定，有的企业只允许用内部部署的模型。

---

场景一：周报

这是项目经理用智能体最常见、也最容易立刻见效的场景。

怎么派活

【模式】先只读材料，列出你看到的信息和缺失的信息；我确认后再写周报。

【材料】项目A/本周材料/ 下的文件：
- TAPD 导出的需求和缺陷清单（本周有状态变化的）
- 项目群 11月3日至7日的聊天记录导出
- 周二、周四两次例会的飞书妙记文字稿
- 里程碑计划.xlsx

【目标】写 项目A/周报/2026-W45.md，结构：
1. 本周完成（每条对应需求或缺陷编号）
2. 进行中及预计完成时间（只写有明确依据的时间，没有依据写「待确认」）
3. 风险与阻塞（按下面的红黄灯规则）
4. 下周计划
5. 需要上级支持的事项

【红黄灯规则】
- 红：影响里程碑日期，或阻塞超过 3 个工作日
- 黄：有延期可能但还有缓冲，或依赖外部团队未确认
- 绿：其余
不要自己发明其他规则。

【约束】
- 群聊里的情绪化表达、对个人的评价，不进周报
- 讨论过但没有结论的事项，写进「待决定」，不要写成已决定
- 不要发送到任何群或邮箱

怎么验收

• [ ] 「本周完成」随机抽 3 条，回到 TAPD 核对状态确实是已完成
• [ ] 所有日期都有依据；「待确认」的条目你逐个去问
• [ ] 红灯和黄灯的判断符合你定的规则，而不是模型自己的感觉
• [ ] 通读一遍，确认没有会让某个同事难堪的表述

第一次用的小技巧

第一周 自己先写一版，再让智能体写一版，对比差异。你会很快发现它漏了什么、多写了什么，然后把这些写进约束。一般两三周后，派活提示就稳定了，可以存成固定模板或 Skill 反复用。

---

场景二：会议纪要和行动项

飞书妙记、腾讯会议都能自动转写和生成摘要，但会议软件的摘要通常是「讨论了什么」，项目经理真正需要的是「决定了什么、谁去做、什么时候」。

怎么派活

【材料】项目A/会议/1105-需求评审-妙记.txt（会议转写文字）

【目标】整理成 项目A/会议/1105-需求评审-纪要.md，包含四部分：
1. 决议：会上明确达成一致的事项。每条注明是谁提出、谁确认的
2. 行动项：表格，列为「事项、负责人、截止日期、依据（转写里的原话或时间点）」
3. 待决定：讨论了但没有结论的事项，以及卡在哪里
4. 待确认：转写不清楚、或负责人和日期没有明说的地方

【规则】
- 负责人和截止日期只能来自会上的明确表述，不能推测。比如「这个后端看一下吧」，
  负责人写「后端（具体人待确认）」，不要自己指定某个人
- 转写有错别字和口误时，按上下文修正，但人名、数字、日期拿不准的放进「待确认」

怎么验收

• [ ] 「决议」里每一条，你都记得会上确实定了
• [ ] 行动项的「依据」一栏能在转写里找到原话
• [ ] 「待确认」那一栏会后 24 小时内在群里逐条问清

发出去之前多做一步：把行动项表发到群里时，@ 每个负责人请他们确认。智能体整理得再准，也只是记录；让负责人自己点头，才变成承诺。

---

场景三：风险与依赖跟踪

什么时候用

项目跨团队、依赖多的时候，风险往往不是某一天突然出现的，而是好几个小延迟累积的结果。人工每周对一遍计划和实际很累，正适合交给智能体。

怎么派活

【材料】
- 里程碑计划.xlsx（计划日期）
- 最近三周的周报（项目A/周报/ 下）
- 本周 TAPD 导出

【目标】输出 项目A/风险/2026-W45-风险跟踪.md：
1. 计划和实际的对比表：每个里程碑的计划日期、当前预计日期、偏差天数、依据
2. 连续两周以上出现的阻塞项（同一个问题反复出现，说明没有真正解决）
3. 对外部团队的依赖清单：依赖什么、对方是否确认过、确认的日期
4. 「如果……会怎样」：对偏差最大的两个里程碑，各列出一种最可能的延期情况，
   以及会连带影响哪些后续里程碑

【约束】只做分析，不给出调整排期的建议；排期怎么调由我决定。

怎么验收

• [ ] 偏差天数的计算抽查两条
• [ ] 「连续出现的阻塞项」是真的同一个问题，而不是两个相似的问题被合并了
• [ ] 外部依赖里标为「已确认」的，确实能找到对方确认的记录

约束里那句「不给出调整排期的建议」是刻意的。智能体给出的排期建议看起来往往很合理，但它不知道哪个同事下个月要休产假、哪个客户关系需要特别照顾。分析可以交出去，取舍留在手里。

---

场景四：同一件事，三种读者

项目经理经常要把同一份进展，写成给不同人看的版本。

怎么派活

【材料】项目A/周报/2026-W45.md（已经确认过的内部周报）

【目标】改写成三个版本，放在 项目A/周报/2026-W45-多版本/：

1. 研发团队版：保留需求编号和技术细节，突出下周的开发和测试安排
2. 业务方版：不出现需求编号和技术术语，说清楚「哪些功能什么时候能用」
   和「需要业务方配合什么」
3. 管理层版：不超过 5 句话。整体状态（红/黄/绿）、最大的一个风险、需要的决定或支持

【规则】
- 三个版本的事实必须完全一致，只改表达方式和详略
- 业务方版和管理层版不得出现：内部人员的分工争议、未确认的日期、内部系统地址

怎么验收

• [ ] 三个版本里的日期、数字、状态逐一对一遍，完全一致
• [ ] 管理层版「需要的决定」是你真正需要老板拍板的事，而不是为了凑格式写的
• [ ] 业务方版让一个不懂技术的同事读一遍，能看懂

这个场景的要点是 先有一份确认过的内部版本，再改写。不要直接从原始材料生成对外版本，否则事实核对要做三遍。

---

场景五：需求变更评估

什么时候用

项目进行到一半，业务方提出「再加一个小功能」。项目经理需要快速回答：这个变更在不在原定范围内？加进来影响什么？

怎么派活

【材料】
- 项目立项文档.md（原定目标和范围）
- 需求变更申请：客户希望增加「批量导出订单」功能（见 变更/1107-批量导出.md）
- 当前里程碑计划.xlsx

【目标】输出 变更/1107-批量导出-评估.md：
1. 范围判断：这个需求在立项文档的范围内、范围外，还是边界模糊？引用立项文档原文
2. 影响分析：可能涉及哪些模块、哪些已排期的工作、哪些里程碑
3. 需要研发确认的问题清单（工作量要由研发估，你不要估）
4. 三个选项的对比：本期加入、下期加入、不做。只列各自的影响，不要推荐

【约束】不要给出工作量估算和推荐结论。

怎么验收

• [ ] 范围判断引用的立项文档原文确实存在
• [ ] 问题清单拿去找研发，看是否问到了点子上

评估文档是你和业务方、研发谈判时的材料。结论，比如接还是不接、放在哪一期，要在谈判里由人定。

---

场景六：项目复盘

怎么派活

【材料】项目A/ 下的全部周报、会议纪要、风险跟踪，以及上线后的缺陷统计

【目标】输出 项目A/复盘/复盘材料.md，作为复盘会的讨论底稿：
1. 项目时间线：关键节点、计划日期、实际日期
2. 偏差最大的三个阶段，每个阶段当时周报和纪要里记录的原因
3. 反复出现的问题（比如同类阻塞多次出现、同类缺陷多次出现）
4. 留给复盘会讨论的问题清单

【规则】
- 只陈述事实和当时的记录，不评价任何个人
- 原因只引用文档里记录过的，不要推测
- 不要写「改进措施」，改进措施在复盘会上由大家讨论

怎么验收

• [ ] 时间线的关键日期抽查
• [ ] 通读一遍，确认没有任何一句话读起来像在指责某个人

复盘最怕变成追责会。让智能体只整理事实和当时的记录，反而能帮团队把讨论聚焦在「流程哪里出了问题」上。

---

定时运行：先人工触发，再定时

WorkBuddy 等桌面智能体支持定时任务，飞书、钉钉也可以通过机器人定时推送。周报这类每周固定的工作，很自然会想到让它定时自动跑。

建议分三步：

1. 前三四周人工触发：每次你都看得到它读了什么、写了什么，及时调整派活提示。
2. 定时生成，但只发给你自己：每周五下午自动生成初稿，放进你的目录或私聊发给你。
3. 你确认后再发群：发送这一步始终保留人工确认。

不建议做的是 定时生成后直接发到项目群或发给老板。只要有一次把错误日期或内部吐槽发出去，团队对这套流程的信任就很难恢复。

---

项目经理最常见的六种翻车

---

不该交给智能体的事

下面这些可以让智能体帮你准备材料，但决定和沟通必须由你来做：

• 排期承诺：对业务方、对客户说「几号上线」。
• 资源调配：谁去支援哪个项目、要不要加人。
• 绩效相关的评价：任何涉及个人表现的判断。
• 坏消息的沟通：延期、砍需求、预算超支，要由你当面或电话说，再用文档补充。
• 冲突调解：团队之间的分歧，智能体可以帮你把双方观点整理清楚，但调解本身是人和人之间的事。
• 风险是否上报：智能体可以标出红灯，但要不要上报、怎么上报、什么时候上报，需要结合你对组织的了解来判断。

---

一个完整例子：小周的一周

第一篇 里出现过的小周，做产品，兼管一个跨三个团队的项目。下面是她用智能体之后的一周（虚构但典型）。

小周算了一下，以前每周花在整理信息和写文档上大约一天半，现在大约半天，主要花在核对和修改上。

更重要的变化在周四。「支付联调」这个阻塞，在她以前的周报里每周都写一句「推进中」，因为每周看起来都只是小问题。是智能体把三周的记录放在一起，才让这个问题变得明显。发现问题可以靠智能体，解决问题还是要靠小周当天去约人谈。

---

延伸阅读

• 站内：智能体不只是聊天 · 派活与验收
• 站内：研发智能体 · 测试智能体
• 站内：WorkBuddy 别人都在干什么（含定时简报等办公场景）

---

后续计划：销售与售前、学习与资料整理等场景会陆续单独成篇。