最新

今天，许多好的想法诞生于推特、讨论串、博客文章和个人随笔中：假设、方法、概念模型、批评、部分结果。但这些想法主要存在于信息流中——以个性驱动、短暂易逝的形式，难以按主题搜索，几乎不可能被引用。如果一个想法没有发展成完整的论文，通常就会消失。 这个提案是一个非营利的社区知识基础设施，它以期刊发布论文的方式发布想法帖子： 一个存档条目 = 一篇原创帖子（博客文章、讨论串、随笔等） 只有原创作者可以提交 帖子将成为经过轻度编辑的权威版本，经过作者批准 一旦发布，内容将永久冻结 每个条目都会获得一个独特的、持久的ID（类似DOI）和稳定的URL 条目按主题组织成各个领域的“想法期刊” 其结果是形成一个永久的、可引用的想法记录，否则这些想法将会在信息流中消失。后续或更正将作为新条目，因此系统保留了想法的时间顺序，而不是无休止地编辑页面。 这不是一个社交网络、论坛、维基或预印本服务器。这是一个想法的出版商和图书馆：一个按主题索引的档案和互联网最佳思维的记忆层。发现的重点在于主题，其次是作者。 没有繁重的同行评审——只有轻度的编辑策划，AI辅助过滤和分类。想想图书馆的标准，而不是期刊的把关。 我并不是自己在构建这个——分享这个想法是因为感觉缺少这样的基础设施。这对你来说解决了一个实际问题吗？类似的东西已经以我未曾注意到的形式存在吗？

嗨，HN， 我创建了 llm-authz-audit，因为我在 LLM 驱动的应用程序中不断看到相同的安全问题：API 密钥与 OpenAI 调用硬编码在一起，FastAPI 端点提供聊天完成服务却没有任何认证，用户输入直接拼接到提示中，以及没有会话隔离的共享对话记忆。 这些问题并不是假设的——它们是我在多个开源 LLM 项目和生产代码库中反复发现的模式。 它的功能： 这是一个静态分析工具（类似于 eslint/semgrep，但专门针对 LLM 安全性构建），可以扫描 Python、JavaScript 和 TypeScript 代码库中的授权和安全漏洞。它配备了 13 个分析器和 27 条规则，涵盖了 LLM 应用程序的 OWASP 前 10 项： - 提示注入风险（提示中的未清理输入，缺失分隔符） - 硬编码的 API 密钥（OpenAI、Anthropic、HuggingFace、AWS、通用） - 未认证的 LLM 端点（FastAPI、Flask、Express） - 没有 RBAC 的 LangChain/LlamaIndex 工具 - 没有文档级访问控制的 RAG 检索 - 权限过大的 MCP 服务器配置 - 没有用户范围的共享对话记忆 - 缺失的速率限制、审计日志、输出过滤 - 通过提示模板转发给 LLM 的凭证 希望能收到任何正在构建或保护 LLM 应用程序的人的反馈。

你好， 问题：我想在使用人工智能验证由人工智能实现的功能是否完全符合开发者的设想时，减少开发体验的摩擦。但我现在陷入困境…… 背景： 首先，我想我们可以将提示形式化，使其成为代码。这个想法是：一个项目规范，其中特定的词定义行为，改变这些词就会改变程序。每个词都是一个函数，因此按下“转到...(F12)”会让你进入一个嵌套的行为（因此称为“分形”）。所以这将是一个由人工智能编译器解释的元规范语言，同时仍然使用自然语言（因此称为“本地”）。 但这基于一个错误的假设——即开发者愿意学习一种新的语言（这种语言比TypeScript、Java或Go更不正式，但仍然是有规范的）。我认为这种情况已经不可能发生了。下一个编程语言将完全是英语（或任何其他自然语言）。 其次，我和一个朋友讨论了这个想法，我们意识到测试是行为的一个很好的描述（当然也有一些例外）。创意继续发展，长话短说，这就是语言规范：https://github.com/slowestmonkey/fractal/blob/main/README.md 那么我为什么会陷入困境呢？我意识到，仅仅提示人工智能并获得正确的行为对于工程师来说是不够的。除非我理解它是如何以及为什么以那种方式构建的，否则我无法自信地说“这有意义”。这是我的领悟：https://www.conjectly.com/thoughts/7 因此，我在寻求帮助或建议： - 这个想法是否以及如何可以进一步发展 - 我还犯了哪些其他错误的假设 请分享你的想法，谢谢。

<a href="https://github.com/Mattbusel/Reddit-Options-Trader-ROT-" rel="nofollow">https://github.com/Mattbusel/Reddit-Options-Trader-ROT-</a><p>拥有纽约证券交易所的ICE公司刚刚开始向机构投资者出售“Reddit信号和情绪”数据。这是为对冲基金提供的结构化Reddit数据。<p>我在9天内构建了同样的东西。165,000行代码，6,916个测试，零CodeQL警报。是的，我使用了人工智能来构建它。不，我对此并不感到抱歉。

我一直在研究一种工作流程，即数据库环境持续保持同步，而不是定期修复漂移。这个想法是将数据库状态视为一种工件——捕捉快照，将其与另一个环境进行对比，并生成对齐所需的确切更改。 理论上，这听起来像是持续集成/持续交付（CI/CD）的自然延伸：环境保持一致，回滚更清晰，漂移问题能够早期显现。但在实践中，我不确定有多少团队真正将其落地实施，而不是依赖于迁移和偶尔的手动对账。 以下是针对运行生产系统的朋友们的一些问题： * 你们是否在积极同步开发、预发布和生产环境的模式，还是仅仅管理向前迁移？ * 你们如何处理环境之间的故意差异？ * 这项工作是在管道内部进行，还是更像是一项运营任务？ * 在自动化模式对齐时，有没有可靠性或安全性方面的顾虑？ * 短暂环境和预览数据库如何融入这个模型？ 我想了解持续同步在大规模下是否现实，或者它是否引入了比解决的问题更多的风险。 作为背景，这篇文章引发了我的思考：https://blog.sonichigo.com/how-diffchangelog-and-snapshots-work-together