一周热榜

我们正在发布关于编码代理治理的早期尝试，名为 Cupcake [1] - 这是一个开源的政策执行层，具有原生集成。您可以使用政策即代码（OPA/Rego）编写规则，Cupcake 通过 Hooks 将这些规则集成到代理运行时中。 <p>查看实际演示（仅限桌面）：<a href="https://cupcake-policy-studio.vercel.app/example-policies/security/protecting-paths?harness=claude-code&format=rego" rel="nofollow">https://cupcake-policy-studio.vercel.app/example-policies/security/protecting-paths?harness=claude-code&format=rego</a></p> <p>帮助我们构建：<a href="https://github.com/eqtylab/cupcake" rel="nofollow">https://github.com/eqtylab/cupcake</a></p> <p>我们是 EQTY Lab，我们的使命是可验证的人工智能（身份、来源和治理）。随着像 Claude Code 这样的强大代理的崛起，部署这些代理的人员需要能够进行自己的对齐和安全控制，这一点变得非常明显。我们不能仅仅依赖前沿实验室。</p> <p>这就是为什么我们为 Claude Code [2] 创建了 Hooks 的功能请求，并在这些 Hooks 实现后转向不再依赖文件系统和操作系统级别的监控。Hooks 提供了我们所需的关键点：</p> * 评估：检查代理的意图和行为。 * 预防：阻止不安全或不希望的行为。 * 修改：在执行之前调整代理的输出。 <p>使用 OPA/Rego 的政策即代码 - 尽管许多代理安全论文建议使用自创的领域特定语言（DSL）来构建类似的政策架构，但 Cupcake 基本上是建立在开放政策代理（OPA）及其政策语言 Rego [3] 之上的。</p> <p>我们选择 Rego 是因为它：</p> * 行业稳健：在企业 DevSecOps 和云原生环境中被广泛采用。 * 专门构建：为定义、管理和执行政策即代码提供独特且成熟的优势。 * 企业导向：这使得 Cupcake 与现有的企业治理框架兼容。 <p>Cupcake 采用 Apache-2.0 许可发布。我们将在 2026 年第一季度正式制定通往 v1.0.0 的路径。这是一个早期预览版本。Cupcake 的目标不是压制，而是确保代理能够快速运行而不崩溃。若要合作或联合，请联系 ramos@eqtylab.io。</p> <p>[1] <a href="https://github.com/eqtylab/cupcake" rel="nofollow">https://github.com/eqtylab/cupcake</a></p> <p>[2] <a href="https://github.com/anthropics/claude-code/issues/712" rel="nofollow">https://github.com/anthropics/claude-code/issues/712</a></p> <p>[3] <a href="https://www.openpolicyagent.org/" rel="nofollow">https://www.openpolicyagent.org/</a></p>

