最新

嘿，HN！我们是 Charles 和 Dean，我们正在构建 Stage：一个代码审查工具，它引导你逐步阅读 PR，而不是拼凑一个巨大的 diff。<p>这里有一个演示视频：<a href="https:&#x2F;&#x2F;www.tella.tv&#x2F;video&#x2F;stage-demo-1pph" rel="nofollow">https:&#x2F;&#x2F;www.tella.tv&#x2F;video&#x2F;stage-demo-1pph</a>。 你可以在这里试用一些示例 PR：<a href="https:&#x2F;&#x2F;stagereview.app&#x2F;explore">https:&#x2F;&#x2F;stagereview.app&#x2F;explore</a>。<p>如今，随着 AI 的发展，团队的行动速度比以往任何时候都快，但越来越多的工程师合并了他们并不真正理解的更改。瓶颈不再是编写代码，而是审查代码。<p>我们是两个对 GitHub 的代码审查 UI 感到沮丧的工程师。随着编码助手的兴起，我们看到我们的 PR 积压速度比我们能处理的还要快。不仅如此，PR 本身也变得越来越大，越来越难以理解，我们发现自己大部分时间都花在试图构建一个关于 PR 实际做了什么的心理模型上。<p>我们构建 Stage 是为了让审查 PR 感觉更像是阅读书中的章节，而不是一组无序的段落。我们现在每天都在使用它，不仅审查彼此的代码，也审查我们自己的代码，而且在这一点上，我们真的无法想象回到旧的 GitHub UI。<p>Stage 的功能：当打开一个 PR 时，Stage 会将更改分组为小的、逻辑上的“章节”。这些章节按照最合理的阅读方式进行排序。对于每个章节，Stage 会告诉你更改了什么以及需要仔细检查的具体内容。一旦你审查了所有章节，你就完成了对 PR 的审查。<p>你可以使用你的 GitHub 账户登录 Stage，所有内容都会无缝同步（评论、批准等），因此它适合你已经习惯的工作流程。<p>我们没有构建什么：像 CodeRabbit 或 Greptile 这样的代码审查机器人。这些工具非常适合捕捉错误（我们自己也在使用它们！），但归根结底，人类要对最终发布的内容负责。很明显，代码审查的规模并没有像编写代码那样扩大，他们（我们！）需要更好的工具来应对 AI 生成代码的猛增，而这种增长只会越来越快。<p>我们构建这个工具非常开心，并很高兴能更进一步。如果你和我们一样，也厌倦了使用 GitHub 审查 PR，我们很乐意让你试用一下，并告诉我们你的想法！

Mulligan Labs 是一个基于浏览器的万智牌测试平台。无需注册或安装。只需创建房间，分享链接，从 Archidekt 或 Moxfield 导入牌表，然后用鼠标和键盘进行游戏（目前对移动设备的支持不太好）。 技术栈：基于 Cloudflare Workers 的 SvelteKit，使用 PartyKit (Durable Objects) 作为权威的游戏服务器。客户端通过 WebSocket 提交操作；服务器验证并广播状态。 背景介绍：我主要负责网络方面，我的联合创始人是工业设计出身——我们俩之前都没有发布过类似的代码库。我们在过去的 5 个月里，在 Claude 的大力协助下完成了这个项目。很乐意在评论中分享具体细节。 虽然有些地方还比较粗糙（目前的牌组构建器还差强人意），但核心的多人游戏循环是可靠的，我们和指挥官牌友们一起玩了大量的游戏。我们非常欢迎反馈，特别是来自玩过 Cockatrice/XMage/Untap 的玩家，他们对浏览器原生版本应该是什么样的体验有自己的看法。

嗨 HN， 在这个代理编码的时代，我发现自己花了很多时间来审查 Markdown 文件。 无论是计划还是文档，都是我让我的代理生成的，我似乎花在阅读 Markdown 上的时间比代码还多。 我尝试过一些不同的解决方案来使其更易于阅读，例如 Obsidian，但我发现它们的 Vault 系统对于这种用例来说非常有限，而且我发现 TUI 解决方案不像我希望的那样易于阅读，所以我制作了 Marky。 Marky 是一个轻量级的桌面应用程序，可以让你非常轻松地阅读和跟踪你的 Markdown 文件。它还有一个有用的 CLI，所以你只需运行 marky FILENAME 就可以让应用程序打开你指向的 md 文件。在过去的一周里，我每天都在使用它，而且我真的很喜欢它，所以我想分享一下。 如果你想查看演示，这里有一个视频：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=nGBxt8uOVjc" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=nGBxt8uOVjc</a>。 我计划添加更多功能，例如将代理工具（如 claude code 和 codex）整合到 UI 中，以及开发一个本地 git diff 审查器，以便在推送到 git 之前进行本地代码审查。 我很乐意听取你的想法和任何功能建议 :)

我在 Python 标准库中发现了一些出乎意料的不安全因素。 如果你对不受信任的 ZIP 文件使用 zipfile.extractall() 函数，你基本上是在信任： * 文件路径不会逃逸你的目标目录 * 归档文件不是巨大的 ZIP 炸弹 * 不存在诸如符号链接或嵌套技巧之类的奇怪边缘情况 事实证明……这些都无法保证。 所以我最终构建了一个小的“安全提取”包装器，它： * 阻止路径穿越（Zip Slip） * 强制执行总的未压缩大小限制 * 限制文件数量 * 避免在目标目录之外进行提取 没什么特别的，只是应该开箱即用的防御性默认设置。 在这里写了一个简短的分解 + 代码： [https://hivesecurity.gitlab.io/blog/zipguard-safe-zip-extraction-python/](https://hivesecurity.gitlab.io/blog/zipguard-safe-zip-extraction-python/) 好奇其他人是如何处理这个问题的——你们是自己编写检查，还是依赖其他东西？