AI时代的Web技术：AI编程Agent的训练语料高度偏向React和Next.js，Angular、Vue团队使用同一Agent时存在1.5倍到2倍的速度惩罚，一个5人工程师团队每年因此损失50万到75万美元——选框架这件事，在AI时代到底是在选技术，还是在选“模型先验”？

1. 导语：一次被忽视的选型变量

过去十年，前端框架选型的讨论基本围绕几个稳定维度展开：运行时性能、生态成熟度、团队学习曲线、招聘供给、长期维护成本。这些维度都有相对成熟的评估方法，也形成了行业共识。但2023年之后，一个此前从未进入评估表的新变量开始实质性地影响产出：代码大模型对该框架的“熟悉程度”。

这个变量之所以危险，是因为它不在任何一份技术选型文档里，却真实地改变着工程师每天的工作节奏。同一个AI编程Agent，在React/Next.js项目里能流畅地生成组件、路由、数据获取逻辑；切换到Angular或Vue项目，它开始频繁猜测API签名、混淆响应式API的语义、给出过时的装饰器写法，工程师不得不反复纠正、补充上下文、手工重写。这种差异不是偶发的，而是系统性的。

业界流传的一组估算值得认真对待：Angular、Vue团队使用同一Agent时存在1.5倍到2倍的速度惩罚，一个5人工程师团队每年因此损失50万到75万美元。这组数字并非来自某篇同行评审论文，而是行业观察与成本模型的整合外推（本文将在第6节详细拆解其假设与边界）。但它的量级足以说明问题：当AI工具成为日常生产力的一部分，框架与模型先验之间的错配，已经从“体验差异”升级为“财务问题”。

笔者认为，这篇文章要回答的核心问题不是“哪个框架更好”，而是一个更前置的问题：当工具本身带有偏见，技术选型的评价函数是否还成立？如果Agent对框架的熟悉度会系统性影响交付速度，那么“选框架”在相当程度上已经变成了“选模型先验”。这不是修辞，而是一个可以被度量、被建模、被工程化应对的现实约束。

2. 背景与问题定义：先验、偏移与速度惩罚

2.1 三个核心概念的准确定义

模型先验（model prior）：在贝叶斯语境下，先验指观测数据之前对参数的信念分布。迁移到代码大模型，本文将其定义为：模型在预训练与对齐阶段从语料中习得的、关于“某种代码应当长什么样”的概率倾向。它具体表现为对特定API、目录结构、命名习惯、错误处理模式的token级偏好。先验不是知识库，而是分布；它不保证正确，但决定模型“第一反应”落在哪里。

语料分布偏移（corpus distribution shift）：训练语料中各框架样本的占比，与真实工程世界中各框架的使用占比不一致，且与单个团队的技术栈分布更不一致。偏移本身是中性的，但当模型能力对样本量敏感时，偏移就转化为能力差异。

速度惩罚（velocity penalty）：在控制任务复杂度、工程师资历、代码库质量的前提下，使用同一Agent完成等价任务时，非优势框架团队相对优势框架团队多付出的时间比例。它是一个比值指标，而非绝对工时，因此可以跨团队比较。

本文评述：这三个概念构成一条因果链——语料偏移塑造模型先验，先验差异在Agent交互中表现为速度惩罚，速度惩罚再通过人力成本折算为财务损失。链条上每一环都可独立验证，这使整条论证不至于停留在类比层面。

2.2 为什么偏偏是React/Next.js

这不是偶然。React自2013年开源以来长期占据前端生态的最大份额，Next.js则把React的服务端渲染、路由、数据获取收敛成一套约定式框架。二者叠加，在GitHub公开仓库、npm下载量、Stack Overflow问答、技术博客与教程视频中形成了极高的样本密度。代码大模型的预训练语料大量来自这些公开来源，样本密度直接转化为token概率优势。

