最新

我对人们在拉取请求（PR）代码审查中与人工和自动化审查者的经历很感兴趣。<p>对于那些使用过PR审查工具或机器人的人：<p>你们觉得哪些方面实际上是有帮助的？<p>哪些又让人感到烦恼或适得其反？<p>在什么情况下你们开始不再关注反馈？<p>我特别想了解人们在审查中如何平衡信号与噪声，以及总结、内联评论或选择性深入讨论在实践中哪种效果更好。<p>我只是想了解真实的使用模式和痛点，并不是为了推广任何东西。很高兴倾听大家的分享。

我创建Vect是因为我厌倦了“随机营销行为”和同时使用15个不相关的工具（文本的LLM、独立的图像生成器、用于规划的电子表格）。我希望有一个统一的系统——一个操作系统——而不仅仅是一个外壳。 我们拒绝成为另一个“文本生成器”，而是基于三个架构支柱构建了Vect： 策略（大脑）：利用实时网络搜索和用户心理模拟进行研究和规划的代理。 执行（双手）：高保真模型（视频使用Veo，图像使用Imagen）的原生集成，以完成实际工作。 自动化（劳动力）：一个“状态感知”的代理系统。通过持久的“品牌档案”，所有代理共享对您的语气、受众和产品的记忆——消除了重新提示上下文的需要。 我们的目标是通过让代理在后台进行繁重的工作，将“创意”转变为“执行的营销活动”，只需几分钟。 我们在这里写了一份关于架构和信用经济的完整指南：<a href="https://blog.vect.pro/vect-ai-bible-guide" rel="nofollow">https://blog.vect.pro/vect-ai-bible-guide</a> 非常期待对代理编排方法的反馈！

嗨，HN， 我来自Nuon团队。在构建“自带云”（BYOC）领域时，我们意识到没有像awesome-selfhosted.net那样的集中式、社区驱动的资源，专门用于管理客户VPC中的软件。 我们希望软件供应商能够提交PR，添加他们的BYOC产品。

我开发了一个小型Linux工具，用于确定性地验证GPU PCIe链接的健康状况和带宽。<p>该工具报告以下内容： - 协商的PCIe代数和宽度 - 主机到设备（Host→Device）和设备到主机（Device→Host）的内存拷贝带宽峰值 - 通过NVML获取的持续PCIe发送（TX）/接收（RX）利用率 - 基于可观察硬件数据得出的规则性判断<p>之所以开发这个工具，是因为PCIe问题（如代数降级、通道宽度减少、扩展卡、分叉）通常在应用层是不可见的，且无法通过内核调优或异步重叠来解决。<p>仅限Linux：该工具依赖于sysfs和PCIe AER暴露，而Windows并不提供这些功能。