得分65.2%，相比谷歌官方的47.8%以及现有顶级闭源模型Junie CLI的64.3%有显著优势。<p>由于最近有很多关于TerminalBench 2.0故意作弊的报告（<a href="https://debugml.github.io/cheating-agents/" rel="nofollow">https://debugml.github.io/cheating-agents/</a>），我想澄清几点<p>1. 在任何时候都没有插入{agents/skills}.md文件，绝对没有任何作弊机制<p>2. CLI代理是以符合排行榜的方式运行的（没有修改资源或超时设置）<p>3. 完整的终端基准测试是使用完全开源版本的代理进行的，GitHub上的版本与实际运行的版本没有区别。<p>我原本打算等它上榜后再发布，但已经过去8天了，维护者不幸没有回应（他们的HF上有大量待处理的拉取请求），所以我决定还是发布出来。<p>HF PR: <a href="https://huggingface.co/datasets/harborframework/terminal-bench-2-leaderboard/discussions/145" rel="nofollow">https://huggingface.co/datasets/harborframework/terminal-bench-2-leaderboard/discussions/145</a><p>根据我进行的这次和其他实验，工具的影响力是惊人的。
返回首页
最新
我觉得用 YubiKey 点击来玩“饼干点击器”可能会很有趣，这只是一个概念验证。Cloudflare 在 2021 年做过类似的事情，提出用 YubiKey 验证的点击作为验证码的替代方案：<p><a href="https://news.ycombinator.com/item?id=27141593">https://news.ycombinator.com/item?id=27141593</a><p>当时，Cloudflare 用 YubiKey 点击来证明身份的想法并没有受到好评。但在这里，对于一个搞笑的游戏，我认为这个想法更具可行性。我们可以证明你有一把钥匙，并且多次点击了它。如果你能自动激活物理钥匙上的触摸传感器，可能会做得更好。这很酷，你值得赢。
中国阻止外国收购人工智能初创公司Manus
[了解更多信息](https://www.reuters.com/world/asia-pacific/china-blocks-foreign-acquisition-ai-startup-manus-2026-04-27)
[点击这里查看相关报道](https://www.bbc.com/news/articles/cj0v0gr2yz7o)
在设计这个电子表格工具时，我意识到我从来没有考虑过键位绑定。这一切都自然而然地来自于 Vim。正常模式/插入模式/可视模式，hjkl 导航，dd/yy/p，:w，:q。习惯的肌肉记忆依然有效。
它支持 CSV/TSV 的导入和导出，以及一种原生的 .cell 格式，可以保留公式。公式引擎支持 SUM、AVERAGE、COUNT、MIN、MAX 和带范围引用的 IF。
代码库是一个 Cargo 工作区：一个纯粹的 cell-sheet-core 库（没有 TUI 依赖）和一个基于 ratatui 的 cell-sheet-tui crate。虽然还处于早期阶段，但已经可以使用。
要尝试它：
cargo install cell-sheet-tui
任何反馈都非常感谢！
嗨，HN，
我已经在这个项目上工作了一段时间，决定何时停止并不容易，无论是信息的呈现方式还是何时停止添加条目。这个项目并不是一个博客，而是一个不断增长的参考资料。
链接： [https://thehardparts.dev](https://thehardparts.dev)
目前我创建了四个主要部分：
- 失败模式：项目出错的方式
- 警示信号：值得认真对待的早期信号
- 技术决策：常见和不常见的艰难选择权衡
- 行动手册：针对重复出现情况的指导方法
我还专注于在它们之间建立联系，以展示许多事物之间的关联：警示信号通常会在失败模式之前出现，而失败模式可能与被迫决策相关联，等等。
以下是一些条目的示例，以便让你了解内容：
- 看不见的截止日期：一个在社会上存在但不够明确以便诚实管理的日期
- 每个人都问同一个人：当一个人变成默认的真相来源时
- 建立实用的回滚策略：如何构建一个可靠的回滚策略
目前在这四个部分中共有151个条目。
我很想知道你对内容、格式和分组的看法。
在这里的一些评论线程中，有几位分享了有趣的想法和模式，足以让我相信，所有对马达工程感兴趣的人都在开发某种软件“黑工厂”。<p>我们有OpenAI的Symphony[1]、StrongDM的Factory[2]、Yegge的GasTown[3]，还有可能有我遗漏的一些其他项目。<p>所以我很好奇，你们在做什么？你们学到了什么？什么是有效的，什么又是失败的？你们认为接下来会发生什么？<p>我先来分享。让我获得有趣结果的第一件事是，在可能的情况下，为模型提供一个真实的基准或参考，以便进行迭代：例如，UI工作的截图或模型，逻辑的API合同和单元/集成测试。这就是我们都熟知并喜爱的Ralph Loop——一个反馈循环。<p>第二个（显而易见，我知道）是将规划和实施分开。<p>接下来是其他模型的评审和迭代循环，取得了可观的成果。然而，实施代理往往会通过将事情推迟到无尽的未来或声称实际上重要的反馈超出了范围而逃避责任。又一个反馈循环。我发现将这些评审转化为“硬性关卡”会带来一系列问题，因为评审代理总会找到一些细枝末节的问题，使得这种迭代实施方法变成近乎无限的循环。<p>将这些评审与代码一起提交计划，导致了一个有趣的意外：评审代理自发且意外地关注这些内容，并通过比较计划和实施大幅改善了他们的反馈（这本该是显而易见的，你可以想象当GitHub Copilot第一次提供有用反馈而不是通常的拼写错误挑剔时，我的惊讶）。<p>然后这里的一条评论让我想到了一个对抗性的绿色团队/红色团队流程。<p>第一个代理根据我的初步计划创建一个规范（基于StrongDM的NLSpec），并进行评审，包括详细的API。<p>红色团队代理根据这些规范编写单元和集成测试，并进行评审。<p>然后，一个绿色团队代理获得这些相同的规范和API，实施实际的功能或修复，并在没有任何测试访问权限的情况下进行迭代，只知道哪些测试失败以及它们测试的内容。这防止了它对测试的操控。<p>最后，一旦测试通过，评审代理会根据规范对实施进行评审。<p>这个流程很不错。它允许混合和匹配模型、思维层次和提供者。但绿色团队和红色团队有时会偏离初始规范和API，有时是有正当理由的。<p>因此，引入了另一个代理来评估这些偏差，并在它们是有效的改进时，从规范生成点重新启动流程，结合新的见解。又一个反馈循环。<p>最后，将日志、OTel跟踪和堆栈跟踪整合到流程中。这些代理似乎在筛选这些信息方面表现得非常出色，端到端的可观察性显著改善了结果。同样，又是一个反馈循环。<p>这就是我目前的分享。期待看到其他人对此的分享！