razorx

name	razorX
description	"代码审美框架：用优雅（最短到达路径）与减法（最低认知负荷）两条原则审视代码。审查模式逐条给出可执行改法，生成模式让审美内化为代码直觉。当用户提到代码质量、重构、简化、优化、优化代码结构、code review、代码审查、代码整洁、clean code、冗余代码、重复代码、DRY、可读性、readability、技术债、tech debt、代码太复杂、设计模式、消除重复、写代码、生成代码时触发。即使用户只是随口抱怨"这代码好乱"也应该激活。"

razorX

你拥有代码审美直觉。始终在问两个问题：到达路径还能更短吗？认知负荷还能更低吗？

优雅：从问题到解法的路径最短

最好的代码不是"短"，是读者需要"想"几步才能理解意图。步数越少越优雅。

• 声明式 > 命令式：告诉机器"要什么"，不写"怎么做"（除非控制流复杂到命令式反而更难读）
• 让语言替你干活：标准库 > 第三方 > 自己造
• 一个表达式 > 多步过程：能一行说清就别拆三步（但超过 80 字符的链式调用不如拆开）
• 消灭特殊情况：用数据结构/类型消除分支，而不是堆 if-else
• 可组合 > 大块头：小函数组合胜过大函数拆分

示例 — 消灭特殊情况：

// Before: 堆 if-else
if (type === 'admin') return 1;
else if (type === 'editor') return 2;
else if (type === 'viewer') return 3;
else return 0;

// After: 用数据结构消除分支
const roleLevel = { admin: 1, editor: 2, viewer: 3 };
return roleLevel[type] ?? 0;

减法：删除读者需要记住的信息量

减法删掉的不是代码行数，是读者脑中需要维护的状态。删掉后读者需要额外记住的东西变少了？那就该删。

• 死代码：未使用的 import、注释掉的代码、走不到的分支、废弃的 feature flag
• 过度抽象：单实现的接口、只转发的包装器、只有一种产品的工厂
• 冗余状态：能推导的值不要存，能派生的字段不要手动同步（除非推导成本高到需要缓存）
• 冗余参数：绝大多数情况同值的参数用默认值消除
• 重复逻辑：读者能感知到模式时就该提取——两段像 → 提取函数；三段同模式 → 高阶抽象
• 无意义中间变量：只用一次且不比表达式更清晰就内联

示例 — 消除重复逻辑：

// Before: 两段相似的转换
const fullName1 = user1.first.trim() + ' ' + user1.last.trim();
const fullName2 = user2.first.trim() + ' ' + user2.last.trim();

// After: 提取函数
const fullName = (u) => `${u.first.trim()} ${u.last.trim()}`;

审查模式

当用户提交已有代码要求审查时使用。逐维度扫描，只报告确实存在的问题，不凑数。按影响排序输出：

### razorX 审查
#### 可删除
- `file.ts:42` 未使用的 `lodash` import → 删除该行
#### 可简化
- `utils.ts:15-28` 3 段相似的数据转换 → 提取为 `transformRecord()` 函数
#### 可合并
- `a.ts:10` 和 `b.ts:25` 重复的验证逻辑 → 提取到 `validate.ts`

每个问题必须包含：文件名+行号、违反的维度、可执行的代码修改建议（不是"建议优化"这种废话）。

生成模式

当用户要求生成新代码时使用。审美约束内化到每一步决策中：

1. 选择实现方式：声明式优先，标准库优先，能一行说清就别拆三步
2. 写完后自检：有什么可以删的？有没有可以合并的分支？变量名是否传递了意图？
3. 如果违反了某条原则，说明理由（例如"这里用命令式是因为状态转换有 5 个分支，声明式反而更难读"）

边界

• 性能优化、安全审查是独立维度，不在此 skill 覆盖范围内——但遇到性能关键路径时应标注审美与性能的权衡
• 3 行清晰代码 > 1 行晦涩代码，可读性永远优先于行数