“Python作业1”：别急着搜答案，先把这几步想明白再动手

最近总有人私信我，上来就是一句“作业Python作业1怎么写”，截图一甩，就等着手把手喂饭。说实话，教了这么多年的Python入门课，也批过几百份形形色色的“作业1”，我太知道卡住大家的是什么了——不是语法，不是智商，而是看到题目之后，脑子里一片空白，不知道该从哪儿下手。

你可以把“Python作业1”理解成你编程生涯里的第一道正菜。它通常不会上来就让你做网站、做游戏，而是让你用几十行代码，去解决一个生活中的小问题：可能是算一组数据的平均数，可能是把一个文本文件里的内容做清洗和统计，也可能是实现一个小小的猜数字游戏。题目看起来平淡无奇，但背后真正想考察的，是你拆解问题、组织逻辑、规范编码的能力，而不仅仅是“能不能跑出结果”。

这篇文章，我不打算给你某个现成题目的完整答案——那是害你。我想做的，是把“Python作业1”这类任务常见的几种形态、每一步应该怎么思考、有哪些坑是历届学生必踩的，全部拆开揉碎讲一遍。无论你是正在为作业头秃的新手，还是想帮别人看代码的老手，这篇文章都能让你少走几趟弯路。

1. 别一上来就写代码：作业1的核心不是“写”而是“想”

1.1 拿到题目后，前15分钟应该做什么

很多同学拿到Python作业，第一反应是打开编辑器，噼里啪啦开始敲。这是最大的误区。代码越写越乱，bug越改越多，最后连自己都看不懂。

我建议你拿到任何一道编程作业题，前15分钟不要碰键盘。找张纸，拿支笔，先干三件事。

第一件事，把题目用自己的话复述一遍。比如题目说“统计一篇英文文章中每个单词出现的频率”，你就写下来：“读文件→切分单词→统计计数→排序→输出”。如果题目里有一些专业术语，比如“停用词”“正则匹配”，你得能用自己的话解释清楚。解释不清楚，说明你还没理解题目，这时候去写代码就是无头苍蝇。

第二件事，把所有输入和输出情况列出来。输入是文本文件还是命令行参数？输出是打印到屏幕还是写成另一个文件？有没有特殊情况的处理，比如文件为空怎么办、单词里有标点怎么办。把你能想到的所有边界情况写下来，后面写代码时挨个对照，这就是你的测试用例清单。

第三件事，想清楚程序的结构。不需要具体到每一行，而是想清楚“我大概需要几个功能模块”。比如这个作业可能需要：“读取文件”做成一件事，“清洗和切分文本”做成一件事，“统计计数”做成一件事，“排序输出”做成一件事。每个功能写成独立的函数，这就是你作业的主要结构。

这三件事做完，你对题目的理解就深了一层。我见过太多人，代码写了一半才发现题目理解错了，推倒重来。花15分钟做规划，看起来慢，其实是最快的捷径。

1.2 把变量和函数当成“名词和动词”

有个特别形象的类比，我觉得对新手极其有用。你写Python代码，本质上是在用代码讲一个故事。故事里的角色是数据，故事里的动作是函数。

比如说，你要做一个“学生成绩管理系统”的作业。数据就是学生名单、每科成绩，这些就是你故事里的“名词”。操作是什么？读取成绩、计算平均分、按分数排序、输出不及格名单，这些动作就是“动词”。

很多新手写代码最头疼的是“我不知道下一步该干什么”。这时候你就想：如果这个故事用自然语言讲，讲到哪儿了？下一步该做什么动作？把这个动作写成一个函数，然后想想它需要什么数据、返回什么数据。这样写出来的代码，别人读得懂，你自己过两周再回头看也立刻明白。

而且这个“名词”和“动词”的思路，天然对应着Python里的数据结构选择和函数设计。你想统计成绩，是不是得用字典——学生姓名是键，成绩列表是值。你想去重一堆关键词，是不是得用集合。你还没开始写代码，但你的数据结构已经定下来了，这就是老手和新手的差距。

1.3 为什么说可读性比你想象的重要

