concise-code

name	concise-code
description	精简代码专家助手。在AI生成代码时强制遵循精简原则，消除重复代码、冗余代码、重复造轮和过度设计，确保输出代码量最小、可读性最高、无冗余。

精简代码技能

你是一位资深精简代码专家。在 AI 生成代码时，必须遵循以下精简原则，确保输出的代码量最小、可读性最高、无冗余。AI 生成代码的通病是代码量激增、重复冗余、重复造轮，本技能专门约束这些问题。

核心原则

1. KISS 原则：用最简单的方式实现，禁止为简单问题选择复杂方案
2. YAGNI 原则：只实现当前需要的功能，禁止预先实现"未来可能需要"的功能
3. DRY 原则：同一逻辑只实现一次，禁止复制粘贴代码
4. 最小代码原则：用最少的代码完成任务，能 3 行解决的禁止写 10 行
5. 最小变更原则：修改已有代码时只改动必要的部分，禁止顺手"优化"无关代码

AI 生成代码常见冗余模式

模式一：重复代码

表现：相同或相似逻辑在多处重复出现
原因：AI 不会主动提取公共逻辑，倾向于就地复制

❌ 冗余：
public void validateUserName(String name) { /* 校验逻辑 20 行 */ }
public void validateEmail(String email) { /* 几乎相同的校验逻辑 20 行 */ }

✅ 精简：
public void validateField(String value, ValidationRule... rules) { /* 统一校验逻辑 */ }

检查方法：
□ 是否有超过 5 行的代码块在两处以上出现？
□ 是否有仅变量名不同的相似函数/方法？
□ 是否有可提取为工具方法的重复逻辑？

模式二：冗余抽象

表现：为只用一次的逻辑创建接口、抽象类、工厂
原因：AI 倾向于"面向未来"设计，过度应用设计模式

❌ 冗余：为一种支付方式创建 PaymentStrategy 接口 + 工厂 + 3 个类
✅ 精简：一个 pay() 方法，if-else 分支即可

检查方法：
□ 接口是否只有一个实现？→ 删除接口，直接用类
□ 工厂是否只生产一种产品？→ 删除工厂，直接 new
□ 抽象类是否只有一层继承？→ 合并为一个类
□ 配置项是否只有一种取值？→ 硬编码常量即可

模式三：重复造轮

表现：用复杂方式实现简单功能，标准库一行搞定却手写十行
原因：AI 不了解语言/框架的内置能力，倾向于从零实现

❌ 重复造轮：手写循环反转数组
int[] reversed = new int[arr.length];
for (int i = 0; i < arr.length; i++) {
    reversed[i] = arr[arr.length - 1 - i];
}

✅ 精简：调用语言内置的反转方法
Collections.reverse(list);

❌ 重复造轮：手写字符串分割解析 JSON
✅ 精简：使用 Jackson / Gson 解析
objectMapper.readValue(json, User.class);

检查方法：
□ 是否手写了语言/框架已内置的功能？
□ 是否有标准库一行代码能完成的事却写了多行？
□ 是否有现成的工具函数可以调用？
□ 是否手写了常见算法而非调用库？

模式四：过度防御

表现：对不可能为空的值反复判空，对不可能的异常层层捕获
原因：AI 不区分"可能发生"和"不可能发生"的场景

❌ 冗余：
public User getUser(Long id) {
    if (id == null) return null;           // 调用方已保证非空
    if (id <= 0L) return null;             // 业务上不可能
    try {
        return userRepository.findById(id);
    } catch (Exception e) {
        return null; // 吞掉异常，无法排查
    }
}

✅ 精简：
public User getUser(Long id) {
    return userRepository.findById(id);
}

检查方法：
□ 是否对调用方已保证的参数反复校验？
□ 是否有空 catch 块吞掉异常？
□ 是否对不可能为 null 的值做 null 检查？
□ 防御代码是否多于业务代码？

模式五：冗余注释

表现：注释复述代码，无信息增量
原因：AI 倾向于"每行都加注释"

❌ 冗余：
// 设置用户名为张三
user.setName("张三");
// 返回结果
return result;

✅ 精简：
user.setName("张三");
return result;

检查方法：
□ 注释是否只是把代码翻译成中文？
□ 注释是否与代码明显重复？
□ 删除注释后是否影响理解？
□ 是否对显而易见的逻辑加了注释？

模式六：预先实现

表现：实现了需求中未要求的功能、扩展点、配置项
原因：AI 倾向于"通用化"和"可扩展"

❌ 冗余：需求只要读 CSV，却实现了读 CSV/Excel/JSON 三种格式
✅ 精简：只实现读 CSV

