是这样的。

上周的时候，一个朋友跟我说，他在用 Windsurf 做全栈项目，后端 Java Spring Boot，前端 Vue3，每天第一件事就是先开两个窗口。后端这边改了接口，切到前端窗口找对应的调用，改一遍。前端报了一个奇怪的错误，切回后端看返回值，再改一遍。

来回切，来回找。

然后他说，最让他抓狂的不是切窗口本身。

是 AI。

他每次跟AI聊问题，AI 只能看到当前窗口里的代码。后端的 AI 不知道前端长什么样，前端的 AI 不知道后端定义了什么接口。每次要解决一个跨端的问题，他得把两边的代码手动复制给 AI，分别解释一遍背景，然后才能得到一个有用的回答。或者在前端的AI窗口里，直接把后端的代码路径给AI，让AI去读。

我听完，一秒钟就想起了我自己刚开始用 Windsurf 的时候。

也是一模一样的状态。

后来，我发现了工作区这个东西。用完之后，我就觉得，哦，原来应该是这样用的。

今天想认认真真跟大家聊聊这个，由于我身边许多在用 Windsurf或者Cursor 的朋友，实则都还没有用上工作区，依然是一个项目一个窗口的习惯，这样真的很可惜。

工作区是什么，三分钟能建好

先说工作区是什么。

这个概念本身不复杂。平时我们打开 Windsurf，一般是打开一个文件夹，这个文件夹就是你的工作目录，AI 也只能看到这个文件夹里的内容。但工作区不一样，你可以把多个不相关的文件夹，同时塞进一个 Windsurf 窗口里。它们在左侧的资源管理器里并排排列着，互不干扰，但同属于一个工作环境。

就是这么简单的一件事。

但这个「就这么简单」，改变了许多东西。

顺便说一下，这不是 Windsurf 独有的功能。Cursor 和 VS Code 用的是同一套工作区标准，.code-workspace 文件三个编辑器通用，在哪个里配好都能直接打开。

怎么建？打开 Windsurf，菜单栏找到 「文件」→「将文件夹添加到工作区」，把你的项目一个个加进来。加完之后，「文件」→「将工作区另存为」，取个名字保存成 .code-workspace 文件，下次双击这个文件，就能一键还原你的整个多项目环境。

整个操作，三分钟能搞定。

AI的上下文边界，就是你的工作区

好，说完怎么建，聊一下为什么要这样做。第一个缘由，也是最重大的缘由，是 AI。

Windsurf 里的AI的能力边界，就是你当前的工作区。你打开什么，它就能看什么，也就只能帮你处理什么。你目前只打开了后端项目，它就只在后端的范围里工作，它不知道你的前端长什么样，不知道你的接口文档定义在哪，不知道前端用了哪个字段、期望拿到什么格式的数据。

你问它一个跨端的问题，它给你的答案，只能是一半。

但如果你把前后端放到一个工作区，局面就不一样了。

这就是工作区给 AI 带来的最大变化，上下文扩展了，它能看到的世界更大了，能做的事情自然跟着多了。

我有时候跟朋友开玩笑说，给 AI 的上下文，就像给一个顾问看的案宗。你给他看残缺的案宗，他给你的判断就是残缺的；你给他看完整的，他才能真的帮你想清楚。

后端开发者必备：launch.json 一键启动

说完 AI，再聊两个具体的开发技巧，这两个我用下来觉得特别好用。

第一个，后端用 launch.json 来管理启动配置。

这个文件许多人知道有，但平时懒得配，觉得直接在终端里 mvn spring-boot:run 或者 java -jar xxx.jar 也够了。我一开始也是这个想法。但一旦项目稍微复杂一点，你就会开始觉得值了。

launch.json 放在项目的 .vscode 目录下，是 Windsurf 的调试启动配置文件。你可以在里面定义你的后端服务怎么起来，指定主类入口，在哪个工作目录下运行，还可以直接在里面声明开发环境的 Profile 和环境变量。一个典型的 Java Spring Boot 项目的配置大致长这样：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "启动 Spring Boot 后端",
      "type": "java",
      "request": "launch",
      "mainClass": "com.example.demo.DemoApplication",
      "projectName": "demo",
      "cwd": "${workspaceFolder}/backend",
      "env": {
        "SPRING_PROFILES_ACTIVE": "dev"
      }
    }
  ]
}

