你和客户的第一个项目在一份两页的报价单下顺利完成。现在第二个项目更大，客户发来他们自己的工作说明书，里面引用了他们的标准供应商条款，而在合作进行到中途时，某个交付物延迟了，某张发票也没收到款。你指着你的报价单，他们指着他们的供应商条款。到底谁的文书说了算？如果你不能用一句话回答这个问题，那你的合同已经跟不上这段合作关系了——而解决办法不是写一份更长的报价单，而是一套双文档结构：一份主服务协议，加上每个项目一份工作说明书。
这篇指南会解释每份文档里该写什么、为什么把它们分开能让你免于在每个项目上重新谈判同样的条款，以及那些会毁掉整个结构的常见错误。开始前照例声明一句：这是一般性的服务合同知识，不是针对你具体情况的法律建议。
一张图看懂两份文档
主服务协议（MSA）承载与同一客户多次合作中始终不变的所有条款：你怎么收款、谁拥有工作成果、谁对什么负责、任何一方如何退出。工作说明书（SOW）则精确描述一次合作：你要构建或交付什么、何时交付、费用多少，以及客户如何验收。
| 主服务协议 | 工作说明书 | |
|---|---|---|
| 回答的问题 | 我们如何合作？ | 你这次要做什么？ |
| 有效期 | 数月到数年，跨越多个项目 | 单个项目，完成后归档 |
| 重新谈判频率 | 极少，甚至从不 | 每次合作重新签订 |
| 典型内容 | 付款机制、保密、知识产权框架、保证、赔偿、责任限额、期限与终止 | 范围、交付物、里程碑、费用、验收标准、变更控制 |
| 签署方 | 双方，一次 | 双方，每个项目一次 |
把 MSA 想象成操作系统，每份 SOW 则是在其上运行的应用。当第三、第四、第五个项目到来时，你只需要谈判 SOW——你已经争取到的责任限额、知识产权转让和付款条款都原封不动。
主协议里该写什么
MSA 里的所有内容都应该对你为该客户做的每一个项目都成立。如果某个条款会因项目不同而变化，它就该放进 SOW。
合作关系的范围。 说来有点反直觉，MSA 通常完全不含项目范围——只有一句框架性表述，声明客户可以就未来工作说明书中描述的服务聘用你。不要忍不住把项目细节粘到这里。一旦项目具体内容渗入主协议，每次工作变动你都得修订主协议，而这正是这套结构存在的意义所在——就是要消除这种麻烦。
付款机制。 不是任何项目的价格，而是收款的机器：发票在多少天内到期、什么算逾期付款、逾期费或利率是多少、谁承担费用以及如何记录，以及开工前是否需要定金。在这里一次性敲定逾期费——常见写法是未付余额每月 1.5%——之后每份 SOW 都自动继承，无需再争。
保密。 一项双向义务，涵盖双方的非公开信息、终止后保密义务存续多久，以及标准的例外情形：已经公开或独立开发的信息。自由职业者在单次报价单里常常跳过这条；放在 MSA 里几乎不花成本，却在每次合作中保护双方。
知识产权框架。 MSA 规定归属规则——通常是你把完成的交付物转让给客户，理想情况下在全额付款后转让——再加上你既有知识产权的例外：在合作之前就已存在的框架、模板、代码库和方法仍归你所有，仅作为交付物的组成部分授权给客户使用。然后 SOW 指明每次合作覆盖哪些交付物。规则留在主协议，清单放在 SOW。
保证与赔偿。 一条简短的保证：你将专业地提供服务，且交付物不侵犯他人的知识产权；再配一条赔偿条款，规定各方有义务为对方抗辩特定的第三方索赔。这些条款读起来像样板文件，直到某个分包商借用的代码或一张未授权的图库照片引来一封索赔函——那时它们就决定了谁为抗辩买单。
责任限额。 这条条款为你最坏情况下的风险敞口设上限，几乎总是设定为相关 SOW 在前 12 个月内已支付的费用，外加双方互免间接和后果性损害。在主协议里谈一次，就能覆盖每个项目。如果你在这里接受了无上限的责任条款，那你也为未来所有工作接受了它，所以这是主协议层面最值得拼命争取的条款。
期限、终止与收尾。 MSA 持续多久、任何一方如何终止（通常是 30 天书面通知）、终止是否会终结进行中的 SOW 还是让它们走完，以及结束时会发生什么：归还保密材料、支付截至终止日已完成工作的费用，以及任何过渡协助。对自由职业者来说，最有价值的一句话是终止费：如果客户中途取消项目，截至取消时完成的工作加上约定的收尾费必须照付。
效力优先顺序。 回答开头那个场景的条款：当文档冲突时，哪个优先？典型的排序是 SOW 在项目专属条款上优先于 MSA，而两者都优先于任何采购订单或发票上的细字条款。没有这条，客户的采购门户就可能用每一张采购订单悄悄覆盖你谈判来的条款。
工作说明书里该写什么
如果 MSA 是宪法，SOW 就是立法——具体、有日期、用完即弃。每份 SOW 都应独立成为对一次合作的完整描述，同时把其他一切指回 MSA。五个要素承担了几乎全部分量。
范围，加上范围外清单。 描述交付物、里程碑、时间表，以及各方的责任——包括客户欠你什么，比如数据访问权限、五个工作日内反馈，以及单一决策人。然后写出镜像：一份明确的不包含事项清单。额外的修改轮次、实施支持、加急交付、你从未同意使用的工具里的工作——把它们点名列出来，并声明范围外的任何事项都需要书面变更单并另付费用。这一段能把大多数范围蔓延从一场争吵变成一张发票。
本次合作的费用。 固定价格、小时费率及上限，或预付费金额——只是这份 SOW 的数字，叠在 MSA 的付款机制之上。把每笔付款绑定到一个带日历日期或可验证事件的里程碑，并说明定金是否不可退、是否抵扣总额。里程碑计划表一举两得：它安排你的现金流节奏，也给客户一个让反馈持续推进的理由，因为他们的拖延会明明白白地推迟他们自己的日期。
验收标准。 客户如何验收每个交付物，以及——关键的是——如果他们沉默不语会怎样。视为验收条款，通常是十个工作日无书面异议即视为验收，能阻止客户无限期拖延签收并把你的最后一个里程碑当作人质。没有验收标准的含糊 SOW 是范围蔓延最常见的单一来源：当"完成"没有定义时，一切就都还在范围之内。
变更控制。 一段话的流程：对范围、时间表或费用的变更必须以书面形式提出、由你报价，并在变更工作开始前由双方签署。没有签署的变更单，就没有变更的工作。一贯执行这一点的自由职业者反馈说，它能在大多数蔓延对话开始前就终结它们，因为客户在承诺之前就看到了绕道的价格。
依赖项与关键人员。 如果你的时间表依赖客户的投入，就写明因客户延迟导致的时间表按天顺延。如果客户是冲着你机构里的具体某几个人来的，就点出他们的名字，并说明如果有人离开会怎样。无论哪句话，都能防止另一方的三周沉默变成你的逾期。
里程碑、付款条款与验收：金钱与文书交汇之处
SOW 的里程碑计划表不只是项目计划——它是合同形式的收入预测，而你的记账应该与之对应。当每个里程碑都有明确的金额和验收触发条件时，开发票就变成了机械动作：里程碑验收通过、发票发出、按 MSA 条款开始计算付款期限。当里程碑含糊不清时，每次开发票都变成一场谈判。
在你的账本里把每份 SOW 作为独立的收入流追踪。开工前收到的定金还不是收入——在你交付它对应抵扣的里程碑之前，它是一项负债（未实现收入）。里程碑付款与带日期的发票干净对应，这让你应收账款账龄报告成为早期预警系统：如果某个客户的 SOW 一直逾期，而其他客户都按时付款，那问题在客户，不在你的开票流程。到了报税时，按 SOW 记录的账目让你能轻松说明哪笔收入属于哪一年，而不必从一整年的银行入账里挖空心思重建。Beancount 文档展示了纯文本账本如何让这类项目级追踪保持可审计，无需月末手忙脚乱。
两份文档下的知识产权归属
把知识产权条款分散在 MSA 和 SOW 里会让人困惑，所以这里是分工。MSA 规定归属规则和例外：交付物在全额付款后转让给客户，你既有的工具库仍归你所有并以许可方式使用，如果谈判成功你还保留作品集使用权。SOW 则指明该规则适用的交付物——本次合作产出的设计、代码、报告或内容。
这里有两个陷阱会绊住自由职业者。第一个是只依赖"职务作品"措辞。根据美国版权法，该原则只覆盖雇员，以及极少数特定委托作品类别；大多数自由职业交付物并不符合，法院也一再裁定：在合同里把某物标注为职务作品，并不能使它成为职务作品。真正转让所有权的是你 MSA 里的书面转让条款——保留它，把职务作品措辞当作后备而不是机制。
第二个陷阱是分包商缺口。如果有任何其他人碰过这项工作，你的分包商协议必须把他们的工作成果一路转让给你。否则你会向客户承诺你并不合法拥有的交付物的所有权，而 MSA 里的知识产权保证就成了一颗等着被发现日的违约地雷。
责任限额：谈一次，覆盖每个项目
责任条款比其他任何条款都更受益于 MSA 结构，因为它们最难谈判，写错也最危险。在主协议层面争取三件事。
第一，与客户实际支付金额挂钩的上限——通常是索赔前 12 个月内受影响 SOW 下已支付的费用。如果你为同一个客户做高频工作，就不要接受与 MSA 下全部费用挂钩的上限，因为那个数字每年都会长成更大的靶子。第二，双方互免间接、附带和后果性损害：没有这条，一个延迟的交付物理论上能让你为客户的发布收入损失负责。第三，上限不适用的狭窄例外——通常是保密违约、知识产权侵权和故意不当行为。让这份清单保持简短。每一个例外都是保护层上的一个洞，而一条给例外加上"或对本协议的任何违约"的客户修改意见，已经悄悄把你的上限整个删掉了。
单打独斗的自由职业者有时以为这些条款是企业作秀。并不是。责任上限设定为已支付费用，意味着你在一个 15,000 美元合作中最坏情况大约就是 15,000 美元——痛苦，但能活下来。没有上限，你最坏情况就是法官认为客户的损失是多少。签一次上限，你之后在该 MSA 下签的每份 SOW 都带着它。
毁掉整个结构的常见错误
双文档系统只有在文档真正相互关联时才起作用。以下是出现最频繁的失败。
签了一份从不引用 MSA 的 SOW。 脱离主协议漂浮的 SOW 只是又一份独立报价单——你谈判来的保护一条都不附着于它。每份 SOW 都应该在开头按日期和标题并入 MSA。一句话就够了。
让采购订单的细字条款获胜。 很多客户把每次合作都走采购流程，采购订单背面印的条款会在付款时间、责任和知识产权上与你 MSA 矛盾。你 MSA 的效力优先顺序条款应把采购订单排在最后，而你也绝不应在采购订单正面与 SOW 矛盾时不加提醒就签字。采购订单是付款工具，不是重新谈判。
口头变更单。 每一次凭一句"我们会解决的"做出的范围外帮忙，都在训练客户绕过你的变更控制条款——并在发票到来时让你没有任何签署记录。给变更定价、拿到签名，然后才干活。没有签名，就不干活。
永不失效的自动续约加上从不审查费率。 年复一年自动续约的 MSA 很方便，直到你意识到你的 SOW 费率自 2023 年以来一直冻结，而你的成本涨了 20%。把自动续约与年度费率审查窗口配对，让你的定价能随市场移动。
作为个体自由职业者照抄大公司的 MSA。 企业 MSA 假定你拥有并不具备的保险单、安全认证和法务部门。逐字签署一份可能让你承诺年度 SOC 2 审计、99.9% 正常运行时间 SLA，或七位数保险覆盖。把每一项义务都当作你个人必须遵守的承诺来读，把那些为百倍于你规模的供应商设计的条款划掉或收窄。
你现在就需要 MSA 吗？
不是每次合作都需要完整的结构。交付物明确、有干净结尾的一次性项目，在一份写得好的独立协议下就没问题——为一个你可能再也见不到的客户搭 MSA，是没有回报的流程开销。
你已经超出单份文档能力的信号是：来自同一客户的回头生意、没有明确"完成"日期的预付费或持续支持工作、分包商加入你的合作，以及背面带条款的采购文书到来。代理机构很快撞上这些信号，往往是第一个多项目客户就到齐了。个体自由职业者通常在与一个好客户的第二或第三次合作时撞上——而这恰恰是提议 MSA 最容易的时候，因为双方都已经希望这段关系继续下去。把它包装成效率提升，而不是升级："我们把长期条款集中到一个地方，以后的项目就只需要一份简短的 SOW。"
让你的项目财务像合同一样有条理
MSA 加上每个项目一份 SOW，让每次合作都有明确的范围、里程碑计划表和书面记录——而这正是好记账所依赖的原材料。当每份 SOW 对应自己的收入流、定金在赚取之前留在未实现收入里、里程碑发票在你的应收账款里明显地累积账龄，你的账本告诉你的是按客户的盈利能力，而不是一团混合的模糊数字。Beancount.io 提供纯文本记账，让你对自己的财务数据拥有完全的透明和控制——没有黑箱，没有供应商锁定。免费开始使用，看看为什么开发者和财务专业人士正在转向纯文本记账。
