使用 Codex 修改普通单体项目时，通常比较容易确认：

代码在哪个目录，命令从哪里执行。

但到了 Monorepo 项目，情况会复杂很多。

一个仓库里可能同时存在：

• 多个前端应用；

• 多个后端服务；

• 公共组件包；

• 工具包；

• 配置包；

• 测试包。

这时候就容易出现一种情况：

Codex明明完成了修改，但改的是另一个Package。

或者代码改对了，命令却在错误目录执行，最后得到完全不同的结果。

---

一、Monorepo为什么更容易让AI判断错位置？

普通项目可能只有：

src/
tests/
package.json

而Monorepo可能是：

apps/
  web/
  admin/

packages/
  ui/
  utils/
  api/

package.json

甚至多个目录里都有：

Button.tsx
config.ts
utils.ts

如果任务只说：

修改Button组件。

Codex就必须先判断：

到底是哪一个Button？

如果上下文不够明确，就可能进入错误Package。

---

二、先确认目标Workspace

开始修改之前，可以先让 Codex 明确：

目标应用：
apps/web

目标Package：
packages/ui

工作目录：
仓库根目录

如果使用 npm、pnpm 或 Yarn Workspace，也最好确认项目实际采用哪一种。

例如：

pnpm-workspace.yaml

通常说明项目使用 pnpm workspace。

而：

workspaces

也可能直接定义在根目录的 package.json 中。

先弄清Workspace结构，比直接开始改代码更稳。

---

三、为什么同名文件特别容易造成误改？

例如项目里存在：

apps/web/src/config.ts
apps/admin/src/config.ts
packages/core/src/config.ts

如果Codex只搜索：

config.ts

会得到多个结果。

这时候不能只看文件名。

还需要结合：

• 当前任务属于哪个应用；

• 哪个Package真正被调用；

• import路径指向哪里。

所以大型Monorepo里，最好确认：

完整路径，而不是只确认文件名称。

---

四、根目录执行命令和子包执行可能完全不同

例如：

npm test

在仓库根目录执行，可能运行所有Workspace测试。

但进入：

apps/web

以后再运行：

npm test

可能只测试当前应用。

有些Monorepo甚至要求：

pnpm --filter web test

如果Codex在错误目录执行命令，就可能出现：

• 找不到脚本；

• 找不到依赖；

• 测试范围错误；

• 构建了错误Package。

所以命令失败时，先不要马上修改代码。

先确认：

命令应该在哪个Workspace执行。

---

五、依赖可能来自另一个Package

例如：

apps/web

依赖：

packages/ui

页面报错时，问题可能并不在 apps/web。

真正需要修改的是：

packages/ui

如果AI只根据错误页面的位置判断，就可能直接在应用层做补丁。

最后形成：

真正问题还在公共包
+
业务层又多了一层临时兼容

所以Monorepo排查时要继续看：

这个模块到底来自哪里。

---

六、可以通过依赖关系确认修改范围

例如：

apps/web
↓
packages/ui
↓
packages/utils

如果修改 packages/utils，影响范围可能比修改 apps/web 大很多。

因为其他应用也可能依赖：

packages/utils

所以公共Package修改以后，不能只验证当前任务。

还应该检查：

还有哪些Workspace依赖它。

这也是Monorepo和普通单项目最大的区别之一。

---

七、为什么项目能编译，仍然可能改错包？

假设项目里有两个相似组件：

packages/ui/Button.tsx
apps/web/components/Button.tsx

AI修改了：

apps/web/components/Button.tsx

代码可以正常编译。

但实际页面引用的是：

@company/ui/Button

也就是说，它真正使用的是：

packages/ui/Button.tsx

这时候不会出现明显语法错误。

只是你的修改根本没有进入真实调用链。

所以确认文件时，不只是：

这个文件是不是存在？

而应该继续确认：

当前功能到底import的是哪个文件？

---

八、注意Workspace里的依赖版本

Monorepo内部依赖可能写成：

{
  "@company/ui": "workspace:*"
}

也可能通过其他方式连接。

如果Codex调整一个Package的API，却没有同步修改依赖它的Workspace，就可能出现：

• 类型不匹配；

• 构建失败；

• 调用参数错误；

• 旧接口继续被使用。

所以修改公共包以后，建议搜索：

Package名称
导出函数名
组件名称
类型名称

确认所有主要调用方。

---

九、一个实用的排查顺序

以后 Codex 修改 Monorepo 项目出现异常，可以按照这个顺序：

第一步：确认仓库根目录

先明确当前真正打开的是哪个仓库。

第二步：确认目标Workspace

到底是：

apps/web

还是：

packages/ui

第三步：确认真实引用

通过import和依赖关系找到真正使用的Package。

第四步：确认命令执行目录

测试、构建、Lint到底应该在哪里运行。

第五步：检查跨包依赖

修改公共Package后，哪些Workspace会受到影响。

第六步：分别运行验证

不要只验证当前一个Package。

---

十、可以让Codex动手前先输出“工作区确认”

对于Monorepo任务，可以增加一条要求：

开始修改前先确认：

1. 仓库根目录；
2. 当前目标Workspace；
3. 准备修改的完整文件路径；
4. 这个Package被哪些模块引用；
5. 测试和构建命令应该在哪个目录执行。

确认后再修改代码。

这一步看起来多花一点时间。

但通常能避免：

改错Package以后再重新返工。

---

十一、公共Package修改要比普通页面更谨慎

例如修改：

apps/web/pages/home.tsx

影响可能只在一个应用。

但如果修改：

packages/ui
packages/core
packages/utils

就可能同时影响多个Workspace。

所以Monorepo里不能只看：

这次改了多少行。

还要看：

这个Package处在依赖关系的什么位置。

越靠底层、被依赖越多，修改以后越应该扩大验证范围。

---

最后

Codex在Monorepo项目里容易改错包，本质上不是因为它不会写代码。

而是这种项目里同时存在：

多个Workspace、同名文件、跨包依赖和不同执行目录。

排查时最重要的是确认：

仓库
↓
Workspace
↓
真实引用
↓
依赖关系
↓
执行目录

尤其不要看到某个文件名称相似，就直接开始修改。

在Monorepo里真正需要确定的是：

当前功能到底属于哪个Package，以及修改这个Package之后还会影响谁。

只要把工作区和依赖边界确认清楚，Codex在大型多包项目里的修改通常会稳定很多。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容和稳定订阅渠道欢迎搜索关注「仙逆GPT」。