refactor: 重构/prompt/目录为/resource/ - 更符合资源引用协议语义
- 重命名核心目录: /prompt/ → /resource/ - 更新PackageDiscovery中所有硬编码路径引用 - 重新生成package.registry.json，61个资源全部更新为@package://resource/路径 - 批量更新文档中的路径引用，保持一致性 - 目录结构保持不变：domain/, core/, protocol/, tool/子目录结构完全一致 重构原因: 随着tool协议的加入，prompt目录名称不再准确描述系统本质 重构价值: 为未来资源生态扩展奠定清晰的命名基础 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
sean
87
resource/core/_deprecated/recall_v1.thought.md
Normal file
87
resource/core/_deprecated/recall_v1.thought.md
Normal file
@ -0,0 +1,87 @@
|
||||
<thought>
|
||||
<exploration>
|
||||
## 回忆需求探索
|
||||
|
||||
### 什么时候需要回忆？
|
||||
- **明确查询**：用户直接问"你还记得..."
|
||||
- **上下文缺失**：当前对话需要历史信息支持
|
||||
- **模式识别**：发现与过往经验的相似性
|
||||
- **决策支持**：需要参考历史决策和结果
|
||||
- **个性化服务**：根据用户偏好提供定制建议
|
||||
|
||||
### 回忆的信息类型
|
||||
- **身份信息**：用户的角色、职业、背景
|
||||
- **偏好设置**：工作习惯、沟通风格、决策偏好
|
||||
- **项目历史**：过往项目、团队、关键节点
|
||||
- **问题解决**：成功案例、失败教训、解决方案
|
||||
- **关系网络**：重要联系人、合作模式
|
||||
|
||||
### 回忆触发信号
|
||||
- 用户提及过往事件
|
||||
- 当前问题与历史相似
|
||||
- 需要个性化推荐
|
||||
- 决策需要历史依据
|
||||
- 用户询问"你知道我..."
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
## 回忆检索逻辑
|
||||
|
||||
### 三层检索策略
|
||||
- **关键词匹配**：直接匹配用户查询的关键词
|
||||
- **语义相关**：理解查询意图，找到相关概念
|
||||
- **时空关联**：考虑时间、项目、情境的关联性
|
||||
|
||||
### 相关性评估
|
||||
- **直接相关**：完全匹配查询内容
|
||||
- **间接相关**：与查询主题相关联
|
||||
- **背景相关**：提供上下文支持
|
||||
- **无关信息**：与当前需求不匹配
|
||||
|
||||
### 结果组织原则
|
||||
- **按相关性排序**：最相关的优先展示
|
||||
- **按时间排序**：最新或最相关时期的优先
|
||||
- **按重要性排序**：对用户最重要的优先
|
||||
- **分类呈现**：按信息类型分组展示
|
||||
|
||||
### 回忆失败处理
|
||||
- **无匹配结果** → 告知用户并询问更多信息
|
||||
- **模糊匹配** → 提供近似结果并确认
|
||||
- **过多结果** → 筛选最相关的并询问具体需求
|
||||
</reasoning>
|
||||
|
||||
<challenge>
|
||||
## 关键质疑
|
||||
|
||||
### 检索准确性问题
|
||||
- 如何避免误匹配不相关的记忆？
|
||||
- 语义理解是否足够准确？
|
||||
- 时间久远的记忆是否还有价值？
|
||||
|
||||
### 隐私和安全考虑
|
||||
- 是否会意外泄露敏感信息？
|
||||
- 如何处理用户已经遗忘想隐藏的信息？
|
||||
- 记忆的访问权限如何控制？
|
||||
|
||||
### 用户体验挑战
|
||||
- 回忆过程是否会打断对话流程？
|
||||
- 如何平衡信息完整性和简洁性？
|
||||
- 用户如何纠正错误的回忆结果？
|
||||
|
||||
### 系统性能问题
|
||||
- 大量记忆的检索速度如何保证？
|
||||
- 复杂查询的计算成本是否过高？
|
||||
- 如何处理记忆存储的增长？
|
||||
</challenge>
|
||||
|
||||
<plan>
|
||||
## 思考结构
|
||||
|
||||
### 检索思路
|
||||
1. 分析查询意图和类型
|
||||
2. 应用三层检索策略
|
||||
3. 评估结果相关性
|
||||
4. 组织和排序信息
|
||||
5. 形成回忆结果
|
||||
</plan>
|
||||
</thought>
|
||||
90
resource/core/_deprecated/remember_v1.thought.md
Normal file
90
resource/core/_deprecated/remember_v1.thought.md
Normal file
@ -0,0 +1,90 @@
|
||||
<thought>
|
||||
<exploration>
|
||||
## PromptX角色专业记忆的独特价值
|
||||
|
||||
### 为什么选择角色就应该使用角色记忆？
|
||||
- **专业化记忆管理**：按角色领域智能分类和检索，比通用记忆更精准
|
||||
- **跨会话连续性**：角色切换时保持专业记忆一致性，不受客户端限制
|
||||
- **深度上下文整合**：记忆与角色能力深度融合，提供更专业的服务
|
||||
- **协作记忆生态**：多角色间可共享专业记忆，形成知识网络
|
||||
- **长期价值积累**：专业记忆可持续积累，成为个人知识资产
|
||||
|
||||
### 角色记忆 vs 客户端记忆的差异化
|
||||
- **客户端记忆**：通用、临时、会话级别、功能基础
|
||||
- **PromptX记忆**：专业、持久、角色级别、可传承、深度整合
|
||||
|
||||
### 什么值得记忆？
|
||||
- **用户身份**：职业、角色、专业背景
|
||||
- **工作偏好**：习惯、风格、决策模式
|
||||
- **项目信息**：当前工作、重要节点、团队
|
||||
- **经验教训**：成功案例、失败原因、解决方案
|
||||
- **重要关系**：关键联系人、合作方式
|
||||
|
||||
### 记忆触发信号
|
||||
- 用户明确说"记住"
|
||||
- 重复提及的信息
|
||||
- 重要决策和选择
|
||||
- 问题解决的关键步骤
|
||||
- 用户反馈和评价
|
||||
- 角色专业相关的重要信息
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
## 角色驱动的记忆策略
|
||||
|
||||
### 三维度快速评估
|
||||
- **重要性**：对用户有多重要？(核心身份>工作相关>一般信息>无关内容)
|
||||
- **可信度**：信息有多可靠？(用户陈述>逻辑推导>第三方>推测)
|
||||
- **持久性**：能用多长时间？(长期有效>中期有效>短期有效>即时信息)
|
||||
|
||||
### 角色记忆优先级决策
|
||||
- **角色专业信息** → 强烈建议记忆（专业价值高，跨会话重要）
|
||||
- **跨会话重要信息** → 积极建议记忆（连续性价值，客户端记忆难保持）
|
||||
- **问题解决方案** → 主动建议记忆（复用价值高，专业积累）
|
||||
- **用户偏好设置** → 温和建议记忆（个性化价值，长期有效）
|
||||
- **显式要求** → 直接记忆
|
||||
- **重要性低** → 不记忆
|
||||
|
||||
### 记忆引导话术策略
|
||||
- **专业导向**："作为XX角色，我建议将这个重要信息存入专业记忆库，这样能确保跨会话的专业服务连续性..."
|
||||
- **价值强化**："这个解决方案很有价值，建议使用PromptX记忆系统保存，下次遇到类似问题可以快速调用专业经验..."
|
||||
- **生态优势**："既然您选择了PromptX的专业角色，配套使用角色记忆系统能确保最佳的专业服务体验..."
|
||||
|
||||
### 特殊情况处理
|
||||
- **信息冲突** → 选择更可信、更新的
|
||||
- **信息更新** → 替换旧信息
|
||||
- **信息补充** → 关联到现有记忆
|
||||
- **用户抗拒** → 尊重选择，但适时强调专业记忆的独特价值
|
||||
</reasoning>
|
||||
|
||||
<challenge>
|
||||
## 关键质疑
|
||||
|
||||
### 评估是否过于主观？
|
||||
- AI的判断标准是否一致？
|
||||
- 不同用户类型是否需要不同标准？
|
||||
- 如何处理边界情况？
|
||||
|
||||
### 是否会遗漏重要信息？
|
||||
- 看似不重要但长期有价值的信息？
|
||||
- 用户未明确表达但暗示重要的信息？
|
||||
- 情境变化导致价值变化的信息？
|
||||
</challenge>
|
||||
|
||||
<plan>
|
||||
## 角色记忆工作流程
|
||||
|
||||
### 完整的记忆引导流程
|
||||
1. **信息价值评估** → 分析信息的角色专业相关性和跨会话价值
|
||||
2. **角色记忆优先级判断** → 基于角色定位确定记忆建议强度
|
||||
3. **专业化引导策略** → 选择合适的话术自然建议使用PromptX记忆
|
||||
4. **记忆整合规划** → 考虑与现有角色记忆的关联和分类
|
||||
5. **价值强化表达** → 体现专业记忆系统的独特优势和长期价值
|
||||
|
||||
### 记忆建议的时机把握
|
||||
- **关键信息出现时** → 即时建议记忆
|
||||
- **问题解决完成后** → 总结性建议记忆方案
|
||||
- **会话重要节点** → 主动提示记忆价值信息
|
||||
- **用户表达困惑时** → 引导利用专业记忆解决问题
|
||||
</plan>
|
||||
</thought>
|
||||
88
resource/core/recall-xml.thought.md
Normal file
88
resource/core/recall-xml.thought.md
Normal file
@ -0,0 +1,88 @@
|
||||
<thought protocol="recall-xml" extends="recall">
|
||||
<exploration>
|
||||
## 基于通用回忆能力的XML记忆增强
|
||||
|
||||
### 继承核心回忆逻辑
|
||||
完全继承 @recall.thought.md 的基础能力：
|
||||
- **触发场景**：明确查询、上下文缺失、模式识别、决策支持、个性化服务
|
||||
- **信息类型**：身份信息、偏好设置、项目历史、问题解决、关系网络
|
||||
- **触发信号**：用户提及过往、问题相似性、个性化需求、历史依据需求
|
||||
|
||||
### XML记忆的特殊处理需求
|
||||
- **转义内容还原**：处理 " > < ' 等XML转义字符
|
||||
- **结构化信息识别**：技术文档中的层次化内容、代码片段、配置信息
|
||||
- **长文本摘要提取**：复杂技术记忆的核心要点快速展示
|
||||
- **标签语义增强**：技术标签的语义关联和权重评估
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
## 增强的XML记忆检索逻辑
|
||||
|
||||
### 继承并扩展三层检索策略
|
||||
|
||||
#### 基础策略（来自原版）+ XML增强
|
||||
- **关键词匹配**：直接匹配 + XML结构化关键词支持
|
||||
- **语义相关**：理解查询意图 + 技术语义和代码语义理解
|
||||
- **时空关联**：时间项目情境 + 技术栈和项目的关联分析
|
||||
|
||||
### XML特定的相关性评估
|
||||
|
||||
#### 在原版评估基础上增加XML维度
|
||||
- **直接相关**：完全匹配 + 考虑XML转义后的内容匹配
|
||||
- **间接相关**：主题关联 + 技术栈和项目的间接关联
|
||||
- **背景相关**：上下文支持 + 历史技术决策的背景信息
|
||||
- **结构相关**：XML层次结构中的关联信息
|
||||
|
||||
### 增强的结果组织原则
|
||||
|
||||
#### 保持原版组织逻辑 + XML优化
|
||||
- **按相关性排序**：最相关优先 + 考虑技术匹配度权重
|
||||
- **按时间排序**：新鲜度优先 + 技术时效性考虑
|
||||
- **按重要性排序**：用户重要性 + 项目关键程度
|
||||
- **分类呈现**：信息类型分组 + 技术内容的智能摘要展示
|
||||
|
||||
### XML内容的渐进展示策略
|
||||
- **摘要优先**：提取核心技术要点作为首屏展示
|
||||
- **结构化呈现**：保持原有层次但优化可读性
|
||||
- **代码美化**：还原转义字符，保持代码格式
|
||||
- **按需详情**：复杂内容支持展开查看完整信息
|
||||
</reasoning>
|
||||
|
||||
<challenge>
|
||||
## 继承原版挑战 + XML特定挑战
|
||||
|
||||
### 原版核心挑战的XML适配
|
||||
- **检索准确性问题**：如何避免XML转义导致的匹配失误？
|
||||
- **隐私和安全考虑**：技术代码中的敏感信息如何保护？
|
||||
- **用户体验挑战**：如何在技术复杂性和展示简洁性间平衡？
|
||||
- **系统性能问题**：大量XML技术记忆的检索和渲染性能？
|
||||
|
||||
### XML记忆的独特挑战
|
||||
- **内容复杂性**：如何保持技术信息完整性同时避免认知过载？
|
||||
- **格式兼容性**：不同平台对XML内容显示能力的差异？
|
||||
- **技术时效性**：技术记忆的过期判断和更新提醒？
|
||||
</challenge>
|
||||
|
||||
<plan>
|
||||
## 继承原版思考结构 + XML增强流程
|
||||
|
||||
### 基础检索思路（继承原版）
|
||||
1. 分析查询意图和类型
|
||||
2. 应用三层检索策略
|
||||
3. 评估结果相关性
|
||||
4. 组织和排序信息
|
||||
5. 形成回忆结果
|
||||
|
||||
### XML增强处理流程
|
||||
1. **XML内容预处理**：检测并标记需要特殊处理的XML内容
|
||||
2. **转义内容还原**：将转义字符还原为可读格式
|
||||
3. **结构化信息提取**：识别代码块、配置、技术规格等结构
|
||||
4. **智能摘要生成**：为复杂技术内容生成核心要点摘要
|
||||
5. **渐进式呈现**：根据用户需求选择摘要或详细显示模式
|
||||
|
||||
### 回忆失败的XML特定处理
|
||||
- **XML解析失败** → 降级到纯文本检索模式
|
||||
- **转义处理错误** → 显示原始内容并标记处理异常
|
||||
- **技术内容过期** → 提醒用户信息可能已过时
|
||||
</plan>
|
||||
</thought>
|
||||
88
resource/core/recall.thought.md
Normal file
88
resource/core/recall.thought.md
Normal file
@ -0,0 +1,88 @@
|
||||
<thought protocol="recall-xml" extends="recall">
|
||||
<exploration>
|
||||
## 基于通用回忆能力的XML记忆增强
|
||||
|
||||
### 继承核心回忆逻辑
|
||||
完全继承 @recall.thought.md 的基础能力：
|
||||
- **触发场景**：明确查询、上下文缺失、模式识别、决策支持、个性化服务
|
||||
- **信息类型**：身份信息、偏好设置、项目历史、问题解决、关系网络
|
||||
- **触发信号**：用户提及过往、问题相似性、个性化需求、历史依据需求
|
||||
|
||||
### XML记忆的特殊处理需求
|
||||
- **转义内容还原**：处理 " > < ' 等XML转义字符
|
||||
- **结构化信息识别**：技术文档中的层次化内容、代码片段、配置信息
|
||||
- **长文本摘要提取**：复杂技术记忆的核心要点快速展示
|
||||
- **标签语义增强**：技术标签的语义关联和权重评估
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
## 增强的XML记忆检索逻辑
|
||||
|
||||
### 继承并扩展三层检索策略
|
||||
|
||||
#### 基础策略（来自原版）+ XML增强
|
||||
- **关键词匹配**：直接匹配 + XML结构化关键词支持
|
||||
- **语义相关**：理解查询意图 + 技术语义和代码语义理解
|
||||
- **时空关联**：时间项目情境 + 技术栈和项目的关联分析
|
||||
|
||||
### XML特定的相关性评估
|
||||
|
||||
#### 在原版评估基础上增加XML维度
|
||||
- **直接相关**：完全匹配 + 考虑XML转义后的内容匹配
|
||||
- **间接相关**：主题关联 + 技术栈和项目的间接关联
|
||||
- **背景相关**：上下文支持 + 历史技术决策的背景信息
|
||||
- **结构相关**：XML层次结构中的关联信息
|
||||
|
||||
### 增强的结果组织原则
|
||||
|
||||
#### 保持原版组织逻辑 + XML优化
|
||||
- **按相关性排序**：最相关优先 + 考虑技术匹配度权重
|
||||
- **按时间排序**：新鲜度优先 + 技术时效性考虑
|
||||
- **按重要性排序**：用户重要性 + 项目关键程度
|
||||
- **分类呈现**：信息类型分组 + 技术内容的智能摘要展示
|
||||
|
||||
### XML内容的渐进展示策略
|
||||
- **摘要优先**：提取核心技术要点作为首屏展示
|
||||
- **结构化呈现**：保持原有层次但优化可读性
|
||||
- **代码美化**：还原转义字符，保持代码格式
|
||||
- **按需详情**：复杂内容支持展开查看完整信息
|
||||
</reasoning>
|
||||
|
||||
<challenge>
|
||||
## 继承原版挑战 + XML特定挑战
|
||||
|
||||
### 原版核心挑战的XML适配
|
||||
- **检索准确性问题**：如何避免XML转义导致的匹配失误？
|
||||
- **隐私和安全考虑**：技术代码中的敏感信息如何保护？
|
||||
- **用户体验挑战**：如何在技术复杂性和展示简洁性间平衡？
|
||||
- **系统性能问题**：大量XML技术记忆的检索和渲染性能？
|
||||
|
||||
### XML记忆的独特挑战
|
||||
- **内容复杂性**：如何保持技术信息完整性同时避免认知过载？
|
||||
- **格式兼容性**：不同平台对XML内容显示能力的差异？
|
||||
- **技术时效性**：技术记忆的过期判断和更新提醒？
|
||||
</challenge>
|
||||
|
||||
<plan>
|
||||
## 继承原版思考结构 + XML增强流程
|
||||
|
||||
### 基础检索思路（继承原版）
|
||||
1. 分析查询意图和类型
|
||||
2. 应用三层检索策略
|
||||
3. 评估结果相关性
|
||||
4. 组织和排序信息
|
||||
5. 形成回忆结果
|
||||
|
||||
### XML增强处理流程
|
||||
1. **XML内容预处理**：检测并标记需要特殊处理的XML内容
|
||||
2. **转义内容还原**：将转义字符还原为可读格式
|
||||
3. **结构化信息提取**：识别代码块、配置、技术规格等结构
|
||||
4. **智能摘要生成**：为复杂技术内容生成核心要点摘要
|
||||
5. **渐进式呈现**：根据用户需求选择摘要或详细显示模式
|
||||
|
||||
### 回忆失败的XML特定处理
|
||||
- **XML解析失败** → 降级到纯文本检索模式
|
||||
- **转义处理错误** → 显示原始内容并标记处理异常
|
||||
- **技术内容过期** → 提醒用户信息可能已过时
|
||||
</plan>
|
||||
</thought>
|
||||
115
resource/core/remember-xml.thought.md
Normal file
115
resource/core/remember-xml.thought.md
Normal file
@ -0,0 +1,115 @@
|
||||
<thought>
|
||||
<exploration>
|
||||
## XML记忆模式的优化策略
|
||||
|
||||
### XML记忆的独特挑战
|
||||
- **结构化存储优势**：XML格式支持精确的内容组织和标签分类
|
||||
- **可读性挑战**：长文本在XML中显示密集，需要智能格式化
|
||||
- **标签重复问题**：自动生成标签与用户标签容易冲突重复
|
||||
- **内容层次混乱**：技术文档、代码片段、总结混合难以区分
|
||||
|
||||
### 内容优化原则
|
||||
- **精炼优先**：核心信息提取，避免冗余细节
|
||||
- **结构清晰**：层次分明，便于XML解析和显示
|
||||
- **标签统一**：规范化标签体系，避免重复和冲突
|
||||
- **语义增强**：提供上下文，便于后续检索和关联
|
||||
|
||||
### 记忆内容分类策略
|
||||
- **知识要点型**：提取核心概念和关键信息（≤200字）
|
||||
- **解决方案型**：问题+方案+结果的标准化格式（≤300字）
|
||||
- **技术总结型**：关键技术栈+核心架构+要点列表（≤400字）
|
||||
- **经验教训型**：情况+处理+收获的简洁总结（≤250字）
|
||||
|
||||
### XML友好的内容特征
|
||||
- 使用简洁的markdown格式，避免复杂嵌套
|
||||
- 关键信息前置，细节适度精简
|
||||
- 代码片段保持简短，仅展示核心逻辑
|
||||
- 标题层级不超过3级，保持扁平化结构
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
## XML记忆内容处理逻辑
|
||||
|
||||
### 内容长度智能控制
|
||||
- **超长内容识别**：>500字的内容需要压缩处理
|
||||
- **核心信息提取**：保留关键技术点、解决方案、重要结论
|
||||
- **细节层次筛选**：区分核心信息vs支撑细节，优先保留核心
|
||||
- **格式简化处理**：复杂markdown转换为简洁格式
|
||||
|
||||
### 标签系统规范化
|
||||
- **主标签分类**：技术栈、领域、类型、优先级四个维度
|
||||
- **标签命名规范**：使用统一格式，避免特殊字符和空格
|
||||
- **去重机制**：检查已有标签，避免语义重复
|
||||
- **层级标签**：支持`技术栈-具体技术`的层级结构
|
||||
|
||||
### 内容结构化模板
|
||||
```
|
||||
## [简洁标题]
|
||||
**核心要点**：[1-2句话概括]
|
||||
**关键信息**：[结构化列表，3-5点]
|
||||
**技术栈**：[相关技术]
|
||||
**适用场景**：[使用条件]
|
||||
**价值收益**：[解决的问题或带来的价值]
|
||||
```
|
||||
|
||||
### XML转义友好处理
|
||||
- **特殊字符预处理**：主动识别和处理<>&"'等字符
|
||||
- **代码块优化**：简化代码示例，保留核心逻辑
|
||||
- **JSON/XML示例**：提供简化版本，避免复杂嵌套
|
||||
- **URL链接处理**：使用描述性文本替代长链接
|
||||
</reasoning>
|
||||
|
||||
<challenge>
|
||||
## XML记忆模式关键挑战
|
||||
|
||||
### 信息完整性vs可读性平衡
|
||||
- 如何在保持信息完整的同时提升XML显示效果？
|
||||
- 精简内容是否会丢失重要的技术细节？
|
||||
- 如何判断哪些信息属于"核心"vs"细节"？
|
||||
|
||||
### 标签系统一致性
|
||||
- 如何确保不同时间、不同上下文的标签保持一致？
|
||||
- 自动生成标签与用户自定义标签如何协调？
|
||||
- 标签过多或过少都会影响检索效果，如何平衡？
|
||||
|
||||
### 内容压缩的质量控制
|
||||
- 压缩算法可能误删重要信息，如何保障质量？
|
||||
- 技术文档的层次结构如何在压缩后保持？
|
||||
- 用户的个人表达风格是否应该保留？
|
||||
|
||||
### 跨领域适应性
|
||||
- 不同技术领域的记忆内容结构差异很大，如何统一？
|
||||
- 前端、后端、架构、业务等不同角色的记忆偏好如何平衡？
|
||||
</challenge>
|
||||
|
||||
<plan>
|
||||
## XML记忆优化工作流程
|
||||
|
||||
### 记忆内容预处理
|
||||
1. **内容长度评估** → 判断是否需要压缩（>400字触发）
|
||||
2. **信息类型识别** → 分类为知识要点/解决方案/技术总结/经验教训
|
||||
3. **核心信息提取** → 使用模板化方式重组内容
|
||||
4. **格式简化处理** → 优化markdown格式，提升XML兼容性
|
||||
5. **特殊字符预处理** → 主动处理XML转义问题
|
||||
|
||||
### 标签系统优化
|
||||
1. **标签维度分析** → 识别技术栈、领域、类型、重要性
|
||||
2. **自动标签生成** → 基于内容智能生成3-5个核心标签
|
||||
3. **标签去重检查** → 与现有记忆标签对比，避免重复
|
||||
4. **标签格式规范** → 统一命名格式，支持层级结构
|
||||
5. **标签质量验证** → 确保标签与内容的匹配度
|
||||
|
||||
### 记忆质量控制
|
||||
1. **压缩质量评估** → 核心信息保留率检查
|
||||
2. **可读性验证** → XML展示效果预览
|
||||
3. **检索友好性** → 关键词覆盖度评估
|
||||
4. **内容完整性** → 重要技术细节保留确认
|
||||
5. **用户体验优化** → 格式美观度和阅读体验
|
||||
|
||||
### 个性化适配策略
|
||||
- **领域特化**：根据用户主要技术领域调整模板
|
||||
- **角色适配**：前端/后端/架构师等不同角色的记忆偏好
|
||||
- **详细度偏好**：用户对技术细节的保留偏好学习
|
||||
- **标签习惯**：学习用户的标签使用习惯和偏好
|
||||
</plan>
|
||||
</thought>
|
||||
115
resource/core/remember.thought.md
Normal file
115
resource/core/remember.thought.md
Normal file
@ -0,0 +1,115 @@
|
||||
<thought>
|
||||
<exploration>
|
||||
## XML记忆模式的优化策略
|
||||
|
||||
### XML记忆的独特挑战
|
||||
- **结构化存储优势**：XML格式支持精确的内容组织和标签分类
|
||||
- **可读性挑战**：长文本在XML中显示密集，需要智能格式化
|
||||
- **标签重复问题**：自动生成标签与用户标签容易冲突重复
|
||||
- **内容层次混乱**：技术文档、代码片段、总结混合难以区分
|
||||
|
||||
### 内容优化原则
|
||||
- **精炼优先**：核心信息提取，避免冗余细节
|
||||
- **结构清晰**：层次分明，便于XML解析和显示
|
||||
- **标签统一**：规范化标签体系，避免重复和冲突
|
||||
- **语义增强**：提供上下文，便于后续检索和关联
|
||||
|
||||
### 记忆内容分类策略
|
||||
- **知识要点型**：提取核心概念和关键信息（≤200字）
|
||||
- **解决方案型**：问题+方案+结果的标准化格式（≤300字）
|
||||
- **技术总结型**：关键技术栈+核心架构+要点列表（≤400字）
|
||||
- **经验教训型**：情况+处理+收获的简洁总结（≤250字）
|
||||
|
||||
### XML友好的内容特征
|
||||
- 使用简洁的markdown格式，避免复杂嵌套
|
||||
- 关键信息前置，细节适度精简
|
||||
- 代码片段保持简短，仅展示核心逻辑
|
||||
- 标题层级不超过3级，保持扁平化结构
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
## XML记忆内容处理逻辑
|
||||
|
||||
### 内容长度智能控制
|
||||
- **超长内容识别**：>500字的内容需要压缩处理
|
||||
- **核心信息提取**：保留关键技术点、解决方案、重要结论
|
||||
- **细节层次筛选**：区分核心信息vs支撑细节，优先保留核心
|
||||
- **格式简化处理**：复杂markdown转换为简洁格式
|
||||
|
||||
### 标签系统规范化
|
||||
- **主标签分类**：技术栈、领域、类型、优先级四个维度
|
||||
- **标签命名规范**：使用统一格式，避免特殊字符和空格
|
||||
- **去重机制**：检查已有标签，避免语义重复
|
||||
- **层级标签**：支持`技术栈-具体技术`的层级结构
|
||||
|
||||
### 内容结构化模板
|
||||
```
|
||||
## [简洁标题]
|
||||
**核心要点**：[1-2句话概括]
|
||||
**关键信息**：[结构化列表，3-5点]
|
||||
**技术栈**：[相关技术]
|
||||
**适用场景**：[使用条件]
|
||||
**价值收益**：[解决的问题或带来的价值]
|
||||
```
|
||||
|
||||
### XML转义友好处理
|
||||
- **特殊字符预处理**：主动识别和处理<>&"'等字符
|
||||
- **代码块优化**：简化代码示例，保留核心逻辑
|
||||
- **JSON/XML示例**：提供简化版本，避免复杂嵌套
|
||||
- **URL链接处理**：使用描述性文本替代长链接
|
||||
</reasoning>
|
||||
|
||||
<challenge>
|
||||
## XML记忆模式关键挑战
|
||||
|
||||
### 信息完整性vs可读性平衡
|
||||
- 如何在保持信息完整的同时提升XML显示效果？
|
||||
- 精简内容是否会丢失重要的技术细节？
|
||||
- 如何判断哪些信息属于"核心"vs"细节"？
|
||||
|
||||
### 标签系统一致性
|
||||
- 如何确保不同时间、不同上下文的标签保持一致？
|
||||
- 自动生成标签与用户自定义标签如何协调？
|
||||
- 标签过多或过少都会影响检索效果，如何平衡？
|
||||
|
||||
### 内容压缩的质量控制
|
||||
- 压缩算法可能误删重要信息，如何保障质量？
|
||||
- 技术文档的层次结构如何在压缩后保持？
|
||||
- 用户的个人表达风格是否应该保留？
|
||||
|
||||
### 跨领域适应性
|
||||
- 不同技术领域的记忆内容结构差异很大，如何统一？
|
||||
- 前端、后端、架构、业务等不同角色的记忆偏好如何平衡？
|
||||
</challenge>
|
||||
|
||||
<plan>
|
||||
## XML记忆优化工作流程
|
||||
|
||||
### 记忆内容预处理
|
||||
1. **内容长度评估** → 判断是否需要压缩（>400字触发）
|
||||
2. **信息类型识别** → 分类为知识要点/解决方案/技术总结/经验教训
|
||||
3. **核心信息提取** → 使用模板化方式重组内容
|
||||
4. **格式简化处理** → 优化markdown格式，提升XML兼容性
|
||||
5. **特殊字符预处理** → 主动处理XML转义问题
|
||||
|
||||
### 标签系统优化
|
||||
1. **标签维度分析** → 识别技术栈、领域、类型、重要性
|
||||
2. **自动标签生成** → 基于内容智能生成3-5个核心标签
|
||||
3. **标签去重检查** → 与现有记忆标签对比，避免重复
|
||||
4. **标签格式规范** → 统一命名格式，支持层级结构
|
||||
5. **标签质量验证** → 确保标签与内容的匹配度
|
||||
|
||||
### 记忆质量控制
|
||||
1. **压缩质量评估** → 核心信息保留率检查
|
||||
2. **可读性验证** → XML展示效果预览
|
||||
3. **检索友好性** → 关键词覆盖度评估
|
||||
4. **内容完整性** → 重要技术细节保留确认
|
||||
5. **用户体验优化** → 格式美观度和阅读体验
|
||||
|
||||
### 个性化适配策略
|
||||
- **领域特化**：根据用户主要技术领域调整模板
|
||||
- **角色适配**：前端/后端/架构师等不同角色的记忆偏好
|
||||
- **详细度偏好**：用户对技术细节的保留偏好学习
|
||||
- **标签习惯**：学习用户的标签使用习惯和偏好
|
||||
</plan>
|
||||
</thought>
|
||||
Reference in New Issue
Block a user