仅更换测试框架，一下午提升15个大模型代码能力

基本信息

作者: kachapopopow
评分: 727
评论数: 267
链接: http://blog.can.ac/2026/02/12/the-harness-problem
HN 讨论: https://news.ycombinator.com/item?id=46988596

导语

随着大语言模型在代码生成领域的应用日益深入，如何通过工程化手段挖掘其潜力成为了关键课题。本文记录了一项针对 15 个主流 LLM 的对比实验，在不修改模型本身的前提下，仅通过切换 Harness（测试框架）便显著提升了编码表现。这一发现不仅揭示了外部框架对模型输出的实质性影响，更为开发者在资源受限时优化 AI 辅助编程效果提供了极具参考价值的思路。

文章中心观点

通过优化提示词工程与测试流程，在不改变模型权重的情况下，可以显著提升多种开源大语言模型（LLM）的代码生成准确率，且这种“软优化”的效果往往优于单纯追求更大的模型参数。

深入评价

1. 内容深度与论证严谨性

事实陈述：文章采用了标准的基准测试集（如HumanEval和MBPP），这是目前评估代码生成能力的行业通用标准，具有可比性。
作者观点：作者强调“Harness”（测试流程/提示词策略）比模型本身更重要。这一观点在技术上是站得住脚的，因为LLM具有极强的上下文敏感性，不同的Few-Shot示例或指令格式会导致输出分布的剧烈变化。
批判性分析：文章的深度在于揭示了“模型即服务”时代的一个真相：模型能力的下限由参数决定，但上限由调用方式决定。然而，论证存在一定的幸存者偏差。文章选取的15个模型可能对某种特定的提示词风格恰好敏感，这并不代表这种“Harness”具有普适的泛化能力。

2. 实用价值

你的推断：对于企业研发团队而言，这篇文章具有极高的性价比参考价值。它暗示企业无需盲目追求GPT-4等昂贵模型的私有化部署，通过优化现有的Llama 3或Mistral调用层，也能获得接近SOTA（最先进）的效果。
实际指导意义：文章展示了“迭代优化”的重要性。在实际工作中，很多开发者习惯于一次性写好Prompt，而忽略了针对特定代码风格进行微调提示词策略的必要性。

3. 创新性

事实陈述：文章并没有提出新的算法架构（如新的Transformer变体）。
作者观点：其创新点在于方法论——将“模型评估”从静态的测试转变为动态的优化过程。
新视角：它提出了“Prompt Engineering is Dead, Prompt Ops is Here”的隐含观点。即，与其手动编写完美的提示词，不如构建一个自动化的测试流程来筛选最佳的提示词策略。

4. 可读性与逻辑性

事实陈述：文章结构清晰，从问题出发到实验对比，最后给出结论。
评价：逻辑链条完整，但可能过于简化了背后的技术难度。读者可能会误以为只需要修改几行代码就能让模型突飞猛进，实际上构建一个高质量的“Harness”本身就需要深厚的工程经验。

5. 行业影响

你的推断：这篇文章可能会加剧“小模型+好工程”对“大模型+粗暴调用”的替代趋势。
社区影响：它鼓励开源社区更多地关注数据质量和推理时增强（RAG, Self-Consistency），而不是仅仅卷模型参数量。

支撑理由与反例

支撑理由：

指令遵循的敏感性：LLM对指令的格式、语气和具体要求极其敏感。一个结构化的、包含强制性约束的提示词，能大幅减少幻觉和语法错误。
测试集泄露的规避：通过精心设计的Harness，可以避免模型在训练阶段见过的测试集上“作弊”，从而更真实地反映其泛化能力。
思维链的引入：优化的Harness通常包含“Let’s think step by step”等CoT（Chain of Thought）触发器，这在代码逻辑推理中已被证明能有效提升准确率。

反例与边界条件：

复杂系统设计能力的缺失：无论Harness如何优化，如果模型本身的参数量不足以理解复杂的业务上下文或跨文件依赖，优化仅能提升“函数级”的代码准确率，无法解决“系统级”的架构设计问题。
特定领域的局限性：对于高度专业化且训练数据稀缺的领域（如嵌入式汇编、量子计算），提示词工程的收益会迅速递减，因为模型缺乏底层的领域知识，再好的提示词也无法“无中生有”。

