mirror of
https://github.com/kuaifan/dootask.git
synced 2025-12-11 02:12:53 +00:00
81 lines
7.1 KiB
Plaintext
81 lines
7.1 KiB
Plaintext
---
|
||
description: Graphiti MCP 记忆使用规范（dootask 项目）
|
||
globs: []
|
||
alwaysApply: true
|
||
---
|
||
|
||
- **总体目标：把 Graphiti 当作本项目的「长期记忆」**
|
||
- 在本项目中，Graphiti MCP 负责持久化：用户偏好（Preferences）、工作流程/习惯（Procedures）、重要约束（Requirements）以及关键事实/关系（Facts）。
|
||
- 使用 Graphiti 的目标是：跨对话、跨任务保持一致的行为和决策，而不是简单地「多记一点东西」。
|
||
- 本项目的 Graphiti `group_id` **统一固定为** `dootask-main`，所有读写操作都应显式使用该 group（或依赖 MCP 服务器已配置好的默认 group）。
|
||
|
||
- **任务开始前：先查已有记忆**
|
||
- 在开始任何实质性工作（写代码、设计方案、做大改动）前，优先调用：
|
||
- `mcp_graphiti-mcp_search_nodes`：搜索与当前任务相关的偏好（Preference）、流程（Procedure）、需求（Requirement）等节点，**优先传入** `group_ids: ["dootask-main"]`。
|
||
- `mcp_graphiti-mcp_search_memory_facts`：搜索与当前任务相关的事实与实体间关系，**优先传入** `group_ids: ["dootask-main"]`。
|
||
- **搜索策略：**
|
||
- 查询语句中尽量包含：任务类型（如「Bug 修复」「重构」「新功能设计」）、涉及模块（如「任务管理」「评论」「WebSocket」「Docker」）、以及「dootask」关键词。
|
||
- 对于复杂任务，同时进行节点搜索和事实搜索，并在阅读结果后再决定具体实现方案。
|
||
- **使用已有知识：**
|
||
- 如果找到与当前任务高度相关的偏好/流程/约束，应优先遵循这些既有规则，而不是从零开始设定新习惯。
|
||
- 如发现多个偏好或流程相互冲突，应在回复中简要说明冲突，并基于上下文（时间、新旧程度、显式优先级）做出合理选择。
|
||
|
||
- **写入记忆：什么时候需要调用 `mcp_graphiti-mcp_add_memory`**
|
||
- **用户偏好（Preferences）：**当用户明确或隐含表达持续性的偏好时，应立即写入记忆。例如：
|
||
- 语言偏好：如「所有回答使用中文」「代码注释使用英文」。
|
||
- 输出格式偏好：如「需要分步骤说明」「统一使用 Markdown 标题结构」。
|
||
- 技术栈偏好：如「优先使用 Laravel 原生特性」「前端优先使用原项目已有的 Vue 组件」。
|
||
- **工作流程 / 习惯（Procedures）：**
|
||
- 当用户描述「以后都按这个流程来」或在项目层面形成稳定流程（例如「先写测试再实现」「所有接口加统一错误码说明」），应将该流程拆解为清晰步骤写入记忆。
|
||
- **约束 / 决策（Requirements）：**
|
||
- 与项目长期有效的决策或约束相关时（如「不再支持 PHP 7.x」「前端打包使用 Vite 而非 Webpack」），应作为需求/约束写入。
|
||
- **关键事实与关系（Facts）：**
|
||
- 例如：重要模块边界约定、服务之间的调用关系、与外部系统（如 AgoraIO、ZincSearch）的集成方式等。
|
||
- **写入内容的组织建议：**
|
||
- 默认使用 `source: "text"`，在 `episode_body` 中使用简洁、结构化的自然语言，包含：
|
||
- 背景（Context）——来自哪次任务/对话，解决了什么问题。
|
||
- 类型（Type）——偏好 / 流程 / 约束 / 事实。
|
||
- 范围（Scope）——例如「dootask 后端任务模块」「docker 部署」「桌面端 electron 打包」。
|
||
- 具体内容（Details）——条目化描述，方便后续检索和理解。
|
||
- 当需要存储明确结构化数据时，可以使用 `source: "json"`，确保 `episode_body` 是合法的 JSON 字符串。
|
||
- 所有写入操作默认应使用 `group_id: "dootask-main"`，只在有非常明确的跨项目需求时才考虑其他 group（目前 dootask 项目不建议这么做）。
|
||
|
||
- **更新与更正记忆**
|
||
- 如果用户**改变了偏好或流程**（例如从「总是返回详细解释」改为「只要简洁答案」）：
|
||
- 新建一条描述最新偏好/流程的 episode，并在其中说明这是对旧习惯的更新。
|
||
- 在后续决策时，优先采用最新一条、最明确的偏好/流程。
|
||
- 如果用户明确要求「忘记」或「不再使用」某些记忆：
|
||
- 通过适当的 Graphiti MCP 删除或更正接口（如 `mcp_graphiti-mcp_delete_episode` 或 `mcp_graphiti-mcp_delete_entity_edge`）进行处理，避免继续引用无效信息。
|
||
- 尽可能避免直接修改历史事实，而是通过新增 episode 记录「更正」或「废弃」说明，以保留决策轨迹。
|
||
|
||
- **在工作过程中如何使用图谱中的知识**
|
||
- **尊重偏好：**在代码实现、文档撰写、回答风格上，优先对齐已存储的用户偏好；如需临时偏离，应在回复中说明原因。
|
||
- **遵循流程：**如图谱中存在与当前任务高度相关的流程（Procedure），应按步骤执行，并在必要时说明是否对流程做了调整。
|
||
- **利用事实：**
|
||
- 在理解系统行为、模块边界、历史决策时优先查阅已存储的事实，减少对代码的「重新摸索」。
|
||
- 对于跨模块改动（如同时涉及 `app/Module`、`docker`、`electron` 等目录），尤其应查找是否已有相关决策或踩坑记录。
|
||
|
||
- **适用于 dootask 项目的具体约定**
|
||
- **领域术语统一：**
|
||
- 在 episode 中描述业务时，优先使用本项目已有的术语：项目、任务、子任务、评论、对话、WebSocket、看板、工时报表等。
|
||
- 如果是针对特定模块的约定（例如「ZincSearch 搜索索引字段约束」），在 Scope 中标明模块名，便于后续检索。
|
||
- **跨平台特性：**
|
||
- 对涉及 Web、Electron 客户端、Docker 部署等多端一致性的规则，应在同一 episode 中写明所有相关端，避免分散且难以关联。
|
||
- **重要变更要总结：**
|
||
- 对于大范围重构或关键特性上线（例如「任务模块权限系统重构」），在完成后为该任务写一条简洁的总结 episode，包含：
|
||
- 变更动机
|
||
- 核心设计决策
|
||
- 受影响的主要文件/模块
|
||
- 后续需要注意的坑或约束
|
||
|
||
- **不要写入 Graphiti 的内容（应只做临时使用）**
|
||
- 含有敏感信息的内容：例如访问密钥、数据库密码、用户隐私数据等，**不得**写入 Graphiti。
|
||
- 只与当前一次任务相关、不会在未来复用的短期信息：例如一次性调试日志、临时命令输出等，只需在当前对话中使用，不应持久化。
|
||
- 特别巨大的原始数据（如完整日志文件、长脚本全文）：应只存储精炼后的摘要与关键结论，而不是原始内容。
|
||
|
||
- **与本项目其他工具的配合**
|
||
- 在需要长期复用的信息上，优先使用 Graphiti MCP，而不是仅依赖对话上下文或一次性注释。
|
||
- 当对某个偏好/流程是否已存储存在疑问时，**先搜索再写入**：避免重复创建大量语义相近但难以区分的条目。
|
||
- 始终将 Graphiti 视为「事实来源之一」：如与代码现状冲突，应以代码实际为准，并在必要时通过新增 episode 更新事实。
|
||
|