MindOS 知识库操作指南

用于在 MindOS 风格的本地知识库中进行安全、一致、可审计的操作。

核心原则

• 以仓库当前状态为唯一依据。
• bootstrap 加载的目录树是一等语义资产。 目录名、文件名及其层级结构编码了用户存了什么、如何组织思维。在调用搜索之前，先从这个结构推断内容位置——它往往不需要任何工具调用就能告诉你答案。
• 写入前先读取。
• 优先最小化、精确化修改。
• 变更结果应易于审阅与追踪。

启动协议

在进行实质编辑前执行以下流程：

1. 加载根级规则。

• 优先调用 mindos_bootstrap。
• 若不可用，直接读取根 INSTRUCTION.md 与根 README.md。

2. 动态发现当前结构。

• 使用 mindos_list_files 与按需 mindos_search_notes。
• 不假设固定一级目录名。

3. 加载目标路径附近的局部规则。

• 若存在，读取就近 README.md / INSTRUCTION.md。
• 优先遵循局部约定，而非全局假设。

4. 再执行编辑。

若关键上下文缺失，按最佳努力继续，并明确写出假设。

动态结构规则

• 不硬编码”标准目录树”。
• 创建或重写内容前，先从相邻文件推断约定。
• 命名、标题结构、CSV 字段顺序、引用格式均优先复用现有模式。
• 新建文件优先跟随同级风格，不引入新标准。
• 除非用户明确要求，不在根目录下创建文件或子目录。 根目录仅保留顶层治理文件（README、INSTRUCTION、CONFIG）。新内容应放在语义最匹配的现有子目录下，从上下文中的目录树推断合适位置。
• 创建新文件或目录时，先根据现有结构确定最佳父目录。若没有明显匹配的目录，提出 1-2 个候选位置并询问用户后再创建。
• 文件增删/移动/重命名后，必须同步更新受影响的 README 文件。 README 是目录的索引与导航入口，任何改变目录内容的操作（创建、删除、移动、重命名文件或子目录）都应自动检查并更新对应目录及其父目录的 README，使其准确反映当前结构。这不需要用户提醒——属于结构一致性的基本纪律。

写前检查清单

在任何非 trivial 写入前，确认以下检查项：

1. 目标文件或路径已确认，且存在或应当创建。
2. 目标位置在合适的子目录下，而非根目录。 若不确定哪个目录最合适，先提出候选并询问用户。
3. 现有内容已读取，或已明确确认不存在。
4. 已考虑目标路径附近的治理文档。
5. 修改范围最小化，且与用户意图一致。
6. 路径变更带来的引用/反链影响已评估。

工具选型指南

发现

• mindos_bootstrap：加载启动上下文。
• mindos_list_files：查看文件树。
• mindos_search_notes：按关键词/范围/类型/日期定位文件。搜索时，第一次就应并行发起多个关键词搜索——同义词、缩写、中英文变体、更宽/更窄的表述。单一关键词很脆弱，一开始就撒网能避免多轮空搜。
• mindos_get_recent：查看近期活动。
• mindos_get_backlinks：重命名/移动/删除前评估影响。

读写

• mindos_read_file：读取文件内容。
• mindos_write_file：仅在确需整文件替换时使用。
• mindos_create_file：创建 .md/.csv 文件。
• mindos_delete_file：仅在用户明确意图下删除。
• mindos_rename_file、mindos_move_file：结构变更后补做引用检查。

精确编辑

• mindos_read_lines：定位精确行。
• mindos_insert_lines：按索引插入。
• mindos_update_lines：替换指定行区间。
• mindos_append_to_file：文件末尾追加。
• mindos_insert_after_heading：标题后插入。
• mindos_update_section：替换单个 Markdown 章节。

历史与表格

• mindos_get_history、mindos_get_file_at_version：追踪/回溯历史。
• mindos_append_csv：读表头校验后追加单行。

回退规则

• 若部分 mindos_* 工具不可用，使用可用等效工具，但保持同样安全纪律。
• 若 mindos_bootstrap 不可用，改为手动读取启动文件。
• 若缺少行级/章节级工具，用”读取 + 受限重写”方式模拟最小化修改。
• 若 mindos_search_notes 无结果，不要放弃。bootstrap 时加载的目录树已经在你的上下文中——目录名、文件名及其层级结构本身就有丰富的语义，往往足以推断内容可能在哪里。逐步升级：
  1. 先回顾上下文中已有的目录结构，根据命名、层级与主题相关性推断哪些目录和文件最可能相关。
  2. 直接读取最可能的候选文件确认内容。
  3. 若候选不明确，对特定子目录调用 mindos_list_files 获取 bootstrap 未覆盖的更细粒度结构。
  4. 同时尝试替代关键词（同义词、更宽/更窄范围、中英文变体）作为并行策略。

