技能介绍

要解决的问题

直接把 requirements.txt 提交进仓库的团队，大多踩过同一个坑：文件里只写了几个直接依赖，比如 requests 和 django，并没有记录它们各自拉进来的传递依赖。等到另一台机器上执行 pip install -r requirements.txt 时，解析器可能因为 PyPI 上某个次版本号的发布而拉到完全不同的传递依赖树，表现为“我这台机器上是好的”。更麻烦的是，这类问题常常不会立刻报错，而是在几周后的线上环境里以微妙的兼容性问题形式爆发。

手工维护固定版本也不是好办法。手动把几十个传递依赖的精确版本写死，既容易漏掉新包，又会在升级时引发连锁修改，工程师会本能地抗拒往这个文件里加东西。

这个技能做了什么

它把依赖解析和锁定拆成两步。你只需要维护一个轻量的输入文件（比如 requirements.in），里面列出直接依赖和大致的版本约束；技能内部调用 pip-compile 从这个输入出发，递归解析完整的依赖图，再输出一份确定性的锁定文件，里面固定了每一个包的精确版本和哈希。之后用 pip install 读取这份锁定文件，装出来的环境就是可复现的。

它的核心价值在于不再需要人工去猜传递依赖的版本：新增依赖时在输入文件里加一行，重新编译，剩下的版本冲突由 pip-compile 自动解决和调整；删除依赖时同理，孤儿版本会被自动清理，不会出现手动删除时删不干净的情况。

适用边界与注意点

解析与安装需要在同一虚拟环境中运行。技能要求 pip-compile 和目标环境使用同一套 Python 解释器与 pip 版本，否则解析结果可能对不上。
它锁的是依赖图，不是镜像源。锁定文件中记录的是包名、版本和哈希，仓库地址变化时仍然需要重新解析。
升级是一个显式决策。锁定文件不会自动跟进新版本，升级某个直接依赖时需要显式修改输入文件中的约束并重新编译。
上游强调依赖需真正固定：即便已经写过约束，也要确认构建环境和 CI 中实际使用那份锁定文件，而不是回退到自由解析。

总体而言，这份技能适合需要向团队交付可复现构建产物的 Python 项目，尤其是涉及多个服务或需要长期维护的场景。