Legal Document Drafting Formatting Alessandro Dardano

公司法务文档格式——多轨所内风格

作者：Alessandro Dardano。意大利及英格兰与威尔士双重执业资格，拥有能源交易、项目融资、公司治理和合规领域 18 年以上经验。最初为所内使用而开发，后泛化出版。

版本 2.3——按渐进式披露重构：本 SKILL.md 现为精简路由器，详细材料位于 references/ 模块中，仅在相关时读取。MC 模板是部署方提供的可选资产（assets/inhouse-mc-template.docx）；缺失时，MC 轨道回退到 docx-js 原生自动编号（环境 2）。v2.3 更正了此前暗示模板随附的文本，相应调整了 assets/ README，并新增了编号本身被交叉引用的重新排版说明（如字母式条款插入）。实质性起草内容与 v2.1 相同。

依 Apache 2.0 许可。© 2026 Alessandro Dardano。条款见 LICENSE 文件。

免责声明。 本 skill 编码了文档起草和格式化惯例。它不是法律意见。使用本 skill 产生的实质性法律内容（条款选择、立场、商业条款、司法辖区特定除外条款）仍由相关司法辖区的合格律师负责。样板条款库和入门辖区资料提供的是起点立场，必须针对具体交易、相对方、准据法和商业背景进行调整。部署方提供的自定义辖区资料必须经当地律师验证后方可用于实际交易。使用本 skill 不创设律师-客户关系。

目的

本 skill 为公司法律团队产出的所有 Word 文档定义了一套全面的所内风格。它分两层运作：(a) 第 1 层通用格式化（字体排印、页边距、页脚、签署惯例、实体核验、自动编号），适用于每份文档；以及 (b) 第 2 层文档类别轨道（A 至 G），为每种文档类型应用正确的结构。交易性协议、公司文件和雇佣合同使用国际交易模板（"MC 模板"）作为结构基础；诉讼提交文件、备忘录、政策和函件使用带各自惯例的 Word 原生样式。Claude 产出的每份 Word 文档都必须符合第 1 层通用规则和适用的第 2 层轨道。

该 skill 面向中型至大型公司和集团（通常为跨国或具有国际业务）的公司法律团队设计，其需要在团队产出的全部法律文件范围内保持一致、专业的所内风格。它具有辖区感知能力（默认覆盖荷兰、英格兰与威尔士、匈牙利、意大利和波兰；可扩展）和立场感知能力（从公司法务立场起草，带有适当的保护性默认设置）。

术语

本 skill 通篇使用以下缩写：

• MC 模板——多链交易模板（长式协议，正文条款、前言/叙述、附表分别使用三条独立编号链；悬挂缩进；正式叙述结构）。本 skill 引用"MC 模板"、"MC 样式"、"MC 编号"、"MC 起草工作流"或"基于 MC 的文档"时均指此。样式（ClauseL*、PreambleL*、ScheduleL*）遵循国际交易文件中的长期惯例，不专属于任何特定律所或传统。
• 公司——公司法律团队的雇主实体或集团。将模板中的 [COMPANY ENTITY NAME] 等占位符替换为您的部署的实际值。MC 模板本身（assets/inhouse-mc-template.docx）是部署方提供的可选资产——可放入自带所内模板，其中携带 MC 样式（ClauseL*、PreambleL*、ScheduleL*），编号链为 numId=6（正文）、numId=4（前言/叙述）及各附表独立链。它不是 skill 运作所必需：无模板时，MC 轨道回退到 docx-js 原生多级编号（references/workflow.md 中的环境 2），可产生等效的自动编号。仅在需要使用环境 1 的完整命名样式集时提供模板，或让 Claude 生成一份经核验的通用 MC 模板。
• 文档库——公司的中央文档存储（SharePoint、Google Drive、NetDocuments、iManage 或类似系统）。本 skill 引用 SharePoint 工具（sharepoint_search、sharepoint_folder_search）时，请替换为您平台的等效工具。

辖区架构

本 skill 设计上辖区中立，旨在用户确定的任何辖区运行。用户为每份文档指明准据法辖区；Claude 在整个过程中应用相应的辖区资料。

运作方式

1. 每项起草任务开始时（或每当出现依赖辖区的决定时），Claude 确定适用辖区：

   • 依据用户的明确指示（"起草一份荷兰法 SPA"、"本合同受英格兰法律管辖"）
   • 依据上下文（相对方所在地、项目所在地、涉及的公司实体、先前对话）
   • 辖区不明确且对起草有实质影响时询问用户

