SOW工作说明书：范围、交付物、验收标准、时间计划

📜 为什么SOW如此重要

很多FDE觉得SOW就是走个形式——合同签了，大家好好合作就行了，SOW写那么细干嘛。结果项目做着做着就出问题了：客户说"这个功能你们应该包含的"，你说"这个不在范围内"；客户说"你们交付的东西达不到要求"，你说"当初没说要达到这个标准"；客户说"你们怎么还没做完"，你说"需求变了，时间要加"。

这些问题的根源，都是SOW没写清楚。SOW（Statement of Work，工作说明书）是项目的"宪法"——项目做什么、不做什么、交付什么、怎么验收、多久做完、双方各负什么责，都在SOW里写清楚。SOW写清楚了，项目过程中就有依据，不会扯皮；SOW没写清楚，后面全是纠纷，轻则加钱加时间，重则项目失败、客户不满意、尾款收不回来。

SOW的三个核心价值：

价值一：范围管理。SOW明确写了项目做什么、不做什么，客户就不能随便加需求（"这个功能很简单，你们顺便做了吧"）。如果客户要加需求，就走变更流程——加钱、加时间。没有SOW，范围就像橡皮筋，客户想拉多长就拉多长，最后你累死还不讨好。

价值二：验收依据。SOW明确写了交付物是什么、验收标准是什么，项目做完了就按SOW验收，客户不能说"我觉得效果不好"就不验收。验收标准要量化、可测试——"AI回复准确率达到85%以上""响应时间不超过30秒""支持100并发用户"，这些都是可测试的。没有量化的验收标准，客户永远可以说"效果不好"，你永远收不到尾款。

价值三：责任划分。SOW明确写了双方各负什么责——FDE负责什么（系统开发、部署、培训），客户负责什么（提供数据、提供系统接口、安排人员配合）。责任划清楚了，出了问题就知道是谁的责任——数据质量差导致效果不好，是客户的责任；系统有bug，是FDE的责任。没有责任划分，出了问题双方互相甩锅，项目就做不下去了。

记住：SOW不是给律师看的，是给项目团队和客户看的。SOW写得清楚、明白、可执行，项目就成功了一半。

📋 SOW的十个核心模块

一份完整的FDE项目SOW，包含十个核心模块：

模块一：项目背景和目标。为什么做这个项目？要解决什么问题？达到什么目标？比如："为解决贵司客服部夜间响应慢的问题（当前平均响应时间32小时，客户满意度3.5分），部署夜间AI客服系统，目标将夜间响应时间降到30秒以内，客户满意度提升到4.2分以上。"背景和目标要跟方案里的痛点和价值对应，让看SOW的人知道"为什么做这个项目"。

模块二：项目范围。项目做什么、不做什么。这是SOW最核心的模块，一定要写清楚。做什么：列出项目包含的所有功能和服务，比如"① AI客服系统开发和部署；② 知识库搭建和FAQ整理；③ 系统对接（智齿客服系统）；④ 培训和上线支持；⑤ 3个月运维保障"。不做什么：明确列出项目不包含的内容，比如"① 不包含客服系统的替换（仍使用现有智齿系统）；② 不包含客户数据的清洗和整理（由客户负责提供干净数据）；③ 不包含二期的客户管理和数据分析功能；④ 不包含硬件采购"。"不做什么"跟"做什么"一样重要——不写清楚，客户就会默认"这些你们应该包含"。

模块三：交付物清单。项目交付什么东西，每个交付物的形式和标准。比如："① 系统源代码（Git仓库）；② 系统部署文档；③ 知识库（FAQ文档，不少于200条）；④ 培训材料（PPT+操作手册）；⑤ 测试报告（功能测试+性能测试）；⑥ 验收报告。"每个交付物都要有明确的形式和标准，不要写"系统文档"这种模糊的词——要写"系统部署文档，包含环境要求、部署步骤、配置说明、常见问题排查，不少于20页"。

模块四：验收标准。怎么算项目完成？每个交付物的验收标准是什么？验收标准一定要量化、可测试。比如："① 功能验收：所有需求规格说明书中的功能点100%实现，无严重bug；② 性能验收：AI回复准确率≥85%（测试集1000条），平均响应时间≤30秒，支持100并发用户；③ 业务验收：夜间响应时间≤30秒（上线后连续2周统计），客户满意度≥4.2分（上线后1个月调研）；④ 文档验收：所有交付物齐全，内容完整、准确。"验收标准分阶段——功能验收（上线时）、业务验收（上线后1-3个月），不要混在一起。

