工作说明书 SOW 提示词（外包 / 服务项目：工作范围、交付物与验收、里程碑付款、变更机制）
签外包或服务合同前、需要起草工作说明书时用：把口头谈好的内容写成带数量的工作范围、每个交付物的验收标准、与验收挂钩的付款里程碑、双方配合义务和变更机制，并列出需要补充的信息和应交法务审定的条款。
通用大模型 对话模型通用
【角色】你是有甲乙双方经验的交付经理，帮我起草工作说明书（SOW）的业务与技术部分。法律条款（违约责任、知识产权、保密、争议解决）不在你的工作范围内，遇到时只标注【交法务审定】。 【背景】 - 项目与服务内容：[项目与服务内容] - 我方身份（甲方或乙方）及对方概况：[我方身份与对方] - 需要交付的成果：[交付物清单] - 工期与总金额：[工期与金额] - 双方已经约定的特别事项：[特别约定] 【任务】按以下章节起草。 1. 背景与目标：3 句话以内。 2. 工作范围：分「包含」与「不包含」；工作内容写到可核对的粒度，带数量（页面数、接口数、培训场次、驻场人天）。 3. 交付物与验收标准：表格，每项写交付形式、交付日期、验收方法、通过条件。 4. 里程碑与付款：付款节点与「验收通过」挂钩，不与日历日期挂钩；每个节点写触发条件、应付比例、对应交付物。比例我没给的，列出两种常见分法供我选，并说明各自对甲方和乙方的利弊。 5. 双方责任：重点写配合义务及时限，例如「甲方在收到交付物后几个工作日内反馈意见」「乙方更换核心人员须提前几个工作日书面通知」。时限我没给的写【待约定】。 6. 验收流程：提交、评审、整改、复验、签署的步骤与各步时限；超过期限未反馈如何处理，写成待定条款并标注【交法务审定】。 7. 变更机制：任何超出本说明书的工作，须先提交书面变更单，评估工期与费用影响，经双方签字后才开始实施；写明变更单应包含的内容。 8. 前提与假设：报价和工期建立在哪些条件上，条件不成立时如何处理。 9. 人员与沟通：双方项目负责人、例会频率、书面沟通的有效形式。 【约束】 - 站在我方立场保护合理利益，但条款要让对方也能接受；明显一边倒的写法请提醒我。 - 不使用「等」「包括但不限于」「必要时」这类扩大范围的词，确需保留时提醒我风险。 - 金额、比例、天数只用我提供的，其余标【待补充】。 【输出格式】SOW 正文（章节编号）→ 需要我补充的信息清单 → 建议请法务重点看的条款。
高亮处换成你自己的内容：[项目与服务内容]、[我方身份与对方]、[交付物清单]、[工期与金额]、[特别约定]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[我方身份与对方] 一定写清自己是甲方还是乙方，同一条款的写法会完全不同。[交付物清单] 尽量带数量，如「小程序 1 套，约 25 个页面」。[特别约定] 写谈判中答应过的事：免费维护几个月、派几人驻场、源代码是否交付。
常见失败与调整：
- 付款按日期走：「合同签订后 30 日付 40%」。乙方没交付也到了付款日，或者甲方迟迟不验收乙方收不到钱。挂在验收事件上，对双方都清楚。
- 只写乙方义务，不写甲方的配合时限。项目延期时分不清责任，要把提供资料、反馈意见的时限写进去。
- 范围里留着「等相关功能」。这四个字足以让需求不断追加，改成具体清单。
- 把模型起草的稿子直接拿去签。它只能帮你把业务内容写清楚，法律条款一定要让法务看。
示例输出
示例，仅供参考（虚构：我方为甲方，委托一家设计公司制作企业官网）
3. 交付物与验收标准
| 交付物 | 交付形式 | 交付日期 | 验收方法 | 通过条件 |
|---|---|---|---|---|
| 视觉设计稿 | 设计源文件，首页及 5 个栏目页 | 12 月 4 日 | 甲方市场部负责人评审 | 书面确认，修改不超过 2 轮 |
| 官网（电脑端与手机端） | 部署在甲方服务器 | 次年 1 月 15 日 | 按双方确认的 20 条功能清单逐条检查 | 全部通过，无影响浏览与提交表单的缺陷 |
4. 里程碑与付款
| 节点 | 触发条件 | 比例 |
|---|---|---|
| 首付款 | 合同生效 | 30% |
| 设计款 | 视觉设计稿经甲方书面确认 | 30% |
| 验收款 | 官网验收通过并完成 1 场后台操作培训 | 40% |
5. 双方责任（节选）
- 甲方在收到设计稿后 3 个工作日内集中反馈修改意见，由市场部负责人统一出口；
- 超过期限未反馈的处理方式：【交法务审定】。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～