从 42 条内容中筛选出 12 条重要资讯。

科技新闻

  1. Claude 溯源 NIST 椭圆曲线种子：来自 lrand48 ⭐️ 8.0/10
  2. Big Fish：利用 OpenBSD 存在 37 年的内核漏洞 ⭐️ 8.0/10
  3. 阶跃星辰发布 Step 5 Preview 智能体旗舰模型 ⭐️ 8.0/10
  4. GitHub 项目 PS5LM：越狱 PS5 上原生运行 GGUF 模型 ⭐️ 7.0/10
  5. JPEG XL 与 AVIF 网页用例对比及编码权衡讨论 ⭐️ 7.0/10
  6. Apple MLX 在四台 Mac Studio 上分布式运行 Muse Spark Open ⭐️ 7.0/10
  7. Anthropic 的 Claude Code 团队谈代码审查自动化 ⭐️ 7.0/10
  8. StarSkirmish Bench v0.2：Gemini 4 Argon 等模型写代码玩《星际争霸》 ⭐️ 7.0/10
  9. Kangrejos 2026：用 pin_init 在 Rust 内核中安全实现自引用结构 ⭐️ 7.0/10
  10. Linux NFS 服务器近期与未来变更概览 ⭐️ 7.0/10
  11. 可灵 Kling 4.0 全量上线，预告 4K/HDR 与开发者 API ⭐️ 7.0/10

财经新闻

  1. 商务部拟修订技术出口目录，涉人工智能、生物医药、光伏 40 项技术 ⭐️ 8.0/10

科技新闻

Claude 溯源 NIST 椭圆曲线种子：来自 lrand48 ⭐️ 8.0/10

据 Anthropic 的研究页面及社区引述的相关文章，Claude 在不到半小时内找出了 NIST P-192、P-224、P-256、P-384 和 P-521 曲线种子的可能来源：它们并非任何哈希算法的输出，而是 C 库 lrand48 随机数生成器以 Unix 时间戳为种子的结果。这解决的是长年被猜测的种子生成方式问题，并不等于证明这些曲线当初被人为挑选，也不代表 ECDSA 本身被攻破。第五个二进制种子 B-163 目前仍无法用该方法解释，保持未解状态。

hackernews · ahlCVA · 10月16日 18:55 · 社区讨论

「背景」 NIST 于 2000 年在 FIPS 186-2 中发布了 P-192、P-224、P-256、P-384 和 P-521 等椭圆曲线；按 ANSI X9.62 的流程，曲线参数由一个“任意种子”经 SHA-1 散列派生，但种子的具体来源长期未公开，成为密码学界延续多年的疑团。Anthropic 称 Claude 发现这些种子来自 C 库的 lrand48 随机数生成器、并以 Unix 时间戳为种子；其中素数曲线所用的种子取自同一生成器但每个输出保留的比特更少，因此需要借助 LLL 格基约化算法，从被截断的线性同余生成器输出中恢复其内部状态。

「影响」 对使用 NIST P-192、P-224、P-256、P-384、P-521 的开发者与机构而言，这次溯源不带来迁移或兼容性动作：曲线参数与标准本身未变，报道也称未发现蓄意后门的证据。留下的具体疑点是 B-163 这一二进制种子仍无法解释，且如社区所指出，确认生成方式并不等于证明当年的曲线筛选过程无偏，因此以“种子来源可疑”为由替换曲线的理由被削弱，但并未被完全排除。

「社区讨论」 有评论者指出，确认生成方法并不能说明曲线的挑选过程：由于无法看到当时生成后被丢弃的候选值，理论上仍可能通过遍历时间戳来搜出具有特定性质的曲线，只是这样做需要事先知道要挑什么性质。另有评论者对未解的 B-163 种子提出最简解释——它与其余种子生成方式相同，只是在发布过程中被误抄了一位数字；还有评论者称赞 Anthropic 选择了更高的赏金并将其捐给 ISRG。

参考链接

标签: #cryptography, #AI-assisted research, #elliptic curves, #NIST standards, #security

