服务条款生成器

把你的服务名称、运营主体、联系方式、适用法律与生效日期填进去,按固定的十二条章节骨架拼出一份结构完整的服务条款文本,同时给出每章的默认字数与「必备 / 建议」标记,支持复制、下载与 CSV 导出,全部在浏览器本地完成。

条款条数12
条款正文字符数1,002
全文总字符数1,285
生效日期2026-10-01
默认示例:服务名称「柳泉在线工具」、运营主体「北京柳泉科技有限公司」、联系方式 support@liuquan.net、适用法律「中华人民共和国法律」、生效日期 2026-10-01,生成十二条正文合计 1,002 个字符、全文 1,285 个字符。任一输入框里按 Enter 即可重新生成。
服务条款

本服务条款(以下简称“本条款”)由 北京柳泉科技有限公司(以下简称“我们”)与你(以下简称“用户”)就 柳泉在线工具(以下简称“本服务”)的使用达成,自 2026-10-01 起生效。

第一条 服务说明
我们通过 柳泉在线工具 向你提供在线工具服务。本服务的具体功能、界面与可用范围以实际展示为准;我们可基于运营需要调整功能,调整前会以页面公告或站内通知提示。你应在使用前阅读并理解本条款,开始使用即视为接受。

第二条 账号与注册
柳泉在线工具 的部分功能需要注册账号。你应提供真实、准确的注册信息,并妥善保管账号与密码;因你自身保管不善导致的风险由你承担。发现账号被盗用,请立即通过 support@liuquan.net 联系我们。

第三条 使用规则与禁止行为
你承诺不利用 柳泉在线工具 从事违反法律法规、侵害他人权益或干扰服务正常运行的行为,包括但不限于上传恶意程序、批量抓取、冒充他人、发布违法信息。一经发现,我们有权限制或终止相关账号的使用。

第四条 费用与支付
柳泉在线工具 的基础功能免费提供。若后续推出收费功能,将在开通前明确标注价格、计费周期与退款规则,由你自主选择是否购买,不在你未确认的情况下扣费。

第五条 用户内容与知识产权
你在 柳泉在线工具 中创建或上传的内容归你所有。你授予我们为提供服务所必需的、非独占的存储与展示许可。柳泉在线工具 的界面、代码与文案等知识产权归我们或相应权利人所有。

第六条 隐私与数据
我们仅在实现服务功能所必需的范围内处理你的数据,处理方式与保存期限以隐私政策为准。柳泉在线工具 的工具类功能在浏览器本地完成,输入内容不会上传服务器。

第七条 免责声明
本条款仅提供通用模板框架,不构成任何形式的法律意见。柳泉在线工具 按“现状”提供,我们不对服务绝对不中断或绝对无差错作出保证。涉及具体合规、诉讼或重大权益时,请咨询执业律师。

第八条 服务变更与终止
你可以随时停止使用 柳泉在线工具 并注销账号。你严重违反本条款或法律法规时,我们有权暂停或终止向你提供服务,并视情况提前通知,以减少对你的影响。

第九条 争议解决
因本条款产生的争议,双方应先友好协商;协商不成的,提交我们所在地有管辖权的人民法院解决。本条款的订立、履行与解释均适用 中华人民共和国法律。

第十条 通知与送达
我们通过 support@liuquan.net 或 柳泉在线工具 内公告向你送达各类通知,通知发出即视为送达。你应确保联系方式有效,联系方式变更后应及时更新,避免遗漏重要信息。

第十一条 协议更新与生效
本条款自 2026-10-01 起生效。我们更新本条款时会在页面提前公示;更新后你继续使用 柳泉在线工具,即视为接受更新后的条款;若不接受,请停止使用本服务。

第十二条 可分割性与完整协议
本条款任一条款被认定无效或不可执行,不影响其余条款的效力。本条款与隐私政策共同构成你与我们之间关于 柳泉在线工具 的完整约定,并取代此前的相关约定。

联系方式:support@liuquan.net

使用方法

  1. 填「服务名称」,默认 柳泉在线工具。这就是条款里反复出现的「本服务」,写你对外展示的产品或站点名,不要写公司全称。
  2. 填「运营主体」,默认 北京柳泉科技有限公司。这里是法律意义上的责任主体,应填营业执照上的名称全称。
  3. 填「联系方式」,默认 support@liuquan.net。条款里有两处会用到它:通知送达与账号申诉,建议填能长期收信的邮箱或客服电话。
  4. 选「适用法律」,默认 中华人民共和国法律。换成港澳台或境外法域后,第九条争议解决的表述会跟着变。
  5. 填「生效日期」,默认 2026-10-01。控件是日期选择器,格式固定为 YYYY-MM-DD,填 2026-2-1 这种缩写会被拦下。
  6. 点「生成条款」,或在任意一个输入框里按 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 面板,边改输入边观察有没有请求发出。

相关工具