💻 computer science

How Do Developers Interact with AI? An Exploratory Study on Modeling Developer Programming Behavior

这项针对 76 名开发者的混合方法研究引入了 S-IASE 模型，通过整合意图、行动、工具和情感来刻画 AI 辅助编程的多维本质，揭示出 AI 的使用在促进更稳定的情感流动和专注的代码生成的同时，也引发了诸如冒名顶替综合征等复杂的心理反应。

原作者： Yinan Wu, Ze Shi Li, Kathryn Thomasset Stolee, Bowen Xu

发布于 2026-05-01

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Yinan Wu, Ze Shi Li, Kathryn Thomasset Stolee, Bowen Xu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

将软件开发想象成一个复杂的烹饪过程。几十年来，厨师（开发者）一直独自遵循食谱、切配食材并管理炉灶。但最近，一种新型的“智能副厨”（如 GitHub Copilot 或 ChatGPT 等 AI 助手）已走进厨房。这些副厨能即时提供食谱建议、切配蔬菜，甚至摆盘。

您提供的这篇论文，就像是对真实厨师开始使用这些智能副厨时发生情况的详细观察。研究人员想知道：厨师是只是坐在一旁观看，还是改变了他们的烹饪方式？在副厨工作时，他们在想什么、感受如何？

以下是他们发现的简明总结：

1. 烹饪的新“食谱”：S-IASE 模型

在这项研究之前，研究人员大多从外部观察厨师，统计他们切菜或搅拌的次数。他们忽略了厨师头脑内部正在发生什么。

研究人员创建了一种观察烹饪的新方法，称为S-IASE 模型。他们不再仅仅观察双手，而是同时关注四个正在发生的事项：

状态（State）： 我们目前处于食谱的哪个阶段？（例如，“酱汁快烧焦了”或“我们需要找一种香料。”）
意图（Intention）： 厨师试图做什么？（例如，“我需要修复这个错误”或“我想让这个过程更快。”）
行动 + 工具（Action + Tool）： 他们在做什么，使用了什么工具？（例如，“向副厨寻求建议”与“在书中查找香料”。）
情绪（Emotion）： 厨师感觉如何？（例如，“开心”、“沮丧”或“内疚”。）

他们发现，当厨师使用智能副厨时，这四个方面会以一种复杂的方式相互变化并交织在一起。

2. “信任但验证”的舞蹈

研究人员注意到厨师使用 AI 时有一种特定的节奏。这不仅仅是“询问并接受”，而更像是一场乒乓球游戏：

厨师向 AI 询问解决方案。
AI 抛回一个建议（“发球”）。
厨师立即检查它、微调它或运行测试（“回球”）。
如果有效，他们继续前进；如果不有效，他们再次询问。

类比： 想象一位不再通读整本食谱书的厨师。相反，他们问副厨：“怎么做这个酱汁？”副厨说：“加盐。”厨师尝了尝，说：“太咸了”，然后问：“好吧，少放点盐怎么样？”他们不断来回交流，直到味道正确。他们创造和验证的速度快得多，但在开始前深入阅读说明的时间却减少了。

3. 情绪过山车（或缺乏过山车）

该研究比较了两组厨师：

A 组： 使用智能副厨。
B 组： 必须从零开始烹饪，没有任何帮助。

发现： 使用 AI 的那一组情绪体验要平稳得多。他们感到压力更小，沮丧更少。他们更快乐，也更自信。

原因？ 因为 AI 帮助他们迅速摆脱困境。
隐患： 尽管他们更快乐，但有些厨师感到一种隐秘的内疚。他们觉得自己是“冒名顶替者”（骗子）。一位厨师说：“我在 AI 的帮助下完成了这道菜，但我感到内疚，因为我没有学会如何自己制作它。”他们担心，如果没有亲自做这项工作，他们就没有真正学到东西。

4. “展示给我，而不是告诉我”的问题

有时，智能副厨给出的说明在技术上是正确的，但因为只是文字而难以遵循。

