学术乱象? 如何正确对待? AI整理版本 关于近期学术造假行为的观察与反思有感于近期曝光的多起著名学术造假事件，本文旨在结合当前学术界的实际情况，对论文造假乱象的现状、深层成因以及严重后果进行综合探讨。一、 近期学术乱象观察：顶刊滤镜的破灭近期，同济大学与中山大学接连爆出《Nature》及其子刊论文造假的丑闻，且据公开消息已基本坐实。这一现象暴露出几个关键问题：造假手段拙劣： 作为国际顶刊，这些论文备受关注。面对众多机构复现失败的情况，相关机构不仅未能给出合理解释，论文中反而被发现存在明显的数据篡改痕迹。“水刊”现状堪忧： 审核严格的顶刊尚且存在如此严重的造假问题，且需网友实名举报才能揭露，国内部分核心期刊、“水刊”的学术规范性更是不容乐观。造假已成常态： 这一系列事件初步印证，论文造假在当前的学术圈内已非新鲜事。二、 论文造假泛滥的深层成因论文评价体系与实际利益的高度绑定，是导致学术不端行为（如利用AI生成论文、找人代写、导师抢夺一作等）屡禁不止的核心驱动力。具体而言，可以分为两种截然不同的情况：1. 造假动机的分类与定性A情况（生存驱动/被动型）： 许多科研人员（如面临“非升即走”的高校教师、有毕业压力的研究生）本身可能不具备充足的科研条件或精力，但在硬性考核指标的逼迫下为了生存而“凑数”。这好比“饿了三天去偷包子”，虽不合规，但在现有评价体系下有其无奈的客观原因。B情况（利益驱动/主动型）： 部分学者为了评选院士、院长或正高等非必要头衔，在已有保障的情况下依然选择造假以牟取更高利益。这如同“为了买豪车去抢劫金店”，性质极其恶劣，完全无法原谅。近期曝光的顶刊造假事件明显属于此类。2. 惩戒机制薄弱与“甩锅”套路目前体制对学术不端的处罚过于轻微，导致造假成本极低。涉事机构在面对质疑时，往往采取以下几种套路应对：大事化小： 将明显的数据篡改定性为“图片管理不当”或“误用”，将主观造假降级为简单的失误。寻找替罪羊： 让课题组中无权无势的弱势群体（如挂名作者或普通研究生）承担责任，享受利益时没有份，出了事情却要“背锅”。冷处理： 避重就轻，拖延回应，等待舆论热度自然消散。三、 学术造假的严重后果与应对呼吁学术造假绝不仅仅是学术圈内部的道德瑕疵，它会带来实质性的社会危害：科研资源的严重浪费： 虚假的数据和结论会引导后续研究者在错误的方向上耗费大量的人力与物力。对公共资金与信任的背叛： 顶刊研究通常有国家基金支持，这些基金源自老百姓的税收。骗取基金不仅是对国家信任的辜负，更是对公共财富的挥霍。本质是经济欺诈： 带有基金支持的学术造假，本质上已经构成了经济欺诈。社会必须大幅提高对这类行为的处罚力度，让造假者付出相应的代价。即兴发挥版本一、近期学术乱象最近发生了两起著名的学术造假的丑闻，一个是同济大学的nature论文造假事件，另外一个是中山大学的论文造假事件。两起事件据公开消息，基本坐实存在造假的情况。由于两篇论文都是国际顶级期刊nature(包含子刊)。所以关注度较高，想要复现的机构也很多，所以被发现造假也很正常。从正常人的思维角度来看，我复现论文实验，没法成功，出现较大的差异，属于正常情况。但是当多家机构以及实验室复现实验都失败的情况下，论文发表的机构需要进行一个详细合理的解释。何况，这次两起事件，论文中都有明显的数据篡改的痕迹，可见造假手段之拙劣。由于是nature的缘故，所以这两篇有问题的期刊很快就被发现，且有网友进行实名举报，但是反过来想想? 那些不是顶刊的期刊或许会存在更加严重的问题。毕竟顶刊的审核相对来说都是比较严格的，但是依然出现了这么多的问题，可想而知，那么那些水刊呢? 国内的中科院top? 中文核心、北大核心?可以得到初步结论，论文造假在学术圈已经不是什么新鲜的事情了。二、什么导致论文造假泛滥呢?对于这个我倒是有很多亲身的经历。我曾经亲耳听到某理工类的高校的在读博士说自己的论文是gemini生成的，某某工程师或者学者找人代写论文，某某导师抢夺学生第一作者。此类事情实在是太多了，这些通通的导向了论文其实可以带来重大的实际利益。例如，一篇顶刊论文可以让老师评上一定的职称，可以申请更多的科研基金等等...… 所以论文在我国的评价体系中实在是非常重要，尤其在带有研究性质的机构中。但是，往往德不配位的情况会经常发生。我们需要一分为二来看，很多导师，因为种种原因，例如工作繁忙、家庭需要、自己科研能力差等等，实际上不具备什么科研的条件，但是受到学校和机构的要求必须要拿出一定的科研成果才可以满足考核要求，我称这种情况为A情况，主要代表不可抗因素逼迫发论文，经典代表为高校非升即走，研究生毕业要求等等。还有另外一种情况，例如某某老师为评院士、院长、正高等非必要的情况，从而需要有一定的学术成就，我称为B情况。在我看来A情况和B情况完全是两种性质截然不同的情况，像是本文一中描述的情况明显属于B情况，非必要的行为。若是为了A情况，从而去造假，貌似还有一定的合理之处，毕竟大家都是出来混口饭吃，基本的应付考核还是合情合理的。但是要是因为B情况从而去造假，那么我觉得完全不能原谅。虽然我承认，很多的论文造假是由于客观的要求不合理导致的，但是这也分为不同情况来看。为了非必要的事情进行造假，从而获取更多非必要的利益是完全错误的行为，我觉得和抢劫无异。我简单举个例子，假如我很贫穷，三天三夜没吃饭了，我去派出所食堂偷了5个包子吃。虽然这种情况属于非法，但是完全是事出有因，所以大概率不追究责任。但是假如我吃饱穿暖，但是我想买个豪车，所以我去抢劫金子，那么一定要受到相应的处罚。所以综上，我觉得B情况和抢劫金店无异，无非是方式不同罢了。那么是为什么让论文造假，抢夺学生挂名等等不端的事件屡屡发生呢? 原因是我们目前的体制对于论文造假的处理太过于轻微，造假事件即使被发现也无所谓，不会有什么严重的后果。就拿这次同济大学的事件来说。首先面对论文数据明显编辑过的情况，同济大学给出的结论是数据图片管理不当，存在误用现象。这一下就将事件由造假变为简单的失误。此外，退一万步，可以找课题组中的替罪羊来抗事情，这个替罪羊运气好点，可能是论文的挂名作者(二作以后)，运气不好连挂名都没有。有道是“虽然这篇论文带来的利益你一点都分不到，但是一旦出事就都是你一个人干的哦”，简直是猥琐至极。我们看最后同济大学的nature的一作那位博士后，虽然估计要担责，但是好歹也算是有一作，某种程度上来说也算是死得其所了，千万不要找一个无权无势的普通研究生来顶啊。那也太残忍了。除了大事化小、寻找替罪羊这两种手段，还有就是可以冷处理，等舆论过去也就算了。三、论文造假会带来什么后果呢?论文造假带来的客观影响就是，会导致浪费大量的人力物力在错误的方向上。大部分顶级的论文都有国家的基金支持，基金的来源是老百姓的税收。所以带有基金的顶级论文造假往往更加恶劣，毕竟假如只是水刊没有基金，那么造假就算了，一是不会有多少人关注没有影响力，另外就是，本身也是自费研究。但是有了基金就完全不是这样了，一旦带有基金就说明你的项目是党和人民对于你的信任，支持你研究，你的研究就不再是你自己的事情了，你需要为你所花费的每一分钱做出一个交代，为信任支持你的力量付出相应的责任。所以我觉得需要加大对于论文造假的处罚措施，这某种程度上就是经济欺诈，需要付出相应的代价。

