Ais_ha_9前一阵我把手头一个内部工具的重构任务丢给AI去做，结果发现一个很尴尬的事情：同一个模型、同一个需求，我把需求描述得详细一点，代码能跑通的概率就明显高一些；我图省事只丢一句话，它就经常给我造出根本不存在的API。后来我决定不靠“感觉”了，直接用A/B测试的方式去优化代码生成提示，让AI写对代码的概率从60%拉到了85%左右。这个过程挺有意思，也很值得复盘，今天把完整思路和实验数据整理出来。
1. 为“提示词玄学”搞一个正经实验台
先交代背景。我当时要生成的是一个用于内部数据清洗的小型Python库，包含文件读取、字段校验、格式转换、错误日志这几个模块。模型用的是市面上主流的通用大模型，不是专门的编程模型。任务复杂度中等偏上，代码量大概在600到900行之间。
起初我的提示词风格非常随意，基本就是“帮我写一个数据清洗脚本”，甚至带着口语化的“把那个日期格式改一下”这种话。结果就是模型经常自由发挥：有的给返回一个半成品类，有的把读取逻辑写错，有的把函数名都拼错了。我自己做了个粗统计，这种“自由发挥”状态下，代码能直接跑通并满足需求的概率只有60%左右。
60%是个什么概念呢？就是你每次生成代码，接近一半的概率要返工，而且返工时你还得耐着性子去一行一行找错。真正让人崩溃的是，有时候那40%的不合格代码看起来特别像样，语法完全正确，import也都是存在的库，但逻辑偏偏就是错的。这种代码比明显的报错更恶心。正因如此，我决定不再靠主观感受去调提示词，而是搞一个尽量规范的A/B测试流程，像做实验一样去改提示词。
A/B测试的第一件事不是写提示词，而是建立一个实验台：一个可重复运行的评估环境。我把评估分成两层：
- 第一层是硬性检查：代码能否通过语法编译，能否在准备好的测试用例上跑通，输出结果是否符合预期；
- 第二层是人工代码审查：让有经验的同事（或者我自己隔一段时间再看）做代码走查，看逻辑、命名、边界处理是否合理。
两层都通过才记作“写对”。整体流程是先准备一批统一的测试任务，每个任务用不同版本的提示词去生成代码，然后在同一个环境里跑测试，记录每一轮的成功率和失败原因。
有人可能会说，你直接看代码好不好不就行了吗，搞这么复杂干什么。但问题是，提示词优化里有一个特别常见的情况：指标看起来提升了，其实是样例变了。如果每次测试用的是不同的题目，你根本分不清是提示词变好了还是题目变简单了。一定要固定测试集、固定评测流程，这样每一次改动才有可比性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 搭建实验台：测试集、评测标准与基线成绩
实验台的第一个组成部分是测试集。我基于实际需求整理出20个数据清洗相关的小任务，覆盖三个难度级别：
| 难度 | 任务数量 | 说明 |
|---|---|---|
| 简单 | 8个 | 单函数，输入输出明确，比如“把字符串yyyy-mm-dd转换为datetime对象并格式化输出” |
| 中等 | 7个 | 多函数协作，涉及异常处理和类型判断，比如“按字段批量校验CSV并生成错误报告” |
| 困难 | 5个 | 多文件、多模块，涉及状态管理和配置参数，比如“从多个Excel中读取数据，按规则去重合并后写出新文件” |
这些任务全部来自之前真实项目里写过的东西，不是现场编的。我严格限制每道题的表述长度，避免有的题目天然就描述得更清楚，导致实验偏移。
第二个部分是评测脚本。我写了一个简单的Python脚本，自动完成以下工作：
- 依次调用AI接口，用指定的提示词模板拼接测试任务；
- 将模型返回的代码保存为独立的.py文件；
- 对每个文件执行语法检查（py_compile）；
- 运行预置好的测试用例，比对输出结果；
- 将语法错误、运行报错、输出不符等情况记录到CSV里。
人工代码审查则放在自动评测通过后做。因为自动评测只能证明“