项目经理怎么用 AI：写项目计划书、拆 WBS 排进度、做风险登记册、写周会纪要和向上汇报、项目复盘的国产模型分工（8 个提示词模板）
项目经理的日常和产品经理不一样：产品经理定「做什么」，项目经理管「什么时候、谁、多少钱做完，出了问题谁兜」。这个岗位的文书量大得惊人——启动阶段的项目章程和计划书、拆到每个人头上的 WBS 和甘特图、每周更新的风险登记册和状态报告、每次会议的纪要和待办、结项时的复盘报告。而且这些东西的难点从来不是「写出来」，是「写出来之后有人真按它干」：计划拆得不够细就是空话，风险写成「可能延期」就等于没写，汇报写成流水账老板看两行就关掉。
AI 在这里最值钱的是把「大目标」逼成「小任务」、把「担心」逼成「能打分的条目」。 从交付目标反推里程碑、拆 WBS、找关键路径、拆风险，用 DeepSeek R1（它会一层层追问「这个活的前置是什么、谁做、多久」，不让你停在「开发阶段 6 周」这种颗粒度，见 DeepSeek R1 推理实战）；读全部需求文档、合同、历史项目的复盘、一个季度的周报找出反复出现的问题，用 Kimi K3（一次能读几十万字，见 Kimi K3 读长文档）；写计划书、纪要、汇报邮件，用 DeepSeek；把技术进展翻译成老板和客户听得懂的话，用 通义千问；进度表和风险表要转成 Excel 公式的，用 GLM-5.1（见 Excel 数据分析）。全部在不墨 AI 助手一个页面切换，Word / PDF / Excel 直接上传。
一个项目从启动到结项的分工
| 阶段 | 模型 | 做什么 |
|---|---|---|
| ① 启动 | Kimi K3 + R1 | 读需求、合同、类似项目资料，写项目章程：范围、目标、边界、干系人 |
| ② 拆解 | DeepSeek R1 | 从交付物反推 WBS，拆到「一个人 2-5 天能做完」的颗粒度 |
| ③ 排期 | DeepSeek R1 | 依赖关系、关键路径、缓冲放哪、哪几个活最容易延 |
| ④ 风险 | DeepSeek R1 | 风险登记册：每条风险可打分、有触发信号、有负责人和应对 |
| ⑤ 周会 | DeepSeek | 会议纪要：决策 / 待办 / 阻塞三段，待办到人到日期 |
| ⑥ 汇报 | 通义千问 | 给老板和客户的状态报告：红黄绿 + 需要他们做的决定 |
| ⑦ 变更 | DeepSeek R1 | 需求变更影响评估：范围 / 时间 / 成本 / 风险四个维度 |
| ⑧ 复盘 | Kimi K3 + R1 | 读全周期的周报和纪要，找反复出现的问题，写不归责到人的复盘 |
8 个提示词模板
1. 项目章程 · Kimi K3 → DeepSeek R1
（上传：需求文档 / 合同或 SOW / 立项材料 / 类似项目的历史资料）
项目一句话：【给谁做什么，什么时候交】
已知约束：【预算、截止日期、人力、必须用的技术或供应商】
请先通读全部材料，然后：
1. 写清项目目标：可验收的交付物列表，每项写「交付什么 + 怎么算完成（验收标准）」，不接受「完成系统开发」这种写法
2. 划边界：明确「不做什么」——从材料里找出客户或业务方可能默认在范围内、但材料没写的事，列出来让我去确认
3. 干系人清单：谁出钱、谁验收、谁用、谁会被影响、谁能一句话叫停项目；每个人最关心什么、最怕什么
4. 材料之间的矛盾和缺口：合同写的和需求文档写的不一致的地方、需求里提到但没有细节的功能、没有写验收标准的交付物
5. 成功标准：项目结束时，用什么 3 个数字判断它成功了
6. 一句话说清这个项目最大的不确定性是什么
输出为项目章程格式，所有需要我去确认的地方标【待确认】。
2. 拆 WBS · DeepSeek R1
交付物清单（模板 1 结果）：【粘贴】
团队：【角色 × 人数，每人可投入比例】
请把每个交付物往下拆：
1. 拆到「一个人 2-5 天能做完、做完有明确产出物」的颗粒度——拆到这层之前不要停。「开发阶段 6 周」不合格；「用户模块-登录接口-开发 2 天-产出：接口可调通 + 单测」合格
2. 每个工作包写：产出物 / 前置依赖（哪个工作包做完才能开始）/ 建议角色 / 工时估算（乐观 / 最可能 / 悲观三个数）
3. 找出隐藏的活：每个交付物背后没人提但必须做的——环境搭建、数据迁移、第三方对接的联调、验收前的文档、培训、上线值守
4. 按角色汇总总工时，和团队可投入的人天对比，指出哪个角色明显超载
5. 标出估算最不可信的 5 个工作包（悲观和乐观差距最大的），这些是排期时要放缓冲的地方
输出 WBS 编号（1 / 1.1 / 1.1.1）的层级表格，我要能直接贴进项目管理工具。
3. 排期与关键路径 · DeepSeek R1
WBS（模板 2 结果）：【粘贴，含依赖和工时】
起止日期：【】 节假日和已知不可用日期：【】
资源约束：【比如 只有 1 个测试，第 3-4 周架构师休假】
请：
1. 按依赖关系排出进度：每个工作包的最早开始 / 最早结束，用最可能工时
2. 找出关键路径：哪一串工作包任何一个延一天、整个项目就延一天；列出这串上的每个活
3. 缓冲怎么放：不要每个活都加 20%，把缓冲集中放在关键路径上估算最不可信的活后面（模板 2 标出的那 5 个），说明每处放几天
4. 资源冲突：同一个人同一时间被排了两个活的地方，怎么调
5. 里程碑：设 4-6 个可对外汇报的里程碑，每个写「日期 + 到这天应该能演示什么」——不是「开发完成」，是「客户能看到什么」
6. 如果截止日期比排出来的早：给三个选项——砍范围（砍哪些）、加人（加哪个角色、加多少、能省几天、有没有边际递减）、并行（哪些活可以拆开并行、代价是什么）
输出甘特图能用的表格：任务 / 开始 / 结束 / 前置 / 负责角色 / 是否关键路径。
4. 风险登记册 · DeepSeek R1
项目章程和 WBS：【粘贴或沿用上下文】
我已经想到的风险：【随手列，写得多粗都行】
请：
1. 把我列的每条风险改写成可打分的格式：「因为【原因】，可能发生【事件】，导致【对目标的影响：延多久 / 超多少钱 / 哪个交付物受影响】」——「可能延期」不合格，「因为第三方接口文档尚未提供，联调可能推迟 1-2 周，导致里程碑 3 延后」合格
2. 补我没想到的：从 WBS 里找——依赖外部的活、只有一个人会做的活、估算最不可信的活、验收标准模糊的交付物，每一个都对应一条风险
3. 每条打分：发生概率（高 / 中 / 低）× 影响（高 / 中 / 低），并说明打分依据
4. 每条写：触发信号（什么现象出现说明它要发生了）/ 预防措施（现在做什么降低概率）/ 应急措施（发生了怎么办）/ 负责人角色 / 下次复查日期
5. 排出 Top 5，说明为什么是这五个
输出为风险登记册表格。每周我会拿这张表更新，所以格式要能直接复用。
5. 周会纪要 · DeepSeek
会议：【项目周会 / 里程碑评审 / 变更评审】 日期：【】 参会：【角色】
会议记录：【粘贴录音转写或我的速记，可以很乱】
上周待办：【粘贴，方便对照哪些完成了】
请整理成纪要，固定三段：
1. 决策：这次会上定了什么。每条一句话，写清「决定了什么 + 谁定的 + 依据」。讨论过但没定的不放这里
2. 待办：格式固定「事项 / 负责人 / 截止日期 / 验收标准」四项缺一不可，缺哪项就标【会上未明确】让我去补。上周待办的完成情况在这段开头列一行
3. 阻塞与风险：谁被什么卡住、需要谁来解、已经卡了几天；新出现的风险一句话，我会转进风险登记册
然后单独列：
4. 会上说了但没人认领的事——这些最容易漏
5. 需要向上升级的事项（团队内解决不了的）
不要写「大家积极讨论」「氛围良好」，不要按发言顺序流水账。控制在一页内。
6. 状态汇报 · 通义千问
汇报对象：【老板 / 客户 / 管理层例会】 他最关心：【进度 / 预算 / 质量 / 某个具体功能】
本周原始信息：【模板 5 纪要 + 进度表 + 风险表，粘贴】
上周汇报的状态：【红 / 黄 / 绿，上周说的问题】
请写状态报告：
1. 第一行：整体状态（绿 / 黄 / 红）+ 一句话为什么。状态从上周变了要说明变化原因
2. 本周完成：3-5 条，每条是「客户或老板能感知的结果」，不是「开发了 3 个接口」，是「用户可以完成注册登录了」
3. 下周计划：3 条，对应里程碑
4. 问题与风险：只写需要对方知道的，每条带「我们正在怎么处理」——不要只抛问题
5. 需要你决定的事：最多 2 条，每条给清楚选项 A / B 和我的建议——这是整份报告最重要的部分，放最后但要醒目
6. 关键数字：进度 %、预算消耗 %、里程碑偏差天数
全文不出现技术术语（「接口」「部署」「重构」翻译成对方听得懂的话），不超过一屏，红黄绿之外不用任何形容词。
7. 变更影响评估 · DeepSeek R1
变更请求：【谁提的，要改什么，为什么】
当前基线：【WBS + 进度表 + 风险表 + 预算，粘贴或沿用上下文】
请评估：
1. 范围：这个变更实际动到哪些工作包？包括看起来无关但有依赖的（改一个字段可能牵动接口、报表、测试用例、文档）
2. 时间：受影响的工作包工时增加多少，是否在关键路径上，里程碑各延几天；如果不想延，要牺牲什么
3. 成本：新增人天 × 单价，第三方费用变化
4. 风险：引入什么新风险，放大了登记册里的哪条
5. 不做的后果：如果拒绝这个变更，业务上会怎样——这一条要客观写，不要为了保进度就说不做没事
6. 给决策者三个选项：全做 / 部分做（做哪部分，剩下放二期）/ 不做，每个选项一行「时间 + 成本 + 风险」
输出为变更评估单格式，我拿去走评审流程。变更提出方的原始诉求原话保留，不要改写。
8. 项目复盘 · Kimi K3 → DeepSeek R1
（上传：项目全周期的周会纪要、状态报告、风险登记册各版本、变更记录、最初的项目章程和计划）
项目结果：【按时 / 延期 X 天，预算 ±X%，验收情况，客户反馈】
请（K3 先读全部材料，R1 分析）：
1. 计划 vs 实际：最初的里程碑日期和实际日期对照，偏差最大的三个在哪、从哪一周开始偏的
2. 反复出现的问题：翻全部纪要，同一个阻塞或风险出现了 3 次以上的有哪些，每次是怎么「解决」的、为什么又回来了
3. 风险登记册的表现：哪些预测到的风险真发生了、哪些发生了但没预测到、哪些预测了从没发生（说明打分偏高）
4. 变更：一共几次，总共吃掉了多少时间，哪次变更是应该拒的
5. 归因到机制不归因到人：每个问题写「什么流程 / 规则 / 信息缺失导致了它」，不写「某某没做好」——同样的人在更好的机制下会做得更好
6. 下个项目要改的 3 件事：具体到「启动阶段增加 X 检查项」「周会加一个 Y 环节」这种可执行的动作，不要「加强沟通」
最后写一段给管理层的 5 句话总结。
5 条防「计划写完就没人看」的规则
- WBS 拆不到 2-5 天颗粒度就不算拆完。 模板 2 之所以逼着拆到这层，是因为「开发阶段 6 周」这种颗粒度没法跟踪：第 3 周你问「进度多少」，没人答得出。拆到 2-5 天，每周会上每个活只有「完成 / 没完成」两种状态，不需要估百分比。
- 风险必须有触发信号，否则等于没写。 「可能延期」谁都知道。模板 4 要求每条风险写「什么现象出现说明它要发生了」——比如「第三方接口文档到第 2 周周三还没收到」——这样风险登记册才能真的在周会上被复查，而不是立项时写一次就压箱底。
- 待办没有负责人和截止日期，不许写进纪要。 模板 5 把四项写死。「大家关注一下」「后续跟进」这种待办下周一定还在。会上没明确的，纪要里标出来，会后当天去问清楚。
- 向上汇报的核心是「需要你做的决定」，不是「我们做了什么」。 老板和客户看状态报告是要知道「要不要我介入」。模板 6 把决策项放最后但要求醒目，就是这个道理。没有需要他决定的事，也要写一句「本周无需决策」，让他放心关掉。
- 复盘归因到机制，不归因到人。 模板 8 明确要求。归因到人的复盘会变成甩锅会，下次没人敢说真话；归因到机制才能改出下个项目真能用的检查项。
常见问题
AI 拆的 WBS 和实际情况不符怎么办？ 一定会不符，它不了解你团队的实际速度。模板 2 的价值是「穷尽」——把你可能漏的活（环境、迁移、联调、文档、培训）都列出来，工时你自己按团队经验改。漏掉一个活比工时估偏危险得多。
风险登记册每周更新太费时间。 模板 4 的输出格式是固定的，每周把纪要贴给它、让它按「新增 / 变化 / 关闭」三类更新登记册，几分钟的事。真正费时间的是第一次写，之后是增量。
给客户的汇报和给老板的汇报能用一份吗？ 模板 6 的结构一样，但「他最关心」和「需要你决定的事」不同。客户关心交付和验收，老板关心预算和资源。分别跑一次，输入不同，各得一份。
项目管理工具（Jira / 飞书项目 / Project）有了，还需要 AI 吗？ 工具负责「记」，AI 负责「想」：拆解、找依赖、找漏、评估变更、复盘找规律。模板 2、3 的输出都是能直接导入工具的表格格式。
要花钱吗？ 登录送免费额度，拆一个中型项目的 WBS、写一周的纪要和汇报够用。同时管几个项目、每周读全部纪要做复盘、反复做变更评估的看会员方案。
一句话总结
项目经理用 AI 的核心是「把大话逼成小事」：项目章程让 Kimi K3 读完全部需求和合同后列出交付物、边界和干系人，DeepSeek R1 把交付物拆到「一人 2-5 天」的 WBS、排出关键路径并把缓冲集中在最不可信的活后面、把每条风险改写成「原因 → 事件 → 影响」并加上触发信号；周会纪要用 DeepSeek 固定成「决策 / 待办（到人到日期）/ 阻塞」三段；给老板和客户的状态报告交给通义千问，红黄绿开头、需要他做的决定收尾；结项时 K3 读全周期纪要找反复出现的问题，R1 归因到机制而不是人。工时和结论你来定，AI 负责让你不漏。