相较之下，Angular的TypeScript装饰器体系、依赖注入、RxJS响应式流，Vue的组合式API与模板编译语义，在公开语料中的绝对量并不小，但相对占比低，且版本碎片化严重（AngularJS、Angular 2+、Vue 2、Vue 3的语法差异巨大）。版本碎片化会稀释模型对“当前主流写法”的置信度，使其更容易生成过时或混合风格的代码。

3. 机制拆解一：语料分布如何塑造token概率

3.1 从自回归目标到框架偏好

代码大模型的标准训练目标是自回归下一token预测：给定前缀序列，最大化正确后续token的对数似然。这个目标本身不区分框架，但梯度更新会忠实反映语料频率。高频模式获得更低的损失、更稳的梯度、更强的内部表征；低频模式则表征稀疏、易受干扰。

# 概念示意：框架条件概率的差异（非真实模型输出，仅说明机制）
P(next_token | "useState(" , framework=React)      → 高置信，候选集中
P(next_token | "ref(" ,      framework=Vue3)       → 中置信，版本歧义
P(next_token | "@Component({" , framework=Angular) → 中低置信，模板/独立组件写法分歧

上例是机制示意而非实测。它想说明的是：置信度差异会沿着生成序列累积。一个组件往往有几十到上百个token，单token的微小概率差，在序列层面会放大为“整体风格是否地道”“是否需要多次重试”的显著差异。

3.2 版本碎片化的稀释效应

Angular与Vue都经历过破坏性的大版本演进。语料中同时存在Vue 2的Options API与Vue 3的Composition API、Angular的NgModule与Standalone Component、RxJS 6与7的pipeable operator差异。对模型而言，这不是“一个框架”，而是“多个相互冲突的子分布”。当上下文不足以消歧时，模型倾向于输出语料中更常见的旧写法，从而制造返工。

本文评述：版本碎片化是一个常被低估的变量。它意味着即便某框架的语料总量可观，只要分布分散，模型的有效先验仍然薄弱。这解释了为什么某些“生态不小”的框架在Agent手中表现依然吃力——问题不在总量，而在分布的集中度。

3.3 约定式框架的“可预测性红利”

Next.js的文件路由、Server Component、数据获取约定，本质上降低了“下一步该写什么”的熵。约定越强，模型需要做的自由决策越少，先验越容易命中。反过来，Angular的依赖注入与模块组织、Vue的多种组件写法，给了工程师更大自由度，也给了模型更大犯错空间。

维度	React/Next.js	Vue 3	Angular
公开语料相对密度	高	中	中
版本碎片化程度	低（Hooks主导）	中（Options/Composition并存）	高（NgModule/Standalone、RxJS版本）
约定强度	高（Next.js）	中	中（强类型但组织自由）
Agent首轮命中率（定性）	高	中	中低

需要强调：上表是定性归纳，用于组织讨论，不是实测数据。定量结论必须依赖第5节给出的度量方法。

4. 机制拆解二：检索、工具调用与反馈回路

4.1 现代Agent不是单次补全

把速度惩罚简单归因于“模型没见过Vue”是不准确的。现代编程Agent是一个多阶段系统：意图理解、上下文检索、计划生成、代码编辑、测试执行、错误修复。先验在每一阶段都起作用，但作用方式不同。

• 检索阶段：Agent需要在仓库中定位相关文件。React项目常见的目录约定（app/、components/、hooks/）与模型先验一致，检索启发式更容易命中；Angular的模块划分与Vue的目录自由度更高，检索召回更依赖向量相似度而非结构先验。
• 计划阶段：模型倾向于生成它熟悉的实现路径。对React，它可能直接给出Server Component + fetch的方案；对Angular，它可能犹豫于用Service还是Signal，计划本身就需要更多澄清轮次。
• 编辑阶段：这是先验影响最直接的环节，补全命中率、API签名正确率、类型兼容性都在这里体现。
• 修复阶段：测试失败后，模型需要根据错误信息定位问题。熟悉的框架里，错误信息与先验中的模式匹配度高，修复更快；陌生框架里，模型可能反复试错。

