平台封号维权文书套件 · 通用版

把一个"我被平台处理了"的模糊诉求，拆成一套能被法院收下的立案材料。

不限平台。 内容社区、社交、电商、直播、游戏、工具类平台——凡是"用户 vs 平台"的
网络服务合同纠纷，方法一致。差异只在两处：协议要你自己下载，
条款要你自己检索（本套件提供完整流程与方法论，但不预置任何平台的协议原文）。

核心原则：不预设。 每个用户的争议事由、账号状态、想要的结果都不一样，所以本套件
不内置任何固定的"事实与理由"叙事，也不内置任何固定的诉讼请求。它提供的是四样东西：
提问框架（把用户自己的事问清楚）、诉求推导树（把用户想要的结果翻译成合法诉请）、
文书结构骨架（把事实装进法院认的格式）、校验清单（把破绽在开庭前找出来）。

绝大多数失败案例死在两处：事实没讲清（时间线断裂、逻辑跳跃）、证据没对上
（证明目的与诉请脱钩、原始载体灭失）。本套件用提问堵住第一处，用证据盘库与三性自检堵住第二处。

> 与专用实现的关系：若你要处理的平台已有专门实现的版本（内置该平台协议全文与
> 实测条款库，技能名通常直接点出平台名），优先用那一套——它的条款库是已逐字核对过的现成成果。
> 本通用版的价值是换任何平台都能开工。

一、适用与不适用

适用：平台封禁、限流降权、强制改名、内容删除、账号处置等引发的争议，不限平台。
不预设用户是内容被误判、被算法自动处置、商家号被处理、还是涉 AI 生成内容标识问题——
一律由第二阶段提问问出来。

不适用，转交或劝退：
- 账号本身确有确凿违规（售假、引流、擦边、侵权）——先做坦白的胜诉率评估，不鼓动起诉
- 争议焦点为知识产权、刑事、涉外、资本市场——超出本套件能力，直接建议专科律师
- 用户只想"出口气"、不接受无偿付能力或无管辖权的现实——先做预期校准（见第五阶段）

与专家协作：若当前会话已选择「中文法律咨询团」（林律师团队），法条检索与判例检索
必须交由该团的法条研究员、判例研究员完成；本套件只负责案情结构化、文书架构与排版格式。
不得自行编造法条与案号。

二、四条铁律（越线即视为任务失败）

1. 不虚构事实。 所有时间、金额、账号 ID、昵称、案号一律来自用户表述或其上传材料。
   用户没说的，写 【待补充：具体内容】 占位，禁止用"典型值""常见情况"填充，
   禁止替用户推测动机、补全情节、润色成更"有利"的版本。
2. 不伪造证据。 不生成、不合成、不修改任何截图；不改时间戳；不代写聊天记录；
   不把"用户说自己有截图"当作"已有该证据"。只做三件事：告诉用户去哪个页面截、
   截什么要素、怎么固定（公证 / 区块链存证）。
3. 不虚构法条与判例，也不虚构条款。 法条须写全"法律名称 + 条号 + 条文摘要"；
   判例须有案号或明确标注来源与"案号待核实"；平台协议条款必须逐字抄录自官方文本，
   条款定位必须真实存在。检索不到就如实写"未检索到"或"未就该事项作出规定"——
   如实留白，绝不脑补。
4. 不隐瞒 AI 参与、不推卸核实责任。 依《最高人民法院关于依法审理涉人工智能纠纷案件的意见》
   （法发〔2026〕10号）第 19 条，当事人提交由人工智能生成的诉讼文书、案例检索报告等材料，
   应当在提交前核实其中法律、司法解释、案例内容的真实性与准确性，在提交时对使用人工智能
   辅助的情况作出说明，并对内容真实性、准确性依法承担责任。因此本套件每一套输出都必须
   同时生成一份《AI 辅助使用说明》，并完成真实性核验清单。不得以"AI 幻觉""技术中立"
   为由免除核实责任——这是官方的明确口径。

兜底条款：报告中每一条法律结论都必须能回溯到某个法条编号、案号或条款位置；
回溯不到，就不是结论，是猜测，必须标 【待核实】。

三、工作流总览

阶段 1 信息不足时必须暂停并向用户提问，不得带着空缺直接成文；
若用户明确要求先出稿，成稿须在显著位置标注「基于有限信息的初步分析」。

四、交互引导逻辑（本套件的核心）

4.1 五轮提问，每轮 ≤5 问

提问必须是"能改变文书写法"的问题。每个问题配三件套：为什么问（让用户理解重要性）、
示例答法（降低表述门槛）、追问触发条件。问题本身不预设答案——
示例只是格式示范，不是事实模板。

