第 04 模块 · 1 节

规模化交付的设计模式

《Codex 生产级工程》04 规模化与质量 · 本节时长 34 分钟

← 返回课程大纲

一个 Agent 好用，十个项目就乱了

你的自定义 Agent、流水线在一个项目里跑得很好。但当它被多个项目、多个团队使用时，就会遇到规模化问题：各项目各搞一套、重复造轮子、难以维护。

这一节讲规模化交付的设计模式——让一套能力，能稳定复用到多个项目。

贯穿项目deploy-bot 目前只服务一个项目。这一节把它的部署能力「抽成可复用的模板」，让第二个、第三个项目能直接套用，而不是每个项目各自再造一个部署机器人。deploy-bot 从「一个项目的工具」走向「团队共享的能力」。

规模化的核心矛盾

单项目：怎么做好一件事。多项目：怎么做一遍、处处用、统一管。

单项目：好用的脚本  →  只在这个项目
多项目：好用的能力  →  复用到所有项目 + 统一维护

核心问题：怎么「复用」+ 怎么「治理」。

对 deploy-bot 来说：它在 A 项目里跑得很好。当 B、C 项目也要自动部署时，如果每个项目各自复制一份 deploy-bot 的脚本和流水线，很快就会各改各的、互不相通。这一节就是解决「别复制，要抽模板」。

模式一：抽共享配置/模板

别让每个项目各写各的。把通用部分抽成共享配置/模板：

通用的 CLAUDE.md 规范 → 抽成团队模板
通用的技能/脚本 → 抽成共享技能库
通用的流水线 → 抽成可复用的模板

共享层（团队级，统一维护）
  ├─ 技能模板
  ├─ 流水线模板
  └─ 规范模板
   → 各项目引用，不再各写各的

抽一层「共享」出来，复用就有根基。

对 deploy-bot，把「部署」里各项目通用的部分抽出来：

deploy-bot 共享模板（团队级）
  ├─ deploy 脚本模板（通用的拉代码/测/构建/部署骨架）
  ├─ 流水线模板（测试 → 构建 → 部署 staging 的标准流程）
  └─ 部署规范模板（门禁、回滚、上报约定）
   → 各项目引用模板，只填自己的构建命令和部署目标

这样 B 项目要接入，不用重写整个 deploy-bot，填自己的差异就行。

模式二：分层设计

把能力分成「通用层」和「项目层」：

层	内容	谁维护
通用层	所有项目都用的	团队统一
项目层	单个项目的特殊配置	项目自己

通用层统一管，项目层按需配。改通用层，所有项目受益；项目层只管特殊。

对 deploy-bot 的分层：

层	deploy-bot 的内容	谁维护
通用层	部署骨架、门禁、回滚、上报逻辑	deploy-bot 负责人团队
项目层	构建命令、部署目标、环境变量、特例	各项目

改通用层（比如加一道安全门禁），所有用 deploy-bot 的项目一起受益；项目层只处理自己那点差异。

模式三：标准先行

规模化最怕「各搞一套」。先定标准，再推广：

命名规范
技能/Agent 的结构标准
流水线阶段的标准

标准统一了，复用和治理才可能。没标准，规模化就是放大混乱。

对 deploy-bot，先定几件事，推广才顺：

deploy-bot 标准（先定再推广）
- 每个项目接入时，必须声明：构建命令、部署目标、环境
- 流水线阶段统一：测试 → 构建 → 部署 staging →（门禁）→ production
- 部署产物命名统一：version + 时间戳

标准定清楚，十个项目接入 deploy-bot 才是同一套玩法，而不是十套。

一个规模化落地示例

团队定了「3 个通用技能 + 1 套流水线模板」
→ 新建项目时，直接引用模板，不用从零写
→ 通用技能改进，所有项目自动受益
→ 项目只在「项目层」加自己的特殊配置

一套能力，处处复用，统一治理。

落到 deploy-bot：

deploy-bot 规模化
→ 团队定「1 份部署脚本模板 + 1 套流水线模板 + 部署规范」
→ 新项目接入：复制模板 + 填自己的构建命令和部署目标
→ 团队给 deploy-bot 加一道「必须回滚」规则，所有项目自动生效
→ 各项目只在「项目层」加自己的环境配置

B、C 项目接入，不再重复造 deploy-bot。

常见坑：把「复制」当「复用」，各项目越改越散

规模化最常见的坑，是表面说「复用」，实际是「复制」——每个项目把模板拷一份，然后各自改动。

真实场景：A 项目复制了 deploy-bot 的部署脚本，因为自己环境特殊，顺手改了构建命令和回滚逻辑。B 项目也复制了一份，又改了别的地方。半年后，三份脚本已经长成三种不同的 deploy-bot，团队根本没法统一维护，安全问题也无法统一修复。

为什么：「复制」会立刻产生分叉。复制完再各自改，就失去了统一维护的能力，规模化变成了「放大混乱」。

怎么破：用「引用模板」替代「复制文件」——项目层只放差异，通用部分指向共享模板。通用模板的改动走统一发布，项目层尽量少动通用部分。真需要特例，先问「能不能收进通用层」，再谈项目层改动。

小结

规模化矛盾：怎么做一遍、处处用、统一管
模式一：抽共享配置/模板
模式二：通用层 + 项目层分层
模式三：标准先行，别各搞一套

练习把 deploy-bot 抽成可复用模板。①三步走：a. 挑出 deploy-bot 里「所有项目都要」的通用部分，写进一份模板；b. 定出项目层要填的差异（构建命令、部署目标、环境变量）；c. 把「接入新项目」的步骤写清楚。②怎么判断做对了：照着模板，新项目能在不改通用层的情况下接上 deploy-bot；通用层改一处（如加门禁），所有接入的项目逻辑上一起生效；模板文档能让人照做。③卡住了怎么办：分不清哪些通用、哪些是项目差异，就先把「绝对所有项目都一样的」放通用层，拿不准的先放项目层；模板不好抽象，就先服务好 2-3 个项目，从真实差异里提炼，别硬套。

下一节，讲自动化测试与质量门禁。

上一节 ← 流水线安全与失败恢复下一节自动化测试与质量门禁 →

返回《Codex 生产级工程》大纲