LLM重塑软件开发：效率革命与开发者角色的演变

唯有变化才是永恒。——赫拉克利特

在当前时代，软件的产出速度已经达到了历史性的高峰。以ChatGPT、GitHub Copilot等为代表的大语言模型（LLM）驱动的代码生成工具和编程助手，正在深刻变革软件开发者的工作模式。LLM不再仅仅是辅助工具，而是转变为一个随时可用的虚拟合作伙伴。AI Coding 正成为全球科技巨头和初创企业竞相布局的战略核心。

然而，尽管沉浸在 AI Coding 中的软件开发者们将工作效率提升了 26%，但也不得不面对一个新的挑战：当 AI 能够生成可直接使用的代码，我们仍在“开发”什么？当效率被 AI 极度放大，人类的创造力与深度思考是否正在被削弱？

近期，莫纳什大学与新加坡管理大学的研究团队通过深度访谈22名软件开发者，深入探讨了 LLM 对软件开发领域的实际影响，以及如何有效管理这种影响。

论文链接：https://arxiv.org/pdf/2511.06428

研究结果表明，LLM 有助于加速开发进程、维持开发流程的顺畅、促进创新创业等，但也存在潜在风险，如可能损害开发者声誉、影响个人特质（如导致惰性）、阻碍开发者技能提升等。

此外，研究团队还提出了一系列关于如何最优使用 LLM 进行软件开发任务的实用建议。

研究方法

为了深入理解软件从业者在采用 LLM 进行软件工程活动时的真实体验，研究团队采用了社会技术扎根理论（STGT）方法。

该研究共分三轮进行，基于对22位软件从业者的访谈数据展开收集与分析。在第一轮中，研究团队采访了6位初级开发者；在第二轮中，他们采访了13位初级与有经验的开发者，以提炼核心概念与类别；在第三轮中，他们又进行了3场访谈，以验证和完善理论框架。

图｜研究方法的全流程概述

在 LLM 使用情况方面，多数参与者使用过多种 LLM 工具，其中 ChatGPT 是最常用的选择。大多数参与者使用 LLM 的时间超过一年，约 59% 的参与者每天与 LLM 至少交互 6 次。

图｜受访者使用 LLM 的情况

研究结果

基于上述方法，研究团队根据个人、团队、组织和社会层面，识别和分类了采纳 LLM 进行软件开发任务的益处和弊端。具体如下：

LLM 如何帮助软件开发者进步？

个人层面，LLM 显著提升了软件开发者的效率和学习能力。LLM 能自动生成样板代码、修复语法错误、提供即时反馈，帮助开发者节省时间、减少工作流中断并维持“心流”状态。

同时，LLM 也是学习与反思的得力工具——开发者能借助它理解陌生代码库、掌握新编程语言、比较不同解决方案。LLM 还能够为开发者提供心理支持，让他们敢于提问，不再担心暴露知识盲区，从而增强自信心与主动性。

图｜LLM 对个人开发者的积极影响

团队层面，LLM 减少了开发者之间的协作干扰与沟通成本。新手能够先借助 LLM 自主解决问题，再向同事寻求帮助，使团队运转更高效。LLM 还能提供“第二意见”，帮助团队突破思维定式，激发整体创造力。

组织层面，LLM 为软件开发公司节约了时间和成本。LLM 能够加速整体调试、错误排查与代码审查等流程，特别是对中小型企业而言，能以更精简的人力完成更复杂的任务。

社会层面，LLM 促进了创新创业生态。许多开发者用 LLM 快速构建原型、学习商业与技术知识，降低了创业门槛。LLM 甚至可以作为日常生活中的智能顾问，协助解决时间规划和信息检索等常见问题。

LLM 如何阻碍软件开发者发展？

当然，基于 LLM 的 AI Coding 也并非没有弊端。例如，许多软件开发者发现，LLM 在生成代码或提供建议时容易出现错误或“幻觉”，反而拖慢了项目进度，还需要额外时间验证结果的正确性。而且，频繁的上下文切换、提示分解和反复修正也让工作量不减反增。

过度依赖 LLM 也可能削弱开发者的代码理解力与学习动力。一些开发者提到，长期使用 LLM 会导致自己变得懒惰、冷漠，甚至对自身能力产生怀疑；新手则更容易陷入“让 AI 替我思考”的陷阱，导致技能发展停滞。更严重的是，当 LLM 生成错误代码时，责任仍由开发者承担，可能影响个人职业声誉。

图｜LLM 对个人开发者的负面影响

此外，由于担心 LLM 输出的代码涉及版权或许可问题，部分软件开发公司会明令禁止员工使用 LLM。而且，LLM 生成代码中可能隐藏安全漏洞，引发潜在风险。成本问题也是一大阻力——频繁调用 LLM 需要付费，增加了企业的运营负担。

最后，LLM 的普及也让一些人面临失业的风险。虽然高端开发者依旧不可或缺，但依赖经验和重复性工作的技术岗位正变得日益脆弱。

软件开发者如何正确使用 LLM？

那么，既然 AI Coding 是未来的一大趋势，开发者如何平衡利弊呢？根据访谈结果，研究团队发现，许多开发者会在不同 LLM 之间反复试用，直到找到最契合自己工作需求的 LLM。

通过这种比较，他们逐渐认识到 LLM 并非“智能体”，而只是基于统计的工具，于是选择使用不同 LLM 解决不同问题，例如，用 ChatGPT 处理需求沟通，用 Copilot 辅助编码，这反映了软件工程向“代理式”系统演进的趋势。

此外，不少开发者更倾向让 LLM 参与代码优化而非直接生成，从而保持对逻辑与结构的控制。他们甚至出于隐私考虑，选择在本地运行模型，哪怕牺牲部分便捷性。

当前，软件开发者需要与 LLM 维持一种成熟的关系：既信任其能力，又保持理性距离，用人机协作的方式扩展自己的边界，而不是被取代。总之，无论使用什么工具，在软件开发工作中都离不开“直觉”。这里的“直觉”不是模糊的感觉，而是开发者在长期经验积累中形成的快速判断能力。它是一种经验性思维，帮助开发者在复杂和不确定的情境下做出决策。

这种基于经验的直觉在开发者与 LLM 协作时，起到了“安全阀”的作用：当 LLM 提供错误或误导性的建议时，帮助开发者识别出问题、避免盲从模型的输出。那么，另一个问题来了，当开发者越来越依赖 LLM 生成的代码或建议，他们的直觉是否会被侵蚀呢？