这张卡讲交付者必须会读也会改的合同文件：SOW。
核心拆解：SOW 与主服务协议（MSA）的分工——MSA 管双方长期合作的法律框架，SOW 管单个项目的具体买卖：范围、交付物、里程碑、价格、验收。FDE 项目的 SOW 有四个必写项：评测集及其归属、效果验收指标、驻场安排与差旅承担、变更流程。最常见的缺陷是 SOW 写成任务清单，只有「做什么」没有「怎么算做成」，验收日必然被动，追加预算时更被动。里程碑应绑定可观测的中间产出而非日期，SOW 还常漏数据条款：客户数据能否用于调优，要在附件写死。
增量判断：国内合同语境里 SOW 常以「技术协议」「开发合同附件」形式出现，名称不同但功能一致；撰写时把范围写成排除项加包含项，比单纯罗列更能防范围蔓延，因为双方对「没写的算谁的」默认正好相反。
行动建议：找出你最近一份 SOW，检查有没有写明不包含什么，没有就补一版排除清单，这是防蔓延的第一道闸。
—— FDEChina编辑部 · 实战派
定义
工作说明书（Statement of Work，SOW）是约定单个项目工作范围、交付物、里程碑、验收条件与价格的合同文件，通常作为主服务协议（MSA）的附件签署和执行。
展开
SOW 与 MSA 的分工要分清：主协议管双方长期合作的法律框架——责任、保密、付款方式、知识产权；SOW 管单个项目的具体交易内容，一个框架下可以挂多个 SOW。对 Forward Deployed Engineer（FDE）项目，SOW 有四个必写项：评测集的定义与归属、效果验收指标及测量方法、驻场安排与差旅承担方式、范围变更的流程与计价。国内语境下，SOW 常以「技术协议」「开发合同附件」等形式出现，名称不同、功能一致。撰写技巧上，把范围写成「包含项加排除项」比单纯罗列包含项更能防范围蔓延——客户与供应商对「没写的算谁的」会有完全相反的默认理解。
最常见的缺陷是 SOW 退化为任务清单：只有做什么、没有怎么算做成，也没有变更条款，验收日与追加预算时全部被动。SOW 的质量基本决定了项目后期的争吵次数，交付者应参与起草而不是等法务定稿再看。