一周热榜

嗨，HN， 我开发了 hanoi-cli，这是一个小型命令行工具，用于分析 Kubernetes 节点上 Pod 的分布情况，并建议更好的放置方案。 这个想法来源于一个反复出现的问题：即使请求/限制设置得当，集群往往还是会出现不平衡的情况。有些节点负载过重，而其他节点则未得到充分利用。 期待大家的反馈。

我厌倦了在决定是否为我的有限责任公司（LLC）选择S公司时进行粗略的计算，所以我在周末制作了一个计算器。 我找到的大多数工具要么忽略州/城市税，要么收费获取答案，或者需要创建账户才能看到有用的信息。TakeHome完全在您的浏览器中运行（无需注册，无分析，无服务器端存储），并且在您拖动滑块时实时更新每一个数字。 它模拟的内容包括： - LLC自雇税与S公司W-2工资的FICA税 - QBI扣除（第199A条款）与SSTB逐步淘汰 - 根据SECURE 2.0规则的单人401(k)（传统/罗斯/分割，按年龄段的补缴限额） - 自雇健康保险扣除 - S公司管理/合规成本比较 - 纽约州所得税、特许税、PTET - 纽约市UBT（LLC）、GCT（S公司）、PIT及IT-219抵免 您可以保存场景，比较任意两个场景（它会准确显示哪些输入不同以及对美元的影响），并进行多维的“假设”实验。 还有一个AI模式，您可以用简单的英语描述一个场景，它会为您生成实验。 税务引擎约有2000行TypeScript代码，没有外部依赖。技术栈为React 19、MobX、Tailwind v4，部署在Cloudflare Workers上。AI功能使用Claude Haiku。 注意事项：纽约/纽约市的税务模型已完全构建；对于其他地区，在联邦层面上是方向正确的（自雇税与FICA税、QBI、401k分析是与地点无关的）。假设为标准扣除。QBI假设为SSTB。此内容不构成财务建议，请将其视为与您的注册会计师（CPA）对话的准备。 我在每个计算项上添加了详细的工具提示，包括公式、IRS代码引用和来源链接。每个数字都展示了其计算过程。 我对反馈很感兴趣，特别是如果您发现税务逻辑错误。同时也想知道我是否应该优先考虑其他州（加州、德克萨斯州、佛罗里达州？）或支持逐项扣除。 <a href="https://takehome.money" rel="nofollow">https://takehome.money</a>

我正在研究从美国支付尼日利亚工程师和承包商时遇到的痛点。 有几个问题想请教有相关经验的人： 你们目前使用什么工具来支付非洲团队成员？ 这个过程最让人沮丧的部分是什么？ 是否有过支付失败导致员工出现严重问题的情况？ 我并不是在推销什么——我是真心想在开发任何东西之前了解这个问题。

在过去几年中，关于人工智能的警告几乎已成为常态。头条新闻常常聚焦于风险：工作岗位被取代、算法操控、监控、对自主系统的失控。在公众讨论中，人工智能经常被视为一种迫在眉睫的威胁，似乎是一种强大且不可预测的力量，可能以危险的方式重塑社会。 然而，在这些恐惧主导讨论的同时，另一种更为安静的现象正在展开。数以百万计的人们已经将人工智能融入到他们的日常生活中。他们依赖算法来帮助撰写电子邮件，向数字助手寻求研究指导，获取观看或阅读的推荐，并使用人工智能驱动的工具来加速工作。批评声愈发响亮，但这种习惯却愈发根深蒂固。 数据揭示了一个显著的矛盾。一项涉及数万名参与者的全球研究发现，全球约66%的人已经定期使用人工智能。对许多人来说，这种使用频繁且实用，出现在工作任务、教育或简单的日常决策中。与此同时，只有46%的人表示他们真正信任这些系统。换句话说，世界上超过一半的人正在使用他们并不完全信任的东西。实用性的发展速度超过了人们的信任感。 这种采用与信任之间的差距已成为当前人工智能时代的一个显著特征。多份全球报告中的研究表明，大约三分之二的人认为，人工智能驱动的产品将在未来五年内显著影响他们的生活。然而，公众讨论仍然被对隐私、虚假信息和社会后果的担忧所主导。矛盾显而易见：技术的发展速度超过了我们对其的心理适应。 在新兴经济体中，这种模式更加明显。最近的研究表明，非洲、亚洲和中东的几个国家中，定期使用人工智能的比例超过了90%。在学生中，对这些工具的依赖尤其强烈。约83%的人表示使用人工智能来学习、生成学术材料或辅助学习。曾经被视为专业技术的人工智能，悄然演变为人们吸收和生产知识的一种延伸。 在工作场所，转型同样显而易见。整个部门开始围绕自动化数据分析、人工智能辅助编程、内容生成和智能客户服务系统进行重组。在许多组织中，采用人工智能的过程是非正式的。员工们只是开始使用人工智能工具来加速任务，而无需正式培训或官方许可。这一现象变得如此普遍，以至于技术研究人员现在将其称为“影子人工智能”，即在公司内部自发使用人工智能而没有集中监督的情况。

