SlopCodeBench：渐进披露机制下的大语言模型代码重构能力评估实战

最近在评估大语言模型（LLM）的代码生成与理解能力时，你是否发现很多基准测试（如 HumanEval、MBPP）更像是“开卷考试”？它们通常提供一个清晰、完整的函数签名和描述，模型只需“填空”即可。然而，真实世界的编程任务，尤其是接手遗留代码或进行系统重构时，我们面对的信息往往是模糊、不完整且逐步展开的。这正是SlopCodeBench这一新兴基准试图模拟的核心场景。

SlopCodeBench 并非另一个简单的代码补全测试集。它通过“渐进披露”（Progressive Disclosure）的机制，专门设计来评估 LLM 在面对信息逐步完善的代码片段时，如何进行有效的代码重构和推理。这对于衡量模型在真实软件开发、特别是维护和重构任务中的实际能力至关重要。本文将深入解析 SlopCodeBench 的设计理念、评估方法，并通过实战示例展示如何利用它来测试和提升 LLM 的代码重构能力，为开发者、研究人员以及关注 AI 编程助手效能的朋友提供一份详尽的指南。

1. 理解 SlopCodeBench：为何重构能力是 LLM 的试金石？

在深入技术细节前，我们首先要理解两个核心概念：代码重构与渐进披露，以及它们为何对 LLM 构成挑战。

1.1 代码重构：不仅仅是重命名变量

代码重构是在不改变软件外部行为的前提下，改善其内部结构的过程。这远不止于修改变量名或格式化代码。真正的重构包括：

• 提取方法/函数：将一段代码封装成独立的函数，提高可复用性。
• 消除重复：识别并合并重复的逻辑。
• 简化条件表达式：将复杂的if-else链条转化为更清晰的结构。
• 引入设计模式：在适当的时候应用策略、工厂等模式。
• 改善模块间依赖：降低耦合度，提高内聚性。

重构要求开发者深刻理解代码的意图（这段代码要做什么）、上下文（它如何被调用、依赖什么）以及潜在缺陷（边界条件、异常处理）。这对于 LLM 来说，需要强大的代码理解、逻辑推理和模式识别能力。

1.2 渐进披露：模拟真实世界的模糊性

“渐进披露”是 SlopCodeBench 的核心创新。在真实开发中，我们很少一次性获得所有信息。例如：

1. 你首先看到一个复杂的、难以理解的函数（“Slop”代码）。
2. 然后，你可能会看到一些调用这个函数的示例，从而推断其预期行为。
3. 接着，你或许会得到一些自然语言描述或注释。
4. 最后，你可能需要参考相关的 API 文档或代码规范。

SlopCodeBench 模拟了这一过程。它不会一次性给出完美的任务描述，而是分阶段、有控制地释放信息，迫使模型必须像人类开发者一样，整合碎片化信息，逐步构建对代码任务的理解，并最终完成重构。

1.3 SlopCodeBench 的目标与意义

SlopCodeBench 旨在填补现有代码基准的空白，其目标包括：

• 评估深度理解：测试模型是否能透过糟糕的代码表面，理解其底层逻辑和意图。
• 测试推理与整合能力：模型能否将分步给出的信息（代码、示例、描述）关联起来，形成完整认知。
• 衡量重构质量：生成的代码是否在功能等价的前提下，显著提升了可读性、可维护性和性能？
• 为 AI 编程助手提供更真实的训练/评估场景：帮助开发出更能应对实际复杂情况的 Coding Agent。

对于开发者而言，理解 SlopCodeBench 有助于你：

• 更客观地评估不同 LLM（如 GPT-4、Claude、DeepSeek-Coder）在复杂任务上的真实能力。
• 为你自己的项目设计更有效的代码审查或重构辅助流程。
• 深入理解 AI 在软件开发生命周期中的潜在作用与当前局限。

2. SlopCodeBench 环境与数据准备

虽然 SlopCodeBench 是一个学术基准，但我们完全可以将其思想应用于本地环境，对开源模型或 API 模型进行测试。

2.1 核心组件与数据获取

SlopCodeBench 的核心是一系列精心设计的“任务”。每个任务包含一个需要重构的“Slop”代码文件，以及与之关联的、逐步释放的“披露”信息。这些信息可能包括：

