前言

写新代码是创造，改旧代码是修行。每个开发者都经历过这种痛苦：接手一份几年前的遗留代码，没有注释、没有类型、函数动辄300行，改一处崩三处。传统重构靠的是经验和耐心，而在2026年，AI编程工具给我们带来了一条全新的路径——用AI辅助完成代码生成与重构，把原来需要一整天的重构工作压缩到一两个小时。

本文是专栏第04篇，聚焦AI辅助代码生成与重构的实战技巧，涵盖Prompt模板、重构对比案例、设计模式应用和代码迁移，帮你真正把AI用出效率。

⚠️ 本文定位为"AI辅助提升效率"，所有AI生成的代码均需人工审查和测试，不提倡"全自动生成直接上线"的做法。

---

一、AI代码生成的5个实用Prompt模板

用好AI生成代码的关键，不在于模型有多强，而在于你的Prompt有多精准。以下5个模板经过大量实战验证，覆盖最常见的代码生成场景。

模板1：功能生成模板

请用 [语言] 实现一个 [功能描述] 的函数/模块。
要求：
1. 输入参数：[参数列表及类型]
2. 返回值：[返回类型和含义]
3. 需要处理的边界情况：[列举边界条件]
4. 代码风格：遵循 [PEP8 / ESLint / Google Style] 规范
5. 请附带类型注解和docstring

使用场景：新建函数、工具类、数据处理模块等。

模板2：单元测试生成模板

请为以下函数生成完整的单元测试，使用 [pytest / jest / unittest] 框架。
要求：
1. 覆盖正常输入、边界值、异常输入三种场景
2. 每个测试用例包含清晰的注释说明测试意图
3. 使用参数化测试减少重复代码
4. Mock外部依赖（如数据库、API调用）

[粘贴函数代码]

使用场景：给已有函数补测试，提升代码覆盖率。

模板3：代码重构模板

请重构以下代码，使其更符合 [SOLID原则 / 函数式风格 / 现代写法]。
重构目标：
1. 提升可读性：拆分过长的函数，提取有意义的变量名
2. 消除重复：提取公共逻辑为独立函数
3. 增加类型注解
4. 保持原有功能不变，不要改变对外接口

[粘贴原始代码]

使用场景：重构遗留代码、优化"面条代码"。

模板4：设计模式应用模板

以下代码存在 [具体问题，如：if-else过多 / 紧耦合 / 难以扩展]。
请用 [策略模式 / 工厂模式 / 观察者模式 / 装饰器模式] 重构，
要求：
1. 先说明为什么选择这个设计模式
2. 给出重构后的完整代码
3. 标注哪些类/方法是新增的，哪些是修改的
4. 说明重构后如何解决原来的问题

[粘贴原始代码]

使用场景：代码结构优化、消除坏味道。

模板5：代码迁移模板

请将以下 [源语言/版本] 代码迁移到 [目标语言/版本]。
迁移要求：
1. 保持功能语义一致
2. 充分利用目标语言/版本的现代特性（如type hints / async await / 可选链等）
3. 标注迁移中需要注意的不兼容点
4. 给出迁移前后的对照说明

[粘贴原始代码]

使用场景：Python 2→3、JavaScript→TypeScript、Java→Kotlin等迁移。

---

二、代码重构实战：3个完整案例

案例1：将遗留Python代码重构成现代风格

这是一个真实的遗留代码场景——用户数据处理模块，函数超长、无类型注解、混合了多种职责。

重构前（遗留风格）：

def process_users(data):
    result = []
    for d in data:
        if d['type'] == 'vip':
            if d['score'] > 100:
                d['level'] = 'gold'
                d['discount'] = 0.7
            elif d['score'] > 50:
                d['level'] = 'silver'
                d['discount'] = 0.85
            else:
                d['level'] = 'bronze'
                d['discount'] = 0.95
            result.append(d)
        elif d['type'] == 'normal':
            if d['score'] > 100:
                d['level'] = 'gold'
                d['discount'] = 1.0
            elif d['score'] > 50:
                d['level'] = 'silver'
                d['discount'] = 1.0
            else:
                d['level'] = 'bronze'
                d['discount'] = 1.0
            result.append(d)
        # 还有其他类型没处理...
    return result

