L站有开源代码不 没有的话佬们有没有啥推荐，老板让在公司内网搭个AI交流论坛，二级部门一千人规模，公司一万＋规模 11 个帖子 - 7 位参与者 阅读完整话题
前期工作，通过对一款软件源代码和claude code 对话讨论功能后，使用自定义的skill /to-prd 让其总结对话功能，输出prd，然后使用自定义的 project-task-planner (agent)拆分成为详细重构任务， 这些都是在github遇到觉得好用的skill或者 agent 接着怕任务太多，拆分出plan目录和进度追踪progress.csv ，其实看情况，可以不做这一步的。 然后再定义一个git commit agent ，在CLAUDE.md文件说明任务总览，进度跟踪，自动提交之间关系。就使用 /goal 命令，自动跑。前期做了架构限制和目录说明，这里就不过多干预，直接一把梭哈，今天早上看了一下可以收菜了 [!info]重构基础版效果展示 中途网络有波动，人工干预了一下，总体效果还是不错的总耗时 2小时上半场，4下半场，从/goal 开始计算时间。 1 个帖子 - 1 位参与者 阅读完整话题
为获得质量更高且数量庞大的优质代码库训练人工智能模型，Google现在希望向 Google Play 应用商店的开发者们付费，购买开发者的应用程序代码库访问权限用来改进开发工具，Google的想法是通过非独占许可让开发者可以继续保留代码的知识产权，Google通过付费“借用”开发者的优质代码。 目前已经有开发者收到来自Google的机密电子邮件，Google在邮件中宣传这项计划的诸多好处，例如帮助Google开发者工具和产品、支持开发者生态系统等，当然大部分好处都是Google的，对开发者来说最有实际意义的就是可以通过该计划获得额外的收入。 Google在机密邮件中表示： 获得项目外收入：分享你的应用程序代码库访问权限以及你的存档项目即可获得丰厚的报酬。 成为早期采用者：作为试点合作伙伴，您将塑造Google未来与开发者社区的合作方式。 提升实际影响力：代码对我们的产品和服务开发都大有裨益，您测试过的代码可以为我们直接提供帮助。 保留代码控制权：这是非独占协议，您将保留 100% 的知识产权，代码仍然属于您，您可以保留数据货币化的权利。 目的是提高 Gemini 代码生成能力： Google的 Gemini 模型落后于竞争对手的原因有很多，这些竞争对手产品在开发环境中的采用率更高，例如 Claude Code 专注于智能编码被诸多开发者和企业用户采用；Codex 目前也获得超过 500 万名开发者并帮助开发者开发项目；GitHub Copilot 实时自动补全与 IDE 无缝集成，可以快速生成开发模板等。 在智能编码领域 Gemini 模型和Google反重力工具的采用率不温不火，常规 AI 对话聊天用户的增长无法改变 Gemini 的窘境，Google也意识到差距所以正在积极弥合差距，当然这也意味着互联网上公开的代码库无法满足Google需求，作为搜索引擎提供商，Google掌握着互联网上的海量免费资源索引，但Google更希望获得优质应用程序的源代码。 目前Google正在向少量优质应用程序的开发者发送电子邮件宣传这项计划，可能不同应用程序的代码库可以获得的报酬不同，截至本文发布时目前还未看到有任何开发者透露已经参与该项目和提供具体的报酬数字。 查看评论
IT之家 6 月 3 日消息，《辐射》系列自 2008 年 B 社接手后变身为一款现代 RPG，也因此登陆了游戏主机平台，不过黑岛时代的《辐射 2》等作只能通过 PC 平台游玩，从未推出过官方主机版。 而根据外媒 Windows Central 报道，一位爱好者 @dtoxmilenko 正在逆向《辐射 2》源代码，将本作以“自制游戏”形式移植到初代 Xbox 主机上。 据介绍，这名爱好者使用了 Xbox 破解社区传奇开发者 Xport 在 20 多年前制作的模拟器框架，在保留原版玩法基础上整合了大量引擎修复与体验优化内容。目前该移植版已经可以运行游戏开场动画、主菜单、脚本系统、画面渲染以及基础战斗功能。不过项目仍处于初期阶段，游戏音频、存档读取等功能尚未完成测试。 尽管如此，这个项目依然让不少老玩家感到兴奋。如果后续开发顺利，未来甚至还有可能看到《辐射》初代以及《辐射：战略版》也被搬上初代 Xbox 游戏机。
有几个平时经常做操作的网页，现在想对这几个网页cli话，不知道有啥好的办法吗？ 4 个帖子 - 4 位参与者 阅读完整话题
前情提要 知名AI终端Warp正式开放源代码 前沿快讯 [image] 开源的威力开始显现，多项内容更新已经合并到官方仓库。（开源好啊，开源都是免费劳动力） 而现在， 官方正式宣布在warp中支持用户自定义的api 。 今天，我们发布了 Warp 社区最希望看到的更新之一：对推理过程的更多控制权。 开发者希望能够自行选择模型、使用自己的服务提供商账户、掌控推理成本，并且无需离开 Warp 平台即可尝试新的服务提供商。从今天开始，我们将进行两项改进，让 Warp 变得更加灵活： BYOK 功能现在也适用于免费套餐用户。 Warp 现在支持与 OpenAI Chat Completions API 兼容的自定义推理端点。 现在，你可以使用自己的 OpenAI、Anthropic 或 Google API 密钥来为 Warp 的代理功能提供支持。或者，你也可以将 Warp 与兼容 OpenAI 的终端节点相连，比如 OpenRouter、LiteLLM、z.ai，或是你自己的内部处理系统。 为什么偏偏是现在？ 我们最近将 Warp 客户端开源了，因为我们希望 Warp 能变得更加开放、可定制，同时也能更好地符合开发人员的实际使用习惯。让用户自行开发推理引擎来驱动 Warp Agent，也是这一目标的一部分。 在 Warp 中，使用 Warp Agent 依然是利用人工智能的最简单便捷的方式。该插件直接集成在 ADE 中，因此无需额外设置即可利用终端状态、代码库、规则、笔记本、工作流程、环境变量以及 MCP 服务器等资源。此外，Warp Agent 还能与 Warp 的代码审查、智能体管理功能以及 Oz 云平台完美配合使用。 同时，模型层应具备更高的灵活性。开发者应能够根据自己的需求，选择最适合的推理方式来使用 Warp Agent。目前，Warp 尚未原生支持某些特定的模型配置、自定义的路由规则、提供者设置、内部网关功能，也无法处理与模型提供者相关的现有协议和约定。 Warp 应能提供一套完整的智能体开发解决方案。开发者应能够自行选择相应的推理方式。 今天有哪些可用资源/服务呢？ BYOK 功能原本只在 Warp 的付费套餐中提供，现在我们也将其纳入了免费套餐中。免费用户可以为自己选择的合作伙伴添加 API 密钥，这些合作伙伴包括 OpenAI、Anthropic 和 Google。用户可以利用这些 API 密钥来提升 Warp 的智能体功能。在免费套餐中，使用 BYOK 功能需要登录账号，但个人用户可以免费使用该功能。 Warp 现在还支持与 OpenAI Chat Completions API 兼容的自定义推理端点。你可以利用这一功能，将 Warp 与模型路由器、网关、托管服务提供商、内部端点或自托管的推理系统相连接。 如果你有如下需求，自定义推理端点会非常有用： Warp 目前还不支持直接使用该模型提供程序。 通过模型路由器或网关来处理请求路径。 尝试使用自己托管或自行搭建的推理系统来进行实验。 我们希望开发者和各个团队能以各种方式来利用这一工具。我们很期待看到人们会用它来创造出什么新的东西。 定价的运作方式 对于个人开发者和小型团队来说，在 Warp 平台上使用自带的 API 密钥或自定义推理端点是完全免费的。无论您使用的是 Free、Build 还是 Max 套餐，只要您使用的是自带的 API 密钥或兼容的推理端点，且该服务是为个人或人数不超过 10 人的公司所使用，Warp 都不会收取任何费用。 对许多开发者来说，Warp 提供的集成式推理功能仍然是最简单的选择。Warp 允许用户无需任何额外设置，即可使用 OpenAI、Anthropic 和 Google 等提供商的优质模型，以及各种顶级的开源模型。我们还负责与各模型提供商的沟通协调、确保模型的可用性、处理数据传输事宜，并保障数据隐私。由于 Warp 能从模型提供商那里获得批量采购折扣，因此使用 Warp 的积分来使用这些先进模型，是一种既方便又经济高效的方式，用户无需再分别管理各个提供商的账户、API 密钥、账单或端点配置。 BYOK 和自定义端点适用于那些希望掌控推理过程的开发者。他们可以自由尝试 Warp 目前还不支持的各类服务提供商和模型。而“打包式推理”则适合那些希望让 Warp 来处理模型访问和基础设施相关工作的开发者。 对于员工人数超过 10 人的公司而言，使用自带设备或自定义终端的方式，必须通过 Warp 的“Business”或“Enterprise”套餐来实现。规模较大的团队则将 Warp 的托管服务作为整个平台解决方案的一部分来使用：该平台还提供工具协调、上下文管理、团队使用情况监控、管理控制、治理机制、安全策略等功能，同时还能满足在整个组织内部署 AI 智能体的基础设施需求。 对于企业和商业客户而言，如果自行处理推理任务，将会消耗平台积分。这些积分是根据智能体在 Warp 的托管系统中实际运行所花费的时间来计算的，而非与模型推理本身相关的成本。由于客户自行提供模型、API 密钥或端点，因此使用这种方式时，所消耗的 Warp 积分远远低于 Warp 直接提供模型推理服务时的消耗量。 接下来要做什么呢？ 从长远来看，开发人员和团队不会再只使用某一种模型、某个供应商或某一种工具。他们会根据具体的任务需求、成本、延迟、安全要求以及执行环境来选择合适的方案。Warp 应该能成为应对这种需求的最佳接口。 接下来，我们计划将一个轻量级的 Rust 客户端工具添加到我们的开源代码库中。这样一来，Warp 就能直接与本地模型进行连接，而无需经过 Warp 的服务器中转。我们还计划支持 Agent Client Protocol，这样开发者就可以将其他客户端工具集成到 Warp 的终端用户界面中。所有这些功能都将在客户端端实现，用户无需登录即可使用。 这与我们在将 Warp 客户端开源时所阐述的方针是一致的：我们希望 Warp 能更加开放、更具可定制性，其设计应符合开发人员的实际工作方式。同时，我们也要确保产品的完整性和可持续性。 首先，打开 Warp 软件，进入“设置”→“AI”选项，然后输入您的 API 密钥或配置自定义的推理端点。 请亲自试用一下，然后告诉我们：您希望 Warp 接下来能够支持哪些服务提供商、端点、本地模型设置以及智能体框架。我们非常期待您的反馈。 1 个帖子 - 1 位参与者 阅读完整话题
致力于供应链攻击的黑客团队 TeamPCP 日前发布商业广告宣称要出售代码托管平台 GitHub 核心源代码和内部组织架构信息，该黑客团伙称此次交易并不是勒索而是独家直接销售，当然即便是勒索 GitHub 也不太可能会向黑客支付赎金以换取数据保密。 值得注意的是 TeamPCP 并未提供任何样本数据，仅展示包含源代码仓库的目录和相关截图，只能说有实力的黑客不屑于提供样本，因为现在 GitHub 官方已经证实确实遭到攻击，经过初步调查后确认约有 3800 个内部仓库被黑客窃取。 涉及多个核心功能的源代码仓库： 从黑客公布的目录和截图来看，此次黑客窃取的数据涉及 GitHub 多个核心功能的源代码仓库，包括 GitHub Copilot、GitHub Enterprise Server、Red Team，还有用于漏洞管理、风险报告以及针对图形用户界面中跨站脚本攻击的缓解补丁仓库。另外 GitHub 运营和内部通信的逻辑通道之类的仓库也被窃取。 部分压缩包名称： raycast-github-copilot.tar.gz chiedo-copilot-cli-skills.tar.gz github-enterprise-server-release-notifier.tar.gz github-security-risk-reporting.tar.gz red-team.tar.gz github-ui-xss-hardening-research.tar.gz github-india.tar.gz repo-custom-claims-chatops.tar.gz GitHub 经过调查后确认数据泄露： GitHub 经过初步调查后确认数据泄露，攻击源头则是 GitHub 员工安装包含恶意代码的 Visual Studio Code 扩展程序，这个扩展程序很可能是 TeamPCP 蠕虫病毒的受害者，即扩展程序开发者也遭到攻击，随后黑客利用窃取的凭证发布包含恶意代码的版本，当更多开发者安装这个扩展程序的恶意版本时也会被窃取凭证。 检测到威胁后 GitHub 立即删除恶意版本的扩展程序并将这名员工的设备隔离，作为应急措施 GitHub 也立即对所有可能受影响的关键凭证进行轮换，不过考虑到蠕虫的潜在威胁，GitHub 还需要继续分析日志监控后续活动避免蠕虫已经感染其他系统并窃取更多凭证。 最后 GitHub 确认大约有 3800 个内部源代码仓库被窃取，GitHub 后续将发布详细的安全调查报告分享经验。 查看评论
我一直是用IDE的，对这种已经看不到源代码和文件系统的编辑器还是不太习惯 是现在的许多程序员都已经完全不审代码也不关心源码了吗，只关心抽象逻辑，还是说连抽象逻辑也不关心了呢？完全用口语化的自然语言描述需求，出了问题就再让AI去改？ 可能是我太保守了，对现在的这种疑似把代码当黑盒的趋势感到迷茫，我当然也是Vibe Coding可我自己还是全部自己review的，提示词也会把详细的逻辑掰碎写出来，整体的思路也是我提或者至少我是过目了的 如果完全用口语化自然语言描述需求，把代码，抽象逻辑，架构都视作一种黑盒，然后自己只负责优化prompt和配置skills，那为什么还需要程序员呢，公司直接全权AI好了，成本低多了 10 个帖子 - 7 位参与者 阅读完整话题
看过clawcode，不过不是go版本的，想问问有没有go版本claudecode的项目推荐 3 个帖子 - 2 位参与者 阅读完整话题
佬们，正在看一个开源代码，有什么好用的工具能快速上手吗。 目前我了解可以把项目对应github链接的url改成deepwiki跳转到一个ai分析代码网站 ps: 没法用vibe coding，ai只能用网页端。 6 个帖子 - 5 位参与者 阅读完整话题
一家自称拥有全球最大恶意软件源代码收藏的研究团队 vx-underground 近日在社交平台 X 发帖称，其当前保存的恶意软件数据总量约为 30 TB（太字节）。不久后，在线多引擎病毒扫描服务 VirusTotal 创始人 Bernardo Quintero 在回复中表示，用户多年来提交到 VirusTotal 的恶意软件样本已经累计达到约 31 PB（拍字节）。按照常用换算，一拍字节约等于一千太字节，这意味着两者的数据规模已远超一般用户的直观想象。 网络安全公司、人工智能研究人员和威胁情报机构普遍将这类恶意软件样本库视作关键基础数据，用于训练检测模型、研究攻击技术演化路径和分析新型威胁。然而，当这些规模动辄以 TB、PB 计的数据被抽象成数字时，它们具体“有多大”，往往很难在物理世界找到参照。因此，有人提出了一个颇具画面感的问题：如果把这些数据都存进传统硬盘，一块块叠起来，这些“恶意软件银行”究竟能堆多高？又能和现实世界的标志性建筑形成怎样的对比？ TechCrunch 记者在编辑部里曾尝试向某款 AI 聊天机器人抛出这一问题，但得到的答案“离谱到不可信”，最后只得放弃。于是，编辑团队改用最直接的方式——拿出纸笔，按常识做了一番“餐巾纸背面的粗略计算”。考虑到 vx-underground 和 VirusTotal 都是以“约多少 TB / PB”来描述自身数据量，记者也沿用了这一“约算”的口径。 为了便于读者形成直观概念，记者假定使用的是标准的 1 TB 3.5 英寸桌面机械硬盘——这类硬盘为了适配通用机箱，物理尺寸基本统一，高度约为 1 英寸（约 2.54 厘米）。在这一前提下，只需要关注“高度”这一维度，就可以模拟“把硬盘一块块往上垒”的效果。文章同时也忽略了硬盘在实际使用中标称容量与可用容量之间的差异，直接按照标称 1 TB 计算，以简化推演。 根据在线存储单位换算工具的结果，vx-underground 所称约 30 TB 的恶意软件数据，大致相当于 30 块 1 TB 硬盘的容量。如果把这 30 块硬盘自下而上叠放，其高度约为 30 英寸，即约 2.5 英尺（不足 1 米）。文章作者以自身身高作对照称，相比自己 6 英尺（约 1.83 米）的身高，这样一摞硬盘更像是堆在脚边的小箱子。 而当视角转向 VirusTotal 时，这种对比立刻发生了“量级跃迁”。以 31 PB 总量换算，约需 31，744 块 1 TB 硬盘才能完全容纳。如果同样采用“竖着往上堆”的方式，这根由硬盘构成的“数据塔”理论高度将达到约 2，645 英尺（约合 806 米）。在世界超高层建筑排行榜上，这个高度已经逼近位于迪拜的全球第一高楼哈利法塔（Burj Khalifa），后者约为 2，722 英尺（约 829 米）。 换言之，如果把 VirusTotal 的恶意软件样本视作一个纯由硬盘构成的立柱，其高度仅比哈利法塔矮出不足 80 英尺，已经足以与这座“垂直城市”的天际线相提并论。记者还选取了另一个标志性参照物——巴黎埃菲尔铁塔，其高度约 1，083 英尺（约 330 米）。按文中粗略估算，VirusTotal 当前所积累的恶意软件样本量，大致相当于“两座半埃菲尔铁塔”那样高的硬盘堆叠。 报道中配发了一张信息可视化示意图，将多个参照对象按高度从高到低横向排开。从左至右依次是：约 2722 英尺高的哈利法塔；约 2645 英尺高、由硬盘堆成的 VirusTotal “数据塔”；约 1792 英尺高的一号世界贸易中心大楼；约 1，083 英尺高的埃菲尔铁塔；身高 6 英尺的记者本人；以及高度仅约 2.5 英尺、代表 vx-underground 30 TB 数据的一小摞硬盘。通过这一排列，读者可以一目了然地感受到不同“恶意软件银行”在数据规模上的巨大差距。 报道最后指出，这些体量惊人的恶意软件样本库不仅是安全研究的“必需品”，同时也在无形中刻画出了当今网络威胁态势的庞大阴影。当安全企业和研究人员在这些数据堆里检索、标注、建模时，他们实际上是在与一座座“看不见的高塔”赛跑，以尽可能提前发现下一波攻击浪潮的蛛丝马迹。 查看评论
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
做了个会议录音 → 知识库的全自动管线，开源了，来分享一下。 背景 ：公司用 Plaud 录音笔积累了大量会议录音，但一直躺在那里没人整理。Plaud 自带的 AI 笔记质量一般，而且说话人都是匿名的（ Speaker 1 、Speaker 2…），行动项根本没法落实到人。 做了什么 ： 录音文件 → 说话人分割 → 身份具名 → AI 纪要 → Wiki 知识库 ↓ 可浏览 + 可搜索 + 可 RAG 问答 每天 22:00 cron 自动跑，0 人工干预。 最核心的部分：三阶段说话人具名漏斗 说话人识别我试过纯声纹方案，发现 CAM++ 跨录音根本不可靠——同一个人在不同录音的余弦相似度只有 0.50–0.65 ，反而不如不同人在同一录音的 0.85–0.97 。直接用声纹聚类，阈值 0.65 时同一个人被拆成 17 个簇。 最后用了三层漏斗： 优先级 方法 命中率 1 外部标签时间戳对齐（地面真相） ~95% 2 CAM++ 声纹余弦匹配（阈值 0.55 ） 填补剩余 3 LLM + 组织架构图 + 称呼惯例推断 兜底 最终 94% 片段具名率（ 56,862 / 60,664 ） 。有了具名，行动项才能从"某参与人说要做某事"变成"张经理需在周五前提交报价"。 技术栈 ： 说话人分割：pyannote community-1 （ GPU ，~28x 实时，比 CAM++ 分割准多了） ASR：FunASR Paraformer-large 声纹提取：CAM++ 192-dim embedding LLM：OpenAI 兼容接口（ Claude / GPT / 本地 Ollama 均可） Wiki：纯 Python http.server + mistune ，零框架 中文搜索：自制 Bigram 分词，不依赖 jieba 几个踩坑记录 ： pyannote 直接读 OGG 会有分割边界漂移，先 ffmpeg 转 16kHz WAV 54 分钟音频不加 VAD 直接跑 FunASR → 需要 43GB 显存 → OOM ，必须开 fsmn-vad LLM 输出 JSON 要多策略解析（ strip code fence → bare JSON → trailing comma ），单一策略会静默丢结果 S3 预签名 URL 不能带 Authorization header ，得用干净 session 开源地址 ： https://github.com/xclgordon/plaud-pipeline 架构文档在 docs/ architecture.md ，比较详细。 需要 NVIDIA GPU （ pyannote 分割），其他没有特殊依赖。主流程已经和 Plaud 解耦，把录音文件丢进 recordings/ 文件夹就能跑。 欢迎提问和 PR 。
小众软件报道过前几日开发者 Andrey Letov 通过 Notepad++ 的源代码开发了 Mac 版本，并取名 Notepad++ for Mac。遭到备受争议的 Notepad++ 开发者 Don Ho 指责：《侵犯商标权：假冒的 Mac 版 Notepad++》。 现在，新版本已经更名为
Claudecode之前的源代码泄露导致了一堆基于claudecode的fork如雨后春笋般冒了出来。今天试了试open cowork表现太棒了。速度甩了openclaw和hermes几条街。还有没有别的高水平claudecode重构版？如果有原生gui操控能力就最好了。 7 个帖子 - 5 位参与者 阅读完整话题