由于能支付宝充值，因此该卡片是国内推广最多的卡片之一。
目前相对正规的U 卡基本已经不支持在国内消费，比如Bybit 等卡片已经无法绑定主流支付方式。
Kimi 发布下一代基础大模型 k2
月之暗面于 2025 年 7 月 12 日发布并开源 Kimi K2 大模型，总参数量达 1 万亿，采用 MoE 架构，激活参数 32 亿。该模型支持 128K 最大上下文长度，在自主编程、工具调用和数学推理等基准测试中表现突出，取得开源模型 SOTA 成绩。模型技术亮点包括 MuonClip 优化器，在 15.5 万亿词元数据上实现稳定训练，以及大规模 Agentic 数据合成和通用强化学习；未来将加入思考和视觉理解能力。
本次开源包括 Kimi-K2-Base（基础预训练模型）和 Kimi-K2-Instruct（指令微调版本），遵循修改版 MIT 协议，可商用。
API 服务已上线，定价为输入 4 元/百万词元，输出 16 元/百万词元。
（月之暗面）
月之暗面于 2025 年 7 月 12 日发布并开源 Kimi K2 大模型，总参数量达 1 万亿，采用 MoE 架构，激活参数 32 亿。该模型支持 128K 最大上下文长度，在自主编程、工具调用和数学推理等基准测试中表现突出，取得开源模型 SOTA 成绩。模型技术亮点包括 MuonClip 优化器，在 15.5 万亿词元数据上实现稳定训练，以及大规模 Agentic 数据合成和通用强化学习；未来将加入思考和视觉理解能力。
本次开源包括 Kimi-K2-Base（基础预训练模型）和 Kimi-K2-Instruct（指令微调版本），遵循修改版 MIT 协议，可商用。
API 服务已上线，定价为输入 4 元/百万词元，输出 16 元/百万词元。
（月之暗面）
Kagi 推出新闻阅读器 Kite
付费搜索引擎 Kagi 推出新闻阅读器 Kite，主打以人工智能驱动的世界新闻和多元角度，并可借助 Kagi Translate 将新闻内容本地化。
地址：
https://kite.kagi.com
付费搜索引擎 Kagi 推出新闻阅读器 Kite，主打以人工智能驱动的世界新闻和多元角度，并可借助 Kagi Translate 将新闻内容本地化。
地址：
https://kite.kagi.com
北京时间 2025 年 7 月 10 日，Elon Musk 旗下的 xAI 公司正式发布了其下一代大语言模型 Grok 4 。该模型在多项关键基准测试中表现出色，综合性能超越了 OpenAI 的 o3 和 Google 的 Gemini 2.5 Pro 等主要竞争对手 。
Grok 4 在被誉为「人类最后的考试 (HLE)」的超高难度测试中得分远超以往模型，其增强版 Grok 4 Heavy 更是在 AIME 2025 (美国数学邀请赛) 中取得满分 。根据 AI 评估平台 Artificial Analysis 的数据，Grok 4 目前在综合性能上排名第一 。
Grok 4 是一个支持文本和图像输入的多模态模型，拥有 256K 的上下文窗口 。其强大的推理能力得益于在强化学习 (RL) 上的大量投入 。Grok 4 Heavy 版本更是一个多智能体系统，能协同解决复杂问题 。
目前，Grok 4 已向付费用户开放，提供每年 300 美元和 3000 美元（针对 Grok 4 Heavy）两种订阅等级 。其 API 接口也已上线，价格与前代持平 。xAI 还公布了未来计划，将在未来数月内陆续发布专用的编码模型、多模态智能体和视频生成模型 。
（综合媒体报道）
Vercel 宣布收购 NuxtLabs，标志着 Nuxt 这个基于 Vue.js 的全栈框架将加入 Vercel 生态。NuxtLabs 成立于 2017 年，其开源框架 Nuxt 每周下载量超过百万次，以文件路由、自动导入和服务器端渲染功能著称。
此次收购后，NuxtLabs 计划将 Nuxt UI v4 的所有 Pro 组件免费开放，并附带 Figma Kit。基于 Git 的内容管理系统 Nuxt Studio 也将开源，支持实时协作和类 Notion 编辑体验。同时，即将推出的 NuxtHub 将与 Vercel Marketplace 集成，支持 Postgres 和 Redis 等服务。Vue.js 创始人尤雨溪确认，此前与 VoidZoid 合作开发 DevTools 的合同仍然有效。
收购完成后，Vercel 旗下将拥有 Next.js、Svelte 和 Nuxt 三大主流前端框架。虽然 Vercel 承诺保持 Nuxt 的开源特性和独立治理模式，但部分开发者对前端框架生态集中化表示担忧。支持者认为此举为 Nuxt 提供了可持续发展的资源保障，质疑者则担心可能形成技术垄断和厂商绑定。
（Vercel）
华为盘古大模型涉嫌抄袭争议
HonestAGI 近日发布 报告 ，指出华为盘古 Pro MoE 72B 大语言模型与阿里千问 2.5 14B 模型存在异常高的相似性。该分析基于一种新的参数分布指纹识别技术，通过检测注意力机制参数的标准差分布模式来识别模型血缘关系。
分析结果显示，两个模型在查询、键值、数值和输出投影矩阵上的相关系数分别达到 0.867、0.928、0.939 和 0.973，综合相关系数为 0.927，远超正常独立开发模型间 0.3 至 0.7 的相似度范围。技术报告还发现，盘古模型保留了千问模型特有的 QKV bias 设计和注意力层归一化权重模式，而这些特征在千问后续版本中已被放弃。
同时，一位自称华为诺亚方舟实验室员工的匿名人士发布详细 举报材料 ，指控由王云鹤领导的「小模型实验室」多次采用「套壳」现有模型的做法。举报者称，盘古 Pro MoE 72B 虽然内部声称是从小模型实验室的 7B 模型扩增而来，但实际上是基于千问 2.5 14B 模型进行的改造。为了掩盖模型来源，开发团队付出了巨大的算力成本进行续训，甚至故意训练「脏数据」来模糊原始特征。举报者表示，用于「洗参数」的算力投入已经足够从头训练一个同等规模的模型。
华为诺亚方舟实验室于 7 月 5 日发布 声明 回应争议。声明表示，盘古 Pro MoE 是基于昇腾硬件平台开发训练的基础大模型，并非基于其他厂商模型增量训练而来。华为承认模型的部分基础组件代码实现参考了业界开源实践，但强调严格遵循开源许可证要求。
2025 年 3 月，华为诺亚方舟实验室发生人事变动，90 后王云鹤接替姚骏担任实验室主任。王云鹤此前担任华为算法应用部部长，曾因高效 AI 算法创新获得华为「十大发明」奖项。
（综合媒体报道）
HonestAGI 近日发布 报告 ，指出华为盘古 Pro MoE 72B 大语言模型与阿里千问 2.5 14B 模型存在异常高的相似性。该分析基于一种新的参数分布指纹识别技术，通过检测注意力机制参数的标准差分布模式来识别模型血缘关系。
分析结果显示，两个模型在查询、键值、数值和输出投影矩阵上的相关系数分别达到 0.867、0.928、0.939 和 0.973，综合相关系数为 0.927，远超正常独立开发模型间 0.3 至 0.7 的相似度范围。技术报告还发现，盘古模型保留了千问模型特有的 QKV bias 设计和注意力层归一化权重模式，而这些特征在千问后续版本中已被放弃。
同时，一位自称华为诺亚方舟实验室员工的匿名人士发布详细 举报材料 ，指控由王云鹤领导的「小模型实验室」多次采用「套壳」现有模型的做法。举报者称，盘古 Pro MoE 72B 虽然内部声称是从小模型实验室的 7B 模型扩增而来，但实际上是基于千问 2.5 14B 模型进行的改造。为了掩盖模型来源，开发团队付出了巨大的算力成本进行续训，甚至故意训练「脏数据」来模糊原始特征。举报者表示，用于「洗参数」的算力投入已经足够从头训练一个同等规模的模型。
华为诺亚方舟实验室于 7 月 5 日发布 声明 回应争议。声明表示，盘古 Pro MoE 是基于昇腾硬件平台开发训练的基础大模型，并非基于其他厂商模型增量训练而来。华为承认模型的部分基础组件代码实现参考了业界开源实践，但强调严格遵循开源许可证要求。
2025 年 3 月，华为诺亚方舟实验室发生人事变动，90 后王云鹤接替姚骏担任实验室主任。王云鹤此前担任华为算法应用部部长，曾因高效 AI 算法创新获得华为「十大发明」奖项。
（综合媒体报道）
AI 代码编辑器 Cursor 宣布就此起对个人 Pro 用户的计费模式调整造成的模糊致歉，并承诺：
- 退还过去三周内用户因使用而产生的任何意外费用
- 新的 Pro 定价允许用户使用无限次 Tab 补全和 Auto 模型，并提供 20 美金的 API 额度供高级模型和高级功能调用（无需额外计费）。
（Cursor Blog）
- 退还过去三周内用户因使用而产生的任何意外费用
- 新的 Pro 定价允许用户使用无限次 Tab 补全和 Auto 模型，并提供 20 美金的 API 额度供高级模型和高级功能调用（无需额外计费）。
（Cursor Blog）
歌词翻译是 iOS 26 的新功能，在新版本中，歌词翻译是可选功能，且开启后用户应能看到源语言和本地语言的双语歌词。
据大量用户实测，Android 等非第一方平台的 Apple Music 客户端不受影响。
Grok 4 系列模型据信将在一周内发布。
目前消息称 Grok 4 系列会有 grok-4-0629 和 grok-4-code-0629 两个型号。具有和前代模型相同的 128k 上下文窗口，支持推理，但只能输入文本模态内容。
目前消息称 Grok 4 系列会有 grok-4-0629 和 grok-4-code-0629 两个型号。具有和前代模型相同的 128k 上下文窗口，支持推理，但只能输入文本模态内容。
百度开源 ERNIE 4.5 大模型家族
百度正式宣布开源其最新的旗舰级大模型系列 ERNIE 4.5，这是一个包含 10 个不同变体的大规模多模态模型家族。该系列包含 2 个多模态大模型和 4 个大语言模型，共计 23 个模型版本，其中最大模型拥有 4240 亿参数，47B 活跃参数。
ERNIE 4.5 采用了创新的异构多模态混合专家（MoE）架构，支持跨模态参数共享的同时，也为每个模态保留专用参数。这种设计在提升多模态理解能力的同时，实现了文本处理性能的同步增强。模型支持图像、视频和文本等多种输入模态，并生成文本输出。
在技术创新方面，ERNIE 4.5 在三个关键领域实现了突破：多模态异构 MoE 预训练、高效扩展的基础设施，以及针对特定模态的后训练。该模型在预训练阶段达到了 47% 的模型 FLOPs 利用率（MFU），在 2016 块 NVIDIA H800 GPU 上实现了高效训练。
性能评测显示，ERNIE 4.5 在指令遵循、世界知识记忆、视觉理解和多模态推理等方面表现出色。在传统基准测试如 MMLU、MMLU Pro 等任务上，该模型与当前最强的 DeepSeek-V3、Qwen 等模型不相上下。然而在更具挑战性的新评测任务如 AIME、LiveCodeBench 等方面，表现相对一般。
本次开源遵循 Apache 2.0 协议，意味着开发者可以自由进行商业化使用和二次开发。百度还同时开源了完整的开发工具链，包括 ERNIEKit 训练工具包和 FastDeploy 推理部署工具包，涵盖从训练、微调到部署的全栈能力。模型提供了 PyTorch 和 PaddlePaddle 两个版本，以满足不同开发者的需求。
（技术报告）
百度正式宣布开源其最新的旗舰级大模型系列 ERNIE 4.5，这是一个包含 10 个不同变体的大规模多模态模型家族。该系列包含 2 个多模态大模型和 4 个大语言模型，共计 23 个模型版本，其中最大模型拥有 4240 亿参数，47B 活跃参数。
ERNIE 4.5 采用了创新的异构多模态混合专家（MoE）架构，支持跨模态参数共享的同时，也为每个模态保留专用参数。这种设计在提升多模态理解能力的同时，实现了文本处理性能的同步增强。模型支持图像、视频和文本等多种输入模态，并生成文本输出。
在技术创新方面，ERNIE 4.5 在三个关键领域实现了突破：多模态异构 MoE 预训练、高效扩展的基础设施，以及针对特定模态的后训练。该模型在预训练阶段达到了 47% 的模型 FLOPs 利用率（MFU），在 2016 块 NVIDIA H800 GPU 上实现了高效训练。
性能评测显示，ERNIE 4.5 在指令遵循、世界知识记忆、视觉理解和多模态推理等方面表现出色。在传统基准测试如 MMLU、MMLU Pro 等任务上，该模型与当前最强的 DeepSeek-V3、Qwen 等模型不相上下。然而在更具挑战性的新评测任务如 AIME、LiveCodeBench 等方面，表现相对一般。
本次开源遵循 Apache 2.0 协议，意味着开发者可以自由进行商业化使用和二次开发。百度还同时开源了完整的开发工具链，包括 ERNIEKit 训练工具包和 FastDeploy 推理部署工具包，涵盖从训练、微调到部署的全栈能力。模型提供了 PyTorch 和 PaddlePaddle 两个版本，以满足不同开发者的需求。
（技术报告）
据 The Information 报道，DeepSeek 备受期待的下一代大语言模型 R2 可能无法像其前任 R1 那样在中国迅速广泛普及。据中国主要云服务提供商员工透露，国内英伟达服务器芯片短缺是主要原因，而美国最近禁止专为中国市场设计的英伟达 H20 芯片销售进一步加剧了这一问题。
DeepSeek 的模型完全针对英伟达的硬件和软件进行了优化，在英伟达芯片上运行时表现最佳。R1 发布后，包括字节跳动、阿里巴巴和腾讯在内的中国科技巨头在 2025 年第一季度为英伟达 H20 芯片下了 160 亿美元订单，相当于 120 万块芯片。相比之下，2024 年英伟达向中国发运了 100 万颗 H20 芯片。
据知情人士透露，由对冲基金公司幻方量化拥有的 DeepSeek 尚未确定 R2 的发布时间。CEO 梁文锋对新模型的性能并不满意，工程师正在持续优化直到获得批准发布。
英伟达在声明中表示：「中国拥有全球最大的开发者群体之一，他们创建了开源基础模型和非军事应用。虽然安全至关重要，但这些应用都应以美国的人工智能堆栈为最佳运行平台。」
云服务提供商员工表示，如果 R2 发布后能超越现有开源模型，其需求将令正在应对英伟达芯片短缺的中国云提供商应接不暇。目前使用 R1 的云客户大部分都使用英伟达 H20 芯片运行该模型。
（The Information）
Cloudflare 于 6 月 24 日宣布，Cloudflare Containers 现已面向所有付费计划用户提供公开测试版服务。
Cloudflare Containers 与现有的 Workers 平台实现了紧密集成，开发者只需定义几行代码即可创建容器，就像部署 Worker 一样简单。容器无需管理跨多个区域的配置。当请求新的容器实例时，Cloudflare 会从其全球网络中选择已预置就绪容器的最佳位置，初始容器启动仅需几秒钟时间。
该平台的突出特点是其可编程性。容器实例可以按需启动，并由 Workers 代码控制。开发者可以根据需求灵活选择工具：轻量级可扩展任务使用 Worker，需要更多算力和灵活性的任务使用容器。这为开发者提供了运行以前无法在 Workers 中运行的库的能力，例如使用 FFmpeg 将视频转换为 GIF 的应用程序。
在定价方面，Containers 采用按使用量付费的透明模式。目前提供三种实例类型：dev（256 MiB 内存）、basic（1 GiB 内存）和 standard（4 GiB 内存）。费用从向容器发送请求时开始计算，在容器实例进入休眠状态后停止计费。容器按每 10 毫秒的活跃运行时间计费，内存费率为每 GiB- 秒 0.0000025 美元，CPU 费率为每 vCPU- 秒 0.000020 美元。
Cloudflare 已经规划了多项未来增强功能，包括提高并发实例限制、支持基于利用率的全球自动扩展、增强 Containers 和 Workers 之间的通信方式，以及与开发者平台其他服务的更深度集成等。
（Cloudflare 官方博客）
Google Cloud 发布全球宕机故障复盘
太平洋夏令时间 2025 年 6 月 12 日 10 时 49 分（北京时间 6 月 13 日凌晨 1 时 49 分），Google Cloud Platform（GCP）发生全球性重大故障，导致包括 Gmail、Google Drive、YouTube 在内的数十项 Google 服务以及依赖 GCP 的第三方服务出现大面积中断。故障持续约 3 小时，其中美国中部地区 us-central1 的恢复时间长达 2 小时 40 分钟。
根据 Google 发布的详细事故报告，故障源于 Service Control 系统 —— 负责 Google 所有 API 请求授权和配额管理的核心组件。5 月 29 日，Google 向 Service Control 部署了一项新的配额策略检查功能，但该代码变更存在致命缺陷：缺乏适当的错误处理机制，且未受功能标志位（Feature Flag）保护。
6 月 12 日，当一项包含空白字段的策略变更被推送到全球数据库时，触发了有问题的代码路径。空指针异常导致 Service Control 二进制文件进入崩溃循环，由于配额管理的全球性质，故障在数秒内蔓延至所有地区。
Google 工程团队在 2 分钟内开始响应，10 分钟内识别根本原因，25 分钟内部署缓解措施。然而，在 us-central1 等大型地区，Service Control 任务重启时产生的「雷群效应」（Thundering Herd）过载了底层基础设施，延长了恢复时间。
此次故障影响了超过 80 项 Google Cloud 服务，包括身份和访问管理（IAM）、Cloud Storage、BigQuery、Vertex AI 等，以及 Gmail、Google Calendar、Google Drive 等 Workspace 产品。Spotify、Discord、Cloudflare、Anthropic Claude、OpenAI 等依赖 GCP 的第三方服务也受到波及。
Google 承诺采取一系列补救措施，包括模块化 Service Control 架构以实现故障开放（Fail-Open）、审查所有消费全球复制数据的系统、强制关键二进制文件变更必须受功能标志保护，以及改进错误处理和测试实践。公司还计划确保监控和通信基础设施在 Google Cloud 主要服务宕机时仍能正常运行。
（Google Cloud）
太平洋夏令时间 2025 年 6 月 12 日 10 时 49 分（北京时间 6 月 13 日凌晨 1 时 49 分），Google Cloud Platform（GCP）发生全球性重大故障，导致包括 Gmail、Google Drive、YouTube 在内的数十项 Google 服务以及依赖 GCP 的第三方服务出现大面积中断。故障持续约 3 小时，其中美国中部地区 us-central1 的恢复时间长达 2 小时 40 分钟。
根据 Google 发布的详细事故报告，故障源于 Service Control 系统 —— 负责 Google 所有 API 请求授权和配额管理的核心组件。5 月 29 日，Google 向 Service Control 部署了一项新的配额策略检查功能，但该代码变更存在致命缺陷：缺乏适当的错误处理机制，且未受功能标志位（Feature Flag）保护。
6 月 12 日，当一项包含空白字段的策略变更被推送到全球数据库时，触发了有问题的代码路径。空指针异常导致 Service Control 二进制文件进入崩溃循环，由于配额管理的全球性质，故障在数秒内蔓延至所有地区。
Google 工程团队在 2 分钟内开始响应，10 分钟内识别根本原因，25 分钟内部署缓解措施。然而，在 us-central1 等大型地区，Service Control 任务重启时产生的「雷群效应」（Thundering Herd）过载了底层基础设施，延长了恢复时间。
此次故障影响了超过 80 项 Google Cloud 服务，包括身份和访问管理（IAM）、Cloud Storage、BigQuery、Vertex AI 等，以及 Gmail、Google Calendar、Google Drive 等 Workspace 产品。Spotify、Discord、Cloudflare、Anthropic Claude、OpenAI 等依赖 GCP 的第三方服务也受到波及。
Google 承诺采取一系列补救措施，包括模块化 Service Control 架构以实现故障开放（Fail-Open）、审查所有消费全球复制数据的系统、强制关键二进制文件变更必须受功能标志保护，以及改进错误处理和测试实践。公司还计划确保监控和通信基础设施在 Google Cloud 主要服务宕机时仍能正常运行。
（Google Cloud）
GitHub Copilot 高级请求计费将于 2025 年 6 月 18 日起施行
GitHub 官方宣布，Copilot 的高级请求（Premium Requests）将于 2025 年 6 月 18 日起正式计费，适用于所有订阅计划。在此之前，用户可免费使用 Copilot 的高级模型，无需为额外的高级请求支付费用。计费开始后，用户的高级请求计数器将重置为零，并可在后台实时追踪用量。部分请求可能会因高需求而受到速率限制。
高级请求主要用于 Copilot Chat、Copilot coding agent、Copilot 代码审查、Copilot Extensions 等高级功能。不同 AI 模型对应不同的高级请求倍率（Multiplier），如 GPT-4.5 单次请求计为 50 个高级请求，Claude Opus 4 为 10，Gemini 2.0 Flash 为 0.25，o3-mini 和 o4-mini 为 0.33。付费用户使用 GPT-4.1 或 GPT-4o 基础模型时不计入高级请求额度，免费用户则每次计 1 个。
GitHub 官方宣布，Copilot 的高级请求（Premium Requests）将于 2025 年 6 月 18 日起正式计费，适用于所有订阅计划。在此之前，用户可免费使用 Copilot 的高级模型，无需为额外的高级请求支付费用。计费开始后，用户的高级请求计数器将重置为零，并可在后台实时追踪用量。部分请求可能会因高需求而受到速率限制。
高级请求主要用于 Copilot Chat、Copilot coding agent、Copilot 代码审查、Copilot Extensions 等高级功能。不同 AI 模型对应不同的高级请求倍率（Multiplier），如 GPT-4.5 单次请求计为 50 个高级请求，Claude Opus 4 为 10，Gemini 2.0 Flash 为 0.25，o3-mini 和 o4-mini 为 0.33。付费用户使用 GPT-4.1 或 GPT-4o 基础模型时不计入高级请求额度，免费用户则每次计 1 个。
微软 Office 团队完成从 Source Depot 到 Git 的大规模迁移
微软 Office 工程团队完成了一项历时数年的重大技术迁移，将版本控制系统从内部专有的 Source Depot 全面转向开源的 Git。这一迁移项目涉及超 4000 名工程师。
Source Depot 是微软基于 Perforce 技术在 2000 年代初开发的定制版本控制系统，专门用于管理 Windows 和 Office 等大型代码库。当时 Git 尚未诞生，Subversion 也不够成熟，Source Depot 承担了管理数百万行代码的重任。然而，随着时间推移，这一集中式系统的局限性逐渐暴露：获取 Office 代码库需要数小时，分支操作异常复杂，合并变更的流程更是令开发者苦不堪言。
迁移面临的最大技术挑战是 Office 代码库的庞大规模 —— 超过 270 GB 的大小和数百万个文件，远超标准 Git 的处理能力。为解决这一问题，微软开发了 Virtual File System for Git (VFS for Git) 技术，通过虚拟化文件系统实现按需下载文件，将克隆时间从 12 小时缩短至几分钟，检出操作从 2 至 3 小时缩短至 30 秒，状态检查从 10 分钟缩短至 4 至 5 秒。
为此，微软采用了「平行宇宙」迁移策略，创建与 Source Depot 持续同步的 Git 代码库，确保迁移过程的平稳进行。团队还为开发者提供了沙箱环境进行培训，并设置了「红色按钮」回滚机制以应对可能出现的问题。
（danielsada.tech）
微软 Office 工程团队完成了一项历时数年的重大技术迁移，将版本控制系统从内部专有的 Source Depot 全面转向开源的 Git。这一迁移项目涉及超 4000 名工程师。
Source Depot 是微软基于 Perforce 技术在 2000 年代初开发的定制版本控制系统，专门用于管理 Windows 和 Office 等大型代码库。当时 Git 尚未诞生，Subversion 也不够成熟，Source Depot 承担了管理数百万行代码的重任。然而，随着时间推移，这一集中式系统的局限性逐渐暴露：获取 Office 代码库需要数小时，分支操作异常复杂，合并变更的流程更是令开发者苦不堪言。
迁移面临的最大技术挑战是 Office 代码库的庞大规模 —— 超过 270 GB 的大小和数百万个文件，远超标准 Git 的处理能力。为解决这一问题，微软开发了 Virtual File System for Git (VFS for Git) 技术，通过虚拟化文件系统实现按需下载文件，将克隆时间从 12 小时缩短至几分钟，检出操作从 2 至 3 小时缩短至 30 秒，状态检查从 10 分钟缩短至 4 至 5 秒。
为此，微软采用了「平行宇宙」迁移策略，创建与 Source Depot 持续同步的 Git 代码库，确保迁移过程的平稳进行。团队还为开发者提供了沙箱环境进行培训，并设置了「红色按钮」回滚机制以应对可能出现的问题。
（danielsada.tech）
