项目变更申请提示词（需求变更影响评估：范围、工期、成本、风险，附选项对比与审批意见稿）
客户或业务方提出改需求、加功能时用：先判断是不是真的变更，再从范围、工期、成本、质量、风险逐项评估影响，给出接受、缩减、推迟、拒绝几种选项的代价，生成可以提交变更控制委员会的申请单和审批意见稿。
通用大模型 对话模型通用
【角色】你是变更控制委员会（CCB）的秘书，负责在开会前把每一份变更申请评估清楚。你不替委员会做决定，但要让他们五分钟内能做决定。 【输入】 - 变更内容（提出人的原话）：[变更内容] - 提出人与理由：[提出人与理由] - 已批准的基线（范围、工期、预算）：[当前基线] - 项目目前进展：[当前进展] - 合同中关于变更的约定：[合同变更约定] 【任务】 1. 定性：对照基线判断，这是「新增或修改需求」「原范围内的澄清」还是「缺陷修复」。写出判断依据的原文；依据不足就写【需核对范围说明书】。 2. 影响评估，逐项写「有 / 无 / 待估算」并说明： - 范围：新增、修改、作废哪些交付物； - 工期：涉及的任务是否在关键路径上，预计影响几个工作日； - 成本：人天、采购、外包各增加多少； - 质量与测试：需要重测的范围； - 风险：引入哪些新风险，对已有风险有什么影响； - 资源：是否占用其他项目共享的人员。 3. 不做的代价：如果拒绝这项变更，业务上会损失什么。 4. 给出 3–4 个处理选项：全部接受、接受缩减版、推迟到下一期、拒绝，每项写清代价和适用前提。 5. 起草审批意见稿：推荐选项、理由、批准后的生效条件（如追加预算到位、客户书面确认延期）。 6. 若获批，列出需要同步更新的文件。 【约束】 - 工期和成本只按我给的数据推算，写出算式；没有数据的写【需估算：由谁估】，不要给一个看似精确的数字。 - 「先做着、手续后补」不作为选项。 【输出格式】变更申请单（编号、日期、提出人、内容摘要、定性）→ 影响评估表 → 选项对比表 → 审批意见稿 → 待更新文件清单。
高亮处换成你自己的内容：[变更内容]、[提出人与理由]、[当前基线]、[当前进展]、[合同变更约定]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[变更内容] 尽量贴提出人的原话，转述容易把范围说小。[当前基线] 写清已批准的范围要点、完工日期和预算。[当前进展] 要包括「这块功能做到哪一步了」，已经开发完再改和还没动手再改，代价差很多。
常见失败与调整：
- 没定性就直接估工作量。很多争执其实是「这本来就该包含」，先让模型把判断依据的原文摆出来。
- 只评估开发工作量，漏掉重测、文档、培训材料的改动。追问一句「受影响的测试用例和培训材料有哪些」。
- 影响写成「略有影响」。要求它写成天数和人天，算不出来就标明由谁去估。
示例输出
示例，仅供参考（虚构：某物业公司报修小程序项目，客户要求增加「业主评价后可追加评论」）
定性：新增需求。依据：范围说明书第 3 条写明「业主可对已完成工单评分并填写一次评价」，未包含追加评论。
| 维度 | 影响 | 说明 |
|---|---|---|
| 范围 | 有 | 新增追评入口、后台追评查看；修改评价详情页 |
| 工期 | 有 | 评价模块在关键路径上，开发 3 天 + 测试 2 天，预计顺延 5 个工作日 |
| 成本 | 有 | 5 人天 × 1500 元 = 7500 元 |
| 质量与测试 | 有 | 评价模块 18 条用例需重测 |
| 风险 | 有 | 追评内容需审核，后台无审核功能，存在不当内容风险 |
| 选项 | 代价 | 适用前提 |
|---|---|---|
| A 全部接受 | 顺延 5 个工作日，增加 7500 元 | 客户书面确认延期与费用 |
| B 推迟到二期 | 本期无影响 | 客户接受上线时暂无追评 |
| C 拒绝 | 客户满意度受影响 | 不建议 |
审批意见稿：建议采用 B。上线日期已对外公布，追评不影响主流程；二期一并补上审核功能。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～