最新

嗨，Hacker News！我是David Huie。我正在推出SpeechOS，一个适用于网页应用的即插即用语音输入SDK。 我受到Wispr Flow的启发，希望在商业应用（如CRM、文档、表单、支持工具）中实现相同的工作流程，而不仅仅是一个独立工具。与打字相比，这为我节省了大量时间。 它的工作原理是：只需添加几行JS代码和一个API密钥，SpeechOS就会在每个文本框上显示一个小麦克风小部件。 实时演示： [https://www.speechos.ai](https://www.speechos.ai) （点击文本框，麦克风小部件就会出现；点击齿轮图标可以查看设置、自定义词汇和片段配置。） 用户可以： - 口述：自然说话，实时语音转化为精炼文本（标点符号，无填充/错别字） - 编辑：说“缩短一下”、“修正语法”、“翻译...” - 命令：定义类似Siri的应用操作（例如，“提交表单”、“标记完成”），我们会将意图与您的命令匹配 它还支持： - 自定义词汇：领域术语和名称（产品名称、缩略语、行话），以确保正确转录 - 文本片段：可通过语音插入的可重用文本块（例如，“我的签名”、“免责声明”、“我的地址”） 为什么：文本输入的速度和准确性仍然对生产力工具至关重要。一项包含37,370名参与者的大规模文本输入数据集显示，平均打字速度为36.2字/分钟，未更正错误率约为2.3%。在语音研究中，语音识别的速度约为键盘输入的3倍，且英语文本输入的错误率约低20.4%。（[https://hci.stanford.edu/research/speech/](https://hci.stanford.edu/research/speech/)） SpeechOS目前处于测试阶段，现阶段免费。请在 [https://app.speechos.ai/accounts/signup/](https://app.speechos.ai/accounts/signup/) 注册，并输入此HN专属测试代码：HN-JFc74cVC（请勿在HN外分享）。 链接： SDK仓库：[https://github.com/speechos-org/speechos-client](https://github.com/speechos-org/speechos-client) 演示：[https://www.speechos.ai](https://www.speechos.ai) 注册（代码：HN-JFc74cVC）：[https://app.speechos.ai/accounts/signup/](https://app.speechos.ai/accounts/signup/) 我希望能得到您的反馈： 1) 在您的技术栈中，这在哪些方面最有价值（笔记？文档？CRM录入？支持宏？） 2) 您希望从语音命令/片段配置中获得什么 3) 什么会让您放心使用这个产品（隐私/安全性、延迟、定价） 如果您在语音AI/口述方面有任何开发，我很乐意交换意见（david@speechos.ai）。

我注意到这种垃圾邮件方法的激增。 这感觉比普通邮件粗鲁了100倍——我理解这种新奇，但真是太让人反感了。

我为自己制作了这个工具，觉得它可能对其他人也有用。我非常希望能收到一些反馈，包括对威胁模型和工具本身的看法。希望你们觉得它有用！ 背景故事：在我开发一个相对雄心勃勃的金融分析工具时，我同时使用了许多代理。我在处理线性求解器的史诗任务、持久层、前端以及第二代求解器的规划时，忙得不可开交。面对权限提示时，我感到像是在玩打地鼠，快要崩溃了。YOLO模式看起来非常诱人，但我还是犹豫了。 然后我想到：如果YOLO模式其实并没有那么糟糕呢？决策疲劳确实存在。如果我能限制一个混乱代理的影响范围，也许我只需要审查一次。这不是更安全吗？ 于是那天，当我的孩子们在午睡时，我决定看看能否将YOLO模式的Claude放入一个沙盒中，以阻止数据外泄并限制git访问。结果就是yolo-cage。 另外：AI在系统的原型内部编写了自己的隔离系统。这要么是非常一致的，要么是非常元的，这取决于你如何看待它。

大家好，我是哈桑，Infracost 的联合创始人之一（<a href="https://www.infracost.io">https://www.infracost.io</a>）。Infracost 帮助工程师在合并代码之前查看并减少每次基础设施变更的云成本。 Infracost 的工作原理是我们从亚马逊网络服务、微软 Azure 和谷歌云收集定价数据。我们称之为“定价服务”，目前大约拥有 900 万个实时价格点 (!!)。然后，我们将这些价格映射到基础设施代码。一旦映射完成，就可以在 GitHub、GitLab 等平台上直接显示代码变更的成本影响。这有点像云基础设施的结账页面。 我们自 2020 年以来一直在开发（我们是 YC W21 批次的一部分），并不断迭代产品，组建团队等。然而，在 2020 年，一位用户问我们是否可以在显示成本的同时也展示碳影响。 自那时起，这个想法一直萦绕在我的脑海中。最大的挑战一直是碳数据。将碳数据映射到基础设施是耗时的，但由于我们已经处理了云成本，这也是可能的。但我们首先需要原始碳数据。过去几年的讨论最终让我找到了英国的一家公司，名为 Greenpixie。我们的几位现有客户已经在使用他们，因此我立即联系了创始人约翰。 Greenpixie 表示他们有数据（太好了！！）而且他们的数据经过验证（符合 ISO-14064 标准并与温室气体协议对齐）。我与他们的一些客户交谈后，便要求我的团队看看我们是否真的能做到这一点，并进行开发。 我的想法是：一些工程师会在意，而另一些则不会（或者可能有些人会喜欢，有些人则会讨厌！）。对于那些在意的人来说，成本和碳实际上是相关的；这意味着如果你减少碳排放，通常也会减少云的成本。这可以作为另一个激励因素。 现在，这个功能已经上线，我非常希望听到你们的反馈。请访问 <a href="https://dashboard.infracost.io/">https://dashboard.infracost.io/</a>，创建一个账户，设置 GitHub 应用或 GitLab 应用，并发送一个包含 Terraform 更改的拉取请求（你可以使用我们的示例 Terraform 文件）。它将显示成本影响和碳影响，以及如何进行优化。 我特别想听听你们的反馈，看看你们认为碳是否是你们团队中工程师的重要驱动力，或者碳是否是你们公司（即是否有自上而下的碳相关政策）的重要驱动力。 欢迎提问 - 我会关注这个讨论线程 :) 谢谢！

嗨，贾里德， 我正在与Miky一起申请YC春季批次，Miky是一家全栈的、以人工智能为核心的咨询公司。你关于全栈AI公司的帖子几乎完美地描述了我正在构建的内容。 Miky并不是销售给咨询师的软件——它本身就是一家咨询公司，配备了AI代理，旨在与传统公司直接竞争。Miky直接连接到企业数据源（如ERP系统、Databricks以及内部财务和运营数据集），构建一个持续更新的业务上下文图谱。在此基础上，Miky生成优先级推荐、绩效指标和具体实施计划——将原始数据转化为管理团队的具体行动、目标和价值创造倡议。该系统设定目标，跟踪执行，并在结果和条件变化时实时更新推荐，重点关注采购优化、利润扩展和收入增长等领域。 我最近在与凯尔尼的高级领导层合作时，内部开发并试点了Miky，以探索这一模型是否可以在传统咨询公司内部运作。结论是，虽然凯尔尼认为这种以AI为核心的模型可以非常成功并吸引大量客户，但AI原生咨询业务与传统咨询模型在同一屋檐下共存是非常困难的。因此，该公司选择不在内部推进这一项目。这为Miky的外部推出创造了强大的机会，鉴于这个概念和知识产权是我的，我现在正在独立构建它。 从我的背景来看，我曾作为创始人/运营者从零开始构建并扩展了一个大型消费互联网平台，达到了全球规模。在过去十年中，我作为高级战略顾问为首席执行官、董事会和私募股权基金提供咨询。Miky正好位于软件、数据和服务的交汇点。 我已经与包括AB InBev、Belcorp、Mars、KKR等潜在客户就Miky在实际运营环境中的实施进行了深入交谈，这有助于塑造产品和初步用例。 我作为单独创始人申请。虽然我目前没有CTO联合创始人，但我有明确的技术路线图，并且正在积极构建和招募。我相信这是一个创始人与市场契合的问题，在这个问题上，速度、洞察力和领域专业知识比初始团队规模更为重要。 感谢你的阅读——我期待有机会进一步讨论。 最好的祝愿，胡安

一种常见的方法来自动化亚马逊购物或类似复杂网站的操作是使用大型云模型（通常具备视觉能力）。我想测试一个矛盾：一个约30亿参数的本地大语言模型（LLM）能否仅通过结构化页面数据（DOM）和确定性断言来完成流程。 这篇文章总结了四次相同任务的运行（搜索 → 第一个产品 → 添加到购物车 → 在亚马逊上结账）。关键比较是演示0（云基线）与演示3（本地自主）；演示1和2是中间控制。 更多技术细节（架构、代码片段、额外日志片段）： https://www.sentienceapi.com/blog/verification-layer-amazon-case-study 演示0与演示3： 演示0（云，GLM-4.6 + 结构化快照） - 成功：1/1 次运行 - 令牌数：19,956（相比于约35k估算减少了约43%） - 时间：约60,000毫秒 - 成本：云API（变化不定） - 视觉：不需要 演示3（本地，DeepSeek R1 规划器 + Qwen ~30亿执行器） - 成功：7/7 步骤（重新运行） - 令牌数：11,114 - 时间：405,740毫秒 - 成本：$0.00 增量（本地推理） - 视觉：不需要 延迟说明：本地堆栈的端到端速度较慢，主要是因为推理在本地硬件（配备M4的Mac Studio）上运行；云基线受益于托管推理，但每个令牌有API成本。 架构 之所以成功，是因为我们改变了控制平面并添加了验证循环。 1) 限制模型看到的内容（DOM修剪）。 我们不提供整个DOM或截图。我们收集原始元素，然后运行WASM处理以生成紧凑的“语义快照”（角色/文本/几何），并修剪其余部分（通常约95%的节点）。 2) 将推理与执行分开（规划者与执行者）。 - 规划者（推理）：DeepSeek R1（本地）生成步骤意图和后续必须为真的条件。 - 执行者（行动）：Qwen ~30亿（本地）选择具体的DOM操作，如CLICK(id) / TYPE(text)。 3) 用Jest风格的验证控制每一步。 在每个动作后，我们断言状态变化（URL变化、元素存在/不存在、模态框/抽屉出现）。如果所需的断言失败，该步骤将失败，并带有伪影和有限的重试。 最小形状： ```python ok = await runtime.check( exists("role=textbox"), label="search_box_visible", required=True, ).eventually(timeout_s=10.0, poll_s=0.25, max_snapshot_attempts=3) ``` “看起来聪明的代理”和真正有效的代理之间的区别 日志中的两个示例： - 确定性覆盖以强制执行“第一个结果”意图：“执行者决策… [覆盖] first_product_link -> CLICK(1022)” - 抽屉处理验证并强制正确分支：“结果：通过 | add_to_cart_verified_after_drawer” 重要的是，这些不是事后分析，而是内联门控：系统要么证明它取得了进展，要么停止并恢复。 结论 如果你想让浏览器代理更可靠，最高效的措施不是使用更大的模型，而是限制状态空间，并通过逐步断言明确成功/失败。 代理的可靠性来自于验证（对结构化快照的断言），而不仅仅是模型规模的扩大。

简而言之：提议的FAA（联邦航空局）变更要求考官在测试之前，必须在您所使用的飞机型号上至少有五小时的飞行时间。由于存在数百种略有不同的型号变体（例如Cessna 172P与172R），大多数考官无法满足每架飞机所需的特定飞行小时数。这实际上使大多数本地考官失去资格，造成巨大的积压，使得几乎不可能找到合法允许进行飞行检查的考官。 FAA已发布对FAA命令8000.95D Chg 1的提议变更，这些变更直接影响指定飞行考官（DPEs）的操作方式以及飞行学校安排和进行实际测试的方式。提交意见的截止日期即将到来——1月23日星期五晚上11:59。请在这些提议变更成为最终政策之前，审阅并提供反馈。 如果您按照本消息末尾的说明和链接操作，提交意见将非常快速和简单。 提议变更的关键摘要 FAA命令8000.9D Chg 1 对DPE进行飞行教员考试的限制：这些变更将限制DPE进行飞行教员实际测试的能力。这一限制可能会显著减少考官的灵活性和可用性，特别是对高流量飞行学校的影响。相关内容见第3卷，第5章，第2节，H段，第（3）和（15）项。 新的PIC（机长）时间要求：考官在进行单发飞机的检查飞行之前，必须在每种型号上至少有五小时的机长飞行时间。此要求可能会限制可用考官的数量，并可能导致排期延误。相关内容见第3卷，第1章，第2节，表3-3。 收费规定：提议的变更将禁止DPE在申请人资格在预考简报中确定之前收取任何费用。这可能会给考官和飞行学校带来行政负担，可能会使排期和支付过程变得复杂。相关内容见第3卷，第5章，第2节，C段，第（7）和（8）项。 请在此处查看FAA命令8000.95D Chg 1提议变更的完整文本： https://www.faa.gov/aircraft/draft_docs/orders

嗨，HN， 大多数生产力工具假设你已经知道该做什么。但我总是在这个阶段之前卡住。 Everpath 是一个将目标规划为路径和路线图的实验，而不是任务列表。你从用自然语言写下的目标开始，它会生成一个你可以不断迭代的路线图： - 通过与之对话来重塑它（“让这个慢一点”，“关注基础”） - 在执行时将其视为一个看板 - 在安排时间时将其视为日历 - 使用一种讨论模式，对不切实际的计划进行反驳 这并不是要取代自律或努力，而是为了让开始变得不那么费脑。 我很好奇哪些内容引起共鸣，哪些没有。

嗨，HN，我正在尝试一个名为PicoFlow的小型Python库，用于构建使用轻量级DSL的LLM代理工作流。 我一直在使用像LangChain和CrewAI这样的工具，想探索一种更简单、更面向功能的方式来组合代理逻辑，更接近于普通的Python控制流和异步函数。 PicoFlow的重点在于： - 使用操作符组合异步函数 - 核心功能最小，学习概念较少 - 通过共享上下文实现明确的数据流 - 易于嵌入现有服务 一个典型的工作流如下所示： ``` flow = plan >> retrieve >> answer await flow(ctx) ``` 像循环和分支/合并这样的模式也被表示为操作符，而不是单独的图形或配置层。 这仍然处于早期阶段，且非常具有学习性质。我非常欢迎对DSL设计、缺失的基本元素，或这种风格是否对实际代理工作负载有用的任何反馈。 仓库链接：https://github.com/the-picoflow/picoflow

嘿，HN！我是法比奥，我创建了UltraContext，这是一个简单的上下文API，专为AI代理提供自动版本控制。 在过去两年中，我在生产环境中构建AI代理，亲身体验到在大规模管理上下文时的挫败感。存储消息、迭代系统提示、调试行为和多代理模式——在这一切过程中，还要确保不出错，真是让我抓狂。 所以我构建了UltraContext。它的思维模型类似于git用于上下文管理： - 更新和删除会自动创建版本（历史记录永不丢失） - 可以在任何时刻重放状态 这个API有5个方法： ```javascript uc.create() // 创建新上下文（可以从现有上下文分叉） uc.append() // 添加消息 uc.get() // 按版本、时间戳或索引检索 uc.update() // 编辑消息 → 创建版本 uc.delete() // 删除消息 → 创建版本 ``` 消息是无模式的。可以存储对话历史、工具调用、系统提示——无论你需要什么格式。可以直接将其传递给你选择的任何框架中的大型语言模型（LLM）。 它的用途包括： - 在会话之间持久化对话状态 - 调试代理行为（回溯到决策点） - 分叉上下文以测试不同的流程 - 无需构建审计基础设施即可实现审计跟踪 - 多代理和子代理模式 它不是什么： - 不是内存/RAG系统（没有语义搜索） - 不是向量数据库 - 不是编排/LLM框架 UltraContext处理版本控制、分支和历史记录。你只需一行代码即可实现时间旅行。 文档： [https://ultracontext.ai/docs](https://ultracontext.ai/docs) 提前访问： [https://ultracontext.ai](https://ultracontext.ai) 非常希望得到反馈！尤其是来自那些自己构建过上下文工程的人，想知道我遗漏了什么。