技能提升网知识库没人维护，通常不是因为工具不好用
项目刚开始时，会议纪要、需求说明和决定记录都能找到。两个月后，同一份方案在聊天、共享页面和个人笔记里出现三个版本，旧结论没有标记，项目成员也不知道应该相信哪一份。团队看起来存了很多资料，真正需要回答问题时却仍要到群里问人。
问题往往出在入口、归档和通知混在了一起。当前协作资料需要多人更新，稳定知识需要长期保存，重要变更还要主动告诉受影响的人。把三类工作全部交给一个页面或一个文件夹，维护责任很快就会变得模糊。
这套流程用 Notion Skill 管理项目中的当前页面和结构化条目，用 Obsidian Skill 沉淀稳定、可迁移的 Markdown 知识，再用 Internal Comms Skill 把已经确认的变化整理成面向不同对象的通知。三项 Skill 不是在三个地方重复存同一份内容，而是分别承担协作、沉淀和传播。
先规定哪一份才算正式版本
开始整理前，先为每类资料指定唯一事实源。正在协作的计划、需求、任务背景和会议决定放在 Notion；已经稳定、将来仍会复用的方法、术语、技术判断和复盘结论再进入 Obsidian；聊天记录、录音和附件只作为证据或输入，不自动成为正式知识。
| 资料状态 | 主要位置 | 维护动作 |
|---|---|---|
| 草稿 | 当前项目工作区 | 补齐来源、负责人和待确认问题 |
| 有效 | Notion 协作页面 | 随项目推进更新，保留当前结论 |
| 稳定 | Obsidian 知识库 | 重写为脱离单次项目也能理解的笔记 |
| 已替代 | 归档区 | 注明替代它的新版本和停止使用日期 |
最重要的规则是不要复制出两个都能修改的正式版本。若一条稳定知识仍需要从项目页进入，可以保留索引和指向关系，但要明确真正需要维护的是哪一份。
入口不是收件箱，而是一道质量门
新资料进入知识库前，至少补齐标题、来源、负责人、当前状态、敏感级别、最近复核日期、下次复核日期和正式位置。缺少负责人的页面只能算临时记录，缺少复核日期的制度和流程很容易在无人察觉时过期。
Notion Skill 可以通过 API 读取和更新页面、数据源及属性，适合把这些字段做成统一结构。连接前要先确认操作的是正确页面或数据源，并把目标页面明确共享给集成。权限只开放到工作需要的范围，写入前先读取现有结构，避免把数据库标识、数据源标识或属性名称用错。
入口还要拦住三类内容：无法确认出处的结论、已经存在的重复页面、包含不必要敏感信息的原始材料。资料很多时，自动化可以帮助找候选项，但是否成为正式知识仍应由负责人确认。
从当前资料晋级为稳定知识
项目页不是写完就搬进长期库。只有当一项决定已经生效、方法经过实际使用、术语得到团队确认，或复盘结论能脱离原项目被再次使用时，才适合晋级。晋级时要去掉临时任务和聊天上下文，补上适用范围、前提条件、例外情况、来源和最后复核时间。
Obsidian Skill 面向由普通文件夹和 Markdown 文件组成的库，适合保存可迁移、可连接的长期笔记。执行前要确认正确的 vault 路径，并避开配置目录。移动或重命名笔记时，应使用能够同步更新内部链接的方式，完成后检查反向链接和断链，不能只看文件已经移动成功。
不是所有内容都值得晋级。每日状态、一次性排期和已结束的临时讨论留在项目档案中即可。长期知识库只保留未来有人会查、会复用、会据此做决定的内容。
维护不是定期大扫除，而是随变化闭环
每次重要结论变化，都触发一次小闭环：更新正式版本，标记旧版本已被替代，检查引用它的页面，通知受影响的人，再设置下一次复核日期。这样维护成本分散在每次变化上，不会堆成季度末没人愿意接手的大扫除。
复核时优先找五类风险：没有负责人的页面、超过复核日期的流程、同名但结论不同的正式文档、指向失效位置的链接、已经更新却没有通知使用者的决定。自动检查可以列出候选问题，负责人再判断是修订、合并还是归档。
通知只讲变化，不要把整篇文档再发一遍
正式页面更新后，如果使用者不知道发生了什么，知识库仍然没有发挥作用。Internal Comms Skill 适合把变化整理成项目更新、状态报告、FAQ 或领导简报。通知至少说明五件事：改了什么、为什么改、影响谁、需要做什么、从什么时候生效，并指向团队内部的正式入口。
通知中的信息要区分已经确认、暂定和仍待决定三种状态。不要把讨论中的方案写成已经生效的制度，也不要把未经授权的项目细节发送给无关对象。不同受众可以收到不同长度的版本，但事实、日期和行动要求必须一致。
三段提示可以直接照着改
整理当前项目空间时：
读取指定项目空间的页面结构，按标题、来源、负责人、状态、敏感级别、最近复核日期、下次复核日期和正式位置列出缺失项。先输出建议修改清单，不要直接写入；标记可能重复或互相冲突的页面。
准备长期知识时：
从已经确认稳定的项目资料中提取可长期复用的知识，改写为独立 Markdown 笔记。每篇写明适用范围、前提、例外、来源和复核日期。先展示计划创建、移动或重命名的文件，并检查这些操作会影响的内部链接。
发送变更通知时：
根据已经批准的新版本生成内部更新，分别列出已确认事实、暂定事项和待决定问题。说明变化、原因、受影响对象、所需行动、负责人和生效日期，不补写来源中没有的结论。
权限和备份要在自动化之前确定
Notion 连接应只访问确实需要处理的页面，首次写入先在测试页面验证字段和权限。Obsidian 操作前应确认 vault 和备份，批量移动、重命名或删除文件要单独复核。内部通知只使用完成任务所需的最小信息，涉及人员、客户或未公开项目时，还要核对接收范围。
凭据不要放进页面、笔记正文或提示词。自动化输出也不应覆盖原始证据。即使写入成功，也要重新读取目标页面或文件，确认内容、位置、链接和权限符合预期。
上线前检查这七项
- 每类资料都有唯一事实源，没有两个可同时修改的正式版本。
- 每个有效页面都有来源、负责人、状态和复核日期。
- 只有稳定且可复用的内容进入长期知识库。
- 移动和重命名后已经检查内部链接与反向链接。
- 旧版本已经标明替代关系，没有悄悄留在搜索结果中。
- 重要变化已经通知受影响的人，行动和生效日期清楚。
- 写入权限、敏感信息范围和备份都经过确认。
可维护的知识库不是资料数量最多的地方，而是每个人都知道资料从哪里进入、何时升级、谁来负责、旧版如何退出。协作空间处理现在，长期笔记保存稳定知识，内部通知推动变化真正发生。边界清楚以后，知识才不会随着项目结束一起失效。
