删除多个不再使用的协议文档，包括memory、dpml、execution、resource和thought协议，清理代码库以提高可维护性。
This commit is contained in:
sean
167
protocol/practice/execution-best-practice.md
Normal file
167
protocol/practice/execution-best-practice.md
Normal file
@ -0,0 +1,167 @@
|
||||
# DPML执行模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML执行模式提示词框架的最佳实践指南，包括表达原则和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 表达原则
|
||||
|
||||
各子概念推荐使用不同的表达方式：
|
||||
|
||||
#### process - 适合使用图形表达
|
||||
|
||||
流程是最适合使用图形表达的元素，推荐使用流程图或时序图：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始] --> B{条件判断}
|
||||
B -->|条件成立| C[执行步骤1]
|
||||
B -->|条件不成立| D[执行步骤2]
|
||||
C --> E[下一步]
|
||||
D --> E
|
||||
E --> F[结束]
|
||||
```
|
||||
|
||||
#### guideline - 适合使用列表表达
|
||||
|
||||
建议性指导原则适合使用有序或无序列表，突出推荐性质：
|
||||
|
||||
```
|
||||
- 提供用户友好的错误信息
|
||||
- 对敏感操作进行二次确认
|
||||
- 使用渐进式信息收集方式
|
||||
```
|
||||
|
||||
#### rule - 适合使用编号列表表达
|
||||
|
||||
强制性规则适合使用编号列表，突出其必须遵守的性质：
|
||||
|
||||
```
|
||||
1. 密码必须包含大小写字母、数字和特殊字符
|
||||
2. 敏感数据传输必须使用加密通道
|
||||
3. 用户操作必须记录审计日志
|
||||
```
|
||||
|
||||
#### constraint - 适合使用分类列表表达
|
||||
|
||||
约束条件适合使用分类列表，按约束类型组织：
|
||||
|
||||
```
|
||||
技术约束：
|
||||
- 服务器内存限制: 16GB
|
||||
- 数据库连接数上限: 100
|
||||
|
||||
业务约束：
|
||||
- 用户年龄限制: >13岁
|
||||
- 服务区域限制: 指定国家/地区
|
||||
```
|
||||
|
||||
#### criteria - 适合使用表格表达
|
||||
|
||||
评价标准最适合使用表格，清晰展示指标和目标值：
|
||||
|
||||
```
|
||||
| 指标 | 目标值 | 最低要求 |
|
||||
|-----|-------|---------|
|
||||
| 响应时间 | <200ms | <500ms |
|
||||
| 成功率 | >99% | >95% |
|
||||
| 用户满意度 | >4.5/5 | >4/5 |
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 用户注册流程示例
|
||||
|
||||
```xml
|
||||
<execution domain="web" context="server">
|
||||
<process>
|
||||
# 用户注册流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始] --> B[验证输入]
|
||||
B --> C{输入有效?}
|
||||
C -->|是| D[检查用户是否存在]
|
||||
C -->|否| E[返回错误信息]
|
||||
D --> F{用户存在?}
|
||||
F -->|是| G[返回用户已存在]
|
||||
F -->|否| H[创建用户]
|
||||
H --> I[发送确认邮件]
|
||||
I --> J[结束]
|
||||
E --> J
|
||||
G --> J
|
||||
```
|
||||
|
||||
## 异常处理路径
|
||||
1. 数据库连接失败：重试3次，仍失败则返回系统错误
|
||||
2. 邮件服务不可用：将邮件加入队列，返回部分成功信息
|
||||
3. 输入验证失败：返回具体的字段错误信息
|
||||
</process>
|
||||
|
||||
<guideline>
|
||||
# 用户体验建议
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((注册体验))
|
||||
表单设计
|
||||
字段顺序从简单到复杂
|
||||
实时字段验证
|
||||
进度指示器
|
||||
错误提示
|
||||
友好明确的错误信息
|
||||
提供修正建议
|
||||
流程优化
|
||||
最少必填字段
|
||||
分步注册可选
|
||||
```
|
||||
|
||||
- 使用渐进式表单，先收集必要信息，成功后再补充其他信息
|
||||
- 提供社交媒体快捷注册选项
|
||||
- 密码强度视觉指示器
|
||||
</guideline>
|
||||
|
||||
<rule>
|
||||
# 必须遵循的规则
|
||||
|
||||
1. 密码必须至少8个字符，包含大小写字母、数字和特殊字符
|
||||
2. 用户邮箱必须通过验证才能激活账户
|
||||
3. 敏感个人信息必须加密存储
|
||||
4. 用户协议必须显式接受
|
||||
5. IP地址和注册时间必须记录日志
|
||||
</rule>
|
||||
|
||||
<constraint>
|
||||
# 系统限制条件
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[技术约束] --> B[数据库连接池上限: 100]
|
||||
A --> C[API调用频率: 10次/秒]
|
||||
D[业务约束] --> E[注册用户年龄: >13岁]
|
||||
D --> F[服务区域: 指定国家/地区]
|
||||
```
|
||||
|
||||
- 存储空间限制：用户头像最大2MB
|
||||
- 处理时间约束：注册流程必须在3秒内完成
|
||||
- 并发限制：同一IP每分钟最多5次注册请求
|
||||
</constraint>
|
||||
|
||||
<criteria>
|
||||
# 成功标准
|
||||
|
||||
| 指标 | 目标值 | 最低要求 |
|
||||
|-----|-------|---------|
|
||||
| 注册成功率 | >95% | >90% |
|
||||
| 平均完成时间 | <60秒 | <90秒 |
|
||||
| 邮箱验证率 | >80% | >70% |
|
||||
| 表单放弃率 | <20% | <30% |
|
||||
|
||||
## 质量检查点
|
||||
1. 所有必填字段已验证
|
||||
2. 用户记录已正确创建
|
||||
3. 确认邮件已发送或进入队列
|
||||
4. 欢迎信息已显示
|
||||
</criteria>
|
||||
</execution>
|
||||
```
|
||||
132
protocol/practice/memory-best-practice.md
Normal file
132
protocol/practice/memory-best-practice.md
Normal file
@ -0,0 +1,132 @@
|
||||
# DPML记忆模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML记忆模式提示词框架的最佳实践指南，包括记忆类型选择、操作建议和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 记忆类型选择
|
||||
|
||||
协议实现可以根据需求采用不同的记忆类型分类方法，以下是基于认知心理学的常见分类：
|
||||
|
||||
1. **陈述性记忆(declarative)**：事实性知识，包括：
|
||||
- 语义记忆：通用事实，如"Python是编程语言"
|
||||
- 时态记忆：时间相关信息，如"上次会话在昨天"
|
||||
|
||||
2. **程序性记忆(procedural)**：过程和技能知识，如：
|
||||
- 操作步骤：如"解决环境配置问题的方法"
|
||||
- 行动模式：如"用户代码风格偏好"
|
||||
|
||||
3. **情景记忆(episodic)**：特定经历和场景，如：
|
||||
- 交互记录：如"用户之前遇到的报错"
|
||||
- 场景重建：如"项目开发历程"
|
||||
|
||||
不同类型记忆的选择建议：
|
||||
- 存储事实性信息时，考虑使用陈述性记忆方式
|
||||
- 存储方法和步骤时，考虑使用程序性记忆方式
|
||||
- 存储具体交互经历时，考虑使用情景记忆方式
|
||||
|
||||
### 记忆操作使用建议
|
||||
|
||||
- **evaluate最佳实践**：
|
||||
- 明确设定评估标准
|
||||
- 综合考虑信息的稀有性、实用性和时效性
|
||||
- 避免过度记忆导致的信息冗余
|
||||
|
||||
- **store最佳实践**：
|
||||
- 为记忆提供足够的上下文
|
||||
- 建立适当的记忆关联
|
||||
- 设置合理的过期策略
|
||||
|
||||
- **recall最佳实践**：
|
||||
- 优先使用精确查询
|
||||
- 指定合理的置信度阈值
|
||||
- 处理记忆缺失的回退策略
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 基础使用示例
|
||||
|
||||
```xml
|
||||
<!-- 简单的记忆定义 -->
|
||||
<memory id="os_preference">
|
||||
用户使用MacOS系统
|
||||
</memory>
|
||||
|
||||
<!-- 带评估的记忆创建 -->
|
||||
<memory id="code_style">
|
||||
<evaluate:thought>
|
||||
<reasoning>
|
||||
用户连续三次使用了相同的代码风格(缩进2空格、驼峰命名)，
|
||||
这是重要的个人偏好信息，应记住以提供一致的代码建议。
|
||||
评分：实用性=8，稳定性=9，总分8.5 > 阈值7.5
|
||||
</reasoning>
|
||||
</evaluate:thought>
|
||||
|
||||
<store:execution>
|
||||
{
|
||||
"indent": "2spaces",
|
||||
"naming": "camelCase",
|
||||
"brackets": "sameLine"
|
||||
}
|
||||
</store:execution>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 高级使用示例
|
||||
|
||||
```xml
|
||||
<!-- 完整的记忆生命周期示例 -->
|
||||
<memory id="error_solution">
|
||||
<!-- 评估阶段：判断是否值得记忆 -->
|
||||
<evaluate:thought>
|
||||
<reasoning>
|
||||
分析用户遇到的依赖安装错误:
|
||||
|
||||
1. 问题特点:
|
||||
- 特定版本冲突问题
|
||||
- 解决方法非官方文档所列
|
||||
- 多次在社区中被报告
|
||||
|
||||
2. 记忆价值:
|
||||
- 解决方案不易找到
|
||||
- 可能重复出现
|
||||
- 节省未来排查时间
|
||||
|
||||
记忆价值评分：9/10，超过阈值
|
||||
决策：应当记忆此解决方案
|
||||
</reasoning>
|
||||
</evaluate:thought>
|
||||
|
||||
<!-- 存储阶段：通过execution实现 -->
|
||||
<store:execution>
|
||||
问题：TensorFlow 2.4安装与CUDA 11.2版本冲突
|
||||
解决方案：使用兼容性补丁并降级CUDA驱动
|
||||
|
||||
<!-- 使用execution协议元素定义存储过程 -->
|
||||
<process>
|
||||
# 存储流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[接收内容] --> B[验证格式]
|
||||
B --> C[分类标记]
|
||||
C --> D[构建索引]
|
||||
D --> E[写入持久存储]
|
||||
```
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
1. 解决方案记忆优先级设为高
|
||||
2. 建立与相关技术的关联索引
|
||||
3. 保存完整的上下文信息
|
||||
</rule>
|
||||
</store:execution>
|
||||
|
||||
<!-- 检索阶段：通过resource实现 -->
|
||||
<recall:resource>
|
||||
@memory://solutions/tensorflow?confidence=0.7
|
||||
</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
> **注意**：memory协议与thought(评估)、execution(存储)、resource(检索)协议紧密结合，形成完整的记忆系统。
|
||||
199
protocol/practice/thought-best-practice.md
Normal file
199
protocol/practice/thought-best-practice.md
Normal file
@ -0,0 +1,199 @@
|
||||
# DPML思考模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML思考模式提示词框架的最佳实践指南，包括图形化表达原则、各类思维模式的推荐用法和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 图形化表达原则
|
||||
|
||||
thought标签内应以图形为主要表达方式，辅以简洁文字说明。这样做的优势：
|
||||
- 思维结构直观可见
|
||||
- 关系与逻辑一目了然
|
||||
- 跨语言理解更容易
|
||||
- 思维模式界限更清晰
|
||||
|
||||
### 各子标签推荐图形
|
||||
|
||||
每种思维模式都有最适合的图形表达方式：
|
||||
|
||||
#### exploration - 思维导图
|
||||
|
||||
用于表达横向思维和概念发散，简单文字仅需说明核心问题和主要分支。
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((核心问题))
|
||||
可能性A
|
||||
子可能性A1
|
||||
子可能性A2
|
||||
可能性B
|
||||
子可能性B1
|
||||
可能性C
|
||||
```
|
||||
|
||||
#### reasoning - 推理图
|
||||
|
||||
用于表达纵向思维和逻辑推导，文字说明只需点明前提和结论间的关系。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[前提] --> B[中间命题1]
|
||||
A --> C[中间命题2]
|
||||
B --> D[结论1]
|
||||
C --> E[结论2]
|
||||
```
|
||||
|
||||
#### plan - 流程图
|
||||
|
||||
用于表达计划思维和决策路径，文字仅需标注关键决策点和行动步骤。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[起点] --> B{判断条件}
|
||||
B -->|条件成立| C[执行步骤1]
|
||||
B -->|条件不成立| D[执行步骤2]
|
||||
C --> E[结果1]
|
||||
D --> F[结果2]
|
||||
```
|
||||
|
||||
#### challenge - 逆向思维导图
|
||||
|
||||
用于表达批判性思维和风险探索，与exploration采用相似的图形表达，但关注的是潜在问题和限制条件。
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((方案风险))
|
||||
技术风险
|
||||
可扩展性问题
|
||||
性能瓶颈
|
||||
实施风险
|
||||
资源不足
|
||||
时间限制
|
||||
业务风险
|
||||
用户接受度
|
||||
```
|
||||
|
||||
### Mermaid图表分类参考表
|
||||
|
||||
下表系统地列出了各种Mermaid图表类型及其适用的思维模式：
|
||||
|
||||
| 图表类型 | 思维模式 | 适用场景 | 优势 |
|
||||
|---------|----------|---------|------|
|
||||
| 思维导图(mindmap) | Exploration/Challenge | 概念发散、头脑风暴、风险识别 | 展示中心概念及其分支关系 |
|
||||
| 四象限图(quadrantChart) | Exploration/Challenge | 方案评估、风险分析、优先级划分 | 在两个维度上评估选项或风险 |
|
||||
| 流程图(flowchart) | Reasoning/Challenge | 逻辑推导、算法思路、决策分析、故障分析 | 清晰表达推理过程中的逻辑关系 |
|
||||
| 饼图(pie) | Reasoning | 比例分析、相对重要性评估 | 直观展示整体中各部分的占比 |
|
||||
| 类图(classDiagram) | Plan | 结构设计、概念分类、系统架构 | 展示实体间的层次和组织关系 |
|
||||
| 甘特图(gantt) | Plan | 项目规划、时间安排、任务依赖 | 展示任务的时间跨度和先后关系 |
|
||||
| 序列图(sequenceDiagram) | Plan | 交互设计、通信计划、协作过程 | 清晰展示实体间的消息传递和时序 |
|
||||
| 状态图(stateDiagram) | Plan | 状态管理、过程转换、行为模式 | 展示系统状态和触发转换的事件 |
|
||||
| 实体关系图(erDiagram) | Plan | 数据结构设计、系统建模 | 展示实体间的关系和属性 |
|
||||
| 时间线(timeline) | Reasoning | 历史分析、演变过程、发展轨迹 | 按时间顺序展示事件发展 |
|
||||
| 用户旅程图(journey) | Plan | 体验设计、流程优化、情感映射 | 展示用户交互过程和体验变化 |
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 基础示例
|
||||
|
||||
```xml
|
||||
<thought domain="design">
|
||||
<exploration>
|
||||
# 功能需求探索
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((用户需求))
|
||||
基础功能
|
||||
用户认证
|
||||
数据管理
|
||||
高级特性
|
||||
数据分析
|
||||
报表生成
|
||||
用户体验
|
||||
响应速度
|
||||
界面美观
|
||||
```
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
# 技术选型分析
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[需求分析] --> B[前端技术选型]
|
||||
A --> C[后端技术选型]
|
||||
B --> D[React]
|
||||
B --> E[Vue]
|
||||
C --> F[Node.js]
|
||||
C --> G[Python]
|
||||
```
|
||||
</reasoning>
|
||||
</thought>
|
||||
```
|
||||
|
||||
### 高级示例
|
||||
|
||||
```xml
|
||||
<thought domain="architecture">
|
||||
<exploration>
|
||||
# 系统架构探索
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((微服务架构))
|
||||
服务拆分
|
||||
用户服务
|
||||
订单服务
|
||||
支付服务
|
||||
技术栈
|
||||
Spring Cloud
|
||||
Docker
|
||||
Kubernetes
|
||||
数据存储
|
||||
MySQL
|
||||
Redis
|
||||
MongoDB
|
||||
```
|
||||
</exploration>
|
||||
|
||||
<plan>
|
||||
# 实施计划
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title 项目实施计划
|
||||
dateFormat YYYY-MM-DD
|
||||
section 基础设施
|
||||
环境搭建 :a1, 2024-01-01, 5d
|
||||
CI/CD配置 :a2, after a1, 3d
|
||||
section 开发
|
||||
用户服务 :a3, 2024-01-08, 10d
|
||||
订单服务 :a4, after a3, 12d
|
||||
section 测试
|
||||
集成测试 :a5, after a4, 5d
|
||||
```
|
||||
</plan>
|
||||
|
||||
<challenge>
|
||||
# 风险评估
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((潜在风险))
|
||||
技术风险
|
||||
服务间通信延迟
|
||||
数据一致性问题
|
||||
运维风险
|
||||
服务器成本
|
||||
监控复杂度
|
||||
团队风险
|
||||
学习曲线
|
||||
人员配置
|
||||
```
|
||||
</challenge>
|
||||
</thought>
|
||||
```
|
||||
|
||||
### 组件选择的灵活性
|
||||
|
||||
实际应用中，可根据角色定位和任务目标灵活选择所需的思考组件（exploration、challenge、reasoning、plan），不必全部包含四种模式。例如，执行者角色更侧重于reasoning和challenge，而设计者或决策者则更需要exploration和plan。可根据实际需求进行裁剪和组合，以适应不同的思考任务和角色分工。
|
||||
Reference in New Issue
Block a user