2026-07-26-简谈前端基建标准与落地

为什么要做统一的工程基建标准#

在一个有多条业务线、多个团队并行开发的组织里,前端工程最容易出现的问题不是某项技术本身不好,而是"各用各的"。目录结构五花八门,技术栈各自为政,构建工具、发布流程、代码规范互不相同,结果就是协作成本高、维护困难,新项目每次都要从零趟一遍配置的坑。制定一套统一的工程基建标准,正是为了系统性地解决这类问题。

统一带来的价值可以从几个层面来看。首先是对 AI 更友好——当目录结构、技术栈、代码规范和约束规则趋于一致时,AI 更容易理解项目上下文,代码生成的准确率与可维护性都会随之提升,这在当下的研发环境中越来越重要。其次是协作效率的提升,统一的开发规范、组件标准与提交流程能够降低沟通成本,减少多人协作中的认知差异。再次是研发效率,统一的脚手架、构建工具与 CI/CD 流程减少了重复配置和环境问题,让需求交付更快。与此同时,通过统一依赖治理、测试规范与工程约束,可以有效遏制项目长期演进中的代码腐化,降低技术债务;而新项目也能直接复用成熟模板与最佳实践,把初始化成本降到最低。

怎样判断一套标准做得好不好#

标准本身也需要被评价。一套好的工程基建标准,大体要在三个阶段满足不同维度的要求。

标准制定阶段,它应当足够统一,能够收敛技术栈、减少碎片化;方案应当保持先进性,跟随业界最佳实践和公司基建的演进;选型要考虑 AI 协作的友好度;同时还要兼顾通用性与定制性,避免"一刀切"——既照顾不同业务之间的共性,为特殊业务留出可定制的空间。

标准落地阶段,可落地性是前提,能落地的标准才有意义,这就需要权衡落地的投入产出比并逐步提升覆盖率;落地效果要可观测,有量化指标可以衡量;并且标准要能随业务和技术的发展持续迭代。

价值论证阶段,标准最终要能体现出研发效率的提升、质量管控能力的增强,以及一线开发同学开发体验的改善。

用分级的方式管理选型#

要让一份庞杂的选型清单真正可执行,关键在于给每一项选型标注清晰的等级,而不是简单地"推荐"或"不推荐"。这份标准把选型分成了四个等级。推荐选型是最优先使用的方案,当所有项目都采用推荐选型时,基建就能达到完全一致;可选选型用于业界或团队尚无唯一定论、或需要按场景灵活选择的情况;建议迁移指那些使用上没有重大风险、但已不是最优、建议在中短期内迁移的方案;禁止使用则针对已停止维护、或存在重大风险的旧选型,应当尽快升级。

以 UI 框架为例,推荐选型是 React 19,React 18 作为可选选型,React 17 及更早版本以及 React 之外的任何 UI 框架则被列为禁止使用。基于这套分级,又可以定义两档准入标准:宽松标准允许推荐、可选和建议迁移三类,只排除禁止使用;严格标准则进一步收紧,只允许推荐和可选两类。这样一来,不同成熟度的项目可以按自身情况选择对应的准入门槛。

前端技术选型的原则#

具体到每一项技术怎么选,背后其实有一以贯之的原则。技术选型首先要匹配业务,因为技术终究是为业务服务的;要优先选择生态成熟、有完备配套的方案,避免重复造轮子;要看重长期稳定性,尽量选经过生产验证、仍处于维护状态的技术;在 AI 时代,是否易于 AI 生成代码也成了一个不可忽视的维度;在其他条件相近时,优先选择团队成员已经熟悉的技术栈;最后,选型不是一锤子买卖,需要定期 review、及时更新,以免积累新的技术债务。

在这些原则的指导下,几个关键领域的选型思路大致如下。

