| name | qualitative-assessment |
| description | 系统定性评估:基于全面分析输出,从设计、开发、运维、非功能等维度总结系统性质,识别系统作用领域,提供尖锐深刻总结 |
系统定性评估技能
核心原则:客观、如实、深刻、尖锐,300-500字总结
评估目的
基于 /full-analysis 前四步的客观分析结果,进行定性总结和系统定位:
- 这是什么系统?(领域定位)
- 系统设计倾向是什么?(面向人 vs 面向机器)
- 开发模式是什么?(可扩展 vs 拷贝再开发)
- 运维模式是什么?(自动化 vs 全人工)
- 非功能属性如何?(健壮性、可维护性、性能)
- 这样的设计是否匹配其领域要求?
输入来源
收集前四步技能的输出文件:
/code-deconstruct → 设计文档、ER图、架构图
/code-review → 代码质量、安全、性能问题
/code-detect-dup → 重复度分析
/code-detect-problem → 项目层面问题、重构方案
find docs/ -name "*.md" -type f | grep -E "(deconstruct|review|dup|problem)" | sort -r | head -10
评估维度
1. 设计维度:面向人 vs 面向机器
| 特征 | 面向人 | 面向机器 |
|---|
| 交互方式 | GUI/CLI交互 | API/消息队列 |
| 错误处理 | 友好提示 | 错误码/日志 |
| 配置管理 | 配置文件/界面 | 环境变量/启动参数 |
| 日志输出 | 人类可读 | 结构化/机器可解析 |
2. 开发维度:可扩展 vs 拷贝再开发
| 特征 | 可扩展设计 | 拷贝再开发 |
|---|
| 架构模式 | 模块化、插件化 | 单体、紧耦合 |
| 代码复用 | 抽象接口、继承 | 复制粘贴 |
| 配置方式 | 配置驱动 | 硬编码 |
| 依赖管理 | 依赖注入 | 直接实例化 |
3. 运维维度:自动化 vs 全人工
| 特征 | 自动化运维 | 全人工运维 |
|---|
| 部署 | CI/CD流水线 | 手动拷贝文件 |
| 监控 | 指标收集、告警 | 人工检查日志 |
| 故障恢复 | 自动重启/切换 | 人工干预 |
| 配置更新 | 配置中心推送 | 手动修改文件 |
4. 非功能属性
| 属性 | 评估要点 | 标准 |
|---|
| 健壮性 | 错误处理、异常恢复、边界条件 | 防御性编程、降级策略 |
| 可维护性 | 代码结构、文档、测试覆盖 | 模块清晰度、注释质量、测试完整性 |
| 性能 | 响应时间、资源使用、扩展性 | 算法复杂度、缓存策略、并发处理 |
5. 领域匹配度
| 系统类型 | 允许宽松度 | 必须严格的要求 |
|---|
| 纯小工具 | 面向人、拷贝再开发、全人工 | 功能正确即可 |
| 管理类(ERP/OA/录单) | 弱化性能、简化设计 | 数据一致性、业务流程正确 |
| 普通报价(外贸/电商) | 中等 | 计算准确性、业务逻辑正确 |
| 金融报价(股票/期货/外汇) | 极低 | 高性能、零差错、强实时性、强一致性 |
| 量化交易 | 极低 | 高性能、零差错、强健壮性、风控完备 |
| 基础设施(数据库/中间件) | 极低 | 高可用、强一致、可扩展 |
领域识别线索:业务术语→业务系统,金融术语→金融系统,技术术语→基础设施,工具术语→工具类
注意:金融报价系统等同于量化交易,要求极严格;普通报价系统(外贸/电商)属业务系统,中等严格度即可。
评估流程
步骤1:收集分析结果
review_file=$(find docs/review -name "code-review-*.md" | sort -r | head -1)
deconstruct_file=$(find docs/deconstruct -name "deconstruct-*.md" | sort -r | head -1)
dup_file=$(find docs/dup -name "dup-*.md" | sort -r | head -1)
problem_file=$(find docs/problem -name "problem-*.md" | sort -r | head -1)
步骤2:维度评分(1-5分)
| 维度 | 5分 | 3分 | 1分 |
|---|
| 设计 | 完全面向机器,结构化API,完善错误码 | 混合设计,既有API也有界面 | 完全面向人,无机器接口 |
| 开发 | 高度可扩展,完整插件体系 | 部分模块化,部分硬编码 | 完全拷贝再开发,高度重复 |
| 运维 | 全自动化,完整CI/CD/监控 | 半自动化,关键步骤自动化 | 全人工,无自动化 |
非功能属性分别评分:健壮性、可维护性、性能。
步骤3:领域识别和匹配度判断
- 提取项目关键词 → 分析主要业务逻辑 → 判断系统核心价值 → 匹配领域分类
- 匹配度:匹配(一致)/ 部分匹配(某些维度不符但可接受)/ 不匹配(关键维度严重偏离)
步骤4:生成尖锐总结
总结结构:一句话定性 → 设计倾向 → 开发模式 → 运维现状 → 非功能短板 → 领域匹配度 → 风险提示 → 改造建议
语言风格:客观(基于事实)、如实(不回避问题)、深刻(看到本质)、尖锐(直指要害但建设性)
输出格式
- 文件命名:
docs/assessment/qualitative-assessment-{yyyymmdd}-{seq%000}.md
- 报告模板:
templates/assessment-report.md
执行方式
/long-term-task 连续执行下列任务
1. skill /code-deconstruct
2. skill /code-review
3. skill /code-detect-dup
4. skill /code-detect-problem
5. skill /qualitative-assessment
/qualitative-assessment
验证标准
- 客观性:所有结论有数据支持
- 深刻性:不止于表面现象,看到本质
- 尖锐性:不回避问题,直指要害
- 建设性:批评的同时给出改进方向
- 简洁性:总结在300-500字内