知识分享有效期由三个要素共同决定：知识对象的敏感度、接收方的分享范围、以及这次分享的用途时效。先给知识定密级，再按分享范围收紧期限，最后按用途确定长短，并把期限和依据写入分享记录，到期时执行复核、续期或回收。本文给出一张定档表、一套六步操作流程、角色分工、三个填写范例和一份验收清单，供团队建立可执行的期限机制。
要点总览（TL;DR）
- 知识分享有效期按敏感度、分享范围、用途时效三要素定档，取三者中最严格的期限作为结论，机密类通常不超过1个月。
- 分享范围逐级收紧期限：个人定向分享可按用途给足时间，跨部门与外部合作方分享应显著缩短，范围扩大时需重新定档。
- 执行分六步：标注密级与时效、匹配默认期限、设置到期动作、写入分享记录、通知接收方、到期前复核并登记结果。
- 知识所有者定档与申请续期，部门或安全负责人审批受限及以上对象，平台管理员配置策略并执行到期动作，接收方反馈使用需求。
- 验收看五项：每类对象有默认期限、分享记录含期限与依据、到期动作有人执行、续期有审批路径、异常情况有处置规则。
先定三要素：敏感度、范围、用途决定期限档位
确定有效期时，先判断知识对象本身有多敏感，再看它要交给谁，最后看这次分享要支撑多长的使用周期。三个要素各自给出一个期限区间，取其中最短的作为初始档位，再按冲突取舍规则微调。这样任何一份知识对象都能映射到一个明确档位，避免每次分享都临时拍脑袋。
敏感度分级与期限的对应关系
敏感度决定期限的上限。密级越高，可分享的时间窗口越短，复核频率越高。下表给出一个可直接采用的基准区间，团队可在此基础上按自身管理要求收紧，不建议放宽。
| 敏感度等级 | 典型内容 | 建议期限上限 | 到期动作倾向 |
|---|---|---|---|
| 公开 | 对外宣传资料、公开白皮书 | 可长期有效，按版本更新复核 | 转正式发布，随版本迭代 |
| 内部 | 内部制度、通用操作手册、团队复盘 | 6–12个月 | 提醒复核，确认后转正式归档 |
| 受限 | 项目过程文档、跨部门方案、客户交付材料 | 1–6个月 | 到期复核，未续期则收回 |
| 机密 | 核心技术方案、未公开商业信息、敏感合同 | 按需短设，通常不超过1个月 | 到期自动失效，逐次申请 |
分享范围对期限的收紧作用
同一份知识，分享范围越大、越靠近组织外部，期限越应缩短。个人之间的定向分享可以按用途给足时间；团队内分享按内部档位执行；跨部门分享因接收方难以持续跟踪，期限应比团队内更短；外部合作方分享则一律按最短档位处理，并明确回收时点。范围扩大时，原定期限不自动延长，需要重新定档。
用途时效如何影响期限长短
用途决定期限的下限需求。一次性交付（如给合作方一份阶段性说明）按交付节点设期限，交付完成即可回收；项目周期内的参考材料，期限与项目阶段对齐，阶段结束触发复核；长期参考类知识（如通用规范）可以给较长周期，但应绑定版本复核节奏，避免内容过时仍在流转。用途越短，期限越贴近实际使用窗口，减少无谓的长期敞口。
三要素冲突时的取舍顺序
三个要素给出的期限不一致时，按以下顺序取舍：先满足敏感度要求，密级给出的上限不可突破；在敏感度允许的范围内，按分享范围收紧；最后才按用途时效在剩余区间内调整长短。举例来说，一份受限技术方案要跨部门使用一个季度，敏感度上限为6个月、跨部门收紧到3个月、用途需要3个月，最终取3个月并设置到期复核。若用途需要超过范围允许的期限，应拆分分享批次或提升审批层级，而不是直接延长。
三要素期限定档表
把上述规则合并成一张可直接填写的定档表，使用时逐列勾选，取最严格的一档作为结论。
| 要素 | 取值 | 对期限的作用 |
|---|---|---|
| 敏感度 | 公开 / 内部 / 受限 / 机密 | 给出期限上限，机密最短 |
| 分享范围 | 个人 / 团队内 / 跨部门 / 外部合作方 | 逐级收紧，外部最短 |
| 用途时效 | 一次性交付 / 项目周期 / 长期参考 | 给出下限需求，越短越贴近使用窗口 |
| 结论 | 取三者中最严格的期限 | 写入分享记录，作为到期依据 |
操作步骤：从定档到写入分享记录的六步
定档结论要落成动作才有约束力。以下六步按顺序执行，每步都说明输入、动作、输出和完成标志，团队可据此形成固定的分享流程。
第一步：识别知识对象并标注密级与时效类型
输入是待分享的知识对象本身。动作是确认它的内容属性，标注密级（公开、内部、受限、机密）和时效类型（一次性交付、项目周期、长期参考）。输出是带密级与时效标签的知识条目。完成标志是该条目在知识库中可被检索到密级字段，且分享人对此无异议。密级判断有疑问时，按较高一级处理，后续由审批人下调。
第二步：选择分享范围并匹配默认期限
输入是已标注的知识条目和接收方名单。动作是确定分享范围属于个人、团队内、跨部门还是外部合作方，并从定档表中取出对应的默认期限。输出是初始期限值。完成标志是期限值有明确起算日和到期日，且与定档表一致；若因用途需要偏离默认值，需记录偏离理由。
第三步：设置到期动作
输入是初始期限和知识对象的用途。动作是从三类到期动作中选择一类：自动失效（到期即停止访问）、提醒复核（到期前通知责任人确认是否续期）、转正式发布（内容成熟，转为长期有效版本）。输出是到期动作类型。完成标志是动作类型与密级匹配，机密类默认自动失效，内部类默认提醒复核。
第四步：记录分享人、接收方、期限与依据
输入是前三步的全部结论。动作是把分享人、接收方、起止日期、密级、分享范围、用途、到期动作和定档依据写入分享记录。输出是一条完整的分享记录。完成标志是记录字段齐全，任何人凭记录能复现定档过程。这一步是后续追溯和责任落实的基础，字段缺失的记录视为未完成分享。
第五步：通知接收方并说明续期方式
输入是分享记录。动作是在分享时同步告知接收方有效期、到期后的影响以及续期申请路径。输出是接收方确认知悉的记录。完成标志是接收方明确回复或系统留痕确认。提前告知能减少到期时的争议，也让接收方在需要时主动发起续期。
第六步：到期前的复核触发与结果登记
输入是临近到期的分享记录。动作是在到期前触发复核：知识所有者确认内容是否仍有效、接收方是否仍需访问、范围是否应调整，然后选择续期、收回或转正式发布。输出是到期处置结果。完成标志是处置结果登记在分享记录上，状态从“生效中”变为“已续期”“已收回”或“已转正”。未在到期前完成复核的，按到期动作默认执行。
角色与交付物：谁定档、谁审批、谁复核
期限机制失效最常见的原因是没人对到期负责。把定档、审批、执行、反馈四类职责分到具体角色，并为每个角色规定交付物，期限才有落点。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| 知识所有者 | 标注密级与时效，提出定档与续期申请，到期前完成内容复核 | 定档记录、续期申请、复核结论 |
| 部门或安全负责人 | 审批受限及以上对象的期限，处理超默认期限的偏离申请 | 审批意见（同意、缩短或驳回） |
| 平台管理员 | 配置默认期限策略与到期动作，执行到期失效与提醒 | 策略配置记录、到期执行日志 |
| 接收方 | 在到期前反馈是否仍需访问及用途变化 | 使用反馈、续期需求说明 |
职责边界要写清楚：知识所有者对定档依据的准确性负责，审批人对期限是否合规负责，平台管理员对到期动作是否按时执行负责，接收方对反馈的真实性负责。到期处置单由知识所有者发起、审批人确认、平台管理员执行，三方留痕，避免期限到期后无人处理或随意延期。
在工具层面，这套流程需要知识库能承载密级标注、分享记录和到期复核状态。ONES 的知识库以页面树组织内容，支持页面共享，并提供从所有页面到单个页面、从内容编辑到内容导出的不同颗粒度权限管控，可作为分享范围与密级落地的承载方式；分享记录中的期限、依据和复核结论可以随文档状态一并维护，到期复核时由知识所有者更新状态、审批人确认，形成可追溯的处置链路。是否支持按时间自动失效，需在选型时向厂商核验。
示例：三类知识对象的有效期设定
以下三个示例演示三要素如何落到具体期限和到期动作，可直接作为填写模板迁移到其他知识对象。
示例一：对外产品资料分享给合作方
某产品介绍文档密级为公开，分享范围为外部合作方，用途为支持一次联合市场活动。按定档表，公开类可长期有效，但外部范围要求收紧，用途为一次性交付，最终期限设为活动结束后30天。到期动作为收回访问权限。定档依据记录为“公开密级+外部范围+一次性用途，取活动窗口加缓冲期”。到期后由知识所有者确认活动已结束，平台管理员执行回收，记录状态改为“已收回”。若合作方需要继续使用，重新发起分享并说明新用途。
示例二：内部项目复盘文档在团队内分享
某项目复盘文档密级为内部，分享范围为团队内，用途为项目周期内参考。期限设为6个月，到期动作为提醒复核。定档依据为“内部密级+团队范围+项目周期参考”。到期前两周触发复核，知识所有者确认复盘结论仍适用，且项目已进入下一阶段，选择转为正式归档，期限改为随版本更新复核。若复盘内容涉及已结束项目的临时数据，则选择收回而非转正。
示例三：受限技术方案跨部门分享
某技术方案文档密级为受限，分享范围为跨部门，用途为支撑一个季度的联调工作。敏感度上限6个月、跨部门收紧到3个月、用途需要3个月，最终期限设为3个月，到期动作为到期复核，未续期则收回。定档依据记录三要素取值及取舍过程。复核时由知识所有者确认联调是否完成、方案是否更新，接收部门反馈是否仍需访问。若联调延期，需提交续期申请，由部门负责人审批，续期不超过一个季度，并重新登记依据。
完成检查：期限机制是否可用的核对项
机制建立后，用以下清单逐项核对。每项都能给出明确的是或否，全部为“是”才说明期限机制可用；存在“否”的项，按对应动作补齐后再验收。
| 核对项 | 判断标准 | 不满足时的补齐动作 |
|---|---|---|
| 每类知识对象是否有默认期限 | 公开、内部、受限、机密四类均有对应期限区间，且已写入制度或配置 | 按定档表补全四类默认值 |
| 分享记录是否包含期限与依据字段 | 任取一条分享记录，能查到起止日期、密级、范围、用途和定档依据 | 补充记录模板字段，回溯补齐在途分享 |
| 到期动作是否明确且有人执行 | 每条记录都标注了到期动作类型，且能指出执行人 | 明确动作类型与执行角色，纳入平台配置 |
| 续期是否有审批路径 | 续期申请有指定审批人，审批结论有留痕 | 设定续期审批层级与时限 |
| 异常情况是否有处置规则 | 提前终止、范围扩大、接收方变更均有对应处理规定 | 补充异常处置条款并通知相关角色 |
除表格核对外，还可抽查若干条已到期的分享记录，确认处置结果已登记、状态已更新。抽查能发现“制度有、执行无”的情况，比只看制度文本更能反映机制是否真正运转。期限机制的价值在于让每一次分享都有明确的起止和责任人，定档有依据、到期有动作、异常有规则，三者齐备即可投入使用。
常见问题
分享中途接收方范围扩大，原定期限需要调整吗？
需要重新定档。范围扩大意味着暴露面变化，原期限不再适用。按取舍顺序先看敏感度上限是否被突破，再按新的分享范围收紧期限，最后核对用途是否仍成立。调整后更新分享记录中的范围、期限与依据，并通知新增接收方知悉有效期。若扩大后的范围超出原审批层级，应重新提交审批，而不是在原记录上直接延长。
到期后接收方仍需要访问，续期该怎么走？
续期按新一次分享处理，而非简单延期。知识所有者先复核内容是否仍有效，接收方说明继续使用的用途和预计时长，再按三要素重新定档并提交审批。续期期限从新的起算日开始计算，不叠加原期限。受限及以上对象的续期由部门或安全负责人审批，审批意见与新的定档依据一并登记在分享记录上，状态更新为“已续期”。
知识内容在有效期内更新了版本，期限要跟着变吗？
版本更新不自动改变期限，但应触发一次复核。内容变化可能影响敏感度判断：新增了未公开数据，密级可能上调，期限应相应缩短；删减了敏感内容，可维持或适度放宽。处理方式是由知识所有者在更新版本时确认密级与用途是否变化，变化则重新定档并更新记录，未变化则保留原期限，并在记录中注明版本更新时点，便于到期复核时对照。
团队规模小、分享频次低，也需要建这套机制吗？
可以简化，但不宜完全省略。频次低的团队可先只做两件事：给知识对象标注密级，在分享时记录接收方和到期日。到期动作可先采用提醒复核，由知识所有者自行确认，暂不设独立审批环节。随着分享对象中出现受限或机密内容、或接收方扩展到外部合作方，再补充审批层级和异常处置规则。机制的目的是让每次分享有起止和责任人，形式可以随规模调整。
到期自动失效和提醒复核，应该优先选哪种？
按密级选择。机密类默认自动失效，到期即停止访问，需要继续使用则逐次申请，避免长期敞口；受限类可用到期复核，未完成复核则按失效处理；内部类默认提醒复核，确认后转正式归档；公开类可长期有效，随版本更新复核。选择时还要考虑接收方能否及时响应：外部合作方难以持续跟踪，倾向自动失效并提前告知；团队内成员便于沟通，提醒复核更合适。
