沉淀脚手架与工程平台

本阶段目标

把已经在多个项目中验证过的工程路径沉淀为脚手架、共享包或内部 CLI。自动化的目标是减少等待、重复劳动和认知负担，而不是隐藏所有底层机制。

先找真实摩擦

在自动化之前记录基线：

• 新成员首次成功启动需要多久
• 新项目从创建到首个预览环境需要多少人工步骤
• 哪些配置最常漂移或复制错误
• CI 最慢、最不稳定的环节是什么
• 发布和排障依赖哪些少数人的记忆

优先处理高频、规则明确且失败成本高的步骤。很少发生的复杂决策通常更适合文档和检查清单。

设计最小 CLI

可以从三个命令开始：

frontend create   创建使用当前模板的新项目
frontend doctor   检查运行时、依赖、凭证和网络
frontend migrate  执行可预览、可回滚的配置升级

命令应具备帮助信息、非交互模式、稳定退出码、结构化输出和 --dry-run。模板必须版本化；生成项目后，还要有升级路径，而不是永久复制创建时的旧配置。

平台边界

平台提供推荐默认路径，同时允许团队在说明责任后退出。不要把所有工具页面聚合到一个门户就称为研发平台；真正价值应体现在更短的反馈时间、更低的失败率和更少的手工交接。

故障演练

1. 在缺少依赖或凭证时运行 doctor，确认输出指出原因和下一步。
2. 对已有手工修改的项目运行迁移，验证冲突不会静默覆盖用户代码。
3. 使用旧模板创建项目，演练升级到当前基线。

最终验收

• 新成员能仅依赖公开文档完成环境准备和首次构建
• 新项目自动接入质量检查、预览部署和监控基线
• 模板、共享配置和 CLI 都有版本及兼容策略
• 迁移支持预览、幂等执行和失败回滚
• 度量关注系统瓶颈，不用于直接评价个人
• 自动化上线后能证明至少一项交付指标得到改善

回到：前端工程化阅读地图。