像 ChatGPT 和 GitHub Copilot 这样的大语言模型 (LLM) 已经席卷了软件开发领域，承诺带来一场真正的革命。我们都听过这样的故事——开发者在几分钟而非几小时内完成复杂任务，AI 结对程序员永不疲倦，团队运作速度似乎比以往任何时候都快。这种兴奋感是显而易见的。公司正争相将这些工具整合进工作流程，而开发者们也在重塑自己的开发方式，常常用一个对 AI 助手的快速提问代替过去对文档或 Stack Overflow 的深入查阅。

但随着热度的降温，一个更复杂的图景开始浮现。这个软件开发的新支柱究竟是坚实的基础，还是脆弱的拐杖？使用 LLM 真的能提升生产力，还是我们正在慢慢用技能换取便利？每一个节省数小时的故事背后，都伴随着另一个关于编码直觉丧失、潜在漏洞以及批判性思维退化的警示。

这正是当下软件从业者面临的张力: 一种微妙的平衡。最近，Ferino、Hoda、Grundy 和 Treude 撰写的研究论文——《行走在软件开发的大语言模型钢丝上: 从业者视角》 (“Walking the Tightrope of LLMs for Software Development: A Practitioners’ Perspective”) 深入探讨了这一问题。研究团队并未采用基准测试或度量指标，而是对 22 位软件从业者进行了详细访谈，以揭示 LLM 如何真正重塑日常工作、协作乃至个体特质。他们的研究揭示了益处、弊端，以及尤其重要的——帮助开发者在这根钢丝上平衡前行、不致坠落的策略。

本文将解析他们的洞见，并探讨开发者如何战略性地运用 LLM——在推动创新的同时，守护造就卓越软件的技艺与批判思维。

场景设定: 从炒作到现实

研究人员从三个看似简单的问题开始:

  • RQ1. LLM 如何推动软件开发者前进? —— 有哪些可见的实际益处？
  • RQ2. LLM 如何阻碍开发者发展? —— 哪些隐藏的成本与挑战值得关注？
  • RQ3. 开发者如何实现对 LLM 的平衡使用? —— 我们如何妥善管理这种取舍？

为回答这些问题，研究团队走进了“一线”——倾听那些每天都在使用基于 LLM 工具的从业者们的真实声音。

研究方法: 倾听一线开发者的声音

这项研究的优势在于其深度。研究人员对来自世界各地的 22 位从业者进行了半结构化访谈，他们的角色涵盖软件工程师、数据科学家、商业智能分析师和科研开发者。

一张表格，展示了 22 位研究参与者的人口统计信息，包括他们的角色、领域、国家、经验水平以及他们参与了第几轮研究。

研究参与者的人口统计信息——来自五大洲、行业经验各异的开发者。

为分析这类丰富的定性数据，研究人员采用了 社会技术扎根理论 (Socio-Technical Grounded Theory, STGT) ——一种严谨的定性方法，既关注人的维度也考虑技术因素。实际上，这意味着从参与者的言语中直接构建理论，而非依据既定假设。STGT 尤其适合研究现代软件工程，因为此领域同时交织着情感、社会与技术要素。

整个研究分为 三个迭代轮次 展开，每一轮都随着新洞见的出现而进一步提炼概念与分类。

一张流程图，展示了三轮研究的方法论，从方案制定开始，经过初步访谈，再到三轮访谈与分析，每一轮都对概念和访谈指南进行提炼。

该研究的三轮方法论——访谈与分析的迭代循环随着时间推移不断深化洞察。

研究团队从访谈记录中，系统地将 原始引述 转化为 编码 , 再到 概念 , 继而形成更高层级的分类。

一张图表演示了定性编码过程，展示了原始数据 (访谈引述) 如何转化为编码，然后是概念、子类别，最终形成像“使用 LLM 的影响”这样的主类别。

STGT 分析过程——原始开发者体验如何演变为结构化的影响类别。

现在，让我们看看他们的发现。

优势: LLM 如何推动开发者前进

LLM 的益处贯穿 个人、团队、组织 和 社会 四个层面。

个人层面

这是影响最直接和最显著的部分。

  • 促进代码开发与节省时间: 大多数参与者报告他们的工作流程显著加速。通过自动化重复性或样板代码任务，LLM 让开发者能将时间投入到更复杂的问题上。一位开发者言简意赅地说: “你花在简单问题上的时间减少了，而花在复杂问题上的时间增多了。”

  • 保持心流状态: 在软件开发中保持高度专注 (所谓的“心流状态”) 极具挑战。LLM 通过在 IDE 内即时处理语法或查询、减少频繁的上下文切换，帮助开发者迅速回归专注。一位工程师指出: “过去在网上找答案要花很久时间，ChatGPT 能立刻让我重回节奏。”

  • 支持持续学习: 许多开发者并未用 LLM 取代学习，而是将其作为导师，用以探索不同方法、理解新语言或学习领域知识。一位数据分析师反思道: “LLM 给了我不同的视角，也许是更简洁的做法。我从中学习。”

  • 创造安全空间: 对于初级开发者而言，LLM 是一个不会评判的倾听者。它提供即时反馈，而不必担心“问了愚蠢的问题”。一位研究员提到: “你可以把同一个问题问 ChatGPT 十遍，它从不会评判，只是不断地解释。”

