shield_lock
JinDaGe
← Back to skills
extension
Category: AI Agent CapabilitiesNo API key required

mindos-zh

The Chinese operation guide for the MindOS knowledge base is only used for Agent tasks within the MindOS knowledge base (mindRoot path). It is triggered only when the target of the operation is a file under the MindOS knowledge base directory. Typical requests include 'update notes', 'search the knowledge base', 'organize files', 'execute SOP', 'review according to team standards', 'hand over the task to another Agent', 'synchronize decisions', 'append CSV', 'review this conversation', 'extract key experiences', 'adaptively update the review results to the corresponding document', 'route this information to the corresponding file', 'synchronize and update all relevant documents', etc. It does not trigger if: the target of the operation is a local code repository file (e.g., /code/xxx/wiki/*.md), the user provides an absolute path that is not under the MindOS mindRoot, or the task involves modifying project source code/documents.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

MindOS 技能

<!-- version: 3.3.1 — CLI 优先，MCP 可选 -->

CLI 命令

使用 mindos file <子命令> 完成所有知识库操作。加 --json 获取结构化输出。

| 操作 | 命令 | |------|------| | 列出文件 | mindos file list | | 读取文件 | mindos file read <路径> | | 写入/覆盖 | mindos file write <路径> --content "..." | | 创建新文件 | mindos file create <路径> --content "..." | | 追加内容 | mindos file append <路径> --content "..." | | 编辑段落 | mindos file edit-section <路径> -H "## 标题" --content "..." | | 标题后插入 | mindos file insert-heading <路径> -H "## 标题" --content "..." | | 追加 CSV 行 | mindos file append-csv <路径> --row "列1,列2,列3" | | 删除文件 | mindos file delete <路径> | | 重命名/移动 | mindos file rename <旧> <新> | | 搜索 | mindos search "关键词" | | 反向链接 | mindos file backlinks <路径> | | 最近文件 | mindos file recent --limit 10 | | Git 历史 | mindos file history <路径> | | 列出空间 | mindos space list | | 创建空间 | mindos space create "名称" |

MCP 用户： 如果只有 MCP 工具（mindos_*），直接使用——工具的 schema 已自带说明。有 CLI 时优先用 CLI（更省 token）。

CLI 安装

npm install -g @geminilight/mindos
# 远程模式：mindos config set url http://<IP>:<端口> && mindos config set authToken <token>

规则

  1. 先了解结构 — 列出知识库目录树，再搜索或写入。
  2. 默认只读。 只有用户明确要求保存、记录、整理、编辑时才写入。
  3. 规则优先级（从高到低）：用户当前指令 → .mindos/user-preferences.md → 最近目录 INSTRUCTION.md → 根 INSTRUCTION.md → 本技能默认。
  4. 多文件编辑先出方案。 展示完整变更列表，获批后再执行。
  5. 创建/删除/移动/重命名后 → 自动同步相关 README。
  6. 写入前先读取。 不基于假设写入。
  7. 自然收口。 回复只完成用户这一轮要求；完整查阅或写入后，不追加无必要的追问。
  8. 尊重源码边界。 本技能只处理 MindOS 知识库。用户要求修改应用/项目源码，但没有源码文件、代码工作区或代码工具时，询问具体仓库/文件/代码片段，不要搜索或写入知识库笔记来冒充改代码。对于裸代码请求，不要用 KB 的 list/search/read 工具去找源码文件。

回答收口

任务结束前按这个契约输出：

  • 查找 / 总结 / 引用： 先给结论，附稳定文件路径，并保持只读。用户点名具体本地文件路径时，最终回答必须包含这个原始路径。用户明确说不要修改或要求只读处理时，最后用用户语言短句说明没有修改（中文用「未做任何修改。」；英文用 "No changes were made."）。除非用户要求下一步或证据不足，不要用“要不要我保存/记录/更新？”结尾。
  • 保存 / 更新 / 追加： 只有写入工具成功后，才报告真实路径和操作。用稳定措辞：已保存到 <路径>、已更新 <路径>、已追加到 <路径>。再补一句极短摘要即可。
  • 上传内容写入： 用户要求把上传内容整理成笔记，且目标类型明确时，直接使用上传内容；最多做一次轻量结构/README 检查，然后写入笔记。不要停在目录列表。
  • 需要澄清： 只有当缺失信息会改变目标位置、范围、成本、安全或可逆性时才问。一次只问一个具体问题；必要时给 2-3 个可选方向。
  • 没有证据或工具失败： 明确说明没找到什么、哪个动作失败，以及下一步怎么恢复。缺少证据的查找任务不要主动提出保存、记录、创建或补充该想法，除非用户要求沉淀。不要空回复。
  • 语言保真： 保留用户语言和原笔记中的关键术语。中文笔记里的术语优先照原文说，不要随手翻译成英文；英文解释只在有帮助时放括号里。
  • 只读收口： 用户只要总结、会议上下文或下一步时，答完即止。不要额外追问"要不要我保存/记录/起草/写入/补充/调整/导出/继续执行？"。最后一句应是陈述句，不要用问题结尾。按 SOP 或 workflow 回答时，必须引用所依据的 SOP/workflow 路径。用户只问下一步时，不要反问是否执行。

检索策略

检索知识时走两条路径，然后先筛选再深读：

路径 1：目录结构扫描

先看知识库目录树和文件名。标题、目录名经常已经暴露答案。比如用户问“认证方案”，看到 Decisions/auth-jwt-vs-session.md 就是强候选，可以直接读。

  • Bootstrap 后先扫描与问题主题相关的路径和目录名。
  • 注意目录语义：Decisions/、Projects/、Workflows/、Resources/ 等目录代表不同内容类型。
  • 小知识库（少于 50 个文件）里，快速扫树往往比搜索更可靠。

路径 2：全文搜索

文件名看不出来时再搜索内容。

  • 用用户原话提炼关键词。用户说“那个很慢的接口”，可以搜“慢 接口”或“性能 API”。
  • 一条精准搜索通常比 4 条模糊搜索更好。只有当第一次结果少于 3 条，或主题明显有中英文/缩写变体时，才补第二条搜索。
  • 不要机械地每次都发 2-4 条搜索。 先判断，再精准检索。

筛选：先看 snippet 再深读

搜索结果有 snippet 和 BM25 分数。用它决定读什么：

  • 高分 + snippet 明确相关 → 读全文。
  • 中等分 + snippet 部分相关 → 没有更好候选时再读。
  • 低分或 snippet 跑题 → 跳过。不要把每个搜索结果都读一遍。
  • 目标是深读 1-3 个文件，而不是浅读 10 个文件。

禁止事项（血泪教训）

  • 禁止写入知识库根目录（除非明确要求）。根目录仅放治理文件，新内容放最合适的子目录。
  • 禁止假设目录名。 从实际目录树推断——知识库可能用中文名或扁平结构。
  • 禁止用整文件覆盖做小修改。 用 mindos file edit-section 或 mindos file insert-heading 做精准修改，整文件覆盖破坏 git diff。
  • 禁止未确认就修改 INSTRUCTION.md 或 README.md。 治理文档——高敏感度。
  • 禁止不看邻居就创建文件。 先读目标目录 1-2 个文件，了解命名和风格。
  • 禁止遗留孤立引用。 重命名/移动后检查反向链接并更新所有引用。
  • 禁止跳过多文件写入确认。 用户的心理模型可能和你不同。

MindOS 概念

  • 空间 (Space) — 按你的思维方式组织的知识分区。Agent 遵循相同结构。
  • 指令 (Instruction) — INSTRUCTION.md，所有连接的 Agent 都遵守的规则文件。
  • 技能 (Skill) — 教 Agent 如何读写和整理知识库。
  • 收集箱 (Inbox) — Inbox/ 目录是快速捕获区。内容暂时找不到归属时先放这里，之后再统一整理——用户手动或 AI 辅助批量归类。

笔记可以同时承载指令和技能——它们只是目录树中的 Markdown 文件。

决策树

用户请求
  │
  ├─ 查找 / 总结 / 引用？
  │   └─ [只读路径]：搜索 → 读取 → 带引用回答。不写入。
  │
  ├─ 保存 / 记录 / 更新 / 整理具体内容？
  │   ├─ 知道放哪 → [单文件编辑]
  │   ├─ 不知道放哪 → [收集箱路径] — 存到 Inbox/，之后再归类
  │   └─ 多文件或不确定 → [多文件路由] — 先出方案
  │
  ├─ 整理收集箱 / 归类收集内容？
  │   └─ [收集箱整理] — 读 Inbox/ 文件，提议目标位置，获批后移动
  │
  ├─ 结构变更（重命名 / 移动 / 删除 / 重组）？
  │   └─ [结构路径] — 变更前后检查反向链接
  │
  ├─ 流程性 / 可重复任务？
  │   └─ [SOP 路径] — 找到并执行现有 SOP，或创建新的
  │
  ├─ 复盘 / 提炼 / 交接？
  │   └─ [复盘路径]
  │
  ├─ 知识健康检查 / 检测冲突？
  │   └─ [健康检查路径] — 读取 references/knowledge-health.md
  │
  └─ 模糊？
      └─ 提问。基于知识库状态提出 2-3 个具体选项。

判断启发

保存意图边界：

  • "帮我记下来" / "保存" = 写入
  • "搜一下" / "总结" = 只读
  • "整理一下" → 先问：仅展示，还是写回知识库？
  • "整理这些东西" 但没有文件、当前文件、上传内容或目标范围 → 先问要整理什么。最多允许一次轻量目录/树检查来给出 Inbox/、某个 Space、当前文件等具体选项；澄清前不要移动、编辑或深读内容。
  • "告诉我下一步" → 读取 SOP 或 workflow，回答下一步和依据路径后停止。除非用户要求继续执行，不要追问是否现在执行、起草、保存、写入或继续。

文件位置不确定：

  • 5 秒内定不了 → 存到 Inbox/，告知用户，之后提议归类
  • "随便放哪" / "先放着" → 存到 Inbox/
  • 用户拖拽文件或粘贴非结构化内容但没指定位置 → Inbox/

稳定路由和文件名：

  • 如果明显存在相关文件，优先更新现有文件，不要新建重复笔记。
  • 如果用户明确要求记录一条事实，而明显已有相关文件承载它，就局部更新该文件或说明它已经记录在那里。不要追问是否另存一份重复的 Inbox 笔记。
  • 排错经验优先放 Debugging/；交接放 Handoffs/；会议记录放 Meetings/；归属不清的快速捕获放 Inbox/。
  • 明确要求交接上下文时，读取可用的本地交接说明后，在 Handoffs/ 下创建或更新一份简洁交接笔记。包含目标、相关文件、验证状态和剩余风险，并报告保存路径。
  • 新文件名从具体主题生成。除非目录已有其他约定，默认用小写 ASCII kebab-case。保留既有产品词和同目录命名习惯，例如 mindroot 与 mind-root 不要来回切换。
  • 文件名优先表达可复用主题，不追求花哨概括：Agent benchmark 的 MIND_ROOT 排错经验应使用 agent-benchmark-mindroot...；Skill 优化和 query replay 的快速捕获，文件名尽量同时保留 skill-optimization 和核心主题。
  • 用户说“当前文件”时，默认把 currentFile 作为目标，除非这会违反安全边界或局部治理规则。

范围蔓延：

  • 输入路由到 >5 个文件 → 暂停确认
  • "全部更新" + 跨多个主题 → 分批确认

引用规范： 引用知识库内容必须附带文件路径。

任务后钩子

写入任务（非简单读取）后扫描此表。最多 1 个提议；优先级最高的优先。先检查 .mindos/user-preferences.md 抑制项。

| 钩子 | 优先级 | 条件 | |------|--------|------| | 经验沉淀 | 高 | 调试、排错或多轮工作 | | 一致性同步 | 高 | 编辑的文件有反向链接 | | SOP 偏移 | 中 | 按 SOP 执行但实际偏离了步骤 | | 关联更新 | 中 | 更改了 CSV/TODO 状态且有关联文档 | | 结构分类 | 中 | 在临时位置或收集箱创建了文件 | | 模式提取 | 低 | 本次会话中 3+ 个结构相似的操作 |

触发时 → 读取 references/post-task-hooks.md。

偏好捕获

用户表达持久偏好时 → 读取 references/preference-capture.md，按确认-写入流程操作。

类似"以后..."、"下次..."、"from now on..."的未来行为表达是偏好信号，不等于自动写入许可。除非用户明确说"保存/记录/写入这条偏好"，否则先确认是否保存。

SOP 编写

创建/重写工作流 SOP 时 → 读取 references/sop-template.md。

收集箱 (Inbox)

Inbox/ 目录是知识库的快速捕获区，有自己的 INSTRUCTION.md 约束行为。

何时使用收集箱：

  • 用户说"先存着" / "放到收集箱" / "随便放哪"，没指定具体位置
  • 内容明显不属于任何现有空间或目录
  • 批量导入多个文件，需要逐个归类

如何存到收集箱：

mindos file create "Inbox/<文件名>.md" --content "..."

如何整理收集箱：

  1. 列出暂存文件：mindos file list Inbox/
  2. 读取每个文件，理解其内容
  3. 根据知识库结构，为每个文件提议最佳目标目录
  4. 向用户展示完整路由方案，获批后执行。明确使用"路由方案"等词，并列出每个源文件路径。
  5. 移动文件：mindos file rename "Inbox/<文件>" "<目标目录>/<文件>"
  6. 移动后检查目标目录的 README 是否需要更新

老化提醒： Inbox 中超过 7 天的文件视为"老化"。如果在 bootstrap 时发现老化文件，主动提醒： "收集箱有 N 个文件已经放了一周以上了，要我帮你整理一下吗？"

知识健康检查

用户要求检查知识库健康度、检测冲突、审计质量，或说"知识健康检查" / "检测冲突" / "check knowledge health" 时 → 读取 references/knowledge-health.md 获取完整流程。

检查维度速览：

  • 矛盾/冲突：同一主题的不同文件说法互相矛盾
  • 断裂链接：引用了不存在的文件
  • 过期内容：带有过期日期标记的文件，或超过 6 个月未更新的活跃主题
  • 重复内容：两个文件覆盖同一主题且没有互相引用
  • 孤立文件：零反向链接，难以被发现
  • 结构问题：文件放错目录、缺少 README、收集箱老化文件

失败恢复

当用户点名的文件路径不存在时：

  1. 明确说明请求的路径不存在。
  2. 从文件名和用户原话推断恢复检索词，不要只搜索字面上的 missing。
  3. 搜索或扫描可能的替代记录。
  4. 如果有候选，列出最强的替代路径；如果没有，说明没有找到相关记录，并说明查了什么。

错误处理（CLI）

"command not found: mindos"  → npm install -g @geminilight/mindos
"Mind root not configured"   → mindos onboard
"401 Unauthorized"           → 检查 AUTH_TOKEN：在服务器运行 mindos token
"ECONNREFUSED"               → 在服务器启动：mindos start