场景： 副厨说：“点击右上角的按钮。”
问题： 厨师找不到那个按钮。文字太模糊。
反应： 厨师放弃 AI，转向人类论坛（如 Stack Overflow），或寻找图片/图表来确切看到按钮在哪里。
教训： 厨师需要视觉辅助。他们想看到步骤，而不仅仅是阅读它们。当 AI 只提供文字时，厨师会卡住，不得不去别处寻找图片。

5. 谁最频繁地使用 AI？

研究发现，厨师在两种情况下最有可能信任 AI：

当他们非常熟悉这道菜时（他们了解基础知识，所以只想要速度）。
当他们完全迷失时（他们不知道该怎么办，所以需要起点）。

中间地带： 如果厨师对这道菜了解一点但不是专家，他们实际上对 AI 持怀疑态度。他们会向 AI 寻求帮助，但随后会双重检查所有内容，因为他们尚未完全信任 AI 的答案。

总结

该论文得出结论：AI 不仅仅是一个让编码更快的工具；它改变了开发者的整个人格。

他们变得更加专注于构建和测试，而不是阅读和规划。
他们感到压力更小，但有时因依赖帮助而感到更内疚。
他们需要视觉辅助，因为纯文字说明往往让他们受挫。

研究人员构建了这个"S-IASE"模型，以帮助未来的 AI 设计者理解：他们不仅仅是在构建一个代码生成器；他们是在构建一个影响开发者如何思考、感受和工作伙伴。

以下是论文《开发者如何与 AI 交互？一项关于建模开发者编程行为的探索性研究》的详细技术总结：

1. 问题陈述

AI 助手（如 GitHub Copilot、ChatGPT）快速融入软件工程，已彻底改变了开发实践。然而，现有研究大多聚焦于可观察的结果（如代码生成速度、缺陷减少）或狭窄的交互模式（如“加速”与“探索”）。

差距：缺乏对开发者与 AI 交互多维本质的深入理解。先前的模型通常将交互视为单一活动，或仅依赖外部观察，未能捕捉隐藏的意图、具体行动、工具使用与情绪状态之间的相互作用。
目标：构建一个综合模型，以刻画 AI 辅助背景下的开发者编程行为，捕捉状态、意图、行动、工具与情绪之间的动态反馈循环。

2. 方法论

作者开展了一项涉及76 名开发者（本科生/研究生及具有行业经验的专业人士）的混合方法用户研究。

研究设计：
- 分组：参与者被分为AI 辅助组（允许使用任何首选的 AI 工具）和非 AI 组（不使用 AI 工具）。
- 任务：基于先验知识分配了两个现实且限时（25 分钟）的软件工程任务：
  1. PyT：涉及 GitHub REST API 管理的 Python 任务（创建组织、生成令牌、创建仓库）。
  2. JavaT：涉及 MySQL 数据库操作的 Java 任务（设置、CRUD 操作、业务查询）。
- 流程：
  1. 前测问卷：收集人口统计学信息、编程经验及 AI 熟悉度。
  2. 活动：参与者在录屏的同时执行任务。
  3. 标注：参与者回顾性观看录像，并使用自定义标注工具将视频分割为时间区间。对于每个区间，他们标记：
    - 意图：行动背后的目标。
    - 行动：执行的具体活动。
    - 支持工具：使用的工具（如 AI、IDE、搜索引擎）。
    - 情绪：在 7 点效价量表上评分。
  4. 后测问卷与访谈：测量认知负荷（NASA-TLX）、自我效能感，并对 14 名参与者进行半结构化访谈，采用社会技术扎根理论（STGT）。
数据分析：
- 定量：统计分析（OLS 回归、Benjamini–Hochberg 校正）以识别聚合行为模式。序列模式挖掘（CloSpan 算法）以识别重复的状态转换。
- 定性：对访谈进行主题分析，以解释定量发现并揭示细微的情绪体验。

3. 主要贡献

