**OrgWebAlchemy** 是一个全新的 Guile Scheme 库，旨在解析 Org-mode 文档并将其渲染为 HTML，且无需依赖 Emacs。
该项目摒弃了脆弱的正则表达式，转而利用 Guile 的 `(ice-9 peg)` 模块实现**解析表达式文法（PEG）**。这种方法带来了一种简洁且模块化的架构：Org-mode 源码首先被转换为抽象语法树（AST），接着转换为 SXML，最后渲染为 HTML。通过将解析器与表示层解耦，该库不仅保持了高度的可定制性，还有望扩展到 Markdown 等其他输出格式。
目前，OrgWebAlchemy 支持核心的 Org 结构，包括嵌套列表、标题、表格、链接以及各种源码/引用块。该项目采用 GNU LGPL v3 协议开源，旨在为 Org-mode 处理提供一种轻量、易于修改且符合 Scheme 惯用法的解决方案。作者目前正寻求社区反馈，已将源代码发布在 [Codeberg](https://codeberg.org/jjba23/orgwebalchemy) 上，并计划将其打包适配到 GNU Guix。
每日HackerNews RSS
抱歉。
``` $ npx safe-not-safe check migration.sql 解析 libpg_query 17 (wasm) · 初始化中 · 0 条语句 · 301 字符 注意：正在下载并编译 PostgreSQL WASM 解析器。 未找到语句。请粘贴迁移脚本或加载示例。 正在检查 — 正在加载 PostgreSQL 解析器。 正在浏览器工作线程中下载并编译 libpg_query WASM。 $ ```
这场 Hacker News 讨论聚焦于确保 PostgreSQL 数据库迁移安全的挑战。讨论由旨在标记潜在危险 DDL 语句的浏览器工具“safenotsafe.dev”引发。
参与者认为，基于静态规则的检查本质上是不完整的，因为迁移的安全性往往取决于数据库的实时状态（如表的大小、现有列数据及活跃程度），而不仅仅是 SQL 语法本身。例如，如果对大型高流量生产表执行细微的架构变更，可能会引发灾难性的表重写或锁竞争。
主要观点包括：
* **细微风险：** 简单的工具可能会遗漏一些边缘情况，例如非唯一索引或在已存数据的列上添加 `NOT NULL` 约束。
* **工具选择：** 开发者分享了多种解决方案，如 `locksmith`、`reshape` 和 `strong_migrations`，这些工具提供了更好的内省能力或自动化安全措施。
* **运维策略：** 许多专家强调，“安全”不仅仅依赖于代码检查；它还需要通过设置 `lock_timeout` 来防止队列堆积、在副本上进行测试，以及采用零停机迁移模式（如先添加无约束列再回填数据）。
* **应用耦合：** 导致故障的主要原因之一是应用程序代码版本与数据库架构状态之间的不匹配，这要求在部署过程中进行精细的协调。
作者探索了一种通过分析大语言模型（LLM）的 token 概率来执行实时视觉任务的技术。通过提示模型从选项列表（例如：[A] 是，[B] 否）中进行选择，并强制模型进行单 token 输出，用户可以利用 `logprobs` API 参数提取模型对每个选项的置信度得分。 这种方法非常灵活，允许用户使用纯文本描述而非专门的计算机视觉模型来定义自定义检查逻辑（例如场景亮度或对象检测）。作者提供了一个 Python 脚本，用于捕获摄像头帧、将其编码为 base64 图像，并发送至本地 `llama.cpp` 实例或 OpenAI API。 该方法在分类任务中十分高效，支持每帧进行快速的多问题分析。虽然专用计算机视觉模型可能具有更高的性能，但这种灵活的“LLM 作为传感器”方法易于随时重新配置。所提供的代码演示了如何处理特定 API 的细微差别（聊天补全与响应），并将概率得分归一化，从而提供可操作的数据，例如以百分比表示的“画面中是否有人”的置信度。
这篇 Hacker News 帖子讨论了利用基于大语言模型（LLM）的封装程序，构建“星际迷航式”交互界面的可能性。这种界面能够根据环境背景推断用户意图，而不仅是依赖简单的触发器。
发帖人建议使用类似 Jev 的封装程序来评估场景（例如判断某人是否打算穿过一扇门）并决定执行动作。支持者认为，这种“随我所愿”（Do What I Mean, DWIM）的方法可以取代效率低下的二进制传感器系统。然而，反对者则对构建此类界面的复杂性表示担忧，指出“意图”本质上是混乱且模棱两可的。批评者警告称，在常用硬件中加入概率性的“黑箱”人工智能可能导致不可预测、令人恼火甚至危险的行为，并指出简单的距离传感器在特定用例中已具备 99% 的有效性。
在技术层面，讨论内容涵盖了如何利用视觉模型在本地实现这些系统、低延迟决策的重要性，以及关于 Jev 的特定架构是真正的革命性创新，还是仅通过对数概率偏置（logit bias）和提示词缓存（prompt caching）即可复制的 API 突破的争论。参与者普遍认为，尽管该技术前景广阔，但如何在“笨拙但可预测”与“智能但不可控”之间填补差距，仍然是一个重大的工程障碍。
Floci 是一款开源工具，提供各大云服务商的本地模拟功能，让开发者无需支付费用即可离线运行云服务。Floci 通过 Docker 容器模拟 AWS（支持 S3、Lambda 和 DynamoDB 等 119 项服务）、Azure（Blob、Queue、Table、Functions）、GCP（Cloud Storage）以及 OCI 的环境。 用户可以通过安装 Floci CLI 实现快速配置，或直接通过 Docker 部署特定的模拟器。运行后，开发者只需将现有的命令行工具（如 `aws`、`az`、`gcloud` 或 `oci`）指向 Floci 暴露的本地端口即可。这使得开发者能够像往常一样进行创建存储桶、上传文件和管理资源等操作，而无需有效的云订阅或网络连接。它是进行测试和开发的理想解决方案，不仅消除了账单顾虑，还简化了本地云集成流程。
关于 Floci（一款用于本地模拟云服务的工具）的 Hacker News 讨论，凸显了它作为 Localstack 等现有方案的一种轻量级替代品而崭露头角。
用户称赞 Floci 在构建自定义云兼容测试套件时易于使用。许多贡献者正在利用 Claude 等人工智能工具快速实现功能，这被一些人视为开源开发的“Folding at Home”模式——即通过集体努力和人工智能辅助，实现复杂模拟器的快速构建。
尽管一些开发者为了更高的保真度更倾向于针对真实的云 API 进行测试，但另一些人认为 Floci 及类似的模拟器（如 `fakecloud` 或 `Testcontainers`）对于个人项目、本地开发以及避免集成成本至关重要。
讨论还涉及了“数字孪生”带来的挑战，即模拟器与真实生产环境之间可能存在的偏差风险；此外还有一个关于产品名称的趣闻，该名称在罗马尼亚语、希腊语和意大利语中有着不太雅观的俚语含义。尽管存在语言上的争议，社区对 Floci 作为现代人工智能辅助编程工作流中一款轻量级、对开发者友好的工具所展现出的潜力持乐观态度。
正在检查您的浏览器...需要启用 Javascript
这篇 Hacker News 讨论聚焦于 Terence Tao 博客上 Amit Sahai 的一篇客座文章。文章认为，随着人工智能开始生成高度复杂且影响深远的科学设计（如核聚变电站），人类将需要进化为一种“可部署的智力储备”，以具备解释、验证和维护这些系统监督的能力。
辩论的关键主题包括：
* **“认知投降”：** 参与者讨论人类是否正变得过分依赖 AI 生成的成果，并随着模型准确性的提高，从审查代码转变为“认知投降”。
* **专业知识的目的：** 争论的焦点在于将数学/科学视为“商品生产”还是“思想转化”。一些人认为 AI 自动化使人类学习这些学科的努力变得过时；而另一些人则坚持认为，学习过程对于人类意义、能动性以及安全管理 AI 系统的能力至关重要。
* **经济风险与生存风险：** 参与者对于 AI 代表的是一场将人类推向“创意经济”的新工业革命，还是一场会导致大规模经济冗余和“贫民窟式”不平等的生存威胁，存在分歧。
* **AI 的局限性：** 持怀疑态度的人指出，大语言模型（LLM）本质上仍然是容易产生隐蔽错误的非确定性“垃圾信息”生成器，并认为它们与编译器等确定性工具存在根本区别。
联邦通信客户端 *Conversations* 始于 2014 年的一个学生项目，此后逐渐发展为一项可持续的业务。十多年来，该开发者通过定制开发、咨询服务、补助金和应用商店销售等多种方式维持运营。
然而，该开发者与 Google 之间的关系却极其恶劣。由于 Google 频繁且武断地拒绝应用上架、缺乏人工支持，以及安全更新的延迟带来的严重风险，开发者对该平台深感失望。在服务如此糟糕的情况下，仍需向 Google 支付 15% 的佣金（每年超过 1000 欧元），这已变得难以接受。
随着长期补助金为收入提供了多元化保障，开发者在财务上不再依赖应用商店。因此，他们决定彻底放弃 Google Play，将重心转向以 F-Droid 作为主要分发渠道。在与 Google 的平台限制抗争多年后，开发者正式结束了与该平台的合作关系。
关于“Conversations”应用转为免费一事，Hacker News 上的讨论凸显了人们对 Google Play 商店生态系统的强烈不满。开发者及许多评论者认为，虽然 15% 的平台费用在托管和税务服务方面尚可接受，但 Google 缺乏支持、不透明的自动化决策以及高门槛的开发者要求，已使该商店成为一个不可持续的环境。
评论者将当前“大型科技公司”的应用商店描述为“敲诈勒索”或寄生行为，指出它们实质上是强制性的垄断机构，在未提供相应价值的情况下榨取“租金”。许多用户认为 Google 将开发者视为“牲畜”，在不提供任何人工支持的同时，强迫开发者遵守死板且往往荒谬的规则。
尽管一些参与者认为这些平台提供了必要的基础设施和安全性，但另一些人则认为这种“垄断权力”是蓄意设计的，旨在阻碍竞争。讨论最后达成了一种强烈的共识：开发者不应试图安抚这些守门人，而应专注于替代分发渠道、PWA（渐进式 Web 应用），或彻底摆脱对中心化寻租平台的依赖。许多人认为当前的格局是市场竞争的失败，需要迫切的监管干预。
作者分享了自己成为“AI 牧羊人”的工作经历——即利用编程智能体来生成、提交和解释代码，以及这种方式对其技术能力的负面影响。起初，AI 似乎是提高生产力的捷径，但很快就导致了自满、对技术掌控力的丧失，以及深重而疲惫的“语境切换”负担。 作者发现，AI 非但没有节省时间，反而迫使他们陷入了“照看”代码、审查平庸代码以及管理复杂智能体工作流的循环，最终阻碍了真正的进展。他们最终意识到，自己变成了一个更差劲、更生疏的开发者，甚至无法完全理解自己交付的代码。 在一次因同事指出 AI 生成的合并请求（PR）中存在基础错误而感到羞愧后，作者彻底停止了使用 AI。回归手动测试驱动开发（TDD）和直接编程的过程，不仅恢复了他们的信心，加深了其对架构的理解，还重新点燃了他们对编程的热爱。作者警告称，过度依赖 AI 会导致关键工程技能退化，并敦促开发者重拾自主权，认为真正的价值来自于亲手解决问题，而非自动化编码过程。
这段 Hacker News 上的讨论反映了资深软件工程师群体对于使用 AI 编程工具所持的对立观点。
**批评意见：**
许多开发者认为 AI 工具如同“随机药物”。他们指出，虽然 AI 承诺能提高生产力，但往往会导致：
* **失去控制：** 开发者不再理解自己的代码库，导致系统变得臃肿、过度工程化且难以维护，形成“靠感觉编程”的局面。
* **技能退化：** 对 AI 的持续依赖使工程师无法保持高质量架构设计和故障排查所需的深层底层专业知识。
* **审查疲劳：** AI 代码生成的速度造成了瓶颈，开发者花费在“照看”和纠正 AI 幻觉上的时间，往往比手动编写代码所需的时间更多。
**辩护意见：**
支持者认为，如果使用得当，AI 是强大的效率倍增器。他们建议：
* **正确使用：** AI 在处理样板代码、单元测试或作为交互式研究助手时表现出色，而不是作为盲目的代码生成器。
* **任务管理：** 成功的关键在于将任务分解为细小、可验证的模块，并保持严格的防护措施。
* **演进趋势：** 许多人认为“手动编码”正在成为一种遗留技能，类似于汇编语言，而未来属于那些精通高阶系统设计和 AI 编排的人。
2011年，苹果推出了“Cards”应用。这是一个由史蒂夫·乔布斯构思的宏大项目，允许用户发送高质量的凸版印刷定制卡片。该计划代号为“极速赛车”（Speed Racer），但对于负责实现乔布斯完美主义愿景的生产合作伙伴来说，这却是一场运营噩梦。
苹果要求提供高端功能，如100%纯棉纸张、厚重的压凹效果，以及为了不破坏美感而采用的肉眼不可见、仅能通过紫外线扫描的条形码。这些要求需要复杂的、多阶段的印刷工艺，并要求邮政部门进行前所未有的配合。该项目因管理不善而臭名昭著，导致了严重的洲际物流混乱，并引来了苹果公司“紧急级别”的审查。
尽管在重压之下上线，但该应用推出后的市场需求并不理想，无法证明其巨大的物流投入是合理的。虽然在乔布斯于2011年10月去世后，苹果内部团队出于对他的敬意坚持了一段时间，但该应用最终还是在2013年被停用。这个项目至今仍是一个警示故事，反映了苹果不妥协的设计理念与大规模市场制造和交付现实之间的冲突。
这篇链接文章及随后的 Hacker News 讨论回顾了苹果公司 2011 年推出的“Cards”应用，该应用允许用户直接通过 iPhone 发送实体的凸版印刷贺卡。
该领域的前竞争对手们回顾了苹果进入市场时那种被“Sherlocked”（被苹果原生功能取代）的感觉。尽管苹果带来了高端的设计，例如为了保持信封整洁而定制的紫外线隐形条码，但该产品在可靠性上表现挣扎，且缺乏主流吸引力。讨论强调了史蒂夫·乔布斯时代“经典”的产品开发模式：即对那些他人认为不必要的“疯狂”审美细节——如隐藏条码或监管标记——有着无情且往往显得生硬的执着。
评论者对这种理念看法不一。一些人将其视为苹果高端品质和追求完美的标志，并将其比作“范·海伦乐队的棕色 M&M 豆”——这是衡量运营能力的一个先行指标。另一些人则批评这是一种傲慢的、由创始人驱动的“脑抽”行为，将虚荣心置于用户需求之上，往往以牺牲员工福祉和实际的产品市场契合度为代价。最终，该应用因需求不足而停用，这也提醒人们：即使是苹果最精心打造的项目，如果缺乏足够的实用性，也同样会失败。
抱歉。