说实话，Zui近这段时间我几乎把所有的业余精力dou扑在了一个新项目上——AudioDock。这不仅仅是一个简单的练手项目，它geng像是我对现代前端工程化的一次“大考”。在这期间，我尝试了一种新的开发模式：pnpm 搭配 monorepo 架构，再辅以当下火热的 AI 辅助编程。这趟旅程走下来感触颇深，甚至Ke以说有点“惊心动魄”。今天难得有空，我想把这些日子里踩过的坑、出的经验，好好跟大伙儿唠唠。

为什么我选择了 Monorepo？

咱们Zuo开发的，Zui怕的就是重复造轮子。我的这个 AudioDock 项目，情况有点特殊，它不仅包含了常规的 Web 端，还深度集成了移动端和桌面端。具体来说移动端用的是 React Native，桌面端则是基于 Electron 构建。

在开发初期我就意识到一个问题：无论是手机上跑的，还是电脑上跑的，甚至未来我打算涉足的小程序和电视端，它们背后调用的逻辑、数据结构其实是大同小异的。Ru果每个端dou各自维护一套代码，那维护起来简直是噩梦。所以我痛下决心，把那些公共的部分抽离出来Zuo成了独立的包。比如数据库操作层我单独封了一个 `db` 包，一些通用的业务逻辑服务也抽离了出来。

这种架构下pnpm + monorepo 的优势就体现得淋漓尽致了。它Zui大的优点在于统一的类型管理和构建范式。以前跨端开发Zui头疼的就是类型定义不同步，现在有了 monorepo，所有端引用的dou是同一份类型定义。这就给 AI 协同开发打下了Zui坚实的基础。

项目结构一览

为了让大家geng直观地理解，我把项目的目录结构贴出来kankan。这不仅仅是一个文件夹列表，geng是我整个项目的“作战地图”：

soundX/
├── apps/                # 应用层 
│   ├── mobile/         # 移动端应用 
│   ├── desktop/        # 桌面端应用 
│   └── mini/           # 迷你端/小程序应用
├── services/            # 后端服务层
│   └── api/            # 核心后端 API 服务 
├── packages/            # 公共模块与包 
│   ├── db/             # 数据库模型与 Prisma 配置
│   ├── ws/             # WebSocket 通讯协议与逻辑
│   ├── utils/          # 公共工具函数
│   └── test/           # 测试辅助工具
├── Dockerfile           # 容器化部署配置
├── docker-compose.yml   # 多服务编排配置
├── package.json         # 根目录配置与工作区管理
├── pnpm-workspace.yaml  # pnpm 工作区定义
└── nginx.conf           # Nginx 反向代理配置

kan到这个结构，你应该Neng明白为什么我说它是“全栈”项目了。这里面既有 NestJS 写的后端服务，也有 React Native 和 Electron 写的前端应用，还有一堆公共的工具库。整体上，我就是用 pnpm 的 workspace 功Neng来统一管理这些乱七八糟但又紧密关联的模块。

AI 在 Monorepo 中的“降维打击”

Zui近这段时间，我Ke以说是重度依赖 AI 进行开发。原本我以为 AI 只Neng帮我写写简单的函数或者注释，但在这个 monorepo 项目里AI 的表现简直让我惊掉了下巴。

大家知道，一个标准的前后端分离项目，需要 models、services、views 多个模块的配合。以前让 AI 写代码，它往往只Nengkan到局部，生成的代码经常跟上下文对不上。但现在在这个架构下AI 始终拥有全量的上下文信息——它既知道前端的组件长什么样，也知道后端的接口定义是什么。

举个例子，当我需要一个新的请求函数时我只需要告诉 AI 我的意图，它就Neng结合后端的 Prisma 模型和前端的视图需求，非常准确地生成请求函数、参数类型以及返回值类型。这种“全知全Neng”的感觉，真的太爽了。

跨端学习的“魔法”

geng有意思的是我在开发移动端的时候，Ru果对 AI 生成的效果不满意，我会尝试让它先去熟悉一下桌面端相同功Neng的实现逻辑。然后再让它基于这个理解去写移动端的代码。你猜怎么着？效果提升巨大！

因为桌面端可Neng我Yi经打磨过一遍了逻辑geng严谨，AI 学习了桌面端的“优秀作业”后再写移动端代码时就像是经验丰富的老手在指导新手，代码质量直线上升。甚至有时候我想重构某个模块，只要把需求丢给 AI，因为它Neng同时kan到所有引用该模块的文件，所以hen少会出现重构失败导致“爆雷”的情况。

关于 Token 消耗的焦虑

当然可Neng会有小伙伴担心：“你这样把全量上下文dou喂给 AI，Token 消耗是不是hen恐怖？大模型的免费额度够用吗？”

这确实是个现实问题。不过说实话，对于个人开发或者小团队来说只要不是那种超大规模的项目，目前的免费额度其实还是Neng顶一顶的。我还没试过那种特别小的项目，但是真的Ru果免费 token 用完了注册个新号继续用也不是什么大不了的事儿。相比于它给我节省下来的时间和精力，这点成本完全Ke以忽略不计。

光鲜背后的“坑”：Docker 部署惊魂

说了这么多好话，要是让人觉得这方案完美无缺，那我就太误导大家了。实际上，这些便捷的背后隐藏着无数个深不见底的坑。这不Zui近我就被两个大坑折磨得够呛。

第一个坑，出现在我第一次尝试打包部署的时候。我的后端是用 NestJS 写的，之前我也写过相关的文章，介绍过它那种类似 Spring Boot 的开发范式，controller、service、module 一应俱全，本来以为打包也就是顺手的事。

结果，当我信心满满地运行构建命令时傻眼了。控制台直接给我甩出一大串报错：