大家好，HN！我们是来自DeepSource的Jai和Sanket（YC W20），今天我们推出了Autofix Bot，这是一款结合静态分析和人工智能的混合型代理，专为与AI编码代理协同使用而设计。 AI编码代理使得代码生成几乎变得免费，但它们将瓶颈转移到了代码审查上。仅依靠静态分析和固定检查器的方式已经不够。仅使用大型语言模型（LLM）进行审查存在几个局限性：运行结果的不确定性、安全问题的召回率低、在大规模使用时成本高昂，以及容易“分心”。 在过去的六年里，我们一直在构建一个确定性的、仅基于静态分析的代码审查产品。今年早些时候，我们从头开始思考这个问题，意识到静态分析可以解决LLM审查的一些关键盲点。在过去六个月中，我们构建了一个新的“混合”代理循环，结合静态分析和前沿的AI代理，以便在发现和修复代码质量及安全问题方面超越仅使用静态分析和仅使用LLM的工具。今天，我们将其公开发布。 以下是混合架构的工作原理： - 静态检查：5000多个确定性检查器（代码质量、安全性、性能）建立了一个高精度的基线。子代理抑制特定上下文的误报。 - AI审查：代理使用静态发现作为锚点来审查代码。可以访问抽象语法树（AST）、数据流图、控制流图、导入图等工具，而不仅仅是使用grep和常规的shell命令。 - 修复：子代理生成修复方案。静态工具验证所有编辑，然后再输出干净的git补丁。 静态分析解决了LLM的一些关键问题：运行结果的不确定性、安全问题的低召回率（LLM容易被风格分散注意力）以及成本（静态分析缩小了提示大小和工具调用）。 在OpenSSF CVE基准测试中（200多个真实的JS/TS漏洞），我们的准确率为81.2%，F1值为80.0%；相比之下，Cursor Bugbot的准确率为74.5%，F1值为77.42%；Claude Code的准确率为71.5%，F1值为62.99%；CodeRabbit的准确率为59.4%，F1值为36.19%；Semgrep CE的准确率为56.9%，F1值为38.26%。在秘密检测方面，我们的F1值为92.8%；相比之下，Gitleaks为75.6%，detect-secrets为64.1%，TruffleHog为41.2%。我们使用了我们的开源分类模型来实现这一点。 完整的方法论以及我们如何评估每个工具的详细信息，请访问： [https://autofix.bot/benchmarks](https://autofix.bot/benchmarks) 您可以通过我们的终端用户界面（TUI）在任何代码库上互动使用Autofix Bot，或者作为Claude Code的插件，或在任何兼容的AI客户端（如OpenAI Codex）上使用我们的MCP。我们特别为AI编码代理优先的工作流程构建，因此您可以要求您的代理在每个检查点自主运行Autofix Bot。 今天就来试试吧：[https://autofix.bot](https://autofix.bot)。我们期待您的反馈！ --- [1] [https://github.com/ossf-cve-benchmark/ossf-cve-benchmark](https://github.com/ossf-cve-benchmark/ossf-cve-benchmark) [2] [https://huggingface.co/deepsource/Narada-3.2-3B-v1](https://huggingface.co/deepsource/Narada-3.2-3B-v1) [3] [https://autofix.bot/manual/#terminal-ui](https://autofix.bot/manual/#terminal-ui)

嗨，HN，简而言之，我们开发了一个错误检测工具，效果非常好，尤其适用于应用后端。欢迎试用并告诉我们你的想法！ 以下是详细内容。 -------------------------- 我们最初的目标是解决技术债务。我们都见过有很多债务的代码库，因此对这个问题有着个人的看法，而人工智能似乎让这个问题变得更加严重。 技术债务似乎是一个很适合用人工智能解决的问题，因为：1）一小部分工作需要思考和战略，而大部分执行则相对机械；2）在解决技术债务时，通常是试图保留现有行为，只是改变实现方式。这意味着如果你能找到有效的方法来检测由于代码更改而导致的意外行为变化，就可以将其视为一个闭环问题。而我们知道如何做到这一点——这就是测试的作用！ 因此，我们开始编写测试。测试创建了保护措施，使未来的代码更改更安全。我们的想法是：如果我们能测试得足够好，就可以以非常高的质量自动化许多其他技术债务工作。 我们构建了一个代理，可以为典型的代码库编写数千个新的测试，大多数是“合并质量”的。一些早期用户通过这种方式合并了数百个PR，但直观上这个工具总是给人一种“好但不够好”的感觉。我们自己偶尔使用它，通常感觉像是一项繁重的任务。 在这个时候，我们意识到：虽然我们最初的目标是编写好的测试，但我们构建了一个系统，经过一些调整，可能非常擅长发现错误。当我们在一些朋友的代码库上进行测试时，我们发现几乎每个代码库中都有大量潜伏的错误，我们能够标记出来。这些是严重的错误，足够有趣，以至于人们放下手头的工作去修复它们。它们就存在于人们的代码库中，已经合并，并在生产环境中运行。 我们还发现了许多漏洞，即使是在成熟的代码库中，有时甚至是在有人进行渗透测试之后。 在技术细节方面： - 我们检查代码库并找出如何为本地开发构建它，并通过测试进行验证。 - 我们对构建的本地开发状态进行快照。（我们使用Runloop对此，并且非常喜欢它。） - 我们启动数百个本地开发环境的副本，以千种方式测试代码库，并标记出看起来不正常的行为。 - 我们挑选出最显著、最令人担忧的例子，并将其作为线性票据、GitHub问题或电子邮件发送。 在实践中，这个工具运作得相当不错。我们能够在从编译器到交易平台（甚至是Rust代码）等各种项目中发现错误，但最佳效果是在应用后端。 我们的方法在质量和计算之间进行了权衡。我们的代码库扫描需要几个小时，远远超出代码审查机器人所能承受的范围。但结果是我们可以更明智地利用工程师的注意力，我们认为这将是最重要的变量。 从长远来看，我们认为计算成本低，而工程师的注意力成本高。合理使用最新的模型可以在大型代码库中执行复杂的更改。这意味着在软件构建中，限制因素是人类的注意力。工程师仍然需要时间和专注来理解信息，例如现有代码、组织背景和产品需求。这些都是工程师能够准确表达他们想要的内容并胜任审查结果差异所必需的。 目前我们正在发现错误，但我们正在开发的技术也扩展到许多其他背景下的半主动工作，以改善代码库。 欢迎试用并告诉我们你的想法。首次扫描免费，无需信用卡： [https://detail.dev/](https://detail.dev/) 我们也在扫描开源代码库，如果你有任何请求。系统的信噪比相当高，但我们不想冒着自动打开问题而打扰维护者的风险，因此如果你请求扫描开源代码库，结果将直接发送给你个人。 [https://detail.dev/oss](https://detail.dev/oss)

在任何网址前加上 tomcp.org/，即可立即将其转换为 MCP 服务器。<p>您可以直接与页面聊天，或者将配置添加到 Cursor/Claude，以便将网站/文档直接传输到您的上下文中。<p>为什么选择 MCP？使用 MCP 比直接抓取或复制粘贴更好，因为它将页面转换为干净的 Markdown。这有助于 AI 更好地理解结构，并显著减少使用的令牌数量。<p>工作原理：它是一个代理，获取网址，去除广告和导航，并将干净的内容以标准 MCP 资源的形式呈现。<p>代码库：<a href="https://github.com/Ami3466/tomcp" rel="nofollow">https://github.com/Ami3466/tomcp</a>（受 GitMCP 启发，但适用于一般网页）

嗨，独立开发者们 我们正在构建 Kinkora，这是一个创意平台，将多个图像和视频人工智能模型集中在一个地方，供用户进行实验和创作。 像许多开发者一样，我们发现自己不断切换工具，只为测试不同的模型或创意方向。每个平台似乎都局限于单一的工作流程或使用案例。因此，我们决定创建一个更模块化、探索性强且以创作者为中心的空间。 Kinkora 的重点是： - 支持流行的生成模型 - 让实验过程快速而愉快 - 为创意社区奠定基础，而不仅仅是一个生成器 我们的长期目标不仅仅是“生成内容”，而是创造一个创作者可以玩耍、迭代和发现新想法的地方，随着模型和技术的发展而不断演变。 我们处于早期阶段，正在积极迭代，非常希望能听到其他独立开发者的反馈，特别是在以下方面： - 功能方向 - 社区机制 - 友好的创作者工作流程 欢迎随时提问！

大家好， 我正在经历一次关于Stripe的重大问题，觉得有必要提醒其他人。 我们租赁车辆，自2017年起开始使用Stripe。我们处理的交易量巨大，到目前为止在Stripe上的支出超过了10亿美元。 我们喜欢Stripe的工具和软件等。但最近，他们的态度更像是黑帮老大，而不是一个供应商，因为他们知道客户已经深陷其中。 随着时间的推移，我们的协议演变为一项多年的最低年费承诺，并采用“企业”定价。在每次续约时，模式都是： Stripe不断提高最低年费。 如果我们没有自然达到这个最低要求，他们期望我们通过附加产品和“可有可无”的功能来弥补差额，以满足承诺。 我们被警告，如果找不到办法达到最低要求，他们可以直接从收入中扣除全额。 在选择Stripe之前，我会考虑以下几点： 1. 让你的集成具有可移植性。不要使用供应商的表单/卡片逻辑。 2. 使用一个可以轻松更换卡片提供商的发票平台。 3. 对于小的年度最低要求要有所抵制，因为他们下次只会提高这个要求，而不是专注于帮助你赚更多的钱，Stripe更关注自身利益。 对任何在Stripe工作的人来说，你们打造了一个很棒的产品，只希望你们能保持让你们走到今天的文化。 祝好运！

嗨，HN，我们是 InspectMind 的 Aakash 和 Shuangling（<a href="https://www.inspectmind.ai">https://www.inspectmind.ai</a>），我们是一款 AI “计划检查器”，可以发现建筑图纸、细节和规范中的问题。 建筑图纸常常存在许多错误：尺寸冲突、协调缺口、材料不匹配、缺失细节等等。这些错误在施工过程中会导致延误和数十万美元的返工。InspectMind 可以在几分钟内审核一个建筑项目的完整图纸集。它交叉检查建筑、工程和规范，以在施工开始前捕捉可能导致返工的问题。 这里有一个包含一些示例的视频：<a href="https://www.youtube.com/watch?v=Mvn1FyHRlLQ" rel="nofollow">https://www.youtube.com/watch?v=Mvn1FyHRlLQ</a>。 在此之前，我（Aakash）创建了一家工程公司，参与了大约 10,000 幢建筑的项目。我们一直感到沮丧的一件事是：许多设计协调问题在施工开始之前并不会显现出来。到那时，错误的成本可能高达 10 到 100 倍，所有人都在忙着修复本可以更早发现的问题。 我们尝试了各种方法，包括检查清单、叠加审查、同行检查，但在 500 到 2000 页 PDF 文档中滚动并记住每个细节与其他页面的连接是一项脆弱的过程。城市审查员和总承包商的预施工团队也在努力捕捉问题，但仍然会有问题漏网。 我们想：如果模型可以解析代码并生成可运行的软件，也许它们也可以帮助我们在纸面上推理建筑环境。因此，我们构建了我们希望拥有的工具！ 您只需上传图纸和规范（PDF 格式）。系统会将它们拆分为不同学科和细节层次，解析几何和文本，并寻找不一致之处：- 各页之间不一致的尺寸；- 被机械/建筑元素阻挡的间隙；- 缺失或不匹配的消防/安全细节；- 从未出现在图纸中的规范要求；- 引用不存在细节的标注。 输出结果是一个潜在问题的列表，包含页面引用和位置，供人工审核。我们并不期望自动化取代设计判断，只是希望帮助建筑、土木工程和电气专业人士不遗漏明显的问题。当前的 AI 在处理明显问题方面表现良好，并且可以处理超出人类准确处理能力的数据量，因此这是一个很好的应用场景。 建筑图纸并没有标准化，每个公司对事物的命名方式也不同。早期的“自动检查”工具在很大程度上依赖于客户手动编写的规则，当命名约定发生变化时就会失效。相反，我们使用多模态模型进行 OCR + 向量几何、跨整个图纸集的标注图、基于约束的空间检查和增强检索的代码解释。再也不需要硬编码规则了！ 我们目前正在处理住宅、商业和工业项目。延迟时间从几分钟到几个小时不等，具体取决于图纸数量。无需任何入门培训，只需上传 PDF 文件。仍然存在许多边缘案例（PDF 提取异常、不一致的图层、行业术语），因此我们从失败中学到了很多，或许比成功学到的还要多。但这项技术已经能够提供以前工具无法实现的结果。 定价采用按需付费的方式：在您上传项目图纸后，我们会立即提供每个项目的在线报价。由于一个项目可能是家庭改造，而另一个可能是高层建筑，因此很难采用常规的 SaaS 定价。我们也欢迎对此的反馈，我们仍在摸索中。 如果您作为建筑师、工程师、机电工程师、总承包商预施工人员、房地产开发商或图纸审查员与图纸打交道，我们非常希望有机会运行一组样本，并听取您的反馈，了解哪些地方出现问题，哪些功能有用，以及哪些功能缺失！ 我们将全天候在这里讨论几何解析、聚类失败、代码推理尝试或关于施工过程中如何出错的真实故事。感谢您的阅读！我们乐意回答任何问题，并期待您的评论！