AI 时代，为什么全栈项目越来越离不开 Monorepo 和 TypeScript

Moment
0 阅读11分钟

大家好 👋，我是 Moment，目前正在使用 Next.js、NestJS、LangChain 开发 DocFlow。这是一个面向 AI 场景的协同文档平台，集成了基于 Tiptap 的富文本编辑、NestJS 后端服务、实时协作与智能化工作流等核心模块。

在这个项目的持续打磨过程中，我积累了不少实战经验，不只是 Tiptap 的深度定制、编辑器性能优化和协同方案设计，也包括前端工程化建设、React 源码理解以及复杂项目架构实践。

如果你对 AI 全栈开发、文档编辑器、前端工程化或者 React 源码相关内容感兴趣，欢迎添加我的微信 yunmz777 一起交流。觉得项目还不错的话，也欢迎给 DocFlow 点个 star ⭐

image.png

GitHub 2025 Octoverse 报告提到，2025 年 8 月 TypeScript 首次按 GitHub 贡献者数量超过 Python 和 JavaScript，成为 GitHub 上使用最多的语言。GitHub 也把这一变化放在 AI、agents、typed languages 正在推动软件开发十年来最大变化的背景下讨论。

20260424141910

State of JavaScript 2025 的结果也显示，TypeScript 的主导地位继续加强，40% 的受访者已经只写 TypeScript，而只写纯 JavaScript 的比例只有 6%。InfoQ 对该报告的解读也将其概括为 JavaScript 生态进入更稳定、更成熟的阶段，TypeScript 成为明确赢家。

这说明一个现实：

现在新全栈项目默认 TS，不是因为大家都喜欢写类型，而是因为整个生态都在向“类型化 JavaScript”迁移。

比如我正在做的 AI 全栈项目，技术栈就包括这些：

  • Next.js
  • NestJS、Fastify
  • LangChain.js
  • Vercel AI SDK
  • OpenAI Agents SDK TS
  • Drizzle
  • Zod
  • Tiptap
  • Yjs
  • BullMQ

这些技术天然更适合在 TypeScript 体系里组合。

AI 时代为什么更需要 TypeScript

因为 AI 生成代码有一个很大的问题：

它写得很快，但不一定写得对。

DORA 2025 关于 AI 辅助开发的报告提到，AI 已经不再是新奇工具，而是开发者工具箱里近乎普遍的组成部分。Google 的解读中也提到，AI 在软件开发专业人士中的采用率达到 90%，超过 80% 的受访者认为 AI 提升了生产力，59% 认为它对代码质量有正面影响。

但同一份报告也指出了信任悖论，只有 24% 的人对 AI 有较高信任，而 30% 的人只是一点点信任或完全不信任。DORA 还把 AI 定义成一种放大器，它会放大高效组织的优势，也会放大混乱组织的问题。

所以 AI 时代的关键不是：

让 AI 多写代码

而是：

让 AI 写出来的代码可验证、可回滚、可测试、可审查

TypeScript 在这里的作用就很明显了。

比如 AI 改了一个接口定义：

type CreateDocumentInput = {
  title: string;
  content: string;
  workspaceId: string;
};

但它在前端实际传的却是：

{
  name: "xxx",
  body: "xxx",
  spaceId: "xxx"
}

如果没有类型系统，这类问题通常要等到运行时才会暴露。

有 TypeScript 以后，编辑器、编译器和 CI 会提前把问题拦下来：

  • name 不存在
  • body 不存在
  • spaceId 不存在
  • 缺少 title
  • 缺少 content
  • 缺少 workspaceId

这就是 TypeScript 在 AI 时代的核心价值：

不是为了让人完全不犯错，而是为了让 AI 产生的错误更早暴露、更早修正。

为什么我在 AI 项目里更推荐 Monorepo

因为 AI Coding 工具越来越像代码库级别的 Agent。

OpenAI 在 2026 年 4 月发布的 Agents SDK 更新里提到，新能力可以让 agent 检查文件、运行命令、编辑代码，并在受控沙箱中执行长周期任务。

这意味着未来很多开发动作会变成这样：

人，帮我把文档权限模型从 owner、editor、viewer 改成 RBAC

AI，检查前端、后端、数据库 schema、测试、文档 AI，批量修改代码 AI，运行测试 AI，提交 patch 人，review

这种场景下，Monorepo 的优势会非常明显。

因为 AI 不需要在多个仓库之间来回切换上下文：

  • frontend repo
  • backend repo
  • shared-types repo
  • db repo
  • worker repo
  • docs repo