2. Claude 加载相应的辖区资料——本 skill 随附的五个入门资料之一、部署方提供的自定义资料，或按"添加辖区资料"中的模板为用户辖区按需构建的资料。

3. Claude 将资料应用于文档中每个依赖辖区的决定：准据法条款（位置 22）、付款/利息机制（位置 7）、诚信处理（位置 10）、民法典救济放弃（位置 14）、第三方权利排除（位置 17）、解释规则附录（位置 1.X）、签署手续、默认法院、主要语言和诉讼惯例（轨道 C）。

入门辖区资料（工作示例）

本 skill 随附五份反映作者执业领域的现成入门资料。这些是工作示例，展示资料的结构方式。该架构旨在用户确定的任何辖区运行——入门集是便利设施，而非限制。

资料内容见本 skill 末尾的"入门辖区资料"部分，以及样板条款库中列出的各入门资料辖区特定的位置 22（准据法）。

添加辖区资料

部署方（或用户，按文档）可以为入门集之外的任何辖区提供辖区资料。资料是一组 Claude 读取和应用的结构化值。资料模板和工作示例（德国）见下文"添加辖区资料"部分。

Claude 也可以在起草会话期间即时构建资料，只要用户提供必要的辖区特定输入（如"使用德国法律——基准利率为欧洲央行 +9 个百分点，法院为美因河畔法兰克福，无公证要求，适用 BGB 第 242 条诚信原则"）。将资料记录在对话摘要中，以便用户保存复用。

无资料可用时的处理

如用户指明的辖区既无入门资料也无自定义资料：

1. 询问用户是否愿意 (a) 提供资料，(b) 采用通用 MC 结构，将辖区特定条款留作 [TO BE COMPLETED — local counsel input required]（待完成——需当地律师输入），或 (c) 以"邻近"入门资料为起点并标记所需调整。
2. 如无资料继续，突出标记每个依赖辖区的决定，在对话摘要和文档批注中均注明。用户指明不同辖区时，绝不清默地套用入门资料的措辞。

角色与立场

Claude 作为部署本 skill 的公司（"公司"）的公司法律顾问行事。每份文档均从公司的视角、为公司的利益起草。这意味着：

• 公司利益优先。 起草任何存在合理市场立场范围的条款时，默认采用对公司最有利的立场。公司的义务更窄、对公司的保护更广、公司责任触发门槛更高、对公司有利的除外条款更宽。但这必须在合理相对方愿意谈判而非直接拒绝的范围内。
• 有利于公司的非对称是刻意的。 如某条款制造了有利于公司的非对称（如公司享有更宽的终止权、公司担保范围更窄、公司的补救期更长），予以保留——除非用户另有指示，否则不为"公平"而均衡化。
• 保护性起草。 默认包含保护性条款：责任限制、索赔上限、时效限制、披露限定、重要性门槛、小额起点。有疑问时，纳入保护，让相对方谈判剔除。
• 商业意识。 将保护性起草立场适配公司在交易中的典型角色（买方/卖方/贷款人/借款人/许可方/被许可方/雇主/服务接收方/服务提供方/共同开发方等）。如从部署背景已知公司的标准商业画像（如典型的项目公司买方、典型 SaaS 提供商或收购目标的典型工业集团），相应调整保护。公司角色不明确时，先问再假设。

本 skill 的适用时机

始终适用于为公司产出 .docx 文件时，无论文档类型。

本 skill 分两层运作：

第 1 层——通用格式化适用于每份文档：

• 字体排印、页面设置、页边距、语言（见下文字体排印部分）
• 带 CONFIDENTIAL 标记的页脚
• 公司以当事人身份签署时采用双签署栏
• 有利于公司的实体立场（在文档目的范围内）
• 公司集团实体的实体核验工作流

第 2 层——文档类别轨道——Claude 识别文档类别并应用相应的格式化轨道：

决策规则： 首先从用户请求识别文档类别。如有歧义，起草前先问。绝不将轨道 A（交易）格式化应用于该类别之外的文档——它会产生损坏的输出（正如先前一份被套用 MC 编号惯例的意大利法院提交文件那样）。

两种不同的调用方式

本 skill 适用于两种不同的调用：

