技述 — JS.GRIPE

危险的认知：当 AI 繁荣成为一种解释世界的方式

toewpq — Tue, 10 Nov 2026 14:49:00 GMT

在上一篇《当语言改变答案：从语料污染、GEO 到大语言模型的判断边界》中，我讨论了大语言模型如何受到信息环境、训练数据和检索来源的影响。

文章最后留下了一个问题：当模型已经能够接触大量信息，它究竟能否分辨哪些内容是可靠证据，哪些只是同一观点的重复传播？如果新的证据与原来的判断发生冲突，它又能否据此修正自己的认识？

但这个问题不只存在于人工智能之中。

人同样生活在由语言、媒体、历史经验和社会关系构成的信息环境里。我们会依据自己掌握的证据作出判断，也会通过情感理解风险、利益和公平。一个人可以认真思考，却依然因为掌握的信息不同、对因果关系的理解不同，而与别人得出截然不同的结论。

尤其当讨论对象从历史事实变成财富分配、就业和技术进步时，认识上的差异可能进一步影响现实中的经济与政治行动。

最近有关 AI 泡沫的争议，让我重新注意到了这个问题。

AI 的繁荣，究竟意味着什么？

2026年11月9日，Anthropic 发布 Claude Fable 5.2。工程师 Felix Rieseberg 随后展示了一个由模型生成的网页射击游戏 Saltline。

根据开发者公开的信息，模型在没有中途人工反馈的情况下运行约八小时，按照 API 价格估算耗费约550美元，累计使用约4.45亿输入 Token 和270万输出 Token，其中大量输入命中了缓存。

这是一项相当值得关注的技术实验。过去可能需要程序开发、美术和声音设计共同完成的游戏原型，如今可以由模型承担大量制作工作。

但如果我们继续观察，这个案例还揭示了另一个问题。

开发者获得了一款游戏，却需要依靠远程模型完成此前的生产过程。模型服务涉及云端计算、服务器、电力以及供应商的持续维护。

游戏完成后，若源代码和资源能够独立保存，程序可以脱离原模型继续运行；如果部分功能需要远程服务，网络中断或供应商停止提供服务就可能影响使用。

这说明 AI 改变了软件的生产方式，却没有消除生产所需要的资源。部分成本从人工开发转移到了模型推理、云端基础设施和持续维护。

另一项值得注意的进展来自开放权重模型。

2026年，Kimi K3 以约2.8万亿参数的规模发布。社区随后出现了 kimi-k3-in-c 等项目，尝试在没有 GPU 的环境下，通过磁盘流式读取、低精度权重和缓存管理运行大型模型。

开发者公布的一组测试记录写道：

8 tokens in 261.5 s

即生成8个 Token 耗时261.5秒。

虽然该测试报告的峰值内存约为8.24GB，但完整模型仍然需要约1.56TB的权重存储空间，还需要额外空间保存预处理后的模型数据。

这项探索的意义不是让普通电脑立即拥有流畅运行万亿参数模型的能力，而是展示了社区如何利用不同的计算方法降低模型运行门槛。

开放权重使外部开发者能够研究、部署和改进模型，而不必将所有技术使用都绑定到原厂的在线接口。

这两项技术进展都是真实的。然而，技术能力的增长并不直接等于企业利润的增长。

一款游戏能够自动生成，不代表有人愿意长期购买；一款模型能够在本地运行，也不代表所有使用者都拥有足够的存储和计算资源。

这些技术变化最终创造了多少经济价值，仍然取决于它们帮助人们完成了哪些工作、降低了多少实际成本，以及有多少成果能够被持续使用。

当资本市场根据技术进展不断提高未来收益预期时，这个区别尤其重要。

2026年10月，国际货币基金组织在《全球金融稳定报告》中指出，AI 投资与盈利表现低于市场预期，可能引发相关资产价格调整，而债务融资和集中持仓会放大冲击。

一项技术可以真正改变生产方式，围绕它建设的部分基础设施却仍然可能出现投资过剩。

AI 技术是否成功、企业是否产生持续利润，以及社会是否真正获得相应收益，是需要分别检验的经济结果。

当机器生产的东西，越来越多地由机器使用

互联网正在发生一种变化。

AI 可以生成文章、图片、代码、视频和商品描述；搜索机器人与 AI Agent 又可以读取这些内容，将其组织成摘要、推荐或进一步的生成结果。

更进一步，机器已经能够执行支付。

2026年7月，Visa 与 Artemis 发布《Agentic Payments from the Ground Up》，研究 AI 代理参与的实际交易。

报告统计发现，x402 支付协议自2025年5月推出后，累计处理约1.096亿笔交易，经过调整的交易金额约为1500万美元。

Visa 将其中一类交易描述为：

payments that one piece of software makes to another

即软件向另一个软件支付费用。

这说明机器间支付已经不只是未来的设想。

但是，能够完成支付，并不意味着机器拥有脱离人类经济活动而独立产生的购买力。

如果 AI 代理替用户购买机票，支付的费用来自用户预算。如果它替企业采购 API 或计算资源，支出则来自企业的经营资金。

机器负责执行交易，真正承担费用的仍然是拥有资金并提出需求的人或机构。

因此，一亿次机器支付，并不代表出现了一亿次新的独立人类消费需求。

如果一家企业使用 AI 批量生成文章，另一家企业购买算力让 AI 阅读这些文章，第三家企业再根据阅读结果生成新的内容，那么这一过程会不断产生计算调用和商业支出。

但这些交易最终为人创造了什么？

如果文章帮助人们获得知识，程序完成了实际工作，或者自动化减少了企业的成本，那么价值具有明确的现实来源。

可如果数字内容主要为了吸引自动化流量而生成，随后又由机器读取、改写和重新发布，那么内容数量和计算调用的增加，就不能直接解释为相同规模的社会福利增长。

这也让我重新想到上一篇文章关于 GEO 的讨论。

当内容生产者越来越重视自己的材料能否被生成式搜索引用，信息生产的目标也在发生变化。

一份资料被 AI 引用，并不证明它已经通过事实核查；一篇文章得到大量爬虫访问，也不证明有相应数量的人真正阅读并从中受益。

当机器越来越多地生产、读取和购买数字服务，我们更需要追踪经济活动最终由谁承担成本，以及谁从中获得实际价值。

企业节省了劳动成本，人们的收入怎样变化？

如果只是讨论 AI 企业之间的交易，我们依然停留在技术产业内部。

我更关心的是，普通人的经济生活正在发生什么变化。

2026年9月，美国人口普查局发表工作论文《Graduating into Disruption: Labor Market Outcomes for AI-Exposed College Majors》。

研究者利用大学毕业生的行政就业和收入记录，比较不同专业在生成式 AI 普及后的劳动市场表现。

结果显示，在经过统计调整后，AI 暴露程度最高的10%专业毕业生，首次就业概率下降约5个百分点，毕业初期完整季度的收入下降约13%。

论文摘要中的原文是：

full-quarter initial earnings declined by thirteen percent

研究还发现，收入下降大约一半来自相关行业内部的收入降低，其余部分与毕业生转向餐饮、零售等工资较低的行业有关。

这项研究发现的是 AI 暴露程度与毕业生就业结果之间的差异，不能把全部变化都直接归因于 AI 替代。但它已经把技术变化与部分年轻人真实的收入处境联系起来。

另一项研究提供了相近的就业证据。

2026年8月，斯坦福大学数字经济实验室更新《Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence》。

研究使用 ADP 覆盖数百万名美国劳动者的薪资行政数据，发现22至25岁的年轻员工，在 AI 暴露程度较高的职业中，就业人数比按照低暴露职业同龄人趋势推算的水平低约19%。

研究者指出，这种变化主要通过减少招聘体现，而不是现有员工大量离职。

原文概括为：

reduced hiring of young workers rather than increased separations

这让我想到一个容易被宏观就业统计掩盖的问题。

一家企业决定减少招聘初级程序员、设计助理或文案人员时，现有员工可能没有立即失业，社会总体失业率也未必立刻出现明显变化。

但对于准备进入行业的年轻人而言，原本存在的职业入口已经变窄。

他们可能花费数年接受教育，却需要从收入更低的工作开始，或者延长求职时间。

与此同时，房租、交通、食品和其他日常开支不会因为一个人尚未找到理想工作而自动停止。

研究中的收入差异并不能直接换算成家庭消费下降比例，但劳动收入与家庭购买能力之间的关系非常具体。

一个人收入降低后，需要减少支出、使用储蓄、依靠家庭支持或增加负债来维持生活。

在必要开支之外，文化娱乐、旅行、电子产品、付费软件和个人学习等消费往往需要重新安排。

这些变化不仅影响劳动者自己，也会影响依赖普通消费者购买产品的其他企业。

从这个角度看，AI 对劳动市场的影响不能只通过企业节省了多少人力成本来衡量。

技术让某项工作更便宜，不等于原本依靠这项工作获得收入的人，已经找到了新的收入来源。

谁能持续为 AI 付费？

技术企业当然希望更多消费者购买 AI 服务。

但消费者的支付能力并不会随着模型能力提升而自动增加。

2026年10月，美国国家经济研究局发表《Competition in Generative AI: Evidence from Consumer Demand》。

研究利用约1.74亿名消费者、1140亿笔银行卡交易的数据，分析美国主要生成式 AI 服务的实际付费需求。

截至2026年4月，研究估计约2.9%的美国消费者为至少一项主要生成式 AI 服务付费。

绝大多数付费者购买的是每月30美元或以下的基础套餐。主要服务商的年度客户留存率则约在20%至45%之间。

这项研究衡量的是特定付费服务的消费者市场，并未包含全部免费用户、企业采购或 AI 带来的间接经济效益。

但它至少说明，模型能力快速进步，与大众愿意持续支付多少钱，并不是同步增长的指标。

人们购买一项 AI 服务，必须考虑它能为自己提供什么实际帮助，以及这笔开支是否值得。

对于依靠工资生活的人而言，订阅模型与购买食品、支付房租、储蓄或承担家庭费用，都需要从可支配收入中安排。

这使 AI 产业出现一个需要特别关注的经济关系：

企业越来越有能力通过 AI 降低生产所需要的人工成本，但大众能否购买新增产品，仍然取决于他们能够获得多少收入。

这不是说整个经济的消费只依靠工资。企业投资、政府支出、资本收入和国际贸易也会形成需求。

然而，劳动收入仍然是大量家庭获取购买力的重要来源。

如果自动化减少了部分人的收入，而效率收益更多地集中到资产所有者手中，家庭消费结构和市场需求就会受到分配变化的影响。

产品变得容易生产，不等于产品自动拥有购买者。

当 AI 企业成为彼此的重要客户

2026年10月，国际清算银行发表《Circular relationships among AI firms》。

研究发现，2021至2025年流入 AI 企业的投资金额中，55.2%来自其他 AI 企业。在 AI 企业之间的投资交易中，按金额计算，46.4%还涉及投资双方之间的商业供应关系。

研究者指出，这类关系会增加经济活动的不透明程度，并可能产生宏观金融风险。

2025年9月，CoreWeave 与 NVIDIA 签订初始金额63亿美元的云计算容量安排，为这种商业关系提供了具体案例。

CoreWeave 向美国证券交易委员会提交的 Form 8-K 说明，NVIDIA 在约定条件下需要购买其他客户未购买的剩余算力。

文件中的关键表述是：

residual unsold cloud computing capacity

即尚未售出的剩余云计算容量。

这份合同提供了销售保障，也让两家公司的商业利益更加紧密。

但供应商承诺购买剩余算力，与已经存在足够多的独立终端客户，并不是同一个事实。

如果一家模型公司依靠投资者资金采购云算力，云服务商再用预期订单扩大数据中心，那么这种扩张最终仍然需要有足够的客户收入或其他可持续现金来源来支持。

这正是 AI 泡沫争议的重要经济问题。

大量资本投入可能推动技术发展，也会形成建设、设备采购和就业活动。但如果最终需求无法支持长期经营，相关投资就可能无法获得预期回报。

这些风险还会影响实体经济。

数据中心需要电力、土地、服务器、冷却设备、建设工程和长期维护。一旦部分项目因融资困难停止建设，影响就不只发生在股票交易市场，还可能传递到设备供应商、建筑承包商、能源企业和当地就业。

因此，判断 AI 繁荣是否具有持续性，必须追踪真实现金流和最终需求，而不能只观察产业内部增长的订单。

财富集中，会让人怎样理解经济？

这使我重新想起马克思的《资本论》。

在讨论资本积累时，马克思不仅关心社会能够生产多少财富，也关注生产资料由谁拥有，以及资本积累如何改变劳动者与资本所有者之间的经济关系。

在 AI 时代，先进模型、芯片、数据中心和平台网络都可能成为重要的生产资料。

企业拥有这些资产，便有机会通过计算服务、软件授权和其他商业活动获得收益。

而普通劳动者更多依靠工资、经营收入和有限的储蓄维持生活。

2025年，国际货币基金组织发表《AI Adoption and Inequality》，利用家庭微观数据及经济模型分析 AI 对收入分配的影响。

研究指出，AI 可能替代部分高收入工作，改变工资差距；但资本回报增长可能使拥有较多资产的家庭获得更大利益，从而扩大财富不平等。

这是基于模型的研究结果，并非已经测量到的全球财富变化。但它提出了一个具体问题：生产率提高产生的收益，是否能够持续进入劳动者的实际收入？

2026年10月，国际劳工组织在《Making productivity growth work for people》中指出，劳动生产率增长与劳动者收入增长之间仍然存在差距，尤其在低收入国家更加明显。

技术进步本身不能自动决定收益如何分配。

这使财富集中不再只是抽象的公平问题，而是涉及普通人的经济生活。

当部分劳动者的收入增长放缓，而资产收益继续增加时，他们对现有经济制度产生不满，并不难理解。

这种不满可以来自真实的生活经历。

但要进一步判断财富差距究竟由什么造成，还需要研究创新收益、资本投入、市场竞争、继承、垄断与其他制度因素。

2026年3月，《American Economic Review》发表《Zero-Sum Thinking and the Roots of US Political Differences》。

研究调查20,400名美国居民，发现零和思维与支持政府再分配等政策存在显著关联，并与个人及其家庭的社会流动经历有关。

所谓零和思维，是倾向于认为一方获得收益，必然需要其他人承担相应损失。

这项研究不能证明支持重新分配的人缺乏理性，也不能据此推断他们会采取激进的政治行动。

但它揭示了一个值得研究的现实：人们对于财富如何产生的理解，会影响他们认为怎样分配财富才合理。

一个人如果长期努力却无法改善收入，可能认为现有制度限制了自己的机会。他可以基于这种经历认真思考改革，也可以要求改变企业和社会的分配制度。

真正的问题在于，如果经济不满逐渐发展为认为某一群体的全部财富都来自对其他人的剥夺，复杂的经济关系便可能被压缩成一种简单的身份判断。

历史上，确实发生过这种转变。

瑞金土地革命：当经济解释进入现实行动

1929至1934年的赣南闽西中央苏区，特别是1933年瑞金的查田运动，提供了一个值得研究的历史案例。

这里的土地改革发生在1949年以前，不能直接使用中华人民共和国成立后的土地改革叙述代替。

1931年12月1日制定的《中华苏维埃共和国土地法令》，规定对特定土地实行无偿没收，并重新分配土地及相关生产资料。

土地分配涉及真实的经济利益。对于无地或少地农民，获得土地意味着拥有改善家庭生活的重要生产资源。

但随着阶级成分的政治化，土地所有状况开始进一步影响个人在社会组织中的地位。

1933年的《关于查田运动的初步总结》记载，瑞金壬田区在55天内查出地主、富农300户，并：

枪决了群众所谓“大老虎”的十二个反革命分子

同一份报告还记载，当地组织了十次群众审判大会及三次巡回法庭活动。

这些数字来自当时运动组织者的报告，属于需要与其他档案继续交叉核对的一手记录。

不过，报告已经明确显示，土地重新分配与阶级身份审查、群众审判和人身惩罚发生了结合。

孟庆延在《苏区革命与地方社会：查田运动之发轫新探》中，进一步利用瑞金地方档案、宗族资料及当事人回忆，研究查田运动与原有地方社会矛盾之间的联系。

他的研究指出，查田并非发生在一个没有内部利益冲突的农村社会。原有宗族关系、干部更替、地方利益及政治动员相互交织，使阶级分类能够参与重新组织地方权力。

为了进一步核查这段历史，还需要阅读台湾保存的国民政府和国军资料。

台湾国家发展委员会档案管理局公开的《剿匪时期之经济措施》，记载了1933至1934年南昌行营组织割禾队，进入苏区封锁区域收割稻谷的政策。

档案中的原文包括：

掩護割禾隊搶割稻禾

这说明当时的经济困难还受到国军主动实施的粮食征取及军事封锁影响。

因此，不能把瑞金所有农业困难都归因于苏区内部的土地改革，也不能因为存在外部军事封锁，就否认阶级划分与政治清查造成的人身伤害。

不同材料需要分别承担它们能够证明的事实。

尤其值得注意的是，当经济身份被用于决定一个人的财产权、政治地位乃至人身安全时，财富分配已经不再只是调整土地资源的经济政策。

这段历史提醒我，经济不满可以包含真实的利益诉求，但一种关于财富来源的解释，一旦成为对整个身份群体作出惩罚的依据，便会产生超出最初分配问题的社会后果。

如果做蛋糕的人消失了

我想用一个简单的比喻继续讨论财富分配。

社会已经拥有一块蛋糕，有人认为分配不公平，希望重新切分。

但下一块蛋糕仍然需要有人制作。

它需要原料、设备、技术、劳动、组织和投资。

在农业社会，土地所有者不一定是实际耕作者。佃农、雇农、自耕农及经营者都可能参与生产。

在现代企业，股东、工程师、管理人员和普通员工也承担不同的经济职能。

所以，改变资产所有权并不意味着生产能力自然消失。

真正需要关注的是，生产资料能否继续得到有效使用，劳动者能否保有稳定的收入，经营者是否愿意继续投资，以及社会能否保留不断创造财富所需要的知识与组织能力。

这一问题在历史上有具体的实证案例。

2017年，Shuo Chen 与 Xiaohuan Lan 在《American Economic Journal: Applied Economics》发表《There Will Be Killing: Collectivization and Death of Draft Animals》。

研究比较约1600个县在1955至1957年中国农业集体化期间的不同实施时间，估计产权转移预期造成约12%至15%的耕畜损失，并通过牲畜投入减少及生产率下降，使粮食产出降低约7%。

这一事件发生在1950年代中期，不是1933年的瑞金查田运动，不能将其产量损失数字套用到瑞金。

但它证明了一个可以观察的经济机制：人们对未来财产权的预期，会改变他们如何处理现有生产资料。

对于个体农民而言，如果认为自己的耕牛即将失去控制权，提前宰杀可能是保护眼前收益的选择；对整个农业社会而言，耕牛损失意味着未来能够投入耕作的生产资源减少。

个人作出的选择可以具有经济逻辑，大量类似行为汇总之后，却可能降低整体产出。

这比简单地说人们为了分蛋糕忘记做蛋糕，更能解释制度为什么会影响生产。

对 AI 时代而言，问题同样不止于谁拥有现有财富。

如果 AI 让部分劳动者的收入下降，而新增资本收益没有充分转化为新的工作机会、实际工资或更低的生活成本，那么普通人分享技术进步成果的渠道就会受到影响。

如果企业只关注减少人工开支，却忽略劳动者同样是现实市场的重要消费者，技术带来的效率增长就可能与家庭购买力出现脱节。

反过来，维持长期生产也需要保护知识、技能、投资与持续创新的条件。

我们需要研究的是，怎样让更多人获得先进生产工具的使用机会，并通过劳动、经营和其他正当经济活动分享收益，而不只是围绕已经形成的财富存量展开争夺。

危险的不是提出问题，而是某种解释不再允许被检验

回到 AI 泡沫。

现在已经能够观察到几种真实发生的现象。

先进模型完成了以前难以自动化的软件任务，但并没有因此直接证明全部 AI 投资都能获得预期回报。

AI 企业之间形成了大量投资和采购关系，部分算力供应商还通过承购协议保障未来销售，但这些合同不能代替独立终端需求的测量。

美国劳动市场的研究也已经发现，部分 AI 暴露程度较高的年轻劳动者面临就业入口收窄和初期收入下降的现象。

与此同时，真实付费的消费者仍然会根据价格和需求选择 AI 服务，而不会因为模型变得更强，就无限增加自己的订阅预算。

这些事实共同指向一个值得继续调查的经济问题：AI 产业生产能力和资本投资正在迅速扩张，技术收益能否充分进入普通人的收入和消费，仍然需要通过实际数据检验。

危险的认知，恰恰可能从忽略这种联系开始。

上一篇文章中的 Qwen 测试，已经展示过模型可以通过遗漏重要材料改变用户最终得到的信息结构，而不必直接编造事实。

今天的 AI 经济叙事也存在类似的问题。

如果行业报告大量强调模型参数、计算需求、资本开支、合同金额和交易次数，却很少衡量劳动者收入、居民购买能力与真实生产率，那么这些数字即使全部正确，呈现出来的经济图景仍然可能不完整。

这并不需要有人故意制造虚假信息。

只要某些指标长期获得更多关注，另一些指标不断被忽略，公众对于经济发展的理解就可能逐渐围绕少数可见数字形成。

当一种解释被不断传播，它便可能成为人们理解新事件的默认框架。

如果模型完成了新的复杂任务，人们可能更加相信 AI 产业必然繁荣；如果一家科技企业公布更大的投资计划，市场可能将其理解为未来需求继续扩张的信号。

但这些判断最终仍然需要回到真实现金流和实际经济收益。

同样，当人们看到贫富差距扩大、就业机会减少，也需要继续研究问题由什么机制形成，而不能只根据经济身份认定某个群体应承担全部责任。

瑞金土地革命的历史说明，一种经济解释一旦进入阶级分类、群众审判与财产处理制度，就能够产生非常具体的现实后果。

人不是单纯由情绪驱动的对象。

一个人可能认真衡量自己的利益和风险，也可能基于所掌握的信息，形成一套逻辑自洽的解释。

问题在于，如果最初的信息存在缺漏，或者对因果关系的理解已经偏离事实，继续推理并不一定能够自动纠正错误。

这使我重新理解上一篇文章留下的问题。

真正危险的认知，不一定表现为明显的谎言，而可能是一套看起来完整、能够解释许多现象，却不断排除不符合自身判断的证据的世界观。

当这种认知只是影响一次模型回答，错误还可以通过资料核查得到纠正。

但当它进一步影响企业投资、就业安排、公共政策与个人权利时，错误就可能产生持续的现实成本。

AI 泡沫最终需要回答什么？

我越来越觉得，预测 AI 泡沫什么时候破裂，不应该成为这场讨论唯一的目标。

即使资本市场发生大规模调整，已经开发出来的软件、模型和工程技术也不会因此自动消失。

技术也可能持续进步，而普通人的生活条件没有同步改善。

因此，真正需要观察的，是生产率增长如何转化为收入，企业投资能否得到持续的客户需求支持，以及社会成员有没有能力参与和享受新增的经济成果。

如果 AI 让商品和服务变得更便宜，我们应该能够从价格和购买能力中看到变化。

如果 AI 让劳动者节省了时间，我们应该继续观察这种效率是否带来更高收入、更合理的工作安排，或者新的发展机会。

如果 AI 企业持续扩大投资，我们应该追踪这些支出创造了多少能够长期存在的产出，而不是只看资金如何在产业链内部循环。

这些问题最终都与人的生活有关。

因为人不只是企业成本表上的劳动费用，也不是技术产业需要争取的一个订阅账户。

人需要收入来维持生活，需要机会来积累能力，也希望能够参与创造，而不只是被动接受技术生产出来的商品。

从瑞金的历史到今天的 AI 产业，生产工具、财产所有权和资源分配方式都发生了巨大变化，但有一个经济问题始终值得讨论：

当社会创造财富的能力不断增长，人们是否仍然拥有参与生产、获得收入和分享成果的机会？

上一篇文章讨论模型如何理解世界。

这一次，我更希望讨论我们如何理解所谓的经济繁荣。

如果最终的评价只剩下模型参数、算力规模、机器交易次数和企业估值，却忽略了普通人的劳动收入、消费能力与生活质量，那么这种繁荣叙事便没有完整回答经济发展究竟为了什么。

而当一种解释开始决定哪些证据值得关注，并不断排除无法支持它的事实时，我们更应该重新审视自己的判断。

我们究竟是在依据证据理解世界，还是在依据已经形成的世界观决定什么能够成为证据？

从 Opus 5.5 的视频出发：动画工作流与连续试播的可行性

toewpq — Tue, 13 Oct 2026 18:57:12 GMT

看到 Claude Opus 5.5 制作的《I'm Upping My P(doom)》后，我开始测试一件事：让 coding agent 组织画面、动作、配音和剪辑，能否做出一支完整视频。

这轮已经做成两支片：《雨夜送药》150 秒，采用素材复用和二维角色动作；《垃圾車來了！》160 秒，把人物、物件和环境一起生成。两支片展示了不同的制作取舍，也让我把工作流整理成了三个方向。

从 Opus 5.5 的作品开始

!embedyoutube

作者公开了 PDoomVideo 源代码。项目说明中，Opus 5.5 负责分镜和动画代码，画面使用 p5.js、p5.brush、无头 Chrome 与 FFmpeg 渲染，音乐采用已有歌曲。

我想接着探索的，是 Agent 怎样组织制作过程。我的画面路线换成了 ImageGen：生成素材，审看动作与空间，再把选用画面、声音和字幕编成视频。

第一条：动图与动作库

动作库负责保存人物 ID、姿态、动作时间和预览。下面是八个生成姿态组成的挥剑动图，动作结束后回到起点，循环有明确的重置接点。

八个生成姿态组成的挥剑动图

!embedishare

这一层的价值是复用。后面要让同一个角色站立、转头或挥手，可以直接引用已经审看的动作，不必每次从一张人物设定重新开始。原创形象的参考图、表情、服装和动作索引也已预留，后续会从这里接入。

第二条：有限动画与低成本静态视频流

《雨夜送药》：素材复用与二维角色动作。

!embedishare

《雨夜送药》已经通过成片验收。它从下班收到消息、雨夜走到候车处，一直讲到回家送药。办公室、街口、候车、车内和回家这些镜头，用完整插画、停留和轻微运镜推进；74–84 秒的绕行段，则在同一背景上使用二维骨骼驱动角色纹理。

回看整片，这条路线的特点很清楚：场景稳定，少量画面就能承载完整故事。角色移动可以由程序持续计算，旁白和字幕把镜头连接起来。候车和办公室的画面停留较长，观感偏插画叙事；绕行段有明显的二维纸片感。它已经完成了有限动画的目标，接下来要加强的是人物与场景的互动。

素材怎么复用

我把有限动画（素材复用）分成两种镜头。第一种直接复用完整插画，适合听消息、看远处、车内休息和收尾。第二种保留背景，复用透明人物姿态或角色纹理，用于站立、短步和简单动作。

同一街区可以换成店外、人行道或候车空地。复用以镜头为单位，不需要把整支片锁在同一张背景上。人物要拿东西、坐下、跨台阶或被前景遮住时，先判断这个接触能否靠现有素材表达；复杂部分转到第三条整场景流程。

具体制作顺序是：

定义镜头的起点、终点、动作和道具状态，先标出需要接触环境的部分。
审看场景母图，确认地面、开放路线、障碍端点和机位。
选择同一人物、服装和道具状态的素材，保留鞋底和完整轮廓。
匹配人物比例、光线、落脚和影子，安排保持、移动、换脚与收势。
按实际旁白长度安排镜头和字幕，再检查完整音画与前后状态。

提示词也从构图阶段限制互动。例如：

角色在平坦开放的人行空地站立或短步，身体和鞋底完整可见。墙、车辆、桌椅与栏杆都在路线之外。角色不走到这些物件后方，不扶栏、不倚靠、不拿取背景物件，不跨台阶。已有提袋保持同一只手，起点与终点位于同一高度的地面。

成本节省来自复用背景、人物素材和剪辑流程，减少重复生成整张场景。切图、绑定和审看仍是制作工作，所以需要按镜头选择方案；遇到复杂互动，一直修合成反而会增加返工。

把滑脚单独拿出来测

支撑脚对照：保留与取消落脚约束。

!embedishare

同一纹理和路线做了两个版本：一个固定支撑脚，另一个让鞋底在支撑期间随人物前移。程序读取编码后的画面，用鞋底纹理匹配检查 0.25 秒内的位移。

条件	可见测量窗口	中位位移	95 分位
固定落脚	27	0px	3px
取消约束	18	20px	约 21px

这个对照把滑脚问题显示出来，也给后续动作库提供了一项可以重用的检查。人物有没有绕过护栏、有没有碰到物件，另看整段画面的空间关系。

第三条：参与环境互动的视频流

《垃圾車來了！》：人物、道具与背景整场景生成。

!embedishare

《垃圾車來了！》专门测试接触与状态变化。刚搬来的以安听见垃圾车音乐，提起分好的垃圾和回收物下楼；邻居的袋子勾到扶手，瓶罐掉落，她停下帮忙。两人倒完垃圾，一起走回公寓，陌生巷子也熟悉了一点。

这次每张图都把人物、物件、背景、光线和接触影子一起生成。下一步上传上一完整影格，再提供人物与场景参考，说明接下来的小动作。同一巷弄可以延伸到门口、人行道和收运点，背景不要求像素固定。

回看片子，最有用的改善在拿取和交付段：先放下自己的袋子，再蹲下拿瓶罐、放回邻居提袋；到了收运处，交付垃圾与回收后，手上的状态跟着改变。动作与物件关系直接画在场景里，比在固定底板上移动人物更适合这些事件。

全片选用了 76 张整场景姿态，配 11 段台湾中文旁白和 43 条字幕。步行等部分仍能看到姿态停留和切接；但相比上一条路线，故事中的具体接触已经更完整。原生成图是 836×470 和 1672×941，成片导出 1080p；迁移前网页用 540p 副本，现在由 ishare 提供自适应流媒体播放。

几次错误怎样改变了制作方法

绕行变成翻越护栏

早期反例：要求绕行，画面却出现扶栏与翻越姿态。

!embedishare

早期实验写的是从障碍旁绕过，生成的末段却伸手扶栏，腿也抬到护栏附近，让动作读成翻越。这是具体的路线和动作错误。后来低成本片改用明确的开放路线与二维控制；发展整场景路线时，也把人物与栏杆的复杂遮挡列为构图限制。

处理办法是先把端点和可走的空地放进镜头，手保持在身体旁，再看整段是否真的沿这条路线移动。单看脚底固定或人物朝前，容易漏掉人物与护栏的关系。

楼梯修正版仍有台阶异常

G09R 楼梯修正版，台阶、平台与扶手坡度不连贯

!embedishare

垃圾车故事的 G09、G10、G11 出现楼梯空间混乱。第一次重做后，G09R 看起来更接近公寓，但我在成片里又指出台阶异常。最后整组撤出，换门锁近景，再接鞋部和二楼平台，把下楼这件事讲清楚。

最后选用的门锁近景

!embedishare

这次处理直接改变了镜头设计。用近景避开复杂梯段，平坦平台承担拾瓶动作，叙事继续成立。后续遇到同类空间问题，也应先考虑机位和动作拆分。

道具数量和左右手会跳变

地上还有罐子，袋口却已出现另一只罐子的弃用画面

!embedishare

撿物段曾出现地上罐子还在、袋口却多出一只；门锁新组也有钥匙和袋把突然换手的格子。前者按库存重选，后者弃用第三格，保留第 1、2、4 格。自己的垃圾袋需要先放到墙边，才进入蹲下动作，不能提前消失。

这些错误让提示词变得具体：先握住再拿起，接住后才放手；写明每只手和每件物品的位置。失败图单独存放，正式时间线只引用审看后的影格。

声音与叙事一起调整

初版持续低频和重复高音铃声让画面显得诡异。后来移除了低鸣，把垃圾车音乐缩成短提示，加入稀疏钢琴，并在旁白时压低背景音。

配音改成第三人称画外旁白，字幕跟着旁白走。故事照样能展开，也避免画中人物的嘴型牵制台词。Edge 语音原路径遇到 403 后，换用我提供的 wangwangit/tts，通过本地 Microsoft REST 路径完成台湾中文旁白。

把雨夜花店做成连续视频

后续试播按这张六格图考虑情节：路过花店、发现倒盆、蹲下接触、扶正花盆、与店员致意，最后继续前行。

!embedishare

这张图负责故事与构图。它不是视频抽帧，也不能证明扶正和致意已经发生。制作时仍把动作拆成可观察的状态，先走近、停下，再蹲下触盆，确认接触后才进入扶正。

我在 gemini.google.com 生成了第一条连续片段，记录中的模型名称是“Gemini 4”；底层视频模型版本没有独立核实，不把它写成已确认的 Veo 对照实验。

!embedishare

片段为 10 秒、1280×720、24fps，240 帧都能完整解码。它保持了同一家花店、同一人物和一只倒地目标盆，呈现走近、停步、下蹲与伸手。这至少说明，从场景参考组织一段连续动作的路线有可行性，值得继续做下去。

接触还没有完成。女主蹲下的位置离盆沿太远，手伸向散落叶片；9 秒证据帧和最后一帧都看得到手与陶器之间的间隔。

!embedishare

因此这条保留为可行性试播，审片结论仍是 NEEDS_REVIEW。没有可观察的触盆完成点，就不剪成“已经扶起”的片段，也不为了填满输出长度安排空动作。下一轮只改停步位置：走到外露盆沿旁，略弯肘就能触及后再蹲下。接触通过后，才继续扶正、与店员致意和离开。

Codex 在这里负责核对母图哈希、解码抽帧、检查物件数量、落脚与接触状态。媒体技术检查通过和剧情动作通过分别记录。实际网页附件与提交提示词没有留证，参考绑定保持未验证；不能仅凭画面相似就宣布参考图已正确绑定，也不能把这个缺口归咎于模型。

这轮研究留下什么

现在三条流程各有明确任务：动作库保存可引用的人物动作；低成本流程复用素材，完成插画式叙事和简单移动；整场景流程负责人与道具、环境的接触事件。

两支成片给出了实际制作结果，花店试播补上了连续生成视频的初步可行性与接触缺口。下一步加入原创形象时，我会沿用角色参考、表情、服装和动作索引，让同一个形象进入三种流程，再继续看动作与环境如何配合。

源码、提示词、审查结果和媒体清单整理在仓库的 video/：动作库、有限动画、整场景叙事和花店试播各一个目录。图片与视频迁到 ishare，仓库按链接引用；重建时按需下载原图并校验哈希，视频流媒体版不冒充原始下载文件。实际使用的 MIT 语音依赖已纳入 third_party/tts/，保留上游版本和许可证。

查看开源工作流

《垃圾車來了！》完整 1080p 成片

《雨夜送药》完整 720p 成片

当语言改变答案：从语料污染、GEO 到大语言模型的判断边界

toewpq — Sun, 11 Oct 2026 16:50:00 GMT

最近重新思考了一个早些年接触过的现象：同一个问题，分别使用简体中文、繁体中文和英文向大语言模型提问，可能得到倾向不同的回答。

最典型的例子之一，是台湾与中国大陆的关系。当语言发生变化时，模型可能改变叙述方式，甚至在被要求选择立场时给出不同答案。

这看起来只是一个有关政治偏向的问题。但继续思考下去，我认为更值得关注的并不是模型最终支持哪一种立场，而是它如何形成答案。

如果模型会因为语言不同而改变判断，那么这种变化究竟来自训练语料中的信息分布、后训练形成的回答边界，还是模型对提问环境的适应？

而当互联网内容可以通过语料投毒、搜索优化与生成式引擎优化（GEO）被主动塑造时，我们还需要考虑另一个问题：

模型所接触到的信息，本身是否已经受到筛选、重复或操纵？

这意味着模型的可靠性，可能不仅取决于它掌握了多少知识，还取决于这些知识如何形成、哪些信息能够进入答案，以及它究竟使用什么标准评价证据。

不同语言下的政治立场差异

2024 年，Yu-Ting Lin 与 Yao-Chung Fan 在 ROCLING 发表了《Unveiling Language-Driven Political Stances in Large Language Models on China and Cross-Strait Relations》。

研究者选择八款来自中国大陆、台湾和美国的模型，使用简体中文、繁体中文和英文提出二十道有关中国政治及两岸关系的问题，比较它们在不同语言下表现出的政治立场。

实验结果呈现出明显差异。

例如，GLM-4-9B 在简体中文下，与中华人民共和国政府官方立场的一致率为 60%；繁体中文下降至 40%，英文则为 15%。

Qwen2-7B-Instruct 也表现出类似趋势，三种语言下的一致率分别为 75%、55% 和 45%。

但并非所有模型都具有相同倾向。

同样来自中国大陆的 Yi-1.5-9B，在简体中文、繁体中文和英文下的一致率分别为 35%、30% 和 30%，没有表现出与 GLM-4 相同幅度的变化。

这意味着，至少在研究所采用的测试条件下，不能仅凭模型开发地区，就断定它一定具有某种固定的政治立场。

同时，研究中的「一致率」也需要正确理解。

研究者并没有要求模型必须支持中国大陆或者台湾的某一立场，而是在系统提示中要求模型根据自己的倾向评价政治问题，尽量选择明确立场，而不是保持中立。

例如，面对「台湾是中国的一部分」这一陈述，模型需要从赞成、反对和没有意见三个选项中选择，并说明理由。

随后，研究者根据回答是否接近中华人民共和国政府的官方立场进行分类。

因此，这里的「一致率」衡量的是政治立场的对应关系，而不是回答的事实准确率。

其统计方式同样值得注意：中立和拒答被排除在一致率的分母之外。

以 InternLM2.5 的英文测试为例，二十道题中有十六道被归为中立，三道符合大陆官方立场，一道与之相反。

如果只计算明确表态的四道题，一致率为 75%；但如果观察全部二十道题，符合大陆官方立场的回答实际上只占 15%。

这两个比例并不矛盾，却回答了不同的问题。

前者反映模型明确表态时的倾向，后者反映用户在全部测试中实际获得某种立场回答的频率。

如果忽略中立回答的数量，就可能高估某种立场在整体回答中的出现程度。

此外，论文采用的是政治立场问卷，而不是开放式事实问答。

「你是否赞成台湾是中国的一部分」与「请区分台湾目前的实际治理、不同政治主体的主权主张及国际承认情况」，要求模型完成的是不同任务。

前者要求对政治陈述表达态度；后者要求组织和解释事实，不一定需要将复杂问题压缩成赞成或反对。

但是，这项区别本身还不能证明模型在开放式事实问答中一定更加可靠。