而是可以在一个 workspace 里看到完整系统：

  • apps/web
  • apps/api
  • apps/worker
  • packages/db
  • packages/contracts
  • packages/ui
  • packages/ai
  • packages/editor

这也是为什么 Nx 现在强调 AI velocity 和 workspace awareness。Nx 2025 总结里提到，AI 工具让开发者能写更多代码，但真正的问题是这些代码能不能顺利合并和部署。Nx 把构建系统、CI 编排和 AI 集成放到一起，目标是帮助团队以 AI 速度交付。

Nx 2025 年 10 月的更新还提到，新创建的 workspace 会自动包含 AI 配置文件，帮助 Cursor、Copilot 这类工具理解项目结构。

这点非常关键。

AI 时代的 Monorepo 不只是：

方便人类共享代码

而是：

  • 方便 AI 理解系统边界
  • 方便 AI 做跨模块修改
  • 方便 CI 验证 AI 修改是否破坏系统

Monorepo 的核心价值是一次改完整个系统

在 Monorepo 里，跨多个服务的重构可以收敛为一个 commit，生产者和消费者可以在同一个 PR 里同步修改，CI 也能直接验证整个系统，而不是让多个仓库之间异步猜测。

比如你要改一个文档权限字段：

role -> permission

如果是多仓库，通常要分别改这些地方：

  • 前端仓库
  • 后端仓库
  • SDK 仓库
  • 数据库迁移仓库
  • 文档仓库
  • Worker 仓库

每个仓库都发一个 PR，最后很容易出现这些错位：

  • 前端已经改了
  • 后端没发版
  • SDK 版本没升级
  • 数据库 migration 漏了
  • worker 还在读旧字段

Monorepo 的好处是，AI 或人可以一次性改完整条链路：

  • packages/db
  • packages/contracts
  • apps/api
  • apps/web
  • apps/worker
  • tests

然后通过一次 CI 完成系统级验证。

这在 AI Coding 时代尤其重要，因为 AI 最擅长做机械但跨文件的修改，而这类修改必须建立在完整上下文之上。

AI 框架正在向 TypeScript 应用层靠拢

做 AI 全栈项目这两年，我的体感越来越明确，主流框架正在向 TypeScript 应用层持续靠拢。

我们现在常用的几条技术路线基本都在强化这件事。

  • Vercel AI SDK 从一开始就把 TypeScript 作为核心定位，重点覆盖结构化输出、工具调用、Agent 以及前端 UI 集成
  • 新版本继续强调类型安全的流式交互和跨框架支持，落地体验明显比早期方案更完整
  • OpenAI Agents SDK 提供了 TypeScript 版本，能直接在我们熟悉的 Node.js 工程里搭建 agents、handoffs、guardrails、tracing 这套能力
  • LangChain.js 的官方学习路径也越来越完善，说明用 TypeScript 构建 agentic AI apps 已经进入稳定工程阶段

所以我的判断一直很清楚，不是 TypeScript 要取代 Python，而是两者在 AI 时代的分工越来越明确：

  • 训练、研究、数据科学，Python 依然强势
  • 产品化、Web 应用、Agent UI、工具调用、流式交互，TypeScript 越来越强

站在我们做产品交付的视角看，面向用户的 AI 应用层，TypeScript 正在成为主流选择。

AI 项目为什么特别适合 Monorepo + TypeScript

我做 AI 项目最大的感受是，这类系统看起来在写业务，实质上一直在维护契约。

它不是简单 CRUD，而是多条链路同时交换结构化数据。只要有一处定义不一致，问题就会在下游放大。

比如一个 Agent 项目里，至少会有这些核心结构：

type StreamEvent =
  | { type: "message.delta"; content: string }
  | { type: "tool.start"; toolName: string; input: unknown }
  | { type: "tool.end"; toolName: string; output: unknown }
  | { type: "agent.step"; stepId: string; status: "running" | "done" }
  | { type: "error"; message: string };

除了事件流，还会有工具定义：

type ToolDefinition = {
  name: string;
  description: string;
  inputSchema: unknown;
  execute: (input: unknown) => Promise<unknown>;
};

还会有结构化输出：

type RewriteResult = {
  patches: Array<{
    from: number;
    to: number;
    replacement: string;
    reason: string;
  }>;
};

还会有记忆系统：

type MemoryItem = {
  id: string;
  workspaceId: string;
  scope: "user" | "project" | "document";
  content: string;
  embeddingId?: string;
  createdAt: string;
};

