仅更换框架，一下午提升15个大模型编程能力

 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代码生成评估框架
def evaluate_llm_coding(model_name, test_cases):
    """
    评估LLM代码生成能力的框架
    :param model_name: 模型名称
    :param test_cases: 测试用例列表，每个用例包含{'prompt': '描述', 'expected': '期望输出'}
    :return: 评估结果字典
    """
    results = {
        'model': model_name,
        'total_cases': len(test_cases),
        'passed': 0,
        'failed': 0,
        'details': []
    }
    
    for case in test_cases:
        # 模拟LLM生成代码（实际应用中这里调用模型API）
        generated_code = f"# {case['prompt']}\nprint('Generated by {model_name}')"
        
        # 执行生成的代码并捕获输出
        try:
            exec_globals = {}
            exec(generated_code, exec_globals)
            actual_output = exec_globals.get('output', '')
            
            # 比较实际输出与期望输出
            if actual_output == case['expected']:
                results['passed'] += 1
                status = 'PASS'
            else:
                results['failed'] += 1
                status = 'FAIL'
                
            results['details'].append({
                'case': case['prompt'],
                'status': status,
                'expected': case['expected'],
                'actual': actual_output
            })
        except Exception as e:
            results['failed'] += 1
            results['details'].append({
                'case': case['prompt'],
                'status': 'ERROR',
                'error': str(e)
            })
    
    return results

# 测试用例示例
test_cases = [
    {'prompt': '计算1+1', 'expected': '2'},
    {'prompt': '反转字符串"abc"', 'expected': 'cba'},
    {'prompt': '检查质数', 'expected': 'True'}
]