• 初始 Slop 代码：一个功能正确但编写糟糕（命名混乱、结构冗余、风格不一致）的代码片段。
• 测试用例：一系列输入/输出对，定义了代码的预期行为。
• 自然语言描述：对代码功能的简要说明。
• API 文档或规范：对代码应遵循的接口或规则的描述。

你可以通过研究相关的论文或开源项目来了解其具体数据格式。通常，数据会以 JSON 或类似的结构化格式组织。

2.2 本地测试环境搭建

为了模拟 SlopCodeBench 的评估流程，我们需要搭建一个可以运行代码并调用 LLM 的本地环境。

基础环境：

• 操作系统：Linux (Ubuntu 20.04+)、macOS 或 WSL2 (Windows)。
• Python：版本 3.8 或以上。这是运行大多数 LLM 工具链和评估脚本的通用语言。

关键 Python 库：

# 创建虚拟环境（推荐） python -m venv slopbench_env source slopbench_env/bin/activate # Linux/macOS # slopbench_env\Scripts\activate # Windows # 安装核心库 pip install openai # 如需调用 OpenAI API pip install anthropic # 如需调用 Claude API # 对于开源模型，可能需要 transformers, torch, vllm 等 pip install transformers torch pip install pytest # 用于运行测试用例验证重构结果 pip install astunparse # 用于 Python 代码的解析和比较（可选）

项目结构示例：

slopcodebench_eval/ ├── data/ # 存放 SlopCodeBench 任务数据 │ ├── task_001.json │ ├── task_002.json │ └── ... ├── slop_code/ # 原始 Slop 代码文件 │ └── task_001_slop.py ├── disclosures/ # 分步披露信息 │ ├── task_001_step1.json │ ├── task_001_step2.json │ └── ... ├── eval_scripts/ # 评估脚本 │ ├── run_benchmark.py │ └── evaluate_output.py ├── results/ # 存放模型输出和评估结果 └── requirements.txt

2.3 模型选择与接入

你可以选择以下一种或多种模型进行测试：

1. 云端 API 模型（方便，但可能有成本）：

   • OpenAI GPT-4/GPT-4o：目前代码能力公认的佼佼者。
   • Anthropic Claude 3 (Sonnet/Opus)：在长上下文和复杂推理方面表现优异。
   • DeepSeek-Coder（通过 API）：在代码生成领域针对性很强。

2. 本地开源模型（可控，但对硬件有要求）：

   • CodeLlama 系列(7B, 13B, 34B)：Meta 出品，专为代码微调。
   • DeepSeek-Coder(1.3B, 6.7B, 33B)：性能强劲，完全开源。
   • Qwen-Coder(1.5B, 7B, 14B)：通义千问的代码模型。

示例：使用 OpenAI API 进行调用

# eval_scripts/call_model.py import openai import os import json # 从环境变量读取 API Key，更安全 openai.api_key = os.getenv("OPENAI_API_KEY") def call_gpt4_for_refactor(slop_code, disclosure_info, model="gpt-4"): """ 调用 GPT-4 进行代码重构 :param slop_code: 原始的混乱代码字符串 :param disclosure_info: 披露信息字典，可能包含测试用例、描述等 :param model: 使用的模型名称 :return: 模型生成的代码字符串 """ # 构建渐进披露的提示词（Prompt） messages = [ { "role": "system", "content": "你是一个资深的软件工程师，擅长代码重构。你将收到一段编写糟糕但功能正确的代码（Slop Code），以及一些逐步给出的额外信息（如测试用例、功能描述）。你的任务是根据所有已有信息，重构这段代码，使其变得清晰、可维护、高效，同时确保其外部行为完全不变。只输出重构后的最终代码，不要包含任何解释。" }, { "role": "user", "content": f"## 初始 Slop 代码\n```python\n{slop_code}\n```\n\n## 披露信息 (步骤 1: 测试用例)\n```json\n{json.dumps(disclosure_info.get('test_cases', []), indent=2)}\n```\n\n请根据以上代码和测试用例，开始重构。" } ] # 在实际的 SlopCodeBench 中，这里会模拟多轮交互，逐步添加 disclosure_info 中的其他信息 try: response = openai.ChatCompletion.create( model=model, messages=messages, temperature=0.2, # 低温度以保证输出的确定性和一致性 max_tokens=2000 ) refactored_code = response.choices[0].message.content.strip() # 清理输出，提取代码块 if "```python" in refactored_code: refactored_code = refactored_code.split("```python")[1].split("```")[0].strip() elif "```" in refactored_code: refactored_code = refactored_code.split("```")[1].split("```")[0].strip() return refactored_code except Exception as e: print(f"调用 API 时出错: {e}") return None # 示例用法 if __name__ == "__main__": # 模拟加载一个任务 slop_code = """ def f(x): a = [] for i in range(0, len(x)): if x[i] % 2 == 0: a.append(x[i] * 2) else: a.append(x[i] * 3) return a """ disclosure = { "test_cases": [ {"input": [1, 2, 3], "output": [3, 4, 9]}, {"input": [], "output": []} ] # 后续可能添加 "description": "将列表中的偶数乘2，奇数乘3" } result = call_gpt4_for_refactor(slop_code, disclosure) print("重构后的代码：") print(result)