Big Fish：利用 OpenBSD 存在 37 年的内核漏洞 ⭐️ 8.0/10

安全研究文章《Big Fish》介绍了如何利用 OpenBSD 内核中一个存在 37 年之久的漏洞。文章及随后的 Hacker News 讨论聚焦于该缺陷为何能长期躲过代码审计，以及为什么仅靠人工审查难以发现这一类漏洞。由于原始内容未提供更多细节，受影响的具体内核组件、版本范围与修复状态在现有材料中尚不明确。

hackernews · rs_rs_rs_rs_rs · 10月16日 14:44 · 社区讨论

「背景」 该漏洞的根源是 System V 共享内存的挂接计数器被声明为有符号 16 位 short，这一写法可追溯到最初的 BSD 源码，已存在约 37 年。外部报道称，研究团队在 OpenBSD 7.9 上把这一整数溢出与另一处内核缺陷（IP 组播选项处理中的越界写）串联起来实现本地提权，并绕过了 OpenBSD 的 KARL 内核地址随机化以及 SMAP、SMEP 硬件防护。

「影响」 该利用需要攻击者先在目标主机上取得本地执行权限，再串联一个约 37 年前的整数溢出缺陷与另一个内核缺陷，将权限提升至 root，因此风险集中在 OpenBSD 7.9 的多用户主机、共享环境与托管服务上。相关缺陷已被修补，而 Calif 已于 2026 年 10 月 16 日公开概念验证代码，所以运维方应尽快升级到含修复的版本，而不是依赖事后审计来发现问题。

「社区讨论」 评论者 phendrenad2 指出，该缺陷似乎是在 1999 年 8 月 NetBSD 重写相关代码时被顺带修复的。ozereray1 认为，一个漏洞能在被高度审计的代码库中存活 37 年，说明单靠代码审查很难捕获这一类问题，并追问模糊测试或静态分析是否真能发现它，还是必须由人去思考利用原语。

参考链接

标签: #OpenBSD, #kernel security, #vulnerability exploitation, #security research, #operating systems

阶跃星辰发布 Step 5 Preview 智能体旗舰模型 ⭐️ 8.0/10

阶跃星辰在 Hugging Face 发布了旗舰智能体模型 Step 5 Preview，采用稀疏 MoE 架构，总参数 6000 亿、激活参数 270 亿，支持最高 100 万 token 上下文，并可接收文本、图像和视频输入。该模型定位智能体工作，厂商称其在软件工程、长周期智能体执行和金融等专业知识任务上表现领先，但作为预览版，这些性能宣称尚未提供独立基准验证。模型可通过 OpenAI 兼容 API 配合 vLLM 或 SGLang 部署，采用 StepFun Model License 1.0 许可。

telegram · zaihuapd · 10月16日 06:36

「背景」 Step 5 Preview 并非首次亮相：据 DataLearner 页面，阶跃星辰已于 2026 年 9 月 20 日正式发布该模型，并在当日通过自有产品与开放平台 API（模型 ID 为 step-5-preview）对外提供服务，此次在 Hugging Face 上线则使其可被下载并配合 vLLM 或 SGLang 自行部署。按掘金与思否转载的介绍，官方将该模型定位为“面向真实世界 Agentic 任务的主力工作模型”，强调在能力、成本、效率和场景覆盖之间取得平衡。其采用的稀疏 MoE 架构指每次推理只激活部分参数，因此 6000 亿总参数下实际激活 270 亿，这也是其控制推理成本的关键设计。

「影响」 对于需要自部署的开发者，模型支持 vLLM 和 SGLang 的 OpenAI 兼容接口，可降低现有 OpenAI API 应用的迁移成本，但 StepFun Model License 1.0 的具体条款以及预览版状态需要在生产采用前评估。

参考链接

标签: #LLM release, #sparse MoE, #agentic AI, #long-context, #multimodal

GitHub 项目 PS5LM：越狱 PS5 上原生运行 GGUF 模型 ⭐️ 7.0/10

