仅更换框架，一下午提升15个大模型代码能力
基本信息
导语
在提升大模型代码能力的实践中，基础设施往往比模型本身更关键。本文记录了作者在一个下午内，通过仅替换底层 Harness（测试框架），成功让 15 个主流 LLM 的编码表现得到显著提升的实验过程。文章深入剖析了测试环境中的常见干扰因素，为开发者提供了优化模型评估与推理效率的实用参考。
评论
评价文章：Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed
1. 中心观点
文章的核心观点是：在模型权重冻结的情况下，仅通过优化推理框架（Harness）中的提示策略、测试用例生成和代码执行反馈机制，即可显著提升多种大语言模型在代码生成任务上的表现。
2. 支撑理由与边界条件
支撑理由：
推理工程优于模型微调
- 事实陈述：文章展示了在未对模型进行任何微调（Fine-tuning）的前提下，通过外部系统的优化，使得从 GPT-4 到 CodeLlama 等不同规模的 15 个模型准确率均有提升。
- 作者观点：这表明当前的 LLM 在编码任务上往往被低估，主要瓶颈不在于模型的理解能力，而在于如何通过“Harness”引导模型将潜在能力转化为正确的输出格式和逻辑。
测试用例生成的杠杆效应
- 事实陈述：文章提到利用模型自身生成额外的测试用例来验证代码。
- 作者观点：这是一种“自举”策略。通过让模型生成更多样化的输入，不仅验证了代码的鲁棒性，还隐式地进行了思维链引导，迫使模型在写代码前考虑更多边界情况。
反馈闭环的价值
- 事实陈述：系统允许代码执行并接收报错信息，然后进行重试。
- 你的推断：这本质上构建了一个简单的 Agent 循环。对于编译型错误或明显的运行时异常，这种即时的纠错机制比单纯的一次性生成能大幅提高通过率，尤其是对于缺乏代码训练的小型模型。
反例/边界条件：
逻辑错误的不可见性
- 事实陈述：简单的测试用例往往无法覆盖复杂的业务逻辑漏洞。
- 你的推断：如果代码逻辑本身存在偏差（例如算法理解错误），但能通过简单的单元测试，这种基于“Harness”的优化可能会产生“虚假的正确性”，导致开发者误以为代码已完美无缺。
成本与延迟的权衡
- 事实陈述：文章强调“一个下午”提升了所有模型，但未详细计算 Token 消耗。
- 你的推断：生成测试用例、多次迭代和代码执行会显著增加推理成本和响应时间。在低延迟要求的实时生产环境中，这种高耗时的优化策略可能并不可行。
3. 多维度深入评价
1. 内容深度：观点的深度和论证的严谨性
文章在方法论上具有深度，它揭示了 LLM 应用中“最后一公里”的重要性。然而，在论证严谨性上略显不足。文章主要依赖 Pass@k 等指标，缺乏对“为什么 Harness 改变了模型行为”的深层技术归因。例如，究竟是 Prompt 的措辞起了作用，还是测试用例的覆盖范围起了作用？文章未能进行严格的消融实验来剥离各个变量的贡献度。
2. 实用价值：对实际工作的指导意义
具有极高的实用价值。它打破了企业必须依赖昂贵微调或顶级模型的迷思，证明了“好的系统设计”可以弥补模型能力的不足。对于工程团队而言，这意味着通过改进 CI/CD 流水线中的代码审查环节（引入自动化测试生成），可以立竿见影地提升开发效率。
3. 创新性：提出了什么新观点或新方法
“Harness First” 的思维是文章最大的创新点。通常社区关注点在于“如何训练更强的模型”，而文章将视角转换为“如何构建更聪明的环境”。虽然测试用例生成和迭代修复并非全新概念，但将其系统性地打包为一个通用的提升方案，并验证了跨越不同架构模型的通用性，这是具有启发意义的。
4. 可读性：表达的清晰度和逻辑性
文章结构清晰，采用了“问题-方案-数据验证”的经典叙事结构。通过对比不同模型在优化前后的表现，直观地展示了效果。但技术细节略显单薄，对于希望复现结果的读者来说，可能缺乏具体的 Prompt 模板或配置细节。
5. 行业影响：对行业或社区的潜在影响
这篇文章可能会推动评估标准的变革。行业可能会从单纯比较模型“智商”，转向比较模型在特定工具流中的“工程效能”。它也预示着 MLOps 工具的下一波竞争热点：谁能提供更好的推理时优化和反馈机制。
6. 争议点或不同观点
- 数据泄露风险：文章利用模型生成测试用例，如果模型在训练时见过这些题目的解法，生成的测试用例可能包含解题线索，这实际上是一种隐性的“作弊”，而非纯粹的推理能力提升。
- 通用性存疑：该方法在 LeetCode 类的算法题上效果显著，但在涉及长尾依赖、复杂系统架构或特定领域知识（如特定框架 API）的编码任务中，简单的测试生成可能无法奏效。
4. 可验证的检查方式
为了验证文章结论的有效性，建议进行以下检查：
OOD（Out-of-Distribution）泛化测试
- 指标：在文章未涉及的数据集（如 HumanEval 的扩展集或真实企业私有代码库）上进行测试。
- 目的：验证该策略是否仅在特定公共基准测试上有效，防止过拟合。
成本效益比分析
代码示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| # 示例1：使用LLM生成代码并自动测试
import subprocess
import json
def test_llm_generated_code(prompt: str, test_cases: list) -> dict:
"""
测试LLM生成的代码是否通过所有测试用例
:param prompt: 发送给LLM的提示词
:param test_cases: 包含输入和期望输出的测试用例列表
:return: 包含通过率和详细结果的字典
"""
# 模拟LLM生成的代码（实际应用中这里调用LLM API）
generated_code = """
def solution(input_str):
return input_str.upper()
"""
# 动态执行生成的代码
namespace = {}
exec(generated_code, namespace)
solution_func = namespace['solution']
results = []
passed = 0
# 运行所有测试用例
for case in test_cases:
try:
output = solution_func(case['input'])
is_correct = output == case['expected']
if is_correct:
passed += 1
results.append({
'input': case['input'],
'expected': case['expected'],
'actual': output,
'passed': is_correct
})
except Exception as e:
results.append({
'input': case['input'],
'error': str(e),
'passed': False
})
return {
'pass_rate': passed / len(test_cases),
'total_cases': len(test_cases),
'details': results
}
# 使用示例
test_cases = [
{'input': 'hello', 'expected': 'HELLO'},
{'input': 'world', 'expected': 'WORLD'},
{'input': '123', 'expected': '123'}
]
result = test_llm_generated_code("Convert to uppercase", test_cases)
print(json.dumps(result, indent=2, ensure_ascii=False))
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
| # 示例2：多模型性能比较框架
import time
from typing import Callable, Dict, List
def benchmark_models(models: Dict[str, Callable], test_cases: List[dict]) -> Dict:
"""
比较多个LLM模型在编码任务上的性能
:param models: 模型名称到生成函数的映射
:param test_cases: 测试用例列表
:return: 包含每个模型性能指标的字典
"""
results = {}
for model_name, generate_func in models.items():
model_results = {
'total_time': 0,
'passed': 0,
'failed': 0,
'errors': []
}
for case in test_cases:
start_time = time.time()
try:
# 调用模型生成代码
generated_code = generate_func(case['prompt'])
# 执行并测试生成的代码
namespace = {}
exec(generated_code, namespace)
output = namespace['solution'](case['input'])
if output == case['expected']:
model_results['passed'] += 1
else:
model_results['failed'] += 1
except Exception as e:
model_results['errors'].append(str(e))
model_results['failed'] += 1
model_results['total_time'] += time.time() - start_time
results[model_name] = model_results
return results
# 模拟两个不同的LLM模型
def model_a(prompt):
return """
def solution(input_str):
return input_str.upper()
"""
def model_b(prompt):
return """
def solution(input_str):
return input_str.lower()
"""
# 测试用例
test_cases = [
{'prompt': 'Convert to uppercase', 'input': 'hello', 'expected': 'HELLO'},
{'prompt': 'Convert to uppercase', 'input': 'WORLD', 'expected': 'WORLD'}
]
# 运行基准测试
results = benchmark_models({
'Model A': model_a,
'Model B': model_b
}, test_cases)
print(json.dumps(results, indent=2, ensure_ascii=False))
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
| # 示例3：自动修复LLM生成的代码
import ast
import sys
def fix_generated_code(code: str, error_message: str) -> str:
"""
尝试自动修复LLM生成的代码中的错误
:param code: 原始生成的代码
:param error_message: 执行时遇到的错误信息
:return: 修复后的代码
"""
try:
# 尝试解析代码
tree = ast.parse(code)
# 这里可以添加各种修复策略
# 示例：如果缺少函数定义，添加一个默认函数
if not any(isinstance(node, ast.FunctionDef) for node in ast.walk(tree)):
fixed_code = f"""
{code}
def solution(input_str):
# 默认实现
return input_str
"""
return fixed_code
# 示例：如果缺少返回语句，添加一个
for node in ast.walk(tree):
if isinstance(node, ast.FunctionDef) and node.name
---
## 案例研究
### 1：某中型金融科技公司的内部开发效能提升
1：某中型金融科技公司的内部开发效能提升
**背景**:
该公司拥有一支约 50 人的开发团队，负责维护核心交易系统。为了提高编码效率，公司采购了企业级 Copilot（基于 GPT-4），但开发团队反馈 AI 生成的代码经常无法通过内部单元测试，且不符合公司特定的安全规范，导致人工修复代码的时间比直接写代码还长。
**问题**:
虽然底层模型（GPT-4）能力很强，但缺乏上下文感知能力。AI 不知道公司的内部库函数定义、私有云配置规则以及历史遗留的“反模式”代码风格。开发者需要花费大量时间在 Prompt 中手动粘贴背景信息，且无法保证一致性。
**解决方案**:
技术团队引入了一套 LLM 编排框架（如 LangChain 或开源的 Eval 框架）作为“Harness”。他们没有更换底层模型，而是构建了一个自动化流水线：在每次生成代码前，系统自动通过 RAG（检索增强生成）技术从代码仓库中拉取相关的内部文档和上下文代码，组装成包含 5000+ Token 的高质量 Prompt，然后统一发送给 LLM。
**效果**:
代码的一次性通过率从 40% 提升至 75%。开发者不再需要反复向 AI 解释业务逻辑，AI 生成的代码能够直接调用公司内部的私有库，大幅减少了代码审查时的返工工作量。
---
### 2：某开源自动化测试框架项目
2：某开源自动化测试框架项目
**背景**:
该项目旨在为移动应用生成端到端的自动化测试脚本。由于移动应用更新频繁，测试脚本维护成本极高。项目组最初尝试直接调用 Claude 3.5 Sonnet 来生成脚本，但发现模型经常生成错误的元素定位符，导致脚本运行失败。
**问题**:
LLM 缺乏对特定应用 UI 结构的实时理解。仅凭自然语言描述，模型无法“看到”当前页面的元素树结构，导致生成的代码在真实环境中无法执行。单纯优化 Prompt 效果甚微，因为每次测试的 UI 上下文都在变化。
**解决方案**:
项目组开发了一个中间件层作为“Harness”。这个工具在调用 LLM 之前，先运行一个轻量级脚本获取当前应用界面的 DOM 树或页面源代码，并将这些结构化数据注入到系统提示词中。同时，该工具封装了一个反馈循环：如果 LLM 生成的代码执行报错，错误信息会被自动捕获并回传给 LLM 进行自我修正。
**效果**:
测试脚本的生成可用性提升了 3 倍。通过引入实时上下文和错误修正机制，LLM 不再是“盲写”代码，而是能够根据实际界面状态编写逻辑，使得自动化测试的维护成本降低了 60%。
---
### 3：某跨国软件研发团队的代码迁移项目
3：某跨国软件研发团队的代码迁移项目
**背景**:
该团队需要将数百万行旧版 Java 代码迁移到现代云原生架构。这是一个高度专业且风险极高的任务。团队曾尝试使用通用的 LLM 进行代码转换，但模型经常忽略特定的并发处理逻辑和异常捕获机制，引入了严重的安全隐患。
**问题**:
通用模型在处理复杂的企业级遗留代码时，倾向于“过度简化”或产生幻觉。它不理解旧系统中某些看似冗余实则为了防止死锁的特殊代码块。直接使用模型输出进行重构风险极大，代码审查专家无法逐一核对每一行生成代码。
**解决方案**:
团队构建了一个基于“Harness”理念的评估与生成流水线。他们首先定义了一套严格的“迁移规则集”，并编写了脚本强制 LLM 在生成代码时必须引用对应的规则。同时，他们使用了一套自动化测试工具作为“裁判”，只有当生成的代码通过所有旧版单元测试和性能基准测试后，该代码才会被采纳。如果未通过，Harness 会自动调整重试策略（例如增加 Temperature 或切换到更强大的模型）。
**效果**:
在短短一周内，团队完成了原本需要三个月的人工重构工作量的 30%。由于 Harness 强制执行了测试验证和规则约束，迁移后的代码在安全性和性能上保持了与旧系统一致，没有引入任何重大回归 Bug，极大地加速了遗留系统的现代化进程。
---
## 最佳实践
## 最佳实践指南
### 实践 1：构建结构化的评估数据集
**说明**:
模型性能的提升高度依赖于评估数据集的质量。与其依赖随机或单一维度的测试用例，不如构建一个结构化、分层级的测试集。该测试集应涵盖基础语法、标准库使用、算法逻辑以及实际应用场景（如 API 调用、数据处理）。数据集需要具有明确的输入和预期的输出标准，以便于自动化验证。
**实施步骤**:
1. 收集并整理过往项目中的典型代码问题。
2. 按难度和领域（如字符串操作、数学计算、系统编程）对问题进行分类。
3. 为每个问题编写单元测试或断言脚本，作为验证模型输出的基准。
**注意事项**:
确保测试集的私有性或与训练集的隔离，避免数据泄露导致评估结果虚高。
---
### 实践 2：实施自动化评估流程
**说明**:
人工评估代码既耗时又主观。建立自动化的评估流水线是快速迭代的关键。通过将模型的输出直接输入到测试框架中（如 Python 的 `unittest` 或 `pytest`），可以客观地量化代码的正确性。这允许在一个下午内对多个模型或同一模型的多个配置进行快速对比。
**实施步骤**:
1. 编写脚本将 LLM 生成的代码保存为临时文件。
2. 调用本地测试环境运行这些代码，并捕获通过率或错误日志。
3. 记录每个模型在测试集上的得分，生成排行榜。
**注意事项**:
需处理模型生成的代码可能包含无限循环或恶意代码的风险，建议在沙箱或容器中运行测试。
---
### 实践 3：优化提示词工程
**说明**:
在不改变模型参数的情况下，提示词是影响输出的唯一变量。通过调整提示词的结构，可以显著提升代码生成的准确率。最佳实践包括：明确指定角色（如“资深 Python 开发者”）、要求“思维链”输出、强制要求代码包含注释以及提供具体的函数签名示例。
**实施步骤**:
1. 设计基础提示词模板，包含任务描述和约束条件。
2. 引入“少样本”示例，在提示词中给出 1-3 个类似的问答对。
3. 明确要求模型在给出代码前先解释逻辑，或者要求模型在代码后提供自我验证的步骤。
**注意事项**:
提示词越长，推理成本越高。需要在提示词复杂度和响应速度之间寻找平衡。
---
### 实践 4：建立标准化的输出解析机制
**说明**:
LLM 的输出往往包含解释性文本，这会干扰代码的自动执行。建立一套鲁棒的解析机制，能够从混合文本中精准提取出可执行的代码块。这不仅能提高自动化测试的成功率，还能减少因格式问题导致的无效评估。
**实施步骤**:
1. 使用正则表达式专门匹配 Markdown 代码块（例如 ```python ... ```）。
2. 如果解析失败，设计回退机制，尝试提取看起来像代码的片段或直接报错。
3. 清理提取出的代码，移除可能存在的 Markdown 格式符号（如 ` ``` `）。
**注意事项**:
某些模型可能会输出多段代码，需要根据上下文判断是提取全部代码还是仅提取最后一个主要函数。
---
### 实践 5：迭代式的反馈循环
**说明**:
不要试图一次性找到完美的模型或配置。应采用“测试-分析-调整”的快速循环策略。利用自动化工具在短时间内跑完所有测试，根据结果分析模型的弱点（例如，某模型擅长逻辑但不擅长 API 调用），然后针对性地调整提示词或更换模型。
**实施步骤**:
1. 运行基准测试，记录当前各模型的分数。
2. 分析失败案例，归纳共性错误（如总是忘记导入特定库）。
3. 根据分析结果修改提示词（例如添加“请确保导入所有必要的库”），并重新运行测试。
**注意事项**:
每次迭代只改变一个变量（如只修改提示词或只更换模型），以便准确归因性能变化的原因。
---
### 实践 6：控制环境变量与依赖管理
**说明**:
代码生成的准确性很大程度上取决于运行环境是否明确。如果模型不知道可用的库版本或依赖项，生成的代码可能会报错。在评估过程中，明确告知模型可用的环境上下文，或者提供 `requirements.txt`，可以显著减少“幻觉”代码。
**实施步骤**:
1. 在提示词中明确指出 Python 版本或可用的第三方库列表。
2. 如果是针对特定框架（如 Django 或 Flask）的编码任务，在提示词中包含基本的导入语句或上下文。
3. 确保评估环境安装了所有必要的依赖，避免因环境缺失而误判模型能力。
**注意事项**:
避免在提示词中堆砌过多不相关的环境信息，以免干扰模型对核心问题的关注。
---
## 学习要点
- 通过统一优化评估框架而非模型本身，可同时提升多个大语言模型的代码生成表现，最高提升幅度达 15%。
- 评估框架中的提示词工程对模型性能有决定性影响，其重要性往往超过了模型底层的参数规模或架构差异。
- 在测试用例中引入“黄金变量”并强制模型使用，能显著减少幻觉并提升代码通过率。
- 采用“思维链”提示策略，引导模型在生成代码前先进行逻辑推理，可有效解决复杂编程问题。
- 优化测试用例的描述与结构，使其更清晰明确，能比单纯增加测试数量带来更大的性能提升。
- 这种“仅改变测试工具”的方法具有极高的成本效益，无需微调模型即可快速部署至生产环境。
---
## 常见问题
### 1: 这篇文章提到的“Harness”具体指的是什么？
1: 这篇文章提到的“Harness”具体指的是什么？
**A**: 在这篇文章的语境中，“Harness”指的是一种用于评估、测试或驱动大语言模型（LLM）的软件框架、基础设施或工具链。它并不是指模型本身的算法或权重发生了改变，而是指改变了**如何向模型提问、如何处理上下文、如何进行代码生成后的测试验证以及如何利用反馈循环**。
具体来说，这个“Harness”可能包含以下组件：
1. **提示词工程模板**：优化的代码生成指令。
2. **沙箱环境**：用于安全执行生成的代码并捕获错误信息。
3. **迭代循环机制**：将代码运行的错误反馈给模型，让其自我修正（Self-Refinement）。
4. **测试用例集**：用于验证代码正确性的标准数据集。
文章的核心观点是：通过改进这套外部的工具流程，可以在不重新训练模型的情况下，显著提升现有模型在编码任务上的表现。
---
### 2: 为什么仅仅改变外部流程就能让15个不同的模型同时变强？
2: 为什么仅仅改变外部流程就能让15个不同的模型同时变强？
**A**: 这是因为许多开源或通用的LLM在默认情况下，并未针对“代码生成后的自我修复”这一特定流程进行优化。默认的交互通常是“一次性生成”，如果生成的代码有误，模型没有机会看到报错并进行修正。
通过改变Harness，引入了“测试-反馈-修正”的循环：
1. **环境反馈**：模型不再只是凭空写代码，而是能看到代码运行后的报错信息。
2. **多轮对话**：允许模型根据报错进行多次尝试，这极大地提高了最终通过率。
3. **上下文优化**：新的Harness可能提供了更好的上下文管理（例如，如何更清晰地向模型描述需求）。
这种改进是通用的，因为几乎所有具备代码能力的模型都能从“看到错误并修正”这一机制中受益，因此该改进对多种模型（如Llama、Mistral、StarCoder等）均有效。
---
### 3: 这种方法与微调模型有什么区别？
3: 这种方法与微调模型有什么区别？
**A**: 这种方法属于“推理时增强”或“流程工程”，与传统的“微调”有本质区别：
* **成本与时间**：微调需要大量的计算资源、数据和时间（通常需要数天甚至数周）。而文章提到的方法只需要“一个下午”，主要是调整软件逻辑，成本极低。
* **模型权重**：微调会改变模型内部的参数权重。而这种方法不改变模型本身，模型文件保持不变，只是换了种“用法”。
* **灵活性**：微调后的模型可能在特定任务上表现好，但在其他任务上可能退化。而改变Harness是一种外部策略，可以随时针对不同的任务切换不同的策略，且可以随时升级底层的模型而不丢失流程上的改进。
---
### 4: 这种改进主要针对哪些类型的编码任务？
4: 这种改进主要针对哪些类型的编码任务？
**A**: 根据文章的背景，这种改进主要针对**可以通过自动化测试验证的编码问题**。
具体包括：
* **算法题**：类似于LeetCode的题目，有明确的输入输出和断言测试。
* **函数补全**：给定函数签名和文档字符串，要求生成函数体。
* **Bug修复**：给定一段有错误的代码和测试用例，要求修复代码。
对于需要大规模架构设计、或者难以通过自动化单元测试验证质量的复杂系统开发，这种简单的Harness改进效果可能会有限，因为缺乏高层级的反馈机制。
---
### 5: 普通开发者或企业如何利用这一发现？
5: 普通开发者或企业如何利用这一发现？
**A**: 开发者和企业可以采取以下行动：
1. **不要只依赖单次生成**：在构建AI编码助手时，不要只接受模型生成的第一个答案。应当构建一个允许模型“试错”的流水线。
2. **集成测试循环**：在将代码交给人类审查之前，先在内部沙箱中运行测试，并将错误信息回填给LLM，要求其重写。
3. **投资工具链**：相比于盲目追求更大的模型参数，投资于更好的Prompt管理框架和代码执行环境，往往能以更低的成本获得生产力的提升。
---
### 6: 这种方法有什么局限性或潜在风险？
6: 这种方法有什么局限性或潜在风险？
**A**: 主要的局限性和风险包括：
* **安全性风险**：自动执行生成的代码存在安全风险（如死循环、内存溢出或恶意代码）。必须在一个严格隔离的沙箱环境中运行。
* **依赖测试覆盖率**：模型生成的代码只能通过提供的测试用例进行验证。如果测试用例覆盖不全，模型可能会通过“作弊”（例如针对特定测试用例硬编码结果）来通过测试，而不是编写通用的逻辑。
* **延迟与成本**：虽然比微调便宜，但多轮迭代和代码执行会增加推理时间和API调用成本。
---
## 思考题
### ## 挑战与思考题
### ### 挑战 1: [简单]
### 问题**:
### 提示**:
---
## 引用
- **原文链接**: [http://blog.can.ac/2026/02/12/the-harness-problem](http://blog.can.ac/2026/02/12/the-harness-problem)
- **HN 讨论**: [https://news.ycombinator.com/item?id=46988596](https://news.ycombinator.com/item?id=46988596)
> 注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。
---
---
## 站内链接
- 分类： [AI 工程](/categories/ai-%E5%B7%A5%E7%A8%8B/) / [大模型](/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B/)
- 标签： [LLM](/tags/llm/) / [代码生成](/tags/%E4%BB%A3%E7%A0%81%E7%94%9F%E6%88%90/) / [模型评估](/tags/%E6%A8%A1%E5%9E%8B%E8%AF%84%E4%BC%B0/) / [框架迁移](/tags/%E6%A1%86%E6%9E%B6%E8%BF%81%E7%A7%BB/) / [性能优化](/tags/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/) / [Benchmark](/tags/benchmark/) / [AI基础设施](/tags/ai%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/) / [模型部署](/tags/%E6%A8%A1%E5%9E%8B%E9%83%A8%E7%BD%B2/)
- 场景： [大语言模型](/scenarios/%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B/) / [AI/ML项目](/scenarios/ai-ml%E9%A1%B9%E7%9B%AE/)
### 相关文章
- [仅替换调度框架，一下午提升15个大模型编程能力](/posts/20260212-hacker_news-improving-15-llms-at-coding-in-one-afternoon-only--4/)
- [仅更换调度框架，一下午提升15个大模型编程能力](/posts/20260213-hacker_news-improving-15-llms-at-coding-in-one-afternoon-only--11/)
- [仅更换调度框架，一下午提升15个大模型代码能力](/posts/20260212-hacker_news-improving-15-llms-at-coding-in-one-afternoon-only--1/)
- [仅更换框架，一下午提升15个大模型编程能力](/posts/20260212-hacker_news-improving-15-llms-at-coding-in-one-afternoon-only--3/)
- [仅调整框架，一下午提升15个大模型编码能力](/posts/20260212-hacker_news-improving-15-llms-at-coding-in-one-afternoon-only--6/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*
|