最新

我们接到了一份模糊的客户请求，内容是“团队生产力仪表板”，并将其通过两种不同的探索流程进行分析：一种是传统的人类分析师方法，另一种是基于人工智能的询问工作流程。 结果令人不安。人类分析师生成了一段礼貌的文字，总结了“理想路径”。而人工智能则生成了一份包含127条技术规范的文档，突出了每一个边缘案例、安全漏洞和我们通常会在第8周才想起的缺失功能。 以下是实验的详细分析，以及我认为“范围蔓延”主要是探索失败的原因。 问题：假设盲点 我们都经历过“第8周危机”。当你完成了12周开发的75%时，客户突然问：“用户管理的管理面板在哪里？”开发团队认为这超出了范围；而客户则认为这是隐含的，因为“所有应用都有登录功能”。 人类具有较高的上下文理解能力。当我们听到“仪表板”时，我们假设有标准的身份验证、标准的错误处理和标准的规模。我们不会把这些写下来，因为这感觉很啰嗦。 而人工智能没有上下文。它不知道“身份验证”是隐含的。它也不知道我们对原型的速率限制并不在意。因此，它会询问。 实验 我们将相同的输入提供给了一位资深人类分析师和一个作为技术询问者的LLM工作流程。 输入：“我们需要一个仪表板来跟踪团队生产力。它应该从Jira和GitHub中提取数据，并显示谁在阻碍谁。” 路径A：人类分析师 输出：约5个要点。 关注于用户界面和“商业价值”。 假设：标准的Jira/GitHub API、单租户、标准安全性。 结果：一份简洁、易读但技术上空洞的总结。 路径B：人工智能询问者 输出：127条独特的技术要求。 关注于：失败状态、数据治理和边缘案例。 结果：一份庞大、乏味但详尽的文档。 结果 数量差异（5对127）令人震惊，但内容差异才是关键。人工智能明确列出了人类完全“盲点”的要求： - 细粒度的RBAC：“如果一名初级开发者试图删除一个仓库链接，会发生什么？” - API速率限制：“我们如何处理同步过程中来自GitHub的429错误？” - 数据保留：“我们是否无限期存储Jira票据？是否有清除政策？” - 空状态：“对于一个没有任何票据的新用户，仪表板会是什么样子？” 人类的规范暗示这些是“实现细节”。而人工智能则将其视为要求。在我的经验中，将RBAC视为实现细节正是项目超预算的原因之一。 权衡与局限性 公平地说，阅读一份127条的规范是非常痛苦的。这里存在严重的信号与噪声问题。 - 膨胀：人工智能可能过于死板。它建议将微服务架构用于应该是单体的项目。它在不存在复杂性的地方产生了幻觉。 - 瘫痪：将一份127条的清单交给开发者作为原型的指导，绝对是打击士气的好方法。 - 过滤：你仍然需要人类来查看清单并说：“我们还不需要多租户，删除第45-60条。” 然而，我宁愿在项目开始时删除20个不必要的要点，也不愿在发布前两周发现20个缺失的要求。 讨论 这个实验让我意识到，我们对编写规范的厌恶，以及对“隐含”上下文的依赖，是技术债务的主要来源。人工智能之所以有用，不是因为它聪明，而是因为它足够细致，能够提出我们认为太显而易见的问题。 我很好奇其他人是如何处理这个“隐含要求”问题的： 1. 你是否有一份关于RBAC/身份验证/速率限制等的清单可以重复使用？ 2. 一份100+条的规范真的有帮助吗，还是只是提前引发争论？ 3. 你如何从“人工智能噪声”中筛选出关键的缺失规范？ 如果有人想查看我们用来触发这种“询问者”模式的具体提示，我很乐意在评论中分享。

我依赖的工具变得太贵了，所以我自己构建了一个替代品。<p>这个工具完全免费且开源，我分享它是希望能帮助到其他人。<p>如果你试用后有任何反馈，我非常欢迎。功能建议也很受欢迎，请提出你希望看到的功能。 如果你觉得这个工具有用，给我的仓库点个星对我来说意义重大——这是我第一次参与开源项目 :)<p>谢谢！

TerminalPhone 是一个单一的、自包含的 Bash 脚本，提供通过 Tor 网络进行匿名、端到端加密的语音和文本通信。它的工作方式类似于对讲机：您录制一条语音消息，该消息会被压缩、加密，并作为一个整体传输给远端的接收方。在通话期间，您还可以发送加密的文本消息。无需服务器基础设施，无需账户，无需电话号码。您的 Tor 隐藏服务 .onion 地址就是您的身份。

好吧，这一切终于发生了。在无尽的发布候选版本之后，我们终于达到了 v0.1.0。 内容包括： - 基于 WebGPU 着色器的 GPU 加速渲染，支持阴影，以及轮廓边缘和特殊的柔光模式等功能。 - 核心操作的速度比原始的 PyMOL 快了多达 1000 倍。以前需要你去喝咖啡的表面生成，现在只需按一下按钮就能完成。 - 完整的 PyMOL 选择代数支持——95 个以上的关键字、布尔逻辑、距离/扩展运算符、斜杠宏。 - 距离、角度和二面角测量，原子标签——结构分析所需的一切。 - Python API——从 `pymol_rs import cmd` 开始，你会感到如鱼得水。 - 支持 PDB、mmCIF、BinaryCIF、SDF/MOL、MOL2、XYZ、GRO 格式——读写、自动格式检测、透明的 gzip 解压缩。 - 场景、电影、光线追踪——全部在 GPU 上进行。 - Kabsch 超位、CE 对齐、RMSD、DSS、所有 230 个空间群的对称性。 - 在 PyMOL 的 798 个原始设置中，有一些实际上是有效的。具体有多少没有人知道，但肯定在几百个以上。此外，我们还添加了一些原版没有的新设置——例如每链的表面生成。 - 13 个独立的 crate——如果你在编写 Rust，可以只使用选择解析器、文件读取器或完整的 GUI。没有单一的庞然大物。

嗨，HN， 我是Bereket，Better Auth的创始人。我们的团队每天在GitHub上花费大量时间。和所有在那待过的人一样，我一直希望能有更好的GitHub体验。 我问过很多人是否能对此做些什么，但似乎没有人真正直接解决GitHub的问题。 几周前，我看到Mitchell（HashiCorp）在推特上抱怨仓库主页。这成为了我的触发点。我决定开始制作一个原型，看看通过GitHub的API我能推动一个替代界面到什么程度。 不到一周，我真的开始将其作为我的默认工具，团队的其他成员也是。在修复了一些小问题后，我决定将其发布出来。 我们希望实现的几件事情： - UI/UX重新思考：重新设计的仓库主页、PR审查流程和概览页面，专注于信号而非噪音。更快的导航和更清晰的结构。 - 以键盘为中心的工作流程：⌘K驱动的指令中心，⌘/进行全局搜索，⌘I打开“Ghost”，一个AI助手，等等。 - 更好的AI集成：上下文感知的AI，能够理解仓库、你正在查看的PR和你正在查看的差异。 - 新概念：提示请求、自愈CI、自动合并及自动冲突解决等。 这是一个简单的Next.js服务器，连接到GitHub API，具有强大的缓存和本地状态管理。 我们正在考虑可选的git托管（与构建替代后端的团队合作），但目前的实验是：在不替换GitHub的情况下，我们能改善多少。 这是一个雄心勃勃且非常早期的项目。目标是探索更现代的代码协作体验可能是什么样子，并使其成为我们都能共同协作的东西。 我很想听听你们对GitHub整体上应该改进的地方的反馈。