人工智能代理时代的初创公司网页技术栈：Next.js、MUI和Firebase
适用于代码代理时代的初创公司网页技术栈：Next.js、MUI、Firebase、Vercel和PostHog，包含最简化的代理设置以及每项选择的理由。
来源: The Teach Stack for Building Full-Stack Apps in the AI-Agentic Era (2026 Edition)
当代码部分由机器生成时如何选择技术栈
Claude Code和Codex这类编程助手改变了软件的开发方式。迭代速度大大提升，但前提是代码必须具备足够的可维护性和扩展性，才能支撑项目的持续发展。
处于初创阶段的团队依赖快速的迭代速度。需求变化迅速，新功能每日都会添加，代码也需不断重写。在这种环境下，所选技术需能够支持快速变更，同时不会损害用户体验。
以下的技术栈是基于在真实学习平台上使用现代工具进行的约四年实验总结而成的。它涵盖了身份认证、用户界面、后端、托管、测试等多个方面，其核心目标是在仍可由人工维护的代码基础上实现快速开发，并拥有可扩展的基础设施。
保持助手与代码的简洁性
智能体让快速改进变得容易：漏洞修复、新功能以及性能优化都能迅速实现。它们还使得过度设计成为可能，因为添加数千行代码简直易如反掌。相应的准则是避免去解决尚不存在的问题，并保持代码、基础设施和用户体验的简洁性。
即便在当前智能体开发盛行的时代，简洁的配置依然很有帮助。智能体之间能更好地协同，功能能更快上线，漏洞也更容易修复，同时人们仍能维护现有系统。
在生产代码中使用智能体的方式是平衡的，配置也较为简单：
- 尽量保持
AGENTS.md或CLAUDE.md的内容简短。只需在其中列出每次对话都会重复的信息，以及智能体经常出错的与项目相关的细节。 - 过大的指令文件会降低模型的性能，使其作用大打折扣。
在MCP服务器上，PostHog能够方便地提供错误追踪和日志，从而加快调试速度。Context7则为模型提供最新的库文档，使智能体能够查阅各类库和框架的最新资料。大多数情况下，智能体无需MCP服务器的帮助就能解决问题，因此很少需要启用它。
一般原则是，每多一个工具、技能或服务器都会争夺模型的注意力。任何在当前任务中无法发挥作用的元素都最好被排除在外，而一旦出现只需一条指令就能解决的重复性错误，就可以重新调整配置。
前端：React 和 Next.js
在许多全栈项目的核心架构中，React 是首选。Vue 和 Svelte 也是可选方案，但 React 拥有庞大的库生态系统，使得添加功能及调整方向更为便捷，这也是开发者偏爱它的原因。
它的弱点在于搜索引擎。Google 和 Bing 使用的爬虫会读取页面的 HTML，而 React 页面通常从服务器返回的初始内容是一个空的 body。要想让网站出现在搜索结果中，服务器的首次响应就必须包含包含正确页面信息的 HTML。
Next.js可以处理这个问题。它是一个提供服务器端渲染和静态生成功能的React框架，页面首先在服务器端渲染，然后将HTML发送到浏览器，这样初始内容就包含了爬虫所需的信息。之后只有必要的JavaScript代码才会发送到客户端，从而保持代码包的大小较小。这既提升了用户体验，也有利于爬虫理解页面内容。
在Next.js项目中，当前的标准是app router，它使得增量静态重新生成和部分预渲染等功能更易于使用，进而让应用运行速度更快。新项目应从使用它开始。
React正在向服务器端发展，其理念在某种程度上越来越接近PHP，而app router为以服务器优先的组件提供了良好的开发者体验。缓存、Turbopack以及对爬虫友好的配置使得开发和迭代更加高效。
UI：基于自定义设计的组件库
传统的网页开发流程包括规划、UI/UX设计、实现，以及设计师与开发人员之间多次的反复沟通。初创公司无法承受如此漫长的周期。
最有效的方法是选择一个成熟的UI框架——本例中为MUI——并遵循相应的设计模板。另一种方式是让设计师在Figma中绘制所有元素，再由开发人员用React重新实现。通过在代码库中保持单一的真实数据源，可以节省数月的时间。
MUI提供了大量可定制的组件，能够满足常见需求。虽然所有内容都可以修改，但默认设置已经足够好，因此大多数组件都直接使用其默认的行为和外观。此外，它还附带了大量可作为React组件的图标，因此将其集成到项目中十分简单。
当然也有其他替代方案：
- shadcn/ui 是一款现代且流行的框架，不过有人认为通过 CLI 将其代码复制到自己的代码库中并非明智之举。
- Ant Design 也是一个不错的选择。
- Chakra UI 也属于 UI 框架范畴。
- HeroUI（原名 NextUI）同样表现不错。
有些人更喜欢 styled-components 或 Tailwind CSS。不过使用这两种工具时仍需编写大量 CSS 代码，从开发者体验角度来看，这不如使用 UI 框架，尤其是当目标是避免从零设计每个页面时。
若需灵感，模板库能提供帮助。MUI 自带的模板库中有许多精美的 UI 模板，Dribbble 上也有 React 模板。另一种方法是委托设计师制作多个原型并选出最佳方案，此外具备 UI/UX 技能还能提升设计质量。
表单
表单在全栈开发中占据重要地位。Zod与React Hook Form搭配使用几乎可以解决所有相关问题。Zod负责模式验证，包括类型、范围、长度和枚举等规则，而React Hook Form则提供了用于操作表单的灵活API。二者结合可实现共享同一表单的嵌套组件、复杂的验证逻辑以及数据的实时更新，使得表单处理变得异常简单。
由于验证模式是一个符合TypeScript规范的普通对象，相同的规则即可同时描述表单允许输入的内容以及后端函数期望接收的数据格式。这避免了界面允许的内容与服务器拒绝的内容之间的不一致问题，而且开发者读取模式的方式要比逐个查看处理函数中的验证逻辑可靠得多。
后端、身份认证与数据库
Firebase和Supabase提供后端即服务，可支撑数百万用户，且无需用户自行维护任何基础设施。该技术栈使用Firebase处理身份验证、存储功能，以及Firestore数据库和用于实现自定义后端逻辑的无服务器函数。
身份验证
Clerk是优秀的身份验证解决方案，但Firebase的默认系统在此场景下也已足够好用。Firebase还提供了一个名为firebaseui-web的包，无需编写任何UI代码即可实现身份验证功能。为确保其正常运行，Next.js应用还需部署在专用的身份验证子域名上，这样Firebase才能顺利处理登录流程。
数据库
在传统的架构中，前端与后端通过数据库相互分离，前端会发起大量API调用来修改数据库中的数据。在许多项目中，约80%的调用属于简单的CRUD操作，而剩下的20%则更为复杂，比如更新多条记录或从多个来源聚合数据。Firebase针对这80%的常见操作进行了优化，使得前端能够轻松操作数据，无需额外的接口。
有两个组件实现了这一功能。
- Firestore规则。访问控制与权限设置都集中在一个文件
firestore.rules中。由于Firebase会自动验证用户是否有权读取某条数据或对其进行创建、更新、删除操作，因此API接口无需在每个函数中都进行权限检查。这种分离大大减少了冗余代码。 - Firestore 客户端 SDK。数据的创建、读取、更新和删除均通过 Firebase SDK 完成，该 SDK 还支持实时监听、计数器递增和批量更新功能，所有操作都会自动与
firestore.rules规则进行比对。
不过有一个需要注意的地方，那就是数据存储的思维模式。Firestore 是为读取操作优化的，而读取操作通常占主导地位，因此它倾向于使用非规范化数据结构。对于有 SQL 开发经验的人来说，这可能会显得不太自然，因此值得一看关于 Firestore 数据建模的优质演讲。
总体而言，Firestore 能够提供出色的用户体验，尤其是通过实时变更监听功能，同时还具备良好的开发者体验，使应用程序能够快速适应不断变化的需求。
新项目最好在 Firestore 的企业版原生模式下启动。该版本支持旧版标准版所没有的功能，比如管道查询和内置的全文搜索，既能带来类似 MongoDB 的数据库灵活性，又具备 Firestore 的易用性。
无服务器函数
客户端代码被刻意设计得较为简单，相关逻辑都集中在无服务器函数中的后端代码里。保持前端简单、后端强大这一架构非常有效。Firebase Functions 可以容纳任何后端代码，它们可以通过普通 HTTP 请求、Firestore 数据的创建或更新来触发，也可以通过 Pub/Sub 以定时任务的形式运行。这样一来，所有的服务器端功能都可以存在于独立的、自包含的函数中。
像 Firebase 这样的 BaaS 工具能节省大量时间，且几乎无需额外调试。因数据库异常或迁移失败而导致的调试问题十分罕见。
AI 功能
AI 是现代网页应用的重要组成部分，许多产品都集成了聊天机器人和智能代理。Vercel 的 AI SDK 可以与不同的模型提供商集成，并用于创建自定义智能代理。它的优势在于能够轻松接入各种模型并在它们之间切换，为开发者带来的体验比任何特定模型的 SDK 都更为便捷。
测试
测试可能是最具争议的话题，尤其是对于那些需求不断变化的初创公司。早期根本不存在测试机制。随着产品的发展，要放心修改现有代码同时确保系统仍能正常运行几乎变得不可能，因此人们开始为后端，尤其是 Firebase Functions 的服务层引入测试。前端因为被设计得较为简单而无需测试，而复杂的后端则需要针对各种边界情况接受测试。
后端测试使用 Jest，并通过 faker.js 在测试中生成虚拟数据。这些测试在独立的 Firebase 项目上运行，从而不会影响到生产环境，同时也便于快速迭代而不必担心会影响用户。一旦测试通过，新的 Functions 版本就会部署到生产环境。
仅测试后端的原因是成本考虑。仅负责显示数据和调用函数的前端几乎没有值得验证的逻辑，而且每当设计发生变化——在产品初期这种情况极为频繁——UI测试就很容易出问题。而后端逻辑则可能存在隐蔽的回归错误，导致数据被破坏或用户被错误收费，因此才需要投入更多精力进行测试。
代码重构
随着项目的发展、功能的变化、需求的调整以及系统老化，代码重构变得不可避免。有两样东西最有助于让人有信心地修改代码：TypeScript和完善的集成测试。TypeScript能在代码变更后保证类型安全，而集成测试则能确认逻辑依然正常运行。
代码重构的出现频率比预期要高。由于平台持续变化，采用新技术往往意味着大规模的代码修改，因此几乎不存在六个月没有进行重大重构的情况。最重要的两个里程碑分别是从纯React转向Next.js，然后再从Next.js的pages路由器转向app路由器。
托管
后端完全基于Firebase（Google Cloud）构建，而前端则部署在Vercel上，后者为部署Next.js提供了最便捷的基础设施。其与GitHub的集成功能完善，可很好地处理分支管理，且无需手动设置：
- 将代码推送到
main分支后，会自动部署到生产环境。 - 将代码推送到其他任何分支时，都会生成一个带有专属链接的预览版本，这样就可以实时查看每个分支的运行状态，从而快速便捷地进行迭代。
审查变更意味着只需打开链接，而无需拉取分支并在本地运行，这非常适合那些设计师、产品经理和工程师都希望无需在各自机器上做任何设置就能查看进展的小团队。
分析与监控
了解用户是谁以及他们如何使用产品非常有价值。通过指出哪些内容需要优先处理，可以节省数周甚至数月的开发时间；而良好的监控机制能够通过发现常见错误来提升用户体验。
PostHog可提供常规分析及产品监控功能，包括会话回放、异常捕获、日志记录以及生产环境源码映射。Firebase的Google Analytics是一个免费的替代方案，但需要更多配置；Sentry则价格稍高一些。这些工具都有助于了解用户，但都无法替代与用户直接沟通。
电子邮件
电子邮件依然是与用户保持联系、发送更新并维持其参与度的最可靠方式之一。该系统最近已从 Sendgrid 更改为 react-email，同时搭配使用 Resend。
react-email 能将每封邮件转化为 React 组件，从而实现高度定制化的邮件功能。Resend 与它兼容性良好，且定价合理。由于邮件属于 React 组件，因此会与其余代码一起进行版本控制，所有更改都会被记录在同一个地方。
预览和测试模板也非常方便，因为在开发过程中相同的组件会在浏览器中渲染，并生成最终发送到用户收件箱的 HTML 内容。
相关阅读
- 使用 Ollama 和 LangChain 在本地 LLM 上运行的 QuickBooks 财务智能体 — 基于 Qwen 3.5 9B 模型与 RTX 4070 显卡的 ReAct 智能体，可无需使用云端服务即可读取 QuickBooks 的实时数据。查看相关代码、输出结果以及已知限制。
- 设计多智能体求职系统：流程、HyDE 工具与可观测性 — 一种包含九个步骤的 LangGraph 流程，用于将简历与职位匹配，同时涉及 HyDE 工具、模型路由、速率限制及追踪功能等方面的八项设计选择。