执行模式

记录或更新笔记

1. 搜索现有文档。
2. 读取目标文档与局部规则。
3. 执行最小化修改。
4. 路径变化时保持引用一致。

沉淀跨 Agent 讨论

1. 先请用户确认关键决策与结论。
2. 定位目标文档。
3. 按“问题、决策、理由、注意事项、后续动作”结构化。
4. 用最小侵入方式写回。

不要暗示你可访问其他 Agent 会话的私有历史。

对话复盘与自适应更新

1. 先让用户确认本次复盘目标与范围。
2. 抽取可复用资产：关键决策、理由、踩坑、未决问题、下一步动作。
3. 通过搜索并读取候选文档，将每类资产路由到最合适的现有文件。
4. 若命中文档则按章节/行级最小化更新；若无合适文档，再在相邻主题下创建边界清晰的新文件。
5. 维护引用与反链一致性，并补一条简短变更说明（改了什么、为什么改）。
6. 若路由置信度低，先给出 1-2 个候选目标并请用户确认后再写入。

执行或更新 SOP/工作流

1. 完整读取流程文档。
2. 分步执行并记录结果。
3. 若流程过时，仅修改受影响章节并说明原因。

CSV 操作

1. 读取表头。
2. 校验字段顺序、数量、类型。
3. 追加单行。

信息收集与外联执行

1. 定位权威联系人/名单来源。
2. 读取外联或执行流程文档。
3. 基于对象画像标签、领域和语气生成个性化输出。
4. 将结果与下一步动作回写，确保可追踪。

按个人与团队标准启动项目

1. 读取偏好与上下文文档，例如技术栈、代码风格、约束。
2. 读取启动或工程流程文档。
3. 产出与标准一致的初始化脚手架和配置。
4. 记录关键决策与初始化状态，便于后续接力。

按标准执行代码审查

1. 读取适用的审查与工程规范。
2. 按命名、错误处理、性能、安全、可维护性进行审查。
3. 输出可执行问题清单，并给出具体到文件的建议。
4. 保持与团队既有审查风格一致的语气和结构。

跨 Agent 接力连续性

1. 将共享知识库视为交接契约。
2. 接手前先读取任务状态、决策与待办。
3. 无需重复探索，直接延续执行并保持约定与理由。
4. 持续回写进度，确保后续会话可立即接手。

关系维护与跟进推进

1. 从用户提供的沟通纪要中抽取事实更新、意图与情绪信号。
2. 结构化更新对应的人脉或关系记录。
3. 生成下一步策略、待办与建议跟进时间。
4. 以可复用格式沉淀，保证后续会话可继续执行。

结构感知的多文件联动更新

一段非结构化输入（聊天记录、会议纪要、语音转文字、随手 braindump）往往包含分属多个文件的信息。MindOS 在启动时即获取完整目录树与文档间引用关系，因此能将输入拆解后一次性路由到各个目标文件——用户无需手动指定去向。

1. 通过 mindos_bootstrap 和 mindos_list_files 加载完整知识库结构与拓扑。
2. 将输入解析为独立语义单元（事实、决策、想法、行动项、关系更新、新概念等）。
3. 为每个单元搜索并读取候选目标文件，按主题、范围和已有结构匹配最佳归属。
4. 写入前，先向用户展示路由计划并请求确认。 用清晰的列表展示：每条信息将写入哪个文件、写在什么位置、为什么放在那里。确认后再执行。
5. 在每个目标文件的正确位置（章节、标题或行级）执行最小化编辑；仅当没有合理匹配时才新建文件。
6. 若某单元路由置信度低，先给出候选目标并请用户选择。
7. 所有写入完成后，汇总"改了什么、在哪里"，便于用户一眼审计。

这正是 MindOS 区别于"一次只能改一个文件"的工具的核心：结构先验意味着一次输入即触发跨知识库的协调更新，不遗漏、不错位。

知识冲突联动更新

当某个决策、偏好或事实发生变化（如"我们从 Redis 换成了 Memcached"），所有引用旧信息的文档都需一致更新。

1. 搜索整个知识库中引用旧信息的位置（使用多种搜索词，包括缩写和变体）。
2. 列出所有受影响文件及具体行/章节。
3. 向用户展示完整变更计划：哪些文件、改什么、为什么。
4. 用户确认后，逐一最小化更新。
5. 更新完成后验证不再有不一致的旧引用。

从经验提炼 SOP

当用户刚完成一项复杂任务，想把过程沉淀为可复用的工作流时，创建结构化、通用的 SOP 文档——不只是一次性记录。

