服务条款模板

自己写服务条款，最容易卡在两处：一是不知道要写哪几条，二是照抄网上的模板却漏掉自己业务的特殊风险。这篇给一份按模块拆开的可套用结构，说明每个模块要填什么、什么情况下必须找法务过一遍，以及条款上线后怎么和站内的风控、安全自查流程对上。

自己起草服务条款，卡点通常不在文笔，而在两处：不知道要写哪几条，以及从网上抄来的模板漏掉了自己业务的特殊风险。尤其你做的是 AI 类产品，提示词、生成结果、额度、模型调用日志这些东西，通用电商模板根本不覆盖。这篇给一份按模块拆开的可套用结构，说明每个模块填什么、按什么顺序填、哪些地方必须自己动手改。

先讲清楚这份模板的定位：它是草稿起点，不是可以直接点发布的成品。凡涉及支付、医疗、未成年人、跨境数据、金融荐股这类场景，别硬套，先找法务过一遍。另外条款写完之后要能和你站内的风控、安全自查流程对上，条款里承诺的检测和处置动作，运营侧得真的做得到，否则写了也是摆设。

先定清楚：这份条款管谁、管什么

动笔前先回答一个问题：这份条款主要给谁看。面向 C 端用户、面向开发者 API 调用方、面向企业客户，三种写法的重心完全不同。C 端要重点写账号安全和禁止行为，用户量大、滥用也是个人行为；API 调用方要重点写额度、限速、调用合规和转售限制，出问题的往往是集成商；企业客户则要重点写 SLA、数据处理、责任上限和审计配合，这类条款经常要单独签补充协议。

再定适用范围。账号这一层管的是注册、登录、注销；额度这一层管的是购买、消耗、过期；内容这一层管的是用户提交的提示词和生成结果；数据这一层管的是日志留存和用途。建议在开头就用一段话把这四层点到，后面每个模块再展开。如果业务同时有网页端和 API，最好分开写或者明确标注哪些条款只适用于哪一端。

• 涉及在线支付的，退款和计费口径必须单独写，不能只抄通用模板；
• 涉及医疗、法律、投资建议类输出的，免责声明要写得更具体，说明输出不构成专业意见；
• 涉及未成年人的，要有年龄限制和监护人条款，通用模板基本没有这块；
• 涉及跨境数据流动的，数据存储位置和传输依据要单独交代；
• 同时做 C 端和 API 的，条款里要注明不同产品的适用差异，别一份打天下。

模板骨架：七个必备模块及填写顺序

七个必备模块分别是：账号与资格、服务内容与变更、付费与额度、用户内容与授权、禁止行为、责任限制、终止与争议解决。这个顺序不是随便排的，建议填写时也按这个逻辑走：先定责任边界（平台担什么、不担什么），再定行为约束（用户能做什么、不能做什么），最后写程序性条款（怎么通知、怎么终止、去哪打官司）。先写程序性条款的人，往往写到一半发现前面的边界没定，回头大改。

账号与资格

谁有资格用、账号归谁、安全问题谁负责，通常一到两段就够

服务内容与变更

卖的是什么、能改什么、改了怎么通知，这段长短取决于服务是否频繁迭代

付费与额度

计费口径、额度规则、退款边界，这块最容易出纠纷，值得多花篇幅

用户内容与授权

用户提交内容的权属和平台拿到的许可范围，AI 产品必写

禁止行为

不能做什么、做了怎么处理，建议清单化而不是大段描述

责任限制

平台责任上限和免责范围，格式固定但要结合业务调整

终止与争议解决

什么情况暂停/终止账号、数据怎么取回、适用法律和管辖地

每个模块写一句还是写一段，判断依据是纠纷概率。账号与资格通常两段以内；付费与额度因为涉及真金白银，建议拆成计费口径、额度有效期、涨价通知、退款处理四个小点分别写。禁止行为适合清单化，一条禁令配一个处置动作，比写成散文更好执行。责任限制和争议解决属于程序性条款，措辞相对固定，但管辖地这类必须按你的实际注册地改，不能照抄。