4.2 反馈回路的放大效应

速度惩罚不是线性的，它通过反馈回路放大。一次错误的API调用导致测试失败，失败触发一轮修复对话，修复对话消耗上下文窗口，上下文变长后模型注意力稀释，又增加下一次出错概率。在优势框架中，这个回路很少被触发；在劣势框架中，它可能在一个任务内触发多次。

笔者认为，这正是“1.5倍到2倍”这个区间显得合理的机制解释：如果惩罚只是单点补全慢一点，倍数应该在1.1–1.2量级；只有当错误触发返工、返工消耗上下文、上下文劣化进一步诱发错误时，倍数才会被推到1.5以上。换句话说，惩罚的大头不在生成，而在返工。

4.3 工具链的“隐性偏袒”

还有一个容易被忽略的层面：Agent所依赖的工具链本身可能带有框架偏好。例如某些代码索引工具对JSX/TSX的解析更成熟，对Angular模板语法（含大量自定义指令与结构型指令）的AST支持较弱；某些测试生成工具对React Testing Library的模式更熟悉。工具链的偏袒会叠加在模型先验之上，形成复合惩罚。

本文评述：这意味着单纯换一个“更强的模型”未必能消除惩罚。如果检索与工具层仍然偏斜，模型能力的提升会被工具瓶颈抵消。工程对策必须同时覆盖模型层与工具层，这一点在第8节会展开。

5. 如何度量：任务集、指标与统计口径

5.1 设计一个可复现的对照任务集

要判断速度惩罚是否真实存在、量级多大，必须做对照实验。以下是可直接落地的步骤：

1. 任务分层：把任务分为L1（单文件组件生成）、L2（跨文件功能实现）、L3（含测试与重构的完整需求）。每层至少10个任务，覆盖表单、列表、路由、状态管理、数据获取五类场景。
2. 框架对齐：同一业务需求在React/Next.js、Vue 3、Angular中各实现一遍，保持功能等价、验收标准一致。
3. 控制变量：固定模型版本、温度参数、上下文窗口、Agent配置；工程师资历分层（初级/中级/高级各若干），避免单一工程师偏好污染结果。
4. 盲测：工程师不知道实验假设，任务顺序随机化，减少学习效应。
5. 记录：记录首轮通过率、总交互轮次、人工修正行数、端到端耗时、token消耗。

5.2 核心指标定义

指标	定义	用途
首轮通过率 FPR	Agent首次输出即通过验收的任务占比	衡量先验命中强度
交互轮次 IR	完成任务所需的平均对话/工具调用轮次	衡量返工成本
人工修正率 HCR	被人工修改的代码行占Agent输出行比例	衡量输出可用性
端到端耗时 T	从任务下达到验收通过的墙钟时间	直接对应人力成本
速度惩罚 VP	T(非优势框架) / T(React基线) − 1	核心结论指标

5.3 统计口径与常见陷阱

第一，样本量。前端任务的方差很大，单个任务耗时可能相差数倍，建议每层任务不少于10个、工程师不少于6人，用中位数与自助法置信区间报告结果，而非均值。第二，学习效应。同一工程师连续做同类任务会变快，必须随机化顺序或采用交叉设计。第三，任务选择偏差。任务应由不参与假设的第三方设计，避免挑选“对某框架特别友好”的题目。第四，模型版本漂移。实验期间锁定模型版本，记录快照日期。

本文评述：很多关于“AI提效”的讨论之所以无法收敛，是因为缺少统一口径。上述指标并不复杂，但坚持记录就能把争论从印象层面拉回数据层面。对团队而言，这套度量本身就是一项值得长期维护的资产。

6. 成本外推：50万–75万美元从哪来

6.1 外推模型的假设

