夜雨聆风很多团队已经读过 Landing Zone：知道仓库里该有 AGENTS.md、该有 Spec 文档、该有门禁与治理红线。下一个在一线反复出现的问题是：「我们把要求写进 Confluence / 飞书、在启动会上讲清楚了，算不算已经落地了？」——算组织共识，但还不算工程落地。只要各服务仓里的 目录形状、Spec 表头、门禁命令仍靠「各组自己悟」，很快会出现：A 仓和 B 仓的 AGENTS 长得不一样、CI 与 markdown 各说各话、AI 换一仓就换一套习惯——评审痛苦，模型也容易「幻觉接口」。
1个场景(618促销)5种范式(Spec/Vibe/Glue/TDD/Harness) ，企业级AI Coding经验分享(附代码示例)
反常识，企业开发Spec Coding不如Vibe Coding代码惊艳，但Spec Coding才是精准“靶向药”（附G1～G6上下文阶梯图）
越早发现越便宜：企业级AI Coding的7道代码分层质量拦截防线
要把 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 脚手架
| Landing Zone | 脚手架（本文含义） | |
| 本质 | 组织里「AI 写代码」的 | 把规约 |
| 读者 | 全员共识 + 评审依据 | 工程效能 + 模板维护者 + 一线按清单执行 |
| 没有 Golden Template 时 | 仍然成立 | 仍存在，只是变成 |
四、最小落地应该长什么样
不必记章节号，记住 四件事进仓即可对齐多数讨论里的「最小一套」：
1. AGENTS.md：栈、目录、习惯、永久红线、本地/CI 验证命令。 2. spec-docs/里三份 P0 规格骨架：用户故事与验收（05）、接口（09）、数据模型（10）——先有结构与表头，再填业务事实。 3. Reference/：分层 每层一例「黄金片段」，约束 AI 别乱发明接口形状。 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 只在「多仓批量、存量安全合并、要强审计」时更值得投资。
| 手段 | 最擅长 | 不擅长 |
| Golden Template | 新仓 | 变量问答、老仓增量合并 |
| Copier / Cookiecutter | 多参数 | 组织治理若未跟上，易变成「个人模板集市」 |
| 自研薄 CLI | 批量、CI、存量安全补文件 | 建设与运维成本 |
| IDE Rules | 会话里自动带上 | 不能替代 |
| RepoWiki | 读代码 → 说明书 | 不能替代 |
| Skill | 高频多步任务 | 不等于文件系统批处理 |
| GlueKit 类工作台 | Proposal → Spec → 任务 | 不替代仓库内 |
逻辑提醒（也是原文档里容易被略读漏掉的一点）：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」。
| 类型 | 解决什么问题 | 示例 slug（完整表见方案 13.8） |
| 新仓接手 | 模板下来后 24h 内别空转 | landing-zone-repo-bootstrap-checklist |
| AGENTS 填全 | 占位符漏填导致 AI 乱改 | landing-zone-agents-placeholder-fill |
| Spec 三件套起笔 | 05/09/10 只有标题没有可测内容 | landing-zone-spec-05-first-us-ac |
| Reference 不跑偏 | 样例变「第二套业务」 | landing-zone-reference-shape-validate |
| 门禁与 CI 对齐 | markdown 与流水线各说各话 | landing-zone-ci-enable-and-align |
| RepoWiki 生命周期 | 扫一次就永远过期 | landing-zone-repowiki-refresh-sop |
| Rules 与 AGENTS 一致 | 双真源 | landing-zone-rules-agents-consistency-audit |
| Wiki / 仓内文档边界 | PM 与研发扯皮写哪 | landing-zone-hosted-wiki-vs-repo-doc-policy |
| MCP 与 hooks 治理 | 外联失控、本地钩子误伤 | landing-zone-mcp-inventory-and-fallback |
| 存量仓与合规模块 | 不敢补、或一补就覆盖红线 | landing-zone-stock-repo-handfill |
判断：对读者而言，「分类地图」比「20 行 slug 表」更易建立行动直觉；全表留给 Ctrl+F 与工程对接更合适。
九、建议演进顺序（与组织成熟度挂钩）
1. 阶段 0：Golden Template + 手工替换占位符（已能解决「多仓对齐形状」）。 2. 阶段 1：Copier 或开源 Spec 工具链（管 变更与规格增量高频路径）。 3. 阶段 2：多仓 + 存量 + 强治理时，再上 薄 CLI；IDE 插件只是 壳，尽量与模板 同版本。
阈值举例（可写进内部立项）：例如同时满足「≥10 个活跃服务仓要对齐」「存量仓多」「要 dry-run / 跳过 AGENTS / 审计」——再投 CLI，否则 模板 + Skill往往更划算。
关注公众号，一起探索企业级AI Coding！
