Anthropic开源内部使用一年的Code Simplifier，专为AI代码善后

小王完成了 Security Auditor 的修复工作，将代码提交给老李审核。老李盯着那个登录方法，眉头再次紧锁。

问题不在于仍有安全漏洞——安全审查已经通过。真正让他皱眉的是代码本身：功能可以运行、测试全部通过、安全扫描也达标，但老李在 Code Review 时却发现了隐患——

// AuthServiceImpl.ja va - 小王的成果
public ResponseEntity login(LoginRequest request) {
    try {
        User user = userRepository.findByUsername(request.getUsername())
            .orElseThrow(() -> new RuntimeException("用户不存在"));
        if (!passwordEncoder.matches(request.getPassword(), user.getPassword())) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED)
                .body(new ApiResponse(false, "密码错误", null));
        }
        if (user.getStatus() != null && user.getStatus().equals("disabled")) {
            return ResponseEntity.status(HttpStatus.FORBIDDEN)
                .body(new ApiResponse(false, "账号已禁用", null));
        }
        String token = jwtUtil.generateToken(user.getUsername(),
            user.getRole() != null ? user.getRole() : "USER");
        Map data = new HashMap<>();
        data.put("token", token);
        data.put("username", user.getUsername());
        data.put("role", user.getRole() != null ? user.getRole() : "USER");
        return ResponseEntity.ok(new ApiResponse(true, "登录成功", data));
    } catch (Exception e) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body(new ApiResponse(false, "系统异常", null));
    }
}

老李叹了口气。

漏洞确实修复了。但 user.getRole() != null ? user.getRole() : "USER" 重复出现了两次，catch 块仍然使用 Exception 粗暴兜底，嵌套的三层 if 结构依然存在，核心逻辑紧紧包裹在 try-catch 内，整个方法长达五十行。

安全扫描通过了，但这代码——下一个接手维护的人打开时，依然难以理解。

这正是第二层问题：AI 生成代码的速度虽然比人类快 10 倍，但堆砌出来的代码有时像赶工的实习生所写。功能正确、安全过关，就是读不下去。

老李想到了 Code Simplifier——一个专为代码可读性而生的 AI 代码简化工具。

它是什么？Anthropic 自己用了一年才开源

Code Simplifier 是 Anthropic 官方 Claude Code 团队内部使用的代码清理 Agent，2026 年 1 月 9 日开源，托管在 claude-plugins-official 仓库中。

核心开发者 Boris Cherny 发布时只说了一句话：

这就是他们每天在用的工具，不是做给用户看的样子货。

它的职责只有一条：让代码更清晰，但绝不改变代码的行为。

功能范围很克制：

• 消除嵌套的三元运算符，替换为 if-else 或 switch
• 去除重复代码和无用抽象
• 改善变量名和函数名，增强代码可读性
• 合并关联逻辑，降低认知负荷
• 删除描述“显而易见”的多余注释

它不会做的事：修改公共 API、调整业务逻辑、重构架构、修复 bug。

默认只处理当前会话中最近改动的代码。你可以指定扩大范围，但它绝不会越界操作。

为什么 AI 编写的代码需要专门的“清洁工”？

这个问题值得深入探讨。

使用 Claude Code 写代码，最初体验很爽：速度快，边界情况也能考虑到。但写着写着你会发现，AI 为了“安全”，常常把简单的事情写得很复杂。

几个常见症状：

1. 防御性代码过度堆叠

// AI style
if (user != null && user.getRole() != null && !user.getRole().isEmpty()) {
    role = user.getRole();
} else {
    role = "USER";
}

这种场景在 User 对象层面用 @Builder.Default 就能优雅解决，或者一行 Optional 链就够了。AI 不是不知道，而是更倾向于写“万无一失”的冗余版本。

2. 异常处理中的偷懒式兜底

catch Exception 是初学者的常见做法，AI 也爱用——因为它“安全”。但具体的业务异常被淹没，出了问题排查困难。

3. 重复的逻辑碎片

getRole() != null ? getRole() : "USER" 在代码中多次出现。AI 生成时不会说“等等，我之前写过”，而是直接再写一遍。

Code Simplifier 的价值就在这里：它作为 AI 生成之后、PR 合并之前的清洁程序，自动优化代码质量。

架构图：在 Java SpringBoot 项目中的完整位置

