服务条款怎么写

很多人写服务条款是照着别人的抄一遍，改个名字就上线，结果真出事时发现自己承诺了自己做不到的事，或者该免责的地方一句没写。这篇不讲法律条文，只讲结构：一份能用的条款由哪几块组成、每块要回答什么问题、哪些内容该写成可操作的动作而不是空泛表态，以及写完以后要怎么和实际产品行为对齐。适用于自建站点、API 中转、工具类产品；正式对外前仍建议找专业法务过一遍。

很多人写服务条款是照着别人的抄一遍，改个名字就上线，结果真出事时发现自己承诺了自己做不到的事，或者该免责的地方一句没写。这篇不讲法律条文，只讲结构：一份能用的条款由哪几块组成、每块要回答什么问题、哪些内容该写成可操作的动作而不是空泛表态，以及写完以后要怎么和实际产品行为对齐。

适用于自建站点、API 中转、工具类产品。核心思路就一句：条款不是给用户看的装饰，是你在出争议时唯一能拿出来的书面约定，所以它必须和你产品的真实行为一一对得上。正式对外前仍建议找专业法务过一遍，尤其是涉及收费和用户数据的部分。

先想清楚：这份条款约束的是谁、约束什么

动笔之前先回答两个问题：这份条款的主体是谁，覆盖范围到哪。主体决定了后面争议解决和联系方式怎么写——个人站点写个人，公司主体写公司全称，境外实体要考虑适用法律和管辖地是否写得住。覆盖范围则决定一份还是多份：只约束注册用户，还是连未注册访客、API 调用方一起管。

主体

写条款的一方是谁，个人、公司还是境外实体，直接影响争议解决与联系方式

适用对象

哪些人受这份条款约束，注册用户、访客、API 调用方要不要分开写

覆盖范围

网站、API、子域名、配套工具是共用一份，还是各自单独一份

• 明确主体：个人站点、公司主体还是境外实体，决定了后续争议处理和联系方式怎么写
• 明确适用对象：只针对注册用户，还是也覆盖未注册的访客与 API 调用方
• 明确覆盖范围：网站本身、API、子域名、配套工具是否共用一份条款
• 不适用的情形：纯内部工具、仅对熟人开放的测试站点，写一份重型条款反而增加维护负担

一份能用的条款，至少要有这七块

不用追求面面俱到，但这七块缺一块就会在某个场景里说不出话。每一块都要回答一个具体问题，而不是凑字数。下面这张表可以当成动笔前的清单，写完一块勾一块。

顺序上建议把「服务内容」和「使用规则」放前面，「责任限制」放后面，因为责任限制通常是用来收紧前面承诺的，位置靠后逻辑更顺，用户读起来也不至于一上来就被免责条款劝退。每一块写多长不重要，重要的是别留空白——空白在争议里等于没有约定。

禁止行为那一段，写成「可判断」而不是「看起来很凶」

「禁止滥用」「不得恶意使用」这类词看着凶，实际执行时站不住脚，因为你没法向用户解释到底哪一步算越线。正确的写法是把每条规则对应到你能观测到的信号，再配上处理动作。你观测不到的行为，就别写进条款。

1. 列信号把你能在日志或后台看到的异常列出来，比如同一账号多地登录、短时间高频调用、批量注册、同一支付方式对应大量账号。列不出来说明你还没能力执行这条规则。
2. 定梯度给每个信号配处理动作的梯度：先限速、再暂停、最后终止。不要只写一句「有权随时封禁」，那既吓不住人，也没法向正常用户解释。
3. 留申诉给出申诉入口和大致响应预期。哪怕只是站内表单加人工看，也比让用户去发帖碰运气强。

额度、计费和退款：最容易埋雷的部分

收费相关的条款是纠纷高发区，因为它同时牵涉钱和预期。原则是：口径必须唯一，去向必须可查，数字尽量不写死。写死具体金额和倍率，等于每次调整都要改条款、重新通知，成本高还容易漏。

• 把额度口径写清楚：按次、按 token 还是按时长，计量以哪个页面为准
• 写清额度有效期、是否可结转、封号后剩余额度怎么处理
• 明确上游涨价或降速时自己的处理方式，以及是否保留调价权
• 具体数字不要在条款里写死，指向站内价格页，避免每次调整都要改条款；价格可到 /official-api 与 /price-watch 对照当时的公开口径