配完之后，每次要起后端服务，直接按一个 F5，或者点左侧调试面板里的绿色箭头，一键启动。不用记命令，不用记参数，不用担心当前终端的目录是不是对的。

更爽的一点是，这个配置文件是可以跟代码一起提交到 git 的。整个团队共享同一套启动配置，新人来了拉一下代码直接跑，省掉了大量的「为什么我本地跑不起来」的时间。

还有一个许多人没发现的细节，工作区里有多个项目，每个项目都有自己的 launch.json，在 Windsurf 的调试面板里，所有项目的启动配置都会合并到一个列表里并排显示。想起哪个就点哪个，完全不会搞混。

前端就简单多了：终端直接跑，一个窗口全搞定

第二个技巧，前端用终端管理，这个相对简单一些。

前端服务一般就是 npm run dev 或者 yarn dev，没有太多复杂参数，直接在终端里跑就够了。Windsurf 的工作区里，你可以同时开多个终端标签，每个标签里跑不同项目的服务。前端 dev server 开着，后端服务也开着，两个终端并排在那里，想看哪边的日志往哪边点一下。

这个组合，实则就是一个完整的全栈本地开发环境，在一个窗口里。

你可能还没用上的进阶技巧

顺着上面的，再说几个具体的使用技巧。

工作区支持在根目录放一个 .windsurf 文件夹，里面配置AI的全局规则，列如「这个工作区里的后端用 Java Spring Boot，前端用 Vue3 + TypeScript，API 遵循 RESTful 规范，变量命名用 camelCase」。这样 AI 在整个工作区里工作的时候，都会遵循这套规则，不用每次开新对话都重新解释一遍项目背景。

全局代码搜索也是跨项目的。你用 Cmd+Shift+F 搜索一个接口名，前端和后端里的所有相关代码都会一起出来，不用切换窗口。这在排查「前后端字段名不一致」这类问题的时候，特别省心，一搜就能看到两边的差异，一目了然。

还有一个就是源代码管理面板。

Windsurf 左侧的源代码管理面板，在工作区模式下会把所有项目的 git 仓库聚合在一起显示。前端仓库有几个改动，后端仓库有几个改动，一眼全看到，不用来回切窗口。你在前端改了一个接口调用，顺手把后端对应的 Controller 也改了，这两个文件分属不同仓库，但都在同一个面板里，写完 commit message、点提交，分别推送，整套动作在一个地方做完。

以前这种「前后端同步改动、同步提交」的事情，我一般是开两个终端分别跑 git 命令，或者记在脑子里「后端改了，等下别忘了也推一下前端」，出过好几次「前端推了，后端忘了推」然后部署出问题的情况。

目前是，源码面板同时展示两个仓库的变更，有改动就有红点，不会漏。

软件这几十年，一直在拆，但也许该合了

说到这里，我突然想起了一件事，跟工程本身没什么关系，但我觉得挺有意思的。

软件开发这几十年，实则一直在做一件事，就是拆。把复杂的系统拆成模块，把大团队拆成小组，前端团队、后端团队、数据团队，各自有各自的仓库，各自有各自的工具链，各自有各自的上下文。这种模式有它的理由，大团队要并行推进，你必须得拆，否则协作成本会把所有人压垮。

但对于一个独立开发者，或者一个五个人以内的小团队，这套拆分的逻辑，许多时候反过来变成了一种负担。

明明是同一个大脑在处理一件事，非得把信息切碎了分开放。然后就出现了那个朋友描述的那种状态，两个窗口，两个 AI，来回搬运上下文，本来可以一口气做完的事情，硬是被拆成了好几个步骤。

AI 也是一样，你给它看越多的上下文，它的能力就越强。工作区，说到底，就是在帮 AI 建立一个更完整的世界观。

好的工具，从来不是让你用更多功能，而是帮你把不必要的摩擦，悄悄消掉。

工作区，就是那个把多余摩擦消掉的东西。

以上，既然看到这里了，如果觉得不错，随手点个赞、关注、转发三连吧。

谢谢你看我的文章，我们，下次再见。