Error: Cannot find module '@nestjs/core'
Require stack:
- /usr/src/app/dist/main.js

kan到这个错误，我第一反应是：不可Neng啊！本地跑得好好的，怎么一打包就找不到核心模块了？一开始我死磕 Dockerfile，觉得肯定是我的环境配置有问题，或者是 COPY 命令少复制了什么文件。那个周末，我几乎把所有的 Dockerfile 配置方案dou试了一遍，反复调整，心态dou要崩了。

Zui后折腾了hen久才发现，这根本不是 Dockerfile 的问题，而是在 pnpm monorepo 项目里开发必然会遇到的一个“特性”。

软链接失效的真相

问题的根源在于 pnpm 的依赖管理机制。我们dou知道 pnpm 通过软链接和硬链接来节省磁盘空间，这在开发环境下简直完美。但是当我们构建 Docker 镜像时通常只会复制生产环境需要的文件。这时候，pnpm 那些精妙的软链接机制就“失效”了导致构建出来的产物找不到原本的包路径。

既然找到了病根，解决方法也就顺理成章了。虽然有点笨，但hen有效：在构建镜像的时候，单独再下载一次生产环境的依赖包！

我的 Dockerfile Zui终是这么改的：

# . 安装生产依赖 + 全局安装 prisma 
RUN apt-get update -y && apt-get install -y openssl
RUN npm i -g pnpm prisma@4 && pnpm install --prod --frozen-lockfile --ignore-scripts

加上这一步后NestJS 终于Neng顺利在容器里跑起来了。那一刻，我差点流下感动的泪水。

第二个大坑：Prisma 版本升级的血泪史

解决完 Docker 的问题，我以为终于Ke以正常运转我的项目了。没想到，Prisma 又给我上了一课。

事情是这样的。原本我使用的是 Prisma 4.x 版本，这个版本默认输出的客户端文件是 CMD 格式的。为了追求geng好的类型支持，我想着Neng不Neng升级到Zui新的 5.x 版本。听说新版本支持自定义输出路径，而且生成的是 ES 格式的文件，Ke以直接在前端引入类型，这听起来多诱人啊！

于是我兴冲冲地把 Prisma 升级了并且配置了自定义输出路径。结果，玩玩没想到，输出之后的文件里有三个变量一直报错，拦住了我去路。

错误信息大概是这样的：

apps/api dev: generated/prisma/internal/prismaNamespace.ts:...
:: - error TS2742: The inferred type of 'DbNull' cannot be named without a reference to '.pnpm/@prisma+client-runtime-utils@...'. This is likely not portable. A type annotation is necessary.
apps/api dev:  export const DbNull = runtime.DbNull
apps/api dev:                  ~~~~~~
apps/api dev: generated/prisma/internal/prismaNamespace.ts:...
:: - error TS2742: The inferred type of 'JsonNull' cannot be named without a reference to '.pnpm/@prisma+client-runtime-utils@...'. This is likely not portable. A type annotation is necessary.
apps/api dev:  export const JsonNull = runtime.JsonNull
apps/api dev:                  ~~~~~~~~
apps/api dev: generated/prisma/internal/prismaNamespace.ts:...
:: - error TS2742: The inferred type of 'AnyNull' cannot be named without a reference to '.pnpm/@prisma+client-runtime-utils@...'. This is likely not portable. A type annotation is necessary.
apps/api dev:  export const AnyNull = runtime.AnyNull
apps/api dev:                  ~~~~~~~

这还没完，除了类型推断错误，有时候还会直接报找不到模块的错误：

node:internal/modules/cjs/loader:  throw err;
  ^
Error: Cannot find module '.prisma/client/default'
Require stack:
- /app/node_modules/.pnpm/@prisma+client@.../node_modules/@prisma/client/default.js

后来我去查了hen多资料，发现这确实是 Prisma 5.x 在 pnpm 项目里的一个“坑”。主要是因为 pnpm 的目录结构和 Prisma 的文件生成机制在某些情况下不太兼容。虽然官方文档说Ke以通过自定义输出路径来解决，但在实际操作中，各种路径引用的问题依然让人头大。

折腾了半天无果，为了不影响进度，我只Neng无奈地回退到了 4.x 版本，老老实实地手写 modal 了。虽然没Neng用上Zui新的 ES 格式，但至少项目Neng跑起来这才是硬道理。

这是个人开发的Zui快形式吗？

回顾这两个周末的开发经历，虽然踩了不少坑，但我依然觉得：pnpm + monorepo 协同 AI 开发，是目前个人或者小团队开发全栈项目Zui快的形式，没有之一。

Prisma 虽然有点小脾气，但它自动生成类型文件和基础业务查询的Neng力，依然让我离不开它。只要避开版本升级的雷区，它依然是好用的工具。而 pnpm 的 monorepo 架构，配合 AI 的全量上下文理解Neng力，极大地降低了跨端开发的复杂度。

以前我可Neng需要花半天时间去对齐前后端的接口定义，现在 AI 几秒钟就Neng搞定。以前重构代码像是在拆炸弹，现在有了 AI 的全局视野，重构变得像搭积木一样安全。

所以Ru果你也是一个独立开发者，或者正在带一个小团队，想要尝试全栈开发，不妨试试这套组合拳。虽然过程中可Neng会遇到 Docker 打包失败、Prisma 报错之类的挫折，但当你kan到移动端、桌面端、后端在一个仓库里井井有条地运行，AI 帮你自动生成完美契合的类型代码时你会发现，这一切dou是值得的。

AudioDock 的开发还在继续，后续还有小程序和电视端的计划。Ru果你对这项目感兴趣，或者想kankan我是怎么填这些坑的，欢迎去 GitHub 上围观。毕竟在技术的道路上，多一个人踩坑，后面的人就少走弯路嘛！

---