UI 框架统一收敛到 React,并推荐升级到已发布稳定版的 React 19;考虑到部分存量业务依赖的组件库尚不支持 React 19、升级收益需要论证、以及风险控制等现实障碍,React 18 暂列为可选,待跑通若干正向案例、解决障碍之后再大规模推广。

状态管理方面,业界和公司都没有唯一答案,因此建议按业务场景选择——小型项目可直接用原生 hooks,轻量场景首选市场份额最高的 Zustand,数据驱动的场景适合 MobX,追求高性能可选 Jotai,大型项目则适合 Redux。

样式方案同样强调按场景选型,原生 CSS 与 Tailwind 作为推荐,Sass/Less 适合深度定制主题,CSS Modules 是解决命名冲突的高性价比方案,CSS-in-JS 更适合组件库项目。

工具层面的选型则更看重协作与一致性。

包管理推荐 pnpm,它凭借硬链接加符号链接复用依赖,在安装速度、磁盘占用和依赖隔离上优势明显,也天然适合 monorepo 项目。

构建工具推荐使用 Rust 实现、对 Webpack 高度兼容且速度大幅领先的 Rspack,并围绕它形成一整套高性能工具链——库开发用 Rslib,单元测试用兼容 Jest 的 Rstest,构建诊断用 Rsdoctor,整体保持在同一技术体系内以获得最好的协同效果。

代码规范上,新兴的 Biome 增长快、对 AI 友好、性能好,是推荐方向,而 ESLint 加 Prettier 加 Stylelint 的经典组合虽然是事实标准、生态最繁荣,但配置复杂、性能偏弱,作为可选保留。 此外,通用工具库推荐支持 Tree-shaking 的 lodash-es,时间库推荐用 day.js 替代已停止维护的 moment,hooks 库推荐 ahooks。

基建平台的选择#

相比技术选型和工具选型需要反复权衡,基建平台这一层通常已经比较收敛,或者优势足够明显,因此往往不需要做详尽的对比分析,而是直接沿用组织内成熟的平台能力。从需求管理、研发流程、代码仓库,到质量门禁、真机测试、视觉检测,再到构建、部署、云平台、内容分发与负载均衡,以及上线之后的前端监控、Node 监控、服务监控、用户行为分析、实验平台和配置中心,这些环节都有对应的成熟平台承接。把平台层固化下来,好处是让团队可以把精力集中在真正需要判断的技术选型与工具选型上,而不必在基础设施上反复纠结。

如何落地 AI 友好建设#

所谓 AI 友好，说到底就是让 AI「能读懂、能生成、能调试」—— 如果 AI 看不懂你的代码结构，推断不出模块之间的约定，那它生成的东西就只能靠猜，幻觉和返工也就随之而来。

这里可以回顾一下编程语言演进的脉络：最早的汇编对硬件友好，每一行都是对寄存器和内存的直接操作；后来的高级语言转向对人友好，贴合人类的思维习惯、便于阅读和长期维护；而当 Copilot、Vibe Coding、Spec Coding 这类协作模式出现之后，我们对代码的期待又多了一层 —— 它要同时对人和 AI 都友好。AI 友好建设，本质上就是在既有工程体系上，补齐面向 AI 这一「新读者」的那部分能力，它至少覆盖技术选型、前端基建、前端架构三个层面，落地时也应当沿着这三条线分别推进。

在技术选型这一层，落地的核心是「消除模糊」。AI 之所以会产生幻觉，很大程度上是因为代码里存在太多隐式约定和不确定的边界，所以选型时应优先向强类型、约束明确的方向靠拢 —— 用 TypeScript 而非弱类型方案，让类型信息成为 AI 推断的锚点，能显著减少它自由发挥的空间。生态成熟度同样关键，像 React 这样训练数据充足的框架，AI 对它的掌握程度远高于小众技术，生成和修改的准确率自然更高。除此之外，还要注意选型在团队内部的一致性，统一的技术栈能让 AI 方案在大团队里复用而不必反复适配；要选择原生支持流式渲染、向量搜索、RAG 这类 AI 应用能力的框架，比如具备 RSC、Streaming、Partial Pre-Rendering 能力的 Next.js; 也要在异步状态管理和数据获取上选用对 AI 协作友好的方案，例如用 TanStack Query 处理带延迟和重试的流式响应，用 Zustand 这类 API 简洁、支持细粒度订阅的状态库，而非结构冗长、AI 适配成本偏高的 Redux。要把「保持简洁、约束明确」当成第一性原则。

