我们推出了 Smart Paste，这是一款内部工具，可通过自动调整粘贴的代码来简化代码编写工作流程。我们介绍了从用户体验和模型准备工作中获得的关键见解，这些见解已在 Google 开发者中取得了优异的表现并成功采用。
大多数开发人员在日常工作中经常复制和粘贴代码，以避免不必要的重复转录。虽然这加快了代码开发的进程，但它不仅仅是简单的复制粘贴。对Google monorepo（ Google 的代码存储库，存储完整的工作历史记录，而不仅仅是已提交的更改）的分析揭示了用户行为中有趣的模式，这些模式是提高效率的潜在目标。例如，根据编辑历史记录，约 25% 的粘贴会被立即修改，编辑范围从小的语法修复（例如，添加缺失的分号）到对周围代码上下文的更复杂的调整（例如，重命名变量并更改其类型）。进行此类更改通常会破坏代码创作流程并减慢开发过程。
考虑到这一点，我们推出了 Smart Paste，这是 Google 现已广泛提供的一种工具，它可以预测代码环境的下一个状态，并使用生成式 AI 对粘贴的代码进行上下文感知调整。利用大型序列模型的最新进展（例如DIDACT，它使代码审查、构建修复等工具成为可能），Smart Paste 简化了代码修订期间的复制粘贴过程。在一项涉及约 4 万名采用该功能的工程师的使用研究中，我们发现 IDE 中所有粘贴中有 6.9% 使用了 Smart Paste，接受率为 42.5%，这大大简化了用户工作流程。
在粘贴Floor时，Smart Paste 会检测Ceil缺少的逻辑，并建议修改函数名称和运算符。
数据准备、模型训练和校准
对于模型训练，我们从 Google monorepo 和相关的综合日志中获取了粘贴后编辑的数据。由于这些数据的质量至关重要，我们设计了一套简单的启发式方法，将粘贴后调整的概念限制在靠近原始粘贴位置的调整范围内。利用这些启发式方法，我们从前几个月中提取了一个训练数据集，并手动评估了生成的示例，不断迭代，直到达到提取启发式方法的最佳状态。在此过程中，我们注意到 28% 的粘贴没有后续编辑（不同编程语言之间的差异从 23% 到 41% 不等）。我们将这些示例保留在训练数据集中，因此模型也可以学习输出“无需编辑”。
我们使用了来自DIDACT 的针对编码相关任务进行预先训练的模型，并使用带注释的数据集对其进行了微调。
训练数据准备。
速度与准确性之间的适当平衡
为了让开发人员保持流畅，模型必须既快速又准确。它需要在建议完全准确的编辑和显示可能提供一些价值但需要后续更改的推测性建议之间取得适当的平衡。
我们的探索始于任意选择的基线模型，该模型的精确匹配精度为 65%，即建议与评估集中的预期目标完全匹配的百分比。在离线实验中，我们迭代了不同大小和不同属性的模型，结果我们只实现了微小的质量改进，但代价是延迟明显增加。经过多次迭代实验和训练数据优化，我们确定延迟约为 150 毫秒，这导致模型在 56% 的评估案例中显示了建议。
寻找正确的用户体验（UX）
我们的目标是设计一个简单的交互模型，以清晰及时的方式建议高置信度的编辑。建议置信度由离线评估阶段获得的分数阈值设定，设置为与原始训练数据中的 65% 的建议完全匹配。如果建议通过此阈值，则会在编辑器中显示装饰性 UI 元素。为了避免打断流程，如果用户执行了除接受建议之外的任何其他操作，建议将被自动丢弃。
显示建议的时间足够长
我们向大约 3000 名工程师内部推出了 Smart Paste 的测试版，并观察了他们的交互行为。我们注意到，在约 27% 的情况下，建议被丢弃，用户甚至没有注意到它们（即，在显示建议后不到 500 毫秒）。为了缓解这种情况，我们在显示建议后增加了一个 1.5 秒的窗口，在此期间，简单的光标移动不会丢弃它。我们发现，这让用户能够注意到建议，而不会用过时的信息污染用户界面。这一变化将接受率提高了约 15%。
视觉模式
最初，我们的 IDE 中有两种 UI 模式来显示建议的编辑：灰色文本（类似于用于代码完成的文本）或完整差异视图。前者无法显示删除，而后者会给用户带来很大的认知负担，造成不必要的干扰。因此，我们决定探索各种新颖的模式来可视化建议。
自动应用
我们考虑自动应用建议的编辑并突出显示更改，以便用户查看并可能恢复它们。
SmartPaste-3-自动应用
自动应用以粗体和下划线显示插入/修改的标志文件。
虽然我们的 AI 爱好者早期测试人员群体对这种模式的整体反应非常积极，但在我们随后的 UX 研究中接受采访的其他用户表达了担忧，并对可能不被注意的不良代码更改感到不安。此模式下默认不显示建议删除，这加剧了这个问题。
我们得出结论，自动应用模式不仅会降低用户对智能粘贴的信任，还会降低其他 AI 功能的信任，因此我们决定不使用它。
内联差异预览
最后，我们考虑以内联差异的形式直接在编辑器中显示插入和删除的片段，用户必须通过已建立的 TAB 快捷方式（用于内联代码完成和IntelliSense）明确接受。
SmartPaste-4-InlineDiff
内联差异突出显示了tryfromenv的删除（删除线）和flagfile的插入（斜体和较低的不透明度）。
总体而言，用户反馈（来自内部论坛、讨论和用户体验研究）都十分积极，表明此模式做出了正确的权衡，即它允许用户保持控制，同时提供对建议更改的充分概述。我们为 Google 的 Smart Paste 选择了这种方法。
未来考虑
将来，我们计划重新考虑针对小的、高可信度的更改的自动应用模式。与包含 10 到 100 个字符的建议相比，少于 10 个字符的建议的接受率几乎只有后者的一半。我们推测这可能是因为用户在粘贴后立即自行添加了建议的更改（例如，在粘贴整行后添加缺少的分号），从而使建议变得过时。
SmartPaste 的下一步是探索该模型在复制粘贴交互之外提供有用建议的能力。受该功能在现实世界中的使用情况的启发，例如在重命名和复制粘贴后自动调整对属性的所有引用（如下所示），我们计划研究不同的触发机制和用户体验解决方案。
用户剪切并粘贴修改后的字符串以在返回字符串上触发粘贴建议。
结果
在对大约 40,000 名工程师的用户行为进行检查后，我们发现 IDE 中所有粘贴操作中有 6.9% 使用了智能粘贴，接受率为 42.5%，这为开发人员节省了大量精力。
SmartPaste-6-结果
漏斗显示了原始粘贴事件和已接受的 AI 生成的建议之间的过滤步骤，该步骤是从 Google 的生产使用情况中提取的。
仔细检查后发现，该模型在所有粘贴事件中生成了 48.4% 的置信度足够高的建议。然后，只有当建议可见时间超过 500 毫秒时，我们才会将其视为“显示在屏幕上”，以便用户有时间阅读和考虑它。目前，生成的建议中有 33.6% 符合此标准（占所有粘贴事件的 16%）。在这些显示的建议中，42.5% 被用户接受，因此占 IDE 中所有粘贴事件的 6.9%。
有趣的是，随着时间的推移，接受率不断提高，而模型或用户体验却没有发生任何重大变化。我们推测这是由于学习曲线和对 Smart Paste 的熟悉程度，因为代码作者随着时间的推移学会了信任和使用它。
结论
我们推出了智能粘贴功能，这是一项新功能，可对粘贴的代码进行 AI 生成的上下文感知调整。该功能现已在 Google 最常用的 IDE 中默认启用，Google 员工每周会接受数十万条建议。
致谢
这项工作是 Google 核心系统和体验团队、Google Research 和 Google DeepMind 许多人共同努力的成果。我们想向 Alexander Frömmgen 表示深深的谢意，他是这项工作的主要贡献者和推动者之一，感谢他的所有贡献、指导和有益的建议，帮助确保了 Smart Paste 的成功。我们还要感谢 Guilherme Herzog 为将该功能推广给更广泛的受众所做的所有贡献。我们还要感谢 Kristóf Molnár 的专业知识和帮助，使这篇文章得以推广给更广泛的受众。如果没有 DIDACT的辛勤工作和咨询，以及我们所有团队成员 Adam Husting、Alberto Elizondo、Ambar Murillo、Boris Bokowski、 Brett Durrett、Chris Gorgolewski、Damien Martin-Guillerez、David Tattersall、David Zhang、Gabriela Surita、Henrik Muehe、Iris Chu、Juanjo Carin、Kevin Villela、Madhura Dudhgaonkar、Maxim Tabachnyk、Nimesh Ghelani、Niranjan Tulpule、Pierre-Antoine Manzagol、Satish Chandra、Siddhant Sanyam、Stoyan Nikolov、Ugam Kumar、Vahid Meimand、Vincent Nguyen 和 Zoubin Ghahramani 的贡献，这项工作就不可能完成。感谢 Tom Small 和 Delphine Carlson 为本文制作图表。
评论