简介这份压缩包面向备战蓝桥杯Python省赛大学A、B、C组的参赛者汇集第14届省赛的完整题目与配套程序源码适合用于熟悉赛题风格、开展赛前专项训练以及对照源码复盘解题思路。包内共35个文件以32个py源码和3个pdf题目文档为主源码可用于运行验证与解法研读pdf便于阅读原始赛题与打印练习整体约5.34MB。目前已有1077人学习或下载具备一定的参考热度。内容按A、B、C组分别组织读者可结合题目要求逐题对照源码理解输入输出处理、算法选择与边界条件设置也能借助完整题面进行限时模拟和查漏补缺既可按组别横向比较命题差异也可按题型纵向归纳常用写法。对于需要系统梳理省赛知识点、提升Python解题熟练度的选手这份材料提供了较完整的练习与参考样本。1. 从一次「样例全过、提交全挂」说起前阵子有个学弟抱着压缩包来找我说他刷了三十多道 Python 省赛真题本地样例全绿一提交就挂。我翻了他那份包——按大学 A、B、C 三个组别分目录题面、样例、参考源码三件套齐全结构其实很干净问题出在他从来没按「标准输入输出 多组数据」的习惯读过题。这份第 14 届省赛 Python 组真题包大学 A/B/C 组题目与源码完整真正的价值不在题量而在于它把三档难度、同一套命题风格摊开给你看A 组偏语法与模拟B 组开始上前缀和、二分C 组压轴基本是搜索和动态规划。适合刚学完 Python 语法想系统过一遍真题的学生也适合需要现成题面和参考实现来排训练的老师。下面按我实际拆包、跑题、改脚本的顺序讲。2. 目录结构拆解A/B/C 三组的题面与源码怎么摆解压本身没技术含量但目录摆得清不清楚直接决定你后面是「按组顺着刷」还是「翻半小时找一个文件」。我拿到这份包的第一件事不是打开题目而是先把目录树打出来把命名规则摸透——后面写索引脚本、做批量对拍全靠这套规则吃饭。2.1 三组平铺的骨架与文件命名规则常见做法是按组别切三个一级目录组内再分「题目 / 源码 / 数据」三块题号前缀统一。这样摆的好处是排序稳定A01、A02一直到A10不会因为字典序变成A1、A10、A2脚本glob出来的顺序就是你要的顺序。第14届-Python省赛真题/ ├── README.md # 组别说明、难度标注、注意事项 ├── A组/ # 大学 A 组偏基础 │ ├── 题目/ │ │ ├── A01_xxx.md │ │ └── A02_xxx.md │ ├── 源码/ │ │ ├── A01_xxx.py │ │ └── A02_xxx.py │ └── 数据/ │ ├── A01_1.in │ └── A01_1.out ├── B组/ # 大学 B 组中等 └── C组/ # 大学 C 组压轴几个细节值得先说清楚。一是题面用 Markdown 而不是 PDF这对二次开发太友好了后面做检索、做题型归类都能直接读文本如果拿到的是 PDF还得先跑一遍转换。二是源码文件与题面文件同名同前缀这种一一对应的命名是我最欣赏的地方脚本里只要把后缀换掉就能配对不用维护额外的映射表。三是数据目录里的.in/.out成对出现_1、_2表示第几组样例——这是本地对拍的命根子别随手删。提示解压后先确认文件编码。题面如果是 GBK 存的中文Path.read_text()默认 UTF-8 会直接抛UnicodeDecodeError读的时候把errorsignore或显式encodinggbk兜一下比较稳。2.2 题面、源码、样例三者的对应关系题面文件内部的结构一般是固定的四段题目描述、输入格式、输出格式、样例说明。做二次开发时真正要抓的是「输入格式」和「输出格式」这两段它们决定了你的读入模板和输出格式而「题目描述」只是背景故事。我见过太多人只读描述不读格式结果多组数据只读了一组样例碰巧过了交上去全错。源码这一块要摆正心态它是参考实现不是标准答案。同一道题可能有复杂度差一个数量级的两种写法参考源码为了可读性往往选的是直观那版不一定是最优那版。所以你拿它对拍对的是「结果一致」不是「写法一致」。真要在赛场上用最稳妥的做法是自己重写一遍再拿参考源码当对拍的另一方。样例数据的对应关系靠文件名前缀维持A01_1.in配A01_1.out。这里有个血泪经验有些包的.out文件末尾带一个空行有些没有直接字符串比较会莫名其妙判错比对前统一strip()一遍能省掉半天排查。2.3 写个脚本把题目变成可检索的索引题目一多靠肉眼找「哪几道是前缀和」低效得离谱。我一般会先花十分钟写个索引脚本扫一遍目录把题号、组别、题名、粗略题型标签吐成 JSON 和一张 Markdown 表。# build_index.py —— 扫描真题包生成题目索引JSON Markdown import json import re from pathlib import Path ROOT Path(./第14届-Python省赛真题) # 解压后的根目录按实际改 GROUPS [A组, B组, C组] # 用来做粗略题型归类的关键词可按需增删 KEYWORDS (前缀和, 二分, 动态规划, BFS, DFS, 并查集, 贪心, 模拟) def parse_statement(md_path: Path) - dict: 从题面 Markdown 里抽取题名和关键词标签。 text md_path.read_text(encodingutf-8, errorsignore) lines [ln.strip() for ln in text.splitlines() if ln.strip()] # 第一行非空内容通常是一级标题去掉 # 号就是题名 title re.sub(r^#\s*, , lines[0]) if lines else md_path.stem tags [kw for kw in KEYWORDS if kw in text] return {title: title, tags: tags, chars: len(text)} def main() - None: index [] for group in GROUPS: statement_dir ROOT / group / 题目 if not statement_dir.is_dir(): continue for md in sorted(statement_dir.glob(*.md)): item parse_statement(md) item[group] group item[id] md.stem.split(_)[0] # 例如 A01 item[statement] str(md) item[code] str(md.parent.parent / 源码 / (md.stem .py)) index.append(item) Path(index.json).write_text( json.dumps(index, ensure_asciiFalse, indent2), encodingutf-8) # 顺手生成一张方便人看的表格 rows [| 题号 | 组别 | 题名 | 标签 |, | --- | --- | --- | --- |] for it in index: rows.append(f| {it[id]} | {it[group]} | {it[title]} | {,.join(it[tags])} |) Path(index.md).write_text(\n.join(rows), encodingutf-8) print(f共索引 {len(index)} 道题) if __name__ __main__: main()逻辑上就三步遍历组别目录 → 每读一个.md抽题名和关键词 → 按命名规则反推源码路径并落盘。ROOT改成你自己解压的位置GROUPS如果包里的目录叫大学A组之类改这一行即可不用动循环体。KEYWORDS是做粗筛的不是精确分类别指望它能区分「二分答案」和「二分查找」——真要精细归类得在题面里找更具体的句式比如「最小的最大值」基本就是二分答案。item[code]之所以用md.parent.parent是因为题面在A组/题目/下往上两级才是A组/再拼源码/。这一步写错索引里所有源码路径全废脚本不报错但后面批量跑会集体FileNotFoundError。3. 跑通第一份源码Python 版本、标准 IO 与批量自测光能打开文件不算跑通能把参考源码在本机按题目要求喂进数据、吐出正确结果才算真的跑起来了。这一章解决的就是「代码在哪跑、怎么喂数据、怎么批量验证」这三件事。3.1 环境准备先别急着装第三方库这类真题包里的参考实现绝大多数只用了标准库sys、collections、heapq、bisect、math就够了。所以环境准备的重点不是装包而是版本对齐。# 建议单独建一个环境别污染主解释器 python3 -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate # 确认版本3.8 以上基本够用 python -V # 先跑一次编译检查能一次性揪出语法层面的问题 python -m compileall 第14届-Python省赛真题/源码compileall这一步我几乎每次都做成本几秒钟收益是能提前发现「这份源码用了你当前解释器不支持的语法」——比如某些写法依赖 3.10 的结构化模式匹配你在 3.8 环境里会直接 SyntaxError而不是跑出错误答案两者排查成本差很远。版本这块还有个隐形坑不同届次的题目在输入规模上差别很大同一份代码在 3.8 和 3.11 上的实际耗时可能差一截。如果你在本地测出来「刚好卡在时间上限」别急着优化算法先换个版本跑一遍有时候就是解释器差异。3.2 真题都是标准输入输出三种读入模板赛题不会让你读文件也不会让你调函数一律走标准输入输出。所以参考源码里必然有一段读入逻辑形式无非三种单组定长、多组不定长、一行多个整数。把这三套模板背下来读任何一份源码都能立刻定位到「它怎么拿数据的」。import sys def read_all_tokens() - list: 最通用的读法一次性读入全部 token按空白切分。 return sys.stdin.buffer.read().split() def solve_single() - None: 单组定长输入第一行 n第二行 n 个数。 data sys.stdin.buffer.read().split() if not data: return n int(data[0]) arr list(map(int, data[1:1 n])) print(sum(arr)) def solve_multi() - None: 多组输入读到 EOF 为止每组第一行是 n。 data sys.stdin.buffer.read().split() idx, total 0, len(data) out [] while idx total: n int(data[idx]) idx 1 arr list(map(int, data[idx:idx n])) idx n out.append(str(sum(arr))) sys.stdout.write(\n.join(out)) if __name__ __main__: # 单组题调 solve_single多组题调 solve_multi solve_multi()关键点是sys.stdin.buffer.read()它拿到的是字节流一次系统调用读完全部输入再split()成 token 列表。对比之下循环里反复调input()在十万行级别的输入下会慢一个数量级这就是很多题「逻辑没错但超时」的真实原因。buffer这一层不能省直接sys.stdin.read()拿到的是 str中间的编解码同样要花时间。solve_multi里那个idx指针是核心它同时承担「读 n」和「跳 n 个数」两个职责。写多组输入的题最典型的翻车方式就是忘了idx n导致下一组读到的还是上一组的数据输出行数对不上但程序不报错。3.3 写一个极简对拍器把样例全跑一遍手动python A01.py A01_1.in一次一次敲十道题之后就烦了。写个几十行的对拍脚本把「跑 比 计时」三件事一次做完后面所有题都受益。# judge.py —— 极简本地对拍器 import subprocess import sys import time from pathlib import Path ROOT Path(./第14届-Python省赛真题) TIMEOUT 5.0 # 单组样例超时秒数按题目规模调 def run_case(code: Path, in_file: Path) - tuple: 跑一组样例返回 (是否通过, 耗时, 实际输出/错误信息)。 expected in_file.with_suffix(.out).read_text(encodingutf-8).strip() start time.perf_counter() try: proc subprocess.run( [sys.executable, str(code)], stdinin_file.open(rb), capture_outputTrue, timeoutTIMEOUT, ) except subprocess.TimeoutExpired: return False, TIMEOUT, TIMEOUT cost time.perf_counter() - start if proc.returncode ! 0: return False, cost, proc.stderr.decode(utf-8, ignore)[-300:] actual proc.stdout.decode(utf-8, ignore).strip() return actual expected, cost, actual[:300] def main() - None: for code in sorted(ROOT.glob(*/源码/*.py)): cases sorted((code.parent.parent / 数据).glob(code.stem _*.in)) for in_file in cases: ok, cost, msg run_case(code, in_file) flag PASS if ok else FAIL print(f[{flag}] {code.name} {in_file.name} {cost:.3f}s) if not ok: print( , msg) if __name__ __main__: main()TIMEOUT是必须设的不然某份源码里有个死循环整个脚本就挂在那儿了。strip()比对前面提过是为了抹平行尾空白差异。输出只截前 300 个字符是因为有的题答案是一整个大矩阵全打出来屏幕直接刷没反而不方便看。这套脚本跑完你手上就有了一张「哪几道题参考源码自己能过、耗时多少」的体检表。耗时那一列特别有价值Python 在计算密集题上比 C 慢三十到五十倍是常态如果某道题参考实现跑了 3 秒那说明这题的标程预期复杂度大概率是 O(n log n)你手上那份可能是优化过的版本值得单独读一读。3.4 复杂度预算动手写之前先算一遍赛题给的数据范围就是明牌告诉你该用什么算法。经验换算大致是Python 一秒能扛的简单循环操作在千万级别所以 n 到 10⁵ 就必须往 O(n log n) 走n 到 10³ 才能容忍 O(n²)。这套判断比「先写完再看超不超时」高效得多因为超时之后你并不知道是算法选错还是常数太大。拿到一道题先看输入规模再定复杂度上限最后才动手写——顺序反了就等着推倒重来。4. 三道典型题的代码骨架模拟、前缀和加二分、网格 BFS把三组的题摊开看A 组的形态是「规则翻译成循环」B 组开始出现区间查询和有序性利用C 组压轴则集中在一维状态转移和二维网格搜索上。下面挑三类最有代表性的骨架代码是我自己习惯的写法你可以直接拿去当模板改。4.1 A 组模拟题就是把规则逐条翻成循环模拟题的坑不在算法在边界。以日期推算这类题为例闰年判断、月份天数表、跨年进位三处任何一处写错样例都可能碰巧过。import sys # 平年每月天数下标 0 占位方便直接用月份索引 DAYS [0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31] def is_leap(y: int) - bool: 闰年能被 4 整除且不能被 100 整除或者能被 400 整除。 return (y % 4 0 and y % 100 ! 0) or y % 400 0 def days_in_month(y: int, m: int) - int: if m 2 and is_leap(y): return 29 return DAYS[m] def day_of_year(y: int, m: int, d: int) - int: 返回这一天是本年的第几天。 total sum(days_in_month(y, i) for i in range(1, m)) return total d def main() - None: data sys.stdin.buffer.read().split() if not data: return y, m, d map(int, data[:3]) print(day_of_year(y, m, d)) if __name__ __main__: main()DAYS表用 13 个元素是为了让月份直接当下标用省掉m - 1这种容易写漏的偏移。is_leap的三个条件必须按顺序写全只写y % 4 0是本类题最高频的错误1900 年这种整百年份就会错。day_of_year里用生成器求和而不是手写循环纯粹是可读性考虑n 只有 12性能无所谓。如果题目改成「求 N 天后的日期」思路一样只是把「求和」换成「逐天推进」或者「按年跳跃」。按年跳跃的写法在 N 到 10⁹ 时是必须的逐天推进会直接超时——这就是上一节说的复杂度预算。4.2 B 组前缀和加二分区间查询类题的固定套路B 组很爱考「区间和」「第几个满足条件的位置」这类问题。核心就两步先把数组压成前缀和让区间求和变成 O(1)再用bisect在有序的前缀和上做二分。import sys from bisect import bisect_left def main() - None: data sys.stdin.buffer.read().split() if not data: return it iter(data) n int(next(it)) a [int(next(it)) for _ in range(n)] # pre[i] 表示前 i 个元素之和pre[0] 0 # 全部为正数时 pre 严格递增可以直接二分 pre [0] * (n 1) for i, v in enumerate(a, 1): pre[i] pre[i - 1] v q int(next(it)) out [] for _ in range(q): x int(next(it)) # 找第一个前缀和 x 的下标即最少取几个数能凑到 x pos bisect_left(pre, x) if pos n: out.append(-1) # 全部加起来也不够 else: out.append(str(pos)) sys.stdout.write(\n.join(out)) if __name__ __main__: main()pre开n 1长度、pre[0] 0是为了让「前 i 个」和「下标 i」对齐查询区间[l, r]时直接pre[r] - pre[l - 1]不用写额外的判断。这个下标偏移我踩过不止一次早期总喜欢开n长度然后各种1 -1补补到最后自己都看不懂。bisect_left和bisect_right的区别要记牢找「第一个大于等于 x」用left找「第一个大于 x」用right。题目问法差一个字答案差一位。另外这套写法有个前提——数组元素全为正前缀和才单调能二分。如果数组里有负数前缀和不再有序就得换成分块或者树状数组这是 B 组往 C 组过渡的分水岭。4.3 C 组网格 BFS 与一维 DP两种压轴形态C 组压轴基本跑不出两类二维网格上的最短步数和一维序列上的方案数统计。前者用 BFS后者用 DP。import sys from collections import deque # 上下左右四个方向写成常量比在循环里手写 dx/dy 清楚得多 DIRS ((1, 0), (-1, 0), (0, 1), (0, -1)) def bfs(grid: list, sr: int, sc: int, tr: int, tc: int) - int: 从 (sr, sc) 走到 (tr, tc) 的最少步数走不通返回 -1。 n, m len(grid), len(grid[0]) dist [[-1] * m for _ in range(n)] # -1 同时表示未访问 dist[sr][sc] 0 q deque([(sr, sc)]) while q: r, c q.popleft() if (r, c) (tr, tc): return dist[r][c] for dr, dc in DIRS: nr, nc r dr, c dc # 越界、障碍、已访问三种情况一起挡掉 if 0 nr n and 0 nc m and grid[nr][nc] 0 and dist[nr][nc] -1: dist[nr][nc] dist[r][c] 1 q.append((nr, nc)) return -1 def main() - None: data sys.stdin.buffer.read().split() if not data: return it iter(data) n, m int(next(it)), int(next(it)) grid [[int(next(it)) for _ in range(m)] for _ in range(n)] sr, sc int(next(it)), int(next(it)) tr, tc int(next(it)), int(next(it)) print(bfs(grid, sr, sc, tr, tc)) if __name__ __main__: main()这段代码里三个地方值得单独说。dist初始化为-1而不是一个很大的数省掉一个visited数组判断更集中。入队时就把dist写好而不是出队时再写这是 BFS 保证「第一次到达即最短」的关键——出队才标记的话同一个点可能被重复入队规模一大就爆内存。方向数组写成模块级常量是因为 C 组有些题要改成八方向改一处就够了。注意网格题的坐标顺序。题面说「第 r 行第 c 列」还是「x 坐标 y 坐标」读反了样例可能碰巧对大数据必错。这类题我一般先用一组非正方形的输入验证一下长方形网格能立刻暴露行列颠倒。4.4 两个容易被忽略的开关递归深度与取模C 组里只要出现「方案数」答案基本要你对 10⁹7 取模。取模的原则是每加一次就取一次不要攒到最后Python 的大整数虽然不会溢出但几千位的大数做加法会慢得离谱。DFS 写法则要提前调sys.setrecursionlimit(1 20)默认的一千层在网格搜索里根本不够用触发RecursionError的时候你会以为是逻辑写错了其实只是栈太浅。不过话说回来网格搜索我更推荐用 BFS 或者显式栈的迭代写法递归在 Python 里既慢又容易炸。5. 常见问题排查本地过样例、提交却翻车的五个现场这部分是我自己刷题和帮人看代码时积攒下来的高频现场每条都按「现象 → 原因 → 解决」写对照着查基本能命中。5.1 输入类多组数据只读了一组现象是本地跑样例输出完全正确提交后一半测试点错错误输出往往只有一行而期望是多行。原因基本是题目用「读到文件末尾为止」的多组输入而代码里只写了一次读入。解决方式是改成while idx total的指针推进写法本地自测时至少构造两组数据拼在一起喂进去看输出行数对不对得上。我自己习惯在写完读入之后先print一下组数确认读的组数和预期一致再往下写逻辑。5.2 输出类多余的提示语和行尾空格现象是答案肉眼看着一模一样判题机却判错。原因通常是两种一是代码里写了print(请输入n:)这类交互提示判题机把它当成输出的一部分二是用print(*arr)打了多个数题面要求用空格分隔而某种情况下末尾多了个空格。解决办法是判题场景只用sys.stdout.write(\n.join(...))输出格式严格按题面的分隔符拼不要依赖print的默认行为。5.3 性能类样例秒过、大数据超时现象是耗时那一列在小样例上是 0.01 秒换大样例直接跑到 5 秒被掐断。原因有两层算法复杂度选错或者复杂度对了但常数太大。前者看数据范围就能判断n 到 10⁵ 还在写双重循环必然是这个问题后者常见于循环里反复调input()、反复切片、反复list.append之外的重建。解决顺序是先换算法算法对了再抠常数——反过来做常常是白优化。5.4 环境类相对路径与编码不一致现象是脚本在题目目录里能跑换个目录就FileNotFoundError或者中文题面读出来是乱码。原因是代码里用了相对路径工作目录一变就失效编码问题则是文件存的是 GBK 而读的时候按 UTF-8 解。解决办法是把路径统一收敛成基于Path(__file__).parent的绝对路径读文件时显式带encoding读题面时加errorsignore兜底宁可丢几个字符也别让脚本中途崩。5.5 逻辑类边界值一个都没覆盖现象是样例全过只有个别测试点挂而且挂的那几个往往是 n1、全相同元素、空输入这类极端情况。原因很直接——样例通常给的是「正常规模」的数据边界根本没覆盖到。解决方式是写完先自己造三组数据最小规模、全相同、极端大。这三组不用判对错只看程序会不会崩、会不会除零、会不会跑出负数。这套动作我一般固定成习惯比事后 debug 便宜太多了。6. 二次开发把真题包改成自己的刷题流水线题面和源码是静态的但只要你加一点自动化它就能变成一个可复用的训练环境。最划算的三个改造方向按投入产出排序是这样改造方向改动点收益用例驱动测试把judge.py改成 pytest 参数化一题一函数改完代码一键回归不用手动敲命令题库检索index.json落进 SQLite加题号、组别、标签字段按「前缀和」筛选题目专项突破错题沉淀每道题维护一份notes.md记下卡点和最终复杂度复习时不重走老路pytest 这条路最省事把对拍的循环换成参数化即可import subprocess, sys, pytest from pathlib import Path ROOT Path(./第14届-Python省赛真题) CASES [(c, c.with_suffix(.out)) for c in sorted(ROOT.glob(*/数据/*.in))] pytest.mark.parametrize(in_file,out_file, CASES) def test_sample(in_file, out_file): code in_file.parent.parent / 源码 / (in_file.stem.split(_)[0] .py) # 题号前缀可能带后缀找不到就跳过避免整批报错 if not code.exists(): pytest.skip(f未找到 {code.name}) proc subprocess.run([sys.executable, str(code)], stdinin_file.open(rb), capture_outputTrue, timeout10) assert proc.stdout.decode().strip() out_file.read_text(encodingutf-8).strip()跑一次pytest -q几十道题的样例状态一目了然改完参考实现立刻知道有没有把别的地方改坏。这里有个小教训in_file.stem带_1后缀取题号必须split(_)[0]我第一次写的时候忘了切结果全部跳过还以为是 glob 路径写错了查了二十分钟。另一件我现在强制自己做的事是每道题跑通之后立刻在题面同目录写三行笔记用了什么算法、复杂度多少、卡在哪个边界。这套真题包本身没有答案讲解参考源码也不写思路笔记就是唯一的后悔药。等你二刷的时候翻笔记比翻代码快十倍。以上这些跑通之后这份包就不只是「一份真题」了而是你自己的一台小型训练机。希望帮到你。本文还有配套的精品资源点击获取
简介这份压缩包面向备战蓝桥杯Python省赛大学A、B、C组的参赛者汇集第14届省赛的完整题目与配套程序源码适合用于熟悉赛题风格、开展赛前专项训练以及对照源码复盘解题思路。包内共35个文件以32个py源码和3个pdf题目文档为主源码可用于运行验证与解法研读pdf便于阅读原始赛题与打印练习整体约5.34MB。目前已有1077人学习或下载具备一定的参考热度。内容按A、B、C组分别组织读者可结合题目要求逐题对照源码理解输入输出处理、算法选择与边界条件设置也能借助完整题面进行限时模拟和查漏补缺既可按组别横向比较命题差异也可按题型纵向归纳常用写法。对于需要系统梳理省赛知识点、提升Python解题熟练度的选手这份材料提供了较完整的练习与参考样本。1. 从一次「样例全过、提交全挂」说起前阵子有个学弟抱着压缩包来找我说他刷了三十多道 Python 省赛真题本地样例全绿一提交就挂。我翻了他那份包——按大学 A、B、C 三个组别分目录题面、样例、参考源码三件套齐全结构其实很干净问题出在他从来没按「标准输入输出 多组数据」的习惯读过题。这份第 14 届省赛 Python 组真题包大学 A/B/C 组题目与源码完整真正的价值不在题量而在于它把三档难度、同一套命题风格摊开给你看A 组偏语法与模拟B 组开始上前缀和、二分C 组压轴基本是搜索和动态规划。适合刚学完 Python 语法想系统过一遍真题的学生也适合需要现成题面和参考实现来排训练的老师。下面按我实际拆包、跑题、改脚本的顺序讲。2. 目录结构拆解A/B/C 三组的题面与源码怎么摆解压本身没技术含量但目录摆得清不清楚直接决定你后面是「按组顺着刷」还是「翻半小时找一个文件」。我拿到这份包的第一件事不是打开题目而是先把目录树打出来把命名规则摸透——后面写索引脚本、做批量对拍全靠这套规则吃饭。2.1 三组平铺的骨架与文件命名规则常见做法是按组别切三个一级目录组内再分「题目 / 源码 / 数据」三块题号前缀统一。这样摆的好处是排序稳定A01、A02一直到A10不会因为字典序变成A1、A10、A2脚本glob出来的顺序就是你要的顺序。第14届-Python省赛真题/ ├── README.md # 组别说明、难度标注、注意事项 ├── A组/ # 大学 A 组偏基础 │ ├── 题目/ │ │ ├── A01_xxx.md │ │ └── A02_xxx.md │ ├── 源码/ │ │ ├── A01_xxx.py │ │ └── A02_xxx.py │ └── 数据/ │ ├── A01_1.in │ └── A01_1.out ├── B组/ # 大学 B 组中等 └── C组/ # 大学 C 组压轴几个细节值得先说清楚。一是题面用 Markdown 而不是 PDF这对二次开发太友好了后面做检索、做题型归类都能直接读文本如果拿到的是 PDF还得先跑一遍转换。二是源码文件与题面文件同名同前缀这种一一对应的命名是我最欣赏的地方脚本里只要把后缀换掉就能配对不用维护额外的映射表。三是数据目录里的.in/.out成对出现_1、_2表示第几组样例——这是本地对拍的命根子别随手删。提示解压后先确认文件编码。题面如果是 GBK 存的中文Path.read_text()默认 UTF-8 会直接抛UnicodeDecodeError读的时候把errorsignore或显式encodinggbk兜一下比较稳。2.2 题面、源码、样例三者的对应关系题面文件内部的结构一般是固定的四段题目描述、输入格式、输出格式、样例说明。做二次开发时真正要抓的是「输入格式」和「输出格式」这两段它们决定了你的读入模板和输出格式而「题目描述」只是背景故事。我见过太多人只读描述不读格式结果多组数据只读了一组样例碰巧过了交上去全错。源码这一块要摆正心态它是参考实现不是标准答案。同一道题可能有复杂度差一个数量级的两种写法参考源码为了可读性往往选的是直观那版不一定是最优那版。所以你拿它对拍对的是「结果一致」不是「写法一致」。真要在赛场上用最稳妥的做法是自己重写一遍再拿参考源码当对拍的另一方。样例数据的对应关系靠文件名前缀维持A01_1.in配A01_1.out。这里有个血泪经验有些包的.out文件末尾带一个空行有些没有直接字符串比较会莫名其妙判错比对前统一strip()一遍能省掉半天排查。2.3 写个脚本把题目变成可检索的索引题目一多靠肉眼找「哪几道是前缀和」低效得离谱。我一般会先花十分钟写个索引脚本扫一遍目录把题号、组别、题名、粗略题型标签吐成 JSON 和一张 Markdown 表。# build_index.py —— 扫描真题包生成题目索引JSON Markdown import json import re from pathlib import Path ROOT Path(./第14届-Python省赛真题) # 解压后的根目录按实际改 GROUPS [A组, B组, C组] # 用来做粗略题型归类的关键词可按需增删 KEYWORDS (前缀和, 二分, 动态规划, BFS, DFS, 并查集, 贪心, 模拟) def parse_statement(md_path: Path) - dict: 从题面 Markdown 里抽取题名和关键词标签。 text md_path.read_text(encodingutf-8, errorsignore) lines [ln.strip() for ln in text.splitlines() if ln.strip()] # 第一行非空内容通常是一级标题去掉 # 号就是题名 title re.sub(r^#\s*, , lines[0]) if lines else md_path.stem tags [kw for kw in KEYWORDS if kw in text] return {title: title, tags: tags, chars: len(text)} def main() - None: index [] for group in GROUPS: statement_dir ROOT / group / 题目 if not statement_dir.is_dir(): continue for md in sorted(statement_dir.glob(*.md)): item parse_statement(md) item[group] group item[id] md.stem.split(_)[0] # 例如 A01 item[statement] str(md) item[code] str(md.parent.parent / 源码 / (md.stem .py)) index.append(item) Path(index.json).write_text( json.dumps(index, ensure_asciiFalse, indent2), encodingutf-8) # 顺手生成一张方便人看的表格 rows [| 题号 | 组别 | 题名 | 标签 |, | --- | --- | --- | --- |] for it in index: rows.append(f| {it[id]} | {it[group]} | {it[title]} | {,.join(it[tags])} |) Path(index.md).write_text(\n.join(rows), encodingutf-8) print(f共索引 {len(index)} 道题) if __name__ __main__: main()逻辑上就三步遍历组别目录 → 每读一个.md抽题名和关键词 → 按命名规则反推源码路径并落盘。ROOT改成你自己解压的位置GROUPS如果包里的目录叫大学A组之类改这一行即可不用动循环体。KEYWORDS是做粗筛的不是精确分类别指望它能区分「二分答案」和「二分查找」——真要精细归类得在题面里找更具体的句式比如「最小的最大值」基本就是二分答案。item[code]之所以用md.parent.parent是因为题面在A组/题目/下往上两级才是A组/再拼源码/。这一步写错索引里所有源码路径全废脚本不报错但后面批量跑会集体FileNotFoundError。3. 跑通第一份源码Python 版本、标准 IO 与批量自测光能打开文件不算跑通能把参考源码在本机按题目要求喂进数据、吐出正确结果才算真的跑起来了。这一章解决的就是「代码在哪跑、怎么喂数据、怎么批量验证」这三件事。3.1 环境准备先别急着装第三方库这类真题包里的参考实现绝大多数只用了标准库sys、collections、heapq、bisect、math就够了。所以环境准备的重点不是装包而是版本对齐。# 建议单独建一个环境别污染主解释器 python3 -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate # 确认版本3.8 以上基本够用 python -V # 先跑一次编译检查能一次性揪出语法层面的问题 python -m compileall 第14届-Python省赛真题/源码compileall这一步我几乎每次都做成本几秒钟收益是能提前发现「这份源码用了你当前解释器不支持的语法」——比如某些写法依赖 3.10 的结构化模式匹配你在 3.8 环境里会直接 SyntaxError而不是跑出错误答案两者排查成本差很远。版本这块还有个隐形坑不同届次的题目在输入规模上差别很大同一份代码在 3.8 和 3.11 上的实际耗时可能差一截。如果你在本地测出来「刚好卡在时间上限」别急着优化算法先换个版本跑一遍有时候就是解释器差异。3.2 真题都是标准输入输出三种读入模板赛题不会让你读文件也不会让你调函数一律走标准输入输出。所以参考源码里必然有一段读入逻辑形式无非三种单组定长、多组不定长、一行多个整数。把这三套模板背下来读任何一份源码都能立刻定位到「它怎么拿数据的」。import sys def read_all_tokens() - list: 最通用的读法一次性读入全部 token按空白切分。 return sys.stdin.buffer.read().split() def solve_single() - None: 单组定长输入第一行 n第二行 n 个数。 data sys.stdin.buffer.read().split() if not data: return n int(data[0]) arr list(map(int, data[1:1 n])) print(sum(arr)) def solve_multi() - None: 多组输入读到 EOF 为止每组第一行是 n。 data sys.stdin.buffer.read().split() idx, total 0, len(data) out [] while idx total: n int(data[idx]) idx 1 arr list(map(int, data[idx:idx n])) idx n out.append(str(sum(arr))) sys.stdout.write(\n.join(out)) if __name__ __main__: # 单组题调 solve_single多组题调 solve_multi solve_multi()关键点是sys.stdin.buffer.read()它拿到的是字节流一次系统调用读完全部输入再split()成 token 列表。对比之下循环里反复调input()在十万行级别的输入下会慢一个数量级这就是很多题「逻辑没错但超时」的真实原因。buffer这一层不能省直接sys.stdin.read()拿到的是 str中间的编解码同样要花时间。solve_multi里那个idx指针是核心它同时承担「读 n」和「跳 n 个数」两个职责。写多组输入的题最典型的翻车方式就是忘了idx n导致下一组读到的还是上一组的数据输出行数对不上但程序不报错。3.3 写一个极简对拍器把样例全跑一遍手动python A01.py A01_1.in一次一次敲十道题之后就烦了。写个几十行的对拍脚本把「跑 比 计时」三件事一次做完后面所有题都受益。# judge.py —— 极简本地对拍器 import subprocess import sys import time from pathlib import Path ROOT Path(./第14届-Python省赛真题) TIMEOUT 5.0 # 单组样例超时秒数按题目规模调 def run_case(code: Path, in_file: Path) - tuple: 跑一组样例返回 (是否通过, 耗时, 实际输出/错误信息)。 expected in_file.with_suffix(.out).read_text(encodingutf-8).strip() start time.perf_counter() try: proc subprocess.run( [sys.executable, str(code)], stdinin_file.open(rb), capture_outputTrue, timeoutTIMEOUT, ) except subprocess.TimeoutExpired: return False, TIMEOUT, TIMEOUT cost time.perf_counter() - start if proc.returncode ! 0: return False, cost, proc.stderr.decode(utf-8, ignore)[-300:] actual proc.stdout.decode(utf-8, ignore).strip() return actual expected, cost, actual[:300] def main() - None: for code in sorted(ROOT.glob(*/源码/*.py)): cases sorted((code.parent.parent / 数据).glob(code.stem _*.in)) for in_file in cases: ok, cost, msg run_case(code, in_file) flag PASS if ok else FAIL print(f[{flag}] {code.name} {in_file.name} {cost:.3f}s) if not ok: print( , msg) if __name__ __main__: main()TIMEOUT是必须设的不然某份源码里有个死循环整个脚本就挂在那儿了。strip()比对前面提过是为了抹平行尾空白差异。输出只截前 300 个字符是因为有的题答案是一整个大矩阵全打出来屏幕直接刷没反而不方便看。这套脚本跑完你手上就有了一张「哪几道题参考源码自己能过、耗时多少」的体检表。耗时那一列特别有价值Python 在计算密集题上比 C 慢三十到五十倍是常态如果某道题参考实现跑了 3 秒那说明这题的标程预期复杂度大概率是 O(n log n)你手上那份可能是优化过的版本值得单独读一读。3.4 复杂度预算动手写之前先算一遍赛题给的数据范围就是明牌告诉你该用什么算法。经验换算大致是Python 一秒能扛的简单循环操作在千万级别所以 n 到 10⁵ 就必须往 O(n log n) 走n 到 10³ 才能容忍 O(n²)。这套判断比「先写完再看超不超时」高效得多因为超时之后你并不知道是算法选错还是常数太大。拿到一道题先看输入规模再定复杂度上限最后才动手写——顺序反了就等着推倒重来。4. 三道典型题的代码骨架模拟、前缀和加二分、网格 BFS把三组的题摊开看A 组的形态是「规则翻译成循环」B 组开始出现区间查询和有序性利用C 组压轴则集中在一维状态转移和二维网格搜索上。下面挑三类最有代表性的骨架代码是我自己习惯的写法你可以直接拿去当模板改。4.1 A 组模拟题就是把规则逐条翻成循环模拟题的坑不在算法在边界。以日期推算这类题为例闰年判断、月份天数表、跨年进位三处任何一处写错样例都可能碰巧过。import sys # 平年每月天数下标 0 占位方便直接用月份索引 DAYS [0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31] def is_leap(y: int) - bool: 闰年能被 4 整除且不能被 100 整除或者能被 400 整除。 return (y % 4 0 and y % 100 ! 0) or y % 400 0 def days_in_month(y: int, m: int) - int: if m 2 and is_leap(y): return 29 return DAYS[m] def day_of_year(y: int, m: int, d: int) - int: 返回这一天是本年的第几天。 total sum(days_in_month(y, i) for i in range(1, m)) return total d def main() - None: data sys.stdin.buffer.read().split() if not data: return y, m, d map(int, data[:3]) print(day_of_year(y, m, d)) if __name__ __main__: main()DAYS表用 13 个元素是为了让月份直接当下标用省掉m - 1这种容易写漏的偏移。is_leap的三个条件必须按顺序写全只写y % 4 0是本类题最高频的错误1900 年这种整百年份就会错。day_of_year里用生成器求和而不是手写循环纯粹是可读性考虑n 只有 12性能无所谓。如果题目改成「求 N 天后的日期」思路一样只是把「求和」换成「逐天推进」或者「按年跳跃」。按年跳跃的写法在 N 到 10⁹ 时是必须的逐天推进会直接超时——这就是上一节说的复杂度预算。4.2 B 组前缀和加二分区间查询类题的固定套路B 组很爱考「区间和」「第几个满足条件的位置」这类问题。核心就两步先把数组压成前缀和让区间求和变成 O(1)再用bisect在有序的前缀和上做二分。import sys from bisect import bisect_left def main() - None: data sys.stdin.buffer.read().split() if not data: return it iter(data) n int(next(it)) a [int(next(it)) for _ in range(n)] # pre[i] 表示前 i 个元素之和pre[0] 0 # 全部为正数时 pre 严格递增可以直接二分 pre [0] * (n 1) for i, v in enumerate(a, 1): pre[i] pre[i - 1] v q int(next(it)) out [] for _ in range(q): x int(next(it)) # 找第一个前缀和 x 的下标即最少取几个数能凑到 x pos bisect_left(pre, x) if pos n: out.append(-1) # 全部加起来也不够 else: out.append(str(pos)) sys.stdout.write(\n.join(out)) if __name__ __main__: main()pre开n 1长度、pre[0] 0是为了让「前 i 个」和「下标 i」对齐查询区间[l, r]时直接pre[r] - pre[l - 1]不用写额外的判断。这个下标偏移我踩过不止一次早期总喜欢开n长度然后各种1 -1补补到最后自己都看不懂。bisect_left和bisect_right的区别要记牢找「第一个大于等于 x」用left找「第一个大于 x」用right。题目问法差一个字答案差一位。另外这套写法有个前提——数组元素全为正前缀和才单调能二分。如果数组里有负数前缀和不再有序就得换成分块或者树状数组这是 B 组往 C 组过渡的分水岭。4.3 C 组网格 BFS 与一维 DP两种压轴形态C 组压轴基本跑不出两类二维网格上的最短步数和一维序列上的方案数统计。前者用 BFS后者用 DP。import sys from collections import deque # 上下左右四个方向写成常量比在循环里手写 dx/dy 清楚得多 DIRS ((1, 0), (-1, 0), (0, 1), (0, -1)) def bfs(grid: list, sr: int, sc: int, tr: int, tc: int) - int: 从 (sr, sc) 走到 (tr, tc) 的最少步数走不通返回 -1。 n, m len(grid), len(grid[0]) dist [[-1] * m for _ in range(n)] # -1 同时表示未访问 dist[sr][sc] 0 q deque([(sr, sc)]) while q: r, c q.popleft() if (r, c) (tr, tc): return dist[r][c] for dr, dc in DIRS: nr, nc r dr, c dc # 越界、障碍、已访问三种情况一起挡掉 if 0 nr n and 0 nc m and grid[nr][nc] 0 and dist[nr][nc] -1: dist[nr][nc] dist[r][c] 1 q.append((nr, nc)) return -1 def main() - None: data sys.stdin.buffer.read().split() if not data: return it iter(data) n, m int(next(it)), int(next(it)) grid [[int(next(it)) for _ in range(m)] for _ in range(n)] sr, sc int(next(it)), int(next(it)) tr, tc int(next(it)), int(next(it)) print(bfs(grid, sr, sc, tr, tc)) if __name__ __main__: main()这段代码里三个地方值得单独说。dist初始化为-1而不是一个很大的数省掉一个visited数组判断更集中。入队时就把dist写好而不是出队时再写这是 BFS 保证「第一次到达即最短」的关键——出队才标记的话同一个点可能被重复入队规模一大就爆内存。方向数组写成模块级常量是因为 C 组有些题要改成八方向改一处就够了。注意网格题的坐标顺序。题面说「第 r 行第 c 列」还是「x 坐标 y 坐标」读反了样例可能碰巧对大数据必错。这类题我一般先用一组非正方形的输入验证一下长方形网格能立刻暴露行列颠倒。4.4 两个容易被忽略的开关递归深度与取模C 组里只要出现「方案数」答案基本要你对 10⁹7 取模。取模的原则是每加一次就取一次不要攒到最后Python 的大整数虽然不会溢出但几千位的大数做加法会慢得离谱。DFS 写法则要提前调sys.setrecursionlimit(1 20)默认的一千层在网格搜索里根本不够用触发RecursionError的时候你会以为是逻辑写错了其实只是栈太浅。不过话说回来网格搜索我更推荐用 BFS 或者显式栈的迭代写法递归在 Python 里既慢又容易炸。5. 常见问题排查本地过样例、提交却翻车的五个现场这部分是我自己刷题和帮人看代码时积攒下来的高频现场每条都按「现象 → 原因 → 解决」写对照着查基本能命中。5.1 输入类多组数据只读了一组现象是本地跑样例输出完全正确提交后一半测试点错错误输出往往只有一行而期望是多行。原因基本是题目用「读到文件末尾为止」的多组输入而代码里只写了一次读入。解决方式是改成while idx total的指针推进写法本地自测时至少构造两组数据拼在一起喂进去看输出行数对不对得上。我自己习惯在写完读入之后先print一下组数确认读的组数和预期一致再往下写逻辑。5.2 输出类多余的提示语和行尾空格现象是答案肉眼看着一模一样判题机却判错。原因通常是两种一是代码里写了print(请输入n:)这类交互提示判题机把它当成输出的一部分二是用print(*arr)打了多个数题面要求用空格分隔而某种情况下末尾多了个空格。解决办法是判题场景只用sys.stdout.write(\n.join(...))输出格式严格按题面的分隔符拼不要依赖print的默认行为。5.3 性能类样例秒过、大数据超时现象是耗时那一列在小样例上是 0.01 秒换大样例直接跑到 5 秒被掐断。原因有两层算法复杂度选错或者复杂度对了但常数太大。前者看数据范围就能判断n 到 10⁵ 还在写双重循环必然是这个问题后者常见于循环里反复调input()、反复切片、反复list.append之外的重建。解决顺序是先换算法算法对了再抠常数——反过来做常常是白优化。5.4 环境类相对路径与编码不一致现象是脚本在题目目录里能跑换个目录就FileNotFoundError或者中文题面读出来是乱码。原因是代码里用了相对路径工作目录一变就失效编码问题则是文件存的是 GBK 而读的时候按 UTF-8 解。解决办法是把路径统一收敛成基于Path(__file__).parent的绝对路径读文件时显式带encoding读题面时加errorsignore兜底宁可丢几个字符也别让脚本中途崩。5.5 逻辑类边界值一个都没覆盖现象是样例全过只有个别测试点挂而且挂的那几个往往是 n1、全相同元素、空输入这类极端情况。原因很直接——样例通常给的是「正常规模」的数据边界根本没覆盖到。解决方式是写完先自己造三组数据最小规模、全相同、极端大。这三组不用判对错只看程序会不会崩、会不会除零、会不会跑出负数。这套动作我一般固定成习惯比事后 debug 便宜太多了。6. 二次开发把真题包改成自己的刷题流水线题面和源码是静态的但只要你加一点自动化它就能变成一个可复用的训练环境。最划算的三个改造方向按投入产出排序是这样改造方向改动点收益用例驱动测试把judge.py改成 pytest 参数化一题一函数改完代码一键回归不用手动敲命令题库检索index.json落进 SQLite加题号、组别、标签字段按「前缀和」筛选题目专项突破错题沉淀每道题维护一份notes.md记下卡点和最终复杂度复习时不重走老路pytest 这条路最省事把对拍的循环换成参数化即可import subprocess, sys, pytest from pathlib import Path ROOT Path(./第14届-Python省赛真题) CASES [(c, c.with_suffix(.out)) for c in sorted(ROOT.glob(*/数据/*.in))] pytest.mark.parametrize(in_file,out_file, CASES) def test_sample(in_file, out_file): code in_file.parent.parent / 源码 / (in_file.stem.split(_)[0] .py) # 题号前缀可能带后缀找不到就跳过避免整批报错 if not code.exists(): pytest.skip(f未找到 {code.name}) proc subprocess.run([sys.executable, str(code)], stdinin_file.open(rb), capture_outputTrue, timeout10) assert proc.stdout.decode().strip() out_file.read_text(encodingutf-8).strip()跑一次pytest -q几十道题的样例状态一目了然改完参考实现立刻知道有没有把别的地方改坏。这里有个小教训in_file.stem带_1后缀取题号必须split(_)[0]我第一次写的时候忘了切结果全部跳过还以为是 glob 路径写错了查了二十分钟。另一件我现在强制自己做的事是每道题跑通之后立刻在题面同目录写三行笔记用了什么算法、复杂度多少、卡在哪个边界。这套真题包本身没有答案讲解参考源码也不写思路笔记就是唯一的后悔药。等你二刷的时候翻笔记比翻代码快十倍。以上这些跑通之后这份包就不只是「一份真题」了而是你自己的一台小型训练机。希望帮到你。本文还有配套的精品资源点击获取
