Cookiecutter：2.5万Star的项目模板引擎，几秒搭好项目骨架

每次新建项目都要重复创建目录结构、写配置文件、搭 CI/CD，这些体力活占用了太多本该写代码的时间。Cookiecutter 就是解决这个问题的，一个命令行工具，用模板生成项目骨架，Python 生态里最知名的项目脚手架之一，GitHub 上拿了将近 2.5 万 Star。

一句话说清楚它干什么

你给它一个项目模板，它根据你的输入（项目名、作者、版本号之类）生成一个完整的项目目录。模板可以放在本地，也可以托管在 GitHub 上。支持任何语言、任何框架，不限于 Python。

装起来也简单，用 uv 一行命令搞定：

uv tool install cookiecutter

然后找个 GitHub 上的模板跑一下：

uvx cookiecutter gh:audreyfeldroy/cookiecutter-pypackage

它会问你几个问题，比如项目名、你的名字、邮箱，答完一个标准的 Python 包项目就生成了，目录结构、setup 文件、测试框架全部就位。

不只是 Python 工具

虽然用 Python 写的，Cookiecutter 的模板可以用在任何语言的项目上。Rust、Terraform、文档站点、Django 项目，只要是你能模板化的东西，它都能生成。模板里的变量用 Jinja2 语法，目录名和文件名里也能嵌变量，灵活度很高。

社区里积累了大量现成的模板。最出名的是 cookiecutter-pypackage，创建标准 Python 包项目的；cookiecutter-django，生成 Django 项目骨架的；还有 pytest 官方提供的 cookiecutter-pytest-plugin，专门创建 pytest 插件项目。在 GitHub 上搜 cookiecutter 能找到成千上万个模板。

模板开发者的视角

从模板创建者的角度看，Cookiecutter 的设计也很干净。一个模板就是一个目录，根目录放一个 cookiecutter.json 文件，定义所有变量和默认值。用户生成项目时回答这些问题，变量就填入模板的对应位置。

模板还支持钩子脚本。在生成项目前后，可以执行 shell 或 Python 脚本，处理 git init、安装依赖这些后续步骤。这让模板不只是复制文件，而是完成一个完整的项目初始化流程。

举一个典型的 cookiecutter.json 例子：

{
    "project_name": "My Project",
    "project_slug": "{{ cookiecutter.project_name.lower().replace(' ', '_') }}",
    "author_name": "Your Name",
    "version": "0.1.0"
}

模板目录里 {{ cookiecutter.project_slug }} 这种变量会被自动替换。零学习成本，看懂一个模板五分钟就够了。

为什么它能活这么久

Cookiecutter 2013 年就发布了，到今天还在维护，支持 Python 3.10 到 3.14。一个工具能活十几年，几个原因：

第一，解决的是真实刚需。每个开发者都经历过创建新项目时的重复劳动，这个痛点不挑语言、不挑框架。

第二，设计克制。它只做一件事，用模板生成项目。不做包管理、不做依赖解析、不做虚拟环境管理，边界清晰。这种克制让它可以和任何工具链配合。

第三，模板生态自驱动。用的人多了，模板自然就多了。模板多了，用的人更多。这个飞轮转了十多年，现在你想创建的几乎所有类型的项目，都有现成的模板可以用。

实际使用中的体验

用 Cookiecutter 久了会发现，最大的价值不是省了创建文件那几分钟，而是团队内部的项目一致性。一个团队维护几套自己的模板，所有新项目用同一套规范生成，目录结构、命名规则、CI 配置全部统一。新人入职跑一行命令就能开始写代码，不用翻文档看项目该怎么组织。

也有一些局限。模板的变量系统基于 Jinja2，复杂逻辑写起来会比较绕。不过日常使用中，简单的变量替换加几个条件判断就够用了，不需要上更重的东西。

总结

Cookiecutter 是个典型的"小而美"工具。它不试图解决所有问题，就专注做好项目模板生成这一件事，做了十多年。如果你还在手动创建项目目录、复制粘贴旧项目的配置文件，可以试试它。五分钟装好，找一个模板跑一遍，大概率就会放进你的默认工具链里。

做了十多年。如果你还在手动创建项目目录、复制粘贴旧项目的配置文件，可以试试它。五分钟装好，找一个模板跑一遍，大概率就会放进你的默认工具链里。