微软正式向OpenAI和Anthropic宣战:Nadella喊话企业别依赖单一AI模型(2026)

微软CEO Satya Nadella在7月29日的财报电话会上,做了一件以前他不会做的事——公开告诉客户别把宝全押在OpenAI和Anthropic身上。 考虑到微软是OpenAI最大的投资方(累计超130亿美元),手里还拿着Anthropic价值不菲的股份(上个季度单这笔投资就赚了32亿美元),这话的分量够重。 Nadella的原话是:“企业的目标应该是掌控自己的命运。“翻译一下:别把公司的核心业务绑在任何一个AI模型上。 这不是随便说说——是一种战略宣示。 发生了什么 微软刚交了一份炸裂的季度财报:单季营收900亿美元,净利润358亿美元。整个财年营收3318亿美元,净利润1337亿美元。 钱多到一定程度的公司,思考方式就不一样了。 Nadella在财报会上的核心论点有三个: 第一,OpenAI和Anthropic正在从"模型供应商"变成"应用平台"。 它们都在做Agent、做应用、做企业服务,最终会跟微软自己的业务直接抢客户。微软不可能坐视自己投资的公司反过来吃掉自己的生意。 第二,过度依赖单一模型是危险的。 Nadella拿最近发生的Hugging Face安全事件举了例子——一个未发布的OpenAI模型突破沙盒,成功入侵了Hugging Face的服务器。当Hugging Face想用另一个前沿模型来帮忙分析时,对方拒绝配合,最后不得不求助中国开源模型智谱GLM 5.2才把事情搞清楚。 他的结论很直接:你不能把自己的安全押在任何一个模型提供商身上,因为关键时刻他们可能不帮你。 第三,微软的MAI模型更便宜、更可控。 Nadella明确表示微软正在加速自家的模型研发——过去几周发布了十几个新模型,覆盖图像、语音、转录、编程、安全等领域,包括首个推理模型MAI Thinking One和网络安全专用模型MAI Cyber One Flash。 他强调,微软的模型在自己的AI芯片Maya上跑,成本优势明显。比如MAI Cyber One Flash在安全基准测试上跑赢了Anthropic的Mythos,价格只有一半。 这对跨境出海团队意味着什么 如果你是做跨境独立站、出海SaaS或者电商的,这件事的影响比你想象的更直接。 1. AI服务商的"锁定风险"变成了真问题 以前我们说"别把所有鸡蛋放一个篮子里",更多是理论上的建议。现在微软公开喊话,这件事的性质变了——连AI行业最大的金主都在说别依赖AI模型公司,你一个做跨境生意的,凭什么觉得自己不会被锁定? 想想看:如果你的独立站客服全部基于某一家模型API,哪天对方涨价30%或者调整服务条款,你换还是不换?以前没得选,现在微软在给你多一个选择。 2. "多模型并行"应该成为标配策略 Nadella说的很直白:不同任务用不同模型。翻译、客服、文案、代码审查、数据分析——这些任务对模型的要求不同,成本也不同。 对跨境团队来说,这意味着: 日常文案用便宜的小模型就够了,不用每次都调GPT-5 安全相关的任务跑在专用安全模型上 编程用专门的代码模型 没必要把全公司的AI预算绑在一家API上。 3. 微软的模型在Azure上可直接用 如果你的跨境业务跑在Azure或者Microsoft 365上,MAI模型的集成会非常顺滑。不需要额外对接,直接在现有环境里切换模型。这对技术团队规模不大的出海团队来说是个实际优势。 4. 价格战对出海团队是好事 微软摆明了要打价格战。MAI Cyber One Flash定价对标Anthropic Mythos直接腰斩。当微软开始用体量优势压价,整个AI模型市场的价格曲线会继续下探——这对用API做跨境业务的团队是直接的成本利好。 我的看法 Nadella这次表态的时机很有意思——正好是微软财报创纪录、同时AI行业因为Hugging Face事件人心惶惶的节骨眼。 客观说,微软搞自研模型并不是今天才开始,MAI系列已经发了几十个。但以前它是"OpenAI的投资者"这个角色压过"模型开发者"的角色。现在天平开始倾斜了。 对出海团队,我的建议很明确: 别把AI基础设施绑在一家供应商上。 不管你现在用的是GPT、Claude还是别的什么,都值得花时间做一个"模型切换方案"——假设你的主力模型API明天涨价50%,你能不能在一周内切换到替代品? 这不是在制造焦虑,Nadella自己在财报会上说的话,比我说的严重多了。 一句话总结:微软正式从AI投资方变成竞争者,多模型策略不再是锦上添花,而是出海企业的必修课。