运行上述脚本，你可能会得到类似下面的重构结果：

def transform_numbers(numbers): """ 将输入列表中的偶数乘以2，奇数乘以3。 """ result = [] for num in numbers: if num % 2 == 0: result.append(num * 2) else: result.append(num * 3) return result

可以看到，模型不仅重命名了函数和变量，还添加了文档字符串，并使用更清晰的迭代方式。

3. SlopCodeBench 任务实战：分步解析与重构

让我们通过一个更复杂的模拟任务，来体验 SlopCodeBench 的渐进披露流程。假设我们有一个处理用户订单数据的“Slop”函数。

3.1 阶段一：面对“天书”代码

你首先看到的只有这段代码：

# slop_code/task_complex_slop.py def p(d): r = {} for k in d: if type(d[k]) == list: t = 0 for v in d[k]: if type(v) == int or type(v) == float: t += v else: try: t += float(v) except: pass r[k] = t / len(d[k]) if len(d[k]) > 0 else 0 else: r[k] = d[k] return r

任务：仅凭这段代码，你能推断出它的功能吗？变量名p,d,r,k,t,v毫无意义，结构嵌套较深。人类和模型都需要进行大量猜测。

3.2 阶段二：获得测试用例

现在，你获得了一组测试用例：

// disclosures/task_complex_step1.json { "disclosure_type": "test_cases", "content": [ { "input": {"price": [10, 20, "30"], "quantity": 5, "discount": [0.1, 0.2]}, "output": {"price": 20.0, "quantity": 5, "discount": 0.15} }, { "input": {"scores": [85, 92, 78, 90], "name": "Alice"}, "output": {"scores": 86.25, "name": "Alice"} }, { "input": {"empty_list": [], "single": [42], "mixed": [1, "2", 3.0]}, "output": {"empty_list": 0, "single": 42.0, "mixed": 2.0} } ] }

分析：通过输入输出对比，我们可以推断：

1. 函数p接收一个字典d。
2. 对于字典中值为列表的项，它计算该列表的平均值。
3. 计算平均值时，它试图将列表元素转换为数值（int/float）。
4. 对于非列表的值，它原样保留。
5. 空列表的平均值被处理为 0。

此时，模型的任务是根据代码逻辑和测试用例，重构出一个功能等价但更清晰的函数。一个好的重构应该：

• 赋予函数和变量有意义的名称。
• 将计算平均值的逻辑提取为独立函数。
• 改进类型检查和转换，使其更健壮。
• 添加适当的注释和文档字符串。

3.3 阶段三：获得自然语言描述

进一步，你得到了功能描述：

// disclosures/task_complex_step2.json { "disclosure_type": "description", "content": "此函数用于处理一个字典，其中某些键对应的值是列表。对于这些列表值，函数计算其元素的平均值（元素应可转换为数字）。对于非列表值，则保持不变。函数应能处理空列表（返回0）和包含非数字字符串的列表（忽略不可转换的元素）。" }

这个描述确认了我们的推断，并补充了“忽略不可转换元素”的细节。这允许模型在重构时，可以优化错误处理逻辑，使其更符合描述（而不仅仅是原始代码中简单的try-except: pass）。

3.4 阶段四：应用重构并验证

现在，我们可以设计一个提示词，整合所有信息，指导模型进行重构。

# eval_scripts/run_complex_task.py def build_refactor_prompt(slop_code, test_cases, description): prompt = f""" 你是一个代码重构专家。请基于以下所有信息，重构给定的 Python 函数。 ## 原始函数 (Slop Code) ```python {slop_code}