开源项目 cobanov/PS5LM 在 GitHub 上展示如何让越狱后的 PlayStation 5 通过 llama.cpp 原生运行 GGUF 格式模型，面向愿意折腾越狱主机的本地推理用户。该条目未附带项目正文，因此具体支持的模型、量化方式、内存占用与实际推理速度均无法核实，现有性能数字都来自社区评论而非项目方或第三方实测。

hackernews · Anon84 · 10月16日 18:32 · 社区讨论

「背景」 llama.cpp 是常用的本地大模型推理引擎，GGUF 是其配套的量化模型格式，通常运行在 PC 或服务器上。PS5 的官方系统限制非签名代码，因此要在主机上运行这类模型需先越狱；该项目正是面向已越狱的 PS5，把 llama.cpp 的 GGUF 推理搬到主机硬件上。

「影响」 对想低成本跑本地模型的用户而言，更易获得的硬件可能不是 PS5 本身：社区指出 AMD BC-250 矿板搭载的“Cyan Skillfish”正是 PS5 定制 APU 的削减版，二手价约 150–200 美元，同一套 llama.cpp 思路有望覆盖这类板卡。该项目目前只托管在 GitHub，有评论者担心索尼可能要求下架，建议改用自有域名，因此依赖该仓库的用户应留意可用性风险。

「社区讨论」 评论者 jjcm 认为，即便只能在 2-bit 量化下运行 Qwen 27B 级模型，这种每天约 0.7 美元电费、可长期挂机的推理对监控错误率、安防画面之类的任务依然实用，属于个人判断而非实测结论。另一位评论者主张项目不应把 GitHub 作为主要托管地，认为 Sony 可能随时下架页面，建议改用自有域名；还有人提出基于 AMD “Cyan Skillfish” APU 的 BC250 矿卡（eBay 上约 150–200 美元）可能同样适用，但这一说法未经验证。

参考链接

标签: #llama.cpp, #GGUF, #PS5 homebrew, #local LLM inference, #hardware hacking

JPEG XL 与 AVIF 网页用例对比及编码权衡讨论 ⭐️ 7.0/10

一篇对比 JPEG XL 与 AVIF 在网页图像交付中适用场景的技术文章发布，面向需要选择网页图片格式的前端与性能工程师。文章覆盖编码速度、压缩率、视觉质量等实际权衡，并涉及 AVIF 的实用编码设置。这是一篇技术比较而非新格式版本或标准发布，相关社区讨论补充了大量实测数据与分歧。

hackernews · farlight · 10月16日 16:12 · 社区讨论

「背景」 JPEG XL 此前因主流浏览器长期缺席而在网页上难以实际部署。Horizon 8 月 26 日的日报曾报道 Mozilla 宣布 Firefox 157 将在所有平台默认启用 JPEG XL，不再需要偏好设置或实验标志；10 月 8 日的日报则报道 Chrome 官方开发者博客宣布 Chrome 开始支持该格式，并指出这是它在早前被从 Chromium 移除后的重新引入。正因两大浏览器的支持刚刚落地，把它与 AVIF 这类已在网页中使用的格式做压缩效率与编码速度的实测对比，才具备现实参考意义。

「实际影响」 对需要在网页上交付图像的开发者来说，最直接的影响是格式选择受浏览器支持限制：AVIF 已可在 Chrome、Firefox、Safari 16+ 和 Edge 中使用，而 JPEG XL 截至 2026 年 4 月仍只在 Safari 中可用，因此把 JXL 作为唯一交付格式会排除大部分浏览器，通常仍需保留 AVIF、WebP 或 JPEG 回退。评论中的经验也表明，同一格式的最终体积与画质高度依赖所选的编码器和参数——有评论者称 JXL 当前编码器表现不佳、更好的编码器可让文中示例再小 30%–39%，也有人给出自己调优后的 AVIF 命令与设置——因此团队应针对自身内容实测，而不能只依据通用的格式对比结论。

