💻 computer science

Prompt Quality and Pull Request Outcomes: A Stage-Based Empirical Study of LLM-Assisted Development

本研究通过对开源拉取请求中 265 次开发者与 ChatGPT 交互行为的实证分析，旨在证明特定的提示词特征——上下文（Context）、明确性（Specificity）和验证（Verification）——对 AI 辅助软件开发结果具有截然不同的、阶段性的影响，其中明确性与上下文驱动可执行的代码生成，验证预测代码采纳情况，而上下文则决定集成深度。

原作者： Richard Sserunjogi, Daniel Ogenrwot, John Businge

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Richard Sserunjogi, Daniel Ogenrwot, John Businge

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

想象一下你是一位大厨（开发者），正试图烹饪一道复杂的菜肴，而你的副厨（AI）虽然非常有才华，但有时会过于刻板。你不能只喊一声“做晚饭！”就指望得到一顿米其林水准的餐点。你必须给出具体的指令。

这篇论文研究了你向副厨寻求帮助的方式是如何影响整个烹饪过程的——从第一种食材到最后呈献给顾客的成品。

研究人员分析了 265 个真实世界的案例，这些案例中，开发者在软件项目中与 AI（ChatGPT）进行了对话。他们想看看“食谱请求”（提示词/Prompt）的质量是否决定了 AI 生成的代码是否有用、是否被接受，以及是否真正被用于最终产品中。

以下是他们的研究结果，使用了简单的类比：

1. 一个优质请求的三种成分

研究人员将每一个请求分解为三个部分，就像检查食谱卡片一样：

上下文（背景设定）： 开发者是否解释了这段代码的用途？（例如：“这是用于我们银行应用登录界面的。”）
具体性（细节描述）： 开发者是否明确说明了想要什么？（例如：“把按钮变成蓝色且圆润的形状”，而不是仅仅说“让它看起来好看点。”）
验证（味觉测试）： 开发者是否说明了如何检查结果是否正确？（例如：“如果我点击这个，它应该能让我成功登录且不报错。”）

2. 厨房工作流的三个阶段

研究发现，随着烹饪阶段的不同，“完美”的请求要求也会随之改变。它并非千篇一律。

第一阶段：获取初稿（代码生成）

最重要的因素： 上下文和具体性。
类比： 如果你想让 AI 真正写出一份食谱，你需要告诉它你在做什么菜，并给出清晰的步骤。
研究发现： 如果请求过于模糊或缺乏背景信息，AI 通常只会给出一个通用的解释，而不是实际的代码。但如果开发者给出了明确的目标和一些背景信息，AI 几乎总能生成可用的代码。
此时并不重要的因素： 是否包含“味觉测试”（验证）并不会阻止 AI 编写代码。

第二阶段：决定是否使用草稿（代码采纳）

最重要的因素： 验证。
类比： 现在 AI 已经写好了一份食谱。开发者必须决定：“我能信任它吗？”如果开发者包含了检查结果的方法（例如“它必须通过这项特定的测试”），开发者就更有可能说：“是的，使用它！”
研究发现： 即使代码写得很好，如果开发者没有提供验证其正确性的方法，他们往往会拒绝使用。 “味觉测试”是让代码被接受的关键。
此时不太重要的因素： 到达这个阶段时，拥有极其具体的目标或额外的背景信息已不再是决定性因素；能够证明其有效性的能力才是关键。

第三阶段：将其混入最终成品（集成深度）

最重要的因素： 又是上下文。
类比： 代码已被接受，但现在需要将其混入现有软件的大锅中。如果 AI 的代码在编写时没有考虑到整体菜肴的“风味特征”，它可能会味道奇怪，从而需要大量的重写。
研究发现： 开发者提供的背景信息（上下文）越多，AI 的代码就越能完美融入现有的项目中。如果 AI 需要猜测自己的位置，开发者之后就必须花费大量时间进行修复。
教训： 为了获得能够无缝衔接的代码，你必须告诉 AI 它在宏观图景中的确切位置。

3. “机器人 vs 人类”检查器

研究人员还尝试观察是否可以使用 AI 来自动对这些请求进行评分。

结果： 结果喜忧参半。AI 在识别“具体性”（清晰的指令）方面表现尚可，但在识别“上下文”（它经常遗漏背景信息）和“验证”（它难以判断是否包含了测试）方面表现较差。
启示： 你不能仅仅依靠机器人来给这些请求打分。你需要人类来复核那些棘手的部分，尤其是背景上下文。

4. 最终结果（Pull Request 是否被合并？）

有趣的是，提示词的质量并没有显著改变项目经理决定合并或关闭请求的速度。这似乎更多取决于请求的大小以及项目的通用规则，而非提示词本身。

总结

把在软件开发中使用 AI 想象成一场接力赛：

起点： 你需要上下文和具体性来让接力棒（代码）跑起来。
中间： 你需要验证来证明跑步者正处于正确的轨道上，以便下一个人接过接力棒。
终点： 你再次需要上下文，以确保跑步者在正确的跑道内冲过终点线，而不会撞到其他跑步者。

该论文得出结论：编写一个好的提示词不仅仅是为了获取代码，更是为了为整个工作流的成功奠定基础。如果你跳过了“上下文”或“验证”步骤，代码或许会被写出来，但它可能会被拒绝，或者在后期需要大量的额外工作来进行修复。

技术摘要：提示词质量与拉取请求结果：一项基于阶段的 LLM 辅助开发实证研究

