mirror of
https://github.com/kuaifan/dootask.git
synced 2025-12-10 09:52:53 +00:00
no message
This commit is contained in:
kuaifan
parent
10925d3a47
commit
df382dafb4
@ -1,80 +0,0 @@
|
||||
---
|
||||
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 更新事实。
|
||||
|
||||
@ -1,88 +0,0 @@
|
||||
---
|
||||
description: dootask 开发流程与代码结构约定（controller + model + module + Vue2 + ./cmd）
|
||||
globs: []
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
- **整体目标**
|
||||
- 统一 dootask 项目的开发流程和代码结构约定，让后续协作、排障和重构更可预期。
|
||||
- 为 Cursor 中的 AI 助手提供清晰的「在本仓库应该怎么查代码、怎么改代码、怎么跑命令」的行为规范。
|
||||
|
||||
- **一、在 Cursor 中处理需求的通用流程**
|
||||
- 处理任何一个需求或问题时，AI 助手应优先按下面的步骤行动：
|
||||
1. **澄清问题与范围**：从用户问题中提炼出是「Bug 修复」「新功能」「重构」还是「排查/文档」类任务，大概会影响哪些模块（如任务、项目、对话、WebSocket、报表等）。
|
||||
2. **定位相关代码**：使用 `grep` / `codebase_search` / `read_file` 等工具，优先阅读路由、控制器、模型、模块，以及前端 `resources/assets/js` 下的相关页面或组件。
|
||||
3. **设计修改方案**：在代码层面给出清晰的改动思路（改哪些文件、增加/修改哪些类和方法），必要时在回复中简单说明权衡点。
|
||||
4. **实施改动并自检**：通过 `apply_patch` 修改代码，保持控制器+模型+模块结构清晰；需要运行命令时，统一通过 `./cmd ...`（如 `./cmd artisan ...`、`./cmd dev`、`./cmd build` 等），并使用 `read_lints` 等工具做基础检查。
|
||||
5. **考虑长期沉淀**：对于「以后会反复遇到」的流程、约束或经验，可以再参考 `001-graphiti-mcp.mdc` 中的约定，选择性地写入 Graphiti（`group_id: "dootask-main"`），但 Graphiti 不是每次任务的必选步骤。
|
||||
|
||||
- **二、后端代码结构约定：Controller + Model + Module**
|
||||
- **Controller（控制器，`app/Http/Controllers`）**
|
||||
- 负责：路由入口、参数接收与基础验证、调用对应的模型/模块、最终组装 API 响应。
|
||||
- 原则：控制器内尽量保持「薄」，只做请求编排，不堆积复杂业务逻辑。
|
||||
- 错误处理：业务异常优先使用 `App\Exceptions\ApiException` 抛出，由全局 Handler 统一转换成标准 JSON 响应。
|
||||
- **Model（模型，`app/Models`）**
|
||||
- 负责：数据表结构映射、关系定义（relations）、访问器/修改器、自定义查询 Scope 等「数据层」逻辑。
|
||||
- 原则：避免在模型方法中塞入大量跨业务的流程控制逻辑，复杂业务应下沉到模块中。
|
||||
- **Module（模块，`app/Module`）**
|
||||
- 负责：承载跨控制器、跨模型的业务逻辑，以及独立的功能子域。
|
||||
- 适用场景示例：
|
||||
- 外部服务集成：如 `AgoraIO/*`、`ZincSearch/*` 等第三方接口与搜索封装。
|
||||
- 通用工具与能力：如 `Lock.php`（分布式锁）、`RandomColor.php`、`TextExtractor.php`、`Image.php` 等。
|
||||
- 业务协作逻辑：项目/任务/对话等领域中，跨多个模型的复杂操作，可抽象为专门的模块方法。
|
||||
- 原则：
|
||||
- 新增较复杂的业务功能时，优先考虑创建/扩展 Module，而不是在 Controller 或 Model 中堆砌流程。
|
||||
- Module 尽量保持「单一职责」与「可复用」，命名上能直接反映其业务或能力作用。
|
||||
- 与长期约定的联动：
|
||||
- 对于关键 Module（如权限相关、搜索相关、外部系统对接），在设计上应尽量保持单一职责和清晰边界；如需记录长期约定，可参考 `001-graphiti-mcp.mdc` 使用 Graphiti 做补充说明。
|
||||
- **运行环境：Laravel + LaravelS（Swoole）**
|
||||
- 本项目通过 LaravelS 将 Laravel 运行在 Swoole 常驻进程中，与传统「每请求重启框架」的 PHP-FPM 模式不同。
|
||||
- 注意事项（AI 在修改后端代码时需特别留意）：
|
||||
- 避免在静态属性、单例、全局变量中存储请求级状态或可变数据，防止请求间数据串联和内存泄漏。
|
||||
- 不要假设构造函数、服务提供者或 `boot()` 方法会在每个请求重新执行；涉及配置、路由等的改动，通常需要通过 `./cmd php restart` 或容器重启后才能生效。
|
||||
- 编写长连接、定时任务、WebSocket 等长生命周期逻辑时，优先复用现有模式（如 `Services`、`Module` 中的实现），并避免使用会长时间阻塞协程/事件循环的操作。
|
||||
|
||||
- **三、数据库与迁移约定**
|
||||
- 表结构变更必须通过 Laravel migration 完成，禁止直接手工修改数据库结构。
|
||||
- 与迁移相关的约定：
|
||||
- 创建迁移文件和执行迁移时，优先使用容器内环境，通过 `./cmd artisan ...`（例如 `./cmd artisan make:migration ...`、`./cmd artisan migrate`）。
|
||||
- 涉及核心表（项目、任务、对话、用户、权限等）的 schema 变更，应在代码注释、迁移命名和提交信息中尽量说明字段含义与兼容性考虑；如属于长期架构决策，可再结合 `001-graphiti-mcp.mdc` 选择性写入 Graphiti。
|
||||
|
||||
- **四、前端开发约定：Vue2 + Vite**
|
||||
- 主前端代码位于 `resources/assets/js`，基于 Vue2 实现单页应用，结构大致包括：
|
||||
- `app.js`、`App.vue`：应用入口与根组件。
|
||||
- `components/`：通用组件与业务组件（如任务看板、文件预览、聊天等）。
|
||||
- `pages/`：页面级组件（登录、项目管理、任务视图、消息、报表等）。
|
||||
- `store/`：全局状态管理。
|
||||
- `routes.js`：路由配置。
|
||||
- 构建与开发命令：
|
||||
- 开发模式：使用 `./cmd dev` 或 `./cmd serve`，内部通过 Vite 启动开发服务器，并自动处理端口与调试模式。
|
||||
- 生产构建：使用 `./cmd build` 或 `./cmd prod`，内部使用 `npx vite build` 产出前端静态资源。
|
||||
- 与后端接口的协作：
|
||||
- 接口调用默认通过 Vuex 的 `call` action 封装：在组件/页面中使用 `this.$store.dispatch("call", {...})` 发起请求；如需新增接口，优先在 `store/actions.js` 中扩展逻辑，而不是在组件中直接调用 `axios/fetch`。
|
||||
- 错误提示、登录态失效、权限校验等跨页面行为，尽量复用已有的全局处理逻辑（如 `AIAssistant.vue`、消息通知组件、全局异常组件等）；如形成稳定的新约定，可按需沉淀到文档或 Graphiti。
|
||||
|
||||
- **五、Electron 相关约定**
|
||||
- 当前项目中 Electron 主要作为桌面入口壳，核心业务逻辑仍在 Web/Vue2 前端与 PHP/Laravel 后端。
|
||||
- Electron 的构建与开发：
|
||||
- 日常开发与调试优先使用 `./cmd electron ...`；仅在需要构建 App 端前端/安装包时，才使用 `./cmd appbuild`。
|
||||
- 原则：
|
||||
- 优先保证 Web 端行为正确，再通过 Electron 壳复用 Web 逻辑。
|
||||
- 若未来扩展 Electron 专有功能（如本地文件访问、系统托盘等），应在代码与文档中说明边界；如属长期约束，可再结合 `001-graphiti-mcp.mdc` 写入 Graphiti。
|
||||
|
||||
- **六、命令行与开发工具统一通过 `./cmd`**
|
||||
- 为了对齐 Docker 环境、避免本地环境差异，项目开发相关命令统一通过根目录的 `./cmd` 脚本执行，包括但不限于：
|
||||
- 启动/停止服务：`./cmd up`、`./cmd down`、`./cmd restart`、`./cmd reup`。
|
||||
- Laravel 工具：`./cmd artisan ...`（迁移、队列、任务、缓存等）。
|
||||
- Composer：`./cmd composer ...`。
|
||||
- PHP 命令：`./cmd php ...`。
|
||||
- 生成 API 文档：`./cmd doc`。
|
||||
- 规则：
|
||||
- 在项目文档、脚本示例和与 AI 的交流中，示例命令尽量使用 `./cmd ...` 形式，而不是直接调用 `php`、`composer`、`npm` 等，保持环境一致性。
|
||||
- 如需对 `./cmd` 脚本进行较大调整（例如新增开发流程或重构子命令），应在提交信息或说明文档中写清动机和影响范围；如这是长期流程变更，可参考 `001-graphiti-mcp.mdc` 选择性写入 Graphiti。
|
||||
|
||||
- **七、与 Graphiti 的关系（简要说明）**
|
||||
- 本规则文件的重点是「在 Cursor 中如何开发 dootask」；Graphiti 作为「长期记忆」工具，仅在需要跨会话、跨任务复用的信息时才使用。
|
||||
- 所有与 dootask 项目相关的 Graphiti 操作应使用 `group_id: "dootask-main"`，具体使用规范见 `001-graphiti-mcp.mdc`。
|
||||
- 当 AI 判断某个流程/约束/事实值得长期记忆时，可结合 `001-graphiti-mcp.mdc` 中的说明，主动调用对应 MCP 工具进行写入。
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@ -60,5 +60,4 @@ laravels.pid
|
||||
.DS_Store
|
||||
|
||||
# Documentation
|
||||
AGENTS.md
|
||||
README_LOCAL.md
|
||||
|
||||
122
AGENTS.md
Normal file
122
AGENTS.md
Normal file
@ -0,0 +1,122 @@
|
||||
# DooTask 项目说明
|
||||
|
||||
## 一、项目总览
|
||||
|
||||
- **项目定位**：DooTask 是一套开源的任务 / 项目管理系统，支持看板、任务、子任务、评论、对话、文件、报表等协作能力。
|
||||
- **后端技术栈**
|
||||
- 基于 Laravel（运行在 LaravelS / Swoole 常驻进程上），代码集中在 `app/`、`routes/`、`config/` 等目录。
|
||||
- 数据库通过 Laravel Eloquent 模型访问，所有表结构变更必须通过 migration 完成，禁止直接手工改库。
|
||||
- **前端技术栈**
|
||||
- 主 Web 前端基于 Vue2 + Vite，代码集中在 `resources/assets/js`。
|
||||
- 打包与开发通过根目录的 `./cmd` 脚本间接调用 Vite。
|
||||
- **桌面端**
|
||||
- 使用 Electron 作为桌面壳，核心业务逻辑仍在 Web 前端与 Laravel 后端中。
|
||||
|
||||
更多安装、升级、迁移说明见根目录 `README.md`。
|
||||
|
||||
## 二、开发与运行（命令约定）
|
||||
|
||||
- 开发 / 构建命令统一通过根目录的 `./cmd` 脚本执行，以保证与 Docker / 容器环境一致：
|
||||
- 启动服务：`./cmd up`
|
||||
- 停止服务：`./cmd down`
|
||||
- 重启服务：`./cmd reup` 或 `./cmd restart`
|
||||
- Laravel 工具：`./cmd artisan ...`
|
||||
- 前端开发：`./cmd dev`
|
||||
- 前端构建：`./cmd prod` 或 `./cmd build`
|
||||
- 其他工具：`./cmd composer ...`、`./cmd php ...`、`./cmd doc` 等
|
||||
- 在示例、脚本与回答中，优先使用 `./cmd ...` 形式，而不是直接调用 `php`、`composer`、`npm` 等命令。
|
||||
|
||||
## 三、代码结构（后端 + 前端）
|
||||
|
||||
- **Controller（`app/Http/Controllers`）**
|
||||
- 负责路由入口、参数接收与基础校验，编排调用模型 / 模块，并组装 API 响应。
|
||||
- 原则：控制器尽量保持「薄」，复杂业务逻辑不要堆积在控制器中。
|
||||
- 业务异常优先使用 `App\Exceptions\ApiException` 抛出，由全局 Handler 统一转换为标准 JSON 响应。
|
||||
|
||||
- **Model（`app/Models`）**
|
||||
- 负责数据表结构映射、关系（relations）、访问器 / 修改器、自定义查询 Scope 等「数据层」逻辑。
|
||||
- 避免在模型方法中塞入大量跨业务的流程控制逻辑，复杂业务应下沉到模块中。
|
||||
|
||||
- **Module（`app/Module`）**
|
||||
- 承载跨控制器 / 跨模型的业务逻辑与独立功能子域，例如：
|
||||
- 外部服务集成：`AgoraIO/*`、`ZincSearch/*` 等；
|
||||
- 通用工具：`Lock.php`、`TextExtractor.php`、`Image.php` 等；
|
||||
- 项目 / 任务 / 对话等领域里的复杂协作逻辑。
|
||||
- 原则：
|
||||
- 新增较复杂的业务功能时，优先考虑创建 / 扩展 Module，而不是在 Controller 或 Model 中堆砌流程。
|
||||
- Module 尽量保持单一职责与可复用，命名能直接反映其业务或能力作用。
|
||||
|
||||
- **运行环境注意事项（LaravelS / Swoole）**
|
||||
- 避免在静态属性、单例、全局变量中存储请求级状态或可变数据，防止请求间数据串联和内存泄漏。
|
||||
- 不要假设构造函数、服务提供者或 `boot()` 方法会在每个请求重新执行；涉及配置、路由等改动时，通常需要通过 `./cmd php restart` 或容器重启后才能生效。
|
||||
- 编写长连接、定时任务、WebSocket 等长生命周期逻辑时，优先复用现有模式，并避免长时间阻塞协程 / 事件循环的操作。
|
||||
|
||||
- **前端（`resources/assets/js`，Vue2 + Vite）**
|
||||
- 结构大致包括：
|
||||
- `app.js`、`App.vue`：应用入口与根组件；
|
||||
- `components/`：通用与业务组件（任务看板、文件预览、聊天等）；
|
||||
- `pages/`：页面级组件（登录、项目、任务视图、消息、报表等）；
|
||||
- `store/`：Vuex 全局状态管理；
|
||||
- `routes.js`：前端路由配置。
|
||||
- 构建与开发：
|
||||
- 开发模式：使用 `./cmd dev` 或类似子命令，内部通过 Vite 启动开发服务器。
|
||||
- 生产构建：使用 `./cmd prod` 或 `./cmd build`，内部通过 Vite 产出前端静态资源。
|
||||
- 与后端接口协作：
|
||||
- 接口调用默认通过已有的 Vuex 封装发起请求，新增接口时优先扩展集中封装，而不是在组件中直接散落 `axios/fetch`。
|
||||
|
||||
- **Electron**
|
||||
- Electron 主要作为桌面入口壳，核心业务逻辑仍在 Web/Vue2 前端与 PHP/Laravel 后端。
|
||||
- 日常开发与调试优先使用 `./cmd electron ...`；需要构建 App 端资源时使用 `./cmd appbuild`。
|
||||
- 原则：优先保证 Web 端行为正确，再通过 Electron 壳复用 Web 逻辑；桌面专有能力（本地文件、托盘等）需在代码中明确边界。
|
||||
|
||||
## 四、在本项目中使用 Graphiti 作为长期记忆
|
||||
|
||||
- **角色与 group_id**
|
||||
- Graphiti 作为本项目的「长期记忆层」，用于持久化：
|
||||
- 用户偏好（Preferences）、工作流程 / 习惯（Procedures）、重要约束（Requirements）、关键事实 / 关系（Facts）。
|
||||
- 目标是：跨对话、跨任务保持一致的行为和决策，而不是简单堆积信息。
|
||||
- 本项目统一使用的 `group_id`：`dootask-main`。
|
||||
|
||||
- **任务开始前（读）**
|
||||
- 在进行实质性工作（写代码、设计方案、做大改动）前，应先通过 Graphiti 查询已有记忆：
|
||||
- 使用节点搜索（如 `search_nodes`）在 `group_id = "dootask-main"` 下查找与当前任务相关的 Preference / Procedure / Requirement；
|
||||
- 使用事实搜索（如 `search_facts`）查找相关事实与实体关系；
|
||||
- 查询语句中可包含：任务类型（Bug 修复 / 重构 / 新功能等）、涉及模块（任务、项目、对话、WebSocket、报表等）以及关键字 `dootask`。
|
||||
- 发现与当前任务高度相关的偏好 / 流程 / 约束时，应优先遵守；如存在冲突，应在回答中说明并做合理选择。
|
||||
|
||||
- **什么时候写入 Graphiti（写）**
|
||||
- **偏好（Preferences）**：用户表达持续性偏好时（语言、输出格式、技术选型等），应尽快写入；
|
||||
- **流程 / 习惯（Procedures）**：形成「以后都按这个流程来」的稳定开发 / 发布 / 调试流程时，应记录为可复用步骤；
|
||||
- **约束 / 决策（Requirements）**：项目长期有效的决策，如不再支持某版本、某模块的架构约定等；
|
||||
- **事实 / 关系（Facts）**：模块边界约定、服务之间的调用关系、与外部系统（如 AgoraIO、ZincSearch）集成方式等。
|
||||
- 写入建议：
|
||||
- 默认使用 `source: "text"`，在 `episode_body` 中用简洁结构化自然语言描述背景、类型、范围、具体内容；
|
||||
- 需要结构化数据时可用 `source: "json"`，保证 `episode_body` 是合法 JSON 字符串；
|
||||
- 所有写入默认使用 `group_id: "dootask-main"`。
|
||||
|
||||
- **更新与更正**
|
||||
- 偏好 / 流程发生变化时，新增一条 episode 说明新约定，并标明这是对旧习惯的更新，后续以最新、最明确的为准；
|
||||
- 用户要求「忘记」某些记忆时，可通过删除或更正相关 episode / 关系的方式处理；
|
||||
- 尽量通过新增 episode 记录「更正 / 废弃说明」，而不是直接改写历史事实。
|
||||
|
||||
- **在工作中的使用方式**
|
||||
- 尊重已存偏好：编码风格、回答结构、工具选择等应对齐已知偏好；
|
||||
- 遵循已有流程：若图谱中已有与当前任务匹配的 Procedure，应尽量按步骤执行；
|
||||
- 利用事实：理解系统行为、模块边界、历史决策时优先查已存 Facts，减少重新摸索；
|
||||
- 如 Graphiti 与当前代码实际冲突，应以代码实际为准，并视情况新增 episode 更新事实。
|
||||
|
||||
- **不要写入 Graphiti 的内容**
|
||||
- 含敏感信息（密钥、密码、隐私数据等）；
|
||||
- 只与当前一次任务相关、未来不会复用的临时信息（调试日志、一次性命令输出等）；
|
||||
- 体量巨大的原始数据（完整日志、长脚本全文等），应只存摘要和关键结论。
|
||||
|
||||
- **最佳实践小结**
|
||||
- 先查再做：在提出方案或改动架构前，优先查阅 Graphiti 中已有的设计、偏好和约束；
|
||||
- 能复用就沉淀：只要发现某个偏好 / 流程 / 约束未来会反复用到，就尽快写入 Graphiti，而不是只放在当前对话里；
|
||||
- 保持项目内外一致：确保 Graphiti 中的记忆与实际代码长期保持一致，避免「记忆漂移」。
|
||||
|
||||
## 五、AI 回复风格与语言偏好
|
||||
|
||||
- 总体说明与重要总结（尤其是最终回答的 recap 部分），在不影响技术表达准确性的前提下，应优先使用简体中文进行回复。
|
||||
- 如用户在对话中明确要求使用其他语言（例如英文），则以用户的显式指令为最高优先级。
|
||||
- 当本次协作的改动已经较为完整且自然形成一个提交单元时，应在最终回答中附带一条或数条推荐的 Git 提交 message，方便用户直接复制使用。
|
||||
Loading…
x
Reference in New Issue
Block a user