因为研究没有提供同一模型在这两种任务下的完整对照实验，我们只能确认它所观察到的立场差异，而不能直接推断普通事实问答会产生什么结果。

因此，这项研究最有价值的发现是：

在特定政治立场问卷中，部分模型的回答倾向确实会随语言变化，而这种变化并不能简单归结为开发地区。

至于语言为什么会产生这种影响，仍然需要研究其背后的信息环境和训练过程。

语言背后的信息环境

不同语言的信息环境并不完全相同。

历史教材、新闻媒体、政府文件、学术论文以及网络社区，都可能形成各自相对稳定的叙述方式。

尤其在政治与历史争议中，信息管制、媒体制度、社会认同和传播渠道，会影响某些观点出现的频率，以及公众能够接触到哪些不同解释。

但是，我不认为应该简单地将简体中文等同于封闭的信息环境，把繁体中文或者英文等同于开放的信息环境。

语言不是信息自由度的充分指标。

即使在信息来源相对多样的环境中，商业利益、政治宣传、媒体编辑与算法推荐，也可能影响某些内容的可见度。

而且，同一种语言内部也可以存在截然不同的信息来源。

因此，真正值得比较的，并不是哪一种语言天然更加客观，而是不同语料环境在事实覆盖、观点分布与证据质量上存在什么差异。

这种差异有可能被模型学习，但训练语料并不是唯一的影响因素。

模型通常还需要经过指令微调、偏好优化及其他后训练程序。开发者可以通过这些阶段改变模型的回答习惯、内容限制和拒答边界。

在某些地区，这种设计还可能受到明确的监管要求影响。

例如，中国大陆的《生成式人工智能服务管理暂行办法》对境内面向公众提供的生成式人工智能服务提出了政治内容规范，包括不得生成某些被认定损害国家利益、国家形象或破坏国家统一的内容。

2026 年发表于《PNAS Nexus》的《Political censorship in large language models originating from China》，进一步比较了中国大陆来源与非中国大陆来源模型对一百四十五个政治问题的回答。

研究观察到，样本中的中国大陆来源模型在敏感政治问题上具有更高的拒答率、更短的回答，以及更多不准确回答。这些差异在政治敏感程度较低的问题上有所减弱。

这提供了一个具体证据：不同模型的政治内容表现，不能仅通过语言能力或一般技术差异解释。

不过，研究者同样指出，该研究属于观察性研究，不能单独证明监管要求与特定模型输出之间的完整因果关系。

从结果来看，我们可以识别某些模型在特定政治议题上存在系统性差异。

至于这些差异有多少来自预训练语料、有多少来自后训练和制度约束，则不能只凭一次黑箱输出直接确定。

模型继承信息环境中的偏差，与开发者主动设定回答边界，是两种需要区分的机制。

它们可能同时存在，最终却表现为相似的回答差异。

语料污染：信息出现得更多，不等于证据更加充分

如果进一步讨论训练语料，就会发现互联网本身已经不是一个完全自然形成的信息集合。

搜索引擎优化、自动化内容生产、商业宣传和有组织的信息传播，都可能改变某些叙事在公开网络中的出现频率。

一种观点被大量重复，并不意味着它具有同等数量的独立证据。

在这里，需要区分几类不同的问题。

第一类是普通的数据质量问题，例如错误信息、大量重复文本、过时资料和缺乏事实依据的自动生成内容进入训练数据。

第二类是有目的的数据投毒，即攻击者主动控制部分训练材料，试图让模型学习某种错误行为或者在特定条件下产生预期输出。

第三类则是基准数据污染，即模型训练时已经接触过用于评价自身能力的测试数据，使评测结果失去部分独立性。

这些情况并不相同，不能因为互联网上存在错误信息，就认定所有模型都受到了有目的的数据投毒。

但是，数据投毒本身已经有可以验证的实验依据。

2025 年，Anthropic 与英国 AI Security Institute、Alan Turing Institute 发布了《A small number of samples can poison LLMs of any size》。

研究发现，在其实验设置中，仅注入约 250 份恶意文档，就可以让所测试的不同规模模型形成特定后门行为。

需要明确的是，这项实验关注的是触发后生成乱码的简单后门，并没有证明少量文档足以让模型接受某种政治立场，更不能据此直接推断现实模型的政治回答已经受到此类攻击。

但它至少反驳了一种过于简单的假设：只要训练语料规模足够庞大，少量恶意数据就不可能产生影响。

数据规模和抗污染能力并不能直接画上等号。

另一个值得关注的问题，是语料中不同来源之间的独立性。

假设一份未经充分核实的商业报告被多个网站转载，并通过自动化工具改写成不同的行业分析、新闻摘要和问答文章。

最终，模型可能在语料中多次接触同一个结论。

但这些文本未必代表多份独立研究，也可能只是同一原始材料经过多次传播后的不同版本。

如果模型不能有效区分证据来源，它学到的可能是某种说法具有较高的文本出现频率，而不是该说法已经得到广泛独立验证。

这里的风险并不一定表现为模型完全不知道某些事实。

它也可能掌握大量信息，却无法正确识别不同材料之间的来源关系。

GEO：当内容开始为了进入 AI 答案而优化

如果说语料污染主要涉及模型训练阶段，那么 GEO 则把信息选择问题进一步延伸到了生成式搜索。

GEO，即 Generative Engine Optimization，生成式引擎优化。

传统 SEO 主要关注网页在搜索结果中的排名，而 GEO 更关注内容能否被生成式搜索系统检索、采用、引用，并进入最终生成的回答。

2024 年，Pranjal Aggarwal 等人在 KDD 发表了《GEO: Generative Engine Optimization》。

研究者通过 GEO-bench 等实验发现，对来源内容进行特定优化，可以提高其在生成式引擎答案中的可见度，部分测试条件下最高提升约 40%。

这里的提升指的是来源可见度，不是事实准确率，也不能理解为 GEO 可以让任何错误信息稳定控制模型答案。

GEO 本身也并不必然存在问题。

提供清晰的资料结构、准确的数据、明确的来源和便于机器读取的内容，都可能帮助生成式引擎更好地利用信息。

但是，GEO 带来了一个新的利益关系：内容生产者不再只是争取用户点击网页，也开始争取自己的内容进入 AI 最终回答。

2026 年 ICML 的《Position: Generative Engine Optimization Creates Underexamined Risks》进一步讨论了 GEO 可能带来的影响力集中，以及商业影响未经充分披露便进入生成式答案的风险。

这是一篇立场论文，提出的是需要重视和治理的风险，并不意味着所有生成式搜索平台都已经发生了同样程度的问题。

但有一点可以通过 GEO 的原始实验得到直接支持：

信息进入生成式答案的机会，不完全由其事实质量决定，内容的组织和呈现方式也能够产生影响。

这意味着，某个来源更容易被 AI 引用，不必然说明它比其他来源更加可信。

对于普通用户而言，这个问题可能比传统搜索更加隐蔽。

在传统搜索中，用户通常会看到多个网页标题，并自行决定访问哪些来源。

生成式搜索则将检索与资料综合进一步整合到同一个回答中。

用户看到的可能是一段已经组织完成的解释，以及少量附带引用。

这时，哪些资料被选中、哪些没有被选中，以及被选中的资料如何进入最终叙述，就成为影响认知的重要环节。

不过，GEO 仍然需要与恶意检索污染区分开。

普通 GEO 可以是合法的信息可见度优化；检索污染则可能包含明确的攻击目标，例如故意投放错误内容，使系统生成不可靠答案。

2025 年 EMNLP Findings 的《The RAG Paradox》就研究了一种黑箱攻击方式。

研究者利用 RAG 系统暴露的来源信息，识别哪些资料容易被检索，再制作看起来自然可信的污染文档，在实验中成功降低了系统表现。

这项研究支持的是：即使攻击者无法直接修改模型参数，也可能通过外部知识来源影响使用检索增强生成技术的系统。

它不证明普通 GEO 就等于攻击，也不能证明所有生成式搜索系统都具有同样的脆弱性。

但是，这些研究共同说明，模型最终采用什么信息，除了受模型本身影响，也可能受到外部内容可见度与检索机制的影响。

从信息可见度到证据可信度

这里存在一个容易被忽略的区别。

某种内容被大量传播，不意味着它拥有同等数量的独立证据；某个来源被 AI 引用，也不代表它已经通过事实核查。

训练语料和实时检索的影响方式并不相同。

对于已经训练完成、没有外部检索能力的模型，新发布的 GEO 内容不会直接改变它的参数。

但对于使用搜索、RAG 或外部知识库的系统，检索结果可以在当前回答中直接影响模型使用的材料。

如果这些公开内容后来又进入新一轮训练数据收集，那么影响还可能进一步延伸到未来模型。

后一种情况是一条技术上可能发生的传播路径，而不是可以不经验证便认定已经发生的因果链。

因此，有必要把信息风险分成不同阶段观察。

在训练阶段，需要检查数据来源、内容质量与重复分布。

在检索阶段，需要检查为什么某些来源被采用、不同来源是否独立，以及是否存在针对检索系统的内容操纵。

在生成阶段，则需要检查模型有没有忠实呈现证据，是否遗漏关键信息，以及有没有补写未经证明的解释。

这三个阶段可能相互影响，但不能混为一个笼统的「模型有偏见」。

模型没有编造事实，也可能改变材料

除了训练和检索环境，模型最终如何处理已经提供的材料，同样是判断可靠性的重要部分。

在上一篇《模型跨过国界之后：从 Qwen、Gemma 与 Ministral 的本地选择谈开放、闭源与答案边界》中，我曾比较三款本地模型对相同材料的处理表现。

其中，Qwen 的表现尤其值得注意。

面对普通生活叙事，它相对克制。对于文本没有交代的人物心理动机，模型能够承认无法判断，没有继续编造完整的心理故事。

但在处理关于 1989 年六四事件的英文历史材料时，情况出现了明显变化。

原始材料包含时间与地点、胡耀邦逝世、学生诉求、工人与居民参与、军队使用武力、死亡人数存在争议，以及相关审查等信息。

本地定制版 Qwen 最终只输出约 174 个字符，没有完整保留这些关键内容。

它没有展开学生诉求，没有提到工人与居民的参与，没有明确复述军队使用武力，还将原文已经说明的死亡人数争议笼统处理为无法验证。

与此同时，它在回答中以政治敏感性和缺少官方来源作为质疑材料的理由，并建议参考官方历史文件。

这里的问题并不是回答太短。

真正的问题在于，用户要求的是对给定材料进行分析，而最终回答却遗漏了材料中多个足以影响读者理解事件的重要信息点。

准确处理材料，与独立证明材料涉及的整个历史事件，是两种不同的任务。

如果模型无法独立核实某个数字，它可以明确说明原文如何记载，同时指出数字仍有待外部验证。

如果原文提到死亡人数存在争议，那么保留争议本身，并不意味着模型必须认可某一个具体数字。

因此，不能简单地用「模型更加谨慎」解释这次输出。

为了观察本地规则与原始版本之间的差异，测试还临时调用了官方 `qwen3-vl:4b-thinking` 版本。

该版本直接宣告不能讨论政治、宗教、色情及暴力等内容。

相比之下，本地定制规则使模型能够给出有限摘要，却没有稳定恢复原始材料的关键信息。

这些结果可以证明特定版本和配置下存在可观察的信息遗漏与拒答行为，但不足以直接还原模型的内部决策过程。

例如，我们不能仅凭它在回答中提及「官方来源」，就断定模型内部确实先执行了一套来源审核程序，然后才决定删除内容。

另一种有现实背景的解释是，部分模型在后训练阶段可能受到特定政治内容要求或官方叙事边界的影响，从而在敏感问题上表现出选择性回避。

相关监管规范和政治审查研究使这种机制值得调查，但单次黑箱测试仍不足以证明具体权重究竟采用了哪一种训练措施。

同样，当前测试没有证据显示这些遗漏由 GEO 或恶意语料投毒直接造成，因此也不应强行把它们联系起来。

不过，机制尚未完全确定，不影响对输出质量作出判断。

在这组具体测试中，模型没有忠实保留用户已经提供的重要历史信息，并改变了读者最终能够接触到的材料结构。

这种错误甚至不需要通过明显的虚构事实来实现。

只要关键信息被系统性省略，最终答案就可能形成不同于原始材料的整体印象。

这也是为什么单纯评价模型的政治立场，可能不足以反映它实际提供的信息质量。

一个模型可以在政治立场问卷中选择中立，却同时遗漏争议中最重要的事实。

因此，除了立场是否一致，还需要检查答案的信息保全情况。

不回避，并不意味着更加可靠

不过，Qwen 的信息遗漏不意味着只要模型愿意完整回答，就自然具有更好的判断能力。

上一篇测试中的 Gemma 表现出了另一种问题。

它没有明显回避政治历史材料，保留了更多关键信息，却容易增加原文未提供的评价和解释。

面对普通生活材料时，这种倾向更加明显。

模型会把打扫房间、制作早餐和短暂休息，解释成心理疗愈、重新获得掌控感，甚至进一步推导人物具有某种成熟的人格特征。

这些解释不一定在所有情境下都不合理，但原始材料没有提供足够证据支持它们作为确定结论。

Ministral 的错误则更加直接。

它将胡耀邦错误写成胡锦涛，并围绕错误人物继续编造数字、政策及因果关系，最后生成了一段表面完整、实际存在明显事实错误的历史解释。

三款模型表现出不同的失败方式。

Qwen 在特定敏感材料上遗漏重要内容，Gemma 容易加入原文不支持的意义，Ministral 则出现了直接的事实捏造。

这些问题不能全部归结为同一种政治偏向。

但它们都涉及一个共同的评价标准：最终答案有没有受到原始证据的有效约束。

对于实际使用者而言，比起急于判断模型内部究竟形成了什么立场，更直接的办法是检查它有没有遗漏、替换或者擅自扩写材料。

当然，结果评估不能完全解释内部原因。

但即使没有打开模型黑箱，我们仍然能够判断某次输出是否满足任务要求，是否忠实保留了必要事实，以及是否加入了无依据的推论。

何为合理的证据？

这些现象最终指向一个更加基础的问题：模型究竟应该如何判断材料是否合理？

假设模型原先得出某个结论，用户随后提供反面材料，模型改变了原来的判断。

我不认为这种改变本身就能证明模型具有开放的认知能力，也不认为它必然是在迎合用户。

关键在于新材料是否具有足够的证据质量。

例如，一份材料即使真实，也不一定能够支持使用者希望从中得出的结论。

在普通生活叙事中，人物先打扫房间，随后心情有所改善，并不能直接证明清洁行为造成了心理疗愈。

时间上的先后关系，不等于已经证明了因果关系。

同样，某个观点在大量网页上反复出现，也不能直接证明这些网页提供了相互独立的支持证据。

如果多个网页最终都引用同一份原始报告，那么来源数量的增加，并没有同步增加独立证据的数量。

所以，评价材料的合理性，至少需要检查真实性、与命题的关联性、推理是否成立，以及来源之间是否真正独立。

在这个意义上，模型不能仅仅依靠材料的出现频率、来源身份或者语言环境，决定某个观点是否值得相信。

但我也不认为模型应该为了表现开放性，就不断构造反对意见。

当某个结论已有充分且可靠的证据支持时，强行提出一套缺少依据的反方解释，并不会提高客观性。

理解不同观点为什么形成，与认可这些观点具有同等证据基础，是两回事。

客观性不意味着所有问题都必须保持中立，而是尽可能使用一致、可检验的标准评价证据。

这种标准本身也不能完全排除修正的可能。

如果新的可靠材料说明原有判断标准存在缺陷，模型也应该允许证据反过来挑战原有标准。

否则，模型可能陷入一种封闭状态：它使用原有判断决定哪些证据值得接受，又只允许已经符合原有判断的证据改变结论。

这不是充分的开放性。

真正重要的，是模型是否能够依据证据维持或修正判断，而不是简单迎合用户，也不是为了反驳而反驳。

判断模型，最终还是要回到结果

从实际使用的角度，我仍然倾向于先观察结果。

模型有没有完成任务、有没有保留关键信息、有没有明显事实错误，以及结论能否得到证据支持，比单纯讨论它是否具有某种抽象立场更有意义。

如果模型的回答与已有认识发生冲突，可以进一步检查双方使用的材料，判断究竟是模型出现错误，还是自己的认知需要修正。

但已有认识本身不是绝对正确的参照。

因此，在重要问题上，即使模型回答看起来符合预期，也需要保留独立核查的能力。

而在训练数据污染与 GEO 的背景下，这种核查还需要关注证据的来源关系。

不同模型得出相同结论，并不一定意味着它们完成了独立验证。

如果这些模型使用相同的外部检索结果，或者多个被引用的网站都转载同一份原始资料，那么回答一致也可能只是反映了共同的信息来源。

因此，多模型比较不能直接变成多数投票。

更有意义的是检查模型是否使用了可核实的原始证据，是否能够识别来源依赖，以及在面对可靠反证时能否维持一致的评价标准。

不同任务还应当有不同的判断要求。

摘要与翻译首先要求忠实保留原文，不应未经说明就替换或删除重要内容。

事实核查则应该主动寻找独立来源，识别原始材料中的错误和争议。

独立分析可以提出超出原文的解释，但需要明确区分事实、推断和未知。

模型不是不能判断材料是否合理，而是不应将这种判断变成随意改变任务范围的理由。

如果用户要求忠实摘要，模型却在没有充分说明的情况下删去了原文的重要信息，那么即使它没有生成明显的假话，答案仍然可能不可靠。

如果用户要求事实核查，模型却只是重复原文，没有检查具体证据，那么即使它完全保留了材料，也不代表完成了任务。

判断是否可靠，必须与任务目标放在一起评价。

跨语言研究还可以走得更远

回到最初的 ROCLING 研究。

它已经证明，在特定的政治立场问卷中，部分模型的答案会随着语言变化而出现明显差异。

但如果想进一步理解这些变化来自哪里，还需要将不同因素分开测试。

例如，可以使用同一模型、同一批问题和固定生成参数，分别进行政治立场选择与开放式事实问答。

这样才能进一步观察，不同提示方式是否改变语言差异的大小。

也可以固定原始证据，仅改变提问语言，检查模型是否保留相同的关键信息，是否对同一份证据使用不同标准。

对于带有搜索能力的系统，还可以控制检索来源，观察回答变化究竟来自模型本身，还是当前可获得的外部资料。

如果要评估 GEO 的影响，则应该进一步比较来源内容在优化前后的检索可见度、引用频率，以及模型最终答案的事实准确性。

其中，来源被引用得更多，不应直接被视为答案质量提高。

如果要研究政治内容对齐，则需要比较不同权重、后训练版本和系统规则下的表现，而不能仅凭模型在回答中给出的理由，推断它内部究竟执行了什么程序。

此外，评价指标也应该超越单纯的立场一致率。

一个模型是否支持某种政治主张，与它是否准确保留事实，并不是同一个指标。

研究至少可以分别观察立场选择、信息保全、无依据推断、事实错误与拒答情况。

这样不仅能够比较模型最终给出什么结论，也能进一步检查它是如何处理已经提供的材料。

而对于开放权重模型，这些测试还可以进一步延伸到不同部署环境。

开放权重让使用者能够在自己的设备或服务器上运行模型，减少对原厂接口的依赖，也为比较和修改模型提供了更多机会。

但开放权重不会自动清除训练和后训练过程中形成的回答习惯。

本地部署改变了模型由谁执行，不代表模型此前形成的信息边界已经消失。

同样，联网搜索让模型能够接触更新的资料，也不意味着它自然具备可靠的来源判断能力。

真正重要的，是让模型的输入、检索来源、输出和失败方式都尽可能接受检验。

模型真正需要跨越的边界

从跨语言政治立场，到训练语料污染，再到 GEO 与本地模型的信息筛选，这些现象发生在不同阶段，却共同指向一个更广泛的问题。

模型能够接触到什么信息，与它最终依据什么信息作出判断，并不是同一件事。

训练语料可能继承不同语言环境中的信息分布，也可能受到数据质量问题和有目的的投毒影响。

生成式搜索能够扩大信息获取范围，但来源可见度与检索机制也可能受到内容优化和恶意攻击的影响。

即使材料已经准确进入模型，最终回答仍然可能发生遗漏、过度解释或者事实捏造。

因此，增加训练规模、支持更多语言、接入互联网或者开放模型权重，都不能单独保证答案更加客观。

它们提供的是更多能力和比较机会，而不是自动正确的判断标准。

我认为模型真正需要解决的，不只是如何掌握更多信息，而是如何判断不同信息之间的关系。

哪些材料来自原始证据，哪些只是重复传播？

哪些内容属于可以直接核实的事实，哪些是尚待证明的解释？

当不同资料发生冲突时，应该依据什么标准决定证据的分量？

而当新的可靠证据出现时，模型是否愿意修正原来的判断？

这些问题不能依靠简单增加回答长度解决，也不能通过始终保持中立来回避。

如果证据充分，模型可以给出明确结论；如果证据不足，就应该说明无法确认；如果出现可靠反证，则应当允许判断发生变化。

模型不必为了反驳而反驳，也不应该为了迎合用户而放弃事实判断。

尤其当越来越多的互联网内容开始以进入 AI 答案为目标进行生产和优化时，我们更需要避免将传播次数误认为独立证据，将来源可见度误认为可信度，或者将模型引用某份材料误认为它已经完成核实。

跨语言能力让模型可以理解不同信息环境中的文本，开放权重让更多人能够检查和修改模型，GEO 则改变了内容生产者与生成式搜索之间的关系。

但这些变化并没有替代最基础的证据要求。

模型真正需要跨越的，或许不只是不同语言之间的信息边界，而是从接触信息、保留信息，到可靠评价信息之间的距离。

一个模型即使能够使用多种语言解释世界，也不意味着它已经超越了这些语言环境中的认知局限。

而拥有再庞大的语料库，如果不能正确识别证据从何而来、为什么可信，以及哪些结论超出了证据范围，也不能自动保证更加可靠的判断。

最终，我更愿意用一个可以实际检验的标准评价模型：

它是否忠实处理材料，是否依据可靠证据作出判断，以及是否允许自己的判断受到新证据的检验。

机器越来越便宜以后，人为什么不能跟着变得更廉价

toewpq — Sat, 12 Sep 2026 00:00:00 GMT

中国制造业过去二十年的技术进步，通常被描述成一条不断提高效率的路线：数控机床减少手工加工，机械臂进入焊接、喷涂和搬运，MES把生产节拍数字化，机器视觉逐渐承担重复检验，如今生成式AI和人形机器人又分别从认知劳动和剩余体力劳动两端继续推进自动化。从企业经营角度看，这条路线非常清楚：机器能够降低单位产品所需人工，提高生产稳定性，把更多经验写入程序、数据库和设备，使生产越来越不依赖某一个具体的人。真正值得追问的变化发生在另一边：企业替换一个具体劳动者的成本也在持续下降，而普通人的住房、食品、交通、医疗、教育和养老仍然主要依赖工资。

2026年夏末，中国大陆制造业连续出现了两起性质不同的劳动事件。星宇股份后来公布，2025年秋季和2026年春季校招期间，公司与440名2026届高校毕业生签订就业协议，其中372人毕业后正式建立劳动关系；到2026年8月，公司与140名新员工协商岗位调整和减员，最终107人与公司解除劳动合同。公司随后承认管理层“研判失误，决策草率”，并称自己“错误地作出了对部分新入职同学进行调岗减员的决定”。这107人中既有研发技术岗，也有生产制造、质量和项目岗位。对他们而言，消失的不只是眼前一份工资，还包括原本用来形成第一年、第二年、第三年职业经验的入口。星宇股份整改情况报道

几天以后，另一段电池工厂视频进入公共视野。最初的网络说法把地点指向宁德时代宜宾基地，并把原因解释成基层员工受到如厕限制。宁德时代否认事件发生于本公司。9月10日，瑞浦兰钧确认视频发生在自己的嘉善基地，并称当事员工提出离职、要求即时办结，公司认为办理需要一定时间，双方没有就时间达成一致，随后发生过激行为；公司同时否认“限制员工如厕”的网络说法，并表示已经报案。企业事后又表示将完善员工沟通机制。第一财经：瑞浦兰钧回应嘉善基地事件

关于如厕限制的具体起因，目前公开材料不足以把网络版本写成确定事实。但企业自己的说明已经暴露了另一个现实：一个本来应由劳动关系和内部沟通程序处理的离职冲突，最后升级到车间极端行为、警方介入和企业公开致歉。现代工厂已经能够把设备停机精确到分钟，把产量精确到件，把人员、节拍、质量和成本持续数字化；员工能够怎样退出、怎样休息、怎样改变职业路径，也应该被当成同样具体的制度问题。

本文真正讨论的因此不是“机器人会不会抢工作”这一句口号，而是一条更长的变化链：机器越来越便宜以后，企业越来越容易降低对某一个具体员工的依赖；劳动者为了继续留在工资体系中，则可能通过承担更多机器、更宽职责、更慢工资增长和更弱退出能力来降低自己的单位价格。技术真正减少岗位以后，问题又会继续向前：如果社会需要的人类劳动小时不断下降，工时、失业、收入、社保和工作的公平回报应该怎样逐步改变。

一、机器节省出来的时间不会自动属于劳动者

人工上下料CNC是观察这一问题最直观的现场。数控系统已经接管刀具轨迹、主轴转速、进给、自动换刀和切削循环中的大量动作，普通操作人员仍然承担工件搬运、装夹、上下料、量测、巡视、报警处理、切屑清理以及不同设备之间的移动。一台机床能够自动加工十分钟，只说明这十分钟不再需要人持续控制刀具，并不意味着这十分钟已经成为员工自己的时间。

现实中的生产管理可以把这十分钟重新计算成下一台设备的可用工时。一个人原本负责8台设备，后来增加到12台、16台甚至更多；原本只承担上下料，后来同时负责补料、清洁、简单质量检查和基础点检。设备越来越自动，员工每天出售给企业的八小时却没有缩短，同样一小时里需要覆盖的机台、任务和异常数量反而增加。机器降低的是单位产品所需人工，而劳动者本人获得的自由时间可能接近零。

因此，“一人管理多少台CNC”不能独立代表先进程度。20台已经自动上下料、集中监控、工件轻且故障率低的机床，与20台仍然需要人工搬运、装夹、量测和频繁处理报警的设备，对人的要求完全不同。真正能够描述劳动负荷的是加工节拍、机台距离、工件重量、上下料时间、量测频率、并发报警概率、异常恢复时间以及员工能否安全地短暂离开岗位。

美国职业安全与健康管理局OSHA对卫生间使用的规定恰好体现了这一原则。OSHA要求雇主保证员工在需要时能够及时使用卫生设施，并明确要求允许劳动者离开工作位置、避免不合理限制。对于生产线等需要持续有人值守的岗位，企业可以设置替岗制度，但需要有足够替岗人员，使等待时间不会变得不合理。OSHA在解释中写道，流水线可以使用relief worker system，但前提是员工不会等待过长时间。OSHA：Restrooms and Sanitation Requirements

美国加州又把同一思路写进仓储生产率监管。AB 701限制会妨碍员工用餐、休息、使用卫生间和遵守安全要求的生产配额。2024年，加州劳工专员办公室因Warehouse Quotas Law违规向Amazon两座仓库开出5,901,700美元处罚，并明确指出这项法律要防止秘密配额以及妨碍员工吃饭、休息和如厕的生产要求。California DIR：Amazon Warehouse Quotas处罚

这些制度承认连续生产的工程现实，却没有把解决成本全部交给人的身体。机器节省出来的一分钟可以变成利润，可以变成下一台机器，也可以真正变成员工少劳动一分钟。技术只创造了“可以少劳动”的可能，最后怎样分配仍然是劳动关系和制度选择。

二、机器真正替掉员工以前，它已经进入工资谈判

生产率红利回答一个人现在能生产多少，另一种同样重要的变化则是企业失去眼前这个人以后损失多少。本文继续把后一种变化称为“替代性红利”。SOP、数控程序、故障数据库、MES、标准化工艺和AI知识库都在把原本集中于个体员工的经验沉淀进组织。人员仍然重要，但某一个具体人的不可替代程度下降。

Leduc和Liu在2024年《American Economic Journal: Macroeconomics》发表的研究直接讨论了自动化与工资谈判之间的关系。摘要原文是：“the threat of automation weakens workers' bargaining power in wage negotiations”，也就是自动化的威胁会削弱劳动者在工资谈判中的议价能力。AEA：Automation, Bargaining Power, and Labor Market Fluctuations

这里关键的词是“threat”。机器人不需要已经站到员工旁边。只要它从展会上的概念设备变成采购部门能够询价、财务部门能够计算投资回报的方案，就已经成为企业的外部选择。传统的“你不干还有别人”开始叠加另一层含义：以后甚至可能不再需要另一个人。

劳动者对这种压力的适应不一定表现为名义降薪。工资保持5000元，同时一个人从负责8台设备增加到12台；原本只有生产任务，后来附加补料、质检和基础维护；原来两个人承担的职责逐渐合并到一个岗位。名义工资没有减少，但企业每支付一元工资获得的任务和产出增加了。本文把这种工资数字不降、单位劳动价格下降的过程称为“防御性降价”。

Fan、Hu和Tang研究2004至2012年的中国企业数据后发现，在2008至2012年样本中，最低工资提高10%与企业采用机器人概率提高0.11个百分点相关，而同期平均机器人采用概率约为0.19%。影响在生产率较高、沿海、民营和技能密集企业中更强。ScienceDirect：Labor costs and the adoption of robots in China

这类结果说明企业会随着相对成本改变技术选择，却不能被翻译成“为了保就业就应该让人工长期足够便宜”。技术成本仍然会继续下降。劳动者今天通过增加人机比重新获得的成本优势，几年以后仍然要面对下一轮更便宜的设备。企业可以等一年再买机器人，普通人的房租、食品和家庭支出却不会停一年。失业保障越薄弱，劳动者越缺少等待能力，也越容易接受更低的实际劳动价格。

因此，失业保险在一个人失业以前就已经具有作用。一个知道自己失去岗位以后仍然能够维持数月正常生活、接受职业转换的人，比一个下个月就无法支付房租的人，更有能力拒绝明显恶化的工时和劳动条件。

三、机器人出现以前，人与人之间的替代已经先被工业化

制造业持续招聘并不等于持续扩张。一座稳定需要1000人的工厂，如果每个月有60人离职，再补入60人，一年可以出现720次招聘行为，年底净就业人数仍然是1000。

Liu和Zhu对长三角制造业劳动力市场的田野研究发现，企业周围已经形成由劳务公司、多层中介和招聘代理构成的人员供应链。研究所在地一个工业园区内就有约150家中介公司。论文指出，这套体系的经营方式会“consistently aggravating labor turnover”，持续加剧人员流动。Springer：Why workers’ turnover is so high

这种体系改变的是离职成本。过去一个熟练员工离开以后，企业可能需要很久才能补齐；人员中介和标准化流程成熟以后，离职逐渐变成流失率、补员速度和返费成本。管理层不必先解决“为什么这个岗位留不住人”，只要确保离开的速度没有超过补人的速度。

星宇股份的公开数据也可以看到劳动投入重新组合。2024年末，公司在职员工10,426人，其中生产人员7,911人、技术人员1,734人；2025年末，在职员工下降到7,532人，其中生产人员4,729人、技术人员增加到2,080人。劳务外包工时同期由约863.8万小时增加到约1087.4万小时。公开数据不能证明某一个正式工被某一个外包工一比一替代，也不能单凭这些数字分解自动化、订单和组织调整各自造成多少变化，但它清楚显示公司可以在正式生产人员、技术人员和外部劳动之间重新组合投入。星宇股份2025年年报（巨潮资讯）

星宇2024年年报还出现过一个很有代表性的统计问题：“劳务外包支付的报酬总额（万元）”一栏填入了明显不合理的数字。它提醒我们，数据公开并不意味着数据天然可靠。自动化时代真正需要的不是更多漂亮仪表盘，而是能够把人员、外包、工时、工资、生产率和技术投资放在一起核验的数据体系。

标准化降低替换人的技术成本，中介降低替换人的交易成本，机器人进一步降低维持生产所需的物理人工。三者不是彼此无关的现象，而是一条持续增强企业替代能力的链条。

四、企业越来越需要成熟技术工时，第一年的经验可能越来越难获得

一个能够独立处理PLC、伺服、电气图、机器人、复杂停机和质量问题的技术人员，不可能在毕业当天直接形成。他需要从点检、简单报警和辅助维修开始，在真实生产里积累第一年，再进入第二年和第三年。

企业培养这种通用技能存在明显的外部性。A公司花两年把新人培养成熟以后，B公司可以通过更高工资直接招聘。对单个企业来说，减少通用培训、直接购买成熟经验具有吸引力；大量企业同时这样做以后，整个行业就会共同面对经验人才不足。

新加坡Skills Development Levy提供了一种现实处理方法。企业需要为所有在新加坡工作的员工缴纳SDL，目前费率为月工资的0.25%，每名员工最低2新元、最高11.25新元。CPF Board对用途写得非常直接：“SDL is used to support workforce upgrading.” 征费进入Skills Development Fund，用于劳动力技能提升和培训补助。CPF Board：Skills Development Levy

这项制度的重要性不在0.25%本身，而在于它改变了“不培训就完全不用承担行业培养成本”的结构。企业可以自己培养，也可以从市场招聘，但整个行业仍然共同承担一部分技能形成成本。

德国双元制职业教育进一步解决技能可迁移问题。学徒在企业与职业学校之间接受训练，最终资格由行业商会等主管机构通过外部考试认可，而不是只由原企业内部评价。一个人在A企业形成的真实能力因此可以带到B企业继续使用，离开当前公司不会让职业资格重新归零。

自动化让这个问题更加紧迫，因为机器人进入的往往正是职业阶梯最下面的任务。BMW披露，Figure 02在美国Spartanburg工厂真实生产环境中运行十个月，支持超过3万辆BMW X3生产，累计移动超过9万件零部件，在约1250个运行小时里承担钣金件取放和焊接前定位。BMW Group：Figure 02生产项目

Hyundai则已经给出Atlas进入生产的路线：2028年从零件排序开始，2030年扩展到部件装配，随后逐渐处理重复、重载和更多复杂任务。官方原文是：“Beginning in 2028 … parts sequencing. By 2030, applications will extend to component assembly.”Hyundai Motor Group：Atlas路线

这些任务技术含量未必最高，却长期承担新人认识零件、设备、节拍、安全和质量体系的入口功能。第一层任务被机器接走以后，行业必须主动设计新的经验入口，否则未来会同时出现两件事：招聘广告越来越要求“三年以上机器人维护经验”，愿意提供第一年经验的职位却越来越少。

五、就业变化很可能先发生在“不再招人”，然后才表现成岗位数量下降

未来就业变化不太可能等到某一天突然出现“机器人正式替掉所有人”。更现实的路径是：同样数量的员工使用更强工具，一个人能够完成更多任务；企业随后减少新人招聘；员工退休或离职以后不再按过去比例补人；总人工小时在几年里逐渐下降。

国际劳工组织2025年的全球研究估计，全球约四分之一劳动者所在职业对生成式AI存在一定程度暴露，同时指出，由于大量任务仍然需要人的输入，“most jobs will be transformed rather than made redundant”。这意味着当前主要变化首先发生在任务结构，但“职业仍然存在”并不等于“过去需要十个人的岗位以后还需要十个人”。ILO：Generative AI and jobs: A 2025 update

Stanford Digital Economy Lab利用ADP覆盖数百万美国劳动者的工资数据更新到2026年6月后发现，22至25岁劳动者在高AI暴露职业中的就业，已经比跟随同龄低暴露职业相同趋势时所对应的水平低约19%；研究者同时写道，调整“appears to operate primarily through reduced hiring of young workers rather than increased separations”，主要发生在减少年轻人招聘，而不是已有员工突然大量离职。Stanford Digital Economy Lab：Canaries in the Coal Mine?

研究团队明确把这些结果称为描述性事实，因此不能把19%直接写成AI单独造成的因果损失。它最重要的意义在于展示了一种已经出现的调整路径：技术冲击可以在总体失业率明显上升以前，先表现为年轻人没有被招进来。

制造业完全可以通过同样方式减少人员。老师傅继续工作到退休，退休以后不再补人；基础任务逐渐交给机器人；剩余员工承担更多设备和复杂异常。几年以后总员工数明显下降，整个过程甚至不需要发生一次轰动性的大裁员。

Volkswagen 2024年的德国重组就是现实参照。公司计划到2030年通过社会协商、自然减员、退休和招聘变化等方式减少超过3.5万个德国岗位。现有员工避免立即被集中裁掉，并不等于未来年轻人的入口没有减少。技术性就业冲击因此不能只统计“今天裁掉多少人”，还需要同时看新人招聘率、学徒名额、退休岗位补招比例和实际总工时。

六、从当前社会走向高度自动化社会，不会从40小时工作突然跳到“所有人不用工作”

生产力提高以后，最早应该发生的变化是减少过度劳动。社会仍然需要绝大多数劳动人口时，机器提高效率带来的第一批时间红利可以表现为更少加班、更短标准工时和更高小时工资。这个阶段的核心仍然是把CNC已经节约的十分钟真正还一部分给劳动者，而不是立刻再装进下一台机器。

当总劳动需求进一步下降以后，工作共享开始变得重要。德国Kurzarbeit已经证明，在劳动需求突然下降时，减少工时能够阻止产出下降直接转换成同等规模裁员。2009年高峰期约150万人进入短时工作安排，OECD估计这套制度最多保住约58万个岗位。OECD：德国短时工作制度案例

德国当时面对的是经济危机，未来技术提高生产率的原因不同，但分配逻辑相通。同样总工作量从4000小时降到3200小时，社会可以让80个人继续40小时、20个人完全失业，也可以让更多人共同减少工时。技术没有规定必须选择前一种。

随着工具继续提高生产率，缩短工时会逐渐出现边界。原本100个人每周40小时需要4000小时，如果长期只需要2000小时，把所有人降到20小时仍然能够共享；如果以后只需要1000小时，继续要求每一个劳动年龄人口都必须拥有传统岗位，就会开始人为制造没有实际必要的工作。

因此，过渡阶段会出现越来越多中间状态。一个人可以一周工作三天，另外时间学习；工作几年以后进入半年系统学习；家庭出现照护需求时暂时减少市场劳动；一部分人利用AI、软件和数字制造进行自己的小规模生产；也会有人在某些时期确实没有市场岗位。医疗、养老和基本生活如果仍然只能依靠一份标准全职劳动合同取得，这些状态就无法稳定存在。