问题陈述
尽管大语言模型（LLM）驱动的工具正日益融入协作式软件工程工作流（尤其是开源拉取请求 [PR] 流程），但提示词结构对下游集成结果的具体影响仍未得到充分理解。先前的研究主要关注对话的帮助程度、广泛采用指标或粗粒度的代码质量。然而，开发者经常根据初始请求的构建方式来优化、调整或拒绝 LLM 生成的代码。目前缺乏实证证据来表明提示词质量的不同维度——特别是其将任务锚定在上下文中的能力、定义明确性的能力以及提供验证线索的能力——如何影响代码从生成到采用及深度集成的演进过程。此外，在大规模实证研究中，使用 LLM 本身来大规模标注这些提示词结构的可靠性，仍然是一个开放性的方法论问题。

研究方法
本研究采用混合方法，分析了与开源拉取请求相关的 265 个经过人工验证的开发者–ChatGPT 交互案例。这些案例源自 PatchTrack 语料库，该语料库追踪了开源仓库中自我承认的 ChatGPT 使用情况（SACU）。

提示词结构的算子化： 作者基于先前关于缺陷报告和 PR 评估的软件工程研究，定义了三个维度的提示词质量：
- 上下文 (Context, C)： 提示词在多大程度上植根于具体的工程制品（如代码片段、日志、错误信息）。
- 明确性 (Specificity, S)： 预期任务的清晰度和精确度，包括目标、范围和约束条件。
- 验证 (Verification, V)： 是否存在允许开发者评估正确性的信号（如测试、预期行为、输入输出示例）。
- 每个维度按 0–2 的序数标度进行评分。
标注策略 (RQ1)： 为了解决人工标注的可扩展性问题，研究首先评估了 LLM 辅助标注相对于人类金标准（Gold Standard）的可靠性。研究人员和 LLM (ChatGPT 5.1/5.2) 对一个分层子集进行了提示词标注。通过加权 Cohen's Kappa ( $\kappa_w$ )、平均绝对误差 (MAE) 和方向性偏差来衡量一致性。这一分析促成了一种类感知混合标注策略，即仅在一致性足够的维度和工作流上下文中应用 LLM 评分，而对于不稳定的维度则保留人工监督。
基于阶段的工作流建模 (RQ2)： 将开发过程建模为一系列关卡（Gates）：
- Gate 0 (代码生成)： 提示词是否产生了可执行的代码？（不可用 [NE] vs. 可用 [PA/PN]）
- Gate 1 (代码采用)： 生成的代码是否被纳入 PR 中？（采用 [PA] vs. 未采用 [PN]）
- Gate 2 (集成深度)： 在 PA 案例中，被保留的代码占最终实现部分的比例是多少？（连续变量）
- 轴 B (生命周期结果)： 合并 vs. 关闭，以及解决时间。
- 使用了统计模型（逻辑回归、分数 Logit 回归和 Cox 比例风险模型）来估计 Context、Specificity 和 Verification 对各阶段的影响，并控制了 PR 大小。

关键结果
研究表明，提示词特征在协作工作流中表现出截然不同的、依赖于阶段的影响：

标注可靠性： 基于 LLM 的标注在 Context 和 Specificity 方面与人类判断具有中等程度的一致性，但在 Context 上存在系统性的低估偏差，且在 Verification 方面可靠性较差，尤其是在正确性线索较为隐晦时。Verification 的一致性随结果类别而显著变化（例如，在“补丁未应用”案例中一致性较高，在“补丁已应用”案例中一致性较低）。这表明需要采用混合的人机标注策略，而非统一的自动化方案。
Gate 0 (代码生成)： 明确性 (Specificity) 和 上下文 (Context) 是生成可执行代码的最强预测因子。具有清晰目标和技术底座的提示词更有可能产生可执行的代码。Verification 不显著影响代码是否生成。
Gate 1 (代码采用)： 验证 (Verification) 成为代码采用的主要预测因子。包含显式正确性预期或验证标准的提示词更有可能导致补丁被采用。一旦代码生成，Specificity 和 Context 的预测能力便会消失。
Gate 2 (集成深度)： 上下文 (Context) 成为主导因素。将任务嵌入丰富实现上下文（周围代码、API、仓库逻辑）的提示词会导致更高的代码保留比例。一旦代码被接受，Specificity 和 Verification 不会显著影响使用的程度。
生命周期结果： 提示词结构对 PR 的合并速率没有显著影响。然而，较高的 Verification 与“关闭而不合并”的速度相关，这表明显式的正确性约束可能有助于维护者快速识别不匹配的情况。

意义与主张
本文主张，提示词构建是一项关键的上游因素，它不仅影响 AI 辅助代码的初始生成，还影响下游的采用和集成结果。研究结果表明，有效的协作取决于将提示词特征与工作流的具体阶段相对齐：

任务定义： Context 和 Specificity 对于生成可执行代码至关重要。
评估： Verification 线索对于获得开发者信任和采用至关重要。
对齐： 上下文锚定对于深度集成和减少下游调整至关重要。

在方法论上，本研究证明，可靠地实现提示词结构的算子化需要具备自适应性、上下文感知的混合标注策略。文章认为，提示词结构应被视为一种“一等公民软件制品”，它塑造了 AI 辅助开发的整个生命周期，而不仅仅是代码生成的输入。结果表明，下游的集成挑战往往起源于上游的提示词构建阶段，这强调了开发者将提示词设计视为软件开发过程组成部分的重要性。