分阶段编程作业：从需求拆解到自动验收的最小闭环实践)
简介：《指令系统实现详解》是一份面向计算机专业学生的实验参考资料，聚焦指令系统取指、译码、执行三阶段，适合正在学习计算机组成原理、体系结构或准备相关实验的读者。资料以PDF收录了完整的实验实现过程，既说明指令集设计特点、寄存器结构与更新方式，也拆解框架代码中函数组织、全局变量使用、译码模板选择等关键环节，并通过ADD/SUB、MOV/NOP、压栈与跳转、有符号扩展、标志位更新、打印变量与栈帧等具体指令实例，展示处理指令细节的实用方法。压缩包内共一个文件，文件类型为PDF，整体大小为1.46MB，内容集中精炼，便于按需阅读和对照实现。目前已有1044人学习，适合在动手实现指令系统前通读，遇到相关框架理解困难时也可快速查阅；整体结构清晰，按模块查阅也较为方便。
1. PA2(上) 这个任务真正要的不是“完成一半”，而是面向自动验收的最小闭环
收到PA2(上)_173071301781这样的任务编号时，先别急着打开编辑器从第一行写到能覆盖所有功能。带“（上）”的提交多半属于分阶段交付：第一阶段先让基础路径跑通，第二阶段再挂高级特性。我以前带项目时见过不少同学把“（上）”理解成“整道题的 50%”，结果提前做了下半阶段才需要的功能，基础命令反而在自动评测机上没过。PA2 通常是课程或工程里的第二次编程作业，末尾那一长串数字一般是提交流水号，归档、回滚都要靠它定位，不要为了整洁去改它。适合读这篇的人：在自动评测平台上做分阶段提交的、第一次拆两阶段项目的新手、以及不想为环境问题反复返工的开发者。下面按我处理这类任务时的习惯顺序来：先翻译需求，再搭基线，然后实现最小闭环，最后排坑和自检。
2. 把 PA2(上) 翻译成模块清单：四步拆解与三个边界问题
2.1 先读PA2(上)_173071301781，任务编号里有三个信息
第一步不是写代码，而是把任务代号拆开看。PA2一般指第二次编程作业；2说明你面对的是第二阶段，但（上）又说明这个阶段被进一步切成了两半。173071301781前面的部分是时间戳或批次号，后面几位可能是学号或随机序号，我一般直接把它当作整个任务的主键：本地目录、提交文件名、Git tag 全都用这个串对齐。
读任务书的时候，我会先用半小时把输入、处理、输出三件事抄到一页纸上。比如 PA2(上) 如果是一个命令行键值存储，那输入就是标准输入里的文本行，处理是解析命令并维护一个字典，输出是标准输出里的结果。这三个框一旦定下来，自动评测机的行为就能猜个八九不离十：它大概率会往 stdin 里灌一批文本，捕获 stdout 后和期望文件做 diff。这也解释了为什么很多人在本地用 IDE 手动敲命令一切正常，一上评分机就 0 分——因为评测机只认重定向后的输出，不认你屏幕上那些提示信息。
拆完三件事，剩下四步是固定的：列出所有命令、为每条命令写一个输入样例、为每个样例写期望输出、把期望输出汇总成一份验收表。做完这四步，你才算真正知道“PA2(上) 要交付什么”。
2.2 用可验收样例表拆模块，而不是按题目小题拆
很多人习惯按题目章节去拆“第一部分做什么、第二部分做什么”，但评测机可不管章节，它只按测试点给分。我更习惯先做一张验收表，每一行都对应一个可以被自动判定的行为。下面这张表是我处理命令行程式 PA2(上) 时的模板：
| 功能模块 | 输入样例 | 期望输出 | 本期是否必须 | 备注 |
|---|---|---|---|---|
| 命令解析 | set\tname\tzhang | 能识别命令名 | 必须 | 分隔符严格用 Tab |
| set 主链 | set\tname\tzhang | OK | 必须 | 成功后状态被更新 |
| get 主链 | 先 set 再 get | 返回zhang | 必须 | 区分“空值”和“无 key” |
| del 主链 | 先 set 再 del | OK | 必须 | 重复 del 要报错 |
| 不存在 key | get\tmissing | ERR no such key | 必须 | 错误文案按任务书统一 |
| 空 value | set\tname\t | OK，get 返回空行 | 必须 | 空行容易在 diff 时被忽略 |
| 大 value | 1MB 左右字符串 | 原样返回 | 视题目而定 | 评测可能压到 256KB |
| 持久化 | 重启进程再 get | 不要求 | 下期再做 | 提前做会引入状态问题 |
这张表的最大价值不是好看，而是每行都能直接变成一条测试命令。比如空 value 那一行，很多人写着写着就忘了，最后评分机给了一个“set 空字符串后 get 应输出空行”的测试点，本地因为用了print(repr(...))带出了引号，直接翻车。验收表里列出的每个“必须”项，都要能在本地用一行命令复现。
把模块拆成这种粒度之后，你会自然发现哪些是“上半部分”的边界：比如持久化、并发、容量淘汰这类功能，如果拿不准，就先在表里标成“下期再做”。这不是偷懒，而是避免让当前阶段的状态机被额外功能污染。
2.3 三个必须在动工前问清楚的边界问题
第一，评测机是黑盒还是白盒。黑盒意味着它只关心 stdin/stdout，你的代码里哪怕有十个内部函数都不影响；白盒则可能会 import 你的模块，检查某些函数名或内部状态。没有头绪时，按黑盒准备最稳妥：所有调试信息只往 stderr 写，stdout 严格只输出题目要求的内容。
第二，每次运行是不是无状态。PA2(上) 最常见的评测方式是“启动进程、灌输入、关闭进程”，每次启动都是全新状态。如果题目没提持久化，那你就不该在退出时偷偷写文件。常见翻车案例是：有人提前做了“重启后数据还在”，结果评测机跑完一次后磁盘状态没清理，下一轮的set name old被旧值干扰。
第三，错误输出到底长什么样。get一个不存在的 key，是要输出ERR，还是空行，还是NULL？这决定了你输出层的每一行。我的习惯是找任务书里的“示例输出片段”，没有的话就做两个版本：本地先用ERR，提交前再根据平台反馈快速换一个版本。把这类“不确定项”写进 README，比用脑袋记可靠。
3. 先用最小命令搭一个不会让 PA2(上) 翻车的工程基线
3.1 从零到能跑的最小仓库布局
拿到PA2(上)_173071301781后，我做的第一件事不是写实现，而是把目录结构搭好。一个能扛住自动评测的仓库，至少要包含源码、测试样例、构建脚本和一份说明文件。下面这个布局很朴素，但足够应付大多数命令行型 PA2：
pa2_upper_173071301781/ ├── kv_store.py ├── test_kv.py ├── Makefile ├── README.md └── samples/ ├── base_in.txt └── base_out.txtkv_store.py是主程序，从 stdin 读、往 stdout 写；test_kv.py存放 assert 形式的单元测试；Makefile 把构建和自测绑成一个命令；samples目录放一组“输入→期望输出”对，方便任何时候做 diff。为什么非要放一对样例文件？因为自动评测机最常做的事情就是“拿你的输出和期望输出 diff”，本地没有这一对文件，你就永远是在盲测。
这段布局的取舍是：不要在这时候引入依赖管理、虚拟环境或者重量级框架。PA2(上) 通常要求一个进程跑完一个固定输入，依赖越少，环境越不容易出问题。如果你用 Python，标准库就够了；如果题目要求 C/C++，那 Makefile 负责编译，主程序同样只从 stdin 读写。
3.2 用 Makefile 把构建、自测、样例比对绑成一个命令
“顺手make test能跑”这个习惯，能帮你避免提交前才手忙脚乱找命令。下面这份 Makefile 是我常用的模板：
.PHONY: all run test clean SRC := kv_store.py IN := samples/base_in.txt EXP := samples/base_out.txt OUT := /tmp/pa2_upper_out.txt all: python3 -m py_compile $(SRC) run: python3 $(SRC) < $(IN) test: python3 $(SRC) < $(IN) > $(OUT) diff -u $(EXP) $(OUT) && echo "PA2(上) base sample OK" clean: rm -f $(OUT) rm -rf __pycache__这里有几个参数需要解释。IN和EXP是我本地固定的样例路径，评测机不需要知道它们，我只在本地用。diff -u输出统一格式的差异，能让多出来的空格和空行一目了然；如果 diff 什么也不输出并打印 OK，说明当前实现和期望完全一致。最关键的是make test里那行重定向：它让程序真正走“从文件读入、向文件输出”的路径，而不是人在终端里手动敲，这和你提交后评测机的运行方式最接近。
Makefile 有一个非常经典的坑：recipe 行前面必须是真正的 Tab 字符，不能用空格代替。如果复制粘贴后报missing separator，第一件事就是把python3那几行的缩进换成 Tab。
3.3 统一 stdin/stdout 行协议：分隔符、换行和返回码
在写任何业务逻辑之前，先确定 stdout 上每一行的样子。我的默认选择是：命令名、key、value 之间用 Tab 分隔，每一行以\n结尾。用 Tab 而不是空格，是因为 value 里很可能带空格；用换行而不是自定义分隔符，是因为评测机通常就是把每一行当一个测试点。
一旦定下来，就用一行命令先验证协议能通：
printf 'set\tname\tzhang\nget\tname\n' | python3 kv_store.py如果程序还没写，这条命令会报找不到kv_store.py，这是好事——你已经把“输入长什么样”固定下来了。我把协议写进 README 的第一段，内容大概是：
- 每行一条命令，命令与 key、value 之间用
\t分隔； - 命令名：
set、get、del、quit； - 成功输出：普通文本；失败输出：
ERR <原因>； - 进程不要求持久化，每次启动内存状态清空。
为什么要白纸黑字写下来？因为等到下半阶段做持久化时，你需要知道上半阶段哪条命令的输出格式不能改。demo 里的quit命令如果没有在任务书里出现，就不要实现；即使实现，也不要多做“保存文件”之类的动作。
4. 从验收样例反推 PA2(上) 的最小实现：核心循环与边界处理
4.1 一个 100 行以内能跑通的 Python 最小实现
有了样例和协议，实现其实是被“推”着走的。下面这个版本对应前文那张验收表，只做set、get、del和quit，不碰持久化：
#!/usr/bin/env python3 """PA2(上) minimal kv store: set/get/del over stdin/stdout.""" import sys from collections import OrderedDict store = OrderedDict() def parse_line(line): # 同时处理 \n 和 \r\n；split 的 maxsplit=2 让 value 里可以保留 Tab line = line.rstrip("\r\n") if not line: return [] return line.split("\t", 2) def cmd_set(parts): if len(parts) < 3: return "ERR missing value" key, value = parts[1], parts[2] store[key] = value return "OK" def cmd_get(parts): if len(parts) < 2: return "ERR missing key" key = parts[1] if key not in store: return "ERR no such key" return store[key] def cmd_del(parts): if len(parts) < 2: return "ERR missing key" key = parts[1] if key not in store: return "ERR no such key" del store[key] return "OK" def main(): for line in sys.stdin: parts = parse_line(line) if not parts: continue cmd = parts[0] if cmd == "set": print(cmd_set(parts)) elif cmd == "get": print(cmd_get(parts)) elif cmd == "del": print(cmd_del(parts)) elif cmd == "quit": break else: print(f"ERR unknown cmd {cmd}") if __name__ == "__main__": main()逻辑看起来直白，但有两个参数值得停一下。第一个是split("\t", 2)里的2：它表示最多拆成三段，这样set key a\tb时，value 会被完整保留成a\tb，而不会被误拆成多段。第二个是OrderedDict：Python 3.7 以后普通 dict 也保留插入顺序，这里用OrderedDict纯粹是给下半阶段留位置——如果下一期要做 LRU 淘汰，move_to_end可以直接用。
这里没有用try/except包住整个循环，而是让每条命令各自返回错误字符串。这么设计是为了让 stdout 的每一行都必须是“一行输出”，异常堆栈只会出现在 stderr 里，不会污染评测结果。
4.2 和验收机对齐的参数：超时、内存、退出码
写实现的同时，要把评测机的运行参数也跑一遍。下面这张表是我在本地验证时固定会过一遍的参数：
| 参数 | 本地自测方式 | 建议值 |
|---|---|---|
| 超时 | timeout 2 python3 kv_store.py < samples/base_in.txt | 2 秒足够 |
| 内存 | ulimit -v 262144后再跑 | 256MB |
| 退出码 | echo $? | 正常结束应为 0 |
| stdout 编码 | 用LC_ALL=C.UTF-8跑 | 避免 ASCII 环境报 Unicode 错误 |
为什么要专门测超时？因为自动评测机对单个用例有严格时间上限，如果任务书要求处理大 value，而你用sys.stdin.read()一次性读入，内存和时间都可能爆掉。这里用逐行迭代，就是为了一次只处理一行。内存限制更隐蔽：Python 解释器自身占内存，如果评测机只有 128MB，你最好不要额外引入第三方库。
退出码这点，很多新手会忽略。虽然评测机主要看 stdout，但它也会检查进程是否正常退出。如果你在KeyboardInterrupt场景下直接崩了，退出码非 0，有些平台会把整个提交标记为超时或异常。所以主流程里quit命令用break而不是sys.exit(0)，保证循环退出后解释器自然收尾。
4.3 边界处理：空 key、空 value 和 \r\n 换行
PA2(上) 里最容易丢分的不是主流程，而是边界。比如空 value：set\tname\t这一行的第三段是空字符串，程序应该输出 OK，之后get name应该输出一个空行。这个空行在 diff 时看起来像“少了一行”，所以很多人会误删。
再比如 Windows 环境生成的输入文件，每行结尾是\r\n。如果代码只做rstrip("\n")，key 会变成name\r，明明 set 过却 get 不到。所以parse_line里统一用rstrip("\r\n")，这一步是血泪经验，几乎所有候选代码里都会有那么一次翻车。
为了把这些边界固化下来，我一共会跑这几条命令：
printf 'set\tname\t\nget\tname\ndel\tname\nget\tname\n' | python3 kv_store.py printf 'set\tname\tzhang\r\nget\tname\r\n' | python3 kv_store.py printf '\n\nset\tkey\tvalue\n' | python3 kv_store.py第一条验证空 value 和重复 del；第二条验证\r\n；第三条验证空行不会干扰状态。每条命令的输出要逐个核对，不能只看“没报异常”就放过。
5. PA2(上) 容易翻车的五个坑：现象、原因、解决
5.1 本地跑得好好的，评分机 0 分
现象：本地make test全绿，提交到平台后一分没有。原因：最常见的是本地把调试信息打到了 stdout。比如代码里有一行print("debug: ...")，终端里看不出问题，但评测机的 diff 会把每个多余字符都算差异。还有一种情况是本地读的是文件，评测机读的是 stdin，代码路径根本对不上。解决：从第一步开始强制所有调试信息走sys.stderr，提交前再跑一次python3 kv_store.py < samples/base_in.txt > /tmp/out.txt，然后cat /tmp/out.txt，确认里面没有一行多余内容。
5.2 路径硬编码，换目录立刻找不到文件
现象：本地运行没问题，把整个目录打包交上去后，代码报“FileNotFoundError: samples/xxx”。原因：代码里写的是相对路径，而你的工作目录和评测机的工作目录不一样。解决：这个方案里主程序刻意不碰任何外部文件，全部从 stdin 读，从根上避开路径问题。如果题目指定要读配置文件，那就用Path(__file__).parent去定位配置文件，而不是依赖进程的当前工作目录。Makefile 里的路径也是同理，所有样例路径相对项目根目录写，不要用~/或绝对路径。
5.3 空 key、空行和末尾换行处理不一致
现象：set\t\tvalue这种空 key 输入，代码直接把空字符串当作 key 存了进去；或者输入文件最后一行没有换行，解析就漏了一条。原因：解析逻辑对“空字符串”和“行不存在”没有区分。解决：parse_line先做rstrip，然后if not line: return []，把空行过滤掉。空 key 是否允许，要按任务书定；如果没提，我的默认选择是把key == ""当作合法但不可读，至少不会让进程崩溃。关键是get空 key 时要输出固定错误，而不是抛出 KeyError。
5.4 提前实现下阶段功能，破坏了当前状态机
现象：P 同学想一步到位，在quit里加了“把内存写入磁盘”，结果评测机跑完一轮后，下一轮启动时读到了上一轮的残留数据。原因：PA2(上) 的评测假设是无状态进程，每轮从空字典开始。你提前加的持久化让状态被外部文件污染，反而导致set之后get拿到旧值。解决：严格按验收表来，凡是标了“下周再做”的功能一律不写。可以用 Git tag 把上半部分固下来，之后想实验新思路就开新分支，别在主提交里夹带私货。
5.5 编号和版本没对齐，提交覆盖了旧结果
现象：本地目录叫PA2(上)_20241026_final，平台任务编号是PA2(上)_173071301781，提交时上传错文件，导致旧成绩被覆盖。原因：把“看起来像最终版”的名字当成了正式编号。解决：整个项目从第一天起就用任务编号命名目录，Git tag 也带完整编号，比如PA2_upper_173071301781_v1。每次提交前检查提交文件名和任务编号是否完全一致，包括下划线和括号。这个习惯能避免最被动的翻车——不是代码不对，而是交错了地方。
6. 提交 PA2(上) 前用一份检查脚本收尾，顺便给下半部分留好扩展位
我的最后一个习惯是把检查过程写成脚本，而不是靠记忆。PA2(上)_173071301781这种提交往往只有一次机会，与其在网页上反复试错，不如在本地把能暴露的问题全部暴露一遍。
下面是我提交前会用的check.sh，只做三件事：清理、跑测试、手动打一组边界输入：
#!/usr/bin/env bash set -euo pipefail make clean make test printf 'set\tname\t\nget\tname\t\ndel\tname\nget\tname\n' | python3 kv_store.pyset -euo pipefail表示任何一步失败都立刻停下，避免在错误状态下继续执行。这里唯一需要你手动确认的是最后一条printf的输出：空 value 的 get 结果应该是一个空行，如果它打印了别的字符，说明输出层还有问题。脚本跑完、输出确认之后，我会顺手打一个 Git tag，比如PA2_upper_173071301781_v1，这就是提交前的“后悔药”；万一平台反馈异常，还能回到这个版本重新查。
至于下半阶段，我不打算在 PA2(上) 里写任何半成品逻辑，但会把扩展位留好：主程序里用OrderedDict保留操作顺序，README 里记清楚“下半阶段计划做容量淘汰和持久化”，代码里不注释掉任何“将来可能用到”的东西，只标注# TODO(PA2 下):。这样等真正做下半部分时，只需要在原有命令上增加分支，而不是重写整个解析器。
我自己的习惯是每次提交都保留一份带完整流水号的输出日志，下次再拿类似PA2(上)_xxx的任务，先翻旧日志看当时哪些边界没测，比重新读一遍任务书快得多。希望帮到你。
本文还有配套的精品资源，点击获取
