VBA手写代码vs AI语音编程：效率差距到底有多大

在日常办公中，Excel数据处理是每个职场人绑定的基本功。一个看似简单的"按部门合并姓名"需求，却能清晰展现传统编程与AI编程之间的巨大效率鸿沟。B站UP主通过一个实际案例，对比了公式法、手写VBA代码和AI语音编程三种方式，结果令人深思。

需求场景：按部门合并姓名

这个案例的需求非常典型：左边是原始数据，包含部门和姓名两列（A2到B16区域），右边是期望的结果——将同一部门下的所有姓名合并到一起，并按照特定格式输出。

原始数据与目标结果

看起来简单，但实际操作中暗藏不少坑。这类"分组合并"需求在实际工作中非常常见，比如按部门汇总人员名单、按类别合并产品信息等，数据量一大就让人头疼。

从技术角度来看，"按部门合并姓名"本质上是数据库领域中经典的GROUP BY + 字符串聚合操作。在SQL中，这可以通过GROUP_CONCAT（MySQL）或STRING_AGG（SQL Server 2017+ / PostgreSQL 9.0+）等函数轻松实现——只需一行SELECT department, STRING_AGG(name, '、') FROM employees GROUP BY department即可完成。但Excel作为电子表格工具，其设计初衷是面向单元格级别的数值计算，原生并不具备字符串聚合函数。在很长一段时间里，用户只能依赖CONCATENATE函数逐个拼接，或者借助辅助列配合IF、INDEX-MATCH等函数进行曲线救国。直到2018年Office 365版本引入了TEXTJOIN函数，配合FILTER函数才勉强实现了类似功能——=TEXTJOIN("、",TRUE,FILTER(B:B,A:A="技术部"))。但对于使用Excel 2016及更早版本的用户来说（据统计，截至2023年仍有超过30%的企业用户使用非订阅版Office），这仍然是一个需要借助辅助列或VBA才能解决的难题。这种功能缺口恰恰反映了电子表格工具与关系型数据库在数据处理范式上的根本差异。

传统方案的痛点

公式法：能用但问题多

视频中首先演示了使用Excel函数来实现这个需求。虽然通过复杂的公式组合确实可以完成任务，但存在几个明显的问题：

中间出现空行时会报错：数据不连续的情况下，公式容易失效
无法动态更新：当原始数据发生变化时，结果不能自动刷新
性能瓶颈：数据量较大时，复杂的数组公式会导致Excel严重卡顿

关于性能瓶颈，这里有必要深入解释一下。Excel中的数组公式（CSE公式，即需要按Ctrl+Shift+Enter确认的公式）之所以会导致卡顿，是因为它的计算机制与普通公式截然不同。普通公式只对单个单元格求值，而数组公式需要在内存中构建一个临时数组，对每个元素逐一运算后再返回结果。当数据量达到数千行时，嵌套的数组公式会产生指数级的计算量——例如一个涉及1000行数据的嵌套数组公式，可能需要执行100万次（1000×1000）比较运算。更糟糕的是，Excel的计算引擎本质上是单线程的（尽管从Excel 2007开始支持多线程重算，但数组公式中的许多操作仍然无法并行化），在面对这种密集计算负载时会明显变慢，严重时甚至导致整个工作簿无响应。此外，每次编辑任意单元格都会触发全表重算，进一步加剧了卡顿问题。微软在Excel 365中引入的动态数组引擎（Dynamic Arrays）通过"溢出"机制在一定程度上缓解了这个问题——公式只需在一个单元格输入，结果会自动溢出到相邻单元格，减少了重复计算。但对于复杂的字符串拼接场景，尤其是需要去重、排序后再合并的需求，性能瓶颈依然存在。

这些问题在小数据量时或许可以忍受，但在实际业务场景中，数据往往成百上千行，公式法的局限性就会被无限放大。

手写VBA代码：门槛高、调试难

第二种方案是手写VBA代码。UP主现场演示了编写过程：需要定义变量、设置字典对象、遍历数据并生成结果。

手写VBA代码运行结果

