最新

嗨，HN， 我一直在尝试让大型语言模型（LLMs）生成并持续修改小型商业应用程序（CRUD、仪表板、工作流）。第一次生成通常是有效的，但问题往往在第二次或第三次迭代时出现。 我看到的一些反复出现的失败模式包括： - 架构漂移，悄然破坏仪表板 - 指标在不同迭代中含义变化 - 用户界面组件以不兼容的方式查询数据 - 人工智能在局部修复某些内容时违反全局不变性 令人惊讶的是，大多数人工智能应用构建者将生成视为一次性问题，而实际应用是需要安全演变的长期系统。 我正在探索的方向是将应用程序视为运行时模型，而不是生成的代码： - 应用程序由结构化的、版本化的JSON/DSL（实体、关系、指标、工作流）定义 - 每个人工智能提出的更改在执行前都由后端进行验证 - 用户界面组件绑定到语义概念（指标、数据集），而不是原始查询 - 人工智能提出结构；运行时强制执行一致性 从概念上讲，这种方法更接近Kubernetes对基础设施的处理方式，或语义层在分析中的工作方式——但应用于完整的应用程序，而不仅仅是报告。 我很好奇： - 这里有没有人探索过类似的模式？ - 是否有成熟的方法来控制人工智能驱动的架构演变？ - 你认为语义层应该在应用程序运行时内部，还是应该仅限于分析？ 我并不是在推销什么——我真心想了解其他人如何看待人工智能与长期应用状态的结合。 谢谢。

Claude Cowork刚刚推出，将代理型人工智能带入日常工作中。Rowboat是一个开源替代方案，能够构建持久的知识。 这里有一个快速演示：<a href="https://youtu.be/T2Bmiy05FrI" rel="nofollow">https://youtu.be/T2Bmiy05FrI</a> 它可以连接到Gmail和会议记录（如Granola、Fireflies），并将这些信息整理成与Obsidian兼容的知识库。使用普通的Markdown文件，带有反向链接，围绕人、项目、组织和主题等内容进行组织。随着新邮件和会议的到来，相关的笔记会自动更新。 Rowboat也是这个知识库的主要界面。您可以直接阅读、浏览、编辑和添加笔记。它包括一个完整的Markdown编辑器和图形可视化功能，让您能够看到上下文如何在对话中积累。 为什么不直接搜索转录文本来获取所需信息呢？搜索只能回答您想到的问题。一个能够随着时间积累上下文的系统，可以跟踪决策、承诺和对话中的关系，揭示您未曾想到的模式。 一旦这些上下文存在，它就成为Rowboat可以利用的知识。因为它运行在您的机器上，所以可以直接处理本地文件，并执行Shell命令或脚本，包括在需要时使用ffmpeg等工具。 标题中的链接打开一个互动示例图，展示了上下文如何在邮件和会议中积累。我们使用了创始人的示例，因为它自然地包含了项目、人员和长期对话，但这种结构适用于任何角色。 使用Rowboat可以做的事情示例：从积累的上下文中起草电子邮件，通过汇总过去的决策并结合外部研究（例如通过Exa MCP）为会议做准备，随着工作的发展在您的机器上组织文件和项目文档，或通过像ElevenLabs这样的MCP服务器将笔记转化为语音简报。 我们对噪音有明确的看法。我们优先关注重复的联系人、活跃的项目和正在进行的工作，而忽略一次性的电子邮件和通知。我们的目标是建立长期有效的知识，随着时间的推移不断积累。 所有数据都以普通Markdown格式本地存储。您可以通过Ollama或LM Studio使用本地模型，或使用托管模型。采用Apache-2.0许可证。 GitHub: <a href="https://github.com/rowboatlabs/rowboat" rel="nofollow">https://github.com/rowboatlabs/rowboat</a> 我们很好奇这如何融入您当前的日常工作流程中。

Genie AI 是一款早期产品，利用人工智能生成社交媒体内容。我们专注于多帧帖子，如轮播和主题串，创建结构、节奏和品牌声音一致的内容，而非普通的输出。 这个职位涉及设计驱动文案生成的核心人工智能系统。它不是仅限于基础设施的角色，也不是仅限于提示的角色，更不是关于单行标题的工作。该工作涉及将说服力和人类判断转化为可扩展的人工智能系统。 该职位起初为兼职/咨询，适合合适的人选有明确的路径转为全职领导或首席技术官角色。 ## 职责 - 设计并构建多帧社交媒体文案的人工智能系统 - 实施管道、路由、约束和评估层 - 直接与大型语言模型（LLM）API（如 OpenAI、Anthropic 等）合作 - 诊断并修复人工智能输出在系统层面失败的原因 - 定义可交付输出的质量标准 - 随着系统的发展，与产品和战略团队合作 ## 我们寻找的人 - 有构建多帧社交媒体内容的人工智能系统的经验 - 能够在连续帖子中保持吸引点、节奏和叙事流 - 能通过系统设计提升输出质量，而不仅仅依赖提示 - 能够构建生产级系统 - 理解说服力、文案写作和人类判断，除了大型语言模型的机制 - 对结果和质量负责 ## 不适合的人 - 人工智能经验仅限于单行标题、博客或普通内容 - 只关注后端基础设施或开发运维 - 主要自我认同为提示工程师 - 在开始工作之前需要非常详细的规格 - 只对短期自由职业项目感兴趣 ## 技术要求 - 有生产软件经验 - 熟悉大型语言模型API - 有构建内部工具、产品或软件即服务（SaaS）的经验 - 能设计具有评估逻辑和反馈循环的模块化系统 ## 如何申请 提交一段简短的 Loom 视频，包括： - 你的背景 - 你为多帧或连续社交内容构建的人工智能系统 - 你与大型语言模型的经验 - 你的回答：<i>为什么大多数人工智能生成的文案感觉很普通，你会如何设计一个系统来解决这个问题？</i> 未附带 Loom 视频或相关系统示例的申请将不予考虑。

