最新

嘿，HN！我们是查尔斯和迪恩，我们正在开发Stage：一个代码审查工具，它引导你逐步阅读拉取请求（PR），而不是拼凑一个巨大的差异文件。 这里有一个演示视频： [https://www.tella.tv/video/stage-demo-1pph](https://www.tella.tv/video/stage-demo-1pph)。你可以在这里尝试一些示例PR：[https://stagereview.app/explore](https://stagereview.app/explore)。 如今，团队借助AI的帮助比以往任何时候都要快，但越来越多的工程师正在合并他们并不真正理解的更改。瓶颈不再是编写代码，而是审查代码。 我们是两名对GitHub的代码审查界面感到沮丧的工程师。随着编码代理的兴起，我们发现我们的PR积压比我们能处理的速度还要快。不仅如此，PR本身也变得越来越大，难以理解，我们发现自己大部分时间都在试图构建一个关于PR实际做了什么的心理模型。 我们构建Stage是为了让审查PR的过程更像是阅读一本书的章节，而不是一组杂乱无章的段落。现在我们每天都在使用它，不仅用来审查彼此的代码，也用来审查自己的代码，此时我们真的无法想象回到旧的GitHub界面。 Stage的功能是：当一个PR被打开时，Stage会将更改分组为小的、逻辑上“章节”。这些章节会按照最合理的顺序排列。对于每个章节，Stage会告诉你哪些地方发生了变化以及需要特别注意的事项。一旦你审查完所有章节，就完成了PR的审查。 你可以使用你的GitHub账户登录Stage，所有内容都能无缝同步（评论、批准等），因此它融入了你已经习惯的工作流程中。 我们不打算开发的东西：像CodeRabbit或Greptile这样的代码审查机器人。这些工具在捕捉错误方面非常出色（我们自己也在使用！），但归根结底，人类对最终发布的内容负责。显然，代码审查并没有像编写代码那样实现规模化，而我们（他们！）需要更好的工具来跟上AI生成代码的洪流，这种情况只会越来越严重。 我们在构建这个工具的过程中非常开心，并期待将其进一步发展。如果你和我们一样，也厌倦了使用GitHub来审查PR，我们非常希望你能试试，并告诉我们你的想法！

Mulligan Labs 是一个基于浏览器的《万智牌：聚会》测试平台。无需注册或安装。只需创建一个房间，分享链接，从 Archidekt 或 Moxfield 导入牌组，然后使用鼠标和键盘进行游戏（目前移动端支持不太理想）。 技术架构：使用 SvelteKit 和 Cloudflare Workers，PartyKit（持久对象）作为权威游戏服务器。客户端通过 WebSocket 提出操作；服务器验证并广播状态。 前言：我的背景是网络技术，而我的联合创始人则是工业设计——我们之前都没有发布过这样的代码库。我们在过去的五个月里在 Claude 的大力协助下构建了这个平台。欢迎在评论中讨论这段经历的具体情况。 在某些地方仍显粗糙（目前的牌组构建器还算一般），但核心的多人游戏循环非常稳固，我们已经和我们的指挥官小组在上面玩了很多场游戏。我们非常希望收到反馈，尤其是来自那些玩过 Cockatrice/XMage/Untap 并对浏览器原生版本应该是什么样有看法的玩家。

嘿，HN， 在这个代理编码的时代，我发现自己花了很多时间在审阅Markdown文件上。无论是我让代理生成的计划还是文档，似乎我花在阅读Markdown上的时间比阅读代码还要多。 我尝试过一些不同的解决方案来使阅读更容易，比如Obsidian，但我发现它们的Vault系统在这个用例上相当有限，而TUI解决方案又没有我想要的那么友好，因此我制作了Marky。 Marky是一个轻量级的桌面应用程序，使阅读和跟踪Markdown文件变得非常简单。它还提供了一个实用的命令行界面，你只需运行`marky FILENAME`，应用程序就会打开你指定的md文件。在过去的一周里，我每天都在使用它，我非常喜欢，所以我决定分享一下。 如果你想查看演示，这里有一个视频链接：[https://www.youtube.com/watch?v=nGBxt8uOVjc](https://www.youtube.com/watch?v=nGBxt8uOVjc)。 我计划添加更多功能，比如将代理工具（如Claude Code和Codex）整合到用户界面中，以及开发一个本地Git差异审查器，以便在推送到Git之前进行本地代码审查。 我很想听听你们的想法以及任何功能建议 :)

我在Python的标准库中发现了一些令人意外的不安全之处。<p>如果你在不可信的ZIP文件上使用zipfile.extractall()，实际上你是在信任以下几点：<p>文件路径不会逃逸到目标目录之外<br>压缩文件不是巨大的ZIP炸弹<br>没有奇怪的边缘情况，比如符号链接或嵌套技巧<p>结果是……这些都没有得到保证。<p>因此，我最终构建了一个小型的“安全提取”包装器，能够：<p>阻止路径遍历（Zip Slip）<br>强制限制总解压缩大小<br>限制文件数量<br>避免在意图之外的目录中提取<p>这并不复杂，只是一些防御性默认设置，实际上应该是开箱即用的。<p>我在这里写了一篇简短的分析和代码：<br>https://hivesecurity.gitlab.io/blog/zipguard-safe-zip-extraction-python/<p>我很好奇其他人是如何处理这个问题的——你是自己实现检查，还是依赖其他方法？