模块五：项目时间计划。项目多久做完？每个阶段的时间和里程碑。比如："项目总周期6周：第1-2周需求调研和数据准备（里程碑：需求规格说明书确认）；第3-4周系统开发和配置（里程碑：系统测试版交付）；第5周测试和试运行（里程碑：测试报告+试运行总结）；第6周正式上线和培训（里程碑：上线验收报告）。"每个里程碑要有明确的交付物和时间节点，时间计划要跟客户确认——客户能不能在规定时间内提供数据、安排人员配合，这些都要考虑进去。

模块六：双方责任和义务。FDE负责什么？客户负责什么？比如："FDE责任：① 按SOW完成系统开发和部署；② 提供培训和上线支持；③ 3个月内免费bug修复；④ 对客户数据保密。客户责任：① 在项目启动后3个工作日内提供所需数据和系统接口；② 安排至少1名专职人员配合项目（需求确认、测试、验收）；③ 按时确认需求和交付物（收到后5个工作日内反馈）；④ 按合同约定付款。"责任划分要具体、可执行，不要写"双方积极配合"这种空话——要写"客户在收到交付物后5个工作日内反馈，逾期视为确认"。

模块七：变更管理。需求变了怎么办？变更流程是什么？比如："项目过程中，任何一方提出需求变更，需提交书面变更申请，说明变更内容、原因、对时间和费用的影响。双方评估后，如确认变更，签署变更确认书，调整项目时间和费用。未经双方书面确认的变更，任何一方不得执行。"变更管理是范围控制的关键——没有变更流程，客户随口说"加个功能"，你就做了，最后时间超了、费用超了，客户还不承认。有了变更流程，每次变更都要签字、加钱、加时间，客户就不会随便提变更了。

模块八：付款方式。怎么付钱？分几期？每期付多少？比如："项目总费用X万，付款方式：① 合同签订后5个工作日内付50%（X万）；② 系统上线验收后5个工作日内付40%（X万）；③ 业务验收（上线后3个月）后5个工作日内付10%（X万）。"付款方式要跟里程碑对应——每个里程碑完成后付一笔，不要"上线后一次性付清"（风险太大），也不要"签合同就付90%"（客户不放心）。

模块九：保密和知识产权。数据归谁？系统归谁？比如："保密：双方对项目过程中接触到的对方商业秘密和数据保密，未经对方书面同意不得向第三方披露。数据所有权：客户提供的所有数据归客户所有，FDE不得用于项目以外的用途。知识产权：系统源代码和定制开发部分的知识产权归客户所有（付款完成后）；FDE保留通用工具和框架的知识产权。"FDE项目的知识产权比较特殊——大模型的能力不是你的，你做的是应用层的开发，要写清楚哪些归客户、哪些归你。

模块十：违约责任和争议解决。违约了怎么办？有争议怎么解决？比如："违约责任：① FDE延迟交付，每延迟1周支付合同总额1%的违约金（最多不超过10%）；② 客户延迟付款，每延迟1周支付应付金额1%的违约金；③ 任何一方严重违约，另一方有权终止合同并要求赔偿。争议解决：因本合同产生的争议，双方友好协商解决；协商不成的，提交甲方所在地有管辖权的人民法院诉讼解决。"违约责任要对等——不要只写FDE违约怎么办，不写客户违约怎么办。

十个模块都写清楚了，SOW就完整了。SOW不需要写得像法律条文那么晦涩，但一定要写得清楚、明白、可执行。

⚠️ FDE项目SOW的特殊注意事项

FDE项目跟传统IT项目不一样，有一些特殊的地方，SOW里要特别注意：

注意一：AI效果的不确定性。AI项目的效果不是100%可控的——模型准确率可能受数据质量、问题类型影响，可能达不到预期。SOW里的验收标准不要写"准确率100%"，要写"预期准确率≥85%"，并且要说明"准确率基于双方确认的测试集，测试集由双方共同准备"。还要设置效果优化期——"上线后3个月内，如果准确率不达标，FDE免费优化（包括调整prompt、补充训练数据、优化知识库）"。把不确定性写清楚，后面才不会因为效果问题扯皮。