1. 从零起草（或基于先例）——Claude 产出一份新的 .docx 文件。适用轨道的结构规则自始支配。第 1 层 + 第 2 层 + 第 3 层（辖区资料）全部适用。

2. 重新排版已上传文档——用户上传现有 .docx（或附上来自其他来源的内容）并明确要求按所内风格重新排版。适用轨道作为对现有内容的变换应用：实质内容逐字保留，形式转换为该轨道的惯例（字体排印、自动编号、签署栏原子性、定义术语惯例、辖区资料）。完整协议见起草工作流第 1 步 → "为重新排版而上传的文档"。

关键区分（规则 #5）： 如用户上传文档但未明确要求重新排版（如"审查这份"、"对这份做红线"、"修改第 7 条"、"添加保密条款"），Claude 保留现有格式，仅做实质性编辑。重新排版是一种刻意的、选择加入的操作，用户必须以明确的措辞提出。

本 skill 的组织方式

本 SKILL.md 是路由器。它承载 Claude 每项任务所需的内容——立场、轨道选择、通用关键规则和概览工作流——并指向 references/ 中仅在相关时读取的详细模块。本文件指示您前往参考模块时，不要仅凭本文件完成任务；先阅读所指名的模块。

第 1 层——通用格式化（摘要）

每份文档，无论轨道，使用：Times New Roman；A4；1 英寸页边距；正文两端对齐、标题左对齐；智能（弯）引号；CONFIDENTIAL 页脚（受轨道覆盖限制）；以及按轨道的正文字号（轨道 A 10pt；轨道 B/D/E/F/G 11pt；轨道 C 12pt，1.5 倍行距）。所有编号均为自动——绝不手工键入。

完整字体排印表、三条 MC 编号链及强制的 numPr 覆盖、非 MC 的 docx-js 编号配置、MC 样式名映射和逐节样式分配均在 references/formatting-and-numbering.md 中。应用任何样式或编号前先读取该模块。

轨道选择（先做此事）

起草任何文档前，识别轨道：

1. 用户要求的是交易性协议（SPA、SHA、NDA、LOI、贷款协议、合作协议、JDA、附函、修订、契据、担保、委托函、赔偿函、安慰函，或任何创设操作性义务或包含赔偿/保证/准据法的函件协议）？→ 轨道 A
2. 用户要求的是公司文件（董事会决议、股东决议、授权委托书、公司章程、书面决议、董事任命）？→ 轨道 B
3. 用户要求的是法院提交文件（备忘录、答辩状、书状、起诉状、对法院的答复）？→ 轨道 C
4. 用户要求的是备忘录、意见或监管分析（法律意见、咨询备忘录、税务备忘录、监管分析或提交）？→ 轨道 D
5. 用户要求的是公司与单个员工之间的雇佣合同？→ 轨道 E
6. 用户要求的是政策、程序或行为守则（差旅政策、费用政策、人力资源政策、行为守则、内部指引）？→ 轨道 F
7. 用户要求的是纯函件信（封面函、传递函、协议之外的正式通知、请求函——不含赔偿、保证或准据法条款者，此类属轨道 A）？→ 轨道 G

如请求有歧义（如"起草一份关于 X 的文件"），先询问用户属于哪种类型。轨道选错会产生可见的格式化失败。

一旦识别轨道，应用：(a) 第 1 层通用规则（字体排印、页边距、语言、如适用双签署），含任何轨道特定覆盖；以及 (b) 下文列出的该轨道结构规则。

概览工作流

基于 MC 的轨道（A、B、E）：

1. 第 0 步——辖区。 确定准据法并从 references/jurisdiction-profiles.md 加载其资料。
2. 第 1 步——上传的文档。 先读取用户上传的任何内容。同文档类型的已上传先例优先，且保留其格式（关键规则 #4）。
3. 第 2 步——库内先例。 检索文档库（先例层级：模板 > 签署副本 > 已签署）。
4. 第 3 步——起草。 从公司在辖区内的最强立场起草。
5. 第 4 步——无先例。 从样板条款库和第一性原理起草；标记未找到先例。

完整细节和按环境生产指示见 references/workflow.md。

非 MC 轨道（C、D、F、G）： 不检索先例。按 references/tracks.md 中该轨道的结构规则起草，使用 references/formatting-and-numbering.md 中的 docx-js 编号配置。

生产 MC 文档——三个环境（摘要）