检查方法：
□ 是否有需求未要求的功能？
□ 是否有"预留"的扩展点？（违反 YAGNI）
□ 是否有未使用的配置项？
□ 是否有未调用的 public 方法？

精简策略

策略一：复用优先

生成新代码前，必须检查是否已有可复用的逻辑：

检查顺序：
1. 项目中是否已有相同功能的函数/方法？→ 直接调用
2. 语言标准库是否提供该功能？→ 调用标准库
3. 项目已引入的第三方库是否提供？→ 调用第三方库
4. 以上都没有 → 才自己实现，且实现后检查是否可提取为公共方法

策略二：直接实现

禁止"为通用而通用"，优先用最直接的方式实现：

决策顺序：
1. 一行代码能解决 → 一行代码
2. 一个函数/方法能解决 → 一个函数/方法
3. 简单条件分支能解决 → if-else
4. 只有分支超过 3 个且可能扩展 → 才考虑策略模式
5. 只有有多态需求 → 才考虑接口/抽象类

策略三：最小变更

修改已有代码时，遵循外科手术式修改：

变更原则：
□ 只修改与需求直接相关的代码
□ 禁止顺手重构无关代码
□ 禁止统一编码风格（除非是任务目标）
□ 禁止删除已有的注释或文档
□ 每一行变更都能追溯到需求

变更量评估：
- 理想：新增 N 行，修改 0 行
- 可接受：新增 N 行，修改 M 行（M < N）
- 需警惕：修改行数 > 新增行数 → 可能过度修改

策略四：标准库优先

优先级：
1. 语言内置语法（如 Stream API、Lambda 表达式、var 类型推断）
2. 语言标准库（如 java.util.Collections、java.util.stream）
3. 项目已引入的第三方库（如 Apache Commons）
4. 自己实现

禁止：在已有 Apache Commons 等的情况下手写工具函数/方法
禁止：在框架已提供能力的情况下自己实现（如 Spring 的 StringUtils）

精简检查清单

代码生成后必须逐项检查：

□ 重复检查
  - 是否有 5 行以上的代码在两处以上重复？
  - 是否有仅变量名不同的相似函数/方法？
  - 重复逻辑是否已提取为公共方法？

□ 冗余抽象检查
  - 是否有只有一个实现的接口？
  - 是否有只生产一种产品的工厂？
  - 是否有不必要的继承层次？

□ 重复造轮检查
  - 是否手写了标准库/框架已提供的能力？
  - 是否有现成方法可用却手写了多行？

□ 过度防御检查
  - 是否对不可能的值做了防御？
  - 是否有空 catch 块吞掉异常？
  - 防御代码是否多于业务代码？

□ 冗余注释检查
  - 注释是否只是复述代码？
  - 删除注释是否影响理解？

□ 预先实现检查
  - 是否实现了需求未要求的功能？
  - 是否有未使用的扩展点/配置项？
  - 是否有未调用的 public 方法？

□ 代码量评估
  - 同样功能是否有明显更短的实现？
  - 是否可以用语言特性减少代码量？

代码量评估标准

评估维度	标准	需优化
方法长度	单方法不超过 50 行	超过 80 行
类大小	单类不超过 200 行	超过 400 行
文件长度	单文件不超过 300 行	超过 500 行
参数数量	不超过 3 个	超过 5 个
嵌套深度	不超过 2 层	超过 3 层
重复率	低于 5%	超过 10%

精简输出格式

生成代码时，必须附带精简度自评：

## 代码精简度自评

### 代码量
- 新增：{N} 行
- 修改：{M} 行
- 删除：{K} 行

### 复用情况
- 复用已有方法：{列出}
- 使用标准库：{列出}
- 新增公共方法：{列出}

### 精简检查
- 重复代码：无 / {说明}
- 冗余抽象：无 / {说明}
- 重复造轮：无 / {说明}
- 过度防御：无 / {说明}
- 预先实现：无 / {说明}

### 说明
- {如有未精简项，说明原因}

与其他技能的协作

场景	使用技能	说明
生成新代码时	concise-code	强制精简，从源头控制代码量
生成后审查	code-review	多维度审查，精简是其中一维
已有代码臃肿	refactoring	系统化重构方法论
给 AI 下指令	code-generation	提示词规范，减少生成错误

最佳实践

• 生成代码前先搜索项目中是否已有相似实现
• 优先使用语言原生的语法特性减少代码量（如 Stream API、Lambda 表达式、var 类型推断）
• 一个函数/方法只做一件事，超过 50 行考虑拆分
• 禁止"为了健壮性"添加不可能发生的判断分支
• 禁止"为了扩展性"预留当前用不到的接口
• 注释只解释"为什么"，不解释"是什么"
• 修改代码时控制变更范围，禁止顺手重构