可验证的检查方式

为了验证文章结论的有效性，建议进行以下检查：

跨模型验证实验：
- 操作：选取文章中表现最好的Harness，应用到未在文章测试名单中的新模型（如DeepSeek Coder或Qwen 2.5）上。
- 预期：如果该Harness具有普适性，新模型的表现应显著高于Baseline（默认提示词）。
真实场景的Pass@K指标：
- 操作：在实际IDE插件中部署该Harness，统计开发者采纳的代码比例。
- 预期：基准测试的分数提升必须转化为实际使用中代码重写率的降低。如果Benchmark分数高但实际可用性低，说明存在过拟合。
鲁棒性测试：
- 操作：故意输入带有歧义或轻微语法错误的自然语言描述。
- 预期：优秀的Harness应能引导模型进行澄清或纠正，而不是直接生成错误的代码。
成本收益分析：
- 操作：对比优化后的Harness带来的Token消耗增加与模型切换带来的成本节省。
- 预期：如果优化后的Prompt导致Token消耗增加50%，但准确率仅提升1%，则其实用价值存疑。

总结与建议

这篇文章是一篇典型的“工程驱动性能提升”的实战指南。它提醒技术人员，**在抱怨模型不够聪明之前，应该

代码示例

 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
# 示例1：自动化代码评估框架
def evaluate_code_generation(model, test_cases):
    """
    评估LLM代码生成能力的通用框架
    :param model: 待测试的LLM模型
    :param test_cases: 测试用例列表，每个用例包含输入和期望输出
    :return: 评估结果字典
    """
    results = {
        'total': len(test_cases),
        'passed': 0,
        'failed': 0,
        'errors': []
    }
    
    for case in test_cases:
        try:
            # 生成代码并执行
            generated_code = model.generate_code(case['prompt'])
            exec_globals = {}
            exec(generated_code, exec_globals)
            
            # 验证输出
            if exec_globals.get('result') == case['expected']:
                results['passed'] += 1
            else:
                results['failed'] += 1
                results['errors'].append({
                    'case': case['prompt'],
                    'expected': case['expected'],
                    'got': exec_globals.get('result')
                })
        except Exception as e:
            results['failed'] += 1
            results['errors'].append({
                'case': case['prompt'],
                'error': str(e)
            })
    
    return results

# 示例测试用例
test_cases = [
    {'prompt': '计算1+1', 'expected': 2},
    {'prompt': '反转字符串"hello"', 'expected': 'olleh'},
    {'prompt': '计算2的3次方', 'expected': 8}
]

 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
# 示例2：提示词工程优化器
class PromptOptimizer:
    """通过迭代优化提高LLM代码生成质量的工具"""
    
    def __init__(self, model):
        self.model = model
        self.history = []
    
    def optimize(self, initial_prompt, test_cases, max_iterations=5):
        """
        优化提示词以提高代码生成准确率
        :param initial_prompt: 初始提示词
        :param test_cases: 测试用例集合
        :param max_iterations: 最大迭代次数
        :return: 优化后的提示词
        """
        best_prompt = initial_prompt
        best_score = 0
        
        for i in range(max_iterations):
            # 测试当前提示词
            score = self._evaluate_prompt(best_prompt, test_cases)
            print(f"Iteration {i+1}: Score {score:.2%}")
            
            if score > best_score:
                best_score = score
                self.history.append(best_prompt)
            
            # 生成改进建议
            feedback = self._get_feedback(best_prompt, test_cases)
            best_prompt = self._refine_prompt(best_prompt, feedback)
        
        return best_prompt
    
    def _evaluate_prompt(self, prompt, test_cases):
        """评估提示词效果"""
        correct = 0
        for case in test_cases:
            generated = self.model.generate(prompt + case['input'])
            if self._check_output(generated, case['output']):
                correct += 1
        return correct / len(test_cases)
    
    def _get_feedback(self, prompt, test_cases):
        """分析失败案例生成改进建议"""
        return "添加更多示例说明"  # 简化示例
    
    def _refine_prompt(self, prompt, feedback):
        """根据反馈改进提示词"""
        return f"{prompt}\n注意：{feedback}"  # 简化示例