AI 友好基建的目标，是让 AI 能「看懂系统、介入全流程、稳定产出、持续进化」。要做到这一点，需要沿着研发链路逐个环节地铺设 AI 能力。需求沟通阶段，可以借助知识库沉淀领域上下文帮助 AI 理解需求，用会议纪要自动总结把讨论结论结构化留存；技术方案阶段，可以用把代码转成文档的工具 (如 DeepWiki ) 帮助人和 AI 快速建立对存量代码的理解。代码开发阶段，则要集成主流的 AI 编码工具，并为它们配上清晰的工程规则 —— 无论是 Claude Code 的 CLAUDE.md、Cursor rules 还是各类 rules 文件，本质上都是把团队的隐性规范显式地写给 AI 看；同时接入常用的 MCP 服务 (Figma MCP、文档系统 RAAS MCP), 用明确统一的 lint 规则约束 AI 产出的代码风格。质量保障环节可以引入 AI 生成测试用例和单元测试的能力，端到端测试也已经有像 Playwright Test Agents 这样能自动生成 E2E 代码的方案，再叠加自动化的代码 review, 就能在产出侧形成一道 AI 参与的质量防线。最后在部署运维阶段，让 AI 承担智能发布 (自动检测指标，无异常自动流转、有问题再人工介入)、智能排查故障和过滤告警噪音的工作，研发全流程的智能化闭环也就基本成型了。

真正的深水区在架构层。模块之间强耦合、大量约定停留在口头或滞后的文档里，巨型组件和缺失的上下文让 AI 难以推理，规范无法被机器读取时 AI 就只能自由发挥甚至凭空杜撰。解决方案是让架构设计围绕四条原则展开 —— 可协作、可约束、可理解、可组合。

一套 AI 友好的架构大致可以拆成四层：最上面是 AI 协作层，同时支持 Prompt、Copilot、Agent 等多种协作方式，并为未来的协作形态预留扩展空间；其下是规范约束层，通过 Schema、Lint、DSL 对 AI 形成强约束，把「自由发挥」收敛成「安全发挥」; 再往下是业务表达层，通过领域分层做业务拆解，用 Domain Model 表达业务模型、View Model 表达视图模型，让边界清晰、职责单一，AI 得以快速推断；最底层是基础能力层，把 UI、hooks 等能力原子化沉淀下来，供 AI 自由组合和搭建。四层从上到下处理「如何协作、如何约束、如何理解、如何复用」四个问题，让整套架构在 AI 眼中变得可读、可控、可扩展。

另外，AI 时代并不存在唯一正确的技术选型或架构范式，不同公司、业务和团队都会有各自的取舍。上面这些做法更像是一套「抛砖引玉」的实践框架：先从选型这类成本最低、见效最快的地方入手，再逐步向基建和架构这两个投入更大、但收益也更持久的方向推进。代码库本身对 AI 友好之后，AI才能读懂系统意图、稳定产出，这也正是我们做 AI 友好建设的最终目的。

ED#

工程基建标准的价值,在于用分级、准入和持续迭代的机制,把"混乱的多样性"收敛成"有序的一致性",同时又为特殊场景保留必要的弹性。最终这些落地为一套关于如何在效率、质量与体验之间取得平衡的方法论。标准会随业务和技术不断演进,但"为什么统一、如何评价、按什么原则选型"这几个问题的思考方式,是可以长期沿用的。