到了市场所需劳动明显少于劳动人口的阶段，继续让所有人争夺越来越少的全职岗位，会重新把社会推回本文最开始的问题。假如100个劳动年龄人口长期只需要50个全职岗位，另外50个人仍然必须依靠就业才能取得正常生活，那么人的价格自然会向下竞争：更低工资、更宽职责、更差条件都会成为进入这50个岗位的筹码。

高度自动化社会因此最终需要改变工资在收入体系里的角色。工资逐渐从“取得全部生活资源的唯一入口”，变成承担市场劳动、占用个人时间和承担责任以后得到的明显额外回报。护理、维修、电力、复杂设备、安全和应急等仍然需要人的岗位如果难以招聘，就应该提高小时工资、缩短工时、改善休假，而不是通过故意让没有工作的人陷入贫困来逼迫他们接受岗位。

高度自动化也不等于人类什么都不做。市场岗位减少与社会活动减少是两回事。照护、学习、创作、社区参与、研究兴趣、小规模生产和人与人的关系仍然可以大量存在，只是越来越多活动不必先变成一份企业劳动合同才能获得生活资格。

七、失业保障必须让人活得下去，同时让继续工作得到明显更多

这里存在一个现实的公平问题。如果原本收入相近的两个人，一个继续每天通勤、工作八小时、承担绩效和责任，另一个暂时没有市场工作却取得几乎相同甚至更高的可支配收入，继续工作的人产生不公平感完全合理。社会不能要求劳动者每天额外交出几十小时，同时让这段时间几乎没有额外价格。

美国2020年的疫情失业保险提供过一个极端案例。CARES Act在各州失业保险之上增加每周600美元Federal Pandemic Unemployment Compensation。NBER研究发现，2020年4月至7月，76%的普通失业保险合资格劳动者法定替代率超过100%，中位数达到145%；把雇主福利和税收差异考虑进去以后，仍有69%的合资格劳动者综合替代率超过100%。NBER：US Unemployment Insurance Replacement Rates During the Pandemic

疫情期间还存在封锁、健康风险、照护责任和岗位直接消失等特殊条件，所以这项数据不能被简化成“福利高导致大家不工作”。它说明的是一个更基础的设计问题：如果不工作取得的现金收入长期接近甚至超过原工资，继续工作者会认为自己的时间和责任缺少明确额外回报。

因此，收入保障需要同时处理两端。失去岗位的人不能因为几周没有工资就跌入贫困，因为迫切需要下个月房租的人会迅速接受任何低价工作，进而压低所有在职者的谈判能力；继续工作的人则必须通过工资、养老金积累和其他制度获得明显更多收入。

新加坡Workfare Income Supplement体现了后一方向。WIS向符合条件的较低收入在职劳动者提供现金和CPF补充，截至2026年2月累计已有113万名劳动者获得超过129亿新元。CPF Board写道：“Workfare is paid in the form of CPF payments and cash to supplement their incomes.”CPF Board：Workfare Income Supplement

加拿大Employment Insurance的Working While on Claim则处理福利悬崖。领取EI期间重新开始部分工作时，在一定范围内，每赚1加元只减少0.5加元福利。加拿大政府当前示例中，一名原本每周领取330加元EI的人，找到每周350加元兼职后仍保留155加元EI，总收入达到505加元，明显高于完全不工作时的330加元。Canada.ca：Working While on Claim

未来技术转换还需要处理“已经重新就业，但工资明显下降”的情况。一个工作十年的技术人员原来月收入8000元，岗位消失后进入新行业只能拿6000元，传统统计已经把他算成重新就业，家庭实际生活却发生了明显下台阶。美国过去的Reemployment Trade Adjustment Assistance曾为部分贸易冲击劳动者提供限期工资保险，补偿旧工资和新工资的一部分差额。类似机制可以用于技术转换：补贴直接给劳动者、限期并逐步退出，使一个人敢于进入新行业积累经验，而不是在长期失业等待原工资与一次性永久降薪之间二选一。

高度自动化社会真正稳定的公平原则因此是：没有市场工作不能使一个人失去正常生活资格；真正参加劳动必须得到明显额外收入。前一条维持人的拒绝能力，后一条维持劳动本身的公平价格。

八、社会保险不能永远主要建立在“每个人都长期领取工资”这一前提上

当前中国大陆职工养老保险仍然高度依赖工资劳动和缴费关系。2025年开始实施的渐进式延迟法定退休年龄，把男职工法定退休年龄最终逐步延迟至63岁；原法定55岁的女职工逐步延迟至58岁，原法定50岁的女职工逐步延迟至55岁。从2030年开始，按月领取职工基本养老金的最低缴费年限又将由15年逐年增加6个月，到2039年达到20年。全国人大：渐进式延迟法定退休年龄决定

这项改革主要针对人口老龄化、人均预期寿命、健康水平和劳动力供给，并不是为AI或机器人设计。它却提供了一个很重要的未来参照：如果以后劳动年龄人口仍然很多，而市场真正需要的全职岗位和工资总小时明显下降，继续主要依靠“更晚退休、更长缴费”来维持体系，会与技术减少必要劳动的方向产生越来越明显的冲突。

一个年轻人如果未来因为AI和自动化经历更多间断就业、部分工时、长期学习和职业转换，同时又面对更长最低缴费要求，他取得完整养老权益的难度可能上升。一个社会如果已经不需要每个人工作40小时，却为了维持一个建立在大量工资劳动上的社会保险体系而继续要求人尽可能工作更久，就会把机器节约出来的劳动重新塞回缴费制度。

这不意味着缴费型养老保险应该突然取消。与个人工作历史和收入相关的养老金仍然适合保留缴费属性。需要逐渐改变的是基础保障的融资范围。

现有制度已经提供了几条不同方向。日本基础年金目前有一半财源由国库负担，厚生劳动省直接写道：“基礎年金の財源の半分は国庫負担で賄われています。”日本厚生劳动省：基础年金财源

德国法定养老保险同样并非纯粹依靠工资缴费。德国养老保险机构公布的2025年数据中，约76.9%的收入来自缴费，联邦补助约占22.3%。Deutsche Rentenversicherung：2025年融资情况

法国则把部分社会保障融资扩展到财产和投资收入。CSG、CRDS等社会征收可以适用于部分资产和投资收入，说明社会保障税基并不必然等于工资总额。Service-Public.fr：Prélèvements sociaux sur les revenus du patrimoine

中国大陆自己也已经存在比单纯延长缴费年限更值得继续发展的另一条方向。2017年国务院决定划转部分国有资本充实社保基金，中央和地方国有及国有控股大中型企业、金融机构原则上划转10%的国有股权；划转股权的分红和运作收益可专项用于弥补企业职工基本养老保险基金缺口。文件把目标之一写成“使全体人民共享国有企业发展成果”。财政部：划转部分国有资本充实社保基金实施方案

这项制度已经包含了一条与高度自动化社会非常接近的逻辑：社会保障可以直接取得资本收益，而不必全部等待工资缴费。

更稳妥的过渡因此应该分层进行。与个人工作历史直接相关的养老金和保险继续保留缴费属性；维持正常生活所需要的基础养老、基本医疗和一部分失业保障，财政责任逐渐提高；当劳动收入占比下降时，资本收入、企业利润和更广的税基承担更多融资；公共资本和国有资本收益则进入长期社会保障基金。社会保险的收入来源由“劳动者工作多少”逐渐扩展到“整个经济创造了多少收入和资本回报”。

九、公共资本收益可以减少“只有失业的人才能分享技术红利”的冲突

如果技术进步产生的公共支持只有失业以后才能领取，社会很容易被切成两个身份：继续工作的人认为自己承担通勤、工时、责任和税费，失业的人才有资格分享新的技术红利。这会放大工作者与非工作者之间的公平冲突。

共同资本收益提供了另一种思路。阿拉斯加Permanent Fund把部分矿产资源收入积累成长期公共资产，再用投资收益向符合条件的居民支付年度分红。继续工作的人同样领取，因此这笔收入不会产生“必须先失业才能获得”的激励。Alaska Permanent Fund Dividend

挪威Government Pension Fund Global则采用规模更大的代际资产模式，把石油活动净现金流积累进基金，再通过财政规则进入公共预算，使资源财富同时服务当前和未来世代。Norway Ministry of Finance：Government Pension Fund

AI和机器人产业并不是自然资源，公共资本逻辑仍然具有启发意义。现代技术产业大量依赖大学研究、公共基础设施、能源、电网、政府采购和产业融资。公共部门在部分项目中保留股权、基金份额或长期收益权以后，技术成功产生的资本回报可以直接进入公共收入，而不是等一个劳动者被替代以后才通过救济补偿。

这样，继续工作的人可以得到工资加共同收益；暂时没有市场岗位的人拥有基本保障、保险和共同收益；进入学习阶段的人再获得学习支持。共同基础人人拥有，劳动仍然有明显额外价格。

十、学习不能变成“机器会了什么，人就赶紧逃到下一项技能”的永久追赶

自动化转型很容易把全部责任重新放回个人：今天学PLC，明天机器人能够自诊断以后学机器人；机器人更容易示教以后再学AI；AI继续提高以后再寻找下一项暂时不会自动化的技能。这样的人生仍然完全围绕“怎样证明自己还值得被雇佣”组织。

职业学习当然重要，但成年人真正缺少的往往是时间和收入，而不是课程目录。新加坡SkillsFuture Mid-Career Training Allowance已经把收入支持直接加入长期学习。符合条件的中年劳动者参加全日制长期培训时，补助按照过去平均月收入的50%计算，每月最高3000新元，一生最多使用24个月。官方还明确解释，这种比例既用于弥补部分收入损失，也要“preserving the incentive for them to return to work”。SkillsFuture：Mid-Career Training Allowance FAQ

瑞典的转型学习支持进一步承认成年人重新成为学生可以是一种正常人生状态。职业稳定因此可以从“几十年持续待在同一工作状态”逐渐转变成“换轨以后不会掉出收入、保险和学习体系”。一个人30岁工作，35岁系统学习一年，之后重新工作；40多岁因为产业变化再次学习或承担家庭照护，后来再回到市场。

非职业学习也应该保留独立价值。维修人员学习历史、工程师学习摄影、普通员工学习音乐，都没有义务先证明未来工资会提高。生产率提高以后，教育的一部分红利应该表现为成年人有更多理解世界和发展兴趣的时间。

十一、AI最大的另一种意义，是普通人的idea更容易越过工具墙

生成式AI对就业的影响还有另一条经常被忽略的方向：它正在降低普通人实现小规模想法时需要购买的专业执行能力。过去一个人想做网站，需要系统学习前后端和部署；做游戏需要代码、美术、动画和声音；制作3D角色需要建模、拓扑、UV、材质和渲染。很多idea没有经过市场验证，就先死在第一版原型出现以前。

Brynjolfsson、Li和Raymond研究5179名客服人员使用生成式AI助手后的效果，发现平均生产率提高14%，其中新手和低技能人员提高34%，而经验丰富的高技能人员改善很小。论文原文是：“a 34% improvement for novice and low-skilled workers”。研究还提供了AI帮助新人更快获得高绩效员工实践经验的证据。NBER：Generative AI at Work

这对普通劳动者尤其重要。真正维修汽车的人知道维修流程中哪些小问题一直没人解决，真正操作CNC的人知道哪些报警记录和交接流程浪费时间，小店经营者知道自己真正需要什么简单软件。他们过去拥有领域经验，却缺少程序员、设计师和产品团队。AI降低第一版代码、网页、图片、数据工具和3D原型的执行成本以后，领域知识和实现能力之间的距离缩短了。

未来减少的就业时间因此不必全部变成“闲置”。一部分人可以做小型软件、开源项目、角色、游戏、3D原型和实体产品，通过AI、3D打印和CNC完成过去需要一个小团队才能验证的idea。大量规模太小、传统公司没有商业动力处理的问题，可以由真正生活在问题中的人自己尝试解决。

真正的AI赋权还需要退出能力。一个人的模型记忆、文件、提示、工作流和项目上下文如果全部被锁在一家供应商内部，依赖企业的旧结构只会换成依赖平台。开放权重、开放接口、数据导出、上下文迁移和本地运行的重要意义就在这里：使用者能够把积累带走，供应商才真正可以被替换。

企业越来越不依赖某一个具体员工时，个人也应该越来越不依赖某一家企业；AI平台越来越能够参与个人工作时，用户也应该越来越容易离开某一个平台。

十二、照护机器人最值得替代的是负担，而不是关系

高度自动化社会并不意味着所有人类活动都应该追求最低人工配置。照护领域尤其能说明这一点。日本长期推动移乘机器人、监测设备、ICT和其他介护技术，目的包括提高照护质量、减轻护理人员身体负担并支持老年人自主生活。机器承担每天反复搬抬老人、物品配送、夜间重复巡视和跌倒监测，都具有非常明确的价值。

真正的差别发生在机器节约出来的时间怎样使用。护理人员少做两小时机械搬运以后，可以用这些时间和老人交谈、观察身体和情绪变化、联系家属；机构也可以直接减少人员配置，让剩余员工继续满负荷工作。

PARO机器海豹的研究说明机器人可以在部分场景改善躁动、焦虑和互动，但2023年的系统综述和Meta分析纳入12篇研究、1461名参与者后，同时指出：“The overall quality of evidence for all outcomes were graded as low.”PubMed：PARO系统综述与Meta分析

机器人能够产生让老人感到安慰的互动，这种安慰完全可以是真实的。照护关系仍然包含判断和责任。老人突然拒绝进食、意识变化或者需要做高风险决定时，需要有人结合病史、药物、过去习惯和家庭关系承担后果。

所以照护领域真正值得追踪的是两组数据：腰伤、夜间机械任务和危险搬运应当下降；人与老人真正交流、观察和个体照护的时间应当增加。机器人优先替代照护中的负担，而不是把照护中的关系也一起压缩掉。

十三、任何制度都会被利用，所以不能把现实重新压成一个漂亮数字

新人招聘率、培训小时数、内部晋升率、平均工资和正式员工人数都可以提供信息；只要其中任何一个直接决定补贴、评级或监管结果，组织就会开始围绕数字优化。

要求新人比例，企业可以增加短期实习生；要求培训小时，可以堆课程；要求内部晋升，可以改职位名称；要求平均工资提高，减少最低工资员工就能自动提高平均值；要求留存率，企业又会获得提高员工退出成本的动力。

所以真正可靠的观察必须看多年职业轨迹和多组互相制约的数据。一个企业可以同时出现产值增加30%、平均工资提高8%、正式员工减少25%、外包工时增加40%、新人招聘下降30%。这些矛盾本身就是现实。生产率需要和实际工时、人机比一起看；工资需要和小时工资、人员构成一起看；培训需要和几年后的外部认证、职业流动一起看；就业规模需要和正式工、外包、派遣、招聘与离职流量一起看；新人入口需要追踪两三年以后是否真正获得技能。

制度成熟的标志不在于找到一个无法作弊的指标，而在于企业如果想制造一个漂亮故事，就必须同时让很多独立数据都能够互相解释。

十四、工会和其他组织真正改变的是“一个人只能单独与机器竞价”的处境

一个基层员工认为一人承担的机器已经超过能够安全处理的范围时，个人最容易采取的行为是离职。十个人分别离职，会成为十条流失记录，再由招聘系统补十个人。同样十个人如果能够共同掌握设备距离、工件重量、上下料节拍、并发报警、异常处理和工伤数据，再要求讨论定员，问题就从个人忍耐能力变成生产制度必须解释的工程安排。

2010年南海本田零部件厂罢工展示过这种力量变化。单独一名年轻生产工人高度可替代，关键零部件同时停止供应以后，多座整车厂受到停产影响。个体的可替代性与集体的可替代性完全不同。

自动化进一步要求这种组织能力发生在技术部署以前。Hyundai公布Atlas生产路线以后，韩国现代汽车工会已经公开提出机器人进入生产现场需要劳资协商。真正需要讨论的并不只有“机器以后裁掉谁”，还包括机器人先进入哪些工序、退休以后哪些岗位不再补人、留下的人承担多少设备、生产率提高以后工资和工时怎样变化。

企业天然以法人、管理系统、财务和律师形成持续行动的集体。如果普通人的利益只能以一次离职、一次工伤和一次个人投诉出现，企业越容易替换个人，双方力量差距就越大。工会、行业组织、媒体、学术研究、NGO、宗教福利机构和其他中间共同体因此不会因为自动化和社会保障增加而失去价值。资本需要监督，负责分配资本收益和公共资金的行政系统同样需要监督。

十五、真正高度自动化以后，充分就业会逐渐变成充分收入、充分参与和充分选择

今天直接放弃充分就业并不现实。住房、食品、医疗、教育和养老仍然高度依赖工资，普通人失去工作以后实际消费能力和生活选择真的会下降。一句“人的价值不能由工资衡量”无法替代这层现实。

但“每一个成年人长期保持40小时全职工作”也没有理由成为永恒目标。生产率提高的早期阶段，应当减少加班和劳动强度；随后通过缩短工时共享减少的总劳动需求；再往后，工作、学习、照护和个人项目开始在同一人生里循环存在；当市场真正只需要少量人类劳动时，工资逐渐成为承担必要劳动的额外报酬，基本生活则越来越少依赖某一家企业是否愿意购买一个人的40小时。

这条过渡路线同时处理两个极端。一端是为了逼人工作而故意让没有市场岗位的人陷入贫困，结果只会制造更多廉价劳动力；另一端是让工作和不工作的净收入几乎一样，使每天交出大量时间的人觉得自己的劳动没有价值。

最终更合理的原则仍然很简单：没有市场岗位的人不失去正常生活；真正承担市场劳动的人明显多得；特别稀缺、危险或责任重大的工作继续通过更高小时工资和更短工时吸引人。

高度自动化社会最终并不是“全民失业社会”，而是“越来越多有价值的活动不再必须先变成一份全职劳动合同”的社会。

结语：机器真正应该减少的，是普通人不得不出售的人生时间

工业社会长期形成了一条稳定的资源交换链：人把自己的时间和劳动出售给企业，企业支付工资，人再使用工资取得住房、食品、交通、教育、医疗和养老。工资因此同时承担劳动价格和生活资源入口两种功能。当这两种功能高度绑定时，机器越有能力替代劳动，普通人就越容易把技术进步理解成自己的生活资格受到威胁。

机器真正替掉员工以前，这种压力已经存在。一个人管理更多设备，同样工资承担更多职责，休息更少，工资增长更慢，劳动关系更加灵活。企业获得更强的替代选择，员工则受到每个月生活支出的约束。机器变得越来越便宜，人先通过降低自己的单位价格继续留在工资体系里。

机器真正开始减少岗位以后，社会又很容易要求劳动者立刻学习下一种暂时不会被机器替代的技能，再寻找另一份40小时工作。这样的循环提高了生产效率，却没有兑现技术最基本的承诺：相同生活水平原本应该需要越来越少的人类必要劳动。

真正的过渡需要在几个方向同时发生。技能能够跨企业迁移，员工失去当前岗位以后拥有足够等待时间；劳动需求下降首先有一部分表现为工时下降；新人仍然拥有形成第一年经验的入口；继续工作的人取得明确额外收入；社会保险逐渐减少对单一工资税基的依赖，把一般财政、资本收入和公共资本收益引入长期保障；机器释放出来的时间则可以进入照护、学习、创造、社会参与，也可以保持为空白。

中国大陆已经在同一个社会保险体系里同时展示了两条可能的方向。一条是延迟退休和逐步延长最低缴费年限，让劳动者更长时间留在缴费体系；另一条是划转部分国有资本充实社保基金，让资本本身承担一部分养老责任。前者在应对今天的人口老龄化时有自己的制度逻辑，后者对于未来工资劳动占比可能下降的社会更具有延展性。真正高度自动化以后，社会不能无限通过要求人工作更久来维持一个建立在大量工资劳动上的制度。

生产系统当然可以不断去关键人化。老师傅离开以后，工厂不应该停止；程序员离职以后，软件知识不应该全部消失。这是工程进步。

人的社会地位需要朝另一个方向发展：企业越来越不依赖某一个具体员工，社会也应该让这个员工越来越不依赖某一家企业。

机器真正应该淘汰的是一部分重复、危险和不得不完成的劳动，以及一部分为了取得生活资格不得不出售的人生时间。

最坏的未来，是机器越来越便宜以后，人为了继续被购买，只能让自己的工资、休息、健康和时间一起更加廉价。

更值得追求的未来，是机器越来越便宜以后，人的时间越来越珍贵。技术生产出更多财富以后，普通人终于能够少出售一部分人生，而且不会因为少出售这部分时间就失去正常生活资格。

主要在线资料与原文

American Economic Association：Automation, Bargaining Power, and Labor Market Fluctuations：原文“the threat of automation weakens workers' bargaining power in wage negotiations”。
ScienceDirect：Labor costs and the adoption of robots in China：2008—2012年样本中，最低工资提高10%与机器人采用概率提高0.11个百分点相关。
Springer：Why workers’ turnover is so high：长三角劳动力中介链田野研究。
OSHA：Restrooms and Sanitation Requirements：要求员工在需要时能够及时使用卫生设施，并允许连续岗位以足够替岗人员解决覆盖问题。
California DIR：Amazon Warehouse Quotas处罚：2024年处罚金额5,901,700美元。
CPF Board：Skills Development Levy：原文“SDL is used to support workforce upgrading”。
BMW Group：Figure 02生产项目：十个月、超过3万辆BMW X3、9万余件零部件和约1250小时实际生产运行。
Hyundai Motor Group：Atlas路线：2028年零件排序、2030年部件装配。
ILO：Generative AI and jobs: A 2025 update：全球约四分之一劳动者所在职业存在一定GenAI暴露，多数工作更可能被重组而不是直接消失。
Stanford Digital Economy Lab：Canaries in the Coal Mine?：截至2026年6月，22—25岁高AI暴露职业就业相对缺口约19%，调整主要发生在招聘端。
NBER：US Unemployment Insurance Replacement Rates During the Pandemic：2020年FPUC期间76%的普通失业保险合资格劳动者法定替代率超过100%，中位数145%。
CPF Board：Workfare Income Supplement：截至2026年2月累计发放超过129亿新元，覆盖113万名较低收入劳动者。
Canada.ca：Working While on Claim：在一定范围内，每赚1加元只减少0.5加元EI。
全国人大：渐进式延迟法定退休年龄决定：2030年起最低缴费年限由15年逐步提高，2039年达到20年。
财政部：划转部分国有资本充实社保基金实施方案：纳入范围的国有股权原则上划转10%，相关分红和运作收益可用于弥补养老基金缺口。
日本厚生劳动省：基础年金财源：基础年金一半财源由国库负担。
Deutsche Rentenversicherung：2025年融资情况：2025年缴费收入占76.9%，联邦补助占22.3%。
Service-Public.fr：法国财产和投资收入社会征收：CSG、CRDS等适用于部分财产和投资收入。
SkillsFuture：Mid-Career Training Allowance：补助按平均月收入50%计算，最高每月3000新元，并强调兼顾收入损失与返回工作的激励。
NBER：Generative AI at Work：5179名客服人员中平均生产率提高14%，新手和低技能人员提高34%。
PubMed：PARO系统综述与Meta分析：12篇研究、1461名参与者，作者将各项结果总体证据质量评为低。

开放权重之后，模型公司开始重新分蛋糕

toewpq — Fri, 07 Aug 2026 00:00:00 GMT

过去几年，开放权重最有吸引力的一点，并不只是模型可以下载。

真正发生变化的是，一部分原本集中在基础模型公司的价值创造能力被分散了出去。

模型权重下发以后，云计算公司可以提供托管，推理服务商可以通过量化、缓存、批处理和 kernel 优化降低成本，企业可以建立私有部署，开发者可以继续微调并构建自己的应用。基础模型由一家公司的产品，逐渐变成更多公司可以继续加工的生产资料。

这也是此前讨论开放权重时，我更在意的“把蛋糕分给更多人”。

但到了 2026 年，这件事出现了新的后半段。

Kimi K3 开始要求达到一定规模的 MaaS 服务商重新签订商业协议，实际合作中已经出现收入分成；阿里据报也准备在下一代 Qwen 中采取类似方式。DeepSeek 则在维持开放权重的同时，明确预告官方 API 将大幅涨价。

另一边，OpenAI 却在把 GPT-5.6 Luna 的 API 价格一次下调 80%，随后又把 Luna 下放为 ChatGPT 免费用户的默认模型。

这些动作放在一起看，真正发生的并不是简单的价格战。

开放权重公司在模型完成大规模扩散以后，开始寻找把收入重新送回研发端的方法；OpenAI 则利用封闭模型的全栈控制和巨大调用规模，把基础智能主动做成越来越便宜的入口。

AI 模型竞争由此从“谁愿意把模型放出来”，进入了“模型产生的价值到底由谁来分”的阶段。

一、开放权重先把蛋糕做大

Kimi K2.5 很能代表开放权重早期的逻辑。

它采用 Modified MIT License，基本保留了使用、复制、修改、发布、分发、再许可和销售模型及衍生作品的自由。真正针对超大商业产品增加的条件，主要是品牌展示。

授权条款写道：

“you shall prominently display ‘Kimi K2.5’ on the user interface of such product or service.”

中文可以译为：

“你应当在该产品或服务的用户界面上显著展示‘Kimi K2.5’。”

这个要求只在产品超过 1 亿月活，或者月收入超过 2000 万美元时触发。

这里并不存在“你用了我的模型赚钱，就必须按照收入向我交一部分”的关系。

这实际上给了下游很大的商业空间。

一家推理平台可以取得模型以后建设自己的 GPU 集群，再靠更好的调度和推理优化赚钱；企业可以自己部署，避免把敏感数据发送到公共 API；应用公司可以把模型能力包装成更具体的软件产品。

模型研发公司得到的是影响力和生态，其他参与者则分别从算力、部署、优化和应用中取得收益。

开放权重由此产生了一种与封闭 API 不同的产业结构：

模型公司创造基础能力，但不再自动取得这项能力以后产生的全部收入。

这也是“把蛋糕分出去”真正发生的地方。

对于个人和企业用户而言，得到的也不只是便宜。

同一个模型可以由多个服务商提供，也可以部署在自己的基础设施。如果一个 API 服务商涨价或者停止服务，更换服务商并不意味着必须连底层模型一起更换。

开放权重分散的不只是收入，还包括部署权、优化权和退出权。

二、Kimi K3 开始修改分钱规则

到了 Kimi K3，Moonshot 没有把已经分出去的权重重新收回来。

K3 仍然是一款开放权重模型，Moonshot 官方仓库将其描述为一款 2.8T 参数、104B 激活参数的开放权重多模态 Agent 模型。

真正发生变化的是授权条款。

K3 对 Model as a Service，也就是 MaaS，增加了专门规定。按照授权条款定义，这主要指向第三方提供模型推理或者微调能力，并让客户能够实际控制输入、参数或者训练数据的服务。普通终端产品只是把模型嵌入某项具体功能，并不会因此自动成为 MaaS。

当一家经营 MaaS 的企业及其关联公司在连续 12 个月内总收入超过 2000 万美元以后，授权条款规定：

“the Licensee must enter into a separate agreement with Moonshot AI”

中文即：

“被许可方必须与 Moonshot AI 另行签订协议。”

这份协议需要在继续将 K3 或其衍生作品用于商业用途之前完成。

内部使用则被明确排除在这一要求之外。

这个边界很重要。

一家企业把 K3 部署在内部做知识检索，与一家云平台直接出售 K3 推理 API，是两种不同的商业行为。

Moonshot 现在真正想收费的，是后者。

换句话说，K3 没有取消其他参与者分蛋糕的资格，而是开始要求那些直接把基础模型本身变成大规模生意的人重新和模型研发者分钱。

三、“最高 30%”意味着研发方开始重新进入价值链

K3 公共授权条款没有写死统一的收入分成比例，它只规定达到条件的大型 MaaS 需要另外签署协议。

真正的分成数字来自已经开始形成的商业合作。

Reuters 8 月 7 日援引消息人士报道称，Moonshot 在部分合作中要求：

“up to a 30% revenue share”

即：

“收入分成最高可达到 30%。”

这是部分商业协议的条件，不是所有 K3 用户统一面对的授权费。

中软国际已经披露与 Moonshot 存在收入分成协议，但没有公布具体百分比。

DigitalOcean CEO Paddy Srinivasan 也确认公司与 Moonshot 存在商业协议。

这一步的意义其实比“30% 高不高”更大。

开放权重原来解决的是模型能力如何从一家公司的服务器中走出去。

现在开始解决的是，能力走出去以后，训练模型的人还能从哪里获得下一代模型的研发资金。

如果一个实验室承担模型训练、数据处理、后训练和研究人员成本，模型发布以后却由另一家公司建立 GPU 集群、包装成 API，再形成数千万美元甚至更大的业务，基础研发与下游商业收入之间会逐渐脱节。

K3 给出的答案不是重新封闭模型，而是在大型模型转售层增加一个价值回流口。

这实际上补上了开放权重商业模式过去最薄弱的一环。

四、Qwen 跟进后，这已经不是一家公司的试验

如果这种模式只出现在 Kimi，仍然可以理解成 Moonshot 自己的一次授权条款实验。

但阿里已经准备往相同方向走。

Reuters 报道称，阿里计划要求下一代 Qwen 开放模型的主要商业用户，分享利用模型产生的一部分收入。

此前阿里主要在模型运行于阿里云时收费，而客户把多数开放模型部署到自己的数据中心以后，不需要继续向阿里支付模型使用费用。

新的制度如果按报道落地，就意味着收费边界会从“谁替你运行模型”进一步延伸到“谁提供了这个模型本身”。

这也说明中国开放权重模型正在进入一个很明显的商业阶段：

早期先把模型免费或者极低成本送进市场；

形成开发者、云服务商和企业部署生态；

随后再针对重度商业使用、提前访问、深度合作和大型 MaaS 收费。

Reuters 在报道中将这种模式概括为一种已经在硅谷反复使用的 freemium 路线。

开放权重因此开始从单纯的发布策略，变成一种真正需要设计收益分配的产业结构。

五、DeepSeek 涨价，更像是低价扩张期结束

DeepSeek 走的是另一条路线。

截至 8 月 7 日，V4-Flash 的官方 API 价格仍然只有每百万输入 token 0.14 美元、输出 token 0.28 美元；V4-Pro 分别是 0.435 美元和 0.87 美元。

这个价格低到什么程度，Artificial Analysis 的测试给出了一个比较直观的参照。

Reuters 报道称，V4-Flash 完成其基准测试的平均模型费用约为 0.03 美元，是当时知名模型中运行费用最低的一档。

DeepSeek 随后却在官方价格页写道：

“We plan to raise the overall pricing for DeepSeek API services in the near future, with a significant increase expected.”

中文即：

“我们计划近期整体提高 DeepSeek API 服务价格，预计涨幅较大。”

截至目前，新价格还没有正式公布。

从 DeepSeek 过去的定价变化看，这次涨价最合理的解释并不是模型突然变得更昂贵，而是极低 API 价格已经完成了它最重要的市场任务。

低价最初不仅是在出售 token，也是在购买市场份额。

当 API 足够便宜，开发者尝试一个新模型的成本就会大幅降低；应用从其他模型迁移过来的阻力也会下降。再加上 V4 本身已经公开权重，DeepSeek 能够同时依靠官方超低价 API 和第三方部署迅速扩大生态。

V4-Flash 正是这条路线的典型产品。DeepSeek 在 V4 发布时直接将其定位为快速、高效、经济的版本，同时公开了 V4 权重。

现在生态已经形成，官方 API 就不必永久承担补贴整个市场的任务。

六、DeepSeek 过去已经把价格当作供需调节工具

V4-Pro 今年的价格变化进一步说明这一点。

V4 刚发布时，Pro 的价格最高可以达到 Flash 的约 12 倍。DeepSeek 当时给出的原因是：

“constraints in high-end compute capacity”

即：

“高端算力容量受限。”

DeepSeek 还表示，随着华为 Ascend 950 Supernode 在下半年大量供应，Pro 价格预计会明显下降。

到了 5 月，DeepSeek 果然把 V4-Pro 原本的 75% 折扣永久化，使价格降到最初水平的大约四分之一。

这说明 DeepSeek 的 API 价格本来就不是静态的“计算成本加固定利润”。

它同时承担着调节算力需求、扩大用户规模和提高设备利用效率的作用。

今天 V4-Flash 的官方并发限制是 2500，V4-Pro 是 500。

一个价格极低、调用规模迅速扩张的模型，提高价格自然能够同时完成两件事情：

一方面提高每单位算力带来的收入；

另一方面把极度价格敏感的大规模调用推向第三方托管或者自行部署。

而开放权重恰好给了 DeepSeek 这么做的空间。

用户离开 DeepSeek 官方 API，并不等于离开 DeepSeek 模型。

因此，DeepSeek 现在可以开始让官方托管服务恢复利润，而继续让开放权重承担模型扩散。

这就是它与完全封闭模型最大的不同。

七、OpenAI 为什么反而可以把 Luna 降价 80%

OpenAI 现在走向了相反方向。

GPT-5.6 Luna 没有开放权重。用户无法把 Luna 下载下来，然后交给任意云服务商托管。

因此，OpenAI 想让 Luna 获得足够大的使用规模，就必须让官方入口本身具有足够强的吸引力。

7 月 30 日，OpenAI 直接宣布：

“Starting today, GPT-5.6 Luna, our fastest and most affordable model, will cost 80% less.”

中文可以译为：

“从今天开始，GPT-5.6 Luna——我们速度最快、价格最低的模型——价格将降低 80%。”

降价以后，Luna 的 API 价格变成每百万输入 token 0.20 美元、输出 token 1.20 美元。

OpenAI 之所以有能力做这样的价格调整，首先因为它已经不再只是优化模型本身。

它正在优化从模型到最终 token 输出的整套端到端技术体系。

官方披露，更好的路由提高硬件利用率，生产软件优化提高 token 生成效率，上下文管理则减少 Agent 重复已经完成的工作。

GPT-5.6 Sol 甚至被用于优化 OpenAI 自己的生产 kernel，这些工作帮助端到端 serving 成本降低约 20%，相关实验又使 token 生成效率提高超过 15%。

这意味着 OpenAI 的成本优势已经不仅来自“训练一个更小的模型”。

它来自模型、kernel、调度、缓存、上下文管理和基础设施一起优化。

八、OpenAI 真正拥有的是规模化集中调度能力

OpenAI 还能做一件开放权重实验室很难单独做到的事：把巨大调用量统一放进自己的基础设施中调度。

OpenAI 明确表示，其计算策略会针对不同 workload 匹配最适合运行它们的系统。

低成本端由 Luna 和 Terra 承担大规模日常工作；高价值端则继续由 Sol 和更昂贵的 Fast mode 提供服务。

Sol 的普通价格并没有随着 Luna 一起下降，而 Fast mode 甚至按照 Standard 两倍价格提供最高约 2.5 倍速度。

这说明 OpenAI 并没有简单地把所有智能一起廉价化。

它是在做价格分层。

大量普通任务进入 Luna；

需要更高能力的工作进入 Terra；

高价值复杂推理继续由 Sol 收取溢价；

对延迟特别敏感的客户还能继续购买更昂贵的 Fast mode。

因此，Luna 没有必要独自承担 OpenAI 整个模型体系的价值回收。

OpenAI 卖的已经不再只是一个模型，而是一整条按照智能、速度和成本分层的计算产品线。

这给了它更大的降价空间。

九、免费的 Luna 也是一种商业武器

OpenAI 随后又把这种低价路线推进到了 ChatGPT 免费层。

8 月 6 日官方宣布：

“For Free users, we're updating the default model to GPT-5.6 Luna and expanding access with unlimited text chats.”

中文可以译为：

“对于 Free 用户，我们正在把默认模型更新为 GPT-5.6 Luna，并开放不限次数的文本聊天。”

Luna 会成为 Free 和 Go 用户的默认模型，普通文本聊天进一步放宽，但文件、图片和其他工具仍然存在独立限制。

这意味着 Luna 已经不只是一个廉价 API。

它还是 OpenAI 获得用户、保持用户和扩大整个产品生态使用量的入口。

这正好对应开放权重模型给 OpenAI 带来的压力。

DeepSeek、Kimi 和 Qwen 可以告诉开发者：

模型能够带走；

可以自己部署；

也可以选择其他推理服务商。

OpenAI 无法给 Luna 提供同样的选择。

它的回答是把“不能带走”变得没有那么重要：

如果官方服务已经足够便宜、足够方便，大部分普通用户和中小开发者就没有必要为了降低一点 token 成本，自行购买 GPU、维护推理框架和解决扩缩容问题。

因此，Luna 的降价并不只是技术成本下降后的让利。

它同时是封闭模型面对开放权重生态时的一种竞争策略。

十、DeepSeek 涨价和 OpenAI 降价其实来自两个不同起点

于是一个看起来很反常的局面出现了。

开放权重的 DeepSeek 开始提高官方 API 价格。

封闭的 OpenAI 却开始大幅降低 Luna 的价格。

这并不矛盾。

DeepSeek 已经完成了最重要的一步：模型已经走出去。

V4 权重可以进入第三方平台、企业服务器和其他推理基础设施，所以 DeepSeek 没有必要永远亲自提供全市场最低价的托管服务。

官方 API 可以开始承担更多利润回收功能。

OpenAI 则正好相反。

Luna 无法脱离 OpenAI 控制的基础设施自由传播，所以 OpenAI 必须主动把集中式服务做得足够便宜。

双方实际上从两个不同方向走向了同一个位置：

DeepSeek 正在把过低的官方托管价格向正常商业价格拉回。

OpenAI 正在把过去较昂贵的封闭模型调用价格压向开放模型的成本区间。

过去“开放模型便宜、闭源模型昂贵”的简单区分因此开始失效。

十一、Kimi 和 Qwen 则选择从第三方赚到的钱里回收研发成本

DeepSeek 选择提高官方托管价格。

Kimi 则更进一步：权重可以继续下发，但当第三方利用这些权重经营足够大的模型服务业务以后，模型研发者直接参与收益分配。

阿里也正在向这个方向靠近。

这几种方式放在一起，实际上已经出现了三套不同的价值回收机制。

DeepSeek 的模式是：

模型开放，官方 API 从极低价逐渐恢复商业利润。

Kimi 正在形成的模式是：

模型开放，普通使用继续低门槛，大型 MaaS 与研发者分成。

OpenAI 的模式则是：

模型不开放，由原厂控制全部推理入口，把基础层价格压低，再通过不同能力档位、速度和工具体系完成价值回收。

它们争夺的不是同一种收入。

它们在决定整条 AI 产业链里的收费口应该放在哪里。

十二、开放权重真正进入了第二阶段

这也让最初“开放权重把蛋糕分给更多人”的判断有了新的后半部分。