VBA（Visual Basic for Applications）是微软在1993年随Excel 5.0一同推出的嵌入式编程语言，几乎内置于所有Office应用程序中。它基于Visual Basic语言，提供了对Office对象模型（Object Model）的完整访问能力，可以操控工作表、单元格、图表、数据透视表等几乎所有Excel元素。在这个案例中，VBA的Dictionary对象（来自Microsoft Scripting Runtime库）是处理分组聚合问题的利器——它以键值对（Key-Value Pair）的形式存储数据，可以通过.Exists(key)方法在O(1)时间复杂度内判断某个部门是否已经出现过，并将新的姓名通过字符串拼接追加到对应的值中。相比之下，如果使用数组或Collection来实现同样的逻辑，就需要每次遍历查找，效率会大打折扣。

尽管VBA功能强大且与Excel深度集成，但它的开发体验基本停留在上世纪90年代：VBE（Visual Basic Editor）编辑器没有智能代码补全（IntelliSense仅提供基础的对象成员提示）、缺乏现代调试工具（没有条件断点、没有变量监视面板的实时刷新）、错误提示信息晦涩难懂（如经典的"Runtime Error 1004"几乎可以对应上百种不同的错误原因）。加上VBA的语法与当今主流编程语言（如Python、JavaScript、TypeScript）差异较大——例如它使用Dim声明变量、Set赋值对象、Sub/End Sub定义过程——这使得它的学习曲线对非程序员来说格外陡峭。值得一提的是，微软近年来已将开发重心转向Office Scripts（基于TypeScript）和Office Add-ins（基于Web技术），VBA虽然不会被移除，但已不再获得新功能更新，这进一步降低了学习VBA的长期投资回报率。

代码写完后确实能运行出正确结果，但调试过程极其痛苦：

拼写错误难以排查：少写一个字母就会报错，比如变量名拼错、关键字写错
新手不知如何调试：面对VBA的报错信息，很多人完全不知道从何下手
查资料耗时耗力：需要去论坛、文档中反复查找解决方案
连环错误：修复一个bug可能引发新的问题，陷入"改了又改"的循环

视频中特意演示了几种常见的出错场景——少写一个字符导致编译错误、变量名写错导致运行时异常。这些对于VBA老手来说可能是小问题，但对普通办公人员来说却是难以逾越的障碍。

AI语音编程：对传统方式的降维打击

接下来就是本视频的重头戏——使用AI语音编程助手来完成同样的任务。

AI编程助手界面

用自然语言描述需求，替代手写代码

UP主只需要用自然语言告诉AI：

"当前选中的表格原数据在A2到B16单元格区域，我想要的模拟结果在D2到E5单元格区域，我想让你把结果生成到D13单元格。用VBA代码帮我生成，要求生成结果跟模拟结果的表头以及格式一样，数据能够隔一行变个色。"

这段话就是全部的"编程"过程。不需要知道字典对象怎么用，不需要了解循环语法，甚至不需要打开VBA编辑器。

AI自动识别错误并智能纠正

你可能没注意到，UP主在描述需求时，模拟结果的数据区域其实说错了，但AI自动识别并纠正了这个错误。这体现了AI对上下文语义的深度理解能力——它不是机械地执行指令，而是能够结合实际数据进行判断。

AI自动生成结果

这背后涉及多个AI技术的协同配合，形成了一条完整的语音到代码（Speech-to-Code）的技术管线。首先是语音识别（ASR，Automatic Speech Recognition）环节，通过深度学习模型（如基于Transformer架构的Whisper等）将用户的语音信号转换为文本，这一步需要处理口语化表达、停顿、语气词等噪声。然后是自然语言理解（NLU，Natural Language Understanding）环节，大语言模型（LLM，如GPT-4、Claude等）对文本进行语义解析，从非结构化的自然语言中提取出结构化的意图信息——包括数据源范围（A2:B16）、目标位置（D13）、输出格式要求（与模拟结果一致）、附加样式（隔行变色）等关键参数。这一步的核心挑战在于意图消歧：同一句话可能有多种理解方式，模型需要结合上下文选择最合理的解释。最后是代码生成环节，模型基于对VBA语法规则和Excel对象模型（如Range、Worksheet、Interior.Color等属性）的训练知识，将结构化意图转化为可执行的VBA代码。

