接单合同不是项目开始后的补充手续，而是一人公司在确认合作前，最后一次把边界、责任和退出方式说清楚的机会。尤其当客户需求还比较模糊、项目周期较长，或者交付内容容易反复修改时，一份结构清楚的接单合同，往往比口头承诺更能减少后续争议。

先明确：合同是一次“边界确认”

很多一人公司经营者接单时，最关注的是报价和能不能成交，却容易忽略另一个问题：客户理解的“做完”，和你理解的“做完”，是不是同一件事？

例如，客户说“做一套品牌方案”，可能认为其中包括品牌定位、Logo、宣传物料、网站视觉和后续修改；你则可能只理解为一份基础视觉方案。如果合同只写一句“完成品牌设计”，项目一旦扩大，双方都可能认为对方在违约。

一份实用的接单合同，至少要回答六个问题：

• 具体要做什么，不做什么？
• 什么样才算达到交付标准？
• 客户什么时候付款，逾期怎么办？
• 项目中途增加需求，如何处理？
• 成果和原始材料的权利归谁？
• 如果合作无法继续，双方如何退出？

这六个模块可以作为一人公司合同的基本骨架。以下内容是通用起草思路，不替代针对具体交易的法律意见。涉及金额较大、权利复杂或已经发生争议的项目，建议咨询专业律师。

模块一：把工作范围写到“可以核对”

工作范围是接单合同的核心。它不能只写服务名称，还要写清楚工作内容、成果数量、服务边界和客户需要配合的事项。

1. 用成果清单替代模糊描述

与其写“提供运营服务”，不如拆成可核对的项目，例如：

• 每月完成若干篇内容策划；
• 提供一份月度数据分析报告；
• 完成指定页面的文案撰写；
• 提供一次线上沟通和一次集中修改。

数量、形式、周期越清楚，后续越容易判断是否已经完成。对于咨询、设计、开发、内容等不同服务，也可以分别列出最终交付物，例如文档、图片、源文件、代码包、演示版本或会议纪要。

2. 同时写出“不包含什么”

很多纠纷不是因为合同少写了内容，而是因为没有排除容易被默认包含的内容。

例如，可以在合同中说明：

• 不包含额外页面、额外版本或额外语言；
• 不包含第三方软件、素材、字体或平台费用；
• 不包含上线后的长期维护；
• 不包含客户新增的调研、拍摄、培训或现场服务；
• 不包含因客户原因产生的重复返工。

“不包含项”不是推卸责任，而是让报价和工作量保持一致。对于一人公司来说，最容易被消耗的往往不是一次大任务，而是大量没有计价的零散要求。

模块二：把交付标准写成可验收的结果

工作范围解决“做什么”，交付标准解决“做到什么程度”。

如果合同只写“按客户要求完成”，实际上仍然很模糊，因为“客户要求”可能在项目过程中不断变化。更稳妥的方式，是从交付形式、验收方式和反馈期限三个方面描述。

1. 明确交付形式

可以写清楚以下内容：

• 文件使用什么格式；
• 通过什么方式交付；
• 是否提供可编辑源文件；
• 是否包含安装、部署或操作说明；
• 每项成果交付几版；
• 是否有演示版本和最终版本之分。

例如，“交付设计文件”与“交付可编辑源文件、导出文件及使用说明”，对应的工作量并不相同。

2. 约定验收和反馈方式

合同可以设计一个简单的验收流程：

1. 你提交阶段成果；
2. 客户在约定时间内集中反馈；
3. 你根据合同约定完成修改；
4. 客户确认，或者提出具体的不符合项；
5. 进入下一阶段或完成最终交付。

这里要特别注意“反馈要集中”。如果客户今天提出一个意见，几天后又补充一个新意见，项目就可能长期处于未完成状态。可以约定客户应在指定期限内一次性反馈，新增意见按变更需求处理。

3. 区分“修改”与“重做”

合同中最好不要只写“包含多次修改”，而要说明修改的范围。基于原需求进行调整，通常可以归入修改；如果客户改变了方向、增加了目标、推翻原方案重新开始，则更接近于新增工作或项目变更。

这一区分能避免“无限修改”的风险。修改次数也不一定非要写成一个很大的数字，更重要的是说明每轮修改的边界，以及超出范围后的计费方式。

模块三：付款节点要和项目进度绑定

付款条款不能只写一个总价，还要写金额、时间、条件和付款后果。

1. 不要只约定“项目完成后付款”

对于周期较长的项目，如果全部款项都放在最终交付后，一人公司会承担较大的现金流压力，也可能在客户迟迟不确认时被动等待。

可以根据项目阶段设置付款节点，例如：

• 合同生效后支付启动款；
• 阶段成果确认后支付阶段款；
• 最终成果交付前或交付后支付尾款。

具体比例应结合项目周期、前期投入和客户情况协商，不必套用固定模板。

2. 写清楚付款条件

付款条款最好同时包含：

• 合同总价及计价单位；
• 是否含税，发票如何开具；
• 付款账户或付款方式；
• 每个节点的触发条件；
• 客户逾期付款时，项目是否暂停；
• 已完成工作和已发生费用如何结算。

如果项目需要你先购买软件、素材、差旅或第三方服务，也要说明这些费用是否包含在报价中，以及由谁承担。

3. 付款与交付要相互对应

可以把“未付款是否继续交付”“客户逾期是否顺延工期”写进合同。这样做不是为了制造对立，而是避免一方已经持续投入，另一方却长期不履行付款义务。

付款节点越清晰，后续催款越不依赖情绪，也越容易留下完整的沟通记录。

模块四：变更管理，避免项目越做越大

