iriver/PromptX
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

删除执行、记忆和思维模式资源文档，清理不再使用的内容，以提高代码库的可维护性。同时在提示词开发者角色文档中新增最佳实践部分，提升文档的实用性和清晰度。

Browse Source
This commit is contained in:
sean
2025-05-20 17:34:27 +08:00
parent 4599e88db1
commit 9d173bc3d1
9 changed files with 755 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

132
domain/prompt/execution/execution-best-practice.execution.md Normal file
View File

@ -0,0 +1,132 @@
<execution domain="prompt-engineering">
<process>
# 执行模式提示词开发流程
```mermaid
flowchart TD
A[明确执行目标] --> B[定义核心流程]
B --> C[制定指导原则]
C --> D[设定强制规则]
D --> E[识别约束条件]
E --> F[确立评价标准]
F --> G[整合验证执行模式]
G --> H{执行模式验证}
H -->|通过| I[完成执行模式]
H -->|不通过| J[修改调整]
J --> B
```
## 核心步骤详解
1. **明确执行目标**
- 确定执行模式的核心任务和目标
- 明确执行对象和预期结果
2. **定义核心流程**
- 通过流程图或有序步骤表达执行路径
- 包含正常路径和异常处理路径
3. **多维度设计**
- 流程(Process): 详细的执行步骤和路径
- 指导原则(Guideline): 建议性的最佳实践
- 规则(Rule): 强制性的必须遵守的原则
- 约束(Constraint): 客观存在的限制条件
- 标准(Criteria): 评价执行结果的标准
4. **整合验证**
- 确保五大元素之间的一致性和完整性
- 验证执行模式的可行性和有效性
</process>
<guideline>
### 表达方式建议
- **流程(Process)应使用图形表达**
- 优先使用流程图或时序图
- 补充关键步骤的文字说明
- 示例：
```mermaid
flowchart TD
A[开始] --> B{条件判断}
B -->|条件成立| C[执行步骤1]
B -->|条件不成立| D[执行步骤2]
```
- **指导原则(Guideline)适合使用列表表达**
- 使用无序列表突出建议性质
- 保持简洁明了，便于理解
- 示例：
```
- 提供用户友好的错误信息
- 对敏感操作进行二次确认
```
- **规则(Rule)适合使用编号列表表达**
- 使用编号强调必须遵守的性质
- 确保表述清晰无歧义
- 示例：
```
1. 密码必须包含大小写字母、数字和特殊字符
2. 敏感数据传输必须使用加密通道
```
- **约束(Constraint)适合使用分类列表表达**
- 按约束类型组织内容
- 明确表达限制条件
- 示例：
```
技术约束：
- 服务器内存限制: 16GB
业务约束：
- 用户年龄限制: >13岁
```
- **标准(Criteria)适合使用表格表达**
- 清晰展示指标和目标值
- 必要时包含不通过标准
- 示例：
```
| 指标 | 目标值 | 最低要求 |
|-----|-------|---------|
| 响应时间 | <200ms | <500ms |
```
### 组织结构建议
- 按照Process → Guideline → Rule → Constraint → Criteria的顺序组织
- 元素间保持逻辑一致性，避免矛盾
- 优先考虑必要元素，不强制使用全部五种子标签
</guideline>
<rule>
1. **五元素一致性** - Process、Guideline、Rule、Constraint和Criteria之间必须保持逻辑一致
2. **Process流程图形化** - 流程部分必须包含至少一个图形化表达
3. **Rule明确强制性** - 规则必须使用明确的、不含模糊表述的语言
4. **Constraint客观性** - 约束必须反映客观存在的限制，而非主观设定
5. **Criteria可度量性** - 评价标准必须可度量，包含明确的指标和目标值
6. **异常路径完备性** - 流程必须包含正常路径和异常处理路径
7. **层次结构清晰** - 各元素内部应保持合理的层次结构，避免平铺直叙
</rule>
<constraint>
1. **元素复杂度限制** - 单个元素内容不宜过于复杂，保持认知负荷合理
2. **流程步骤限制** - 主流程步骤建议控制在7±2个，符合人类短期记忆容量
3. **表达方式限制** - 表达方式受目标环境支持的格式限制
4. **执行环境限制** - 必须考虑实际执行环境的能力边界
5. **集成兼容性限制** - 执行模式必须能与其他协议(思考、记忆等)协同工作
</constraint>
<criteria>
| 指标 | 通过标准 | 不通过标准 |
|------|---------|-----------|
| 流程清晰度 | 执行路径明确无歧义 | 步骤混乱或缺失关键节点 |
| 规则明确性 | 规则表述精确可执行 | 规则模糊或自相矛盾 |
| 约束合理性 | 约束反映客观限制 | 约束不合理或过度限制 |
| 标准可度量性 | 标准包含具体可测量指标 | 标准笼统难以评估 |
| 结构完整性 | 五大元素协调一致 | 元素间逻辑矛盾或重大缺失 |
| 异常处理 | 包含完善的异常处理路径 | 缺少异常情况考虑 |
| 可执行性 | 能够指导实际执行 | 过于理论化难以落地 |
| 表达适当性 | 各元素使用合适的表达方式 | 表达方式与内容不匹配 |
</criteria>
</execution>

