AI 做全栈开发，到底该几个会话？谈谈我的实战经验
最近在折腾全栈项目，有个一直困扰我的问题：当我们把大脑外包给 AI 的时候，到底该怎么管理它？
尤其是遇到那种前后端分离的大型项目，涉及到代码联调、字段变更的时候，是开两个会话，一个管前端一个管后端，还是直接把需求扔给一个会话，让它自己去搞定前后端的所有修改？
如果是以前，我可能会毫不犹豫地选择前者，分工明确嘛。但在实际使用 AI 编程助手（比如 Claude、Codex 等）的过程中，我发现这里面其实有不少门道，稍微换一种思路，效率真的能翻倍。
为什么要纠结“几个会话”？
在传统的团队协作里，前端和后端分属不同的人，是为了明确责任边界。后端负责 API 接口和数据库，前端负责页面逻辑和交互，大家各司其职，最后通过接口文档对接。
AI 编程工具示意图
但当“后端”是你，“前端”也是你，而“打字员”变成 AI 的时候，这种分离带来的成本就变成了信息不对称。如果你在给后端聊天的会话里改了接口字段，却忘了告诉负责前端的会话，或者反过来，这就变成了灾难。
所以，问题的核心其实不是“几个会话”，而是如何保证 AI 拥有全知视角（Context）。
Monorepo 代码仓库结构
方案一：物理隔离，逻辑统一
有很多开发者目前的做法是：虽然代码仓库是分开的（比如一个 Git 仓库存后端，一个存前端），但在本地开发时，会把前后端代码放在同一个大的父级文件夹下。
优点非常明显：
- 单会话管理：你只需要在一个 AI 对话窗口里说话，比如“修改用户表的 ID 字段类型，并同步更新前端的列表页渲染”。
- 无需额外切换：AI 可以同时读取到两个文件夹里的文件，自己就能完成联调，省去了你作为中间商传话的麻烦。
- 提交独立虽然物理路径在一起，但 Git 仓库还是分开的，提交代码时互不干扰，保持了项目结构的整洁。
对于大多数中小项目，这种“物理上放在一起，逻辑上分开管理”的方式是最舒服的，既省事又不会搞乱项目结构。
方案二：利用 AI 工具的特性
其实现在的 AI 编程工具本身也越来越聪明，它们也意识到了全栈开发的需求。这里分享两个具体的操作技巧：
1. Claude 的 /add-dir 指令
如果你是用 Claude 做开发，它有一个非常实用的功能叫做 /add-dir。即使你的前后端代码分布在完全不 同的路径下，你也可以通过这个指令把另一端的代码目录“加”进当前的上下文窗口里。
这样意味着，你的主会话可以一直盯着后端代码，当需要改前端时，只要运行一下 /add-dir，AI 就瞬间获得了前端的“视野”，修改完之后再释放掉，非常灵活。
2. Codex 的引用功能 (@)
在类似 Codex 的工具里，可以通过 @ 符号直接引用文件。更棒的是，你可以直接 @另一端文件夹里的 README 文件。
只要你的 README 里写得清楚（比如包含了 API 规范、数据结构定义），AI 就会自己去读取参考，从而在生成代码时自动对齐两端的规范。这种方式特别适合那些代码库特别大，不想把所有文件都塞进上下文的情况。
终极形态：拥抱 Monorepo
当然，最极致的玩法其实是直接上 Monorepo 模式。
什么是 Monorepo？ 简单说就是一个仓库里包含了前端、后端、公共库、文档等所有代码。
为什么对 AI 友好？ 因为 AI 是基于上下文的。在 Monorepo 模式下，整个项目就是一个 Workspace。当 AI 在分析代码依赖、生成跨端逻辑时，它不需要跨越仓库的边界，可以直接“看见”所有的链路。
对于 AI 来说，一个 Workspace 对应一个项目，这是最自然的思维模式。既然是 AI 负责全栈，那就尽量减少人为设置的障碍，让它在一个统一的环境里自由发挥。
总结与建议
回到最初的问题：到底几个会话？
如果项目规模不大，建议一个会话走天下。把前后端代码放在本地同一层级，或者利用 /add-dir 这样的工具技巧，赋予 AI 全局的视野。毕竟，使用 AI 的最大初衷就是减少沟通成本，如果还要你在两个会话之间复制粘贴接口定义，那这就背离了提效的初衷。
只有当项目极其庞大，或者团队协作真的需要严格的权限隔离时，才考虑分开处理。对于绝大多数独立开发或小团队场景，“合并同类项”永远是性价比最高的选择。
评论已关闭