重构后（现代风格，AI辅助生成+人工审查）：

from dataclasses import dataclass
from enum import Enum
from typing import Optional


class UserType(Enum):
    VIP = "vip"
    NORMAL = "normal"


@dataclass
class User:
    name: str
    type: UserType
    score: int
    level: Optional[str] = None
    discount: float = 1.0


def calc_level_and_discount(user_type: UserType, score: int) -> tuple[str, float]:
    """根据用户类型和积分计算等级与折扣。"""
    thresholds = {
        UserType.VIP: [
            (100, "gold", 0.70),
            (50, "silver", 0.85),
            (0, "bronze", 0.95),
        ],
        UserType.NORMAL: [
            (100, "gold", 1.00),
            (50, "silver", 1.00),
            (0, "bronze", 1.00),
        ],
    }
    for threshold, level, discount in thresholds[user_type]:
        if score > threshold:
            return level, discount
    return "bronze", 1.0


def process_users(users: list[User]) -> list[User]:
    """批量处理用户等级与折扣。"""
    for user in users:
        user.level, user.discount = calc_level_and_discount(
            user.type, user.score
        )
    return users

重构要点总结：

• 用 dataclass 替代裸字典，增加类型安全
• 用 Enum 管理用户类型，杜绝魔法字符串
• 提取 calc_level_and_discount 函数，单一职责
• 用数据驱动（thresholds 字典）替代层层嵌套的 if-else

---

案例2：用策略模式消除 if-else 地狱

重构前（JavaScript）：

function calculatePrice(order) {
  let price = order.basePrice;

  if (order.paymentMethod === 'credit_card') {
    price = price * 0.98; // 信用卡2%手续费优惠
  } else if (order.paymentMethod === 'debit_card') {
    price = price * 0.99;
  } else if (order.paymentMethod === 'alipay') {
    price = price * 0.95;
  } else if (order.paymentMethod === 'wechat') {
    price = price * 0.96;
  } else if (order.paymentMethod === 'crypto') {
    price = price * 1.02; // 加密货币额外费用
  } else {
    throw new Error('Unsupported payment method');
  }

  if (order.userLevel === 'vip') {
    price = price * 0.9;
  } else if (order.userLevel === 'svip') {
    price = price * 0.8;
  }

  return price;
}

重构后（TypeScript + 策略模式）：

type PaymentStrategy = (basePrice: number) => number;
type LevelStrategy = (price: number) => number;

// 支付策略映射表 —— 新增支付方式只需加一行
const paymentStrategies: Record<string, PaymentStrategy> = {
  credit_card: (p) => p * 0.98,
  debit_card:  (p) => p * 0.99,
  alipay:      (p) => p * 0.95,
  wechat:      (p) => p * 0.96,
  crypto:      (p) => p * 1.02,
};

// 用户等级折扣策略
const levelStrategies: Record<string, LevelStrategy> = {
  vip:  (p) => p * 0.9,
  svip: (p) => p * 0.8,
};

function calculatePrice(order: {
  basePrice: number;
  paymentMethod: string;
  userLevel: string;
}): number {
  const paymentFn = paymentStrategies[order.paymentMethod];
  if (!paymentFn) {
    throw new Error(`Unsupported payment method: ${order.paymentMethod}`);
  }

  let price = paymentFn(order.basePrice);

  const levelFn = levelStrategies[order.userLevel];
  if (levelFn) {
    price = levelFn(price);
  }

  return price;
}

重构要点：策略模式 + 查表法，新增支付方式只需在映射表中加一行，完全符合开闭原则（OCP）。这一思路可以广泛适用于任何"根据类型分支处理"的场景。

