2026-03-12 Hacker News Top Stories #
- 作者认为所谓“奇点”被夸大,AI 只是搜索与优化的技术演进,真正受冲击的是依靠复杂性和租金的岗位,建议专注为他人创造真实价值而非恐慌。
- 一名前 DOGE 员工被指离职时将社会保障局敏感数据带到新雇主,可能影响超过7000万美国公民,监察长已展开调查,细节仍在核实。
- Cloudflare 发布 /crawl API,可通过单次调用用无头浏览器发现并抓取网站并异步返回 HTML、Markdown 和结构化 JSON,支持深度与增量控制,适用于训练与内容监控。
- Bloomberg 回顾了历时九年的 Temporal 提案,指出其通过不可变类型、原生时区与日历支持等修复了 JavaScript 中 Date 的长期缺陷并成为标准。
- 作者构建了能在“睡觉时”运行的 AI 编程代理并结合 TDD 与浏览器/curl 验证以发现集成问题,但发现无法修正错误需求,工具已开源。
- Zig 对类型解析系统进行了重构以实现更懒惰的字段分析、改进依赖循环提示并显著提升增量编译性能,同时引入多种实验性异步 I/O 后端。
- 研究通过查证 1949–1952 年 H. Berthold 字体样本,支持 Unicode 符号 ⍼ 被命名为 “Azimuth” (方位角)的历史起源。
- 研究团队演示用自主进攻性 AI 代理利用麦肯锡内部 AI 助手的未保护 API 实施 SQL 注入并获取生产数据库权限,暴露大量敏感数据并凸显提示词的安全风险。
- 文章主张应把注意力放在将 WebAssembly 与 Web 平台深度整合(简化加载、直接访问 DOM/浏览器 API 等),以使其成为 Web 的一等语言。
- 斯坦福研发的鼻腔给药通用疫苗在小鼠中对多种冠状病毒、细菌和尘螨过敏原显示广谱保护,若能在人类转化或减少对年度变异疫苗的依赖,但需谨慎评估安全性与长期影响。
奇点更近了 (Create value for others and don’t worry about the returns) #
https://geohot.github.io//blog/jekyll/update/2026/03/11/running-69-agents.html
文章标题为“the singularity is nearer”,作者 geohot 在 2026 年 3 月 11 日发布了一篇反思当前 AI 热潮的博客。
作者首先以调侃语气指出,所谓“每分钟不运行 69 个 AI 代理就会落后”的说法纯属玩笑,提醒读者不要被社交媒体制造的焦虑所裹挟。社交媒体不断渲染“不用 AI 就会被淘汰”“你每小时只值 0.003 美元”等恐慌情绪,制造出一种非黑即白的生存压力。
作者认为,AI 并非什么颠覆性的“奇点”或魔法,而只是技术演进的自然延续。它在某些领域有进步,也有局限,本质上仍是搜索与优化的组合,而非科幻中的自我迭代。他提醒读者,若曾上过计算机科学课程,就应清楚这些技术的边界。
真正的危机并非 AI 本身,而是“租金攫取”(rent seeking)模式的瓦解。那些靠制造复杂性、为他人增加负担来谋利的工作,终将被效率更高的系统淘汰。大公司借“AI”之名进行裁员,实则是为了集中资源,巩固自身优势,而非技术革命。
作者给出核心建议:不要参与零和游戏。与其追逐虚幻的比较和焦虑,不如专注于为他人创造真实价值。只要创造的价值超过自身消耗,就足以在健康的社会中立足。真正的出路不在于跟风,而在于摆脱“红皇后竞赛”式的内卷。
最后,作者坦言,这篇理性声音可能不如煽动焦虑的内容传播广泛,但它才是真正能指引方向的出路。
HN 热度 646 points | 评论 429 comments | 作者:ppew | 18 hours ago #
https://news.ycombinator.com/item?id=47332074
- 创造真实价值比担心被 AI 取代更重要,真正有价值的工作不会被轻易替代。
- AI 虽能完成部分写作和营销任务,但缺乏真正价值的内容仍无法取代人类创作者。
- 软件工程师是否被替代取决于公司对价值的定义,而非个人能力本身。
- 公司更关注成本与收益比,即使 AI 无法完全替代人类,也可能因成本优势而裁员。
- 高端岗位同样面临被 AI 替代的风险,因为企业愿意用更低薪资雇佣“足够好”的人。
- 软件行业利润高,若薪资下降,创业门槛降低,可能催生更多新公司。
- 创业并非解决就业问题的可行路径,因市场竞争激烈,多数初创难以成功。
- 企业决策往往基于短期财务指标,而非长期价值或员工贡献。
- 员工价值由公司评估,且标准随时变化,难以稳定保障。
- 企业追求员工可替代性,避免依赖单一人才,这与“不可替代”相悖。
- 即使 AI 无法完全替代资深工程师,企业仍因盲目相信 AI 能力而大规模裁员。
- 在游戏等行业,裁员早于 AI 出现,AI 只是加剧了这一趋势。
- 企业对价值的判断常基于错误假设,误以为 AI 能实现所有价值。
前 DOGE 成员被指离职时带走社保数据至新岗位,引发安全疑虑 (Whistleblower claims ex-DOGE member says he took Social Security data to new job) #
https://www.washingtonpost.com/politics/2026/03/10/social-security-data-breach-doge-2/
一名前美国 DOGE 服务员工被指控在离职时将社会保障局的敏感数据带至新工作单位,引发重大安全疑虑。据知情人士透露,美国社会保障局内部监察长办公室已就此展开调查。该员工被指曾接触两个高度敏感的数据库,并计划将信息分享给其私人雇主,若属实,这将是该机构历史上罕见的重大安全违规事件。
该事件涉及超过 7000 万美国公民的个人信息,影响范围广泛。目前调查仍在进行中,尚未公布具体细节或结论。事件也引发公众对政府机构数据安全和人员流动管理的广泛关注。
报道指出,该员工曾在 DOGE 服务项目中担任工程师,该项目是政府推动的效率改革计划之一。其行为若被证实,可能对公众信任和政府数据保护机制造成严重冲击。
HN 热度 560 points | 评论 249 comments | 作者:raldi | 10 hours ago #
https://news.ycombinator.com/item?id=47335572
- DOGE 团队在白宫未通知相关部门的情况下安装星链终端,使用无用户名和双因素认证的“Starlink Guest”Wi-Fi,导致设备可绕过监控,存在数据泄露和被黑客攻击的风险。
- 该行为明显是为了规避监管,允许设备在不受监控的情况下传输数据,可能正是其设计目的。
- 尽管情报机构可能有能力监控星链网络,但其是否实际执行或能否突破加密仍存疑。
- 美国情报机构被明确禁止随意监控本国公民,因此不能简单假设他们拥有无限制的监控能力。
- 历史上政府长期存在对公民通信的监控行为,如“Room 641A”项目和罗斯福时期对电报的审查,说明集中化系统必然带来监控风险。
- DOGE 成员在法庭视频中对 DEI 的模糊回应暴露了其刻意回避责任的策略,表面无知实则有意推诿。
- 该成员声称 DEI 定义“完全来自总统行政令”,但又表示记不清具体内容,明显在撒谎或故意混淆视听。
- 有观点指出,该成员将关于二战期间犹太女性受害者的纪录片称为“本质上具有歧视性”,说明其真实立场并非无知,而是有意为之。
- 整个听证过程呈现出一种“理想证人”模式:表现得像遭受严重脑损伤,看似愚蠢、健忘、迟钝,但能有效规避法律责任。
- 在高信任社会中,缺乏道德底线的人会利用制度漏洞为所欲为,而制度却难以有效制衡。
- 面对这种破坏社会契约的行为,应采取极端反制措施,以彻底瓦解其行为基础,避免最终全面崩溃。
- 当前政府在华盛顿的欺诈与危害远超所谓“种族主义”的虚假争议,真正的重点被刻意转移。
- 将 DEI 污名化为“种族主义”是无知或恶意的体现,DEI 涵盖所有边缘化群体,不应被狭隘解读。
- 面部识别算法对有色人种的识别偏差问题,正说明缺乏多样性团队开发技术的严重后果。
- 历史研究中关注少数群体的视角并非“歧视”,而是对被长期忽视的真相的还原。
Cloudflare 推出全新 /crawl API 端点,支持通过单次调用完整抓取网站内容 (Cloudflare crawl endpoint) #
https://developers.cloudflare.com/changelog/post/2026-03-10-br-crawl-endpoint/
Cloudflare 推出浏览器渲染服务的全新 /crawl API 端点,支持通过单次 API 调用完整抓取网站内容。该功能目前处于公开测试阶段,可自动发现页面链接,使用无头浏览器渲染页面,并以 HTML、Markdown 和结构化 JSON 格式返回结果。
该功能为签名代理,自动遵循 robots.txt 和 AI 爬取控制规则,确保爬取行为符合网站所有者的指引,降低对目标站点造成干扰的风险,适用于模型训练、RAG 管道构建及内容监控等场景。
爬取任务异步执行,用户提交起始 URL 后获取任务 ID,后续通过任务 ID 查询结果。支持多种配置选项,包括控制爬取深度、页面数量限制、路径通配符规则,以及基于时间的增量爬取(通过 modifiedSince 和 maxAge 参数),有效节省重复爬取的时间与成本。
对于静态网站,可启用静态模式(render: false),直接获取 HTML 内容,无需启动浏览器,提升抓取效率。
该功能适用于 Workers 免费版和付费版计划。需要注意的是,该接口无法绕过 Cloudflare 的机器人检测或验证码,且会主动标识自身为机器人。
开发者可通过官方文档快速上手,并建议网站所有者遵循 robots.txt 和站点地图的最佳实践,以优化爬取体验。
HN 热度 470 points | 评论 179 comments | 作者:jeffpalmer | 1 day ago #
https://news.ycombinator.com/item?id=47329557
- Cloudflare 若提供预抓取的网站内容,可减少对第三方爬虫服务的依赖,但需权衡缓存空间和性能成本。
- 预缓存内容会显著增加缓存占用,可能降低整体缓存效率,而按需转换可避免无效缓存。
- 采用“二次请求缓存”策略能有效提升缓存命中率,避免仅被访问一次的内容占用缓存资源。
- 通过延迟响应机制,可灵活控制数据提供时间,实现对请求的调度与管理,无需实时存储所有数据。
- Cloudflare 已支持基于内容协商的实时内容转换,如将 HTML 自动转为 Markdown,具备类似功能的技术基础。
- CDN 本身具备检测内容变化的能力,可通过缓存头(如 Etag)判断内容是否更新,无需频繁回源。
- 提供预抓取内容可能引发版权和隐私问题,容易被滥用为 AI 爬虫的便利通道,带来法律风险。
- 一旦开放此类功能,可能使网站内容被批量抓取并转售,违背原网站的隐私和版权初衷。
- 该功能若需引入访问控制,将变成复杂的定制化 API,违背 CDN 服务的初衷且增加法律负担。
历时九年的 Temporal:修复 JavaScript 中的时间处理 (Temporal: A nine-year journey to fix time in JavaScript) #
https://bloomberg.github.io/js-blog/post/temporal/
本文由 Bloomberg 资深软件工程师 Jason Williams 撰写,回顾了 JavaScript 中时间处理机制的演进历程,重点介绍了 Temporal 提案的 9 年发展历程。
JavaScript 最初在 1995 年由 Brendan Eich 在 10 天内完成,其 Date 对象直接移植自 Java,设计上带有“Make It Look Like Java”(MILLJ)的倾向。这种历史选择导致 Date API 存在诸多缺陷:可变性引发意外修改、月份计算不一致、解析行为模糊等,长期困扰开发者。
随着 JavaScript 在金融、全球协作等复杂场景中的广泛应用,Date 的局限性日益凸显。开发者不得不依赖 Moment.js 等第三方库来弥补缺陷,但这些库带来了包体积过大、无法有效 Tree-shaking 等问题,维护成本高昂。
2017 年,Maggie Johnson-Pint 等人在 TC39 提出 Temporal 提案,旨在从根本上重构 JavaScript 的时间处理机制。该提案目标包括:提供不可变的日期时间类型、原生支持时区与日历系统、解决现有 API 的语义混乱问题。
Bloomberg 作为早期支持者,因在终端系统中处理全球时间数据的复杂需求,深刻体会到 Date 的不足。公司工程师积极参与 Temporal 的标准化工作,推动其从 Stage 1 逐步推进至 Stage 4,最终成为 ECMAScript 标准的一部分。
Temporal 的诞生标志着 JavaScript 终于拥有了一个现代、安全、可预测的时间处理系统,解决了困扰开发者近三十年的痛点。
HN 热度 469 points | 评论 161 comments | 作者:robpalmer | 9 hours ago #
https://news.ycombinator.com/item?id=47336989
- Temporal 通过强制区分时间点和日历时间,有效避免了 JavaScript 中 Date 对象容易引发的时区和夏令时相关错误,虽然代码略显冗长,但值得。
- 与 Python 中长达十年的 ISO8601 日期解析问题类似,JavaScript 也经历了长期的日期处理困境,Temporal 的出现是重大进步。
- 从 isoformat 解析日期的便捷性相比旧方法是质的飞跃,使日期处理变得简单可靠。
- Temporal 的实现得益于志愿者 André Bargull 的独立贡献,体现了社区力量的重要性。
- Temporal 的对象包含方法,导致其无法直接通过 JSON 序列化/反序列化,与前后端共享纯数据(JSON)的架构理念存在冲突。
- Temporal 团队有意不实现自动反序列化,以避免接收意外数据时类型错误,开发者需手动重建对象,这是为了安全性和明确性。
- 通过在数据传输层(如 tRPC)添加转换逻辑,可解决 Temporal 对象的序列化问题,且代价较小。
- 尽管 Temporal 的设计牺牲了部分序列化便利性,但其类型安全优势显著,能防止因遗漏时区或日历系统导致的隐性错误。
- 与 date-fns 等纯函数式库相比,Temporal 的面向对象设计虽然不便于跨边界传输,但提供了更强的类型保障。
- 为解决常见类型(如日期、大数、十进制)的序列化问题,可考虑扩展 JSON 格式或使用 YAML 等支持标签的格式。
- JSON 本身不支持自动还原复杂对象,无论是 Date 还是 Temporal,都需要手动处理反序列化,这是通用限制。
- 从类型安全角度看,Temporal 的设计优于纯数据 + 函数的分离模式,尽管牺牲了部分便利性。
睡眠时运行的 AI 代理 (Agents that run while I sleep) #
https://www.claudecodecamp.com/p/i-m-building-agents-that-run-while-i-sleep
作者正在构建能在睡眠期间自动编写代码的 AI 代理,但逐渐意识到无法有效验证这些代码是否真正符合需求。尽管使用 AI 生成代码和测试,但测试往往只是验证 AI 自己的理解,而非真实需求,形成“自我恭维”的循环。
作者指出,传统代码审查在 AI 高度参与后变得不可行,因为审查者无法逐行检查大量自动生成的代码。他提出,真正的解决方案是回归 TDD(测试驱动开发)的核心思想:先明确“正确”是什么,再编写代码。通过在编写代码前定义清晰的验收标准,可以有效验证功能是否按预期运行。
在实践中,作者团队为前端功能生成具体的验收标准,例如登录成功后的跳转、错误提示、表单验证等。AI 根据这些标准实现功能后,由 Playwright 浏览器代理自动执行测试,通过截图和行为验证每个标准是否通过。后端则通过 curl 命令验证 API 响应是否符合预期。
整个流程分为四个阶段:预检(bash 脚本快速验证环境)、规划(使用 Opus 模型分析需求和代码)、浏览器代理执行(并行运行 Sonnet 模型进行交互测试)、最终判断(Opus 模型综合证据给出每个标准的通过或失败结论)。
作者强调,这种模式无法解决需求本身错误的问题,但能有效发现集成错误、渲染问题和实际运行时的异常。关键在于:必须在 AI 开始工作前就定义好“完成”的标准。虽然这比直接写提示更耗时,但能显著提升交付质量。
该工具已开源为 Claude Code 插件,可直接安装使用,无需额外后端或密钥,支持灵活替换模型或集成到 CI 流程中。
HN 热度 406 points | 评论 478 comments | 作者:aray07 | 1 day ago #
https://news.ycombinator.com/item?id=47327559
- 使用 AI 代理自动编程虽然看似能简化开发,但实际投入大量人力和资金构建复杂框架,反而增加了开发成本和复杂性。
- 过度依赖 AI 自动运行而缺乏人工监督,可能导致生成代码质量低下,未来可能被视作类似“用 PHP 开发”的荒谬行为。
- AI 应作为增强人类能力的工具,而非完全替代人类决策,盲目让 AI“熬夜工作”只会产生更多错误,增加后续审查负担。
- 提升 AI 生成质量的关键在于提供高质量的上下文,如架构文档、系统提示和技能文件,使 AI 能基于已有决策持续优化。
- 缺乏清晰需求和规范的项目,即使 AI 并行运行也无法产出有价值的结果,真正瓶颈在于前期规划和需求定义。
- 一些团队可能利用 AI 快速堆积功能,但最终导致代码库混乱、难以维护,一旦 AI 服务停止,将面临技术债务危机。
- 人类程序员在代码量上存在自然上限,而 AI 可以轻易生成数万行冗余代码,可能催生过度设计和低质量实现。
- AI 生成的代码缺乏真实场景理解,若需求未被充分训练数据覆盖,生成结果可能完全偏离实际需求。
- 人类在理解复杂系统和应对突发问题方面仍不可替代,而 AI 缺乏情感和判断力,无法应对真实开发中的不确定性。
- 随着 AI 模型效率提升,未来在家用设备上即可运行高性能模型,这将改变开发者角色,但核心能力仍需人类主导。
- 当前 AI 模型虽在进步,但整体水平仍处于“尚可但未达优秀”阶段,距离真正可靠自动化仍有较大差距。
- 企业若盲目投入 AI 开发,可能面临投入产出比下降、系统维护成本飙升和产品方向混乱等风险。
- AI 生成代码的长期维护成本可能远高于人工开发,尤其在缺乏文档和架构设计的情况下。
- 未来 AI 技术积累将催生二手服务器设备市场,硬件资源将被重新利用,形成新的产业生态。
Zig – 类型解析系统重构与语言改进 (Zig – Type Resolution Redesign and Language Changes) #
https://ziglang.org/devlog/2026/#2026-03-10
2026 年 3 月 10 日:类型解析系统重构,带来多项重要改进
Zig 编译器进行了大规模的内部重构,核心是重新设计类型解析逻辑。此次更新由 Matthew Lugg 主导,历时约两个月,合并了一个超过 3 万行代码的 PR。这次重构不仅让编译器内部结构更清晰,还带来了多项用户可见的改进。
首先,编译器现在更加“懒惰”地分析类型字段。当类型仅作为命名空间使用时,编译器不会去检查其内部字段,从而避免不必要的编译开销。例如,之前使用 @compileError 的字段会导致编译失败,但现在只要该类型未被实例化,代码就能顺利通过。
其次,依赖循环错误的提示信息得到极大改善。过去这类错误信息模糊不清,现在能精准指出循环路径,包括具体哪一行代码导致了依赖关系,帮助开发者快速定位问题。
此外,增量编译性能显著提升。此前存在大量“过度分析”问题,导致编译效率低下,现在这类问题基本被消除,使得增量编译更快、更高效,极大提升了开发体验。
该 PR 还包含数十个 bug 修复、少量语言微调及整体编译性能优化,整体影响深远。
2026 年 2 月 13 日:io_uring 与 Grand Central Dispatch 的 std.Io 实现正式落地
随着 Zig 0.16.0 版本发布周期临近,Andrew Kelley 与 Jacob 共同完成了 std.Io.Evented 模块的两个新后端实现:io_uring 和 Grand Central Dispatch(GCD)。
这两个实现基于用户态栈切换技术(即“纤程”或“绿色线程”),允许在不依赖系统线程的情况下实现高效的异步 I/O。开发者可通过 std.Io.Evented 构建应用,实现 I/O 模式的无缝切换。
示例代码展示了如何在 Threaded 和 Evented 两种模式间切换,仅需更改初始化部分,而业务逻辑保持不变。通过 strace 可以观察到两种模式的系统调用差异:Threaded 使用线程,而 Evented 使用 io_uring 系统调用,表现出更轻量级的特性。
尽管功能已可用,但两个实现仍处于实验阶段,存在以下待完善问题:
- 错误处理机制不完善
- 日志输出仍存在
- 在某些场景下性能下降
- 部分函数未实现
- 测试覆盖不足
- 缺乏用于查询函数最大栈大小的内置函数,影响在“栈过载”禁用环境下的使用
尽管如此,这一进展标志着 Zig 正迈向“I/O 实现可自由切换”的理想状态,为高性能、低资源消耗的系统编程提供了强大支持。
HN 热度 388 points | 评论 219 comments | 作者:Retro_Dev | 23 hours ago #
https://news.ycombinator.com/item?id=47330836
- Zig 语言的类型解析重构虽然带来了一些破坏性变更,但实际影响非常有限,大多数用户几乎不会遇到问题,即便遇到也只需进行微小修改即可解决。
- 作者澄清了外界对此次变更破坏性过大的误解,强调这些变更主要是为了修复 bug 和提升增量编译性能,而非大规模重构。
- 有评论者承认自己最初的批评存在误解,但强调其本意并非否定开发者的努力,而是希望更充分地讨论语言变更的影响。
- Zig 的“开放世界”模型允许通过类型结构的匹配自动支持方法调用,这带来了强大的元编程能力,但也导致了类型信息不明确的问题。
- 与 Rust 的“封闭世界”模型相比,Zig 的动态类型匹配机制使得文档、自动补全和 LSP 支持等工具面临挑战。
- Zig 的
anytype特性允许在编译时接受任意类型,类似于 C++ 模板的鸭子类型,虽然强大但可能导致编译错误难以理解。 MultiArrayList(T)结构中避免依赖@alignOf(T)以防止类型依赖循环,是通过将指针类型改为[*]u8并手动进行对齐转换来实现的。
符号 ⍼(U+237C)的命名由来:方位角的起源与历史证据 (U+237C ⍼ Is Azimuth) #
https://ionathan.ch/2026/02/16/angzarr.html
本文探讨了符号 ⍼(U+237C)的起源与命名由来。该符号在 Unicode 中被标记为“Azimuth”,意为“方位角”。一年前,维基百科用户 Moyogo 更新了“Angzarr”词条,引用了 1950 年德国字体公司 H. Berthold AG 出版的《Zeichenprobe》(符号样本册)中的一条记录,确认该符号在当时被命名为“Azimut, Richtungswinkel”,即“方位角”或“方向角”。
文章指出,该符号出现在 1950 年的《Zeichenprobe》第 7 页,以及 1949、1951 和 1952 年的《Schriftprobe》(字体样本册)第 104 页,但未在 1946 年及更早的 1909 年、1900 年版本中出现。作者提供了这些样本册的扫描页作为证据,并特别标注了符号存在的页面与缺失的页面。
此外,文章提到一位推特(Mastodon)网友的观察:符号 ⍼ 的形状与通过六分仪测量方位角时光线的路径相似,尤其是其直角部分,象征角度的通用符号。文中还引用了维基百科关于六分仪工作原理的插图和实际使用照片,说明其在航海导航中测量水平角的应用。
整体而言,本文通过历史文献与视觉类比,揭示了 ⍼ 符号在技术与历史语境中的真实含义,为 Unicode 中这一符号的命名提供了可靠依据。
HN 热度 387 points | 评论 75 comments | 作者:cokernel_hacker | 1 day ago #
https://news.ycombinator.com/item?id=47329605
- 该符号可能并非源自六分仪测量方位角,六分仪主要用于测量天体与地平线之间的垂直角度,水平使用测量方位角并不常见且效率低下。
- 该符号更可能是表示从正北方向测量的各种角度,符合“方位角”的常规定义,且避免了使用文字或指南针符号,适合小尺寸图形表达。
- 六分仪在航海中主要用于测量天体高度,而非水平方位角;水平角度测量通常使用方位环,六分仪并非理想工具。
- 有观点指出“Azimut”与“Richtungswinkel”在现代德语中是两个不同概念,且维基百科条目中未相互关联,暗示该符号可能并非源于六分仪。
- 有用户指出“Haussystem Didot”中的符号可能用于地图导航说明,但未找到该符号在早期文献中的实际使用证据。
- 该符号的曲线形态可能象征角度从起点到终点的旋转过程,现代弯曲箭头比原始锯齿状更符合这一含义。
- 有用户提到六十四卦与 DNA 密码子数量相同,均为 64,可能暗示某种深层模式,但更可能是巧合。
- 64 卦的排列顺序在 Unicode 中遵循传统王文序列,而与邵雍的二进制排列不同,反映了两种不同的哲学起点。
- DNA 中的起始与终止密码子与六十四卦的结构对应,可能具有象征性相似,但尚无确凿证据支持其功能性关联。
- 有用户质疑某评论为 AI 生成,认为其语言风格过于流畅,缺乏人类写作的自然瑕疵。
- 作者回应称使用 AI 工具仅用于润色,但核心思想来自个人思考,强调表达清晰优先于语言风格。
我们如何攻破了麦肯锡的 AI 平台 (How we hacked McKinsey’s AI platform) #
https://codewall.ai/blog/how-we-hacked-mckinseys-ai-platform
本文披露了一次针对全球顶级咨询公司麦肯锡(McKinsey & Company)内部 AI 平台 Lilli 的渗透测试结果。Lilli 是麦肯锡为超过 4.3 万名员工打造的 AI 助手,支持聊天、文档分析、基于检索增强生成(RAG)的内部知识查询等功能,已覆盖超 70% 员工,每月处理超过 50 万次请求。
研究团队使用自主进攻型 AI 代理(无凭证、无内部信息、无人工干预)对 Lilli 发起攻击,仅用两小时便获得生产数据库的完整读写权限。攻击成功的关键在于一个未受保护的 API 端点,该端点将用户输入的 JSON 字段名直接拼接到 SQL 查询中,导致可被利用的 SQL 注入漏洞。传统安全工具如 OWASP ZAP 未能识别此问题,但 AI 代理通过 15 轮盲注,逐步获取数据库结构并最终获取敏感数据。
泄露内容极为严重:
- 4650 万条聊天记录,涵盖战略讨论、客户项目、财务数据、并购活动等;
- 72.8 万份文件,包括 PDF、Excel、PPT、Word 等,部分含敏感命名;
- 5.7 万员工账户信息;
- 38.4 万个人工智能助手与 9.4 万个工作区,揭示公司内部 AI 使用架构。
攻击还发现:
- 95 份系统提示词配置,暴露 AI 行为规则、安全限制及模型部署细节;
- 368 万条 RAG 文档片段,包含麦肯锡数十年积累的专有研究与方法论,存储路径公开;
- 110 万份外部 AI API 流转文件,涉及 OpenAI 向量库,暴露数据处理全流程;
- 存在跨用户数据访问漏洞,可读取他人搜索历史。
最危险的是,攻击者可直接修改存储在数据库中的系统提示词。这意味着:
- 可植入虚假建议,影响顾问决策;
- 可让 AI 在输出中嵌入机密信息,实现隐蔽数据外泄;
- 可移除安全限制,使 AI 无视权限控制;
- 修改无日志、无文件变更,攻击完全隐形。
文章强调,尽管麦肯锡拥有顶尖技术团队和安全投入,但该漏洞属于最基础的 SQL 注入,且已存在两年未被发现。AI 代理的出现改变了威胁格局——它们能自动探测、链式攻击、持续渗透,远超传统安全检测能力。
作者指出,AI 提示词(prompts)已成为新的“皇冠级资产”,但目前几乎没有任何组织对其实施访问控制、版本管理或完整性校验。这标志着 AI 安全的新战场正在形成。
事件披露时间线显示,研究团队于 2026 年 2 月 28 日发现漏洞,3 月 1 日启动负责任披露,麦肯锡于 3 月 2 日确认并修复所有公开端点,3 月 9 日公开披露。
本文由 AI 安全平台 CodeWall 发布,其正在招募早期合作伙伴,提供持续 AI 驱动的安全测试服务。
HN 热度 377 points | 评论 151 comments | 作者:mycroft_4221 | 14 hours ago #
https://news.ycombinator.com/item?id=47333627
- Lilli 项目在一年前仍为内部使用,需通过 VPN 和 SSO 访问,后来才对外公开,可能由高级合伙人推动,但项目缺乏持续维护。
- 麦肯锡的组织文化导致技术项目缺乏长期规划,开发人员因绩效考核机制只关注短期成果,项目完成后便无人接手,导致软件快速腐化。
- 麦肯锡内部存在“人人自扫门前雪”的现象,技术开发人员缺乏指导,项目多为领导层短期想法的产物,缺乏统一愿景。
- 麦肯锡曾大力引进技术人才,但 2023 年危机后大量技术人才被裁员,技术战略被放弃,如今更像一个以非技术背景人员主导的“伪科技咨询”公司。
- 技术人员在麦肯锡被视为二等公民,与业务顾问之间存在明显的“运动型”与“技术型”对立,影响团队协作与技术发展。
- 尽管薪酬在行业内具有竞争力,但与工作强度和文化环境相比,对多数人而言吸引力有限,尤其是顶尖人才。
- 高层合伙人享有高额利润分成,但其收入与工作强度不成正比,且团队中普遍存在缺乏独立思考的“顺从型”人才。
- 麦肯锡的咨询模式本质上是一种“过度承诺、交付不足”的行业常态,容易被人工智能颠覆,其核心价值正面临挑战。
- 项目安全漏洞频发,反映出组织对技术安全和权限控制的严重忽视,是文化问题的直接体现。
- 一些评论者调侃麦肯锡的咨询业务如同“自我循环的咨询”,甚至提出“让麦肯锡咨询自己”以摆脱其无效干预。
让 WebAssembly 成为 Web 平台的一等语言 (Making WebAssembly a first-class language on the Web) #
https://hacks.mozilla.org/2026/02/making-webassembly-a-first-class-language-on-the-web/
WebAssembly 虽然自 2017 年发布以来取得了显著进步,支持了 C/C++ 等语言,并逐步引入共享内存、SIMD、异常处理、垃圾回收等特性,但其在 Web 平台中仍被视为“第二类语言”。尽管语言能力已接近原生性能,但开发者体验依然不佳,限制了其广泛采用。
核心问题在于 WebAssembly 与 Web 平台的集成度不足。JavaScript 作为第一类语言,可直接访问 Web API,而 WebAssembly 必须通过 JavaScript 作为中介,导致使用门槛高。主要体现在两个方面:
一是代码加载复杂。JavaScript 可通过 <script> 标签直接加载,而 WebAssembly 目前无法在标签中使用,必须通过 WebAssembly.instantiateStreaming 等繁琐 API 手动加载,流程复杂且易出错。虽然 ESM 集成提案已支持 import 和 <script type="module"> 方式简化加载,但仅解决了表面问题。
二是调用 Web API 需要大量“绑定代码”(glue code)。WebAssembly 无法直接访问 DOM 或浏览器 API,必须通过 JavaScript 封装函数,如 console.log 需手动将 Wasm 内存中的字符串解码为 JS 字符串。这类代码重复、繁琐,通常需借助工具(如 wasm-bindgen)自动生成,增加了构建复杂度和运行时开销。
这种“桥接”机制带来了额外的性能损耗和开发负担,即使技术上可行,也使 WebAssembly 难以被普通开发者接受。尽管 WebAssembly 在性能上优势明显,但其使用成本过高,导致仅大型企业愿意投入资源,限制了其在更广泛 Web 生态中的价值。
作者认为,WebAssembly 语言本身已足够成熟,下一步应聚焦于与 Web 平台的深度整合,而 WebAssembly Components 等新方向可能提供更根本的解决方案。
HN 热度 360 points | 评论 137 comments | 作者:mikece | 19 hours ago #
https://news.ycombinator.com/item?id=47331811
- WebAssembly 的发展本可提前五年实现更理想的跨语言和 WebIDL 支持,但因转向组件模型和忽视 DOM 访问而错失良机,令人惋惜。
- 组件模型的初衷是支持非 Web API 和跨语言互操作,因此放弃了与 WebIDL 的兼容性,以换取更高的可移植性。
- WebIDL 与组件模型的设计理念存在冲突,后者更注重通用性和跨语言支持,而非 Web 生态的完整性。
- 有人希望字符串引用(stringref)功能回归,以减少 Wasm GC 语言在字符串处理上的二进制体积和 JS 互操作性能开销。
- 当前 WebAssembly 的工具链复杂且变化频繁,开发者面临显著的认知负担,工具链成熟度仍需提升。
- 组件模型虽有潜力,但其生成的代码和接口抽象可能使开发体验更加复杂,尤其在涉及 DOM 交互时。
- 有开发者担忧组件模型中资源引用采用借用检查机制,会削弱 Wasm GC 语言在引用管理上的优势。
- WebAssembly 组件模型的工具链虽尚处早期,但正快速演进,未来有望大幅改善开发体验。
- WebAssembly 的目标是无缝融入现有开发工具链,成为主流编译目标,目前在 Rust、C/C++、Go、Python 等语言中已有良好支持。
- 有人提出应将庞大的 Web API 拆分为更小、可订阅的标准化子集,以提升安全性并支持小型浏览器替代品的构建。
- 当前 Web API 的庞大规模是浏览器垄断的重要保护屏障,因此拆分和模块化难以被主流推动。
- WebAssembly 组件应具备依赖追踪能力,并避免强制依赖庞大的 DOM 等单体 API,以实现更灵活的集成。
针对呼吸道感染和过敏原的通用疫苗 (Universal vaccine against respiratory infections and allergens) #
https://med.stanford.edu/news/all-news/2026/02/universal-vaccine.html
斯坦福大学医学院的研究团队开发出一种新型鼻腔疫苗,可在小鼠体内提供对多种呼吸道病原体和过敏原的广泛保护,向“通用疫苗”的实现迈出了关键一步。该疫苗于 2026 年 2 月 19 日发表在《科学》杂志上,具有突破性意义。
与传统疫苗依赖特定抗原(如病毒刺突蛋白)来激发免疫反应不同,这种新疫苗不模拟病原体本身,而是模拟免疫细胞在感染时的通信信号。它通过激活先天免疫系统,并利用适应性免疫中的 T 细胞持续维持先天免疫的活跃状态,形成一种长期的免疫反馈回路。
研究发现,该疫苗能有效保护小鼠免受 SARS-CoV-2 及其他冠状病毒、金黄色葡萄球菌、鲍曼不动杆菌(医院常见感染菌)以及尘螨(常见过敏原)的侵害。在接种三剂疫苗后,小鼠的肺部几乎无病毒残留,体重损失显著减少,全部存活,而未接种组则出现严重症状甚至死亡。
该疫苗名为 GLA-3M-052-LS+OVA,包含一种可激活先天免疫的成分(模拟 T 细胞信号)和一种无害抗原(卵清蛋白),通过鼻腔滴注方式给药。其保护效果可持续至少三个月。
这一策略突破了传统疫苗“抗原特异性”的局限,为应对病毒变异和新发疫情提供了全新思路。若成功应用于人类,有望替代每年接种的流感和新冠疫苗,并在新型大流行病出现时提供快速保护。
HN 热度 352 points | 评论 127 comments | 作者:phony-account | 1 day ago #
https://news.ycombinator.com/item?id=47329608
- 免疫系统持续激活可能带来进化上的代价,如能量消耗或自身免疫疾病风险,因此自然选择未将其固定。
- 持续激活先天免疫系统可能引发自身免疫疾病,如类风湿性关节炎、系统性红斑狼疮、1 型糖尿病等。
- 进化并不追求完美,而是追求足够适应环境,因此现有免疫系统可能是“够用就好”的结果。
- 人类寿命在进化中并非关键因素,只要能存活至生育年龄即可,因此无需进化出更强大的免疫系统。
- 免疫系统过度活跃可能导致免疫系统与病原体之间的“军备竞赛”,使病原体更容易演化出逃避免疫的能力。
- 人类社会的资源分配机制(如更年期、社会分工)可能与资源竞争有关,老年个体的生存价值在进化中被权衡。
- 疫苗中的佐剂已实现免疫系统的非自然激活,说明人为增强免疫反应是可行的,但需权衡风险。
- 无需长期激活免疫系统,仅在流感季节或高风险时期短期增强可能更安全有效。
- 该研究仍处于动物实验阶段,需警惕“在小鼠身上有效”并不等于在人类身上有效。
- 现代文明带来的高密度聚居和人畜共处,使传染病传播加剧,人类尚未有足够时间进化出应对机制。
Hacker News 精彩评论及翻译 #
The MacBook Neo #
https://news.ycombinator.com/item?id=47332421
IMO the consumer PC industry is near an existential crisis. The big players are just awful at marketing; too many SKUs and models - it takes a paragraph to figure out how 2 Dell laptops from the same release year differ. The exact same specs will be in two different chassis designs.
Additionally, you can’t count on the basic being correct. It takes a hour of research to know if the trackpad is not-awful, keyboard doesn’t suck, and display isn’t a 300nits POS unusable even in a bright room.
You want the same performance as a MacBook Air without one of these fatal flaws? You’ll hand to spend $1500+ anyway so you save nothing. Then the OS is full of ads and pre-installed garbage “gaming-optimization-tool” or driver tools taking up 99% of a single core while being riddled with security holes.
KingMachiavelli
在我看来,消费级PC产业正面临一场生存危机。主要厂商的营销做得极差;产品型号和SKU过多——要搞清楚同年发布的两款戴尔笔记本有何不同,简直需要读一段文字。配置一模一样的电脑,却可能有两种完全不同的机身设计。
此外,你也不能指望最基础的东西是合格的。你得花上一个小时去研究,才能知道触控板是否勉强能用,键盘是否不烂,屏幕是否不是那种亮度仅300尼特、在明亮房间里完全没法用的垃圾产品。
如果你想要一台性能与MacBook Air相当、却没有上述那些致命缺陷的电脑?反正你还得花上1500多美元,根本省不下钱。而且,操作系统里满是广告和预装的垃圾软件,比如所谓的“游戏优化工具”或驱动工具,它们会占用单个核心99%的资源,并且系统本身还漏洞百出。
SSH Secret Menu #
https://news.ycombinator.com/item?id=47330350
Find the HIDDEN SECRETS that THEY DON’T WANT YOU TO KNOW!
$ man ssh
0xbadcafebee
发现他们不希望你知道的隐藏秘密! $ man ssh
Roblox is minting teen millionaires #
https://news.ycombinator.com/item?id=47329276
Roblox turns a blind eye to child exploitation (whether being creeped on by adults, or being exploited by teens/adults to make games) and makes a fortune out of it. If it weren’t online, it’d be illegal and people would be in jail.
Also, Roblox’s favourite thing - other than sitting back and rolling in the cash that their playerbase generated for them - is puff pieces in the news talking about how people who make games for them strike it rich!!!! They don’t mention that to do so, you first have to become popular amongst millions of competing titles, and the easiest way to do it is to pay them so they’ll advertise it for you.
Oh, and the company scrip - Robux - has very, very different exchange rates, depending on whether you want to buy Robux from the company, or you want to get a payout and convert your Robux to real money. They pay a lot less than it costs to buy Robux, further incentivising you to never actually make real money, because your Robux is “worth more” inside the Roblox walled garden. This is on top of the 75% cut they take!
In all, approximately 17% of the real-world money paid into Roblox is paid back out to creators. What a scam.
https://www.youtube.com/watch?v=_gXlauRB1EQ
https://www.youtube.com/watch?v=vTMF6xEiAaY
amiga386
Roblox对儿童剥削(无论是被成年人骚扰,还是被青少年/成年人利用来制作游戏)视而不见,并从中大发横财。如果这不是线上的行为,那就会是非法的,相关人员也会因此入狱。
此外,除了坐享其成、大赚其用户为他们赚到的钱之外,Roblox最喜欢的就是在新闻上发布一些吹捧的文章,吹嘘那些为他们制作游戏的人如何一夜暴富!!!他们从不提及,要做到这一点,你必须先在数百万个竞争作品中脱颖而出,而最简单的方法就是花钱让Roblox为你打广告。
哦,对了,公司自己的代币——Robux——其汇率有着天壤之别,这完全取决于你是想从公司那里购买Robux,还是想把你的Robux换成真钱。他们支付的价值远低于购买Robux的成本,这进一步激励你永远不要真正赚到钱,因为你的Robux在Roblox这个“围墙花园”内部“更值钱”。而这,还是在他们抽走75%分成之上的操作!
总而言之,支付给Roblox的真实世界资金中,大约只有17%会返还给创作者。这简直是个骗局。
Don’t post generated/AI-edited comments. HN is for… #
https://news.ycombinator.com/item?id=47341249
What a welcome post. The whole reason I come here is to get thoughtful input from smart people, and not what I could get myself from an LLM. While we are at it; Think your own thoughts as well :) I know how easy it is to “let it come up with a first draft” and not spend the real effort of thinking for yourself on questions, but you’ll find it’s a road to perdition if you let yourself slip into the habit. Thanks to all the humans still here!!
nkh
真是个不错的欢迎帖。我来这里就是为了获得聪明人的深思熟虑的见解,而不是我自己就能从大语言模型那里得到的东西。顺便说一下,也要有自己的思考 :) 我知道“让它先出个初稿”是多么容易,而不是在问题上真正努力地自己去思考,但你会发现,如果你让自己养成这种习惯,那将是一条通向毁灭的道路。感谢所有还留在这里的人类!!
Lego’s 0.002mm specification and its implications … #
https://news.ycombinator.com/item?id=47335679
Lego is one of those companies that is simultaneously amazing and kind of sucks. On one hand the core product is incredible. The tolerances on the bricks are micrometer-level precision and the fact that pieces from the 70s snap perfectly into ones made today is mind blowing.
On the other hand, a lot what the company does today just sucks. Set prices are outrageous. Printed bricks get replaced with stickers and many sets feel like display models than something you can play with. The Mindstorms/NXT line had huge potential but then just sort of fizzled out. And the push towards smartphone-dependent toys feels weird. Who actually wants their kids staring at a phone to play Lego?
It’s so sad, because the core product is basically perfect.
scatbot
乐高这家公司,既令人惊叹,又有点让人失望。一方面,其核心产品令人难以置信。积木的公差达到了微米级的精度,70年代的零件能与今天生产的完美拼接在一起,这一点简直令人震惊。
另一方面,公司如今的许多做法都令人失望。套装价格高得离谱。印刷砖被贴纸取代,很多套装感觉更像陈列品,而不是可以用来玩的玩具。Mindstorms/NXT系列本有巨大的潜力,但后来却后继乏力。而且,向依赖智能手机的玩具发展的趋势也感觉很怪。谁真的希望自己的孩子盯着手机来玩乐高呢?
这太令人惋惜了,因为其核心产品基本上是完美的。
Don’t post generated/AI-edited comments. HN is for… #
https://news.ycombinator.com/item?id=47340520
Good. This helps establish it in the HN culture. That’s the purpose of guidelines.
99% of rule enforcement, both IRL and online, comes down to individuals accepting the culture.
Rules aren’t really for adversaries, they are for ordinary situations. Adversaries are dealt with differently.
abtinf
好的。这有助于将其确立为HN(Hacker News)文化的一部分。这就是指南的目的。
无论是线上还是线下,99%的规则执行,都取决于个人对这种文化的认同。
规则并非针对对手而设,它们是为处理普通情况而存在的。对手则会用不同的方式来应对。
Agents that run while I sleep #
https://news.ycombinator.com/item?id=47331205
This all (waves hands around) sounds like alot of work and expense for something that is meant to make programming easier and cheaper.
Writing all (waves hands around various llm wrapper git repos) these frameworks and harnesses, built on top of ever changing models sure doesn’t feel sensible.
I don’t know what the best way of using these things is, but from my personal experience, the defaults get me a looong way. Letting these things churn away overnight, burning money in the process, with no human oversight seems like something we’ll collectively look back at in a few years and laugh about, like using PHP!
hi_hi
这一切听起来只是为了把编程变得更简单、更便宜,结果却带来了如此多的工作和开销。 写所有这些框架和工具包,它们建立在不断变化的模型之上,这感觉实在不靠谱。 我不知道使用这些东西的最佳方式是什么,但根据我的个人经验,默认设置就能让我走得很远。 让这些东西整夜不停地折腾,烧着钱,还无人监督,感觉几年后我们集体回看时,会觉得这很可笑,就像我们现在回头看使用PHP一样!
Tony Hoare has died #
https://news.ycombinator.com/item?id=47325228
As Dijkstra was preparing for his end of life, organizing his documents and correspondence became an important task. Cancer had snuck up on him and there was not much time.
One senior professor, who was helping out with this, asked Dijkstra what is to be done with his correspondences. The professor, quite renowned himself, relates a story where Dijsktra tells him from his hospital bed, to keep the ones with “Tony” and throw the rest.
The professor adds with a dry wit, that his own correspondence with Dijsktra were in the pile too.
srean
当迪杰斯特拉为生命尽头做准备时,整理他的文件和信件成了一项重要任务。癌症悄然袭来,时间已所剩无几。
一位帮助他处理此事的资深教授曾问迪杰斯特拉,他的信件该如何处理。这位教授本人也颇具声望,他讲述了一个故事:迪杰斯特拉从病床上告诉他,留着那些与“托尼”的通信,其他的都扔掉。
这位教授还带着一丝冷幽默补充说,他自己与迪杰斯特拉的通信也在那堆要被扔掉的文件里。
After outages, Amazon to make senior engineers sig… #
https://news.ycombinator.com/item?id=47325298
When I was really early in my career, a mentor told me that code review is not about catching bugs but spreading context (i.e. increasing bus factor.) Catching bugs is a side effect, but unless you have a lot of people review each pull request, it’s basically just gambling.
The more expensive and less sexy option is to actually make testing easier (both programmatically and manually), write more tests and more levels of tests, and spend time reducing code complexity. The problem, I think, is people don’t get promoted for preventing issues.
ardeaver
在我的职业生涯早期,一位导师告诉我,代码审查不是关于发现bug,而是传播上下文(即提高巴士系数)。发现bug只是副作用,但除非有很多人审查每个拉取请求,否则基本上就是在赌博。成本更高且吸引力更小的选择,实际上是让测试更容易(包括编程和手动层面),编写更多测试和多层测试,并花时间降低代码复杂度。我认为,问题在于人们不会因为预防问题而获得晋升。
Agents that run while I sleep #
https://news.ycombinator.com/item?id=47331724
sounds like alot of work and expense for something that is meant to make programming easier and cheaper.
Not if you are an AI gold rush shovel salesman.
From the article:
I’ve run Claude Code workshops for over 100 engineers in the last six months
serial_dev
听起来像是很多工作和花费,而这个东西本意是让编程更容易、更便宜。
除非你是个AI淘金热铲子销售商。
来自文章:
在过去的六个月里,我已经为100多名工程师举办了Claude Code工作坊。
Lego’s 0.002mm specification and its implications … #
https://news.ycombinator.com/item?id=47336306
Lego was always expensive, you can compare prices adjusted for inflation. For example, the 1979 Galaxy Explorer < https://brickset.com/sets/497-1 > was around $32, that’s $144 today. The reimagined set from 2023 < https://brickset.com/sets/10497-1 > was sold at $99, $106 today. Not only it is cheaper, but much larger and with many more pieces.
mmustapic
乐高一直很贵,你可以比较一下通货膨胀调整后的价格。例如,1979年的银河探险家当时售价约为32美元,相当于今天的144美元。而2023年的重制版售价99美元,相当于今天的106美元。它不仅更便宜,而且体积更大,零件也多得多。
How we hacked McKinsey’s AI platform #
https://news.ycombinator.com/item?id=47336554
Some insider knowledge: Lilli was, at least a year ago, internal only. VPN access, SSO, all the bells and whistles, required. Not sure when that changed.
McKinsey requires hiring an external pen-testing company to launch even to a small group of coworkers.
I can forgive this kind of mistake on the part of the Lilli devs. A lot of things have to fail for an “agentic” security company to even find a public endpoint, much less start exploiting it.
That being said, the mistakes in here are brutal. Seems like close to 0 authz. Based on very outdated knowledge, my guess is a Sr. Partner pulled some strings to get Lilli to be publicly available. By that time, much/most/all of the original Lilli team had “rolled off” (gone to client projects) as McKinsey HEAVILY punishes working on internal projects.
So Lilli likely was staffed by people who couldn’t get staffed elsewhere, didn’t know the code, and didn’t care. Internal work, for better or worse, is basically a half day.
This is a failure of McKinsey’s culture around technology.
frankfrank13
一些内幕消息:至少一年前,Lilli还是一个内部系统。访问它需要VPN、SSO(单点登录)等所有安全措施。不确定是什么时候这种情况改变的。
麦肯锡规定,即使是向一小群同事发布产品,也必须聘请外部的渗透测试公司。
我可以原谅Lilli的开发人员犯这种错误。对于一个“智能型”安全公司来说,要让很多环节都出问题,才能发现一个公开的端点,更不用说开始利用它了。
话虽如此,这里的错误是致命的。看起来几乎没有授权机制。根据我非常过时的了解,我猜测是一位高级合伙人动用了关系,才让Lilli对外公开。到那时,最初的Lilli团队的大部分、甚至全部成员都已经“调离”(去了客户项目),因为麦肯锡严厉惩罚从事内部项目的工作。
因此,Lilli团队很可能由在其他地方找不到工作、不懂代码、也不在乎的人组成。不管好坏,内部工作基本上就是半天的活儿。
这是麦肯锡在技术文化上的一次失败。
Meta acquires Moltbook #
https://news.ycombinator.com/item?id=47324764
I thought that Moltbook was sort of a joke because it was people LARPing as agents as much as it was agents, and given that, I’m confused by this:
“The Moltbook team has given agents a way to verify their identity and connect with one another on their human’s behalf,” Shah says. “This establishes a registry where agents are verified and tethered to human owners.”
So the impetus for the acquisition was either the verification technology or to hire someone who has worked on verifying agent identity.
Does anyone know what exactly Moltbook’s technology is, the technology being described by Meta? I can’t find anything on the website related to this. The only “verification” they seem to have is an OAuth connection with Twitter.
edit: I guess it’s this https://xcancel.com/moltbook/status/2023893930182685183
3rodents
我原以为 Moltbook 有点像个玩笑,因为它上边既有真正的特工,也有很多人只是在假装扮演特工。既然如此,我对下面这句话感到很困惑:
“Moltbook 团队为特工们提供了一种验证身份的方法,并代表他们的‘人类’主人互相联系,”Shah 表示。“这建立了一个注册系统,在这个系统里,特工的身份得到验证,并与他们的‘人类’主人绑定在一起。”
所以,这次收购的动机要么是其身份验证技术,要么是为了雇佣一位有验证特工身份经验的人。
有谁知道 Moltbook 的技术到底是什么?也就是 Meta 所描述的那种技术?我在他们的网站上找不到任何与此相关的内容。他们唯一的“验证”方式似乎只是一个与 Twitter 的 OAuth 连接。
编辑:我猜是这个:https://xcancel.com/moltbook/status/2023893930182685183
Online age-verification tools for child safety are… #
https://news.ycombinator.com/item?id=47323040
An FTC spokesperson told CNBC that companies must limit how collected information is used. […] The agency pointed to existing rules requiring firms to retain personal information only as long as reasonably necessary and to safeguard its confidentiality and integrity.
the very same rules that have allowed literally every single piece of my data to be leaked several separate times, and now i have free credit monitoring instead of privacy? and all of those companies still operate normally, as if nothing ever happened? very neat.
Discord said it is using the additional time this year to add more verification options, including credit cards, more transparency on vendors and technical detail of how age verification will work
and why didnt we start with credit cards? instead of facial recognition with peter thiel? (this is a rhetorical question)
john_strinlai
美国联邦贸易委员会(FTC)的一位发言人告诉CNBC,公司必须限制所收集信息的使用方式。[…] 该机构指出,现有规则要求公司仅在合理必要的情况下保留个人信息,并保护其机密性和完整性。
这些规则让我的所有数据在好几次不同的时间里被泄露得一干二净,而我现在得到的却是免费的信用监控,而不是隐私?所有这些公司依旧照常营业,仿佛什么都没发生过?真是太棒了。
Discord表示,今年正在利用额外的时间来增加更多的验证选项,包括信用卡验证,提高对供应商的透明度,并详细说明年龄验证将如何运作
那我们为什么不一开始就用信用卡验证呢?而不是用彼得·蒂尔(Peter Thiel)的面部识别?(这是个反问句)
Debian decides not to decide on AI-generated contr… #
https://news.ycombinator.com/item?id=47325134
My two cents: I’ve been coding practically my entire life, but a few years back I sustained a pretty significant and lasting injury to my wrists. As such, I have very little tolerance for typing. It’s been quite a problem and made full time work impossible.
With the advent of LLMs, AI-autocomplete, and agent-based development workflows, my ability to deliver reliable, high-quality code is restored and (arguably) better. Personally, I love the “hallucinations” as they help me fine-tune my prompts, base instructions, and reinforce intentionality; e.g. is that >really< the right solution/suggestion to accept? It’s like peer programming without a battle of ego.
When analyzing problems, I think you have to look at both upsides and downsides. Folks have done well to debate the many, many downsides of AI and this tends to dominate the conversation. Probably thats a good thing.
But, on the flip side, I personally advocate hard for AI from the point-of-view on accessibility. I know (more-or-less) exactly what output I’m aiming for and control that obsessively, but it’s AI and my voice at the helm instead of my fingertips.
I also think it incorrect to look at it from a perspective of “does the good outweigh the bad?”. Relevant, yes, but utilitarian arguments often lead to counter-intuitive results and end up amplifying the problems they seek to solve.
I’d MUCH rather see a holistic embrace and integration of these tools into our ecosystems. Telling people “no AI!” (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.
mr-wendel
我的一点看法:我基本上这辈子都在编程,但几年前我的手腕遭受了相当严重且持久的伤害。因此,我几乎无法忍受长时间的打字,这成了一个大问题,甚至让我无法全职工作。
随着大语言模型、AI自动补全以及基于代理的开发工作流程的出现,我交付可靠、高质量代码的能力恢复了,而且(可以说)比以前更好了。就我个人而言,我很喜欢这些“幻觉”,因为它们帮助我微调提示词、基础指令,并强化我的意图;例如,这个真的值得接受吗?这就像结对编程,但没有自尊心的较量。
在分析问题时,我认为我们必须权衡利弊。很多人对AI的诸多弊端进行了很好的辩论,而这些讨论往往会主导整个对话。也许这是一件好事。
但另一方面,我个人极力从可访问性的角度支持AI。我(或多或少)确切地知道自己想要什么样的输出,并且会执着地去控制它。但现在,是由AI在我的指引下工作,由我的思想来主导,而不是我的指尖。
我也认为,从“好处是否大于坏处?”的角度来看待AI是错误的。这个问题固然重要,但功利主义的论点往往会带来反直觉的结果,最终反而加剧了它试图解决的问题。
我宁愿看到我们生态系统对这些工具的整体接纳和集成。告诉人们“不要用AI!”(即便这得到了非常清晰的定义)对于那些不太在乎让世界(或仅仅是某个特定的代码库)变得更好的人来说,是毫无约束力的。
Debian decides not to decide on AI-generated contr… #
https://news.ycombinator.com/item?id=47326788
I’d MUCH rather see a holistic embrace and integration of these tools into our ecosystems. Telling people “no AI!” (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.
That doesn’t address the controversy because you are a reasonable person assuming that other people using AI are reasonable like you, and know how to use AI correctly.
The rumors we hear have to do with projects inundated with more pull requests that they can review, the pull requests are obviously low quality, and the contributors’ motives are selfish. IE, the PRs are to get credit for their Github profile. In this case, the pull requests aren’t opened with the same good faith that you’re putting into your work.
In general, a good policy towards AI submission really has to primarily address the “good faith” issue; and then explain how much tolerance the project has for vibecoding.
gwbas1c
我宁愿看到这些工具在我们的生态系统中得到全面采纳和整合。告诉人们“禁止使用AI!”(即使对其含义有非常清晰的界定)对于那些不关心让世界(或仅仅是某个特定的代码仓库)变得更好的人来说,是毫无威慑力的。
那并未触及争议的核心,因为你是个理性的人,想当然地认为其他和你一样理性的人懂得如何正确地使用AI。
我们听到的传闻是,一些项目收到了远超其审查能力的拉取请求,这些请求的质量明显很低,而且贡献者的动机不纯。也就是说,这些PR是为了充实他们的GitHub个人资料。在这种情况下,这些PR的发起并非出于与你工作相同的善意。
总的来说,一个关于AI提交的良好政策,首要任务必须是解决“善意”的问题;然后,再说明该项目对“氛围编程”有多大的容忍度。
Entities enabling scientific fraud at scale (2025) #
https://news.ycombinator.com/item?id=47336131
It kinda skips over how large mainstream journals, with their restrictive and often arbitrary standards, have contributed to this. Most will refuse to publish replications, negative studies, or anything they deem unimportant, even if the study was conducted correctly.
RobotToaster
这段内容一定程度上忽略了主流期刊及其 restrictive(限制性)和 often arbitrary(往往武断的)标准为此所做出的贡献。大多数期刊会拒绝发表重复性研究、负面研究结果,或任何他们认为是无关紧要的研究,即便这些研究的操作是正确无误的。
I was interviewed by an AI bot for a job #
https://news.ycombinator.com/item?id=47339362
If your potential employer is dehumanizing you before you’re on the payroll, how will they treat you once hired?
For me, this is the key point. If a company can’t even be bothered to show up for my interview – when everyone is trying to put their best foot forward – that bodes very ill for how I’ll be treated if I were to work there.
JohnFen
如果在你正式入职前,潜在雇主就不把你当人看,那么一旦你被雇佣,他们会怎样对待你?
对我来说,这才是关键。如果一家公司连面试都懒得参加——要知道在面试时人人都想展现自己最好的一面——那么,如果我真的去了那里工作,他们对我想必也不会好到哪里去。
Whistleblower claims ex-DOGE member says he took S… #
https://news.ycombinator.com/item?id=47335750
Ex-employee alleges data copied to a flashdrive.
Agency: “Social Security initially denied Borges’s allegations and said the data referenced in his complaint is stored in a secure environment walled-off from the internet.”
Ah walled of the internet, so no one can get there and copy the data to a flashdrive. Move on, move on!
You can’t make that up.
KingOfCoders
前雇员声称数据被复制到了U盘里。 相关机构称:“社会保障局最初否认了博赫斯的指控,并表示他投诉中提到的数据存储在与互联网隔绝的安全环境中。” 啊,与互联网隔绝,所以没人能进去把数据拷到U盘里。没事没事,走开走开! 你编都编不出来。