服务条款生成

要解决什么问题

上线 Web 应用、SaaS 或数字市场时，服务条款（ToS） 往往既要覆盖订阅计费、用户内容与 API 使用等平台细节，又要在责任限制、争议解决等条款上尽量可执行。团队常卡在：不知道哪些章节与商业模式绑定、条款写法是否踩法院常拒执的坑，以及消费者/企业、不同司法辖区下的差异该如何表述。

技能如何工作

本技能按固定流程把业务事实转成条款草案，而不是输出泛泛的「法律模板」：

1. 厘清商业模式 — 平台类型（SaaS、市场、社交、API）、收入模式（订阅、免费增值、交易费、广告）、用户类型（C 端/B 端/混合），以及是否涉及支付、UGC、第三方集成或受监管数据。
2. 用户权利与限制 — 可接受使用与禁止行为（滥用、爬取、逆向工程、绕过访问控制）、账户义务与许可范围，并与订阅层级挂钩。
3. 责任与保证 — 免责声明、责任上限、排除间接损害，并兼顾主要辖区消费者法例外；无 SLA 时明确否认 uptime 承诺。
4. 争议解决 — 准据法与管辖、仲裁与集体诉讼弃权（在可执行范围内）、小额诉讼例外及非正式协商步骤；必要时区分 B2B 与 C 端条款。
5. 可执行性审查 — 检查不合理条款、重大条款（自动续订、仲裁）的醒目呈现，以及应用商店等平台规则。

使用时直接描述平台、商业模式、用户群与关注点（是否处理 UGC、支付、受监管行业等）；技能会产出对应章节的可执行英文法律文本片段（示例中涵盖接受条款、订阅、UGC/DMCA、交易与责任限制等）。

适用边界与注意点

• 欧盟/英国用户：消费者保护、强制仲裁限制、数字内容 14 天撤销权等需单独考虑。
• 开源组件：ToS 不得与已适用的开源许可证冲突，必要时增加开源声明。
• 政府/教育客户：赔偿、仲裁、准据法条款可能需附录或由采购条款覆盖。
• 关停或转型：应写清数据导出、预付订阅退款与服务终止后的处理。
• API 访问：速率限制、自动化使用边界宜与交互式使用分章表述。

生成内容仅供起草与结构参考，不能替代执业律师对具体业务与辖区的审阅。