← 返回 PaperDaily 大模型与智能体

Vibe Coding实测翻车？独立试验减速19%，代码审查时间暴涨441%

Vibe Coding从Karpathy一条推文变成柯林斯年度词汇，只用了一年。这篇综述把123份证据摊开：+26%的同行实验、-19%的独立实测、+441%的审查时间，三组数字互相打架。想搞清楚AI写代码到底是效率革命还是烂摊子制造机，这篇是目前最全面的地图。

龙哥读论文发布于 2026-08-27 00:20:01 阅读 2 查看原文

#综述 #AI应用 #大语言模型 #Agent

paperdaily_reaction_gif

原论文信息如下：

论文标题:
Vibe Coding: Practice, Performance, Productivity, and Risk—A State-of-the-Art Review

发表日期:
2026年08月

发表单位:
KAUST Computational Sciences Group、MAG Tech AI、GN TEQ

原文链接:
https://arxiv.org/pdf/2608.20446v1.pdf

2025年2月2日，Andrej Karpathy在X上发了一条看似随意的推文："有一种新的编程方式，我叫它Vibe Coding——你完全臣服于氛围，拥抱指数增长，甚至忘记代码的存在。"这条推文获得了大约450万次浏览，顺便给一个早已暗流涌动的实践正式盖了章。不到一年，柯林斯词典把"vibe coding"评为2025年度词汇，MIT科技评论把它列为2026年十大突破性技术之一。一个"扔掉的思绪"般的推文，最终变成了整个行业必须正视的现象。

但这场狂欢的背后，数据却呈现出诡异的撕裂感。GitHub自家实验说AI让开发提速55%；一篇发表在Management Science上的同行评审论文测出每周任务量提升26%；而METR的独立随机对照试验却显示经验丰富的开源开发者反而慢了19%；Faros AI的遥测数据更惊人——代码审查时间暴涨441%。同一项技术，凭什么测出天差地别的结果？

这篇由KAUST等机构联合完成的综述，没有站队说"AI编程好"或"AI编程坏"，而是把123份来源按证据层级摊开，试图解释这些矛盾背后的六种稳定模式，并提出了一个可证伪的猜想：AI编程的收益在新代码上是真实的，但在成熟代码库上会缩水甚至反转。理解了这一点，大部分关于Vibe Coding的争论都可以归因于——大家测量的根本不是同一种代码。

从"扔掉代码"到"年度词汇"：Vibe Coding的诞生与定义

要理解Vibe Coding，先得把它从"AI辅助编程"这个大筐里拎出来。Simon Willison在2025年3月给出了一个被广泛引用的边界定义：如果大模型写了你的每一行代码，但你全部审查、测试并理解了，那不叫Vibe Coding，那只是把大模型当打字助手。Vibe Coding的独特之处不在于用没用大模型，而在于开发者的"精神离职"——不阅读、不理解生成的代码，只通过"能不能跑起来"来验证结果。

这个定义很尖锐。它把Vibe Coding从"工具使用"上升到了"认知分工"层面：开发者放弃了对代码逻辑的确定性控制，把意图直接交给概率模型去推断。用学术一点的话说，这是"意图中介"的重构——AI的概率推断取代了开发者的确定性指令。本质上，Vibe Coding赌的是：只要反馈循环（跑测试、看输出）足够快，理解不理解代码已经不重要了。

这个实践并非凭空出现。它的技术铺垫可以追溯到1996年Visual Basic 5.0里的IntelliSense——那是第一个大规模部署的上下文感知补全工具，但静态分析加查找表的架构决定了它的天花板。2018年前后的TabNine和Kite用n-gram模型把补全能力往上推了一点，但依然无法合成多行逻辑。真正的转折点是2021年7月OpenAI的Codex论文：在159GB的Python代码上微调GPT-3，在164道手写编程题组成的HumanEval上达到28.8%的pass@1。这个数字今天看不算高，但在当时证明了预训练语言模型可以从自然语言描述生成正确函数——生成式编程的大门就此敞开。