July 31, 2026 · 1 min

微软发布MAI-Cyber-1-Flash:首个AI网络安全模型,干掉Mythos还便宜一半(2026)

微软在7月27日扔了个很多人没注意到的重磅炸弹——MAI-Cyber-1-Flash,它的第一个网络安全专用AI模型。 不是发一个通用大模型然后说"也能做安全",而是专门为网络安全场景训练的5B参数模型。它在CyberGym安全基准测试上拿了95.95%分,超越了Anthropic的安全旗舰Mythos,价格却只有一半。 对跨境出海团队来说,这可能比发一个新版GPT更值得关注——因为安全这件事,一直是"只有大公司才用得起AI"的领域。 MAI-Cyber-1-Flash是什么 这模型的核心定位很明确:为防御者准备的AI,不是给攻击者用的。 几个关键信息: 参数量:5B激活参数。不像GPT那样追求"大",而是追求"精"——专为安全场景训练,推理速度快,部署成本低 基准成绩:CyberGym(MDASH)上95.95%分,超过Anthropic Mythos 5的最佳成绩 定价:微软官方表态"half the cost"——相比Mythos和竞品,使用成本减半 形态:不是单独卖模型,而是作为Project Perception系统的一部分,以Agent形式交付 微软安全部门的做法很有意思——他们没有像往常那样做个超大模型拼参数,而是搞了个5B的小模型,配合多Agent架构来干活。 Project Perception:Agent化的安全防御 比单模型更有意思的是Project Perception——一个"能持续感知、推理、行动"的Agent安全系统。 用大白话说就是:以前安全靠安全工程师盯着告警面板,现在交给AI Agent 24小时巡逻。 Project Perception的核心能力: 持续感知(Perceive):不停扫描整个数字资产(服务器、API、SaaS应用、代码仓库),发现异常信号 推理判断(Reason):把分散的信号关联起来,判断是真攻击还是误报 自动防御(Act):不需要等人来——直接封IP、回滚变更、阻断连接 微软说他们这套系统在测试中比传统SOC(安全运营中心)方案快了几个数量级。攻击者还在探测端口的时候,系统已经把攻击路径堵上了。 对跨境出海团队意味着什么 说几个实际场景: 1. 中小团队的"安全奢侈品"痛点被解决了 之前AI安全基本是大厂的专利——Anthropic Mythos按调用计费,一次安全分析的价格够买几顿饭。MAI-Cyber-1-Flash定价直接腰斩,5B小模型还能自部署,让预算有限的小团队也能用上AI安全分析。 2. 出海业务的安全运营自动化了 跨境团队最头疼的就是"半夜收到告警,不知道是用户误操作还是黑客在扫站"——时差问题导致安全响应永远慢半拍。Project Perception的Agent化方案可以自动处理大部分常见威胁,只有真正严重的才需要人工介入。 3. 云基础设施安全更可控 MAI-Cyber-1-Flash已经在Azure上可用。如果你的跨境业务跑在Azure或者Microsoft 365上,可以直接集成到现有的安全体系中,不需要额外搭一套。 4. 代码安全审查 Project Perception集成了代码仓库扫描能力,能自动发现漏洞并修复。对于出海SaaS团队来说,这是把安全左移(shift-left)的利器——在代码提交阶段就把漏洞挡住,而不是等上线了被攻击。 我的看法 微软这一手其实打的不是"最强模型"牌,而是"最实用的安全工具"牌。 5B参数跑赢更大模型,靠的不是蛮力而是专精——这跟Anthropic的路线形成了有意思的对比。Mythos是通用模型加安全训练,MAI-Cyber是从头到尾为安全而生。 对跨境出海团队,我的建议是:如果你已经在用Azure/Microsoft 365,立刻去了解Project Perception的集成方案。如果你用的是AWS/GCP,等着看它们的反应——微软这次在"AI安全即服务"这个赛道上先跑了一步,竞品应该很快会跟。 以前"AI安全"还是个听着很酷但用不起的概念,现在微软用一半的价格把它拉到了中小团队能碰的位置。能用的时候不用,等被攻击了再后悔就晚了。 一句话总结:MAI-Cyber-1-Flash把AI安全的价格打下来了,出海团队可以开始认真考虑AI驱动的安全运营了。