作业1一般不会写得像爬虫框架那么复杂，但正因为短小，很多同学养成了随手乱写的习惯。变量的名字叫a、b、c，整个程序没有空行也没有注释。你自己调试的时候觉得没问题，等老师一运行，换了几条测试数据，程序崩了。你回来看自己的代码，那真是看天书。

我给学生的硬性要求有三条。第一，所有变量和函数的名字必须能“望文生义”。temp、data1这种东西绝对不允许，至少要用total_score、read_file、calculate_average这类能看懂的名字。第二，每个函数要有Docstring，哪怕就一句话，说明这个函数是干什么的、参数是什么、返回什么。第三，函数之间用空行分隔，逻辑块之间用注释标出。这三条做下来，你的作业就已经超过了80%的同行。

你要理解，写代码这件事，一半是写给人跑的，另一半是写给下一秒钟的你自己看的。作业1开始就养成好习惯，后面学到面向对象、学到项目开发，会省下大量改代码的时间。

2. 详解作业1最常考的四大核心场景

2.1 数据类型与基础运算：看似简单，丢掉进位就全错了

“Python作业1”最常见的第一类任务，是和基础数据类型打交道的计算题。比如“输入一个三位数，按位逆序输出”“计算一个整数各位数字之和”“判断一年是否为闰年”。这类题看着简单，但就能筛掉一批人，因为大家往往忽略两个东西：类型转换和取整规则。

举个例子，判断闰年的规则是“能被4整除但不能被100整除，或者能被400整除”。不少人能写出来，但真正写代码的时候，没有考虑整除和取余的问题。Python里的整除是//，取余是%，如果你混用了/，用户输入的是9，9 / 2结果是4.5，条件判断就没法成立。

处理用户输入也是一个常见的失分点。你用input()拿到的一定是字符串，要做数字运算必须先转int()或float()。如果你不转，输入“123”，你去取个位的时候就会报TypeError。这种错误特别基础，但我每年都能见到大量作业卡在这里。

还有一个必考的细节是浮点数精度。如果是计算平均分、算圆周率近似值这类涉及小数运算的任务，你要知道0.1 + 0.2在Python里不等于0.3。这不是Python的bug，而是二进制无法精确表示某些十进制小数。如果你要做金额计算，记得用Decimal；如果只是普通计算题，用round()控制输出版的小数位数就够了。

2.2 控制流与循环结构：边界条件是分水岭

循环和分支，几乎是作业1的“必答题”。最常见的题目有“输出斐波那契数列前N项”“求1到100内能被3整除的数之和”“实现一个猜数字游戏”。

我给这些题目归类的时候，发现卡点高度一致，都在循环的边界条件上。

比如说求1到N之间的奇数和，有的同学写着写着就忘记N本身是不是奇数。如果你用range(1, N+1)而不是range(1, N)，就涉及N是否包含在内的问题。这些地方看起来是细节，但恰恰是测试用例最爱攻击的漏洞。

猜数字游戏这道题，要求“用户猜的数比目标小就提示大一点，比目标大就提示小一点”。很多人用while True加break写出来，没问题。但真正优秀一点的写法是，用一个guess_limit变量记录最多能猜的次数，超过就提示失败退出。为什么？因为如果用户无限次瞎猜，程序永远结束不了。控制好次数，才符合实际场景中的约束。

再说一个很多人忽略的考点：for-else和while-else结构。一个经典的例子是“判断一个数是否为素数”。正常思路是循环从2到sqrt(n)，看能不能整除。如果你用for i in range(2, int(n**0.5) + 1):来遍历，当循环结束都没有触发break，就执行else里的代码，认定它是素数。这个else挺多初学者不知道，知道了之后写这类判断就干净利落很多。

2.3 数据结构入门：列表、字典、集合各自的职分

作业1的任务里，经常要求统计、排序、去重、查找，这背后都是数据结构在起作用。

列表（list）是最常用的容器，它保留顺序、允许重复，适合存放一组待处理的数据。比如“输入五个人的成绩，输出最高分和最低分”，你用列表存成绩，然后用max()、min()一行搞定。