用反射等效替代方法调用和字段访问 → 使静态分析和反编译工具的效果大大降低。此功能为实验性，预计会有性能损失。

S2一年前在Hacker News上发布了我们的介绍博客文章（<a href="https://news.ycombinator.com/item?id=42480105">https://news.ycombinator.com/item?id=42480105</a>）。S2最初是一个无服务器API——可以把它想象成S3，但用于流数据。 流作为云存储原语的想法引起了很多人的共鸣，但缺乏开源选项成为了采用的一个障碍——尤其是对于那些本身就是开源项目的团队！因此，我们决定构建它：<a href="https://github.com/s2-streamstore/s2" rel="nofollow">https://github.com/s2-streamstore/s2</a>。 s2-lite采用MIT许可证，使用Rust编写，并使用SlateDB（<a href="https://slatedb.io" rel="nofollow">https://slatedb.io</a>）作为其存储引擎。SlateDB是一个基于对象存储的嵌入式LSM风格的键值数据库，这使得它非常适合提供与s2.dev相同的耐久性保证。 您可以指定一个桶和路径，以便在像AWS S3这样的对象存储上运行——或者完全跳过，直接在内存中运行。（这也使得它成为开发/测试环境的优秀模拟器）。 为什么不直接开放我们的云服务后端呢？s2.dev采用了一个解耦的架构，多个组件在Kubernetes中运行，包括我们自己的K8S操作员——我们在优化一个彻底的多租户云基础设施SaaS的操作时做出了权衡。通过s2-lite，我们的目标是推出一个操作简单的产品。两者之间有很多共享代码，现在都在开源代码库中。 一些功能仍然缺失（尤其是资源和记录的删除），但s2-lite已经基本准备就绪。请尝试在README中的快速入门，使用s2 CLI流式播放《星球大战》！ S2与Kafka或Redis Streams之间的主要区别在于支持大量的耐久流。我曾在关于代理会话的背景下撰写过相关博客（<a href="https://s2.dev/blog/agent-sessions#landscape">https://s2.dev/blog/agent-sessions#landscape</a>）。Kafka和NATS Jetstream将流视为预配置的资源，协议/实现围绕这种假设进行设计。Redis Streams和NATS允许更多的流，但没有适当的耐久性。 云服务是完全弹性的，但尽管lite是一个需要垂直扩展的单节点二进制文件，您仍然可以在很大程度上使用它。lite中的流在SlateDB中“仅仅是键”，而云对象存储是无底的——当然，元数据开销是不可避免的。 我很期待在s2-lite中改进写入的流水线处理以提升性能（已经在一个开关后面支持，但需要上游接口的更改以确保安全）。这是我们在s2.dev中广泛使用的一种技术。基本上，当您处理像S3这样的高延迟时，您希望在客户端和存储之间保持数据流动，而不是逐步进行，先等待确认再进行下一次写入。这就是为什么S2在无状态REST之外，还采用了基于HTTP/2的会话协议。 您可以使用`s2 bench` CLI命令自行测试lite的吞吐量/延迟。主要因素包括：您与存储桶区域之间的网络质量、远程存储的延迟特性、SlateDB的刷新间隔（`SL8_FLUSH_INTERVAL=..ms`），以及流水线处理是否启用（`S2LITE_PIPELINE=true`以体验未来）。 我会在这里收集想法和反馈，并回答任何问题！

我曾是他们平台上的企业客户。Cerebras开始频繁终止生产模型，并每隔几个月就更换一次。这次他们通知我们将终止Llama 3.3 70B，这是我所订阅的模型。 他们没有为我们提供替代计划，而是告诉我们其他所有计划都已售罄，并将我们踢出了他们的平台。 他们的Discord支持群里有多个企业客户都遭遇了相同的待遇。他们自己的支持人员告诉客户要迁移到Groq。 与一个如此频繁随机终止模型的公司建立稳定的业务是不可行的。这样一家公司不尊重客户（尤其是企业客户，而不仅仅是小型用户），如果决定停用你的模型，根本没有任何应急计划。 由于他们的架构限制，他们只能托管有限数量的模型。更新换代速度很快，因此如果你的模型被标记为弃用，你将被迫离开平台。 Cerebras适合个人爱好项目，但绝对没有能力向企业销售“企业”账户。