项目地址：https://github.com/nonozone/deploy-baseline
做项目做久了，你会发现，真正拖慢团队效率的，往往不是业务代码本身，而是那些“每个项目都差不多，但每次都不一样”的工程细节。
部署就是其中最典型的一类。
表面上看，大家都在写 Docker Compose、都在写 Makefile、都在写 README、都在写部署脚本。但只要你接手过几个项目，就会很快发现一个现实问题：这些东西虽然名字差不多，实际用法却千差万别。
有的项目 make dev 能跑起来，有的项目 make dev 只是个摆设。
有的项目 deploy/ 目录结构很清楚，有的项目把部署逻辑散落在 README、shell 脚本、CI 配置甚至聊天记录里。
有的项目本地开发是 Docker 全量启动，有的项目是数据库走 Docker、前端本地热更新，但文档里从来没写清楚。
更常见的是，项目自己用着没问题，但一旦换人接手，成本立刻暴露出来。
这也是我决定做这套 deploy-baseline 的原因。
普通开发者在部署上经常会遇到什么问题
1. 每个项目都有自己的一套命令“黑话”
理论上，工程接口应该尽量一致。
但现实里，经常会出现这种情况：
- A 项目用
make dev - B 项目用
make start-local - C 项目要先手动起数据库和缓存，再分别启动后端和前端
- D 项目甚至没有统一入口，只能照着 README 一条条敲命令
问题不是命令多，而是命令没有统一语义。
开发者每切换一个项目，都得重新学习一遍“这个项目自己的规则”。这类重复学习没有业务价值，却会持续消耗时间和精力。
2. 文件看起来差不多，但职责并不清楚
很多项目都有：
docker-compose.ymldocker-compose.prod.yml.envscripts/deploy/
但这些文件到底分别负责什么，经常没有共识。
结果就是：
- 有些运行约定写在 Compose 里
- 有些写在脚本里
- 有些写在 README 里
- 有些根本没人写，只靠口头传承
当项目还是 1 个人维护时，这种问题不一定会立刻爆发；但一旦团队协作、交接、排障、上线频率变高，混乱就会被成倍放大。
3. 新项目总在重复发明部署轮子
每次新建一个项目，理论上都知道应该有这些东西：
- 开发入口
- 构建入口
- 测试入口
- 部署入口
- 回滚入口
- 日志入口
- 环境变量样例
- 部署前检查
- 部署文档
但现实里，大多数项目都不会一次性把这些基础设施搭完整。
于是每个新项目都会重新经历一遍：
“先随便跑起来，后面再整理。”
问题是，这个“后面”通常不会真正到来。
4. 老项目能跑，但很难迁移、很难收敛
真正麻烦的不是从零开始，而是接手一个已经跑了很久的老项目。
它可能已经有一堆脚本、一堆 Compose 文件、一套历史遗留命名、一条只有原作者才懂的发布链路。
这时候你不能简单地说“全部推倒重来”，但如果完全不收敛，混乱又会一直存在。
所以真正需要的，不只是一个模板，而是一套“可以分析、可以判断、可以渐进改造”的部署基线。
我做这套部署基线，主要是想解决什么问题
deploy-baseline 想统一的，不是技术栈，而是工程接口。
也就是说，不管项目是 Node、Python、Go，还是前后端分离、单体服务、混合开发，它至少应该在下面这些层面尽量一致：
- 顶层命令入口一致
- Makefile 的职责边界清晰
- Compose 分层方式一致
- 环境变量分层一致
- 部署文档结构一致
- 回滚和健康检查有明确约定
这样做带来的价值非常直接：
- 开发者切项目时不需要重新学习一套命令体系
- 新项目可以更快落地
- 老项目可以按步骤渐进迁移
- 团队的部署经验可以沉淀为可复用资产，而不是散落在人脑里
这套工具的优点是什么
1. 统一的是接口，不是强行统一技术实现
这套基线允许不同项目保留自己的实现方式，比如：
- 全量 Docker 开发
- 混合开发
- 分离式发布
- 多服务、多前端、多 Worker
但无论内部怎么做，外部工程接口尽量统一。
这比“强制所有项目长得完全一样”更现实，也更容易在团队里真正落地。
2. 同时适用于新项目和老项目
很多模板工具只对新项目有用。
但实际团队里，更难处理的往往是已经存在的项目。
所以 deploy-baseline 不只是提供一个 template/，还定义了完整的基线标准、部署 SOP、命令约定和目录职责。
它既能作为新项目的起点，也能作为旧项目的收敛目标。
3. 它补的不只是模板，还有规范和执行路径
这套仓库不是只放了几份模板文件，而是把部署相关的关键部分一起补齐了：
- 通用部署基线规范
- 通用部署 SOP
- 可复制模板骨架
- Makefile 命令面
- 部署脚本入口
- 可被 Codex 调用的 skill
也就是说，它不是一份“看完以后自己想办法实现”的文档，而是一套真正可以带进项目里的工程资产。
4. 它能降低接手成本和维护成本
当命令语义、目录结构、部署文档结构都稳定下来以后，团队收益会非常明显：
- 新人更容易上手
- 老项目更容易接手
- 运维和开发沟通成本更低
- 出问题时排查路径更清晰
- 不同项目之间更容易复用经验
这类收益平时不容易被高估，但长期看，往往非常值钱。
为什么我还额外做了一个 skill 工具
如果只有规范和模板，那它依然偏“人工使用”。
你得自己看文档、自己判断项目现状、自己决定怎么改、自己一点点落文件。
这当然可行，但门槛还是不低。
所以我又把这套能力包装成了一个可以直接调用的 skill：deploy-baseline-kit。
它的作用是，把“部署基线”从一套文档，变成一套可调用能力。
开发者可以直接在目标项目目录里调用它，让它先分析，再给出改造方案，再在一次确认后执行生成或收敛。它会帮助判断：
- 项目根目录在哪里
- 当前项目属于空目录、轻量项目，还是重度已有项目
- 当前更适合全量 Docker 还是混合开发
- 当前数据库类型是什么
- 应该走“直接生成”还是“收敛改造”
这件事的价值很大，因为真正能被团队持续使用的东西，不能只“写得对”，还得“调用方便”。
如果一个方案太复杂、太依赖人工判断、太需要开发者自己拼装流程，最后大概率会变成“知道它很好，但没人愿意真正去用”。
而 skill 化之后，调用成本更低，落地概率也更高。
这套部署基线适合什么样的人
如果你符合下面这些场景，这套东西会比较有用：
- 你在多个项目之间频繁切换
- 你经常接手历史项目
- 你希望团队的部署方式更统一
- 你不想每个新项目都重新搭一遍部署骨架
- 你想把部署经验沉淀成模板、规范和工具，而不是口头约定
结语
我做这套部署基线，并不是因为我觉得“所有项目都应该一样”，而是因为我越来越确定一件事：
一个团队真正需要统一的，不是业务，而是工程协作的基本接口。
部署命令、目录结构、环境变量分层、文档形态、回滚入口，这些东西看起来不如业务功能耀眼，但它们决定了一个项目是否容易接手、容易迁移、容易维护。
deploy-baseline 想做的，就是把这些本来容易混乱、容易失控、容易依赖口口相传的部分，沉淀成一套可以复制、可以收敛、可以被工具直接调用的工程基线。
而 deploy-baseline-kit 的存在，则让这套基线不只是“文档上的标准”，而是“开发者可以真正拿来用的能力”。