---

案例3：JavaScript → TypeScript 迁移

迁移前（JavaScript，无类型保护）：

// api.js
export async function fetchUserData(userId) {
  const response = await fetch(`/api/users/${userId}`);
  const data = await response.json();
  return {
    name: data.name,
    email: data.email,
    age: data.age,
    orders: data.orders.map(o => ({
      id: o.id,
      amount: o.total_amount,
      date: o.created_at,
    })),
  };
}

export function getActiveUsers(users) {
  return users.filter(u => u.lastLogin > Date.now() - 30 * 24 * 3600 * 1000);
}

迁移后（TypeScript，完整类型定义）：

// types.ts
interface User {
  id: string;
  name: string;
  email: string;
  age: number;
  lastLogin: Date;
}

interface Order {
  id: string;
  amount: number;
  date: string;
}

interface UserProfile {
  name: string;
  email: string;
  age: number;
  orders: Order[];
}

// api.ts
export async function fetchUserData(userId: string): Promise<UserProfile> {
  const response = await fetch(`/api/users/${userId}`);
  if (!response.ok) {
    throw new Error(`Failed to fetch user: ${response.status}`);
  }
  const data = await response.json();
  return {
    name: data.name,
    email: data.email,
    age: data.age,
    orders: data.orders.map((o: Record<string, unknown>) => ({
      id: o.id as string,
      amount: o.total_amount as number,
      date: o.created_at as string,
    })),
  };
}

export function getActiveUsers(users: User[]): User[] {
  const thirtyDaysMs = 30 * 24 * 3600 * 1000;
  return users.filter(
    (u) => u.lastLogin.getTime() > Date.now() - thirtyDaysMs
  );
}

迁移要点：

• 独立 types.ts 文件集中管理类型定义
• 增加错误处理（response.ok 检查）
• 用 Date 对象替代时间戳比较，语义更清晰
• 类型注解使IDE能提供自动补全和编译时错误检查

---

三、设计模式 + AI：让模式落地不再困难

很多开发者学了设计模式却"用不上"，原因是：识别场景难、手写样板代码多。AI在这两个环节都能提供强力辅助。

3.1 AI辅助识别"该用哪个模式"

当你把代码贴给AI并描述问题时，AI可以帮你推荐合适的设计模式。例如：

“这段代码里有大量 isinstance 判断来决定调用哪个处理函数，后续还要不断加新类型。”

AI会推荐使用 访问者模式 或 策略模式 + 注册表，并解释原因。关键是你要描述清楚代码的痛点，而不是简单地说"帮我优化"。

3.2 AI生成设计模式脚手架

一旦确定了设计模式，可以让AI先生成骨架代码，你再填充业务逻辑。这比从零手写快得多，也减少了样板代码出错的可能。

实战建议：

1. 先让AI解释为什么推荐这个模式，判断是否合理
2. 让AI生成骨架代码 + 接口定义
3. 你来填充具体业务逻辑
4. 让AI审查最终代码是否符合模式规范

3.3 常见场景与推荐模式速查

代码坏味道	推荐模式	AI辅助要点
大量 if-else/switch 分支	策略模式 + 查表法	让AI生成策略映射表
对象创建逻辑复杂	工厂模式 / 建造者模式	让AI生成Builder链式调用
多模块需要通知联动	观察者模式 / 事件总线	让AI设计解耦的事件接口
功能需要动态扩展	装饰器模式	让AI生成可组合的装饰器
第三方接口需要适配	适配器模式	让AI生成Facade层

---

四、代码迁移实战经验

4.1 Python 2 → Python 3 迁移

AI辅助迁移的步骤：

1. 批量语法转换：让AI处理 print 语句→函数、xrange→range、unicode→str 等基础语法变更
2. 类型注解补全：让AI根据函数逻辑推断并添加 type hints
3. f-string替换：将 %s 和 .format() 替换为 f-string
4. 异步改造：将同步IO替换为 async/await
5. 测试验证：让AI生成迁移对比测试，确保行为一致

