项目问题跟踪表提示词（RAID 日志：问题、假设、依赖逐条登记，含分级升级规则与升级说明）
项目例会后整理待跟进事项时用：把会议纪要和群聊里的零散事项分拣成问题、假设、依赖三类逐条登记（风险只引用风险登记册的编号），给每条定唯一负责人和日期，并按规则找出本周需要升级的条目、起草升级说明。
通用大模型 对话模型通用
【角色】你是项目管理办公室的专员，负责维护项目的 RAID 日志。本次重点是问题、假设、依赖三类；风险已有单独的风险登记册，这里只引用编号和一句话摘要，不重复评估。 【输入】 - 项目简述与当前阶段：[项目与阶段] - 本周的会议纪要、群聊要点或口头事项：[本周事项原文] - 风险登记册中已有的编号与标题：[已有风险编号] - 升级路径（项目经理之上依次是谁）：[升级路径] 【任务】 1. 分拣。把原文里的每件事归入四类之一： - 已经发生、正在影响项目的，是问题； - 还没发生、可能发生的，是风险（只登记编号与摘要；登记册里没有的，标「建议新增到风险登记册」）； - 我们当作成立、但没人确认过的，是假设； - 要等别人交付后我们才能继续的，是依赖。 同一件事可以拆成两条，例如「供应商说下周给接口文档」既是依赖，也隐含「文档内容完整」这个假设。 2. 问题表：编号、描述（现象 + 影响哪个交付物或里程碑）、严重程度、唯一负责人、下一步动作与日期、状态（新建 / 处理中 / 待验证 / 关闭）、已持续天数。 3. 假设表：编号、假设内容、若不成立的后果、由谁验证、验证截止日、结果（未验证 / 已证实 / 已推翻）。已推翻的假设要转成问题或风险。 4. 依赖表：编号、需要什么、提供方及对接人、我方最晚需要日期、对方承诺日期、状态、影响的任务。对方承诺日期晚于我方需要日期的，直接转为问题。 5. 升级规则（默认值，可调整）：阻塞关键里程碑的问题，2 个工作日无进展升级一级；一般问题 5 个工作日无进展升级一级；假设到验证截止日仍未验证、依赖到承诺日期未交付，次日升级。 6. 列出本周需要升级的条目，各起草一段不超过 80 字的升级说明：升级给谁、现状、希望对方做什么决定。 【约束】 - 只登记原文中有依据的事项；负责人或日期不明确的写【待指定】。 - 每条只有一个负责人。 【输出格式】问题表 → 假设表 → 依赖表 → 风险引用表 → 本周升级清单与升级说明。
高亮处换成你自己的内容：[项目与阶段]、[本周事项原文]、[已有风险编号]、[升级路径]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[本周事项原文] 直接贴会议纪要和群聊摘录，不用先分类，分拣交给模型。[已有风险编号] 贴风险登记册的编号和标题，避免同一件事登记两遍。[升级路径] 写成「项目经理 → 部门总监 → 项目指导委员会」。
常见失败与调整：
- 把问题和风险混在一张表里。风险是「可能发生」，要做的是预防；问题是「已经发生」，要做的是解决和升级，混在一起两头都管不好。
- 假设没人管。「客户会按时提供数据」写进计划后就被当成事实，直到出事。每条假设都要有验证人和截止日。
- 问题挂了三周还是「处理中」。看「已持续天数」，到了时限就升级，升级不是告状，是让有权决定的人知道。
示例输出
示例，仅供参考（虚构：某医疗器械经销商的订单系统项目，实施阶段）
问题表
| 编号 | 描述 | 严重程度 | 负责人 | 下一步与日期 | 状态 | 已持续 |
|---|---|---|---|---|---|---|
| I-07 | 测试环境无法连接财务系统，影响 11 月 20 日的联调里程碑 | 高（阻塞里程碑） | 信息部鲁工 | 11 月 13 日前开通网络策略 | 处理中 | 3 个工作日 |
假设表
| 编号 | 假设内容 | 若不成立 | 验证人 | 截止日 | 结果 |
|---|---|---|---|---|---|
| A-03 | 财务系统供应商提供的接口文档内容完整 | 联调延后约 5 个工作日 | 开发组长韦工 | 11 月 13 日 | 未验证 |
依赖表
| 编号 | 需要什么 | 提供方 | 我方需要日 | 对方承诺日 | 状态 |
|---|---|---|---|---|---|
| D-05 | 财务系统接口文档 | 财务系统供应商 昌经理 | 11 月 12 日 | 11 月 17 日 | 晚于需要日，已转为问题 I-08 |
升级说明（I-07）：致信息部总监：测试环境连不上财务系统已 3 个工作日，影响 11 月 20 日联调。请您在明天前确认能否优先开通网络策略。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～