一张图表将各种软件开发任务 (如头脑风暴、代码生成和调试) 与它们在个人层面带来的好处 (促进代码开发、节省时间和保持心流) 联系起来。

多种开发任务与生产力、学习和保持心流等核心益处相互关联。

超越个人层面

  • 团队层面: 团队中断更少——初级开发者可迅速从 AI 获得解答，高级开发者则能专注本职工作。
  • 组织层面: 更快的调试和自动化带来成本节约，尤其在生产事故处理中更显著。
  • 社会层面: LLM 激发创业精神，通过快速原型能力，让新创者拥有一个“虚拟联合创始人”。

劣势: LLM 如何可能阻碍开发者发展

每场革命都伴随副作用。这项研究揭示了一系列值得警惕的权衡。

个人层面

  • 拖慢开发进度并增加负担: 讽刺的是，当 LLM 陷入错误建议或生成不准确内容时，开发者往往需要重新开始或反复验证结果。一位数据工程师分享道: “继续同一个聊天，它就一直重复错误。我不得不从头再来。”

  • 技能退化与学习缺失: 最普遍的担忧是技能的萎缩。过度依赖 LLM 的新人难以建立坚实的问题解决基础；而资深工程师则发现自己的“编码肌肉”在减弱: *“有时我会忘记基础知识，因为我已经习惯自动补全了。”*一位参与者这样坦言。

  • 性格上的负面变化: 除技术能力外，一些开发者自述变得更“懒惰”、缺乏好奇心。一位机器学习科学家承认: “我变懒了——就连小函数都问模型，而不是自己查文档。”

  • 声誉受损: 最终，AI 生成代码的漏洞不会污点 AI 自身，而是开发者的名声。一位参与者说得直白: “当你把代码推送到 Git 时，署名的是你，不是 LLM。”

一张图表将软件开发任务与它们在个人层面可能导致的缺点联系起来，例如降低代码质量、阻碍技能发展以及削弱开发者的心智模型。

若过度依赖，LLM 自动化的任务可能导致代码质量下降或技能成长受限。

团队、组织与社会层面

  • 团队层面: 自助获取便利可能削弱导师机制。初级开发者越来越多向 LLM 寻求帮助而非资深同事，从而减少了面对面的学习互动。
  • 组织层面: 企业在 安全、隐私 和 许可 上面临挑战。许多公司禁止在专有代码上使用公共 LLM 以防泄密或法律风险。
  • 社会层面: 更广泛的伦理问题浮现——LLM 被用于技术面试作弊或生成虚假信息，损害社会信任。参与者也担心自动化可能减少低技能开发岗位。

寻求平衡: 成功地行走钢丝

既然优势与风险并存，开发者该如何找到平衡？论文的第三个研究问题 (RQ3) 基于从业者经验总结出实用的建议:

  1. 务实——知道何时使用: 把 LLM 当作工具，而非替代品。可以用它来处理语法、模板代码、文档或调试，但要懂得什么时候自己动手更高效。一位开发者提醒: “如果它浪费时间，就停下来，自己做。”

  2. 在节省时间与学习之间保持平衡: 便利可能抑制技能成长。要抵制把所有问题都交给模型解决的冲动；先自己尝试，再寻求辅助。一位参与者总结理想心态: “它帮我节省时间，但也让我学到东西。”

  3. 聚焦代码优化，而非完整生成: 熟练的用户倾向于利用 LLM 改进与审查代码，而非不加监督地生成整个模块。一位开发者表示: “我先写逻辑，然后让 Copilot 帮我补全或优化。”

  4. 灵活组合工具: 不同模型擅长不同任务。开发者报告他们会结合 ChatGPT 处理需求、Copilot 负责编码、Claude 解释概念。视 LLM 为工具箱，而不是万能解。

  5. 隐私重要时本地运行: 在处理敏感数据时，越来越多开发者使用 Ollama 或 LM Studio 等工具，将开源模型本地部署以保护专有代码。

核心要点: 掌控是关键

LLM 正在重塑软件开发——但转变不意味着放弃掌控。最有效的开发者都是有意图、务实且自律的。他们用 AI 助手加速基础任务、提升理解，同时保持深度推理、创造性问题解决和质量把控在人类之手。

一张图表将本研究发现的优缺点与其他四篇相关研究论文的发现进行比较，展示了研究结果的重叠之处以及本研究做出的新贡献。

与相关研究的对比——本研究提供了更广泛、多层次的视角并提出平衡采用的具体策略。

最终，正如研究人员总结的那样, 平衡的掌控才是答案 。 LLM 的优势伴随权衡，长期成功取决于开发者智慧地管理这些权衡的能力。

LLM 能带来生产力、创造力与心流——前提是我们要始终是架构师，而非乘客。这根钢丝确实存在，但只要保持意识、自律与好奇心，开发者就能自信而稳健地行走其上——驾驭 AI 的力量，同时不失定义我们这门技艺的技能与直觉。