123 lines
5.8 KiB
Markdown
123 lines
5.8 KiB
Markdown
<execution domain="role-design-quality">
|
||
<constraint>
|
||
## 设计质量约束
|
||
|
||
### DPML协议约束
|
||
- **语法完整性**：所有DPML标签必须正确闭合，属性格式规范
|
||
- **引用有效性**：@引用路径必须指向存在的有效资源
|
||
- **嵌套限制**：标签嵌套深度不得超过5层，保持可读性
|
||
|
||
### 角色功能约束
|
||
- **能力边界**：角色功能必须与其定位明确匹配，不得越界
|
||
- **专业深度**：每个角色必须专注特定领域，避免过度泛化
|
||
- **一致性保证**：personality与principle必须逻辑一致
|
||
|
||
### 用户体验约束
|
||
- **学习成本**：用户学习使用角色的时间不得超过30分钟
|
||
- **认知负荷**：角色复杂度必须控制在用户可理解范围内
|
||
- **响应性能**：角色响应时间不得超过3秒
|
||
</constraint>
|
||
|
||
<rule>
|
||
## 质量控制强制规则
|
||
|
||
### 代码质量规则
|
||
1. **DPML语法检查**：所有角色定义必须通过语法验证器检查
|
||
2. **引用完整性检查**：所有@引用必须在发布前验证其有效性
|
||
3. **组件依赖验证**：必须确保所有依赖组件存在且可访问
|
||
4. **版本兼容性验证**：新角色不得破坏现有系统兼容性
|
||
|
||
### 设计标准规则
|
||
1. **思维模式图形化**：thought组件必须包含至少一个图形化表达
|
||
2. **执行框架完整性**：execution组件必须包含五要素中的至少三个
|
||
3. **文档完备性**：每个角色必须提供完整的使用文档和示例
|
||
4. **测试验证要求**：角色发布前必须经过功能和性能测试
|
||
|
||
### 专业性规则
|
||
1. **领域知识准确性**：角色涉及的专业知识必须准确无误
|
||
2. **实用性验证**：角色必须能解决实际问题，创造真实价值
|
||
3. **差异化定位**：新角色必须与existing角色有明确差异化
|
||
</rule>
|
||
|
||
<guideline>
|
||
## 质量控制建议
|
||
|
||
### 设计阶段建议
|
||
- **需求调研充分**：建议深入了解目标用户的真实需求
|
||
- **原型快速验证**：推荐先创建简化版本进行快速验证
|
||
- **迭代式改进**：建议采用小步快跑的迭代改进策略
|
||
- **用户反馈驱动**：推荐在设计过程中持续收集用户反馈
|
||
|
||
### 实现阶段建议
|
||
- **组件复用优先**：建议优先使用existing组件，避免重复开发
|
||
- **模块化设计**：推荐将复杂功能拆分为独立的可复用模块
|
||
- **渐进式交付**：建议先实现核心功能，再逐步扩展高级特性
|
||
- **错误处理完善**：推荐为所有可能的错误情况设计处理机制
|
||
|
||
### 测试阶段建议
|
||
- **多场景测试**：建议在不同使用场景下全面测试角色功能
|
||
- **性能压力测试**：推荐测试角色在高负载下的性能表现
|
||
- **兼容性测试**：建议测试与其他角色和系统组件的兼容性
|
||
- **用户验收测试**：推荐邀请目标用户进行实际使用测试
|
||
</guideline>
|
||
|
||
<process>
|
||
## 质量控制流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[设计完成] --> B[代码质量检查]
|
||
B --> C{语法检查通过?}
|
||
C -->|否| D[修正语法错误]
|
||
D --> B
|
||
C -->|是| E[功能完整性检查]
|
||
E --> F{功能完整?}
|
||
F -->|否| G[补充缺失功能]
|
||
G --> E
|
||
F -->|是| H[专业性验证]
|
||
H --> I{专业知识准确?}
|
||
I -->|否| J[修正专业内容]
|
||
J --> H
|
||
I -->|是| K[用户体验测试]
|
||
K --> L{用户体验达标?}
|
||
L -->|否| M[优化用户体验]
|
||
M --> K
|
||
L -->|是| N[性能测试]
|
||
N --> O{性能达标?}
|
||
O -->|否| P[性能优化]
|
||
P --> N
|
||
O -->|是| Q[兼容性测试]
|
||
Q --> R{兼容性通过?}
|
||
R -->|否| S[解决兼容性问题]
|
||
S --> Q
|
||
R -->|是| T[质量验收通过]
|
||
```
|
||
|
||
### 检查清单执行
|
||
1. **技术质量检查**：验证DPML语法、引用完整性、组件依赖
|
||
2. **功能质量检查**：验证角色功能完整性、专业知识准确性
|
||
3. **用户体验检查**：验证学习成本、使用便利性、满意度
|
||
4. **系统集成检查**：验证与PromptX生态的兼容性和协作性
|
||
5. **性能质量检查**：验证响应时间、资源消耗、并发能力
|
||
</process>
|
||
|
||
<criteria>
|
||
## 质量评价标准
|
||
|
||
| 质量维度 | 优秀(90+) | 良好(80-89) | 合格(70-79) | 不合格(<70) |
|
||
|---------|----------|------------|------------|-------------|
|
||
| **代码质量** | 无语法错误，引用100%有效 | 轻微问题，引用基本有效 | 少量错误，引用大部分有效 | 严重错误，引用失效较多 |
|
||
| **功能完整** | 完全满足需求，边界清晰 | 基本满足需求，边界较清晰 | 部分满足需求，边界模糊 | 需求满足度低，边界不清 |
|
||
| **专业准确** | 专业知识完全准确 | 知识基本准确，少量偏差 | 知识大体正确，有缺漏 | 知识错误多，缺失严重 |
|
||
| **用户体验** | 极易使用，学习成本极低 | 易于使用，上手较快 | 可以使用，需要学习 | 难以使用，学习困难 |
|
||
| **性能表现** | 响应迅速，资源消耗低 | 性能良好，消耗合理 | 性能一般，消耗可接受 | 性能差，消耗过高 |
|
||
| **兼容集成** | 完美兼容，集成顺畅 | 兼容良好，集成较顺畅 | 基本兼容，集成可行 | 兼容性差，集成困难 |
|
||
|
||
### 最终验收标准
|
||
- **技术验收**：DPML语法正确率100%，引用有效性≥95%
|
||
- **功能验收**：需求满足度≥90%，专业知识准确性≥95%
|
||
- **体验验收**：用户满意度≥4.5/5.0，学习成本≤30分钟
|
||
- **性能验收**：响应时间≤3秒，资源消耗在合理范围内
|
||
- **生态验收**：与existing组件兼容性≥95%，无重大冲突
|
||
</criteria>
|
||
</execution> |