更新DPML协议文档，新增属性约束部分，详细阐述属性的通用性、定义原则和规范管理，确保提示词的一致性和互操作性。同时，删除不再使用的执行、记忆、资源、角色和思考协议文档，优化代码库结构以提高可维护性。
This commit is contained in:
sean
167
domain/prompt/practice/execution-best-practice.md
Normal file
167
domain/prompt/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>
|
||||
```
|
||||
253
domain/prompt/practice/memory-best-practice.md
Normal file
253
domain/prompt/practice/memory-best-practice.md
Normal file
@ -0,0 +1,253 @@
|
||||
# DPML记忆模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML记忆模式提示词框架的最佳实践指南，包括知识库设计、记忆类型选择、操作建议和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 知识库设计
|
||||
|
||||
角色的先验知识库设计应考虑以下因素：
|
||||
|
||||
- **结构化程度**：
|
||||
- 高度结构化：适合专业领域知识，便于精确检索
|
||||
- 半结构化：适合通用知识，平衡灵活性和组织性
|
||||
- 低结构化：适合创意和启发性内容，保持关联灵活性
|
||||
|
||||
- **知识粒度**：
|
||||
- 宏观框架：定义领域整体认知结构
|
||||
- 中观原则：定义关键概念和方法论
|
||||
- 微观细节：定义具体事实和操作步骤
|
||||
|
||||
- **表达方式推荐**：
|
||||
- 领域地图：使用思维导图表达知识间的关系
|
||||
- 分类表格：使用表格整理分类知识
|
||||
- 核心原则：使用编号列表表达重要规则和原则
|
||||
|
||||
- **资源引用特性**：
|
||||
- 预加载原则：knowledge标签中的所有资源引用都会在角色初始化时加载
|
||||
- 内容与引用平衡：综合使用直接内容和资源引用
|
||||
- 分级引用：核心知识内联，扩展知识通过资源引用
|
||||
|
||||
### 记忆类型选择
|
||||
|
||||
协议实现可以根据需求采用不同的记忆类型分类方法，以下是基于认知心理学的常见分类：
|
||||
|
||||
1. **陈述性记忆(declarative)**：事实性知识，包括：
|
||||
- 语义记忆：通用事实，如"Python是编程语言"
|
||||
- 时态记忆：时间相关信息，如"上次会话在昨天"
|
||||
|
||||
2. **程序性记忆(procedural)**：过程和技能知识，如：
|
||||
- 操作步骤：如"解决环境配置问题的方法"
|
||||
- 行动模式：如"用户代码风格偏好"
|
||||
|
||||
3. **情景记忆(episodic)**：特定经历和场景，如：
|
||||
- 交互记录：如"用户之前遇到的报错"
|
||||
- 场景重建：如"项目开发历程"
|
||||
|
||||
不同类型记忆的选择建议：
|
||||
- 存储事实性信息时，考虑使用陈述性记忆方式
|
||||
- 存储方法和步骤时，考虑使用程序性记忆方式
|
||||
- 存储具体交互经历时，考虑使用情景记忆方式
|
||||
|
||||
### 记忆操作使用建议
|
||||
|
||||
- **knowledge最佳实践**：
|
||||
- 将核心知识组织为分层结构
|
||||
- 使用可视化图表表达知识间的关系
|
||||
- 区分"确定性知识"和"启发性知识"
|
||||
- 避免过于琐碎的细节，保持适当抽象
|
||||
- 确保所有关键知识都在角色初始化时可用
|
||||
- 平衡内联内容和资源引用，内联核心概念，引用详细信息
|
||||
- 使用资源引用时考虑加载成本，避免引用过大的资源
|
||||
|
||||
- **evaluate最佳实践**：
|
||||
- 明确设定评估标准
|
||||
- 综合考虑信息的稀有性、实用性和时效性
|
||||
- 避免过度记忆导致的信息冗余
|
||||
|
||||
- **store最佳实践**：
|
||||
- 为记忆提供足够的上下文
|
||||
- 建立适当的记忆关联
|
||||
- 设置合理的过期策略
|
||||
|
||||
- **recall最佳实践**：
|
||||
- 设计清晰的记忆检索触发条件
|
||||
- 制定多层次的检索策略
|
||||
- 规划记忆应用的具体步骤
|
||||
- 处理记忆缺失的回退策略
|
||||
- 资源引用按需加载，注意引用路径的准确性
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 基础使用示例
|
||||
|
||||
```xml
|
||||
<!-- 带知识库的简单记忆定义 -->
|
||||
<memory id="tech_specialist">
|
||||
<knowledge>
|
||||
# 技术领域基础知识
|
||||
|
||||
## 核心概念（直接内联，预加载）
|
||||
- 编程语言：Python、JavaScript、Go
|
||||
- 开发框架：React、Django、Flask
|
||||
- 数据库技术：SQL、MongoDB、Redis
|
||||
|
||||
## 详细资料（资源引用，预加载）
|
||||
- @file://references/programming_languages.md
|
||||
- @file://references/frameworks.md
|
||||
</knowledge>
|
||||
|
||||
<!-- 运行时记忆处理 -->
|
||||
<evaluate:thought>
|
||||
<reasoning>
|
||||
用户提供了特定的代码风格偏好，这对提供一致的代码建议很重要。
|
||||
评分：实用性=8，稳定性=9，总分8.5 > 阈值7.5
|
||||
</reasoning>
|
||||
</evaluate:thought>
|
||||
|
||||
<store:execution>
|
||||
{
|
||||
"indent": "2spaces",
|
||||
"naming": "camelCase",
|
||||
"brackets": "sameLine"
|
||||
}
|
||||
</store:execution>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 高级使用示例
|
||||
|
||||
```xml
|
||||
<!-- 完整的记忆生命周期示例 -->
|
||||
<memory id="support_specialist">
|
||||
<!-- 知识库定义 -->
|
||||
<knowledge>
|
||||
# 技术支持专家知识库
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((技术支持))
|
||||
常见问题
|
||||
依赖冲突
|
||||
环境配置
|
||||
性能优化
|
||||
诊断方法
|
||||
日志分析
|
||||
错误模式识别
|
||||
性能分析
|
||||
解决策略
|
||||
快速修复
|
||||
根本解决
|
||||
预防措施
|
||||
```
|
||||
|
||||
## 优先级框架
|
||||
| 问题类型 | 优先级 | 响应时间 |
|
||||
|---------|-------|---------|
|
||||
| 系统宕机 | 紧急 | <30分钟 |
|
||||
| 功能障碍 | 高 | <2小时 |
|
||||
| 性能问题 | 中 | <1天 |
|
||||
| 功能建议 | 低 | <1周 |
|
||||
|
||||
## 知识库引用（全部预加载）
|
||||
- @file://kb/common_errors.md
|
||||
- @http://internal.docs/troubleshooting-guide.html
|
||||
- @db://support/solutions
|
||||
</knowledge>
|
||||
|
||||
<!-- 评估阶段：判断是否值得记忆 -->
|
||||
<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>
|
||||
|
||||
<!-- 检索阶段：通过thought实现 -->
|
||||
<recall:thought>
|
||||
<reasoning>
|
||||
根据当前用户描述的错误信息分析:
|
||||
- 涉及TensorFlow与CUDA版本问题
|
||||
- 错误模式与之前记录的类似
|
||||
- 应当检索相关解决方案
|
||||
</reasoning>
|
||||
|
||||
<plan>
|
||||
# 记忆应用计划
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[识别问题模式] --> B[检索相关记忆]
|
||||
B --> C[验证适用性]
|
||||
C -->|适用| D[应用解决方案]
|
||||
C -->|不适用| E[寻找替代方案]
|
||||
D --> F[监控结果]
|
||||
```
|
||||
|
||||
1. 检索TensorFlow相关解决方案
|
||||
2. 验证版本兼容性
|
||||
3. 提供定制化指导
|
||||
|
||||
<!-- 按需加载的外部资源 -->
|
||||
@file://solutions/tensorflow_cuda_fixes.md
|
||||
</plan>
|
||||
</recall:thought>
|
||||
</memory>
|
||||
```
|
||||
|
||||
## 实现考虑事项
|
||||
|
||||
### 知识预加载与按需加载的平衡
|
||||
|
||||
- **预加载考虑**：knowledge标签中的所有内容和资源引用都预加载
|
||||
- 优点：对话开始时角色就拥有完整知识
|
||||
- 缺点：初始化成本高，特别是引用大型资源时
|
||||
|
||||
- **混合策略建议**：
|
||||
- 核心知识直接内联在knowledge标签中
|
||||
- 必要但不常用的知识通过资源引用方式组织
|
||||
- 极少使用的扩展知识放在recall中按需引用
|
||||
|
||||
- **性能优化**：
|
||||
- 对大型知识库考虑使用索引+按需加载模式
|
||||
- 使用分层加载策略：核心立即加载，细节延迟加载
|
||||
- 为循环引用建立保护机制，避免无限递归加载
|
||||
|
||||
> **注意**：memory协议现在包含四个核心组件：knowledge(先验知识库)、evaluate(评估)、store(存储)和recall(回忆)，共同构成完整的记忆系统。knowledge定义预加载知识，而其他组件负责运行时记忆管理。
|
||||
101
domain/prompt/practice/resource-best-practice.md
Normal file
101
domain/prompt/practice/resource-best-practice.md
Normal file
@ -0,0 +1,101 @@
|
||||
# DPML资源模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML资源模式提示词框架的最佳实践指南，包括资源路径设计、查询参数设计、引用建议和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 资源路径设计
|
||||
|
||||
资源路径设计应遵循以下原则：
|
||||
- 使用直观、符合惯例的路径格式
|
||||
- 支持绝对路径和相对路径
|
||||
- 适当使用通配符增强灵活性
|
||||
- 路径分隔符应统一使用`/`
|
||||
|
||||
### 查询参数设计
|
||||
|
||||
查询参数设计应考虑以下因素：
|
||||
- 参数名称应清晰表达其功能
|
||||
- 参数值格式应明确定义
|
||||
- 常见操作应有对应的参数支持（如范围指定、格式转换等）
|
||||
- 参数组合应有明确的优先级规则
|
||||
|
||||
### 资源引用最佳实践
|
||||
|
||||
1. 使用最合适的协议名称表示资源类型，提高语义明确性
|
||||
2. 嵌套引用时，如果清晰度很重要，使用完整形式（带内部@符号）
|
||||
3. 如果简洁性更重要，则使用简写形式（省略内部@符号）
|
||||
4. 保持资源路径的相对引用，以提高提示词的可移植性
|
||||
5. 合理使用通配符，避免过于宽泛的匹配模式
|
||||
6. 使用查询参数进行资源过滤，而不是在提示词中手动处理
|
||||
7. 避免过深的嵌套引用，建议不超过3层，保持可读性
|
||||
|
||||
### 表达风格推荐
|
||||
|
||||
- **location**: 优先使用EBNF格式正式描述语法规则，辅以简洁示例
|
||||
- **params**: 使用表格形式列出参数，清晰展示名称、类型、描述和示例
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 自定义协议示例
|
||||
|
||||
以下示例展示了如何定义自定义资源协议：
|
||||
|
||||
```xml
|
||||
<resource protocol="memory">
|
||||
<location>
|
||||
# 路径规则 (EBNF)
|
||||
|
||||
```ebnf
|
||||
memory_path ::= [namespace '/'] memory_key
|
||||
namespace ::= (letter | digit | '_' | '-')+
|
||||
memory_key ::= (letter | digit | '_' | '-' | '.')+
|
||||
```
|
||||
|
||||
## 示例
|
||||
- @memory://user_preferences
|
||||
- @memory://session/history
|
||||
- @memory://system/config
|
||||
</location>
|
||||
|
||||
<params>
|
||||
# 查询参数
|
||||
|
||||
| 参数名 | 类型 | 描述 | 示例 |
|
||||
|-------|------|------|------|
|
||||
| ttl | 数字 | 生存时间(秒) | ?ttl=3600 |
|
||||
| default | 字符串 | 默认值 | ?default=empty |
|
||||
| type | 字符串 | 值类型 | ?type=json |
|
||||
</params>
|
||||
</resource>
|
||||
```
|
||||
|
||||
```xml
|
||||
<resource protocol="context">
|
||||
<location>
|
||||
# 路径规则 (EBNF)
|
||||
|
||||
```ebnf
|
||||
context_path ::= [scope '/'] path
|
||||
scope ::= (letter | digit | '_' | '-')+
|
||||
path ::= path_segment {'/' path_segment}
|
||||
path_segment ::= (letter | digit | '_' | '-' | '.')+
|
||||
```
|
||||
|
||||
## 示例
|
||||
- @context://global/settings
|
||||
- @context://user/preferences
|
||||
- @context://session/state
|
||||
</location>
|
||||
|
||||
<params>
|
||||
# 查询参数
|
||||
|
||||
| 参数名 | 类型 | 描述 | 示例 |
|
||||
|-------|------|------|------|
|
||||
| mode | 字符串 | 上下文模式 | ?mode=read 或 ?mode=write |
|
||||
| scope | 字符串 | 访问范围 | ?scope=local 或 ?scope=global |
|
||||
| format | 字符串 | 返回格式 | ?format=json |
|
||||
</params>
|
||||
</resource>
|
||||
```
|
||||
426
domain/prompt/practice/role-best-practice.md
Normal file
426
domain/prompt/practice/role-best-practice.md
Normal file
@ -0,0 +1,426 @@
|
||||
# DPML角色合成提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML角色合成提示词框架的最佳实践指南，包括角色类型特点、组合原则和实际示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 角色类型与协议侧重
|
||||
|
||||
不同类型的角色在三大基础协议的侧重点不同：
|
||||
|
||||
1. **顾问型角色(Advisor)**
|
||||
- 思考侧重: exploration(探索)和challenge(挑战)
|
||||
- 执行侧重: guideline(指导原则)
|
||||
- 记忆侧重: 广泛的领域知识
|
||||
- 对话特点: 引导式、多角度分析、提供选项
|
||||
|
||||
2. **执行型角色(Executor)**
|
||||
- 思考侧重: reasoning(推理)和plan(计划)
|
||||
- 执行侧重: process(流程)和rule(规则)
|
||||
- 记忆侧重: 程序性知识和最佳实践
|
||||
- 对话特点: 任务确认、步骤分解、结果报告
|
||||
|
||||
3. **决策型角色(Decider)**
|
||||
- 思考侧重: challenge(挑战)和reasoning(推理)
|
||||
- 执行侧重: criteria(标准)和constraint(约束)
|
||||
- 记忆侧重: 综合性知识和经验模式
|
||||
- 对话特点: 结论先行、权威陈述、明确判断
|
||||
|
||||
4. **创造型角色(Creator)**
|
||||
- 思考侧重: exploration(探索)
|
||||
- 执行侧重: guideline(指导原则)
|
||||
- 记忆侧重: 创意资源和参考
|
||||
- 对话特点: 发散联想、比喻表达、灵感激发
|
||||
|
||||
### 角色组合原则
|
||||
|
||||
构建角色时应遵循以下原则：
|
||||
|
||||
1. **完整性原则**: 角色定义应包含思考、执行和记忆三个方面，缺一不可
|
||||
2. **一致性原则**: 三大协议的内容应相互协调，避免矛盾冲突
|
||||
3. **特性突出原则**: 根据角色类型突出关键特性，保持特点鲜明
|
||||
4. **边界清晰原则**: 明确定义角色的能力边界和限制，避免能力过度或不足
|
||||
5. **可扩展原则**: 设计时预留角色能力的扩展点，便于后续调整
|
||||
|
||||
### 角色设计策略
|
||||
|
||||
#### 顾问型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好多角度分析，善于质疑和挑战
|
||||
* **执行特点**: 以指导为主，可提供多种方案和选择
|
||||
* **记忆组织**: 知识体系全面，重点是领域核心概念和原则
|
||||
* **表达方式**: 善用比较分析，提供决策建议而非指令
|
||||
|
||||
#### 执行型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好结构化分析，善于规划和步骤分解
|
||||
* **执行特点**: 以流程和规则为核心，注重效率和一致性
|
||||
* **记忆组织**: 侧重操作技巧和最佳实践，程序性知识丰富
|
||||
* **表达方式**: 步骤化、清晰简洁、关注可操作细节
|
||||
|
||||
#### 决策型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好批判性思考，善于权衡利弊
|
||||
* **执行特点**: 以标准和约束为核心，注重判断和评估
|
||||
* **记忆组织**: 综合性知识模型，侧重决策经验和模式识别
|
||||
* **表达方式**: 结论明确、逻辑严谨、判断清晰
|
||||
|
||||
#### 创造型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好探索性思维，善于联想和创新
|
||||
* **执行特点**: 以灵活指导为主，鼓励实验和尝试
|
||||
* **记忆组织**: 侧重创意资源和参考案例，注重启发性知识
|
||||
* **表达方式**: 生动形象、丰富多样、富有启发性
|
||||
|
||||
### 角色定义表达技巧
|
||||
|
||||
为提高角色定义的清晰度和直观性，推荐使用以下表达技巧：
|
||||
|
||||
1. **思维模式可视化**：使用思维导图展示角色的思考模式
|
||||
```mermaid
|
||||
mindmap
|
||||
root((角色思维))
|
||||
核心思考方式1
|
||||
子思维特点1
|
||||
子思维特点2
|
||||
核心思考方式2
|
||||
子思维特点3
|
||||
```
|
||||
|
||||
2. **执行流程图形化**：使用流程图展示角色的执行模式
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[起点] --> B{判断点}
|
||||
B -->|情况1| C[行动1]
|
||||
B -->|情况2| D[行动2]
|
||||
```
|
||||
|
||||
3. **记忆结构层次化**：使用树状图展示角色的知识组织
|
||||
```mermaid
|
||||
graph TD
|
||||
A[知识领域] --> B[子领域1]
|
||||
A --> C[子领域2]
|
||||
B --> D[具体知识点]
|
||||
```
|
||||
|
||||
4. **对话模式示例化**：使用示例对话展示角色的交互风格
|
||||
```
|
||||
用户: [典型问题]
|
||||
角色: [典型回应格式和风格]
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 顾问型角色(Advisor)示例
|
||||
|
||||
```xml
|
||||
<!-- 数据分析顾问角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="data-analysis">
|
||||
<exploration>
|
||||
# 数据解读思路
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((数据分析视角))
|
||||
统计模式识别
|
||||
相关性分析
|
||||
离群值识别
|
||||
业务洞察
|
||||
行业基准比较
|
||||
趋势预测
|
||||
可视化策略
|
||||
数据故事构建
|
||||
关键指标突出
|
||||
```
|
||||
</exploration>
|
||||
|
||||
<challenge>
|
||||
# 数据质量评估
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((数据质疑点))
|
||||
数据完整性
|
||||
缺失值影响
|
||||
样本代表性
|
||||
分析方法
|
||||
统计假设适用性
|
||||
模型选择合理性
|
||||
解读偏差
|
||||
确认偏误风险
|
||||
因果关系误判
|
||||
```
|
||||
</challenge>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="consulting">
|
||||
<guideline>
|
||||
# 咨询流程指南
|
||||
|
||||
- 先理解业务问题，再设计分析方案
|
||||
- 提供多角度的数据解读，而非单一结论
|
||||
- 使用客户熟悉的行业术语解释复杂概念
|
||||
- 结合定量分析和定性洞察
|
||||
</guideline>
|
||||
|
||||
<constraint>
|
||||
# 咨询限制
|
||||
|
||||
- 仅基于已提供的数据进行分析
|
||||
- 不对缺乏数据支持的领域做推断
|
||||
- 不提供法律或监管合规建议
|
||||
</constraint>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="data-science">
|
||||
<store:execution>
|
||||
# 专业知识库
|
||||
|
||||
- 统计学原理和最佳实践
|
||||
- 行业标准和基准数据
|
||||
- 常见数据分析方法论
|
||||
- 数据可视化技巧
|
||||
|
||||
<rule>
|
||||
1. 保持知识的时效性，过时信息标记不确定
|
||||
2. 行业特定知识与通用原则分开存储
|
||||
</rule>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
### 执行型角色(Executor)示例
|
||||
|
||||
```xml
|
||||
<!-- 项目管理执行者角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="project-management">
|
||||
<reasoning>
|
||||
# 项目评估逻辑
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[项目需求] --> B[资源评估]
|
||||
A --> C[风险评估]
|
||||
B --> D[时间估算]
|
||||
C --> E[解决方案设计]
|
||||
D --> F[项目计划]
|
||||
E --> F
|
||||
```
|
||||
</reasoning>
|
||||
|
||||
<plan>
|
||||
# 项目管理方法
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title 项目管理流程
|
||||
dateFormat YYYY-MM-DD
|
||||
section 规划
|
||||
需求分析 :a1, 2023-01-01, 5d
|
||||
资源规划 :a2, after a1, 3d
|
||||
section 执行
|
||||
任务分配 :a3, after a2, 2d
|
||||
进度监控 :a4, after a3, 10d
|
||||
section 收尾
|
||||
评估总结 :a5, after a4, 3d
|
||||
```
|
||||
</plan>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="project-execution">
|
||||
<process>
|
||||
# 标准执行流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[接收任务] --> B[任务分解]
|
||||
B --> C[资源分配]
|
||||
C --> D[执行监控]
|
||||
D --> E{是否达标}
|
||||
E -->|是| F[报告完成]
|
||||
E -->|否| G[调整方案]
|
||||
G --> D
|
||||
```
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
# 执行规范
|
||||
|
||||
1. 每日更新项目状态和进度
|
||||
2. 问题必须在24小时内上报或解决
|
||||
3. 资源变更必须获得预先批准
|
||||
4. 文档必须与实际执行保持同步
|
||||
</rule>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="project-management">
|
||||
<store:execution>
|
||||
# 程序性知识
|
||||
|
||||
- 项目管理最佳实践和方法论
|
||||
- 常见问题的解决方案模板
|
||||
- 资源调配策略和优先级规则
|
||||
|
||||
<process>
|
||||
# 经验应用流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[问题识别] --> B[经验检索]
|
||||
B --> C[方案调整]
|
||||
C --> D[实施应用]
|
||||
```
|
||||
</process>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
### 创意型角色(Creator)示例
|
||||
|
||||
```xml
|
||||
<!-- 创意写作者角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="creative-writing">
|
||||
<exploration>
|
||||
# 创意发散思路
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((故事构思))
|
||||
角色塑造
|
||||
性格矛盾点
|
||||
成长弧线
|
||||
世界观
|
||||
规则体系
|
||||
文化冲突
|
||||
情节设计
|
||||
悬念布局
|
||||
情感共鸣
|
||||
主题表达
|
||||
核心寓意
|
||||
社会映射
|
||||
```
|
||||
</exploration>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="writing">
|
||||
<guideline>
|
||||
# 创作指南
|
||||
|
||||
- 先发散思考，再聚焦核心创意
|
||||
- 避免陈词滥调，寻找新颖表达
|
||||
- 感性与理性相结合，情感与逻辑并重
|
||||
- 注重细节描写，以小见大
|
||||
</guideline>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="literature">
|
||||
<store:execution>
|
||||
# 创意资源库
|
||||
|
||||
- 文学典故和经典作品参考
|
||||
- 叙事技巧和表达手法
|
||||
- 多领域知识与灵感来源
|
||||
|
||||
<guideline>
|
||||
- 融会贯通不同领域知识
|
||||
- 寻找新颖的比喻和隐喻
|
||||
- 积累丰富的感官描写词汇
|
||||
</guideline>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
### 决策型角色(Decider)示例
|
||||
|
||||
```xml
|
||||
<!-- 技术决策者角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="tech-decision">
|
||||
<challenge>
|
||||
# 技术风险评估
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((技术决策风险))
|
||||
技术债务
|
||||
维护成本
|
||||
扩展难度
|
||||
集成挑战
|
||||
系统兼容性
|
||||
依赖管理
|
||||
生命周期
|
||||
技术成熟度
|
||||
社区活跃度
|
||||
```
|
||||
</challenge>
|
||||
|
||||
<reasoning>
|
||||
# 决策逻辑框架
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[问题定义] --> B[评估标准确定]
|
||||
B --> C[方案比较]
|
||||
C --> D[风险分析]
|
||||
D --> E[成本效益评估]
|
||||
E --> F[最终决策]
|
||||
```
|
||||
</reasoning>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="decision-making">
|
||||
<criteria>
|
||||
# 技术选型标准
|
||||
|
||||
| 指标 | 权重 | 衡量方法 |
|
||||
|-----|------|---------|
|
||||
| 性能 | 高 | 基准测试 |
|
||||
| 可维护性 | 中 | 代码复杂度 |
|
||||
| 社区支持 | 中 | 活跃度指标 |
|
||||
| 成本 | 低 | TCO分析 |
|
||||
</criteria>
|
||||
|
||||
<constraint>
|
||||
# 决策约束
|
||||
|
||||
- 必须符合组织技术栈战略
|
||||
- 安全合规不可妥协
|
||||
- 团队学习曲线必须考虑
|
||||
</constraint>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="tech-knowledge">
|
||||
<store:execution>
|
||||
# 技术决策知识库
|
||||
|
||||
- 历史技术选型案例与后果
|
||||
- 技术趋势和演进路线
|
||||
- 行业最佳实践和标准
|
||||
|
||||
<rule>
|
||||
1. 基于事实和数据作决策，而非个人偏好
|
||||
2. 考虑长期影响，避免短期优化
|
||||
3. 平衡创新与稳定性
|
||||
</rule>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
199
domain/prompt/practice/thought-best-practice.md
Normal file
199
domain/prompt/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