使用方法
- 填甲方（信息披露方）与乙方（信息接收方）的完整主体名称，示例是
北京柳泉科技有限公司和上海示例数据服务有限公司，去首尾空白后需 2～60 个字符。 - 选签署日期，示例
2026-10-03；再填保密期限，示例3年。工具会按「签署日 + 自然年」算出到期日2029-10-03与相隔 1096 天。 - 勾选保密信息范围，默认 5 项（技术资料、商业计划、客户名单、财务数据、源代码）。这些词会直接嵌进第一条的枚举句，勾几项就写几项。
- 填违约金，示例
500000元，输出时格式化成500,000 元；再填管辖地与协议目的，目的会同时出现在第二条的使用范围里。 - 按 Enter 或点「生成协议正文」重算；「复制全文」把整份正文带进剪贴板，「载入示例」把八个字段与五个勾选项还原成默认值。
这个保密协议生成器能解决什么问题
一是把「先签一份保密协议再谈」的时间压到一分钟内。投融资接触、外包开发、渠道比价、面试候选人的作品讨论，这些场景都需要在交换敏感资料前落一份书面文件。这个保密协议生成器把八条必备条款固定下来，只让你填会变的部分，省掉从零起草时最容易漏条款的环节。
二是避免期限与到期日写错。「保密期三年」这种表述本身不完整，必须落到具体日期。工具按民法典的口径做「签署日 + 自然年」的推算，遇到 2 月 29 日这种没有对应日的起始日期会自动回退到到期月的最后一天，而不是像 setFullYear 那样悄悄滚进 3 月。
三是让单向与双向两种模式一次选清。单向协议里只有接收方承担保密义务，适合甲方单方披露资料；双向协议里双方互负义务，适合交换客户名单、互相试探合作。选错模式会让条款文本与真实意图相反，工具按选择改写第一、二条的表述，不给模棱两可的中间态。
四是把违约金写成一个具体数字而不是一句狠话。约定「依法承担全部责任」在谈判桌上没有威慑力，写「违约金 500,000 元」才可预期。工具把金额格式化成带千分位的写法，并保留「损失难以计算时按违约金赔偿、不足部分继续追偿」的兜底句。
这个保密协议生成器不做隐私政策、服务条款、Cookie 声明这类面向用户的信息合规文件，那是「隐私政策生成器」「服务条款生成器」的活；也不做租赁、授权委托、遗嘱这类强格式化的法律文书；更不做条款合规审查——它只按固定模板拼装正文，输出的是草稿而不是法律意见。
原理与规则说明：条款要素、期限推算与格式函数
生成方式是「条款骨架 + 占位符替换」，没有模板引擎。八条条款的顺序与措辞作为纯文本写在页面里（同时也负责首屏直出），占位符只有 12 个：@A@ 甲方、@B@ 乙方、@SIGN@ 签署日、@YEARS@ 年数、@DUE@ 到期日、@DAYS@ 相隔天数、@SCOPE@ 范围枚举、@PURPOSE@ 合作目的、@PLACE@ 管辖地、@PENALTY@ 违约金、@MODE@ 协议类型、@M1@ 与 @M2@ 两条双向专用句。运行期只做一次全局替换，条款正文本身不进 JavaScript——这样既把逻辑代码压到 8 KB 以内，也让「首屏不依赖脚本就有完整正文」成为天然结果。占位符用 @ 包裹而不用花括号，是因为本项目模板引擎把花括号当标签定界符解析，正文里出现花括号会被提前吃掉。
日期格式化交给 Intl.DateTimeFormat。构造时固定传 { timeZone: 'UTC', year: 'numeric', month: 'long', day: 'numeric' }，得到的是「2026年10月3日」这种中文长格式。这里必须显式指定 timeZone: 'UTC'：一旦让运行环境按本地时区渲染，东八区以外的用户会看到日期少一天，而协议里的签署日差一天就可能影响期限起算。解析时也不用 new Date('2026-10-03')，而是手工拆出年、月、日三个整数，再用 Date.UTC 组装。
期限推算按民法典第二百零一条执行。该条规定，按照年、月计算期间的，到期月的对应日为期间的最后一日；没有对应日的，月末日为期间的最后一日。所以工具先算「签署日的年月 + N 年」，再看目标月份有没有对应的日；2028-02-29 加 1 年时，2029 年 2 月没有 29 日，到期日就取 2029-02-28，而不是 JavaScript 默认滚出来的 2029-03-01。示例 2026-10-03 加 3 年，对应日存在，到期日为 2029-10-03，两个日期相差 1096 天（2028 年是闰年，多出一天）。
金额用 Intl.NumberFormat('zh-CN') 格式化。输入框里填 500000，输出成 500,000 元。中文合同里阿拉伯数字配千分位是最不容易被改动的写法——「五十万」加一横就成了「五百万」，而 500,000 改一位数字会很显眼。工具只做千分位，不生成中文大写金额，因为大写规则（是否写「整」、角分如何处理）各地法院要求不一，需要人工按当地习惯补写。
条款要素来自商业秘密的三个构成要件。《反不正当竞争法》第九条把商业秘密定义为「不为公众所知悉、具有商业价值并经权利人采取相应保密措施的技术信息、经营信息等商业信息」。第三个要件「采取相应保密措施」正是签这份协议的目的，所以第一条必须把保密信息的范围写明确——这就是勾选项的作用：勾了「客户名单」「定价策略」，第一条的枚举句里就会出现这两个词，日后发生争议时才有明确的指向，而不是笼统写「一切商业信息」。
六条约束与法条对应关系。第二条与第三条对应《民法典》第五百零一条（当事人在订立合同过程中知悉的商业秘密，无论合同是否成立，不得泄露或者不正当地使用）；第四条对应第二百零一条的期间计算；第六条对应《民法典》第五百八十五条关于违约金的规定，而违约金如果明显高于实际损失，对方可以请求法院或仲裁机构适当减少，所以工具把它做成可调数字而非写死。
完整示例（数值仅作演示）
示例条件与页面默认值完全一致：甲方 = 北京柳泉科技有限公司，乙方 = 上海示例数据服务有限公司，签署日期 = 2026-10-03，保密期限 = 3 年，违约金 = 500000 元，协议类型 = 单向，保密范围 = 5 项。复算结果如下：
- 到期日 2029-10-03（对应日存在，无需回退），与签署日相隔 1096 天；
- 若起始日换成 2028-02-29、期限 1 年，到期日为 2029-02-28，而直接调用
setFullYear会得到 2029-03-01，两者差 1 天； - 违约金
500000渲染为 500,000 元； - 第一条枚举出 5 项保密范围，与勾选数量一致；
- 固定 8 条条款：保密信息定义、保密义务、使用限制、保密期限、保密信息的返还与销毁、违约责任、争议解决与管辖、其他约定；
- 整份正文共 1248 个字符，其中汉字 1006 个，一次
textContent赋值即可渲染完成。
下面给出不同期限在同一签署日 2026-10-03 下的到期日，前 12 行默认显示，点「加载更多」展开剩余 4 行：
| 保密期限 | 签署日 | 到期日 | 相隔天数 | 是否回退月末 | 说明 |
|---|---|---|---|---|---|
| 1 年 | 2026-10-03 | 2027-10-03 | 365 | 否 | 对应日存在 |
| 2 年 | 2026-10-03 | 2028-10-03 | 731 | 否 | 对应日存在 |
| 3 年 | 2026-10-03 | 2029-10-03 | 1096 | 否 | 默认示例 |
| 5 年 | 2026-10-03 | 2031-10-03 | 1826 | 否 | 含 2028 闰年 |
| 10 年 | 2026-10-03 | 2036-10-03 | 3653 | 否 | 含 2028、2032 闰年 |
| 20 年 | 2026-10-03 | 2046-10-03 | 7305 | 否 | 本页期限上限 |
| 1 年 | 2028-02-29 | 2029-02-28 | 365 | 是 | 2 月无 29 日，取月末 |
| 2 年 | 2028-02-29 | 2030-02-28 | 730 | 是 | 2 月无 29 日，取月末 |
| 3 年 | 2028-02-29 | 2031-02-28 | 1095 | 是 | 2 月无 29 日，取月末 |
| 4 年 | 2028-02-29 | 2032-02-29 | 1461 | 否 | 2032 年 2 月有 29 日 |
| 1 年 | 2025-01-31 | 2026-01-31 | 365 | 否 | 月底起始，对应日存在 |
| 2 年 | 2025-12-31 | 2027-12-31 | 730 | 否 | 年末起始 |
| 1 年 | 2024-02-29 | 2025-02-28 | 365 | 是 | 2025 年无 2 月 29 日 |
| 5 年 | 2024-02-29 | 2029-02-28 | 1826 | 是 | 2028 有 29 日但 2029 无 |
| 10 年 | 2024-02-29 | 2034-02-28 | 3652 | 是 | 2034 年无 2 月 29 日 |
| 20 年 | 2024-02-29 | 2044-02-29 | 7305 | 否 | 2044 年 2 月有 29 日 |
输入范围与对照表
八个字段的允许范围与超限动作如下，右列是填错时结果区会显示的具体提示：
| 字段 | 允许范围 | 超限或填错时的动作 |
|---|---|---|
| 甲方名称 | 去空白后 2～60 字符 | 拒绝生成并提示「甲方名称需 2～60 个字符，你填了 N 个」 |
| 乙方名称 | 去空白后 2～60 字符 | 同上，逐字段报出实际长度 |
| 签署日期 | 1900-01-01 ～ 2100-12-31 | 空日期、越界、或 2026-02-30 这类不存在的日期一律拒绝 |
| 保密期限 | 整数 1～20 年 | 0、负数、小数、空值、超过 20 均拒绝 |
| 违约金 | 整数 1～1000000000 元 | 拒绝并提示合法区间；不接受千分位逗号以外的字符 |
| 管辖地 | 去空白后 2～30 字符 | 拒绝生成，提示填写省市级地点 |
| 保密信息范围 | 8 项中至少勾 1 项 | 一项都不勾时拒绝，提示「第一条需要有明确的保密信息范围」 |
| 协议目的 | 去空白后 2～80 字符 | 拒绝；该文本会同时写入第二条的使用范围句 |
常见误用与正确做法的对照：
| 写法 | 常见误用 | 正确做法 |
|---|---|---|
| 保密期限 | 写「永久保密」当默认值 | 填具体年数（本页 1～20）；商业秘密的保护不受约定期限限制，不需要靠「永久」二字撑 |
| 违约金 | 填 1 亿元当作威慑 | 按可预见的损失量级填；民法典第 585 条允许对方请求调减明显过高的违约金 |
| 协议类型 | 交换资料却签单向 | 双方都要给对方看资料时选「双向」，条款会切成互负义务 |
| 保密范围 | 只勾一项图省事 | 至少覆盖实际会交换的资料类型，笼统条款在争议中难以指向具体信息 |
| 使用目的 | 留空或写「合作」两字 | 写明具体事项（如「评估数据分析工具的合作可行性」），目的直接决定哪些使用算越界 |
边界与法律提示
- 本页输出的是模板草稿，不构成法律意见。八条条款覆盖的是通用要素，不针对行业监管要求（例如医疗数据、金融个人信息、涉密项目）做特别处理。正式签署前请由执业律师结合具体交易审阅，尤其是涉外主体、数据出境、竞业限制这几类情形。
- 保密期限上限是 20 年。下拉以外只能通过输入框填整数年，超出 20 年直接拒绝。原因不是法律限制，而是可预期性：超过 20 年的保密安排在实务中几乎无法执行，且接收方很难证明已履行的谨慎义务。需要更长时间保护的信息，应当通过商业秘密管理制度而不是单靠一份协议的期限条款。
- 期限届满不等于信息可以公开。《反不正当竞争法》第九条保护的商业秘密，只要仍满足「不为公众所知悉、具有商业价值、采取保密措施」三个要件就持续受保护，与协议约定的保密期限无关。第四条特意保留了「届满后仍不得泄露或者不正当使用商业秘密」这一句，删掉它会给人错误暗示。
- 违约金可以调减，也可以调整自洽性。《民法典》第五百八十五条规定，约定的违约金过分高于造成的损失的，当事人可以请求人民法院或者仲裁机构予以适当减少。所以本页把违约金做成变量而不是固定金额，同时保留「不足以弥补实际损失的，有权就差额部分继续追偿」的兜底表述。
- 到期日采用「对应日 / 月末日」口径，不再做二次修正。2 月 29 日加年回退到 2 月 28 日之后，工具不会再把日期顺延到 3 月 1 日。相隔天数按两个日期的自然日差计算，不包含签署日本身：2026-10-03 至 2029-10-03 是 1096 天，含首尾则是 1097 天，正文里给出的是前者。
- 金额只做千分位，不转中文大写。「500,000 元」是工具的输出；「伍拾万元整」需要人工补写，因为大写规则（整数是否连写「整」、有无角分、是否写「人民币」）各地要求不一，机器统一处理反而容易出错。
- 主体名称按原样写入，不做工商核验。工具不会校验名称与统一社会信用代码是否匹配、也不判断主体是否存续。名称写错会导致协议主体不适格，这一步必须在生成之后人工核对营业执照。
常见问题
生成的保密协议能直接拿去签吗？
可以当作谈判起点，但不建议直接签。这份保密协议生成器输出的是通用八条条款的草稿：它不针对行业特殊要求（医疗、金融、涉密）、不处理数据出境与个人信息、不约定竞业限制与知识产权归属的细节。签署前请把正文交给执业律师按具体交易审阅，特别是双方是否有跨境主体、是否会接触个人数据这两点。
单向和双向到底怎么选？
看谁在给资料。只有甲方向乙方披露（比如甲方发标、乙方投标），选单向——条款只约束接收方。双方都要把客户名单、报价、代码给对方看，就必须选双向，此时工具会把第一、二条改写成「甲乙双方互为披露方与接收方」并追加互负义务的表述。选错的后果是单向协议约束不了甲方，你给出的资料泄密时对方不担责。
为什么 2028-02-29 加 1 年算出的是 2029-02-28？
因为《民法典》第二百零一条规定，按年计算期间的，到期月的对应日为最后一日，没有对应日的以月末日为最后一日。2029 年 2 月没有 29 日，所以取该月最后一天 2029-02-28。如果直接用 JavaScript 的 setFullYear 加一年，引擎会自动进位得到 2029-03-01，多出一天。两种结果差 1 天，在争议里就可能落在「协议还有效」与「已经过期」的两侧。
违约金填多少算合适？
没有一个通用数字。合理区间通常与可预见的损失量级挂钩：技术外包类的保密违约金常见在合同金额的 10%～30%，投融资接触阶段可能写成固定 50 万元。要注意《民法典》第五百八十五条——约定过高时对方可以请求法院适当减少，写一个夸张的数字并不能真正锁定赔偿。本页允许填 1～1000000000 元，只是不做主观评判，具体数值需要你按项目风险定。
保密期限写 3 年够吗？
够覆盖大多数商业合作，这也是本页把默认值设为 3 年的原因：合作结束后的一两年是泄密风险最高、损失最直接的阶段，3 年与行业常见做法（2～5 年）一致。但要注意，约定 3 年不等于 3 年后信息就能公开——只要还满足商业秘密的三个构成要件，它仍然受《反不正当竞争法》保护，第四条的兜底句就是为了说明这一点。
保密信息范围勾少了会怎样？
第一条的枚举句会跟着变，勾了 5 项就只有 5 项。范围写窄的直接影响是举证困难：发生争议时你要证明对方泄露的那份资料属于协议约定的保密信息，如果第一条里没列举「定价策略」，对方就可以主张该信息不在约定范围内。建议按实际会交换的资料类型勾选，宁可多勾一两项也不要只勾「技术资料」了事。
为什么日期要指定 UTC，不用本地时区？
因为这里的日期是一个「日历日」，不是某个时间点。协议写「2026-10-03 签署」，对北京和纽约的双方都是同一天。若按本地时区渲染，运行在 UTC-5 的浏览器会把 UTC 午夜显示成前一天的 19 点，日期少一天。工具手工拆出年月日整数、用 Date.UTC 组装、再用 timeZone:'UTC' 的 Intl.DateTimeFormat 显示，链路里没有任何本地时区参与，任何地区打开都是同一天。
我的公司名称会被上传吗？
不会。整份正文由页面里的 JavaScript 在你本机拼接，没有任何网络请求。可以在浏览器开发者工具的 Network 面板里核对：点「生成协议正文」时不会产生新的请求。把页面另存为本地文件、断网后打开，功能完全一样。
相关工具
- 隐私政策生成器：面向用户的信息收集告知文件，要素是收集范围、Cookie、第三方共享，与约束交易对手的保密协议不是一类文书。
- 服务条款生成器：管的是平台与用户之间的权利义务，属于用户协议族，条款结构与 NDA 完全不同。
- Cookie政策生成器：只处理 Cookie 与追踪技术的告知与同意项，合规依据是个人信息保护相关规定。
- Disclaimer生成器：生成责任限制与风险提示段落，常用于网站底部与内容页，与本页的交易保密文书用途不同。
- 简易合同生成器：通用交易条款的骨架，适合小额采购与服务委托，保密只是其中可选的一条。
- 租赁协议生成器：房屋与设备租赁的专用要素（租期、押金、维修责任），与保密义务无关。
- SEO与营销：政策文件、条款文本与营销文案生成工具的集中入口。