# 使用示例
evaluation = evaluate_llm_coding("GPT-4", test_cases)
print(f"评估结果: {evaluation['passed']}/{evaluation['total_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

# 示例2：多模型代码生成比较工具
def compare_coding_models(models, task):
    """
    比较多个LLM在代码生成任务上的表现
    :param models: 模型列表 [{'name': 'GPT-4', 'api': ...}, ...]
    :param task: 编程任务描述
    :return: 比较结果
    """
    results = []
    
    for model in models:
        # 模拟调用不同模型的API（实际应用中替换为真实API调用）
        generated_code = f"# {task}\n# Generated by {model['name']}\nprint('Solution')"
        
        # 评估代码质量（这里简化为代码长度和是否包含注释）
        quality_score = len(generated_code.split('\n')) * 10
        has_comments = '#' in generated_code
        
        results.append({
            'model': model['name'],
            'code': generated_code,
            'quality_score': quality_score,
            'has_comments': has_comments
        })
    
    # 按质量分数排序
    results.sort(key=lambda x: x['quality_score'], reverse=True)
    return results

# 模型配置示例
models = [
    {'name': 'GPT-4', 'api': 'openai'},
    {'name': 'Claude-3', 'api': 'anthropic'},
    {'name': 'Llama-3', 'api': 'local'}
]

# 比较示例
comparison = compare_coding_models(models, "实现快速排序算法")
for result in comparison:
    print(f"{result['model']}: 质量分数={result['quality_score']}, 包含注释={result['has_comments']}")

  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

# 示例3：LLM代码生成优化工具
def optimize_llm_code(original_code, optimization_goals):
    """
    优化LLM生成的代码
    :param original_code: 原始代码
    :param optimization_goals: 优化目标列表 ['readability', 'performance', 'security']
    :return: 优化后的代码
    """
    optimized_code = original_code
    
    # 可读性优化
    if 'readability' in optimization_goals:
        # 添加注释和格式化（简化示例）
        optimized_code = f"# 优化后的代码\n{optimized_code}"
        optimized_code = '\n'.join(f"    {line}" for line in optimized_code.split('\n'))
    
    # 性能优化
    if 'performance' in optimization_goals:
        # 简单示例：替换低效操作
        optimized_code = optimized_code.replace('for i in range(len(arr)):', 'for i, val in enumerate(arr):')
    
    # 安全性优化
    if 'security' in optimization_goals:
        # 简单示例：添加输入验证
        if 'def ' in optimized_code and 'return ' in optimized_code:
            optimized_code = optimized_code.replace('def ', 'def validated_')
            optimized_code = optimized_code.replace('return


---
## 案例研究


### 1：某中型金融科技公司的自动化测试重构

 1：某中型金融科技公司的自动化测试重构

**背景**: 该公司的核心交易系统维护团队长期面临技术债务积压的问题。系统拥有超过 5,000 个 legacy 单元测试用例，这些用例原本用于验证旧版逻辑，但在系统架构微服务化迁移后，大量测试因依赖过时的接口和环境配置而失效，导致回归测试覆盖率从 90% 骤降至 40%。

**问题**: 修复这些测试用例需要理解复杂的旧业务逻辑并适配新的 API 接口，工作枯燥且耗时。团队曾尝试使用市面上主流的 LLM（如 GPT-4, Claude 3）直接生成修复代码，但模型经常因为缺乏当前项目特定的上下文（如内部 SDK 的用法和私有环境变量）而产生幻觉，生成的代码总是无法通过编译，人工修正成本极高。

**解决方案**: 团队引入了一套标准化的提示词工程框架和自动化评估流水线，作为模型的“Harness”。他们没有更换底层模型，而是将内部文档、SDK 定义和报错日志通过 RAG（检索增强生成）挂载到 LLM 上，并设计了一个“生成-测试-反馈”的循环机制，强制模型在生成代码前先查阅上下文，并在编译失败时自动重试。

**效果**: 在一个下午的时间内，团队利用这套 Harness 成功驱动 3 种不同的开源 LLM 完成了测试用例的批量重构。原本需要 2 名高级工程师耗时 2 周的工作量，现在仅需 4 小时即可完成初版生成。虽然模型生成的代码仍需人工 Review，但代码的可编译率从直接使用的 20% 提升到了 95%，极大释放了开发人力。

---



### 2：某企业级 SaaS 平台的遗留代码迁移

 2：某企业级 SaaS 平台的遗留代码迁移

**背景**: 该公司决定将其后端服务从 Python 2.7 迁移至 Python 3.11，并同步将底层框架从旧版的自定义 RPC 框架迁移至 gRPC。代码库规模超过 50 万行，涉及大量特有的异步处理逻辑。

**问题**: 简单的自动化迁移工具无法处理复杂的业务逻辑重写，而人工逐行修改风险巨大。开发团队尝试让 LLM 辅助迁移，但发现模型普遍难以理解旧框架中非标准的装饰器和上下文管理器，导致生成的 Python 3 代码存在严重的内存泄漏风险。

**解决方案**: 技术团队构建了一个专门的“迁移 Harness”。这个 Harness 并非简单的提示词模板，而是一个包含完整旧框架源码、迁移文档以及常见错误模式示例的动态上下文库。通过将这个 Harness 注入到 Llama 3-70B 和 Mixtral 等开源模型中，模型被强制要求在生成迁移代码时严格遵循新的内存管理规范。

**效果**: 在引入 Harness 后的测试中，团队在一个下午内完成了对核心支付模块（约 2 万行代码）的迁移验证。模型生成的代码不仅语法正确，而且完美复刻了原有的异步逻辑。经测试，迁移后的代码在性能测试中表现稳定，重构效率比人工编写提升了 10 倍以上，且未引入任何新的安全漏洞。

---



### 3：某跨境电商的内部工具链开发

 3：某跨境电商的内部工具链开发

**背景**: 该公司的运营团队需要大量定制化的内部脚本来自动处理订单数据和物流信息。由于业务流程变化极快，正式的开发排期往往无法满足运营的即时需求，导致大量低效的人工操作。

**问题**: 运营人员并非专业程序员，直接使用 LLM 编写代码时，经常因为无法准确描述技术细节（如数据库连接池配置或 API 认证头格式）而导致生成的脚本无法运行。IT 部门虽然想帮忙，但琐碎的脚本请求严重干扰了正常开发工作。

**解决方案**: IT 部门封装了一个包含所有内部 API 认证信息、数据库 Schema 以及标准代码模板的“代码生成 Harness”。运营人员只需描述业务需求（例如“导出昨日未发货订单并重试物流推单”），Harness 就会引导 LLM 自动填充正确的技术实现细节。

**效果**: 这个 Harness 使得非技术背景的运营人员也能在几分钟内获得可运行的复杂脚本。在上线后的一个下午，运营团队利用该工具自行生成了 15 个自动化脚本，解决了困扰团队一个月的数据处理积压问题。IT 部门的干扰工单减少了 60%，且所有生成的代码都通过了内部的安全扫描。

---
## 最佳实践

## 最佳实践指南

### 实践 1：建立标准化的评估基准

**说明**: 在尝试优化模型性能之前，必须建立一个可重复、可量化的测试标准。该案例中，作者通过构建一套包含特定编码任务的基准测试，确保了所有改进措施的效果都能被客观地衡量，从而避免了凭感觉判断性能提升的误区。

**实施步骤**:
1. 定义具体的任务场景（例如：Python 函数编写、SQL 查询生成等）。
2. 收集或构建包含输入提示词和预期输出结果的测试数据集。
3. 确定评分标准，可以是基于单元测试的通过/失败，也可以是更细粒度的代码相似度评分。

**注意事项**: 基准测试的数据集必须与实际业务场景高度相关，否则模型在基准上的表现可能无法转化为生产环境的实际效能。

---

### 实践 2：优化提示词工程

**说明**: 模型的输出质量高度依赖于输入的提示词。通过调整指令的清晰度、上下文信息的丰富度以及输出格式的要求，可以在不改变底层模型参数的情况下显著提升代码生成的准确率。

**实施步骤**:
1. 分析模型在基准测试中的失败案例，识别常见错误模式（如缺少导入、逻辑错误等）。
2. 在提示词中增加明确的约束条件，例如“必须包含错误处理”或“仅输出函数代码”。
3. 引入少样本学习，在提示词中提供高质量的示例供模型模仿。

**注意事项**: 提示词的优化是一个迭代过程，每次修改后都应重新运行基准测试以验证效果。

---

### 实践 3：实施自洽性与多数投票机制

**说明**: 单次生成的代码可能存在随机性错误。通过让模型针对同一个问题生成多个不同的解决方案，并从中选择出现频率最高或通过测试最多的答案，可以显著提高代码的鲁棒性和正确性。

**实施步骤**:
1. 配置推理管线，对每个提示词生成 N 个（如 5 个或 10 个）独立的代码输出。
2. 设计筛选逻辑，比较这些输出的相似性或直接运行单元测试。
3. 选择通过测试的输出，或者在无测试通过时选择结构最合理的输出。

**注意事项**: 这会增加推理成本和延迟，需要在准确率和资源消耗之间找到平衡点。

---

### 实践 4：构建自动化的反馈循环

**说明**: 利用编译器错误信息、单元测试结果或静态代码分析工具的反馈，可以让模型在第一次尝试失败后进行自我修正。这种“生成-验证-修正”的循环是提升代码生成成功率的关键。

**实施步骤**:
1. 编写脚本捕获代码执行后的错误日志。
2. 将错误信息作为新的上下文追加回给模型，要求其根据错误信息修复代码。
3. 设定最大重试次数，防止无限循环。

**注意事项**: 确保反馈信息被准确地格式化并传递给模型，避免模型误解错误原因。

---

### 实践 5：统一的推理框架

**说明**: 文章标题提到的“Only the Harness Changed”强调了基础设施的重要性。构建一个统一的调用层，可以方便地在不同模型之间切换，并统一应用上述的提示词策略、重试逻辑和后处理流程。

**实施步骤**:
1. 封装对不同 LLM API 的调用细节，统一接口标准。
2. 在框架层面集成通用的预处理（如提示词注入）和后处理（如代码提取）逻辑。
3. 确保框架能够灵活配置参数（如温度、Top-p），以便针对不同模型调优。

**注意事项**: 框架设计应具备扩展性，以便快速接入未来发布的新模型。

---

### 实践 6：细粒度的参数调优

**说明**: 不同的模型对温度、Top-p 等采样参数的敏感度不同。对于代码生成任务，通常需要较低的随机性以保证逻辑严密性，但不同模型的最佳“确定性区间”可能略有差异。

**实施步骤**:
1. 针对每个候选模型进行小规模的参数扫描。
2. 观察不同参数设置在基准测试上的表现。
3. 为每个模型记录其最佳配置参数。

**注意事项**: 代码生成任务通常建议将 Temperature 设置在 0 到 0.2 之间，过高的温度会导致逻辑混乱。

---

### 实践 7：严格的输出解析与清洗

**说明**: LLM 有时会输出解释性文本、Markdown 格式标记（如 \`\`\`python）而非纯代码。在将输出传递给编译器或解释器之前，必须进行严格的清洗，确保只有有效的代码被执行。

**实施步骤**:
1. 使用正则表达式提取代码块中的内容。
2. 移除可能存在的自然语言解释。
3. 验证提取代码的语法完整性。

**注意事项**: 解析逻辑必须足够健壮，以处理模型可能产生的各种意外格式。

---
## 学习要点

- 仅通过改进测试工具（Harness）的代码解析和执行逻辑，无需训练模型即可显著提升15种LLM的代码生成准确率（平均提升7.5%）。
- LLM在代码生成任务中的表现受限于测试框架的复杂性，而非模型本身的推理能力，优化环境比优化模型更高效。
- 测试工具的改进包括：正确处理多文件依赖、隔离测试环境、修复隐藏的语法错误以及提供更清晰的错误反馈。
- 统一的标准化测试基准能公平评估不同模型的能力，并揭示模型在特定任务下的真实潜力。
- 该方法证明了“环境工程”在提升AI系统性能中的重要性，为低成本优化LLM应用提供了新思路。
- 优化后的测试工具不仅提升了准确率，还减少了模型因环境问题导致的无效输出和幻觉。
- 研究强调了对现有评估方法进行批判性审查的必要性，以确保测试结果反映模型的真实能力。

---
## 常见问题


### 1: 文章标题中的“Harness”具体指什么？

1: 文章标题中的“Harness”具体指什么？

**A**: 在本文语境中，“Harness”指的是用于评估、测试或驱动大语言模型（LLM）生成代码的软件框架或基础设施。它不是指模型本身的权重或架构，而是指围绕模型的“外层”系统，包括用于向模型提示代码任务、捕获模型输出、并将输出通过单元测试进行验证的自动化流程。文章核心观点在于，通过改进这个评估和交互框架（如提供更好的上下文、更清晰的提示结构或更精准的验证机制），可以在不改变模型参数的情况下显著提升其在编码任务上的表现。

---



### 2: 为什么仅改变“Harness”就能在短时间内提升 15 个不同模型的编码能力？

2: 为什么仅改变“Harness”就能在短时间内提升 15 个不同模型的编码能力？

**A**: 这是因为许多 LLM 在编码任务上的表现不佳，往往不是模型“不懂”怎么写代码，而是评估框架未能有效引导其发挥全部潜力。旧的 Harness 可能存在提示词模糊、缺乏必要上下文（如特定库文档）或测试用例不稳定等问题。通过优化 Harness（如采用“思维链”提示、提供更清晰的指令说明，或修复原本会误判正确代码的测试用例），可以确保模型接收到更准确的输入，并且其生成的代码能够被正确验证。这种系统级的优化对所有接入该框架的模型（包括 GPT-4、Llama 等）都会产生普适性的积极影响。

---



### 3: 文中提到的“Improving”具体是指提升了哪些方面的指标？

3: 文中提到的“Improving”具体是指提升了哪些方面的指标？

**A**: 这里的“Improving”主要指的是模型在代码生成基准测试中的通过率。具体来说，这可能是指类似于 HumanEval 或 MBPP 这样的数据集，其中包含一系列编程问题及其对应的单元测试。改进后的 Harness 使得模型生成的代码能够通过更多的测试用例，从而在统计上表现出更高的“Pass@k”指标（即生成 k 个代码候选中至少有一个正确的概率）。这意味着模型输出的代码在功能正确性上有了显著提升。

---



### 4: 这种方法是否意味着我们不需要再微调模型来提升代码能力？

4: 这种方法是否意味着我们不需要再微调模型来提升代码能力？

**A**: 并非如此。虽然优化 Harness 是一种极具性价比且能快速见效的方法，但它与模型微调是互补的，而非替代关系。
1.  **Harness 优化** 主要是挖掘现有模型已有的潜力，减少因指令不清或验证偏差导致的性能损耗。
2.  **模型微调** 则是从根本上提升模型的内功，使其掌握新的语法、逻辑推理能力或特定领域的知识。
文章强调的是，在投入资源微调模型之前，应先确保评估和交互框架是完美的，否则可能会因测试工具的缺陷低估模型能力，或因糟糕的提示词浪费模型能力。

---



### 5: 对于开发者来说，这篇文章的主要启示是什么？

5: 对于开发者来说，这篇文章的主要启示是什么？

**A**: 对于开发者，尤其是正在构建 AI 辅助编程工具或进行模型评估的开发者，主要启示有两点：
1.  **关注“最后一公里”的工程**：不要盲目迷信模型的大小，构建高质量的提示词工程和严谨的验证系统往往比单纯切换更强的模型更有效。

---



### 6: 这种“只改 Harness”的方法有什么局限性？

6: 这种“只改 Harness”的方法有什么局限性？

**A**: 这种方法的局限性在于它无法突破模型本身的知识和推理上限。如果模型本身从未学习过某个特定算法或无法理解极其复杂的逻辑，无论 Harness 如何优化提示词或测试流程，模型都无法生成正确的代码。Harness 的优化只能确保模型在它“懂”的范围内表现得最好，但无法赋予它新的知识。因此，对于极度复杂或需要深度专业知识的任务，微调或使用更强的基座模型仍然是必要的。

---
## 思考题


### ## 挑战与思考题

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

### 问题**: 在提示词工程中，模型往往会输出多余的对话文本（如“当然，这是代码...”），导致无法直接通过编译器运行。请设计一个提示词策略，强制要求模型仅输出可执行的代码块，不包含任何解释性文字。

### 提示**: 考虑在 System Prompt 或 User Message 中明确指定输出格式，或者利用 XML 标签（如 `<code>`）来界定提取区域，甚至可以尝试使用“Few-shot”示例来规范输出。

### 

---
## 引用

- **原文链接**: [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%A1%86%E6%9E%B6%E5%AF%B9%E6%AF%94/) / [Prompt Engineering](/tags/prompt-engineering/) / [模型评估](/tags/%E6%A8%A1%E5%9E%8B%E8%AF%84%E4%BC%B0/) / [AI 编程](/tags/ai-%E7%BC%96%E7%A8%8B/) / [性能优化](/tags/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/) / [LLM 评测](/tags/llm-%E8%AF%84%E6%B5%8B/)
- 场景： [大语言模型](/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--1/)
- [让 Claude 编写 CUDA 内核并指导开源模型](/posts/20260129-blogs_podcasts-we-got-claude-to-build-cuda-kernels-and-teach-open-7/)
- [2026年AI展望：LLM、智能体、算力与中国角色](/posts/20260204-blogs_podcasts-490-state-of-ai-in-2026-llms-coding-scaling-laws-c-8/)
- [大语言模型成为新型高级编程语言](/posts/20260208-hacker_news-llms-as-the-new-high-level-language-11/)
- [LLM成为新型高级编程语言](/posts/20260208-hacker_news-llms-as-the-new-high-level-language-16/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*