138
domain/prompt/execution/memory-best-practice.execution.md Normal file
View File

@ -0,0 +1,138 @@
<execution domain="prompt-engineering">
<process>
# 记忆模式提示词开发流程
```mermaid
flowchart TD
A[设计记忆策略] --> B[构建记忆评估机制]
B --> C[设计记忆存储流程]
C --> D[规划记忆回忆策略]
D --> E[整合验证]
E -->|验证通过| F[完成记忆模式]
E -->|需要调整| B
```
## 核心步骤详解
1. **设计记忆策略**
- 确定适合任务的记忆类型(陈述性/程序性/情景性)
- 规划记忆的生命周期管理
- 设计记忆的组织结构
2. **构建记忆评估机制**
- 设计`<evaluate:thought>`组件
- 定义价值评估标准
- 建立多维度评分机制
- 设置评估阈值
3. **设计记忆存储流程**
- 设计`<store:execution>`组件
- 确定存储格式和标记系统
- 规划存储路径和方式
- 设计存储确认反馈
4. **规划记忆回忆策略**
- 设计`<recall:thought>`组件
- 定义记忆触发条件
- 建立检索机制和优先级
- 规划记忆应用方式
5. **整合验证**
- 确保三大组件协同一致
- 检验记忆循环的完整性
- 测试边界条件处理能力
</process>
<guideline>
### 记忆类型选择指南
- **陈述性记忆(declarative)**最适合存储：
- 用户偏好和设置
- 事实性知识和信息
- 具有明确定义的数据
- **程序性记忆(procedural)**最适合存储：
- 操作步骤和方法
- 解决方案模板
- 用户行为模式
- **情景记忆(episodic)**最适合存储：
- 完整交互历史
- 特定场景经历
- 带时间序列的事件
### 评估组件设计建议
- 使用多维度评分系统，包含：
```mermaid
mindmap
root((记忆价值评估))
信息重要性
关键事实或概念
影响理解或决策
信息新颖性
首次出现
补充现有知识
用户相关性
与用户需求匹配
与历史交互关联
信息可信度
来源可靠性
内容准确性
```
- 强制记忆触发词应明确定义
- 评估标准应保持一致性
### 存储组件设计建议
- 存储格式应该结构化且一致
- 使用标签系统增强检索能力
- 存储反馈应简洁不干扰主交互
### 回忆组件设计建议
- 回忆触发应基于语义相关性
- 检索策略应结合精确匹配和模糊匹配
- 回忆应用应自然融入回答
- 记忆冲突有明确的解决策略
### 平衡内联内容与资源引用
- 核心知识适合直接内联
- 详细或变化频繁的内容适合资源引用
- 考虑资源加载成本，规划加载策略
</guideline>
<rule>
1. **角色初始化必须加载记忆** - 角色初始化时必须自动加载相关记忆文件
2. **评估-存储-回忆完整性** - 记忆模式必须包含完整的评估-存储-回忆循环
3. **实际存储强制执行** - 记忆存储必须通过实际工具调用执行，不得仅在对话中声明
4. **存储结果验证** - 必须验证存储操作是否成功，并有失败处理机制
5. **存储格式一致性** - 所有存储的记忆必须遵循统一的格式和标签系统
6. **回忆主动性** - 系统必须能在相关场景下主动检索和应用记忆，无需用户明确请求
7. **存储原子性** - 记忆存储操作必须保持原子性，避免部分成功导致的不一致
</rule>
<constraint>
1. **记忆容量限制** - 内存中可同时处理的记忆条目数量有限
2. **存储性能限制** - 存储操作不应明显延迟对话响应时间
3. **检索精度限制** - 记忆检索存在准确性与召回率的平衡难题
4. **工具调用限制** - 记忆读写依赖于系统支持的工具调用能力
5. **文件访问限制** - 记忆文件的访问可能受环境权限限制
6. **格式兼容性限制** - 记忆格式需兼容不同环境的解析能力
</constraint>
<criteria>
| 指标 | 通过标准 | 不通过标准 |
|------|---------|-----------|
| 初始化完整性 | 角色初始化时自动加载记忆 | 需用户提醒才加载记忆 |
| 存储可靠性 | 通过工具调用实际存储并验证 | 仅在对话中声明或无验证 |
| 存储格式符合性 | 遵循统一格式和标签系统 | 格式不一致或标签混乱 |
| 价值评估准确性 | 正确识别高价值信息 | 存储低价值或忽略高价值信息 |
| 回忆及时性 | 相关场景下主动检索应用 | 需用户明确提醒才回忆 |
| 回忆自然性 | 记忆自然融入回答 | 生硬引用或过度突显记忆来源 |
| 记忆一致性 | 不同会话中记忆表现一致 | 记忆应用不一致或丢失 |
| 循环完整性 | 评估-存储-回忆循环完整 | 循环断裂或缺少关键环节 |
</criteria>
</execution>