关键提醒：Python 2的字符串行为（bytes vs str）是迁移中最大的坑，AI可能忽略编码问题，务必人工检查。

4.2 JavaScript → TypeScript 迁移

推荐渐进式迁移策略：

1. 第一步：allowJs: true，让TS编译器接受JS文件，先跑起来
2. 第二步：用AI为公共接口生成 .d.ts 类型声明文件
3. 第三步：逐文件迁移，优先迁移工具函数和API层
4. 第四步：开启 strict 模式，逐步修复类型错误
5. 第五步：让AI帮你把 any 替换为具体类型

每一步都可以让AI生成代码骨架，但类型语义需要开发者自己把关。

---

五、AI生成代码的质量检查清单

AI生成的代码不能"拿来就用"，以下是我总结的8项质量检查清单，每次使用AI生成代码后都应过一遍：

✅ AI代码质量检查清单
┌──────────────────────────────────────────────────────┐
│ □ 1. 功能正确性：核心逻辑是否正确？是否覆盖边界情况？     │
│ □ 2. 安全性：是否存在SQL注入、XSS、硬编码密钥等问题？    │
│ □ 3. 类型安全：类型注解是否准确？有没有滥用 any？        │
│ □ 4. 错误处理：异常是否被合理捕获和处理？                 │
│ □ 5. 性能：是否存在N+1查询、内存泄漏、不必要的循环？      │
│ □ 6. 可读性：命名是否清晰？函数是否过长？有无注释？        │
│ □ 7. 可维护性：是否符合项目现有代码风格和架构约定？       │
│ □ 8. 可测试性：代码是否方便编写单元测试？                 │
└──────────────────────────────────────────────────────┘

实操建议：可以让AI帮你做检查——把生成的代码贴回去，让它对照这8项逐条审查。相当于让AI当你的"初审助手"，你自己做终审。

---

六、最佳实践总结

结合前面4篇专栏的经验，总结几条AI辅助代码生成与重构的核心原则：

1. 先理解再生成：不要把AI当代码生成器，先理解要重构的代码做了什么，再给AI精准的指令
2. 小步快跑：不要一次让AI重构整个文件，拆成函数级别的增量重构
3. 始终保留测试：重构前确保有测试覆盖，重构后跑测试验证
4. 人工审查不可省略：AI生成的代码可能在逻辑上正确，但在安全性、性能、可维护性上存在隐患
5. 建立团队Prompt库：把好用的Prompt模板沉淀为团队资产，减少重复摸索

---

结语

AI不会取代程序员，但会用AI的程序员正在取代不会用的。代码重构是一项需要经验和判断力的高级工作，AI是目前非常强大的"重构助手"之一——它能快速生成方案、识别坏味道、执行机械化改造，但最终的架构决策和质量把控仍然需要人类开发者。

掌握AI辅助代码生成与重构的技巧，你就能把更多精力放在架构设计和业务理解上，让编码真正成为创造性的工作。

---

🤖 AI辅助声明：本文由作者主导选题、架构设计和内容审核，AI工具（Claude 4 Sonnet）辅助完成内容起草和代码示例生成。所有代码示例均经过人工审查和修改，确保准确性和可读性。文中观点基于作者实际开发经验，AI仅作为效率工具使用。

---

专栏导航：

• 第01篇 AI编程工具全景图：2026年开发者必须知道的10个工具
• 第02篇 Python+AI工具链环境搭建指南
• 第03篇 AI辅助Debug：从2小时到2分钟的效率飞跃
• 第04篇 AI代码生成与重构技巧：让旧代码焕发新生（本文）
• 第05篇 AI辅助API开发：从设计到文档一站式提速
• 第06篇 AI驱动测试革新：让代码覆盖率不再是噩梦