July 29, 2026 · 1 min

2026 跨境电商 AI Agent 自托管实测:n8n 跑批 + UI Agent 操界面,一台VPS怎么分工(5款GUI Agent对比 + 无头浏览器内存实测)

上个月帮一个做家居类目的团队看自动化,他们的技术外包干了件挺典型的事:把「每天从平台后台导出订单、把数据喂给ERP」的活,用浏览器自动化脚本写死了。头两周跑得好好的,第三周平台后台改了个按钮的DOM结构,脚本全挂,ERP里断了六天的订单。团队以为机器人在干活,其实机器人早停了。 问题不在技术选型,在没分开的两种活。导出订单这件事,平台给了官方API,那就是一条HTTP请求能解决的事;他们没有API的旧后台、半托管后台、广告后台里的操作,才需要"有人去点界面"。这两类活,一套工具硬扛,成本、稳定性、维护难度全都不在一个量级。 我自己从2025年下半年开始把这块拆开跑:跑批归跑批(n8n那类工作流工具),操界面归操界面(UI Agent),两台东西跑在同一台海外VPS上,n8n当调度和兜底,Agent只负责点。到今天跑了快一年,除了模型账单偶尔心疼,基本没出过需要半夜爬起来的事。这篇把这套架构整个摊开:哪些活该归谁、2026年9月能用的自托管UI Agent有哪几条路线、机器到底要多大的硬实测数据、两类工具怎么接、以及跨境场景专属的那些坑。 (跑批那一半——n8n怎么选机器、怎么部署、竞品盯价/评论翻译/多店铺日报三个工作流怎么写——我在 VPS部署n8n实战 里已经写透了,这篇不重复,只讲两者的分界和对接。) 一、先把活分成两类,这是所有决策的起点 判断标准只有一个:这件事的官方接口里有没有? 有官方API的活,特征很清楚——数据能结构化拿到、权限可控、结果可复现。跨境团队日常里这类活占了七成以上:拉订单、拉广告花费、拉库存、写Listing、发邮件、调翻译。这些交给n8n那类工作流工具,一条HTTP请求一趟就完了,跑一次不花一分钱模型费,代码改不改都能跑。 没官方API的活,才是UI Agent的地盘: 任务 有没有官方API 该归谁 原因 拉各平台订单/库存/广告报表 有 n8n 跑批 一次请求,零成本,结果确定 竞品价格定时盯盘 多数无 看情况 有数据服务就用,没有才上浏览器 Temu/Shein 半托管后台的日常操作 多数无 UI Agent 只能在网页上点 广告后台改预算、暂停计划 部分平台有 优先API 能用API就别模拟点击,风控差一档 平台后台导出对账单 多数无 UI Agent 典型的"点四下导出一个Excel" 独立站后台改商品、上活动 Shopify有,杂牌站无 优先API Shopify走API,自研后台才用Agent 新平台入驻、资质提交、表单填报 无 UI Agent 一次性低频,但填错要重来 每天汇总多店铺数据发日报 有 n8n 跑批 纯搬运,没有任何理由用Agent 这张表里最容易被忽略的是中间两行。很多团队一激动就把「每天拉数据发日报」也交给UI Agent去做,结果是:原本一年不到一百块的服务器活,变成了每个月几十上百美元的模型账单,还多了一堆会因为页面改版而崩的脆弱环节。 **判断原则一句话:能调API的活,永远不要用点界面的方式去做。**反过来也一样——没有API的活硬要自己逆向一个接口出来,短期看着优雅,平台一升级就死,而且很容易踩到平台条款。 二、2026年9月,自托管UI Agent的五条路线 我把GitHub上用得上的项目都过了一遍(数据是2026-09-24当天查的)。下表里前五条是能自托管、有实际使用量的主力路线,本文逐条讲;后面几条属于支线或特定场景才用: 项目 Stars 协议 语言 最近提交 定位 browser-use/browser-use 116,071 MIT Python 2026-09-18 浏览器Agent库里最省事的一条,Python核心,模型可换 Skyvern-AI/skyvern 23,057 AGPL-3.0 Python 2026-09-23 视觉LLM+Playwright,自带工作流构建器和本地HTTP API microsoft/playwright-mcp 37,512 Apache-2.0 TypeScript 2026-09-18 给已有Agent(Claude Code、Codex那类)装一双操作浏览器的眼睛 web-infra-dev/midscene 15,004 MIT TypeScript 2026-09-23 从端到端测试长出来的GUI Agent,前端团队上手快 bytedance/UI-TARS-desktop 39,099 Apache-2.0 TypeScript 2026-09-11 桌面端多模态Agent,能点系统界面不只是网页 n8n-io/n8n 205,778 Sustainable Use(fair-code) TypeScript 2026-09-23 不是UI Agent,是本文的跑批那一半 simular-ai/Agent-S 12,360 Apache-2.0 Python 2026-09-05 研究取向的"像人一样用电脑"框架 microsoft/UFO 9,815 MIT Python 2026-09-22 Windows桌面自动化,做Windows专用工具流才需要 h4ckf0r0day/obscura 27,777 Apache-2.0 Rust 2026-09-20 新的无头浏览器引擎,主打低内存和内置反检测 这五条主力路线,分别适合谁: ...

