很多老板签网站开发合同时，注意力都在报价和工期上，交付物那一栏随手写一句「网站一套、源码一套」。等项目做完才发现：设计稿不给、后台账号在乙方手里、服务器用的是对方名义、改个 banner 还要另外付费。
这不是谁坏，是合同没写清。交付物写得越具体，后面越省心。下面按五类拆开说，每类都给出可以照着改的写法。
一、源码和部署包：写清「给什么、怎么给」
源码是最容易含糊的一项。建议在合同里明确三件事：交付哪些代码、以什么形式交付、交付后能不能独立跑起来。
可行的写法是：前端源码、后端源码、数据库结构文件、部署说明文档，打包交付，并约定交付后甲方可在自有服务器上独立部署运行。
避坑点有两个。一是只写「提供源码」却没写数据库结构，拿到代码也跑不起来；二是代码里引用了乙方自建的私有组件或加密文件，表面交付了，实际离不开对方。企业网站这类项目尤其要注意，很多模板站的所谓源码，其实是带授权的二次封装。
如果是小程序开发，还要额外写清：小程序主体账号归甲方、代码可提交到甲方自己的开发者后台。
二、设计稿和素材：别只给截图
设计交付物建议写明：可编辑的源文件（如 Figma、Sketch 或 PSD）、切图资源、字体与图标的使用说明。
只给 JPG 截图等于没给。后续换设计师、做活动页延展，全部要重画。
还要约定素材版权归属：乙方使用的图片、字体、图标，是否可商用，出现版权纠纷谁负责。这一条在网站开发项目里经常被忽略，但真出事就是直接下架。
三、域名、服务器、账号：所有权必须写死
这是纠纷高发区。合同里应明确：域名注册在甲方名下，服务器或云账号由甲方实名购买，乙方只保留开发和运维期间的必要操作权限。
一个具体场景：某公司做官网改版，做完了发现域名在上一家服务商手里，续费要加钱，迁移要配合，拖了一个月。
所以交付清单里要列出：域名管理账号、云服务器账号、数据库账号、后台管理员账号、备案信息、第三方服务（短信、支付、地图）的账号与密钥。交接时逐项核对签字。
四、后台与文档：能用起来才算交付
后台管理系统交付的不只是账号，还包括：功能清单、字段说明、角色权限说明、常见操作手册。
建议约定一次线上或线下的交接培训，并留存录屏。这样人员流动时，新同事能自己看。
App开发和复杂后台项目，还应要求提供接口文档和版本记录，方便后续接入其他系统。
五、验收标准：把「能用」变成可测项
验收条款要可执行。建议写：功能按需求文档逐项验收、主流浏览器与机型兼容清单、页面加载时间上限、网站安全测试的基础项（如常见注入、越权、敏感信息暴露的排查）。
同时约定缺陷修复期和响应时限，以及验收不通过时的整改轮次。
避坑：不要写「以甲方满意为准」，也不要写「符合行业标准」这种无法验证的话。
什么情况适合找 MIC Studio
如果你正处在下面几种状态，可以考虑找我们聊聊：需求已经想清楚、需要一份能落地的交付清单；已有系统要做逆向测试或安全排查；或者内部没有专职技术，但希望账号、源码、文档都握在自己手里。
我们做企业网站、小程序开发、App开发和脚本开发，也接安全测试。合同阶段我们会把交付物逐条列成表格，作为附件签进去，避免后面反复解释。
三条可执行建议
1. 把交付物做成表格附件，逐项写「名称、形式、交付时间、验收方式」，签字确认。
2. 签约前先确认域名和云账号在谁名下，不在自己名下的，先迁移再谈开发。
3. 尾款比例和验收挂钩，留 10%～20% 在交接培训完成、账号核对无误后支付。
合同写得细，不是不信任，是让双方都少花时间在解释上。