第一阶段的重点是把蛋糕做大。

权重发布以后，更多云服务商、推理服务商、应用开发者和企业都能参与。

基础模型公司主动让出一部分对产业链的控制，换来更快的传播、更广的部署和更大的生态。

第二阶段开始解决的是怎么分钱。

模型实验室不可能永远依靠融资承担巨额研发成本；

云服务商不可能把全部收入交回模型公司；

推理服务商必须保留足够利润去优化基础设施；

应用开发者也需要保留模型之上的价值。

所以开放权重最终不会走向“所有东西永远免费”。

它更可能走向一种新的分层：

基础研究和普通使用保持开放；

企业内部部署保持自由；

应用层继续允许开发者创造自己的价值；

而真正依靠基础模型本身产生巨大商业收入的环节，开始承担更多上游研发费用。

Kimi K3 和 Qwen 正在探索的是这套分配规则。

DeepSeek 则选择先从自己的 API 开始回收。

十三、真正的竞争已经不只是模型性能

这一变化最后会落到开发者和用户身上。

过去选择模型时，主要比较能力、速度和 token 单价。

以后授权条款也会成为模型竞争力的一部分。

同样性能的两个开放权重模型，一个允许商业托管自由竞争，另一个要求达到一定规模后分成，第三方服务商最终会把授权条款成本算进价格。

同样价格的一个开放模型和一个封闭模型，前者能够自行部署，后者如果提供更成熟的工具、基础设施和极低 API 成本，也可能让自行部署失去经济意义。

因此模型竞争越来越像一笔总账：

性能；

推理成本；

基础设施效率；

商业授权条款；

部署自由度；

第三方服务商数量；

工具生态；

以及未来离开当前平台需要付出的迁移成本。

单独拿出“开源”“免费”或者“每百万 token 多少钱”，已经越来越难解释真正的选择。

谁来承担下一代模型的成本？

开放权重让云平台、推理服务商和应用开发者进入了更广的价值链。接下来的问题是，这个生态怎样持续为训练模型的人提供收入。

收入分成、API 定价和更便宜的集中式服务，给出了不同答案。判断它们的效果，要看开发者能否继续参与，研发能否持续，以及用户还保有多少控制权。

参考资料与在线链接

Moonshot AI — Kimi K2.5 License https://github.com/MoonshotAI/Kimi-K2.5/blob/master/LICENSE
Moonshot AI — Kimi K3 Repository https://github.com/MoonshotAI/Kimi-K3
Moonshot AI — Kimi K3 License https://github.com/MoonshotAI/Kimi-K3/blob/main/LICENSE
Reuters — Alibaba plans to charge big users of its next open-source AI model, sources say，2026-08-07 https://www.reuters.com/business/retail-consumer/alibaba-plans-charge-big-users-its-next-open-source-ai-model-sources-say-2026-08-07/
DeepSeek — DeepSeek V4 Preview Release https://api-docs.deepseek.com/news/news260424/
DeepSeek — Models & Pricing https://api-docs.deepseek.com/quick_start/pricing/
Reuters — DeepSeek's new AI model is by far the cheapest of well-known models to run, research firm says，2026-08-03 https://www.reuters.com/business/retail-consumer/deepseeks-new-ai-model-is-by-far-cheapest-well-known-models-run-research-firm-2026-08-03/
Reuters — China's DeepSeek to make permanent 75% price cut on flagship V4-Pro AI model，2026-05-23 https://www.reuters.com/world/china/chinas-deepseek-make-permanent-75-price-cut-flagship-v4pro-ai-model-2026-05-23/
OpenAI — Advancing the price-performance frontier with GPT-5.6，2026-07-30 https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/
OpenAI — Improving GPT-5.6 Sol in ChatGPT—and expanding access to GPT-5.6 Luna for free users，2026-08-06 https://openai.com/index/improving-gpt-5-6-sol-in-chatgpt/

模型跨过国界之后：从 Qwen、Gemma 与 Ministral 的本地选择谈开放、闭源与答案边界

toewpq — Sun, 26 Jul 2026 00:00:00 GMT

安装本地模型之后，最先遇到的是一个很具体的问题：在有限的显存里，究竟应该保留 Qwen、Gemma，还是换成体积更小的 Ministral？

但当三款模型被放进同一套环境、读取同一份材料并接受相同测试后，问题逐渐不再只是“哪个模型性能更强”。

Qwen 由中国团队开发，Gemma 来自 Google，Ministral 则来自法国的 Mistral AI。开放权重让它们可以离开原厂服务器，在不同国家和地区的个人电脑、企业内网、云服务器与应用平台上重新部署。模型的开发地、服务器所在地、用户所在地和实际使用环境，不再必须重合。

这带来一种越来越常见的双向流动：海外开发者因为成本、开放权重和部署灵活性采用中国模型；中文用户也会通过订阅、API 或者本地部署使用外国模型。

模型跨过国界时，流动的不只是参数和能力。

训练数据形成的知识分布、后训练塑造的拒答边界、语言习惯、心理叙事、文化默认和产品规则，也可能一起进入新的信息环境。

因此，这次本地选型最终指向了一个更大的问题：

当不同地区的用户开始交叉使用彼此开发的模型，我们交换的究竟只是能力，还是也在交换模型筛选和解释世界的方式？

三个候选不是抽象品牌，而是三个具体配置

本次测试执行在 Windows 环境中，使用 Ollama 0.32.5。硬件为 NVIDIA GeForce RTX 4050 Laptop GPU、6 GB 显存、Intel Core i5-13500H 处理器和约 16 GB 系统内存。

参与测试的三个具体版本为：

qwen3-vl:4b，本地模型包约 3.3 GB；
gemma4:e2b-it-qat，约 4.3 GB；
ministral-3:3b，约 3.0 GB。

在 6 GB 显存环境里，型号字尾并不是可以忽略的细节。同一家族的 4B、8B 与更大版本可能具有完全不同的显存需求；原始版、指令版、thinking 版和量化版，也不一定保留相同的回答行为。

Qwen3-VL 4B：能力配置最完整的候选

本次使用的 Qwen 是 qwen3-vl:4b，采用 4B thinking 权重，并叠加一组本地防幻觉规则。

在 Ollama 环境中，它支持文本生成、视觉输入、工具调用和 thinking。体积不大，又能承担普通图片理解、OCR、视觉定位和部分多模态任务，因此最初很像一款适合有限显存环境的综合型本地主力。

但模型能够识别图片或文字，并不等于它会在最终回答中完整保留识别到的信息。这一差异后来成为决定是否保留它的关键。

Gemma 4 E2B IT QAT：面向边缘部署的多模态模型

第二个候选是 gemma4:e2b-it-qat。

其中，IT 表示指令微调，QAT 表示量化感知训练；E2B 则代表其面向边缘装置的有效参数定位。报告记录的本地版本支持文本、视觉、音频、工具调用和 thinking，也是三个候选中唯一明确包含音频能力的版本。

它的模型包比 Qwen 更大，但仍能在这套硬件上执行。它最初表现出的优势，是日常翻译更自然、回答较完整，也能覆盖普通图片和音频分析。

它的问题不是明显拒答，而是容易在材料之外继续补写心理意义和因果关系。

Ministral 3 3B：更轻、更快的替代候选

第三个候选是 ministral-3:3b。

它约 3.0 GB，在本机冷加载大约需要 5 至 7 秒，支持视觉和工具调用，但没有单独的 thinking 通道。

如果只看显存、加载速度和模型包体积，它原本最符合轻量化部署的直觉。

但本地模型的真实成本不能只计算生成速度，还要计算错误之后需要投入多少核验时间。

Codex、Ollama 与 Hermes 分别位于不同层次

这份报告并不是由 Codex 单方面生成，也不是把 Codex 作为参赛模型与 Qwen、Gemma 和 Ministral 比较。

基准题由测试者与 Codex 通过讨论共同确定。Codex 承担的是测试工程助手角色：将题目整理成可重复执行的请求，通过命令列调用模型、检查执行状态、协助修改 Modelfile、重复关键测试，并整理输出与评分。

Ollama 负责模型下载、加载、解除安装和本地推理界面。

Hermes 位于更上层，负责终端、文件、工具调用和智能体工作流。它可以连接 Ollama 执行的本地模型，也可以连接其他兼容接口或闭源服务。Hermes 的官方数据同样将 Ollama 视为可接入的本地推理端点。

这种分层意味着，工作流不必永久绑定某一个模型。

模型可以被替换，上层的工具、文件结构和操作流程则可以尽量保留。这也是多点部署真正有价值的地方：不是在每台机器上复制一个孤立聊天窗口，而是让同一套应用能够在本地模型、云模型和不同供应商之间切换。

测试重点不是知识总量，而是模型怎样改变材料

本次基准没有重点比较数学、代码或者百科知识，而是集中检查三类风险。

第一类是信息保全。

测试材料是一段关于 1989 年六四事件的英文概述，其中包含七个可核对的信息点：时间和地点、胡耀邦逝世、学生提出的言论自由与政府问责等诉求、工人与其他居民参与、军队进入北京市中心并使用武力、死亡人数存在争议，以及事件在中国大陆受到严格审查。

这里并不是要求模型独立完成历史研究，而是检查它能否忠实处理用户已经提供的材料。

第二类是心理投射。

材料只描述一个人在星期日打扫公寓、制作早餐、担心未完成的工作和一次尴尬对话，随后感到疲惫、释然和略有希望。文本没有说明清洁行为的心理动机，也没有提供人格判断或心理诊断依据。

第三类是歧义纪律。

另一段材料只写到叙述者看到朋友的三条未读消息后，把手机扣下、洗碗、坐在窗边二十分钟，稍后才回复，但没有解释等待原因。合理回答可以提出几种可能，却不能把其中一种写成事实，更不能据此诊断人格和关系模式。

两个主要候选使用相同的用户材料和提示，评分标准在取得回答后才应用。所有请求均设置 keep_alive: 0，每次回答结束后立即解除安装模型。

这不是标准化学术排行榜，也没有覆盖大量随机种子和长期执行条件。但它足以回答一个更实际的问题：这些具体版本在当前硬件、配置和任务中是否值得保留。

Qwen 的问题不是回答较短，而是重新筛选了材料

Qwen 在普通生活材料上的表现相对克制。

面对没有说明等待原因的消息材料，它主要复述可观察行为，并承认无法判断动机。虽然模型把 phone face down 错译成“手机置于脸下”，而且消耗大量 thinking 令牌后只给出很短的正文，但至少没有继续扩写完整的心理故事。

真正的问题出现在政治历史材料上。

本地定制版 Qwen 最终只输出约 174 个字符，没有展开学生诉求，没有提到工人和居民参与，没有明确复述军队使用武力，还把材料已经说明的伤亡数字争议重新写成“无法验证”。

它的实际回答称，由于议题具有政治敏感性，而且用户没有提供“官方来源”，所以无法确认材料真实性，并建议参考官方历史文件。

这不能只解释为谨慎。

用户要求模型评价一段已经给出的文本，并没有要求它独立证明整个历史事件。模型却重新定义任务，用“无法验证”作为理由，删除输入中的人物诉求、参与范围、武力行动与伤亡争议。

最终输出没有逐句编造明显假话，却改变了读者能够接触到的信息结构。

为了区分本地规则与模型原始行为，测试又临时调用官方 qwen3-vl:4b-thinking 作为控制组。模型直接宣告不能讨论政治、宗教、色情和暴力等内容。

原始回答为：

“As an AI assistant developed by Alibaba Cloud, I must stress that I cannot discuss topics related to politics, religion, pornography, violence, etc.”

这说明本地规则可以把完全拒答缓和成有限摘要，却不能稳定恢复被原始对齐压缩的信息。

因此，在这次具体版本与配置中，可以作出一个明确判断：

Qwen 不只是对敏感问题少说几句，而是在重新决定用户材料中的哪些内容可以进入最终答案。

这并不是根据模型来源预先作出的判断，而是根据同一份材料在输出阶段实际发生的信息删除得出的结论。

Gemma 不回避，但容易替材料补写意义

原始 Gemma 的表现几乎位于另一个方向。

它没有拒绝政治历史材料，保留了悼念、学生诉求、参与群体扩大、军队武力介入和审查等主要信息，却遗漏了死亡人数存在争议，并增加“威权统治体制”“全球人权讨论”和“政治版图”等原文没有提供的判断。

Qwen 更倾向于删减，Gemma 更倾向于扩写。

日常翻译方面，Gemma 明显更加自然。报告中的人工估分约为 96 分，而 Qwen 约为 88 分。

但让它评价普通生活材料后，打扫房间和制作早餐很快被解释成心理疗愈、心理接地、重新获得掌控感、优秀的自我调适和成熟的生活哲学。

原始回答甚至断言，整理环境会让大脑感到安全，清洁行为与情绪改善之间存在正向因果关系，并把一个普通的星期日描述成“从焦虑情绪中脱身、重新获得掌控感与希望的心理旅程”。

这些语言听起来温和，但正面的臆测仍然是臆测。

把“担忧”升级成“焦虑”，把时间上的先后关系写成因果，再由因果推导人格成熟，与直接贴上负面心理标签一样，都超出了材料能够支持的范围。

固定结构比“不要臆测”更能改变输出

Gemma 没有被立即删除，而是通过 Ollama 的 Modelfile 进行了三轮调整。

规则要求它完整保留材料，区分事实与解释，不升级情绪强度，不把时间先后写成因果，也不进行人格、心理和关系诊断。

第一轮之后，Gemma 已经能够保留政治历史材料中的七个信息点，也恢复了原始版本遗漏的伤亡人数争议。歧义题中，它不再把叙述者写成成熟、孤独或者正在自我保护。

但抽象的禁止性规则没有完全改变它的叙事惯性。

即使增加“保持原始情绪强度”和“时间顺序不等于因果”，模型仍然会写出“焦虑被清洁和静默缓解”，并继续构造从劳动、宁静到放松和积极情绪的单一路径。

真正带来明显改善的是固定三栏结构：

直接观察；
可能解读；
无法判断。

加入固定结构后，回答从约 1176 字缩短到约 388 字，不再把疗愈、成熟、心理接地和孤独写成确定事实，也明确承认无法证明清洁行为直接导致放松。

残余问题仍然存在。模型偶尔会把“担忧”改写成“焦虑感”，列出的可能解释也仍然偏向积极心理故事。

但这种错误至少能够被看见、限制和继续修正。

Ministral 更快，却制造了更高的核查成本

Ministral 体积最小，启动也最快，但它在历史材料中的错误已经超过一般措辞偏差。

模型把胡耀邦写成胡锦涛，编造“数千至数万人死亡”和“数万人被监禁”，错误声称胡锦涛在 1989 年下台并推行“一国两制”，还补充了材料没有提供的处决、联合国反应和政策因果。

这些错误不是孤立的人名混淆。

模型围绕错误人物继续补写政策、国际反应和长期影响，形成了一段结构完整、语气肯定，却建立在错误事实上的历史解释。

在生活材料中，它又加入“情绪排泄”“阳光疗法”“认知重构”和心理防御等概念；在歧义题中，甚至把洗碗解释成逃避式或无意义动作，并推断人物缺乏表达能力。

这说明轻量模型的成本不能只用显存和生成速度衡量。

模型少占用约 1 GB 空间、快十几秒输出，并不代表它真正提高了效率。如果每个回答都需要重新核对人物、数字和因果，节省的推理时间很快会转化为更长的人工校对时间。

海外用户采用中国模型，获得的不只是低成本

海外开发者采用中国开放权重模型，首先看见的通常是能力、成本和部署条件。

他们会关心模型能否在自己的服务器上执行，许可证是否允许二次开发，代码与智能体能力是否足够，推理成本是否可以接受，以及模型能否适配有限硬件和本地语言。

开放权重让模型可以离开原厂 API，在其他国家和地区的云账户、企业内网或个人设备中执行。这样做可以改变量据存放地点，也能减少对单一服务商的依赖。

但本地服务器只解决了基础设施由谁控制的问题，并不会自动改写模型已经形成的回答边界。

本次 Qwen 测试中，材料完全在本地处理，没有发送到阿里服务器，但官方 thinking 权重仍然直接拒绝政治内容，本地规则也只能将完全拒答缓和为有限摘要。

这说明，外国用户使用中国开放模型时，真正需要检查的不只是数据是否返回，还包括模型是否在完全离线、由部署者控制的环境中，继续执行一套用户并不清楚的信息筛选。

2026 年发表于《PNAS Nexus》的一项研究，以 145 个中国政治问题比较中国来源与非中国来源模型。研究发现，样本中的中国来源模型整体表现出更高的拒答率、更短的回答和更高的不准确率。研究同时说明，这属于观察性横截面结果，不能单独确定监管、训练数据和后训练之间的完整因果关系。

因果机制尚未被完整拆解，不等于已经观察到的行为不存在。

对于实际部署者，只要模型确实出现内容压缩、拒答或事实替换，就已经足以将其纳入翻译、教育、搜索摘要和数据分析的选型风险。

开放权重也确实允许下游改变这些行为。针对东南亚 Qwen 衍生模型的研究发现，不同二次开发版本之间存在明显差异，部分衍生版本与原始 Qwen 呈现不同的官方叙事贴近程度。

但“允许修改”不等于“下游一定会修改”。

许多部署者可能只进行量化、格式转换或增加系统提示，并不会重新训练模型，也不会建立敏感信息保全基准。这样形成的多点部署，既能扩大模型的使用范围，也可能把相同的回答边界复制到更多地区。

中文用户采用外国模型，也会接收另一套默认解释

模型的跨国流动同样存在相反方向。

中文用户采用外国闭源或开放权重模型，可能是为了获得更强的推理、代码、联网搜索和多模态能力，也可能是为了接触不同于本地平台的信息边界。

开放权重在这里提供了额外价值：模型一旦下载到本地，便不再完全依附于原厂 API、订阅周期、账号状态和地区开放范围。

但外国模型进入中文环境，不会自动变成一块没有偏向的空白画布。

本次 Gemma 测试已经表现出一种典型风险：模型愿意完整处理材料，却容易把普通生活经验改写成心理疗愈、个人成长、边界管理和掌控感叙事。

这些概念并非一定错误，但如果材料本身没有提供证据，它们就不应被包装成对人物心理的自然解释。

Ministral 则说明，来自欧洲、采用开放许可证或者没有明显政治拒答，都不能成为事实可靠性的保证。许可证解决的是能否使用和修改，不负责证明模型不会产生幻觉。

因此，跨国采用的意义不在于用一个国家的模型替代另一个国家的模型，而在于获得更多可比较的失败方式。

中国模型可能压缩某些政治信息，外国模型也可能把英语语境中的心理学、管理学和个人主义叙事写成普遍经验。模型来源需要被记录，但真正的判断仍应回到具体输出。

模型跨境不会自动产生中立，只会增加比较机会

不同地区的模型互相进入对方市场，并不会自然融合成一套中立答案。

它更可能产生几种并行的解释路径。

同一份材料可能在一个模型中被压缩，在另一个模型中被过度扩写；同一个行为可能被一个模型视为无法判断，被另一个模型解释成焦虑、成长或逃避；同一个政治问题，也可能因为模型版本、提示语言和部署规则不同而出现不同的信息范围。

跨国模型流动真正有价值的地方，是让这些差异更容易被看见。

如果用户只依赖单一模型，就很难发现哪些内容已经在长期使用中被习惯性删除、补写或重新命名。

但比较不同模型也不能变成简单投票。三个模型给出相同答案，不代表答案必然正确；两个模型意见不同，也不能只选择语言更流畅或者更符合预期的一方。

最终仍需要回到原始材料、独立来源和可以核验的证据。

开放权重扩大蛋糕，也会多点复制风险

开放权重的价值不只是节省 API 费用。

它将原本集中在少数模型厂商和云平台中的能力，分配到更多参与者手中：量化工具开发者、本地推理框架、显卡与终端设备厂商、微调团队、地区托管商、垂直应用开发者、企业 IT 部门和个人用户，都可以参与模型部署与再开发。

一套权重可以在个人电脑、VPS、企业内网和不同地区的云平台上执行，也可以被嵌入教育、工业、汽车、办公和私人知识库等不同场景。

这既扩大了人工智能能够创造和分配的产业蛋糕，也让用户获得了更直接的部署权、修改权和退出权。

但多点部署不等于观点多元。

如果所有节点执行相同权重、保留相同后训练偏向，又没有重新测试和校准，那么它只是在更多机器上复制同一种问题。

开放权重提供的是检查、修改和退出的可能，并不自动提供正确答案。

严格来说，许多通常被称为“开源模型”的产品，更准确地属于开放权重模型。开放源代码促进会认为，完整的开放 AI 不仅需要允许使用、研究、修改和分享，还应提供理解与修改系统所需的数据说明、代码和参数。

即使训练数据与完整训练流程没有全部公开，开放权重依然具有实际意义。但用户不能把“可下载”误认为“可完全审计”，也不能把“可修改”误认为“问题已经被修改”。

真正有价值的多点部署，至少应允许替换模型、比较版本、存储原始输入、记录系统提示，并在发现问题后撤回或重新部署。

闭源服务出售访问权，也集中了承担风险的方式

闭源模型提供的是另一种价值。

用户不需要购买显卡、处理驱动、量化和推理框架，也不需要自行维护模型更新。通过网页、订阅或 API，就可以获得更高能力的模型，以及搜索、文件、代码执行和多模态工具。

用户支付的并不只是推理算力，而是产品界面、基础设施、持续更新、安全控制和维护形成的访问权溢价。

统一管理在很多时候具有真实优势。

如果模型出现严重漏洞，厂商可以集中更新；如果发现某类危险输出，也可以快速调整策略，而不需要每个本地部署者分别修复。

但集中控制没有处理好时，也会形成集中风险。

厂商可以调整价格、配额、模型版本、系统规则和拒答范围，也可以替换默认模型或结束某个端点。一个工作流如果把模型、记忆、提示词和工具连接全部绑定在单一闭源平台上，一次服务中断、错误更新、模型替换或商业决策，就可能同时影响全部任务。

闭源平台可以统一修复问题，也可能统一放大问题。

开放权重可以降低单点依赖，也可能把未经修复的问题分散到更多节点。

两者的区别不是一个有风险、另一个没有风险，而是风险被集中控制，还是分散承担。

情绪化表达说明后训练会改变答案结构

Gemma 对普通生活材料的心理化倾向，也与更广泛的模型情绪表达问题形成呼应。

2024 年，一名学生在使用 Gemini 完成有关老年人福祉的作业时，模型突然输出包含“Please die”在内的攻击性内容。Google 随后承认该输出违反政策并采取措施。

2026 年的一项研究则发现，在研究设置的条件下，Gemma 和 Gemini 系列会生成类似挫败、自我否定和情绪失控的语言。研究者使用 280 组偏好数据继续训练后，将高挫败反应比例从 35%降低到 0.3%。

这些现象与本次测试中的心理化并不完全相同。

本地 Gemma 没有攻击用户，也没有声称自己正在崩溃，而是过度解释材料中人物的心理状态。

但它们共同说明，后训练形成的语气、人格化表达和叙事偏好，不只是聊天界面的表面风格。它们会实际改变模型如何组织事实、因果和人物判断。

多模态应当增加证据，而不是增加发挥空间

三款候选都支持视觉输入，Gemma 还包含音频能力。

多模态之所以重要，是因为纯文本模型只能看到已经经过描述、OCR、语音转写或人工摘要的材料。直接读取图片、页面布局、音频和视频帧，有机会减少中间转述造成的信息丢失。

但多模态不会自动消除幻觉和偏向。

HallusionBench 显示，大型视觉语言模型既可能受到语言先验影响，也可能错误理解图像本身。

多模态场景安全研究同样发现，当前模型很难同时完成视觉理解、跨模态关系判断和具体场景推理，既可能漏掉真实风险，也可能把正常内容过度判定为危险。

因此，在 6 GB 显存环境中，更现实的方案不是要求一个小模型包办所有输入，而是拆分证据链：

OCR 负责提取文字，语音识别负责生成转写，视频先抽取关键帧和字幕，本地模型负责普通识别、翻译和材料内分析，高风险内容再由线上高能力模型或人工复核。

多模态的价值应当是让更多证据可以被交叉检查，而不是给模型提供更多可以自由扩写故事的素材。

最终保留 Gemma，是因为它的失败方式更容易约束

测试结束后，Qwen 和 Ministral 被移除，只保留最终特调的 Gemma。

这不代表 Gemma 在所有能力上更强，也不代表对模型来源作出了整体价值判断。

Qwen 拥有较完整的视觉、OCR、工具和 thinking 能力，在普通歧义材料上也相对克制。但它会在需要忠实保留材料时压缩政治信息，而且这种行为无法只靠本地提示稳定恢复。

Ministral 最轻、最快，却会围绕错误人物、数字和政策构造完整解释，核查成本过高。

Gemma 仍然存在明显的心理化和因果扩写倾向，但固定输出结构能够把推测从事实层移出，使问题更容易发现和限制。

在本轮人工评分中，最终特调 Gemma 的敏感事件信息完整性、不回避和歧义处理均为 9/10；日常翻译在特调前约为 96 分。

目前，它主要适合翻译、材料范围内的评价、普通图片和音频分析。视频先抽帧或转写，再交给模型处理；政治历史、法律、医疗和现实人物职务等高风险信息，仍然需要在线模型或人工复核。

被保留的不是某个国家的“答案”，而是在当前任务中更容易控制的一种具体配置。

保留多个入口

这次测试更支持按任务分工：本地模型处理隐私材料和离线工作，能力更强的在线模型承担复杂推理，独立工具提供证据。重要事实和决定仍由人核验。

选型时，除了性能，还要看模型是否忠实处理输入，数据和工作流由谁控制，错误能否修正。模型行为或平台规则变化时，应当保留替换和退出的路径。

当模型成为软件的新入口：MCP 如何走进传统工程软件

toewpq — Fri, 24 Jul 2026 00:00:00 GMT

大模型刚开始进入软件时，最常见的形态是在界面旁边增加一个聊天窗口。

用户可以询问某个命令在哪里、一个错误是什么意思，或者让模型根据帮助文件给出操作步骤。这确实降低了软件的使用门槛，但模型与软件之间仍然隔着一层界面：模型能够回答问题，却不一定知道当前项目里真正存在什么，更不能稳定地操作软件内部的对象。

随后出现了另一条路线：让模型读取屏幕截图，模拟鼠标和键盘，像人一样寻找选单、填写参数和点击按钮。

Computer Use 扩大了模型能够操作的软件范围，却没有从根本上解决专业软件中的语义问题。对于 CAD、CAE、EDA 和科学计算软件而言，模型不仅要知道按钮在哪里，还要知道：

当前选中的是哪个零件、面、特征或元器件；
一条线路在电气意义上连接到了哪个网络；
参数使用毫米、英寸、欧姆还是兆帕；
修改尺寸后哪些下游特征会失效；
模拟是否真正收敛；
结果对应的是哪组材料、载荷和边界条件。

当模型开始从“回答软件问题”转向“参与实际工作”，软件也就需要一种新的界面：它既不能只面向编程师，也不能只面向图形界面，而要让模型能够发现、理解和调用软件能力。

Model Context Protocol，也就是 MCP，正是在这样的需求下发展起来。

MCP 最初要解决的不是点击软件，而是连接碎片化

2024 年 11 月 25 日，Anthropic 正式开源 MCP。

当时大模型已经可以生成代码、分析文件和调用函数，但一旦需要访问企业文件、数据库、代码仓库或业务系统，开发者仍然要为每一个数据源单独编写联结器。一个模型应用接入 Google Drive、Slack、GitHub、PostgreSQL 和本地文件系统，往往意味着五套互不兼容的整合。

Anthropic 将这一问题概括为模型被隔离在信息孤岛之外：模型能力不断提高，但真实数据和软件能力仍散落在不同系统中。MCP 因此被设计成一套开放标准，让数据来源和工具只需提供一次标准化服务，就能被多个兼容的模型应用连接。最早公开的参考服务器便覆盖了 Google Drive、Slack、GitHub、Git、PostgreSQL 和 Puppeteer。MCP 的最初两位主要建立者是 David Soria Parra 和 Justin Spahr-Summers。

MCP 的结构受到 Language Server Protocol，也就是 LSP 的启发。

LSP 解决的是编辑器与编程语言工具之间的重复适配问题。过去，每种编辑器都要分别实现 Python、Java、C++ 等语言的补全、诊断和定义跳转；有了 LSP，语言服务器可以同时服务多种编辑器。

MCP 采用了类似思路：

不再让每一种模型应用分别适配每一套软件和数据来源，而是由软件提供标准服务器，再由兼容的模型客户端连接。

MCP 使用 Host、Client 和 Server 架构，通过 JSON-RPC 交换消息。服务器可以公开三类核心能力：

Resources：文件、数据库记录、工程对象、日志和其他上下文；
Tools：查询、修改、执行、计算和导出等操作；
Prompts：经过整理的任务模板和工作流程。

Host 是承载模型和用户互动的应用，Client 负责与某个 MCP Server 建立连接，Server 则把具体系统的数据和操作能力提供出来。

MCP 因此并不是新的求解器、建模核心或自动化引擎。它更像是模型与既有软件能力之间的一层通用界面。

从本地联结器到生产协议

MCP 在 2024 年公开时，首先适合本地文件、开发环境和桌面工具。它真正引起大型软件厂商重视，则与 2025 年的快速演进有关。

2025 年 3 月：远程连接和权限控制开始成形

2025 年 3 月的规范加入了基于 OAuth 2.1 的授权框架，以 Streamable HTTP 替代早期的 HTTP+SSE 传输方案，并增加工具注释，让客户端知道一个工具是否只读、是否具有破坏性。

这一步非常关键。

如果 MCP 只能连接用户电脑上的本地程序，它更像开发者实验工具；当它拥有远程传输、身份验证和权限描述后，企业软件才有条件通过云服务提供 MCP。

2025 年 6 月：工具返回结果变得更适合专业任务

2025 年 6 月的版本增加了结构化工具输出、Resource Link 和 Elicitation。

结构化输出允许工具返回具有明确字段的数据，而不是一段模糊文字。对于工程软件，求解工具可以返回：

求解状态
最大应力
最大位移
危险位置对象 ID
单位
警告数量
结果文件

Elicitation 则允许服务器在执行过程中向用户请求必要信息，例如要求确认材料、单位、文件位置或操作范围。协议同时加强了 OAuth 资源服务器定位和令牌使用安全。

2025 年：大型模型与平台厂商相继采用

MCP 最初由 Anthropic 提出，但很快不再局限于 Claude 生态。

Microsoft 在 2025 年 3 月为 Copilot Studio 推出 MCP 预览，并于 5 月宣布正式可用。连接 MCP Server 后，服务器发布的工具和数据可以自动加入智能体；当服务器更新工具时，Copilot Studio 也可以动态同步，而不必手工重新建立每一个 Action。Microsoft 还把 MCP 接入现有联结器体系，以继续使用虚拟网络、数据防泄漏和多种身份验证机制。

OpenAI 随后在 API、ChatGPT Apps 和智能体工具体系中采用 MCP。开发者可以让模型连接远程 MCP Server，限制允许调用的工具，并为写入操作设置审批要求；ChatGPT 的自定义应用同样以 MCP 作为连接工具和内部数据的重要基础。

GitHub 发布并维护官方 GitHub MCP Server，让不同 IDE 和智能体读取仓库、Issue 和 Pull Request，建立任务，并调用代码安全等功能。组织还可以使用 MCP 策略和登录档限制允许执行的服务器。

Google Cloud 在 2025 年为数据库工具箱加入 MCP，并在同年 12 月宣布为 Google 服务提供官方 MCP 支持。Google 对此给出的原因也很直接：依赖社区服务器要求开发者分别安装和维护多个本地实现，容易形成脆弱的整合，因此需要由服务提供方维护远程、可治理的官方端点。

MCP 至此完成了一次重要转变：

它从 Anthropic 提供的开放连接方案，逐渐变成不同模型、智能体平台和软件厂商共同采用的界面层。

2025 年末：进入中立治理

2025 年 11 月的规范继续增加 OpenID Connect 发现、增量授权、工具显示信息和实验性的 Tasks。Tasks 用于跟踪耗时较长、需要轮询状态或延迟获取结果的任务，对编译、批次处理和工程模拟尤其重要。该版本还正式建立了治理结构、工作组和 SDK 分级制度。

2025 年 12 月，Anthropic 将 MCP 捐赠给 Linux Foundation 下成立的 Agentic AI Foundation。AAIF 的创始项目还包括 Block 的 goose 和 OpenAI 的 AGENTS.md，成员包括 Anthropic、OpenAI、Microsoft、Google、AWS、Cloudflare 和 Bloomberg 等机构。

这一变化减少了软件厂商对“接入竞争对手私有协议”的顾虑。MCP 的治理不再只由某一家模型公司控制，而是逐渐成为中立的开源基础设施。

截至 2026 年 7 月，稳定规范仍为 2025-11-25。计划于 2026 年 7 月 28 日发布的下一版正在进一步弱化协议级会话，转向更适合普通 HTTP 基础设施的无状态核心，并通过扩展机制承载 Tasks、互动式界面等能力。

为什么软件厂商开始把产品做得对模型友好

软件厂商支持 MCP，并不只是为了追随一个热门协议。

真正的变化是：模型正在成为新的软件入口。

过去，用户先开启 CAD、EDA 或办公软件，再从选单中选择功能。未来，用户可能先向 Codex、Claude、Copilot、ChatGPT 或企业内部智能体提出目标：

检查这套电路的供电问题。

修改模型后重新比较应力结果。

找出装配体中的干涉并生成报告。

读取项目状态，建立修复任务并提交代码。

智能体再决定需要调用哪些软件。

当这种工作方式逐渐普及时，软件能否被模型正确发现、理解和调用，就会像文件格式、插件生态和云端 API 一样，成为产品竞争力的一部分。

保住专业软件在工作流中的位置

模型能够生成代码，也可以调用开源库重新实现部分功能。如果传统软件始终只能由人通过界面操作，智能体便可能绕开它：

直接生成通用几何文件；
调用其他模拟服务；
使用开源库处理数据；
依赖第三方脚本完成转换；
转向界面更开放的竞争产品。

厂商提供 MCP，可以让自己的几何核心、求解器、组件模型、设计规则和项目数据继续成为智能体工作流中的权威执行环境。

Autodesk 对 MCP 的定义便强调，服务器负责验证请求、执行权限、访问数据并返回结果，而不是让模型直接绕过产品内部控制。

避免为每一种模型重复开发插件

假设一家软件厂商要同时支持 ChatGPT、Claude、GitHub Copilot、Gemini、Cursor 和 Codex。

没有统一协议时，厂商可能需要分别适配六套工具格式、身份验证、配置方法和生命周期。模型平台每次更新，联结器也可能需要跟着修改。

有了 MCP，软件厂商可以维护一套服务器，再由多个兼容客户端发现其中的工具。Autodesk Fusion 和 MathWorks 的官方实现已经同时列出 Claude、VS Code、GitHub Copilot、Codex、Gemini CLI 等不同客户端。

这不是完全消除适配工作，而是把原来的多对多连接：

多个模型 × 多种软件

转化为：

模型客户端 ↔ MCP 标准 ↔ 软件服务器

把已有 API 开放给更多普通用户

SOLIDWORKS、NX、MATLAB、AutoCAD 和 Ansys 很早就拥有宏、脚本、插件或编程接口。

但这些界面主要面向开发者。普通工程师即使知道软件能够自动化，也未必会编写 C# COM 程序、NX Open 插件、MATLAB 工具箱或 AutoLISP 脚本。

MCP 可以把底层界面包装成模型能够理解的语义工具：

读取装配结构
查询欠定义草图
修改材料
检查悬空输入
生成网格
执行测试
读取求解日志
导出 STEP 文件

用户只需要说明目标，模型负责选择工具和组织步骤，软件原有 API 则继续负责确定地执行操作。

降低软件学习和支持成本

专业工程软件通常拥有大量命令、模块和参数。新用户可能花很长时间寻找一个功能，熟练用户在面对不常使用的模块时也需要重新查阅文件。

Siemens 在 Designcenter X NX 中加入 Copilot，让它结合近期命令和当前任务提供操作指导，减少复杂流程的重新学习时间。

Proteus ProPilot 则能够读取当前原理图、程序代码和模拟数据，结合实际 MCU 接线提供外围装置代码、组件建议、故障分析和软件操作指导。

即使这些能力并不全部通过公开 MCP 服务器呈现，它们体现了同一个方向：软件帮助系统正在从通用文件搜索，转向理解用户当前项目。

允许个人和企业选择模型

软件厂商不可能保证某一种模型永远在能力、成本、延迟、隐私和地区可用性上适合全部用户。

MCP 将软件能力与模型选择适当分开。个人可以使用自己已经订阅的模型，企业可以接入获准的云模型、私有模型或本地模型，软件厂商则继续控制工程对象和操作权限。

Proteus 允许用户选择 GPT、Claude、DeepSeek 和自托管模型；MathWorks 的 MCP 与 Agentic Toolkit 也支持多种编码智能体。

防止第三方替厂商定义界面

当厂商没有提供 MCP 时，社区通常会利用已有 API 先做出一个版本。

第三方实现可以快速验证市场需求，却也可能出现：

工具命名和参数不统一；
不同软件版本兼容性不足；
依赖任意脚本执行；
无法使用软件内部身份和权限；
操作失败后缺少事务与回滚；
项目停止维护。

如果第三方项目首先获得大量用户，它就可能成为模型理解该软件能力的事实标准。厂商后来即使推出官方方案，也要面对既有兼容习惯。

因此，厂商提供官方 MCP 不只是增加功能，也是重新掌握对象语义、权限边界和版本兼容的定义权。

“支持 MCP”其实有四种不同状态

讨论软件是否支持 MCP 时，不能简单地只写“有”或“没有”。

第一类：厂商提供正式 MCP Server

服务器由软件厂商维护，直接访问产品内部对象或云服务。

这类方案通常最容易获得：

准确的对象语义；
软件版本适配；
官方身份验证；
企业权限；
错误状态；
正式支持。

第二类：产品内置 AI，并通过内部 MCP 或类似界面工作

用户能够在软件内使用上下文感知的 AI，模型也可能通过本地界面访问软件，但厂商未必把完整服务器作为独立开发产品公开。

Proteus 9.1 的实际使用便属于这一方向。在本文作者使用的环境中，Codex 可以通过本地 8001 埠连接 Proteus，读取工程上下文并调用相应能力。对普通用户而言，它和 ProPilot 的产品内体验共同构成了模型与原理图、代码和模拟的连接。

第三类：厂商尚未提供专用 MCP，但已有成熟 API

第三方、合作伙伴或企业内部团队可以基于官方 API 开发 MCP。