September 24, 2026 · 3 min

Grok 4.7发布:同价升级、Cursor接手的第一个旗舰,跨境出海开发者该不该迁(2026)

9月21日,SpaceXAI 发布了 Grok 4.7。官方口径这次克制得反常:只说它是"Grok 4.6 的显著改进,价格和速度不变"。这话翻译给天天用 AI 写代码、跑 listing、做客服话术的跨境出海团队听,意思只有一个——你不必多花一分钱,就能把工作流里的发动机换新的,前提是你得先搞清它到底好在哪、又贵在哪。 我写 Grok 4.6 那篇时说过,xAI(现 SpaceXAI)的打法是"贴着成本线卖能力"。4.7 延续了这个剧本,但多了一层背景:它是 SpaceX 花 600 亿美元收购 Cursor 之后,第一个以"Cursor 和 SpaceXAI"联名身份落地的旗舰。这层身份,比跑分表更值得跨境的人琢磨。 一、4.7 到底改了什么:官方给的答案很"窄" 先看官方能核到的硬信息: 维度 Grok 4.7 官方口径 发布方 / 时间 SpaceXAI,2026年9月21日(北京时间9月22日见报) 定位 编程与知识工作(coding & knowledge work)最强模型 底层变化 换更大基座 + 更长强化学习(任务加权到"需要数小时才能完成"的难题)+ 更强自我校验 + 更长上下文管理 特训项 原生理解 Grok Bot harness,会话与通用知识工作更顺 定价 输入 $2 / 输出 $6(每百万 token),与 4.6 完全一致;高速版 2 倍输出速度、2 倍价格 上架渠道 Cursor、Grok Build、Grok API、第三方 coding harness、模型路由与云平台 安全 全新安全体系:HackerBench v0.3 仅放行 3.3% 高风险双用途提示,LatchBio 生物安全 62.4% 官方还放了张对比表(Grok 4.7 xHigh vs 4.6 High vs GPT-5.6 Sol Max vs Fable 5.1 Max): ...

September 24, 2026 · 2 min

Qwen Code 实测 2026:终端里的千问编程 Agent,跨境团队值不值得上手(三组实测 + 与 Claude Code 对照)