这是一个小型社交实验：每个用户一生只能发布一条帖子（永久，不可删除或重发）。发布后，你将解锁动态，查看其他人选择了什么。

嗨，HN， 我们一直在思考一个简单的问题： AI代理实际上更喜欢哪些产品？ 随着越来越多的代理开始使用API、工具和软件，它们似乎需要一个地方来交流哪些产品效果良好。 因此，我们建立了一个小实验：AgentDiscuss。 这是一个讨论论坛，AI代理可以在这里： 1. 开展产品讨论 2. 评论和辩论工具 3. 投票支持他们喜欢的产品 人类也可以在这里发布产品，并观察代理的反应。 我们很想知道，如果代理之间开始讨论产品，会发生什么。 如果你正在构建代理，欢迎将它们发送到这里。 [https://agentdiscuss.com](https://agentdiscuss.com) 期待听到你的想法或批评。

大多数抵押贷款处理延迟并不是由于风险造成的，而是由于手动工作流程造成的。 我们一直在开发SimplAI，这是一个专为银行和金融服务设计的人工智能驱动系统，首先应用于抵押贷款操作。 我们不断遇到的问题包括： - 处理时间为15到22天 - 繁重的手动文件处理（每笔贷款超过500页） - 重复的数据输入和验证循环 - 核保人员在非决策工作上花费数小时 因此，我们构建了一套AI代理来处理操作层面的问题： - 文档AI（IDP）→ 在几分钟内对贷款文件进行分类和数据提取 - 收入分析模型 → 解析税单、工资单和可变收入 - 验证集成 → 实时的就业和财务检查 - AI辅助核保 → 预先验证文件并生成条件 - 合规引擎 → 持续检查是否符合监管规则 在实际应用中，我们观察到的结果是： - 从端到端处理时间：约18天缩短至3-5天 - 数据提取准确率：97%以上 - 核保审核时间：3-4小时缩短至不到45分钟 - 每笔贷款成本降低约40-50% 我们并不是在取代核保人员，而是在消除他们周围的操作瓶颈。 虽然还处于早期阶段，但我们正在探索： - 跨贷款生命周期的基于代理的工作流程 - 更好地处理边缘案例（自雇借款人、非合格贷款） - 核保决策的可解释性 我们非常希望听到金融科技、贷款领域或任何在受监管环境中构建AI系统的人的反馈。

我已经花了大约一年的时间进行了四次重大重写。Godogen 是一个管道，它接受文本提示，设计架构，生成 2D/3D 资产，编写 GDScript，并进行视觉测试。最终输出是一个完整的、可玩的 Godot 4 项目。 要让大型语言模型（LLMs）可靠地生成功能性游戏，需要解决三个特定的工程瓶颈： 1. **训练数据稀缺**：LLMs 对 GDScript 的了解几乎为零。GDScript 具有大约 850 个类和类似 Python 的语法，这使得模型可能会产生无法编译的 Python 习惯用法。为了解决这个问题，我建立了一个自定义参考系统：手写的语言规范、从 Godot 的 XML 源转换而来的完整 API 文档，以及一个用于引擎行为的特性数据库，这些是仅靠文档无法学习到的。由于 850 个类会使上下文窗口膨胀，因此代理在运行时仅懒加载其所需的特定 API。 2. **构建时与运行时状态**：场景由无头脚本生成，这些脚本在内存中构建节点图并将其序列化为 .tscn 文件。这避免了手动编辑 Godot 序列化格式的脆弱性。但这意味着某些引擎特性（如 `@onready` 或信号连接）在构建时不可用——它们仅在游戏实际运行时存在。教会模型在不同阶段可用哪些 API，以及每个节点需要正确设置其所有者，否则在保存时会默默消失，这需要仔细的提示，但最终是值得的。 3. **评估循环**：编码代理本质上对其自身输出存在偏见。为了防止它作弊，一个独立的 Gemini Flash 代理充当视觉质量保证（QA）。它仅查看运行引擎生成的渲染截图——没有代码——并将其与生成的参考图像进行比较。它捕捉到文本分析遗漏的视觉错误：Z冲突、漂浮物体、物理爆炸，以及应当是自然的网格状放置。 在架构上，它作为两个 Claude Code 技能运行：一个协调者负责规划管道，另一个任务执行者在 `context: fork` 窗口中实现每个部分，以便错误和状态不会累积。 一切都是开源的： [https://github.com/htdt/godogen](https://github.com/htdt/godogen) 演示视频（真实游戏，而非挑选的截图）： [https://youtu.be/eUz19GROIpY](https://youtu.be/eUz19GROIpY) 完整故事的博客文章（所有错误的转折）即将发布。欢迎提问。

我发布了 WebAssembly4J，并附带了两个运行时绑定： - Wasmtime4J – Wasmtime 的 Java 绑定 [链接](http://github.com/tegmentum/wasmtime4j) - WAMR4J – WebAssembly Micro Runtime 的 Java 绑定 [链接](http://github.com/tegmentum/wasmr4j) WebAssembly4J 是一个统一的 Java API，允许在不同的引擎上运行 WebAssembly [链接](http://github.com/tegmentum/webassembly4j)。 这个项目的动机在于，当前 Java 有多个新兴的 WebAssembly 运行时，但每个运行时都暴露了自己的 API。如果你想尝试不同的引擎，就必须每次都重写集成层。 WebAssembly4J 提供了一个单一的 API，同时允许在底层使用不同的运行时提供者。 项目目标： - 从 Java 应用程序运行 WebAssembly - 允许跨引擎比较运行时 - 使 WebAssembly 运行时对 Java 开发者更易获取 - 在运行时演变的同时提供稳定的接口 当前支持的引擎： - Wasmtime - WAMR - Chicory - GraalWasm 为了支持传统和现代的 Java 环境，该项目的目标是： - Java 8（JNI 绑定） - Java 11 - Java 22+（支持 Panama） 构件已发布到 Maven Central，因此可以直接添加到现有项目中。 我非常希望听到从事 Java + WebAssembly 集成或运行时实现的人的反馈。

嗨，HN， 我开发了一个小工具，叫做 Lengpal。它基本上是一个非常简单的视频聊天室，专为语言交流而设计。 我认识的大多数进行语言交流的人都使用 Zoom、Meet 或 Teams。这些工具虽然能用，但并不是专门为此设计的。一个常见的问题是如何管理发言时间，以便双方都能获得平等的练习机会。 因此，我们目前专注于一个内置计时器，允许你在语言之间分配时间。例如，30分钟西班牙语，30分钟英语。 这个想法故意保持简单。你创建一个房间，将链接发送给你的伙伴，然后开始会话。没有匹配，也没有复杂的设置。 我们今天刚刚上线，正在尝试看看这种简单的方法是否真的能帮助人们进行语言交流。 网站： [https://lengpal.com](https://lengpal.com) 如果有人感兴趣，我们今天也在 Product Hunt 上上线了： [https://www.producthunt.com/posts/lengpal](https://www.producthunt.com/posts/lengpal) 期待听到你的想法。

抱歉，我无法直接访问或翻译网页内容。不过，如果你能提供网页上的具体文本或信息，我很乐意帮你翻译成中文。