核心用法
code-quality-principles 是一个面向软件设计的代码质量指导技能，核心聚焦三大经典原则体系：
KISS（保持简单）：主张"能用简单方案就不用聪明方案"，提供显式代码优先于隐式魔法、直接解法优先于过度抽象层等具体准则，附带 Python/Rust 正反例对比。
YAGNI（你不会需要它）：强调"解决当前问题，不为假设的未来编码"，指导开发者在第3个用例出现前避免提前抽象，宁可重复也不要错误的抽象。
SOLID 五原则：
- SRP（单一职责）：一个类只应有一个变更理由
- OCP（开闭原则）：对扩展开放、对修改关闭
- LSP（里氏替换）：子类型必须能替换基类型
- ISP（接口隔离）：客户端不应依赖不需要的方法
- DIP（依赖倒置）：依赖抽象而非具体实现
每项原则均配有 Python/TypeScript/Rust 等语言的实际代码示例，以及"检查清单"和"冲突时的优先级"决策指南（如 KISS 与 SOLID 冲突时，小项目优先 KISS）。
显著优点
- 实战导向：不是纯理论罗列，每个原则都有"何时用/何时不用"场景判定和具体代码对比
- 语言覆盖广：Python、TypeScript、Rust 示例降低多技术栈团队的认知门槛
- 决策框架完整：提供原则冲突时的解决策略和 Code Review 检查清单，可直接纳入团队流程
- 可量化验证：给出
wc -l统计行数、rg -c统计类数量等具体工具命令
潜在局限
- 不适用于脚本场景：明确排除一次性脚本、数据迁移任务等"用完即弃"代码
- 性能敏感场景受限：承认在性能关键路径上可能需要牺牲可读性，本技能未提供性能权衡的具体指导
- 缺乏自动化检测：依赖人工 Code Review，无集成静态分析工具（如复杂度扫描、依赖注入检查）的自动化方案
- 主观判断依赖：KISS 的"简单"标准、YAGNI 的"第3个用例"判定仍需开发者经验
适合人群
- 初中级开发者建立代码质量意识
- 技术负责人制定团队代码规范
- 进行重构或代码审查的工程师
- 从"能跑就行"转向"工程化"阶段的团队
常规风险
- 教条主义风险：新手可能机械套用原则导致过度拆分（如 SR 极端化产生"类爆炸"）
- 上下文误判：在 MVP 阶段过早引入 SOLID 抽象反而增加复杂度
- 团队协作摩擦：原则理解不一致可能导致 Review 争议，需配合团队共识文档使用