最新

我在几条评论中提到过这个问题，但想要展开一个更大的讨论。 有些观点认为，使用大型语言模型（LLMs）来编写代码只是我们作为工程师所使用的一种新的高级语言。然而，这在代码审查时会导致一种脱节，因为被审查的代码是生成该代码过程的产物。如果我们现在通过自然语言（提示、规划、编写，作为新的“编程语言”）来表达自己，但只将生成的产物（实际代码）提交审查，那么我们如何才能全面审查它呢？ 我最近感到有些困惑，似乎缺少了关于如何产生这些变化的上下文，包括计划、提示等，以理解工程师是如何得出这个具体代码变更的。他们是一次性完成的，还是花了几个小时进行提示、迭代等？或者是介于两者之间的情况？ PR中的总结通常说明了变化是什么，但并不包含完整的对话或我们是如何得出这个具体变化的（权衡、替代方案等）。 在你们的组织中，如何进行PR审查？你们是否制定了任何规则、自动化流程等？

该项目仍处于 alpha 阶段，但已经存在其他更成熟的替代方案，例如 Tunic：<p><a href="https://github.com/mikeslattery/tunic" rel="nofollow">https://github.com/mikeslattery/tunic</a>

我在寻找高质量讨论时感到沮丧，因此开始了这个项目，以更好地理解这个社区的运作方式。 这促使我构建了 readhn，这是一个 MCP 服务器，旨在帮助实现三件事： - 发现：通过关键词、评分和时间窗口找到相关的故事/评论 - 信任：使用类似 EigenTrust 的传播方法，从种子专家那里识别可信的声音 - 理解：展示每个结果的排名原因，提供明确的信号，而不是黑箱评分 它包含六个工具：discover_stories、search、find_experts、expert_brief、story_brief 和 thread_analysis。 我还添加了 readhn setup，以便 AI 代理（如 Claude Code、Codex、Cursor 等）在 pip install 后可以自动配置。 我希望能收到以下方面的反馈： 1) 这些排名信号是否与您评估 HN 质量的方式相匹配， 2) 信任模型的权衡， 3) 什么会使这个工具在您的日常工作流程中更有用。 如果您觉得这对您有帮助，给这个仓库加星可以帮助其他人发现它： [https://github.com/xodn348/readhn](https://github.com/xodn348/readhn)

我一直在思考一个关于在大型语言模型（LLMs）时代的著作权的哲学和伦理问题，我很好奇HN社区是如何划定界限的。 假设你花了几个月深入研究一个小众话题。你做出了自己的发现，整理了自己的见解，并将所有这些精心策划、非常具体的背景信息输入到一个LLM中。你实际上是在构建一个定制的知识库，并根据你自己的思维框架训练模型。 当你最终想写一篇帖子或评论来分享你的发现时，你概述了自己的具体想法，并利用这个经过精心准备的LLM来构建和生成最终的文本。 我想问你几个问题： 1. 在没有“AI生成”免责声明的情况下发布这些内容是否不道德？ 2. 实际上展示的知识是谁的？LLM生成的是语法，但语义、见解和深层背景信息都是100%人类来源的。 这与使用代笔、编辑或高度先进的编译器根本上有何不同？如果我在进行背景工程和知识发现的重任，限制自己不利用LLM来构建最终输出似乎有些不合理。然而，互联网仍然普遍将任何AI生成的文本视为本质上“非人类”或低投入的。 人类的见解在哪里结束，AI的生成又从何开始？如果核心思想是你的，那么文本的媒介真的就是信息吗？

访问 chrome:&#x2F;&#x2F;flags&#x2F;#vertical-tabs，然后右键点击你的标签栏，选择“将标签移动到左侧”。

最近在HN上有不少关于伊朗互联网被封锁和Starlink信号被干扰的文章。我想了解一下目前Starlink和其他卫星互联网服务提供商的情况如何。

嗨，HN， 我正在开发 Mumpix，这是一个以本地为先的基础设施栈，用于构建不依赖于集中式云平台的 AI 系统。 我们的目标是让 AI 的记忆、状态和基础设施能够在任何地方运行：手机、浏览器、桌面、服务器或边缘设备。 该栈目前有四个层次： **MumpixDB** 一个为 AI 记忆和应用状态设计的结构化层次数据库。 键的示例： - memory^assistant^context - memory^assistant^recent - workflow^task^42^status **特点：** - 层次化键模型 - 前缀扫描 - 状态变化的观察者 - 确定性快照 - 链接解析 - 基于生成的同步 --- **MumpixFS** 一个文件基础层，旨在与记忆层集成。 处理文件、别名和版本引用。 示例： - files^alias^report - files^versions^report^latest --- **MumpixSL** 系统级运行时和守护进程（mumpixd），通过以下传输方式将栈作为共享基础设施暴露： - Unix 套接字 - REST - WebSocket - D-Bus - Binder（Android） 这使得多个应用程序可以共享一个内存系统。 --- **MumpixFE** 前端运行时，直接在浏览器中运行 MumpixDB，允许相同的记忆模型在客户端工作。 --- **为什么会有这个项目** 目前，大多数 AI 系统严重依赖集中式 API 和基础设施。 这在模型推理方面效果很好，但记忆和应用状态不一定需要存储在云端。 如今，许多代理系统将状态存储在： - 提示 - 向量数据库 - 临时 JSON 数据块 MumpixDB 是一个尝试，旨在构建一个应用程序和代理可以依赖的确定性结构化记忆层。 --- **10 亿美元基础设施资助** 为了鼓励采用，我们还将推出 Mumpix AI 基础设施资助。 我们的想法是逐步分配价值 10 亿美元的基础设施和开发资源给构建以下项目的团队： - AI 代理 - 本地优先的 AI 应用 - 边缘 AI 系统 - 保护隐私的 AI 工具 基础平台将保持免费供开发使用。 --- **欢迎反馈** 这仍处于早期阶段，我希望能从 HN 社区获得关于以下方面的反馈： - 层次化键模型 - 守护进程与进程内使用 - 浏览器运行时（MumpixFE） - AI 代理的集成模式 欢迎提出问题。