Hacker News 每日播报：今天我们聚焦美国软件开发税收政策的重大变化、德国百年悬挂式铁路的独特魅力、AI 编程工具的性能追踪、AI 卡路里计数应用的实际表现，以及一些关于互联网文化、宗教习俗和流行文化趣闻的深度探讨。
美国软件开发税收政策巨变：Section 174 条款引发行业震动
美国税法中关于软件开发费用扣除的 Section 174 条款近期引发了科技行业的广泛关注和震动。根据这项修改，美国公司在软件开发上的支出，特别是工程师的工资，不再能像以前那样在当年全额作为运营费用（OpEx）扣除，而是必须像资本支出（CapEx）一样，在五年内（如果是海外开发则是十五年）进行摊销。
这项变化意味着，即使公司实际现金流或会计利润不高，甚至可能亏损，其短期内的应税利润也会大幅增加。因为公司支付了实实在在的工资，但在税务上却不能完全抵扣，这给公司的现金流带来了巨大压力，尤其对那些投入大量资金进行研发但尚未盈利的初创公司来说，更是雪上加霜。有观点认为，这甚至被认为是导致近期一些科技公司裁员的原因之一。值得注意的是，这项规定目前只针对软件开发人员，而其他岗位的工资仍然可以当年全额扣除。目前，包括 Y Combinator 在内的多方正积极推动国会撤销这项修改，恢复之前的税收政策。
社区对此展开了热烈讨论，观点多样且深入。许多人认为，这本质上是强迫公司在软件开发上为政府提供一笔为期五年的无息贷款。一个核心争议点在于，税法中“软件开发”的定义非常宽泛，这给公司带来了巨大的合规和追踪负担，需要投入额外精力区分和记录员工在不同类型工作上的时间，这与软件开发的实际流程脱节。
关于软件开发是否应该被区别对待，也引发了激烈辩论。一些人认为软件也是一种资产，资本化是合理的。但另一些人反驳说，软件公司是“建造者”，他们的开发人员工资应该是成本，而非购买资产。此外，软件的维护和持续迭代特性与物理资产不同，它更像是一个需要持续投入运营成本的“活系统”。不少人认为，这项税改并非基于合理的经济或会计原则，而是2017年税改法案为了在预算上显得“收入中性”而采取的权宜之计，甚至可能适得其反，通过扼杀创新和初创企业，长期来看反而会减少税收。大家普遍认为 Section 174 的修改是一项考虑不周、执行困难且对美国科技行业有害的政策。
德国百年悬挂式铁路：穿越历史的空中之旅
《卫报》的一篇文章带我们前往德国伍珀塔尔，探索了世界上最古老的悬挂式铁路——伍珀塔尔悬挂式单轨列车（Schwebebahn）。这条独特的历史线路，自1901年正式开通以来，已在城市上空运行了一个多世纪，是工程史上的一个奇迹。
文章强调了 Schwebebahn 的悠久历史和独特设计。由于伍珀塔尔地处狭窄陡峭的山谷，传统地下或高架铁路难以修建，发明者 Eugen Langen 巧妙地将轨道架设在伍珀河上方。乘坐它被描述为一种愉悦的体验，每天八万名乘客的通勤仿佛变成了一场游乐园之旅。文章还提到了伍珀塔尔这座城市本身，以及1950年马戏团大象 Tuffi 意外坠河的著名趣闻，这个故事至今仍被当地人津津乐道。
社区对这篇文章的讨论非常活跃，从城市美学到工程实用性，再到历史背景，无所不包。许多人被其独特的视觉效果所吸引，并分享了历史影像资料，引发了关于城市发展和美学的讨论。一些人感叹现代城市因汽车和缺乏装饰的建筑而失去美感，而另一些人则指出历史城市也有其问题，且伍珀塔尔在二战后重建时，速度和成本是优先考量。
从工程角度看，悬挂式铁路的稀有性是一个热门话题。大家讨论了其潜在优势（如电气设备远离天气、轨道不占街道）和显著劣势（大量钢材、复杂结构、难以建造道岔、无法轻松过渡到地面或地下）。人们指出，这种设计在伍珀塔尔之所以成功，正是因为其路线基本线性且沿河而建，最大限度地减少了复杂道岔的需求。
历史背景也引发了讨论，大家澄清了 Schwebebahn 早于伍珀塔尔市的正式命名，并强调了城市基础设施的韧性，指出百年系统仍是交通核心的情况并不少见。关于安全记录，虽然文章侧重其魅力，但也有人提到了1999年的事故，并指出那是由于维护失误而非系统设计缺陷，其125年来的整体安全记录依然出色。
当独立服务器管理员遭遇数据抓取与执法机构：一场技术与侦探之旅
一篇来自 freespeechextremist.com 博客的文章，讲述了 Fediverse 实例管理员 Pete 如何追踪网站上的恶意流量，意外发现一个为美国联邦调查局（FBI）提供数据的抓取服务，并与 FBI 打交道的离奇经历。这篇故事不仅技术细节丰富，还揭示了互联网数据流动的隐秘角落以及去中心化社区运营的挑战。
故事始于管理员 Pete 试图解决 FSE 实例上出现的非法内容用户问题。为了深入了解恶意流量来源，Pete 运用了大量的系统管理和日志分析技术，强调了掌握 Unix 工具和网络诊断工具的重要性。在分析流量时，他注意到许多可疑用户来自 boardreader.com，一个已被 SocialGist 收购的论坛搜索引擎。BoardReader 正在积极抓取 FSE 的公共时间线，但其抓取行为非常激进，甚至使用住宅代理来逃避封锁，给 FSE 的服务器带来了巨大的负载和带宽费用。
在尝试通过邮件联系 SocialGist 无果后，Pete 采取了更激进的技术手段：他编写了一个 CGI 脚本，专门为 BoardReader 的抓取请求提供虚假的、随机生成的帖子数据。这种数据投毒策略最终奏效，BoardReader 停止了对 FSE 的抓取。
故事的高潮出现在 Pete 与 BoardReader 斗智斗勇期间。他收到一封来自 FBI 特工的邮件，要求提供一个用户的威胁信息。FBI 提供的截图并非来自 FSE，而是来自 BoardReader 的内部界面。Pete 意识到，FBI 正在通过 BoardReader/SocialGist 获取数据。他向 FBI 解释该用户并非 FSE 用户，并指出了 BoardReader 的错误归因。文章结尾揭示了该用户的真实身份——一个因进行大量虚假炸弹威胁和报假警而被捕的惯犯，这解释了 FBI 对这个看似荒谬的威胁如此感兴趣的原因。
社区对这篇文章的反应非常热烈，许多人赞扬了文章的质量和技术深度，认为它提供了关于数据抓取以及小型服务器运营者如何应对恶意行为的宝贵见解。关于 FSE 的平台政策以及它被其他 Fediverse 实例屏蔽的问题引发了激烈的辩论，讨论扩展到了关于平台管理员的审核权、以及 Fediverse 作为由不同规则的“数字草坪”组成的网络的本质。大家也讨论了 FBI 对在线威胁的评估，指出执法部门有责任调查所有威胁，无论其表面上看起来多么荒谬。
AI 编程代理性能大比拼：GitHub PR 数据背后的洞察
一篇关于 AI 编程代理（AI Coding Agents）性能追踪的文章，通过统计 GitHub 上几个主要 AI 编程代理创建的 Pull Request (PR) 数量、被合并的 PR 数量以及合并成功率，引发了热烈讨论。数据显示，OpenAI Codex 在总 PR 数和合并数上遥遥领先，成功率高达 83.5%。Devin 的 PR 数也相当可观，成功率为 60.9%。而 GitHub Copilot 和 Codegen 的成功率则在 40% 左右。
社区的讨论深入挖掘了这些数据的含义，并引出了许多相关的技术、法律和使用体验话题。关于数据本身的解读，有观点指出，简单比较合并率可能具有误导性，因为不同的产品在工作流程中创建 PR 的时机不同。例如，某些代理可能在用户私下迭代并对结果满意后才创建 PR，这样公开的 PR 合并率自然高。而另一些代理可能在任务开始时就创建 Draft PR，导致大量未合并的 Draft PR，从而拉低了整体的合并率。大家认为，合并率并不能完全反映代理的质量，还需要考虑 PR 的大小、复杂性、人工修改程度、设置便利性以及成本等多种因素。
讨论也对文章遗漏了一些重要的 AI 编程工具表示不解，并解释了这可能是因为文章的统计方法依赖于代理在 PR 作者或分支名称中明确标识自己。用户分享了他们使用不同 AI 代理的实际体验，有人对某些专用工具感到失望，认为它们不如直接使用大型语言模型。另一些用户则高度评价某些工具的自主性和任务管理能力，认为它们非常适合处理更复杂的任务。
一个重要的法律和版权问题也被提出。有观点引用了美国版权局的指导意见，即生成式 AI 的输出只有在包含足够的人类表达元素时才能获得版权保护。这引发了关于纯粹由 AI 生成的代码是否属于公共领域、以及这如何与开源许可证交互的讨论。有人提出了利用 AI 进行“洁净室”式代码重写的可能性，以规避原始代码的许可证限制。
AI 卡路里计数应用：智能健康管理的新挑战
一篇来自 Lifehacker 的文章，标题直截了当：《我使用了 AI 驱动的卡路里计数应用，结果比预期的还要糟糕》。作者 Meredith Dietz 对这类应用提出了尖锐的批评，认为尽管 AI 卡路里计数应用承诺通过拍照来简化饮食记录，但在实际使用中，它们的表现远未达到预期，甚至可以说是令人失望。
文章详细阐述了这些应用声称的工作原理：通过分析食物照片的颜色、纹理、相对大小，甚至结合参考物体来估算食物种类和份量。然而，作者的实际测试揭示了严重的准确性问题。例如，一个简单的苹果被识别为“咖喱鸡”，即使正确识别后，卡路里估算也比实际值低了 33%。更复杂的混合餐食则完全让 AI 束手无策，估算结果与实际值相去甚远。作者总结认为，AI 驱动的卡路里计数应用未能兑现其效率承诺，用户需要花费大量时间纠正 AI 的错误识别和份量估算，这使得它们比传统的、结合食物秤的手动记录更加耗时且不确定。
文章发布后，社区展开了热烈的讨论。SnapCalorie 的创始人直接在讨论中回应，澄清了定价并声称他们的算法确实比人类视觉估算份量更准确，但也承认两者都相当不准确。然而，许多人对创始人的回应提出了质疑，认为照片根本无法捕捉到关键信息，比如烹饪用油、酱汁等，这些对卡路里含量影响巨大，是 AI 视觉无法解决的根本性问题。
另一方面，许多人认同文章中关于手动卡路里计数的价值并非仅仅在于数字本身。他们认为，卡路里计数最重要的作用是教育和提高意识，通过查找和记录食物的卡路里，人们学会了不同食物的能量密度，从而能做出更明智的饮食选择。这种“测量本身就会改变行为”的心理效应，可能比 AI 的自动化更有效。讨论中也出现了对“卡路里进出”（CICO）模型本身的批判性声音，认为它过于简化，忽略了食物消化吸收率的个体差异和烹饪方式的影响。
经典 Mac 塑料色重现：3D 打印助力复古科技
对于复古科技爱好者和创客来说，一个令人兴奋的消息是：经典 Macintosh 电脑的标志性塑料颜色，现在以 3D 打印耗材的形式回归了。
文章详细介绍了收藏家 Joe Strosnider 如何致力于复制苹果经典 Macintosh 电脑（1980年代末至1990年代）所使用的标志性“白金色”（Platinum）塑料。由于原版 Mac 塑料常因时间推移而变脆和变色，Strosnider 投入资金与 Polar Filament 合作，精确匹配了他收藏的 Mac Color Classic 内部扬声器盒的颜色。更重要的是，他安排 Polar Filament 将这种名为“Retro Platinum”的 PLA 耗材公开发售，为爱好者们提供了稳定、可及的复古配件制作方案。
这种新耗材为复古计算社区带来了无限可能。爱好者们现在可以 3D 打印替换零件、定制配件，甚至全新的机箱，完美匹配他们经典机器的美学。文章特别提到了“SE Mini”桌面机箱项目，它允许用户将老式 Macintosh SE 或 SE/30 的逻辑板安装在紧凑的 3D 打印外壳中，连接到现代显示器，同时保留经典外观。
在讨论中，大家深入探讨了颜色名称的历史准确性，以及原版塑料变色的原因（如紫外线、阻燃剂）。许多人表达了对复古计算的怀旧之情，特别是对他们年轻时使用或渴望拥有的机器。他们欣赏老硬件相对的简洁和开放性，并认为修复、维护甚至为这些老机器制造新硬件是一种艺术形式，也是一种传承记忆的方式。讨论还将这种爱好与经典汽车或复古键盘等其他收藏爱好进行了类比，强调其价值在于热情、社区和保存，而非仅仅实用性。
初探 iOS 应用开发：AI 辅助下的学习与挑战
一位非专业 iOS 开发者分享了他首次尝试构建 iOS 应用的经历。他主要背景在产品和市场推广，偶尔写代码解决特定问题。这次尝试源于对现有照片管理应用的不满和好奇心，想看看自己构建一个简单的 iOS 应用——能管理、查找重复照片并支持滑动删除——到底有多难。
作者描述这是一个为期三天的紧张旅程，他称之为自己、AI 工具 Cursor 和 Xcode 之间的“有趣舞蹈”。他会先用 AI 工具交流想法，获取样板代码和结构建议，然后将这些代码片段导入 Xcode 进行扩展、验证、调试和研究。他发现这种 AI 辅助的方式比从零开始传统学习 Swift 要快，尽管比“凭感觉写代码”慢一些。在开发过程中，作者对 iOS 平台提供了丰富的原生库和 API 印象深刻，但也遇到了代码签名、目标管理和部署配置等平台特有的挑战。
文章中一个引人注目的观点是作者对现有照片管理应用定价模式的看法。他注意到许多类似功能的工具收取高昂的每周或每月订阅费，而实现核心功能所需的 API 并不复杂。他认为这种定价与实际价值脱节，计划自己的应用只收取一次性费用。关于 AI 在编码中的作用，作者认为 AI 的价值在于加速迭代和从错误中学习，但同时也强调了 AI 的局限性，特别是在涉及用户认证或敏感数据时，他不会完全依赖 AI 生成的代码。
社区围绕这篇文章展开了多方面的讨论。许多人对作者提到的代码签名、配置和部署的复杂性表示同感，并讨论了 Apple Developer Program 每年 100 美元的费用对于独立开发者或想发布免费应用的人来说是否是障碍。关于支持旧设备和平台更新，大家就苹果是否让支持旧设备变得困难展开了辩论，一方认为苹果的工具链更新频繁，另一方则反驳说，苹果的工具链允许使用最新 SDK 构建支持旧 iOS 版本的应用，开发者选择放弃旧设备更多是出于自身考虑。
关于应用盈利和定价模式，大家普遍认为，像作者这样只收取一次性低价的模式，在 iOS 平台上很难盈利，甚至难以覆盖开发和维护成本。他们强调，在 App Store 成功需要强大的市场推广，而这通常非常昂贵。
曼哈顿的“隐形边界”：Eruv 与宗教律法的现代诠释
一篇来自 Atlas Obscura 的文章，探讨了正统犹太教中的一个概念：Eruv（伊鲁夫）。伊鲁夫是一个象征性的边界，它将一个公共区域在宗教意义上转化为一个私人领域。根据犹太律法，在安息日（Shabbat）期间，禁止在私人领域之外携带或推动物品。对于正统犹太社区来说，这给日常生活带来了不便。伊鲁夫的设立，通过将大片区域（如曼哈顿的大部分）包含在一个象征性的“家园”内，使得这些活动在安息日变得可行。
文章指出，这个边界通常不是一道物理的墙，而是巧妙地利用现有的城市基础设施，比如电线杆之间的电线、围栏、建筑物的边缘等，形成一个连续的“门廊”或“墙壁”的视觉效果。曼哈顿的伊鲁夫规模巨大，覆盖了岛上的大部分区域，其维护和检查需要社区的持续努力。
社区对这篇文章引发了热烈讨论，展现了对这一宗教实践的多样化视角。关于伊鲁夫的实际边界和维护是讨论的一个焦点，大家分享了不同年份的曼哈顿伊鲁夫地图链接，并好奇边界是如何检查其连续性的。
其次，也是最集中的讨论点，在于对这种宗教律法解释和“变通”的看法。一部分人认为，将“墙壁”的概念解释为一根电线或利用现有结构形成的象征性边界，是一种“钻空子”的行为，是对原始律法精神的规避。另一部分人则从犹太教内部的视角进行解释和辩护，认为这并非简单的“钻空子”，而是拉比犹太教长期以来对律法进行解释和适应的传统，被视为在不断变化的现实世界中，保持对古老律法核心精神的忠诚的一种方式。讨论也触及了更广泛的宗教哲学问题，比如律法的字面意义与精神意义，以及宗教文本的解释权等。
《寻找肖恩·门德斯》：一场歌词里的地理侦探喜剧
一篇非常有趣、角度独特的博客文章，标题是《寻找肖恩·门德斯》（Finding Shawn Mendes）。这篇文章以一种极其认真严谨的方式，试图从流行歌手肖恩·门德斯（Shawn Mendes）的歌曲歌词中，推断出他当时身处何地，甚至幽默地推测他对某个地缘政治争议的立场。
文章的作者开篇就幽默地指出，在这个名人对政治影响力越来越大的时代，了解他们的政治观点变得越来越重要。于是，作者决定深入研究门德斯的歌曲《迷失在日本》（Lost in Japan），希望能从中找到线索。文章的核心要点在于，作者对歌词进行了字面意义上的地理和时间分析。歌词中提到“我离日本只有几百英里”，并且想“今晚飞到你的酒店”，而且飞过去后“我们会在同一个时区”。作者结合地图、时区图、航班信息，甚至门德斯对蚊子过敏的已知事实，一步步排除可能性。
经过层层推理，作者将目光投向了俄罗斯远东地区的一个岛屿。作者最终找到了一个看似完美的匹配，并由此得出结论：肖恩·门德斯通过这句歌词，巧妙而坚定地表达了他在某个争议中的立场。文章最后甚至配了一张经过处理的门德斯在机场的照片，声称是他在该岛机场的“确凿证据”，进一步强化了这种荒诞的严肃性。
社区对这篇文章的反应非常热烈，并且充满了赞赏和幽默。许多读者表示，尽管不确定这篇文章的“目的”是什么，但它“非常有趣”、“引人入胜”，让他们一口气读完。大家普遍认为这是一篇“精彩的恶搞博客文章”，是“对阴谋论的绝佳模仿”，或者是一种“将空洞流行歌词字面化以达到幽默效果”的手法。读者们也积极参与到作者的“推理游戏”中，指出作者逻辑中的潜在漏洞，而作者则继续用歌词的韵律和音节来反驳这些现实解释，将这种荒诞进行到底。