最新

几个月前，我们在这里发布了内容，并收到了很多有见地的反馈。根据这些反馈，我们进行了以下改进。 MoneyOnFIRE 解答了两个问题：你何时可以实现财务独立，以及你应该做些什么才能最快达到这个目标？它通过对收入、税收、账户、贡献、收益和提款进行财务模拟，生成一个优先级行动清单，其中包含具体的金额、日期和步骤。 一些最大的改进直接来源于上一个 HN 讨论串的评论： - 租赁物业支持：现在系统可以模拟租金收入、抵押贷款、房产增值以及这些物业如何与财务计划的其他部分相互作用。 - 情景建模：你现在可以并排比较不同选择（如较低的收益、延长工作时间、调整支出）对财务独立时间线的影响。 - 无需登录：有些人不想创建账户或存储财务数据。现在你可以在不注册的情况下运行完整的计划。 - 财务独立与财务独立退休（FI vs FIRE）：我们最初是为早期退休人群构建的。反馈显示，这对任何追求长期财务独立的人同样有用——计算和行动是一样的。 此外，我们还推出了：支持多个孩子和大学时间线、罗斯转换梯度、IRA 策略选择、综合和定期人寿保险的规模，以及随着输入变化而动态更新的报告。 核心论点没有改变：个人财务是一个复杂的相互作用规则和计算的网络。我们希望解决这个问题，并为每个人提供一套清晰、有序的可实施行动方案。 欢迎提出关于引擎或其背后建模决策的问题。

我身边的人开始重复他们在TikTok或其他社交媒体上看到的各种心理战宣传内容。<p>尤其是在波罗的海国家，这里几乎是24小时不间断的恐慌宣传，无论是俄罗斯通过当地人或社交媒体进行的针对性虚假信息活动，还是一些博主为了吸引点击而追逐热点的帖子，这让我感到非常烦躁。当我身边的人被这些帖子吸引时，我不得不花时间解释为什么这些内容毫无意义，这让我感到分心和恼火。<p>于是我动手制作了一个仪表板，经过一些手动调整，使用了我的“垃圾机器”。主要指标是一个每日的0-100威胁评分，这只是加权总和和阈值的计算——目前还没有使用机器学习。

这个仓库是关于如果人类不再是主要编程者，什么样的编程语言可能合适的讨论结果。最初的想法是“大型语言模型（LLMs）可以直接生成二进制文件”（这在某位更著名的人提出相同想法之前）。但经过反思，这似乎是一个不好的方法，因为编程语言的存在是为了捕捉被翻译成机器代码时省略的程序语义。接下来的思考是，是否可以使用现有的“机器可读”程序表示作为大型语言模型代码生成的目标。结果证明是可以的。这个项目的成果是请求Claude创建一个完全用LLVM的中间表示语言编码的应用程序栈。

Native Desktop 是一个工具包，旨在使用现代网页技术构建本地桌面应用程序，而无需处理桌面工具的复杂性。它专注于提供简单的开发体验，让开发者能够使用熟悉的工作流程和模块化的包生态系统来搭建、构建和分发桌面应用程序。Native Desktop 不强迫开发者管理复杂的本地环境，而是提供一个命令行界面（CLI）和一组处理繁重工作的包，从而保持项目的灵活性和可维护性。其目标是让开发者能够快速将创意转化为可工作的桌面应用程序，同时仍然对架构和分发保持完全控制。该项目专为那些已经使用现代网页技术栈进行开发的开发者设计，旨在为他们提供一种简单的方法，将这些应用程序转变为桌面软件，而无需重新发明整个工具链。

嘿，HN——我注意到开发者们常常表达同样的沮丧：在调试CI管道时，经历提交-推送-等待-查看日志的循环。因此，我构建了PipeStep。 PipeStep解析你的GitHub Actions YAML，启动合适的Docker容器，并为你的运行提供逐步调试器：Shell命令。你可以： - 在每一步之前暂停并检查容器状态 - 在管道运行中进入正在运行的容器（按I键） - 在特定步骤上设置断点（按B键） - 重试失败的步骤或跳过其他步骤 它故意不尝试复制完整的GitHub Actions运行环境——没有秘密、没有矩阵构建、没有使用：动作执行。对于完整的本地工作流运行，请使用act。PipeStep是当事情出错时，你需要找出原因，而不必再推送10个提交。可以把它看作是你的CI管道的gdb，而不是本地的GitHub运行器。 pip install pipestep (v0.1.2) · Python 3.11+ · MIT · 需要Docker 非常希望能收到反馈，特别是来自那些遇到相同痛点的人。已知的限制在README中有记录，并且里面有一些问题我希望能得到关注！

