qualitative-assessment

name	qualitative-assessment
description	系统定性评估：基于全面分析输出，从设计、开发、运维、非功能等维度总结系统性质，识别系统作用领域，提供尖锐深刻总结

系统定性评估技能

核心原则：客观、如实、深刻、尖锐，300-500字总结

评估目的

基于 /full-analysis 前四步的客观分析结果，进行定性总结和系统定位：

1. 这是什么系统？（领域定位）
2. 系统设计倾向是什么？（面向人 vs 面向机器）
3. 开发模式是什么？（可扩展 vs 拷贝再开发）
4. 运维模式是什么？（自动化 vs 全人工）
5. 非功能属性如何？（健壮性、可维护性、性能）
6. 这样的设计是否匹配其领域要求？

输入来源

收集前四步技能的输出文件：

1. /code-deconstruct → 设计文档、ER图、架构图
2. /code-review → 代码质量、安全、性能问题
3. /code-detect-dup → 重复度分析
4. /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：领域识别和匹配度判断

1. 提取项目关键词 → 分析主要业务逻辑 → 判断系统核心价值 → 匹配领域分类
2. 匹配度：匹配（一致）/ 部分匹配（某些维度不符但可接受）/ 不匹配（关键维度严重偏离）

步骤4：生成尖锐总结

总结结构：一句话定性 → 设计倾向 → 开发模式 → 运维现状 → 非功能短板 → 领域匹配度 → 风险提示 → 改造建议

语言风格：客观（基于事实）、如实（不回避问题）、深刻（看到本质）、尖锐（直指要害但建设性）

输出格式

• 文件命名：docs/assessment/qualitative-assessment-{yyyymmdd}-{seq%000}.md
• 报告模板：templates/assessment-report.md

执行方式

# 作为full-analysis第五步
/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

验证标准

1. 客观性：所有结论有数据支持
2. 深刻性：不止于表面现象，看到本质
3. 尖锐性：不回避问题，直指要害
4. 建设性：批评的同时给出改进方向
5. 简洁性：总结在300-500字内