这篇文章就像是一份**“软件工程师与 AI 大模型合作的‘诚实与透明’操作手册”**。
想象一下，软件工程师（SE）们最近发现了一个超级助手——大型语言模型（LLM）（比如 ChatGPT）。这个助手无所不能，能写代码、改 Bug、甚至模拟人类说话。但是，这个助手有个怪脾气：它有点“记性不好”且“性格多变”。
- 记性不好：它的训练数据是黑盒，没人知道它具体学了什么。
- 性格多变：你问它同一个问题，哪怕只隔了一分钟，它给出的答案可能完全不同（这就是“非确定性”）。
- 版本更新快：今天它很聪明，明天它可能就“变笨”了，或者换了个名字。
这导致了一个大问题：如果两个科学家分别用这个助手做实验，他们得到的结果可能完全不一样，而且谁也说不清为什么。这就像两个人用不同的食谱做蛋糕，结果一个甜一个咸，却都说是“标准食谱”做的，这怎么行？
为了解决这个问题，22 位来自世界各地的软件研究专家联手写了这份指南。他们把指南分成了**“七种玩法”和“八条铁律”**。
第一部分：LLM 在研究中的“七种角色” (Study Types)
专家们把 LLM 在研究中的用途分成了七类，就像你在厨房里给助手分配不同的任务：
- 贴标签员 (Annotators)：让 AI 帮忙给一堆文本打标签（比如把评论分类为“好评”或“差评”）。
- 裁判 (Judges)：让 AI 当评委，给代码质量打分，或者判断需求文档写得好不好。
- 总结大师 (Synthesis)：让 AI 读几十篇论文，然后帮你总结核心观点，或者生成新的合成数据。
- 演员 (Subjects)：让 AI 扮演“虚拟人类”，模拟用户怎么说话、怎么反应，用来做实验（省去了找真人做实验的麻烦）。
- 观察对象 (Studying Usage)：研究人类工程师到底是怎么使用 AI 工具的（比如他们是不是真的在用，还是只是装样子）。
- 新工具的核心 (New Tools)：把 AI 直接做成一个新的软件工具，比如一个能自动写单元测试的插件。
- 考试选手 (Benchmarking)：给不同的 AI 模型做“考试”，看谁在写代码、修 Bug 方面更厉害。
第二部分：八条“铁律” (The 8 Guidelines)
为了让这些研究结果可信、可重复，专家们制定了八条规则。你可以把它们想象成**“做菜的透明化标准”**：
1. 📢 大声说出你用了谁 (Declare Usage)
- 规则：如果你用了 AI，必须在论文里大声说出来！不能偷偷用。
- 比喻：就像你在餐厅点菜，如果厨师用了预制菜，他必须告诉你，不能假装全是现做的。你要说清楚：用了哪个模型？用来干什么？
2. 📝 记下详细的“配方” (Report Version & Config)
- 规则：必须记录模型的具体版本号、设置参数（比如温度参数）、甚至微调的细节。
- 比喻：做蛋糕不能只说“我用了面粉”，得说“用了 2025 年 1 月生产的 5 号面粉，烤箱温度 180 度，烤了 20 分钟”。因为 AI 稍微变个参数，味道（结果）就完全不同。
3. 🏗️ 画出完整的“厨房图纸” (Report Architecture)
- 规则：如果 AI 是工具的一部分，要画出整个系统的结构图。
- 比喻：不能只说“我用了搅拌机”，得说清楚搅拌机前面有没有加料器，后面有没有过滤网。因为有时候，是“加料器”决定了味道，而不是搅拌机本身。
4. 💬 公开所有的“对话记录” (Report Prompts & Logs)
- 规则：把你给 AI 的指令（Prompt）和 AI 的回答全部公开。
- 比喻：就像侦探破案，必须公开所有的审讯记录。因为 AI 对问题的问法非常敏感，换个问法，答案就变了。如果不公开指令，别人就无法复现你的实验。
5. 👨🔬 请真人来“试吃” (Human Validation)
- 规则：AI 生成的东西，最好让人类专家检查一下。
- 比喻：AI 做的菜，虽然看起来像那么回事，但最好请个老饕（人类专家）尝一口，确认味道对不对。不能光靠 AI 自己说“我做得很好吃”。
6. 🆓 找个“开源选手”做对比 (Use Open LLM as Baseline)
- 规则：如果你用了昂贵的商业模型（比如 GPT-4），最好也用一个免费的开源模型（比如 Llama）跑一遍作为对比。
- 比喻：如果你说你的跑车（商业模型）跑得飞快，最好也拿一辆普通的自行车（开源模型）比一下，或者至少让人家知道你的车具体快在哪里，而不是只说“我用了法拉利”。
7. 📏 用对的“尺子”去量 (Suitable Metrics)
- 规则：选对衡量标准。别用错尺子。
- 比喻：你不能用量长度的尺子（比如代码行数）去衡量重量（比如代码质量）。如果 AI 生成的代码能跑通，但全是乱码，那“能跑通”这个指标就不够好。要选真正能反映质量的指标。
8. 🚧 承认“翻车”的可能性 (Report Limitations)
- 规则：诚实地告诉别人你的研究有什么缺点，AI 哪里不可靠。
- 比喻：就像天气预报说“明天有 80% 概率下雨”，你得承认还有 20% 可能不下。别把话说太满，要告诉别人：如果模型变了，或者时间过了半年，我的结论可能就不准了。
总结：为什么要这么做？
这就好比**“科学界的透明厨房”**。
以前，大家用 AI 做研究，就像在黑盒子里做菜：你只看到端上来的菜（结果），不知道里面放了什么调料（模型版本），也不知道厨师（AI）当时心情好不好（随机性）。
这份指南就是要求大家把厨房的灯打开：
- 公开配方（模型和参数）。
- 公开过程（指令和日志）。
- 请人试吃（人类验证）。
- 承认局限（如果明天模型变了，菜的味道可能就不一样了）。
只有这样，其他科学家才能复现你的实验，验证你的发现，整个软件工程的领域才能建立在坚实、可信的基础上，而不是建立在“运气”之上。
一句话总结：用 AI 做研究没问题，但别把它当黑魔法，要把它当成一个需要详细记录、严格验证的普通工具，这样大家才能一起把蛋糕做得更好吃！
1. 研究背景与问题 (Problem)
自 2022 年 ChatGPT 发布以来，大语言模型（LLM）已迅速成为软件工程研究的核心焦点。然而，涉及 LLM 的实证研究面临着严峻的可重复性（Reproducibility）和可复制性（Replicability）挑战，主要源于 LLM 的三个固有特性：
- 非确定性（Non-determinism）： 相同的提示词（Prompt）在不同运行中可能产生显著不同的结果，微小的参数变化（如温度设置）也会导致输出差异巨大。
- 模型演变的不可追踪性： 商业模型（如 GPT 系列）在后台持续更新，即使版本号相同，其实际表现也可能随时间变化，导致历史研究无法复现。
- 数据与架构的不透明性： 即使是“开源”模型，其训练数据、微调细节和具体架构往往未完全公开；商业模型更是黑盒，缺乏透明度。
此外，现有的软件工程实证研究指南（如 ACM SIGSOFT 标准）并未针对 LLM 的这些特殊挑战提供具体指导，导致研究质量参差不齐，结果难以验证。
2. 方法论 (Methodology)
本研究采用协作式专家共识的方法，遵循类似医学领域 CONSORT 或 TRIPOD-LLM 指南的开发流程：
- 发起与组织： 项目始于 2024 年国际软件工程研究网络（ISERN）会议，由 22 位来自全球不同机构的资深研究人员组成团队。
- 迭代过程： 团队进行了多次双周会议，通过多轮讨论、同行评审和细化，逐步确立了研究类型分类法和具体指南。
- 内容构建：
- 首先定义了涉及 LLM 的七种研究类型（Study Types），以区分不同的研究场景。
- 随后制定了八项核心指南（Guidelines），区分了“必须（Must）”和“应该（Should）”的要求。
- 通过文献检索和专家筛选，为每种类型和指南提供了具体案例。
- 最后，团队将指南与 SIGSOFT 实证标准进行自我评估，并创建了适用性矩阵和报告清单。
- 验证： 指南在提交前经过了外部实证研究专家的审查，并在《Empirical Software Engineering》期刊的审稿过程中根据反馈进行了完善。
3. 关键贡献 (Key Contributions)
A. LLM 参与实证研究的七种类型分类法 (Taxonomy of Study Types)
作者将 LLM 在 SE 研究中的角色分为两大类，共七种具体类型：
- LLM 作为研究人员的工具 (LLMs as Tools for Researchers):
- S1 标注者 (Annotators): 用于定性数据的编码和标注。
- S2 评判者 (Judges): 评估软件工件（如代码可读性、需求质量）。
- S3 综合者 (Synthesis): 整合多源信息生成理论框架，或生成合成数据。
- S4 受试者 (Subjects): 模拟人类行为（如用户访谈、招聘场景）。
- LLM 作为软件工程师的工具 (LLMs as Tools for Engineers):
- S5 研究 LLM 的使用 (Studying LLM Usage): 观察工程师如何使用 LLM 工具。
- S6 构建新的 SE 工具 (LLMs for New Tools): 开发集成 LLM 的代理（Agents）或辅助工具。
- S7 LLM 基准测试 (Benchmarking LLMs): 在标准化任务上评估 LLM 性能。
B. 八项核心指南 (Eight Guidelines)
针对上述类型，提出了八项具体指南，明确了“必须”和“建议”的层级：
- 声明 LLM 的使用和角色 (G1): 必须在论文中明确披露 LLM 的使用目的、具体任务及在研究流程中的位置。
- 报告模型版本、配置和定制 (G2): 必须报告精确的模型名称、版本、实验日期、配置参数（如 temperature, seed）及微调细节。对于量化模型需报告量化级别。
- 报告模型之外的工具架构 (G3): 必须描述完整的系统架构，包括 LLM 与其他组件（如 RAG 检索、代理逻辑、外部 API）的交互，特别是代理（Agent）系统的决策流。
- 披露提示词、开发过程及交互日志 (G4): 必须发布所有提示词（Prompt）及其模板、开发策略（如零样本/少样本）、迭代过程。对于商业 SaaS 工具，应尽可能提供完整的交互日志。
- 使用人工验证 LLM 输出 (G5): 当缺乏参考数据集时，必须引入人工验证。需定义测量构念，报告评分者间信度（IRA），并控制混淆变量。
- 使用开源 LLM 作为基线 (G6): 在使用商业模型时，应包含一个开源模型作为基线，以增强可复现性，并提供完整的复现包。
- 使用合适的基线、基准和指标 (G7): 必须论证基准和指标选择的合理性，避免仅依赖单一指标。由于 LLM 的非确定性，必须重复实验并报告结果分布（描述性统计）及推断统计。
- 报告局限性与缓解措施 (G8): 必须透明报告局限性（如非确定性、泛化性、数据泄露风险），并说明采取的缓解策略（如三角验证、敏感性分析、成本核算）。
C. 辅助资源
- 适用性矩阵 (Applicability Matrix): 清晰展示了每种指南适用于哪些研究类型（哪些是必须的，哪些是建议的）。
- 报告清单 (Reporting Checklist): 类似于 CONSORT 清单，按论文结构（引言、方法、结果等）列出了具体的检查项，供作者和审稿人使用。
- 在线活资源: 指南维护在
llm-guidelines.org，作为社区共同完善的动态资源。
4. 结果与发现 (Results & Findings)
虽然这是一篇指南性论文而非实验性论文，但其核心“结果”体现在对当前研究现状的深刻洞察和规范化框架的建立：
- 现状诊断： 当前许多涉及 LLM 的研究缺乏关键元数据（如具体版本、Prompt 细节），导致结果无法复现。
- 分类价值： 七种研究类型的划分帮助研究者识别自身工作的性质，从而应用针对性的报告标准。例如，"LLM 作为受试者”的研究必须关注模拟的真实性，而“基准测试”则必须关注数据污染问题。
- 指南的可行性： 通过区分"Must"和"Should"，指南在严格性和现实可行性之间取得了平衡。例如，对于无法获取内部配置的闭源模型，指南要求尽可能报告已知信息并承认局限性，而非强制不可行的要求。
- 社区共识： 22 位作者的一致背书表明，这些指南代表了软件工程实证研究社区对 LLM 挑战的广泛共识。
5. 意义与影响 (Significance)
- 提升科学严谨性： 该指南为涉及 LLM 的 SE 研究设立了新的质量标准，通过强制性的透明报告（如 Prompt、配置、日志），显著提高了研究的可重复性和可信度。
- 指导实践与评审： 为研究人员提供了具体的操作手册（Checklist），同时也为期刊审稿人提供了评估此类稿件的明确依据（如检查是否披露了模型版本、是否有人工验证）。
- 应对技术快速迭代： 通过强调“活资源”和持续更新，该指南能够适应 LLM 技术的快速变化，避免指南迅速过时。
- 伦理与可持续性： 指南特别关注了数据隐私、模型偏见、以及 LLM 实验的高能耗问题，引导研究者在追求性能的同时兼顾伦理和可持续性。
- 填补领域空白： 这是首个专门针对软件工程领域 LLM 实证研究的综合性指南，填补了现有通用实证标准在 LLM 特异性问题上的空白。
总结： 该论文不仅是一份技术规范，更是软件工程实证研究在 AI 时代的一次重要范式调整。它呼吁研究者从“黑盒”使用转向“白盒”透明化，确保在利用 LLM 提升研究效率的同时，不牺牲科学研究的严谨性和可验证性。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。