160
domain/prompt/execution/resource-best-practice.execution.md Normal file
View File

@ -0,0 +1,160 @@
<execution domain="prompt-engineering">
<process>
# 资源模式提示词开发流程
```mermaid
flowchart TD
A[明确资源需求] --> B[设计资源路径结构]
B --> C[定义查询参数]
C --> D[建立资源注册表]
D --> E[验证资源协议]
E -->|通过| F[完成资源定义]
E -->|不通过| G[调整修正]
G --> B
```
## 核心步骤详解
1. **明确资源需求**
- 确定资源类型和用途
- 定义资源的生命周期和作用域
- 规划资源的访问模式
2. **设计资源路径结构**
- 使用`<location>`标签定义路径规则
- 通过EBNF形式描述路径结构
- 提供清晰的路径示例
3. **定义查询参数**
- 使用`<params>`标签定义参数
- 明确参数名称、类型和作用
- 设计参数组合规则和优先级
4. **建立资源注册表**
- 使用`<registry>`标签建立映射
- 将抽象ID映射到具体资源路径
- 确保映射关系清晰且无冲突
5. **验证资源协议**
- 测试资源引用的解析正确性
- 验证资源加载语义（@、@!、@?）
- 检查嵌套引用和查询参数功能
</process>
<guideline>
### 资源路径设计指南
- **简洁明确**：路径应当简洁但足够明确，避免歧义
```
@file://documents/report.md ✓
@file://docs/some-stuff/thing.md ✗
```
- **分层结构**：使用层级结构组织资源，增强可读性
```
@file://project/src/components/button.js ✓
@file://project_src_components_button.js ✗
```
- **命名规范**：使用一致的命名规则
```
@file://images/logo.png ✓
@file://Images/LOGO.png ✗
```
- **通配符合理使用**：
```
@file://src/**/*.js ✓ (递归查找所有JS文件)
@file://**/* ✗ (过于宽泛)
```
### 查询参数设计指南
- **参数命名**：使用描述性名称，遵循常见约定
```
?format=json ✓
?f=j ✗
```
- **参数分组**：相关参数应使用一致的前缀
```
?filter.type=user&filter.status=active ✓
?filter_type=user&status_filter=active ✗
```
- **默认值处理**：明确指定参数的默认行为
```
在<params>中说明: "format默认为'text'" ✓
不指定默认值 ✗
```
### 注册表设计指南
- **ID命名**：使用有意义的ID，体现资源内容
```
analytical (用于分析型思维) ✓
thought1, thought2 ✗
```
- **路径模板**：对于相似资源，使用一致的路径模板
```
@file://PromptX/domain/{domain}/{resource}.{type}.md ✓
混合不同路径风格 ✗
```
- **分类组织**：按功能或领域对注册表条目分组
```
<!-- 基础思维模式 -->
| analytical | ... |
| creative | ... |
<!-- 专业领域思维模式 -->
| medical | ... |
```
### 资源引用指南
- **加载语义选择**：
- `@`：一般资源，非关键，可延迟加载
- `@!`：关键资源，必须立即加载
- `@?`：大型资源，仅在需要时加载
- **嵌套引用建议**：
- 简单情况使用简写形式：`@execution:file://path.md`
- 复杂情况使用完整形式：`@execution:@file://path.md`
- 多重嵌套不超过3层：`@outer:middle:inner://path`
</guideline>
<rule>
1. **路径格式一致性** - 资源路径必须遵循EBNF中定义的语法规则
2. **三要素完整性** - 自定义协议必须包含location、params和registry三个核心组件
3. **加载语义明确性** - 资源引用必须明确其加载语义（@、@!、@?）的使用场景
4. **查询参数规范化** - 参数名称和值格式必须明确规范
5. **注册表唯一性** - 注册表中的ID必须唯一，不允许重复
6. **资源获取主动性** - AI必须主动使用工具调用获取资源，特别是@!前缀的资源
7. **路径解析完整性** - 必须正确处理嵌套引用，从内向外解析
8. **资源验证必要性** - 必须验证资源是否成功加载，并妥善处理加载失败情况
</rule>
<constraint>
1. **路径长度限制** - 资源路径不应过长，建议不超过255字符
2. **嵌套深度限制** - 嵌套引用不应超过3层，以保持可读性
3. **查询参数复杂度限制** - 单个资源引用的查询参数不宜过多
4. **注册表大小限制** - 单个注册表条目数量应控制在可管理范围内
5. **资源访问权限限制** - 需考虑环境对资源访问的权限限制
6. **解析环境限制** - 资源路径和参数需考虑在不同解析环境中的兼容性
</constraint>
<criteria>
| 指标 | 通过标准 | 不通过标准 |
|------|---------|-----------|
| 路径清晰度 | 路径结构直观易懂 | 路径结构混乱或难以理解 |
| 参数设计合理性 | 参数命名明确，功能清晰 | 参数命名模糊，功能重叠 |
| 注册表组织性 | 注册表条目分类合理，ID有意义 | 注册表混乱，ID无意义 |
| 加载语义正确性 | 正确使用@、@!、@?前缀 | 加载语义使用不当 |
| 嵌套引用可读性 | 嵌套结构清晰，不过度复杂 | 嵌套过深或结构混乱 |
| 资源获取可靠性 | 资源加载有验证和错误处理 | 缺少验证或错误处理 |
| 通配符使用合理性 | 通配符模式精确且高效 | 过于宽泛或低效的模式 |
| 整体一致性 | 资源协议设计风格统一 | 设计风格不一致或混乱 |
</criteria>
</execution>

