📍 WDQWDWQD987AAAAA:216.73.217.13
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /882563912c8f.html
📄

网站外包阶段里程碑怎样约定：把验收、付款和改动边界写进每个节点

网站外包的阶段里程碑，本质上是把“做到什么程度算完成”变成可检查、可验收、可付款的节点。约定时不要只写“设计完成”“开发完成”，而要给每个节点配上可见交付物、验收标准、确认时限和未通过时的处理方式。对第一次外包的人来说，最稳妥的做法是先定阶段划分，再逐项确认每个阶段的产物和付款比例，最后写清延期与返工责任。

先按交付物划分阶段，而不是按时间划分

按“第1周、第2周”划分里程碑，很容易出现时间到了但东西不能用的情况。更可靠的方式是按可验收的交付物划分，常见结构如下：

• 需求确认阶段：交付需求说明、页面清单、功能清单，确认范围边界。
• 设计与原型阶段：交付首页及关键内页设计稿、交互原型，确认视觉方向和结构。
• 开发与联调阶段：交付可访问的测试环境，核心功能可实际点击操作。
• 内容与数据填充阶段：交付真实内容录入后的页面，检查排版和链接。
• 上线与交接阶段：交付正式站点、后台账号、源码或部署说明、操作文档。

阶段数量不宜过多，小型企业站通常四到五个节点即可；功能复杂的项目可以拆得更细，但每个节点都必须能拿出看得见、点得开的东西。

每个里程碑要写清四件事

只写阶段名称没有约束力。一个可执行的里程碑条目，至少包含以下四项：

1. 交付物：具体到文件、链接或环境，例如“测试环境地址”“设计稿源文件”“后台管理员账号”。
2. 验收标准：写成可判断的条件，例如“主流浏览器下首页无错位”“表单提交后能收到通知邮件”。
3. 确认时限：甲方在收到交付物后几个工作日内反馈，逾期未反馈如何处理。
4. 付款关联：该节点对应多少比例款项，验收通过后多少天内支付。

举例来说，假设合同约定“设计阶段验收通过后支付30%”，那么就要同时写明：设计稿包含哪些页面、修改几次以内不额外收费、超出部分如何计价。否则“修改到满意”会成为无限责任，双方都难受。

付款节奏与验收节奏要对应

常见的付款方式是预付款加阶段款加尾款。判断比例是否合理，可以看两个条件：

• 乙方风险：预付款能否覆盖前期需求梳理和设计投入，比例过低会导致对方拖延或中途放弃。
• 甲方风险：尾款是否留到上线并完成交接之后，比例过低则失去约束力。

具体比例没有统一标准，取决于项目规模和双方信任基础。关键是每一笔款项都能对应一个已验收的里程碑，而不是按日期自动支付。若某个阶段未通过验收，应约定整改后重新验收，而不是直接进入下一阶段付款。

改动边界和延期责任要提前写明

项目延期和反复修改，多数源于边界不清。约定里程碑时，建议同时写明：

• 每个阶段包含的修改轮次，以及超出轮次的计费方式。
• 需求变更的处理流程：提出、评估工期与费用、双方书面确认后再执行。
• 因甲方提供资料延迟导致的顺延，与因乙方原因导致的延期，责任区分开。
• 验收不通过时的整改期限，以及多次不通过后的处理方式。

这些内容不需要写得像法律文书，但要在合同或附件中留下文字记录。口头承诺在出现分歧时很难作为依据。

第一次外包可以按这个顺序推进

1. 先列出自己必须要的功能和页面，形成一份需求清单。
2. 要求对方按交付物给出阶段划分和每阶段付款比例。
3. 逐条检查每个里程碑是否有可见产物和可判断的验收标准。
4. 把修改轮次、变更流程、延期责任补进合同附件。
5. 每个阶段验收时留下书面确认记录，再进入下一阶段。

下一步，把你手上的需求清单整理成一页纸，对照上面的四项要素，逐条补齐每个阶段的交付物、验收标准、确认时限和付款比例，再拿去和外包方逐项确认。