从脚本到 AI，Python 程序员的技术栈正在发生变化

Python 一直非常擅长快速把事情做起来。

几行 Python 就可以自动化一个重复任务、处理一个文件、调用一个 API，或者把一个想法变成可以运行的原型。对于很多开发者来说，这种简单性正是最初学习 Python 的主要原因。

但今天 Python 的使用方式正在发生变化。

Python 越来越多地处于 AI 应用、数据管道、API、自动化系统和基于 Agent 的软件的中心。因此，围绕 Python 的技能也在发生变化。

今天的 Python 开发者可能上午还在写一个 30 行的脚本，下午就需要处理依赖锁定、结构化数据验证、异步 API、可观测性、模型提供商、向量搜索和部署。

语言本身并没有发生根本性的变化。

变化的是它周围的整个工程技术栈。

从 python script.py 到一个真正的项目

传统的 Python 工作流很简单：

python script.py
pip install requests

对于一个小脚本来说，这完全合理。

问题出现在脚本逐渐变成一个产品之后。

一个不断增长的应用需要明确的 Python 版本、可复现的依赖、开发依赖、测试、格式化、lint、打包、CI 和部署。

现代 Python 项目越来越多地把这些信息放进 pyproject.toml，而 uv 这样的工具可以通过单一工作流管理项目环境、依赖、锁定、运行命令、打包和发布。uv 的项目工作流可以在 pyproject.toml 旁边创建项目环境和 lockfile。(docs.astral.sh [1])

例如：

my-project/
├── pyproject.toml
├── uv.lock
├── .python-version
├── .venv/
├── src/
├── tests/
└── README.md

重要的变化在于思维方式。

Python 应用越来越被当作一个可复现的软件项目，而不是一堆 .py 文件。

lockfile 在这里尤其重要。pyproject.toml 描述项目需要的依赖，而 uv.lock 记录环境使用的解析后版本。这使开发者和部署系统能够在不同机器上复现相同的依赖集合。(docs.astral.sh [2])

仍然有大量 Python 代码使用 pip 和 requirements.txt，这些工具也仍然属于 Python 生态的一部分。重点在于，现代 Python 开发已经拥有了更加完整的项目管理层。

Python 技术栈正在变得更加类型化

另一个重要变化是 type hints 越来越重要。

Python 仍然是动态类型语言，但现代 Python 应用越来越多地把 type annotations 作为设计的一部分。Type hints 本身不会自动在运行时执行检查；运行时验证需要使用 Pydantic 这样的工具。

来看一个简单的 API：

def create_user(name: str, age: int) -> User:
    ...

这些 annotations 可以被 IDE、静态类型检查器、文档工具、框架以及运行时验证库使用。

这在 AI 应用中尤其有用。

LLM 可能返回文本，但应用的其他部分通常需要结构化数据。

例如：

class UserProfile(BaseModel):
    name: str
    age: int
    interests: list[str]

像 Pydantic 这样的库可以把这些声明转换成验证规则。

这样可以让 Python 代码和外部数据之间的边界更加清晰。

随着 Python 应用与 API、数据库、消息队列和 AI 模型进行通信，这种模式变得越来越重要。

应用不再只是简单地传递字符串。

它正在为系统的不同部分定义契约。

FastAPI 改变了 Python 在后端的角色

Python 已经用于 Web 开发很长时间了，Django 和 Flask 等框架也已经成为生态的重要组成部分。

FastAPI 通过将 Python type hints 与请求验证、异步编程和自动 API 文档结合起来，推动了生态向另一个方向发展。

这与现代 AI 应用非常契合。

一个 AI 服务可能需要：

 

接收 HTTP 请求。

 

 

验证结构化输入。

 

 

调用 LLM。

 

 

从数据库或搜索系统中检索信息。

 

 

执行工具。

 

 

流式返回响应。

 

 

记录 traces 和 metrics。

 

Python 越来越多地被用作连接这些组件的应用层。

模型本身可能运行在其他地方。

Python 应用则成为围绕模型进行编排的那一层。

这个区别很重要。

一个 AI 产品很少只是：

response = model.generate(prompt)

一个真正的应用还需要在这个调用周围处理认证、重试、超时、验证、持久化、日志、监控和故障处理。

AI 正在为 Python 技术栈增加新的一层

这可能是 Python 开发者面临的最大变化。

传统应用开发通常大致是这样的：

Python
   ↓
Web Framework
   ↓
Database
   ↓
External APIs

AI 应用增加了几个新的组件：

Python
   ↓
API / Application Layer
   ↓
AI Framework / Model SDK
   ↓
LLM
   ↓
Tools / Retrieval / Memory
   ↓
Database / Vector Search / External Services

有时中间还会有一个 Agent：

User
  ↓
Python API
  ↓
Agent
  ├── LLM
  ├── Tools
  ├── Retrieval
  ├── Memory
  └── External APIs
  ↓
Response

LangChain、LangGraph 和 Pydantic AI 等框架，都是用于构建这类应用的工具。

具体选择哪个框架仍然在不断变化。

更加持久的能力是理解架构。

开发者需要理解 Agent 调用工具时发生了什么，状态如何维护，结构化输出如何验证，故障如何处理，以及如何在生产环境中观察一个 AI 请求。

模型只是整个系统中的一个组件。

从机器学习到 AI 工程

这里还有另一个重要变化。

你不一定需要成为机器学习研究人员，才能构建有用的 AI 应用。

当前 AI 开发中有很大一部分属于应用工程，尤其是围绕已有模型 API 构建的应用。