1. 先定责任边界把责任限制、免责范围、平台义务写清楚，后面所有条款都以这个为基准。验证方法：检查后面每一条用户义务，是否都能对应到平台已经声明不承担的责任。
2. 再定行为约束写禁止行为清单和用户内容授权范围。验证方法：每条禁令后面标注平台对应的处置动作，处置动作要能被日志或风控实际检测到。
3. 最后写程序性条款补账号、付费、变更通知、终止与争议解决。验证方法：把所有提到期限、通知方式、生效条件的地方列成一张表，看有没有前后矛盾。

账号、服务范围与变更条款怎么写

账号部分要回答三个问题：账号归谁、谁负责安全、多人共用怎么办。账号所有权一般写归平台、使用权归用户，这是常见做法；但反过来写归用户，在用户数据归属上会更清晰，看你业务。安全义务要写清用户对自己账号下的所有行为负责，包括 API Key 泄露导致的消耗，这条不写清楚，后面额度纠纷很难扯。多人共用要单独约定，比如是否允许团队账号、子账号怎么管理、主账号对子账号行为是否连带负责。

服务内容与变更条款，核心是给自己留出调整空间，同时别把话说死。不要写「服务永久提供」「保证可用率」这类绝对化措辞，改成「平台有权根据运营情况调整服务内容，重大变更将提前通知」这种表述。变更要不要提前通知，判断标准是变更是否影响用户已付费的权益：影响就通知，纯功能优化可以不通知但要更新版本记录。通知方式也要在条款里写明，比如站内公告、邮件、控制台弹窗，选哪个写哪个，别写「以平台认为合适的方式」这种模糊说法。

• 账号所有权和用户使用权分开表述，避免权属歧义；
• 安全义务明确到「用户对账号下所有操作负责」，包括密钥泄露；
• 多人共用写明是否允许、子账号权限边界、主账号是否连带；
• 服务内容用「可能调整」而非「保证长期提供」；
• 变更通知方式和生效时间写具体，不要用模糊表述。

付费、额度与退款条款的填写要点

付费这块最容易产生争议，原因往往是计费口径没写清。按量计费要写清计量单位、计量精度、超出额度的处理方式；订阅制要写清周期、自动续费规则、取消方式；额度包要写清有效期、是否可结转、过期怎么处理。这三种计费方式经常混用在同一个产品里，条款里最好分条写，别揉成一段。具体单价和额度面额不用写死在条款里，引导用户到当前有效页面核对即可。

涨价和套餐变更，条款里要写通知方式和生效时间。一般做法是提前一段时间通知，已购额度按原规则执行到用完，新购买按新价。这个提前多久、怎么通知，按你业务实际填，别抄网上的固定天数。退款条款，边界要清楚：什么情况不退、什么情况可退、可退的话走什么流程。有些场景可以留白，比如金额小、争议少的，写「具体以客服协商为准」反而比写死规则更灵活，但要在条款里明确这个协商入口在哪。

用户内容、数据与授权范围

AI 产品这块必须写清楚：用户提交的提示词、上传的文件、生成的输出，权属归谁，平台拿到的是什么权利。通行做法是权属归用户，平台获得一项非独占的、仅为提供服务所需的使用许可。注意区别「使用许可」和「所有权」：写许可，平台只能按约定用途使用；写所有权，用户会把这条当成霸王条款，口碑和合规都有风险。许可范围要具体到用途，比如用于生成返回、用于风控审核、用于故障排查、用于模型训练，每一项都单独列。

数据用途和留存期限最容易被忽略。是否用于训练是敏感项，用就明确写用、并提供关闭途径；不用就明确写不用，别含糊。留存期限按业务需要写，比如日志留存多久、用户注销后多久清理。调用日志、提示词、生成结果这三类数据的归属和处理要分开约定，很多模板把它们混在一起，导致用户不知道自己的输入到底被怎么处理了。这些内容的实际处理规则，可以到站内的安全自查相关页面参照，确保条款描述和实际做法一致。

• 用户提交内容权属归用户，平台只拿许可不拿所有权；
• 许可范围逐项列明：生成返回、风控审核、故障排查、模型训练分开写；
• 是否用于训练必须明确表态，用就给关闭途径，不用就写不用；
• 留存期限分类型写：调用日志、提示词、生成结果各自约定；
• 用户注销后的数据处理方式单独说明，别和留存混在一起。