嗨，HN，我是Robel。我创建LogClaw是因为我厌倦了为Datadog付费，却仍然收到“出现问题”的通知，而没有任何上下文信息。 LogClaw是一个开源的日志智能平台，运行在Kubernetes上。它通过OpenTelemetry获取日志，并使用基于信号的复合评分检测异常，而不是简单的阈值警报。该系统提取8种故障类型信号（OOM、崩溃、资源耗尽、依赖失败、数据库死锁、超时、连接错误、身份验证失败），并结合统计z-score分析、影响范围、错误速度和复发信号，计算出一个复合评分。关键故障（如OOM、恐慌）在<100毫秒内触发即时检测路径——甚至在时间窗口完成之前就能检测到。该检测在关键故障方面的准确率达到99.8%，同时过滤噪声（验证错误和404不会触发事件）。 一旦确认异常，5层追踪关联引擎会根据traceId对日志进行分组，映射服务依赖关系，跟踪错误传播级联，并计算受影响服务的影响范围。然后，工单代理会提取相关的时间线，将其发送给大型语言模型进行根本原因分析，并在Jira、ServiceNow、PagerDuty、OpsGenie、Slack或Zammad上创建去重的工单。从日志噪声到提交工单的循环大约需要90秒。 架构：OTel Collector → Kafka（Strimzi，KRaft模式）→ 桥接（Python，4个并发线程：ETL、异常检测、OpenSearch索引、追踪关联）→ OpenSearch + 工单代理。AI层支持OpenAI、Claude或Ollama，以实现完全隔离的部署。每个租户使用单个Helm图表进行部署，命名空间隔离，没有共享数据平面。 要在本地尝试： [https://docs.logclaw.ai/local-development](https://docs.logclaw.ai/local-development) 目前尚未实现的功能： - 指标和追踪——目前仅支持日志。指标支持在开发计划中。 - 异常检测是基于信号和统计的（使用z-score的复合评分），而不是深度学习。它能够捕捉99.8%的关键故障，但尚未检测到微妙的性能漂移模式。 - 仪表板功能正常但较为基础。我们使用OpenSearch Dashboards进行重负载处理。 许可证为Apache 2.0。如果您不想自托管，托管云版本的费用为每GB $0.30。 嗨，HN——我是Robel。 我创建LogClaw是因为厌倦了醒来时只收到“出现问题”的警报，而没有任何上下文信息。 LogClaw是一个针对Kubernetes的开源日志智能平台。它通过OpenTelemetry获取日志，并使用基于信号的异常检测来识别操作故障，而不是简单的阈值。 LogClaw并不是仅仅关注单一指标，而是从日志中提取故障信号（如OOM、崩溃、依赖失败、数据库死锁、超时等），并结合错误速度、复发、z-score异常和影响范围等统计信号，计算出一个复合异常评分。 关键故障可以绕过时间窗口，在<100毫秒内触发检测。 一旦确认异常，关联引擎会重建跨服务的追踪时间线，检测错误传播，并计算影响范围。 然后，工单代理会生成根本原因摘要，并在Jira、ServiceNow、PagerDuty、OpsGenie、Slack或Zammad中创建去重的事件。 架构： OTel Collector → Kafka → 检测引擎 → OpenSearch → 工单代理 代码库： [https://github.com/logclaw/logclaw](https://github.com/logclaw/logclaw) 希望能收到运行大型生产系统的人的反馈。

我创建了Understudy，因为许多实际工作仍然涉及本地桌面应用程序、浏览器标签、终端和聊天工具。目前大多数代理仅存在于这些界面中的一种。 Understudy是一个以本地为先的桌面代理运行时，可以在一个会话中操作图形用户界面应用程序、浏览器、命令行工具、文件和消息传递。我最希望获得反馈的部分是通过示范教学：你执行一次任务，代理会录制屏幕视频和语义事件，提取意图而不是坐标，并将其转化为可重用的技能。 演示视频： [https://www.youtube.com/watch?v=3d5cRGnlb_0](https://www.youtube.com/watch?v=3d5cRGnlb_0) 在演示中，我教它：谷歌图片搜索 -> 下载一张照片 -> 在Pixelmator Pro中去除背景 -> 导出 -> 通过Telegram发送。然后我让它为埃隆·马斯克做同样的事情。重放并不是一个脆弱的宏：发布的技能仅将意图步骤、路线选项和图形用户界面提示存储为后备。在这个例子中，当有更快的路线可用时，它也可以优先选择这些路线，而不是重复每一个图形用户界面步骤。 当前状态：仅支持macOS。第一层和第二层目前已在工作；第三层和第四层部分完成，仍处于早期阶段。 ``` npm install -g @understudy-ai/understudy understudy wizard ``` GitHub: [https://github.com/understudy-ai/understudy](https://github.com/understudy-ai/understudy) 欢迎就架构、通过示范教学或当前实现的局限性提出问题。

在之前的文章中，我介绍了 VS Code Agent 看板。这个扩展的核心思想是将计划形式化，实施一个工作流，该工作流要求代理在我已经使用了一段时间的 markdown 文件中进行对话——但我一直是手动管理这些文件（该工作流的推理和好处在链接的文章中有详细说明）。本文将讨论这一过程的发展，转向使用 Git 工作树。