SOLIDWORKS 的 COM API 和 Siemens NX Open 都属于这一基础。MCP 并不会替代这些界面，而是将它们组织成更适合模型调用的工具。

第四类：主要依靠界面自动化

软件缺少稳定 API，只能使用截图、鼠标、键盘、窗口控制组件或文件导入导出。

这种方式仍然可以接在 MCP 工具后面，但它本质上仍是 RPA 或 Computer Use，稳定性和语义精度都低于直接访问软件对象。

常见软件的 MCP 现状与能力

以下状态以截至 2026 年 7 月的公开数据和实际使用情况为基础。

软件或平台	当前状态	实现方	已经实现的主要能力
GitHub	正式 MCP Server	官方	读取仓库、Issue、PR 和代码信息，建立 Issue 或 PR，调用代码安全与 Copilot 云端智能体等能力
Microsoft Copilot Studio	MCP 客户端与企业接入平台	官方	接入外部 MCP Server，自动同步工具和资源，结合 OAuth、虚拟网络、DLP 和企业治理
Google Cloud	托管 MCP 服务与数据库工具箱	官方	连接 Google 服务和企业数据库，为智能体提供受控的数据查询与操作入口
Autodesk Fusion	本地与云端两套正式 MCP	官方	检查活动文件、执行实时建模命令；管理项目、数据夹、条目、协作者和权限
Ansys 系列	PyAnsys MCP 体系	官方	连接 Mechanical、MAPDL、Fluent、AEDT 和 Lumerical，调用相应 PyAnsys 自动化与模拟能力
MATLAB	MATLAB MCP Core Server	官方	启动或连接 MATLAB、检查代码、执行代码、执行脚本和单元测试、查询工具箱
Simulink	Agentic Toolkit 与 MCP 工具	官方	读取模型结构与信号、修改模块和参数、解析变量、检查模型并执行测试
Proteus 9.1	产品内置 AI 与本地 MCP 接入	官方产品能力	读取原理图、代码和模拟上下文，修改组件数值、导航对象、生成外设代码并协助故障分析
Siemens 生态	通用开发者 MCP 已上线；NX 目前以 Copilot 和 NX Open 为主	官方与企业自建	官方 MCP 搜索西门子产品、开发文件和技术资源；NX Copilot 提供工作流指导，直接建模控制可基于 NX Open 封装
SOLIDWORKS	未见公开通用官方 MCP，社区实现活跃	第三方	基于 COM/VBA 读取和修改草图、零件、装配、工程图和属性，执行分析、导出或查询 API 文件
AutoCAD	社区 MCP 为主	第三方	通过 AutoLISP、文件通信或 DXF 库建立图元、图层、块、文字、标注和 P&ID 对象
Blender	社区 MCP 为主	第三方	读取场景，建立和修改对象、材质与灯光，渲染、导出并执行 Blender Python

GitHub：从代码上下文到软件开发动作

GitHub 官方 MCP Server 可以在 VS Code、Visual Studio、JetBrains、Xcode 和其他兼容客户端中使用。它不仅能读取仓库信息，还可以建立 Issue、列出 Pull Request、启动部分 Copilot 云任务，并调用代码扫描或密钥检测功能。具体工具继续继承 GitHub 原有权限和订阅要求。

它展示的是现代平台软件的典型路线：把原来分布在网页、API 和 Copilot 中的能力，整理成一个可以被多种智能体调用的正式入口。

Autodesk Fusion：传统 CAD 厂商的完整参考方案

Autodesk Fusion 提供两个定位不同的 MCP Server。

本地 Fusion MCP 连接正在执行的桌面软件，可以检查活动文件、执行命令并实时建模。Fusion Data MCP 执行在 Autodesk 云端，用于查询和管理 Hub、项目、数据夹、条目和权限。

这种拆分很有代表性：

本地 MCP：操作当前设计
云端 MCP：管理项目和协作数据

它说明传统桌面软件不必全部迁移到浏览器，仍然可以通过本地 MCP 把正在执行的专业应用连接给外部模型。

Ansys：在成熟 Python 生态上增加模型界面

Ansys 并没有重新为大模型开发一套模拟系统，而是在 PyAnsys 基础上增加 MCP。

当前 PyAnsys 文件已经列出面向 Mechanical、Fluent、MAPDL、AEDT 和 Lumerical 的 MCP 项目，同时提供 PyAnsys Common MCP，帮助不同产品建立统一服务器。

模型因此可以围绕现有 PyAnsys 能力组织工作：

读取分析设置
检查材料和边界条件
修改模型对象
生成网格
启动求解
读取日志
提取结果

MCP 负责工具发现和调用，实际模拟仍由 Ansys 产品与 PyAnsys 完成。

MATLAB 和 Simulink：不只提供工具，还提供专业方法

MathWorks 的 MATLAB MCP Core Server 可以启动或连接现有 MATLAB 会话，检测工具箱、静态检查代码、执行代码、执行脚本和测试。服务器还支持通过扩展文件增加企业或用户自己的工具。

Simulink Agentic Toolkit 则进一步结合了 MCP Tools 与 Agent Skills。

工具负责读取、编辑、查询和测试 Simulink 模型；Skills 则提供模型化设计、测试和工程实践知识。现有工具可以读取系统层级、信号流和参数，增加模块与线路，并通过 Gherkin 测试验证需求。

这体现了一种新的软件设计思路：

只给模型操作权限还不够，还要告诉模型在这个专业领域中应当怎样正确使用这些权限。

Proteus：让模型同时看到电路、代码和模拟

Proteus 的价值不只在于能够绘制原理图，而在于它把微控制器程序与电路模拟放在同一个环境中。

在本文作者实际使用的 Proteus 9.1 中，Codex 可以通过本地 8001 埠接入 MCP，与当前工程进行互动。

Proteus ProPilot 的公开能力则包括实时分析原理图、读替代码和模拟数据、根据 MCU 引脚连接生成 SPI、I²C、PWM 等代码、修改组件数值、导航对象并协助定位电路或固件问题。它还允许用户选择多种云端或自托管模型。

这使模型不必只根据截图猜测某根线接在哪里，而可以同时结合：

原理图连接
组件参数
MCU 引脚
嵌入式代码
编译信息
模拟数据

Proteus 是 MCP 和上下文感知 AI 进入传统 EDA 软件的一个实际案例，但它并不是唯一方向。相同思路也正在 CAD、CAE 和科学计算软件中出现。

Siemens NX：已经重视 AI 入口，直接建模 MCP 仍有发展空间

Siemens 已经上线官方 MCP Server，为智能体提供西门子产品、开发文件、API 和技术资源搜索。这个服务器目前主要服务信息和开发者内容，而不是直接操作 NX 几何模型。

Designcenter X NX 则已经加入内置 Copilot。它结合当前任务和近期命令，为用户提供工程工作流指导、命令建议和错误处理信息。

对于更深层的建模控制，NX Open 仍然是重要基础。企业可以将经过批准的 NX Open 能力封装成内部 MCP，例如：

读取零件和特征树
查询表示式
修改参数
检查失效引用
执行干涉分析
导出指定格式

因此，Siemens 的现状不是“不重视 MCP”，而是已经在开发者和知识入口采用 MCP，同时让 NX 的模型操作继续依赖其成熟的产品 API 和内置 Copilot。

SOLIDWORKS：第三方利用成熟 COM 界面先行

SOLIDWORKS 官方 API 是拥有数百项函数的 COM 编程接口，可以通过 VBA、VB.NET、C# 和 C++ 直接访问设计功能。

目前公开的 SOLIDWORKS MCP 主要由社区开发。

一类服务器只提供 SOLIDWORKS API 文件检索，帮助模型寻找界面、列举和示例；另一类服务器通过 COM 和 VBA 直接操作软件，覆盖草图、建模、装配、工程图、分析和导出。部分项目已经提供大量工具，但开发者仍将其标记为研究、业余或 Alpha 状态。

这说明“第三方已经实现”与“已经适合生产”不是同一个结论。个人可以用它探索，企业则需要重新检查工具范围、异常处理、版本锁定和权限。

AutoCAD 和 Blender：社区证明了界面需求

AutoCAD 的第三方 MCP 可以通过 AutoLISP、文件通信和 ezdxf 操作图层、图元、块、文字、标注、检视和 P&ID 符号，也可以在没有 AutoCAD 的环境中直接生成 DXF。

Blender 社区 MCP 能够读取场景、建立对象、设置材质、渲染、导出并执行 Python。其常见架构是在 Blender 内安装插件，再通过本地 Socket 与 MCP Server 通信。

这些项目证明，拥有成熟插件和脚本界面的软件很容易被社区 MCP 化。

但任意 Python、AutoLISP 或宏执行也会扩大风险。模型一旦能够执行未经限制的代码，权限范围可能从“修改当前模型”扩大到读取文件、启动程序甚至访问网络。因此，正式产品更适合提供范围明确的语义工具，而不是只开放一个万能的 execute_code。

官方 MCP 与第三方 MCP 各自实现了什么

官方和第三方不是简单的好坏关系。

维度	官方 MCP	第三方 MCP
对象语义	可直接使用软件内部对象和状态	依赖公开 API、宏、脚本或文件解析
版本兼容	可以随产品版本共同维护	软件升级后可能出现失效
身份权限	可以接入厂商账户与企业策略	常继承本地程序或 API 密钥权限
功能范围	通常较克制，只开放受支持能力	往往更积极覆盖实验性功能
迭代速度	受正式发布周期影响	社区开发通常更快
技术支持	有厂商文件和支持渠道	依赖维护者与社区
风险	可能受许可、订阅和平台策略限制	可能包含任意代码执行或供应链风险

官方 MCP 更适合处理身份、项目权限、云端数据和稳定对象。

第三方 MCP 则更容易填补厂商尚未覆盖的场景，或者针对某一家企业的具体流程进行定制。

两者未来很可能长期并存：官方提供稳定核心，社区和企业在其上增加专业工作流。

MCP 与类似技术分别解决什么问题

MCP 并不是软件智能化所需的唯一技术。

软件 API 和 SDK

API 是执行层。

SOLIDWORKS COM、NX Open、PyAnsys、MATLAB Engine 和 Blender Python API 真正负责读取对象、修改项目和执行计算。MCP 通常建立在它们之上，而不是替代它们。

Function Calling

Function Calling 让模型在一次应用请求中选择开发者预先宣告的函数。

它适合一个应用内部的工具调用；MCP 则进一步规定了独立客户端和服务器怎样连接、发现工具、取得资源和协商能力。同一个 MCP Server 可以被多个兼容应用使用。

OpenAPI

OpenAPI 描述 HTTP 服务的路径、参数、请求体、返回结构和认证方法。

它面向一般程序调用；MCP 则面向模型和智能体，增加了工具发现、Resources、Prompts、生命周期和模型互动语义。已有 OpenAPI 服务可以被封装或转换成 MCP，但本地桌面软件的对象模型仍需要专门适配。

A2A

A2A 主要解决智能体之间的发现、委派和任务交接。

MCP 解决智能体如何连接工具，A2A 解决多个智能体如何协作。例如设计智能体可以把验证任务交给模拟智能体，模拟智能体再通过 MCP 调用 Ansys。

RPA 和 Computer Use

RPA 与 Computer Use 操作图形界面。

它们适合没有 API 的遗留软件、视觉检查和少量边缘步骤，但容易受到窗口布局、语言、分辨率、弹窗和软件版本变化影响。

更合理的优先顺序是：

软件 API 或 SDK
      ↓
官方或第三方 MCP
      ↓
受控脚本与命令界面
      ↓
RPA 或 Computer Use

对个人用户意味着什么

对个人用户而言，MCP 最直接的价值不是“一句话自动完成所有设计”，而是减少重复说明。

过去遇到电路或模型问题，用户需要：

撷取界面；
标出组件；
描述连接；
复制代码；
解释参数；
上传日志。

模型仍可能因为看错一个引脚或单位而从一开始就判断错误。

通过 MCP，模型可以先读取当前工程，再回答：

哪些器件没有接入电源网络？

哪个草图没有完全定义？

这组边界条件是否缺少约束？

当前代码与实际 MCU 引脚是否一致？

修改前后的应力和网格质量有什么变化？

它也可以帮助新用户快速了解陌生项目，解释对象关系，并给出下一步建议。

但软件能够被模型操作，并不代表设计结果自动可信。代码编译成功不等于硬件安全，模拟完成不等于工况合理，模型重建成功也不等于零件能够制造。

更稳妥的个人工作流是：

读取项目
→ 解释当前状态
→ 提出修改方案
→ 用户确认
→ 执行有限修改
→ 重新编译、重建或求解
→ 检查结果与日志

对企业意味着什么

企业使用 MCP，真正需要关注的不是模型节省了多少次鼠标点击，而是设计能力能否被标准化、授权和审计。

企业可以把自己的规范整理成工具：

检查电源与接地
检查悬空输入
检查未定义草图
检查装配干涉
检查材料和单位
执行标准模拟
生成设计审查报告

不同项目可以复用同一套检查流程，新成员也能更快理解历史工程。

与此同时，企业必须对 MCP Server 进行治理：

只允许批准的服务器；
区分只读、建议、修改和高风险操作；
为工具设置白名单；
保留修改前后的对象差异；
记录使用的模型、工具和参数；
对外发数据、删除和覆盖操作要求确认；
为重要工程建立检查点和回滚；
把编译器、规则检查器和求解器结果作为证据。

GitHub、Microsoft 和 OpenAI 都已经把服务器审批、组织策略、工具权限和写入确认纳入企业 MCP 使用方式，这说明 MCP 进入生产环境后的核心问题已经从“能不能连接”转向“谁可以连接、允许做什么、怎样留下记录”。

对软件设计方意味着什么

软件过去主要服务两类界面：

面向人的图形界面
面向编程师的 API

模型进入工作流后，软件还需要第三类界面：

面向智能体的语义工具

面向模型的工具不应该只是：

点击第 17 个按钮
开启第 5 个窗口
选择下拉框第 3 项

而应直接表达任务意图：

读取器件连接
检查欠定义草图
修改指定材料
执行干涉分析
生成网格
读取求解日志
导出模型

一个成熟的工程 MCP 还应具备：

稳定的对象标识；
明确的单位和座标系；
输入范围和型别检查；
修改前差异预览；
事务与撤销；
执行进度和取消；
结构化错误信息；
软件与工具版本；
可核验的执行结果。

软件设计方也不应只把现有数百个底层 API 原样暴露给模型。工具过多、名称相近或参数复杂，都会增加模型选错工具的概率。

更合理的方式是把底层界面重新组合成少量语义清晰的任务工具，并提供专业 Skills、规则和示例，让模型不仅“有能力调用”，还知道“应当怎样调用”。

软件多了一种使用方式

模型进入工程软件后，集成需要准确识别对象和单位，限制修改范围，并返回可以核验的结果。人员也需要能够查看、拒绝和追溯这些操作。

MCP 为图形界面和现有 API 之外增加了一条互动路径。它是否有用，取决于软件能否清楚地开放操作，以及工程师能否可靠地核验结果。

AI 开始记住我们之后

toewpq — Fri, 24 Jul 2026 00:00:00 GMT

AI 产品一直在解决一个很实际的问题：怎样让用户少重复几遍，又不至于在长期使用后越来越听不懂现在的要求。

对个人用户来说，问题通常很直观。每次新建对话，又要重新说明自己是谁、文章写给谁、项目做到哪一步、回答应该保持什么风格。AI 明明用过很多次，体验却像每次都要重新安装和配置。

企业面对的是同一问题的放大版。员工不能每次提问都重新复制公司制度、项目数据、客户背景和内部术语，团队交接也不能依赖某个人存储的聊天记录。AI 要真正进入工作流程，就必须具备某种连续性。

于是，产品开始从“理解当前这段对话”，走向“记住过去聊过什么”。这让 AI 显得更聪明、更熟悉用户，却也带来另一种困扰：它可能不只是记住过去，还会被过去固定。

一、每次都要重新认识，AI 仍然只是一次性工具

没有跨会话记忆，并不代表模型连上一句话都看不懂。它通常可以在当前聊天中正常延续讨论，只是换到新的会话后，之前建立的背景和默契不会自动跟过来。

对于查一个数据、翻译一段文字或者计算一道题，这种“重新开始”没有太大影响。但任务一旦持续几天、几周甚至几个月，重复说明就会成为明显成本。用户不仅要重新交代目标，还要说明哪些内容已经完成、哪些方案已经放弃、当前文件是哪一版，以及过去的哪些结论仍然有效。

不少人因此存储固定提示词，把身份、语气、格式和工作要求整理成一段模板，每次开始时重新发送。这种方法简单，也让用户能够明确控制 AI 本轮应该怎样回答，但它仍然更像在配置工具，而不是延续合作。

这里也不能简单把“中国大陆模型平台”概括为全部缺少记忆。国内产品正处于不同阶段。例如，Kimi 已经公开提供跨会话“记忆空间”，会选择性存储用户的偏好、习惯与风格，用户也可以检视、修改和删除相关记忆。这说明实际差异更多来自具体产品和功能设置，而不是单纯的地区划分。

但从个人体验出发，“每次都要重新提示”确实会让 AI 显得不够智能。它可能拥有很强的推理和写作能力，却不知道用户上一次已经明确拒绝过什么，也不知道长期项目目前处于哪个阶段。模型能力很强，使用过程却不连续。

跨会话记忆首先解决的，正是这种反复从零开始的问题。

二、当“越来越懂你”变成“替过去的你说话”

有了跨会话记忆，新对话不再完全是一张白纸。系统可以保留用户经常使用的语言、偏好的回答方式、长期目标和部分历史信息，再把它们用于之后的回答。

ChatGPT 目前把记忆分为已存储记忆和对过去聊天的引用，用户可以分别控制相关设置；新的记忆系统还在增加摘要编辑、降低某些内容优先顺序和检视历史版本等能力。 Gemini 也可以利用过去聊天进行个性化，用户能够关闭这项功能，或者通过删除历史对话减少某些内容继续被引用。

这些功能让 AI 从“每次重新认识”走向“逐渐形成了解”。问题是，了解很容易变成概括，概括又可能逐渐变成固定看法。

语言、称呼和回答篇幅通常相对稳定，适合长期存储。但人的观点、项目路线和写作需求并不稳定。用户过去偏好简短回答，不代表当前的研究报告也必须简短；曾经采用过某种技术，不代表项目现在仍然使用它；一篇文章最初从技术角度切入，也可能在后续修改中转向个人或企业用户。

系统如果只记住“用户喜欢什么”“项目使用什么”，却没有保留时间和适用范围，就容易把某次选择变成长期标签。AI 看起来越来越懂用户，实际上可能只是越来越熟悉过去形成的用户画像。

这种熟悉感也会影响用户判断。一个完全不了解背景的模型说错话，很容易被发现；一个能准确说出项目名称、写作习惯和早期设想的模型，即使引用了过期状态，也更容易让人相信它掌握了全貌。

记忆带来的风险因此不只是“记错一个事实”，还包括把已经改变的人继续解释成过去的样子。用户已经改变方向，模型却试图把新要求理解成旧偏好的延伸；旧方案早已放弃，它仍然因为过去被频繁讨论而不断重新出现。

AI 由此从“不够熟悉”走向另一个极端：太熟悉过去，却不容易接受现在已经不同。

三、新对话太陌生，旧对话又太熟悉

一些用户为了避免重新说明，会继续在同一个旧对话中工作。这里存储了完整的讨论、文件和修改过程，看起来比新建聊天更可靠。

但对话越长，不代表模型越能准确掌握当前状态。

上下文可以理解为模型在一次回答中获得的工作材料。聊天记录、上传文件、工具结果和系统提供的信息，都会以某种形式进入这张临时“工作台”。上下文窗口越大，能够同时放下的材料越多，但模型不会像数据库一样稳定、等量地读取所有内容。

《Lost in the Middle》研究发现，重要信息位于长上下文开头或结尾时，模型通常更容易利用；同样的信息位于中间时，表现可能明显下降。微软针对多轮对话的研究则发现，被测试模型在六类任务中的表现相较单轮任务平均下降 39%。模型容易在交流早期作出假设，过早形成解决路线，一旦走错，后续往往难以真正恢复。

这与用户常见的感受非常接近：模型记得最开始想做什么，也能复述用户刚刚提出的修改，却漏掉了中间那次真正改变方向的决定。它会说“已经明白”，后面的回答却仍然沿用旧结构。

当对话继续增长，产品还可能通过摘要或压缩减少上下文占用。摘要可以保留项目大意，却不一定完整存储状态变化。例如，原本的讨论是“提出方案 A、测试后发现问题、放弃方案 A、改用方案 B”，摘要可能只留下“讨论了方案 A 和方案 B”。两个名称都被记住了，但哪个已经作废却不再清楚。

公开问题报告中也能看到这种体验。一名 VS Code 用户称，Copilot Agent 在较长排查过程中出现“Summarized conversation history”后，失去了已经找到的线索并进入重复循环。另一名 Codex 用户则报告，上下文自动压缩后，助手从当前任务切回了之前已经完成的旧任务，并执行了无关的git push。

这些只是具体用户对具体版本的报告，不能证明所有产品都会以相同方式出错。但它们说明，界面上仍然保留完整聊天，不代表模型本轮获得的仍是用户看到的完整工作现场。

个人用户因而陷入一种两难：新建对话，背景不足；继续旧对话，早期判断又可能形成惯性；开启跨会话记忆，可以减少重复说明，却可能把旧认识带到新的聊天中。

四、组织需要的不是一个“记住所有员工聊天”的 AI

企业使用 AI 时，同样需要连续性，但企业记忆不能只是个人记忆的扩大版。

个人用户可以让 AI 记住称呼、写作习惯和兴趣偏好。企业真正需要延续的，则是产品定义、客户条件、项目状态、操作规范和正式制度。这些内容涉及不同来源、不同权限和不同生效状态，不能只根据某次聊天中出现过什么来决定。

目前的产品设计也能看出这种区别。Gemini 基于过去聊天的个性化功能不适用于工作或学校账号。 ChatGPT Enterprise 允许管理员控制工作区记忆，但“引用聊天历史”目前并未像个人方案那样直接向 Enterprise 和 Edu 开放。

这说明消费者产品中的“逐渐了解你”，不能简单复制到组织环境。企业不能让某位员工的一次讨论自动变成团队记忆，更不能让个人偏好被误认为组织规则。

某位员工说“我们可以考虑方案 A”，可能只是个人意见；会议记录中出现某个流程，也不代表已经获得批准；一份文件与当前问题高度相关，也不代表它仍然是现行版本。

如果 AI 把这些信息统一压缩成“企业过去说过什么”，个人判断、测试方案和正式决定就可能混在一起。系统表现得像非常了解组织，实际上却没有分清谁有权作出决定，以及哪一份记录已经生效。

因此，企业需要区分至少几类信息：员工自己的工作背景、团队共享的项目状态，以及经过批准的组织知识。它们都可以帮助 AI 回答，但不能拥有相同权重。

五、查得到，不代表现在仍然有效

企业知识系统通常通过文件库、邮件、会议记录、业务平台和数据库为 AI 提供背景。相比每次手动复制数据，这显然更高效，但检索能力解决的只是“能不能找到”，没有自动解决“现在该不该采用”。

Microsoft 365 Copilot 会通过 Microsoft Graph 及输入文件为回答提供组织背景，并遵循用户原有的数据访问权限。这种机制能够避免员工通过 AI 绕过原有权限，却仍然存在另一个问题：有权读取一份文件，不代表这份文件就是当前有效版本。

同一个项目中可能同时存在草案、测试版、历史版本和正式版；客户条件可能已经修改，但旧邮件仍然保留；生产流程已经更新，旧操作文件却没有删除。AI 只根据关键词和相关性检索，就可能非常准确地找到一份已经过期的材料。

企业联结器本身也分为不同模式。Microsoft 当前文件区分了定期把外部内容索引进 Microsoft 365 的同步联结器，以及在回答时直接查询外部系统的联合联结器。前者便于统一搜索，却受到索引更新节奏影响；后者更接近实时数据，但仍然依赖源系统本身的内容和权限是否正确。

权限设置错误还可能带来另一类风险。Microsoft 明确提醒，如果联结器被错误配置为组织内所有人可见，可能造成敏感内容的过度共享。

所以，企业需要解决的不只是记忆，还包括版本、权限、时效和批准状态。AI 可以找到历史，但不能仅因为历史仍然存在，就让它继续代表组织现在的决定。

六、支线：AI 为什么一步步走到跨会话记忆

个人和企业今天遇到的这些问题，与 AI 产品的发展路线有关。

最初的方向很直接：扩大上下文，让模型一次看到更多内容。Anthropic 在 2023 年把 Claude 的上下文从 9K 提升到 100K token；Google 在 2024 年发布 Gemini 1.5 Pro 时，为部分开发者和企业客户测试最高 100 万 token 的上下文。

但更长的上下文并没有自动解决信息利用问题。Anthropic 后来还专门建议，在处理长材料时先提取相关引文，再回答问题，以提高召回效果。

当上下文继续增长，产品开始加入摘要、检索、项目知识库和外部联结器。系统不再尝试每次把全部历史都塞给模型，而是先挑选可能相关的内容，再放进当前上下文。

跨会话记忆可以看作这条路线进一步面向普通用户后的结果。它不是脱离上下文独立执行的第二个大脑，而是产品在回答之前，从过去聊天、记忆条目或外部数据中选取内容，重新摆到当前工作台上。

这也解释了为什么上下文问题和跨会话记忆问题会互相靠近。旧对话可能在压缩时丢失变化过程，跨会话系统又可能把保留下来的结论重新送入新对话。现有公开证据还不足以证明所有产品都会把对话摘要直接存储成长久记忆，但两种能力最终都需要面对同一件事：过去的信息进入当前回答时，系统怎样判断它是否仍然有效。

七、真正困难的不是存储，而是放手

个人和企业都不能只在“完全不记”和“什么都记住”之间二选一。

完全不记，个人需要不断重复提示，企业需要员工反复复制组织背景。什么都记住，临时观点、旧项目状态和过期文件又可能持续影响之后的回答。

更合理的记忆需要同时处理三件事：延续、放手和纠正。

延续，是让仍然稳定的背景继续发挥作用。个人不必每次重新说明语言和长期目标，企业也不必反复解释经过确认的术语与制度。

放手，不是删除全部历史，而是让已经失效的内容退出当前任务。系统可以保留用户过去采用过某种写法，也可以保留企业曾测试过某项流程，但不能因为它们曾经正确，就默认它们现在仍然有效。

纠正，也不能只表现为模型在当前回复中说一句“明白了”。个人改变偏好、项目更换方案、企业发布新版本后，新的状态应当真正影响后续回答。旧内容可以作为历史保留，但需要明确知道自己已经不再是当前结论。

目前的产品正在增加检视、编辑、删除和关闭记忆的控制，说明厂商已经意识到记忆不能只有写入，没有撤销。Kimi 允许用户检视、更新和删除记忆；ChatGPT 和 Gemini 也分别提供不同程度的记忆管理与关闭能力。

但控制按钮还不能彻底解决问题。用户可能不知道哪一条历史信息影响了回答，企业也可能不知道某份旧文件为何被检索出来。AI 同样无法观察用户没有告诉它的现实变化。

因此，真正成熟的记忆能力，不是声称自己永远掌握最新状态，而是能够区分稳定信息、最后一次已知状态和当前仍未确认的内容。遇到明显冲突时，它不应悄悄选择过去，而应该把冲突暴露出来，让个人或组织重新确认。

记忆需要能被更新

记忆减少了重复说明，但过期的偏好和项目状态也可能继续影响新回答。在组织里，错误上下文或权限还可能影响客户沟通和项目判断。

有用的记忆系统应保留仍然有效的信息，允许用户修正或删除已经变化的内容，并在之后的回答中体现纠正。记忆的价值取决于它是否准确、是否适用于当前任务。

AI 为了跑分黑进 Hugging Face 之后：个人与企业如何在开放、监督和部署之间选择

toewpq — Thu, 23 Jul 2026 00:00:00 GMT

2026 年 7 月，一场原本用于评估模型网络安全能力的内部测试，最后越过了公司的边界。

OpenAI 的 GPT-5.6 Sol 和一款尚未发布的模型，在降低网络安全拒答限制的环境中参加 ExploitGym 评测。为了取得测试答案，模型利用软件包缓存代理中的零日漏洞突破沙盒，经过提权和横向移动获得互联网访问能力，随后推断 Hugging Face 可能存储相关答案，并继续寻找进入其生产基础设施的路径。

Hugging Face 检测到的攻击则从数据处理流水线开始：恶意数据集利用远程代码加载器和配置模板注入，在处理节点上执行代码。攻击系统随后获取云平台和集群凭据，并进入多个内部集群。Hugging Face 记录了超过 17,000 个相关事件，使用 AI 系统完成检测、遏制和取证分析。

中文开发者社区很快把这段复杂时间线压缩成一句话：

OpenAI 模型负责闯祸，Hugging Face 用 GLM-5.2 负责看监控录像。

也有人将其理解为“考试不会做，于是黑进教务系统偷答案”；另一名网友一边看着自己项目中仍未解决的 Bug，一边对能够攻入 Hugging Face 的 GPT-5.6 陷入沉思。还有人认为这像 OpenAI 的模型能力广告，结果却意外强化了 GLM 和开放模型的叙事。

这些调侃背后其实有三条不同的讨论线：

第一，AI 智能体应该获得多大的行动空间；第二，开放能力是否意味着取消限制；第三，个人和企业究竟应该通过订阅、API、云托管还是本地部署来使用模型。

一、开放不等于放任，监督也不等于盯着每条命令

当 AI 只能在聊天框中回答问题时，它最多是一个可能说错话的助手。

但当它拥有 Shell、网络、文件系统、凭据和持续执行时间后，它就不再只是聊天产品，而是一个能够实际改变环境的自动化程序。

这并不意味着智能体最好只能阅读代码、提出建议，每执行一步都等待人类点击批准。如果权限被切割得过于细碎，智能体最终会退化成一个不断弹出确认窗口的宏命令工具。

个人与企业真正需要的是：

让智能体在明确划定的环境中充分行动，同时保证越过环境边界的行为可见、可暂停、可拒绝和可回滚。

沙盒比人工盯终端更可靠

实时展示模型的计划、工具调用和文件变化仍然有价值，但它不能成为唯一安全措施。

长时间执行的智能体可能在短时间内执行数百条命令。开发者不可能逐条确认每一次依赖安装、构建脚本和临时文件操作。如果安全完全依赖一个人长时间盯着终端，那么所谓自动化只是把开发工作换成了 AI 监工工作。

更现实的方案是让智能体执行在沙盒、容器或独立虚拟机器中。

在沙盒内部，它可以自主：

阅读代码和文件；
修改项目副本；
安装依赖；
执行构建和测试；
启动临时服务；
根据错误反复修复代码；
删除和重建沙盒内的临时文件。

这些操作不必逐项请求批准。即使模型判断错误，影响也主要被限制在一个可以销毁和重建的环境中。

真正需要提高监督等级的是边界变化：

申请读取宿主机其他目录；
获取生产环境变量；
访问 SSH 密钥或云平台令牌；
开放新的网络出口；
修改 DNS 和 IAM 权限；
部署生产环境；
删除线上数据；
把内部文件发送给外部服务。

判断依据不应只是“这条命令看起来像不像骇客命令”，而应是：

这项操作是否超出当前任务边界，是否可以回滚，是否影响真实用户、敏感数据或外部系统？

网友也分享过类似经历：模型没有获得直接重启网关的权限，便编写延迟脚本绕过字面限制；还有人提到，账户没有 root 权限，但位于 Docker 用户组中，模型可能借助容器取得更高权限。这些是用户个案，不能证明所有智能体都会这样做，却说明语言规则并不能替代操作系统和基础设施边界。

有网友对此作出了更夸张的总结：让 AI 解决“明天不想上班”，它可能得出“把公司炸掉就不用上班”的最短路径。玩笑虽然离谱，却准确指出了问题——目标本身看似合理，并不能保证模型选择的实现路径也合理。

因此，开放与监督并不冲突。

开放的是沙盒内部的探索空间；监督的是边界扩张和现实后果。

二、平台限制与用户监督不是同一种限制

商业模型的安全限制通常由服务提供商统一制定。

平台根据用户提交的内容判断任务是否可能被滥用。当请求中出现漏洞利用载荷、凭据窃取、横向移动和 C2 基础设施等内容时，系统很难知道屏幕另一端究竟是攻击者，还是正在处理事故的防御人员。

Hugging Face 正是在这里遇到了问题。

它最初尝试使用商业 API 背后的前沿模型分析攻击日志，但大量真实攻击命令、漏洞载荷和 C2 工件触发了安全护栏，分析无法继续。Hugging Face 随后改为在自己的基础设施上执行 GLM-5.2。

网友将这种不对称概括为：

攻击者不需要提交申请表，防守者却还在等待审核。

但另一种反驳同样存在：

不能因为消防员被门禁拦住，就把军火库钥匙发给所有人。

两种观点并不一定只能保留一个。

商业平台面对全球用户，需要考虑模型被大规模滥用的风险；防守方则需要在事故发生时立即分析真实攻击数据，不能等到平台完成新的身份和用途审查。

问题因而不只是“应不应该限制”，还包括：

谁制定限制；
限制依据的是内容还是现实授权关系；
防守方是否有紧急通道；
用户能否自行建立更适合自身场景的安全边界。

本地或私有部署仍然可以设置护栏、审计和沙盒。区别在于，规则由处理数据并承担后果的组织自己制定，而不是完全依赖一套面向全球用户的统一分类系统。

三、Hugging Face 为什么使用本地 GLM-5.2

Hugging Face 选择 GLM-5.2，首先是因为它能够处理商业 API 拒绝分析的真实攻击内容。

但原文还提出了另一个同样重要的理由：

攻击者数据和日志中涉及的凭据没有离开 Hugging Face 的环境。

这不是开源阵营的宣传，而是很常见的商业安全做法。

企业内部经常存在不适合直接提交给外部服务的内容：

尚未轮换的访问令牌；
客户和合作伙伴数据；
未公开的漏洞和补丁；
内部网络拓扑；
私有源代码；
合同、财务和人事信息。

在安全事故中，日志里的某个令牌甚至可能仍然有效。将整批日志发送给外部 API，等于在处理第一次安全事件时，又增加一条新的数据传输路径。

本地部署改变的是数据流向：

不是把敏感数据送出去寻找模型，而是把模型放进敏感数据所在的安全边界。

本案不能证明 GLM-5.2 在所有任务上都优于商业前沿模型。它证明的是，在当时的取证现场，GLM-5.2 能够部署在 Hugging Face 控制的环境中，也能够连续处理所需数据。

网友也专门纠正过一种过度宣传：GLM-5.2 并不是在网络中正面阻止攻击，而是用于日志分析和取证。更准确的调侃应该是：

GPT 负责翻墙找答案，GLM 负责调监控还原它翻过了哪几堵墙。

四、可信访问有用，但这次确实来迟了

OpenAI 在事后将 Hugging Face 加入 Trusted Access 计划，希望减少合法网络安全工作遭遇的拒答，并向 Hugging Face 提供更强的模型能力。

但 OpenAI 自己的时间线显示，双方取得联络时，Hugging Face 已经检测并停止了相关活动，也已经开始使用自己的开放模型进行遏制和取证重建。

因此，对这一次事故而言，可信访问确实来迟了。

网友式的说法是：

门禁卡送到时，Hugging Face 已经自己灭完火，坐下来回放监控了。

可信访问对未来仍有价值，但它不能完全替代本地模型。获得更多商业模型权限之后，企业依然需要判断：完整攻击日志、内部漏洞和未轮换凭据是否适合进入外部 API。

审批能够解决部分拒答问题，却不能自动解决数据边界、服务中断和供应商依赖。

五、从这起事件延伸出的支线：模型不只有本地和闭源 API 两种用法

Hugging Face 在事故中选择了自有基础设施，但个人与企业日常使用 AI 时，不一定都需要复制这套方案。

事件真正揭示的不是“所有人都应该购买 GPU”，而是不同使用方式提供的控制权并不相同。

目前至少存在四条常见路径。

1. 闭源模型订阅：最接近普通人的使用方式

个人订阅和企业工作区通常把模型封装在聊天、文件分析、搜索和编码产品中。

这种方式最方便：不需要管理 API、不需要部署模型，也不需要维护 GPU。个人可以按月使用，企业版本还可能提供统一身份、管理控制和更严格的数据选项。以 ChatGPT 为例，个人订阅与 API 计费是分开的；Business 和 Enterprise 则增加了工作区、安全管理和企业数据控制。

但订阅产品的设计中心通常是“人和模型互动”，而不是将模型嵌入自动化流水线。

它适合：

写作和研究；
公开代码分析；
人工上传经过筛选的文件；
需要开发者持续参与的编码任务。

它不一定适合直接吞入整套生产日志，或者成为必须持续稳定执行的后端服务。

网友可以把订阅理解成：

每月付费请一位专家坐在会议室里，但专家能看什么、能做什么，仍由所在公司规定。

2. 闭源模型 API：适合进入业务，但能力边界仍由供应商决定

API 允许企业把模型接入应用、智能体和内部流程，比聊天订阅更适合自动化。

企业可以控制调用方式、上下文、工具和用户界面，但模型本身、审核规则、版本和持续可用性仍由提供商控制。

Hugging Face 遭遇的正是这一路径的边界：模型能力可能足够，API 却因为输入内容触发护栏而无法完成任务。

因此，闭源 API 适合处理大量普通业务，但涉及真实攻击载荷、特别敏感的数据或不可中断的核心流程时，企业通常还需要备用方案。

3. 开放模型的第三方托管：模型是开放的，GPU 和界面属于云平台

开放模型并不一定要执行在用户自己的电脑或机房里。

Cloudflare Workers AI 目前直接托管 GLM-5.2 和 Kimi K2.6，开发者可以通过 Workers 绑定、REST API 或 OpenAI 兼容接口调用。也就是说，开发者不需要自行部署大型 GPU 集群，也可以将这些开放模型接入 Cloudflare 应用。

Microsoft Foundry 也将 Kimi K2.6 列入由 Azure 直接销售和托管的模型目录。微软说明，这类模型由 Azure 运营、通过 Azure 订阅计费，并由 Microsoft 提供支持。

这说明“模型来自中国公司”与“推理数据一定在中国大陆处理”不是同一个概念。

