⚠️ 法律与用途声明：本文讨论仓库模板化与 CI 能力推广的设计，基于开源工具（GitHub Actions / Conan 2 / workflow_call），属于经验分享。所有企业名、项目名、内部脚本与路径命名均已脱敏，代码示例中的标识符均为占位。读者须遵守所在地区法律法规。
一、好能力别藏着，得让每个仓库都用上
前 13 篇（A1 到 A13），我们一块一块搭起了整套平台能力：self-hosted runner 调度、Docker 三层构建、hardlink 缓存治理、声明式构建矩阵、私有 Conan Center、交叉工具链包、Token Broker 自助授权、制品真源与加速层分离、人工晋升门禁、Build Registry 可观测、板测三键模型、上板验证闭环、benchmark CI。
这些能力搭起来不容易，但搭完之后有个问题：一个新算法仓库要接入这套平台，得做多少事？
如果每个新仓库都要从头配一遍 CI workflow、手写 Conan recipe、记住该配哪些 Secrets、搞清楚 build-matrix 怎么声明——那这些能力再强也推广不动。开发者会觉得"接入平台比写算法还累"，宁可自己土法搞。
这一篇就讲怎么把前 13 篇的能力打包成一个模板，让新仓库几分钟接入、开箱即用。
二、从零搭的痛
先说从零搭为什么不行。一个新算法仓库要接入平台，如果全靠手动，要做这些事：
- 从别的仓库复制粘贴 CI workflow，改仓库名、改路径、改目标列表。粘漏一行，CI 报错排查半天。
- 手写 Conan recipe，记不清
exports_sources怎么声明、metadata.json哪些字段必填。 - 去平台文档里翻"该配哪些 Secrets 和 Variables"，漏配一个 CI 就跑不通。
- 构建矩阵声明格式记不住，照着别的仓库改，改出语法错误。
这些事的共同特征是：重复、易错、依赖人的记忆。每多一个仓库，就多一次重复犯错的机会。人不是机器，手动做这些迟早出岔子。
三、模板仓库：一份标准开店手册
解法是做一个模板仓库——它不是某个具体的算法项目，而是一份"标准开店手册"，新仓库从它创建，自带接入平台所需的所有骨架：
template-repo/
├── conanfile.py # Conan recipe 骨架（含 metadata 继承）
├── metadata.json # 包元数据（单一数据源）
├── configs/build-matrix.yaml # 构建矩阵声明（声明式，A4 讲过）
├── .github/workflows/
│ └── ci.yml # CI 入口（极简，只引用平台模板）
├── docs/ # 文档骨架（Doxygen/Sphinx）
├── test_package/ # Conan 测试骨架
└── benchmark/ # benchmark 骨架（bench_entry + 板卡配置）
这个模板仓库的关键设计是：每个文件都是骨架，不是成品。conanfile 是骨架（具体算法往里填）、build-matrix 是声明模板（具体目标按需改）、CI 入口只引用不写实现。
GitHub 有个 template repository 功能——把一个仓库标记为模板，新仓库可以一键从它创建。创建出来的仓库自带模板里所有文件，开发者不用复制粘贴，开箱就有全套骨架。
四、workflow_call：CI 模板总部定义，门店只引用
CI workflow 是模板化推广里最关键的一环。前 13 篇讲的那些能力（三层构建、缓存治理、构建矩阵展开、promote 门禁、benchmark CI），它们的实现逻辑都在平台的 CI 模板里。业务仓库不该自己写这些逻辑，只该引用它们。
GitHub Actions 的 workflow_call 就是干这个的。平台的 CI 模板仓库里定义好一整套可复用 workflow，业务仓库的 CI 入口只写几行引用：
# 业务仓库的 CI 入口（极简）
jobs:
build:
uses: <平台组织>/<ci-templates>/.github/workflows/build-matrix.yml@<版本>
with:
matrix_file: configs/build-matrix.yaml
secrets: inherit
promote:
uses: <平台组织>/<ci-templates>/.github/workflows/promote.yml@<版本>
if: github.event_name == 'workflow_dispatch'
secrets: inherit
这个设计的好处是平台 CI 逻辑只维护一份。平台升级了 hardlink 策略（A3）、改了门禁检查（A9）、加了 benchmark 闭环（A13），只需要改 CI 模板仓库里那一处。所有引用它的业务仓库下次跑 CI 自动用新版本，不用一个个去改。
这就是"平台演进、业务无感"的终极落地——业务仓库只声明意图（build-matrix.yaml + workflow 引用），平台负责所有实现细节。两边各自演进，互不拖累。
五、接入 checklist：新仓库几分钟开张
有了模板和 workflow_call，新仓库接入就简化成一份 checklist：
一个初始化脚本可以自动完成大部分（伪代码）：
def init_new_repo(template_repo, repo_name, targets):
# 1. 从模板创建仓库
repo = create_from_template(template_repo, repo_name)
# 2. 按需求生成构建矩阵
generate_matrix(repo, targets=targets)
# 3. 填好 metadata（包名、版本、依赖）
fill_metadata(repo, name=repo_name, version="1.0.0")
# 4. 输出需要手动配的 Secrets/Variables 清单
print_checklist([
"Secrets: CONAN_USER, CONAN_PASS (只读 token)",
"Secrets: CONAN_UPLOAD_USER, CONAN_UPLOAD_PASS (上传 token)",
"Variables: CONAN_REMOTE_URL",
])
return repo
开发者拿到这份 checklist，去 GitHub 仓库设置里配几个 Secrets，改一下 build-matrix 声明自己的目标，push 上去——CI 就自动跑起来了。从模板到第一次 CI 绿，应该控制在几十分钟以内。如果接入要花一整天，说明模板化还不够彻底。
六、模板更新怎么传到老仓库
模板不是一成不变的。平台会升级 CI 逻辑、加新检查、优化缓存策略。这些更新怎么传到已经创建的仓库？
靠 workflow_call 的版本引用。业务仓库引用的是 @<版本>，平台发新版本模板后，业务仓库把引用的版本号一改（甚至指向 @main 自动跟最新），下次 CI 就用新逻辑了。模板更新不需要业务仓库改代码，只改一个引用版本号。
模板仓库本身也可以沉淀版本——用语义化版本标记每次模板变更。大改（破坏性）升 major，小改升 minor，这让业务仓库可以按自己的节奏选择跟进哪个版本。
七、平台系列 A：一条线串起来
写到这里，平台系列 A 的 15 篇（A0-A14）就全部串完了。回头看，它们是一条清晰的线：
- A0 总纲：两层架构、六层 CBB 模型
- A1-A4 调度与执行：runner 调度分离、Docker 三层构建、hardlink 缓存治理、声明式构建矩阵
- A5-A7 Conan 生态：私有 Conan Center、交叉工具链包、Token Broker 自助授权
- A8-A10 制品与可观测：制品真源与加速层分离、人工晋升门禁、Build Registry 可观测账本
- A11-A13 上板测试：板测三键模型、上板验证闭环、benchmark CI 性能量化
- A14 模板化推广：把前 13 篇的能力打包成模板，惠及每个新仓库
这条线的本质是：从搭一个能力到让所有仓库都用上这个能力。A1-A13 是搭能力，A14 是让能力可复制。没有 A14，前 13 篇的能力只存在于一个仓库里；有了 A14，每个新仓库开箱就有全套基础设施。
八、结语：平台系列的终点，是让开发者忘了平台的存在
平台系列 A 讲完了。回头看这 15 篇搭的东西，最终目标其实只有一句话：
让算法工程师写完代码、push 上去，CI 自动构建、自动测试、自动出报告——他全程不需要知道 runner 怎么调度、Docker 怎么隔离、Conan 缓存怎么治理、真源怎么归档。
最好的基础设施，是让人忘了它的存在。A1 到 A13 搭的那些能力，对算法工程师来说应该是透明的——他只管写算法、声明构建矩阵、看 CI 结果。至于背后那套三层构建、hardlink 快照、读写锁、三键模型、板测闭环……他不需要知道，也不该知道。
平台的成功，不在于它有多复杂，而在于它能让开发者觉得一切都很简单。
接下来，我们换一个视角。前 15 篇讲的是"平台"（地基），后面要讲的是"模板仓"（建筑）——模板仓里的 metadata 怎么驱动一切、Conan recipe 怎么从元数据继承、文档/测试/benchmark 怎么自带。那个系列叫 B，从 NO.B0 开始。
中间还会插一篇耦合篇（NO.AB1），专门拆解平台和模板仓怎么解耦又怎么靠契约对话——那是架构师视角的核心。
参考链接：
[1] GitHub：创建 template repository https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repository
[2] GitHub Actions：可复用 workflow（workflow_call） https://docs.github.com/en/actions/how-tos/sharing-workflows-reusing-workflows
[3] Conan 2：recipe 结构与模板化 https://docs.conan.io/2/reference/conanfile.html
[4] 语义化版本（SemVer） https://semver.org/
[5] GitHub Actions：仓库 Secrets 与 Variables https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/using-secrets-in-github-actions
[6] Conan 2：build-matrix 与多目标声明 https://docs.conan.io/2/reference/config_files/profiles.html