Code Simplifier 并非独立环节，而是接在 AI 生成之后、人工 Review 之前的缓冲层。它帮团队过滤掉“不用人看也知道要改”的代码，让 Code Review 的精力集中到真正的业务逻辑上。

实战：老李的登录模块改进

将小王的代码交给 Code Simplifier 处理，指令很简单：

Use code-simplifier on the auth module I just built

改进前（原始 AI 生成代码）：

public ResponseEntity login(LoginRequest request) {
    try {
        User user = userRepository.findByUsername(request.getUsername())
            .orElseThrow(() -> new RuntimeException("用户不存在"));
        if (!passwordEncoder.matches(request.getPassword(), user.getPassword())) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED)
                .body(new ApiResponse(false, "密码错误", null));
        }
        if (user.getStatus() != null && user.getStatus().equals("disabled")) {
            return ResponseEntity.status(HttpStatus.FORBIDDEN)
                .body(new ApiResponse(false, "账号已禁用", null));
        }
        String token = jwtUtil.generateToken(user.getUsername(),
            user.getRole() != null ? user.getRole() : "USER");
        Map data = new HashMap<>();
        data.put("token", token);
        data.put("username", user.getUsername());
        data.put("role", user.getRole() != null ? user.getRole() : "USER");
        return ResponseEntity.ok(new ApiResponse(true, "登录成功", data));
    } catch (Exception e) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body(new ApiResponse(false, "系统异常", null));
    }
}

改进后（Code Simplifier 输出）：

public ResponseEntity login(LoginRequest request) {
    User user = userRepository.findByUsername(request.getUsername())
        .orElseThrow(() -> new UsernameNotFoundException("用户不存在"));
    validateUserCredentials(user, request.getPassword());
    String role = user.getEffectiveRole();
    String token = jwtUtil.generateToken(user.getUsername(), role);
    LoginResponse loginData = LoginResponse.of(user.getUsername(), role, token);
    return ResponseEntity.ok(ApiResponse.success("登录成功", loginData));
}

private void validateUserCredentials(User user, String rawPassword) {
    if (!passwordEncoder.matches(rawPassword, user.getPassword())) {
        throw new BadCredentialsException("密码错误");
    }
    if (UserStatus.DISABLED.equals(user.getStatus())) {
        throw new DisabledException("账号已禁用");
    }
}

具体的改进点：

• 重复两遍的 getRole() != null ? getRole() : "USER" 逻辑，整合进了 user.getEffectiveRole() 方法
• 验证逻辑提取为 validateUserCredentials()，login() 方法本身更加清晰
• 异常由 RuntimeException 替换为语义明确的 UsernameNotFoundException、BadCredentialsException
• 返回类型从 ResponseEntity 改为 ResponseEntity，类型更安全
• Map 替换为 LoginResponse 对象，不再使用散装键值对

需要说明的是：Code Simplifier 不会自动创建 LoginResponse 类和 getEffectiveRole() 方法。它会标记“这里应该有专门的类”，具体实现仍需你或 Claude Code 补充。边界十分清晰。

注册模块：同样的代码优化思路

注册场景中，AI 特别倾向于将所有校验塞进 Service 层，导致方法体动辄五六十行：

原始版本（AI 生成）：

public ApiResponse register(RegisterRequest request) {
    if (request.getUsername() == null || request.getUsername().trim().isEmpty()) {
        return new ApiResponse(false, "用户名不能为空", null);
    }
    if (request.getUsername().length() < 3 || request.getUsername().length() > 20) {
        return new ApiResponse(false, "用户名长度3-20位", null);
    }
    if (userRepository.findByUsername(request.getUsername()).isPresent()) {
        return new ApiResponse(false, "用户名已存在", null);
    }
    if (request.getPassword() == null || request.getPassword().length() < 8) {
        return new ApiResponse(false, "密码至少8位", null);
    }
    if (!request.getPassword().equals(request.getConfirmPassword())) {
        return new ApiResponse(false, "两次密码不一致", null);
    }
    // 还有十几行...
}

Code Simplifier 处理后：

public ApiResponse register(RegisterRequest request) {
    validateRegistration(request);
    User user = User.builder()
        .username(request.getUsername())
        .password(passwordEncoder.encode(request.getPassword()))
        .role("USER")
        .status(UserStatus.ACTIVE)
        .createdAt(LocalDateTime.now())
        .build();
    userRepository.sa ve(user);
    return ApiResponse.success("注册成功", null);
}