功能描述

{description}

测试用例 (输入 -> 输出)

{json.dumps(test_cases, indent=2)}

重构要求

1. 保持功能完全一致：重构后的函数必须通过所有提供的测试用例。
2. 提升代码质量：
   • 使用有意义的函数名和变量名。
   • 将计算平均值的核心逻辑提取为独立的辅助函数calculate_average。
   • 改进类型转换和错误处理，使其更健壮、更符合 Python 风格（例如，使用isinstance进行类型检查，更优雅地处理转换失败）。
   • 添加清晰的文档字符串（Docstring）说明函数的行为、参数和返回值。
   • 考虑代码的可读性和可维护性。
3. 只输出重构后的最终代码，不要包含任何额外的解释或注释（除了代码内的文档字符串）。

请开始重构：

""" return prompt # 假设我们已经有了 slop_code, test_cases, description 变量 final_prompt = build_refactor_prompt(slop_code, test_cases_json, description_text) # 然后将 final_prompt 发送给 LLM

将上述提示词发送给一个能力足够的 LLM（如 GPT-4），我们可能得到如下重构结果：

def calculate_average(value_list): """ 计算一个列表中所有可转换为数字的元素的平均值。 参数: value_list (list): 可能包含数字或可转换为数字的字符串的列表。 返回: float: 列表中所有有效数字元素的平均值。如果列表为空或没有有效数字，返回 0.0。 """ total = 0.0 count = 0 for item in value_list: # 尝试将元素转换为浮点数 try: num = float(item) total += num count += 1 except (ValueError, TypeError): # 忽略无法转换的元素 continue return total / count if count > 0 else 0.0 def process_dictionary(data_dict): """ 处理一个字典，计算其中列表类型值的平均值，并保留其他值不变。 参数: data_dict (dict): 输入字典，其值可以是任意类型。 返回: dict: 一个新的字典，其中列表值被替换为其平均值（浮点数）， 非列表值保持不变。 示例: >>> process_dictionary({{'price': [10, 20, '30'], 'quantity': 5}}) {{'price': 20.0, 'quantity': 5}} """ result = {} for key, value in data_dict.items(): if isinstance(value, list): # 对列表值计算平均值 result[key] = calculate_average(value) else: # 非列表值直接保留 result[key] = value return result

3.5 验证重构结果

重构完成后，必须验证功能是否正确。我们可以使用 Python 的pytest或unittest来运行原始测试用例。

# eval_scripts/validate_refactor.py import sys sys.path.insert(0, '.') # 假设重构后的代码保存在当前目录的 refined.py 中 from refined import process_dictionary # 导入重构后的函数 def test_process_dictionary(): """使用提供的测试用例验证重构函数""" test_cases = [ ( {"price": [10, 20, "30"], "quantity": 5, "discount": [0.1, 0.2]}, {"price": 20.0, "quantity": 5, "discount": 0.15} ), ( {"scores": [85, 92, 78, 90], "name": "Alice"}, {"scores": 86.25, "name": "Alice"} ), ( {"empty_list": [], "single": [42], "mixed": [1, "2", 3.0]}, {"empty_list": 0, "single": 42.0, "mixed": 2.0} ) ] all_passed = True for input_data, expected_output in test_cases: actual_output = process_dictionary(input_data) # 注意浮点数比较的精度问题 if actual_output != expected_output: # 更细致的比较，处理浮点误差 for key in expected_output: if isinstance(expected_output[key], float): if abs(actual_output.get(key, 0) - expected_output[key]) > 1e-9: print(f"测试失败！输入: {input_data}") print(f" 期望: {expected_output}") print(f" 实际: {actual_output}") all_passed = False break elif actual_output.get(key) != expected_output[key]: print(f"测试失败！输入: {input_data}") print(f" 期望: {expected_output}") print(f" 实际: {actual_output}") all_passed = False break if not all_passed: break else: print(f"测试通过: {input_data} -> {actual_output}") if all_passed: print("所有测试用例通过！重构成功。") else: print("部分测试用例失败，请检查重构代码。") return all_passed if __name__ == "__main__": test_process_dictionary()

运行此验证脚本，如果所有断言通过，则证明重构在功能上是等价的。

4. 评估模型表现：超越功能正确性

在 SlopCodeBench 中，仅仅通过测试用例是不够的。它通常包含更全面的评估维度，我们可以借鉴：

4.1 评估维度

1. 功能正确性（Pass@k）：在多次生成中，至少有一次通过所有测试用例的概率。这是底线。
2. 代码质量提升：
   • 可读性：变量/函数命名、注释、文档字符串、代码结构。
   • 可维护性：模块化程度（如提取的函数）、圈复杂度降低、重复代码消除。
   • 健壮性：错误处理是否更完善（例如，用isinstance()代替type()==，更具体的异常捕获）。
3. 信息利用效率：模型是否有效地整合了渐进披露的信息？例如，在只有代码时，它可能只做简单重命名；在看到测试用例后，它是否修正了逻辑理解；在获得描述后，是否优化了边界情况处理？
4. 重构决策的合理性：模型选择的重构策略（如提取函数、简化条件、使用推导式）是否符合常见的最佳实践？

4.2 自动化评估指标（示例）

我们可以设计一些简单的自动化检查来辅助评估：

# eval_scripts/metrics_calculation.py import ast import astunparse import radon.complexity as radon_cc from radon.visitors import ComplexityVisitor def calculate_metrics(original_code, refactored_code): """计算并比较原始代码与重构代码的度量指标""" metrics = {} # 1. 代码行数 (粗略衡量) metrics['original_lines'] = len(original_code.splitlines()) metrics['refactored_lines'] = len(refactored_code.splitlines()) # 2. 解析 AST try: orig_ast = ast.parse(original_code) ref_ast = ast.parse(refactored_code) except SyntaxError as e: print(f"代码解析错误: {e}") return metrics # 3. 圈复杂度 (使用 radon 库) # 注意：这里需要安装 `radon` 库: pip install radon try: orig_cc = radon_cc.cc_visit(original_code) ref_cc = radon_cc.cc_visit(refactored_code) # 取平均复杂度或总复杂度 metrics['original_avg_complexity'] = sum([func.complexity for func in orig_cc]) / len(orig_cc) if orig_cc else 0 metrics['refactored_avg_complexity'] = sum([func.complexity for func in ref_cc]) / len(ref_cc) if ref_cc else 0 except Exception as e: print(f"计算圈复杂度时出错: {e}") # 4. 函数/变量名长度 (可读性代理指标) def collect_names(node): names = [] for n in ast.walk(node): if isinstance(n, ast.FunctionDef): names.append(n.name) elif isinstance(n, ast.Name) and isinstance(n.ctx, ast.Store): names.append(n.id) return names orig_names = collect_names(orig_ast) ref_names = collect_names(ref_ast) metrics['original_avg_name_len'] = sum(len(n) for n in orig_names) / len(orig_names) if orig_names else 0 metrics['refactored_avg_name_len'] = sum(len(n) for n in ref_names) / len(ref_names) if ref_names else 0 # 5. 是否有文档字符串 metrics['original_has_docstring'] = ast.get_docstring(orig_ast) is not None metrics['refactored_has_docstring'] = ast.get_docstring(ref_ast) is not None return metrics # 使用示例 original = """def p(d):...""" # 之前的 slop 代码 refactored = """def process_dictionary(data_dict):...""" # 重构后的代码 metrics = calculate_metrics(original, refactored) for key, value in metrics.items(): print(f"{key}: {value}")

输出可能类似于：

original_lines: 15 refactored_lines: 35 # 可能因为提取函数和添加文档而增加 original_avg_complexity: 5.0 refactored_avg_complexity: 2.5 # 复杂度降低，是好事 original_avg_name_len: 1.2 refactored_avg_name_len: 8.7 # 命名更具描述性 original_has_docstring: False refactored_has_docstring: True # 添加了文档

这些自动化指标可以量化重构在结构上的改进，但最终仍需人工审查代码的逻辑清晰度和设计合理性。

5. 常见问题与模型表现分析

在实际使用 SlopCodeBench 思想测试不同模型时，你可能会遇到以下典型问题：

5.1 模型常见失败模式

5.2 不同类别模型的对比分析

• 大型通用模型（如 GPT-4, Claude 3）：

  • 优势：强大的推理和上下文理解能力，能很好地将自然语言描述、测试用例与代码关联。擅长进行深度的、语义层面的重构。
  • 劣势：可能生成过于“通用”或“冗长”的代码，有时会过度设计。API 调用有成本。

• 专用代码模型（如 DeepSeek-Coder, CodeLlama）：

  • 优势：在代码语法、惯例上非常熟练，生成代码简洁、符合习惯。对于纯代码理解任务（仅给代码和测试）可能表现更直接。
  • 劣势：在需要复杂推理、整合非代码文本信息（如模糊描述）时，可能弱于通用大模型。

• 较小参数模型（<7B）：

  • 挑战：可能难以完成复杂的、需要多步推理的重构任务。更容易出现逻辑错误或无法整合所有信息。
  • 适用场景：对于结构相对简单的 Slop 代码，或作为初步的“代码清理”工具。

实践建议：对于重要的重构任务，可以采用“大型模型设计，专用模型实现”的协作模式。即用 GPT-4 分析问题、制定重构方案，再用 DeepSeek-Coder 生成具体的、符合惯例的代码。

6. 最佳实践与工程建议

将 SlopCodeBench 的思维应用到实际开发和 AI 编程助手评估中，可以遵循以下最佳实践：

6.1 设计有效的渐进披露评估

1. 构建真实的任务：从你的实际代码库中寻找那些“能工作但很难看”的函数，为其编写测试用例和简要描述，构建自己的微型 SlopCodeBench。
2. 分阶段评估：不要一次性给出所有信息。先给代码，评估模型的初步理解；再给测试用例，看其能否修正理解；最后给描述，评估其最终优化能力。这能精准定位模型的薄弱环节。
3. 多样化任务类型：包括算法重构、API 封装、错误处理改进、性能优化（如将 O(n²) 改为 O(n)）等不同类别。

6.2 优化用于重构的提示词工程

1. 明确系统角色：如“你是一个注重代码清洁度和可维护性的资深软件工程师”。
2. 结构化输入信息：清晰分隔“原始代码”、“测试用例”、“功能描述”、“约束条件”。
3. 具体化重构要求：不要只说“重构”，要列出具体期望，例如：
   • “为函数和变量选择具有描述性的名称。”
   • “将重复的逻辑提取到一个单独的函数中。”
   • “用更 Pythonic 的方式（例如列表推导式、内置函数）替换显式循环。”
   • “添加类型提示（Type Hints）和文档字符串。”
   • “改进错误处理，避免裸露的except: pass。”
4. 要求输出格式：明确要求“只输出重构后的最终代码”，并指定代码块语言，便于后续自动提取和验证。

6.3 将重构能力集成到开发流程

1. 作为代码审查助手：在提交代码前，将复杂或冗长的代码片段交给 AI，要求其提供重构建议。但必须由人类开发者最终审核和合并。
2. 理解遗留代码：面对陌生的、文档不全的代码库时，可以分段将代码和你能找到的任何上下文（日志、调用示例）输入给 AI，让其帮助你解释和理清逻辑。
3. 技术债管理：定期从项目中挑选“Slop Code”，使用 AI 辅助生成重构方案，作为技术债偿还的候选任务。

6.4 安全与风险控制

1. 功能等价是铁律：任何重构都必须通过完整的测试套件（包括单元测试、集成测试）。AI 生成的重构代码绝不能直接用于生产环境，必须经过严格测试。
2. 理解优于盲从：AI 可能给出看似优美但错误的重构。开发者必须理解 AI 提出的更改，确保其逻辑正确。
3. 版本控制：在应用大规模 AI 辅助重构前，确保代码已提交，方便回滚。
4. 合规与许可：确保用于评估或训练的代码数据不涉及公司机密或第三方版权问题。

SlopCodeBench 及其代表的“渐进披露”评估范式，为我们打开了一扇窗，让我们能更真实地衡量 LLM 在复杂、模糊的软件工程任务中的能力。它提醒我们，一个优秀的 AI 编程助手，不仅要在清晰的指令下写出代码，更要在信息不全时展现出强大的推理、整合和迭代改进能力。

对于开发者而言，掌握这种评估方法，不仅能帮你选择更合适的 AI 工具，更能启发你设计出更健壮、更易维护的代码——因为你在用“未来可能被 AI 或他人重构”的标准来要求自己当下的代码。尝试用本文介绍的方法，对你项目中的一些代码片段进行“SlopCodeBench”式测试，看看你常用的 AI 助手表现如何，这本身就是一个极佳的学习和提升过程。