AI 生成的代码能直接用吗？四阶段质量保障流程

前段时间上线了一个 AI 生成的功能模块。

Claude Code 写完后自信地说"代码没问题"，我看了一眼逻辑也对，就直接合并了。

结果上线第二天，用户反馈数据丢失。

复盘的时候发现，代码确实"没问题"——逻辑是对的，测试也过了。但有一个边界条件，AI 没有考虑到，我也没有验证到。

这件事让我意识到：AI 的自信不等于代码的正确。

只做 Review 是不够的

最早我的工作流很简单：AI 写代码，我来 review，没问题就提交。

后来发现这个流程有三个盲区：

第一个盲区：理解偏差

有时候我的需求描述不够清晰，AI 按"它的理解"写了代码。逻辑是对的，但不是我要的。Review 的时候我看到了代码，但忘记了最初的需求是什么。

第二个盲区：过度设计

AI 生成的代码经常会"过度设计"——三层封装、提前优化、冗余注释。代码能跑，但维护成本高。Review 的时候容易忽略这些问题，因为逻辑是对的。

第三个盲区：盲目信任

这是我踩的坑。AI 说"没问题"，我就真的信了。但 AI 只能检查你给它的上下文，它看不到系统整体。

后来我改成了一个四阶段流程：Plan → Review → Simplify → Trust。

每个阶段解决不同的问题，组合起来才能保证代码质量。

阶段一：Plan —— 避免返工的关键

什么时候需要 Plan Mode？

我给自己定了一个判断标准：

Plan Mode 的核心是：先想清楚，再动手。

我会写一个简单的 plan 文件，内容包括：

• • 目标（具体要达成什么）
• • 步骤（每个步骤可验证）
• • 风险点（哪些地方可能出问题）

例如：

# Plan: 添加用户登录功能

## 目标
用户可以通过邮箱密码登录，登录状态保持 7 天

## 步骤
1. 创建 login API → 验证：单元测试通过
2. 实现 session 管理 → 验证：手动测试登录流程
3. 添加登录状态校验中间件 → 验证：未登录用户被拦截

## 风险点
- session 过期时间要可配置
- 密码存储必须用 bcrypt

写完 plan 后，我会自己检查一遍，确认理解是对的。然后才让 Claude 按计划执行。

这个阶段解决的是"理解偏差"问题——返工的成本远高于提前想清楚的成本。

阶段二：Review —— 双重验证机制

代码写完后，我会做两层 review。

第一层：AI Review（快速）

用 /review 命令让 Claude 自己检查代码。

AI Review 适合检查：

• • 代码风格一致性
• • 常见反模式（比如 SQL 拼接）
• • 基本逻辑漏洞
• • 错误处理完整性

但 AI Review 有局限：它只能看到你给它的上下文，它不懂你的业务逻辑，也不知道系统整体的约束。

第二层：人工 Review（深度）

这一层必须自己做，而且要专注在 AI 不擅长的地方：

• • 业务逻辑正确性（AI 不懂业务）
• • 系统级影响（跨模块依赖）
• • 性能瓶颈（需要实测）
• • 边界条件（需要领域知识）

我的检查清单：

## AI Review Checklist
- [ ] 代码风格符合规范
- [ ] 无明显安全漏洞（OWASP Top 10）
- [ ] 错误处理完整
- [ ] 测试覆盖关键路径

## 人工 Review Checklist
- [ ] 业务逻辑正确
- [ ] 与其他模块的交互正确
- [ ] 性能测试通过
- [ ] 边界条件覆盖

两层 review 是互补的：AI 快速扫描常见问题，人工深度验证业务和系统层面。

阶段三：Simplify —— 过度设计的清理

这一步是我后来加上的，因为发现 AI 生成的代码经常会"过度设计"。

举个例子。

有一次我要写一个数据导出功能，支持 CSV 和 JSON 两种格式。AI 给我生成了这样的代码：

class DataProcessorFactory:
    def create_processor(self, format_type):
        if format_type == "csv":
            return CSVProcessor()
        elif format_type == "json":
            return JSONProcessor()

class CSVProcessor:
    def process(self, data):
        # 30 行处理逻辑
        pass

class JSONProcessor:
    def process(self, data):
        # 30 行处理逻辑
        pass

看起来很"工程化"，但对于这个项目来说，完全不需要三层封装。

简化后：

def export_data(data, format_type):
    if format_type == "csv":
        return _to_csv(data)
    elif format_type == "json":
        return _to_json(data)

def _to_csv(data):
    # 直接处理
    pass

def _to_json(data):
    # 直接处理
    pass

从 60 行减到 30 行，逻辑更清晰，维护成本更低。

我会用 /simplify 命令，让 Claude 检查代码里是否有：

• • 不必要的抽象层
• • 提前优化
• • 过度封装
• • 冗余注释

然后我会评估简化建议是否合理。不是所有的简化都是对的，性能敏感的场景，有些优化是必要的。

阶段四：Trust —— 按场景分级验证

最后一步是判断：这段代码，我该信多少？

我给自己定了一个信任框架：

高信任场景（可直接使用）：

• • 样板代码（boilerplate）
• • 标准库调用
• • 常见模式实现（CRUD、validation）
• • 格式化、重构

这类代码，我会快速扫一眼逻辑，直接用。

中信任场景（需 spot check）：

• • 业务逻辑实现
• • 新依赖的使用
• • 性能敏感代码
• • 第三方 API 调用

这类代码，我会逐行阅读，理解每一行的意图，然后验证关键逻辑。

低信任场景（需完整验证）：

• • 安全相关代码（认证、加密）
• • 并发控制
• • 数据迁移脚本
• • 核心算法

这类代码，我会完整 review，写测试，必要时手动验证。

我踩过的坑：简单 ≠ 低风险。

并发控制的代码可能只有 10 行，但需要深度验证；而一个简单的 CRUD 功能可能有 100 行，但风险很低。

信任度不取决于代码复杂度，而取决于出问题的影响范围。

完整流程示例

上周我实现一个用户权限管理功能，完整走了四阶段：

Plan 阶段：

• • 写了 plan：定义权限模型、实现权限检查、添加测试
• • 自己检查 plan，发现漏了"权限继承"的处理，补充进去
• • 确认 plan 后让 Claude 执行

Review 阶段：

• • AI Review：发现两处命名不规范，一处错误处理不完整
• • 修复后人工 Review：验证业务逻辑，发现权限缓存可能导致数据不一致
• • 补充了缓存失效逻辑

Simplify 阶段：

• • /simplify 发现权限检查有重复代码
• • 提取了公共函数，减少了 50 行重复

Trust 阶段：

• • 权限涉及安全，属于低信任场景
• • 补充了完整的单元测试和边界测试
• • 手动验证了权限继承逻辑

整个过程看起来"慢"，但上线后没有出问题。如果直接跳过 plan 和 simplify，可能早就上线了，但很可能会有 bug，返工的成本会更高。

一句话总结

四阶段流程看起来复杂，其实一句话就能概括：

Plan 避免返工，Review 发现错误，Simplify 去除冗余，Trust 分级验证。

流程不是负担，而是"看起来慢，实则快"的保障。

AI 会写代码，但判断代码质量的还是你。