论文技术总结：LLM 在协作软件设计中的作用

1. 研究背景与问题 (Problem)

尽管大量现有研究探讨了大型语言模型（LLM）在个人软件开发任务（如编码）中的应用，但关于 LLM 如何影响协作式软件工程工作（特别是软件设计阶段）的研究仍然匮乏。

• 核心痛点：软件设计本质上是一项高度协作、需要权衡取舍（如质量属性、可行性、成本）的人类中心活动。目前尚不清楚 LLM 在小型设计团队中如何被使用，以及它如何改变设计师之间的协作模式、思维过程和最终的设计产出。
• 研究缺口：现有研究多关注单一设计师使用 GenAI 进行建模等特定任务，缺乏对多人协作场景下 LLM 使用模式、依赖程度及交互影响的深入考察。

2. 研究方法 (Methodology)

本研究采用探索性实验室实验，模拟远程协作环境，旨在观察软件专业人士在自然状态下如何使用 LLM 进行设计。

• 参与者：18 对（共 36 名）具有行业经验的软件专业人士（包括工程师、架构师、产品经理等），经验跨度从 1 年到 20 年以上。大多数参与者此前已有 LLM 使用经验。
• 任务：设计一个“大学校园自行车停车应用程序”。任务基于产品需求文档（PRD），包含目标、6 个关键功能和屏幕原型，属于“绿地（Greenfield）”设计任务，无需特定领域知识。
• 设置：
  • 参与者通过 Zoom 远程协作，使用自选的协作设计工具（如 Google Docs, LucidChart）。
  • 提供定制开发的 LLM 聊天工具（基于 ChatGPT 3.5 Turbo API），允许每对参与者独立或共同调用 LLM。
  • 时间限制：90 分钟。
• 数据收集：Zoom 会话录音、访谈记录、LLM 交互日志（提示词与回复）、最终设计文档。
• 分析方法：主要采用定性分析，结合归纳与演绎编码（Abductive Coding）。对交互日志、视频记录和访谈转录文本进行编码，识别协作模式、LLM 角色及设计决策过程。

3. 关键发现与结果 (Key Findings & Results)

3.1 协作模式 (RQ1)

研究发现了三种主要的 LLM 联合使用模式：

1. 共享实例 (Shared Instance)：类似结对编程，一人操作（Driver），另一人协助或审查。这种模式有助于建立共同理解 (Shared Understanding)。
2. 协作中的独立实例 (Separate Instances while Co-working)：两人同时工作但各自使用独立的 LLM 会话。这有时能利用 LLM 的非确定性生成不同方案，但也可能导致**“上下文漂移” (Context Drift)**，即双方对设计的理解出现分歧，需要额外协调。
3. 独立工作时的独立实例 (Separate Instances while Working Individually)：两人拆分任务并行工作，各自使用 LLM。这需要高度的后期协调以确保设计的一致性。

3.2 LLM 的角色与依赖程度 (RQ2)

根据对 LLM 的依赖程度，研究者定义了四种角色：

1. 无角色 (No Role)：2 对参与者几乎未使用 LLM，原因包括不信任、认为手动设计更高效或已有足够能力。
2. 信息源 (Information Source)：5 对参与者将 LLM 视为知识检索工具（如查询 API 细节、数据库选择），依靠自身能力完成设计。
3. 生成器 (Generator)：8 对参与者利用 LLM 生成设计工件（如数据模型、API 定义）作为起点，随后进行人工修改和细化。
4. 生产者 (Producer)：3 对参与者让 LLM 生成整个设计文档，人类主要负责引导提示词和最终审查。

关键观察：

• 上下文提供：提供上下文（如完整 PRD）的程度差异巨大，从仅提问到提供完整需求文档不等。
• 辅助类型：最常见的是“创建工件”和“寻求信息”，其次是探索问题/解决方案空间。

3.3 对 LLM 响应的解读与行动 (RQ3)

设计师并非盲目接受 LLM 输出，而是进行了深度的审查、反思与迭代：

• 审查与验证：参与者会仔细检查 LLM 生成的代码或模型，对比 PRD 要求，甚至使用可视化工具验证。
• 早期锚定 (Early Anchoring)：LLM 生成的第一个方案往往成为“稻草人”（Straw Man），虽然提供了起点，但也可能限制了对替代方案的探索（除非刻意要求生成多个方案）。
• 迭代循环：通过多轮提示词（Prompt-Review-Revise）来修正错误、添加约束或细化设计。
• 洞察获取：LLM 的回复常引发设计师反思现有设计的遗漏或确认设计决策（如复用现有 API）。

3.4 设计师的感知 (RQ4)

• 信任与怀疑：普遍存在对“幻觉”的担忧，因此人工审查至关重要。
• 信心提升：LLM 作为“ sanity check"（合理性检查）工具，增强了设计师的信心，并降低了面对未知领域的压力。
• 人类伙伴的价值：参与者强调，与人类搭档协作比单独与 LLM 工作更有效，因为人类伙伴能纠正假设偏差，提供 LLM 无法替代的深层洞察。
• 适用性：LLM 被认为适合“尖峰探索 (Spike works)"、高层设计或绿地项目，但在处理复杂细节时，人工效率可能更高。

4. 主要贡献 (Key Contributions)

1. 协作模式图谱：首次系统性地揭示了在软件设计协作中，LLM 的共享与独立使用模式及其对团队动态（共同理解 vs. 上下文漂移）的影响。
2. 依赖程度分类：提出了 LLM 在协作设计中的四种角色（无角色、信息源、生成器、生产者），展示了从完全人工到完全由 AI 生成的连续谱系。
3. 人机交互洞察：证实了即使在 AI 辅助下，人类专家的核心地位依然不可动摇。设计师通过审查、批判性思考和迭代，将 LLM 输出转化为有价值的边界对象（Boundary Objects）。
4. 工具设计启示：指出了现有工具在支持协作设计方面的不足，并提出了改进方向。

5. 意义与启示 (Significance & Implications)

• 对工具开发的启示：未来的 AI 辅助设计工具应支持分支（Forking）与合并（Merging）功能，以支持并行探索不同设计方案；应提供机制来缓解上下文漂移和认知偏差（如锚定效应），帮助团队保持设计的一致性。
• 对软件工程实践的影响：研究表明，LLM 不会取代软件设计师，而是改变了设计流程。设计师需要从单纯的“执行者”转变为“审查者”和“引导者”。
• 未来研究方向：需要进一步研究 LLM 对最终设计质量（如可维护性、性能）的具体影响，以及在不同经验水平（新手 vs. 专家）和不同协作场景（远程 vs. 本地）下的表现差异。

总结：该论文通过实证研究证明，LLM 在协作软件设计中是一个强大的辅助工具，但其引入也带来了新的协作挑战（如上下文管理）。成功的关键在于人类设计师如何有效地驾驭 LLM，将其作为增强而非替代人类创造力和决策能力的工具。