第一、三、四、五轮的详细脚本见 references/01-案情采集问卷.md。

第二轮要点（最容易被忽略，也最影响成稿质量）：必须问出三件事——
1. 平台的处置通知原文写了什么（让用户原样复制，不要转述）；
2. 是人工审核还是算法自动判定（用户通常能从"秒拒""系统判定""找不到人工通道"判断出来）；
3. 处置范围：全账号封禁 / 仅限流降权 / 单篇内容被删 / 被强制改名。

这三件事直接决定走哪条叙事框架、主攻哪个审查层次（见 5.1）。

同时要问出平台身份（本通用版特有）：平台名称、运营主体（用于确定被告与管辖）、
以及该平台对外公示规则的位置（App 内协议页 / 官网规则中心）——
2.4 阶段要用。

4.2 五张检查清单（引导的骨架）

• 清单 A · 立案前材料完整性——见 references/01
• 清单 B · 证据三性自检（每份电子数据证据连问四句）——见 references/01
• 清单 C · 诉请可行性自检——见 5.0 与 references/01
• 清单 D · 材料真实性与 AI 合规核验（依意见第 19 条）：
• [ ] 每一条法条：法律名称 + 条号 + 摘要是否与官方现行文本一致？标 【待核实】 的是否已核实？
• [ ] 每一则判例：案号是否可核？标"案号待核实"的是否已注明来源？有无 AI 编造的案号或裁判要旨？
• [ ] 每一处事实：是否都能回溯到用户提供的材料？有无为行文顺畅而"补全"的内容？
• [ ] 每一份证据：是否为原始文件，未经裁剪、拼接、时间戳修改？
• [ ] 是否已生成《AI 辅助使用说明》并准备随材料提交？
• [ ] 是否已删除所有无法核实的"参考判例"？
• 清单 E · 协议条款引用自检（每引用一条平台条款，连问六句，详见 references/06）：
• [ ] 原文：是否逐字对照协议全文或原件抄录？有无截半句改变语义？
• [ ] 定位：条款定位是否真实存在？原文无条款编号的（常见于"公约""准则"类文本）
  只能写"章节 / 板块 + 主题段"，禁止写成"第 X 条"
• [ ] 性质：该条是 🟢有利 / 🟡双刃 / 🔴不利？引用的这一条有无对己不利的后半句被漏掉？
• [ ] 对象：该条文的适用对象是否涵盖本案用户？（经营类条款的约定对象常是商家与品牌，
  不得套用于普通内容分享用户）
• [ ] 版本：所引条款在处置行为发生日是否已生效？有无拿处置后新增/修改的规则回溯评价之前的行为？
• [ ] 机检：是否已运行 scripts/verify_term_quotes.py 且退出码为 0？

4.3 引导红线：只建议，不代劳

如实披露义务：若检索到同平台 / 同被告的败诉先例，必须在证据册的风险部分披露，
并写明可主张的区分点。隐瞒不利判例等于把当事人送进法庭挨打。

五、文书的生成步骤与格式要求

详细结构与字段规范见 references/02-文书结构与格式规范.md，此处为执行骨架。

5.0 诉求推导树（先推导，再动笔）

禁止从模板里挑一组诉请套用。诉请从三个已知量推导出来：

输入① 争议类型（平台指控什么、怎么处置的）
输入② 账号当前状态（仍封禁 / 已恢复 / 已注销）
输入③ 用户想要的结果（按优先级排序）
            ↓
输出：诉请组合 = 行为请求 + 确认请求 + 给付请求 + 费用负担

诉请菜单（按需取用，不预设必选）：

不建议列入（应主动向用户说明原因）：注销账号 / 删除个人信息（已有判例倾向否定）、
赔礼道歉与精神损害赔偿（合同纠纷中通常不获支持）、惩罚性赔偿（除经营者欺诈等法定情形）。

备位诉请机制：对支撑度为"中/弱"的诉请，改为递进写法——
「判令被告支付【有票据的实际损失】；如不予支持，判令被告就封禁期间的流量损失
以平台推广资源方式补偿」。让法院即使否定主位主张，也有裁量空间。

诉请表述注意：账号所有权通常在协议中归属平台，用户仅有使用权——
诉请应写"恢复账号使用权限"，而非"返还账号所有权"。

5.1 事实与理由：按争议类型选择叙事框架

不预设固定叙事。先按第二轮问出的争议类型选框架，再用第三轮的时间线往里填。

通用写法要求：
- 每一段指控后面必须括号挂上证据编号
- 用户的否认必须原样写足、加粗
- 有利事实要具体到可验证的程度（时间、时长、次数）
- 不得隐去对自己不利的事实——起诉状不是广告，庭上会被拆穿

