别再手动复制 GitHub Actions 和 Linter 配置了，试试 Pyrig 配合 uv 的自动化工作流

做 Python 开发最耗时的往往不是写业务逻辑，而是那些千篇一律的“基建”工作。每开一个新项目，都要重新配置 Ruff、Black、Mypy，还要手写 GitHub Actions 的 CI 流程，甚至要反复调试 Git hooks。这种机械劳动不仅枯燥，还容易因为版本差异导致配置失效。最近我在几个小型项目中尝试了 Pyrig 配合 uv 的工作流，发现它将项目初始化的复杂度降到了最低，尤其是那种基于 Python 类的配置管理思路，确实解决了传统脚手架“生成即结束”的痛点。

Pyrig 的核心优势在于它不仅仅是一个文件生成器，更是一套具备继承机制的工程管理体系。传统的脚手架工具（如 cookiecutter）通常只是基于模板填充变量，一旦你决定修改默认的 linting 规则或 CI 策略，往往需要去翻找 YAML 或 TOML 文件进行微调。Pyrig 则不同，它将配置逻辑抽象为 Python 类。这意味着你可以像编写普通代码一样，通过子类化（subclassing）来覆盖默认行为。当你运行 pyrig sync 时，它会根据你定义的类动态同步所有配置文件，这种“配置即代码”的方式让大型项目的维护变得异常清晰。

对于已经习惯使用 uv 作为包管理器的开发者来说，Pyrig 的集成体验非常丝滑。下面是一个从零开始搭建标准化项目的完整实操流程，重点展示了如何利用这两个工具快速构建一个包含 CI/CD 和测试骨架的项目。

第一步：初始化环境与依赖

首先，使用 uv 创建项目并指定 Python 版本。这里我们选择目前生态支持较好的 3.12 版本，并将 Pyrig 添加为开发依赖。注意，--dev 参数确保了 Pyrig 不会污染生产环境的依赖树。

uv init my-new-project --python 3.12
cd my-new-project
uv add pyrig --dev

第二步：一键生成工程骨架

接下来，只需运行一条初始化命令。Pyrig 会自动生成标准的目录结构、预配置的测试框架、预提交的 Git hooks，以及一套开箱即用的 GitHub Actions 工作流。这省去了你手动创建 .github/workflows/ci.yml 并配置矩阵构建的时间。

uv run pyrig init

执行后，你会发现项目根目录下已经出现了完善的结构，包括 src/、tests/ 以及配置好的 pyproject.toml。此时，你的项目已经具备了进入 CI 流水线的所有条件，无需任何额外配置。

第三步：扩展 CLI 与测试同步

随着项目迭代，你可能需要添加命令行接口。Pyrig 提供了便捷的命令来生成符合最佳实践的 CLI 入口，避免了手动编写 argparse 代码的繁琐过程。假设我们要为一个数据处理脚本添加 process 子命令：

uv run pyrig mk cmd process

这一步会自动生成对应的命令模块和关联的测试文件。更巧妙的是它的测试同步功能。当你修改源代码结构时，运行 pyrig sync 可以自动检测变化并更新测试骨架。这种“镜像式”的维护机制能有效防止测试用例遗漏，确保代码覆盖率随功能增长而保持同步。

为什么这个组合值得关注？

Pyrig 的价值不在于它生成了多少个文件，而在于它提供了一种可演进的配置范式。通过 Python 类继承来处理配置，使得团队可以在不破坏现有构建流程的前提下，轻松定制 Linter 规则或 CI 步骤。结合 uv 极快的解析速度和依赖管理，这套工具体系让项目从“0”到“1”的启动成本几乎可以忽略不计。如果你受够了每次新建仓库都要复制粘贴 .gitignore 和 workflow 文件，Pyrig 配合 uv 是目前值得投入时间探索的高效方案。