最新

Nitter.net 和 Xcancel.com 都已被 X Corp 的“停止并终止”信函强制关闭。

我们解决的问题是组织摩擦和可见性问题。随着层级的增加和会议的增多，你离真正了解情况会越来越远。我们构建了一个工具，让任何人只需点击一下按钮，就能看到项目实际的进展情况。无需与人工智能争论，无需解读甘特图。只需一个合理的、人类能理解的解释。 当然，我们一开始不会做到完美。我们专注于做好一件事，让项目经理或总监点击“更新”，就能以他们期望的方式获得更新。这意味着我们需要“了解”他们的项目。为此，我们正在使用人工智能。 我们不期望用户在我们的工具中启动项目，也不期望他们调整现有的工作流程。我们消化一切，然后输出状态更新。这意味着我们的工具在结构上能够像项目经理一样理解事物。有些人可能会说，这意味着我们的工具无法完美契合他们的项目或计划。对此，我想说：“你并没有你想象的那么有独创性。”这意味着人工智能从一开始就具备规则和技能，能够将事物分类并进行自我调整。我们一开始并不花哨，我们提供了 Jira 集成和文档上传功能。 现在，还有调整的空间。通常情况下，这些调整是在人工智能聊天中进行的，而对我们来说，这些调整体现在规则和技能中，以及结构化的提示。但是，用户并不关心这些。相反，当状态更新返回时，他们会进行一两次调整。然后，我们会在后端调整规则，以便下次应用。所以，我们一开始的准确率是 80%，但每次用户使用后都会变得更好。而且，嘿，对于你的项目、你那些不规范的格式和你的语气，80% 的准确率已经相当不错了。 那么，最终结果是什么？对最终用户来说，这意味着他们可以登录工具，点击“运行”，看到它运转片刻，然后获得一个他们可以轻松使用的状态更新。我们提供的是一种“一键生成状态更新”的体验，取代了手动整理文件和项目以获取状态更新，或者更现代化的方式——与 Claude 的输出进行协调、恳求和最终妥协。 简而言之，想象一下这样一个世界：当有人问“有什么更新吗？”，你只需按一下按钮，他们就会自行离开，或者给你所需的信息以继续工作。就是这样。 这里的愿景是什么？我的意思是，如果你在大公司工作过，我们肯定认为在削减状态更新报告中的水分方面，有很大的商机。从这个角度来看，我们的整个愿景是解决公司里人们花费时间最多的项目管理环节。这首先包括状态更新，但将来还会涉及更多内容（例如项目章程、RACI 等）。 想试用我们的 Alpha 版本吗？请通过 logan@quickapproveai.com 或 uzma@quickapproveai.com 与我们联系。

PayPal 应用现在似乎无法在 GrapheneOS 上运行。我不确定这是否仅仅是因为我启用了 PayPal 卡进行非接触式 NFC 支付，但在打开应用时，它会因以下异常而崩溃：com.paypal.oslo.app.rasp.RootDetectionSecurityException: Security policy violation: s=root

我正在为小型技术团队（约 3 名开发人员）在快速开发中使用大型语言模型（LLM）寻求一些建议。 和大多数人一样，我们越来越依赖 LLM 来生成代码。我们在侧边栏使用 Cursor 来严格控制和维护我们应用程序的工程质量标准。 然而，我们发现代码审查正日益成为开发中的一个瓶颈，拉取请求（PR）堆积如山。在过去一年里，代码生成与审查所需的时间平衡已经发生了倾斜。代码审查现在占用的时间比例更高。 我们尝试过集成 CodeRabbitAI 等工具，但并未发现它们是万能的。它们对于报告基本错误和遗漏的测试用例很有用，但通常会忽略与整个应用程序上下文相关的关键问题。 此外，AI 代码审查也未能实现代码审查的重要目标——与团队其他成员共享上下文、理解和所有权。 我担心我们最终会面临一个令人沮丧的矛盾。我们既希望比传统代码审查（即理解）更快地生成新功能，又希望亲自理解正在生成的架构和代码。 因此，我正在寻求建议。你们尝试过哪些有效的方法？在一个代码生成速度比以往任何时候都快​​的专业工程团队中，需要牺牲什么？

在训练大型语言模型时，会面临许多系统挑战，并且可以使用不同的分片方案。尽管市面上有很多关于扩展大型语言模型的优秀资源（例如 <a href="https://huggingface.co/spaces/nanotron/ultrascale-playbook" rel="nofollow">https://huggingface.co/spaces/nanotron/ultrascale-playbook</a> 或 <a href="https://jax-ml.github.io/scaling-book/" rel="nofollow">https://jax-ml.github.io/scaling-book/</a>），但我认为在可视化不同形式的并行化以及建立分布式训练中重叠和执行顺序的直观理解方面，仍然存在不足。 其想法是让可视化 FSDP/张量并行/专家并行/上下文并行并进行推理变得更容易——您可以拖放计算内核和集合操作，根据真实的 torchtitan 配置文件创建 DDP/TP/FSDP/EP/CP 追踪。