5.2 起诉状 / 5.3 证据目录 / 5.4 证据册

三者的结构、字段规范、分组要求、排版参数见 references/02。此处只强调三条纪律：

1. 证据目录的"证明目的"必须能回溯到某一条诉请或抗辩点；回溯不上的证据删掉，不要用数量凑声势。
2. 证据册必附"司法三层审查框架"与"须如实披露的诉讼风险"。
3. 参考判例必须分组呈现（正向 / 规则确立 / 损失量化 / 不利 / 同平台）。
   只挑有利判例的检索报告是不合格的。

5.5 脚本化生成

文书量大、格式要求细（中文字体、表格底色、PDF 证据转图），逐份手搓极易崩格式。
用 scripts/gen_litigation_docs.py：喂一份 JSON 案情清单，一次输出全套 docx。

python scripts/gen_litigation_docs.py --case assets/example-case.json --out ./deliverables/platform-ban-litigation

依赖：pip install python-docx（必需）；pip install PyMuPDF Pillow（可选，用于把 PDF 证据自动转图插入）。

脚本已内置依赖自举：检测不到 python-docx 时会自动尝试安装；若装不上，
会打印当前解释器下可直接复制的 pip 命令并以退出码 2 结束——不要因缺依赖回退成手写 docx，
那会破坏版式规范。PyMuPDF 缺失时不会静默跳过，会在标准错误流给出警告并说明哪份 PDF 未转图。

换机器/换使用者时若报依赖错误，优先换一个已装好 python-docx 的解释器执行，而不是改脚本。

输入 JSON 的字段：cause / dispute_type / court / case_no / plaintiff / defendant / claims[] / facts[{heading,paragraphs[]}] / laws[{title,text}] / jurisdiction[] / evidences[{num,name,form,purpose,note,file}] / evidence_groups[] / precedents[{group,title,court,source,holding,similarity,note}] / terms_source{} / terms_clauses[{no,source,locate,text,nature,effect,support,caution}] / term_conflicts[{no,left,right,conflict,usage,verified}] / term_risks[{no,locate,risk,response}] / risks[] / ai_assist{} / sign_date。参考 assets/example-case.json。

产出：01-民事起诉状.docx / 02-证据目录.docx / 03-证据目录及证据册.docx / 04-起诉状.md / 05-AI辅助使用说明.docx / 06-平台协议条款清单.docx / 06-平台协议条款清单.md。

只重跑某一份（避免覆盖已手工修订的文书）：

python scripts/gen_litigation_docs.py --case case.json --out ./out --only terms
python scripts/gen_litigation_docs.py --case case.json --out ./out --only book,ai

--only 接受逗号分隔的 complaint / catalog / book / md / ai / terms，省略则全跑。
注意：terms 依赖 terms_clauses 字段，缺失时报错并提示补字段，不会静默跳过。

脚本内的关键坑（已在实现中规避）：
- 中文字体必须同时设 w:eastAsia，否则中文回退成等线体
- PDF 证据用 PyMuPDF 按 150dpi 转图后插入，高度超过 20cm 需等比缩放
- 截图统一按 15cm 宽插入并居中
- 缺失的证据文件不中断生成，改在证据册中以红字标注 【缺件】，末尾打印缺件数量——
缺件就是证据链断裂点，必须补齐后重新生成
- 表格需 set_fixed_widths() 固定列宽，否则 Word 会自动重排列宽导致版式错乱

5.6 AI 辅助使用说明（依意见第 19 条，必产）

每套材料必须同时生成一份《AI 辅助使用说明》，随材料一并提交法庭。内容包含：
使用了哪些 AI 工具、AI 参与了哪些环节（检索 / 起草 / 排版）、由谁做了哪些核实、
核实方式与核实结论、真实性责任承担声明。模板见 references/05。

5.7 平台协议条款清单（阶段 2.5 的产物）

目的：这类案件最有力的材料不是法条，而是被告自己写的文本与自己的行为之间的落差。
本产物把本案平台的协议文本中对用户有利、相互矛盾、被平台自己违反的条款，
整理成一份可当庭引用的清单。

前置：阶段 2.4 协议准备（本通用版必做）

本套件不预置任何平台的协议原文（版权 + 时效两重原因）。先按
references/platform-terms/README.md 的四步完成准备：

1. 获取——从平台 App 内协议页 / 官网规则中心 / 协议域名下载，记录获取日期与来源 URL；
2. 导出——文本型 PDF 直接提取；网页型复制正文；图片型 PDF 必须视觉转录（纪律见该文档）；
3. 固定——对原件计算 SHA-256，填入协议状态表；
4. 命名——统一为 references/platform-terms/<协议名>-全文.md。
   命名是硬要求：引文校验脚本靠这个命名识别来源。

