从重复函数到跨环境运行Python状态统计器的第一次工程迭代专栏从Python基础到大模型应用与Agent开发 · 01阶段学习Day 1Day 2核心成果重构通用状态统计函数并在Windows与Kali WSL中得到一致结果数据说明本文只使用自建脱敏数据不包含真实业务、数据集或漏洞信息。1. 背景与问题我此前已经学习过Python基础、算法和数据结构因此本文不再逐项讲解列表、字典、for循环和if语句而是记录这些基础知识如何组合起来解决一个具体问题。我正在构建一个简化的任务结果统计器。第一阶段目标不是直接调用大模型而是先建立一条可靠的数据处理链路脱敏任务数据 → Python状态统计 → 真实错误定位 → Windows与WSL交叉验证 → 为后续模型结构化输出定义输入、输出边界本文中的Python代码和命令均已实际运行Token、Prompt和Temperature部分是为下一阶段模型API调用做的概念与接口设计尚不代表已经完成真实模型调用。1.1 运行环境与验收边界项目本文环境或状态Windows Python3.10.11已运行统计脚本WSLWSL 2默认发行版为Kali LinuxWSL Python3.13.12已运行同一脚本示例数据3条自建脱敏任务已验证通用计数函数、真实错误修复、路径映射、跨环境运行尚未实现JSON文件落盘、真实模型API调用、RAG与Agent1.2 需要统计的数据假设有一组脱敏任务结果results [ {task_id: 1, status: success}, {task_id: 2, status: failed}, {task_id: 3, status: failed}, ]最初我分别写了count_success()和count_failed()两个函数success_total count_success(results) failed_total count_failed(results)两个函数内部都需要从0开始计数遍历任务列表读取每条任务的status状态符合要求时将计数加1返回最终数量。两个函数唯一变化的部分只是目标状态分别为success和failed。如果为每一种状态都写一个函数就会产生重复代码。因此可以把“目标状态”提取成参数。2. 用参数消除重复逻辑2.1 重构后的完整代码def count_by_status(results, target_status): count 0 for result in results: if result[status] target_status: count count 1 return count results [ {task_id: 1, status: success}, {task_id: 2, status: failed}, {task_id: 3, status: failed}, ] success_total count_by_status(results, success) failed_total count_by_status(results, failed) print(f成功任务数{success_total}) print(f失败任务数{failed_total})运行结果成功任务数1 失败任务数2这里的两个参数分别表示results本次需要检查的整批任务数据target_status本次需要统计的目标状态。第一次调用时count_by_status(results, success)函数本次执行过程可以理解为target_status success因此统计成功任务。第二次调用时count_by_status(results, failed)此时target_status failed同一个函数便开始统计失败任务。我由此理解了通用函数的核心保留相同的处理流程把会变化的内容设计成参数。2.2 真实错误一把变量写成字符串我曾经写出下面的判断if result[status] target_status:运行结果是成功任务数0 失败任务数0问题在于target_status表示读取变量中保存的值target_status表示一段固定的字符串。加上引号以后程序寻找的是状态真的等于文字target_status的任务。数据中没有这种状态所以两次统计结果都是0。正确写法是if result[status] target_status:2.3 真实错误二参数拼错却仍然能运行我还曾把参数写成def count_by_status(resullts, target_status):但循环里使用的却是for result in results:程序当时仍然能够运行是因为函数外面恰好存在一个名为results的全局变量。这会掩盖参数拼写错误使函数没有真正使用收到的第一个参数。这个错误让我意识到程序“能够运行”不等于实现一定正确。除了观察输出还要检查函数是否真正使用了参数以及换一批数据后是否仍然有效。2.4 这一轮重构真正验证了什么这次重构展示的并不是“会写一个计数器”而是三个更通用的工程习惯发现重复逻辑后把变化项提取成参数根据真实输出定位问题而不是看到程序能运行就停止检查修复后重新执行用结果确认行为没有被破坏。当前函数还存在进一步改进空间例如未知状态校验、输入为空时的处理以及自动化测试这些会在后续迭代中补充。3. 为模型调用补齐输入边界Token与上下文本节不是独立的大模型原理教程而是回答一个与统计器后续升级直接相关的问题当任务数据和指令发送给模型时模型实际接收和生成的是什么3.1 Token不是算力我之前误以为Token代表模型消耗的算力。学习后我对它有了更准确的理解Token是模型处理文本时使用的基本单位之一而不是算力本身。文本进入模型前大致会经过下面的过程原始文本 → Tokenizer分词器 → Token → Token ID → 模型计算 → 预测下一个Token → 转回文本不同模型使用的分词器、词表和切分规则可能不同所以同一句话在不同模型中不一定具有相同的Token数量。3.2 模型逐步预测下一个Token大模型通常不是一次性生成完整回答而是重复预测下一个Token输入 → 预测第1个Token 输入第1个Token → 预测第2个Token 输入前两个Token → 继续预测这种生成方式也解释了为什么Temperature会影响输出的随机性以及为什么生成内容越长所需时间和Token消耗通常越多。3.3 上下文窗口会限制任务数据规模上下文窗口可以理解为模型一次能够处理的Token容量通常需要同时容纳系统指令用户输入历史对话模型生成内容例如一个模型的上下文上限是100个Token系统指令10个Token 历史对话40个Token 本次问题30个Token 合计已用80个Token理论上只剩20个Token空间。如果还要求模型生成30个Token总量就会超过上限。因此当任务数据量增大时不能把所有历史记录不加处理地塞给模型。应用可能需要截断、分批、检索或总结较早的内容。被移出上下文的细节模型无法直接看到这可能造成统计遗漏或回答错误。这一点会直接影响后续RAG和Agent设计哪些数据进入上下文、哪些数据保存在外部系统、每次取回多少内容都需要明确策略。4. 同一脚本的跨环境验证从Windows到WSL4.1 检查并进入WSL我在Windows CMD中检查WSLwsl --status检查结果表明电脑已经安装WSL 2默认Linux发行版为Kali Linux。因此当前阶段不需要重复安装Linux环境。从Windows项目目录进入WSLwslWindows路径D:\LLM-Agent-Study进入WSL后对应/mnt/d/LLM-Agent-Study也就是说WSL通过/mnt/盘符的形式访问Windows磁盘。4.2 用Shell确认项目位置我没有单独背诵命令而是用它们完成项目定位命令在本次验证中的作用pwd确认当前是否位于/mnt/d/LLM-Agent-Studyls确认WSL能看到三个Python文件cd ..进入当前目录的上一级cd /mnt/d/LLM-Agent-Study使用绝对路径直接返回项目学习过程中我误执行了cd随后又执行cd ..从项目目录进入了/home。这并不会删除文件只是改变当前目录。最后使用项目的绝对路径恢复cd /mnt/d/LLM-Agent-Study这个真实失误没有修改或删除任何文件但暴露了我对cd默认行为不熟悉。修复策略可以总结为不确定自己在哪里时先运行pwd需要快速恢复时使用经过确认的绝对路径。4.3 区分Windows与WSL的Python环境我的Windows CMD中使用python --version版本为Python 3.10.11。Kali WSL中使用python3 --version版本为Python 3.13.12。二者可以访问D盘中的同一个Python文件但属于不同运行环境。在一个环境中安装的第三方包不一定能直接被另一个环境使用。我最终在WSL中运行同一个统计脚本python3 eval_result_analyzer.py输出仍然是成功任务数1 失败任务数2至此我完成了“Windows中保存代码—WSL访问同一文件—Linux Python执行”的完整流程。两边输出一致说明当前这段纯Python逻辑没有因运行环境变化而改变。但这不代表所有项目都能直接跨环境运行。以后加入第三方库后Windows和WSL需要分别管理依赖文件权限、换行符和路径写法也可能产生新问题。5. 把统计任务写成模型输入、输出契约这一部分完成的是接口设计练习并未实际请求模型API。目标是先明确如果后续让模型参与分析应该给它哪些信息又应该如何检查返回结果。5.1 Prompt不只是一句话Prompt可以包含模型完成任务所需的指令、背景、数据和输出要求。一个结构清楚的任务Prompt可以包含角色模型以什么身份工作 任务具体需要完成什么 数据模型依据哪些内容处理 输出要求结果采用什么格式例如角色你是严谨的数据评测助手。 任务统计成功和失败任务数量。 数据 [ {task_id: 1, status: success}, {task_id: 2, status: failed}, {task_id: 3, status: failed} ] 输出要求只能依据给出的数据回答不得编造返回JSON包含success_count和failed_count。根据当前数据期望返回{ success_count: 1, failed_count: 2 }这里的JSON是根据数据人工核验得到的期望结果不是一次真实模型响应。后续接入API后它可以作为最小测试用例用于检查模型是否遵守字段和数量要求。5.2 system、user和assistant聊天模型常按消息角色组织输入system规定模型的身份、工作规则和回答边界user提出本次具体问题或任务assistant模型生成的回答后续也可能作为历史对话再次传入。可以简单理解为system → 工作说明书 user → 本次工单 assistant → 模型处理结果5.3 Temperature影响随机性不保证正确性Temperature主要影响模型选择下一个Token时的随机性而不是让模型变得更聪明或更“活跃”。较低Temperature输出通常更稳定、集中、一致较高Temperature输出通常更多样、更有随机性。在数据评测项目中统计数量、提取字段、固定JSON输出 → 需要稳定适合较低Temperature 头脑风暴名称、生成不同创意方案 → 需要多样性可以使用较高Temperature需要注意降低Temperature并不能给模型增加知识也不能保证彻底消除幻觉。即使Temperature很低程序仍然需要检查JSON能否解析、字段是否齐全以及数量是否与原始数据一致。6. 这次迭代形成的能力证据相比“学习了哪些语法”下面这些经过验证的证据更有意义能力方向本文证据当前边界Python编码用列表、字典、循环、条件、参数和返回值完成通用计数尚未加入类型标注和异常处理调试定位变量/字符串混淆与参数拼写问题并重新运行验证尚未编写自动化测试Linux工程基础在WSL中定位D盘项目、处理目录错误并运行脚本只掌握基础Shell命令大模型原理能解释Token、逐Token生成和上下文容量尚未进行Tokenizer代码实验Prompt设计能定义角色、任务、真实数据和JSON输出要求尚未实际调用模型API这些成果对应大模型应用开发岗位中的基础编码、调试、Linux环境和模型接口理解但距离可交付项目仍有明显差距因此不能把当前脚本描述为完整评测系统或Agent。7. 下一步让结果真正结构化落盘下一次迭代将完成现有统计结果 → 构造Python字典 → 写入summary.json → 使用Shell检查文件 → 处理文件和数据异常完成JSON读写和测试后再接入真实模型API。这样能先保证确定性的本地处理可靠再逐步引入具有随机性的模型输出。8. 复盘我会继续使用的学习闭环对初学者来说“看懂”与“能独立实现”之间还有很长距离。相比连续观看大量课程我目前更适合围绕一个小项目循环完成理解需求 → 自己编写 → 实际运行 → 根据报错定位 → 修复后重新验证 → 用自己的话解释这篇文章是“从Python基础到大模型应用与Agent开发”系列的第一篇。后续文章将围绕同一个统计器逐步增加JSON、HTTP、模型API、评测、RAG和Agent能力并只记录实际完成和验证过的结果。