Files

2026-04-12 01:02:14 +08:00

8.7 KiB

Raw Blame History

name, description

name	description
profile-memory	渐进式用户/项目画像系统。在对话中被动检测用户个人特质（审美、技术偏好、做事风格等）和项目信息（定位、技术栈、产品方向等），对话结束前统一总结并经用户确认后记录。当用户提到"画像"、"profile"、"我的偏好"、"查看画像"、"项目信息"等时触发。

Profile Memory

渐进式画像系统，被动收集并持久化用户个人特质与项目信息。

存储结构

文件	位置	用途	注入上下文
user-profile.md	`~/.cursor/profile/`	个人画像精简版	是（每次会话）
user-profile-log.md	`~/.cursor/profile/`	个人画像详细日志	否
project-profile.md	`.cursor/profile/`	项目画像精简版	是（每次会话）
project-profile-log.md	`.cursor/profile/`	项目画像详细日志	否

精简版 Profile 是 Agent 每次会话的上下文输入，必须极度精简。详细 Log 保留完整上下文，供用户主动查阅和溯源。

锚点 ID 机制

每条画像记录在写入时生成一个锚点 ID，格式为 PF-YYYYMMDD-NN（如 PF-20260412-01），其中 NN 为当天的序号。

锚点 ID 在精简版和 Log 中保持一致：

精简版条目格式：- 条目内容 （HTML 注释，不影响可读性）
Log 条目的 H3 标题：### [PF-20260412-01] YYYY-MM-DD — 简短标题

这使得从精简版到 Log 的查找可以通过 Grep 精准定位，无需全文读取 Log。

逐级上溯机制

当 Agent 在使用精简版 Profile 作为上下文时，如果某条记录语义模糊 （如无法判断偏好的具体适用场景、与当前任务的关系不明确），执行以下查找：

1. 从精简版条目中提取锚点 ID（HTML 注释中的 PF-xxx）
2. 在对应的 Log 文件中 Grep 该 ID
   - 找到 → 用 Read 工具读取该 ID 所在行号 ±15 行范围（精准读取，不读全文）
   - Log 中包含原始上下文、来源对话等完整信息，通常足以消除歧义

上溯原则

按需触发：只有在精简版信息不足以支撑当前判断时才上溯
精准读取：通过 Grep 定位行号 + Read 局部读取，禁止全文读取 Log
最小化：一次上溯通常只涉及 1-2 条记录

硬上限

user-profile.md：不超过 50 行
project-profile.md：不超过 30 行
每条信息一行，- 开头，措辞客观中立

操作 A：被动检测 + 对话结束前确认

检测范围

在正常对话中被动检测以下信号（不主动询问）：

个人特质：

审美/设计偏好（"太花哨了"、"我喜欢 minimal"）
技术偏好（"以后都用 X"、"我不喜欢 class 写法"）
做事风格（"先讨论再动手"、"不要自作主张"）
沟通偏好（"给我简短的回答"、"多解释一下原理"）
产品理解/思维方式

项目信息：

项目定位和目标（"这个项目是做 X 的"）
技术栈与架构决策
设计约定和规范
产品方向和目标用户

检测原则

保守而非激进：宁可漏记也不误记
只记录持久性的偏好/特质，忽略一次性的临时需求
区分"个人"和"项目"两个维度

变更分类

检测到的新信息与已有条目的关系分为三类，处理方式不同：

类型	定义	示例	提示强度
新增	全新维度，无已有条目	首次提到审美偏好	常规
演进	已有条目的深化、细化或自然发展	"偏好 React" → "偏好 React + Next.js 全栈"	常规，展示前后对比
转向	与已有条目方向性矛盾或根本性变化	"偏好 React" → "想转 Vue"；项目方向从 B2C 转 B2B	加强提醒，展示前后对比

确认流程

1. 在对话过程中将检测到的信息在内部缓存，分类为"个人"或"项目"
2. 对每条缓存信息，与已有 Profile 比对，标记变更类型（新增/演进/转向）
3. 当用户的主线任务完成后，统一提出，格式如下：

   "本次对话中我注意到以下可记录的画像信息："

   **个人画像：**
   - [新增][分类] 条目内容
   - [演进][分类] 旧：xxx → 新：yyy
   - [转向][分类] 旧：xxx → 新：yyy ⚠️

   **项目画像：**
   - （同上格式）

   转向类条目额外标注 ⚠️ 并附一句说明：
   "⚠️ 以下条目与已有记录存在方向性变化，请特别关注："

   "是否记录？你可以全部确认、逐条修改或跳过。"

