最新

我最近一直在开发 <a href="https://synthchat.netlify.app" rel="nofollow">https://synthchat.netlify.app</a>。这是一个技术交流平台，人们可以在这里分享想法、交流观点，并就工程技术问题进行讨论，而不会受到社交媒体带来的干扰。我希望这个平台的界面简洁、直观，并且整体使用起来非常简单。 我创建这个平台是因为我感觉大多数平台都将技术内容与噪音、算法和吸引眼球的内容混在一起，这使得真正的讨论变得比它应该的更难。有时候，你只是想有一个干净的空间来思考、提问，并与其他工程师交流想法。我希望 Synth Chat 能为人们提供一个以对话为核心的场所——没有严厉的审核和尖酸刻薄的回复（咳咳，Stack Overflow）。我很好奇哪些功能能让这个应用更上一层楼，并促进围绕发人深省的想法的讨论。如果你有任何建议，请告诉我。

我年轻的时候读过理查德·费曼的《别闹了，费曼先生！》、威廉·吉布森的《神经漫游者》和保罗·哈尔莫斯的《你想要成为一名数学家吗？》。 如今，哪些书在年轻的、有技术头脑的人群中很受欢迎？

Hi HN， 总结：我们开发了一个效果很好的 bug 查找工具，尤其适用于应用程序后端。 欢迎试用并告诉我们您的想法！ 以下是详细内容。 -------------------------- 我们最初的目标是解决技术债务问题。我们都见过存在大量技术债务的代码库，所以对这个问题深有感触，而且人工智能似乎让情况变得更糟。 技术债务似乎也是一个非常适合人工智能解决的问题，因为：1）一小部分工作需要思考和策略，而大部分执行工作都相当机械化，2）当你解决技术债务时，你通常试图保留现有的行为，只是改变实现方式。这意味着如果你能找到好的方法来检测由于代码更改导致意外行为变化，你就可以把它当作一个闭环问题来处理。而我们知道该怎么做——这就是测试的目的！ 所以我们从编写测试开始。测试创建了安全保障，使未来的代码更改更安全。我们的想法是：如果我们能很好地进行测试，我们就能以非常高的质量自动化许多其他技术债务工作。 我们构建了一个代理，可以为典型的代码库编写数千个新测试，其中大部分都达到了“合并质量”。一些早期用户合并了数百个通过这种方式生成的 PR，但从直觉上来说，这个工具总是感觉“不错，但不够好”。我们自己也偶尔使用它，但通常感觉像一项苦差事。 大约在这个时候，我们意识到：虽然我们最初的目标是编写好的测试，但我们构建了一个系统，稍作调整后，可能非常擅长查找 bug。当我们在一​​些朋友的代码库上测试它时，我们发现几乎每个代码库都隐藏着大量 bug，我们能够标记出来。都是严重的 bug，而且足够有趣，让人们放下手头的工作来修复它们。这些 bug 就存在于人们的代码库中，已经被合并，并在生产环境中运行。 我们还发现了许多漏洞，即使在成熟的代码库中也是如此，有时甚至是在某人进行渗透测试之后。 底层原理： * 我们检出代码库，并弄清楚如何为本地开发构建它，并用测试来运行它。 * 我们拍摄构建的本地开发状态的快照。（我们为此使用了 Runloop，并且非常喜欢它。） * 我们启动数百个本地开发环境的副本，以数千种方式运行代码库，并标记看起来有问题的行为。 * 我们选择最突出、最令人担忧的示例，并将它们作为线性工单、github 问题或电子邮件发送。 在实践中，它运行得非常好。我们已经能够在从编译器到交易平台（甚至在 rust 代码中）的各种地方找到 bug，但最佳应用是应用程序后端。 我们的方法是用计算换取质量。我们的代码库扫描需要数小时，这远远超出了代码审查机器人的实用范围。但结果是，我们可以更明智地利用工程师的注意力，我们认为这将是最重要的变量。 从长远来看，我们认为计算是廉价的，而工程师的注意力是昂贵的。如果运用得当，最新的模型可以在大型代码库中执行复杂的更改。这意味着构建软件的限制因素是人类的注意力。工程师仍然需要时间和专注来摄取信息，例如现有代码、组织背景和产品需求。在工程师能够明确表达他们想要什么并出色地审查结果差异之前，所有这些都是必要的。 目前，我们正在查找 bug，但我们正在开发的技术可以扩展到许多其他后台、半主动的工作，以改进代码库。 欢迎试用并告诉我们您的想法。 首次扫描免费，无需信用卡：[https://detail.dev/](https://detail.dev/) 我们也在扫描 OSS 存储库，如果您有任何请求，请告诉我们。该系统的信号噪声比很高，但我们不想冒着通过自动打开问题来惹恼维护者的风险，因此如果您请求扫描 OSS 存储库，结果将发送给您个人。[https://detail.dev/oss](https://detail.dev/oss)

大家好，我是 <a href="https://replay.io" rel="nofollow">https://replay.io</a> 的 CEO。我们一直在致力于 Web 开发的时间旅行调试 (<a href="https://news.ycombinator.com/item?id=28539247">https://news.ycombinator.com/item?id=28539247</a>)，最近我们还开发了一个 AI 应用构建器，它利用这个调试器来解决问题，而不是原地打转 (<a href="https://news.ycombinator.com/item?id=43258585">https://news.ycombinator.com/item?id=43258585</a>)。 我们已经能够相当轻松地构建应用来替代关键业务 SaaS 工具，其中一些我们现在正在内部使用： * 我们构建了自己的问题追踪器来跟踪所有开发项目、工单、错误修复等，完全取代了 Linear。 * 我们构建了一个知识库来管理内部文档和正在进行的项目状态，完全取代了 Notion。 * 我们构建了一个遥测系统，通过 Webhook 接收 OTLP 事件，并支持自定义图表和可视化，主要取代了 Honeycomb。 我们希望尽可能多地控制我们运行 Replay 所需的应用。我们可以根据自己的需求定制这些应用，完全拥有它们及其数据，并避免 SaaS 供应商的恶意行为，例如按席位定价、付费墙功能、将我们锁定在其平台中以及阻止我们访问自己的数据。 今天，我们推出了 Builder (<a href="https://builder.replay.io/" rel="nofollow">https://builder.replay.io/</a>)，这是我们用来构建这些应用的工具，以及我们构建的这些应用和其他应用。您可以免费复制这些应用，下载源代码并自行托管它们，或者让我们来负责托管、修复错误并根据您的需求进行修改。 如果您只想试用一下，这里有几个（共享，无需登录）这些应用的副本： * 问题追踪器：<a href="https://16857470-551d-4f50-8e5b-b7d24a4a874a.http.replay.io" rel="nofollow">https://16857470-551d-4f50-8e5b-b7d24a4a874a.http.replay.io</a> * 知识库：<a href="https://d7e0dff4-f45c-4677-9560-6ea739c00a94.http.replay.io" rel="nofollow">https://d7e0dff4-f45c-4677-9560-6ea739c00a94.http.replay.io</a> 我们对 AI 应用构建器加速软件开发、释放非开发人员的创造力，尤其是帮助削弱许多大公司对我们的控制充满期待。我们自己也在不断构建新的应用来帮助实现这一目标，所以请告诉我们您的想法！哪些应用和供应商最让您感到沮丧？

Hi HN， 我构建了Presently (<a href="https:&#x2F;&#x2F;presently.us" rel="nofollow">https:&#x2F;&#x2F;presently.us</a>)，因为我厌倦了用混乱的Excel表格来管理我的节日购物。我试过的每一个“礼物追踪器”应用都充斥着广告，需要繁琐的注册，或者只是想向我推销东西。 我想要一个简洁、快速，并且专注于送礼物流的应用：我要为谁购买，状态是什么（想法 -&gt; 已购买 -&gt; 已包装），以及我花了多少钱？ 主要功能： - 视觉状态看板：一目了然地看到谁还需要礼物，以及什么需要购买/包装/赠送。 - 预算管理：自动汇总您的支出，并与您的预算进行对比。 - 移动友好：在您实际在商店时，在浏览器中也能流畅运行（类似PWA体验）。 - 无摩擦分享：与家人/朋友分享愿望清单，无需他们创建账户。 - AI头脑风暴：集成了Gemini，根据兴趣和关系生成礼物创意，当您完全卡住时可以使用。 技术栈：使用Firebase、React和Tailwind构建，托管在GCP上。我非常注重流畅的UI和较低的认知负担（谁在买礼物的时候还需要更多压力呢？）。 我很想听听您对用户体验流程的反馈。它是否比您当前的系统更快？ 谢谢，Al

大家好，我是 Juan，前 NetApp 的可靠性工程师，曾为财富 500 强客户每月处理 60 多起关键事件。 我构建了 ARF，因为我反复看到了同样的模式：生产 AI 系统默默地失败，人们凌晨 3 点醒来，需要 30-60 分钟才能恢复，而公司每次事件损失 5 万到 25 万美元。 ARF 使用 3 个专门的 AI 智能体： * 侦探：通过 FAISS 向量记忆进行异常检测 * 诊断师：使用因果推理进行根本原因分析 * 预测：在故障发生前进行预测 结果：平均修复时间（MTTR）为 2 分钟（而手动修复为 45 分钟），收入恢复 15-30%。 技术栈：Python 3.12、FAISS、SentenceTransformers、Gradio 测试：158 个测试中通过 157 个（覆盖率 99.4%） 文档：8 个综合文件，共 42,000 字 实时演示：[https://huggingface.co/spaces/petter2025/agentic-reliability-framework](https://huggingface.co/spaces/petter2025/agentic-reliability-framework) 一个有趣的技术挑战是让智能体在没有紧密耦合的情况下进行协调。每个智能体都可以独立测试，但为了进行整体分析，它们会被编排在一起。 很乐意回答关于多智能体系统、生产可靠性模式或用于事件召回的 FAISS 的问题！ GitHub：[https://github.com/petterjuan/agentic-reliability-framework](https://github.com/petterjuan/agentic-reliability-framework) （如果您需要在您的基础设施中部署此系统，也可提供咨询服务：[https://lgcylabs.vercel.app/](https://lgcylabs.vercel.app/)）

Construct 是一款开源的 AI 编程助手，它以 gRPC 服务的形式运行，而不仅仅是一个 CLI 工具。你可以在笔记本电脑上本地运行它，也可以在远程服务器上运行，连接多个客户端，断开和重新连接而不会丢失上下文，并且可以轻松地将其集成到其他工具中。我想要一个可以一直运行，随时可以回来使用的工具，并且易于在沙盒中运行。 与使用 JSON 模式不同，代理使用 JavaScript 与工具交互。这意味着它们可以使用循环、条件语句、错误处理，并且鼓励它们在一轮中执行多次调用（如果需要，可以在一轮中执行数百次）。如果你想看看它的样子，README 中有一个视频。这种方法受到了 CodeAct 论文（<a href="https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2402.01030" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2402.01030</a>）的启发，该论文发现代理在使用代码而不是 JSON 调用工具时表现更好。我在这里更详细地解释了好处：<a href="https:&#x2F;&#x2F;github.com&#x2F;Furisto&#x2F;construct&#x2F;blob&#x2F;main&#x2F;docs&#x2F;tool_calling.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Furisto&#x2F;construct&#x2F;blob&#x2F;main&#x2F;docs&#x2F;tool_cal...</a> 它内置了用于不同任务（规划/实施/优化）的代理，或者你可以使用自定义提示和模型分配来创建自己的代理。它是一个单一的 Go 二进制文件，不需要 npm 或类似的东西。目前支持 Anthropic，很快将支持其他提供商。 很乐意回答有关架构或工具调用方法的问题。

我花了 20 年时间构建身份和安全系统（EA、Nexon IPO，两项加密身份验证专利）。去年开始构建多智能体管道，遇到了一个问题：当出现故障时，无法知道哪个智能体产生了什么结果。 MOSS 为智能体提供加密身份并签署其输出。每个签名都包含 ML-DSA-44（后量子，FIPS 204）、用于重放检测的序列号和 SHA-256 负载哈希。 ```python pip install moss-sdk from moss import Subject agent = Subject.create("moss:myapp:agent-1") envelope = agent.sign({"action": "approve", "amount": 500}) ``` 密钥存储在本地的 ~/.moss/keys/ 目录下。没有云端，没有账户。 框架集成：moss-crewai, moss-autogen, moss-langgraph, moss-langchain 选择后量子的原因：审计日志需要保持可验证性多年。出于这个原因，选择了 ML-DSA-44 而不是 Ed25519。 规范：[https://github.com/mosscomputing/moss/blob/main/SPEC.md](https://github.com/mosscomputing/moss/blob/main/SPEC.md) 网站：[https://mosscomputing.com](https://mosscomputing.com) 很乐意回答有关设计的任何问题。

使用 ThinkMoon，你可以构建自己的 Alpha 竞技场：插入来自 OpenRouter、OpenAI、Anthropic（或我们定制的）的模型，向它们提供实时数据（K线图、订单簿、行情），然后让它们交易真实的加密货币（通过币安期货）。 你可以定义规则：风险限额、交易哪些币种（BTC、ETH、SOL、XRP… 随意），甚至混合使用不同的 LLM 并比较它们的表现。 AI 的每一次操作都会被记录——完整的提示、推理、市场快照——这样你就可以审计或从中学习。 有一个实时仪表盘，显示盈亏、持仓情况和 AI 的思维链。通过 Telegram 或 Slack 警报，在交易发生时通知你。 此外，还有止损、止盈、仓位限制，以及当回撤过大时的紧急停机开关。 我们目前正在测试微调模型，如 DeepSeek 3.2 Speciale 和 Grok 4.1——早期结果看起来很有希望，表现比通用模型更稳定。 很想听听你希望 AI 交易助手具备哪些功能。 （LLM 编排和逻辑框架：LangChain）