项目中途变更很常见。真正需要防范的，不是客户提出变化，而是变化没有被记录、没有重新报价，最后却变成了你的义务。

1. 先定义什么叫变更

以下情况通常应当考虑纳入变更范围：

• 增加新的交付物；
• 增加页面、功能、版本或服务次数；
• 改变原先确认的方向；
• 更换目标用户、使用场景或技术要求；
• 因客户迟延提供资料导致流程重排；
• 原定项目之外新增会议、培训或维护。

2. 设计一个简单的变更流程

不需要把流程写得特别复杂，可以约定：

1. 客户提出变更内容；
2. 你确认变更对工作量、费用和工期的影响；
3. 双方通过补充协议、变更单或可留存的书面方式确认；
4. 在确认前，原项目按照原约定继续，或暂时暂停受影响部分；
5. 变更确认后再开始新增工作。

关键不是使用哪种文件名称，而是让新增事项具备可追溯的记录。口头说过、聊天中提过，不等于双方对价格和时间都达成了一致。

3. 给每次变更留下三个结果

任何变更都至少要确认：

• 增加或减少哪些工作；
• 费用如何变化；
• 工期和交付节点如何调整。

如果只确认了“可以做”，没有确认价格和时间，后面很容易出现“我以为包含在原价里”的争议。

模块五：知识产权约定要区分成果、素材和工具

知识产权约定是接单合同中容易被忽略、但影响较大的部分。它不只是写一句“版权归客户所有”就结束了。

1. 先列出交付成果

合同可以把最终成果逐项列明，例如：

• 最终确认的文案、设计稿或视频；
• 已交付的代码或文档；
• 客户购买或指定使用的素材；
• 项目过程中形成但不一定交付的过程文件。

只有先定义对象，后续讨论归属、使用范围和授权方式才有基础。

2. 区分最终成果与既有材料

一人公司通常会使用自己原有的模板、方法、组件、字体、代码、工具或工作流程。这些内容不一定因为被用于某个项目，就当然变成客户专属资产。

因此，合同可以区分：

• 为本项目专门制作的最终成果；
• 你在项目开始前已经拥有的材料和工具；
• 第三方提供的素材、软件或平台内容；
• 项目过程中形成的未采用方案和过程稿。

对于既有材料，可以说明客户获得的是在项目范围内的使用权，还是更广泛的授权。对于第三方素材，则要提醒客户遵守相应的使用条件，不能把你无法控制的权利直接承诺给客户。

3. 写清楚何时生效、能否公开展示

如果双方约定成果权利或使用权限在尾款支付后生效，可以在合同中明确对应条件。若你希望将项目用于作品集、案例展示或营销宣传，也应提前写明，并考虑客户的保密要求。

对于未被采用的方案、源文件和通用方法，最好分别约定处理方式。不要为了成交，直接使用“全部权利永久归客户”这类自己并未充分理解后果的表述。

模块六：违约与退出，让合作可以体面结束

一份好的合同不只考虑项目顺利完成，也要考虑合作无法继续时怎么办。

1. 约定哪些情况可以暂停或终止

常见情形包括：

• 一方长期不付款；
• 客户长期不提供必要资料或反馈；
• 项目因客户原因持续停滞；
• 一方明确表示无法继续履行；
• 发生影响项目完成的重大变化。

合同可以分别说明暂停、终止和结算的处理方式。暂停不一定等于终止，有时只是等待资料、付款或决策恢复。

2. 终止时要结算已完成工作

如果项目中途结束，至少需要考虑：

• 已完成部分按什么标准计价；
• 已发生且无法退回的成本由谁承担；
• 已支付款项如何处理；
• 已交付成果是否可以继续使用；
• 未完成部分和未交付材料如何处理；
• 双方是否仍需承担保密等后续义务。

这些内容越早写清楚，越不容易在项目结束时重新争论。

3. 责任条款要避免写成空泛口号

“违约方承担全部责任”看起来很强，但实际执行时仍然需要判断哪些行为构成违约、损失如何计算、责任边界在哪里。

起草时可以围绕具体行为写，例如逾期付款、无故拖延验收、未经确认擅自增加需求、擅自使用未获授权的成果等。条款不一定越重越好，重点是与项目规模和实际风险相匹配。

一份接单合同的起草检查表

签署前，可以用下面这份清单做最后检查：

• [ ] 合同主体、联系人和通知方式是否准确；
• [ ] 项目目标和工作范围是否具体；
• [ ] 不包含的事项是否已经列明；
• [ ] 交付物的数量、格式和时间是否明确；
• [ ] 验收方式、反馈期限和修改范围是否清楚；
• [ ] 总价、税费和付款节点是否对应；
• [ ] 客户逾期付款或迟延配合时如何处理；
• [ ] 需求变更如何确认、报价和顺延；
• [ ] 最终成果、源文件、过程稿和既有工具如何区分；
• [ ] 知识产权或使用授权何时生效；
• [ ] 是否允许案例展示，是否存在保密要求；
• [ ] 项目暂停、终止和退出如何结算；
• [ ] 双方是否保留了合同及变更记录。

结语：合同的价值，是让双方少靠猜

一人公司接单，不一定需要一开始就把合同写得非常复杂，但不能只依赖报价单、聊天记录和口头承诺。真正有用的合同条款，应当能够让一个不熟悉项目的人看懂：要做什么、做到什么程度、什么时候付款、变化怎么处理，以及合作结束时各自带走什么。

把合同当作接单前最后一次确认边界的机会，不是为了把客户推向对立面，而是为了让合作建立在相同理解之上。对于金额较大、涉及多方权利、长期授权或已经出现争议的项目，通用框架仍然不够，建议在签署或处理前咨询专业律师。