「社区讨论」 评论者就编码器成熟度与画质取舍展开争论：有评论指出 libjxl 在最大 effort 下比默认慢 50–180 倍（9–46 秒），照片仅缩小 2–7%、截图和插画约缩小 25%，而 jixel 能在数秒内得到相同结果；另有评论认为 JXL 编码器目前不佳，更好的编码器可把无损示例再缩小 30–39%。关于 AVIF，有评论者称其在 F1 图片中抹掉了车身高光细节，质疑其不适合需要细看的图像，但也承认它适合大尺寸博客头图等整体观感场景；另有评论者分享了面向 2K 以内图片、可保留透明度的 ffmpeg 编码设置。

参考链接

标签: #image compression, #JPEG XL, #AVIF, #web performance, #frontend

Apple MLX 在四台 Mac Studio 上分布式运行 Muse Spark Open ⭐️ 7.0/10

Apple ML 研究团队介绍了一项用分布式 MLX 在四台 Mac Studio 上运行近万亿参数模型 Muse Spark Open 的方案，文章称该集群生成速度超过 36 tokens/秒，单台 Mac Studio 最高支持 512GB 统一内存并可向外扩展，所用最新版 MLX 同日发布。这是 Apple 描述的方案与厂商展示，并非独立复现；社区讨论同时质疑其基准公平性和 8K 上下文的实用性。

hackernews · antipaul · 10月16日 13:43 · 社区讨论

「背景」 MLX 是苹果面向 Apple Silicon 的本地推理框架，此前主要用于在单台 Mac 上运行大模型，把模型切分到多台机器上的分布式推理是其新扩展的方向。Horizon 6 月 21 日的日报曾报道，LM Studio 与苹果在 WWDC 上用预览版 LM Studio 在四台 Mac Studio 组成的集群上运行了 1 万亿参数的 Kimi K2.6（tool-2-1）；此次则是苹果自家 MLX 的分布式方案搭配接近万亿参数的 Muse Spark Open，硬件仍是四台 Mac Studio。Horizon 8 月 26 日的日报还报道了搭载 M5 Max 与 M5 Ultra、支持 Thunderbolt 5 且内存带宽最高 1.2TB/s 的新款 Mac Studio，苹果当时已把本地 AI 作为核心卖点（tool-2-2）。

「影响」 对打算本地部署的开发者来说，Muse Spark Open 是 816B 总参数、42B 激活参数的 MoE 模型，权重支持最长 1,048,576 token 的上下文（tool-3-1、tool-3-2），而苹果演示的吞吐数据只覆盖 8,192 token 上下文，因此多台 Mac Studio 在长上下文下的实际速度与内存表现仍待验证；同时分布式推理依赖当天发布的最新 MLX 版本，演示中 Meta 模型用 4-bit、Qwen 用原生 BF16 的对比也不能直接换算成其他量化配置下的性能。该模型另有 BF16 与 NVFP4 权重可在自有 GPU 上运行（tool-3-3），四台 Mac Studio 集群只是其中一条本地部署路径。

「社区讨论」 HN 评论中，peri-cl 质疑基准不公平：Muse Spark Open 以 4-bit 量化对比原生 BF16 的 Qwen，且未展示其他量化结果，并称 Muse Spark 并非其会优先考虑的模型；mrboatshoepants 则指出 15–36 tokens/秒的柱状图对应 8,192 token 上下文，认为这一长度已不够实用。liuliu 分享单台 M5 Ultra（256GiB）运行 DeepSeek 4.1 Flash 0910 约 3200 tokens/秒预填充、约 45 tokens/秒生成，并用 MathArena Apex、GPQA Diamond 等检查质量；这些均为社区经验，未经独立验证。

参考链接

标签: #MLX, #Apple Silicon, #local LLM inference, #distributed inference, #model benchmarking

Anthropic 的 Claude Code 团队谈代码审查自动化 ⭐️ 7.0/10

