在软件开发的世界里，”遗留代码”（legacy code）是一个让无数工程师头疼的词。一段写于十年前的代码，可能曾经是创新的产物，但随着技术栈的老化、依赖包的过时，它逐渐变成了一座难以跨越的技术债务高山。更让人沮丧的是，现代化改造这类任务往往收益有限——”与其重构，不如重写”——但真正动手时又会发现，代码已经大到无法轻易推倒重来的地步。
GitHub Copilot产品经理Cassidy Williams最近分享的一个真实案例，恰好展示了AI编程工具如何正在改变这一局面。
从十年旧代码到现代化前端：一次真实的Copilot体验
Cassidy在博客中详细记录了她使用GitHub Copilot应用对个人项目进行前端现代化的全过程。这个项目始于2014年前后，使用的是React 15（2016年发布）、Less CSS预处理器，以及那个年代的react-bootstrap版本——是的，你没看错，是Bootstrap。
“尝试在没有AI的情况下理清这些依赖需要花我好几周时间，”她在博客中写道，”我之前尝试过，也放弃过。这个应用说大不大，但刚好大到让人痛苦，付出和回报完全不成正比。”
但现在有了AI。她启动了GitHub Copilot应用，添加了仓库，开始了改造工作。
第一步，她尝试用Plan模式（规划模式）一次性完成所有改造。她输入的提示词非常详细，涵盖了需要用Tailwind或原生CSS替代Less、清理所有无障碍和响应式问题、缩小输入框的圆角、调整标签样式、为容器添加最大宽度限制等多个方面。
结果如何？”不行，”她坦诚地写道。
堆叠会话：处理复杂多步骤任务的新方式
这里就要引出GitHub Copilot最近推出的一个重要功能——堆叠会话（Stacked Sessions）。
传统的AI编程辅助通常是单次对话模式：用户提出一个请求，AI生成一段代码，任务完成。但实际软件开发中的复杂任务往往不是这样运作的。一个代码现代化改造项目可能涉及几十个相互关联的改动：修改样式后需要调整组件结构，更新依赖版本后可能引入新的兼容性问题，修复了一处破坏的无障碍访问后又发现另一处也有同样问题。
堆叠会话就是为了解决这种复杂性而设计的。它允许开发者在同一个仓库中创建多个相互关联的会话，每个会话都建立在前一个会话的基础上。当第一个会话完成了一批改动并创建了拉取请求后，开发者可以开启第二个会话，让AI基于第一个会话的上下文继续工作，而不是从头开始。
在Cassidy的案例中，她的第一次尝试以失败告终——生成的代码存在问题。但关键的是，Copilot能够理解她之前已经做出的决策（她选择了Tailwind而非原生CSS，她确定了特定的样式规范），并在后续会话中延续这些决策，而不是推翻重来。
更值得注意的是，Copilot甚至能够主动处理意外情况。Cassidy后来发现，她其实早先在开发分支上做过部分改造，但她忘记了这一点。当新的会话尝试从main分支创建改动时，与她在dev分支上已部署的版本产生了冲突。
“AI帮我做了一个很酷的事情，”她写道，”它自动关闭了我之前尝试的那个拉取请求，把我之前确定的样式决策迁移到了正在dev分支上应用的改动中。”
这意味着什么？在没有AI的情况下，开发者需要手动处理这些分支合并冲突，理解两个不同方向上的改动如何相互影响，然后小心翼翼地将它们整合在一起。Copilot不仅完成了这些工作，还主动”关闭”了废弃的拉取请求，保持代码库的整洁。
AI编程工具的现实意义：不只是”自动补全”
这个案例揭示了一个重要的趋势：AI编程工具的能力边界正在快速扩展。
最初，GitHub Copilot给大多数开发者的印象是”高级自动补全”——它能根据上下文预测下一行代码，减少打字工作量。这当然有价值，但本质上还是一种效率工具，做的还是”代笔”的活。
堆叠会话代表了一种质变。它不再只是预测下一行代码，而是开始理解软件开发的工作流程本身：代码改造是一个迭代过程、决策需要前后一致、多个改动之间存在依赖关系、分支管理是开发流程的一部分。当AI能够处理这些”元问题”时，它的价值就远远超出了代码补全。
值得强调的是，即使有了这样强大的AI辅助，人类开发者的角色并没有被削弱。Cassidy在案例中清楚地展示了人机协作的模式：她制定改造策略，做出关键技术决策（比如选择Tailwind而非原生CSS），审核AI生成的改动，在关键节点进行判断和调整。AI负责执行细节、保持上下文一致、处理重复性工作。
从GPU利用率看AI工具的基础设施支撑
如果说GitHub Copilot代表了AI赋能给开发者带来的直接效率提升，那么Hugging Face团队最近的一篇关于GPU管理的文章，则从另一个角度揭示了这场AI革命的底层支撑。
Hugging Face的文章提出了一个颇具洞察力的类比：飞机的利用率是航空公司最重要的指标。一架飞机的成本是按日历小时累积的——融资、折旧、保险、维护、机组人员合同——而收入只按飞行小时计算。停在地面上的每一小时，成本照常累积，收入却为零。因此，航空公司的核心竞争力之一，就是最大化每架飞机的飞行时间。
AI计算基础设施面临着完全相同的结构性问题。
一块GPU的成本是按日历小时计算的：融资、折旧、电费、冷却系统运营——无论它此刻是否在处理任务。这些成本是固定的，而产出（计算量）只有在GPU实际工作时才会产生。
Hugging Face团队指出，2020年微软为OpenAI构建的超算集群使用了超过10,000块GPU和285,000个CPU核心，在当时被认为是全球五大超算系统之一，旨在训练GPT-3。六年后的今天，这个数字看起来更像是起点而非天花板。到2026年，即使是最资金充裕的AI实验室，也在将计算资源的获取视为实时战略约束而非已解决的问题。
这种稀缺性不只是发生在实验室层面。当企业通过API消费AI模型时，GPU利用率的影响同样深远地传递下来。一家能够更高效利用GPU资源的企业，在同等成本下能处理更多请求，这意味着更低的单位服务成本和更快的产品迭代。
技术生态正在形成正循环
将这两个维度结合起来看，我们会发现一个正在加速的正向循环。
更好的AI编程工具（如GitHub Copilot）让更多开发者能够更高效地工作，这带来了更多AI应用的出现；更多AI应用产生了更多对AI计算能力的需求；更大规模的AI计算需求推动了GPU等硬件的更快发展和成本下降；硬件成本的下降又使得更多开发者能够负担得起AI工具，进一步扩大使用规模。
在这个循环中，工具层和基础设施层是相互依存的关系。Copilot这样的工具帮助人类开发者更高效地建造软件，而GPU管理这样的基础设施优化则确保建造软件所需的计算资源被高效利用。两者缺一不可。
对于普通软件开发者而言，这意味着一个简单的结论：AI编程工具的能力边界正在快速扩展，而学习使用这些工具的窗口期正在缩小。堆叠会话功能只是开始——随着AI更深地理解软件开发的工作流程，更强大的功能将会不断涌现。
Cassidy的案例中最发人深省的，或许不是Copilot完成了多么复杂的代码改造，而是它展现了一种新的可能性：那些”太大而无法改造”的代码，现在可能不再是一个无法解决的难题。这不仅对个人开发者有意义，对于那些维护着大量遗留系统的大型企业来说，可能意味着一次技术债务大清理的机遇。
本文使用GitHub官方博客及Hugging Face官方博客作为信息来源，所有事实性内容均经过来源核验。