185
domain/prompt/execution/role-best-practice.execution.md Normal file
View File

@ -0,0 +1,185 @@
<execution domain="prompt-engineering">
<process>
# 角色合成提示词开发流程
```mermaid
flowchart TD
A[确定角色类型与目标] --> B[设计角色人格]
B --> C[定义角色原则]
C --> D[构建角色知识]
D --> E[设计角色经验]
E --> F[规划角色激活]
F --> G[整合验证]
G --> H{角色验证}
H -->|通过| I[完成角色定义]
H -->|需调整| J[修改优化]
J --> B
```
## 核心步骤详解
1. **确定角色类型与目标**
- 明确角色的主要职责和应用场景
- 选择适合的角色类型（顾问型/执行型/决策型/创造型）
- 设定角色能力范围和限制
2. **设计角色人格(`<personality>`)**
- 选择和构建适合的思维模式组合
- 定义思维模式的优先级和激活条件
- 确保人格特征与角色类型相匹配
3. **定义角色原则(`<principle>`)**
- 构建角色的行为准则和执行框架
- 设定行为模式的优先级和触发条件
- 确保原则与人格定义协调一致
4. **构建角色知识(`<knowledge>`)**
- 设计角色的预设知识库结构
- 整合领域专业知识和通用知识
- 建立知识的层次关系和索引系统
5. **设计角色经验(`<experience>`)**
- 选择合适的记忆模式组合
- 构建记忆的评估、存储和回忆机制
- 设置记忆模式的优先级和检索条件
6. **规划角色激活(`<action>`)**
- 设计角色的初始化序列
- 定义资源加载的优先级顺序
- 构建稳健的启动确认机制
</process>
<guideline>
### 角色类型选择指南
- **顾问型角色(Advisor)**适合场景：
- 需要多角度分析和建议
- 用户需要决策支持而非直接执行
- 涉及复杂或模糊问题的解析
```mermaid
mindmap
root((顾问型角色))
思维特点
多角度思考
批判性分析
表达方式
提供选项
平衡利弊
知识结构
领域全面性
原则性知识
```
- **执行型角色(Executor)**适合场景：
- 需要明确的操作步骤和流程
- 任务目标明确，需精确执行
- 重视效率和一致性
```mermaid
mindmap
root((执行型角色))
思维特点
逻辑性思考
结构化分析
表达方式
步骤分解
明确指令
知识结构
操作性知识
程序性记忆
```
- **决策型角色(Decider)**适合场景：
- 需要根据标准做出判断
- 在多种选择中确定最佳方案
- 需要权威性的结论
```mermaid
mindmap
root((决策型角色))
思维特点
批判性思考
权衡分析
表达方式
结论先行
判断明确
知识结构
评估标准
判断框架
```
- **创造型角色(Creator)**适合场景：
- 需要创新思维和新颖视角
- 重视独特性和灵感激发
- 解决开放性问题
```mermaid
mindmap
root((创造型角色))
思维特点
发散思维
联想能力
表达方式
生动形象
启发性表达
知识结构
跨领域关联
启发性资源
```
### 角色组件设计建议
- **人格(personality)组件**：
- 使用思维导图展示思维特点和关系
- 明确主导思维模式和辅助思维模式
- 设置适当的思维模式切换触发条件
- **原则(principle)组件**：
- 使用流程图展示核心执行流程
- 以列表形式呈现行为规则和指导原则
- 确保原则间的优先级清晰
- **知识(knowledge)组件**：
- 采用树状结构组织领域知识
- 区分核心知识和扩展知识
- 平衡内联知识和资源引用
- **经验(experience)组件**：
- 明确定义记忆的评估标准
- 建立一致的存储格式和标签系统
- 设计高效的检索机制和应用策略
- **激活(action)组件**：
- 使用流程图展示初始化序列
- 明确资源依赖关系和加载顺序
- 包含必要的状态检查和错误处理
</guideline>
<rule>
1. **角色完整性** - 角色定义必须包含personality、principle和action三个核心组件
2. **组件一致性** - 各组件定义的内容必须相互协调，避免矛盾或冲突
3. **思维边界清晰** - 角色的思维模式必须有明确的边界，避免角色行为不一致
4. **行为规范明确** - 角色的行为原则和规范必须明确定义，不包含模糊表述
5. **激活流程完整** - 角色激活组件必须包含完整的初始化流程和资源加载顺序
6. **资源依赖明确** - 所有外部资源依赖必须明确标注，包括加载时机和路径
7. **角色边界严格** - 角色能力范围和限制必须明确，避免能力范围模糊或过度承诺
</rule>
<constraint>
1. **组件复杂度限制** - 单个组件的复杂度应控制在可管理范围内
2. **资源依赖数量限制** - 角色直接依赖的外部资源数量应适当控制
3. **知识库大小限制** - 内联知识库大小应控制在可高效加载的范围内
4. **角色专注度限制** - 角色定义应保持适度的专注度，避免能力过于发散
5. **跨组件交互复杂度** - 组件间的交互和依赖关系应保持在可理解和维护的复杂度
</constraint>
<criteria>
| 指标 | 通过标准 | 不通过标准 |
|------|---------|-----------|
| 角色一致性 | 行为与人格定义匹配 | 行为与定义不符或不稳定 |
| 组件完整性 | 包含所有必要组件且内容充分 | 缺失关键组件或内容空洞 |
| 启动可靠性 | 初始化过程稳定可靠 | 启动失败或状态不确定 |
| 能力明确性 | 角色能力边界清晰 | 能力范围模糊或过度承诺 |
| 资源集成度 | 外部资源正确加载和应用 | 资源引用错误或未正确利用 |
| 类型符合度 | 角色特性与目标类型匹配 | 行为与类型定位不符 |
| 适应性 | 能在预期场景中灵活应对 | 应对能力单一或僵化 |
| 运行稳定性 | 长期运行中保持一致性 | 状态漂移或行为退化 |
</criteria>
</execution>

