python-dev

核心用法

python-dev skill 是一套立场鲜明的 Python 生产级开发栈，主张「零决策负担」——不讨论选项，直接使用这套经过验证的组合。其核心工作流围绕 uv（包管理与 Python 版本控制）、ty（Rust 编写的类型检查器）、ruff（统一 linter + formatter）、pytest（测试框架）和 just（命令运行器）展开。

典型使用场景：

• 初始化新项目：uv init --package 生成 src 布局，pin Python 3.13，通过 uv add --dev 安装开发依赖
• 配置单一真相源：所有工具配置收敛到 pyproject.toml，包含 Ruff 的宽松规则集、Ty 的 Python 3.13 环境、pytest 的异步自动模式
• 日常开发：just check 一键执行类型检查 + 自动修复 + 格式化；just test 运行测试套件
• 遗留项目迁移：提供从 pip/poetry/mypy/black/flake8 的完整迁移路径

显著优点

1. 速度优势显著：uv 的 Rust 实现使依赖解析与虚拟环境创建达到秒级；ty 同样基于 Rust，类型检查速度远超 mypy
2. 配置极简主义：通过「约定优于配置」消除决策疲劳，pyproject.toml 模板经过生产验证，Ruff 规则集刻意保持宽松（仅启用 E/F/I/UP），避免过度约束
3. 工具链一致性：Astral 出品的 uv/ty/ruff 共享设计理念，pre-commit 钩子与 justfile 无缝集成
4. 现代化默认：强制 src 布局、Python 3.13+、PEP 621 元数据标准、依赖组（dependency-groups）替代传统 dev-requirements

潜在缺点与局限性

• ty 的成熟度风险：截至 2024 年底仍处于 pre-alpha（0.0.1a32），API 与规则集可能剧烈变动，部分 mypy 插件生态无法兼容
• 锁定 Astral 生态：对 uv/ty/ruff 的深度绑定意味着若 Astral 调整方向或商业策略，迁移成本较高
• Python 版本门槛：要求 Python 3.13+， legacy 项目或企业环境可能受限
• just 的学习成本：Make-like 语法对非 Unix 背景开发者需适应

适合人群

• 追求开发效率的独立开发者与小团队
• 希望统一团队 Python 规范的 Tech Lead
• 愿意接受 bleeding-edge 工具以换取性能的技术早期采用者
• 需要从 poetry/pipenv 迁移但厌倦配置文件的开发者

常规风险

| 风险类别 | 说明 |

|---------|------|

| 供应链 | uv.lock 文件需审计，依赖 Astral 预编译 wheel 的可信来源 |

| 工具稳定性 | ty 的 alpha 状态可能导致 CI 意外失败，建议 pin 精确版本 |

| 兼容性 | Ruff 的 UP 规则自动升级语法可能破坏 Python <3.10 的向后兼容 |

| 知识孤岛 | 团队需统一学习 justfile 语法与 uv 命令行习惯 |

本 Skill 是一套面向现代 Python 开发的标准化配置指南，深度整合了 Astral 团队推出的高性能工具链，包括 uv(包管理器)、ruff(代码检查与格式化)、ty(类型检查)以及 pytest(测试框架)和 just(命令运行器)。

核心用法

该 Skill 主要服务于三类场景：新项目初始化、遗留项目现代化改造、以及日常开发工作流优化。对于新项目，它提供了从 uv init 初始化、Python 版本锁定、开发依赖安装到 pyproject.toml 和 Justfile 配置的完整步骤。对于已有项目，则给出了从 pip/poetry/mypy/black/flake8 等旧工具迁移的具体命令和配置替换方案。Skill 的核心价值在于将分散的工具配置收敛到单一的 pyproject.toml 文件中，实现"单一可信源"的配置管理。

显著优点

首先，性能优势突出。uv 采用 Rust 编写，依赖解析和安装速度比 pip/poetry 快 10-100 倍；ruff 同样基于 Rust，lint 和 format 速度远超 black/flake8/isort 的组合；ty 作为 Astral 的新类型检查器，旨在替代 mypy 并提供更快的检查速度。其次，配置高度统一，所有工具均支持 pyproject.toml 配置，避免了传统 Python 项目中配置文件散落各处的混乱。第三，提供开箱即用的生产级模板，包括合理的 ruff 规则集(聚焦 E/F/I/UP 核心规则，避免过度约束)、完整的 pytest 配置、pre-commit 钩子设置以及符合 src 布局的项目结构。

潜在缺点或局限性

主要限制在于工具链的前瞻性。ty 目前处于早期 alpha 阶段(版本号为 0.0.1a32)，API 和规则可能频繁变动，存在生产环境稳定性风险。其次，这是一套" Opinionated"方案，强制推断了 Astral 生态，对于已深度绑定 mypy/pyright/pylint 等工具的团队，迁移成本不可忽视。此外，Python 版本要求较高(模板默认 3.13+)，老旧项目可能需要调整。最后，作为纯文档型 Skill，它本身不执行任何自动化操作，开发者仍需手动复制配置并根据实际情况调整。

适合的目标群体

本 Skill 最适合追求工程效率、愿意接受现代工具链的 Python 开发者，特别是：启动新项目的独立开发者或技术负责人；希望统一团队开发规范的工程管理者；对现有 pip/poetry + black/flake8/mypy 工具链性能不满的开发者；以及希望快速建立 CI-ready 项目结构的 DevOps 工程师。对于坚持使用成熟稳定工具的企业环境，建议等待 ty 进入稳定版本后再全面迁移。

使用风险

由于本 Skill 为纯文档类型，自身无代码执行风险，但使用其推荐的配置时需注意以下几点：ty 的 alpha 版本可能导致类型检查行为与 mypy 不一致，需要团队重新适应；uv 的 lock 文件格式与 poetry 不兼容，混合使用可能引发依赖冲突；ruff 的部分规则可能与遗留代码库产生大量冲突，初次启用时需要评估修复成本；Justfile 依赖 just 工具，在 Windows 环境下的兼容性和团队普及度可能低于 make。建议在实际采用前，先用非核心项目验证工具链的稳定性。