Anthropic 的 Claude Code 团队发布博文，介绍其内部如何处理代码审查：大部分流程自动化，人的注意力被引导到风险所在处；评测会随每次事故增长，对审查器的每次改动都会用整个评测集打分。评论区引用的博文内容还显示，文档、文案、内部功能以及藏在开关后的增量改动被列为低风险，在自动审查和安全检查通过后无需人工审查。这些是 Anthropic 对其内部实践的描述，而非独立测量的结果，完整博文也未被提供。

hackernews · pretext · 10月16日 19:04 · 社区讨论

「背景」 Anthropic 此前已在 Claude Code 中推进代码审查与代理式工作流：其官方文章介绍过如何在 Claude Code 中组织代理任务来完成代码审查（tool-2-2）。Horizon 9 月 19 日的日报也曾报道，改版后的 Claude Projects 在 Claude Code 中开启 beta，Claude 会自行拆解目标、分配并行线程并审查产出（tool-1-1）。这些早期能力与说法，是理解该团队为何要公开讨论代理生成代码审查流程的前提。

「影响」 对想借鉴该流程的团队，关键动作是先把自动审查和安全检查做成可信的放行条件，再按风险划分哪些改动可免人工审查；否则“低风险”豁免就没有依据。评论区对这种低风险豁免是否安全、以及自动审查能否覆盖新增失败模式存在明显质疑。

「社区讨论」 评论区的核心分歧在于自动化能走多远：有评论质疑没人能跟上每天约 3 万次 pull request，因而只能依赖 AI 自行审查，并追问 churn rate 和每行代码成本；也有人批评博文中“低风险文档改动在自动检查通过后无需人工审查”的做法，认为让 LLM 写文档却无人阅读不可接受。另有评论指出“放慢速度会降低错误率，但主要是因为做得更少”混淆了比率，还有人怀疑文章本身是否由 AI 撰写。

参考链接

标签: #AI code review, #Anthropic, #software engineering, #developer productivity, #code review automation

StarSkirmish Bench v0.2：Gemini 4 Argon 等模型写代码玩《星际争霸》 ⭐️ 7.0/10

作者在 Hacker News 发布了 StarSkirmish Bench v0.2，刷新了这个让大语言模型通过编写代码来玩《星际争霸：母巢之战》的基准测试，并给出 OpenAI、Anthropic、Google 和 Muse 旗舰模型的新结果；对想比较代理式编码模型的开发者而言，这是跨实验室的又一组参考排名。根据社区评论转述，榜单包含 Gemini 4 Argon、GPT-6 Astra、Claude Opus 5.5 等模型，但这些都是该基准项目自身的测试结果，而非独立复现。评论中对该方法的描述称，每个模型在其实验室的一方 CLI 工具中、以可用的最高推理设置运行，且没有联网或网页抓取。

hackernews · __cayenne__ · 10月16日 14:18 · 社区讨论

「背景」 StarSkirmish Bench 的评测方式并非让模型直接操控游戏，而是给每个模型 1 小时挂钟时间，由它编写一个《星际争霸：母巢之战》机器人，再让该程序与一批人类编写的竞技机器人及演示机器人对战，以胜率计分（tool-2-1、tool-2-3）。该基准此前已有 v0.1 版本页面（tool-2-3），本次发布的 v0.2 是结果刷新，汇总了 OpenAI、Anthropic、Google 与 Muse 各家旗舰模型的最新排名。

「影响」 若开发者把该榜单用于选型，需要注意结果与运行条件绑定：评论中描述每个模型跑在各自的 CLI harness 和最高推理设置下，并禁用联网，因此这些排名不能直接外推到 API 调用、较低推理预算或不同工具配置下的表现。

「社区讨论」 评论者 GodelNumbering 称，v0.2 排名（GPT-6 Astra ＞ GPT-6.1 Sol ＞ Gemini 4 Argon ＞ Claude Opus 5.5 ＞ Claude Fable 5.1 ＞ Claude Sonnet 5.5）与其朋友用 KataGo 作 Elo 锚点的 9x9 围棋基准排序完全一致，并认为这可能反映跨任务的通用能力排序。cgearhart 则质疑一小时时限下智能体写的机器人是否只是较差的真人脚本，以及它们是否可能从人类机器人代码中训练而来。