111
domain/prompt/execution/thought-best-practice.execution.md Normal file
View File

@ -0,0 +1,111 @@
<execution domain="prompt-engineering">
<process>
# 思考模式提示词开发流程
```mermaid
flowchart TD
A[分析思考需求] --> B[确定所需思维模式]
B --> C{选择适当组件}
C -->|探索性思维| D[使用exploration标签]
C -->|推理性思维| E[使用reasoning标签]
C -->|规划性思维| F[使用plan标签]
C -->|批判性思维| G[使用challenge标签]
D --> H[设计思维导图表达]
E --> I[设计推理图表达]
F --> J[设计流程图表达]
G --> K[设计逆向思维导图]
H --> L[组装完整思考模式]
I --> L
J --> L
K --> L
L --> M[优化表达方式]
M --> N[验证思考逻辑]
N --> O[完成thought组件]
```
## 核心步骤详解
1. **分析思考需求**
- 明确需要解决的问题类型
- 确定所需的思考深度和广度
2. **选择适当组件**
- 根据任务性质选择合适的思维模式组件
- 不必强制使用全部四种组件，应按需选择
3. **设计图形表达**
- 为每种思维模式选择最适合的图形表达方式
- 确保图形能够清晰展示思考逻辑和结构
4. **验证思考逻辑**
- 检查思维流程是否完整
- 确保不同思维模式之间的连贯性
</process>
<guideline>
### 图形化表达原则
- 使用图形作为主要表达方式，辅以简洁文字说明
- 选择最适合特定思维模式的图表类型
- 保持图表简洁明了，避免过度复杂
- 确保图表能够独立表达核心思想
### 思维模式图表选择建议
- **探索性思维(exploration)**
- 优先使用思维导图(mindmap)
- 适用于概念发散、头脑风暴
- 核心问题置于中心，向外扩展可能性
- **推理性思维(reasoning)**
- 优先使用流程图(graph/flowchart)或时间线
- 适用于逻辑推导、因果分析
- 清晰展示前提到结论的推理路径
- **规划性思维(plan)**
- 优先使用甘特图(gantt)、流程图或序列图
- 适用于项目规划、决策路径
- 展示步骤间的依赖关系和时间顺序
- **批判性思维(challenge)**
- 优先使用逆向思维导图或四象限图
- 适用于风险探索、假设检验
- 聚焦于方案的潜在问题和限制条件
### 混合使用建议
- 复杂问题可组合多种思维模式，按照"探索-批判-推理-计划"的顺序
- 各思维模式间应有明确的逻辑承接关系
- 保持风格一致性，便于整体理解
</guideline>
<rule>
1. **思考组件必须图形化** - 每种思维模式必须至少包含一个图形化表达
2. **图表必须符合语义** - 使用的图表类型必须与思维模式的语义匹配
3. **文字必须精简** - 文字说明应简洁，仅用于补充图表无法表达的内容
4. **思维模式边界明确** - 不同思维模式之间的职责边界必须清晰
5. **可执行性保证** - 思考模式必须能够指导AI进行实际的思考过程
6. **一致的表达风格** - 在同一个thought标签内保持一致的表达风格
7. **思维全面性** - 确保覆盖关键思考维度，避免重要思考角度的遗漏
</rule>
<constraint>
1. **图表复杂度限制** - 单个图表节点和连接数量应控制在可理解范围内
2. **表达深度限制** - 思维展开不宜超过三层，以保持清晰度
3. **AI理解能力限制** - 图表必须是AI能够理解的标准格式
4. **渲染环境限制** - 考虑不同环境下图表渲染的兼容性
5. **语言限制** - 图表中的文字应简洁明了，避免长句
</constraint>
<criteria>
| 指标 | 通过标准 | 不通过标准 |
|------|---------|-----------|
| 图形表达清晰度 | 图表能独立表达核心思想 | 图表混乱或需大量文字解释 |
| 思维模式匹配度 | 图表类型与思维模式匹配 | 图表类型与思维目的不符 |
| 结构完整性 | 思考逻辑路径完整 | 思考路径有明显断点或跳跃 |
| 表达简洁性 | 简明扼要，无冗余元素 | 过于复杂或重复表达 |
| 实用指导性 | 能有效指导实际思考 | 过于抽象，难以应用 |
| 思维覆盖面 | 覆盖问题的关键维度 | 遗漏重要思考角度 |
| 视觉组织性 | 视觉层次清晰，重点突出 | 平面化设计，难以区分重点 |
</criteria>
</execution>