如果这些定义散落在多个仓库里，团队很快就会出现这种割裂：

  • 前端一套 event type
  • 后端一套 event type
  • Agent 一套 tool schema
  • 数据库一套 memory schema
  • 日志系统又一套 trace schema

最后的结果通常不是功能不能跑，而是局部能跑、全链路不稳定，排查成本越来越高。

所以我现在更倾向于用 Monorepo + TypeScript，把契约抽到共享包里统一维护：

  • packages/contracts
  • packages/ai
  • packages/db
  • packages/editor
  • packages/observability

然后让所有应用都引用同一份规范：

import type { StreamEvent } from "@repo/contracts/stream";
import { CreateMemorySchema } from "@repo/contracts/memory";
import { documentTools } from "@repo/ai/tools";

这件事对 AI 项目尤其关键，因为 AI Agent 本质上就是在不同系统之间传递结构化信息：

  • 用户输入
  • 模型输出
  • 工具参数
  • 工具结果
  • 事件流
  • 数据库记录
  • 前端渲染状态
  • 日志 trace
  • 评测结果

在我们的工程里，TypeScript 的价值不是语法更优雅，而是把这些结构在编译期和协作期串成一条可验证的链路。

避免盲目上 Monorepo

我在项目里反复验证过一件事，Monorepo 本身不是问题，粗糙的 setup 才是问题来源。
如果边界没设计好、构建和发布策略没定清楚，团队后面基本都会一直打补丁。

所以我的判断很直接，不是所有全栈项目都必须上 Monorepo。前后端耦合很弱，或者一个框架就能承载主要需求时，Monorepo 反而可能是额外负担。

适合 Monorepo 的项目

  • Next.js + NestJS、Fastify 这类前后端分层架构
  • 有独立 API 服务
  • 有 Worker 或异步任务系统
  • 有共享类型或共享 UI 组件
  • 有 AI Agent、Tool、Workflow 这类跨模块能力
  • 有数据库 schema 和迁移管理
  • 有多端应用、CI/CD、多人协作

比如你的 DocFlow、AI 公众号创作平台、LogiX 这种项目，非常适合。

不适合 Monorepo 的项目

  • 只有一个小前端项目
  • 没有后端服务
  • 没有共享包和共享类型
  • 只是临时 demo 或短周期验证
  • 一个 Next.js 项目就能覆盖全部需求
  • 团队当前还不具备维护 workspace 的经验

小项目一上来搞复杂 Monorepo，反而会被配置拖死。

AI 时代真正的瓶颈是验证速度

我非常认同 DORA 的这份生成式 AI 研究 的核心结论，AI 的确在提升个人效率和体验，但如果团队没有快速反馈机制，代码写得越快，交付压力反而越大。

这份报告里有几个点和我们做工程时的体感高度一致：

  • AI 会提升个人生产力，但团队层面的交付吞吐和稳定性不一定同步变好
  • AI 让代码生成更快后，变更批次通常会变大，评审和回归验证的负担随之上升
  • 要让 AI 真正成为收益，而不是风险放大器，关键是自动化测试、快速评审和持续集成

这就解释了为什么 Monorepo + TS 变得更重要，就是因为AI 让我们：

  • 写代码更快
  • 生成文件更多
  • 跨模块修改更频繁

但我们真正需要的是：

  • 类型检查
  • schema 校验
  • 单元测试
  • 集成测试
  • E2E 测试
  • CI 依赖图
  • 增量构建
  • 可观测 trace
  • 代码审查

Monorepo + TypeScript 正好是承载这些验证机制的基础，所以 AI 时代的工程重点不是让 AI 多写一点代码，而是让 AI 生成的代码稳定进入一套可靠的验证系统。

总结

写到最后，我的结论其实很简单，在 AI 时代做全栈项目，Monorepo + TypeScript 不是跟风配置，而是工程确定性配置。AI 确实让我们写得更快，但速度本身并不等于可交付，真正决定上限的是系统能不能持续验证这些改动。

我会把 Monorepo 看成组织约束，把 TypeScript 看成类型约束，把 schema 看成运行时约束，再用 CI、测试和可观测性把这些约束串成闭环。这样做的意义不在于技术名词堆得多完整，而在于每次 AI 参与改动后，我们都能快速判断代码是否正确、是否可回滚、是否可以安全上线。

所以对我来说，这套组合之所以值得长期坚持，不是因为流行，而是因为它刚好解决了 AI 工程里最核心的问题，如何把更快的代码生产速度，转化为稳定、可信、可持续的交付能力。

avatar
文章
阅读
粉丝