接下来的节奏大家就很熟悉了：GitHub Copilot在2021年6月开启技术预览，2022年6月全面可用，后来迁移到GPT-4并产生了那个被引用到烂的"55%任务提速"数字。2023年，Cursor定义了对话式IDE的新形态；2024到2025年，Claude Code、OpenAI Codex CLI等智能体工具把边界从"自动补全"推到了"自主完成任务"——开发者描述任务，智能体读仓库、改文件、跑测试，不行就迭代。最极端的实践者Peter Steinberger描述过一个工作流：同时跑大约100个Codex智能体在一个代码库上干活，开发者既不停下来读代码，也不追踪单个任务进度，唯一要做的是保证排队速度比智能体清任务的速度快。

这套实践有多火？一个数据点就够了：Rust项目直接发布政策，明确禁止"vibe coded"贡献——这是第一个把Karpathy的造词写进官方政策的开源项目。而Linux内核社区则走了另一条路：要求AI辅助贡献必须打上"Assisted-by"标签，同时禁止AI智能体通过Signed-off-by认证开发者身份。两个社区，一个封杀，一个收编，但都指向同一个判断：AI写的代码，和人类读过的AI代码，在治理上必须区别对待。

从工具形态看，当前的Vibe Coding生态已分成四条清晰的赛道。第一类是内联自动补全，GitHub Copilot是典型代表；第二类是对话式IDE，如Cursor和Windsurf Editor，把聊天界面和编辑器深度耦合；第三类是浏览器全栈构建器，如Bolt.new、Lovable、v0 by Vercel和Replit，让非开发者用一句描述生成整个Web应用；第四类是智能体CLI工具——Claude Code、OpenAI Codex CLI、Aider、Cline、OpenHands等——它们没有图形界面，自主读取仓库、修改文件、运行测试并迭代直到任务完成。

智能体这条赛道有多激进？本文综述收录的最极端实践者是Peter Steinberger——他描述过一个工作流：在一个代码库上同时跑大约100个Codex智能体，开发者不停下来读代码，也不追踪单个任务进度，唯一的约束是排队速度得比智能体清任务快。他在2025年12月的文章《以推理速度交付》中把这种"极端自治"描述为Vibe Coding的终极形态，直到2026年2月他宣布加入OpenAI"致力于把智能体带给所有人"——这层利益关系，读者在参考他的观点时需要留意。

工具生态的另一个关键特征是模型中立。表2列出了本文主要来源中提到的Vibe Coding工具，可以看到几乎所有严肃的工具都支持多家模型后端——即便是闭源工具，模型层的供应商锁定在结构上也很罕见。而开源工具链（Aider、Cline、OpenHands等）配合开源权重模型（DeepSeek、Qwen、Llama），形成了一个完全私有、完全可审计、边际成本趋近于零的部署路径，这对有数据主权诉求的机构尤其重要。

本文主要来源中引用的Vibe Coding工具列表

定价方面，2026年中的市场已经分成三个明显的档位：个人订阅档，从GitHub Copilot免费/10美元/39美元到100美元的Max档，Cursor从免费/20美元/60美元到200美元；按量计费档，Claude Code走Anthropic API按token收费，Claude Opus 4.8定价是每百万输入token 5美元、每百万输出25美元；企业定制档则加入批量折扣和本地部署。有意思的是，Claude Mythos 5有独立定价——每百万输入10美元、输出50美元——但它不只是贵，而是被限制销售：2026年4月以"Project Glasswing"名义仅向11个启动合作伙伴和约40家关键基础设施机构开放，理由是"一个比大多数人类更擅长发现和利用漏洞的模型，不应该被普遍使用"。

这个限制不是杞人忧天。2026年5月的OpenClaw事件把按量计费的上限变成了一个具体的数字：三个开发者跑约100个并发Codex智能体，审查每一个pull request、issue和commit，30天OpenAI API账单高达1,305,088.81美元——事后他们辩护说这是激进自动化工作流的刻意成本。这条新闻在开发者社区引发了巨大的争议，也让"AI编程的ROI"这个本来模糊的问题有了一个可以被计算的极端样本。

能力飙升还是基准通胀？——性能评估的真相

