首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >AI 写的代码,什么时候该改,什么时候该扔?——重构 vs 重写的决策框架

AI 写的代码,什么时候该改,什么时候该扔?——重构 vs 重写的决策框架

原创
作者头像
用户12475538
发布2026-05-11 13:10:38
发布2026-05-11 13:10:38
400
举报
文章被收录于专栏:与workbuddy合作与workbuddy合作

AI 写的代码,什么时候该改,什么时候该扔?——重构 vs 重写的决策框架

"我帮你改一下"是对 AI 代码最危险的本能反应。有时候,第二次从零生成比修修补补快五倍。


一个我反复犯的错

AI 给我生成了 200 行代码。逻辑合格,但结构混乱——函数职责不清、变量命名别扭、三个地方重复了同样的逻辑。

我本能地开始"改一下"。

20 分钟后,我修了 6 处,但发现修第 7 处会破坏第 3 处的逻辑。40 分钟后,代码被我改成了一个"原版 + 我的修补 + 修补的修补"的三层夹心。60 分钟后,我删掉所有代码,重新给 AI 发了需求——这次加上了结构约束。新版本 5 分钟生成,干净。

"先改改看"是我在 AI 协作中效率损失最大的来源。 不是 AI 的问题——是我没有在动手前做一个关键判断:这段代码是该改,还是该扔。


决策矩阵:改还是扔

代码语言:python
复制
def should_refactor_or_rewrite(code_from_ai):
    score = 0

    # 结构维度
    if has_clear_function_boundaries(code_from_ai):
        score += 2
    if has_consistent_naming(code_from_ai):
        score += 1
    if has_no_duplicated_logic(code_from_ai):
        score += 2

    # 正确性维度
    if core_algorithm_is_correct(code_from_ai):
        score += 3
    if edge_cases_handled(code_from_ai):
        score += 2

    # 匹配度维度
    if matches_project_conventions(code_from_ai):
        score += 2
    if uses_correct_dependencies(code_from_ai):
        score += 1

    if score >= 8:
        return "微调即可"
    elif score >= 5:
        return "局部重构"
    else:
        return "重新生成(改需求描述)"

核心逻辑:结构分低 + 正确性高 = 改。结构分低 + 正确性也低 = 扔。 因为修结构的前提是核心逻辑是对的——如果逻辑也歪了,你修结构的同时还在修逻辑,两个变量同时变,debug 难度指数级上升。


三种典型场景

场景一:微调——结构好,只是细节偏差

代码语言:python
复制
# AI 给的:结构清晰,但有一个 bug
def calculate_discount(user, order):
    # 逻辑分层清晰
    base_rate = get_user_discount_rate(user)
    seasonal_rate = get_seasonal_multiplier()
    loyalty_bonus = calculate_loyalty_bonus(user.years_active)

    # ❌ bug:应该用乘法而不是加法
    return base_rate + seasonal_rate + loyalty_bonus

# 判定:改一行,不改结构。5 秒。

微调的标志:你改动的行数 < 代码总行数的 10%。 超过这个比例,进下一档。

场景二:局部重构——逻辑对,但结构乱

代码语言:python
复制
# AI 给的:功能对,但是一团浆糊
def process_order(order):
    # 验证、查库存、计算价格、扣款、发邮件全在一个函数里
    # 300 行,职责不清
    ...

# 判定:抽函数,不动核心逻辑。
def process_order(order):
    validate_order(order)          # 抽1
    inventory = check_inventory(order.items)  # 抽2
    price = calculate_price(order, inventory) # 抽3
    charge_payment(order.user, price)         # 抽4
    send_confirmation(order)                  # 抽5
    return order

局部重构的标志:你能清楚地命名每个要抽出去的子函数。 如果你看着代码说不出"这段应该叫 handle_payment"而只能说出"这段应该整理一下"——那就是扔的信号。命名不出来 = 你不理解结构 = 改不如重来。

