用途
codeprobe-code-smells 是 codeprobe-claude 项目中的一个代码坏味道与反模式检测子技能，主要用途是在代码审查、重构准备或质量评估阶段，自动识别代码中的可维护性问题和常见反模式。它以结构化方式对代码质量缺陷进行分类和报告，帮助开发者定位需要改进的代码区域。
主要能力
该技能按以下类别组织检测能力：
膨胀类（Bloaters）
- 长方法：方法体超过行数阈值（默认 > 30 LOC）
- 大类：类定义超过行数阈值（默认 > 300 LOC）
- 数据泥团：同一组 3 个以上参数在 3 处以上位置一同出现
- 基本类型偏执：用字符串或整数表示领域概念（如邮箱、金额、电话号码、状态字符串等）
面向对象滥用（Object-Orientation Abusers）
- 依恋情结：方法访问其他对象数据的次数超过自身数据 3 倍以上
- 不当亲密：类访问另一个类的私有/受保护内部成员
- 拒绝遗赠：子类继承但不使用父类大部分方法
变更阻碍（Change Preventers）
- 霰弹式修改：修改一个概念需要在 5 个以上文件中编辑
- 发散式变化：一个类因 3 个以上不相关原因被修改
冗余类（Dispensables）
- 死代码：不可达分支、未使用的导入、注释掉的代码块
- 推测性泛化：只有一个实现且无预期第二实现的抽象
- 中间人：仅委托给另一个类而无额外逻辑的类
耦合类（Couplers）
- 时间耦合：方法必须按特定顺序调用但无任何强制机制
可读性（Readability）
- 魔法数字：业务逻辑中无命名常量的硬编码字面量
- 布尔盲区：具有 2 个以上布尔参数的方法
- 深层嵌套：嵌套层级超过阈值（默认 > 3 层）
使用方式
该技能支持独立模式。若直接调用而非通过编排器，需要先执行以下步骤：
- 读取
../codeprobe/shared-preamble.md了解输出契约、执行模式与约束 - 根据项目技术栈加载
../codeprobe/references/下的适用参考文件 - 默认使用完整模式，除非用户另有指定
分析前会检查项目根目录的 .codeprobe-config.json 文件，若存在则加载 severity_overrides 部分调整默认阈值。可配置项包括：long_method_loc（长方法行数上限，默认 30）、large_class_loc（大类行数上限，默认 300）、deep_nesting_max（深层嵌套最大层级，默认 3）。
所有发现项使用 SMELL- 前缀顺序编号，如 SMELL-001、SMELL-002。每个发现项附带修复建议提示词示例，例如提取方法、替换魔法数字为命名常量、用值对象替代布尔参数、移除注释掉的死代码等。
不检测范围
该技能明确不标记以下内容：
- 生成代码：迁移文件、编译输出、vendor 目录（vendor/、node_modules/、dist/、build/、.next/）以及自动生成文件
- 测试文件中冗长的 setup 方法：测试上下文中长的 setUp() 或 beforeEach() 是预期且可接受的
- 包含大量条目的配置文件：50 个键值对的配置文件不是“大类”坏味道
- 数据迁移文件：本质上是过程式的，常包含长方法
- 签入仓库的第三方代码
- codeprobe-solid 或 codeprobe-architecture 已标记的结构性问题：本子技能仍会检测并报告，但编排器会在同一位置去重重叠发现项
适用场景
适用于代码审查前自动识别可维护性问题、重构前定位需要改进的代码区域、持续集成中作为代码质量门禁的一部分，以及团队代码规范落地时的辅助检查。
限制
各检测项有默认阈值和严重程度（Minor、Major、Suggestion 等），部分阈值可通过配置文件调整。严重程度升级规则有明确限制，例如大类问题永远不会升级为 critical，因为它是可维护性顾虑而非生产缺陷。该技能的部分检测依赖 Grep 跨项目搜索和模式识别，具体检测精度和覆盖率取决于项目代码结构与所用技术栈。关于是否收费、价格、具体平台支持范围等信息，资料中暂未提供。