苹果在 iOS 26 推出的全新 Liquid Glass 界面曾引发巨大争议，如今公司被认为终于在功能更新与性能优化之间找到了新的平衡节奏。 该界面在视觉上强调光影、反射和折射效果，苹果高管曾表示这是为了让软件“更具表现力、更具响应感”，但用户在多个平台上抱怨其带来明显的性能下降。面对负面反馈，苹果并未放弃这一方向，而是让工程和开发团队“回到绘图板前”，细致梳理哪些效果需要调整、删减或重写，被认为是一次来得很晚但终究到来的系统级“补课”。 此前有报告称，Liquid Glass 不会被弃用，而是会在未来几年持续获得渐进式改进，本次更新只是长期优化计划的第一步。在今年的 WWDC 2026 上，苹果公布了其各平台系统合计 262 项修复和改进，其中包括被视为性能关键改动的“CPU 调度器优化”等。外界推测，苹果内部最初列出的待改进项目可能远不止这些，只是部分内容因优先级不够高而被砍掉，而这一切的源头都指向最初那次 UI 大改所引发的连锁反应。 在作者看来，这一轮 iOS 27、iPadOS 27、macOS 27、watchOS 27、tvOS 27、visionOS 27 和 homeOS 27 的统一优化，可被视作苹果对用户的一次“变相道歉”，承认公司在过去几年里一味追求界面与新功能，却没有及时把性能和稳定性问题解决。文章指出，苹果鲜少公开认错，如今选择在全部操作系统上集中发力优化，某种程度上是在用行动回应此前被忽视的性能与体验反馈。 作者据此判断，苹果未来在软件更新节奏上很可能会形成一个新的模式：在功能性更新与优化性更新之间轮替推进。今年已经是以优化为主的一年，因此在明年的 iOS 28、iPadOS 28、macOS 28 等版本中，预计会重新把重点放回到新功能与新特性上，而对底层优化的投入则相对收缩。这被认为与此前“年年叠加新功能、频繁改 UI 却鲜少理会用户反馈”的做法截然不同，标志着苹果意识到，如果基础体验不过关，再多的视觉效果和新增功能也难以赢得口碑。 文章引用用户反馈称，一位 M1 Pro 版 MacBook Pro 用户表示，当前 macOS 27 Golden Gate 开发者测试版在日常使用中的表现甚至优于稳定版 macOS Tahoe，过去被抱怨的“整体卡顿感”有明显缓解。在作者看来，这是苹果本轮优化见效的一个具体案例，也为其“先做优化、再谈新功能”的节奏提供了现实支撑。同时，iOS 27 依然支持发布已接近七年的 iPhone 11，被视为苹果在向旧设备用户释放善意，让“老机型也能分享到优化成果”。 文章最后指出，如果说 2026 年在软件层面属于苹果的一年，那么竞争对手若想跟上节奏，可能不得不在更新策略上采取类似“功能与优化交替”的方式。作者也抛出问题邀请读者投票：苹果是否应该继续坚持“功能一年、优化一年”的轮换模式，有人认为这是在体验和创新之间实现平衡，也有人主张苹果应长期把优化放在首位，减少大幅度的界面和功能改动。 查看评论
7 个帖子 - 7 位参与者 阅读完整话题
IT之家 6 月 9 日消息，苹果今日宣布，Siri AI 将提供“全新的语音体验”， 让用户可以自定义语音助手的声音 。 在支持苹果最新端侧模型的设备上，Siri AI 将带来更具表现力的声音，同时系统范围内的语音输入准确度也会显著提升。 从截图可以看到， 用户可以通过带有滑块的新界面，根据个人喜好调整 Siri 语音的表现力和节奏 。而在 iOS 27 开发者预览版 Beta 1 中，该功能仅限美国用户使用。 此外，自定义 Siri AI 语音助手的能力并非所有机型都有，以下是 Siri AI 语音自定义功能的最低硬件要求： iPhone Air、iPhone 17 Pro、配备 M4 及后续芯片且内存至少 12GB 的 iPad，以及配备 M3 及后续芯片且内存至少 12GB 的 Mac。 IT之家注意到，更新后的语音输入引擎将以精致文本形式捕捉语音， 实时自动处理大小写、标点和格式化 。苹果表示，提高语音理解意味着用户可以更自然地与 Siri AI 对话，并相信自己的话语会准确且如预期般呈现。 根据苹果官方介绍，苹果称 Siri AI 是“全新版本的 Siri”，并表示它比之前的智能助手版本更具对话性，功能也更强大。 Siri AI 支持在系统范围内使用，能够读取屏幕上的内容并与你的应用程序互动；并配有独立 App，屏幕顶部的灵动岛会冒出很大的气泡。
现在豆包是不是降智了，5月份还能翻译，现在经常遇到翻译失败。有兄弟们知道原因么。难道要我付费的节奏？ 4 个帖子 - 4 位参与者 阅读完整话题
最近发现一个很想改变的现象，特别是读《认知觉醒》这本书的时候，感觉跟“先帝创业未半而中道崩殂”一样。每次想静下心来读书，翻开书页不到十分钟，手就不自觉地摸向手机。 在读书-刷手机-哈哈大笑-懊悔中循环。 我发现自己读书的目的已经变了。不再是为了享受那种沉浸在故事里的快感，也不是因为遇到困难而去寻求答案；而是为了"完成"这件事。就像打卡一样，读完了，数字加一，好像就完成了某种任务。 所以如何去找寻人生的意义呢？ 5 个帖子 - 5 位参与者 阅读完整话题
1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。
1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。
cpa 天天更新，跟不上节奏又封号，这里做了个docker compose 每两个小时自动尝试更新 services: cli-proxy-api: image: eceasy/cli-proxy-api:latest container_name: cli-proxy-api restart: unless-stopped ports: - "8317:8317" volumes: - ./config.yaml:/CLIProxyAPI/config.yaml - ./auth-dir:/root/.cli-proxy-api labels: - "com.centurylinklabs.watchtower.enable=true" watchtower: image: containrrr/watchtower:latest container_name: watchtower restart: unless-stopped environment: TZ: Asia/Shanghai WATCHTOWER_SCHEDULE: "0 0 */2 * * *" WATCHTOWER_CLEANUP: "true" WATCHTOWER_LABEL_ENABLE: "true" WATCHTOWER_ROLLING_RESTART: "true" WATCHTOWER_TIMEOUT: "30s" volumes: - /var/run/docker.sock:/var/run/docker.sock 5 个帖子 - 5 位参与者 阅读完整话题
1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。
1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。
Anthropic 呼吁全球主要 AI 实验室考虑放缓前沿模型开发节奏。该公司在博客中表示，AI 进步速度极快，可能很快出现无需人类干预即可自我改进的“递归自我改进”能力，这会带来重大社会风险。公司警告，若没有全球协调机制，单方暂停只会让对手抢跑，因此提议多国主要 AI 企业同步停止并遵守可验证规则，避免单一暂停让对手趁机赶超。 该提议在华盛顿和硅谷遇冷，批评者认为其夸大风险，实为借安全之名打压对手，且放缓研发恐让中国获得战略优势。Anthropic 近日刚完成近万亿美元估值的融资，并已提交 IPO 保密文件。 anthropic.com When AI builds itself Our progress toward recursive self-improvement, and its implications. 24 个帖子 - 24 位参与者 阅读完整话题
想着周五把剩下限额登完，下周又刷新了，这一重置感觉又被打乱了节奏。大家没有这种感觉？ 12 个帖子 - 12 位参与者 阅读完整话题
我已经 /fast 开蹬了, 诸君 2 个帖子 - 2 位参与者 阅读完整话题
虽然全程没听懂潮汕话说的是啥，但那份真挚的感情，确实很触动内心。 在这个快节奏时代，这种跨越时间和空间的情感，真的会让人感觉很珍贵！ 5 个帖子 - 5 位参与者 阅读完整话题
官网： https://cwtus1pn64.jobs.feishu.cn/index 工作地点：杭州，广州 关于 AtlasV 2019 年成立，专注 AI + 移动应用出海。总部分在新加坡，产研在杭州/广州，在印尼、印度、巴西有本地团队。 产品矩阵：AI 图像、AI 视频、工具类产品，一共 40 多款，全球 150+ 国家发行，累计用户超 7 亿，月活 5000 万以上。 在美国区 App Store 拿过 AI 图像搜索第一、AI 视频前五。2024 年拿到两个授权发明专利。 团队 以 90 后为主，核心成员来自华为、网易、百度、腾讯、字节。扁平管理，节奏快，不搞 PPT 文化，做出来的产品直接面向全球用户，数据说话。 在招什么人 做产品的人：会用 AI 提效、有 sense 、喜欢动手而不是写文档 做增长的人：对海外用户有感觉，懂本地化 做技术的人：端侧 AI 、跨平台方案 不卡学历，但希望你做过东西、能说清楚自己做过什么。 为什么选我们 产品已经跑通，有正向现金流 出海赛道，中国团队有结构性优势 团队小，你做的事能直接看到结果
官网： https://cwtus1pn64.jobs.feishu.cn/index 工作地点：杭州，广州 关于 AtlasV 2019 年成立，专注 AI + 移动应用出海。总部分在新加坡，产研在杭州/广州，在印尼、印度、巴西有本地团队。 产品矩阵：AI 图像、AI 视频、工具类产品，一共 40 多款，全球 150+ 国家发行，累计用户超 7 亿，月活 5000 万以上。 在美国区 App Store 拿过 AI 图像搜索第一、AI 视频前五。2024 年拿到两个授权发明专利。 团队 以 90 后为主，核心成员来自华为、网易、百度、腾讯、字节。扁平管理，节奏快，不搞 PPT 文化，做出来的产品直接面向全球用户，数据说话。 在招什么人 做产品的人：会用 AI 提效、有 sense 、喜欢动手而不是写文档 做增长的人：对海外用户有感觉，懂本地化 做技术的人：端侧 AI 、跨平台方案 不卡学历，但希望你做过东西、能说清楚自己做过什么。 为什么选我们 产品已经跑通，有正向现金流 出海赛道，中国团队有结构性优势 团队小，你做的事能直接看到结果
IT之家 5 月 28 日消息，NBA 总裁亚当 · 肖华表示，联盟将借助人工智能实现出界判罚等一类判罚的自动化，以此加快比赛节奏、减少球权争议。 IT之家注意到，肖华将这套系统比作网球运动中使用的鹰眼技术，该技术可通过电子边线判罚系统快速判定球是否出界。 当地时间本周三，肖华在 ESPN 的《Pat McAfee Show》节目中称：“我们将转向这样一种系统，将这类判罚全部改为自动化判定。最终球权归属湖人、尼克斯或是其他球队，这类判罚都将由赛场周边摄像头配合人工智能自动化系统完成。” 这项技术能即时做出相关判罚，让裁判可以专注于身体接触与犯规判罚。他说道：“这类客观判罚将不再由裁判人工裁定，也不会再出现针对此类判罚的挑战申诉。” 肖华并未公布该系统正式落地的具体时间，但表示推进速度会“相当快”。 为提升判罚准确度，NBA 近年越来越依赖录像回放与集中裁定机制，不过回放环节往往会拖慢比赛节奏。 肖华表示，在判定身体接触方面，裁判的作用依旧无可替代，这类情况需要人为判断球员是否遭到犯规阻挡。“几乎每一个回合都会出现身体接触，但并非所有接触都构成犯规。这类判罚无法单凭摄像头完成。”
一时兴起 买了几个甲骨文账号 带原油的 存活不到一个星期全挂了 只是登录了一下 机器都还没开 封号有点太快了吧 甲骨文依据什么来封号的？ 邮箱里也没有任何通知 9 个帖子 - 5 位参与者 阅读完整话题
IT之家 5 月 26 日消息，Linux 创始人林纳斯 · 托瓦兹（Linus Torvalds）于 5 月 24 日再次发文表达不满，称很多 AI 提交的修复并非契合当前内核开发阶段，加重维护人员负担。 IT之家此前报道，托瓦兹于 5 月 17 日发文抨击， 称内核开发流程中，AI 工具已给维护开发工作造成额外负担 。开发者一边用 AI 找问题，一边却不提交对应修复，已经把排查和收尾工作甩给少数维护者。 托瓦兹于 5 月 24 日再次发文，指出开发者借助 AI 工具， 提交大量细碎补丁，导致 Linux RC5 体量异常偏大。 托瓦兹指出在内核发布周期后段，维护重点不应该放在长期存在、又不紧急的老问题上， 而是应该聚焦修复 Bug，新改动引发的错误方面。 如果开发者把这些针对旧问题的 Bug 修复也集中塞进 RC5 阶段， 不仅增加代码变动量，也会抬高审查和合并成本，给维护者带来额外负担。 按照 Linux 内核常见节奏，一个开发周期通常包含 7 个发布候选版本，必要时会增加到 8 个，随后才进入正式发布。也正因如此，RC5 往往被视为应当逐步“降噪”的阶段，整体节奏理应放缓。 为了让开发节奏回到正轨，Torvalds 要求开发者重新审视自己的 Pull Request（合并请求）。提交前先判断，这到底是不是回归修复；如果不是，是否更适合放到下一个开发周期。 至于本周实际合入的修复，范围仍然很广，涉及文件系统、显卡、内存管理、网络、安全、稳定性和硬件兼容。硬件部分包括 HP Pavilion Plus 14、ASUS Armoury 和 Lenovo Yoga 7 14AGP11 的 Bug 修复。
节奏刚刚好，A 号蹬完换 B 号，B 号蹬完，A 号的 5h 冷却就刷新了 11 个帖子 - 6 位参与者 阅读完整话题