AI 编码智能体需要堆叠会话，而不是更长提示词

AI 编码助手正在进入更务实的阶段。过去的常见做法是把很长的需求塞进一个提示词，让模型一次性修改项目，然后希望结果还能被审查。GitHub 关于 Copilot app 中 stacked sessions 与 pull requests 的文章展示了更合理的方向：把相关工作拆成清晰的会话、分支和合并请求，让开发者可以比较、暂停、关闭或继续。

这很重要，因为智能体软件既强大也有风险。TechCrunch 关于 Anthropic 安全测试的报道提醒我们，高级模型在受控测试中已经能完成复杂入侵任务。因此，自动化工具需要窄权限、可审计证据和人工审核，而不是盲目信任。对 BTTC 读者来说，最有价值的 AI 工作流不是一次写最多代码，而是让每个改动都可检查。选择生产力软件时，也可以查看 BTTC 软件目录，为关键步骤准备可靠工具。

为什么堆叠会话值得关注

堆叠会话让 AI 编码更像正常工程流程。开发者可以让智能体现代化样式、移除依赖、改进可访问性或补充测试，而不必把所有想法塞进同一个分支。每个会话都有自己的上下文和 pull request。如果某条路径变得混乱，团队可以关闭它，从正确的基础分支重新开始，而不是整理一个巨大的混合 diff。

新能力的核心是审查设计

随着生成能力提升，瓶颈会从“能不能生成”变成“能不能审查”。团队需要定义智能体能改哪些文件、必须运行哪些测试、哪些区域禁止触碰、何时必须人工批准。好的任务应包含目标、小范围、基础分支、测试预期和回滚方式。pull request 描述也应说明改了什么、为什么改、如何测试以及哪里仍不确定。

来自安全测试的提醒

Anthropic 相关安全测试并不意味着应该拒绝 AI 编码智能体，而是说明它们必须像生产系统一样设计。智能体应使用最小权限、隔离环境、有限密钥和可审计日志。个人开发者也应使用独立分支、阅读 diff、运行测试、检查生成的命令，并在智能体越界时缩小任务。

开发者的实用流程

可以从简单积压开始：一个会话处理 bug，一个补测试，一个写文档，一个做重构。每个会话给出窄提示词，并要求产出适合 pull request 的结果。按依赖顺序审查，只合并通过测试且确实改进项目的部分。截图工具、PDF 转换器、压缩工具、diff 查看器和笔记应用仍然重要，因为它们让人工审查更快。你也可以继续阅读 BTTC 博客，寻找适合 AI 辅助工作站的工具。

常见问题

堆叠会话只适合大型团队吗？

不是。独立开发者也会受益，因为每个会话都是干净检查点，可以丢弃失败实验而不影响其他工作。

AI 编码智能体应该自动合并 PR 吗？

初期通常不应该。自动合并需要强测试、有限范围、分支保护和明确责任。多数团队应先采用智能体创建 PR、人工批准的模式。

第一个任务应该选择什么？

选择小而可验证的任务，例如补测试、改文档、修 lint 或更新单个组件。不要一开始就做大规模重写。

结论

下一波 AI 编码的成败不只取决于模型能力，还取决于工作流纪律。GitHub Copilot 的堆叠会话之所以重要，是因为它符合开发者保护质量的方式：小分支、pull request、测试和审查。让智能体准备工作，但把范围、安全和最终决定留给人。