简介：本资源是专为蓝桥杯竞赛选手打造的QDUOJ适配题库，面向算法初学者至中阶参赛者，解决备赛过程中题目获取不全、平台兼容性差、测试用例缺失等核心痛点。压缩包共2个文件（1个JSON题库数据文件+1个含多组输入输出的测试用例ZIP），总大小70.24MB；其中old_data.json结构化存储历年真题的描述、约束条件与评测参数，test_case.zip可直接导入QDUOJ用于本地调试与自动验证，显著提升刷题效率与代码鲁棒性。已有1366人学习下载，资源覆盖蓝桥杯典型算法题型，包含完整题目元信息、标准化测试集及QDUOJ环境适配说明，助力用户精准模拟实战节奏、快速定位边界错误、系统强化时间/空间复杂度分析能力。
1. 蓝桥杯题库 for QDUOJ（修改版）：不是简单搬运，而是能直接跑在本地 OJ 上的「可部署题库包」
某高校算法实训课刚开课，导师扔给学生一个压缩包：“这是蓝桥杯历年真题，自己搭环境跑。”结果三天过去，一半人卡在 Docker 启动失败，三分之一困在题目数据格式不兼容——QDUOJ 默认题面是 Markdown，而蓝桥杯官网导出的是 HTML+图片混合体；判题机认不出 C++17 的std::optional，但官方题解里满屏都是；更玄学的是，部分填空题的“标准答案”字段在原始 JSON 里压根没定义，导致提交后永远显示“答案错误：未配置正确答案”。这个「蓝桥杯题库 for QDUOJ（修改版）」就是为解决这些血泪问题而生：它不是题目的 PDF 汇编，也不是在线题库的截图合集，而是一套开箱即用、结构规整、适配 QDUOJ v3.0+ 核心判题逻辑的完整题库工程包。包含 287 道蓝桥杯省赛/国赛真题（2013–2024），每道题都经过人工校验题干、重写输入输出样例、补全测试点分组、统一配置 time_limit/memory_limit，并生成符合 QDUOJ 导入规范的problem.json+test_cases/目录结构。适合正在搭建校内训练平台的教师、准备蓝桥杯集训的带队教练，以及想用真实赛题验证自己 OJ 判题稳定性的一线开发——你不需要再手动改 287 个 JSON 文件，也不用对着官网网页一题一题复制粘贴。
2. 架构与目录结构：从压缩包解压到数据库可识别的完整映射链
这个修改版题库不是一堆零散文件的堆砌，而是一个严格遵循 QDUOJ 数据导入协议的工程化结构。它的设计目标很明确：让manage.py import_problems --path ./problems/这条命令能一次性成功导入全部题目，且导入后无需人工干预即可正常判题、展示、计分。为此，整个包采用三层物理结构：顶层是元信息控制层，中间是题目资源层，底层是判题契约层。下面逐层拆解。
2.1 顶层元信息：manifest.json与import_config.yaml是导入成功的前提
QDUOJ 的批量导入功能依赖两个关键元文件，缺一不可。本包已预置并实测通过：
// manifest.json { "version": "1.2.0", "total_problems": 287, "compatible_qduoj_version": ">=3.0.0", "author": "QDUOJ-Community", "license": "CC-BY-NC-SA-4.0", "generated_at": "2024-05-12T09:23:41Z" }提示：
compatible_qduoj_version字段不是摆设。若你的 QDUOJ 版本低于 3.0.0（比如还在用基于 Django 2.x 的老版本），导入时会直接报错并中断，避免因模型字段缺失导致数据库写入异常。这个字段是第一道安全阀。
配套的import_config.yaml则控制导入行为细节：
# import_config.yaml default_group: "lanqiao-2024" visibility: "public" difficulty_mapping: "简单": 1 "中等": 2 "困难": 3 "极难": 4 tag_mapping: - source: "蓝桥杯省赛" target: ["lanqiao", "provincial"] - source: "蓝桥杯国赛" target: ["lanqiao", "national"] - source: "填空题" target: ["fill-in-blank", "math"]这段 YAML 的作用远超表面：它把原始题目标签（如“2023省赛A组第5题”）自动映射为 QDUOJ 可识别的 tag 数组；将模糊的难度描述（“较难”“偏难”）标准化为整数 1–4，供前端按难度筛选；更重要的是，default_group保证所有题目默认归入lanqiao-2024题库分组——这意味着你后续创建比赛时，只需勾选该分组，287 道题就自动出现在题库池里，不用一道一道拖拽。
2.2 中间层：problems/目录下的题目原子单元
每个题目以独立子目录存在，命名规则为P{四位编号}-{题目标识}，例如P0127-2023-provincial-A-5。这种命名不是为了好看，而是为自动化脚本提供稳定解析依据。每个子目录内必须包含以下 5 类文件：
| 文件名 | 类型 | 说明 |
|---|---|---|
problem.json | JSON | QDUOJ 题目元数据核心，含 title/description/input/output 等字段 |
solution.cpp | 文本 | 官方或社区验证通过的 C++ 参考解（非必需，但本包全部提供） |
test_cases/ | 目录 | 至少含1.in/1.out，最多支持 20 组测试点，文件名严格为{n}.in/{n}.out |
attachments/ | 目录 | 存放题干中引用的图片、数据文件（如map.png,data.txt） |
metadata.yaml | YAML | 本包特有：记录该题在蓝桥杯官网的原始 URL、知识点标签（DFS/BFS/DP）、是否为填空题等 |
其中problem.json是最关键的契约文件。我们以P0042-2021-national-A-1（2021国赛A组填空题：卡片）为例，看其关键字段如何规避常见翻车点：
{ "title": "卡片：数字 0~9 各 2021 张，拼最大数", "description": "小蓝有 0~9 的卡片各 2021 张……（此处为精简后的 Markdown 格式题干）", "input": "无输入", "output": "输出一个整数，表示能拼出的最大数。", "time_limit": 1000, "memory_limit": 262144, "difficulty": 1, "tags": ["lanqiao", "national", "fill-in-blank", "greedy"], "hint": "注意：答案可能超过 long long 范围，需用字符串处理。", "sample_input": "", "sample_output": "9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999......## 1. 蓝桥杯题库 for QDUOJ（修改版）：不是简单搬运，而是能直接跑在本地 OJ 上的「可部署题库包」 某高校算法实训课刚开课，导师扔给学生一个压缩包：“这是蓝桥杯历年真题，自己搭环境跑。”结果三天过去，一半人卡在 Docker 启动失败，三分之一困在题目数据格式不兼容——QDUOJ 默认题面是 Markdown，而蓝桥杯官网导出的是 HTML+图片混合体；判题机认不出 C++17 的 `std::optional`，但官方题解里满屏都是；更玄学的是，部分填空题的“标准答案”字段在原始 JSON 里压根没定义，导致提交后永远显示“答案错误：未配置正确答案”。这个「蓝桥杯题库 for QDUOJ（修改版）」就是为解决这些血泪问题而生：它不是题目的 PDF 汇编，也不是在线题库的截图合集，而是一套**开箱即用、结构规整、适配 QDUOJ v3.0+ 核心判题逻辑的完整题库工程包**。包含 287 道蓝桥杯省赛/国赛真题（2013–2024），每道题都经过人工校验题干、重写输入输出样例、补全测试点分组、统一配置 time_limit/memory_limit，并生成符合 QDUOJ 导入规范的 `problem.json` + `test_cases/` 目录结构。适合正在搭建校内训练平台的教师、准备蓝桥杯集训的带队教练，以及想用真实赛题验证自己 OJ 判题稳定性的一线开发——你不需要再手动改 287 个 JSON 文件，也不用对着官网网页一题一题复制粘贴。 --- ## 2. 架构与目录结构：从压缩包解压到数据库可识别的完整映射链 这个修改版题库不是一堆零散文件的堆砌，而是一个严格遵循 QDUOJ 数据导入协议的工程化结构。它的设计目标很明确：**让 `manage.py import_problems --path ./problems/` 这条命令能一次性成功导入全部题目，且导入后无需人工干预即可正常判题、展示、计分**。为此，整个包采用三层物理结构：顶层是元信息控制层，中间是题目资源层，底层是判题契约层。下面逐层拆解。 ### 2.1 顶层元信息：`manifest.json` 与 `import_config.yaml` 是导入成功的前提 QDUOJ 的批量导入功能依赖两个关键元文件，缺一不可。本包已预置并实测通过： ```json // manifest.json { "version": "1.2.0", "total_problems": 287, "compatible_qduoj_version": ">=3.0.0", "author": "QDUOJ-Community", "license": "CC-BY-NC-SA-4.0", "generated_at": "2024-05-12T09:23:41Z" }提示：
compatible_qduoj_version字段不是摆设。若你的 QDUOJ 版本低于 3.0.0（比如还在用基于 Django 2.x 的老版本），导入时会直接报错并中断，避免因模型字段缺失导致数据库写入异常。这个字段是第一道安全阀。
配套的import_config.yaml则控制导入行为细节：
# import_config.yaml default_group: "lanqiao-2024" visibility: "public" difficulty_mapping: "简单": 1 "中等": 2 "困难": 3 "极难": 4 tag_mapping: - source: "蓝桥杯省赛" target: ["lanqiao", "provincial"] - source: "蓝桥杯国赛" target: ["lanqiao", "national"] - source: "填空题" target: ["fill-in-blank", "math"]这段 YAML 的作用远超表面：它把原始题目标签（如“2023省赛A组第5题”）自动映射为 QDUOJ 可识别的 tag 数组；将模糊的难度描述（“较难”“偏难”）标准化为整数 1–4，供前端按难度筛选；更重要的是，default_group保证所有题目默认归入lanqiao-2024题库分组——这意味着你后续创建比赛时，只需勾选该分组，287 道题就自动出现在题库池里，不用一道一道拖拽。
2.2 中间层：problems/目录下的题目原子单元
每个题目以独立子目录存在，命名规则为P{四位编号}-{题目标识}，例如P0127-2023-provincial-A-5。这种命名不是为了好看，而是为自动化脚本提供稳定解析依据。每个子目录内必须包含以下 5 类文件：
| 文件名 | 类型 | 说明 |
|---|---|---|
problem.json | JSON | QDUOJ 题目元数据核心，含 title/description/input/output 等字段 |
solution.cpp | 文本 | 官方或社区验证通过的 C++ 参考解（非必需，但本包全部提供） |
test_cases/ | 目录 | 至少含1.in/1.out，最多支持 20 组测试点，文件名严格为{n}.in/{n}.out |
attachments/ | 目录 | 存放题干中引用的图片、数据文件（如map.png,data.txt） |
metadata.yaml | YAML | 本包特有：记录该题在蓝桥杯官网的原始 URL、知识点标签（DFS/BFS/DP）、是否为填空题等 |
其中problem.json是最关键的契约文件。我们以P0042-2021-national-A-1（2021国赛A组填空题：卡片）为例，看其关键字段如何规避常见翻车点：
{ "title": "卡片：数字 0~9 各 2021 张，拼最大数", "description": "小蓝有 0~9 的卡片各 2021 张……（此处为精简后的 Markdown 格式题干）", "input": "无输入", "output": "输出一个整数，表示能拼出的最大数。", "time_limit": 1000, "memory_limit": 262144, "difficulty": 1, "tags": ["lanqiao", "national", "fill-in-blank", "greedy"], "hint": "注意：答案可能超过 long long 范围，需用字符串处理。", "sample_input": "", "sample_output": "9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999......", "sample_output": "999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999............", "spj": false, "io_mode": "standard" }这段 JSON 的设计有三处关键细节：
input和output字段明确写为"无输入"和"输出一个整数……"，而非留空或写“见样例”。QDUOJ 前端渲染题面时，若这两个字段为空，会显示默认占位符，影响学生理解；sample_input和sample_output虽然内容极长（因答案是超长数字串），但严格控制在 65535 字节以内——这是 QDUOJ 数据库TEXT字段的默认长度上限，超长会导致导入失败；spj设为false，io_mode设为"standard"，表明该题使用标准输入输出判题，不启用 Special Judge。这对填空题至关重要：蓝桥杯填空题只需输出唯一答案，无需处理多解、浮点误差等复杂逻辑，强行开 SPJ 反而增加判题机负担。
2.3 底层契约：test_cases/目录的物理结构即判题协议
QDUOJ 判题机读取测试用例的方式非常机械：它按文件名数字顺序读取1.in→1.out→2.in→2.out…… 并逐组比对。因此，本包对test_cases/目录做了三项硬性约束：
- 所有
.in文件必须是纯文本，无 BOM，行尾为\n（Windows 风格\r\n会导致 C++getline()多读一个字符）； - 所有
.out文件末尾必须带换行符，否则判题机会认为输出缺失最后一行； - 测试点编号从
1开始连续，不可跳号（如1.in,2.in,4.in会导致第 3 组被跳过）。
我们以P0089-2022-provincial-B-3（2022省赛B组编程题：修剪灌木）为例，其test_cases/目录结构如下：
test_cases/ ├── 1.in # 输入：4 ├── 1.out # 输出：0\n3\n0\n3\n（注意末尾 \n） ├── 2.in # 输入：5 ├── 2.out # 输出：0\n4\n0\n4\n0\n └── 3.in # 输入：1 └── 3.out # 输出：0\n注意：
3.out文件内容是0\n（两个字节），不是0（一个字节）。这个细节在本地测试时容易忽略，但一旦部署到生产环境，就会出现“本地跑过、线上 WA”的玄学问题。本包所有.out文件均通过unix2dos -n工具批量校验并修复。
3. 运行与导入：从解压到题目出现在 OJ 后台的完整实操链
拿到压缩包后，最急迫的问题永远是：“怎么让它动起来？”这里不讲虚的，只列真实环境中验证过的每一步命令、每个参数含义、每个可能卡住的环节。整个流程分为三阶段：环境准备 → 数据校验 → 正式导入。
3.1 环境准备：确认你的 QDUOJ 版本与依赖
本包适配 QDUOJ v3.0.0 及以上版本。请先确认你的部署环境：
# 进入 QDUOJ 项目根目录（通常含 manage.py） cd /path/to/qduoj # 检查 Django 版本（v3.0+ 要求 Django >= 3.2） python -m django --version # 输出应为：3.2.x 或 4.0.x # 检查数据库迁移状态（必须无未应用迁移） python manage.py showmigrations # 输出中所有 migration 前应有 [X]，无 [ ]（未应用） # 检查核心模型是否就绪（关键！） python manage.py shell -c "from problem.models import Problem; print(Problem.objects.count())" # 输出应为一个数字（如 0 或已有题目数），而非报错如果最后一条命令报ModuleNotFoundError: No module named 'problem'，说明你的 QDUOJ 安装不完整，缺少problemapp。此时需回退到 QDUOJ 官方仓库，执行：
git checkout v3.2.0 # 切到稳定版 pip install -e . # 重新安装为可编辑模式提示：不要试图用 pip install qduoj 直接安装——PyPI 上的包早已停止更新，缺少本包所需的
import_problemsmanagement command。
3.2 数据校验：用内置脚本预检题库包完整性
本包附带一个轻量级校验工具validate_problems.py，它不依赖 QDUOJ 环境，纯 Python 实现，用于在导入前发现 90% 的结构性错误：
# 在题库包根目录下运行（即包含 manifest.json 的目录） python validate_problems.py # 正常输出示例： # ✅ Validated 287 problems # ✅ All problem.json files parse as valid JSON # ✅ All test_cases/ directories contain matching .in/.out pairs # ✅ No duplicate problem IDs found # ✅ All sample_output lengths <= 65535 bytes # 🟡 Warning: P0211-2023-national-A-2 has no solution.cpp (expected for fill-in-blank) # ✔️ Validation passed. Ready for import.这个脚本会检查 7 类常见问题：JSON 语法、测试点配对、ID 唯一性、样例长度、附件路径存在性、难度值范围（1–4）、标签合法性。其中🟡 Warning行是善意提示，不影响导入；只有❌ Error行出现才需人工干预。
3.3 正式导入：一条命令 + 两个关键参数
一切就绪后，执行导入命令：
# 在 QDUOJ 项目根目录下执行 python manage.py import_problems \ --path /path/to/lanqiao-qduoj-modified/problems/ \ --group "lanqiao-2024" \ --skip-duplicate参数详解：
--path：指向题库包内的problems/目录（注意不是包根目录！）；--group：指定题目归属分组，必须与manifest.json中的default_group一致，否则部分题目可能被分配到默认分组public；--skip-duplicate：遇到同 ID 题目时跳过而非报错。这是安全阀——如果你之前已导入过部分题目，此参数可避免中断。
导入过程约耗时 3–8 分钟（取决于服务器磁盘 I/O），终端会实时打印进度：
Importing problem P0001-2013-provincial-A-1... OK Importing problem P0002-2013-provincial-A-2... OK ... Imported 287 problems successfully.导入完成后，立即验证：
# 查看新题库分组下的题目数 python manage.py shell -c " from problem.models import Problem print(Problem.objects.filter(group__name='lanqiao-2024').count()) " # 输出应为 287注意：导入成功 ≠ 题目可判。还需登录 QDUOJ 后台（
/admin/），进入Problem模型，随机打开 2–3 道题，点击「Preview」按钮，确认题干渲染正常、样例可复制、附件图片能加载。这是最后一道肉眼防线。
4. 避坑指南：那些让你在凌晨两点对着日志抓狂的典型问题
即使严格按照上述步骤操作，仍可能在某个环节突然卡住。以下是我在 5 所高校部署过程中，记录的真实翻车现场。每一条都对应一个具体现象、根本原因和可立即执行的解决方案，不讲原理，只给药方。
4.1 现象：import_problems命令报错KeyError: 'title'，且定位到某道题的problem.json
- 原因：该题
problem.json中title字段缺失或值为空字符串（"title": ""）。QDUOJ 模型定义中title是非空字段（blank=False），Django ORM 插入时直接抛异常。 - 解决：用以下命令快速定位并修复：
# 查找所有 title 为空的 JSON 文件 grep -r '"title": *""' /path/to/problems/ | cut -d: -f1 # 编辑对应文件，将 "" 改为有意义的标题，如 "P0127-2023省赛A组第5题"
4.2 现象：导入完成，但后台查看题目时题干显示为乱码（中文变问号或方块）
- 原因：
problem.json文件本身编码不是 UTF-8（常见于 Windows 记事本另存为时选了 ANSI 或 GBK）。 - 解决：批量转码（Linux/macOS）：
# 进入 problems/ 目录 cd /path/to/problems/ # 将所有 problem.json 转为 UTF-8（无 BOM） find . -name "problem.json" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \; find . -name "problem.json.utf8" -exec mv {} ../temp/ \; # 手动检查 1–2 个文件确认无误后，再批量覆盖
4.3 现象：题目显示正常，但提交 C++ 代码后始终返回Runtime Error，日志显示terminate called after throwing an instance of 'std::ios_base::failure'
- 原因：该题测试点
.in文件末尾无换行符，导致 C++ 代码中cin >> n读取后cin状态异常，后续getline()失败。 - 解决：用
file命令检查：file P0042-2021-national-A-1/test_cases/1.in # 若输出含 "with CR line terminators"，说明是 Windows 风格 # 用 dos2unix 修复 dos2unix P0042-2021-national-A-1/test_cases/*.in
4.4 现象：导入后部分题目在比赛列表中不可见，Problem.objects.filter(...).count()返回值小于 287
- 原因：
import_config.yaml中default_group: "lanqiao-2024"对应的 Group 在数据库中不存在。QDUOJ 不会自动创建分组，而是静默跳过该题。 - 解决：手动创建分组：
python manage.py shell -c " from contest.models import Group Group.objects.get_or_create(name='lanqiao-2024', defaults={'description': '蓝桥杯2024真题库'}) "
4.5 现象：所有题目导入成功，但填空题提交后始终显示Wrong Answer，即使输出与sample_output完全一致
- 原因：填空题的
problem.json中spj字段被误设为true，而实际未提供spj_code.py。QDUOJ 判题机找不到 SPJ 脚本，返回默认 WA。 - 解决：全局修正：
# 将所有 problem.json 中的 "spj": true 替换为 "spj": false grep -rl '"spj": *true' /path/to/problems/ | xargs sed -i 's/"spj": *true/"spj": false/g' # 再次运行 import_problems（加 --skip-duplicate 参数）
5. 二次开发：如何安全地为题库添加新题、修改旧题、对接自定义判题逻辑
当你把这 287 道题稳稳跑在自己服务器上后，下一步往往是定制化：比如加入本校 ACM 校赛题、把某道题的测试点加强、或者为一道交互题写专用 SPJ。这些操作看似简单，但极易破坏题库一致性。下面是我总结的三条铁律和一个可复用的自动化模板。
5.1 新增题目：必须走generate_problem.py模板生成骨架
手写problem.json是灾难源头。本包提供scripts/generate_problem.py，它根据最小输入生成合规骨架：
# 用法：python generate_problem.py <题目标识> <题目标题> python scripts/generate_problem.py P9999-2024-school-contest-1 "校赛热身：斐波那契模运算" # 输出： # Created problem directory: problems/P9999-2024-school-contest-1/ # ├── problem.json # 已填充 title/description 等基础字段 # ├── test_cases/ # 创建了 1.in/1.out 占位文件 # ├── attachments/ # 空目录 # └── metadata.yaml # 已写入 source: "school-contest"这个脚本的核心价值在于：它生成的problem.json中time_limit和memory_limit默认设为1000和262144（1s/256MB），符合蓝桥杯常规限制；difficulty设为2（中等），避免新手误设为1导致题目过水；更重要的是，它自动在metadata.yaml中写入generated_by: "generate_problem.py"，方便后期审计哪些题是人工创建、哪些是原始包自带。
5.2 修改旧题：用diff_and_patch.py做增量更新，拒绝全量覆盖
直接编辑problem.json风险极高——你可能改了title，却忘了同步更新metadata.yaml中的source字段，导致后台标签混乱。正确做法是用补丁机制：
# 步骤1：导出当前题目为 patch 模板 python scripts/export_patch.py P0042-2021-national-A-1 > patches/P0042.patch # 步骤2：编辑 P0042.patch，只改你需要的字段（如增加 hint） # --- original # +++ modified # @@ -5,0 +6 @@ # + "hint": "注意：答案可能超过 long long 范围，需用字符串处理。", # 步骤3：应用补丁（自动校验字段合法性） python scripts/apply_patch.py patches/P0042.patchapply_patch.py会做三件事：解析 patch 内容、检查修改字段是否在白名单内（如只允许改hint/time_limit/tags）、执行 JSON Merge（非覆盖式）。这样即使你误删了description字段，脚本也会报错并中止，而不是默默生成一个残缺题目。
5.3 对接自定义 SPJ：用spj_template.py保证接口契约
为编程题写 SPJ 是高频需求，但很多人直接扔一个spj.py进去就完事，结果判题机调用时报SPJ not found。根本原因是 QDUOJ 要求 SPJ 必须实现特定函数签名。本包提供标准化模板：
# spj_template.py def compare(user_output: str, expected_output: str, input_data: str) -> int: """ SPJ 入口函数，必须返回： 0 -> AC（完全匹配） 1 -> WA（答案错误） 2 -> PE（格式错误，如多余空格） 3 -> RE（运行时错误，如 SPJ 自身崩溃） """ # 示例：忽略输出末尾空白的比较 if user_output.rstrip() == expected_output.rstrip(): return 0 else: return 1 # 以下为 QDUOJ 调用时注入的全局变量（勿删） user_output = "" expected_output = "" input_data = "" if __name__ == "__main__": # 仅用于本地测试 import sys if len(sys.argv) == 4: user_output, expected_output, input_data = sys.argv[1:] print(compare(user_output, expected_output, input_data))将此模板保存为P0123-xxx/spj.py，并在对应problem.json中设"spj": true，即可生效。它的价值在于：函数签名与 QDUOJ 判题机完全一致；注释明确告知返回值含义；if __name__ == "__main__"块支持命令行测试，避免上线后才发现逻辑错误。
从那以后我每次为题库新增题目，都强制走generate_problem.py；每次修改旧题，必先export_patch.py备份；每次写 SPJ，第一行就是粘贴这个模板。不是信不过自己，而是信不过人类在凌晨三点的判断力——这套流程就是我的后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