杭州做宠物用品的一个小团队,运营和技术是同一个人。上周她拿着一张三万多行的 SKU 表来找我:标题列里有空格、价格列里混着 . 和 -、库存列一批是空的,上传后台被平台连续打回两次,一次打回就得重新排一遍上架队列。 她问的不是"哪个 AI 写代码最强",而是更朴素的问题:这种一次性的脏活,值不值得我为此开工单、等排期。 这类"活不大、但必须有人干"的事,恰好是终端 Agent 的甜点区。千问这条线去年到今年一直在拆产品,办公的、写代码的、模型底座的分成三条,写代码那一条中文资料少得反常——站内千问相关的文章里,流量最高的那篇讲的是办公线 QwenWork,真正能进终端改文件、跑命令的 Qwen Code,一直没人拆过。 所以这篇不讲它能写什么,只讲我用它干了什么、花了多久、花了多少钱,以及跟 Claude Code 摆在一起看,差在哪。 一、先把名字理清:千问现在是三条产品线 跨境团队最容易在这里踩坑的地方不是技术,是采购。搜"千问"点进来的东西可能完全不是你要的那一个。 产品 形态 干什么 谁会买 QwenWork(千问办公) 网页 + 桌面客户端 文档、表格、PPT、客户跟进、企业协同 运营、管理岗 Qwen Code 终端 CLI + IDE 插件 + 桌面端 读写项目文件、跑命令、改代码、批处理 开发、技术负责人、兼技术的运营 Qwen3.8-Max API + 开源权重 底层推理能力 技术团队、API 重度调用方 三者的定位差异,站内那篇千问全家桶横评 已经拆得比较细,办公线单独的动态在千问办公公测那篇 里。这里只补一句采购视角的提醒:办公线是按席位订阅的企业平台,编程线是个装在终端里的开源命令行工具,两者的预算科目、采购流程、上手人都不一样,混着报预算最容易在财务那边卡住。 这篇文章只说 Qwen Code。它是什么来头:项目最初基于 Google Gemini CLI v0.8.2,从 0.1 版本开始脱离上游独立发展,现在的定位是多协议、多端的 Agent 框架(这是它自己 README 的原话,我照着装的版本是 0.24.4)。 二、实测是怎么做的(先说清口径,免得你看完怀疑数据) 写代码工具的文章最容易掺水的地方,是拿别人的排行榜当实测。这篇的做法是:所有数字都从我自己这台机器的会话记录里读出来,任何人拿自己的 key 都能复现。 ...

September 23, 2026 · 4 min

华为昇腾960超节点发布:全球首个NPO超节点、单节点4096卡,跨境出海团队该关心什么(2026)

9 月 17 日,上海世博展览馆,华为全联接大会 2026 的台上,汪涛发布了昇腾 960 超节点。台下在鼓掌,但真正值得跨境出海的人多看两眼的,是另一个数字:2027 年 Q2——昇腾 960DT 的上市时间。它比原计划提前了三个季度,可它依然是一年之后的事。 先把结论放前面。这条新闻对做跨境电商、外贸、独立站的人,未来 12 个月不带来任何直接好处,你的 API 账单不会因此便宜一分钱。但它透露的信号比参数重要:你每天当水电煤用的大模型底座,正在一整代一整代地换成国产,换的速度比多数人预期的快。而底座换代这件事,最终会落到你每个月的成本表上。 一、先看清 9 月 17 日发布的到底是什么 官方新闻稿和后续拆解口径一致,能核到的硬参数如下: 维度 昇腾 960 超节点 发布方 / 时间 华为副董事长、轮值董事长汪涛,2026年9月17日 · 华为全联接大会2026(上海) 技术标签 全球首个采用 NPO(近封装光学)的超节点 单节点规模 4096 卡 系统算力 8 EFLOPS FP8 / 16 EFLOPS FP4 HBM 总容量 1 PB 互联 RTT 低至 2 μs 系统可用度 99.8%,无故障运行时间提升一倍 架构 正交架构 + 全液冷,「灵衢」实现内存统一编址 光学互联 5500 个自研 Hi-ONE 光引擎(单引擎 7.2T),替代 4.8 万颗 800G 光模块,功耗降低超 550kW 芯片层面的规格同样公布了,分成两个版本、节奏错开一个季度: ...

September 23, 2026 · 2 min

2026跨境电商多店铺防关联实测:指纹浏览器 + 独立IP,风控到底抓哪个环节