private void validateRegistration(RegisterRequest request) {
    if (userRepository.existsByUsername(request.getUsername())) {
        throw new UserAlreadyExistsException("用户名已存在");
    }
    // 格式校验交给 Bean Validation 处理
}

配合 Spring Boot 的 Bean Validation，格式校验直接放在 DTO 中：

public class RegisterRequest {
    @NotBlank(message = "用户名不能为空")
    @Size(min = 3, max = 20, message = "用户名长度3-20位")
    private String username;

    @NotBlank
    @Size(min = 8, message = "密码至少8位")
    private String password;
}

原来塞在 Service 里的众多 if 判断，Code Simplifier 会指出：这部分交给 @Valid 更合适。它不帮你修改 DTO，但指明了优化方向。

个人中心：最易被忽视的臃肿地带

个人中心的接口通常不复杂，但 AI 编写时容易将“更新用户信息”和“权限校验”混在一起：

Code Simplifier 处理前：

public ResponseEntity updateProfile(Long userId, UpdateProfileRequest request,
                                        HttpServletRequest httpRequest) {
    String token = httpRequest.getHeader("Authorization");
    if (token == null || !token.startsWith("Bearer ")) {
        return ResponseEntity.status(401).body("未授权");
    }
    String username = jwtUtil.extractUsername(token.substring(7));
    User currentUser = userRepository.findByUsername(username)
        .orElseThrow(() -> new RuntimeException("用户不存在"));
    if (!currentUser.getId().equals(userId)) {
        return ResponseEntity.status(403).body("无权限");
    }
    // 再 20 行更新逻辑...
}

处理后：

@PreAuthorize("#userId == authentication.principal.id")
public UserProfileResponse updateProfile(Long userId, UpdateProfileRequest request) {
    User user = userRepository.findById(userId)
        .orElseThrow(() -> new UserNotFoundException(userId));
    userMapper.updateFromRequest(user, request);
    userRepository.sa ve(user);
    return UserProfileResponse.from(user);
}

权限逻辑下沉到 Spring Security，Service 只关心业务本身。方法体从五十行缩减为八行。

3条洞见

洞见1：AI生成的代码是草稿，不是成品

过去用 IDE 写代码，写完就是成品——因为写的过程本身就是思考过程。AI 辅助写代码时，生成过程是 AI 的思考，而不是你的。AI 给你的是一份草稿，需要经过一道清洁工序才能变成你愿意签名的代码。

Code Simplifier 正是那个自动化的清洁步骤。它不能替代 Code Review，但能让 Review 专注于真正重要的事情。

洞见2：这不是一次性清理，而是需要养成的编程习惯

Code Simplifier 最大的价值不在于“一次性清理”，而在于让这个步骤内化为开发习惯。就像写完代码要跑测试一样，跑完 Code Simplifier 也应成为标准动作。

Anthropic 的工程师们使用了一年，这个习惯已经进化为肌肉记忆。开源的意义，正是将这套实践传递出去。

洞见3：它示范了AI工具的正确分工

Code Simplifier 清楚自己能做什么、不能做什么。这种克制本身就是优秀工具的设计哲学。

并非所有问题都要由一个 AI 解决，每个环节都有最合适的工具——这才是 AI 时代软件工程的正确姿态。

如何在你的项目中用起来

安装：

# 插件市场
claude plugin install code-simplifier
# 或在会话内
/plugin marketplace update claude-plugins-official
/plugin install code-simplifier

使用口令：

# 清理当前会话改动的代码
Use code-simplifier on the auth module I just built

# 清理特定文件
Run the code simplifier on UserService.ja va

# PR 前批量清理
Simplify the last three components we wrote this session

使用前记住三件事：

• 在 git 追踪的目录中运行，方便通过 git diff 确认改了什么
• 查看改动后再提交，不要跑完直接提 PR
• 在 CLAUDE.md 中写清你的编码规范，Code Simplifier 会遵循你的规范进行优化

方法论速查表

“AI 写代码的时代，Code Review 的重心需要转变。以前 Review 是发现问题能不能用，现在 Review 是确认要不要这样用。Code Simplifier 帮我们过滤了第一层噪声，剩下的才是真正需要人脑判断的关键。”