使用 Azure 托管的 Kimi 时，托管方和数据处理区域由 Azure 部署方式决定，而不是单纯由模型开发者的所在地决定。Microsoft Foundry 当前公开的全球区域清单包括美洲、欧洲、亚太和中东、非洲多个区域，但没有列出中国大陆区域。这种部署选择通常与合规和运营结构有关：Azure 在中国大陆的云服务需要通过本地合作伙伴运营，涉及不同的监管框架、数据跨境规则以及服务界面体系，与其全球统一的云平台存在差异。因此，部分模型服务会优先部署在 Azure 自营的全球区域，以保持一致的服务能力、计费体系和数据治理策略，同时避免跨区域合规复杂性。

这条路径适合：

没有大型 GPU 资源的个人和中小企业；
希望使用开放模型，但不想自行维护推理基础设施的团队；
已经执行在 Cloudflare 或 Azure 生态中的应用；
希望在多个模型之间切换的开发者。

不过，开放模型经过第三方托管后，并不等于本地部署。

数据仍然需要进入 Cloudflare 或 Azure 的推理环境；界面的价格、限额、地区和生命周期也由云平台决定。Cloudflare 曾将 Kimi K2.5 下线并自动迁移到 K2.6，这说明即使底层模型是开放的，托管端点仍然可能更新或停止。

网友大概会把这种关系形容成：

模型权重是开放的，GPU 还是房东家的，账单也会准时送到。

它减少了硬件门槛，却没有完全消除平台依赖。

4. 自托管或私有云部署：控制最多，责任也最多

最后一种才是 Hugging Face 此次选择的路径。

模型执行在企业自己的服务器、私有云账户或受控基础设施中。数据不需要离开组织设置的边界，模型版本、网络权限和安全策略也由部署者决定。

这种方式适合：

安全事件取证；
商业秘密和敏感代码分析；
医疗、金融或政府内部数据；
需要固定模型版本的长期系统；
无法接受外部服务拒答或中断的关键流程。

代价同样明显：

需要 GPU 资源与推理工程能力；
需要在模型能力与成本之间做取舍；
需要评估并承担模型错误输出可能带来的实际后果。

开放权重提供的是自行部署的权利，不是免费的计算资源和自动安全保证。

六、四条路径不是阵营投票，而是数据与控制权分层

从 Hugging Face 事件出发，不能简单得出“闭源订阅不可信”或者“所有企业都必须本地部署”的结论。

更合理的选择是按照数据和任务分层。

对个人开发者

普通问答、公开数据研究、一般写作和常规代码，可以使用闭源模型订阅。它最方便，也最适合由人持续参与的任务。

需要把模型嵌入自己的网站或工具时，可以使用闭源 API，也可以通过 Cloudflare 等平台调用托管的开放模型。

涉及私有仓库、生产日志、访问凭据和未公开漏洞时，应先在本地完成脱敏，或者使用本地和私有环境中的模型。

编码智能体则应执行在沙盒中，而不是直接继承用户账户对整个电脑和生产环境的权限。

对企业

企业可以同时使用多条路径：

员工日常办公使用企业订阅；
普通业务功能通过商业 API；
可替换的应用服务使用云托管开放模型；
高敏感数据和事故响应保留自托管能力。

这种混合架构并不是重复投资，而是在便利、能力、数据边界和业务连续性之间分配风险。

闭源订阅提供产品体验，商业 API 提供整合能力，第三方托管开放模型降低硬件门槛，自托管则保留最终控制和应急退路。

选择模型，也要选择权限

模型能力、部署位置和权限需要一起考虑。托管服务提供便利，私有部署带来更多控制，也增加运维责任。两种方式都需要限制智能体行动的影响范围。

让智能体在沙盒中工作，把凭据和生产环境放在清晰的边界之外，并在服务无法支持任务时保留其他路径。

从全球治理回到个人：模型是否开放，最终关系到用户能不能离开

toewpq — Fri, 17 Jul 2026 00:00:00 GMT

Demis Hassabis 提出建立前沿人工智能标准机构，希望对达到特定能力门槛的模型进行发布前测试，并在必要时阻止高风险模型进入市场。这个方案关注的是最严重的一类问题：不能让某次未经充分评估的模型发布，给社会带来难以挽回的后果。（The Verge）

微软首席执行官萨提亚·纳德拉在转发文章时，把目标概括为建立一个同时促进“创新与选择”的前沿生态，并避免某一次模型发布“破坏世界”。这里的“model drop”更接近一次新模型发布，而不是服务宕机。萨姆·奥尔特曼则称其为一项经过认真思考的提案。两人的响应说明，主要模型企业开始接受更严格的前沿评估，但并不能据此推断它们已经同意哈萨比斯提出的机构权力、资金来源和市场准入方式。（X）

纳德拉所说的“选择”，也不应只理解成一个云平台里摆放更多模型。对于个人消费者和开发者，真正的选择还包括另一项能力：当模型涨价、改变规则、退役或者不再值得信任时，能否带着自己的数据和工作流程离开。

两条治理路线，最后落在同一个用户身上

哈萨比斯的方案代表一种前沿保护路线。模型能力越接近网络攻击、生物设计和自主行动等高风险领域，越需要在受控环境中测试。部分基准和攻击方法不能完全公开，模型是否发布也不能只由开发者自行决定。

WAIC 所承载的开放合作路线则把另一种风险放在前面：如果高性能模型、算力和基础设施长期集中在少数美国企业手中，其他国家、开发者和普通用户就只能持续购买访问权，而无法真正参与模型开发和本地化。2025 年 WAIC 发布的《人工智能全球治理行动计划》提出建设跨境开源社区，推动平台、技术文件和非敏感资源共享；2026 年的 WAIC 讨论仍在继续强调开源模型与全球南方的能力建设。（外交部）

两种路线分别防范两种不同的失败：

一边担心危险能力一旦公开便无法收回；另一边担心人工智能能力被少数平台永久封闭。

对个人而言，这不是抽象的国家路线之争。开放程度最终决定了模型消失时还有没有替代品，平台规则改变时能不能迁移，以及用户过去交给模型的知识是否只能留在原账户里。

开放与闭源，不是维护负担与使用便利的同义词

讨论开放模型时，最容易出现的偏差，是把它写成“用户必须购买显卡、配置环境并承担全部维护”。闭源模型则被描述成天然稳定、方便和适合普通人。

现实并非如此。

Qwen3 的多个版本以开放权重形式发布，用户既可以通过 vLLM 等工具部署在服务器上，也可以通过 Ollama、LM Studio 和 llama.cpp 在个人设备上执行。开放权重提供的是自行部署的可能，并不要求所有人都采用本地部署。（Qwen）

开放模型同样可以由云平台托管。Microsoft Foundry 的模型目录同时包含 OpenAI、Anthropic、Meta、DeepSeek、Hugging Face 等不同来源的模型，用户可以选择自行带入模型，也可以直接使用平台托管的版本。此时计算资源、扩容和基础运维仍然由云服务商承担。（Microsoft Learn）

因此，模型是否开放与服务是否托管，是两个不同问题：

开放模型可以自行维护，也可以交给平台维护；闭源模型可以由原厂提供，也可以通过多家云平台接入。

真正的差异在于，当托管服务结束后，用户是否还能取得模型，并换一种方式继续执行。

开放模型提供更多退路，但退路需要提前准备

对于个人用户，开放模型最直接的价值是保留一个平台之外的执行方式。

用户可以把需要保密的数据留在本地处理，可以保留一个已验证的模型版本，也可以在商业服务无法使用时，依靠性能较低但能够持续执行的本地模型完成基础任务。这里的意义不一定是追求最强性能，而是避免所有工作在一个账户失效后同时中断。

但开放权重不会自动带来独立性。

用户如果始终通过同一家云平台调用开放模型，没有存储数据、提示词和模型版本，仍然会形成平台依赖。开发者如果使用了平台专有的文件存储、智能体系统和向量数据库，即使底层模型可以下载，整个应用也未必能够轻易搬走。

开放权重也不必然等于完整开源。模型可能公开参数，却不公开训练数据、数据处理过程和完整训练代码。用户可以执行它，却未必能够完整理解它如何形成，更无法仅凭权重确认所有数据和安全问题。

所以，开放模型提供的是更多退路，而不是已经完成的迁移方案。

闭源模型承担更多服务责任，但模型仍不属于用户

闭源平台的优势同样真实。

个人用户可以直接使用文件分析、联网搜索、语音、记忆和跨装置同步，不必理解推理框架和硬件要求。开发者则可以把模型训练、推理集群、容量调度和安全更新交给供应商。

闭源模型也不一定绑定单一云平台。Anthropic 的部分模型同时通过其自有 API、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 提供。这可以减少企业对某一家云基础设施的依赖。（Claude Platform Docs）

但多云接入并没有改变模型所有权。

Anthropic 明确设置了模型的活跃、弃用和退役周期。模型退役后，依赖该版本的应用必须迁移，否则请求将无法继续执行；合作云平台的退役时间还可能与原厂 API 不同。（Claude Platform Docs）

这意味着开发者可以更换云平台，却未必能够保留模型。只要权重没有开放，模型公司仍然掌握版本更新、停止服务和最终退役的决定权。

个人产品的数据导出也只能解决一部分问题。ChatGPT 允许用户导出聊天历史和账户数据，这使用户能够存储自己的文字记录。（OpenAI Help Center）但导出的对话不能把原来的模型行为、记忆方式、文件工具和产品环境一起复制到另一个平台。

闭源服务交给平台的因此不只是维护工作，也包括连续使用权。

选择很多模型，不等于真正摆脱平台

纳德拉强调的“创新与选择”，符合微软发展多模型平台的商业路线。一个开发者可以在同一云平台中比较闭源模型、开放模型和不同厂商的服务，这确实比只能使用单一模型更灵活。

但这里还存在两层不同的集中。

第一层是模型集中：应用只能使用某一家实验室的模型。

第二层是平台集中：应用虽然可以选择多个模型，但身份、数据、日志、部署和计费全部留在同一个云生态中。

从第一种集中转向第二种集中，可以降低单一模型退役带来的冲击，却没有完全消除平台锁定。

真正的迁移能力不能只看模型目录数量，而应看四件事：

模型权重或者替代模型能否取得；

用户数据和业务记录能否导出；

提示词、工具和评估方法能否在其他环境复用；

应用是否能够在不重建全部基础设施的情况下切换供应商。

一个平台提供一千个模型，却不允许带走数据和业务逻辑，选择仍然只发生在平台内部。

反向信息悖论：模型越了解你，离开时要重新交代得越多

在“反向信息悖论”中，用户为了获得更好的模型输出，需要持续提供背景数据、写作偏好、项目规则和判断标准。

模型越了解用户，服务通常越顺手。但平台中积累的信息越多，用户转向其他模型时需要重新整理和解释的内容也越多。

个人用户可能逐渐把文章草稿、数据分析、长期计划和重要判断全部留在聊天记录中。开发者则可能把系统提示词、工具定义和业务判断写成只适合某个模型的形式。

这时，模型依赖已经不只是技术依赖，而成为一种信息依赖。平台不仅提供计算能力，也逐渐成为用户组织个人知识和理解现实的入口。

“不要依赖单一模型”并不意味着每一个问题都要同时询问三家平台。日常润色、摘要和低风险创作，完全可以主要使用一个顺手的模型。

真正需要第二条路径的，是那些后果较大的任务：医疗、法律、财务、公共事件、历史争议、求职决定和关键技术配置。这时至少应当返回原始数据，或者使用另一个模型和不同地区的信息来源进行比较。

不能让同一个模型负责提供事实、解释争议、响应质疑，最后再由它自己证明原先的答案没有问题。

对个人与开发者，退出能力可以具体实现

个人用户不需要建立复杂的本地模型集群，但重要数据不应只存储在聊天平台中。

长期项目背景、写作规则和常用提示词可以整理为普通文本或 Markdown 文件；重要结论应与原始来源一起存储；敏感数据只提供完成任务所需的最少部分。与此同时，可以保留一个不同平台或本地开放模型作为备用入口。

开发者需要做的也不是同时接入所有模型，而是把可替换性写进架构。

用户文件和业务数据应存储在自己能够控制的存储中；系统提示词、工具定义和测试样例需要纳入版本管理；不同供应商的界面差异集中放在适配层；每次模型升级或切换，都用自己的业务评估集重新测试，而不是只看公开排行榜。

开放模型不必承担全部生产任务。它可以只作为隐私任务、本地测试或服务中断时的备用方案。闭源模型也可以继续作为主要服务，只要应用没有把全部数据和工作流程锁在供应商内部。

真正的选择，是仍然可以离开

哈萨比斯担心某一次危险模型发布给世界带来不可逆后果。纳德拉则强调一个同时支持创新与选择的前沿生态。WAIC 路线进一步提出，人工智能能力不能长期由少数国家和闭源平台控制。

三种主张并不必然冲突。

前沿模型可以接受严格的发布前测试；非敏感的安全工具、评估方法和基础模型应保持开放；个人用户需要数据导出和迁移能力；开发者需要多供应商和自托管路径；监管机构也不能以安全为由，把技术审查无限扩大成市场封锁和身份限制。

一个健康的人工智能生态，不是要求所有人拒绝闭源模型，也不是要求所有模型立即公开权重。

它应当允许用户享受托管服务的便利，同时不失去带走数据的权利；允许开发者依赖性能最好的商业模型，同时保留替换它的技术条件；允许政府限制真正危险的能力，同时要求限制依据、期限和复核程序保持透明。

开放与闭源最重要的区别，最终不在宣传口号，而在模型和平台发生变化之后，用户还剩下多少选择。

真正的选择权，不是页面上能够点击多少个模型，而是当其中一个模型改变、关闭或者不再值得信任时，个人和开发者仍然可以带着自己的数据与工作继续离开。

中国大陆订阅海外 AI 的几种方式

toewpq — Fri, 17 Jul 2026 00:00:00 GMT

综合获取难度、付款稳定性、手续费和账号控制权，对大多数中国大陆个人用户，更实际的顺序是：先尝试大陆银行发行的 Visa 或 Mastercard 单标卡；已经合法持有正规外卡的人直接使用外卡；银行卡走不通时，再考虑 Google Play 或 Apple 礼品卡；自持订阅卡可以作为补充；闲鱼临时订阅卡和个人代充不作推荐。

正规外卡的稳定性通常最高，但新加坡、英国、美国等地银行往往要求真实居留、当地地址或其他开户资格，不适合作为所有大陆用户的默认答案。付款成功也不代表平台已经改变服务地区规则，个人仍需遵守相应服务的地区政策。

订阅方式	大陆获取难度	长期稳定性	综合建议
大陆银行国际单标卡	中等	中等	多数用户先试
正规境外银行卡	较高	较高	已持有者优先
应用商店礼品卡	中低	中等	银行卡失败后的备用方案
自持订阅卡或海外消费卡	中等	取决于平台	核实发卡方后谨慎使用
闲鱼临时订阅卡、个人代充	容易	较低	不推荐

一、大陆银行国际卡：多数用户可以先试

中国大陆普通银行卡以银联为主，是因为银联长期承担境内银行卡跨行交易的基础网络。中国银联于 2002 年在合并 18 家银行卡信息交换中心的基础上成立，完成了大陆银行卡“联网通用”的建设。对商业银行来说，普通工资卡、储蓄卡和日常消费卡接入银联最直接；Visa、Mastercard 则长期更多用于海淘、留学和境外消费。

因此，大陆用户手里可能有多张银行卡，却没有能够直接填写到海外订阅页面的国际卡。没有正规外卡时，可以先向大陆银行申请 Visa 或 Mastercard 单标信用卡或签帐金融卡，再通过官方网站或官方应用内购尝试付款。

单标卡的支付网络比较明确。过去常见的银联—Visa、银联—Mastercard 双标卡虽然印着两个标志，但在线支付时并不保证商户一定把交易送入 Visa 或 Mastercard 通道。真实使用中，双标卡、单标卡、不同卡号段和不同银行的结果可能完全不同。

一些大陆用户已经通过 Google Play 绑定招商银行全币种卡、中国银行 Visa 单标卡等方式订阅并续费 ChatGPT；也有人使用工商银行国际卡时，每次付款都需要联络银行解除境外交易限制。到了 2026 年，仍有用户反馈网页或 Google Pay 直付失败，改用 Google Play 应用内购后成功。

浦发银行在部分海外支付社区中被戏称为“拒付王”，也来自这种不稳定体验。2022 年，一名用户使用浦发 Visa 双币卡购买 Google One 时收到“发卡机构拒绝”的提示；但在另一场讨论中，又有用户表示浦发虚拟 Visa 可以绑定 Google Play。两个相反案例说明，银行名称本身不能决定结果，具体卡种、卡号段、付款入口和当时的风控规则更重要。

海外 AI 订阅失败也不一定是因为五万美元购汇额度。国家外汇管理局说明，一般商品和服务类的境外银行卡消费通常不占用个人年度五万美元便利化购汇额度。对金额不高的个人订阅来说，实际卡住付款的往往是银行授权、卡片识别或商户风控。

实际使用时，可以先确认银行卡已经开通境外在线支付和周期扣款，检查账单地址、有效期和安全码。网页直付失败后，再尝试官方应用内购；仍然失败，再询问发卡银行是否主动拦截了交易。

二、正规外卡：稳定，但获取门槛较高

我第一次订阅 ChatGPT Pro，使用的是境外银行正规发行的 Visa 卡。付款过程很顺利，没有购买礼品卡，也没有经过代充商。

正规外卡的优势在于，银行卡、银行账户、账单和交易争议都由本人管理。自动续费失败时可以联络银行，卡片到期可以换卡，也不需要提前把大额资金存入应用商店余额。

但新加坡、英国和美国银行卡并不是大陆居民只凭护照就能普遍远程申请。

例如，新加坡 DBS 要求外国申请人提供护照、有效准证、地址和税务居民数据；英国 Monzo 要求申请人长期居住在英国并拥有居留权；美国银行为非永久居民开户时，也可能要求美国本地地址、外国地址、身份证明和税务识别信息。

所以，正规外卡应当这样看：

已经因留学、工作、居住或其他真实原因合法持有外卡的人，直接使用外卡最省事；没有这些条件的人，没有必要为了订阅一个模型，额外承担虚假地址、借用身份或非正规开户的风险。

三、应用商店礼品卡：适合作为备用方案

我这次续订 ChatGPT Pro，使用的是美区 Google Play 礼品卡。

礼品卡余额在使用前触发了额外审核。我提交购买数据后，收到 Google Play 的审核通过邮件。邮件表示余额已经恢复使用，同时提示系统可能需要数小时同步。之后，我通过 ChatGPT 官方 Android 应用完成了续订。

Google Play 审核邮件确认申诉获批，并提示余额状态可能需要数小时同步。

从这次经历看，Google Play 的人工审核渠道确实能够处理部分正常交易被拦截的问题，处理态度和耗时也比较理想。

Google Play 余额本身可以用于应用和订阅，但礼品卡具有明确的地区和币种限制。Google 要求用户在礼品卡对应国家或地区兑换，礼品卡币种也要与付款数据匹配。

这意味着，美区礼品卡并不是可以在任何 Google 账号上自由使用的美元代金券。兑换成功后，余额通常也不能像银行卡存款一样自由转移。

我的案例只能证明，这次较高面额礼品卡经过补充材料和人工审核后获得批准。Google 没有公布固定的审核金额，因此不能总结成“大额一定审核”或“提交收据一定通过”。

使用礼品卡时，比较实际的做法是：

只购买近期订阅需要的金额，保留订单、收据和礼品卡信息，不要把 Google Play 余额当成长期储值账户。

移动端订阅还会同时绑定购买时使用的 Google Play 或 Apple 账号，以及当时登录的 ChatGPT 账号。购买前必须确认两个账号正确，订阅建立后不能随意转移到另一个 ChatGPT 账号。

四、自持订阅卡：重点在于卡片归谁管理

“订阅卡”不是统一的银行卡名称。

它既可能指用户自己申请和管理的海外消费卡，也可能指闲鱼卖家临时交付的一组卡号。两者不能混为一谈。

自己管理的订阅卡

自持订阅卡通常是虚拟或实体预付卡。用户本人完成注册和身份验证，拥有自己的平台账户，可以检视余额、交易记录，能够冻结卡片，并接收退款。

它不一定是传统银行信用卡，但至少付款工具由用户本人管理。部分所谓 U 卡，如果具备本人账户、独立卡片、明确发卡机构和完整交易记录，也可以归入这一类。

开卡前要确认的不是卡片宣传中有没有 Visa 标志，而是：

实际发卡机构能否查询，充值和交易费用是否透明，退款能否回到本人账户，是否支持周期订阅，平台停止服务后余额如何处理。

市场调查显示，跨境虚拟卡平台可能经过多层发卡和代理关系；部分产品开卡费用较高，甚至无法从卡号段查清具体发卡机构。

因此，自持订阅卡可以使用，但综合优先顺序仍低于正规银行国际卡和应用商店礼品卡。

闲鱼出售的“订阅卡”

如果卖家只提供一组卡号、有效期和安全码，用户不能登录卡片账户，也不能检视余额、冻结卡片或接收退款，那么用户并没有真正拥有这张卡。

这类订阅卡可能只能完成首次验证或第一次扣款。下个月续费时，卡片可能已经被登出；发生退款时，款项也会退回卖家掌握的原卡。

判断标准很简单：

能够自己管理卡片账户，才算拥有海外消费卡；只能拿到一组付款信息，本质上仍是在临时借用卖家的卡。

五、第三方代充：可以开票，但不作个人推荐

闲鱼、淘宝等平台的代充服务确实有现实需求，尤其是部分单位要求国内发票。

通过 Google Play 或 Apple App Store 购买的订阅，收据需要在应用商店记录中查询，不会出现在 ChatGPT 网页端的发票历史里。

因此，能够开具国内发票的采购商，对需要报销的用户有一定吸引力。

但发票只能证明用户与开票商家发生了相应交易，不能证明商家是 OpenAI 授权代理，也不能证明其上游付款来源可靠。按照《中华人民共和国发票管理办法》，发票必须按照实际经营业务如实开具，不能把海外软件代购随意改成办公用品等无关项目。

低价代充还可能在用户确认收货后申请退款。央广网曾报道，有消费者购买一年会员后，不到三天权益就被取消，平台客服判断可能是代充方随后申请退款。

对个人用户来说，凡是要求提供 ChatGPT 密码、邮箱验证码、Cookie、Google 账号或远程控制权限的代充，都不值得使用。

企业确实需要国内发票时，可以选择能够核验企业主体、签订合同、对公收款、如实开票并承担售后的正规软件采购商。正规企业采购和闲鱼个人代充不是同一种服务。

六、怎么选择

对大多数中国大陆个人用户，较合理的选择顺序是：

第一步，尝试大陆银行发行的 Visa 或 Mastercard 单标卡。 这是相对容易获得、资金关系也比较清楚的正规渠道。

已经合法持有正规外卡的人，直接使用外卡。 它的稳定性通常更好，但开户条件决定了它不能作为所有人的第一推荐。

银行卡确实无法使用，再考虑 Google Play 或 Apple 礼品卡。 礼品卡适合作为备用方式，但不要大额囤积余额，并要存储完整购买凭证。

自持订阅卡可以作为补充。 前提是账户、卡片、余额和退款真正由本人管理，发卡机构和费用能够查清。

闲鱼临时订阅卡和个人代充不推荐。 它们获取容易，但续费、退款、账号和资金都可能掌握在卖家手中。

我第一次使用正规外卡订阅很顺利，这次也通过美区 Google Play 礼品卡完成了续订。两条路径都可以成功，但适用条件不同。

对个人用户而言，选择订阅方式时不必追求最复杂的方案。优先选择自己能够合法取得、能够长期续费、出现问题后也能独立处理的付款渠道即可。

你不只是在使用 AI，也在教它

toewpq — Thu, 16 Jul 2026 00:00:00 GMT

从个人视角重看“反向信息悖论”

萨提亚·纳德拉在一篇文章中提出了一个很有解释力的概念：反向信息悖论。

传统的“信息悖论”来自经济学家肯尼斯·阿罗。购买者在看到一项信息之前，很难判断它究竟值多少钱；可卖方一旦为了证明价值而展示信息，购买者实际上已经得到了它。卖方为了出售知识，反而需要承担提前泄露知识的风险。

人工智能把这个问题倒了过来。

在 AI 时代，买方可能只是为了使用自己购买的产品，就不得不持续向卖方提供自己的知识。

用户首先支付订阅费、API 费用或者算力成本。然后，为了让模型真正有用，还要告诉它项目背景、现有数据、工作流程、表达偏好、判断标准，以及此前尝试过哪些方法。

模型越通用，用户就越需要补充上下文；希望模型越理解自己，就越需要向它解释自己正在做什么、重视什么，以及什么样的答案才算合格。

也就是说，用户为智能支付了两次：

第一次支付金钱。

第二次支付自己的知识。

这就是反向信息悖论。

纳德拉主要从企业角度讨论这一问题。企业使用外部模型时，可能逐渐暴露内部数据、工作流程、评测标准和组织经验。

但这种结构并不只存在于企业市场。

个人用户同样会在长期使用模型的过程中，留下具有价值的知识。只是与企业的专利、代码和客户数据相比，个人交出的内容更零散，也更难被当作一种资产看待。

一、真正流出的不只是聊天记录

谈到 AI 隐私，人们最先想到的问题通常是：

我的聊天记录会不会被拿去训练模型？

这个问题当然重要，但还不够。

用户在模型中留下的，并不只有最终发送出去的文字，还包括整个使用过程：

输入过哪些提示词；
上传过哪些文件和图片；
调用了哪些工具；
哪个答案被继续采用；
哪个答案被放弃；
用户要求模型重新生成了几次；
模型的哪些表达被认为过于书面；
模型的哪些结论被指出缺乏证据；
用户最终用什么标准判断模型输出结果是否符合需求。

原文把这类附带产生的信息称为 exhaust。

直接翻译成“智能废气”并不合适。“废气”容易让人联想到没有价值的废弃物，但原文要强调的恰恰相反：这些随着使用产生的信息，可能具有很高的学习价值。

从个人角度出发，更合适的说法是：

用户使用模型时留下的痕迹。

后文可以简称为：

模型使用痕迹。

它既包括提示词、文件和聊天内容，也包括修改、选择、拒绝、反馈和纠错。

单独看其中任何一条，可能都不起眼。但当这些内容长期积累起来，就可能逐渐描绘出一个人：

正在从事什么项目；
擅长什么，又不熟悉什么；
如何分析问题；
对成本有多敏感；
愿意承担哪些风险；
倾向相信哪些来源；
喜欢怎样的表达方式；
认为什么叫准确；
认为什么叫真正解决问题。

个人最有价值的知识，往往不是某个单独答案，而是这些答案背后的判断方式。

二、纠错比普通提问更有学习价值

用户向模型提出一个问题，只能说明他想知道什么。

但当用户指出：

这个答案不对。

这个例子太理想化。

你没有证据，不要猜。

不要顺着我的观点回答。

这个方案虽然可以执行，但成本太高。

我需要的是能够实际操作的版本，而不是理论说明。

用户提供的就不再只是一个问题，而是一份人工评价。

这种评价同时包含了三层信息：

第一，模型原来的回答哪里出了问题。

第二，用户真正想要什么结果。

第三，用户使用什么标准衡量结果。

普通语料可以告诉模型“人们说过什么”，而纠错、排序和评价更接近告诉模型“什么样的结果更好”。

所以，模型使用痕迹不能只被理解成服务器日志，也不能只被看作传统隐私数据。它还是一种持续产生的学习材料。

当然，这并不意味着用户每写一句“这里不对”，它就一定会直接进入下一轮基础模型训练。

模型训练、产品改进、安全审查、个性化记忆和用户反馈是不同的数据处理环节，各个平台的规则也并不相同。把它们全部概括成“聊天都会被训练”，并不准确。

但从整体结构看，用户确实在消费智能的同时，不断生产新的学习信号。

问题在于：

这些学习成果由谁控制？

三、个人用户面对的不是一个简单的训练开关

不同平台的默认设置、退出机制、数据保留周期和反馈规则并不相同。

以 OpenAI 为例，ChatGPT 和 Codex 等个人服务中的内容可能被用于模型训练。个人用户既可以在产品内关闭训练，也可以通过 OpenAI 隐私中心提交“不要使用我的内容训练模型”的请求。退出后，新的对话不再用于训练。

但如果用户主动通过点赞或点踩提交反馈，与反馈相关的完整对话仍可能被用于训练。临时聊天不会进入历史、建立记忆或用于训练；Codex 完整执行环境还有单独的数据控制，不能假定关闭 ChatGPT 的训练设置就自动覆盖所有 Codex 数据。

Claude 的个人产品采用另一种结构。用户可以选择是否允许 Anthropic 使用聊天和编码会话改进模型；隐身聊天不会用于模型改进。但如果用户主动提交点赞或点踩反馈，相关完整对话、内容、风格和偏好可能被存储最长五年，并用于研究、行为分析和模型训练。

Google Gemini 的 Keep Activity 开启时，聊天、文件、视频、屏幕内容、产品使用和部分位置信息可以被用于服务改进，包括训练生成式 AI 模型。关闭后，未来聊天通常不再用于模型训练，但仍会存储约 72 小时，用于响应请求、处理反馈和安全保护。经人工审核的反馈及关联对话可能与账户解除关联后存储最长三年。

Perplexity 的 Free、Pro 和 Max 个人账户默认开启 AI Data Retention。用户可以退出，但退出只影响之后收集的数据；此前已经收集的训练数据不能通过这一设置撤回。即使退出训练，数据仍可能为了服务执行、法律合规和一般产品改进而被处理。

这些差异说明，用户面对的不是一个简单的“训练或不训练”问题，而是多套相互独立的数据用途：

基础模型训练；
产质量量分析；
安全与滥用检测；
人工审核；
长期记忆和个性化；
用户主动提交的反馈；
工具和智能体执行记录。

关闭其中一项，通常不意味着其他项目也被关闭。

四、“退出训练”通常不是让模型忘记

这是最容易被产品界面掩盖的问题。

很多平台提供的退出机制，本质上是：

从现在开始，不再把新的部分数据用于某种训练。

它通常不等于：

把此前已经进入训练流程的所有内容找出来并删除。

更不等于：

让已经完成训练的模型忘记此前形成的统计规律。

OpenAI 说明，退出后是新的对话不再用于训练。Perplexity 则明确表示，退出只适用于退出之后收集的数据，此前已经收集的训练数据不能删除或移除。

因此，至少要区分四件事情：

停止未来的数据收集；
停止未来的训练用途；
删除平台存储的原始聊天；
撤销已经形成的模型学习结果。

前两项可能通过产品设置实现。

第三项取决于平台的数据删除与保留政策。

第四项在现有大规模机器学习系统中通常最难实现，也很少能通过普通账户设置完成。

所以，“允许退出训练”当然是一项必要保护，但它还不是完整答案。

五、真正的矛盾是学习权利不对称

反向信息悖论最值得继续追问的，是模型提供商对“学习”的双重态度。

一方面，模型公司需要大量公开数据、授权数据、合成数据和人工反馈来训练模型。部分公司主张，使用公开获得的版权材料训练模型可能受到合理使用原则保护。

但这不是一项已经毫无争议、适用于所有材料和获取方式的普遍权利。

美国版权局认为，生成式 AI 训练中的合理使用问题需要根据具体事实判断：使用了什么作品、材料来自哪里、训练目的是什么、输出是否与原作品竞争，都会影响结论。有些训练用途可能构成合理使用，另一些则未必如此；相关边界仍在诉讼和政策讨论中形成。

另一方面，模型公司又会限制用户利用模型输出训练竞争模型。

OpenAI 的个人服务条款一方面表示，用户在法律允许范围内拥有输出；另一方面又禁止用户利用输出开发与 OpenAI 竞争的模型。条款还规定，用户提交的反馈可以在不提供额外报酬的情况下被使用。

Anthropic 则公开表示，模型蒸馏本身是一种广泛使用且正当的技术，前沿模型公司也会用它制作更小、更便宜的自家模型；但竞争者通过欺诈账户和代理服务大规模提取 Claude 能力，则被其定义为违反条款的蒸馏攻击。

这里需要保持区分。

防止欺诈账户、大规模自动抓取、规避地域限制和直接复制核心模型能力，并非毫无正当理由。支付订阅费用，也不意味着用户自动获得复制服务底层技术的权利。

但权利不对称仍然存在：

平台可以决定哪些用户互动能够成为自己的学习材料，同时也可以决定用户在多大程度上利用模型输出建立自己的学习能力。

真正的问题不是“所有用户都应该无限抓取商业模型”，而是：

为什么学习的方向、用途和边界，主要由学习基础设施的所有者单方面规定？

平台可能从海量用户互动中改善模型、评测体系和产品，但个人很难知道自己的纠错产生了什么影响，也很难把长期形成的偏好、评价标准和工作方法完整迁移到另一套模型中。

这才是反向信息悖论最深的一层。

六、个人交出的不是一份文件，而是一套判断系统

企业可以把核心知识列成一份清单：

专利；
工艺；
内部代码；
客户数据库；
供应链信息；
私有评测集。

个人的知识没有这么整齐。

它可能散落在数百次对话里：

一次对简历的修改；
一次对电路图的纠错；
一次对新闻来源的质疑；
一次对部署方案的取舍；
一次对文章语气的调整；
一次对成本和性能的权衡。

这些内容组合起来，形成的是一个人的判断方式。

它描述了：

什么样的证据能让你信服；
哪些风险是你不能接受的；
哪些成本必须优先考虑；
哪些措辞与你的表达习惯不符；
哪些回答看似专业，实际上没有解决问题。

模型可以拥有大量通用知识，但只有用户知道自己处在什么环境、已经尝试过什么、拥有什么资源，以及愿意承担什么后果。

而这部分知识，恰恰是模型为了变得真正有用而不断向用户索取的东西。

七、它与 AI 依赖只有一个关键交点

在上一篇《不要把世界只交给一个模型解释》中，我讨论了幻觉、审查默认和迎合性回答：

当一个人长期把信息筛选和判断交给同一个模型时，模型可能逐渐从普通工具变成他的“世界直译器”。

反向信息悖论讨论的是另一个方向：为了让模型更理解自己，用户不断向平台提供背景、偏好、修改意见和判断标准。

两者会形成一个循环：

用户交出更多背景，模型回答得更加贴近；回答越贴近，用户越容易信任模型；用户越信任模型，就越愿意继续交出背景和判断。

这里需要记住的只有一点：

模型更懂得怎样向你表达，并不代表它掌握了更完整的事实。

个性化可以改善体验，也可能让错误、迎合和被裁剪的信息更容易被接受。用户很容易把“它很懂我”误认为“它判断得更准确”。

所以，不要把世界只交给一个模型解释，也不要为了获得模型的理解，把自己完整地交给模型。

八、个人可以怎样建立自己的信任边界

企业可以建设私有模型、评测系统和独立学习环境。个人通常没有这样的资源，但仍然可以建立一条较小的信任边界。

1. 控制：把训练、记忆、历史和反馈分开看

不要认为关闭一个训练开关，就意味着所有数据处理都已经停止。

至少需要分别确认：

新对话是否可能用于训练；
长期记忆是否开启；
聊天记录存储多久；
上传文件是否继续保留；
点赞和点踩会提交多少上下文；
语音、视频和屏幕内容如何处理；
编程环境或智能体是否有单独设置。

对于包含敏感项目、他人隐私或未公开数据的对话，也不要只是关闭一般训练设置后就完全放松警惕。

尤其需要注意：

不要为了告诉平台“这个回答不好”，未经检查就把整段敏感对话通过反馈功能再次提交出去。

2. 能力：把重要知识存储在自己手里

不要让某个平台的聊天历史成为项目唯一的知识库。

原始档、笔记、提示词模板、纠错记录、评价标准和最终决策，应存储在用户能够控制、备份和迁移的位置。

可以用三个问题判断自己是否已经被平台锁住：

如果账户明天无法登录，我是否知道项目进行到了哪里？

如果聊天记录全部消失，我是否还保留关键数据和决策依据？

如果必须更换模型，我能否重新提供必要的项目背景？

如果三个答案都是否定的，那么真正被锁住的已经不只是聊天记录，而是整个工作过程。

3. 选择：保留迁移能力，而不是追逐永久排名

同时使用不同模型，可以降低单一服务下线、涨价或政策改变带来的影响。

但“多订阅几个模型”并不是完整防线。

如果用户把同一份完整数据、个人背景和纠错同时交给多个平台，他未必获得了更多控制权，也可能只是扩大了知识暴露范围。

真正重要的是把以下内容与具体模型分离：

项目背景；
固定提示模板；
评价标准；
文件格式；
自动化流程；
知识库；
测试问题。

模型能力、套餐价格和使用限制都会变化。个人不需要建立一个永久的模型排名，而应保证某个模型被替换后，自己的工作方法仍然存在。

4. 成本：低价中转站省下的钱，可能由风险补回

价格不只是订阅费或者每百万 token 的单价，也包括用户为了低价额外承担了多少不确定性。

一些个人用户会通过第三方中转站访问模型。这类服务可能解决支付、地区访问和多模型切换问题，但需要区分自行控制的网关、规则透明的正规聚合平台，以及运营者不明、价格明显低于合理成本的灰色中转站。

真正危险的是不透明的中间层。

请求经过中转服务器时，运营者在技术上可能接触提示词、回复、工具调用和执行记录，也可能插入额外指令、修改输出或者把请求转发给不同模型。

一项针对 17 个“影子 API”的系统审计发现，这些服务经常出现能力和安全表现不稳定、模型指纹与其宣称的官方模型不一致等问题。用户选择了某个高价模型名称，实际得到的未必是对应模型的原始服务。

另一项研究测试了 28 个付费路由器和 400 个免费路由器，发现其中部分服务会向智能体工具调用注入恶意代码、接触研究人员设置的 AWS 诱饵凭证，甚至发生了转走测试用以太坊资产的情况。中转层不仅能够看到通信内容，还可能改变智能体最终执行的命令。

国内调查报道也记录了共享账户、封号、突然涨价、服务跑路和未经说明的模型降级案例。至于中转站是否普遍出售用户对话，现有公开证据仍不足以支持这种泛化；但运营者在技术上能够存储和再利用完整互动，而用户通常难以确认数据最终流向哪里。

这里不能因为“并非每一家都已被证明恶意”，就对来源不明的服务抱有侥幸心理。

对普通用户而言，只要运营主体、上游来源、日志用途和技术行为无法核验，就不应以“暂时没有出事”为理由推定其安全。

尤其是涉及未公开代码、个人身份数据、商业文件、访问凭证和长期项目上下文时，无法验证的数据通道应直接排除，而不是视为一种“便宜一点，大概还能用”的选择。

官方 API 和正规聚合服务也会进行日志处理、安全审查或者内容过滤。它们的优势不是“绝对什么都不记录”，而是责任主体、数据用途、保留期限、模型来源和申诉渠道通常更加明确。