场景三:重新生成——结构和逻辑都有问题

代码语言:python
复制
# AI 给的:一团乱麻,而且核心算法也错了
def sync_data(source, target):
    # 用了错误的同步策略(全量覆盖而不是增量)
    # 变量名 a, b, c
    # 没有错误处理
    # 而且嵌套了四层 if
    ...

# 判定:扔。但关键——改需求描述后再重新生成。

最容易忽略的一步:扔之前,先想想为什么 AI 写成了这样。 大概率是你的需求描述有问题——没说清楚结构约束、没说核心策略、没说边界情况。修复这些问题后重新生成,通常第二次的质量会好一个量级。


重写前的"需求修复"清单

扔掉代码之前,先过一遍:这次生成为什么失败了?把答案写进下一次的需求里。

代码语言:markdown
复制
[ ] 结构约束说了吗?
    → "每个函数不超过 30 行"
    → "抽成三个模块:验证层、业务层、持久层"

[ ] 核心策略说了吗?
    → "同步用增量策略,不是全量覆盖"
    → "缓存用 LRU,不是 TTL"

[ ] 边界情况说了吗?
    → "用户不存在返回 404"
    → "库存不足时返回具体缺货数量"

[ ] 项目约定说了吗?
    → "错误处理用装饰器 @handle_errors"
    → "返回值统一用 {"code": 0, "data": ...}"

这个清单的本质:你不是在"让 AI 重新写",你是在"修复自己的需求描述"。 AI 写错了通常不是因为模型不行,是因为你给的信息不够。


一个时间换算

代码语言:python
复制
# 拿到 AI 生成的代码后,花 30 秒做这个判断
def estimate_effort(code):
    fix_time = estimate_fix_time(code)     # 预估修补耗时
    rewrite_time = estimate_rewrite_time() # 预估重写耗时(包括改需求描述)

    if rewrite_time < fix_time * 0.5:
        return "重写"
    elif rewrite_time < fix_time * 0.8:
        return "重写(如果质量提升明显)"
    else:
        return "修"

经验数据:如果修需要 30 分钟以上,重写的投入产出比通常更高。 因为修补 30 分钟意味着问题足够复杂——复杂到你在修补过程中会引入新 bug。


最容易被低估的成本

修补 AI 代码的最大成本不是时间,是理解负担

你修别人写的代码时,大脑在处理两个东西:作者的原意(这行为什么这样写?)和你的修改(我要改成什么样?)。当原作者是 AI,第一个问题尤其难——你不知道它是基于什么推理写出的这行。

修 200 行 AI 代码,等于先理解 200 行你没有参与思考的代码,再修改它。 重新生成 200 行,等于看着它按你的新约束从头写。

两者的认知负荷不在一个量级。


一个反直觉的体验

用 AI 越久,我越少"改"代码,越多"扔"代码。

不是因为 AI 写得越来越差——是因为我对"什么值得改"的判断越来越精确。以前是"能跑就行,调调",现在是"结构不对就重新来,别浪费时间"。

修修补补带来的"我在进步"的错觉,是 AI 协作里最贵的幻觉。重新生成只花了 5 分钟就得到干净代码,比花 30 分钟修出一个勉强能用的版本,对自己诚实得多。


本文所有示例均已脱敏处理。你对 AI 代码是"改派"还是"扔派"?欢迎评论区站队。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • AI 写的代码,什么时候该改,什么时候该扔?——重构 vs 重写的决策框架
    • 一个我反复犯的错
    • 决策矩阵:改还是扔
    • 三种典型场景
      • 场景一:微调——结构好,只是细节偏差
      • 场景二:局部重构——逻辑对,但结构乱
      • 场景三:重新生成——结构和逻辑都有问题
    • 重写前的"需求修复"清单
    • 一个时间换算
    • 最容易被低估的成本
    • 一个反直觉的体验
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档