最近有个朋友问我说他在做一个前后端分离项目前端React、后端Java两个独立仓库平时用Cursor写代码但总觉得这个AI“不聪明”——它只看得见当前打开的文件要么就是把无关的代码目录一起扯进来经常改着改着就把接口契约改没了。我说这太正常了Cursor在家里写单文件Demo的时候很顺手一旦拿到工程化、多目录、多语言、多团队协作的前后端分离项目里你还按单文件的问法去用它当然水土不服。这篇文章不是教你“怎么写提示词”而是给你一套完整的、我在实际项目里验证过的AI跨工程管理方案怎么让Cursor理解“前端-后端-公共类型包”之间的关系怎么做到“改后端接口时顺手把前端类型同步掉”怎么把团队规范钉在Rules里让AI输出和几个人写出来的代码风格一致。1. 为什么前后端分离项目需要“跨工程”的AI管理思路1.1 单文件的AI使用方式放在多工程下为什么会失灵很多人用Cursor的习惯是从“单文件补全”练起来的写一个Python脚本让AI补一个函数写一个React组件让AI改个状态。这种用法在demo阶段没有任何问题因为整个上下文就一个文件模型一眼就能看全。但前后端分离项目不是这样。前端工程、后端工程、公共SDK或类型包经常是三个独立目录甚至三个独立仓库。AI如果只盯着当前打开的那个文件逻辑链是断的后端接口改了字段名前端还在用旧字段前端想要新增一个参数后端还没写校验逻辑两边各改各的跑起来全是联调错误。这类问题的根源不是模型不够强而是你没有给AI搭好“跨工程读取上下文”的通道。更麻烦的是很多前后端分离项目里真正的代码契约不在代码里而在开发者的脑子里——比如“token怎么传、分页参数叫什么、错误码长什么样”。如果这些约定没有被结构化地告诉AI它写出来的代码就是你最不想看到的那种单看一个文件还行一跑整个链路就崩。1.2 真实的多工程协作场景与核心痛点我挑几个我自己反复遇到的场景你看看有没有共鸣后端接口从“返回全量列表”改成“分页返回”前端所有调用方都得跟着改类型定义、改渲染逻辑、改分页状态。这是典型的前后端联动。前端mock数据和后端真实返回结构对不上忙活半天发现是接口文档没人维护。公共类型定义在packages/shared里前后端谁想改都直接改结果两边各自引入了一份副本契约彻底失效。一个需求从“前端页面”到“后端接口”到“数据库字段”涉及三处代码改动但AI只在你打开的那一个文件里干活。这些场景的共同点是知识分散在多个工程里单点提问根本覆盖不全。传统做法是人工去翻代码、翻文档、问同事而Cursor这套方案要解决的就是——让AI能主动把散落在多个工程里的关联代码建立索引在动手修改之前先搞清楚完整调用链产出的是“跨工程一致”的改动而不是“局部正确”的代码。联调阶段最大的时间黑洞就是前后端各改各的、契约漂移。跨工程管理思路的出发点就是把“AI辅助”从“帮你写一段代码”升级为“帮你管理一段代码变更在多个工程里的连锁影响”。2. Cursor里能支撑跨工程管理的关键能力2.1 Agent模式从“问答机器”变成“能主动翻代码的助手”我最早用Cursor的时候停留在Chat模式问一句答一句让我复制粘贴。后来切到Agent模式体验完全不同。Agent模式最大的区别是它会主动去你的代码库里翻文件而不是等你把文件打开。这个能力在跨工程管理里极其重要。你打开的是前端页面文件但需求是“给用户列表加分页”Agent会自己去后端工程里找对应的Controller和Service找到接口实现发现现有逻辑是返回全量列表然后回头告诉你“这个接口需要改成PageQuery参数前端List类型也要一起换”。你只需要确认方向它自己就把关联代码挖出来了。实际操作的时候我建议你把Agent模式当成默认模式用但有一个前提先让Agent把它的理解说清楚再动手。比如你可以先问“你先解释一下这个接口从请求到返回的完整链路涉及哪些文件”等它列出一份文件清单你再让它改。这样能避免它走了弯路。实测下来先解释链路再改动比一上来就“帮我改”成功率高出非常多。2.2 Codebase索引与引用让AI准确锁定工程范围跨工程管理最怕的是AI定位错文件。Cursor里有两个工具能解决这个问题一个是Codebase索引一个是引用。Codebase索引会把整个工作区workspace里的代码结构建索引你在Chat里问“用户分页接口在哪个文件哪一行”它能直接告诉你路径。对于单仓库monorepo项目直接在仓库根目录打开Cursor索引就能覆盖前后端所有代码。对于多仓库项目情况复杂一些。我试过几种方案最顺手的是把几个相关仓库clone到一个父目录下让Cursor打开父目录作为工作区。这样AI能把前端、后端、公共类型包都纳入视野。注意这不是让你把代码物理合并只是让Cursor的索引范围变大。引用方面Codebase是全局检索文件路径是定点引用。跨工程场景下正确做法是大范围用Codebase让AI自己找小范围用路径把关键文件钉死。比如我知道公共类型定义的入口文件是packages/shared/index.ts那直接在prompt里一下这个文件告诉AI“所有跨工程类型同步都以这个文件为准”效果会好很多。不要一上来就塞给AI十个文件它分不清主次。2.3 Rules与.cursorrules把团队约定固化给AI这是我认为整个跨工程管理方案里权重最高的一环。没有Rules的AI就像刚入职不看文档的实习生代码风格随缘接口约定靠猜。有了RulesAI等于人手一份《团队开发手册》。Cursor里写Rules有几个入口项目根目录的.cursorrules文件、.cursor/rules目录下的md文件、以及全局User Rules。我个人的分配方式是全局User Rules里放通用偏好比如“代码里不要用拼音变量名”“注释用中文但代码命名用英文”项目级Rules里放这个项目专属的约定比如“后端统一走/apis/v1前缀”“前端类型只能从packages/shared导入”。Rules要写在AI能读到的地方生效优先级最高的是项目根目录。团队里其他人clone项目后Rules文件也跟着走AI行为的基准就统一了。关于格式.cursorrules就用最朴素的Markdown直接写规则条目不要搞花活。AI对短句规则的理解准确率远高于长篇大论。我见过有人把Rules写成两千字的散文结果模型把关键约束全漏了。规则越像“军规”执行越到位。2.4 Notepads、上下文记忆与跨窗口协作如果你用过Cursor的新版会注意到有个Notepads功能可以把它理解成“给AI准备的小抄板”。跨工程方案里我会把一些不适合写进代码的说明放进Notepads比如“当前迭代的接口变更清单”“这次需求涉及的调用链路径”。另外一个实战技巧是多窗口分工。现在很多人在做全栈项目时会开两个Cursor窗口一个专注前端一个专注后端。这没问题但注意两个窗口共用同一份Rules否则AI的风格会漂移。如果你有多个模型可用也可以让一个窗口用快速模型做检索解释另一个用强模型做代码生成长上下文消耗会少一些。这个属于进阶玩法后面在团队协作部分我会再展开。2.5 顺手解决Cursor中文设置既然很多人问这里插一个小话题。你会发现Cursor安装后默认界面是英文中文用户在Rules里写中文注释没问题但看菜单栏确实别扭。其实切换中文很简单在Cursor的Settings里搜索“language”找到Locale或Language选项选择简体中文重启就生效了。新版Cursor在右上角设置入口的“Appearance/Language”里直接改。注意“设置成中文”和“汉化插件”是两回事Cursor原生支持多语言界面不需要额外装汉化包。界面语言不影响AI理解代码里的中文注释该写规则就写。3. 实操前后端分离项目下的AI跨工程管理配置方案3.1 工程结构设计与目录规划先把工程结构说清楚后面所有配置都基于这个结构。我用一个典型的前后端分离项目举例技术栈不限定但目录思路通用my-platform/ # 整个项目的工作区根目录Cursor打开这一层 ├── apps/ │ ├── web/ # 前端工程React TypeScript Vite │ │ ├── src/ │ │ │ └── api/user.ts # 前端调后端接口的封装 │ │ └── package.json │ └── api/ # 后端工程Node.js Express也可以是Java │ ├── src/ │ │ ├── routes/user.ts │ │ ├── controllers/userController.ts │ │ └── services/userService.ts │ └── package.json ├── packages/ │ └── shared/ # 公共类型与接口契约定义 │ ├── src/ │ │ ├── types/user.ts # User类型、分页请求/响应类型 │ │ └── api/userApi.ts # 接口路径常量与请求/响应类型 │ └── package.json ├── docs/ │ └── api.md # 接口变更记录AI也会同步维护 ├── .cursor/ # Cursor项目配置目录 │ └── rules/ │ ├── 01-global.mdc # 通用规则 │ ├── 02-frontend.mdc # 前端专项规则 │ ├── 03-backend.mdc # 后端专项规则 │ └── 04-workflow.mdc # 跨工程协作流程规则 └── .cursorignore # 让Cursor别索引node_modules等目录这里有个关键决策把所有工程放在一个父目录下然后让Cursor直接打开父目录。这样AI看到的是一棵完整的“平台树”而不是某个孤零零的前端仓库。很多人的问题是只打开了apps/webAI根本不知道还有apps/api和packages/shared那它再怎么聪明也做不了跨工程联动。3.2 Rules配置详解跨工程协作的规则文本Rules不是摆设它直接决定AI行为的边界。我说几段我实际在用的规则文本你直接抄就行注意结合自己项目的技术栈调整。第一段全局规则里的“工程边界”## 工程结构约束 - 前端代码只在 apps/web 目录下修改禁止改动 apps/api 下的任何文件。 - 后端代码只在 apps/api 目录下修改禁止改动 apps/web 下的任何文件。 - 前后端共享的类型定义统一定义在 packages/shared/src 目录下。 - 前端调用后端接口时路径常量必须从 packages/shared/src/api 导入禁止在前端代码里硬编码接口URL。这段规则的作用是让AI在“跨工程”的时候不乱串门。它仍然能读取其他工程的文件做参考但修改时只会在正确的目录里动手。第二段接口契约同步规则## 接口变更同步流程 当需要修改后端接口时必须按以下顺序执行 1. 先说明变更原因和影响的调用方。 2. 修改 packages/shared/src/types 下的类型定义。 3. 修改后端接口实现确保返回结构符合共享类型定义。 4. 修改前端调用代码使用新的类型定义。 5. 更新 docs/api.md 中的接口文档。 所有步骤缺一不可除非用户明确指定跳过某一步。这段规则是跨工程管理的灵魂。没有它AI帮你改完后端接口大概率会“忘记”同步前端类型最后联调报错你还要返工。有了它AI每次改接口都会走完整套流程。实测下来文档同步这一步最容易被忽略但有了规则约束后AI能稳定执行。第三段代码风格约束## 代码风格 - 前端变量命名使用 camelCase组件文件使用 PascalCase。 - 后端错误响应格式统一为{ code: number, message: string, data: null }。 - 分页请求参数统一为 { page: number, pageSize: number }。 - 接口路径统一前缀所有业务接口以 /apis/v1 开头。 - 禁止在代码中硬编码用户ID、密码、密钥等敏感信息。这些约束看起来琐碎但恰恰是AI生成代码最容易“自由发挥”的地方。你试过就知道不给规则时AI经常写出五花八门的错误格式有了规则后生成代码直接就能通过lint。对于.mdc文件Cursor支持给每个规则文件设置Glob匹配比如02-frontend.mdc里可以只作用于apps/web下的文件。这个功能建议用起来否则前端规则可能会干扰后端代码生成。3.3 让AI完成一次真正的跨工程改动现在来一次完整的实操演示。假设需求是“用户列表接口改为分页返回同时前端列表页加上分页控件。”我不会一上来就让AI改代码而是先让它走一遍“跨工程理解”流程。第一步我这样问Codebase 用户列表目前是前端 apps/web/src/api/user.ts 直接调用后端 /apis/v1/users 接口一次返回全量列表。现在要改成后端分页返回前端展示分页。先不要改代码先列出这个变更涉及的完整文件清单和调用链。Cursor的Agent会开始翻代码找到后端路由、控制器、服务层找到前端的接口封装和列表组件然后给出类似下面的链路说明涉及文件 1. apps/api/src/routes/user.ts —— 注册 /apis/v1/users 路由 2. apps/api/src/controllers/userController.ts —— 当前处理函数返回全量数组 3. apps/api/src/services/userService.ts —— 查询逻辑需增加 page/pageSize 参数 4. packages/shared/src/types/user.ts —— UserListResponse 类型需增加分页字段 5. packages/shared/src/api/userApi.ts —— 接口调用类型需增加请求参数 6. apps/web/src/api/user.ts —— 前端接口封装需要传分页参数 7. apps/web/src/pages/UserList.tsx —— 列表页需要分页控件和状态看到这份清单后我确认无误然后让它开始改。注意第二步的指令要把“范围”和“验收标准”写清楚按上面列出的文件清单执行接口分页改造。后端分页参数命名为 page 和 pageSize默认值分别为 1 和 20。响应结构按 packages/shared 里的分页类型定义返回。前端列表页使用 antd 的 Pagination 组件。整个过程中shared 类型定义是唯一契约来源。接下来AI会按照Rules里定义的“接口变更同步流程”依次改文件。这个过程中你可能需要盯一下它是否真的动了shared类型文件——如果它没有说明Rules没生效检查一下Rules文件的路径和命名。改完以后我还会让它输出一份变更摘要总结这次改动涉及的文件清单并更新 docs/api.md 中的接口文档。这一步看似多余实际上对后续排查和团队协作非常有用。接口文档在跨工程项目里经常是“写一次就不再更新”但AI能随手维护的话文档和代码就会保持同步后面其他同事用Cursor干类似活的时候也能基于正确的文档理解代码。3.4 让AI读多工程上下文的五步法我把上面的过程提炼成一个可复用的五步法以后所有跨工程需求都可以按这个套路走初始化索引。在Cursor里打开工作区根目录首次使用前让Agent执行一次“扫描整个工作区结构”确认它能准确说出apps/web和apps/api的关系。这一步不用太复杂比如问一句“这个仓库里前端和后端分别在哪个目录”就够了。定义数据流。在提示词里讲清楚数据流向例如“前端通过fetch调用后端接口类型定义来自shared包”。很多AI出错是因为它默认前端和后端共享同一个进程上下文。确定调用链。让AI在改代码前先列出改动涉及的全部文件路径用文件清单作为改动范围基线。文件清单列得越准后续改动越安全。给定验收点。明确告诉AI“改完以后什么样子算对”。例如“返回结构必须符合shared里定义的类型”“前端能编译通过”。验收点越具体AI越不会跑偏。增量修改与总结。一次只改一条调用链不要“一次帮我全改了”。每完成一步让AI总结改了哪些文件再继续下一步。这个流程看起来步骤多但实际执行比“让AI乱改然后你花两小时排查联调错误”要快得多。原因很简单AI最耗时的错误不是代码写得慢而是方向理解错了之后在错误方向上疯狂输出。4. 常见问题与排查技巧实录4.1 Cursor响应速度慢索引卡顿怎么办跨工程管理对索引的压力远大于单文件目录一大Agent检索起来速度明显下降。我遇到过的最夸张的一次问一个问题等了快三分钟最后发现是Cursor把node_modules里的几万个小文件也一起建索引了。解决办法是配置.cursorignore把不需要索引的目录全部排除node_modules dist build .git .idea .vscode target配置完以后建议在Cursor里执行一次重新加载窗口CommandShiftP输入Reload Window让索引重新生成。实测下来排除node_modules后跨工程检索的速度能提升两倍以上。另外Rules文件不要写得过长太长也会拖慢每次请求的上下文加载速度。控制在200行以内规则只留“纪律性”内容。4.2 AI改错工程动了不该动的文件怎么办这是跨工程场景下最扎心的问题。前端需求AI跑进后端目录改了一行程式码或者反过来。即便我在Rules里写了“前端代码只在apps/web下修改”也架不住某些prompt里同时提到了前后端代码AI就会去动其他目录。我的排查思路是这样的第一在改动指令里主动限定范围明确说“这次需求只允许改前端文件”第二利用Git diff做检查改动完成后先看变更文件清单如果发现越界文件直接回退第三把Rules里的“工程边界”规则放在最前面不要和其他规则混在一起。实测下来Rules顺序越靠前被模型读取和执行的优先级越高。4.3 接口契约不同步AI只顾一头这个问题太典型了。AI改完后端接口返回结构变了前端还在用旧类型一跑就报错。我前面说过根治方案是Rules里的“接口变更同步流程”。这里再补一个排查思路当AI没有按流程走完时不要马上重新生成一次而是用更直接的口吻追加指令。你上一步改完后端接口但没同步 packages/shared/src/types 下的类型定义请按Rules要求补齐shared类型定义并检查前端是否有依赖旧类型的代码同步修正。这种“点出差错再纠正”的方式比让AI重新跑一遍整个需求要节省大量token。AI对“补一个遗漏步骤”的理解准确率很高对“重做一遍”反而容易重复犯错。4.4 免费额度与长上下文的取舍Cursor的免费额度对重度跨工程用户来说确实不够用。Agent模式下每次请求要携带索引信息和上下文消耗速度比Chat模式快非常多。我的经验是把“探索性提问”和“代码生成”分开。探索时用快速模型回答简短token消耗少正式生成时再切到强模型一次到位。这一步能显著延长免费额度的使用时间同时也减少“AI边想边烧钱”的心理负担。4.5 提示词与敏感信息泄露风险这条必须提醒。Rules文件会进入每次请求的上下文如果你在Rules里写了数据库密码、Redis连接串、第三方密钥这些信息会跟着请求发给模型服务商。跨工程项目里Rules经常被团队成员共享一旦泄露范围更大。我的建议是Rules和Notepads里只写规范和路径绝不写任何真实凭证。敏感信息一律通过环境变量管理AI的代码生成里如果需要读取配置只需要让它引用process.env里的变量名就可以了不需要知道真实值。这个习惯越早养成越好。常见问题典型表现排查思路响应慢一次请求等几十秒甚至几分钟配置.cursorignore排除大目录精简Rules改错工程前端需求动到后端文件指令里限定范围用Git diff检查变更文件清单契约不同步后端改了返回结构前端没跟上确认Rules同步流程存在缺步骤时单独要求补齐上下文混乱AI在多个文件里反复横跳逻辑前后矛盾用五步法中的“先列文件清单再动手”规则不生效明明写了Rules但AI不执行检查Rules文件位置和命名放在项目根目录额度消耗过快Agent模式token烧的飞快探索和生成分开用不同模型避免重复提问4.6 团队协作与后续扩展跨工程AI管理不只是个人的工具技巧放到团队里同样有效。我建议把.cursor目录纳入Git版本管理这样每个人的AI行为基准都一样。新人加入项目之后不需要啃完所有文档先让Cursor读一遍Rules开发规范就灌进去了。再进一步可以接上API文档自动生成和测试用例生成。比如让AI在每次接口变更后同步OpenAPI规格文件再基于OpenAPI规格批量生成前端接口调用代码和mock数据。这个思路打通以后前后端联调时间能压缩到一个很理想的状态。我在一个中型项目上实践过接口相关的联调问题下降非常明显主要收益来自契约一致性而不是AI写代码的速度。说到底跨工程管理要管的不只是代码更是代码之间的“约定”。最后分享一个小技巧在Rules里加一条“修改前先读取相关文件的首部注释和类型定义”能让AI在动手前先看契约文件跨工程场景下这条规则价值极高。因为很多前后端不一致的问题都是AI没看类型定义凭直觉写出来的。我自己的体会是Cursor这套工具真正发挥作用靠的不是某一个神奇功能而是把工程结构、项目规范、上下文策略和AI能力串成一个闭环。你花在Rules和目录规划上的每一分钟都会在后续每一次跨工程改动里省回来。