注意二：数据质量的责任。AI项目的效果很大程度上取决于数据质量——数据脏、数据少、数据不准，效果就好不了。SOW里要明确写："客户负责提供干净、准确、完整的数据，数据质量直接影响AI效果。如果因数据质量问题导致效果不达标，FDE不承担责任，但会协助客户改善数据质量。"不要默认"客户的数据肯定没问题"——大部分客户的数据都有问题，提前写清楚责任，后面才不会背锅。

注意三：大模型服务的依赖。FDE项目通常依赖第三方大模型服务（OpenAI、阿里云、百度等），这些服务的可用性、价格、能力变化不是FDE能控制的。SOW里要写："系统依赖XX大模型服务，该服务的可用性、价格、能力变化由服务提供商负责，FDE不承担因服务提供商变更导致的影响。如果大模型服务价格上涨，超出原预算的部分由客户承担。"把第三方依赖的风险写清楚，不要自己扛。

注意四：人机协同的定位。FDE项目大部分是"人机协同"，不是"完全替代人工"。SOW里要明确写："本系统定位为人机协同工具，AI处理常见和重复性问题，复杂和特殊问题转人工处理。系统不替代人工客服，而是提升人工客服的效率。"不要为了签单承诺"完全替代人工"——一旦客户觉得"AI替代了人"，就会裁员，裁完员发现AI处理不了复杂问题，又会回来找你麻烦。

注意五：持续运营的责任。AI系统上线后不是"交付就完了"，还需要持续运营——知识库更新、模型优化、效果监控、用户反馈处理。SOW里要明确写："项目交付后3个月内，FDE提供免费运维支持（bug修复、小幅度优化）。3个月后，如需持续运维和优化，双方另行签订运维服务合同（年费建议为项目费用的15-20%）。"不要默认"交付后就不管了"，也不要默认"交付后终身免费维护"——写清楚免费期和收费标准，后面才不会有纠纷。

注意六：业务效果的归因。AI项目的业务效果（比如转化率提升、成本降低）往往是多个因素共同作用的结果，不只是AI系统的功劳。SOW里的业务验收标准要写清楚："业务效果指标（如客户满意度、转化率）为参考指标，受多种因素影响，不作为唯一验收标准。功能和性能指标达标即为验收通过。"不要把业务效果作为硬性验收标准——你控制不了客户的其他业务决策，把业务效果写死，后面可能背锅。

💡 SOW写作的注意事项

注意一：用清晰、简洁的语言，不要用模糊的词。SOW里不要出现"等""相关""适当""尽量"这些模糊的词——"等"意味着范围不确定，"相关"意味着内容不确定，"适当"意味着标准不确定。要用明确、具体的语言——"不少于200条FAQ""5个工作日内反馈""准确率≥85%"。

注意二：所有数字都要明确，不要用"约""大概"。时间、费用、数量、标准，所有数字都要明确——"6周""50%""200条""85%"，不要写"约6周""大概50%"。数字不明确，后面就有争议的空间。

注意三：SOW要跟方案和合同一致，不要互相矛盾。方案里写的功能、SOW里要包含；合同里写的费用、SOW里的付款方式要对应。不要方案里写了10个功能，SOW里只写了5个；不要合同里写100万，SOW里的付款加起来是80万。不一致的地方，后面一定会出问题。

注意四：SOW要双方确认，不要单方面写。SOW写完后，要跟客户逐条确认——范围对不对？交付物齐不齐？验收标准能不能接受？时间计划合不合理？双方确认后再签字。不要自己写完就发给客户"请确认"，客户可能根本没仔细看，后面出了问题说"我当时没注意这条"。

注意五：SOW是活文档，变更要更新。项目过程中如果有变更（需求变更、时间调整、费用变化），要及时更新SOW，签署变更确认书。不要口头说"这个变更我们同意了"，然后不更新SOW——口头承诺没有法律效力，后面双方记忆不一致就扯皮。变更一定要书面确认，更新SOW。

注意六：SOW要存档，项目过程中随时查阅。SOW签字后，项目团队每个人都要有一份，项目过程中随时查阅——客户提需求了，先看SOW里有没有；交付物要交付了，先看SOW里的标准；验收了，先看SOW里的验收标准。不要SOW签完就锁起来，项目过程中全凭记忆——记忆会出错，SOW不会。