参考链接

标签: #LLM benchmarking, #StarCraft, #AI agents, #code generation, #game AI

Kangrejos 2026：用 pin_init 在 Rust 内核中安全实现自引用结构 ⭐️ 7.0/10

在 Kangrejos 2026 大会上，Gary Guo 提出了一种基于内核 pin_init crate 的方法，使自引用数据结构无需 unsafe 代码即可实现；这是会议演讲中展示的设计方案，并非已合入内核的改动。该方案借助 Rust 的子类型、well-formedness 规则与仅限于生命周期参数的高阶多态（如 &dyn for<'a> Fn(&'a u32)）来处理过去难以满足的生命周期约束。按演讲所述，它有望移除 Nova GPU 驱动中大部分与生命周期相关的 unsafe 代码，并可能逐步推广到其他 Rust-for-Linux 组件。原文指出问题的根源在于设备资源（例如设备内存）只在设备绑定期间有效：原有的 Devres 类型内部使用 Revocable 指针，强制每次访问都做可失败检查，给驱动代码引入了大量冗余的失败路径。

rss · LWN.net · 10月16日 18:30

「背景」 内核 Rust 中，设备资源只在设备绑定期间有效，而设备随时可能被拔出解绑；最初的 Rust 驱动绑定用 `Devres`/`Revocable` 指针强制每次访问都检查设备是否仍存在，使驱动代码遍布可失败的访问路径，而当某个进行中的补丁集需要在 `Drop` 实现（不允许失败）里访问设备时，这套抽象就不够用了——这正是自引用结构所针对的场景。Horizon 的 8 月 29 日日报曾报道，一组补丁把 Rust 版 rnull 块驱动提升到与 C 版 `null_blk` 功能对等，其中已使用 `pin_init_scope()` 做固定初始化，说明 Guo 这次扩展所依托的 `pin_init` crate（用于创建不可移动、通常面向 C 互操作的数据结构）已在内核 Rust 驱动中实际投入使用。

「对内核 Rust 开发者的影响」 若该方案被上游采纳，Rust-for-Linux 驱动开发者可以用 pin_init 直接表达设备资源的生命周期，从而不必像既有的 Devres/Revocable 抽象那样在每次访问设备时都走可能失败的检查路径——这一点在 Drop 实现中尤其关键，因为 Drop 不允许失败。但这是 Kangrejos 2026 上提出的一项设计提案，尚无已合并的 pin_init 改动；Nova 驱动及其他 Rust 组件要真正受益，需先等待相关补丁进入内核，并把现有基于 Revocable 的代码迁移过去。

参考链接

标签: #Rust, #Linux kernel, #memory safety, #self-referential data structures, #Nova GPU driver

Linux NFS 服务器近期与未来变更概览 ⭐️ 7.0/10

在 2026 年 Linux Plumbers Conference 上，NFS 开发者 Jeff Layton 介绍了 Linux NFS 服务器的一系列近期增强与后续计划。已落地的功能包括：用于同一主机上客户端/服务器（如容器化负载）的 LOCALIO，可绕过大部分协议处理直接把请求交给文件系统；异步远程复制已实现并默认启用；服务器可选择用直接 I/O 或显式关闭缓存来执行非缓存 I/O；RPC 帧上限提升到 4MB，服务器缓冲区可达 8MB；线程池支持按需动态增减（默认关闭）；以按连接划分的互斥锁取代旧的全局互斥锁。管理接口方面新增 netlink API 与 nfs-utils 中的 nfsdctl 命令，新功能将只能通过该 API 控制，旧的 /proc/fs/nfsd 接口已被弃用，mountd 也已迁移到 netlink。其他进展包括签名文件句柄、NFSv4.1 属性委派（RFC 9754）、目录委派与写委派扩展、NFSv4.2 POSIX ACL 扩展，以及用 xdrgen 自动生成 XDR 代码，并计划日后改为生成 Rust。

rss · LWN.net · 10月16日 14:26