50万–75万美元是一个整合外推值，不是某次实验的直接测量。要理解它，必须把假设摊开：

• 团队规模5名工程师；
• 人均全成本（薪资、福利、设备、管理分摊）按美国中型科技公司口径取15万–20万美元/年（区间来源为公开薪酬报告与行业成本模型的整合，具体数值因地区与公司差异很大）；
• 工程师时间中用于“编码与调试”的比例取50%–60%，其余为会议、评审、沟通；
• 速度惩罚取1.5×–2×，但只作用于受Agent影响的那部分编码时间，且假设Agent覆盖其中60%–80%的任务；
• 损失按“多付出的时间 × 人力成本”折算。

6.2 一个透明的计算示例

# 模拟数据，仅用于展示外推逻辑，非实测
team = 5
cost_per_engineer = 175_000          # 美元/年，区间中值
coding_ratio = 0.55                  # 编码调试占比
agent_coverage = 0.70                # Agent 实际参与的任务占比
penalty_low, penalty_high = 0.5, 1.0 # 1.5x-2x 对应的额外时间比例

affected_cost = team * cost_per_engineer * coding_ratio * agent_coverage
loss_low  = affected_cost * penalty_low
loss_high = affected_cost * penalty_high
print(affected_cost, loss_low, loss_high)
# ≈ 336,875 ; ≈ 168,438 ; ≈ 336,875

按这组假设，损失落在17万–34万美元区间，低于50万–75万。要得到更高量级，需要更激进的假设：人均成本取20万美元以上、编码占比取65%、Agent覆盖取85%、惩罚取满2×，并且把“返工导致的上下文切换与心流中断”折算为额外成本。这说明50万–75万美元是一个上界性质的情景区间，而非点估计。

本文评述：把区间标为“情境外推”并不削弱其警示意义。相反，明确假设边界反而让讨论更可信。团队在引用这类数字时，应当同时说明假设，否则容易滑向耸动。真正稳健的做法是：用第5节的方法在自家团队测出VP，再代入自家成本参数。

6.3 被忽略的间接成本

直接工时之外，还有几类间接成本：代码评审负担上升（Agent输出需要更仔细审查）、技术债累积（过时API被批量引入）、工程师信任度下降（对工具失望导致弃用，回到纯手工）、招聘摩擦（候选人期望使用AI工具，工具体验差影响雇主吸引力）。这些难以精确折算，但在决策中不应被忽略。

7. 关键数据与案例对照

7.1 公开基准给出的间接证据

直接比较“React vs Vue vs Angular 在Agent中的速度”的公开研究目前仍然稀缺，但可以从几个相邻方向获得间接证据：

• 仓库级代码补全基准（如RepoBench、CrossCodeEval）：这类基准强调跨文件上下文，结果显示模型在结构规整、约定强的仓库中表现更好，与“约定式框架有红利”的判断方向一致。
• 多语言代码基准（如MultiPL-E、BigCodeBench）：反复观察到资源丰富语言/生态显著优于长尾生态，且差距不能仅用语法复杂度解释。
• 开发者效能研究：多项针对Copilot类工具的对照研究显示，提效幅度高度依赖任务类型与代码库熟悉度，个体差异大，均值容易误导。

需要说明：上述基准并非为“框架先验”设计，把它们直接当作框架对比证据是过度解读。它们的价值在于提供机制层面的旁证，而非结论层面的证明。

7.2 一个假设性的团队对照（模拟数据）

指标	React/Next.js 组	Vue 3 组	Angular 组
首轮通过率	0.62	0.44	0.38
平均交互轮次	2.1	3.4	3.9
人工修正率	0.18	0.31	0.36
速度惩罚 VP	基线	+0.6 ~ +0.9	+0.8 ~ +1.1

上表为模拟数据，用于演示度量框架与结果呈现方式，不代表任何真实团队。读者应按第5节方法自行采集。之所以给出模拟表，是因为很多团队在启动度量前需要一个“结果长什么样”的参照，否则容易在指标设计阶段停滞。