深度调研：主流虚拟机与容器 GPU 直通（Passthrough）方案全解析 在高性能计算、深度学习及远程桌面（VDI）领域，如何让虚拟机（VM）或容器高效地调用宿主机显卡资源是核心课题。本文总结了目前主流的显卡直通技术路径，涵盖 Docker、Type 1/2 虚拟机及风扇控制等配套方案。一、 容器化方案：Docker GPU 调用对于不需要完整操作系统开销的场景，Docker 是最简便的选择。核心工具：nvidia-container-toolkit。实现方式：无需特殊启动命令，只需在标准 Docker 命令中加入 --gpus 标志。示例：docker run --gpus all nvidia/cuda:12.0-base nvidia-smi限制：目前该方案主要适用于 NVIDIA 显卡。二、 虚拟机监控器（Hypervisor）方案对比根据底层架构的不同，显卡直通的难度和稳定性存在差异。1. Type 1 Hypervisor（原生型）直接运行在硬件上，性能损耗极低，是生产环境的首选。平台特点直通方案Proxmox VE (PVE)开源、功能强大通过修改 vfio 配置实现。支持 TCC 模式切换（可将普通卡伪装成 Quadro 专业卡）。VMware ESXi企业级稳定8.0 免费版即可实现 GPU 直通，且 Linux 虚拟机下无需额外授权。Windows ServerWindows 环境友好使用 DDA (Discrete Device Assignment) 实现稳定直通，优于不稳定的 GPU-PV。2. Type 2 Hypervisor（托管型）运行在操作系统之上，通常用于个人开发环境。VMware Workstation：支持添加 PCI 设备进行显卡直连，但在性能和稳定性上略逊于 Type 1。Oracle VirtualBox：教程较少，直通复杂度高。三、 重点实战路径与教程索引🔹 Proxmox VE (PVE)PVE 在显卡直通上的灵活性最高。通过在直通设备上修改显卡 ID 为 Quadro 系列的 DeviceID，可以强行开启 TCC (Tesla Compute Cluster) 模式，这对提升计算效率非常有帮助。实战参考：PVE 8.4 针对 2080 Ti 及 3090 的直通指南已非常成熟。🔹 VMware ESXi 8.0ESXi 的图形化界面操作相对友好。避坑指南：在 ESXi 8.0 中直通 NVIDIA 显卡至 Linux 系统时，需注意驱动版本的匹配，部分场景下需要调整高级设置参数以绕过驱动限制。🔹 Windows Server (Hyper-V)在 Windows 环境下，DDA 是唯一推荐的生产级直通方式。相比之下，GPU-PV（半虚拟化）虽然设置简单，但在高负载下容易出现不稳定的情况。四、 特殊硬件与配套调优1. Intel DG1/DG2 显卡目前 Intel 独显在 PVE 和 ESXi 上的直通已有成功案例，甚至可以配合群晖 SA6400 驱动进行视频转码加速。2. 散热与风扇控制显卡满载运行会产生巨大热量。在 PVE 或 Ubuntu 宿主机上，可以通过 fancontrol 和 pwmconfig 工具实现根据 GPU 温度动态调整主板风扇转速，确保硬件寿命。五、 调研结论与部署策略经过对比测试，针对不同应用场景，我们制定了以下最佳部署实践：目标系统推荐宿主机平台直通技术备注Windows 虚拟机Windows ServerDDA稳定性最高，兼容性最好。Linux 虚拟机ESXi 8.0PCI Passthrough部署便捷，无需授权即可满足生产需求。计算性能测试Proxmox VE (PVE)TCC Mode未来计划使用 PVE 开启 TCC 模式，若训练提升明显，将作为 Linux 的首选平台。💡 技术核心点总结：WDDM vs TCC：WDDM 模式兼顾显示和计算，但有系统开销；TCC 模式完全为计算而生，能够显著优化 CUDA 内存管理和任务调度。vGPU 注意事项：对于整租 GPU 场景，vGPU-Unlock 等补丁项目通常无实际增益，应优先考虑物理直通。下一步建议：如果你需要开始部署，我可以为你整理 PVE 开启 TCC 模式的具体指令集，或者 ESXi 8.0 直通时的常用参数配置表。你想先深入哪一部分？