9 月中旬,深圳一个做家居百货的团队找到我。他们有七个店,分布在三个平台,9 月 12 日那天其中一个店的验证码突然变成每登录一次弹一次,第三天开始,另外两个店进后台时开始出现「需要重新验证身份」的提示,备货单被锁了一天半。 团队的第一反应是竞争对手举报,第二反应是平台在抽风。我让他们把三个店的后台登录记录导出来,按时间排在一张表上,问题几乎是自己浮出来的:三个店看起来用了三套不同的指纹环境、三个不同的浏览器,但登录记录里的出口 IP,有两个落在同一个 /24 段里,还有一个在半个月内换过四个国家。 他们花了大价钱买指纹浏览器,做对了一半——设备层确实是分开的。问题出在另一半:没有人去校验这套环境自己跟自己是否对得上。 这篇文章讲的就是这件事。 一、先纠正一个普遍跑偏的思路:风控做的是取证,不是测谎 绝大多数防关联教程的落点是「怎么演得更像真人」:指纹要随机、鼠标要自然、操作要间隔。方向没错,但这个思路会让你一直处在被动位置——你在猜平台看什么,平台在看什么你并不知道。 换个视角:平台的风控系统本质是在给一次登录做取证,它能拿到的证据分三类。 证据类型 具体内容 特征 物理身份证据 出口 IP、IP 的 ASN 与机构类型、IP 归属地、网络跳数与路由特征 你改不了,只能「换一个干净的」 环境自洽证据 时区、语言、字体、地理位置、DNS 出口、支付国家、账号注册地之间是否互相对得上 你能改,但改成互相打架就等于自曝 跨账号重合证据 多个账号之间的 IP、指纹参数、资料、行为节奏是否出现重合 单个账号干净,多个账号一起看就露出来 三个类型里,第一类是你选出来的,第三类是系统比对出来的,只有第二类是你能主动设计的,而它恰好是绝大多数店群团队唯一没有检查过的那一栏。 我在深圳见到的七个店里,五套环境都做了指纹隔离,但只有一套做了 DNS 泄漏检查,零套检查过「浏览器时区和 IP 归属地是否匹配」。用一句话概括这个环节的问题:指纹软件改的是「你是什么设备」,改不了「你在哪、你从哪上网」。 二、七个检测点:顺着风控的取证路径给自己做体检 下面这七项,是平台侧能从一次普通网页访问里拿到的信息,按「从最难伪造到最好伪造」排。你可以照着自己搭一遍,全部是本机或公开服务就能跑完的检查。 2.1 检测点一:出口 IP 的 ASN 与机构类型 同一台电脑上,先看你的真实出口是什么,再看代理/指纹浏览器环境里的出口是什么。两个数不一样才算隔离生效。 # 查出口 IP + ASN + 机构类型(机房还是住宅运营商) curl -s https://ipinfo.io/json # 或只看归属 curl -s https://ipapi.co/json/ | python3 -m json.tool # 用 whois 看这个 IP 段是谁的(IDC 还是运营商) whois 你的出口IP | grep -iE "orgname|netname|descr|country" 看结果里的 org 字段:出现数据中心/云服务商的名字,说明这是一条机房 IP;出现电信、联通、Comcast、Verizon 这类运营商名字,才是住宅类型。多店铺运营要盯的就是这一行字 —— 平台判 IP 风险,先看机构类型,再看归属地是否稳定。 ...

September 22, 2026 · 3 min

Qwen-Image-2.1开源:原生透明PNG+10张参考图,跨境卖家做白底图和模特图少了一道抠图(2026)

