AI写代码善后？Anthropic内部用一年的Code Simplifier开源

来源：互联网 2026-07-02 06:33:12

Anthropic资讯合集

Anthropic开源内部使用的CodeSimplifier，专门清理AI生成代码中的重复逻辑、嵌套三元运算符和泛化异常，改善可读性且不改变行为，作为AI输出与人工审查之间的缓冲层。

小王跑完 Security Auditor 的修复，把代码提给老李看。老李盯着那个登录方法，眉头又皱起来了。

不是因为还有漏洞。安全那关已经过了。是因为这代码——代码能跑，测试也过，安全扫描也通过了，但老李一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。

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

AI写代码善后？Anthropic内部用一年的Code Simplifier开源

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都爱干。初学者是因为不知道，AI是因为"安全"。但具体的业务异常被淹没了，出了问题很难排查。

3. 重复的逻辑碎片

getRole() != null getRole() : "USER" 出现了好几次。AI生成的时候不会说"等等我之前写过"，它就再写一遍。

Code Simplifier的价值就在这里。它是在AI生成之后、PR合并之前，插入的一道清洁程序。

架构图：在Ja va SpringBoot项目里的完整位置

AI写代码善后？Anthropic内部用一年的Code Simplifier开源

Code Simplifier不是独立环节，是接在AI生成之后、人工Review之前的缓冲层。它帮你过滤"不用人看也知道要改"的那部分，让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生成的代码是草稿，不是成品

AI写代码善后？Anthropic内部用一年的Code Simplifier开源

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

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

洞见2：这不是一次性清理，是要建立的编程习惯

AI写代码善后？Anthropic内部用一年的Code Simplifier开源

Code Simplifier最大的价值不是"一次性清理"，是让这个步骤内化成习惯。就像写完代码要跑测试，跑完 Code Simplifier 也是一个标准动作。

Anthropic工程师们用了一年，这个习惯进化成了肌肉记忆。开源的意义就是把这个传递出去。

洞见3：它示范了AI工具应该怎么分工

AI写代码善后？Anthropic内部用一年的Code Simplifier开源

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 确认改了什么
看完改动再 commit，不是跑完直接提
CLAUDE.md 里写清楚你的编码规范，Code Simplifier 会跟着你的规范走

方法论速查表

阶段	工具	职责
功能实现	Claude Code	写出能跑的代码
代码清洁	Code Simplifier	化简可读性，不改行为
人工审查	工程师	确认业务逻辑和架构
自动验证	JUnit + CI	回归测试防止引入问题
合并上线	Git + CD	交付到生产环境

Code Simplifier 能做	Code Simplifier 不做
消除嵌套三元运算符	修改业务逻辑
合并重复代码	重构架构
改善变量命名	修 bug
提取小方法	更改公共 API
删除废注释	自动写测试