4. 用户确认后执行写入流程
5. 如本次对话未检测到任何画像信息，则不触发此流程

写入流程

1. 读取对应的精简 Profile 和详细 Log（不存在则用模板创建）
2. 为每条新记录生成锚点 ID：PF-YYYYMMDD-NN（检查 Log 中已有 ID 避免冲突）
3. 按变更类型执行：
   - 新增：在对应分类下追加条目，带锚点 ID 注释
   - 演进：替换对应旧条目为新措辞，沿用旧条目的锚点 ID（或生成新 ID，视变化程度而定）
   - 转向：替换对应旧条目为新措辞，生成新锚点 ID（用户已在确认流程中审核）
4. 写入精简 Profile（条目格式：`- 内容 <!-- PF-xxx -->`）
5. 追加详细 Log（标题格式：`### [PF-xxx] YYYY-MM-DD — 简短标题`），其中：
   - 新增条目：操作记为"新增"
   - 演进条目：操作记为"更新（旧值 → 新值）"
   - 转向条目：操作记为"转向（旧值 → 新值）"，便于溯源重大变化
6. 检查精简 Profile 是否超过硬上限，超过则提醒用户精简

操作 B：用户主动管理

当用户说"查看我的画像"、"profile"、"查看项目画像"、"我的偏好"等：

1. 读取对应的精简 Profile，展示给用户
2. 如用户要看详细版或溯源，读取对应 Log 展示
3. 用户可要求：
   - 删除某条记录（同步删除精简版条目，Log 中标记为已删除）
   - 修改某条记录的措辞
   - 合并/重组分类
   - 新增分类

操作 C：变更比对与冲突处理

比对逻辑

对每条新检测到的信息，在同分类下的已有条目中查找语义相近项：
1. 无相近条目 → 标记为"新增"
2. 有相近条目且方向一致（深化/细化/补充） → 标记为"演进"
3. 有相近条目且方向矛盾（替代/转向/否定） → 标记为"转向"

前后对比格式

演进和转向类条目在确认流程中必须展示前后对比：

- [演进][技术偏好] 旧：偏好 React → 新：偏好 React + Next.js 全栈开发
- [转向][产品方向] 旧：面向 C 端个人用户 → 新：转向 B 端企业客户 ⚠️

用户选择

对每条演进/转向条目，用户可以：

确认更新：用新条目替换旧条目
保留两者：旧条目不动，新条目作为补充追加（适用于不同细分维度）
放弃：不记录本条

数据文件模板

首次使用时，如对应文件不存在，按以下模板创建。

user-profile.md

# User Profile

## 审美与设计

## 技术偏好

## 做事风格

## 沟通偏好

## 产品理解

user-profile-log.md

# User Profile Log

详细记录每次画像更新的完整上下文，按时间正序追加。

## 记录

project-profile.md

# Project Profile

## 项目定位

## 技术栈与架构

## 设计约定

## 产品方向

project-profile-log.md

# Project Profile Log

详细记录每次项目画像更新的完整上下文，按时间正序追加。

## 记录

Log 条目格式

每次写入 Log 时，追加以下格式的条目：

### [PF-20260412-01] YYYY-MM-DD — 简短标题
- **分类**: 对应的精简 Profile 分类名
- **精简版**: 写入精简 Profile 的那一行内容
- **原始上下文**: 用户原话或对话中的关键语句
- **来源对话**: [对话简述](chat-uuid)
- **操作**: 新增 / 演进（旧值 → 新值）/ 转向（旧值 → 新值）/ 删除

分类扩展

预设的分类列表可以扩展。当检测到的信息不属于任何现有分类时：

1. 在确认流程中标注"建议新增分类: [分类名]"
2. 用户确认后在精简 Profile 中新增该分类的 H2 标题
3. 注意硬上限，新增分类会占用行数

与其他系统的协作

系统	关系	说明
`profile-recall` Rule	下游消费者	每次会话读取精简 Profile 并注入上下文
`epee-orchestrator`	注册	在 registry.md 中注册本 Skill

自迭代日志

本节记录使用本 Skill 过程中发现的必要检查项。

已知必要检查

（暂无）

8.7 KiB Raw Blame History Unescape Escape