"我帮你改一下"是对 AI 代码最危险的本能反应。有时候,第二次从零生成比修修补补快五倍。
AI 给我生成了 200 行代码。逻辑合格,但结构混乱——函数职责不清、变量命名别扭、三个地方重复了同样的逻辑。
我本能地开始"改一下"。
20 分钟后,我修了 6 处,但发现修第 7 处会破坏第 3 处的逻辑。40 分钟后,代码被我改成了一个"原版 + 我的修补 + 修补的修补"的三层夹心。60 分钟后,我删掉所有代码,重新给 AI 发了需求——这次加上了结构约束。新版本 5 分钟生成,干净。
"先改改看"是我在 AI 协作中效率损失最大的来源。 不是 AI 的问题——是我没有在动手前做一个关键判断:这段代码是该改,还是该扔。
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 难度指数级上升。
# 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%。 超过这个比例,进下一档。
# 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"而只能说出"这段应该整理一下"——那就是扔的信号。命名不出来 = 你不理解结构 = 改不如重来。
# AI 给的:一团乱麻,而且核心算法也错了
def sync_data(source, target):
# 用了错误的同步策略(全量覆盖而不是增量)
# 变量名 a, b, c
# 没有错误处理
# 而且嵌套了四层 if
...
# 判定:扔。但关键——改需求描述后再重新生成。最容易忽略的一步:扔之前,先想想为什么 AI 写成了这样。 大概率是你的需求描述有问题——没说清楚结构约束、没说核心策略、没说边界情况。修复这些问题后重新生成,通常第二次的质量会好一个量级。
扔掉代码之前,先过一遍:这次生成为什么失败了?把答案写进下一次的需求里。
[ ] 结构约束说了吗?
→ "每个函数不超过 30 行"
→ "抽成三个模块:验证层、业务层、持久层"
[ ] 核心策略说了吗?
→ "同步用增量策略,不是全量覆盖"
→ "缓存用 LRU,不是 TTL"
[ ] 边界情况说了吗?
→ "用户不存在返回 404"
→ "库存不足时返回具体缺货数量"
[ ] 项目约定说了吗?
→ "错误处理用装饰器 @handle_errors"
→ "返回值统一用 {"code": 0, "data": ...}"这个清单的本质:你不是在"让 AI 重新写",你是在"修复自己的需求描述"。 AI 写错了通常不是因为模型不行,是因为你给的信息不够。
# 拿到 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 删除。