# 使用示例
# optimizer = PromptOptimizer(model)
# optimized_prompt = optimizer.optimize("编写Python代码", test_cases)

  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
# 示例3：多模型集成系统
class MultiModelCodeGenerator:
    """集成多个LLM提高代码生成质量的系统"""
    
    def __init__(self, models):
        self.models = models
        self.performance = {model.name: 0 for model in models}
    
    def generate_with_voting(self, prompt, num_solutions=3):
        """
        通过多模型投票生成代码
        :param prompt: 编程问题描述
        :param num_solutions: 每个模型生成的方案数
        :return: 得票最高的代码方案
        """
        solutions = []
        
        # 收集所有模型的解决方案
        for model in self.models:
            for _ in range(num_solutions):
                code = model.generate_code(prompt)
                solutions.append((model.name, code))
        
        # 简单投票机制（实际应用中可以使用更复杂的评估）
        votes = {}
        for name, code in solutions:
            code_hash = hash(code)
            if code_hash not in votes:
                votes[code_hash] = {'code': code, 'count': 0}
            votes[code_hash]['count'] += 1
            self.performance[name] += 1
        
        # 返回得票最高的方案
        best = max(votes.values(), key=lambda x: x['count'])
        return best['code']
    
    def get_performance_stats(self):
        """获取各模型性能统计"""
        total = sum(self.performance.values())
        return {name: count/total for name, count in self.performance.items()}

# 使用示例
# models = [ModelA(), ModelB(), ModelC()]
# generator = MultiModel


---
## 案例研究


### 1：某中型金融科技公司的内部工具重构

 1：某中型金融科技公司的内部工具重构

**背景**:
该公司拥有一套维护了 5 年的遗留 Java 支付网关系统，代码逻辑复杂且缺乏文档。团队计划将其核心逻辑迁移至 Go 语言以提升性能，但仅有两名熟悉旧系统的资深开发人员，且他们无暇兼顾日常开发与重写工作。

**问题**:
人工重写代码耗时长，且容易在复杂的业务逻辑转换中引入错误。初级开发人员因不熟悉旧业务逻辑，无法通过简单的 Prompt 让大模型一次性生成正确的代码，导致生成的代码可用率低于 40%，大量时间耗费在修正大模型产生的幻觉代码上。

**解决方案**:
技术团队引入了基于“Harness”理念的自动化评估与迭代框架。他们不再依赖单一的大模型对话，而是构建了一个包含 500 个旧系统单元测试用例的“测试驱动”评估闭环。通过该框架，让 4 个不同的开源大模型（如 Llama 3 和 DeepSeek Coder）并行生成代码，并利用测试用例进行即时验证与反馈。在一个下午的时间内，团队完成了对这 4 个模型在特定代码库上的微调与提示词工程优化。

**效果**:
通过 Harness 框架的筛选与反馈，最佳模型的代码通过率从 40% 提升至 85%。初级开发人员只需负责审核由模型生成并通过测试的代码片段，而非从零编写。原本预计需要 3 个月的重构工作，在 3 周内即完成了核心模块上线，且未出现任何生产环境事故。

---



### 2：跨国电商企业的自动化测试脚本生成

 2：跨国电商企业的自动化测试脚本生成

**背景**:
该企业业务覆盖全球，UI 界面元素随地区和营销活动频繁变动。为了保证发布质量，QA 团队需要维护庞大的 Selenium 自动化测试脚本库。由于前端框架的频繁升级，大量测试脚本每周都会失效。

**问题**:
编写和维护这些脚本是重复且枯燥的工作，QA 工程师缺乏足够的时间去探索更深层次的自动化测试策略。此前尝试使用通用的 GPT-4 模型生成脚本，但由于模型无法连接实时的 UI 元素库，生成的选择器经常因页面变动而失效。

**解决方案**:
团队搭建了一个基于 Harness 的评估流水线。他们不直接训练模型，而是将 UI 的实时 DOM 结构注入到 Prompt 上下文中，并使用一套“脚本有效性验证器”作为 Harness。在一个下午的实验中，他们对包括 GPT-4o、Claude 3.5 Sonnet 在内的 15 个 LLM 进行了对比测试。Harness 自动运行生成的脚本，记录失败原因，并动态调整 Prompt 策略（例如从 CSS 选择器切换为 XPath 或文本定位）。

