导读：PyCon 的一场演讲让他决定重构整个 Python 工作流。核心标准只有一个：最少总工作量。

从教育项目到模板仓库

打开网易新闻 查看精彩图片

他的 python-prototype 仓库最初只是为了教学。现在他想让它成为随手可用的项目模板。

借着升级测试框架（pytest）和打包配置（pyproject）的机会，他开始思考：还能加什么？

Black 和代码检查工具用了很多年，但有没有更好的方案——能自动维护代码风格（PEP 8）、文档字符串（PEP 257）和类型提示（PEP 484）？

开发环境也得现代化。Poetry 还是 uv？这像极了 emacs 与 vi 的阵营之争，还没算上其他工具。

他需要的东西要覆盖代码质量、格式化、打包，甚至更多：减少依赖记忆或翻阅 README 的任务，提高实际执行的概率。

没有"一站式套餐"，只能测试各种维护良好、可持续的方案，找到最适合自己的。

唯一标准：懒人的总成本

驱动所有选择的单一准则是：最少总工作量。

工具越少 = 配置越少 = 维护越少。

这位"懒"开发者希望工具链在提交前就拦截问题，防止步骤被遗漏。但不过度：刚好足够产出高质量代码。

第一次用代码检查工具扫描 simple-sample 时，分数刺痛了他：4.35/10。高中生的成绩，不该出现在教学仓库里。

他坐下来修正 JavaScript 后遗症：myClass 改成 my_class（PEP 8 命名规范），foo、bar、foobar 改成 get_param_processing、get_boolean、get_reverse_protected_param——能说明用途的名字。

分数爬到 9.41/10。

工具的三道判断题

庆祝之前，三个警告需要裁决。每个都是"工具对代码的判断正确，但对上下文判断错误"。

这就是静态分析的边界：它告诉你发现了什么，却不告诉你是否真的需要修复。逐案判断仍由人做，工具本身不会自动改变任何东西。

他主动找麻烦，对测试套件运行检查。新警告出现：W0621 redefining-outer-name，指向 fixture：

「工具说'你在重新定义外部作用域的 mci'。但这种模式正是 fixture 的工作方式：不是重定义，是参数注入。」

检查器像执行代码一样读代码，却不知道 pytest 如何运行它。

误报。变通方案存在：给 fixture 加 name 参数，让函数名和注入名分离。但这只是为了消除噪音，而非改进代码本身。

一图拆解：懒人的质量防线

整个实验的核心逻辑可以用一张图概括——从代码提交前的拦截机制，到工具选择的成本公式。

第一层：提交前拦截。工具链必须在 git commit 之前崩溃，而不是在生产环境。这是"懒"的精髓：用自动化替代记忆。

第二层：工具数量与维护成本的反比关系。每增加一个工具，配置文件的乘法效应就开始了——格式化器的行长、检查器的禁用规则、测试框架的搜索路径，各自为政。

第三层：误报的处理成本。W0621 不是孤例。每个误报都需要人类判断：是真的问题，还是工具不懂上下文？这种判断消耗的认知资源，必须计入"总工作量"。

第四层：代码可读性的复利。get_param_processing 比 foo 多打的字符，会在六个月后的调试中连本带利返还。命名是写给未来的自己的信。

第五层：教育代码的示范义务。4.35/10 的分数不只是难堪——它传递了"代码质量可有可无"的错误信号。模板仓库的每一行都是教学材料。

Poetry 与 uv：环境管理的阵营战

回到那个未完成的抉择。作者提到了 Poetry 和 uv 的对立，像 emacs 与 vi 的永恒战争。

但原文没有给出他的最终选择。我们只能看到思考框架：维护状态、社区活跃度、与现有工作流的集成成本。

这种开放性本身就是诚实——工具选型没有标准答案，只有特定上下文下的局部最优。

他的方法论是测试驱动：不依赖口碑或