**Pushup RPG** 是一款免费且注重隐私的健身应用程序，适用于 iOS 和 Android。它利用设备端的摄像头姿态识别技术来自动计数。所有视频或图像数据均不会被记录或上传，确保了用户的隐私安全。 该应用通过将俯卧撑和深蹲转化为角色扮演（RPG）冒险来增加锻炼的趣味性。你可以通过运动赚取经验值、金币和战利品，以击败八个不同生态区域中的 48 种独特敌人。应用还提供 40 秒的实时对决，让你能与好友或匹配的对手一较高下。 除了俯卧撑和深蹲外，该应用还支持仰卧起坐和平板支撑，助你保持每日锻炼打卡。虽然平板支撑和仰卧起坐主要作为个人训练工具，但俯卧撑和深蹲是驱动核心 RPG 机制、排行榜及进度升级的主要方式。 Pushup RPG 无需穿戴式传感器或其他额外设备，仅需一部手机和地面即可实现精准的动作追踪锻炼。你可以以游客身份使用，也可以登录账户在多台设备间同步进度。通过将游戏化体验与安全、实时的计数技术相结合，Pushup RPG 将基础的自重训练转变为一种既有成就感又充满竞争力的健身体验。
每日HackerNews RSS
抱歉。
鉴于人工智能的飞速发展，研究人员和开发人员应如何调整时间分配？我们又该培养哪些新技能，以防未来被时代淘汰？我认为，基于“人工智能作为常规技术”这一论点，我们仍有大量工作要做。该论点认为，在人工智能能力提升与任务或工作的自动化之间，仍存在诸多瓶颈。证据表明，将人工智能视为辅助性技术而非自动化技术更为恰当。人类精力的投入重心将转向那些难以验证的任务——即从开发模型转向构建框架，从单纯的建设转向评估与监控。从长远来看，随着纯技术技能的贬值，研究人员和开发人员都必须做出调整。在研究领域，人类的精力将从解决问题转向提出问题和寻求概念上的突破；在工业界，人际交往能力、领域知识以及审美和规范性的判断力将变得愈发重要。
抱歉。
AI 编程代理的飞速发展正在引发软件开发领域的根本性变革。从历史上看，开发流程一直是一个循序渐进、以实现为重的循环（构思 → 设计 → 工程 → 质量保证）。然而，随着 AI 使得代码生成变得高效且廉价，实现阶段已不再是主要的瓶颈。
开发模式正演变为一种更具经验性、更精简的循环：**意图 → 实现 → 观察结果**。
在这种新范式下，代码库不再是功能成功与否的最终判定标准。仅凭代码无法捕捉运行时的现实情况，例如 UI 故障、用户流程错误或性能退化。因此，产品、设计和工程等岗位正融合为一种统一的职能，关注重点从单纯的语法转向了最终成果。
未来开发的核心在于**行为证据**。像 Revyl 这样的平台正致力于连接现有工具（如 Figma 和 Cursor），以确保每一次代码变更都配有可验证的运行时记录。随着标准的演进，拉取请求（Pull Request）将很快要求默认提供行为证据，而运行时信号也将成为开发中不可或缺的背景信息。产品开发并未消失，它正在被重写，以实现结果为先，而非仅仅堆砌代码。
这篇 Hacker News 讨论批判了在人工智能驱动产品开发的时代，“代码库不再重要”这一观点。
尽管 AI 智能体的支持者认为开发重心正转向高层级的产品能力而非手动编码，但持怀疑态度的人对此强烈反驳。许多评论者指出，一个架构良好的代码库对于长期扩展性、可验证性和组织学习而言依然至关重要。人们担心，忽视代码的重要性会导致产生难以维护且成本高昂的低质量软件（即“代码垃圾”）。
此外，参与者对将转向大模型（LLMs）与历史上从马车到引擎、从汇编语言到高级语言的转变进行类比的做法提出了质疑，指出这些转变在本质上完全不同。归根结底，经验丰富的开发者们达成共识：虽然编写代码的“过程”正在发生变化，但人类的监督、严谨的架构以及对系统行为的把控，对于构建可靠、专业的软件依然至关重要。
.png)
在 2026 年的 Hot Chips 大会上，IBM 发布了一款专为其 IBM Z 和 LinuxONE 大型机设计的突破性双架构处理器。这款 2 纳米芯片由 IBM 与 Arm 合作开发，使企业能够同时运行 Arm 原生 Linux 环境与 IBM 的专有系统。
通过将 Arm 庞大的软件生态系统（支持云原生和人工智能应用）与 IBM 闻名遐迩的企业级安全性、可靠性及事务处理能力相结合，这款新处理器为各机构提供了前所未有的基础设施灵活性。该芯片配备了 11 个高性能核心，能够同时执行 IBM Z 和 Arm 指令，并辅以 AI 推理加速器和专用 I/O 加速功能。
这一创新代表了关键任务计算领域的一次重大变革，使企业能够在不牺牲 IBM 大型机安全与性能优势的前提下，实现应用组合的现代化并扩展人工智能部署。通过融合这两种架构的优势，IBM 旨在为现代数字基础设施提供一个更加通用且稳健的基石。
抱歉。
自2026年9月11日起，欧盟《网络韧性法案》（CRA）要求软件制造商在发现被主动利用的漏洞后24小时内向监管机构报告。企业如何接收这些初步报告是一个关键但常被忽视的挑战。 近期对492家欧洲软件供应商的扫描显示，76%的企业未能发布 `security.txt` 文件（RFC 9116）。该标准文件为安全研究人员披露漏洞提供了重要的私密渠道。若缺乏此渠道，研究人员更有可能选择公开漏洞或向第三方报告，这可能会在企业察觉事件之前，便意外触发CRA法案规定的24小时合规时限。 由于CRA第14条适用于所有产品（无论其上市时间早晚），这种缺乏可访问联系方式的情况构成了重大的合规与安全风险。为缓解此风险，建议供应商立即实施 `security.txt`，以确保具备必要的可见性，从而在严格的规定时限内响应漏洞披露。
最新报告显示，绝大多数欧盟软件供应商尚未为即将实施的《网络韧性法案》（CRA）中有关漏洞披露的要求做好准备。数据显示，在所分析的公司中，有 76% 到 90% 的企业未能发布有效的 `security.txt` 文件，而这正是报告安全漏洞的标准机制。
Hacker News 上的讨论凸显了业界对 CRA 适用范围的困惑，尤其是纯 SaaS 平台是否属于其监管范围。虽然一些参与者对这些文件所产生报告的数量和质量表示怀疑，但另一些人则强调了其必要性，指出缺乏明确的披露渠道会迫使安全研究人员转向通用的支持渠道，而这一过程往往效率低下且容易出错。
为简化合规流程，一些开发者指出，Cloudflare 等平台提供了一键式部署 `security.txt` 的解决方案，使组织能够在新法规生效前更轻松地建立专业的漏洞报告渠道。
为了优化网站以适配 AI 智能体，请实施内容协商机制，在提供标准 HTML 的同时，额外提供一份简洁的 Markdown 版本。通过使用 `Accept: text/markdown` 请求头，服务器可以输出剔除了导航栏、脚本和布局包装器的精简内容。 这种方法具有三个关键优势： 1. **Token 效率：** 减少不必要的 DOM 元素，确保 AI 模型能将上下文窗口集中在核心内容上。 2. **提升检索质量：** 消除广告和弹窗等噪音，使 RAG（检索增强生成）流水线能更精准地索引你的数据。 3. **降低延迟：** 更小的数据载荷能加快获取和解析速度，从而实现更快的模型处理。 此做法遵循标准网络协议（RFC 9110/7763），并兼容主流框架和平台。通过提供轻量级的 Markdown 变体，可以提升内容的“AI 就绪度”，确保智能体能够高效获取你的信息，而无需处理冗余的开销。
抱歉。
arXivLabs 是一个允许合作者直接在我们的网站上开发并分享 arXiv 新功能的框架。与 arXivLabs 合作的个人和组织都认同并接受我们关于开放、社区、卓越和用户数据隐私的价值观。arXiv 始终致力于这些价值观，并仅与遵循这些价值观的合作伙伴进行合作。如果您有能为 arXiv 社区增值的项目想法，欢迎了解更多关于 arXivLabs 的信息。
抱歉。
拒绝访问。你没有权限访问此服务器上的“http://www.gatesnotes.com/work/make-ai-work-for-everyone/reader/the-risks-of-ai-are-real-but-manageable”。参考编号 #18.d6de9b7c.1787776375.5ed7776 https://errors.edgesuite.net/18.d6de9b7c.1787776375.5ed7776
抱歉。
我创建这个网站的初衷，是希望能根据我所构建产品所依赖的服务及受影响的严重程度，来筛选 GitHub 的故障历史。每个人的可靠性叙述，都取决于他们所依赖的服务以及预期的“几个 9”。请使用上方的筛选器来设定属于你的需求。你的筛选条件可能与他人不同，现在你可以明确自己的标准，避免各说各话了。自 2016 年 3 月以来，GitHub 已发生 1125 起故障，平均每月发生 24 起（较过去三个月下降 5%）。在此期间，其最长的无故障间隔为 8 天，结束于 2025 年 12 月 31 日；情况最糟糕的月份是 2026 年 2 月，共发生了 37 起故障。
Hacker News 上关于“isgithubcooked.com”的讨论，反映了人们对 GitHub 可靠性下降的广泛不满。用户愈发诟病该平台频繁出现的宕机问题，认为在海量流量高峰（尤其是由 AI 生成的代码和自动化流程引起的）面前，GitHub 的服务已变得“脆弱不堪”。
争议的核心在于 GitHub 是否应该优先考虑付费企业客户，而非免费用户。虽然有人认为 GitHub 是自身成功的受害者，在应对极端压力时应当给予理解，但主流情绪依然是烦躁与不满。许多人认为，GitHub 的不稳定是其为了追求 AI 驱动的增长而忽视服务稳定性所带来的后果。
批评者指出，尽管微软资源雄厚，却未能妥善解决技术债务，也未实施合理的限流措施来保护核心服务。对许多专业人士而言，系统停机已成为一项关键的业务风险，导致一些人开始质疑是否应继续依赖该平台。归根结底，这篇讨论串捕捉到了一种日益增长的情绪：GitHub 似乎迷失了方向，难以在其作为大型公共基础设施的角色与企业级专业工作流所需的可靠性之间取得平衡。
请提供您需要翻译的内容。
抱歉。