最近一份范德堡政策加速器报告显示，公司正在利用忠诚度计划中的法律漏洞，广泛追踪消费者。这些计划，例如麦当劳的数字大富翁游戏，虽然看似提供奖励和折扣，但由于参与是“主动选择加入”，因此绕过了许多隐私法律。 这使得公司能够收集的数据远不止购买历史，还包括地理位置、浏览活动，甚至社交媒体数据。例如，麦当劳利用这些信息来训练人工智能，构建关于顾客的详细心理画像，以预测和影响他们的行为。 该报告警告说，如果麦当劳到2027年实现2.5亿忠诚度计划用户目标，它将积累一个规模可与国家情报机构相媲美的消费者数据库，引发严重的隐私担忧。本质上，消费者正在用个人数据交换感知到的好处。
每日HackerNews RSS
## 人工智能、广告与剥削：摘要
一篇近期文章指出，人工智能不仅被用于*定位*广告，还被用于*欺骗*消费者花更多钱。这并非新现象——公司分析购买模式以预测行为的例子可以追溯到21世纪初（例如Target臭名昭著的怀孕预测）。然而，人工智能放大了这些做法，实现了更复杂的画像和动态定价。
讨论线程显示出对数据隐私的担忧，用户分享了基于个人健康或财务状况的令人毛骨悚然的精准广告定位的案例。一些人指出，人工智能的有效性在于利用弱点——例如针对赌徒或经历生活变化的人——而不是简单地提供有用的产品。
许多评论者认为，核心问题不是人工智能本身，而是不受约束的资本主义和缺乏监管。人们对个性化定价、数据收集以及对更强消费者保护的需求表示担忧，可能包括国有化广告公司或预装广告拦截器。最终，对话表明人们对一个旨在以牺牲消费者福祉为代价来最大化利润的系统越来越不安。
## SugarBank 的错失良机 2007年移居拉脱维亚，作者获得了更快的互联网，得以见证史蒂夫·乔布斯发布第一款 iPhone——这一瞬间激发了一个关键的想法。作者认识到 iPhone 有潜力颠覆成人内容行业，并构想了 SugarBank，一个赋能创作者直接将其内容变现的平台，绕过当时昂贵且限制重重的壁垒。 然而，SugarBank 最终失败了。作者详细描述了各种挑战：缺乏资金、完美主义倾向阻碍了快速开发、依赖不可靠的技术支持，以及在社交媒体出现之前的世界中，规范在线展示的心理障碍。 这段叙述凸显了 2003 年到今天之间巨大的技术差距——从昂贵的设备和缓慢的互联网到复杂的在线支付处理。最终，作者认为 SugarBank 只是太早了，预见了 OnlyFans 等平台将会蓬勃发展的未来。反思 OnlyFans 的成功，作者指出了关键因素，例如流量产生和拥抱成人内容的意愿，而 SugarBank 在这些方面优先考虑了道德考量。这次经历既是一个警示故事，也是一个新事业的基础，旨在通过从一项开创性但过早的尝试中吸取的经验教训来赋能创作者。
一个黑客新闻帖子讨论了一项“发明OnlyFans”的说法。该帖子标题为“我是如何以及为什么在2004年发明了OnlyFans (themosthandsomemanintheworld.com)”，引发了评论区的争论。
用户很快指出该标题很可能是点击诱饵，因为作者在2004年创建了一个*类似*的网站，但最终失败了——它实际上并不是OnlyFans。一些人认为这种说法是比喻性的，并指出不寻常的标点符号（“我是如何发明Facebook的。2001年”）暗示了一种比较，而非字面意义上的发明。另一些人则认为该标题具有误导性，因为发明需要相同的产品名称。一位评论员还指出，作者塞缪尔·阿格博拉（Samuel Agboøla）之前曾为Fleshbot撰稿。
讨论的中心在于“发明”与创建前驱之间的语义差异，以及标题措辞的有效性。
我们检测到您的浏览器已禁用 JavaScript。请启用 JavaScript 或切换到受支持的浏览器以继续使用 x.com。您可以在我们的帮助中心查看受支持的浏览器列表。帮助中心 服务条款 隐私政策 Cookie 政策 版权信息 广告信息 © 2025 X Corp.
## VRChat 与日本创作者：总结
最近Hacker News上的讨论强调了日本创作者在VRChat中的不成比例的活跃度。虽然人口数量是一个因素，但评论员认为文化因素很重要。日本似乎比美国更鼓励参与艺术创作——绘画、设计等，这可能源于对自我表达更支持的态度和对失败的恐惧较少。
这与美国被认为存在的“螃蟹桶效应”形成对比，在这种效应中，创意努力常常受到阻碍或受到负面评价，特别是如果不能立即盈利。日本的VR资产市场，例如头像，正在蓬勃发展，平台如Booth.pm 拥有很高的参与度和对原创性的关注。
许多评论员指出日本独特的文化活动，如Comiket，为创作者提供了草根机会，以及社会对工艺的重视。 还有人指出经济因素和日本艺术工具的可及性。 讨论还涉及VRChat本身的更广泛的社会动态，一些人将其描述为一个既有创意潜力又有问题社交互动的空间。
## PostHog SSRF 到 RCE：24 小时研究
在团队评估 PostHog 用于自托管产品分析时，一位安全研究人员对该平台的内部机制进行了 24 小时的深入研究。这导致发现了一个关键漏洞链，能够实现远程代码执行 (RCE)。
研究人员发现，虽然 PostHog 提供了广泛的外部集成，但其 webhook 功能缺乏适当的 SSRF 保护。一个看似经过验证的 webhook 端点允许绕过限制，从而能够向内部服务发送请求。具体而言，ClickHouse 的 PostgreSQL 表函数中的一个缺陷，加上不正确的转义，导致了 SQL 注入。
通过串联这些漏洞——一个被遗忘的 webhook 验证、Rust worker 中的 SSRF、ClickHouse 转义错误以及 PostgreSQL 的 `FROM PROGRAM` 功能——研究人员以 `postgres` 用户的身份实现了 RCE。攻击涉及触发一个 webhook，在 PostgreSQL 服务器上执行 shell 命令。
这些漏洞 (CVE-2024-9710, CVE-2025-1522, CVE-2025-1521) 已通过 Zero Day Initiative (ZDI) 负责任地披露给 PostHog，并且已得到解决。这强调了在供应商选择期间进行彻底、实践的安全研究的价值，即使是开源解决方案也是如此。
## PostHog 安全问题总结
一份近期报告详细说明了 PostHog 内部的几项安全漏洞，包括服务器端请求伪造 (SSRF)、ClickHouse SQL 逃逸问题，以及暴露的默认 Postgres 凭据导致潜在的远程代码执行 (RCE)。
PostHog 的安全团队迅速响应，在 2024 年 10 月收到报告后 24 小时内解决了 SSRF 漏洞。最初的影响仅限于自托管部署，因为其云版本使用更安全的 Rust 服务处理 Webhook。他们现在正在实施“烟幕”等架构改进，以提供更好的外向保护。
ClickHouse 漏洞允许执行任意 SQL 代码，是实现 RCE 的关键组成部分。虽然这不是 ClickHouse 本身直接的缺陷，但设置——允许访问内部服务——受到了批评。ClickHouse 漏洞的修复已经实施。
讨论还集中在 PostHog 使用 AI 生成的代码（“氛围编码”），其中超过 300 次提交归功于 Claude，引发了对代码审查实践的担忧。一些用户因这些发现而对平台失去了信任。
## 商业地产中的“延长与假装”问题 大城市里空置的店面不一定是因为房东坚持高租金，而是源于一种复杂的金融动态。核心问题是：商业地产通常被视为一种*金融产品*，而非实体建筑。 与基于购房者还款能力的住宅抵押贷款不同，商业贷款基于建筑物的*收入潜力*，且通常是短期贷款。建筑物的价值由其预测的收入流和协商的“资本化率”决定。如果建筑物表现不佳——例如空置率达到一半——收入下降，其价值将暴跌。 降低租金以填补空置可能*降低*建筑物的评估价值，从而可能迫使业主面临止赎。业主和银行都希望避免这种损失，从而导致“延长与假装”——在最初乐观的条款下延长贷款期限，希望市场好转，即使这意味着持续亏损。 这种做法并非最佳方案，但解决方案很困难。通过税收增加对房东的压力可能会引发违约和银行不稳定。问题的根源在于市场上过剩的资本将建筑物变成了金融工具，而扭转这种趋势可能会影响建筑供应。
## 商业空间空置的原因 - Hacker News 总结
最近 Hacker News 上的一场讨论围绕商业空间空置问题展开，起因是 Strong Towns 的一篇文章。核心问题似乎是多种因素的复杂作用，**土地投机和财务激励常常将持有空置房产置于以合理价格出租之上。**
许多评论员指出，**加州第 13 号提案** 以及类似政策加剧了这个问题，允许业主避免因房产价值上涨而缴纳更高的税款。一个关键论点是，银行有动机*维持* 虚高的房产估值，即使房产空置，因为降低租金以填补空缺将承认价值下降和潜在损失。这导致了一种“**延长和假装**”的情况，即业主承担损失而不是出售或降低价格。
提出的解决方案包括**土地价值税**、**空置税**以及更严格的区域规划法规，以阻止建造更多空置空间。然而，一些人认为仅仅增加成本无法解决问题，而且目前的制度使富有的房产所有者受益，他们有能力等待价值上涨。最终，这场讨论强调了商业地产被更多地视为**一种金融产品，而不是企业的功能性空间**，从而对当地经济产生不利影响。
GitHub 推迟了已宣布的 GitHub Actions 计费变更。
GitHub postponing the announced billing change to GitHub Actions
1 天前
👍 1人点赞 👎 1人踩 😄 1人笑 🎉 1人欢呼 😕 1人困惑 ❤️ 1人爱心 🚀 1人火箭 👀 1人眼睛。 你现在无法执行该操作。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
GitHub 推迟了宣布的 GitHub Actions (github.com/orgs) 计费变更
20 分，top_sigrid 1 天前 | 隐藏 | 过去 | 收藏 | 1 条评论
rawling 1 天前 [–]
https://news.ycombinator.com/item?id=46304379 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## Fedify 与面向库的日志记录的需求 作者在构建 Fedify（一个 ActivityPub 服务器框架）时遇到一个挑战：现有的日志库是为应用程序设计的，而不是为不引人注目的库设计的。像 Winston、Pino 或 `debug` 这样的传统选择要么对用户施加配置选择，要么缺乏复杂、联邦系统所需的结构化、基于级别的日志记录。 为了解决这个问题，作者创建了 **LogTape**，一个专门为库作者设计的日志库。LogTape 利用 **分层类别**，允许开发者进行广泛的日志记录，*而无需*默认输出——用户明确启用特定子系统（例如“fedify”、“federation”、“http”）的日志记录。这提供了精细的控制，并避免了控制台的混乱。 LogTape 还通过 `AsyncLocalStorage` 提供 **隐式上下文**，自动使用 `requestId` 标记日志，以便轻松关联异步操作，这对于调试联邦活动流程至关重要。 用户可以选择不记录日志、仅记录错误级别的日志，或针对特定区域进行详细调试，所有这些都可以配置而无需更改代码。LogTape 支持各种运行时（Node.js、Deno、Bun），并与现有的可观察性工具集成。作者强调尽早设计类别、使用结构化日志记录，并信任用户控制日志可见性。 LogTape 旨在填补日志记录领域的空白，为需要仅在请求时才提供详细调试信息的库提供解决方案。
## 日志库：开发者们的烦恼
一位在Hackers.pub的开发者创建了自己的日志库，因为现有的选项无法满足他们的需求，由此引发了关于最佳实践的讨论。核心争论在于库是否*应该*直接进行日志记录。
许多评论者认为库不应该处理日志记录，而是应该发出事件，然后由应用程序根据需要记录这些事件。这样可以避免强制用户使用特定的日志实现，并防止库的日志记录干扰应用程序级别的日志配置。人们对可组合性、潜在的性能影响以及将库日志集成到集中化系统中的难度表示担忧。
另一些人则指出了Java、Python和Rust等语言中已建立的日志解决方案，这些方案允许在库中进行可配置的日志记录。讨论还涉及了一些实现（如Log4j的漏洞）的缺点，以及像OpenTelemetry这样的新标准的潜力。最终，共识倾向于库提供钩子，让用户注入自己的日志记录机制，而不是强制使用固定的解决方案。
## FIFA 即将登陆 Netflix 游戏 – 摘要
Netflix 正在将其不断扩充的游戏库中增加一款新的 FIFA 游戏，由 Delphi Interactive 开发。然而，这并非大多数人所期望的 FIFA 游戏。EA 失去了 FIFA 授权，现在制作“EA Sports FC”，这意味着这将是一款独立的游戏。
讨论的中心是这款新游戏的游戏质量，由于宣布时缺乏细节，人们对此表示怀疑。一些用户质疑游戏体验，特别是手机作为控制器的设置。另一些人则争论 Konami 的 eFootball 作为替代品的优点，以及 Konami 和 EA 的商业行为的更广泛问题。
一个关键的讨论点是 FIFA 领域的碎片化——EA 的品牌重塑，FIFA 尝试创建自己的游戏，以及对游戏玩家的整体价值主张。许多评论员表达了对较早 FIFA/PES 游戏的怀旧之情，质疑现代版本是否提供了显著的改进。对于企业宣传和潜在的令人失望的游戏体验，也存在愤世嫉俗的态度。
GPT-5.1、Claude Sonnet 4.5、GPT-5-Codex、Claude Opus 4.5 和 Gemini 3 Pro 的模型基准测试，用于了解它们作为编码代理后端在延迟、吞吐量、速率限制、冷启动、成本和分词效率方面的表现。
## AI 编程现状报告 2025：摘要
Greptile 是一家每月分析约十亿行代码的 AI 代码审查公司，发布了第一份“AI 编程现状”报告。该报告强调了代码输出的显著增加——每位开发人员的月代码行数从 4,450 行增加到 7,839 行，这归功于 AI 编程工具的使用。据报道，团队的速度提高了 76%。
然而，该报告引发了争论，主要围绕其对“代码行数”（LoC）作为指标的依赖。许多评论员指出，LoC 历来是衡量生产力的一个糟糕指标，并且可能预示着技术债务的增加，尤其是在报告中显示错误数量增加的情况下。
讨论集中在需要更好的质量指标——代码变更率、持久性、错误率和可维护性——来真正评估 AI 的影响。虽然一些用户分享了使用 AI 辅助编码的积极体验，但另一些用户则对代码质量以及潜在的复杂性增加表示担忧。Greptile 承认 LoC 的局限性，并计划在未来的报告中探索更有价值的指标。该报告还涉及大型企业和初创公司之间 AI 采用成功率的差异。
## 人工智能的类人幻觉
尽管现代人工智能——特别是大型语言模型（LLM）——看起来非常像人类，能够进行对话并提供建议，但它们与人类认知从根本上是不同的。这种差异不太可能随着规模的扩大而缩小；事实上，随着改进，LLM 可能会变得*更不*像人类。
核心区别在于它们的处理方式。人类依赖有限的资源、过去的经验和高效的启发式方法，而 LLM 则利用海量数据集和并行处理来进行下一个词元的预测。LLM 在数据摄取和计算能力方面不受生物限制。
最近的研究表明，简单地扩展 LLM 或使其与人类偏好对齐（例如通过人类反馈强化学习）并不能弥合这一差距。这些方法优化了*输出*，而不是推理的底层*过程*。
要真正评估“类人程度”，需要一个以过程为重点的框架——一个探究 LLM *如何*做出决策，而不仅仅是 *做出什么* 决策的框架。这涉及创建受控环境，以测试歧义、新颖性和动态反馈，从而反映人类思维的复杂性。理解这些根本差异对于负责任的 AI 开发以及确保与人类价值观保持一致至关重要。
## AI能力与人性：一则黑客新闻讨论总结
最近的一次圆桌讨论引发了关于大型语言模型（LLM）的能力是否等同于人性的争论。尽管LLM的训练数据远超任何个人，但评论员认为这并不意味着它们拥有同等程度的理解或智能。
主要观点包括：人类拥有多感官体验，并且可以主动操纵世界，而LLM目前缺乏这一点。LLM在选择性学习方面存在困难，并且容易“忘记”信息，这与人类不同。此外，LLM不具备人类大脑中固有的进化“先验知识”，其运作方式也不同——并行处理信息，而人类则是逐步进行。
许多人认为，仅仅关注无法区分的*输出*会忽略*过程*上的根本差异。即使人工智能可以像人类一样预订航班，其*方式*也可能仍然明显非人类。讨论还强调了对LLM被宣传为廉价的人力替代品，以及认识其局限性的重要性，尤其是在相关性和上下文理解方面。最终，共识倾向于LLM是强大的工具，但与人类智能从根本上不同。