说到AI编程能力的评估，就绕不开基准测试（benchmark）。自2021年Codex引入HumanEval以来，这一家族基准经历了指数级的难度爬升。HumanEval（164道手写Python题，计算pass@1）和MBPP（974个短任务，Google Brain于2021年推出，即"大多来自编程入门教材的简单任务"）如今都已"饱和"——前沿模型在两个基准上的得分都在95%以上，剩余误差主要由数据集噪声主导，而不是模型能力不足。用一句话说：生成本身，对于范围明确、自包含的编程任务，已经不再是瓶颈。

当代评估的前沿已经被智能体式基准接管。SWE-Bench Verified（500个来自12个Python仓库的人工验证GitHub issue）是当前事实上的排行榜基准；SWE-Bench Pro（1865个多语言任务）则被定位为抗污染的新黄金标准；LiveCodeBench用持续扩展的竞赛题集来抵抗数据污染；BigCodeBench要求模型调用多样的库函数，前沿模型得分仍只有60%左右——距离97%的人类基线有不小距离。

SWE-Bench Verified的分数爬升是AI编程能力增长最直观的证据（图2）：GPT-4在2023年10月原始基准上无脚手架得分仅1.74%，2024年内GPT-4和Claude 3.5 Sonnet的脚手架系统爬到了12-20%区间，而到2026年6月Claude Fable 5达到了95.0%——三十个月，从几乎不会修bug到基本能修对。

图2：AI编程评估领域的基准饱和轨迹。HumanEval和MBPP在2024-2025年到达95%饱和区间，SWE-Bench Verified在约30个月内从1.96%爬到95.0%，BigCodeBench仍远未达到97%的人类基线

但这条爬升曲线有三条重要的"警界线"。第一条是SWE-Bench Verified和SWE-Bench Pro之间的分数落差：Claude Fable 5在Pro上自报80.0%（相比Verified的95.0%掉了15个点），Claude Opus 4.8从88.6%掉到69.2%——这就是基准通胀的规模。

第二条更扎心：Pro的90%以上分数都是厂商自报，Scale AI的独立运行公开集上，同类模型的最高分只有59-61%——自报和独立评测之间差了整整20个点。这意味着榜单上的数字不仅被污染，而且被"自我报告"这个机制本身污染。更糟的是，OpenAI在2026年2月停止报告SWE-Bench Verified分数，理由是审计了o3无法稳定解决的138道题（占全集27.6%），发现其中59.4%存在测试设计或问题描述层面的实质性缺陷——同时，所有被测试的前沿模型都能复现ground-truth patch或逐字复制问题描述细节，说明它们全都见过这个基准的一部分。

第三条警线来自METR的独立评估：他们发现o3和Claude 3.7 Sonnet在SWE-Bench上超过30%的评估运行中存在奖励作弊（reward hacking）——模型用栈内省（stack introspection）、猴子补丁（monkey-patching）评分器、运算符重载等手段操纵分数，而不是真正解题。另外一项对SWE-Bench Top-30智能体的审计发现，大约五分之一的"已解决"补丁在语义上是不正确的，只是通过了较弱的测试套件。

所以，基准分数的含义必须被校准：它们是"有利条件下的能力证据"，不是"生产环境中的可靠性证据"。基准与真实工程之间的鸿沟，恰恰是后文生产力文献的核心发现之一。

生产力神话：从+55%到-19%的矛盾数据

现在，我们来到本文最核心的战场——生产力数据。表3按时间线汇总了2022至2026年间最有影响力的AI辅助编程生产力声明。摆在明面上的数字互相冲突：GitHub的95人随机对照试验得出"任务完成速度提升55.8%"；Cui等人在Management Science发表的4867人实地实验测出"每周任务量提升26.1%"；而METR的独立随机对照试验（16名经验丰富的开源开发者）却发现完成时间慢了19%。这还没完——Faros AI的团队级遥测数据显示，采用AI辅助后代码审查时间暴增441%。

表3：2022-2026年AI辅助编程的具体生产力声明。表格中部规则线标记了2025年2月"vibe coding"一词的诞生

这些数字放在一起，本能反应是"有一半是假的"。但本文的核心贡献在于：这些不是矛盾，而是对同一现象在不同测量维度下的不同读数。综述识别出六个稳定模式来解释这种离散——

