不是所有 AI 辅助功能都值得你放下键盘去鼓掌。但 GitHub Copilot 刚塞进 App 里的堆叠会话（Stacked Sessions），让我想起那个经典问题——你能不能在不掀翻整个桌子的前提下，给一辆正在行驶的火车换轮子？答案就藏在这个发布里：能，而且你还能顺手把每个新轮子的 Pull Request 自动建好。这就是它最狠的地方。
不是又一个 AI 噱头，这次它切中了要害
Plan 模式先把地图画出来，而不是让你瞎猜
先别急着说“Copilot 早就能给建议了”。旧版本的体验更像是你在编辑器里打个问号，它甩回来一段代码，至于这段代码塞进去会引发多少连锁反应，你自己扛。这次不一样。Copilot App 里直接杀出一个 Plan 模式：你把意图扔过去，它通读整个仓库上下文，然后给你列出一份可执行的任务清单，每个步骤都对应一个明确的作用范围。没有玄学，没有“或许你可以试试这个”。它就是一张施工图。
在 Cassidy 的演示里，这个 Plan 模式面对的是一个尘封十几年的个人项目——前端骨架还捆在 2013 年的 React-Bootstrap 上。Copilot 扫完仓库后不是泛泛地说“升级依赖”，而是把“现代化前端”这个大命题拆成若干个切口极小的任务：先处理导航栏组件，再碰按钮，然后是网格系统，接着表单元素，最后全局清理。你看，这就像外科医生告诉你，我们不能一次把病人全身切开，得沿着骨骼间隙一层一层来。
每个会话只做一件事，但上下文贯通整条链
理解堆叠会话的关键词不是“堆叠”，而是上下文继承。老的 Copilot 会话像金鱼，每次新对话都感觉你是第一天认识它。堆叠会话破了这堵墙：你完成第一个任务后，可以基于它创建第二个，第二个基于前两个创建第三个，以此类推。每往前叠一层，Copilot 都完全记得前面那几层对文件做了什么、为什么这么做、哪些逻辑被改动了。这不是简单的聊天记录记忆，是实打实的仓库状态上下文。
实际效果是什么？当你处理按钮替换时，Copilot 已经知道导航栏刚被改过，它会自动避免样式冲突和导入路径错乱。你用不着在每个会话开头重新解释一遍项目结构，更不用心惊胆战地复制粘贴 diff。一条链跑下来，整个重构就像是一个人从头做到尾，而不是五个失忆的机器人在接力。
拉取请求自动生成，不用你说第二遍
最让我觉得值回邮件的部分是——每一个堆叠会话结束，Copilot 自动创建对应的 Pull Request。描述、提交信息、变更范围都给你填好，你只需要扫一眼点合并。这意味着你的大型重构不再表现为一个六百文件、四十条评论的巨型 PR，而是一串小而完整的补丁序列。每份 PR 的变更范围被严格限定在单个任务内，审查者不用在同一个 diff 里同时面对样式替换和业务逻辑改动，测试也能单独跑。这就是根治范围蔓延的系统级解法。
一个 2013 年的项目，如何被一步一步拆解
那是一个像活化石的前端骨架
Cassidy 拿来演示的项目不是精心挑选的玩具，而是一个真正带着历史伤痕的活代码——十几年前搭建的 React 应用，核心 UI 库是早已失宠的 React-Bootstrap。这种项目每个开发者手上都有：能跑，看起来也没大毛病，但一旦试图碰底层组件，整个界面就像多米诺骨牌一样连环崩塌。你不敢动它，于是技术债越积越厚。
从 React-Bootstrap 到新组件库，分五刀切完
Copilot 给出的 Plan 在这里展示出了真实智慧。它没有建议一次性全局替换，而是顺着组件树的依赖顺序拆成五个堆叠会话。第一个会话只攻击导航栏，把 React-Bootstrap 的 Navbar 重写为新的组件库实现，同时调整相关的测试。第二个会话处理按钮，因为导航栏里也用到了按钮，但上下文在前一步里已经清晰了，Copilot 自动复用了相同的模式。第三个会话动网格系统，这是最容易引发布局崩坏的部分，但此时由于前面两个会话的铺垫，依赖关系已经一目了然。第四个会话扫清表单元素，最后一个会话做全局兜底和清理。
每个会话完成的刹那，一个独立的 PR 就已经躺在仓库里。Cassidy 只需要依次审查、合入，整个重构就静悄悄地完成了。没有冲刺式的通宵合并，没有合并冲突引起的团队血压飙升。这事儿要搁两年前，你可能得专门拨出一个 sprint 来做。
自动 PR 的意义：从“人盯着 AI”到“AI 盯着流程”
很多人还在纠结 AI 生成的代码可不可靠，却忽略了更大的问题：可靠的东西用错地方，就是不可靠。一个正确的组件替换，如果必须跟四十个其他改动塞进同一个 PR，出错概率是指数级上升的。堆叠会话搭配自动 PR，等于在流程层面对代码生成进行了约束，每一个改动都落在一个独立且可验证的节点里。这样你审查的就不再是 AI 的思路是否天马行空，而是单个任务的代码质量。做对了这一点，AI 辅助编程才真正从玩具跨进工程。
工具在进化，但别把它当灵丹
Plan 不是圣旨，你得懂什么时候不照着走
堆叠会话看起来很聪明，但有一个陷阱需要警惕：Plan 模式生成的方案是基于静态代码分析和你给的提示，它无法感知团队正在进行的其他分支、即将变更的 API，或是某个组件实际上已经有人重构了一半。如果开发者无脑点“全自动进行到底”，几天后你可能会发现仓库里躺着一串完美的 PR，但恰好和另一个人的工作撞车。Cassidy 的演示也强调了一点——她会审查每一份计划，根据人的判断调整堆叠顺序，甚至删掉某些自动生成的会话。这份人的判断力，是堆叠会话不该掩盖的成本。
上下文再长，也不意味着你该把整个项目塞进去
堆叠会话支撑起了一条很长的上下文链，理论上你可以叠到十个、十五个会话。但每一个额外会话都会增加上下文噪声。Copilot 可能会开始重复考虑已经废弃的方案，或者在后期任务里引入早期不存在的假设。要不要继续叠，需要看变更的紧耦合程度。若是两个任务逻辑完全独立，强行塞进同一个堆叠链只会让会话臃肿，反而不如另起一条干净的对话。这跟写函数一样——过长的上下文就像过长的函数，表面是复用，底子是耦合。
它可能悄悄改写你的工作流
堆叠会话最长远的影响不是某个功能，而是对开发者节奏的重新塑造。过去重构大型项目，你的自然反应是开一个 feature 分支，在上面闷头改几天，最后捏出一个庞然大物扔去审查。现在 Copilot 给你另一种默认：任何大于一个小步骤的改动，都应当被分解为一系列可独立合入的 PR。这其实不是 AI 的发明，而是诸多高效工程团队早就推崇的“小步提交、持续集成”法则。Copilot 只不过把它焊进了工具层，让遵循好工程实践的成本比不遵循还要低。如果你的团队还在为“怎样才能逼大家把 PR 拆小”头疼，这个功能可能就是你们一直在等的那个软性推手。