「剩余额度怎么处理」这一条最容易被跳过，但它往往是投诉最集中的地方。你得提前想好：封号时剩余额度是退、是转、还是作废；上游服务下线导致你的产品不可用时，你是顺延、退费还是只做说明。这些不写清楚，争议一起就只能临时拍脑袋。

条款和隐私、数据边界的分工别混在一起

很多站点把条款和隐私说明写成一锅粥，结果两处对同一条数据给出不同说法，反而成了把柄。正确分工是：条款管「什么能做、什么不能做」，隐私说明管「数据怎么收、怎么用、存多久」。两者互相引用，但不要互相重复。

用户上传内容的授权范围要尽量收窄，只授权为提供服务所必需的用途，不要顺手写「可用于任何商业推广」。这种顺手加的一行，往往是后面最解释不清的地方。反过来，如果产品完全不收集个人信息，隐私说明可以极简，但条款仍需保留基本的免责与终止条款，两者不能互相替代。

改条款和发通知：流程比文案更重要

条款不是写完就不动的文档，产品在变，条款就得跟着变。问题在于变更本身也要有规矩：怎么通知、什么时候生效、老版本怎么留。这块拼的是流程，不是文笔。选通知方式时只选你确定能长期做到的那种。

• 约定变更生效方式：站内公告、邮件还是登录时二次确认，选你能真正做到的那种
• 重大变更给缓冲期，小修补可以即时生效，但要在条款里区分这两类
• 保留历史版本并标注生效范围，出争议时能说清当时适用的是哪一版
• 把通知动作写进上线流程，而不是等想起来才补

一个常见误区是承诺「任何变更都会提前邮件通知每一位用户」。听起来很负责，做起来很难：用户换了邮箱、邮件进了垃圾箱、你忘了发。与其写一个做不到的承诺，不如写成「重大变更以站内公告为主要通知方式，并在公告页保留历史记录」。判断标准很简单：过去半年你实际发过几次通知，就以那个能力为上限来写。

写完之后的对照检查：条款不能和产品打架

条款最怕的不是写得少，是写的和产品不一样。用户拿条款截图来找你时，你只能按条款办，而条款写的偏偏是你做不到的事。所以上线前要做一遍逐条对照，把每条承诺翻成产品里的一个具体动作去验证。

1. 对照功能逐条读条款，凡是提到「支持」「提供」「可导出」的地方，去产品里真操作一遍。条款说支持导出，产品里就得真有导出入口。
2. 对照计费与限速把条款里关于额度、限速、周期的描述，和站点实际执行的值对一遍。数值口径统一指向站内价格页，到 /price-watch 核对当时的公开口径是否和条款表述一致。
3. 对照客服口径拿条款去过一遍一线回复话术，两者不能相反。客服口头承诺的内容如果条款里没有，要么补进条款，要么统一话术。
4. 固定成上线动作把上面三步做成清单，每次改产品或改条款都跑一遍，可参考站内 /safety 分区的其他自查清单一起做。

几个常见坑：抄模板最容易踩的地方

抄模板本身没错，错在抄完不改。模板里的主体、管辖地、退款政策都是别人的，套在你身上要么无效，要么反而给你自己加负担。下面几个坑几乎每个抄模板的站点都会踩一次。

• 照搬大厂条款：主体、管辖地、退款政策全是别人的，出事时完全用不上
• 把所有风险都推给用户：单方面「不承担任何责任」的写法在争议中往往站不住
• 术语前后不一致：「账号」「账户」「用户」「会员」混用会带来解释歧义
• 只写不改：产品迭代了两年条款还停在第一版，是纠纷里最容易被抓的点

还有一类是「承诺过度」：为了显得正规，把自己包装成有完整风控、有 SLA、有赔付机制的样子，可实际上没有。这种写法短期看是加分，出事时全变成减分。判断标准是：每写一句承诺，问自己「用户拿这句话来找我，我今天能不能兑现」。兑现不了就改写成描述性表述。

服务条款不是写给用户看的门面，是你出问题时唯一能翻出来的那本书，写得少可以补，写错了改不掉。