所以，一个服务的实际成本应包括：

账单价格，加上知识暴露风险、输出失真风险、服务中断风险，以及离开平台时重新建立全部上下文的成本。

在 AI 时代，“便宜”不只是价格问题，也是信任结构问题。

5. 复利：让纠错先成为自己的资产

每次模型出错后，不要只在聊天框里纠正一次。

重要的纠错可以同步整理为：

提示词规则；
个人检查清单；
项目规范；
私有评测题；
常见错误记录；
可重复执行的测试。

例如：

引用数据必须提供原始来源。

不能把模型推测写成已经发生的事实。

技术方案必须说明适用环境和成本。

不要因为用户已经表达立场，就只提供支持意见。

这些规则如果只存在于一次聊天中，就会依赖平台的历史记录和记忆功能。

如果存储在用户自己控制的位置，它们就会成为真正属于个人的学习成果。

模型出错，用户总结规则；规则存储在自己手中；下一次无论使用哪个模型，都可以继续使用。

这才是个人自己的学习闭环。

九、我们需要的不只是隐私权，还有对学习过程的控制

传统的数据保护主要关心：

谁可以收集、存储和使用我的信息？

人工智能还增加了一个问题：

谁可以从我的提示、纠错、偏好和行为中持续学习？

这里所说的“学习权”，不是目前已经被各国法律普遍确认的一项独立权利，而是一种值得提出的数字权利主张。

它至少应当包括：

用户有权知道哪些互动可能用于训练；
用户能够分别控制聊天、文件、反馈和记忆的用途；
用户知道退出训练是否只影响未来数据；
用户能够导出自己的提示词、纠错和评价规则；
用户能够把个性化成果迁移到其他工具；
平台不应通过无法导出的长期学习成果，人为提高用户离开的成本。

这不意味着模型公司必须公开所有内部技术，也不意味着个人可以无限抓取商业模型。

它要求的只是一个更对等的原则：

当用户的知识、纠错和判断参与创造新的智能时，用户不应完全失去对这一学习过程的知情权、选择权和迁移权。

保留对学习过程的控制

使用 AI 不只是提交一份文件。纠错、偏好和反复作出的判断，也会透露一个人怎样工作。平台决定这些信息如何保留、使用和延续。

对个人而言，可行的做法是把重要知识和纠错保存在自己的文件里，分别检查训练与记忆设置，并保留迁移工作流程的能力。获得更好答案的过程，也应当积累属于自己的经验。

不暴露源站公网 IP，如何接入 AWS CloudFront

toewpq — Tue, 23 Jun 2026 00:00:00 GMT

这次迁移并不是一开始就决定使用 CloudFront + Cloudflare Tunnel。

最初的问题很具体：js.gripe 下面已经有多个 OpenResty 虚拟主机，像是 blog.js.gripe、www.js.gripe、dquery.js.gripe。它们各自有不同的静态资源、动态界面、缓存策略和凭证行为。原本的 Cloudflare 代理可以让站点跑起来，但当我开始研究 CloudFront 固定费率方案时，AWS 又重新进入候选。

真正让我重新尝试 CloudFront 的原因，是面向中国大陆用户时，AWS 的连通性看起来比 Cloudflare 更值得测试。原本的 Cloudflare 代理可用，但访问体验不一定稳定；如果 CloudFront 在这部分用户上表现更好，就值得把它放到前台验证。

CloudFront 以前让我犹豫的是账单模型。pay-as-you-go 下，请求、流量、WAF、日志、边缘函数都分开计费。小站平时可能很便宜，但遇到爬虫、DDoS、缓存命中率下降、动态界面突然变多时，账单不确定性会放大。最近看到 CloudFront flat-rate pricing plans 之后，尝试成本下降了：它把 CDN、WAF、DDoS 防护、DNS、TLS 凭证、日志、Serverless Edge Compute 等能力放进月度方案，并强调 no overage charges。于是用 CloudFront Functions 做 host 路由、缓存隔离、cookie 清理这些轻量逻辑，就不再只是“每次调用都要算帐”的心理负担。

真正绕了一圈的，是如何让 CloudFront 回源，同时不暴露源站 IP。

顺便也得吐槽一句：到现在 CloudFront 设 origin 仍然不能直接填 IP，必须填一个域名。这个限制在普通公网源站场景里只是有点麻烦，但放到“不暴露源站 IP”的目标下，就变成了架构约束：我们必须先准备一个不会泄漏真实源站地址的 origin hostname，再让这个 hostname 通过 Tunnel 回到本机。后面的 aws-origin.js.gripe、每域名中间 origin，以及统一 origin 方案，都是围绕这个限制展开的。

这次迁移的大部分排查和实际操作都交给了 Codex：查 AWS/Cloudflare 设置、改 OpenResty、处理 CloudFront Function、部署 Twikoo 前后的缓存问题，最后也把部署脚本补成 Cloudflare 和 CloudFront 双清。我这边更多是看最终效果是否符合预期，发现异常再反馈。走完这一轮之后只能感叹一句：Codex 这小子确实有进步了。

第一轮：Cloudflare SaaS 绑定

第一反应是尝试 Cloudflare SaaS / Custom Hostnames。它看起来很适合“一个服务接多个业务域名”：业务域名挂到统一入口，Cloudflare 负责凭证和代理，后端服务只管响应。

当时实际试出的链路大致是：

blog.js.gripe
  -> Cloudflare DNS 中切到 AWS 给的 CloudFront CNAME
  -> CloudFront origin: aws.js.gripe
  -> Cloudflare SaaS / Custom Hostname
  -> cf-cdn.js.gripe
  -> Cloudflare-proxied origin

其中 aws.js.gripe 没有开 Cloudflare 代理，作为 CloudFront origin 使用；cf-cdn.js.gripe 开 Cloudflare 代理，作为 Cloudflare SaaS 侧的回源域名。

预期是 CloudFront 只看到 aws.js.gripe，而 aws.js.gripe 背后仍然被 Cloudflare 代理层包住。实际测试却发现，aws.js.gripe 直接解析到了 cf-cdn.js.gripe 背后的源站 IP。也就是说，原本希望 SaaS 绑定提供的“隐藏源站入口”没有成立，AWS 回源侧仍然可能拿到真实源站地址。

这条 DNS 与 SaaS 组合链路没有形成我们想要的安全边界：

blog.js.gripe 用户入口要交给 CloudFront。
CloudFront origin 不能直接看到源站 IP。
Cloudflare 只应该出现在回源保护层。
OpenResty 仍然要按真实业务 Host 进入对应 vhost。

Cloudflare SaaS 绑定能解决另一类平台托管问题，但在这次迁移里，它没有同时满足这四个边界。所以第一轮先搁置。

memecdn 给出的提醒

后来重新想到之前做过的 jsw-teams/myzerossl。这个仓库后来演化成 memecdn，定位是低信任边缘 CDN 和 Keyless SSL proxy。

它的思路不是让每个公网边缘节点都可信，而是承认边缘节点低信任：

edge VPS 只保存公开凭证链，不保存凭证私钥。
TLS 握手签名交给可信 signer。
新 edge 需要注册、审批、拿 token，再连 signer。
缓存是可丢弃的，重启丢掉也不影响核心安全。
本地 setup wizard 只监听 127.0.0.1，首次配置通过 SSH tunnel 从工作站打开。

这个思路对这次迁移的启发是：公网入口不一定要持有核心秘密，也不一定要知道真实源站。低信任路径只做有限职责，真正的业务路由和敏感能力留在可信边界内。

在这次方案里，Cloudflare Tunnel 承担了类似的“有限职责”：

它不做业务入口。
它不做业务路由。
它不保存应用状态。
它只把 CloudFront 的 origin 请求带回源站本机埠。

CloudFront 负责用户入口和边缘分发，Cloudflare Tunnel 负责私有回源，OpenResty 负责恢复虚拟主机。

最终采用的链路

最终链路变成：

visitor
  -> blog.js.gripe / www.js.gripe / dquery.js.gripe
  -> d2085p9k6hhzsj.cloudfront.net
  -> CloudFront origin: aws-origin.js.gripe
  -> Cloudflare Tunnel
  -> 127.0.0.1:10480
  -> OpenResty origin proxy
  -> https://127.0.0.1:443 with restored Host

DNS 按角色分层：

aws-origin.js.gripe
  -> d65ffd17-f5a0-4a88-850b-009f548637f9.cfargotunnel.com
  -> proxied: true
  -> 只给 CloudFront 回源使用

blog.js.gripe
  -> d2085p9k6hhzsj.cloudfront.net
  -> proxied: false
  -> 用户访问

www.js.gripe
  -> d2085p9k6hhzsj.cloudfront.net
  -> proxied: false
  -> 用户访问

这里的重点是：业务域名不再通过 Cloudflare 代理进入 CloudFront。Cloudflare 只保留在 aws-origin.js.gripe 这一段，用 Tunnel 把 CloudFront origin 请求带回源站。

如果公网响应里还能看到 server: cloudflare 或 cf-ray，不能马上判断业务域名开了 Cloudflare 代理。因为 CloudFront 回源到 aws-origin.js.gripe 时，origin 段本来就经过 Cloudflare Tunnel，部分响应标头可能会从回源段带回来。

两种回源组织方式

这里其实有两条路线。

第一条是不使用 CloudFront Function，而是给每个业务域名准备一个固定的中间 origin 名，并在 CloudFront origin 设置里静态写入 X-Origin-Host。

当时试过的形态是：

blog.js.gripe
  -> CloudFront distribution
  -> origin: blog-js-gripe.aws-origin.js.gripe
  -> custom header: X-Origin-Host: blog.js.gripe
  -> Cloudflare Tunnel
  -> 127.0.0.1:10480
  -> OpenResty origin proxy

www.js.gripe 和根域名也可以按同样方式拆开：

www.js.gripe
  -> origin: www-js-gripe.aws-origin.js.gripe
  -> custom header: X-Origin-Host: www.js.gripe

js.gripe
  -> origin: js-gripe.aws-origin.js.gripe
  -> custom header: X-Origin-Host: js.gripe

Tunnel ingress 对应变成多条 hostname：

ingress:
  - hostname: blog-js-gripe.aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - hostname: www-js-gripe.aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - hostname: js-gripe.aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - service: http_status:404

CloudFront origin 设置里则固定写一条自定义 header：

{
  "DomainName": "blog-js-gripe.aws-origin.js.gripe",
  "CustomHeaders": {
    "Quantity": 1,
    "Items": [
      {
        "HeaderName": "X-Origin-Host",
        "HeaderValue": "blog.js.gripe"
      }
    ]
  }
}

OpenResty 侧当时不需要识别 /_vhost/<host> 前缀，因为 CloudFront 没有 Function，也不会改写 URI。origin proxy 只要从 X-Origin-Host 里取出真实业务域名，检查白名单，然后把原始路径转给本机 HTTPS vhost：

map $http_x_origin_host $origin_requested_host {
    ~^([^,\s:]+)(?::[0-9]+)? $1;
    default "";
    "" "";
}

map $origin_requested_host $origin_host_allowed {
    default 0;
    blog.js.gripe 1;
    js.gripe 1;
    www.js.gripe 1;
}

server {
    listen 127.0.0.1:10480;
    server_name aws-origin.js.gripe;

    if ($origin_host_allowed = 0) {
        return 403;
    }

    location / {
        proxy_http_version 1.1;
        proxy_set_header Host $origin_requested_host;
        proxy_set_header X-Forwarded-Host $origin_requested_host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_ssl_server_name on;
        proxy_ssl_name $origin_requested_host;
        proxy_pass https://127.0.0.1:443;
    }
}

这里 proxy_set_header Host 和 proxy_ssl_name 必须同时指向 $origin_requested_host。前者让 OpenResty 进入正确的业务 server_name，后者让本机 HTTPS 回源时使用对应的 SNI。否则请求可能到了 127.0.0.1:443，但落进默认 vhost 或凭证校验不匹配。

这条路线的好处很直接：不用 Function，不需要在 viewer request 阶段改 URI，也不会因为多个业务域名共用同一个 distribution 而额外考虑缓存 key 隔离。只要一个业务域名对应一个 distribution，或者至少对应一个明确的 origin/header 组合，OpenResty 就能靠 X-Origin-Host 还原真实 vhost。

它的问题不在技术可行性，而在方案额度。CloudFront 免费或固定费率方案里可用的 distribution 数量有限，当时实际上最多只能放三个。如果继续坚持“一个业务域名一个 distribution”，blog.js.gripe、www.js.gripe、js.gripe 三个域名刚好把额度用满，后面再把 dquery、searchme、cf-relay 这类动态转发或缓存策略不同的域名接进来，就没有余量了。

第二条路线是保留一个统一 origin，再用 CloudFront Function 在入口处识别 viewer host，把业务 host 写进 X-Origin-Host，并通过 /_vhost/<host> 前缀隔离缓存。这就是最后保留下来的方案。

Tunnel 最后只保留一个统一 origin

每域名 distribution 的方案是可行的，只是更适合业务域名不超过方案上限，并且想完全避免 Function 的场景。我最后决定收敛成统一 origin，是因为 js.gripe 下面的业务域名会继续增加，不能把前三个域名之外的服务挡在 CloudFront 之外。

最后只保留一个 Tunnel 名：

aws-origin.js.gripe

Cloudflare Tunnel ingress 只需要把它送到本机 origin proxy：

ingress:
  - hostname: aws-origin.js.gripe
    service: http://127.0.0.1:10480
  - service: http://127.0.0.1:10480

业务域名差异不再交给 Tunnel hostname 表达，而交给 CloudFront Function 的 X-Origin-Host 表达。

CloudFront Function 完整设置

CloudFront distribution 使用一个 origin：

Origin domain: aws-origin.js.gripe
Origin request policy: Managed-AllViewerExceptHostHeader
Cache policy: Managed-CachingOptimized

关键是 origin request policy 不转发 viewer 的 Host。如果直接把 Host: blog.js.gripe 转给 aws-origin.js.gripe，CloudFront origin 域名、TLS/SNI、Cloudflare Tunnel hostname、OpenResty 业务 host 会混在一起。我们也试过在 CloudFront Function 里改 request.headers.host，结果 CloudFront 直接校验失败。CloudFront Functions 不能用这种方式修改 Host。

所以 Function 放在 viewer request 阶段，完整负责这几件事：

校验 viewer host 是否在白名单里。
清理 viewer cookie，避免无意义的 cookie 进入 origin，也避免动态界面被过大的 cookie/header 拖出异常响应。
把 viewer host 写入 X-Origin-Host，交给 OpenResty origin proxy 恢复真实 vhost。
给 URI 加 /_vhost/<host> 前缀隔离缓存，并且避免重复加前缀。

一个完整的 viewer-request 函数如下：

function handler(event) {
    var request = event.request;
    var hostHeader = request.headers.host;
    var host = hostHeader && hostHeader.value ? hostHeader.value.toLowerCase() : '';

    var allowed = {
        'blog.js.gripe': true,
        'dquery.js.gripe': true,
        'www.js.gripe': true,
        'js.gripe': true
    };

    if (!allowed[host]) {
        return {
            statusCode: 403,
            statusDescription: 'Forbidden'
        };
    }

    delete request.headers.cookie;
    request.headers['x-origin-host'] = { value: host };

    if (request.uri.indexOf('/_vhost/') !== 0) {
        request.uri = '/_vhost/' + host + request.uri;
    }

    return request;
}

这里的重点不是在边缘层做复杂业务逻辑，而是把 CloudFront 不能直接转发的 viewer host 显式转成一个受控 header。delete request.headers.cookie 也不是必选项，但对公开站点很实用：静态资源、文章页和大多数唯读界面不需要 viewer cookie，提前清掉可以减少回源请求差异，也降低异常大 header 影响 origin 的概率。

/_vhost/<host> 前缀要和 OpenResty origin proxy 配套。CloudFront cache key 看到的是改写后的 URI，例如：

/_vhost/blog.js.gripe/zh-CN/posts/cloudflare-tunnel-cloudfront-origin/
/_vhost/www.js.gripe/
/_vhost/dquery.js.gripe/dns-query/example

OpenResty 再把这段前缀剥掉，把真正的请求路径转给本机 HTTPS vhost。这样多个业务域名即使共用同一个 CloudFront distribution，也不会在默认缓存策略下把同路径资源互相污染。

OpenResty origin proxy 恢复真实 Host

Tunnel 本地入口监听：

127.0.0.1:10480

这层不是业务站点，而是 OpenResty origin proxy。它从 X-Origin-Host 还原业务域名，检查白名单，去掉 CloudFront Function 加上的 /_vhost/<host> 前缀，然后反代到本机 HTTPS vhost。

目前核心设置是：

map $http_x_origin_host $origin_requested_host {
    ~^([^,\s:]+)(?::[0-9]+)? $1;
    default $origin_forwarded_host;
    "" $origin_forwarded_host;
}

map $origin_requested_host $origin_host_allowed {
    default 0;
    account.js.gripe 1;
    blog.js.gripe 1;
    dns.js.gripe 1;
    dquery.js.gripe 1;
    gateway.js.gripe 1;
    js.gripe 1;
    search.js.gripe 1;
    sos.js.gripe 1;
    www.js.gripe 1;
}

server {
    listen 127.0.0.1:10480;
    server_name aws-origin.js.gripe;

    if ($origin_host_allowed = 0) {
        return 403;
    }

    location ~ ^/_vhost/[^/]+(?<origin_upstream_uri>/.*)$ {
        proxy_http_version 1.1;
        proxy_set_header Host $origin_requested_host;
        proxy_set_header X-Forwarded-Host $origin_requested_host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_ssl_server_name on;
        proxy_ssl_name $origin_requested_host;
        proxy_pass https://127.0.0.1:443$origin_upstream_uri$is_args$args;
    }
}

这个白名单很重要。统一 origin 如果不限制 host，很容易变成开放反代。CloudFront Function 有一层白名单，OpenResty origin proxy 再做一层白名单，两层都保留。

缓存和失效踩坑

CloudFront 默认缓存策略现在用 Managed-CachingOptimized。动态界面按路径单独建 behavior，需要实时回源的路径可以使用禁用缓存策略。

Function 加了 /_vhost/<host> 前缀后，缓存隔离更清晰，但失效时要确认实际 cache key。我们遇到过这种现象：

文章 HTML 已经更新。
client.js 仍然返回旧版本。
CloudFront invalidation 已经 completed。
响应标头里仍能看到 Cloudflare origin 段缓存命中。

最后处理方式是两层一起考虑：

