网站建设外包：服务范围怎样界定
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c8999aeafbb5.html
📄
网站建设外包：服务范围怎样界定
网站建设外包的服务范围，应以一份可逐项验收的《工作范围说明》来界定，而不是靠“做个网站”这类口头描述。判断边界是否清楚，只看三点：每项交付物有没有文件名或可访问地址、验收标准能不能客观复现、范围外的事有没有写明由谁负责。已有页面或项目需要改进时，同样先补这份说明，再谈改动。
先分清三类边界：交付物、责任、变更
外包纠纷多数不是因为价格，而是因为双方对“包含什么”理解不同。把范围拆成三层，歧义会明显减少。
- 交付物边界：页面模板、样式文件、前端脚本、后台功能、数据库结构、部署配置、说明文档，哪些在范围内，逐项列出。
- 责任边界：域名与服务器由谁购买和续费、内容由谁录入、图片与字体版权由谁提供、上线后多久内修缺陷。
- 变更边界：超出原范围的新需求怎么计价、按次还是按工时、改动前是否需要书面确认。
已有项目做改进时，还要额外写清“改动基线”：以哪个版本、哪份代码或哪个线上地址为起点。基线不写，后面很难判断问题是原有缺陷还是新改动引入的。
用一份范围清单逐项对齐
下面这份清单可以直接拿去和外包方逐条确认，每项都要求给出可检查的结果，而不是“已完成”三个字。
- 页面与模板：列出页面数量和类型，例如首页、列表页、详情页、表单页，各自对应哪个模板文件。
- 响应式范围：明确适配哪些断点，例如手机竖屏、平板、桌面，并说明在哪些浏览器上需要验证。
- 功能模块：搜索、筛选、登录、支付、评论、多语言等，逐项写明“包含”或“不包含”。
- 后台与数据：是否提供内容管理后台、字段有哪些、能否导出数据、数据归属方是谁。
- 性能与基础优化：图片压缩、缓存策略、静态资源合并等是否在范围内，用什么指标验收。
- 部署与交接：代码放在哪个仓库、服务器如何配置、是否提供部署步骤文档、账号权限如何移交。
- 维护期：上线后多长时间内免费修缺陷，缺陷与新增需求如何区分。
清单里每一项都应能回答“怎么算做完”。例如“完成响应式”应改成“在 375px 与 1440px 宽度下无横向滚动条，主要按钮可点击”。
验收信号：怎么判断范围真的落地了
验收不看口头承诺，看可复现的证据。可以按下面的信号逐条核对：
- 拿到代码仓库访问权限，能独立拉取并跑起来，说明部署与交接这部分交付了。
- 按文档从零部署一次，若成功，说明环境配置在范围内；若失败且无人协助，说明这项被漏掉或未交接。
- 在约定断点下逐页检查，出现布局错乱，属于未达验收标准，可要求修复而非另计费用。
- 对照清单勾选功能项，清单外出现的功能若未事先确认，应按变更流程处理，而不是默认免费加做。
如果外包方只给一个线上地址、不给代码和文档，那么“网站建设外包”实际上只交付了使用权，不是完整交付。这类情况在签约前就应问清，而不是上线后才发现。
已有项目改进时的特殊处理
在原有页面上做改进，范围界定比新建更麻烦，因为要区分“修旧”和“加新”。建议先做一次现状盘点：列出当前页面清单、已知问题、技术栈版本、可用的账号权限。然后把工作分成两类——修复既有缺陷、新增或改造功能，分别报价和排期。
适用条件是：你手里已经有可运行的项目，且能拿到源码或至少后台权限。如果连源码都拿不到，任何改进都会受制于原外包方，此时第一步不是谈改动，而是先解决代码与账号的归属交接。
判断结果也很直接：能在本地或测试环境复现改动、能回滚到改动前的版本，说明范围与流程都清楚；只能直接改线上、出问题无法回退，说明流程边界还没建立，应先补上再继续。
下一步，把上面的清单整理成一页文档，标出“包含”“不包含”“待确认”三栏，发给外包方逐条回复。回复中仍然含糊的条目，就是签约前必须继续追问的部分。