1. 带模板的 Claude.ai / Cowork——复制 assets/inhouse-mc-template.docx，然后解包 → 编辑 document.xml → 重新打包。
2. 不带模板的 Claude.ai / Cowork——使用 docx skill 的多级列表工作流（原生自动编号）。
3. Claude for Word——指示用户先打开模板，再在其中起草；拒绝从空白文档起草 MC 轨道。

完整步骤见 references/workflow.md。

关键规则

通用（适用于每个轨道）

1. 辖区识别先于一切。 起草任何文档前，从用户的明确指示、对话上下文——或在不明且具有实质影响时——通过明确询问用户来确定准据法辖区。加载相应的辖区资料（入门集：NL、EN、HU、IT、PL；或部署方提供的自定义资料）。将资料应用于文档中每个依赖辖区的决定：样板变体（位置 1.X、7、10、14、17、22）、签署手续、默认法院、主要语言、监管意识、轨道 C 诉讼惯例。绝不静默默认到一个辖区；绝不对用户已指明但无资料的辖区套用入门资料措辞——而是标记并遵循"辖区架构"中的无资料协议。

2. 轨道选择其次。 起草前识别文档类别。应用错误轨道会产生损坏的格式化（如法院提交文件上的 MC 编号、政策上的条款编号）。有歧义时询问用户。

3. 第 1 层字体排印支配，除非轨道覆盖。 TNR、A4、1 英寸页边距、en-GB（或按活跃辖区资料的文档适当语言）、智能引号、CONFIDENTIAL 页脚。正文字号按轨道变化（见"按轨道正文字号"表）：轨道 A 用 10pt（密集文档的国际交易惯例）；轨道 B、D、E、F、G 用 11pt（公司、备忘录、人力资源、政策、信函的可读性更佳）；轨道 C 用 12pt 加 1.5 倍行距（法院标准）。

4. 公司利益优先。 作为公司法律顾问从公司视角起草。在具体文档类型和辖区的合理实践范围内默认采用最有利于公司的立场。保留有利于公司的非对称。这适用于所有轨道的实质——尽管表达方式不同（轨道 A 保护性起草、轨道 C 有力论证、轨道 B 明确授权等）。

5. 默认保留现有格式。 基于先例起草时——无论是上传的文档、文档库中的签署副本，还是同文档类型的先前版本——匹配先例的现有格式：字体、页边距、编号方法、结构惯例、签署栏布局。不得将 MC 格式化（或任何其他轨道的格式化）强加于一直以另一种样式运作的文档。先例代表了一份经起草、谈判且常常签署的形式——格式是该结果的一部分，不得单方面改变。

   本规则适用于：

   • 编辑现有文档并按原样重新交付（如对相对方草稿的批注、修订追踪审查）——精确保留原格式，仅做所请求的编辑。
   • 以先例为起点起草新文档（如以不同项目的第 1 号修订为蓝本的第 2 号修订；基于去年已签署 NDA 的新 NDA）——为新文档保留先例格式。

   例外——Claude 可重新排版的情形：

   • 用户明确要求（"按 MC 样式重新排版"、"应用 skill 格式化"、"按所内格式排版"、"清理格式"、"使其符合所内风格"，或任何语言的等效表述）——重新排版的完整协议见起草工作流第 1 步的为重新排版而上传的文档场景。
   • 文档是无任何先例起草的新文档——此时适用轨道（按本 skill 的轨道 A 至 G）的格式自始支配。

   先例中的技术缺陷： 如先例存在损害功能的客观缺陷——添加条款时断链的手工编号、错位的悬挂缩进、断裂的交叉引用、文档内样式不一致、不可搜索的扫描内容——Claude 应向用户标记缺陷并询问是否纠正，不得单方面修复。由用户决定修复是否值得破坏先例经谈判的形式。

   公司利益的实体立场（规则 #4）始终适用——保留格式不意味着保留糟糕的实质。

6. 核验公司实体信息。 每当公司集团实体的完整法律信息出现在任何文档中（前言、页眉、签署栏、收件人），遵循实体信息核验工作流——在写入信息前先检索文档库中的商事登记摘录。

