签建站合同前，这 4 条必须写清楚（版权、源码、售后、验收）

HUDING · WEBSITE BUILD INSIGHT

一、合同是唯一能事后翻出来看的东西

建站项目的沟通大多发生在群里：需求在群里聊，方案在群里发，修改意见在群里提。项目顺利时，群聊记录比合同还厚。问题出在项目不顺的时候：改了几轮算不算额外收费？上线之后服务器谁管？设计稿能不能拿去做画册？这时候群聊说了不算，截图也算不上凭据，唯一能翻出来看的只有合同。合同写得清，分歧就有出处；合同含糊，每一处含糊都会变成一次拉扯。有人会说，合作靠信任，合同写太细伤感情。这话听着在理，其实站不住：合同写细不是预设对方不好，而是把双方的理解对齐到同一处。真正的信任，恰恰建立在双方都愿意把丑话说在前面的基础上，谈判桌上愿意逐条对齐的服务商，执行时反而少扯皮。

所以建站合同不是走流程的文书，它几乎是企业在这个项目里唯一掌握的凭据。这四条条款还有一个共同特点：它们都不涉及技术判断，市场负责人一个人就能核对，不需要懂代码也能把把关。换句话说，这是建站采购里门槛最低、收益最大的一步。这篇文章把建站合同里最容易含糊的四条摊开：版权归属、源码交付、售后边界、验收口径。每一条都给出合同里应该出现的表述要点，签约前逐条核对即可。

为什么偏偏是这四条

取舍不是随意的。这四条对应建站纠纷最高发的四个节点：设计交付时争版权，改版升级时争源码，上线之后争售后，结款验收时争标准。每一条背后都是真金白银的扯皮成本。与其事后消化纠纷，不如事前花一个下午把条款定清。

二、第一条：版权归属，设计与素材各有各的账

版权归属要先分清对象：设计成果是一笔账，素材是另一笔账。设计成果包括页面视觉稿、图标、版式，合同里应写明设计成果的著作权归企业所有，建站方保留的仅限于作品集展示等合理用途。素材这笔账更细：图片、字体、图标库各有各的授权范围。字体侵权是重灾区，很多企业不知道商用字体需要授权，网站上线许久之后收到字体厂商的函，才回头追问当时字体是谁选的。合同里应写明：建站方使用的素材确保具备商用授权，因素材授权问题产生的责任由建站方承担。版权条款示例的表述要点可以这样起头：本项目设计成果，含视觉稿、页面样式实现、图标与插画，著作权自交付之日起归企业所有；建站方保证所用字体、图片、图标等素材具备商用授权，并提供授权凭证备查。

还有一处容易漏：企业自己提供的资料，logo、产品图、公司介绍，合同里也应注明这些素材的权利仍归企业，建站方仅在本项目范围内使用。听起来是常识，但没写进合同的常识，就等于没有约束。网站内容的合规边界与网络权益保护，也可以参照国家网信部门发布的公开规范逐项确认，这部分同样值得写进合同附件。

三、第二条：源码交付，范围与格式写进附件

源码交付这条，很多合同只用一句"项目完成后交付源码"带过，这句话在执行时几乎必然产生分歧。源码包含什么？只是程序文件，还是包括数据库结构和设计源文件？什么格式交付？压缩包还是代码仓库？什么时候交付？结清全款当天还是验收通过当天？

写进附件才有效。附件里应逐项列出交付物：程序源码、数据库、设计源文件、部署文档，每项写明格式与交付节点。这里的原则是清单化：凡是没列进清单的，验收时都可以被解释为不含。关于这一条的完整展开，可以配合营销观察栏目里源码与归属的专题讨论一起看，那里把代码、数据、管理权三层都过了一遍。附件里除了交付物清单，还建议写明源码的版本与完整性标准：能独立部署、能完整运行，才算交付达标。缺了这条，交付过来的可能是一堆跑不起来的文件。

顺带一个提醒：源码交付和售后是两件事，不要因为约定了源码交付，就默认企业要自己接手维护。交付源码保障的是企业的所有权，维护仍可以由建站方继续承担，两者并行不悖。还有一种情况要防：合同写了交付源码，却没写交付的时间点。拖到项目结束再交付，中间企业想核对都没机会。交付节点写进附件，最好与验收节点绑定，验收通过即交付，延误的责任也顺带写明。

四、第三条：售后边界，免费与付费的分界线

售后是建站合同里分歧最多的部分，根源在于维护这个词没有边界。同一句提供一年免费维护，两种理解可以差出很远：一种理解为改内容、修故障、打补丁都包，另一种理解为只修程序故障。分界不清的代价由谁承担？通常是企业：改内容被报价，修故障被排期，一年维护期很快过去，才发现很多事从来不在免费范围里。售后边界要写清四件事：