如何避免DNS劫持? 常见的科学上网姿势是购买一个机场，机场会给你一个订阅链接，将这个链接填入客户端（例如Clash）后，客户端会通过订阅链接下载一个配置文件到本地。在新手阶段，大家更关注的是节点（Proxies）和规则（Rules），这两者共同决定了不同目标网站的流量路径。直到遭遇DNS劫持。常见的节点类型包括ss、vmess、http，它们都支持流量加密和伪装，但节点地址都是以域名的形式表达的，那么就涉及到域名解析（DNS）。为了表述方便，将全过程简化如下：客户端A----DNS1----|墙GFW|----节点M----DNS2----目标服务器X一般来说，M是“看上去”身份合法的，GFW会允许A正常解析M的IP地址并连接到M。而一旦到了M，剩下的问题就不大了，M负责联系X，并将加密、混淆后的数据传给A。但某些情况下，GFW会“破获”某些机场使用的节点M们，或者某段时间检测到某个M流量突增，一看传输内容都是混淆后的不知所云的数据，再一检测又发现它并不是一个正常的网站，就有可能将它列入“嫌疑人名单”。那么为了阻止A连接M，通常采取的措施之一就是DNS劫持。在“客户端A----DNS1----|墙GFW|----节点M----DNS2----目标服务器X”链条中，前两个是在GFW的“势力范围”。很明显，DNS劫持将在“DNS1”这一步来实现。例如，某个节点的域名是xeqdfik3.abc.top，它正确的解析地址应该是：67.229.123.123（位于洛杉矶）。当GFW怀疑它时，就会强行在“DNS1”这一步，将xeqdfik3.abc.top的解析地址劫持为：221.228.32.13（位于国内某省某ISP数据中心），那么A就连不上真正的M，整个数据链当然就被破坏了。不仅如此，该数据中心还会不断收到你的请求“给我转接网站X！我的认证密钥是！”这就太尴尬了。所以，我们需要仔细研究一下配置文件中的DNS相关设置，对它进行一番必要的改造。这个配置文件，就是通过订阅链接下载下来的文件，对于Clash来说通常后缀名是YML。dns段dns段以“dns:”开头，通常位于配置文件的靠前位置。需要重点关注其中的“default-nameserver”与“nameserver”配置项。其中nameserver是Clash日常使用的主要设置。如果仔细看过多家机场的配置文件，就会发现一个惊人的事实：default-nameserver与nameserver中，大量充斥着这样一些IP：223.5.5.5（阿里）、223.6.6.6（阿里）、119.28.28.28（腾讯）、119.29.29.29（腾讯）、120.53.53.53（腾讯）、180.184.1.1（字节跳动）……出于“保护”你的需要，它们都会将一些“怀疑对象域名”的DNS解析劫持到错误的地址，让你无法访问，或干脆跳到反诈网站首页，甚至可以让你直接跳转到新浪。你的亲密战友“M”很可能不幸被列入其中。那么，是否将nameserver换成可靠的DNS，例如：8.8.8.8（Google）、1.1.1.1（Cloudflare），就一定能找到M了呢？未必。使用可靠的DNS当然会返回正确的解析地址，但这个正确的结果能不能递到你手上就难说了。因为默认情况下，整个DNS查询过程对于ISP来说仍然是透明的，GFW/ISP知道你是谁，也知道你在什么时候向8.8.8.8提出了一个域名M的解析请求，这仍然会暴露整个“不法行径”。同时，由于整个交易地点是GFW/ISP的主场，它可以强行改变结果，仿佛戴上了一枚“现实戒指”。打个容易理解的比方：你在街头想买点毒品，根据配置文件，你找的卖方（DNS）是223.5.5.5，它和你完成了交易，但卖给你的是假货，你回家发现这粉一点儿劲都没有————这就是你使用默认配置文件时发生的事情。第二次你聪明了，你修改了配置文件，找到了正确的卖方（DNS）8.8.8.8，它和你完成了交易，它拿出来的也是真货，但全程有一个警察站在旁边，他“啪”地一下打掉了8.8.8.8给你的真货（解析结果数据包），然后反手塞给你一包普通面粉。————这就是透明代理下发生的事情。所以，我们需要用到DoH（DNS over Https）。将nameserver的表达形式从IP改成一个https链接，如下所示：nameserver:- https://dns.google/dns-query # Google - https://1.1.1.1/dns-query # Cloudflare这就把默认情况下通过53端口与DNS的明文通信，变成了通过443端口与DNS的Https加密通信。虽然整个交易仍然在GFW/ISP的主场进行，但现场多了一只牢不可破的保险箱，你把解析请求放入保险箱，而DNS从保险箱里读取请求，并把解析结果也放进保险箱，你最后从保险箱中拿到结果————整个过程是加密的。从理论上讲，你们交易的可能是“毒品”，也有可能是完全无害的两只苹果，这就让GFW/ISP的干预失去了“法理基础”。好了，经过千辛万苦，客户端A终于知道了M的真实地址，下面可以愉快地通信了。别急，在clash的安卓端，在dns:段还有一个单独的设置：clash-for-android：clash-for-android: append-system-dns: false顾名思义，它的意思是，在DNS解析的时候是不是要加上系统（指的是安卓系统）自身的DNS啊？如果是国内品牌的安卓手机，那当然是信不过的；那如果是类似三星这样的国外品牌手机呢？其实也一样，因为在默认情况下，安卓系统会从ISP那里获取DNS，通常是你所在当地的、延迟低的DNS，以保障网络的通畅。所以，只要你用的是国内的ISP，那都是不值得托付的啊！所以这一项必须是false。fakeip与geoip根据以上设置完，所有的DNS解析都非常可靠了，但牺牲了速度：用Google和Cloudflare的DNS解析国内的网站很慢，有时候甚至需要好几秒，这很不爽。因此可以借用Clash自带的fake-ip和geoip，将国内与国外的DNS解析分开，同时提供DNS缓存功能。在dns段增加fake-ip和geoip的设定，同时将nameserver重新设置成国内的DNS：dns: enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 fake-ip-filter:- '*.lan' - '*.localdomain' - '*.example' - '*.invalid' - '*.localhost' - '*.test' - '*.local' - '*.home.arpa'nameserver:- 119.28.28.28 - 119.29.29.29 - 223.5.5.5 - 223.6.6.6fallback:- https://dns.google/dns-query - https://1.1.1.1/dns-query - 8.8.8.1 - 1.1.1.1fallback-filter:geoip: true注意，虽然nameserver又设置成了万恶的国内DNS，但fallback-filter设置为geoip为true，这一项确保了只有国内服务器地址才会被nameserve解析。国外服务器地址将使用fallback中的DNS——这就兼顾了安全与效率。开启fake-ip后，DNS服务器甚至不知道请求客户端的IP，这就进一步防止了泄漏。fake-ip还有一个好处是，由于它在DNS请求中加了一层（真实客户端IP-伪造的客户端IP），它还“赠送”了一个DNS缓存服务，这就使得你的DNS请求大部分时候直接从缓存中读取，无需请求DNS服务器，进一步提高了效率。需要注意的是，该模式下可能无法使用一些银行客户端APP，因为这些APP会检测客户端IP是否合法。一个局域网地址192.18.0.10显然不能过关。不过相信你应该知道如何设置Clash客户端的APP例外吧。hosts段对于机场提供的M们来说，你不需要了解它们指向的具体IP，因为很可能为了应对诡谲多变的网络环境，这些IP是会变化的，通过前文的措施进行可靠的DNS解析就可以了。那么还有一种节点，它是自建的，一般情况下，它的IP是固定的————这时候就可以采用更简单粗暴的方法：直接指定hosts。在配置文件中，hosts:段与dns:段平行，都属于最上一级。格式如下：hosts: "m01.abc.top": 152.22.10.10 "m02.abc.top": 69.13.125.105这样一来，啥DNS都不需要了，Clash将直接把域名替换成IP地址。解决了DNS劫持并不是万能的需要补充说明的是，前文都是围绕着如何把M的域名转换为真实的IP地址以建立连接，但对域名的DNS污染或劫持，只是GFW可能采用的部分手段，并非全部手段。GFW有能力直接屏蔽IP，这件事如果发生，那么M除了更换IP之外别无它法。幸好，GFW并不会滥用这个终极杀招，因为IP资源是有限的，某个IP也未必永远提供着“不良内容”，它有可能会被转手，也可能因为网络调整而变化。为了防止这件事发生，客户端A在和M接上头之后，如何进行隐蔽的通讯，减少M“毒贩”身份的暴露，也是有讲究的。tls加密常用的节点类型中，ss默认使用的是密码加密，也可以通过插件，再加上一层https，实现tls加密。而vmess和http原生就支持tls加密。但必须注意的是，我们需要在配置文件中指定这一点，才能强制它验证https证书和使用tls加密，以进一步确保数据的安全：tls: true skip-cert-verify: false当然，在这种设置下，要确保M的https证书保持更新。可以使用自动续期脚本来实现这一点。这样一来，客户端A与M之间传递的数据，将全部加密，某种程度上保护了M的安全，延长了M的“生命周期”。客户端设置配置文件经过上述的调整，已经可以满足安全要求。但在安卓版的clash客户端上，还有一些需要调整的地方。首先在“设置”-“覆写”-“DNS”-“策略”中，默认是“使用内置”，建议改为“强制启用”。这将强行使用配置文件中的设置，而不使用安卓系统内置的DNS服务。经过测试发现，移动运营商（联通、移动、电信在手机端）可能会不支持DoH，导致nameserver中的设置失效，其结果就是导致所有的M们都失联。这时候，Fallback Name Server的设置就派上了用场。在“设置”-“覆写”-“DNS”-“Fallback Name Server”中，添加8.8.8.8和1.1.1.1。当DoH不管用的时候，就会切换到这两个备用DNS。“覆写”功能是比较方便的，它让你不用每次都手动修改订阅链接下载下来的配置文件，而是用一套覆写规则自动覆盖相关条目。在“DNS”设置下，还可以参考前文，手动设置nameserver、添加Name Server策略等，此处不再赘述。原文来自lucyqin_blog: https://blog.lucyqin.cn/?p=1874