最新

嘿，HN，我们是来自Runtime的Gus和Carlos（<a href="https://runtm.com">https://runtm.com</a>）。我们正在构建一种基础设施，让整个团队（包括非工程师）能够使用Claude Code、Codex和其他代理进行开发，而不需要工程师在每个会话中进行指导。 在Mentum（YC S21）被收购后，我个人在三个月内使用编码代理发布了四个全栈产品。当我尝试将相同的工作流程推广到其他团队成员时，事情却崩溃了：大多数PR无法合并——每个代码库都需要工程师进行一次性的本地设置——技能和背景知识都集中在一个人的脑海中——PM没有安全的方式接触真实的代码库，风险是可能导致错误的部署或泄露机密。 Carlos曾在Modern Treasury构建代理调解系统时遇到过类似的经历，他让自己的支持团队使用devin。 我们最终构建了内部的后台代理基础设施，但很快就变成了维护和开发的噩梦。我们创建Runtime就是为了让你不必经历这种事情。 Runtime的工作方式如下：工程师只需定义一次上下文：系统指令、技能和可通过CLI、mise、npm或任何包管理器安装的范围集成。然后，Runtime会快照你的完整运行环境，包括多服务的Docker Compose设置、Kafka、Redis、预置的数据库，因此每个服务器都能在毫秒内启动。 我们根据你的设置在E2B、Daytona、EC2或自托管的K8s等沙盒提供商之间进行编排。机密信息通过我们的托管代理注入，因此它们不会直接接触代理，而安全防护措施在基础设施层面运行：命令允许/拒绝列表、网络出口控制，以及按用户和代理范围划分的RBAC。每个会话还会获得一个可分享的预览URL，因此内部构建可以从沙盒转到团队的其他成员，而无需生产访问权限。 Runtime与团队已经使用的任何代理兼容：Claude Code、Codex、Cursor、Copilot、Gemini、Devin。你可以通过我们的网页应用、CLI、Slack、Linear、GitHub或API触发沙盒。 我们的一个客户构建了一个值班检查器，将PagerDuty、Sentry和他们的代码库连接起来，因此当警报触发时，代理会找到原因并在任何人被通知之前打开一个包含单元测试的PR。另一个客户在一个私密的Slack频道中运行一个财务代理，从Stripe、NetSuite和Snowflake提取数据，以便在几分钟内进行对账，并附上源行。 一家金融科技独角兽和几家YC规模的初创公司正在使用Runtime，包括一些曾在内部构建类似基础设施并将其交给我们接管的团队。 核心部分是开源的，地址在<a href="https://github.com/runtm-ai/runtm" rel="nofollow">https://github.com/runtm-ai/runtm</a>。托管版本已上线，地址为<a href="https://app.runtm.com">https://app.runtm.com</a>，包括免费套餐。我们收取固定的平台费用加上计算费用，没有代币加价。 查看我们的演示：<a href="https://www.youtube.com/watch?v=wLwj__aEEh4" rel="nofollow">https://www.youtube.com/watch?v=wLwj__aEEh4</a> 我们很想听听你们如何考虑基础设施，以便让更多组织中的人使用编码代理，而不造成混乱！

你好，HN，我创建了Parseflow，这是一款简单且以证据为中心的提取API，能够提取PDF、DOCX和TXT文件中的信息，并将其分块，以改善大型语言模型（LLM）的上下文并减少令牌使用。如果你想试用演示版，可以在这里找到：demo.parseflow.tech。 我仍然是一名学生开发者，今年将高中毕业，所以我还有很多需要学习的东西。我正在努力构建这个项目，以帮助支付今年的学费，同时也帮助我学习。因此，任何反馈、建议、问题等都非常感谢，我会尽量回复评论，或者你可以通过电子邮件联系我，邮箱是hello@parseflow.tech。 谢谢， bollethegoalie

在Reddit、HN等评论区，关于某些发布的内容是否由人工智能生成的讨论非常热烈。显然，使用AI越多，识别明显特征就越容易，但随着时间的推移，这将变得更加困难。那么，人们正在使用或构建什么系统来证明他们是手动创作了一篇文章、图片等呢？ 最近，我在考虑录制自己写博客文章的过程，可以是屏幕录制或手动使用打字机（这是我最近的爱好）。 希望其他人也在考虑这个问题，尽管我不知道是否有不需要额外大量工作的解决方案。 编辑：我采取的另一种方法是直接写作，不再进行太多修订。感觉越是精致的内容，越容易引起人们的怀疑。不过，我想你也可以在创作过程中加入这种想法。

嘿，HN社区， 我不久前开发了一个开源项目，它在GitHub上变得相当受欢迎。这是我在管理岗位上工作了一段时间后，重新与编程建立联系的一种有趣方式。 这也让我亲眼见证了开源领域的变化。 生成的问题和拉取请求的数量给我带来了压力。有些是有帮助的，但很多则不是。无论如何，维护者现在必须在他们已经免费做的所有工作之上，审查、分类和回应越来越多的“AI”生成的工作。 一个实际的应对方法是，维护者也可以使用这些工具：过滤问题、进行初步的拉取请求审查、帮助处理安全补丁、编写测试，或者处理项目中的一些重复性工作。这并不是每个人都能接受的，我对此表示尊重。但如果使用得当，它确实可以提供帮助。 问题在于成本。 开源维护者不应该个人承担维持项目生成工作量所需的计算费用。 这种新出现的压力就是我构建opub的原因。 opub允许捐赠者为开源项目提供计算资源。维护者可以创建有限金额的计算密钥，并在30多个模型中与编码代理和工具一起使用。代币的使用和支出与项目相关联，连同捐赠一起，项目的计算余额在公开中可见。 注册现已开放，我非常希望听到HN社区的反馈。 如果你维护一个在GitHub上有100个以上星标的开源项目，前20位注册者可以获得我们提供的50美元的起始捐赠计算资源。