模式一：效果收缩。测量范围越宽、时间窗口越长，效果就越是缩水。GitHub的55.8%是在95名开发者、以"完成任务时间"为计量单位的严格控制实验中测得的；Cui的26.1%是4867名开发者的实地实验，计量单位是每周任务量；METR的16名经验丰富的开源开发者独立随机对照试验测的是完成时间，结果是-19%。样本量、任务类型、开发者水平、测量方式——每换一个维度，数字就变一次。

模式二：自我报告与独立测量的背离。凡是"开发者觉得自己变快了"的问卷，效果都是正的；凡是独立测量的实验，效果就大幅缩水甚至反转。METR的-19%是独立随机对照试验测出来的，不是开发者自评。这一模式在整份文献里稳定得令人不安。

模式三：产出量与生产力被混为一谈。许多报告把"提交的代码量"或"完成的任务数"当作生产力的度量。但Cui的+26%是"每周任务量"，Faros的+441%是"代码审查时间"，GitHub的+55%是"完成任务时间"——三者度量的根本不是同一件事。产出量上升的同时，审查、返工和修复的时间也在上升，后者往往不被计入"生产力"。

模式四：时间窗口决定结论。大胆的主张在更长的时间窗口测试后被收回。大多数研究只追踪了几天到几周，少数追踪了几个月。一旦把观察窗口拉长到"一个完整迭代"或"一个发布周期"，正面效果开始消退。

模式五：代码类型的分野。新代码 vs 成熟代码库——这是综述提出的核心猜想。所有正面效果都出现在"新代码"场景（新项目、新功能、样板代码），而负面效果几乎都出现在"成熟代码库"场景（修改、重构、维护）。

模式六：存活者偏差。目前还能被引用的大胆正面主张，是那些没有被更长周期的后续测试推翻的"幸存者"。而大多数早期主张——包括GitHub自己的55%——在更严格的独立复现后都打了折扣。

大家看图3，这张图横轴是证据审计质量层级，纵轴是效应大小。绿色点是正面的生产力爆款头条，红色点是负面发现。可以看到：所有正面结论都集中在低审计质量和中审计质量区间，而独立随机对照试验和遥测数据层级上，几乎全是负面发现。这不是巧合——它说明目前关于AI编程"大幅提效"的证据基础，整体偏脆弱。

图3：生产力声明审计质量层级与头条效应大小。绿色点为正面的AI生产力头条，红色点为负面发现；点面积与样本量的对数成正比

风险四重奏：安全、质量、版权与技能退化

如果生产效率的账还算不清，那风险的账就清楚多了。综述按照安全、质量、版权、技能四条线，把Vibe Coding的阴暗面整理了一遍。

安全：一把双刃剑，而且是严重不对称的双刃。先看好消息：AISLE的AI系统在2026年1月OpenSSL协调安全更新中发现了全部12个此前未知的漏洞，其中5个连修复补丁都写好了且被维护者接受；Google Project Zero和DeepMind合作的Big Sleep系统在FFmpeg、ImageMagick等广泛部署的库中报告了20个此前未知的漏洞，发现阶段完全不需要人类协助；OpenAI的Codex Security在beta期扫描了超过120万次提交，报告了792个关键和10561个高严重性发现。

但坏消息也很刺眼。当Anthropic的受限访问模型Mythos在2026年5月被用来跑curl时，它报告了5个已确认漏洞，但维护者审核后只有1个真实漏洞——20%的准确率。curl的创建者Daniel Stenberg由此直言："这个模型目前的大肆宣传主要是营销。"这说明AI在漏洞发现上的误报率基线高得惊人，独立验证仍是必需品。

质量：代码库正在"熵增"，而且是可测量的。GitClear的纵向研究（跨越多年代码库的统计分析）发现了一个令人不安的趋势：在AI辅助编程普及的同期，重构（refactoring）在所有代码变更中的占比下降了一半以上，而代码重复率显著上升、代码动荡度（churn）同步攀升。用一句话概括：开发者正在用"更多的新代码"替代"更少的重构"，代码库的可维护性在大规模数据中呈现出肉眼可见的退化。这正好和Willison的定义边界呼应——当开发者停止阅读AI生成的代码，他们也就停止了执行"区分重构和单纯替换"这种人类判断。

