研发文档要发给外包团队或合作伙伴，先要回答一个判断问题：这份文档属于什么密级，当前合作进行到哪个阶段，它又是什么类型的资料。三个条件叠加，才能得出直接外发、审批后限权外发、限权外发留痕还是禁止外发的结论。本文给出一张可套用的外发判定表，配套五步操作、角色分工和完成检查清单；在ONES知识库与项目管理中，密级字段、审批流、访问限权和外发台账可以作为承载这套机制的落点。
要点总览（TL;DR）
- 研发文档外发先按公开、内部、秘密、机密四级定密，再叠加合作阶段与文档类型，形成一张判定表，把结论归入直接外发、审批后限权外发、禁止外发三档。
- 公开级可直接外发；内部级限权外发并留痕；秘密级需审批后限权外发，接洽阶段通常只能现场查阅；机密级禁止外发，业务确需时走脱敏改写或现场查阅并记录例外。
- 落地靠五步：盘点打标、查表出结论、按密级定审批人、按最小必要配置限权、登记台账并回收，每步都有输入、动作、输出和完成标志。
- 责任要分到人：文档所有者打标发起，部门负责人与安全法务分级审批，管理员配置权限并维护台账，合作方确认接收与删除。
- 机制是否可用按清单核对：标注覆盖率、判定一致性、审批完整性与时效、限权实际生效、台账齐全、回收闭环、例外有记录。
外发判定表：分类分级怎么定、三档结论怎么判
判定表的第一维是密级。研发文档按泄露后对业务、客户和合规的影响划分为四级：公开级指已对外发布或明确可公开的材料，如公开产品说明、已上线的接口文档；内部级指仅限公司内部使用、泄露后造成一般被动的内容，如常规需求说明、内部会议纪要；秘密级指泄露后会带来竞争损失或客户风险的内容，如核心设计文档、未公开的架构方案、关键测试数据；机密级指泄露后可能触发合同违约、监管处罚或重大安全事件的内容，如核心源码、密钥与配置、客户敏感数据、未公开的合同条款。
第二维是合作阶段。接洽阶段双方尚未签署保密协议，外发范围应压到最低；执行阶段有合同与保密条款约束，可按约定范围共享；验收阶段以交付物核对为主，共享范围应收窄到验收所需材料；合作结束后原则上停止新增外发，仅保留必要的收尾与审计访问。同一份秘密级文档，在执行阶段可以审批后限权外发，在接洽阶段通常只能提供脱敏摘要。
第三维是文档类型。需求文档与测试用例的敏感度集中在业务逻辑与缺陷信息；设计文档与源码涉及实现方案和知识产权；运维文档常含环境地址、账号与拓扑；合同类文档涉及商务条款与责任边界。类型决定限权时重点限制什么，例如源码类要限制下载与转发，运维类要遮蔽地址与账号，合同类要限制复制与打印。
三个条件叠加后，结论归入三档：直接外发、审批后限权外发（含内部级限权外发留痕）、禁止外发。下表给出常用组合的判定参考，实际执行时以企业自己的密级定义为准。
| 密级 | 接洽阶段 | 执行阶段 | 验收阶段 | 合作结束后 |
|---|---|---|---|---|
| 公开级 | 直接外发 | 直接外发 | 直接外发 | 直接外发 |
| 内部级（需求、测试用例） | 脱敏摘要，限权外发 | 限权外发并留痕 | 限权外发并留痕 | 停止新增，回收访问 |
| 秘密级（设计、运维） | 禁止外发，可现场查阅 | 审批后限权外发 | 审批后限权外发，范围收窄 | 禁止外发，回收并确认删除 |
| 机密级（源码、密钥、客户数据、合同） | 禁止外发 | 禁止外发，仅现场查阅或脱敏改写 | 禁止外发 | 禁止外发 |
边界情形需要单独说明。文档含多份材料拼接时，按其中最高密级判定；文档部分章节涉密时，可拆分后对非涉密部分外发，拆分记录随台账保存；合作方为同一集团关联主体时，仍按合同约定的共享范围执行，不因关联关系自动降级。禁止外发的文档如果业务确实需要，走脱敏改写或现场查阅，并在台账中记录例外原因与批准人。
执行步骤：从打标到外发的五步操作
判定表解决怎么判，五步操作解决怎么做。每一步都明确输入、动作、输出和完成标志，避免流程停在纸面。
第一步：存量文档盘点与密级标注
输入是拟共享项目下的文档清单，动作是逐份确认文档类型、内容敏感度和是否已公开，按四级密级打标，输出是带密级字段的文档清单。完成标志是清单内每份文档都有密级，且同一类型文档的判定口径一致。存量较大的项目可先按目录批量初判，再对秘密级及以上逐份复核。
第二步：按判定表生成外发结论
输入是已打标的文档清单、合作阶段和合同中的共享范围条款，动作是查判定表得出每份文档的结论，输出是一张外发结论清单，列明文档、密级、结论和依据。完成标志是清单中不存在无结论的文档，禁止外发项已单独标出。
第三步：审批发起与审批人确定
输入是结论为“审批后限权外发”的文档，动作是由文档所有者发起审批，审批人按密级确定：内部级由部门负责人审批，秘密级由部门负责人加安全或法务审批，涉及客户数据的加客户负责人确认。输出是审批记录，包含审批人、审批意见和有效期。完成标志是审批通过且有效期明确，审批未通过的文档退回改写或转为禁止外发。
第四步：限权配置
输入是审批通过的文档和外发对象名单，动作是按最小必要原则配置访问权限：可见范围限定到具体人员或合作方账号，设置访问有效期与审批有效期一致，开启水印，关闭下载与转发，必要时关闭复制与打印。输出是生效的权限配置记录。完成标志是用合作方账号实际验证一次，确认可见、不可下载、不可转发，到期自动失效。
第五步：外发登记与回收
输入是已外发的文档与权限记录，动作是在外发台账中登记文档名称、密级、接收方、外发时间、有效期、审批单号和回收状态，到期前提醒回收，合作结束时统一关闭访问并索取删除确认。输出是完整台账和回收回执。完成标志是台账记录与权限系统状态一致，回收动作有回执或截图留证。
角色与交付物：谁打标、谁审批、谁登记
流程空转通常源于责任不清。把打标、审批、配置、登记四类动作分配到具体角色，并约定各自的交付物，才能让判定表真正运转。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 文档所有者（研发负责人） | 确认文档类型与内容敏感度，完成密级标注，发起外发申请与审批 | 带密级的文档清单、外发申请单 |
| 部门负责人 | 审批内部级与秘密级外发，确认业务必要性 | 审批意见与有效期 |
| 安全或法务 | 审批秘密级及涉客户数据的外发，判定合规风险与合同约束 | 合规意见、例外批准记录 |
| 知识库管理员或项目管理员 | 配置可见范围、有效期、水印与下载转发限制，维护外发台账 | 权限配置记录、外发台账 |
| 外包方或合作伙伴接口人 | 确认接收范围，按约定使用，合作结束时确认删除 | 接收确认、销毁回执 |
角色之间有两处交接容易断档。一是文档所有者发起审批后，管理员未及时配置权限，导致审批通过但文档仍不可见或权限过宽，需要约定审批通过后的配置时限。二是合作结束时，管理员关闭了访问但未取得对方删除确认，台账上应把“已关闭访问”和“已确认删除”作为两个状态分别记录。
在ONES中，知识库文档可以设置密级属性与访问范围，审批可通过工作项流程承载，外发记录可作为台账工作项持续跟踪状态；这套承载方式适合已经把研发文档和项目协作放在同一平台上的团队，减少判定、审批、登记分散在多个工具中的交接成本。
示例：一次外包协作中的外发判定全过程
以下为演示情景。某研发团队与一家外包公司合作开发一个模块，合作进入执行阶段，双方已签署保密协议。团队需要向对方共享接口设计文档和测试用例，并提前准备验收阶段的材料。
接口设计文档判定为秘密级：它包含未公开的接口协议与数据结构，泄露会影响产品竞争力。执行阶段、设计类文档，按判定表结论为审批后限权外发。测试用例判定为内部级：内容涉及业务规则但已脱敏，结论为限权外发并留痕。另有一份部署配置文档，含测试环境地址与账号，判定为秘密级，但其中账号信息属于机密级内容，处理方式是拆分：地址与拓扑部分审批后限权外发，账号与密钥部分禁止外发，改为由团队人员在对方现场配置。
审批路径上，接口设计文档由研发负责人发起，部门负责人与安全负责人依次审批，审批单注明外发对象为外包公司两名接口人、有效期与执行阶段一致。测试用例由研发负责人发起，部门负责人审批即可。限权配置上，两份文档均限定到具体人员账号，开启水印，关闭下载与转发；接口设计文档额外关闭复制与打印。配置完成后用对方账号验证一次，确认可见范围与限制生效。
外发台账记录四行：接口设计文档、测试用例、部署配置（拆分后的非涉密部分），以及被禁止外发的账号密钥部分（记录例外处理方式与批准人）。合作进入验收阶段后，管理员将测试用例的访问范围收窄到验收核对所需章节；合作结束时关闭全部访问，取得对方接口人的删除确认回执，台账状态更新为“已回收”。
完成检查：外发管理是否可用的核对项
机制是否真正运转，可以用下面这份清单逐项核对。建议在每个合作项目结束时核对一次，并按季度抽查。
- 密级标注覆盖率：拟共享文档是否全部完成密级标注，抽查同一类型文档的判定是否一致。
- 判定一致性：外发结论清单是否逐份对应判定表，禁止外发项是否单独列出并有处理方式。
- 审批完整性：审批记录是否包含审批人、意见和有效期，审批人是否符合密级对应的审批层级。
- 审批时效：从发起到通过的时间是否在约定时限内，超时是否有催办或升级记录。
- 限权生效：用接收方账号实际验证，可见范围、有效期、水印、下载与转发限制是否按配置生效。
- 台账齐全：外发台账是否覆盖文档名称、密级、接收方、时间、有效期、审批单号和回收状态。
- 回收闭环：到期回收是否有记录，合作结束是否有删除确认回执，“已关闭访问”与“已确认删除”是否分别标记。
- 例外处理：禁止外发项的例外是否有脱敏改写记录、现场查阅记录和批准人签字。
核对中发现的问题按两类处理：标注与判定不一致的，回到第一步统一口径并补充判定示例；限权或回收未闭环的，由管理员在台账中挂起并限期处理。清单全部通过，说明这套按分类分级判断审批、限权和禁止外发的机制已经可以稳定使用。
常见问题
合作方是长期合作伙伴，已经签过框架保密协议，外发时还需要逐份审批吗？
框架保密协议解决的是法律约束问题，审批解决的是每一次外发的业务必要性与范围问题，两者不能互相替代。建议按密级区分：内部级文档在协议约定范围内可以限权外发并留痕，由文档所有者发起、部门负责人确认即可；秘密级文档仍逐份审批，审批时把框架协议作为依据附上，重点确认本次外发范围是否超出协议约定的资料类别。合作阶段变化时也要重新判断，接洽阶段即便有框架协议，秘密级文档通常也只提供脱敏摘要或现场查阅。
文档里只有一小部分内容涉密，整份禁止外发会影响协作，怎么处理？
按最高密级判定是原则，但可以拆分后分别处理。把涉密章节剥离，非涉密部分按拆分后的密级重新判定并走对应流程，拆分记录随外发台账保存，注明原文档、拆分依据和批准人。涉密部分如果对方确实需要了解，改为现场查阅或脱敏改写，例如把真实地址、账号替换为示例值。需要注意拆分后的文档仍可能通过上下文推断出敏感信息，拆分前由文档所有者与安全人员共同确认，避免出现形式拆分、实质泄露的情况。
限权配置做了，但怎么确认对方真的不能下载和转发？
配置完成不等于生效，需要用接收方账号实际验证一次。验证内容包括：用对方账号登录后能否看到文档、可见范围是否只覆盖约定人员、下载与转发按钮是否不可用、水印是否显示、访问到期后是否自动失效。验证结果截图或记录存入台账。另外要区分平台内限制与对方本地行为的边界：平台能限制下载和转发，对方通过截屏等方式留存内容难以完全阻止，这也是秘密级文档要控制外发范围、机密级文档禁止外发的原因，必要时在合同中约定使用与销毁义务。
合作结束后，访问已经关闭，台账上还需要记录什么？
建议把“已关闭访问”和“已确认删除”作为两个独立状态分别记录。关闭访问是平台侧动作，由管理员执行并留存操作记录；确认删除是对方侧动作，需要取得接口人的书面或邮件确认，作为回收回执归档。两个状态都完成，该条外发记录才算闭环。合作结束后的收尾期内如果还有审计或验收核对需要访问，单独开具有限期的临时权限，并在台账中注明用途和到期时间，避免用长期权限代替临时授权。
团队规模不大，是否也需要完整的判定表和台账？
判定表和台账的价值在于让每次外发有据可查，与团队规模关系不大，但形式可以简化。小团队可以先用一张表把密级定义、三档结论和审批人固定下来，台账用共享表格维护，字段保留文档名称、密级、接收方、时间、有效期、审批人和回收状态即可。真正需要完整机制的是外发频次高、涉及客户数据或核心设计的场景。随着合作方增多，再逐步把审批和权限配置迁移到知识库与项目管理工具中承载，减少人工核对的遗漏。
