2026 年 7 月 30 日，GitHub 官方博客展示了 Copilot 应用中的“堆叠会话”工作方式：开发者可以在同一仓库里创建前后依赖的多个会话，让后一个任务承接前一个任务的上下文和代码成果，并分别形成按顺序合并的拉取请求。它解决的不是模型会不会写代码，而是 AI 一次改得太多之后，团队还能不能审得清楚。
一个旧项目为什么需要会话堆叠
GitHub 展示的案例是一套从 2014 年延续至今的个人应用，仍使用 React 15、Less 和较旧的 React-Bootstrap。开发者先让 Copilot 规划前端现代化，再逐步实现；当移除 React-Bootstrap 开始超出当前任务范围时，她没有继续扩大原会话，而是先为已有工作建立拉取请求，再创建承接前序上下文的新会话。
Copilot 随后完成了三件事：保存当前修改为一个拉取请求；为组件替换创建新的堆叠会话并生成待确认计划；基于前一个分支建立下一个拉取请求。这样，每项修改都有自己的审查边界，同时保留明确的依赖顺序。
它针对的是 AI 编程的新型范围失控
AI 编程降低了生成代码的成本，却也让“大改一把”变得过于容易。一个提示可能迅速演变成上万行修改，功能、重构、依赖升级和样式调整混在一起。代码即使能够运行，评审者也很难判断哪一项改动导致回归。
堆叠会话把长任务拆成可以单独测试和审查的增量：先合并底层准备，再合并依赖它的功能；某一层出问题时，也更容易定位和撤回。它让 AI 代理的工作单位从一次长对话，转向一组有交付关系的小任务。
使用时别忽略这四个检查点
- 每个会话只保留一个清晰目标，避免把顺手重构继续塞进去。
- 下层拉取请求变化后，要重新同步上层分支并处理冲突。
- 测试应跟随每一层修改，而不是等整个堆栈结束后才统一运行。
- 合并顺序必须明确；上层代码依赖尚未进入主分支时，不应被误当成可独立发布。
堆叠会话并不会替开发者决定拆分边界，也不会自动证明代码正确。它真正释放的价值，是让长时间运行的编码代理仍然接受传统软件工程约束：小范围修改、独立验证、清楚依赖和可回滚审查。对于遗留系统升级和跨多步迁移，这比追求一次生成全部完成更可靠。