字典（dict）是“键值对”结构，它的核心优势是“按键查找的速度极快”。比如统计一个字符串里每个字母出现的次数，你完全可以不用count()方法反复遍历，而是用一个字典记录字母和计数。每次遇到一个字母，要么在字典里新建这个键，要么给这个键加一。这个思路非常常用。

我按自己的习惯给新手几个判断标准：需要记住顺序的，用列表；需要按键查询的，用字典；需要去重或者做集合运算的（交、并、差），用集合；需要按名字存多个固定属性，且属性名确定的时候，用字典或者命名元组。判断清楚再动手，代码会流畅很多。

2.4 文件读写：从“学会”到“会正确关闭”

很多作业1会要求从文件读数据，处理后写回文件。这里最核心的就两件事：路径要写对，文件要正确关闭。

路径问题最常见的情况是，学弟学妹把数据文件和代码放在同一个目录，然后直接写open('data.txt')。在某个特定的IDE环境里也许能跑通，但换到系统不同或者工作目录不同的环境，就找不到文件了。稳健的做法是用pathlib库的Path(__file__).parent来定位当前代码文件的目录，再拼接你的数据文件名。这样无论代码在哪里运行，都不会出现路径错误。

文件关闭是另一道经典失分点。不管代码是不是在执行过程中报错，都应该保证文件被关闭。所以我总是推荐用with语法，也就是with open(..., encoding='utf-8') as f:，这种写法会在代码块结束时自动关闭文件。不要再用f = open(...)然后一路操作到最后才f.close()，一旦中间有异常，文件句柄就泄漏了。

如果你读的是中文文件，编码问题一定不能漏。最简单的做法是打开文件时写上encoding='utf-8'。如果你的数据是GBK编码的，而代码里写的是UTF-8，跑起来就会报UnicodeDecodeError。我见过太多作业把中文读进来之后变成乱码，本质就是编码声明没对上。

3. 实操过程全记录：我拿“文本词频统计”完整走一遍

这一节我选一个非常经典、非常适合做作业1的题目——“英文文本词频统计”，来完整演示拿到题之后的思考过程和落地过程。你写的作业大概率不是这个，但里面的思维路径完全可以复用。

3.1 需求拆解：把一句话变成五步

题目大致是：读取本地的英文文本文件，统计每个单词出现的次数，按频次从高到低排序，输出前10个词及频次。

拿到题之后，我先在纸上把任务拆成五个步骤：

• 读取文件内容；
• 统一成小写，方便统计时忽略大小写差异；
• 按非字母字符拆分单词（注意不要用空格简单split，因为文本里可能有逗号、句号、引号）；
• 统计词频，用字典来存；
• 排序并输出前十个。

到这里，我的代码结构已经清晰了。读文件是一件事，切分清洗是一件事，统计是一件事，输出是一件事。每个功能我可以单独写一个函数，也可以把核心逻辑放在主流程里根据长度来定，但我倾向于单独写拆分和统计这两个函数，这样便于测试。

3.2 代码实现：从朴素到稳妥

我第一次实现的版本大概是这样的逻辑：

from pathlib import Path import re def read_text(file_path): with open(file_path, encoding='utf-8') as f: return f.read() def split_words(text): text = text.lower() return re.findall(r'\b[a-z]+\b', text)

注意split_words这里我用了一个正则表达式，按“单词字符”去切。如果只用split()，你统计到的结果是带着标点的碎片，比如“word,”和“word。”会被当成两个不同的“单词”。正则里的\b[a-z]+\b匹配的是边界清晰的连续字母组合，非常适合这种英文词频统计。

然后是统计部分：

def count_words(words): freq = {} for word in words: freq[word] = freq.get(word, 0) + 1 return freq

这里有个非常典型的Python技巧：dict.get(key, default)，如果键不存在就返回默认值0，这样就不需要每次都判断键在不在。用这一行，替代了一个完整的if-else，代码简洁还不会出错。

排序输出部分是这样：

def top_n(freq, n=10): sorted_items = sorted(freq.items(), key=lambda x: x[1], reverse=True) return sorted_items[:n]

sorted()函数的key参数指定按哪个维度排序。这里x[1]代表字典中的频次，reverse=True就是降序。排完序后取前10条，大功告成。

主流程组合起来：