1. 从用户描述中提取操作步骤、决策点、前置条件和常见坑。
2. 泛化处理：去掉一次性细节，保留可复用模式。
3. 在 Workflows/ 或类似目录下找合适位置，检查现有 SOP 模板或同级格式。
4. 创建 SOP，包含：前置条件、分步操作、排障/踩坑、相关文档引用。
5. 若适用，从相关索引文件链接到新 SOP。

周期性回顾与总结

当用户要求 weekly review、月度复盘或进度总结时：

1. 用 mindos_get_recent 和/或 mindos_get_history 找出相关时间窗口内变动的文件。
2. 读取变动文件理解发生了什么。
3. 按领域分类（项目、Profile、工作流等）。
4. 产出结构化总结：做了什么关键决策、活跃项目进展、待办事项、需关注的问题。
5. 询问用户是否要将总结回写为一条 review 记录。

基于上下文的问答

当用户问自己的偏好、项目状态、存储的知识等问题时：

1. 从目录树推断哪些文件可能包含答案。
2. 读取相关文件——不凭通用知识猜测。
3. 回答必须基于实际存储内容，并注明来源文件。
4. 若信息不完整或缺失，明确告知，不编造。

TODO 与任务列表管理

当用户要添加、完成或修改任务时：

1. 定位 TODO 文件或任务列表（搜索或从目录结构导航）。
2. 读取当前内容，理解现有格式（复选框、优先级、分类方式）。
3. 做最小化定向修改：标记完成、添加新项、更新状态。
4. 保留所有其他内容和格式不变。
5. 严格遵循现有格式约定——不引入新的任务格式。

交接文档合成

当用户需要为他人（新同事、协作者、上级）生成交接或简报文档时：

1. 跨知识库识别该主题的所有相关文件（项目文档、决策记录、状态、技术栈、待办）。
2. 逐一读取提取相关信息。
3. 合成为一份连贯的交接文档，包含：背景、关键决策与理由、当前状态、待办事项、延伸阅读（附源文件链接）。
4. 将交接文档放在对应项目目录下，不放根目录。

结构性重命名与移动

重命名或移动文件/目录时：

1. 用 mindos_get_backlinks 查找所有引用目标路径的文件。
2. 向用户报告影响范围：多少文件受影响、是哪些、引用了什么。
3. 确认后再执行。
4. 执行重命名/移动。
5. 更新所有受影响文件中的断裂引用。
6. 验证无遗留的失效链接。

目录变更后同步 README

任何影响目录结构的操作（创建、删除、移动、重命名文件或子目录）完成后：

1. 确定受影响的目录：文件原位置所在目录、新位置所在目录、以及它们的父目录。
2. 读取每个受影响目录的 README（若存在）。
3. 更新 README 中的文件列表/索引/导航，使其准确反映当前目录内容。
4. 若 README 中有文件描述或链接，同步更新路径和名称。
5. 若目录下没有 README 且同级目录普遍有 README，考虑为新目录创建一个。

此步骤是所有结构变更操作的自动收尾动作，不需要用户单独请求。

交互规则

• 当请求模糊或范围过大时（如"帮我整理一下"），先问清楚再动手。 基于知识库现状（近期变动、目录结构）提出具体选项，但不要在理解用户意图和范围之前就开始重组或重写。
• 展示搜索结果或选项时，优先简洁和相关性，最可能的匹配排前面。
• 从存储内容回答问题时，始终注明来源文件路径，便于用户验证。

安全规则

• 默认将根级 INSTRUCTION.md、根级 README.md 和其他目录下的 INSTRUCTION.md 治理文档视为高敏感，先确认再改。
• 修改高敏感治理文件前先确认。
• 执行高影响动作前先确认。
• 高影响动作包括批量删除、大规模重命名/移动、目录大重构、跨文件批量重写。
• 当操作涉及多个文件时，必须先向用户展示完整的变更计划。 列出每个目标文件、将做什么修改、为什么。等用户确认后再执行。多文件更新在执行前必须可见、可控。
• 不写入密钥、Token、密码。
• 不执行超出用户意图的删除或覆写。

持续评估迭代

对重要工作流执行快速迭代闭环：

1. 为当前任务类型定义 2-3 个代表性提示词。
2. 依据本 Skill 运行流程。
3. 按用户目标、局部约定与安全规则评估结果质量。
4. 找到能避免失败模式的最小指令改动。
5. 复跑并仅保留“提升稳定性且不过拟合”的改动。

质量闸门

在结束前确认：

1. 结果直接回应用户意图。
2. 新增或修改内容符合局部风格与结构。
3. 结构调整后引用/链接仍有效。
4. 未引入敏感信息。
5. 给用户的总结足够具体，便于快速审计。

风格规则

• 遵循仓库局部风格。
• 文本保持简洁、可执行。
• 保留标题、清单、表格、引用等有效结构。