mindos-zh

# 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 安装 ```bash 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/post-task-hooks.md)。 ## 偏好捕获 用户表达持久偏好时 → 读取 [references/preference-capture.md](./references/preference-capture.md)，按确认-写入流程操作。 类似"以后..."、"下次..."、"from now on..."的未来行为表达是偏好信号，不等于自动写入许可。除非用户明确说"保存/记录/写入这条偏好"，否则先确认是否保存。 ## SOP 编写 创建/重写工作流 SOP 时 → 读取 [references/sop-template.md](./references/sop-template.md)。 ## 收集箱 (Inbox) `Inbox/` 目录是知识库的快速捕获区，有自己的 `INSTRUCTION.md` 约束行为。 **何时使用收集箱：** - 用户说"先存着" / "放到收集箱" / "随便放哪"，没指定具体位置 - 内容明显不属于任何现有空间或目录 - 批量导入多个文件，需要逐个归类 **如何存到收集箱：** ```bash 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](./references/knowledge-health.md) 获取完整流程。 检查维度速览： - **矛盾/冲突**：同一主题的不同文件说法互相矛盾 - **断裂链接**：引用了不存在的文件 - **过期内容**：带有过期日期标记的文件，或超过 6 个月未更新的活跃主题 - **重复内容**：两个文件覆盖同一主题且没有互相引用 - **孤立文件**：零反向链接，难以被发现 - **结构问题**：文件放错目录、缺少 README、收集箱老化文件 ## 失败恢复 当用户点名的文件路径不存在时： 1. 明确说明请求的路径不存在。 2. 从文件名和用户原话推断恢复检索词，不要只搜索字面上的 `missing`。 3. 搜索或扫描可能的替代记录。 4. 如果有候选，列出最强的替代路径；如果没有，说明没有找到相关记录，并说明查了什么。 --- ## 错误处理（CLI） ```bash "command not found: mindos" → npm install -g @geminilight/mindos "Mind root not configured" → mindos onboard "401 Unauthorized" → 检查 AUTH_TOKEN：在服务器运行 mindos token "ECONNREFUSED" → 在服务器启动：mindos start ```