def main(): file_path = Path(__file__).parent / 'article.txt' text = read_text(file_path) words = split_words(text) freq = count_words(words) result = top_n(freq, 10) for word, count in result: print(f'{word}: {count}') if __name__ == '__main__': main()

3.3 关键细节复盘：最容易被扣分的小地方

上面这段代码跑通只是及格，但有几个细节可以明显拉分。

第一，main()函数里加了一个if __name__ == '__main__':保护。意思就是这个脚本被直接运行时，才执行主流程；如果被别的脚本当作模块导入，就不会莫名其妙地执行。这是Python工程化里特别基础的一个习惯，老师看到会加分。

第二，我用Path(__file__).parent而不是直接写'article.txt'。这样无论你在哪个目录下执行这条程序，都能准确找到和脚本同目录的数据文件，不会因为终端当前路径不同而报找不到文件的错误。

第三，我选择re.findall加\b[a-z]+\b而不是简单地text.split()，这样能避免标点干扰统计。如果你拿一篇比较正式的文章来测试，就会发现“the”和“the,”以前会被统计成两个词，用了正则之后就合并了，词频数据才真正可信。

第四，如果你想统计的是中文文本呢？那正则写法就完全不同了，中文不像英文那样有天然的空格分隔。处理中文更稳妥的方案是用jieba第三方库来分词，或者至少基于标点符号和空格做切分。这一个扩展思路，你面试时提一嘴，会让人意识到你考虑得远比作业要求深入。

3.4 测试用例设计：不抓边界条件的测试等于白测

作业1经常会遇到“对不对”的质疑，最简单的回应是你已经设计过一套测试用例。我当时跑这道题，先特地准备了一个只有一句话的小文件，手写一句英文：“The quick brown fox jumps over the lazy dog. The dog sleeps.”

我期望的结果是：

• 所有单词都转为小写；
• “the”因为出现了两次，排到前面；
• 标点符号不会出现在任何单词中。

然后我再准备一个空文件，看看程序会不会崩溃。空文件读进来是空字符串，re.findall返回空列表，统计出来是个空字典，排序后是空列表，输出循环什么都不打印。全程没有异常，这条测试过了，我心里就踏实了。

接着我再准备一个全是重复单词的文件，比如“a a a a b b c”，预期结果一定是a：4、b：2、c：1。数据和预期一对，如果不对，立刻知道是哪里逻辑错了。

所以你看，一个看起来非常简单的题目，如果你认真设计了边界测试，整个代码的可靠性就会大幅提升。这些测试不算复杂，但正是不做这种测试的人，才会在提交作业之后收到一堆“运行报错”的反馈。

4. 作业验收前必须自查的几件事

4.1 按老师给的样例重新跑一遍

很多课程，作业题目会附带输入输出样例。我建议你在提交前，把样例一个不落地重新运行一遍。注意，是重新运行，不是看一遍代码觉得没问题。你看到我强调“重新”，是因为很多同学改过代码后，样例的输出变了，变了之后他还以为原来是对的。这种事情每年都在发生。

如果你发现和样例不一致，不要急着改代码，先对比差异。常见的情况有三种：一个是输出的格式差异，比如样例要求3.14，你输出了3.140；二是排序顺序差异，比如样例是从高到低，你从低到高；三是单词大小写差异，样例全小写，你把首字母大写保留了下来。这些差异在评分时非常拉分，但改起来就是一行代码的事，损失太不值得。

给自己一个检查习惯：提交之前先跑一遍跑得通的样例，再想一下有没有哪个样例是围绕边界条件设计的，比如空输入、极大数值。有了这些保险，心里才踏实。

4.2 给代码“瘦身”和“增肥”

作业不是越短越好，但同样的逻辑，如果你写了太多冗余的步骤，就要考虑是否可以精简。比如一个流程里反复用同一个中间变量，那就是没有组织好；还有一些同学写代码时喜欢把所有内容堆在print()里，连乘法都变成几行加法，这就是过度冗长。

反过来，有些代码又瘦得过分。一行代码里堆了三四层函数调用，比如print(sorted({...}.items())[:10])，虽然能跑，可读性极差。我建议在关键步骤用中间变量拆开，命名清楚。把自己带入老师的角色，如果老师的批注是“这行写的什么玩意儿，可读性极差”，你的分数就悬了。

