qualitative-assessment

# 系统定性评估技能 **核心原则**：客观、如实、深刻、尖锐，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` → 项目层面问题、重构方案 ```bash 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：收集分析结果 ```bash 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` ## 执行方式 ```bash # 作为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字内