本文引入了S-IASE 模型，这是一个用于建模开发者编程行为的新颖框架。

S-IASE 模型：将开发状态定义为一个元组：
$State_n \rightarrow State_{n+1} [Intention, \langle Action, Supporting Tool \rangle, Emotion]$
- 状态：当前的开发上下文。
- 意图：开发者的目标（例如，“解决错误”、“实现代码”）。
- 行动与支持工具：成对出现，以区分使用/未使用 AI 或其他工具执行的动作（例如，“编写代码” + "AI 工具”vs.“编写代码” + "IDE"）。
- 情绪：情感状态（7 点效价量表）。
标注工具：开发了一款开源工具，以促进对这四个维度的回顾性标注。
行为模式：揭示了交互的聚合（统计）模式和序列（时间）模式。

4. 主要结果

A. 聚合行为模式（RQ2）

焦点转移：AI 辅助开发者显著更多地专注于创建、评估和验证代码。与非 AI 开发者相比，他们在深度阅读和理解上花费的时间更少。
工具使用：AI 组显著较少依赖搜索引擎（如 Stack Overflow），而更多地依赖AI 工具和IDE。这表明 AI 已成为主要的知识接口。
情绪稳定性：AI 辅助参与者报告了更多积极和中性情绪，负面情绪波动较少。非 AI 参与者经历了更高的挫败感和情绪波动。
任务表现：AI 组实现了更高的完成率和功能正确性，但由于任务复杂性，整体正确率仍然较低（13%）。

B. 序列行为模式（RQ3）

“信任但验证”：观察到的主导序列是：理解上下文 $\rightarrow$ 通过 AI 实现代码 $\rightarrow$ 设计/规划新代码。这颠覆了传统的“先设计后实现”范式；开发者首先利用 AI 在代码库中获得“立足点”，然后完善架构。
迭代反馈循环：阅读 $\rightarrow$ 提示 $\rightarrow$ 编写 $\rightarrow$ 阅读。开发者将 AI 输出视为草稿，进行快速的试错循环，而非深入的初始理解。
模态不匹配：当任务需要视觉指导（如 API 设置）时，纯文本的 AI 建议失效，导致开发者回退到搜索引擎以获取视觉文档。

C. 定性洞察（访谈）

“冒名顶替”现象：尽管统计上情绪稳定，但许多 AI 辅助开发者报告了内疚、自我怀疑和冒名顶替综合征。他们感觉自己是在“作弊”或没有学习，导致在生产力（速度）与技能发展（理解）之间产生内心冲突。
自我归咎：当 AI 生成的代码失败时，开发者往往归咎于自己的提示技巧或环境，而不是 AI 工具本身。

5. 意义与启示

对研究人员：S-IASE 模型提供了一个结构化的多维视角来研究开发者与 AI 的交互，超越了简单的活动日志，纳入了情感和意图状态。它强调了研究 AI 协作中“隐藏”的认知和情感层面的必要性。
对从业者（AI 设计者）：
- 视觉指导：AI 助手需要支持视觉模态（截图、图表）以应对设置和配置任务，而不仅仅是文本。
- 信任校准：系统应帮助开发者验证 AI 输出而不引发内疚感，例如通过明确突出 AI 正在执行的操作以促进学习。
- 工作流集成：工具应支持“信任但验证”的工作流，促进快速迭代，并方便在 AI 生成与人工细化之间切换。
对教育：课程应解决利用 AI 提高效率与保持深层概念理解之间的张力，帮助开发者管理因依赖 AI 而产生的“冒名顶替”感。

结论

本研究填补了理解开发者与 AI 交互的社会技术复杂性的关键空白。通过 S-IASE 框架对行为进行建模，作者揭示了 AI 辅助从根本上改变了编程的序列和情感基调，创造了一种新的“氛围编程”（vibe coding）范式，该范式优先考虑快速迭代和验证，而非深入的初始理解，同时也为开发者带来了新的心理挑战。