微信小程序合规避坑卫士

概述

当用户在微信小程序项目里处理支付分账、非雇佣协议、个保法敏感信息、协议版本管理时，先按本 skill 核对，避免把"看起来对"但事实错、合规错的条款写进正式文件。

何时用本 skill

• 起草/改写「平台 × 自由职业者（喂养师、骑手、家政、站长等）」合作协议，且强调非雇佣关系
• 接入微信支付、设计分账比例、写分账回调/逆向清算代码、申请或配置商户号
• 涉及人脸核验、无犯罪记录证明等个人信息收集
• 用 python-docx 改协议正文、维护同一套协议的多个版本

三大高频致命坑（动手前必查）

坑一：分账比例超微信原生分账 30% 硬上限

微信原生分账给接收方的比例合计 ≤ 30%（央行防穿透规则），超过就要走银行专户/电商收付通等重方案。

• 错误写法：「平台抽成 + 服务商抽成」合计 >30%，却写"走原生分账"
• 正确做法：把非平台方（服务提供者+城市代理等）合计控制在 ≤30%。例：喂养师 71% + 站长 15% + 平台 14%（非平台方共 86%，由平台持有后分；平台自身留 14%）
• 详见 [references/payment_compliance.md](references/payment_compliance.md)

坑二：资金流事实写反（二清红线）

• 用户常说"钱不进我们账、由微信平台收和分"——这是对的方向（一清架构）。
• 但"微信平台分账"的前提是必须有一个商户号主体在微信侧驱动分账（自持/服务商/子商户），不存在"零主体、微信直接分"。
• 协议第五条应写："微信支付平台统一收取并分账，甲方不代收、不沉淀资金，仅收取信息技术服务费"。绝不要写"甲方统一代收代付/甲方代为收取"。
• 详见 [references/payment_compliance.md](references/payment_compliance.md)

坑三：强制收集个保法高风险敏感信息

• 人脸是顶格敏感信息 → 不自采，复用微信平台实名（底层已含人脸核验），协议写"微信平台实名认证（含人脸核验）"。
• 无犯罪记录证明属高风险敏感信息 → 不要强制乙方提交公安证明。改走"乙方本人承诺无相关犯罪前科 + 平台在法律允许范围内开展线上风控核验"。
• 详见 [references/non_employment_protocols.md](references/non_employment_protocols.md)

标准工作流

1. 先建/查「单一事实源」：所有协议的核心条款（主体名、电话、分账比例、敏感信息策略、保险/税务/管辖）只在一处定义，改动先改源头再联动同步。见 [references/non_employment_protocols.md](references/non_employment_protocols.md) 的"核心条款单一事实源"模板。
2. 支付相关：按 payment_compliance.md 核对商户号身份、分账比例、开通分账产品、逆向清算。
3. docx 改动：用 [scripts/insert_docx_clause.py](scripts/insert_docx_clause.py) 安全插入条款；改前先 Read 真实文本，zip 内文件用 unzip -p 比对而非 grep 管道。见 [references/engineering_pitfalls.md](references/engineering_pitfalls.md)。

参考文档

• references/payment_compliance.md — 二清红线、原生分账≤30%、商户号三种身份、逆向清算、商户号申请避坑
• references/non_employment_protocols.md — 非雇佣协议核心条款单一事实源、人脸/无犯罪证明/保险/税务/管辖口径、版本联动规则
• references/engineering_pitfalls.md — docx 安全插入脚本用法、Edit/Read 规范、zip 内 grep 误报规避

脚本

• scripts/insert_docx_clause.py <docx路径> <锚点段落前缀> <新段落完整文本> — 在某段落（如"6.4"）后安全插入新段落并保留原排版。