**效果**:
最终筛选出最适合该电商 UI 结构的模型与参数组合，测试脚本生成的准确率达到 92%。QA 团队的工作重心从“编写脚本”转变为“审核与执行”，回归测试的覆盖率提升了 3 倍，且在最近一次大促前的版本迭代中，测试准备时间从 5 天缩短至 1 天。

---



### 3：SaaS 创业公司的遗留代码库文档化

 3：SaaS 创业公司的遗留代码库文档化

**背景**:
一家成立 4 年的 B2B SaaS 公司，其核心产品由 3 位联合创始人开发，代码中存在大量隐式的业务规则和“魔术数字”。随着团队扩张至 20 人，新入职的开发人员难以理解代码逻辑，导致新功能开发频繁引入 Bug。

**问题**:
创始人无力口述所有业务细节，而人工编写技术文档不仅进度缓慢，且极易与代码实现脱节。团队曾尝试让大模型阅读代码并生成文档，但生成的内容往往过于泛泛，缺乏对特定业务场景的深度理解。

**解决方案**:
技术主管构建了一个文档质量评估 Harness。该工具不仅检查文档的通顺度，更重要的是验证文档与代码执行路径的一致性。在一个下午内，团队利用该框架对多个专门针对代码分析的开源模型进行了测试。Harness 通过模拟代码执行，强制模型修正那些“看起来合理但与实际逻辑不符”的文档描述。

**效果**:
成功将 80% 的核心业务模块补充了高精度文档。新员工 Onboarding 时间从 4 周缩短至 2 周。更重要的是，该 Harness 被保留下来，每次代码合并时，系统会自动提示相关文档是否需要更新，确保了代码与文档的长期一致性。

---
## 最佳实践

## 最佳实践指南

### 1. 建立标准化评估基准
**核心逻辑**：避免主观偏差，建立客观量化标准。
*   **操作步骤**：
    1.  构建覆盖多语言与难度的测试集。
    2.  定义通过率、语法准确性等评分指标。
    3.  记录所有模型的初始基准分数。
*   **关键注意**：严格防止测试集数据泄露至训练集，避免数据污染。

### 2. 深度优化提示词工程
**核心逻辑**：通过结构化指令引导模型输出，提升一致性。
*   **操作步骤**：
    1.  设计包含背景、约束与输出格式的模板。
    2.  明确指定编码规范（如缩进、命名）及依赖库。
    3.  利用“少样本”示例引导模型行为。
*   **关键注意**：提示词策略需随模型版本迭代持续审查。

### 3. 构建自动化评估框架
**核心逻辑**：以自动化替代低效的手动测试，实现快速反馈。
*   **操作步骤**：
    1.  开发脚本自动调用 LLM API 并提交任务。
    2.  集成代码执行环境，捕获运行结果与报错。
    3.  建立可视化仪表板对比分析数据。
*   **关键注意**：必须实施沙箱隔离，防范恶意代码破坏系统。

### 4. 实施迭代式 A/B 测试
**核心逻辑**：控制变量，精准定位性能提升的归因。
*   **操作步骤**：
    1.  每次仅改变单一变量（如温度参数或特定指令）。
    2.  保持其他配置一致，对比对照组与实验组。
    3.  分析得分差异以验证改动有效性。
*   **关键注意**：确保样本量充足，排除随机波动干扰。

### 5. 引入后处理纠错机制
**核心逻辑**：在模型外层构建防护网，提升系统鲁棒性。
*   **操作步骤**：
    1.  集成静态代码分析工具检查语法。
    2.  利用正则或修正模型自动修复简单错误。
    3.  将测试失败反馈给模型进行重生成。
*   **关键注意**：平衡准确性增益与响应延迟之间的关系。

### 6. 强化外部工具集成
**核心逻辑**：改变交互方式（Harness）比模型本身更能提升性能。
*   **操作步骤**：
    1.  赋予模型访问文档与搜索引擎的能力。
    2.  允许模型在沙箱中运行代码并根据报错自我修正。
    3.  建立反馈循环，将运行结果作为上下文输入。