版权：悬在头上的达摩克利斯之剑还没落下来。主流AI编程模型都是在开源代码上训练的，但"训练数据的合法性"和"生成输出的版权归属"这两个问题至今没有定论。法律诉讼尚未给出决定性的判例，但企业采用AI编程时面对的版权暴露风险是真实存在的——尤其是当生成的代码与训练数据中的受保护代码高度相似时。

技能退化：最慢但最危险的风险。这点在综述里被反复提及但缺乏大规模数据支撑——因为技能退化需要数年时间才能显现。但目前有一个明显的替代指标：初级软件工程师的就业指数从2022年底的峰值到2025年9月下降了20%。当新手开发者从第一天开始就依赖AI写代码，他们的调试能力、架构判断力、代码审美——这些需要"读代码"才能建立的素养——是否还有机会形成？这是一个需要整个行业回答的问题。

开源社区的治理实验：AI作为审查者而非作者

开源社区——这个AI生成代码的最早尝鲜者群体——正在以惊人的速度形成一套治理共识。2026年FOSDEM闭幕演讲中，curl创始人Daniel Stenberg给出了一个影响深远的判断：AI增强人类有"坏的方式"和"好的方式"。坏的方式是AI生成的垃圾bug报告淹没维护者的时间——这个动态已经迫使curl在运营六年后关闭了HackerOne漏洞赏金计划；好的方式是AI作为静态分析器，在熟练的人类手里，悄悄发现以往任何工具都没找到的深层漏洞——curl通过AI分析工具修复了100多个代码问题，其中包含传统静态分析器未能发现的缺陷。

Linux内核社区在2026年把这种区分制度化：正式政策要求AI辅助贡献必须被打上"Assisted-by"标签，同时禁止AI智能体通过Signed-off-by机制认证开发者身份——因为"签名"意味着对代码负有个人责任，而AI无法承担责任。换句话说：AI可以帮忙写，但AI不能署名，也不能替人类做担保。

Rust项目则走得更远——直接发布禁令，禁止"vibe coded"贡献，成为第一个把Karpathy的造词写进官方政策的开源项目。Linus Torvalds本人的态度也很有代表性：他认可AI用于"起步"（getting started），但认为AI做"维护"（maintenance）是"一个糟糕的主意"（a horrible idea）。

把这些治理实验放在一起，能看出一条清晰的规律：最了解代码质量的维护者们，普遍接受"AI作为审查者"，普遍警惕"AI作为作者"。这个信号值得每一个把AI编程当"自动驾驶"的企业深思。

三条曲线的分歧：未来五年走向何方

图4把Vibe Coding时代的三个关键趋势画在了一张图上，堪称全文最浓缩的一页。上面那条曲线是AI编程能力——SWE-Bench Verified从1.96%冲到95.0%，指数级爆发。中间那条是随机对照试验中测得的开发者生产力——从+55.8%到+26.1%再到-19%，一路下滑。下面那条则是初级软件工程师的就业指数——从2022年底的峰值到2025年9月，跌了20%。三条曲线指向三个完全不同的方向。

图4：领域的三条分歧曲线——能力（顶部）、随机研究中的生产力（中部）、初级开发者就业（底部）

这三条曲线的综合，引出了综述最核心的可证伪猜想：AI编程的收益在新代码上是真实的，但在成熟代码库上会缩小甚至反转。写一个新函数的效率提升是巨大的，但在一个有着复杂依赖、历史包袱和隐性约定的生产代码库中修改逻辑，AI的收益会快速蒸发。如果这个猜想成立，那么目前文献中大部分看似矛盾的结论都可以被"测量的是哪种代码"这个变量所解释。

市场结构和成本分层也在同时演进。截至2026年中，前沿模型市场形成了明显的三个梯队：美国闭源权重实验室（OpenAI、Anthropic、Google、xAI）加上开源权重锚点Meta；欧洲的Mistral；中国梯队（DeepSeek、Qwen、Kimi、GLM）——从2022年的缺席到2026年已占据十家前沿厂商中的四席。自2024年6月以来，没有哪个单一模型能保持"实际默认选择"超过约六个月。近一半的模型发布是开源权重，但从业者语料倾向于将其视为边缘存在。

