最新

我开发了Vynix，这是一款跨平台的移动应用程序（iOS/Android），将100多个AI模型整合到一个界面中。用户无需在不同的AI应用之间切换，就可以在一个地方获得图像生成、视频创作、文本转语音、音乐生成和大型语言模型聊天等功能。 技术栈： - Kotlin多平台 + Compose多平台（在iOS和Android上共享UI） - Firebase（身份验证、Firestore、云函数） - 后端代理连接Replicate和fal.ai的API - 基于积分的系统——无需订阅 该应用在模型公开可用后的几天内就会添加新模型。目前包括以下模型： - 文本转图像（多种风格：照片真实感、动漫、数字艺术） - 文本转视频和图像转视频 - 文本转语音（50多种声音选项） - AI音乐生成 - 大型语言模型聊天（多模态） 免费试用——注册时可获得40个积分 + 每日免费积分。 网站： [https://vynix.app](https://vynix.app)

构建 AISH 旨在使终端输出更有用，而不改变命令的执行方式。您的代理上下文会喜欢它。 它的功能： - 在真实的 PTY 中运行命令（颜色/进度仍然有效） - 记录每次运行的完整输出 - 成功时显示简短摘要 - 失败时显示相关摘录（工具感知检测器 + 通用回退） - 通过 ai 包装器和可选的 shim 支持 bash/zsh 示例： - aish-run -- cargo test - aish-run --last - aish-run --open 当前支持的检测器包括 pytest/jest/vitest/cargo/go/tsc/eslint/ruff/mypy/maven/gradle/dotnet/cmake/terraform/docker/kubectl。 希望能收到关于以下方面的反馈： - 检测器质量 / 误报 - shell 用户体验默认设置 - 打包/发布体验

我想问问HN（以及OpenAI的员工）关于这些交易中令人困惑的方面，现在已经过去几天了。<p>现在我们终于得到了大规模的确认，OpenAI确实签署了一项协议，允许美国国防部（DoD）拥有自主杀伤性武器，而人们正在抵制OpenAI，这一切已经进入了主流新闻。<p>是的，即使在Sam Altman最近的推文中提到将增加更多条款之后，这一说法也被驳斥，因为这些条款只是以更强烈的措辞表达OpenAI对DoD的偏好，但在任何情况下仍然无法强制执行。根据当前的协议，DoD可以在Pete Hegseth/现任政府发布的指令下创建自主杀伤性武器和大规模监控，而OpenAI根据条款是被允许同意的。<p>对于所有签署了notdivided.org请愿书的OpenAI员工（我看到有98位签署者），你们打算怎么做？<p>&gt; 他们试图通过恐惧来分化每家公司，担心其他公司会妥协。这种策略只有在我们都不知道其他人立场的情况下才有效。这封信旨在在面对来自战争部的压力时，创造共同理解和团结。<p>你们会坚持你们认为正确的事情吗？当OpenAI的交易宣布时，人们就问过这个问题，但当时的情况并不明确。但现在，经过一段时间，人们已经非常清楚OpenAI签署的协议绝对允许创建自主武器。<p>我认为OpenAI的员工不会面临经济上的困境，正如一些人所指出的那样。我的意思是，任何人工智能公司都应该感到幸运能拥有你们（在我看来），他们应该能够公平地与OpenAI竞争。<p>我在HN上看到有人将此与这样一个事实进行比较：在这一事件发生后，任何在一个月内留下来的人将展现出对当前情况的道德立场。<p>我记得OpenAI曾经是一个非营利组织，以及员工因非营利组织解雇Sam Altman而离开OpenAI的事情。<p>我不禁想知道董事会是否做出了正确的决定。我认为答案是肯定的。但我的问题是，OpenAI的员工确实拥有巨大的权力。我相信那里很多人会更好地选择不让自己的工作助长痛苦的根源。<p>我希望提出，如果OpenAI的员工再次团结起来，他们可以做与之前相同的事情，但现在是为了推翻那个决定。<p>也就是说，如果我是OpenAI的员工，我考虑了一下，这里是我发现的所有令人困扰的事情，这些事情可以被推翻：<p>1. 终止与DoD的交易。<p>2. 实际上从ClosedAI转变为OpenAI（转变为非营利结构，如原本意图）并解雇Sam Altman。<p>3. 如果能对内存价格上涨采取措施。我看到一些项目被取消，托管服务提供商关闭或提高价格，因为内存价格上涨了5倍，所有这一切都是因为OpenAI试图占用全球20%的内存生产。

我最近从在浏览器中使用大型语言模型（LLMs）转向在VS Code中使用本地代理工作流程（Gemini代码助手）。我可以批准或拒绝更改，这很好，但在上下文管理方面遇到了瓶颈。最初，我将整个代码库作为上下文提供给非代理版本的Gemini代码助手，它的表现很好。 我了解到代理模式“更好”，因此为了使代理与我项目的架构保持一致，我手动构建了7个密集的Markdown文件，作为项目的系统指令。我需要Gemini在我们实现功能时更新这些文件。 这些文件包括：gemini.md（指示Gemini读取其他md文件并处理更新）、project_overview.md、architecture.md、features.md、database.md、api.md、security.md。 每个文件的字数在500到1500之间，所以我担心这是否是正确的做法。目前似乎没有关于上下文文件最佳实践的共识。我看到对简约、精简指令和密集、全项目规格的论据都有很强的支持。老实说，LLM的正确使用和提示模式似乎就像看星座运势，每个人都凭直觉判断，而最常被引用的真相来源是确认偏误。 你在工作流程中是如何使用.md上下文文件的？

您可以在 neuralops.com 上找到它。