• 范围：维护包含哪些动作，内容更新算不算、安全补丁算不算、服务器续费与备案续期谁负责、数据备份的频率与保留周期是多少。
• 响应：出现故障后如何报修、多快响应、什么情形算紧急，联系方式与工作时段写明，避免出事时找不到人。
• 分界：哪些属于免费维护，哪些属于另行报价的增值开发，比如新增功能模块、大型改版、结构性调整，逐类写清。
• 移交：合作终止时如何交接，账号、数据、文档以什么形式移交，写清移交清单与期限。

这四件事落在纸面上，售后的样子就清楚了。判断一家服务商的售后诚意，也可以从它愿不愿意把这四条写进合同看出来：愿意写的，是把售后当承诺；推说到时候好商量的，售后大概率是空话。响应条款里还有一个实务点：紧急情形的定义。网站打不开、表单收不到线索、页面出现异常代码，这三类应当单独列为紧急项并约定更快的响应方式，日常的内容修改归入普通项。分了级，售后资源才会用在真正要紧的地方。

五、第四条：验收口径，按清单逐项过

验收口径决定两件事：尾款什么时候结，纠纷怎么算。含糊的验收标准就是一句验收合格后支付尾款，可合格谁说了算？按清单逐项验收，是唯一可执行的口径。

清单应包含几个层面：功能层面，表单能不能正常提交、后台能不能正常操作、移动端显示是否正常；性能层面，主流网络环境下的加载表现是否达标；配置层面，站点地图、语义化结构、统计代码这些上线必查项是否到位；内容层面，约定的页面与内容是否完整上线。每项写明通过标准，验收时逐项打钩，全项通过才算验收完成。更多上线路径的检查要点，可以配合SEO 基础配置的清单一起看，两份清单拼起来就是完整的上线验收。性能这一项常被含糊带过，建议写法是约定在主流网络环境与主流机型下的基本可用标准，而不是抽象的流畅二字。

验收口径还有一个隐藏作用：它反过来约束开发过程。有明确清单的项目，开发方会在过程中对照清单自查，交付质量通常更稳；没有清单的项目，质量全凭对方自觉。验收清单不必追求一次写全，签约时先定框架，开发中途补充细化，双方签字确认后并入附件。清单是活的文件，但它必须始终白纸黑字，口头补充的部分一律不算数。

六、四条速查：谈判桌上的核对表

把四条浓缩成一张表，签约前对照核对，缺哪条就补哪条。

条款	应写清的要点	常见的含糊表述
版权归属	设计成果著作权归企业；素材商用授权由建站方保证；企业素材权利不变	设计风格可供企业使用
源码交付	交付物清单、格式、节点写入附件	项目完成后交付源码
售后边界	范围、响应、免费与付费分界、移交方式逐项写明	提供一年免费维护
验收口径	按清单逐项验收，写明各项通过标准	验收合格后支付尾款

表格右侧那一列，就是谈判桌上最常听到的话。听到这些话，不是不能合作，而是要把含糊的部分落成白纸黑字。合同条款的完备程度，其实也是对服务商专业度的一次测试：越规范的服务商，越不怕把事情写清楚。核对表也可以反过来用在需求沟通上：把四条要点提前发给对方，让对方按要点出合同草案，比收到合同再逐条挑刺省力得多。谈判的主动权，往往就藏在这些提前准备里。企业在采购营销型官网建设这类要用很多年的服务时，这一条尤其成立。

七、写在最后

四条条款，版权、源码、售后、验收，没有一条是高深的东西，全是把口头共识落成文字的笨功夫。但建站项目里的绝大多数纠纷，恰恰就败在这些笨功夫上：该写的没写，该列的没列，出事之后各说各的理解。

合同也是一面镜子。一份愿意把归属、交付、售后、验收都写清楚的方案，背后通常是一套规范的服务流程；一份处处含糊的合同，背后往往是先签下来再说的思路。企业建站本来就是一笔要用很多年的投入，多花一个下午把合同定清，是这笔投入里性价比最高的动作。合同定清还有一个后续红利：多年后的改版、迁移、增购，都能从这份合同出发去谈，历史权属清清楚楚，每一次续作都不用从头掰扯。关于互鼎在官网项目上的交付与协作方式，可以在关于我们页面看到更完整的说明。

参考资料

• 国家互联网信息办公室
• Gartner：营销技术与买方行为研究
• 哈佛商业评论