最新

我开发 VueCode 是因为我看到太多代码库——无论是 AI 生成的还是人工编写的——在没有经过任何适当审查的情况下就上线了。它有 7 个专业代理，从安全、架构、数据库、代码质量、用户体验/流程、DevOps 和项目管理等角度分析你的代码库。生成一份完整的报告，其中包含可直接复制粘贴的补丁和敏捷修复路线图。实时演示：vuecode.dev/demo——对真实代码库的真实分析，而非模拟。

我正在认真尝试借助智能体进行开发。理想情况下，我希望能够紧跟前沿，但可能不会完全处于最前沿。请注意，这并非用于构建生产代码。 看起来这个领域的变化非常快，可能去年12月编写的东西现在就已经过时了。有哪些实践或链接可以描述我应该使用的实践？

对这个小小的浏览器玩具有点着迷。必须把它做出来。

我一直在使用 Claude Code 构建 SaaS 产品，但一直遇到同样的瓶颈：它能写出精彩的代码，但 20 分钟后就会忘记你的数据库模式，并开始重写已经运行的代码。 问题不在于模型的记忆力，而在于会话之间没有持久的项目上下文。第二天再来，Claude 对昨天构建的内容一无所知。 我的解决方案：强制 Claude 在每次操作前读取项目的真实文件。 我构建了一个多智能体系统，预先创建持久的上下文文件： * PROJECT.md - 你要构建什么，商业模式，核心功能 * REQUIREMENTS.md - 数据库模式，身份验证流程，API 结构，边缘情况 * ROADMAP.md - 带有成功标准的构建阶段 * STATE.md - 当前位置，已完成的工作，待处理的任务 工作原理： * AI 产品经理会提出大多数开发人员会跳过的问题： * “资金如何流转？” * “如果用户在月中取消会发生什么？” * + 任何特定于你的 SaaS 的边缘情况 * 根据你的回答创建 Markdown 文件。 * Claude Code 在编写任何代码之前都会读取这些文件。 * 无需猜测。不会忘记模式，因为它被明确记录了。 * 每个任务都会生成执行器智能体，每个智能体都会读取相同的上下文文件。 * 它们并行构建，但永远不会破坏已经运行的内容。 * 验证器智能体在每个阶段后根据成功标准进行测试。 * 如果出现问题，则生成调试器智能体，并附带持久的调查文件。 结果： 使用该系统在 30 天内构建了 3 个产品： * 分析仪表板：13 小时 * 反馈小部件：18 小时 * 内容日历：9 小时 没有上下文漂移。没有“Claude 忘记了我的身份验证系统”的情况。只有一致的构建。 最大的区别： * 星期六：使用 Claude 构建身份验证 * 星期日：回来，描述下一个功能 * Claude 读取 REQUIREMENTS.md，看到现有的身份验证模式 * 构建新功能，不触及身份验证 * vs. Claude 重写所有内容的正常体验。 我将其打包为 PropelKit（Next.js 样板 + AI PM 系统，可自动创建这些文件）。但核心概念，持久的 Markdown 上下文，适用于任何 Claude Code 设置。 试用一下：[https://propelkit.dev](https://propelkit.dev) 智能体架构使用 Claude Sonnet/Opus（可配置）并行思维来生成多个智能体，所有智能体都从相同的真实文件读取。很乐意回答有关实施的问题。

大家好，我们是沈杰、Charles、Andreas 和 Shaocheng。我们开发了 Chamber (<a href="https:&#x2F;&#x2F;usechamber.io">https:&#x2F;&#x2F;usechamber.io</a>)，一个为您管理 GPU 基础设施的 AI 智能体。您可以在团队已经使用的任何地方与它对话，它会处理诸如配置集群、诊断失败作业、管理工作负载等任务。演示：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=xdqh2C_hif4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=xdqh2C_hif4</a> 我们都曾在亚马逊从事 GPU 基础设施方面的工作。我们加起来花了数年时间解决这个问题——监控 GPU 资源池、大规模调试故障、构建相关的工具。离职后，我们与许多 AI 团队交流，并不断听到同样的问题。平台工程师们把一半的时间都花在维护系统运行上。他们整天都在构建仪表盘、编写调度配置、回答“我的作业什么时候开始？”之类的问题。研究人员会因为训练运行失败而损失数小时，因为要找出原因，就得在完全不同的工具中翻阅 Kubernetes 事件、节点日志和 GPU 指标。几乎每个人都拼凑了 Prometheus、Grafana、Kubernetes 调度策略以及一堆自制的脚本，而且他们花在维护所有这些东西上的时间，与实际使用它们的时间一样多。 我们一直注意到的是，大多数这类工作都遵循一定的模式。对故障进行分类，关联一些信号，然后确定如何处理。如果您有一个平台，可以结构化地访问 GPU 环境的完整状态，那么您就可以让一个智能体来为您完成这项工作。 所以，这就是我们构建的东西。Chamber 是一个控制平面，它维护着您的 GPU 资源池的实时模型：节点、工作负载、团队结构、集群健康状况。它支持的每个操作都作为智能体可以调用的工具公开。检查节点健康状况、读取集群拓扑、管理工作负载生命周期、调整资源配置、配置基础设施。这些都是具有验证和回滚功能的结构化操作，而不仅仅是原始的 shell 命令。当我们向平台添加新功能时，它们也会自动成为智能体可以执行的任务。 我们花了很多时间在安全性上，因为我们已经看到了基础设施自动化出错时会发生什么。一个错误的调用可能会中断一个为期数天的训练运行，或者在整个集群中引发连锁反应。因此，智能体具有渐进的自主性。它会自行处理日常事务：诊断失败的作业、使用更正后的资源重新提交、隔离故障节点。但是，任何涉及到其他团队的工作负载或生产作业的操作都需要先获得人工批准。每个操作都会记录智能体看到了什么、它为什么采取行动以及它更改了什么。 底层的平台才是真正让诊断工作发挥作用的关键。当智能体调查故障时，它会查询 GPU 状态、工作负载历史记录、节点健康状况时间线和集群拓扑。这与“您的作业 OOM”和“您的作业 OOM 是因为批处理大小超出了此节点上可用的 VRAM，这里有一个更正后的配置”的区别在于根本原因的不同，会得到不同的修复方案。 有一件事让我们感到惊讶，即使我们来自亚马逊，在那里我们见过大型 GPU 资源池：我们交谈过的大多数团队甚至无法告诉您现在正在使用多少个 GPU。监控根本不存在。他们对他们最昂贵的硬件一无所知。 我们已经与一些早期客户合作并正在为新团队提供支持。我们仍在完善定价，目前正在评估按 GPU 管理和分层计划等模式。我们计划在验证了哪种方案最适合客户后，发布透明的定价。与此同时，我们知道“联系我们”并不是一个理想的选择。 很乐意听取任何运行 GPU 集群的人的意见。您设置中最繁琐的部分是什么？您实际上会信任智能体做什么？哪些是禁区？期待您的反馈！

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

嗨，Hacker News， 我开发了 Winstwaker，这是一款针对荷兰企业的簿记服务，它直接从您的银行提取交易数据，并将整理好的数据交给专门的会计师。 在荷兰经营一家小企业意味着要处理大量的行政事务。大多数企业主要么聘请一位他们很少联系的簿记员，要么忍受他们并不完全理解的会计软件。我想要一个介于两者之间的解决方案。 我们建立了与 ING、Rabobank、ABN AMRO、bunq 以及其他几家银行的直接 API 连接。 收据、Mollie 支付、Stripe 交易、Shopify 订单——所有数据都会自动流入。您的会计师可以看到相同的实时数据，并主动联系您，而不是等到年底才手忙脚乱。 无需手动导出，无需追逐发票，也无需意外的税单。 欢迎任何处理过荷兰税务管理或构建过类似混合服务产品的人提供反馈。