「背景」 目录委托（directory delegation）是 NFSv4.1 的机制，允许客户端缓存目录项并在服务端发生变更时收到异步通知，从而减少往返服务器确认的开销。Horizon 2026 年 9 月 1 日的日报曾报道，Linux 7.3 合并窗口为 NFS 服务器加入了目录委托的 CB_NOTIFY 支持，这属于同一功能线的前一步；本次 LPC 演讲则给出了该特性在服务端与客户端两侧更完整的实现状态与遗留缺口。

「影响」 对 NFS 服务器管理员而言，最直接的兼容性影响是管理接口切换：新功能只能通过 netlink API（配合 nfs-utils 的 nfsdctl）配置，旧有的 /proc/fs/nfsd 接口已被弃用，因此依赖该虚拟文件系统接口的脚本和部署需要迁移。非缓存 I/O 目前由服务器选项控制，未来将作为 exports 文件中的选项暴露。

参考链接

标签: #NFS, #Linux kernel, #filesystems, #Linux Plumbers Conference, #networking

可灵 Kling 4.0 全量上线，预告 4K/HDR 与开发者 API ⭐️ 7.0/10

10 月 15 日，可灵 Kling 4.0 在 klingai.com 全量上线，创作页面同步完成升级。官方称后续将推出 4K 以及 1080p 10-bit HDR 格式输出，属于尚未交付的计划。可灵表示 Kling 4.0 的能力已接入 MCP/CLI，面向企业与开发者的 API 服务将于近期开放。该公告未披露模型参数、性能对比、定价或具体开放时间等细节。

telegram · zaihuapd · 10月16日 04:30

「背景」 可灵（Kling）是 AI 视频生成产品，其官网现已将 Kling 4.0 列为主打版本，并以音画表现和稳定动态为主要卖点（tool-2-1）。从此次上线公告看，4.0 的能力是分阶段释放的：全量上线当天同步升级的是创作页面，MCP/CLI 已可接入，而 4K、1080p 10-bit HDR 输出以及面向企业与开发者的 API 服务均被表述为「后续」或「近期」推出，因此并不属于本次已经交付的部分。

「影响」 对开发者与企业而言，当前可直接调用 Kling 4.0 的入口只有已接入的 MCP/CLI，官方 API 仍处于“近期开放”的预告阶段，因此已把视频生成接入自有产品或流水线的团队暂时无法通过 API 升级到 4.0，需要等待实际开放时间。需要 4K 或 1080p 10-bit HDR 输出的用户同样要等后续推送，现阶段仍应按官方公告的既有格式规格来规划交付。

参考链接

标签: #AI 视频生成, #可灵 Kling 4.0, #开发者 API, #MCP/CLI, #模型发布

财经新闻

商务部拟修订技术出口目录，涉人工智能、生物医药、光伏 40 项技术 ⭐️ 8.0/10

商务部就修订《中国禁止出口限制出口技术目录》公开征求意见，拟新增人工智能、生物医药、光伏三个领域共 40 项技术：人工智能 23 项（含大模型、智能体、算力集群、信息处理），生物医药 5 项（含细胞和基因治疗、小核酸药、病原微生物），光伏 12 项（含多晶硅、硅片、电池制造及承载相关技术的关键核心设备）。根据该征求意见稿，已通过开源、发表学术论文等方式进入公共领域的技术不纳入管理范围，不涉及所有权转让的对外授权模式适用自动许可等便利措施。

telegram · zaihuapd · 10月16日 09:12

「背景」 《中国禁止出口限制出口技术目录》是中国管理技术出口的清单，被列入的技术在出口前须获得许可。据商务部发言人介绍，此次在公开征求意见修订目录的同时，还对相关技术先行实施出口前登记的临时管理措施。

「影响」 涉及这 40 项人工智能、生物医药和光伏技术对外许可或转让的中国企业和科研机构，在目录正式修订前须先办理出口前登记，相关技术交易的流程和时点因此受到约束。

参考链接

标签: #export-controls, #China-policy, #artificial-intelligence, #biotechnology, #solar