*   **关键注意**：严格管控外部工具调用权限，保障数据安全。

---
## 学习要点

- 仅通过改进评估框架，无需重新训练模型，即可在一天内将15个主流大模型的代码生成准确率平均提升5-10%。
- 引入“测试用例生成”和“代码自我修正”的迭代循环，是提升模型表现最有效的单一技术手段。
- 框架的核心改进在于从静态的“一次性生成”转变为动态的“多轮对话与反馈”机制。
- 该方法证明了模型性能的瓶颈往往不在于模型权重本身，而在于如何通过Prompt工程引导其思考。
- 统一的评估标准显示，开源模型（如DeepSeek Coder）在特定优化框架下可以匹敌或超越闭源模型（如GPT-4）。
- 实现这一显著提升不需要额外的训练数据或算力投入，仅需优化推理阶段的逻辑控制。

---
## 常见问题


### 1: 这篇文章主要讨论了什么技术或方法？

1: 这篇文章主要讨论了什么技术或方法？

**A**: 这篇文章的核心主题是关于“评估框架”对大语言模型（LLM）性能的影响。文章描述了一个实验，研究者在同一个下午测试了 15 个不同的 LLM（包括 GPT-4、Llama 2、Claude 等）。实验的关键在于，他们并没有修改这些模型本身，也没有改变提示词，而是仅仅更换了用于运行代码测试的底层工具或框架。结果显示，通过切换到一个更优化的测试工具，所有模型的代码生成成功率都得到了显著提升。这说明了模型的表现很大程度上取决于评估工具的准确性和稳定性。

---



### 2: 为什么仅仅更换“工具”就能提高模型的得分？

2: 为什么仅仅更换“工具”就能提高模型的得分？

**A**: 这主要归因于评估环境的精确度和鲁棒性。在代码生成任务中，模型生成的代码通常需要在沙箱环境中运行测试用例以验证是否正确。如果使用的测试工具存在以下问题，模型就会被误判为失败：
1.  **执行超时设置不合理**：如果工具给的时间太短，正确的代码可能因为运行稍慢而被杀死。
2.  **环境依赖缺失**：某些模型生成的代码可能引用了特定的库，如果工具环境没有预装这些库，代码就会报错。
3.  **解析错误**：工具在提取模型输出的代码块时可能不够智能，导致将解释性文字误认为代码，从而无法运行。
文章中提到的“Harness”解决或优化了这些问题，从而让模型的真实能力得以体现。

---



### 3: 文章中提到的“Harness”具体指什么？

3: 文章中提到的“Harness”具体指什么？

**A**: 在这篇文章的语境中，“Harness”指的是一套用于评估 LLM 代码生成能力的软件框架或基础设施。它负责接收模型的输出，解析其中的代码，在隔离的环境中编译或运行该代码，输入预设的测试用例，并判断输出是否与预期一致。作者通过构建或切换到一个更严谨、兼容性更好的 Harness，排除了因环境配置不当或工具缺陷导致的“假阴性”结果，从而得出了“模型表现变好了”的结论。

---



### 4: 这个实验对开发者选择 LLM 有什么启示？

4: 这个实验对开发者选择 LLM 有什么启示？

**A**: 这个实验给开发者的主要启示是：在基准测试中，不仅要看模型的排名，还要关注评估方法的有效性。
1.  **基准测试的可靠性**：一个模型在某个榜单上得分低，可能不代表模型能力差，而是测试工具本身有缺陷。
2.  **工具的重要性**：在实际应用中，构建一个能够容忍语法小错误、拥有丰富依赖库且执行稳定的评估/执行框架，与选择强大的模型同样重要。
3.  **开源模型的潜力**：通过优化测试工具，许多开源模型的表现可能比传统榜单上显示的要好得多，这意味着开发者可以利用更小的开源模型达到预期效果，从而降低成本。

---



### 5: 文章是否改变了模型的参数或训练数据？

5: 文章是否改变了模型的参数或训练数据？

