2026 年 Django 开发者调查把两个正在重塑 Python 团队工作方式的话题放到了一起：开发者如何把 LLM 纳入日常开发，以及项目如何获得稳定、可复现的构建。前者提高编码速度，后者控制交付风险；如果只关注其中一边，团队很容易得到“写得更快、坏得也更快”的结果。
来源摘要没有提供具体比例，因此不宜凭空解读调查数字。但这些问题本身已经足够明确：LLM 正在成为开发流程的一部分，而依赖、解释器和构建环境必须被更严格地固定下来。
LLM 更适合缩短反馈周期，而不是替代工程判断
在 Django 项目中，LLM 很容易生成模型、视图、表单、测试和迁移建议。真正影响结果的，不是“是否使用 AI”，而是团队把它放在哪一个环节。
比较稳妥的用途包括：
- 根据既有模型补充单元测试和边界案例；
- 解释 ORM 查询并指出潜在的 N+1 查询；
- 为重复的管理命令、序列化器或表单生成初稿；
- 总结错误堆栈，给出排查顺序；
- 协助升级 Django，并整理废弃 API 的替换清单。
风险较高的用途则包括：
- 未经审查就执行模型生成的数据迁移；
- 把生产日志、用户数据或密钥直接发送给外部模型；
- 接受没有测试覆盖的认证、权限或支付代码；
- 让模型自行决定依赖升级范围。
可以给团队准备一个带约束的提示词，而不是只说“帮我写测试”：
你正在审查一个 Django 5.x 项目。
任务：为下面的服务函数生成 pytest 测试。
约束：
1. 不修改生产代码。
2. 覆盖正常路径、权限失败、重复请求和数据库回滚。
3. 不猜测不存在的模型字段；缺少信息时列出问题。
4. 禁止真实网络请求，使用 mock。
5. 输出测试代码，并解释每个测试防止了什么回归。
项目约定：pytest-django，Python 3.12，时区使用 UTC。
这类提示词把模型定位为“受约束的代码助手”。生成内容仍然需要经过格式化、静态检查、测试和人工评审。
可复现构建不只是锁住 Django 版本
仅在 requirements.txt 中写 Django>=5，无法保证开发机、CI 和生产环境安装到相同内容。不同时间解析依赖，可能得到不同的传递依赖版本；Python 小版本、操作系统和 CPU 架构也可能影响最终安装的 wheel。
一个更完整的可复现边界通常包含：
- 固定 Python 版本；
- 锁定直接依赖和传递依赖；
- 校验下载包的哈希；
- 在干净环境中执行测试；
- 记录操作系统或容器基础镜像；
- 明确区分“重新生成锁文件”和“按照锁文件安装”。
锁文件并不意味着永不升级。它的作用是把升级从一次不可见的安装副作用，变成一次可审查的代码变更。
可以这样实践：为 Django 项目生成带哈希的依赖文件
下面是一套可直接改造的 pip-tools 流程。示例假设使用 Python 3.12；运行前请把 Django 和数据库驱动版本范围换成项目实际支持的范围。
创建 requirements.in：
Django>=5.0,<5.3
psycopg[binary]>=3.1,<4
创建 requirements-dev.in：
-c requirements.txt
pytest>=8,<9
pytest-django>=4.8,<5
ruff>=0.6,<1
生成并安装锁定依赖：
python3.12 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install pip-tools
pip-compile --generate-hashes --resolver=backtracking \
--output-file=requirements.txt requirements.in
pip-compile --generate-hashes --resolver=backtracking \
--output-file=requirements-dev.txt requirements-dev.in
pip-sync requirements.txt requirements-dev.txt
python -m pip check
提交 requirements.in、requirements-dev.in 和生成的两个锁定文件。CI 与生产构建只负责安装，不应在每次运行时重新解析版本：
python -m pip install --require-hashes -r requirements.txt
python manage.py check
python manage.py test
--require-hashes 可以阻止未记录或内容不匹配的分发包被悄悄安装。需要注意，锁文件可能与平台相关：如果 Linux CI、macOS 开发机和 ARM 生产环境可用的 wheel 不同，应分别验证，必要时为不同目标生成锁文件。
把环境也纳入构建边界
依赖完全一致，但 Python 补丁版本或系统库不同，结果仍可能漂移。团队可以进一步使用固定摘要的容器镜像。以下写法是实践示例，并不代表来源节目指定了 Docker：
FROM python:3.12.8-slim
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements.txt ./
RUN python -m pip install --no-cache-dir --require-hashes -r requirements.txt
COPY . .
RUN python manage.py check
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]
正式环境还应考虑使用镜像 digest，而不是只依赖可移动标签，并通过 Gunicorn、Uvicorn 等生产级服务器启动 Django。数据库、系统级动态库和外部服务版本也需要记录，否则“容器可复现”仍只是部分可复现。
把 AI 生成内容放进同一条质量流水线
LLM 不应拥有一条绕过现有规范的快速通道。无论代码由谁生成，都可以进入相同的 CI：
name: django-ci
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12.8"
cache: pip
- run: python -m pip install --require-hashes -r requirements-dev.txt
- run: python -m pip check
- run: ruff check .
- run: python manage.py check
- run: pytest -q
这里的关键不是某个特定 CI 产品，而是建立不可跳过的验证顺序：锁定安装、依赖一致性检查、静态检查、Django 系统检查和自动化测试。
采用时的检查清单
团队不必一次重建全部工具链，可以先完成几个高收益动作：
- 固定 Python 版本，并让本地、CI 和生产尽量一致；
- 将宽泛的依赖声明编译为可审查的锁文件；
- 在 CI 中使用哈希校验安装，而不是现场重新解析依赖；
- 要求 LLM 生成的代码附带测试，并接受同样的代码评审；
- 禁止把密钥、生产数据和未脱敏日志提交给外部模型；
- 定期、主动地更新锁文件，并通过自动化测试验证升级；
- 在不同操作系统或架构上验证包含原生扩展的依赖。
LLM 能让 Django 开发更快，但速度需要由可复现环境和自动化验证托底。真正成熟的流程不是排斥生成式工具，而是确保每一份代码——无论来自开发者还是模型——都能在明确、稳定、可审计的环境里被构建和验证。