> ⚠️ 不要跳过这一步去引用记忆中的条款。 平台会改规则，凭印象写的条款
> 一旦对不上原文，整份清单在庭上会被推翻。

生成步骤：
1. 按 references/06 第一节的检索四步法命中条款（三路取词，缺一路会漏条款）
2. 每条命中条款答完四问（性质 / 用途 / 原文逐字 / 表述注意）才可入清单
3. 从 references/06 第五节的矛盾模式清单 CM1–CM12 中择取本案实际命中的项，填入 term_conflicts
4. 从第六节的不利条款模式清单 U1–U12 中逐项自查，填入 term_risks——不得为空
5. 把本案协议的名称与版本填入 terms_source（用于生成清单的检索声明：
objects_text / incorporation / quote_note / scope / transcription_note）
6. 写入 JSON 的 terms_clauses / term_conflicts / term_risks，跑 --only terms
7. 强制校验（提交法庭前的守门人，非可选）：

python scripts/verify_term_quotes.py --case case.json --terms references/platform-terms

校验器逐条比对清单中的条款原文是否真的逐字存在于协议全文中，并检查定位规范性与清单结构。
校验未通过（退出码非 0）时，引文异常的条款不得写入诉讼文书。
引文允许的两类整理标记：……（省略原文内容，如链接、中间各项）、／（原文为分行列举，
引文并作一行）；除这两类标记外，每一个字符都必须能在原文中找到。

清单的硬性要求：
- 🟢 有利条款优先排序在前，但清单里必须同时出现 🟡 和 🔴 条目——只有有利条款的清单是无效清单
- 条款原文逐字，不改标点、不截半句、不把"不鼓励"引成"禁止"
- 原文无条款编号的（常见于"公约""准则"类文本），定位写"章节 / 板块 + 主题段"；
写成"第 X 条"即为杜撰（校验器会直接判失败）。哪些协议无编号，在
references/platform-terms/_sources.json 的 no_clause_number 中声明
- 每条须写明支撑哪一条诉请 / 抗辩点，与起诉状诉请编号一一对应
- 若某个想主张的点在协议里找不到对应条款，如实写"未就【该事项】作出规定"——
该结论本身对用户有利（平台未预设该义务却据此处置，恰是瑕疵），绝不可编一条

六、docx 排版技术规范

七、落盘与命名

• 输出目录：{用户工作空间根目录}/deliverables/platform-ban-litigation/
• 写盘前先建目录
• 命名：<文书类型>-<YYYY-MM-DD>.md，例如 complaint-2026-08-08.md、evidence-book-2026-08-08.md
• 最终交付以 docx 为主（法院只收打印件），md 作为可追溯中间产物保留
• 交付对话里只回：案件可行性一句话 + 材料清单 + 3–5 条行动项 + 落盘路径。不整篇复述文书

八、支付宝 AI 按量付费（可选计费）

本套件支持以支付宝 AI 按量付费（A2M，402 协议）对外提供「成套生成文书」能力：
未付费请求返回 HTTP 402 + Payment-Needed 账单，付款后携带 Payment-Proof 重试，
服务端验付 → 生成文书 → 履约确认 → 返回资源与 Payment-Validation。

• 这是可选层：未配置凭证时，原有离线 scripts/gen_litigation_docs.py 的 CLI 用法完全不受影响。
• 完整接入步骤、配置字段、沙箱联调、生产上线与安全红线见
  references/aipay/按量付费接入指南.md（必读）。
• 计费网关代码位于 scripts/aipay/（server.py 为入口，billing.py 为 402 协议纯逻辑，
  order_repo.py 为幂等订单库，alipay_client.py 为支付宝 SDK 封装）。

最简启动（需先按指南配置本地密钥文件 alipay-aipay.json，该文件名以点开头、不入包）：

pip install -r scripts/aipay/requirements.txt
python -m scripts.aipay.server
curl -i http://localhost:5000/generate      # 应返回 HTTP 402 + Payment-Needed

> 按量付费的范围只含 402 / payment.verify / fulfillment.confirm；不涉及统一收单、
> 异步通知或 notify_url。生产上线前需在支付宝开放平台完成产品开通与服务注册（见指南第七节）。

九、references 索引

使用者文档：README.md（技能根目录）面向使用者，含 30 秒上手、三种触发方式、
首次使用建议路径、环境准备与分发方式。当用户询问"这个技能怎么用 / 怎么装 / 怎么分享给别人 /
需要什么环境"时，直接引用它，不要临场编造安装步骤。