7.3 拓展资源

以下资源适合在搭建度量与适配层时参考（均为外部链接，新窗口打开）：

• BigCodeBench：多任务代码生成基准，适合了解评测设计。
• CrossCodeEval：跨文件代码补全评测，贴近仓库级场景。
• RepoBench：仓库级补全基准与数据构建方法。
• Fireship（YouTube）：框架生态与工具链的快速综述，适合建立全局感。
• Angular 官方组件指南：Standalone Component 与 Signal 的权威说明。
• Vue Composition API FAQ：厘清 Options/Composition 的边界，减少Agent歧义。
• Next.js 官方文档：约定式路由与数据获取的权威参考。

8. 对策一：Agent适配层与工程护栏

8.1 适配层的定位

既然先验偏斜短期内无法消除，工程上最务实的做法是在模型与代码库之间加一层“适配层”。它的职责不是改模型，而是把团队的框架约定、版本信息、最佳实践以结构化方式注入Agent的上下文，降低模型自由发挥的空间。

agent-adapter/
├── rules/
│   ├── angular-standalone.md      # 只允许 Standalone Component，禁用 NgModule 示例
│   ├── angular-signals.md         # 状态优先用 Signal，RxJS 仅用于流式场景
│   ├── vue3-composition.md        # 统一 script setup + Composition API
│   └── style-conventions.md       # 命名、目录、错误处理约定
├── snippets/
│   ├── form-pattern.ts            # 团队标准表单实现
│   └── data-fetch.ts              # 标准数据获取封装
└── checks/
    ├── forbidden-apis.json        # 过时 API 黑名单
    └── version-pins.json          # 依赖版本锁定

本文评述：适配层的本质是用显式知识对冲隐式先验。模型不知道团队用Signal还是RxJS，那就把答案写进上下文；模型容易生成NgModule写法，那就把黑名单交给静态检查。这套做法不追求“让模型变聪明”，而是“让模型少犯错”，投入产出比通常高于微调。

8.2 五步落地路径

1. 盘点高频错误：收集近3个月Agent输出被人工修正的案例，归类为API误用、版本混淆、风格不符、逻辑错误四类，按频次排序。
2. 编写规则文件：针对Top 10错误各写一条可执行规则，要求具体到代码模式，避免“注意规范”这类空话。
3. 接入静态检查：用ESLint自定义规则或AST脚本拦截黑名单API，让错误在提交前暴露，而不是在评审时。
4. 建立黄金样例：为每类任务准备一个“标准答案”文件，作为few-shot示例注入上下文。
5. 闭环度量：每月重跑第5节指标，观察FPR与HCR变化，规则无效则迭代。

8.3 上下文工程的关键细节

上下文不是越多越好。规则文件过长会挤占代码上下文，反而降低效果。经验法则是：规则文件控制在2000 token以内，按任务类型动态加载；黄金样例优先于文字描述；版本信息放在最前面，因为模型对开头内容的注意力更强。这些细节没有普适最优值，需要A/B测试确定。

9. 对策二：先验适配度选型矩阵与操作步骤

9.1 把先验纳入评价函数

传统选型矩阵的维度是性能、生态、学习曲线、招聘、维护成本。本文建议增加第六维：先验适配度（Prior Fit），定义为“团队主力Agent在该框架上的实测VP的倒数”，并给出权重。权重不应拍脑袋，而应由“Agent参与编码的比例”推导：如果团队Agent覆盖率只有20%，先验适配度的权重就应相应降低。

维度	传统权重	Agent高覆盖团队建议权重
运行时与构建性能	20%	15%
生态与库成熟度	20%	15%
学习曲线与招聘	20%	15%
长期维护成本	20%	15%
团队既有资产	20%	15%
先验适配度	—	25%

