你大概经历过这个循环。第一周把 AI 助手接进编辑器，交付速度翻倍。到第三个月，速度回到原点——但 debug 的 bug 更诡异了。
我在四个项目里用了两年 AI 助手，这个模式反复出现：生产力提升真实存在，但集中在前期，而且会衰减——除非改变工作方式。大部分衰减来自一个具体、可修复的问题。
核心问题：看起来对、跑不通的代码
最常见的 bug 不是语法错误。是生成的代码调用了某个函数、方法或配置项，看起来完全是库该有的——但实际不存在。
上个月我做 CSV 导入功能，助手生成了这段代码：
import pandas as pd
# Read CSV with progress reporting — looks reasonable, right?
df = pd.read_csv(
"users.csv",
on_progress=lambda pct: print(f"Loading: {pct}%"), # this kwarg does not exist
chunksize=10_000,
on_progress 不是 pd.read_csv 的真实参数。代码语法正确，linter 没报错，失败模式是静默的——这个参数被吞掉，导入照常跑，只是没有进度条。直到用户反馈"加载条没动"我才发现。
这就是核心问题。AI 生成的代码以一种特定且危险的方式"合理"：它模式匹配了真实 API 的形状，而这恰恰是 code review 时最难察觉的。
根因：幻觉如何溜过检查
三件事共同作用：
第一，模式匹配优先于正确性。模型见过成千上万个 pd.read_csv 调用，也见过其他 I/O 函数的进度回调。把两者拼接，产出看起来对、实际不对的代码。
第二，类型检查器常常救不了你。很多库用 **kwargs、动态分发或鸭子类型。静态分析不会标记一个不存在的关键字参数——它直接流过 **kwargs。
第三，审阅疲劳。周围代码都对、函数名也真实，你的眼睛会滑过那个捏造的参数。200 行"基本正确"的输出之后，你不再仔细阅读。
更深的问题是 workflow 层面的。如果你 prompt 一个功能然后粘贴结果，相当于外包了生成，却保留全部验证责任——而验证别人写的代码更难，因为你没有作者该有的 mental model。
修复方案：把验证强制纳入循环
被坑够多次后，我换了这套 workflow。核心原则：除非有东西——不是你的眼睛——碰过这段代码，否则不接受。
第一步：先写测试
生成实现之前，写（或生成）一个测试，覆盖你想要的具体行为。这会把行为锚定到可运行的东西上。
# tests/test_import.py
from myapp.importer import load_users
def test_load_users_reports_progress():
progress_log = []
def capture(pct):
progress_log.append(pct)
load_users("users.csv", on_progress=capture)
assert len(progress_log) > 0
assert progress_log[-1] == 100
现在 AI 生成的代码必须通过这个测试。on_progress 参数不存在？测试失败，当场暴露。
第二步：小步迭代，强制运行
不要生成 200 行然后审阅。生成 20 行，跑测试，通过再继续。失败模式从"三周后发现生产 bug"变成"90 秒内看到报错"。
第三步：用类型系统当护栏
如果库支持，加类型存根或 TypedDict 定义配置结构。把 **kwargs 换成显式参数。AI 生成不存在的字段时，mypy 会直接标红。
第四步：保留人工审阅给架构决策
别用眼睛去核对参数拼写——让测试和类型检查器干这个。把审阅精力留给"这个函数该不该存在""异常处理策略对不对"这类机器无法判断的问题。
关键认知转变
AI 助手不是更快的打字机，是更快的原型生成器。如果你用旧 workflow 接它——写 prompt、粘贴、肉眼审阅——你会得到更快产生的技术债。
修复 workflow 后，我的速度曲线变了：第一周没有暴涨，但三个月后没有衰减。第六个月还在稳定提升，因为测试库和类型定义在累积，AI 在更坚实的 scaffolding 上工作。
工具没变，变的是人和工具的协作方式。这才是 AI 编程助手真正的使用门槛。
热门跟贴