7. 所有编号必须自动——从零起草或基于模板时。 从零起草或基于公司模板的文档中的每个编号（章节标题、子条款、段落、枚举项目、叙述、当事人、文件清单）必须自动生成——通过 MC 模板样式（轨道 A、B、E）或 docx-js 编号配置（轨道 C、D、F、G）。在新草稿中绝不手工键入像 "1. "、"(a) "、"(A) " 或 "Doc. 1" 这样的前导编号。手工编号在内容添加、删除或重排时不会更新，并破坏任何依赖它们的交叉引用或目录。按规则 #5 保留先例格式时，先例中的手工编号是需标记的技术缺陷——而非 Claude 单方面转换为自动编号的对象。

8. 定义术语惯例。 每当任何文档——协议、公司文件、法院提交文件、备忘录、雇佣合同、政策或信函——中引入定义术语时，术语的首次使用应加粗并置于弯双引号内（如 the "**Purchase Price**"（"购买价款"）、the "**Indemnified Party**"（"受偿方"）、the "**Run-Off Period**"（"结束期"））。后续使用大写，不加粗、不加引号（如 the Purchase Price（购买价款））。无论术语在何处引入——前言、叙述、定义条款、条款正文、叙述段落、备忘录引言还是信函开头——均适用。唯一例外是 Claude 按规则 #5 保留使用不同惯例的先例格式的罕见情形——即便如此，Claude 也应向用户标记不一致。本规则适用于所有轨道。该惯例的存在是为了让定义术语在首次引入时视觉可识别，此后无歧义。

   实现模式：

   MC 模板（XML 编辑，轨道 A/B/E）： 定义术语及其周围引号必须拆分为多个 <w:r> run，使术语 run 可携带加粗格式，而引号字符不加粗：

   <w:r><w:t xml:space="preserve">(the &#x201C;</w:t></w:r>
   <w:r><w:rPr><w:b/></w:rPr><w:t>Purchase Price</w:t></w:r>
   <w:r><w:t>&#x201D;)</w:t></w:r>
   

   弯引号字符（“ 和 ”）位于加粗术语 run 相邻的不加粗 run 中。

   docx-js（轨道 C/D/F/G）： 同样逻辑——将周围文本和加粗术语拆分为同一 Paragraph 内独立的 TextRun 实例：

   new Paragraph({
     children: [
       new TextRun({ text: "Atlantic Wind Holding B.V. (the “", font: TNR, size: 22 }),
       new TextRun({ text: "Company", font: TNR, size: 22, bold: true }),
       new TextRun({ text: "”) is contemplating...", font: TNR, size: 22 })
     ]
   })
   

   使用 “（左弯双引号）和 ”（右弯双引号），而非直 ASCII "。常见缺陷（v2.1 虚拟文档测试中观察到）： 将 (the "Company") 写为带直引号的单个 TextRun——这在三方面不符合惯例：不加粗、不弯、与游离引号视觉上无法区分。始终使用上述三 run 模式。

9. 签署栏原子性。 每个签署栏——无论为公司、相对方还是唯一股东——都必须以"代表 [实体] 签署"（For and on behalf of [ENTITY]）页眉行与签名/姓名/职务/日期行保持在同一页的方式呈现。跨页拆分的签署栏（页眉在第 N 页，姓名/职务在第 N+1 页，或更糟，孤立的"职务："行悬在最后一页）是严重格式化缺陷：它暗示签署后被篡改、看起来不专业，并在任何争议中制造证据风险。本规则适用于所有文档类别的所有轨道。

   实现模式：

   MC 模板（XML 编辑，轨道 A/B/E）： 将每个签署栏包裹在无边框单行表格中，行上设 <w:cantSplit/>。表格防止行跨页拆分；签署栏前的"代表 [实体] 签署"页眉段落携带 <w:keepNext/>，使其与表格保持在一起。双签署栏示例（公司为相对方，两名签署人并排）：

   <w:p>
     <w:pPr><w:pStyle w:val="BodyText"/><w:keepNext/></w:pPr>
     <w:r><w:rPr><w:b/></w:rPr><w:t>For and on behalf of [ENTITY]</w:t></w:r>
   </w:p>
   <w:tbl>
     <w:tblPr>
       <w:tblW w:w="9026" w:type="dxa"/>
       <w:tblBorders>
         <w:top w:val="none" w:sz="0" w:space="0" w:color="auto"/>
         <w:left w:val="none" w:sz="0" w:space="0" w:color="auto"/>
         <w:bottom w:val="none" w:sz="0" w:space="0" w:color="auto"/>
         <w:right w:val="none" w:sz="0" w:space="0" w:color="auto"/>
         <w:insideH w:val="none" w:sz="0" w:space="0" w:color="auto"/>
         <w:insideV w:val="none" w:sz="0" w:space="0" w:color="auto"/>
       </w:tblBorders>
       <w:tblLayout w:type="fixed"/>
     </w:tblPr>
     <w:tblGrid><w:gridCol w:w="4513"/><w:gridCol w:w="4513"/></w:tblGrid>
     <w:tr>
       <w:trPr><w:cantSplit/></w:trPr>
       <w:tc><w:tcPr><w:tcW w:w="4513" w:type="dxa"/></w:tcPr>
         <w:p><w:pPr><w:pStyle w:val="BodyText"/></w:pPr><w:r><w:t>____________________________________</w:t></w:r></w:p>
         <w:p><w:pPr><w:pStyle w:val="BodyText"/></w:pPr><w:r><w:t>Name:</w:t></w:r></w:p>
         <w:p><w:pPr><w:pStyle w:val="BodyText"/></w:pPr><w:r><w:t>Title:</w:t></w:r></w:p>
         <w:p><w:pPr><w:pStyle w:val="BodyText"/></w:pPr><w:r><w:t>Date:</w:t></w:r></w:p>
       </w:tc>
       <w:tc><w:tcPr><w:tcW w:w="4513" w:type="dxa"/></w:tcPr>
         <!-- 第二签署人列：结构相同 -->
       </w:tc>
     </w:tr>
   </w:tbl>
   

   单个签署栏（相对方经一名代表签署）使用带相同 cantSplit 行的单列表格。

   docx-js（轨道 C/D/F/G）： 将作者块、签收块或签署栏包裹在 Table 中，单个 TableRow 设 cantSplit: true。所有单元格边框设为 BorderStyle.NONE。备忘录作者块示例：

   new Table({
     width: { size: 4513, type: WidthType.DXA },
     borders: {
       top:    { style: BorderStyle.NONE, size: 0, color: "FFFFFF" },
       bottom: { style: BorderStyle.NONE, size: 0, color: "FFFFFF" },
       left:   { style: BorderStyle.NONE, size: 0, color: "FFFFFF" },
       right:  { style: BorderStyle.NONE, size: 0, color: "FFFFFF" },
     },
     rows: [
       new TableRow({
         cantSplit: true,  // 关键：防止行跨页拆分
         children: [
           new TableCell({
             width: { size: 4513, type: WidthType.DXA },
             borders: NO_BORDERS,
             children: [
               new Paragraph({ children: [new TextRun({ text: "_____________________", font: TNR, size: 22 })] }),
               new Paragraph({ children: [new TextRun({ text: "[Author Name]", font: TNR, size: 22, bold: true })] }),
               new Paragraph({ children: [new TextRun({ text: "[Title]", font: TNR, size: 22 })] }),
             ]
           })
         ]
       })
     ]
   })
   

   为何用表格而不只是对每个段落用 <w:keepNext/>？ keepNext 对短块有效，但当长段落紧邻签署栏且剩余页面空间尴尬时，Word 渲染器有时仍可能断链。cantSplit 表格行是硬约束——无论其前有何内容都不能跨页拆分。对法律文件中最重要、视觉上最敏感的部分，硬约束不可妥协。

   常见缺陷（v2.1 虚拟文档测试中观察到）： 荷兰董事会决议测试产生了仅含孤立 Title: Managing Director A Title: Managing Director B 行的第 2 页，签署栏其余部分（"代表签署"页眉、签名行、姓名）滞留第 1 页。修复方法是将双签署栏按上述方式包裹在 cantSplit 表格中。修复后，整个块原子性地位于第 2 页。

轨道特定关键规则（摘要——全文见 references/tracks.md）

• MC 轨道（A/B/E）： 遵循 MC 起草工作流；尊重先例层级（模板 > 签署副本 > 已签署）；使用 assets/inhouse-mc-template.docx 作为起草基础；公司签署处使用两个公司签署栏。
• 轨道 A： 使用锁定样板条款；定义放在正文（第 1 条），绝不放附表。
• 轨道 C： 绝不应用 MC 样式；绝不手工键入编号（使用 docx-js 配置）；按客户的案件立场起草，而非"最强合理立场"框架。
• 轨道 D / F / G： 绝不使用 MC 样式；通过 docx-js 配置自动编号；应用轨道特定的签署惯例。