简介《合作协议模板》是一份可直接编辑的docx法律文书范本面向需要快速拟订商业合作条款的中小企业、创业团队及渠道运营人员帮助双方明确在推广、销售与服务环节的权责边界避免口头约定带来的争议。包内共有1个docx文件压缩包约25KB正文按八章结构铺开涵盖合作方式与条件、双方权利义务、合作期限、分成比例及支付节点、保密责任、不可抗力、适用法律与争议解决、协议生效及附件管理条款齐备且留有空位供填写。资源特别区分首次成交与续费的分成比例并附带《授权书》附件便于甲方授予乙方非独家推广权限。目前已有83人学习下载适合作为合同起草底稿或商务合规参考稍作修改即可用于实际签约场景无论用于正式签约还是内部参考均能节省起草时间。1. 合作协议模板.docx把合同从每次重抄变成只填差异如果电脑里躺着一个叫合作协议模板.docx 的文件大概率它是从上一份协议复制、改名、改日期改出来的二手货。项目合作做到一定次数就会明白协议最耗时的不是条款谈判而是每次都要分辨哪一段是通用条款、哪一段是上一个项目特有的还要惦记上一版有没有漏改的项目名称和金额。合作协议模板.docx 的价值就是把这个过程彻底逆转把协议拆成固定模块加参数位正文结构和格式锁死每次合作只填差异字段再用脚本批量生成。它同时服务两类人一类是需要自己出协议的独立开发者和小团队另一类是给业务部门提供标准文本的合规和流程岗。这篇内容按协议内容怎么拆、Word 模板怎么建、自动化怎么跑、常见坑怎么排往下走末尾给一段让模板能长期维护的进阶做法。2. 协议内容怎么拆条款模块清单与参数位判断标准做协议模板的第一步不是打开 Word而是先把旧协议当成一份可以重构的源码。合作协议的形态很多但拆到模块级别翻来覆去就是下面这些块。2.1 从首部到签署页一份合作协议的模块化骨架一张表看清一份常规合作协议由哪些模块组成以及哪些内容属于固定文本、哪些属于参数位协议模块固定文本量常用参数位首部协议编号、签订地点少协议编号、签订地点、签订日期甲乙方基本信息少当事人名称、统一社会信用代码、联系人、地址合作内容与范围中项目名称、服务内容、交付物合作期限与生效少开始日期、结束日期、续约条件费用与结算少金额小写、金额大写、税率、账期双方权利义务多里程碑、验收标准、响应时限知识产权与保密多数据归属、保密期限违约责任多违约金比例、免责情形解除与终止多提前通知天数、已付款项处理争议解决多仲裁机构或约定法院签署页少单位名称、代表人、签署日期这张表不是让你照抄而是给你判断依据。小型合作项目砍到五个模块也能运转甲乙方信息、合作内容、费用结算、违约责任、签署页。但砍不是删条款而是把条款里只在特定场景出现的内容交给参数位。固定文本越多后续维护成本越高所以模板里真正要反复打磨的反而是那些标注为“多”的模块它们的措辞直接决定这份模板能复用几轮。2.2 参数位设计判断一个字段该留空、预设还是自动带出参数位设计的错误集中在三个问题上谁来填、填几次、填错的影响面。每单必填的字段如甲乙方名称、项目名称、金额、签署日期属于第一优先级地址、开票信息、联系人这类内容配置一次就能复用我一般把它们放到模板前面做一个常驻配置区协议编号、日期时间戳这类可以从业务系统自动带出的值生成后再由人工复核。命名规范是另一个容易忽视的点。在 Word 文档里写中文方括号占位符会遇到两个问题一是和正文里的顿号、括号混在一起不好识别二是不利于脚本处理。我习惯用可替换的英文变量并用双花括号包裹比如 {{ party_a }}。规则有三条变量名和上下文不混、全模板唯一、人能看懂。party_a 比 p1 好project_name 比 xm 好。变量在模板里只能出现一次否则脚本替换时会漏改或者改出两套值。还有一件事值得做给模板建一份字段登记表记录每个参数位的来源、校验规则、由谁维护。不用做成系统模板开头放一页说明即可。有了这份表后面用脚本批量生成时就不会出现“金额字段忘了传大写”这类低级问题。2.3 从旧合同提炼条款只保留两版之间的公共部分手里有五六份旧协议时不要逐份读全文。我的做法是把所有旧协议按上一小节的模块对齐然后把每个模块里重复出现的措辞保留下来变化大的内容参数化。举个例子有份旧协议里写的是“合作范围为某图像处理Demo 的技术预研”下一份项目换成了“某跨平台系统升级”如果不做参数化就只能全文手动替换漏改的风险极高。正确做法是把具体项目名放进 {{ project_name }}把“乙方负责完成的交付物包括但不限于”这类通用表述留在固定文本里。提炼原则可以类比代码重构两版以上重复出现的文本进固定模块只在一份协议里出现过的临时约束尽量参数化或者干脆删掉。协议模板不是越厚越好保留的每一句话都要有被重复使用的理由。3. 在 Word 里把模板搭成可控结构样式、编号与占位符内容骨架定了之后接下来是在 Word 里把格式固化。这一步的目标是让模板经得起多人修改、跨版本保存、跨工具打开。3.1 页面设置、页眉页脚与多级编号一次配到位先打开页面布局把基础参数定死。A4、上下边距 2.54cm、左右边距 3.17cm页眉距边界 1.5cm、页脚距边界 1.75cm这些值在一开始设置好后面就没人再动。页眉里写“合作协议”以及模板版本号版本号建议用 Word 的“插入—文档部件—域”里的 DOCPROPERTY 引用而不是手写文字。这样修改文档属性时页眉会自动更新不会出现版本号印在页眉里但内容已经翻了好几版的情况。页脚用 { PAGE } 和 { NUMPAGES } 域组合成“第 X 页 共 Y 页”覆盖多页协议的基本排版需求。条款编号也在这里一次配好。合作条款习惯用“第1条、第2条”而不是纯数字编号无论用哪种都要用 Word 的“定义新的多级列表”做成自动编号不要手动敲“第3条”。手动编号在增删条款时不会自动重排这是模板里最容易翻车的地方之一。3.2 用样式表接管格式别让格式刷把模板变成黑匣子新建文档先改样式不要先打内容再格式刷。把“正文”样式设成中文宋体或仿宋、西文 Times New Roman、小四号、1.5 倍行距、首行缩进 2 字符。把“标题1”用于“第X章”级别“标题2”用于下属条款。标题颜色建议直接改成黑色Word 默认标题是蓝色打印成黑白稿后层次感会丢从模板转 PDF 时也会变花。格式刷在协议模板里要少用。格式刷会把字体设置变成散落在各个段落里的直接格式后续维护时根本查不到这一处格式是从哪来的。正确做法是只改样式定义然后全选正文清除直接格式一键回到统一样式。需要批量设置时用查找替换里的“同样式文本”定位而不是肉眼去找。3.3 内容控件与纯文本占位符两种可写区方案怎么选Word 开发工具下的内容控件可以把可填写区锁死给纯人工填写场景很顺手。做法是先写说明文字再插入纯文本控件或下拉列表控件在属性里勾选“无法删除内容控件”。优点是防止填表人误改版式缺点是对脚本填充和 WPS 兼容性都不太友好。如果要走自动化填充我建议回到纯文本占位符 {{ party_a }} 这种写法。理由有三脚本处理简单、跨 Word 和 WPS 保真度高、漏填时可以通过正则快速发现。缺点是普通填表人看到双花括号会懵所以我一般准备两个文件一个给人工填的内容控件版一个给代码跑的占位符版。人工版每次发布时由同样一套脚本把占位符版另存出来再替换成内容控件避免两个版本各自漂移。3.4 存 docx 还是 dotx容易被忽略的第一道坎Word 的模板后缀是 dotx双击后自动新建一个 docx 文档优点是不会覆盖源文件。但从工程角度看我推荐还是存成合作协议模板.docx 这样的常规 docx 文件。原因很实际dotx 在部分云盘和协作工具里打开不正常脚本处理时还要多做一层格式判断。用 docx 存储生成新协议靠复制文件或脚本渲染源文件命名固定反而更好管理。4. 让模板自动出协议docxtpl 从安装到批量渲染模板搭好之后接下来是把这个过程工程化一份模板、多个参数、批量出协议。这里用 Python 生态里的 docxtpl 完成。4.1 环境准备为什么选 docxtpl 而不直接替换文本协议模板的自动化填充有两个常见方案python-docx 直接操作段落文本或者用 docxtpl 做模板渲染。直接替换文本在遇到变量被 Word 拆成多个 run 时会失效处理起来非常难受。docxtpl 把 Word 模板和 Jinja2 语法结合起来天然支持变量渲染、条件判断、循环列表比手工操作 run 稳定得多。安装很简单pip install docxtpldocxtpl 依赖 python-docx装完这两个库就都有了。版本上我一般固定 1.x 系列避免新版在占位符解析上出现行为变化。装完后在 Python 里 import DocxTemplate 不报错环境就绪。4.2 模板改造把参数位写成 Jinja2 变量回到 Word 模板把上一章设置好的参数位替换成双花括号变量例如 {{ agreement_no }}、{{ project_name }}、{{ start_date }}。填写时不要用中文括号也不要在变量内部加空格否则脚本匹配不到。模板里可以正常写固定文字变量只出现在需要替换的位置。如果某段条款在特定项目里不出现还可以用 {% if %} 包起来例如判断是否存在保密约定这是 docxtpl 相对普通替换最大的优势。4.3 渲染单份协议的最小脚本与参数约定下面这段脚本做的事是读模板把 context 里的键按 Jinja2 规则替换再另存为新文件。from docxtpl import DocxTemplate tpl DocxTemplate(合作协议模板.docx) context { agreement_no: RJ-2024-027, project_name: 某跨平台系统升级, party_a: 甲方公司, party_b: 乙方公司, amount: 100000.00, amount_upper: 人民币壹拾万元整, start_date: 2024年07月01日, end_date: 2025年06月30日, } tpl.render(context) tpl.save(合作协议_RJ-2024-027.docx)这里有几个参数约定值得注意。agreement_no 必须保证唯一生成逻辑建议放在循环外部否则后面会覆盖文件。amount_upper 直接传写好的中文大写字符串不要在模板里做数字到中文的换算docxtpl 里做这一步既不好调试也不可控。日期全部用“2024年07月01日”这种完整字符串不要传 2024/7/1 或 2024-07-01保证协议内部日期写法一致。tpl.save 的目标文件名不要覆盖源模板否则下一次渲染就没得读了。4.4 批量生成多份协议循环里不能复用同一个模板对象多个项目需要一次性生成多份协议时把参数放进列表循环渲染。from docxtpl import DocxTemplate contracts [ { agreement_no: RJ-2024-027, project_name: 某跨平台系统升级, party_a: 甲方公司, party_b: 乙方公司, amount: 100000.00, amount_upper: 人民币壹拾万元整, start_date: 2024年07月01日, end_date: 2025年06月30日, }, { agreement_no: RJ-2024-028, project_name: 某图像处理Demo, party_a: 甲方公司, party_b: 丙方公司, amount: 200000.00, amount_upper: 人民币贰拾万元整, start_date: 2024年08月01日, end_date: 2025年07月31日, }, ] for item in contracts: tpl DocxTemplate(合作协议模板.docx) tpl.render(item) tpl.save(f合作协议_{item[agreement_no]}.docx)循环里每次都要重新创建 DocxTemplate 对象不能把同一个 tpl 对象拿来做多次 render。这是脚本批量生成时容易踩坑的地方同一个对象第二次渲染时上一次的变量可能残留导致第二份合同里出现第一份的项目名称。每次 new 一个模板对象就是让每次渲染从干净状态开始。4.5 残留占位符扫描段落和表格都要查渲染完成后不要急着交付。先跑一遍占位符扫描确保所有 {{ }} 都被替换掉。占位符如果出现在表格单元格里段落遍历查不到所以要连表格一起查。import re from docx import Document def check_placeholders(path: str): doc Document(path) hits [] for p in doc.paragraphs: for m in re.finditer(r\{\{.*?\}\}, p.text): hits.append(m.group()) for table in doc.tables: for row in table.rows: for cell in row.cells: for p in cell.paragraphs: for m in re.finditer(r\{\{.*?\}\}, p.text): hits.append(m.group()) return hits print(check_placeholders(合作协议_RJ-2024-027.docx))这段脚本只做读取不改文件安全。输出为空说明没有漏填的变量有命中说明模板或传参有问题应该回到渲染流程里修不要拿 Word 手动补否则下一份协议还会漏。5. 合作协议模板避坑五个高频问题的现象、原因与解决模板用久了问题多半不在法条上而在 Word 文档本身的细节里。下面五条是我在合作协议模板上踩过的最常见问题。5.1 模板里的占位符被拆成多个 run替换后原样保留现象在 Word 里明明写的是 {{ party_a }}渲染后原样保留Word 查找替换也找不到完整的变量。原因Word 的拼写检查、自动更正、字体切换会把一个完整单词拆成多个 run甚至拆成多个段落。解决办法是先把模板里所有变量写在一个独立段落里写完后全选清除格式确保变量是一个整体。更稳妥的做法是先用脚本读取确认from docx import Document doc Document(合作协议模板.docx) for i, p in enumerate(doc.paragraphs): if party_a in p.text: print(i, [r.text for r in p.runs])如果输出显示 run 被拆成了 [{{, party_, a}}]说明占位符在层级上就不完整docxtpl 解析不了。此时回到模板里重新输入该变量不要试图用代码硬修。5.2 直接用 python-docx 替换整段文本样式崩成默认格式现象协议正文原本是宋体小四用 python-docx 把段落 text 整个替换后字体变成 Calibri行距变单倍。原因直接给 paragraph.text 赋值会清空该段落原有的所有 run新 run 不继承原 run 的属性。解决不要在渲染阶段用 paragraph.text 做全段替换。要么在 run 级别精确替换要么直接用 docxtpl 渲染。如果只是检查文本内容就用只读脚本不做写操作。5.3 日期、金额格式不统一交出去才被发现现象同一份协议里出现 2024/1/5、2024-01-05、2024年1月5日三种写法金额小写没保留两位小数大写也缺位。原因旧协议模板里历史遗留格式太多加上 Word 自动更正对日期有自作主张的调整。解决在模板字段登记表里明确规定日期写法统一为“2024年01月05日”金额小写统一为 100000.00 这种字符串大写统一用“人民币壹拾万元整”。传参时全部用字符串数字格式化放在 Python 侧完成不要依赖 Word 自动格式。5.4 同一份 docx 在 Office 和 WPS 下版式不一致现象Office 里看正常的模板用 WPS 打开后页边距、字体、表格宽度全部变化保存后字段丢失。原因两个软件对 OOXML 里部分元素的解释不完全一致中文字体在两边的默认替换规则也不同。解决对外交付前固定两个事实。一是模板字体只使用常见中文字体不要用特殊字体特殊字体会在没装字体的机器上被静默替换二是最终签约版本转成 PDF 存档不要直接把 docx 发给对方反复打开保存。谁动了模板谁在变更记录里留下说明这也是避免版式漂移的底线。5.5 修订、批注和上一版残留一起交付现象协议文档里还留着隐藏的修订记录、批注或者旧协议编号没有清干净。原因模板是从老协议复制出来的改的时候只删了正文没检查审阅面板和文档属性。解决交付前用 Word 的“检查文档”清理个人和隐藏信息同时先接受所有修订、删除所有批注。再用正则扫描一遍编号规则例如搜 RJ-2023-命中就说明有上一版内容残留不要直接发出去。6. 进阶用文档属性做版本、用校验脚本做契约把模板变成长期资产做到这一步模板已经能跑起来但离长期维护还差一口气。最后这部分让模板在团队里真正沉淀下来。6.1 用文档属性做版本标记别把版本写进文件名文件名改成合作协议模板_v3_final 这种做法后期会很痛苦。我习惯把版本号写进 docx 的核心属性生成协议时把版本号带进输出文件让每份协议自带元数据。脚本如下from docx import Document from docxtpl import DocxTemplate tpl DocxTemplate(合作协议模板.docx) context { agreement_no: RJ-2024-030, project_name: 某跨平台系统升级, party_a: 甲方公司, party_b: 乙方公司, amount: 300000.00, amount_upper: 人民币叁拾万元整, start_date: 2024年10月01日, end_date: 2025年09月30日, } out_path 合作协议_RJ-2024-030.docx tpl.render(context) tpl.save(out_path) doc Document(out_path) cp doc.core_properties cp.title f合作协议 {context[agreement_no]} cp.subject 合作协议模板 v2.1 cp.author 合规组 doc.save(out_path)这里注意顺序先用 docxtpl 渲染并保存再重新打开设置属性并保存不要在渲染前改属性docxtpl 对象不保证 core_properties 的写入结果。这样生成的每份协议都带版本号后续追溯用了哪版模板直接看文件属性就行。6.2 渲染前先校验必填参数别等生成后才发现漏项多人共用模板时一定有人会漏传参数。我在脚本里加一个轻量校验函数缺少必填项直接抛错不生成文件。def validate_context(context): required [ agreement_no, project_name, party_a, party_b, amount, amount_upper, ] missing [k for k in required if not context.get(k, ).strip()] if missing: raise ValueError(f渲染前发现缺失参数: {missing})这个函数放在渲染脚本的最前面校验通过再执行后续逻辑。别看它简单作用是把错误提前到生成阶段而不是让一份缺甲方名称的协议流到签署环节。6.3 收尾习惯定版前跑一次扫描与对账协议是正式文本模板是工程资产。我给自己定的维护节奏是每季度做一次模板复审把业务侧新出现的字段补进字段登记表而不是临时改正文。定版对外发布前至少跑一遍占位符扫描和版本号检查确认没有残留变量、没有上一版编号、没有隐藏修订。我以前吃过一次亏把旧合同改名当模板结果把上一版的付款比例原样带给了新项目对方直接在协议里用红字标了出来。从那以后我给自己立了条规矩——任何模板在对外发布前先跑一次占位符扫描和版本校验多花两分钟后面省下来的不止两小时。希望帮到你。本文还有配套的精品资源点击获取