环境配置与基础教程：当前大厂主流套路：使用 Poetry 替代 Conda/pip 进行 PyTorch 项目依赖隔离与精细化管理
引言：一个让人崩溃的 PyTorch 环境配置故事
凌晨两点，你正准备提交一个准备了整整三天的 PyTorch 实验代码。本地跑得好好的，push 到 CI 跑不通。查了半天日志，发现 CI 服务器上的 PyTorch 版本比本地高了一个小版本，导致某个 OP 的行为变了。你打开requirements.txt，发现根本没锁死版本——当初写着torch>=2.0.0，想着“反正都能用”。
这不是虚构的故事。根据 2025 年 Python 开发者调查，使用环境管理工具的团队，环境配置耗时平均减少 72%，生产环境依赖冲突率下降 91%。但在 AI/ML 领域，依赖管理问题比普通 Web 项目严峻得多——PyTorch 项目不仅要处理 Python 包本身，还要面对 CUDA 版本、硬件架构、平台特定二进制等“地狱级”难题。
Conda 曾经是 AI 开发者的默认选择，因为它能一条命令装好 CUDA、cuDNN 和 Python 全家桶。但随着项目规模的膨胀和协作需求的增加，Conda 的弊端也逐渐暴露：环境体积臃肿、依赖解析极慢、与 PyPI 生态的割裂感越来越强。
Poetry 2.0 发布后，用 Poetry 管理 PyTorch 项目正在成为大厂和开源社区的主流方案。本文将结合 2025-2026 年最新的工具生态变化和实战经验，系统讲解为什么要迁移、如何优雅地配置，以及有哪些坑需要避开。