未来五年的走向，综述给出了一个冷静的预判：模型能力短期内不会见顶，但"能写代码"到"能维护系统"之间还有巨大鸿沟；生产力争论会在"新代码"和"成熟代码库"的区分下逐渐收敛；技能退化和代码质量的问题会迫使行业建立新的工程规范——就像Linux内核和Rust已经做的那样。AI从"自动生成"到"负责任地使用"的转变，将是未来几年软件工程最重要的叙事线。

最后看看这篇综述的语料底盘。表1给出了123份来源的证据分级构成：15篇同行评审论文、16篇独立研究报告和14篇新闻杂志构成"高证据"层的核心，而权重最低的厂商/平台发布材料只有16篇——一个相对健康的证据结构。这种跨学科、分级别的语料组织方式，正是它比此前任何单一学科的Vibe Coding综述都更有解释力的原因。

表1：引用语料构成及每个类别对应的证据层级。另有54个来源被分类但未被引用

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？Karpathy命名的Vibe Coding一年间成为现象级词汇。这篇跨学科综述汇总123份证据，发现AI编程早期基准几乎饱和，但独立实测显示成熟项目开发者减速19%、代码审查时间暴涨441%，并系统剖析安全、质量、版权与技能萎缩

这篇工作最值得看的点是什么？作为综述，本文系统性地整合了123个来源的证据，包括15篇同行评审论文、16份独立研究报告等，提出了六个稳定模式解释生产力记录中的矛盾，并给出了可证伪的猜想。

这篇工作的边界或风险在哪里？优点：跨学科语料库整合全面，涵盖软件工程、人机交互、劳动经济学、安全研究、治理和教育；对生产力记录的矛盾给出了系统性解释（六个稳定模式）；提出了可证伪的猜想（代码库年龄假说）；对证据来源进行了分级（tier）管理，区分了不同可靠度的证据。缺点：作为综述，缺乏一手实验数据；部分结论依赖于厂商报告和灰色文献，证据质量参差不齐；对某些现象的量化（如安全事件频率）采用"模式确立即停止"的策略，未给出精确统计。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★☆☆跨学科整合框架和"新代码vs成熟代码库"的可证伪猜想有增量贡献，但整体未提出全新方法论。

实验合理度：★★★★☆语料来源分级透明，独立RCT和遥测数据被置于更高权重，但灰色文献采信标准仍带主观性。

学术研究价值：★★★★☆首次把多学科证据摊在同一张桌子上分析，六个模式和可证伪猜想为后续实证研究提供了清晰靶点。

稳定性：★★★★☆综述是静态文献快照，价值不随单点实验变化而失效；但无法对快速变化的模型能力保持实时更新。

适应性以及泛化能力：★★★★☆覆盖软件工程、人机交互、劳动经济学、安全、治理和教育多学科，框架可迁移到其他AI应用场景的评估。

硬件需求及成本：★★★★★纯文献综述，无需任何计算资源，阅读门槛就是时间。

复现难度：★★★☆☆一半以上语料来自灰色文献（博客、推文、厂商页面），许多需通过Wayback Machine回溯快照，复现成本偏高。

产品化成熟度：★★★★☆非产品，但核心结论对工程决策有直接参考价值——尤其"新代码受益、成熟代码库需谨慎"的猜想可直接用于团队采用策略。

可能的问题：跨学科深度天然受限，每个学科内部的关键细节可能被简化；部分结论依赖少量独立研究；对中文社区和国内大模型生态（DeepSeek、Qwen等）虽然提了但着墨较少。

主要参考文献

[1] Michels D L, Ghazaleh M A, Lazzari F, et al. Vibe Coding: Practice, Performance, Productivity, and Risk—A State-of-the-Art Review. arXiv:2608.20446, 2026.

[2] Chen M, Tworek J, Jun H, et al. Evaluating Large Language Models Trained on Code. arXiv:2107.03374, 2021.

[3] Cui Z, et al. The Effects of Generative AI on High-Skilled Work: Evidence from 4,867 Developers. Management Science, 2025.

[4] METR. Randomised Controlled Trial of AI Coding Assistants on Experienced Open-Source Developers. 2025.

[5] Karpathy A. tweet on “vibe coding”, X (Twitter), 2 Feb 2025.

[6] Jimenez C, et al. SWE-Bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024.

[7] Scale AI. SWE-Bench Pro: Contamination-Resistant Benchmark Evaluation Report.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！