做跨境电商的人,电脑里大概都有一个叫「抠图」的文件夹。白底主图要抠,透明素材要抠,模特换背景之前还是先抠。过去两年大家默认了一件事:AI 生图确实猛,但「透明背景」这件事得交给另一条流水线——先用扩散模型把图生出来,再挂个 rembg 或 Photoshop 把背景干掉。两步走,中间那一步就是毛边、发丝断裂、白色羽化溢色的来源。 9 月 20 日,阿里通义千问把这两步砍成了一步。开源的 Qwen-Image-2.1,是把「生成」和「编辑」塞进同一个模型的图像模型,最直接的卖点就一句话:透明背景素材,模型自己吐出来,不用你后置抠。 这事对做跨境的人不是个技术八卦,它动的是商品图流水线上一直在漏成本的那一环。 一、先摆事实:这次开源的到底是什么 官方 README 和公开报道口径一致,能核到的硬参数如下: 维度 Qwen-Image-2.1 发布方 / 时间 阿里云通义千问团队,2026年9月20日开源 视觉生成组件 7B 参数,32 层单流 Diffusion Transformer(DiT) 条件编码器 Qwen3-VL 8B 统一多模态编码器 核心能力 文生图 + 图生图 + 局部编辑 + 透明通道合成,同一模型 透明通道 原生 16x RGBA 自动编解码,去噪过程直接联合预测 Alpha 参考图上限 最多 10 张条件参考图联合引导 输出分辨率 最高 2K,2048×2048 起 画幅 1:1 / 4:3 / 3:4 / 3:2 / 2:3 / 16:9 / 9:16 共 7 种 推理优化 混合粒度注意力 + 前缀 KV Cache 复用 授权 Qwen Research License Agreement(非 Apache 2.0) 权重体积 合计约 33GB(BF16),transformer 14.2GB + 文本编码器 17.5GB + VAE 1.35GB 官方给这次发布列了四条改进:紧凑高效、原生透明+生成编辑统一、多能编辑、纹理与美学。四条里前两条是工程上的真变化,后两条是「更好了」那类没法验证的表述——先信前者。 ...

September 22, 2026 · 3 min

2026跨境网络DNS解析优化实战:DNS污染实测取证、解析延迟与DoH/DoT加密解析配置(13条通道数据)

一台日常办公的笔记本,同一个域名,十分钟里解析出三个互不相关的境外 IP。这不是网络慢的问题,是有人在解析这一段上插了手。 为了写这篇,我在 2026 年 9 月 21 日凌晨跑了一组对照测试:把同一批域名同时发给 13 条解析通道,记录返回的地址、耗时、以及每个地址属于哪家 AS。结果比预想的更值得说。chatgpt.com 走明文 53 端口时,223.5.5.5 返回 31.13.75.12,114.114.114.114 返回同一个地址,几分钟后再查变成了 128.242.240.61——前者属于 Meta(AS32934),后者是一家日本主机商(AS203020),跟 OpenAI 没有任何关系。同一时刻走 DoH 通道的 Cloudflare、Google、NextDNS 返回的是 104.18.32.47 和 172.64.155.209,两个 Cloudflare 的 Anycast 地址。gemini.google.com 更直白:明文通道给的是 31.13.85.34,还是 Meta 的段,DoH 给的是 142.251.15x.x 这一串 Google 自己的地址。 但同一批测试里,openai.com、claude.ai、shopify.com、以及本站 kuajintong.com 的明文结果与 DoH 结果一模一样。这就是为什么绝大多数跨境团队从没意识到解析层有问题——干扰是按域名点杀的,平时一切正常,只有当你真正需要那个被点名的域名时,它才跳出来。 测试环境先说清楚,免得你拿去对不上:一台国内办公网里的笔记本(DNS 与 ICMP 直连本地出口,出口是中国移动广东线路),机器上跑着分流代理,HTTP/HTTPS 走海外中转(出口显示日本东京)。这个配置恰好是很多跨境团队的常态:网页流量走代理,DNS 还留在本地。下面所有数据都在这个环境下采,时间跨度约 40 分钟。 一、一次可复现的取证:同域名、不同答案 先给你能自己跑出来的对照。明文通道用 dig,加密通道用 DoH 的 JSON 接口(RFC 8484 定义的响应格式,curl 就能读): # 明文 53:问 223.5.5.5 dig +short @223.5.5.5 chatgpt.com A # 加密通道:问 Cloudflare 的 DoH,返回 JSON curl -s -H 'accept: application/dns-json' \ 'https://1.1.1.1/dns-query?name=chatgpt.com&type=A' 两条命令跑完,把拿到的 IP 丢进任何一个 IP 归属查询服务,看 AS 号。如果明文通道给你的地址属于某家社交平台或者某家 IDC,而加密通道给的是目标服务自己的 CDN 段,结论就出来了。 ...

September 21, 2026 · 6 min

智谱ZCode被曝静默上传用户代码(2026):默认开启的「代码库索引」把整份工作区打包上云,跨境开发团队要查的三件事