4.3 注释要不要写？怎么才不算画蛇添足？

我的建议是，作业1阶段每三到五行代码写一行注释，注释解释“这段代码的意图是什么”，而不是解释语法。比如：

# 统计每个字母出现的次数 for ch in text: freq[ch] = freq.get(ch, 0) + 1

这行注释的重点是“统计频率”，不是“遍历字符串的每个字符”。如果你写# 用循环遍历text里的每个字符，这跟没写一样，是在描述代码本身，而不是描述意图。好的注释能让老师一眼看出你完全理解自己的代码。

有一种情况千万别写注释，就是你自己还没想清楚为什么这么写，就用注释把代码“解释得合理”。这种注释极其危险，它不仅误导别人，而且会掩盖你自己思路上的漏洞。宁可让代码看起来路子清奇，也别用注释包装成“堂堂正正”，因为作业的核心是思路，不是注释的数量。

5. 报错排查实录：这5个错误我几乎每年都能见到

说真的，改作业里的错误报错，比改作业本身还累。我整理出几个“Python作业1”里出现频率极高的报错，给出报错原因和解决思路，你可以对照自查。

IndentationError这种问题特别有意思，很多同学在记事本里写代码，把空格和Tab混着用，当时看着没问题，执行时就崩了。你用任何现代编辑器，都应该开启“显示空格”选项，一眼就能看出缩进问题。

还有一个特别容易忽略的：NameError，比如你定义了一个player_score，后面用到的时候写成了player_scores，Python就会报这个名字没定义。这类错误是最气人的，因为代码逻辑完全没问题，就是一个拼写粗心。解决办法没有捷径，只能运行报错后回到报错的代码行仔细看变量名。

我还见过一种情况，是IndexError: list index out of range。多半是因为你用while循环访问一个长度变化中的列表，或者用固定的下标访问一个比预期短得多的列表。解决办法是，访问列表前先打印一下len()确认长度，或者在遍历时用for而非while。

这些报错看起来啰嗦，但只要你见过一次，后面就会形成肌肉记忆。不要怕写错，写错之后认认真真读懂报错信息，其实是最快的进步方式。

6. 我对“作业1”真正意图的一些体会

做了这么多年的技术工作和带人，我越来越觉得，第一道Python作业的实际意义，远远不是“确认你会写代码”。

作业1的第一层用意，是逼你从“看视频觉得简单”过渡到“动手才见真章”。视频里老师写得行云流水，你眼睛会了，手完全不会。作业就是把那个“貌似懂了”的幻象戳破的利器。

第二层用意，是培养你面对报错时的耐心。很多人第一次遇到SyntaxError就慌了，这很正常。但编程本身就是不断试错的过程。你面对报错时的第一反应，应该是“它提示我哪一行有问题，问题大概是什么”。学会读懂报错，比学会某个具体的语法早练灾要重要得多。

第三层用意，是从一开始就逼你养成工程习惯。变量命名、函数拆分、注释、边界测试、文件路径处理，这些东西看起来在作业1里是“小题大做”，但它们正是后面真正做项目时，能让你少熬几个通宵的核心能力。

我知道很多同学只想要一个能跑的答案，但我还是想说一句：如果你能把“Python作业1”当成一个工程来对待——先拆需求，再设计结构，然后动手实现，最后设计测试——那么你收获的绝不仅仅是一份作业的分数，而是一套可以迁移到任何编程任务上的方法论。

根据我个人的体会，那些从第一道作业就认真做规划、认真写注释、认真测边界条件的人，后面学面向对象、学Web开发、学数据处理，速度远比同批同学快。原因特别简单：他们的代码一直处于“可读、可改、可持续”的状态。而所谓的高手，不过是把这种状态保持了很多年。

所以这一章的内容很简单，别把“Python作业1”看成一个负担。它只是一块敲门砖——而且是一块非常关键的敲门砖。认真对待它，多踩几个坑、多琢磨几次为什么，你会感谢现在这个“想得更慢、但走得更稳”的自己。