特别值得关注的是模型的上下文推理（Contextual Reasoning）能力——当用户说错数据区域时，AI并不是简单地"听什么写什么"，而是能够读取工作表的实际数据分布，将语音描述与单元格内容进行交叉验证，发现两者之间的矛盾（例如用户说的区域是空白的，而实际数据在另一个区域），并自动修正。这种能力源于大语言模型在海量代码库（如GitHub上数百万个VBA项目）和技术文档上的预训练，使其具备了对Excel操作场景的深层理解。本质上，这已经超越了简单的"语音转代码"映射，而是一种具备常识推理和错误容忍能力的智能编程代理（Coding Agent）。

从生成到运行的全自动闭环

AI完成了从代码生成到调试运行的完整闭环：

自动编写代码：根据自然语言需求生成完整的VBA代码
自动调试：发现问题后自行修复，无需人工干预
自动运行：直接执行代码并输出结果
自动验证：对比生成结果与预期结果，确保准确性

这种"生成-执行-验证-修复"的自动闭环在AI领域被称为Agentic Workflow（智能体工作流）。与传统的单次生成不同，AI Agent会在一个循环中反复迭代：生成代码后先在沙箱环境中试运行，如果报错则分析错误信息并修改代码，直到运行成功；然后将输出结果与用户描述的预期进行比对，如果不匹配则进一步调整逻辑。这种自主迭代能力大幅减少了人工干预的需要，也是当前AI编程工具（如Devin、OpenHands等AI软件工程师）的核心技术路线。

整个过程中，用户只需要等待几十秒，就能得到一个格式规范、数据准确、甚至带有隔行变色效果的最终结果。

公式法、手写VBA与AI编程的效率对比

维度	公式法	手写VBA	AI编程
学习成本	中等	很高	极低
实现时间	较长	长	极短
调试难度	中等	很高	无需调试
可维护性	差	一般	好
大数据适应性	差	好	好

对普通办公人员的启示

这个案例虽然简单，但它揭示了一个深刻的趋势：AI正在将编程能力民主化。过去需要专业VBA技能才能完成的自动化任务，现在只需要清晰地描述需求就能实现。

"编程民主化"（Democratization of Programming）是近年来科技行业最重要的趋势之一，其核心理念是让不具备专业编程背景的人也能创建软件解决方案。这一趋势经历了几个关键阶段：最早是可视化编程时代（如2000年代的Visual Basic拖拽式界面设计），随后是低代码/无代码平台的兴起（如微软Power Platform、Mendix、OutSystems，用户通过拖拽组件和配置规则来构建应用），而如今则进入了AI代码生成的新纪元（如GitHub Copilot、Cursor、通义灵码、Amazon CodeWhisperer等工具，直接将自然语言转化为可执行代码）。据Gartner预测，到2026年，80%的软件产品将由非专业开发者（即"公民开发者"，Citizen Developer）构建或参与构建。在办公自动化领域，这一趋势尤为明显：微软已将Copilot深度集成到Microsoft 365全家桶中，用户可以用自然语言指挥Excel进行数据分析、生成图表甚至编写宏；谷歌也在Google Workspace中推出了Duet AI（现已更名为Gemini for Workspace），提供类似的AI辅助能力。

但这并不意味着学习编程毫无价值。恰恰相反，懂得编程逻辑的人能够更精准地向AI描述需求，从而获得更好的结果。这在AI领域被称为Prompt Engineering（提示工程）——如何组织语言、提供上下文、设定约束条件，直接决定了AI输出的质量。AI编程助手降低的是语法层面的门槛，而需求分析、逻辑思维、边界条件考量这些核心能力依然不可替代。值得注意的是，AI生成的代码并非总是完美的——它可能存在边界条件处理不当（如空数据行、特殊字符）、性能不够优化（如不必要的全表遍历）、安全隐患（如宏病毒风险）等问题。斯坦福大学2023年的一项研究表明，使用AI辅助编程的开发者虽然效率提升了55%，但代码中的安全漏洞数量也增加了约30%。因此，具备基本编程素养的用户能够审查和优化AI输出，这正是**"人机协作"**（Human-AI Collaboration）模式的核心价值所在——AI负责繁重的代码编写，人类负责质量把关和决策判断。

对于职场人来说，现在最值得投入的不是去死记VBA语法，而是学会如何与AI高效协作——清晰地定义问题、准确地描述需求、合理地验证结果。这才是AI时代真正的"编程能力"。