资料分布在多个文件夹、项目和对话里，长期积累后难以检索、关联和复用。
建立 raw/wiki 分层、frontmatter、索引、hot 缓存、项目页和跨文档链接规则，让 AI 可以按任务读取并维护知识库。
形成了可用于日常捕捉、项目管理、内容生成和自动化调度的知识底座。
背景：资料增长速度超过人的记忆能力
myWiki 的起点不是为了做一个漂亮的笔记库，而是为了处理一个非常具体的问题：AI 对话、项目资料、日记、书摘、临时想法和自动化记录不断增加，人的记忆已经无法稳定追踪它们之间的关系。很多材料本身有价值，但如果散落在不同文件夹、不同项目和不同对话里，真正要复用时仍然像不存在一样。
这个案例的核心目标，是让资料从“被保存”变成“能被重新调用”。保存只是第一步，真正的价值在于后续能不能按问题找到相关材料，能不能把多个项目中的模式连接起来，能不能让 AI 在执行任务时读到正确上下文，而不是每次都从零解释。
问题：普通笔记结构无法支撑 AI 协作
普通笔记系统通常面向人阅读：标题、目录、正文、链接已经足够。但当 AI 也要参与维护和调用时，结构要求会变得更高。AI 需要知道哪些是原始材料，哪些是整理后的知识，哪些内容可以修改，哪些内容只能引用，哪些页面代表项目状态，哪些页面只是临时想法。
如果这些边界不清楚，AI 很容易把临时观点当成稳定结论，把原始材料改坏，或者在回答问题时引用过期页面。因此 myWiki 不是单纯扩展目录，而是建立了一套面向人和 AI 双方都能理解的知识治理规则。
结构设计：raw 与 wiki 分层
系统把原始素材和知识成果分开。raw 层保存对话、摘录、文章、语音转录和附件，原则上只读；wiki 层保存经过整理的项目页、概念页、方法页、问题页和场景页。这个分层让资料保留来源，也让后续加工有明确位置。AI 可以读取 raw，但不应该随意改动 raw；AI 可以维护 wiki，但必须遵守页面类型和链接规则。
这种分层解决了两个常见问题：一是保留证据链，二是避免整理过程污染原始资料。当后续需要追溯某个观点从哪里来，可以回到 raw；当需要把材料转成行动方案，则进入 wiki。
运行方式：从被动存档到主动工作台
myWiki 不是只在整理资料时使用，而是逐渐变成日常工作台。项目启动时创建项目页，过程中记录决策和待办，阶段结束后沉淀复盘。新的想法先进入临时区域，再根据价值转成 idea、concept、playbook 或 project。这样知识不是一次性整理，而是在工作流中不断生长。
AI 在其中承担的角色也不是替人思考，而是帮助扫描关联、提取结构、生成草稿、维护索引和检查缺口。真正的判断仍然由人完成，尤其是哪些内容应升级为稳定概念，哪些内容仍然只是尝试。
结果：知识库成为项目连续性的基础
这个系统的结果不是某个单点功能，而是连续性提高了。一个项目暂停几周后，可以通过项目页恢复上下文；一个想法在多个场景中反复出现，可以升级为概念；一个处理问题的方法被多次复用，可以正式变成 playbook。知识不再只是积累，而开始具备组织能力。
更重要的是，myWiki 让 AI 协作变得可控。AI 不再依赖一次性提示词，而是可以围绕已有结构读取上下文。这样每次协作的质量更稳定，也更容易追溯为什么得出某个结论。
这个案例说明了什么
这些案例不是为了展示一个孤立功能，而是为了说明善意AI处理问题的方式：先把真实场景拆开，再建立资料、流程、复核和输出之间的关系。AI 的价值不在单次生成，而在持续减少混乱，让重复出现的问题能够被稳定处理。
每个案例都有一个共同特征：先从内部真实问题出发，而不是先选择工具。只有问题足够真实，样本足够具体，系统设计才不会停留在演示效果。
可复制的不是界面，而是方法
案例中的页面、目录和模块不应该被简单照搬。不同团队的资料来源、责任结构、内容边界和使用习惯不同，真正可复制的是方法：定义场景，梳理输入，明确输出，保留人工复核，记录错误样本，持续迭代。
如果直接复制界面，很容易忽略背后的业务约束。比如知识库看起来都是文档管理，但有的团队需要客户问答，有的团队需要项目复盘，有的团队需要内容素材。目标不同，结构就应该不同。
从小闭环开始，而不是一次做全
案例都遵循一个原则：先做小闭环。小闭环意味着一个明确问题、一组真实样本、一个可复核输出、一个维护责任人。这个范围足够小，才容易快速判断系统是否真的有用。
如果第一版就试图覆盖所有资料、所有角色和所有流程，项目很容易变成庞大的空架子。相反，一个小闭环跑顺以后，团队会更清楚下一步应该扩展什么，也更清楚哪些功能暂时不需要。
复核机制决定系统能不能长期使用
AI 参与工作流以后，复核不是附加环节，而是核心设计。案例中所有关键输出都需要人确认：知识库答案要看来源，阅读结论要回到原文，内容稿件要检查事实和边界。没有复核机制，系统越自动化，风险越难发现。
好的复核机制不会让效率降低，反而会让负责人把注意力集中在真正需要判断的部分。AI 处理重复整理，人处理判断和承诺，这样分工更稳定。
资料治理是所有案例的底层能力
无论是第二大脑、辅助阅读还是内容平台，底层问题都是资料治理。资料从哪里来，是否可公开，是否过期，应该放在哪里，如何被引用，如何被删除，都会影响系统可信度。没有资料治理，AI 只能在混乱材料上生成更流畅的混乱。
资料治理不一定要复杂。小团队可以先从命名、标签、来源、更新时间和责任人开始。只要这些最小规则稳定下来，后续再接入 AI 或自动化才有基础。
下一步如何迁移到你的场景
如果要把这些经验迁移到你的业务，第一步不是挑选某个案例照搬，而是回答三个问题：你最想减少哪类重复劳动，哪些资料已经存在，谁能负责复核结果。只要这三个问题清楚，就能设计第一版小闭环。
迁移时也要保留边界。客户资料、公开内容、合同承诺、价格政策和高风险专业事项，都需要更严格的确认流程。善意AI更倾向于先让系统变得可靠，再逐步扩大自动化范围。
交付后真正要看的指标
案例是否成功，不能只看页面是否好看、流程是否完整，也不能只看 AI 是否能生成一段看起来顺畅的文字。更重要的指标是：同类问题再次出现时，团队能否更快找到资料，能否更少重复解释背景，能否更稳定地输出可复核结果，能否把一次经验沉淀成下一次可以直接调用的资产。
这些指标看起来不如功能清单显眼，但它们直接决定系统有没有长期价值。一个好用的 AI 工作流，应该让负责人感觉手里的事情更清楚，而不是增加新的维护负担；应该让新人更容易理解已有做法，而不是只留下少数人知道如何操作的复杂配置；应该让复盘更容易发生，而不是让问题被漂亮界面掩盖。
为什么不先追求复杂系统
很多团队在第一次引入 AI 时，会自然地想把所有资料、所有流程和所有岗位一次性连起来。这种冲动可以理解，但风险很高。复杂系统在没有真实运行样本之前，很难判断哪些环节必要，哪些环节只是想象出来的需求。越早把结构做重，后续调整成本越高，也越容易让团队因为使用门槛太高而放弃。
善意AI更倾向于先把一个小流程跑顺，再决定是否扩展。小流程的优势是反馈快、责任清楚、失败成本低。它可以帮助团队看见真实阻力：资料是否缺失，字段是否难填，复核是否耗时，输出是否能被使用，成员是否愿意持续维护。只有这些问题被看见并处理，后续扩展才不是堆功能，而是沿着真实需求生长。
从案例到服务的转化路径
把案例迁移成你的方案时，通常会经历四步。第一步是场景访谈，把业务动作、资料来源、使用角色和失败后果说清楚。第二步是样本整理，用少量真实材料找出输入、判断和输出之间的关系。第三步是流程设计，把 AI 适合参与的部分和必须保留人工判断的部分分开。第四步是持续改进，用每次使用后的反馈修正模板、资料和边界。
这个路径适合服务、产品、案例介绍和内部知识整理等多种场景。它不会承诺一开始就解决所有问题，而是先建立一个能运行、能复核、能迭代的基础。只要基础稳定，后续无论是扩展成知识库、内容流程、客户沟通辅助，还是轻量内部工具，都会比从空白处直接追求大系统更稳。