企业级 AI Coding：有了 Landing Zone，为什么还要谈「脚手架」？

很多团队已经读过 Landing Zone：知道仓库里该有 AGENTS.md、该有 Spec 文档、该有门禁与治理红线。下一个在一线反复出现的问题是：「我们把要求写进 Confluence / 飞书、在启动会上讲清楚了，算不算已经落地了？」——算组织共识，但还不算工程落地。只要各服务仓里的 目录形状、Spec 表头、门禁命令仍靠「各组自己悟」，很快会出现：A 仓和 B 仓的 AGENTS 长得不一样、CI 与 markdown 各说各话、AI 换一仓就换一套习惯——评审痛苦，模型也容易「幻觉接口」。

要把 Landing Zone 从 「大家认同的道理」变成 「每个仓里可打开、可评审、可对齐版本的那套文件」，就需要 脚手架：在本文语境里，它泛指 模板仓、生成器、IDE 集成、团队 Skill等一切 「把同一套规约复制进多仓」的手段——不是必须先做一个叫某某名字的专用 CLI。

一、「脚手架」在这里指什么

企业级 AI Coding 脚手架，优先服务的是：规约、Spec（含可对齐验收的契约）、分层样例、协作与质量、治理底线——让 人、AI、CI打开仓库就对齐同一把尺。它和常见的 Spring Initializr / 空工程模板不同：后者首要目标是「依赖齐、能跑」；这里首要目标是 「首屏就对齐、先规格后实现」。业务代码默认不是主角；若公司另有统一空工程母版，适合 分阶段、分版本号叠加，而不是和 AI 工作面混成一锅。

一句话：Landing Zone 告诉你「该长什么样」；脚手架帮你「每个仓真的长成那样，且多仓一致」。

二、有了 Landing Zone，为什么还要脚手架？

Landing Zone解决的是 「应该有什么」——契约、边界、清单、评审口径。

脚手架解决的是 「这些约定如何低成本、可重复、可对齐版本地进入每一个仓库」——模板、变量渲染、存量合并策略、发版与 CHANGELOG 等。

没有脚手架只靠自觉，常见结局是：

• 各仓 AGENTS结构不一，横向评审没法对齐；
• 先写代码后补 Spec，验收时才发现契约从未写死；
• 门禁命令只写在 markdown，CI 没接或接了另一套，文档与流水线两张皮。

因此二者 不是重复立法，而是 「规则」与「工具」：没有工具，规则仍成立，但落地靠手抄，成本高、易漂移；有了印刷厂，多仓才能同版对齐。没有 Golden Template这类手段时，脚手架仍然存在，只是退化成 对照清单手工建文件——本质需求没变，变的只是效率与可控性。

三、两句话对照：Landing Zone vs 脚手架

四、最小落地应该长什么样

不必记章节号，记住 四件事进仓即可对齐多数讨论里的「最小一套」：

1. 1. AGENTS.md：栈、目录、习惯、永久红线、本地/CI 验证命令。
2. 2. spec-docs/里三份 P0 规格骨架：用户故事与验收（05）、接口（09）、数据模型（10）——先有结构与表头，再填业务事实。
3. 3. Reference/：分层 每层一例「黄金片段」，约束 AI 别乱发明接口形状。
4. 4. 协作与质量：至少要有 quality-gates.md里写清「团队公认要跑哪几条命令」，并尽量与 CI 同源。

其余（企业知识模板、培训清单、治理专章、RepoWiki、IDE Rules 等）是 强烈推荐的加厚层，适合按组织成熟度 分期上，不宜与「第一天必须交卷」绑死——否则落地阻力会被人为放大。这一条判断，是对「清单越来越长」的刻意收敛，逻辑上是为了 可执行优先于完备。

五、九成团队够用的抓手：Golden Template

Golden Template不是新框架，就是托管平台上 「模板仓库 + 从模板创建」：把上面那套目录 一次性复制到新仓库。平台只做复制，不会替你自动替换项目名（除非你们另加 Copier / 脚本），也不会对老仓做「只补缺失文件」——后者要 overlay + dry-run一类能力，属于 CLI 或严谨手工流程。

为什么仍值得单独写进「脚手架」叙事？

因为它是最便宜的 「版本化基线」：模板打一个 tag，CHANGELOG 写清对齐哪版 Landing Zone 论述，各服务仓就不容易长成「民间方言」。

六、CLI 不是必选项：一张表看懂「谁干什么」

没有某家公司的专用 CLI，并不等于「没法工程化」。GitHub / GitLab 的 Template 仓库、Copier、IDE 扩展、团队 Skill，都是真实可落地的脚手架形态。CLI 只在「多仓批量、存量安全合并、要强审计」时更值得投资。

逻辑提醒（也是原文档里容易被略读漏掉的一点）：AGENTS.md+ spec-docs/应是「单一事实来源」；Rules、Wiki、RepoWiki 是 放大器或渠道，若与之冲突，应以 AGENTS + Spec为准，并建立 季度或发版前的对照习惯——否则会出现 「IDE 里一套、PR 里另一套」的双真源。

七、五块「容易漏但很重要」的拼图（各一句话边界）

• IDE Rules（如 .cursor/rules）：把规约 切片进会话；主规约仍在 AGENTS，避免双标准。
• RepoWiki / 仓库百科：从代码沉淀 地图；不写验收契约，契约仍在 Spec。
• Agent Skill：把「写首条 05、过门禁清单」收成 可复用剧本；与 CLI 并列，不是替代关系。
• GitHub/GitLab Wiki：适合 长叙事、慢变更；接口与验收 不要只活在 Wiki。
• MCP / hooks：外联与提交前提醒；要有 数据分级与降级，且 不替代 CI。

微信篇幅里 不展开操作步骤，可参见完整方案《企业级AI-Coding-脚手架方案》。

八、配套 SKILL：不必一次上齐，先认「地图」

完整版方案里列了 20 条以 landing-zone-为前缀的占位 SKILL（仅有名称与作用，正文另仓后续发布）。微信里若全表粘贴，阅读体验差，这里按 意图聚类，每类给 代表 slug，便于内部对齐「以后要补哪类 Skill」。

判断：对读者而言，「分类地图」比「20 行 slug 表」更易建立行动直觉；全表留给 Ctrl+F 与工程对接更合适。

九、建议演进顺序（与组织成熟度挂钩）

1. 1. 阶段 0：Golden Template + 手工替换占位符（已能解决「多仓对齐形状」）。
2. 2. 阶段 1：Copier 或开源 Spec 工具链（管 变更与规格增量高频路径）。
3. 3. 阶段 2：多仓 + 存量 + 强治理时，再上 薄 CLI；IDE 插件只是 壳，尽量与模板 同版本。

阈值举例（可写进内部立项）：例如同时满足「≥10 个活跃服务仓要对齐」「存量仓多」「要 dry-run / 跳过 AGENTS / 审计」——再投 CLI，否则 模板 + Skill往往更划算。