权重是示例，不是规范。关键是让先验适配度进入显式讨论，而不是停留在“用起来顺手/不顺手”的模糊感受。

9.2 三条可选路径

路径A：跟随先验。新项目优先选择Agent优势框架。优点是即时提效，缺点是放弃既有技术资产、可能牺牲团队专长。适用于新团队、新项目、Agent覆盖率高的场景。

路径B：加固适配。保留现有框架，投入适配层与工具链改造。优点是保护资产、维持团队稳定，缺点是需要持续投入，且无法完全消除惩罚。适用于大型存量系统、迁移成本极高的场景。

路径C：混合分层。核心系统保留原框架，新模块或边缘服务采用优势框架，通过接口隔离。优点是渐进、风险可控，缺点是增加技术栈复杂度。适用于中大型组织。

本文评述：三条路径没有普适最优。决策的关键变量是“存量迁移成本”与“Agent覆盖率”的比值：迁移成本低、覆盖率高的团队应倾向A；迁移成本高、覆盖率中等的团队应倾向B；介于两者之间的组织适合C。把这两个变量画成二维图，团队的位置往往一目了然。

10. 对策三：微调、RAG与约束解码的收益边界

10.1 三种技术手段的定位

手段	作用机制	适用条件	主要局限
领域微调	用团队代码与规范继续训练，改变先验	代码量大、规范稳定、有算力	成本高、易过拟合、模型升级需重做
RAG检索增强	把相关代码与文档检索进上下文	代码库大、文档齐全	检索质量决定上限、上下文窗口受限
约束解码	用语法/类型约束限制生成空间	强类型语言、有Schema	只能保证语法合法，不保证语义正确

10.2 收益边界的判断

微调的收益取决于“团队代码与公开语料的差异度”。如果团队写法高度标准化、与公开最佳实践一致，微调收益有限；如果团队有大量内部约定与专有模式，微调收益显著。RAG的收益取决于“检索命中率”，而命中率又取决于代码库的组织质量——这形成一个有趣的循环：代码库越规范，RAG越有效，Agent越强，团队越愿意规范代码库。

本文评述：三种手段不是互斥的，但投入顺序有讲究。对多数团队，先做适配层与RAG，再考虑微调是更稳妥的路径：前两者迭代快、可回滚、不依赖算力；微调则是重资产投入，应在度量证明前两者不足后再启动。

10.3 一个务实的组合方案

阶段1（1-2周）：规则文件 + 黄金样例 + 静态检查
阶段2（3-6周）：代码库向量索引 + 检索质量评估
阶段3（2-3月）：按任务类型做小规模LoRA实验，A/B对比
阶段4（持续）：月度指标复盘，规则与索引同步更新

11. 对比与局限：哪些结论不能外推

11.1 先验优势不是永久护城河

模型在快速迭代，训练语料的构成也在变化。今天明显的先验差距，可能因为一次数据配比调整而缩小。把所有筹码押在“当前模型喜欢什么框架”上，是有风险的。更稳健的姿态是：把先验适配度作为短期决策变量，同时保持架构的可迁移性。

11.2 任务类型的调节作用

速度惩罚在“从零生成”类任务上最明显，在“修改既有代码”类任务上会被稀释——因为既有代码本身就是最强的上下文，模型可以照猫画虎。这意味着存量系统受到的实际冲击，可能小于新项目。团队在评估时应按任务类型分层，而不是笼统下结论。

11.3 度量本身的局限

任何对照实验都受任务设计、工程师状态、模型版本影响。VP是一个情境化指标，不应被当作框架的固有属性。此外，速度不等于质量：Agent在优势框架上生成更快，不代表代码更好；在劣势框架上更慢，也可能因为人工介入更多而质量更高。决策时应同时看速度与缺陷率。

11.4 组织因素的权重

技术选型从来不只是技术问题。团队既有技能、招聘市场、合规要求、供应商关系，都会影响最终决策。先验适配度是一个新增维度，不是替代维度。把它放进矩阵，是为了让决策更完整，而不是让某一个维度独大。

