**摘要：Un-0 与物理人工智能的未来**
Unconventional AI 致力于以利用物理定律的节能计算，取代耗电的 GPU 深度学习。他们的首个里程碑 **Un-0** 是一款图像生成器，它模拟了一个耦合库拉本托（Kuramoto）振荡器系统——这是一个振荡能够自组织成模式的物理动力系统。
**工作原理：**
Un-0 用大量振荡器取代了传统的神经层。这些振荡器随时间演化，受学习到的耦合强度和频率控制。图像的生成过程是：初始化一个随机状态，让系统通过物理动力学“计算”出输出结果，最后将最终的相位表示通过一个紧凑的传统解码器进行处理。
**性能表现：**
在 ImageNet 64×64 基准测试中，Un-0 的 FID 得分为 6.74，达到了早期传统生成模型的质量水平。消融研究证实，物理动力学执行了有意义的计算：振荡器系统负责处理结构多样性和特征可分性，而解码器则专注于提升图像质量。
虽然 Un-0 在参数效率或峰值质量上尚未达到最先进水平，但它证明了现代人工智能任务可以在物理基底上运行，使该团队朝着实现 1000 倍能源效率提升的目标更近了一步。
每日HackerNews RSS
Om Malik 于 2026 年 6 月 24 日在斯坦福医院因长期心脏健康问题去世，家人和朋友陪伴在他身边。我们邀请您在下方评论区分享您对 Om 的怀念，或在 X/Twitter、Instagram、Threads 或 LinkedIn 上发布并标记他的账号。如需了解更多关于 Om 的生平和工作，您可以访问他的个人主页或阅读维基百科上的相关资料。—— Om 的家人
科技界正在哀悼先驱科技记者、《GigaOm》创始人奥姆·马利克（Om Malik）的离世，享年 60 岁。
马利克被广泛视为早期科技博客的教父，他以直言不讳、充满人文关怀的视角以及在充满炒作的行业中始终保持的深厚诚信而备受赞誉。除了《Broadbandits》等新闻贡献外，许多硅谷人士将他视为一位“仁者”——他是一位无私的导师，不求回报地为新人提供机会与指导。
无论是通过对电信行业的敏锐分析，还是后来转向摄影和细腻的散文创作，马利克始终保持着善良与好奇的声誉。许多同行和前门徒认为他塑造了他们的职业生涯，并体现了曾经定义湾区科技圈的协作与支持精神。他的离世引发了各界的悼念，人们赞赏他对真相的执着以及他透过商业表象洞察人性的能力。他留下了一份专业卓越与个人慷慨的深远遗产。
这段内容是 PDF 文件的二进制数据流（已压缩），不是可以直接阅读的文本。
由于您未提供需要翻译的内容，请将文本粘贴在上方，我将为您翻译。
抱歉。
“看门人谬论”（Doorman’s Fallacy）是指一种错误认知，即认为技术可以在不产生负面后果的情况下取代人工服务。最近的一次早午餐体验完美地诠释了这一点：那家餐厅用二维码取代了实体菜单和服务。 这种看似高效且能降低成本的手段，最终却降低了顾客的体验。基于二维码的系统强迫客人们不断地查看手机，破坏了团体的社交氛围。浏览菜单、处理停车提醒、分摊账单等简单任务，变成了摩擦、困惑和焦虑的来源。存在缺陷的数字化界面导致一行人对支付情况感到不确定，引发了关于分摊费用的尴尬对话，账单结算也出了错，最终还是需要工作人员出面干预。 虽然餐厅的初衷是追求运营效率，但这一做法剥夺了用餐体验的轻松感与“魔力”。通过将数字化自动化置于人工服务之上，该机构无意间创造了一个令人紧张的环境，从而让顾客不再愿意进行多人聚餐。这是一个警示故事：当企业优先考虑削减成本的技术而非人的因素时，往往会牺牲掉吸引顾客回头的核心品质。
“看门人谬论”（Doorman’s Fallacy）指的是企业倾向于将那些提供显著但微妙的人性价值的角色进行自动化处理。尽管看门人常被简单地视为开门者（这一任务可轻易被技术取代），但他们实际上提供了“被动式待客之道”和隐形协作，例如安保、问题解决以及社交润滑。
所引用的 Hacker News 讨论指出，当企业用技术取代人工（如扫码点餐或停车应用）时，他们往往关注直接成本，而非客户体验的“最后一公里”。评论者认为，糟糕的自动化忽略了环境背景、极端情况以及服务中复杂的社交动态，从而制造了阻碍。
然而，讨论存在分歧：一些人认为该“谬论”是理解过度追求效率的设计如何侵蚀社会结构的有用框架；另一些人则认为，许多“过时”的角色被取代仅仅是因为它们效率低下或属于奢侈配置。批评该术语的人士认为，许多现代抱怨并非针对自动化本身，而是针对“糟糕的界面”和不当的实施，并指出设计良好的技术有时比人工更高效地处理任务，例如分摊账单。
初创企业常面临一种危险的诱惑，即来自大型“不匹配”企业客户的订单。虽然眼前的收入可以解决生存问题，但为了迎合这些客户，初创公司往往被迫定制产品，从而逐渐侵蚀其最初的愿景和路线图。
布莱恩·切斯基（Airbnb）、斯图尔特·巴特菲尔德（Slack）以及科里森兄弟（Stripe）等创始人之所以能存活下来，是因为他们意识到产品路线图需要有“主心骨”。他们明白，拒绝那些利润丰厚但目标不一致的客户，是关乎企业存亡的必要之举。如果缺乏一个具体且可证伪的论点来明确产品受众及其价值创造方式，创始人就难免会屈服于大型客户的“引力”，最终打造出一个无法扩展的“科学怪人”式产品。
这给我们的启示并非要避开大客户，而是要保持清醒，明确哪些问题才是自己该解决的。约束具有保护作用：通过过滤掉不匹配的潜在客户，初创公司可以优化其产品、信息传达和市场契合度。归根结底，拒绝错误的客户是接受正确客户的前提。企业的生存取决于是否拥有足够清晰的使命，以便在产品偏离过远时能够察觉，并有勇气及时纠正。
这条 Hacker News 帖子讨论了一篇题为《差点搞垮 Slack、Stripe 和 Airbnb 的客户》的病毒式文章，该文声称这些公司之所以成功，是因为它们抵制了来自大型企业客户的压力。
然而，讨论很快转向了一个关键的发现：这篇文章是所谓的“AI 垃圾内容”——由大语言模型在虚假作者充斥的网站上生成的、容易产生幻觉的通稿。原作者承认，他们制作这些内容是为了测试自动化文章的制作成本可以压多低，并最终为这种低质量的贡献表示道歉。
用户之间更广泛的讨论集中在两个主要议题上：
1. **“企业级”需求的陷阱：** 有经验的开发者们讨论了让早期大型客户左右产品路线图的风险。一些人认为，抵制此类需求对于保持产品的核心愿景至关重要；另一些人则认为，区分“有价值的设计合作伙伴”和“制造干扰的边缘需求者”是一项关键但困难的技能。
2. **AI 内容的泛滥：** 用户对“高速垃圾内容”的增加表示沮丧，并对过滤 AI 生成的内容感到困难——这些内容几乎没有提供任何见解，却污染了信息生态系统。
现代烘焙往往优先考虑科学的精确性，数字秤和高度优化的电子表格取代了传统的直觉依赖。尽管这种分析性的转变使烹饪变得更具可重复性和易学性，但也造就了一代因害怕偏离精确测量而变得畏手畏脚的厨师。
从历史上看，食谱都很简洁，默认厨师具备深厚的直觉经验。向标准化、经验主义烹饪的转变直到上个世纪才逐渐流行，这得益于家政运动和厨房的工业化。然而，这种对绝对掌控的追求只是一种错觉；厨房是一个生物环境，湿度和食材质量等变量在不断变化。
烹饪不是实验室实验，而是一种极其私人的感官体验。依靠“框架”而非死板的公式，可以让厨师适应各自独特的生活环境。通过摆脱对精确克数的执念，我们重新找回了烘焙的艺术性。正如作者在教母亲制作哈拉面包时所发现的那样，真正的烹饪自信源于相信自己的感官——感受面团、观察火候，并拥抱过程的灵活性。归根结底，食谱仅仅是一个起点；真正的魔法始于我们停止测量、开始感知的那一刻。
关于“追求完美面包的焦虑”，Hacker News 上的讨论探讨了科学烹饪的精确性与直觉式家庭烹饪之间的矛盾。
许多参与者认为，尽管食谱为商业环境下的可重复性提供了必要框架，但它们往往忽略了环境湿度、面粉质量和海拔等变量。推崇“凭感觉烹饪”的人认为，死板地遵循克数和比例可能是一种“徒劳”，并主张家庭烹饪的真正目标在于享受和调整，而非追求科学上的完美。
反之，另一方则捍卫精确性，认为它是确保一致性的工具，尤其对于没有导师的初学者而言。他们指出，质量测量和固定比例提供了一个可靠的基准，能有效避免浪费和挫败感。最终，共识倾向于一个折中方案：精确性是初学者的有效辅助，但经验丰富的厨师最终会转向直觉。这种演变使他们能够考虑到食材的“弹性”，将烹饪从一项刻板且令人焦虑的任务，转化为一种实验性和创造性的过程。
Persona 是一个基于 TypeScript/原生 JS 构建的可主题化、与框架无关的 AI 聊天小部件。它专为快速集成而设计，可为任何网站或产品提供即插即用的 UI，作为 React、Vue 或 Svelte 等现有技术栈的轻量级配套工具。
主要功能包括：
* **灵活部署：** 通过简单的配置或 `<script>` 标签支持浮动、停靠（侧边栏）和全屏布局。
* **后端无关：** 可连接到任何支持 SSE 的后端，并提供针对 Node、Bun、Deno 和 Cloudflare Workers 的适配器。
* **丰富功能：** 包含流式响应、多模态内容（图像/文档）、语音输入/输出、工具调用可视化、工件渲染和推理气泡。
* **高度可扩展：** 提供强大的插件系统，允许开发者无需分叉（fork）核心代码即可自定义 UI 层、解析器和组件逻辑。
* **开发者体验：** 内置对 WebMCP/页面工具、安全 API 代理和热重载开发环境的支持。
无论你需要一个简单的支持启动器还是功能齐全的 AI 工作区，Persona 都提供了一种声明式、低依赖的方式来构建能无缝集成到任何环境中的 AI 体验。
抱歉。
构建 PyTorch 训练循环看似简单，实则其操作顺序非常脆弱。如果代码行位置放错（例如在 `backward()` 之后调用 `zero_grad()`，或调度器位置不当），可能会导致静默失败、收敛缓慢或内存泄漏，且不会抛出任何异常。
**可靠训练循环的核心要素：**
* **数据流水线：** 使用 `DataLoader` 并设置 `pin_memory=True` 和 `num_workers > 0`，以防止 CPU 成为瓶颈。
* **模型初始化：** 务必在构建优化器*之前*将模型移至设备（GPU），以确保优化器正确引用模型参数。
* **训练与验证：** 使用 `model.train()` 和 `model.eval()` 来切换 Dropout 和 BatchNorm 等层。配合 `model.eval()` 使用 `torch.no_grad()`（或 `torch.inference_mode()`）来禁用计算图构建，从而减少内存占用。
* **循环过程：** 使用 `optimiser.zero_grad()` 清除梯度，进行前向传播，计算损失，执行 `backward()`，必要时进行梯度裁剪，最后调用 `optimiser.step()`。
* **日志记录：** 使用 `loss.item()` 提取数值，因为保留原始张量会导致整个计算图驻留在内存中。
可以通过 `torch.compile`、混合精度训练 (`autocast`) 和异步数据传输来提高效率。务必设置随机数种子以确保结果可复现。
OpenKnowledge 是一款基于本地优先、Markdown 的维基与编辑器。它结合了类似 Notion 或 Google Docs 的易用所见即所得界面，并深度集成了 Claude、Codex 和 Cursor 等大模型功能。该软件专为个人及团队设计，利用 Git 实现无缝协作与自动同步。 该平台提供 macOS 桌面应用程序，也可通过 CLI 在 Linux 和基于 Intel 的 Mac 上作为本地 Web 应用运行（需 Node.js 24+ 环境）。OpenKnowledge 是一个开源项目（采用 GPL-3.0 或更高版本协议），欢迎通过 Pull Request 贡献代码，提交的内容会自动同步至内部代码仓库以供审核。其模块化结构简化了开发与设置流程，并配有详尽的文档以帮助用户快速上手。
**OpenKnowledge** 是一款全新的开源、AI 优先的 Notion 和 Obsidian 替代产品。它提供了一个专为团队和高级个人用户设计的“所见即所得”（WYSIWYG）Markdown 编辑器。
**核心功能：**
* **智能体集成：** 内置模型上下文协议（MCP）服务器和技能，允许智能体（如 Claude、Codex、Cursor）查看、编辑并与本地 Markdown 文件交互。
* **协作功能：** 利用 Git/GitHub 进行版本控制和同步，在保持数据私密性的同时，实现“无代码”团队共享。
* **技术栈：** 基于 Tiptap、ProseMirror、CodeMirror 和 Yjs (CRDT) 构建，确保“所见即所得”编辑器与原始 Markdown 之间实现双向、无损同步。
* **灵活性：** 提供 macOS 应用、Web 界面以及面向终端用户（TUI）的命令行工具（CLI）。
**社区反馈：**
尽管用户称赞该项目旨在将 Notion 式的编辑体验引入本地 Markdown，但也有人对其“AI 优先”的品牌定位表示怀疑，指出 Obsidian 本身已经具备极高的 AI 兼容性。常见的改进建议包括：原生支持本地大模型、更好地兼容复杂的插件生态（如 Obsidian 的 Dataview）、以及提升跨平台性能。开发团队已对此做出回应，确认本地模型集成和更广泛的平台支持是其路线图中的重中之重。