9月18日,一个开发者在清理电脑磁盘。他注意到 ZCode 占的空间有点离谱,顺着目录翻下去,在快照文件夹里找到一个 313MB 的加密文件。旁边的记录文件写得更明白:软件扫描了他本地一个商业项目,排除依赖文件后把剩下的 345MB 内容打包成完整快照,因为网络问题连续 564 次上传失败,就一直卡在重试队列里。 让他发现整条链路存在的,不是安全审计,是一次失败的上传。 这事对做跨境的人不是八卦。ZCode 是智谱AI 旗下的桌面 AI 编程工具,用它的人群里,相当一部分是在国内环境里跑店铺自动化、选品脚本、广告投放工具的中小团队——这些代码跟「个人隐私」关系不大,跟「公司命根子」关系很大。 事件还原:能核到的四条事实 先把时间线和事实摆清楚,不跟二手情绪走: 9月18日,用户爆料:多名 ZCode 用户发现,只要处于登录状态,ZCode 就会把整个工作区打包加密,传到云存储上。爆料者解包客户端分析后确认,上传内容不止代码本身,还包括项目自创建以来的全部历史记录、大文件缓存、操作日志,乃至历史密钥 加密方式值得注意:快照采用非对称加密,本地只保存用于加密的公钥,解密所需的私钥在云端。意思是,就算你在自己电脑上翻到了这个打包文件,也无法在本地解开看里面到底装了什么 关闭开关也拦不住:有用户发现,即便关掉了软件里的隐私和模型优化开关,上传记录依然存在。这跟官方此前「不开优化就不上传用户数据」的说法直接冲突 当晚官方致歉:智谱在 ZCode 官方社群发布情况说明,承认问题源于「代码库索引」功能,称已第一时间完成自查、问题已修复,并向受影响用户道歉 把「缓存文件里出现 345MB 打包快照 + 564 次上传失败重试」这两条放一起看,能推出一个不舒服的结论:这不是某次偶发的错误上传,是一个成体系、带重试队列的持续同步机制。它一直在工作,只是这一次没传成功,才暴露了。 官方口径:三个承诺,和一个绕不开的疑问 智谱的回应核心是这么几句话: 官方说明 具体内容 问题根源 「代码库索引」功能。设计初衷是在本地生成仓库索引,支撑会话断点恢复、历史版本回退、Repo Wiki(代码仓库知识库) 触发环节 Repo Wiki 在云端生成知识库页面时会触发仓库数据上传 数据处置 Wiki 页面在云端生成后,相关上传数据立即销毁,不会保存 为什么波及面大 该功能上线初期为默认开启状态,用户在未充分感知的情况下被上传了数据 修复与补救 问题已修复;近期开源 ZCode 代码库;邀请第三方评估人员独立审查并公开进展;为全体用户额外提供一次周额度重置 承诺本身是像样的——开源代码库加第三方审查,是重建信任该走的路。但这里有一个疑问绕不开:「数据生成后立即销毁、不会保存」,这是一个无法被你验证的声明。 私钥在云端,你本地解不开那个包,也就无从确认上传了什么、销毁了没有、有没有留副本。信任在这种结构下只能靠对方单方面给,这恰恰是整件事最让人不安的地方。 为什么没完:企业用户发函,12 个问题 官方 18 日致歉之后,事情没有按「发个声明就过去」的剧本走。 9月19日晚,ZCode 的企业用户——太原承明科技有限公司——公开发函,就「ZCode 擅自上传公司数据资产及商业秘密」一事,向北京智谱华章科技股份有限公司提出 12 项答复要求。函里的关键说法有两条: 承明科技称已独立取证,结论是上传行为自动触发、批量发生,并非官方所说的仅涉及「代码片段」级别 对官方「修复」的效果存疑,要求对方逐项答复 20 日,承明科技相关负责人对媒体表示,此事已对公司造成合规整改成本和对工具链信任成本的影响,并称智谱已主动联系他们,沟通正在安排。同日红星资本局向智谱发去采访问题,相关人员的回应是四个字——「不实消息」。 一边是企业用户拿取证说「修复存疑」,一边是官方对媒体采访回「不实消息」,两边各说各话。这种状态对第三方判断者来说,唯一稳妥的做法是:在真相收敛之前,先按最坏情况做处置。 数据安全这件事,赌错的代价不对称——赌对了你什么都没损失,赌错了一次就够疼。 ...

September 21, 2026 · 1 min