Python 开发者可以通过 API 使用现有模型，将它与应用数据结合，通过 FastAPI 暴露功能，使用 Pydantic 验证结果，将信息存储在 PostgreSQL 中，使用 Redis 进行缓存，然后通过 Docker 部署整个系统。

这更接近软件工程，而不是传统的模型研究。

因此，技能范围也变得更广。

一个从事 AI 应用开发的开发者可能需要理解：

 

Python

 

 

HTTP 和 APIs

 

 

异步编程

 

 

数据库

 

 

缓存

 

 

认证

 

 

结构化数据

 

 

LLM APIs

 

 

embeddings

 

 

retrieval

 

 

agent workflows

 

 

测试

 

 

可观测性

 

 

容器

 

 

CI/CD

 

这比传统 Python 脚本所涉及的技术栈要大得多。

工具层正在变得更快

现代 Python 工具也正在转向更快的原生实现。

Ruff 在一个高性能工具中提供 linting 和 formatting。

uv 提供快速的项目和包管理工作流，并使用 Rust 实现。

Pydantic 的验证引擎使用 Rust 组件。

Polars 提供了一个基于 Rust 引擎实现的 DataFrame 系统。

这在 Python 生态中形成了一个有意思的模式。

Python 仍然是开发者表达应用逻辑时使用的语言，而对性能敏感的基础设施越来越多地转向原生代码。

开发者仍然会写：

result = process(data)

但在这个调用下面，大量工作可能是在经过优化的原生库中完成的。

这种方式让 Python 保持高生产力，同时不要求每个开发者都为了性能关键部分去编写 C 或 Rust。

AI 编程工具正在改变开发者的工作方式

还有一个不能忽视的变化：开发者在编写 Python 时越来越多地使用 AI 工具。

代码生成可以在几秒钟内生成一个函数。

它可以生成测试、解释陌生代码、重构重复代码，并帮助调查错误。

这改变了编写代码的成本结构。

生成代码变得越来越容易。

理解生成的代码是否正确仍然很重要。

例如，AI 助手可能生成一个在小数据集上可以工作的数据库查询，但在大规模数据下性能很差。它可能生成无意中阻塞 event loop 的异步 Python。它也可能调用一个外部 API，却没有正确处理 timeout。

因此，开发者需要更加深入地理解代码下面的系统。

AI 可以减少需要输入的代码量。

但它不会消除工程判断的必要性。

测试变得更加重要，而不是更不重要

这一点在 AI 应用中尤其明显。

传统软件通常具有确定性的输入和输出：

assert add(2, 3) == 5

LLM 应用可能具有更低的确定性。

因此，一个有用的 AI 系统需要多个层次的测试。

有针对应用逻辑的普通单元测试。

有针对数据库和 API 的集成测试。

也可以使用 evaluation sets 来评估模型行为。

生产系统还需要可观测性。

例如：

Request
   ↓
API
   ↓
Agent
   ↓
LLM
   ↓
Tool
   ↓
Database

当最终答案出现错误时，开发者需要知道问题发生在哪里。

是 prompt 有问题？

是 retrieval 返回了质量较差的文档？

是模型选择了错误的 tool？

是 tool 返回了错误的数据？

还是应用错误地解析了模型输出？

如果没有 tracing 和结构化日志，调试会变得非常困难。

这就是为什么可观测性和评估正在成为 AI 应用技术栈的一部分。

“脚本”和“应用”之间的边界正在发生变化

现代 Python 生态中最有意思的一点，是一个快速脚本与生产应用之间的距离正在变小。

开发者可以从下面这样的代码开始：

import requests
data = requests.get(url).json()
print(data)

之后，同一个想法可能变成：

CLI
 ↓
Python package
 ↓
FastAPI service
 ↓
Database
 ↓
AI model
 ↓
Agent
 ↓
Production infrastructure

现代工具让这些阶段之间的转换变得更加容易。

例如，uv 同时支持 Python projects 和 standalone scripts，包括带有内联依赖元数据的脚本。(docs.astral.sh [3])

这意味着 Python 不需要强迫每个实验一开始就采用完整的项目结构。

一个小脚本可以继续保持小巧。

当这个想法变得有价值之后，周围的工程体系可以随之扩展。

Python 开发者接下来应该学习什么？

Python 生态太大了，不可能把所有东西都学会。

更加实际的方式，是建立一个分层的技能体系。

首先，把 Python 本身学好：

Python
├── Functions
├── Classes
├── Iterators
├── Asyncio
├── Exceptions
├── Type hints
└── Standard library

然后学习现代应用开发：

Application Development
├── FastAPI
├── Pydantic
├── SQL
├── PostgreSQL
├── Redis
├── pytest
└── Docker

然后加入 AI 层：

AI Engineering
├── LLM APIs
├── Structured output
├── Embeddings
├── RAG
├── Tool calling
├── Agents
├── Evaluation
└── Observability

最后，学习足够运行你所构建系统的基础设施知识：

Production
├── Linux
├── Networking
├── Containers
├── CI/CD
├── Monitoring
└── Cloud

这并不意味着每个 Python 开发者都需要成为 AI 工程师。

这意味着 Python 开发的重心正在扩大。

过去的 Python 开发者可能主要从脚本、包和 Web Framework 的角度思考。

今天的 Python 开发者越来越需要从系统的角度思考。

而从事 AI 开发的 Python 开发者需要理解更广泛的一点：

Python 正在成为连接模型、数据、API、工具和生产基础设施的胶水。

语法看起来可能依然熟悉。

但围绕它的工作正在发生变化。

以上就是“从脚本到 AI，Python 程序员的技术栈正在发生变化”的详细内容，想要了解更多Python教程欢迎持续关注编程学习网。