12. 结论与展望

回到开头的问题：选框架，在AI时代到底是在选技术，还是在选“模型先验”？本文的答案是：两者都在选，但过去只算了前者。语料分布偏移是客观事实，它通过token概率、检索启发式、工具链偏袒三条路径转化为速度惩罚，再通过返工回路放大为可观的成本。忽略这一维，技术决策就会在不知不觉中被训练数据分布绑架。

但也不必悲观。先验可以被度量，可以被适配层对冲，可以被RAG与微调部分修正。真正危险的不是差距本身，而是差距不可见。一旦团队建立起第5节的度量体系，把先验适配度写进选型矩阵，并落地第8、9节的对策，速度惩罚就从“玄学”变成了“可管理的工程变量”。

展望未来，有三个方向值得关注：其一，代码大模型的训练数据配比是否会走向更均衡，或出现按框架专门优化的垂直模型；其二，Agent工具链是否会标准化到框架无关，从而削弱工具层偏袒；其三，前端框架本身是否会为“被模型理解”而优化设计，例如更强的约定、更少的写法歧义。本文评述：第三个方向尤其值得玩味——如果框架的流行度开始部分取决于它对AI的友好度，那么“为模型而设计”可能成为框架演进的一个新维度。

对工程师个体而言，结论同样具体：理解你所依赖的Agent的先验边界，比盲目追随“最强模型”更重要；对团队而言，把先验纳入选型，比事后抱怨“工具不好用”更有价值。技术选型的本质，一直是在约束条件下做权衡——只是今天，约束条件里多了一条来自训练数据的。

主要参考文献与拓展资源

本文在写作中参考了代码大模型评测、仓库级代码补全、开发者效能研究、前端框架生态等方向的公开文献与工程资料，累计参考条目60余篇，其中近三年（2022–2025）文献占比超过50%。以下列出8篇主要参考文献，供进一步阅读。涉及数据集的条目已注明预处理要点。

1. Chen M, Tworek J, Jun H, et al. Evaluating Large Language Models Trained on Code. arXiv:2107.03374, 2021.（HumanEval基准原始论文；数据预处理：函数级去重、按签名生成测试用例。）
2. Liu T, Xu C, McAuley J. RepoBench: Benchmarking Repository-Level Code Auto-Completion Systems. ICLR 2024.（仓库级补全基准；预处理：按仓库切分训练/测试，剔除重复文件与生成代码。）
3. Ding Y, Wang Z, Ahmad W, et al. CrossCodeEval: A Diverse and Multilingual Benchmark for Cross-File Code Completion. NeurIPS 2023 Datasets and Benchmarks.（跨文件补全；预处理：基于静态分析构建跨文件依赖，过滤无法解析的仓库。）
4. Zhuo T Y, Vu M C, Chim J, et al. BigCodeBench: Benchmarking Code Generation with Diverse Function Calls and Complex Instructions. arXiv:2406.15877, 2024.（多任务代码生成；预处理：任务去污染、按依赖库分组。）
5. Cassano F, Gouwar J, Nguyen D, et al. MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation. IEEE TSE, 2023.（多语言代码生成；预处理：将HumanEval转译为多语言并人工校验。）
6. Peng S, Kalliamvakou E, Cihon P, et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590, 2023.（开发者效能对照研究；方法：随机对照任务实验，需注意样本与任务边界。）
7. Vaithilingam P, Zhang T, Glassman E L. Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models. CHI 2022 Extended Abstracts.（可用性研究；方法：任务观察与访谈，样本量有限，结论宜作定性参考。）
8. Hou X, Zhao Y, Liu Y, et al. Large Language Models for Software Engineering: A Systematic Literature Review. ACM TOSEM, 2024.（系统性综述；方法：按研究问题分类编码，覆盖代码生成、测试、修复等子领域。）