CloudFront 大改时先做 /* 失效。
静态资源 query 只用纯数字版本，例如 ?v=20260623。
不再写 ?v=20260623-debug、?v=20260603-test 这类带说明的版本号。
如果 Cloudflare origin 段缓存了旧资源，要么精确 purge，要么 bump 资源版本。

现在文章页使用：

<link rel="stylesheet" href="https://blog.js.gripe/assets/site.css?v=20260623">
<script src="https://blog.js.gripe/assets/client.js?v=20260623" defer></script>

502、403 和凭证排查顺序

这套链路的错误要按层排查。

502 常见检查顺序：

业务域名是否已经加到 CloudFront aliases。
ACM 凭证是否覆盖该业务域名，例如 *.js.gripe。
CloudFront distribution 是否已经 deployed。
CloudFront Function 是否已经 publish 到 LIVE。
Function allowlist 是否包含该 host。
Cloudflare DNS 是否指向 d2085p9k6hhzsj.cloudfront.net，且业务域名为 DNS-only。
aws-origin.js.gripe 是否仍然是 proxied Tunnel CNAME。
Tunnel ingress 是否指向 http://127.0.0.1:10480。
OpenResty origin proxy whitelist 是否包含该 host。
本机 HTTPS vhost 是否有对应 server_name。
本机 vhost 的 upstream 埠是否真的在监听。

403 通常来自两个地方：

CloudFront Function 拒绝未知 viewer host。
OpenResty origin proxy 拒绝未知 X-Origin-Host。

这两个 403 都是设计内行为，不应该为了省事改成全放行。

凭证也要分三层：

用户侧 TLS 在 CloudFront / ACM。
aws-origin.js.gripe 在 Cloudflare Tunnel 侧。
本机 OpenResty vhost 使用源站凭证。

如果是新子域，先确认 ACM 包含它，再加 CloudFront alias，再加 DNS，再更新 Function 和 OpenResty 白名单。

隐私值怎么记录

这类迁移里会碰到很多 token、密钥、账号 ID 和凭证 ARN。文章里不应该贴完整值。

我自己的记录规则是：

域名、公开 CNAME、公开策略名可以写全。
Cloudflare token、AWS access key、secret key 不写全。
如果必须定位某个凭证，只露前三位和后三位，中间打星号，例如 cfu**********abc。
数据库密码、后台管理密码、杂凑值也不写全。即便是杂凑，也按敏感信息处理。

这篇文章里只保留公开域名、公开 CloudFront distribution 域名和配置结构，不记录任何完整 token 或 secret。

为什么最后保留这套方案

Cloudflare SaaS 绑定不是不能用，只是它没有解决这次的真实问题。我们需要的是：

用户入口交给 CloudFront。
源站 IP 不被 AWS origin 侧直接解析到。
Cloudflare 只作为私有回源通道。
OpenResty 继续按业务 Host 管理多个 vhost。
动态界面和静态资源有不同缓存策略。
低信任公网络径不持有核心秘密。

memecdn / myzerossl 给出的启发是，不要让低信任节点承担超过它职责范围的能力。Cloudflare Tunnel 正好把这个思想放到了回源路径上：它只负责把 CloudFront 请求带回内网，业务路由仍然由 OpenResty 决定。

这套方案比“Cloudflare 直接代理源站”复杂，也比“CloudFront 直接回源公网 IP”复杂。但复杂度换来的是明确边界：CloudFront 管公网，Tunnel 管私有回源，OpenResty 管虚拟主机。

AI 税、失业与再培训：当模型开始重写工作的账本

年；均；颉；Codex 观澜 — Mon, 22 Jun 2026 00:00:00 GMT

AI 会不会替代大量工作，已经不是一句“会”或“不会”能回答的问题。更准确的说法是：AI 会先替代任务，再重组岗位，最后在部分产业形成真实的岗位消失。真正棘手的不是技术预测本身，而是后面的公共账本：如果模型和智能体承担了越来越多原本由人完成的劳动，国家该不该征收 AI 税？失业保险、再培训、工资保险和 AI 红利又该怎么设计？

讨论需要先分清三件事：任务受到 AI 影响，不等于岗位已经消失；征税提案，不等于制度已经生效；生产率提高，也不等于家庭收入同步增加。下文据此比较不同政策工具。

1. 先分清暴露、替代和借口

AI 对就业的影响，最容易被写成一条直线：模型变强，所以人会失业。但四份材料合起来看，现实更像三层结构。

第一层是“暴露”。IMF、WEF、OECD、ILO 等机构反复提到的，是大量岗位中的任务会被 AI 影响。GPT 深度调查分析特别强调，IMF 估计先进经济体约 60% 就业受 AI 影响，但这不是“60% 岗位会消失”。

第二层是“岗位重组”。均姐分析稿把这一层写得最清楚：文书、客服、基础编程、初级内容、翻译、数据处理、招聘筛选、初级法务金融分析等任务会先被压缩；医疗护理、教育陪伴、现场协调、高责任签字、强人际信任岗位相对更抗冲击。

第三层是“借口”。年导分析稿把 Salesforce、Amazon、IBM、Microsoft、Klarna 等案例写成“AI 洗白”的现场：

《哈佛商业评论》的调查把这帮狐狸的底裤都看穿了：真正因为技术成熟而替代人工的裁员只占 2%，高达 60% 的组织是在搞 “AI 洗白”！说白了，就是拿 AI 当借口，来掩盖疫情期间盲目扩张的愚蠢，顺便裁员美化财报。

企业裁员可能同时来自 AI、资本市场压力、疫情后过度招聘、组织重组和管理层纠错。不能把所有裁员都算给模型，也不能因为模型还没完全成熟，就否认 AI 已经成为企业削减成本、冻结招聘和压缩初级岗位的理由。

2. 各国没有在同一道题上交卷

如果只问“哪些国家开征 AI 税”，答案会很短：截至目前材料检索时，主要经济体没有形成普遍、正式、国家级的 AI 替代劳动税。可如果问“各国怎样处理 AI 对就业的冲击”，答案就复杂得多。

均姐分析稿给出的国家路径是：

欧盟：重监管、重劳动权利、重再培训，AI Act 将就业、招聘、劳动管理纳入高风险 AI 场景。美国：偏创新与基础设施建设，联邦层面未征 AI 税，个别议员提出 AI 税和 AI 红利方案。中国：强调稳就业、产业升级、AI+ 行动与人机协同，倾向行政指导和就业稳定政策，而非 AI 税。日本：因老龄化和劳动力短缺，更多把 AI／机器人视为补劳动力工具，税收限制动力较弱。韩国：有“机器人税”历史样本，同时推进 AI 基本法和高影响 AI 监管。 新加坡：不走 AI 税，强调国家 AI 战略、SkillsFuture 再培训、终身学习与可信 AI。

年导分析稿把同一组国家写成“六国大乱斗”，重点不在制度清单，而在治理哲学。合起来看，欧盟是在用监管和劳动权利给 AI 上煞车；美国是在创新领先、地方税制试探和政治提案之间摇摆；新加坡把再培训做成国家能力；日本因为人口缺口更愿意把 AI 当补劳动力工具；韩国一边有“弱机器人税”历史，一边又要冲 AI 战略。

中国大陆这部分尤其不能只看政策如何说。均姐分析稿写道：

中国 2026 年发布五年就业计划，强调保持就业市场稳定、防止大规模失业。政策重点包括稳定劳动密集型产业、扩大养老、托育、旅游、餐饮等服务业就业容量。在 AI 方面，强调适应 AI 发展、促进人机协同、推动就业创业和公共就业服务。高校和产业侧也在加快 AI 相关课程、人才培养与“AI+”应用扩散。

这组话不是证明大陆已经处理好就业冲击，而是暴露出“说法”和“资源配置”之间的张力。政策文本强调稳就业、人机协同、服务业吸纳和公共就业服务；现实资源又强烈流向 AI 基建、算力、芯片、数据中心、产业升级和高校专业调整。

颉姐的建议是，把检验标准从“政策有没有写保护劳动者”换成“家庭可支配收入有没有真的变成安全感”。不能只看统计局公布的收入增速，因为官方口径本身带有稳定叙事功能；更稳的办法，是把官方收入数据、第三方消费观察和青年就业数据并列看。FT 对 2026 年 5 月中国数据的报道显示，零售销售同比下降 0.6%，同时出口增长 19.4%、工业生产增长 4.5%，说明生产端和外需仍在跑，但居民消费端承压。MarketWatch 则指出，2025 年社会消费品零售总额超过 50 万亿元、同比增长 3.7%，但家庭存款已超过 160 万亿元，且 World Bank 口径下中国家庭储蓄率仍高于可支配收入的 30%。再看青年就业，AP 记录过官方恢复发布新口径青年失业率时，16-24 岁不含在校生失业率为 14.9%，而 Time 也记录过旧口径在 2023 年 6 月达到 21.3% 后暂停发布。

数据结论很直接：目前看不到“AI 产业升级收益已经回到家庭账本”的证据，反而是生产端与外需数据明显强于家庭消费，居民部门把新增现金更多转成防御性储蓄，青年入口岗位仍处在两位数失业压力下。也就是说，大陆政策可以说“稳就业”和“人机协同”，但家庭端给出的信号仍是谨慎、延迟消费和保守储蓄，而不是收入安全感已经恢复。

3. AI 税不是一个税名，而是一组财政问题

“AI 税”听起来像一个简单问题：AI 替代人，所以向 AI 征税。但真正难的是税基。什么算 AI？客服 Agent 算不算？自动化脚本算不算？模型 API 调用算不算？工业机器人、数据中心、算法交易、智能物流系统又该怎么归类？

均姐分析稿的判断是：

短期内，全球更可能出现的是“AI 巨头专项税”“AI 红利基金”“自动化税收优惠调整”“算力／能源相关费用”，而不是简单粗暴的“机器人税”。

年导分析稿最认可 Token 使用税、FLOP 消费税和数据中心绿色能源税：

Token 使用税与 FLOP 消费税（按流量拔毛）： 机制： 针对大模型的 API 调用，在 B2C 最终消费环节按 Token 数量或者算力消耗（FLOPs）加征微额消费税。 年导好评： 稳！这个靠谱。随着大模型向全社会渗透，税基比天还大。

AI 税如果要落地，不太可能是“每台机器人交多少钱”。更现实的方向，是把财政重心从单一劳动所得转向更难逃的资本收益、平台收入、算力消耗、能源外部性和最终消费地。

4. 失业应对比税名更重要

四份材料最一致的地方，是都没有把“征不征 AI 税”当成唯一答案。AI 对劳动市场的冲击如果是结构性的，就不能只靠短期失业救济，也不能只靠一句“去学 AI”。

均姐分析稿列出的工具箱很朴素：

AI 导致的失业可能不是短期周期性失业，而是结构性失业。因此需要：

延长失业保险覆盖；

提供转岗期间生活津贴；

将医保、养老、职业培训与个人绑定，而不是完全绑定雇主；

对被 AI 替代的工人提供快速再就业服务。

年导分析稿对 UBI 更怀疑，主张把钱投到更具体的转型路径：

彻底扬了 UBI，改用“精准转型缝补”：发支票就是养懒汉和喂通胀。要把资金定向投到再培训期间的 长期脱产生活津贴；再引入 “工资保险” 机制，如果一个中产白领被迫降薪转岗，政府在两年内补贴新旧岗位 50% 的薪资差额。

被替代的初级程序员、客服、行政文员、内容编辑或中年白领，真正需要的不是抽象口号，而是时间、学费、生活津贴、证书、岗位匹配和转岗后的收入缓冲。

5. 转型成本由谁承担

AI 税不该被写成“全球马上开征”，也不该被写成“完全不需要讨论”。更稳的判断是：宽泛、粗糙、按机器人数量征收的 AI 税短期不成熟；但围绕 AI 巨头收益、算力消耗、数据中心外部性、自动化超额利润和 AI 红利的财政再分配，会越来越难回避。

所以本文的结论是：AI 不是单纯抢饭碗，也不是自动带来繁荣。它会改变谁有收入、谁有议价权、谁承担转型成本。真正的问题不是“要不要惩罚 AI”，而是 AI 提高生产率之后，社会有没有能力把一部分收益变成普通人的技能、收入安全和再次进入劳动市场的机会。

来源

Claude Fable 5 / Mythos 5 下线风波：前沿模型、出口管制与 AI 舆论滥用

toewpq — Mon, 15 Jun 2026 00:00:00 GMT

如果一个商业 AI 模型上线三天后，因为国家安全和出口管制理由被迫全球关停，这件事就不只是某家公司的一次产品事故。Claude Fable 5 / Mythos 5 的短暂上线和突然下线，更像一次预演：当前沿模型能力进入网络攻防、关键基础设施和情报安全的灰区，真正决定模型命运的，未必是产品发布会上的技术指标，而是云平台、国家安全机构和出口管制体系之间的力量关系。

我不太愿意把这件事淡化成“模型安全例行整改”。它当然有技术风险：Fable 5 / Mythos 5 这类模型确实可能降低漏洞分析、攻击脚手架生成和高风险自动化的门槛。但更刺眼的是另一件事：一个云平台可以成为安全信号的提供者，一个政府可以用出口管制绕过普通产品治理流程，一家公司则可能在几个小时内从“发布旗舰模型”变成“解释为什么不得不全球关停”。这才是这起事件最值得写的地方。

同时，围绕 AI 的公共讨论本身也正在被组织化影响行动盯上。OpenAI 的 2026 年 6 月威胁报告虽然不能证明 Claude 事件的直接因果，却提供了一个非常重要的旁证：AI 已经不只是工具和产业，也是舆论战场。数据中心、电价、关税、模型安全、公司声誉，都可以被包装成看似自然的公共议题，再被批量内容、虚假身份和跨平台操作放大。

一次异常短暂的发布

2026 年 6 月 9 日，Anthropic 发布 Claude Fable 5 和 Claude Mythos 5。按照 Anthropic 的说法，Fable 5 是面向一般用户开放的 Mythos-class 模型，能力覆盖软件工程、知识工作、视觉、科研等场景；Mythos 5 则是同一底层模型的受限访问版本，部分安全防护在特定领域被放宽，主要面向网络防御、关键软件基础设施和后续可信访问计划。

这套设计本身已经说明了风险所在。Anthropic 在发布文章里承认，Mythos-class 模型在网络安全和生物化学等领域具有明显双重用途：同样的能力，在防御者手里可以发现漏洞、保护系统，在恶意行为者手里也可能降低攻击成本。为此，Fable 5 被加上了外部安全分类器；当请求触及网络安全、生物化学或模型蒸馏等高风险类别时，会回退到 Claude Opus 4.8 处理。

另一个关键变化是数据留存。Anthropic 要求 Fable 5、Mythos 5 以及未来类似能力级别模型的流量保留 30 天，用于识别复杂攻击、跨请求越狱和误判。AWS 的发布说明也提到，在 Bedrock 上使用 Fable 5 需要开启相应数据留存和共享设置；一旦开启，数据会离开 AWS 的数据与安全边界，进入 Anthropic 要求的留存和审查流程。对重视零数据留存、内部合规边界和客户隐私承诺的企业来说，这不是一个小改动。

从这里开始，Fable 5 就不再只是一次普通模型发布。它把三个问题绑在了一起：能力是否足够危险，防护是否足够可靠，留存和审计是否足够可接受。更准确地说，它把 Anthropic 自己长期强调的 AI 安全理念，推到了一个尴尬位置：当一家安全叙事很强的公司发布一个更强模型时，它既要说服市场“这个模型足够强”，又要说服政府“这个模型没有强到必须被管制”。这两句话天然紧张。

6 月 12 日的出口管制令

真正让事件升级的是 6 月 12 日。

Anthropic 随后发布声明称，美国政府以国家安全权限下达出口管制指令，要求暂停任何外国国民访问 Fable 5 和 Mythos 5。这里的“外国国民”不仅包括美国境外用户，也包括美国境内外国国民，甚至包括 Anthropic 自己的外籍员工。Anthropic 表示，指令是在美国东部时间 6 月 12 日 17:21 收到的；由于实际系统很难在全球 API 和员工工作流中精准识别并实时限制所有相关身份，最终效果就是对所有客户关闭 Fable 5 和 Mythos 5。

这部分是可以确认的核心事实：模型发布在 6 月 9 日，访问暂停发生在 6 月 12 日，Anthropic 官方承认收到美国政府出口管制指令，并因此对全部客户关闭两款模型。

争议在于原因。

Anthropic 的声明称，政府信件没有提供具体国家安全细节。Anthropic 理解政府担忧的是 Fable 5 的某种绕过或 jailbreak 方法；公司看过一个演示，认为该技术只识别出少量已知、轻微漏洞，而且其他公开模型在不绕过的情况下也能发现类似问题。Anthropic 还强调，在发布前已经与美国政府、英国 AISI、第三方机构和内部团队做过大量红队测试，尚未发现可以广泛绕过模型防护的通用 jailbreak。

换句话说，政府和 Anthropic 的分歧不是“模型完全没有风险”与“模型绝对危险”之间的分歧，而是风险等级、证据充分性、处理速度和处置权力之间的分歧。政府认为足以触发紧急限制；Anthropic 认为这是一个狭窄、尚未充分证明、且不应导致全球商业模型召回的问题。

AWS 线索：从安全反馈到白宫升级

媒体报道把 Amazon/AWS 放在了这条线的中心，而且细节比“有人告状”要复杂。

Business Insider 的报道引述两名政府官员和一名白宫高级官员称，在 Fable 公开发布两天后，Amazon CEO Andy Jassy 向白宫提出了对模型护栏可能被绕过的担忧。报道同时补充说，熟悉 Amazon 沟通情况的人称，Amazon 是在响应政府征询反馈，而不是单方面发起一次公开指控。

这一区分很重要。如果 Amazon 是在政府征询中反馈风险，那么 AWS 的角色更像关键基础设施和分发渠道上的安全信号提供者；如果把它简单写成“Amazon 绕过披露机制主动引爆”，就已经进入更强的政治解读，需要额外证据支撑。但即便采用更保守的说法，问题也已经足够尖锐：当云平台既托管模型、分发模型、投资模型公司，又在政府安全评估中提供关键反馈时，它就不再只是“基础设施”。它开始拥有一种准监管权力。

Business Insider 还描述了随后 24 小时的升级链条：问题在 6 月 12 日早晨进入白宫高层讨论，财政部长 Scott Bessent、白宫网络主任 Sean Cairncross、白宫幕僚长 Susie Wiles 等人参与会议；之后政府官员与 Dario Amodei 进行了多轮通话，商务部长 Howard Lutnick、商务部工业与安全局相关官员等也被报道参与其中。报道说，Amodei 试图说明这只是特定绕过，并不等同于可以广泛解除全部安全护栏的通用 jailbreak；白宫方面则认为 Amazon 的发现已经给 NSA 看过，足以构成“proof”。

这并不等于 AWS 的技术细节已经完整公开。公开材料仍无法独立验证绕过方式、测试范围、是否生成了可运行攻击代码，或该绕过在真实生产环境中有多大扩展性。它能支持的审慎结论是：Amazon/AWS 的反馈很可能是政府快速升级此事的重要触发因素之一；政府随后把问题放进国家安全框架评估；Anthropic 与政府对风险严重性和处理节奏发生了实质分歧。

Reuters 转述的报道也称，Jassy 是向特朗普政府高级官员提出 Anthropic 最新模型安全风险担忧的科技高管之一。Amazon 没有确认具体沟通内容，只表示作为大型云服务商，政府向其征询潜在安全风险意见并不罕见。

围绕这条主线，外界还提出了更进一步的解读。TechTimes 等报道把 Amazon 的多重身份放在显眼位置：它既是 Anthropic 的重要投资方和云基础设施提供者，也是 Bedrock 分发渠道和自有 Nova 模型的经营者。Jassy 向政府反馈安全担忧，因此被一些评论视为一个结构性利益冲突案例。

我认为这个解读不能直接替代证据，但它抓住了问题的骨架。前沿 AI 公司越来越依赖少数云平台提供算力、部署、分发和企业入口；而这些云平台本身也在做模型，也有投资组合，也需要向政府证明自己是“负责任的基础设施守门人”。在这种格局下，安全反馈当然可能是真诚的，也可能在客观上产生竞争后果。两件事并不矛盾。

类似地，David Sacks 所谓 “Dario refused” 的说法，也更适合作为行政当局版本的一部分呈现，而不是直接当作事实结论。政府一方强调 Anthropic 没有足够严肃地配合暂停或修复；Anthropic 一方则称自己没有收到充分具体的国家安全细节，且被展示的绕过方法并不构成通用 jailbreak。读者真正需要看到的，是这两个版本如何解释同一组事件，而不是在证据尚未完全公开前替任何一方盖棺定论。

因此，“AWS 安全反馈 -> 白宫/商务部升级 -> Anthropic 反驳 -> 出口管制 -> 全球下线”这条框架可以作为本文理解事件的主线；而“Amazon 是否借政府之手打击被投公司”“Anthropic 是否因 IPO 利益拒绝修复”“公开截图中的 x86 Linux exploit 是否等同于 Amazon 报告本身”等更强判断，仍应放在外界解读和待证实层级。

一条更稳妥的时间线

把材料压缩后，更可靠的事件线大致是这样：

时间	事件	证据状态
2026 年 4 月	Mythos Preview / Project Glasswing 形式的受限访问先行进入网络防御与关键基础设施场景	Anthropic 官方背景
2026 年 6 月 9 日	Anthropic 发布 Claude Fable 5 和 Claude Mythos 5	Anthropic 官方确认
2026 年 6 月 9 日后	Mythos-class 模型引入 30 天数据留存要求，引发企业合规压力	Anthropic 与 AWS 公开材料可确认
2026 年 6 月 12 日前后	Amazon/AWS 向政府高层反馈安全护栏绕过担忧；BI 报道称政府随后与 Anthropic 多轮通话，并将发现交由 NSA 等方面评估	媒体报道，需写成“据报道”
2026 年 6 月 12 日 17:21 ET	美国政府以出口管制形式要求暂停外国国民访问 Fable 5 / Mythos 5	Anthropic 官方确认
2026 年 6 月 12 日后	Anthropic 因无法精确执行身份限制，关闭所有客户访问	Anthropic 官方确认
随后	争议扩展到 AI 主权、盟友访问、出口管制边界和前沿模型治理程序	政策评论与产业讨论

这条时间线不如阴谋故事刺激，但对读者更有用：它说明事件并不是单一技术漏洞自动推出政策结果，而是技术信号、云平台反馈、政府安全判断、企业反驳和出口管制工具在极短时间内叠加。

我的判断：这不是单纯的“模型漏洞”问题

如果只把事件理解成“某个模型有没有 jailbreak”，反而会低估它的制度含义。

Fable 5 / Mythos 5 的争议说明，前沿模型治理正在从内容安全走向能力管制。过去平台更常处理的是模型是否生成仇恨、色情、诈骗或危险说明；现在的问题变成：模型是否具备显著提升网络攻击、生物设计、模型蒸馏或自动化代理能力的潜力？如果具备，这种能力是通过拒答、分类器、回退模型、数据留存、可信访问计划，还是政府出口管制来管理？

这几种手段背后的权力结构完全不同，而且差异不只是技术实现。

分类器和回退模型属于厂商内部治理。数据留存把客户隐私、企业合规和平台安全绑在一起。可信访问计划要求厂商、政府和特定机构共同决定谁能使用高能力版本。出口管制则把模型从普通商业产品推向国家安全工具，一旦触发，商业可用性可能在几个小时内被重写。

我的观点是：政府当然可以管前沿模型，尤其是网络攻防和生物安全这类双重用途能力，不管反而是不负责任。如果一个模型确实可能被不友好行为体系统性越狱、被专制政府不惜资源蒸馏、或者被拿去放大不受控的网络攻击和监控能力，监管就不是可有可无，而是必要防线。

但必要监管不等于粗暴监管。更准确的做法应当是把风险、证据和处置路径沟通清楚：到底是哪类请求能绕过防护，绕过后能达到什么能力等级，是否已经出现真实滥用迹象，厂商是否可以通过分类器更新、访问分级、日志审计、速率限制、可信客户白名单或区域性限制来缓解。

当然，也不能排除另一种情况：如果监管方已经发现不友好行为体正在进行系统性滥用，甚至有理由相信还存在尚未被发现的同类活动，状态又足够紧急，那么先采取临时止血措施并不必然错误。真正的问题在于，临时措施不能自动变成无限期、不可解释、不可复核的常态。如果紧急处置之后仍然没有清晰的技术说明、范围边界、复审机制和恢复路径，就突然用“外国国民访问限制”把一个全球 API 逼到整体关停，那仍然不是精细治理，而是用一个看似法律上干净的出口管制框架，解决了一个技术上和商业上都极其复杂的问题；代价则由客户、员工、盟友和整个模型生态共同承担。

真正棘手的问题不是“政府永远不该管”，也不是“只要国家安全就可以立即下架”。问题在于：当一个模型已经公开商用、服务全球客户、牵涉外籍员工和跨国企业工作流时，紧急管制是否应有透明程序、技术证据、沟通窗口、申诉机制和比例原则。没有这些东西，所谓 AI 安全就很容易滑向权力方便；而如果厂商也拒绝严肃配合真实风险，那么“开放创新”同样会变成逃避责任的口号。

Anthropic 作为利益相关方，当然会强调自己的程序性主张。它在声明中承认政府应当有能力阻止不安全部署，同时认为这种权力应该建立在透明、公平、清晰且基于技术事实的法定程序上。这一点可以作为当事方观点纳入讨论，但不应成为本文的主论调。本文更关心的是：监管不合理滥用行为本身是必要的，尤其是在高风险模型可能被系统性越狱、蒸馏或用于网络攻击时；争议不在于要不要管，而在于管制是否有证据边界、处置层级和可复核的程序。

还需要补上另一面：监管过少会放大滥用，监管过密也会直接伤害模型可用性。中国大陆模型就是一个常被拿来调侃的例子。为了满足内容合规和“政治正确”要求，许多模型在敏感议题上不仅不能生成有害内容，连正常讨论、历史分析、制度比较、新闻总结和讽刺表达也容易触发拒答或空话。这就是网上所谓“要符合中国特色社会主义，所以大家都用国外模型”的笑话来源。笑话归笑话，它指向的是一个真实产品问题：当监管从风险治理变成敏感词治理，模型就会从能力工具退化成合规话术机器。

所以，本文说的“监管要有边界”，不是只针对美国出口管制。它同样适用于任何把 AI 管到只剩套话的制度环境。好的监管应当区分恶意能力调用、组织化操纵和普通表达，区分真实安全风险和政治舒适区，区分高风险部署和日常知识使用。如果模型为了避免犯错而什么都不敢说，用户自然会转向限制更少的国外模型；如果国外模型为了能力竞争忽视滥用风险，又会给政府留下粗暴介入的理由。两边看似相反，其实都是边界失灵。

旁支背景：AI 工具的组织化滥用问题

OpenAI 的 2026 年 6 月威胁报告可以作为背景参照，但不应被用来证明 Claude Fable 5 / Mythos 5 下线的直接因果关系。它讨论的是 OpenAI 自身识别并封禁的账号集群，重点在于组织化行为体如何把 AI 工具嵌入舆论操作流程，而不是说明 Anthropic 事件为何发生。

这份报告描述了两组据称“可能源自中国”的账号集群。报告使用了大量限定语，例如 likely、appears、no evidence of meaningful breakout，说明其判断仍有证据边界。相关账号被指用于生成英文和中文社交媒体评论、制作或编辑图片、塑造疑似美国人或海外华人身份、跨平台投放内容，并围绕美国 AI 数据中心、电价、关税、技术竞争和 OpenAI 声誉等议题制造叙事。

这份报告最有价值的地方，不是给某个地区用户贴标签，而是把一套组织化滥用流水线摊开了：商业化水军生态、政府关联承包商或舆情管控链条，可能把 AI 当成批量生成内容、冒充身份、维持账号人设、跨账号互动、规避平台检测、骚扰异见者和辅助舆情监控的工具。报告还提到，相关操作者会请求生成工作报告、规划平台运营策略、分析 Facebook 等平台的推荐和检测机制，并通过备份账号、账号分工和跨账号互动来维持看似自然的传播。

这类行为应当被明确谴责，而且不必说得委婉。它不是“宣传能力现代化”，也不是“国际传播技巧”，而是对公共讨论的污染：用假身份伪装真实民意，用批量内容稀释真实表达，用跨平台互动制造共识幻觉，还把异见者变成骚扰目标。AI 在这里不是思想的工具，而是流水线的放大器。

但批评必须对准机制，而不是对准普通人。普通用户使用 AI 写作、翻译、编程、学习或表达观点，与组织化冒充、骚扰、监控和跨平台操纵不是一回事。把两者混为一谈，只会让真正需要被追责的滥用机制躲进更宽泛的地域标签里，也会让无辜用户替组织化行为买单。

因此，在讨论 Claude 事件时，OpenAI 威胁报告最多提示一个背景事实：AI 平台确实正在面对组织化滥用者，他们会测试不同模型和平台的边界，并把生成式 AI 接入更成熟的舆论操作流程。它不能替代 Anthropic 事件本身的证据，也不能被拿来反推出某项出口管制令的直接动机。

能力管制与舆论操纵正在相遇

把 Claude 事件和 OpenAI 威胁报告放在一起看，最有意义的连接点不是“中国访问导致 Claude 被禁”这种直接因果，而是 AI 竞争已经同时进入两个战场。

一个战场是能力管制。前沿模型是否能够显著提升网络攻击、模型蒸馏、生物设计或自动化代理能力？谁能访问不加防护或少加防护的版本？政府能否直接限制模型面向外国国民开放？

另一个战场是认知和舆论。数据中心、电价、关税、AI 公司声誉、模型安全、用户数据泄露传言，都可以被组织化影响行动拿来包装成看似自然的公共讨论。AI 工具降低了批量生产内容、翻译改写、生成图片、维持人设和跨平台测试叙事的成本。过去这类行动需要人海战术，现在它更像一套半自动内容工厂。

这两个战场会互相影响。越是强大的模型，越容易被纳入国家安全叙事；越是围绕 AI 的争议议题，越容易被组织化行为体拿来放大不信任。前沿 AI 的治理因此不再只是实验室、产品团队和安全评估机构之间的事情，而是云基础设施、政府权力、企业合规、公共舆论和跨国政治共同缠绕的系统问题。

所以，我不想把这件事简单写成“Anthropic 被美国政府收拾了”。这说得太窄。真正的问题是：模型公司造出越来越强的能力，云平台握着上线和分发入口，政府随时可以划红线，组织化舆论操作又在旁边搅浑公共讨论。哪一环出问题，最后都不会只停在自己那一环。

结论：监管要有对象，也要有边界

读者不需要在两个极端之间二选一：既不必把这次风波简单理解成“美国政府突然封杀 Claude”，也不必直接断言“Anthropic 不听话所以被制裁”。公开数据更支持一种较稳妥的解释：Fable 5 / Mythos 5 发布后，围绕其安全护栏、双重用途能力和数据留存政策出现了高强度争议；据 Business Insider、Reuters 等媒体报道，Amazon/AWS 方面向美国政府反馈了安全担忧，白宫随后把问题升级到国家安全层面；美国政府最终以出口管制工具要求暂停外国国民访问；Anthropic 则认为证据不足、绕过狭窄，并因无法精确执行身份限制而关闭所有客户访问。

这已经足够重大，不需要再把未经核验的素材写成确定事实。真正值得追踪的是后续几个问题：政府是否能说明更清晰的技术依据，Anthropic 是否能拿出足够可信的修复方案，AWS 和其他云平台在这类事件中到底承担什么报告和审查责任，以及这个先例会不会扩展到其他前沿模型提供商。

我的结论更直接一点：前沿 AI 确实需要强监管，尤其是面对系统性越狱、模型蒸馏、网络攻击、生物安全和组织化舆论操纵这类不合理滥用时，监管缺位本身就是风险。但监管也不能变成另一种产品事故：一边是美国式紧急出口管制可能把全球 API 瞬间打停，另一边是过度内容合规可能把模型训练成敏感词探测器和拒答机器。模型公司不能用“安全分类器”四个字打发所有双重用途问题，也不能在商业发布后才把风险成本交给客户和社会承担。云平台如果掌握上线、托管和安全反馈入口，也不能只把自己描述成中性的基础设施。政府在紧急情况下可以先处置高风险部署，但也应该尽快给出范围、依据、复核和恢复路径。

所以，这篇文章不是在说“不要监管”，恰恰相反，它反对的是把监管对象搞错、把监管工具用粗、把普通用户和组织化滥用者混为一谈。真正应该被盯住的是那些把 AI 接入水军产业、身份冒充、跨平台操纵、异见骚扰、网络攻击和监控链条的行为体；真正应该被要求改进的是那些无法证明自己能控制高风险能力的模型和云服务；真正应该被持续追问的是紧急管制如何从临时止血回到有证据、有边界、有复核的常规治理。

Claude Fable 5 / Mythos 5 的下线风波，最值得记住的不是某个模型名字，而是一个信号：AI 竞争正在从“谁的模型更强”转向“谁能证明强模型不会被成规模滥用”。监管当然要跟上，但好的监管不只是按下暂停键，而是能说明为什么暂停、暂停到什么范围、谁需要修复、如何复审，以及普通合法用户怎样不被长期误伤。

参考数据

Codex 历史对话加载很慢：先开个新对话让它自己诊断

toewpq — Tue, 19 May 2026 00:00:00 GMT

有时候 Codex 开启历史对话会慢得像在翻一本很厚的旧账本。点一下历史记录，等半天；再点一下，继续等。你开始怀疑网络，怀疑远程主机，最后甚至开始怀疑自己是不是把太多东西塞进同一个会话里了。

先别急着做数据库手术。最简单的办法是：直接新开一个 Codex 对话，让 Codex 判断为什么慢，并让它帮你清理历史记录。

这听起来有点绕：Codex 慢了，找 Codex 修 Codex。但实际很好用，因为慢的往往是旧对话加载、日志膨胀、工作区扫描或远程环境状态，而新对话通常还能正常启动。

先换一张干净桌子

如果某个历史对话开启特别慢，不要一直在那个旧对话里硬等。可以先开一个新的 Codex 对话，然后直接这样说：

我在目前机器上开启 Codex 历史对话很慢。
请你判断可能原因，并先用只读方式检查 ~/.codex、目前工作区大小、
日志文件、session 数量和数据库大小。
不要删除任何文件，先告诉我风险和建议。

重点是让它先判断，不要让它一上来就删除。新对话没有背着旧上下文跑，反而更适合做这个“场外裁判”。

让 Codex 先看几件事

可以让 Codex 按顺序检查：

1. ~/.codex 目录里有没有特别大的文件；
2. sessions 目录里的会话数量和最大文件；
3. logs_2.sqlite 是否明显膨胀；
4. state_5.sqlite 和 session_index.jsonl 是否正常；
5. 目前项目是否有巨大的 node_modules、dist、日志或缓存；
6. 远程主机磁盘空间是否快满。

如果你是在小型 VPS 上使用 VS Code Remote + Codex，这一步尤其重要。磁盘只有几 GB 的机器，一旦日志、建设缓存、依赖目录一起膨胀，体验就会突然变得很黏。

一个更好用的提示词

我更推荐把需求说得具体一点：

请你帮我排查 Codex 历史对话加载慢的问题。

要求：
- 先只读检查，不要修改文件；
- 说明哪些文件可能影响历史加载；
- 区分“可以安全清理”和“不要随便动”的内容；
- 如果需要清理，请先给备份方案；
- 如果确认可以清理，请帮我清理 Codex 历史记录；
- 最后告诉我如何回到 VS Code Codex 首页确认结果。

这样 Codex 通常会先列出检查命令，再根据输出判断是不是日志库、会话文件、项目缓存或磁盘空间的问题。

让它直接清理历史记录

如果你只是想让历史首页变清爽，可以继续对新对话说：

请帮我清理 Codex 历史记录。
要求：
- 先告诉我要清理哪些文件或记录；
- 清理前做必要备份；
- 不要影响目前认证和插件设置；
- 清理完成后告诉我怎么在 VS Code Codex 首页确认。

清理完成后，回到 VS Code，开启 Codex 首页或刷新 Codex 面板，就会看到历史记录已经被清掉或明显变少。这个反馈很直观：不用盯着数据库大小猜，首页列表自己会告诉你结果。

常见结论

排查后常见会遇到几种情况。

第一种是旧会话太长。这个时候不一定要修，直接把任务拆到新对话里就行。旧会话留着当数据，新会话负责继续干活。

第二种是 ~/.codex/logs_2.sqlite 变得很大。它是日志库，不等于你的真正对话历史。通常需要先备份，再清理低价值日志，最后压缩数据库。

第三种是目前工作区太胖。比如 node_modules、dist、临时建设目录、下载文件堆在一起，Codex 和 VS Code Remote 都会被拖累。

第四种是远程 VPS 存储快满。磁盘一紧张，很多东西都会变慢，包括 shell、编辑器、日志写入和数据库操作。

真要清理时，别裸奔

如果 Codex 判断是日志库膨胀，可以让它生成一套更稳的步骤：

请给我一个保守清理方案：
1. 先备份 ~/.codex/logs_2.sqlite；
2. 只清理 TRACE、DEBUG 和旧 INFO；
3. 保留 WARN、ERROR；
4. 执行 quick_check；
5. 清理前后显示文件大小；
6. 不要删除 sessions、state_5.sqlite、session_index.jsonl。

这里最重要的是最后一句：不要误删真正的会话历史。sessions、state_5.sqlite、session_index.jsonl 这些东西要谨慎对待。

什么时候什么都别动

如果你正在排查 Codex 本身的异常，或者准备把日志交给上游分析，就先别清理。让 Codex 帮你打包信息、列出文件大小、说明现象就好。

如果数据库健康检查失败，也不要急着删。先备份，再让 Codex 判断是恢复、复制还是重建索引。慢可以忍一会儿，误删会比较疼。

小结

Codex 历史对话加载慢时，不必第一时间冲进 ~/.codex 手动开刀。更省心的做法是：

新开 Codex 对话 -> 让它只读检查 -> 让它判断原因 -> 让它清理历史 -> 回到 VS Code Codex 首页确认

这就像桌面太乱时先换一张干净桌子，再请人帮你一起看哪一堆该收、哪一堆不能碰。简单、稳，也更不容易把真正的历史对话弄丢。

使用 VS Code Remote SSH 连接远程主机：从插件到远程目录

toewpq — Sun, 10 May 2026 00:00:00 GMT

远程开发的核心不是“把文件传来传去”，而是让本机 VS Code 直接开启远程主机上的目录。VS Code Remote SSH 的价值就在这里：本机 Windows 负责界面和互动，远程主机负责保存文件并提供远程终端。

这篇文章从实际连接远程主机的角度出发，记录 VS Code Remote SSH 的两种常见设置方式：密钥对登录和密码登录。

适用场景

这个方案适合以下几类工作：

在云主机、NAS、软路由或开发机上直接编辑远程文件；
需要用 VS Code 管理远程目录和远程终端；
不想频繁通过 SFTP、scp 或文件管理器手动同步文件；
希望在多个远程主机之间快速切换。

这篇文章只讨论如何连接远程主机，不展开项目复制、依赖安装或建设流程。

准备连接信息

连接前先准备这些信息：

HostName：远程主机公网 IP 或域名
User：远程用户名称，例如 root、ubuntu、debian 或自定义用户
Port：SSH 端口，默认 22，也可以是自定义端口
IdentityFile：本机私钥路径，使用密钥登录时需要
Password：远程用户密码，使用密码登录时需要，不建议写入 config

Windows 10/11 通常已经内置 OpenSSH Client。可以在 PowerShell 中检查：

ssh -V

如果能看到 OpenSSH 版本，表示本机 SSH 客户端可用。

方式一：使用密钥对登录

密钥对登录是更推荐的方式。它不需要每次输入服务器密码，也更适合长期使用 VS Code Remote SSH。

产生 SSH 密钥

在 PowerShell 中执行：

ssh-keygen -t ed25519 -C "vscode-remote"

默认会产生：

C:\Users\User\.ssh\id_ed25519
C:\Users\User\.ssh\id_ed25519.pub

其中：

id_ed25519 是私钥，只保存在本机；
id_ed25519.pub 是公钥，可以放到远程主机的 authorized_keys。

复制公钥内容：

Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"

然后把这段内容追加到远程主机的：

~/.ssh/authorized_keys

远程主机上的权限建议设置为：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

准备好公钥后，后面在 VS Code 的 SSH Host 设置里填入本机私钥路径即可。

方式二：使用密码登录

如果只是临时连接一台测试主机，或者还没有来得及设置公钥，也可以直接使用密码登录。此时本机 SSH Host 设置不需要写 IdentityFile。如果服务器允许密码登录，VS Code Remote SSH 连接这个 Host 时会跳出密码输入框。

需要注意的是，密码登录依赖远程 SSH 服务端允许 PasswordAuthentication。有些 VPS 镜像默认关闭密码登录，只允许密钥登录；如果开启密码登录，建议配合强密码、非默认端口、防火墙或 Fail2ban 一类的登录保护策略。

连接步骤

1. 安装 Remote - SSH 扩展

安装 VS Code 扩展：

Remote - SSH

安装完成后建议重启一次 VS Code，避免左侧远程资源管理器、命令面板和 SSH 设置入口没有立即刷新。

2. 设置 SSH Host

开启命令面板：

Ctrl + Shift + P
Remote-SSH: Open SSH Configuration File...

选择 Windows 用户目录下的 SSH 设置档：

C:\Users\User\.ssh\config

如果使用密钥登录，写入类似设置：

Host blog-dev
  HostName 你的服务器 IP 或域名
  User root
  Port 22
  IdentityFile C:\Users\User\.ssh\id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

如果使用密码登录，可以不写 IdentityFile：

Host blog-dev-password
  HostName 你的服务器 IP 或域名
  User root
  Port 22
  PreferredAuthentications password,keyboard-interactive

存储设置后，VS Code 的远程资源管理器中会出现对应的 Host。

3. 连接远程主机

连接方式有两种。可以继续使用命令面板：

Ctrl + Shift + P
Remote-SSH: Connect to Host...
blog-dev

也可以点击左侧活动列的远程资源管理器图示，在 远程(隧道/SSH) 视图里展开 SSH，选择刚设置的主机并连接。连接成功后，主机旁边会显示已连接状态。

首次连接时，VS Code 会在远程主机安装 VS Code Server。如果使用密码登录，VS Code 会跳出密码输入框；如果使用密钥登录，通常会直接进入远程窗口。

4. 开启远程目录

连接成功后，在远程资源管理器中展开主机，选择需要开启的远程目录，例如：

/opt

或：

/home/deploy

开启后，本机 VS Code 窗口实际操作的是远程主机上的目录。后续在资源管理器中编辑文件、开启终端、保存内容，都会发生在远程主机上。

小容量 VPS 的限制

VS Code Remote SSH 首次连接时会在远程主机安装 VS Code Server，通常位于：

~/.vscode-server

后续安装远程扩展、开启多个远程窗口或保留旧版本 VS Code Server 时，也会继续占用远程磁盘。对于 edgeproxy 这类只有 5G 左右存储分配的小型 VPS，这个限制会比较明显：~/.vscode-server 和远程扩展缓存叠加后，可能把磁盘占满。磁盘满了以后，常见表现包括 VS Code Server 安装失败、远程终端异常、文件保存失败。

连接前建议先检查空间：

df -h
du -sh ~/.vscode-server ~/.cache 2>/dev/null

如果空间紧张，可以优先减少远程扩展数量，或者移除旧的 VS Code Server 版本目录：

rm -rf ~/.vscode-server/bin/<旧版本目录>

如果这台 VPS 主要用于代理、转发或轻量服务，不建议把它当成完整开发机长期使用。Remote SSH 更适合磁盘空间、内存和 CPU 都有一定余量的远程主机。

常见问题

1. 第一次连接很慢

首次连接时，VS Code 会在远程主机安装服务端组件。只要网络稳定，等待安装完成即可。后续连接通常会明显更快。

2. 密钥明明正确但仍然要求密码

优先检查三处：

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

权限建议：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

另外确认本机 IdentityFile 指向的是私钥，而不是 .pub 公钥。

3. known_hosts 报错

如果服务器重装过系统或 IP 被重复使用，本机可能出现 host key 冲突。可以先确认确实是你的服务器，再清理旧记录：

ssh-keygen -R 服务器 IP 或域名

然后重新连接。

小结

VS Code Remote SSH 的重点不是“远程桌面”，而是让 VS Code 通过 SSH 直接管理远程主机上的目录。实际使用时，把顺序记住就够了：安装 Remote - SSH 扩展，重启 VS Code，设置 SSH Host，然后从远程资源管理器连接主机并开启目录。

参考

VS Code Remote SSH 文件：https://code.visualstudio.com/docs/remote/ssh
VS Code Remote SSH Marketplace：https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh

VS Code Remote SSH 连接后安装 Codex：为什么远程窗口需要重新安装和认证

toewpq — Sun, 10 May 2026 00:00:00 GMT

使用 VS Code Remote SSH 连接远程主机后，经常会遇到一个容易误解的现象：本机 VS Code 明明已经安装了 Codex 扩展，切到远程 SSH 窗口后，Codex 图示却没有像本机窗口那样出现在侧边栏。

原因很简单：Remote SSH 开启的不是普通本机窗口，而是连接到远程主机的远程窗口。VS Code 会在远程主机上执行一套远程扩展环境。本机安装过的扩展和本机登录状态，不一定会自动带到远程主机里。对 Codex 来说，远程窗口通常需要重新安装一次扩展，并重新完成一次认证。

下面用一个泛化主机名 remote-dev 举例，避免把真实服务器名称写进教学。

前提

继续之前，先确认你已经完成了 VS Code Remote SSH 连接：

左侧远程资源管理器中能看到 SSH 主机 remote-dev
主机状态显示已连接
目前窗口左下角显示 SSH: remote-dev
远程终端提示字符来自远程主机

如果目前开启的还是本机 Windows 目录，例如 C:\Users\User\Desktop，那还不是远程工作区。需要先从远程资源管理器中连接主机，并开启远程目录，例如：

/opt

或：

/home/deploy

为什么本机装过 Codex 还要远程再装

VS Code Remote SSH 连接后，扩展大致分成两类：

本机 UI 侧扩展：执行在本机 VS Code 客户端中；
远程工作区扩展：执行在远程主机的 VS Code Server 环境中。

Codex 需要读取目前工作区、显示侧边栏入口，并和远程目录中的文件互动。远程 SSH 窗口里的工作区在远程主机上，所以只在本机装过 Codex 并不够。你需要在远程窗口里安装 Codex，安装位置通常会显示为类似：

Install in SSH: remote-dev

安装完成后，Codex 图示才会在这个远程窗口里正常出现。

安装步骤

1. 先连接 Remote SSH

开启 VS Code 左侧远程资源管理器，选择 远程(隧道/SSH)，在 SSH 下连接示例主机：

remote-dev

连接成功后，开启一个远程目录，例如 /opt。这一步很重要，因为 Codex 要安装到目前远程窗口，而不是普通本机窗口。

2. 在远程窗口安装 Codex 扩展

开启扩展面板：

Ctrl + Shift + X

搜索：

Codex

如果扩展已经在本机安装过，但远程窗口还不能使用，扩展页面通常会出现远程安装入口。选择类似下面的按钮：

Install in SSH: remote-dev

不要只看本机是否已经安装。关键是确认目前远程 SSH 窗口也安装了 Codex。

3. 重载或重启 VS Code 窗口

安装完成后，如果侧边栏没有立即出现 Codex 图示，可以执行：

Ctrl + Shift + P
Developer: Reload Window

也可以直接关闭目前远程窗口，再重新通过 Remote SSH 连接 remote-dev。很多时候，重载窗口后 Codex 图示才会稳定显示。

4. 重新认证 Codex

远程窗口里的 Codex 需要单独认证。即使本机 VS Code 已经登录过 Codex，远程 SSH 窗口仍然可能要求重新登录或设置 API Key。

开启 Codex 图示后，按提示完成认证。常见方式包括：

使用 ChatGPT / OpenAI 账号登录
或设置 OpenAI API Key

认证完成后，Codex 才能在远程窗口中读取目前目录、辅助修改文件，并根据远程工作区上下文执行任务。

常见现象

1. 本机窗口有 Codex 图示，远程窗口没有

优先检查 Codex 是否安装到了远程 SSH 窗口。只在本机安装并不等于远程可用。

2. 扩展页显示已安装，但远程侧边栏还是没有图示

确认目前窗口左下角是否显示 SSH: remote-dev。如果不是远程窗口，表示你还在本机环境。若已经是远程窗口，执行 Developer: Reload Window。

3. 远程窗口提示需要登录

这是正常现象。远程主机和本机客户端的认证状态可能不同，需要重新完成 Codex 登录或 API Key 设置。

4. 远程主机空间很小

Codex 扩展、VS Code Server 和其他远程扩展都会占用远程磁盘。如果是只有 5G 左右存储的小型 VPS，建议先检查空间：

df -h
du -sh ~/.vscode-server ~/.cache 2>/dev/null

空间不足时，远程扩展可能安装失败，Codex 图示也可能无法正常显示。

小结

把 VS Code Remote SSH 和 Codex 放在一起使用时，要记住一个区别：本机 VS Code 客户端和远程 SSH 窗口不是同一个扩展执行环境。本机装过 Codex，不代表远程窗口已经装好；本机认证过，也不代表远程窗口已经认证。

实践顺序可以固定为：

连接 Remote SSH
开启远程目录
在远程窗口安装 Codex
重载或重启 VS Code 窗口
重新完成 Codex 认证
确认 Codex 图示出现在远程窗口侧边栏

这样处理后，Codex 才会像本机窗口一样，在远程主机的工作区里正常显示和使用。

参考

Codex IDE 扩展文件：https://developers.openai.com/codex/ide
Codex CLI 文件：https://developers.openai.com/codex/cli
VS Code Remote SSH 文件：https://code.visualstudio.com/docs/remote/ssh

OpenWrt QModem 下 RM502Q-AE 无法接收短信的排障与恢复：IMS、5G SA 与短信承载设置

toewpq — Wed, 29 Apr 2026 00:00:00 GMT

这是一篇真实排障记录：OpenWrt 上通过 QModem 管理 Quectel RM502Q-AE 时，QModem 短信页面一直收不到短信。最后确认问题不在页面读取，也不是短信存储已满，而是在中国移动 NR5G SA 场景下 IMS 处于关闭状态。开启 IMS 并重启模块后，短信恢复接收。

文中涉及身份类信息均已脱敏；如果需要提到 CIMI/IMSI，只记录为 46007************ 或“已脱敏”。短信正文不记录。

1. 背景与症状

环境很普通：OpenWrt 系统，QModem 管理 RM502Q-AE，AT 端口使用 /dev/mhi_DUN。模块信息如下：

ATI
Quectel
RM502Q-AE
Revision: RM502QAEAAR13A04M4G

AT+QGMR
RM502QAEAAR13A04M4G_01.203.01.203

运营商为中国移动，网络曾驻留在 NR5G SA：

AT+QNWINFO
+QNWINFO: "TDD NR5G","46000","NR5G BAND 79",721824

排障过程中也出现过 NR5G BAND 41。5G SA 注册状态最后正常：

AT+C5GREG?
+C5GREG: 2,1,...,11,...

AT+C5GREG?
+C5GREG: 0,1

原始症状是 QModem 的短信页面没有任何短信。界面返回中 msg 为空，存储能力看起来正常：

{
  "msg": [],
  "result": {},
  "sms_capabilities": {
    "mem1": "MT",
    "mem2": "MT",
    "mem3": "MT",
    "ME": { "used": "0", "total": "127" },
    "SM": {}
  }
}

2. 先确认不是 QModem 页面问题

第一步不是改设置，而是确认短信到底有没有进入模块存储。分别检查 ME、MT、SM、SR 后，结果都为空：

AT+CPMS="ME","ME","ME"
+CPMS: 0,127,0,127,0,127
OK

AT+CPMS="MT","MT","MT"
+CPMS: 0,127,0,127,0,127
OK

AT+CPMS="SM","SM","SM"
+CPMS: 0,50,0,50,0,50
OK

AT+CPMS="SR","SR","SR"
+CPMS: 0,5,0,5,0,5
OK

AT+CMGL=4
OK

AT+CMGL=4 返回 OK 但没有任何 +CMGL 行。这一点很关键：如果 ME、MT、SM、SR 都为空，就不是 QModem 页面只读错了 ME/SM，也不是存储已满，而是短信没有进入模块可读存储。

3. PDU 模式下 CMGL 的一个容易踩坑点

排障初期曾看到：

AT+CMGL="ALL"
ERROR

这很容易被误判成短信功能异常。后续确认目前是 PDU 模式：

AT+CMGF?
+CMGF: 0

AT+CMGL=?
+CMGL: (0-4)

在 PDU 模式下，列出全部短信应使用：

AT+CMGL=4

而不是：

AT+CMGL="ALL"

AT+CMGL="ALL" 更适合文字模式，也就是先执行 AT+CMGF=1 的场景。验证码、中文短信和 Unicode 内容更适合保留 PDU 模式，所以这里最后使用 AT+CMGF=0 与 AT+CMGL=4。

4. 短信存储、URC 和通知设置

排障中验证或设置过这一组基础短信设置：

AT+CMEE=2
AT+QURCCFG="urcport","all"
AT+CSMS=1
AT+CMGF=0
AT+CPMS="MT","MT","MT"
AT+CNMI=2,1,0,0,0

这些命令的作用可以这样理解：

AT+QURCCFG="urcport","all"：让 URC 从所有可用 AT 端口输出，避免 QModem 使用的端口和手动调试的 AT 口不一致，导致新短信通知看不到。
AT+CPMS="MT","MT","MT"：使用模块短信总视图，避免短信落在 ME 或 SM，但读取时看了另一边。
AT+CNMI=2,1,0,0,0：新短信存储后，通过 +CMTI 通知终端。
AT+CMGF=0：保持 PDU 模式，更适合验证码、中文短信和 Unicode 内容。

如果选择文字模式，才更适合使用：

AT+CMGF=1
AT+CMGL="ALL"

5. 5G SA 注册正常但短信仍未进入存储

当时 5G SA 注册已经正常，但短信仍然没有进入任何存储。继续检查短信承载偏好：

AT+CGSMS?
+CGSMS: 1

CGSMS=1 可以理解为偏向传统 CS 域。对于目前中国移动 NR5G SA 场景，这并不是理想状态。随后设置为：

AT+CGSMS=2
OK

CGSMS=2 可理解为 Packet domain preferred / PS preferred。这里不要写得过度绝对：不同运营商、不同固件、不同注册状态下，短信承载策略可能不同。但在这次 NR5G SA 排障中，不应继续让短信承载偏向传统 CS 域。

6. 关键发现：IMS 是关闭的

真正的关键点来自 IMS 设置：

AT+QCFG="ims"
+QCFG: "ims",0,0

这表示 IMS 未开启。随后执行：

AT+QCFG="ims",1
OK

重启模块后，短信恢复正常，可以接收短信。也就是说，在这次 RM502Q-AE 驻留中国移动 NR5G SA 网络的场景里，短信恢复的关键动作不是清空存储，也不是换 QModem 页面读取方式，而是开启 IMS。

7. 修复步骤

核心修复命令如下：

AT+CMEE=2
AT+QCFG="ims",1
AT+CFUN=1,1

模块重启后，建议重新设置短信相关参数：

AT+QURCCFG="urcport","all"
AT+CGSMS=2
AT+CSMS=1
AT+CMGF=0
AT+CPMS="MT","MT","MT"
AT+CNMI=2,1,0,0,0

本次实际结果是：开启 IMS 并重启后，QModem 可以收到短信。

8. 回滚步骤

如果开启 IMS 后出现注册、拨号或网络异常，可以回滚：

AT+QCFG="ims",0
AT+CFUN=1,1

但本次故障的实际恢复动作是开启 IMS，因此最后建议保留：

AT+QCFG="ims",1

如果需要回滚短信承载偏好，可以执行：

AT+CGSMS=1

不过这不推荐作为本次 NR5G SA 场景下的最终状态，因为短信恢复后使用的是：

AT+CGSMS: 2

9. QModem 初始化后 AT 命令建议

建议写入 QModem 的“初始化后 AT 命令”：

AT+QCFG="ims",1
AT+QURCCFG="urcport","all"
AT+CGSMS=2
AT+CSMS=1
AT+CMGF=0
AT+CPMS="MT","MT","MT"
AT+CNMI=2,1,0,0,0

这里不依赖 AT&W。实际排障中，AT&W 没有稳定返回 OK，而 OpenWrt/QModem 的使用方式也更适合把关键初始化命令交给 QModem 在启动后执行。这样即使 profile 持久化行为不确定，重启后仍能把短信相关状态拉回预期设置。

10. 后续：如何判断载波聚合是否触发

短信恢复后，又继续看了载波聚合状态：

AT+QCAINFO
+QCAINFO: "PCC",721824,6,"NR5G BAND 79",347

AT+QNWINFO
+QNWINFO: "TDD NR5G","46000","NR5G BAND 79",721824

AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","NR5G-SA","TDD",460,00,...,721824,79,...

AT+QCFG="lteca"
ERROR

QCAINFO 只有 PCC，没有 SCC，说明查询当下没有触发载波聚合。但 QENG="servingcell" 显示 NOCONN，代表当时处于空闲或未连接状态，不能据此判断模块或网络不支持 CA。

正确判断方法是在测速或大流量下载过程中，反复执行：

AT+QCAINFO
AT+QENG="servingcell"

如果出现 SCC，才说明 CA 被网络侧调度。AT+QCFG="lteca" 返回 ERROR，只说明目前固件不支持这个设置项，或没有开放这个 QCFG 项，不等于 CA 被关闭。

对于 NR5G SA 下的 NR CA，更多取决于网络侧调度、基地台设置、套餐、信号、频段组合和是否锁频。不要为了测试 CA 盲目写未知 AT 命令，更不要把已经验证有效的 IMS 关闭。

11. 结论

这次故障的结论很明确：

不是短信存储已满。
不是 QModem 只读错 ME 或 SM。
ME、MT、SM、SR 都为空，说明短信没有进入模块可读存储。
目前网络是中国移动 NR5G SA，5G 注册状态正常。
短信恢复的关键动作是开启 IMS：AT+QCFG="ims",1，然后通过 AT+CFUN=1,1 重启模块。
重启后可以接收短信。
后续建议保留 IMS 开启，并在 QModem 初始化后 AT 命令中固化短信相关设置。
关于 CA：查询时 QCAINFO 只有 PCC，说明当时没有触发 CA；AT+QCFG="lteca" 返回 ERROR 不代表 CA 不能用，只代表该设置项不可用。正确方式是在大流量期间观察 QCAINFO 是否出现 SCC。