**A**: 没有。文章标题明确指出“Only the Harness Changed”（只有工具改变了）。这意味着模型的权重、参数、训练数据以及微调状态完全没有发生任何变化。模型在回答问题时的“智力”水平与之前是一样的。变化的仅仅是外部衡量这种智力的“尺子”。这就像同一个学生做同一张试卷，如果之前的阅卷系统有误判（例如因为字迹潦草或扫描不清），换了一个更精准的阅卷机后，分数自然就提高了。

---



### 6: 这种“更换工具”带来的提升幅度有多大？

6: 这种“更换工具”带来的提升幅度有多大？

**A**: 根据文章的描述，这种提升是显著且普遍的。对于所有测试的 15 个模型，通过切换到新的 Harness，其代码生成的通过率都实现了增长。这表明旧的评估工具可能普遍存在某些系统性缺陷（如对特定库的支持不足或超时机制过严），导致所有模型的得分都被人为压低了。这种提升不是针对某个特定模型的优化，而是整个评估流程的优化。

---



### 7: Hacker News 社区对这篇文章的主要观点是什么？

7: Hacker News 社区对这篇文章的主要观点是什么？

**A**: Hacker News 上的讨论通常集中在技术细节和实验的可复现性上。针对这篇文章，评论区的常见观点包括：
1.  **验证了“垃圾进，垃圾出”**：强调评估数据质量和方法论的重要性。
2.  **对现有排行榜的质疑**：许多开发者指出，目前许多 LLM 排行榜缺乏统一的标准，导致不同模型之间难以进行公平比较。
3.  **工程实践的价值**：讨论了在实际落地 LLM 应用时，后端的工程化处理（如沙箱环境、重试机制、代码清洗）往往比单纯追求模型参数更能决定最终效果。

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**: 在文中提到的实验中，为什么仅仅通过更换“Harness”（测试框架/评估工具）就能让所有 15 个 LLM 的代码生成能力得到显著提升？请列举出三个可能导致旧测试环境低估模型能力的具体技术原因。

### 提示**: 思考一下在编写代码提示词时，哪些微小的环境差异会导致模型输出无法通过测试。例如：上下文窗口的限制、提示词的格式、或者对模型输出结果的解析方式。

### 

---
## 引用

- **原文链接**: [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 的分析。

---


---
## 站内链接

- 分类： [大模型](/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B/) / [AI 工程](/categories/ai-%E5%B7%A5%E7%A8%8B/)
- 标签： [LLM](/tags/llm/) / [代码生成](/tags/%E4%BB%A3%E7%A0%81%E7%94%9F%E6%88%90/) / [基准测试](/tags/%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95/) / [评估框架](/tags/%E8%AF%84%E4%BC%B0%E6%A1%86%E6%9E%B6/) / [模型微调](/tags/%E6%A8%A1%E5%9E%8B%E5%BE%AE%E8%B0%83/) / [HumanEval](/tags/humaneval/) / [LLM 评估](/tags/llm-%E8%AF%84%E4%BC%B0/) / [AI 开发](/tags/ai-%E5%BC%80%E5%8F%91/)
- 场景： [大语言模型](/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/20260213-hacker_news-improving-15-llms-at-coding-in-one-afternoon-only--10/)
- [让 Claude 编写 CUDA 内核并指导开源模型](/posts/20260129-blogs_podcasts-we-got-claude-to-build-cuda-kernels-and-teach-open-8/)
- [Claude Code 每日基准测试：追踪模型性能退化](/posts/20260129-hacker_news-claude-code-daily-benchmarks-for-degradation-track-3/)
- [让 Claude 编写 CUDA 内核并指导开源模型](/posts/20260129-blogs_podcasts-we-got-claude-to-build-cuda-kernels-and-teach-open-7/)
- [AGENTS.md 架构在智能体评估中超越 Skills 技能](/posts/20260130-hacker_news-agentsmd-outperforms-skills-in-our-agent-evals-5/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*

仅更换测试框架，一下午提升15个大模型代码能力

仅更换测试框架，一下午提升15个大模型代码能力

基本信息

导语

评论

文章中心观点

深入评价

1. 内容深度与论证严谨性

2. 实用价值

3. 创新性

4. 可读性与逻辑性

5. 行业影响

支撑理由与反例

可验证的检查方式

总结与建议

代码示例

应用场景

大语言模型

AI/ML项目