禁止行为清单怎么列才可执行

禁止行为别写成一大段「用户不得从事违法违规行为」，那种写法执行不了。可行的做法是一条禁令配一个处置动作，从「不可做」写到「做了会怎样」。比如禁止账号共享，对应动作是检测到多地点并发登录后限制或封禁；禁止绕过限速，对应动作是触发阈值后降速或暂停密钥；禁止爬取输出，对应动作是识别异常调用模式后限流。写不出处置动作的禁令，要么删掉，要么先想清楚怎么检测再写。

高风险行为建议单独成条：账号共享、绕过限速、批量爬取输出、二次分发或转售、用输出训练竞品模型。这几条在 AI 产品里出现频率高，单独列出来既方便用户理解，也方便你在处理时引用具体条款。禁令的可执行性还取决于日志和风控能力，条款里写的检测手段，运营侧得真的能覆盖，否则真出事时你引用了条款却拿不出证据。相关检测能力可以参照站内的安全自查清单来对一遍。

1. 列禁令把不允许的行为逐条写出来，一条一句，不要合并成概括性描述。验证方法：用户读一遍能不能准确知道自己不能做什么。
2. 配处置动作每条禁令后面写上发现后的处理方式，警告、限流、暂停、封禁分级写清楚。验证方法：每条处理方式是否对应到一个可检测的信号。
3. 对风控能力把写进条款的检测手段和实际日志、风控能力核对一遍。验证方法：随机制定一条禁令，问运营能不能从日志里查出来。

责任限制、终止与争议解决

责任限制条款的常见写法是：平台对间接损失、利润损失不承担责任，直接损失以用户已支付金额为上限。这类表述在多数场景下是有效的，但明显无效的写法也要避开，比如「平台对任何情况均不承担责任」「用户放弃一切索赔权利」，这种全免责表述法院基本不认，反而让整条条款的可信度下降。责任限制要和你实际提供的服务匹配，涉及关键业务系统的，对方往往会要求提高上限，这属于商业谈判范畴，条款里留出可协商空间即可。

终止条款要写清三件事：什么情况暂停或终止、怎么通知、用户怎么取回数据。触发条件一般包括严重违规、长期欠费、账号长期不活跃，建议分级写，警告、暂停、终止分开。通知方式要和前面变更通知保持一致，别一处写邮件一处写站内信。数据取回窗口很关键，终止后给用户多长时间导出数据、过期后怎么处理，这段不写清楚，用户投诉时你没有依据。争议解决条款要写适用法律、管辖地、通知送达方式三件事，管辖地按你的实际注册地填，不能照抄。

上线前检查与后续维护

条款写完别直接发布，先过一遍自查清单。版本号、生效日期、变更记录、历史版本可查，这四样是基本要求，尤其历史版本，用户有争议时你要能证明当时适用的是哪一版。另外条款和隐私政策、可接受使用政策之间要分工清楚，隐私政策管数据怎么收集处理，可接受使用政策管行为规范，服务条款管双方权利义务。三者互相引用可以，但不能互相矛盾，比如隐私政策说不用于训练、服务条款说可能用于训练，这种冲突一旦被用户发现就是信任问题。

• 版本号和生效日期是否标明，历史版本是否可查；
• 条款与隐私政策、可接受使用政策之间有无相互矛盾；
• 所有提到期限、通知方式、金额的地方是否前后一致；
• 禁止行为的处置动作是否和实际风控能力对得上；
• 用户内容处理规则是否和实际做法一致；
• 争议解决条款的管辖地是否按实际注册地填写。

改条款的节奏也有讲究。纯文字表述优化、补充说明性内容，更新版本号并标注生效日期就可以；涉及用户权利义务实质性变化的，比如数据用途扩大、责任范围调整、计费规则变化，必须重新取得用户同意，通常做法是弹窗确认或重新勾选。判断标准很简单：这次改动会不会让用户做出不同的决策，会就要重新同意，不会就更新版本即可。站内的指南中心有关于条款维护和产品合规的更多内容，可以配合一起看；条款里涉及价格展示的部分，记得引导用户到站内价格追踪页面核对当前数字，不要在条款里写死。