使用方法
- 填「服务名称」,默认 柳泉在线工具。这就是条款里反复出现的「本服务」,写你对外展示的产品或站点名,不要写公司全称。
- 填「运营主体」,默认 北京柳泉科技有限公司。这里是法律意义上的责任主体,应填营业执照上的名称全称。
- 填「联系方式」,默认 support@liuquan.net。条款里有两处会用到它:通知送达与账号申诉,建议填能长期收信的邮箱或客服电话。
- 选「适用法律」,默认 中华人民共和国法律。换成港澳台或境外法域后,第九条争议解决的表述会跟着变。
- 填「生效日期」,默认 2026-10-01。控件是日期选择器,格式固定为 YYYY-MM-DD,填 2026-2-1 这种缩写会被拦下。
- 点「生成条款」,或在任意一个输入框里按 Enter。右侧四格数字与下方条款文本会一起刷新,可继续点「复制条款」或「导出 CSV」。
这个服务条款生成器能解决什么问题
一是把「不知道写哪几章」变成一张清单。自己从零起草服务条款,最常见的问题不是措辞,而是漏章:写了免责声明却忘了争议解决,写了费用却忘了怎么终止。这个服务条款生成器固定输出十二个章节——服务说明、账号与注册、使用规则、费用与支付、用户内容与知识产权、隐私与数据、免责声明、服务变更与终止、争议解决、通知与送达、协议更新、可分割性,对照表里还标了哪五章属于「必备」。
二是把身份信息一次性灌进全文。默认示例里「柳泉在线工具」出现 8 次、「北京柳泉科技有限公司」出现 1 次、support@liuquan.net 出现 3 次、2026-10-01 出现 3 次,这些位点原本要在十几个自然段里手工替换,漏一处就会留下占位符。本页用一个单次扫描的替换把 4 个占位符一次性换掉,避免反复替换带来的连锁错误。
三是给出字数与结构的量化基准。默认十二条正文合计 1,002 个字符、全文 1,285 个字符,最短的第九条 70 字、最长的第一条 103 字。对照表把这些数字逐条摊开,让你一眼看出哪一章写得过薄——通常少于 60 字的条款在真实纠纷里很难起到说明作用。
四是把「模板」和「法律意见」分开。条款骨架是通用的,能覆盖大多数在线工具与 SaaS 站点的常见情形;但具体到某个行业、某个地区,通用条款远远不够。本页因此在第七条正文里直接写明不构成法律意见,而不是把它藏在页脚。
本页不做这些事:不下结论说某条款「合法」或「能打赢官司」(那属于执业律师的判断);不生成隐私政策、Cookie 政策与退款政策的具体内容(请用对应的专门页);不做多语言版本的双语对照(本页只输出中文一版)。
条款框架、占位符与编号口径
骨架是十二条,不是十二个模板。骨架数据放在页面里的一个隐藏容器中,按「章节名一行、正文一行」交替排列,共 24 行;脚本启动时把它读成 12 组「章节名 + 一段带占位符的正文」。生成时按顺序拼成「第N条 章节名」加正文,中间空一行,最后补一行联系方式。新增或删减章节,就是改这个容器的行数——所以页面上「条款条数」恒等于骨架条数,改不了。
占位符用单次扫描替换,不用连续 replace。正文里有 4 个占位符:@n 服务名称、@c 联系方式、@l 适用法律、@d 生效日期。这里有个真实的坑:默认联系方式是 support@liuquan.net,字符串里自带一个 @,后面紧跟的是 l。如果先替换 @c 再替换 @l,那么已经写进正文的邮箱会被第二次替换,@liuquan.net 就被啃成了 中华人民共和国法律iuquan.net。本页改用一次正则 /@([ncld])/g 配回调函数,每个占位符只扫描一次,替换结果不会再被扫到,从根上避免了这种连锁替换。
中文条号是算出来的。条号不是硬编码的「第一条」到「第十二条」,而是由序号经字符表 一二三四五六七八九十 映射得到:1~10 直接取第 n 个字,11 与 12 输出「十一」「十二」。好处是数组长度变了条号依然连续;如果把章节扩到 20 条,只需给映射函数补一条 20 以上的分支。
日期要过两道校验。第一道是格式:必须匹配 \d{4}-\d{2}-\d{2},所以 2026-2-1 与空值都会被拒。第二道才是日历合法性:把年月日拆开后,用一张按月份排列的天数表比对,其中二月天数先判断 (y % 4 === 0 && y % 100 !== 0) || y % 400 === 0,是闰年才给 29 天。因此 2026-02-30 会被判非法,而 2024-02-29 合法。只做格式校验的生成器会把 2026-02-30 原样写进条款,这是本页特意补上的第二道关。
字符数按码点算,不按字节也不按 UTF-16 码元。统计用 Array.from(文本).length,一个汉字、一个英文字母、一个数字各记 1 个字符。不这么做的后果是:某些生僻字与 emoji 在 UTF-16 里占 2 个码元,用 length 统计会被多算一倍。默认正文 1,002 个字符对应 1,002 个码点,写进条款时可以直接当作排版字数的参考。
免责声明必须落在正文里。第七条正文明确写「不构成任何形式的法律意见」,这不是客套话,而是这个工具的能力边界:它只负责拼装结构,不负责判断某条约定在你所在法域是否有效、是否可执行。
完整示例(数值仅作演示)
页面打开时的默认参数是:服务名称 柳泉在线工具、运营主体 北京柳泉科技有限公司、联系方式 support@liuquan.net、适用法律 中华人民共和国法律、生效日期 2026-10-01。这个服务条款生成器在默认参数下的复算结果如下:
- 输出条款共 12 条,正文合计 1,002 个字符,全文合计 1,285 个字符、41 行;
- 单条正文字符数从 70(第九条 争议解决)到 103(第一条 服务说明),平均约 83.5 个字符;
- 服务名称占位符
@n在正文里出现 8 次,联系方式@c出现 2 次,适用法律@l与生效日期@d各出现 1 次; - 加上抬头与结尾行后,字符串「柳泉在线工具」在全文出现 9 次、
support@liuquan.net出现 3 次、2026-10-01出现 3 次; - 把生效日期改成 2024-02-29 可以正常生成,改成 2026-02-30 会被日历校验拦下并提示不是合法日历日;
- 只改适用法律为「新加坡共和国法律」,其余不动,只有第九条末句跟着变,全文总字符数从 1,285 变成 1,283(少 2 个字符)。
再看边界:服务名称填到上限 40 个字符时,@n 会被替换 8 次,全文总字符数约为 1,285 + 8 × (40 − 6) = 1,557 个字符,仍是一次本地字符串拼接,耗时可以忽略。整个生成过程没有任何网络请求,也不写浏览器存储。
章节、默认字数与是否必备对照表
下表十二行与生成结果一一对应:条号是生成时算出来的中文序号,「默认字符数」是在默认示例下该条正文的长度,「必备」一栏的五条是通用在线服务条款里最不建议省掉的章节。点「加载更多行」会补上十二个可选扩展模块,它们不进入固定十二条骨架。
| 条号 | 章节模块 | 默认字符数 | 是否必备 | 起草要点 |
|---|---|---|---|---|
| 第一条 | 服务说明 | 103 | 必备 | 界定「本服务」的范围与可调整性 |
| 第二条 | 账号与注册 | 102 | 建议 | 注册信息真实性与账号保管责任 |
| 第三条 | 使用规则与禁止行为 | 94 | 必备 | 列举禁止行为与处置权 |
| 第四条 | 费用与支付 | 73 | 建议 | 免费与收费边界、不擅自扣费 |
| 第五条 | 用户内容与知识产权 | 84 | 建议 | 用户内容归属与平台许可范围 |
| 第六条 | 隐私与数据 | 75 | 必备 | 数据处理范围与指向隐私政策 |
| 第七条 | 免责声明 | 87 | 必备 | 现状提供与不构成法律意见 |
| 第八条 | 服务变更与终止 | 72 | 建议 | 注销、违规停服与提前通知 |
| 第九条 | 争议解决 | 70 | 必备 | 协商前置、管辖法院与适用法律 |
| 第十条 | 通知与送达 | 89 | 建议 | 送达渠道与联系方式更新义务 |
| 第十一条 | 协议更新与生效 | 79 | 建议 | 更新公示方式与继续使用的含义 |
| 第十二条 | 可分割性与完整协议 | 74 | 建议 | 条款无效的剥离与整体约定优先 |
两条规律值得注意:必备项的字符数并不最长,最长的是第一条服务说明(103 字),而必备的第九条争议解决只有 70 字——长度不代表重要性;十二条正文合计 1,002 个字符只是骨架体量,真实上线前每一条通常还要按业务补充二到三倍的细节,本页给的是「不低于这个量级」的下限。
输入范围、边界与免责说明
- 服务名称 1~40 个字符、运营主体 1~40 个字符、联系方式 1~60 个字符。三个字段都不能为空,空值会被拦下并给出具体提示。输入框设了
maxlength,超出上限的字符根本打不进去,不会出现「悄悄截断」。 - 生效日期必须是合法的 YYYY-MM-DD。先过格式正则,再过闰年日历表。
2026-2-1、2026-13-01、2026-02-30都会报错;年份建议落在 2000~2100 之间。 - 适用法律只提供 4 个预设值。这是一个下拉选择而非自由输入,避免出现「适用法律」栏里填了一串无法解析的文本。四个选项分别对应中国大陆、香港、新加坡与英格兰法域。
- 条号与条数由骨架数组决定,不能自定义。本页固定输出十二条。想要增减章节,需要改代码里的数组;把「必须写在页面上的那一章」硬塞进其他章反而会让条款结构混乱。
- 字符数按码点统计,与 Word 字数会有出入。本页统计不含标点之外的空白折算规则,与办公软件的「字数」口径并不完全一致,量级参考即可。默认全文字符数 1,285,其中汉字 1,036 个。
- 占位符替换是单次扫描,不会污染已替换内容。正因为按一次正则配回调完成,联系方式里自带
@也不会被后面的@l规则二次命中——这一条是本页与「连续 replace」写法的关键差别。 - 替换只认四个占位符,不认任意花括号。正文里写
@x这类未定义的占位符不会被替换,会原样出现在输出里。想让某处留占位,得先把它加进映射表。 - 本服务条款生成器输出的是通用模板,不构成任何法律意见。条款是否有效、是否符合你所在行业的监管要求、是否需要备案,都需要执业律师结合具体业务判断。涉及重大权益、诉讼或合规审查时,请勿以本页文本为最终依据。
常见问题
生成的服务条款能直接上线用吗?
可以作为初稿,但不建议直接上线。它给的是通用骨架与中性措辞,能覆盖大多数在线服务都会写的十二个章节,但缺少你的业务特有的约定:数据保存多久、退款怎么算、内容审核标准是什么、有没有自动续费。正确用法是把本页输出当成提纲,逐条补上这些业务细节,再请执业律师过一遍。
为什么正文里会出现「中华人民共和国法律iuquan.net」这种怪东西?
那是「连续 replace」写法的典型故障:先替换 @c 把默认邮箱 support@liuquan.net 写进正文,紧接着替换 @l 时,邮箱里自带的 @l 又被命中,于是 @liuquan.net 被啃成了「中华人民共和国法律iuquan.net」。本页改成一次正则配回调的单次扫描,每个占位符只处理一遍,替换结果不再进入下一轮,因此不会出现这种连锁替换。
服务名称和运营主体到底填哪个?
服务名称填用户看到的产品名或站点名,它是条款里「本服务」的所指,会反复出现;运营主体填承担法律责任的实体,一般是营业执照上的公司全称。两者混填的后果是:条款通篇指向一个品牌名,真发生纠纷时无法明确责任主体,这在争议解决与通知送达两章里尤其要紧。
生效日期为什么非要严格到日?
因为条款的更新往往靠生效日期来区分版本。写成「2026 年 2 月」这种模糊表述,一旦出现新旧两版条款并存的情形,就无法判断某次行为究竟适用哪一版。本页因此限定 YYYY-MM-DD 格式,并额外校验日历合法性,避免把 2026-02-30 这类不存在的日期写进正式文本。
十二条里哪几条最不能省?
对照表标为「必备」的五条:服务说明、使用规则与禁止行为、隐私与数据、免责声明、争议解决。原因很直接——前两条界定权利义务的边界,隐私与数据回应监管要求,免责声明划定责任范围,争议解决决定出事后去哪里解决。其余七条属于重要但可后补的部分。
字符数是按什么口径统计的?
按 Unicode 码点统计,用 Array.from(文本).length。一个汉字、一个英文字母、一个半角标点各记 1,生僻字与 emoji 也只记 1(如果用 UTF-16 的 length,它们会被记为 2)。默认示例的十二条正文合计 1,002 个字符,全文含标题与结尾共 1,285 个字符。
能把生成结果导出去吗?
可以。点「复制条款」把全文复制到剪贴板,粘贴进 Word 或在线文档继续编辑;点「复制对照表」得到制表符分隔的表格,粘进 Excel 会自动分列;点「导出 CSV」下载一份带 BOM 的 terms-of-service-outline.csv,用中文 Excel 打开不会乱码。
输入的内容会被上传或保存吗?
不会。填写的五个字段只读取自当前页面,生成过程就是一次字符串拼接,没有任何网络请求,也不写 localStorage。刷新页面后全部回到默认示例。可以打开开发者工具的 Network 面板,边改输入边观察有没有请求发出。