本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 github.com GitHub - Jinghao67/conductor: Context conductor for clean master sessions, dirty... Context conductor for clean master sessions, dirty explainer sidecars, and interactive AI branches 作为一个既需要发论文（科研导向）又需要做项目（工程导向）的学生，我在使用ai的过程中，经常遇到下面几个问题： 1）主session污染问题：在一个session内和ai聊久了，主 session 很快会被需求讨论、实现细节、失败尝试、长篇解释、review 记录全部污染，最后自己也不知道哪个 session 是干什么的。在科研上，有了idea后需要做不同的实验去验证和实现，实验过程中涉及到配环境、调参等很容易让ai陷入局部最优而进行过度尝试污染上下文的问题。在工程上，很多工程也会涉及到这些问题，subagent由于其不可显示导致人为不可控且需要用户自己设计而过于繁琐。 2）无论是工程还是科研都来源于一个并不具体的想法，可以说：在完成整个项目的过程中，没有人对这个项目完全了解，这就需要有一个session能拿到所有session的context，来解答用户所有的问题，无论是什么问题，这个session就是用来污染的，且永远不会并入主session污染其他session。 3）过程文档至关重要，但是一个被污染的session总结出的过程文档往往是带有各种无意义信息，比如偏向用户让他给解释的概念、反复陈述各种试错的失败信息，显然这对于未来需要这份过程文档的人是噪音，所以如何维护一个无污染的过程文档至关重要。 针对上述问题，我写了conductor，它的思路是把当前主对话变成一个永远干净的master session（用于自己需要理清项目逻辑、写过程文档等），只保留全局目标、关键决策、分支地图和批准后的子session的摘要；具体使用而言：使用时会先把当前对话设为干净的master session，如果需求不清楚，可以结合grill-me or grill-me-docs追问，等讨论清楚后，conductor会先做依赖分析，判断哪些任务可以并行，哪些必须串行等待。 接着，它不会乱开session，而是先生成branch card，每张card写清这个分支要做什么，为什么开，允许带入哪些context，预期产物是什么，完成标准和return condition，只有用户确认后，才会开真正的branch session。最开始会有四个session。1）主session。2）专门用于问问题随便污染的session。3）讨论分多少branch，并行or串行的session。4）第一个branch session 进入branch session后，这个session只拿到自己的branch brief和已批准的master session的context，不会继承任何session的杂乱历史，用户可以在branch里继续交互实现任何东西，这解决了subagent不能交互的问题，这下每个子任务用户都可以及时纠偏，这些细节都会留在branch里，主session依然干净。 当branch觉得任务完成后，不会自动合并，它会先建议完成，用户确认完成后，会生成总结，把这个session中过度的污染去掉但是把经验和正确的流程总结压缩，然后master session会询问用户是否合并，因为某些子任务必须合并进入主线，要么主线不完整，比如，在科研中，配环境复现paper的branch可以不合并，但是自己的重要实验必须要合并，不然主session会缺乏细节了解。 如果使用Treills，conductor还会把master、branch、依赖关系、状态和产物路径持久化成parent/child tasks、branchmap和metadata，方便回看、回退和继续推进。 整个流程的目标是：主session保持干净和主导，分支负责探索完成，专门留有一个有所有session context的session来让用户随意问问题讨论、污染。 6 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI 生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出 导读 继 【开源推广】一款自动读取页面内容的浏览器AI对话插件 之后脚本又增加了很多实用功能。 github.com GitHub - AhYi8/browser-ai-assistant: 基于当前网页上下文的 Chrome 侧边栏 AI... 基于当前网页上下文的 Chrome 侧边栏 AI 助手，支持多模型渠道、视觉图片输入、聊天历史、隐私模式和数据同步。 这个项目是浏览器侧边栏 AI 助手插件。 可以读取当前 网页的标题 、 URL 、 可见文本 、 HTML 、 截图 作为上下文进行 AI 对话； 支持对话生命周期的管理，以及对话进行文件夹分类、归档、增删改查； 支持自定义渠道，支持配置 NewAPI 模型，同时，支持视觉理解模型，支持图片上传、图片理解； 支持提示词管理，支持通过 / 命令来快捷调用提示词； 支持Chrome Sync/WebDAV/S3 远程备份、恢复； 新增高级功能： Network 网络请求自动化分析 ：支持采集 DevTools 中 Network 请求，支持根据用户需求自动过滤、分析、总结 Network 中的请求； 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 WorkFlowX：一个更强调可控、可追踪和 Token 效率的 AI 多智能体开发工作流 项目地址： github.com GitHub - TreeX-X/WorkFlowX: AI... AI 驱动开发的多智能体工作流框架，编排需求分析、任务规划、代码实现与质量评估，形成从需求到交付的闭环协作流程 || A multi-agent workflow framework for AI-driven development, orchestrating requirement analysis, task planning, code implementation, and quality evaluation into a closed-loop delivery process. 为什么做这个项目 作为探索AI领域的一名从业者，Superpowers、OMC 这些开源工作流都上手试过。它们各自都有很优秀的设计，但我在实际工作中用的始终有点不顺手。 首先就是一个需求扔进去，不知道底部流转机制经历了什么，每一次消耗的token和需求的大小有时候没有直接关系。 而且我觉得spec-coding的思想是很重要的，不仅仅是让AI生成更好，而是让开发过程有了沉淀，真实项目要维护的、要复盘的，不能就是地单纯让AI修改生成代码。 vibe-coding和自动化工作是一种很爽的过程，但正经干活时，我还是希望开发者能够在AI开发的流程中进行介入，而不是让他自己一股脑的跑完。 针对上面的几个问题，我决定开发一个需求能追踪、质量能审计、Token利用率高的工作流，让开发者能够在全自动&半自动的流程中随时介入。 WorkFlowX 是什么 作为一个多智能体协作的开发工作流框架，我设计的核心思路来源于Anthropic 研究里提的 Harness Design，通过标准化的流程，用文档机制去约束我们的Agent去按照一个约束去进行工作。 我依赖了主流Agent工具都具备的一个功能"runSubAgent",设计了一个主智能体 orchestratorX 做路由和编排，以及对应调度的子智能体： orchestratorX — 主编排者，管路由、文档、任务分发和迭代控制 promptMasterX — 把用户的输入理清楚，减少歧义和 prompt 里的坑 coderX — 写代码，遵循最小实现原则 evaluatorX — 独立审计代码，不听 coderX 自己说"我写完了" abstracterX — 做代码结构分析和工程总结 为什么用子智能体？因为每个子智能体有独立上下文，不会被前面的对话污染。这样每个 Agent 都是在理论能力最强的状态下干活，出来的代码质量会稳定很多。 WorkFlowX可以按照需求大小分为三种模式，不会啥需求都走同一套重流程： 模式 适用场景 特点 `xwhole` 新功能、跨模块重构、大需求 完整规划、Hybrid Tree 文档、coder/evaluator 迭代 `xlocal` 1-2 个模块内的修改 跳过完整 PRD，但保留需求发现和评估 `xunit` 单文件修 bug、小改动 最轻量，快速搞定，默认不走完整评估 核心机制：xwhole 完整工作流 在本次中我主要介绍xwhole，它是框架的完整工作流，其他的工作流都是其分解出的一部分 开发者在提出一个模块开发或者需求时，不会马上开始写代码，而是先走规划，这有点像传统的"plan"模式，但是我们进行了特殊设计 首先工作流会进行苏格拉底式的提问，不断将你的需求提问，直到理解明白，并且会在分析需求的时候，进行质疑，并提出方案和指出不合理的地方，反馈你修正，到生成最终计划时只会留下我们交流中实际确认的需求 需求确认后，就会开始生成一个工作流中很核心的一部分，我命名为Hybrid Tree，工作流把需求拆分为需求树， Parent 文档记全局目标、范围、非功能要求、路由表； Child 文档记具体子任务、验收标准、涉及的文件、评估结果 通过这个结构，后续子智能体干活的时候，就不需要整个项目上下文都吞一遍，通过父文档路由到对应的子文档，只读当前任务真正需要的东西 另外规划阶段会提前把项目探索一遍，相关文件、关键实体、依赖关系记到文档和临时记忆里。后面 coderX 和 evaluatorX 不用每次从零开始搜项目，Token 自然就省下来了 从需求到代码，再到评估 Hybrid Tree 建好之后，这里我还是采纳了Anthropic 研究里提到的生成对抗网络(GANs)的思路，让生成过程变成一个不断迭代的过程 首先，orchestratorX 把子任务分给 coderX，coderX 的工作很明确：读文档、读验收标准、写最小必要实现。我给它引入了Karpathy 那套工程观 —— 别过度设计，别为了显得高级而搞复杂，用最短路径解决真问题 代码写完，不会让 coderX 自己评价自己。这是很多 AI 工作流的通病：同一个 Agent 既实现又评估，它天然倾向于觉得自己做得不错 所以评估交给了 evaluatorX，一个完全独立的审核 Agent，只读读需求文档和验收标准，只看git diff 和相关代码，不了解coderX 的自我声明，根据逐条AC 判 pass / partial / fail / unevaluable，然后输出问题清单、严重级别、修复建议 没过的话，orchestratorX 把 evaluatorX 的意见扔回给 coderX 改。每个 Child 有迭代上限，不会无限循环；evaluatorX 判 PASS 就提前收工，不白烧 Token Token 优化怎么做的 首先就是工作流的分级，根据不同的需求，使用不同的流程，合理分配 然后就是依赖Hybrid tree机制，将需求分散，每次只给 Agent 当前子任务需要的文档，不灌全量，并将关键文件和知识点沉淀下来，后面按需加载 在迭代过程中，我设计了增量评估，evaluatorX 这轮只看 diff、失败的 AC 和相关文件，不每轮都重新吞一遍全量上下文；我还在评估中设计了早退机制，让任务完成了，就不会一直继续迭代，而是直接停止 目标不是把 Token 消耗干到零，而是让它透明、可控、花得明白 和别的工作流有啥不一样 Superpowers 侧重工程习惯和自动化体验，OMC 侧重工具调度、多模型协作和专业 Agent 覆盖。WorkFlowX 选了另一个方向：需求追踪、质量审计、结构化迭代、Token 可控 几个独有的特点： Hybrid Tree 做需求追踪，需求从哪来到哪去都能查 AC 交叉验证，不是 coderX 说了算 orchestratorX 是唯一写文档的人，避免多 Agent 写出冲突 coderX / evaluatorX 职责分离，实现的人不评估 人可以在任意节点介入、确认、审阅 按任务规模选不同工作流，不一刀切 现在还不完美的地方 作为作者，我自己都知道WorkFlowX距离完全成熟的工作流还有一定的距离 没有一个专业的安全审查机制，TDD机制也是没有的，不同语言和框架的审核可以做的更好，并行工作流和调度还有细节要打磨，文档可视化也有优化的控件 但即使如此，作为一个以需求为切入点、强调人为可控和 Token 效率的工作流，我觉得它现在到了可以拿出来让人真实试用、给反馈的阶段 接下来的更新计划 一个是 ultra 参数模式，参考二级路由能力，可能引入 HTML 结构替代部分 Markdown，做一个更重型但能力更强的模式 另一个是把安全审查做得更系统，吸收 OMC 里 security-review 的好思路，但保持 WorkFlowX 自己的结构化风格 还有一个方向是参考 Karpathy 最近提的 autoresearch，让模型反过来分析和优化工作流本身，从真实使用里挖升级点。跑通了会继续分享 最后 如果你用 AI 开发的时候也碰到过这些： 需求聊着聊着就丢了 AI 写完代码，不知道是不是真的满足了要求 Token 花了不少，但不知道花在哪 想自动化，但不想完全失去控制 希望开发过程能留下点什么，以后维护用得上 希望你能来试试WorkFlowX 欢迎提 issue、PR，或者直接在帖子里说想法。觉得有帮助的话，顺手点个 star 也行 项目地址： github.com GitHub - TreeX-X/WorkFlowX: AI... AI 驱动开发的多智能体工作流框架，编排需求分析、任务规划、代码实现与质量评估，形成从需求到交付的闭环协作流程 || A multi-agent workflow framework for AI-driven development, orchestrating requirement analysis, task planning, code implementation, and quality evaluation into a closed-loop delivery process. 2 个帖子 - 2 位参与者 阅读完整话题
IT之家 5 月 29 日消息，小米大模型应用团队今日发布 ControlFoley 开源模型 ，面向视频同步音效生成中的“可控性”难题，统一支持文本引导视频配音、文本控制视频配音和参考音频控制视频配音三类任务。 ControlFoley 在多个视频音效生成任务上达到 开源 SOTA 表现 ，在语义对齐、时间同步、声音质量以及多模态控制能力上取得全面提升。代码、模型权重、技术报告、在线 Demo 和开箱即用 Skill 均已开放。 给一段无声视频自动配上音效，已经不再是新鲜事。视频音效生成模型可以根据画面内容生成匹配的声音，让无声视频变得更完整、更有沉浸感。 然而，如果模型只会根据画面自动猜声音，创作者就很难真正控制配音结果。视频音效生成的下一步，需要从“看画面配声音”走向“按意图配声音”。为此，小米大模型应用团队提出并开源了 ControlFoley，一个统一且可控的视频音效生成框架。 它不只让视频“有声音”，更希望让声音真正“按你想要的来” 。 ControlFoley 的核心目标，是构建一个统一的可控视频音效生成框架，让模型同时具备三类能力： TV2A：文本引导视频配音 。根据视频和文本提示生成同步音效，文本用于补充和细化画面中的声音语义。 TC-V2A：文本控制视频配音 。当文本和视频语义发生冲突时，模型仍能遵循文本意图生成目标声音，同时保持和视频动作的时间同步。 AC-V2A：参考音频控制视频配音 。根据视频和参考音频生成同步音效，让输出声音在音色和风格上贴近参考音频，同时不破坏视频节奏。 这意味着，ControlFoley 不只是一个“视频生音频”模型，而是一个 面向创作控制的 多模态 音频生成 模型 。 ▲ ControlFoley 模型架构：联合视觉编码、时间-音色解耦与多模态鲁棒训练共同支撑可控视频音效生成 联合视觉编码：既理解画面，也听懂控制意图 在视频音效生成中，视觉信息非常强势。它能告诉模型画面中发生了什么，但也容易在多模态融合时压制文本控制。为此， 团队新提出并自训练了时空音视频编码器 CAV-MAE-ST ，用来增强模型对音视频事件、动作节奏和时间同步关系的理解。 ▲ 时空音视频编码器 CAV-MAE-ST 简单理解，CLIP 更擅长理解视觉与文本之间的通用语义关系；CAV-MAE-ST 则面向视频配音任务重新设计和训练，更关注“动作什么时候发生、声音应该什么时候出现”这类音视频时空对应关系。它通过视频帧与音频特征的联合建模，帮助模型捕捉动作节奏、音频事件和时间同步线索。 二者结合后，ControlFoley 既能保留强音画同步能力，又能在文本与视觉发生冲突时更好地响应文本控制。这让模型在“画面是一回事，用户想要另一种声音”的场景下，不再只是被画面牵着走。 时间-音色解耦：让参考音频控制风格，而不扰乱同步 参考音频控制的难点在于：一段音频里同时包含“听起来像什么”和“什么时候发生”两类信息。如果模型直接使用参考音频，参考音频里的节奏和时间结构可能会干扰视频本身的动作同步。结果就是，声音风格没控稳，音画同步也被破坏。 ControlFoley 采用时间-音色解耦策略 ，抑制参考音频中冗余的时间信息，保留更关键的全局音色特征。这样一来，参考音频主要负责控制“声音听起来像什么”，视频则继续负责控制“声音什么时候发生”。 模态鲁棒训练：一个模型，适配多种输入组合 真实使用中，用户提供的条件并不固定：有时只有视频，有时有视频和文本，有时还会额外提供参考音频。 ControlFoley 采用随机模态 dropout 和统一多模态表示对齐训练，让模型在不同条件组合下都能保持稳定。同时，模型通过统一 REPA 对齐目标，将生成音频的内部表示与聚合后的多模态条件对齐，提升语义一致性和控制鲁棒性。换句话说，ControlFoley 不是为某一个单点任务“特化”出来的模型，而是一个 统一覆盖 TV2A、TC-V2A、AC-V2A 的多任务框架 。 在常规视频配音任务 TV2A 上，ControlFoley 在 VGGSound-Test、Kling-Audio-Eval、MovieGen-Audio-Bench 等多个 benchmark 上取得 开源 SOTA 表现 。 结果对比显示，ControlFoley 在多个数据集上均取得更好的语义对齐、时间同步和声音质量表现。 下图展示了典型视频配音结果的频谱对比。以乐器演奏和体育运动两类典型场景为例，ControlFoley 生成的音频在动作发生的关键时刻能够对齐视频节奏，同时保留更完整的高频细节；相比之下，部分方法会出现声音事件错位、漏掉关键动作声音，或生成与画面不匹配的音频。直观来看，ControlFoley 不仅能“配上声音”，也更能把声音配准、配细。 对标商业闭源系统 Kling-Foley，ControlFoley 在关键体验指标上同样展现出竞争力。在语义对齐、时间同步和声音质量等关键体验指标上，ControlFoley 相比 Kling-Foley 展现出稳定优势；完整客观指标可见技术报告。 ControlFoley 的相关资源已经开放，IT之家附开源链接： 技术报告 ： https://arxiv.org/abs/2604.15086 GitHub ： https://github.com/xiaomi-research/controlfoley 模型权重 ： https://huggingface.co/YJX-Xiaomi/ControlFoley 项目主页 / 在线体验 ： https://yjx-research.github.io/ControlFoley_web_page/ 一键调用 Skill ： https://clawhub.ai/yjx-research/controlfoley-audio-generator 完整结果对比 ： https://yjx-research.github.io/ControlFoley/
提需求-review?-测试验证,调整 如何review,大家推荐一下提示词 或者 经验把 或者有没有想过的skills. 8 个帖子 - 5 位参与者 阅读完整话题
如题。 小项目使用Claude Code 感觉问题不大。 但是大项目使用Claude Code 开发，要如何让项目处于可控状态？ 各位有相关经验可以分享吗？ 3 个帖子 - 3 位参与者 阅读完整话题
之前的互联网革命是提高人类信息流通效率，有成本边际递减效应，开发一个网站用的人越多成本越低。 AI 完全没有这种效用提升，用的人越多成本越高，无尽的吞噬掉芯片、电力，搞得现在普通人配个电脑都配不起。
之前的互联网革命是提高人类信息流通效率，有成本边际递减效应，开发一个网站用的人越多成本越低。 AI 完全没有这种效用提升，用的人越多成本越高，无尽的吞噬掉芯片、电力，搞得现在普通人配个电脑都配不起。
之前的互联网革命是提高人类信息流通效率，有成本边际递减效应，开发一个网站用的人越多成本越低。 AI 完全没有这种效用提升，用的人越多成本越高，无尽的吞噬掉芯片、电力，搞得现在普通人配个电脑都配不起。
之前的互联网革命是提高人类信息流通效率，有成本边际递减效应，开发一个网站用的人越多成本越低。 AI 完全没有这种效用提升，用的人越多成本越高，无尽的吞噬掉芯片、电力，搞得现在普通人配个电脑都配不起。
之前的互联网革命是提高人类信息流通效率，有成本边际递减效应，开发一个网站用的人越多成本越低。 AI 完全没有这种效用提升，用的人越多成本越高，无尽的吞噬掉芯片、电力，搞得现在普通人配个电脑都配不起。
之前的互联网革命是提高人类信息流通效率，有成本边际递减效应，开发一个网站用的人越多成本越低。 AI 完全没有这种效用提升，用的人越多成本越高，无尽的吞噬掉芯片、电力，搞得现在普通人配个电脑都配不起。
IT之家 5 月 20 日消息，在今天的华为鸿蒙办公新品技术沟通会上，华为官方公开了一组 IDC 数据： 华为平板中国市场出货量已连续两年度（2024-2025）排名第一 ，同时 2025 华为擎云服务行业客户超 10 万。 华为终端 BG 平板与 PC 产品线总裁朱懂东表示，鸿蒙办公在形态、交互、生态方面持续融合创新，助推行业变革，通过软硬芯云协同，充分发挥全链路自主可控优势，重塑办公体验。 形态融合： 操作系统与移动设备统一、芯片技术拥抱 ARM 架构、移动设备技术轻薄便携； 交互融合： 多模态交互支持触屏、手写、视觉、AI Agent； 生态融合： 传统桌面生态侧重办公，重生产力；丰富移动生态侧重娱乐，轻生产力。 IT之家在华为鸿蒙办公新品技术沟通会现场了解到，华为全链路自主可控优势覆盖处理器、硬件、操作系统、云等方面。
信创、国产化、自主可控类的要求，主要针对计算机终端和服务器搭载的中央处理器（CPU）、人工智能训练推理芯片、操作系统、数据库，以及激光或喷墨打印机搭载的主控芯片等开展。政策名字一直在变，名单以中国信息安全测评中心公布的安全可靠测评公告为准。目前名录里的设备整理如下，供大家选型参考： 序号 类别 产品名称 厂商 型号/版本 安全等级 公告期号 公告日期 1 CPU 兆芯ZX-D 上海兆芯集成电路股份有限公司 KX-U5580 I级 2023年第1号 2023-12-26 2 CPU 兆芯ZX-E 上海兆芯集成电路股份有限公司 KX-U6780A/KH-37800D/KX-6640MA/KX-6640A I级 2023年第1号 2023-12-26 3 CPU 海光2号C86 海光信息技术股份有限公司 3230/3250/3280/5280/7250/7260/7280/7285 I级 2023年第1号 2023-12-26 4 CPU 海光C86-3G 海光信息技术股份有限公司 C86-3G I级 2023年第1号 2023-12-26 5 CPU 申威1621 无锡先进技术研究院 1621 I级 2023年第1号 2023-12-26 6 CPU 申威3231 无锡先进技术研究院 3231 I级 2023年第1号 2023-12-26 7 CPU 申威SW421 无锡先进技术研究院 SW421 I级 2023年第1号 2023-12-26 8 CPU 盘古M900 海思技术有限公司 M900 I级 2023年第1号 2023-12-26 9 CPU 飞腾FT-2000 飞腾信息技术有限公司 FT-2000 I级 2023年第1号 2023-12-26 10 CPU 飞腾FT-2000+ 飞腾信息技术有限公司 FT-2000+ I级 2023年第1号 2023-12-26 11 CPU 飞腾腾云S2500 飞腾信息技术有限公司 S2500 I级 2023年第1号 2023-12-26 12 CPU 飞腾腾锐D2000 飞腾信息技术有限公司 D2000 I级 2023年第1号 2023-12-26 13 CPU 鲲鹏920 深圳市海思半导体有限公司 920 I级 2023年第1号 2023-12-26 14 CPU 麒麟9006C 深圳市海思半导体有限公司 9006C I级 2023年第1号 2023-12-26 15 CPU 麒麟990 深圳市海思半导体有限公司 990 I级 2023年第1号 2023-12-26 16 CPU 龙芯3A4000/3B4000 龙芯中科技术股份有限公司 3A4000/3B4000 I级 2023年第1号 2023-12-26 17 CPU 龙芯3A5000/3B5000 龙芯中科技术股份有限公司 3A5000/3B5000 I级 2023年第1号 2023-12-26 18 CPU 龙芯3C5000L 龙芯中科技术股份有限公司 3C5000L I级 2023年第1号 2023-12-26 19 CPU 兆芯处理器KH-40000 上海兆芯集成电路股份有限公司 KH-40000 Ⅰ级 2024年第1号 2024-05-20 20 CPU 海光处理器C86-4G 海光信息技术股份有限公司 C86-4G Ⅱ级 2024年第1号 2024-05-20 21 CPU 海光处理器C86-4G-L 海光信息技术股份有限公司 C86-4G-L Ⅰ级 2024年第1号 2024-05-20 22 CPU 申威SW-WY831型微处理器 无锡先进技术研究院 SW-WY831 Ⅰ级 2024年第1号 2024-05-20 23 CPU 飞腾腾云S5000C 飞腾信息技术有限公司 S5000C Ⅱ级 2024年第1号 2024-05-20 24 CPU 飞腾腾珑E2000 飞腾信息技术有限公司 E2000 Ⅱ级 2024年第1号 2024-05-20 25 CPU 飞腾腾锐D3000 飞腾信息技术有限公司 D3000 Ⅱ级 2024年第1号 2024-05-20 26 CPU 鲲鹏920 V200 深圳市海思半导体有限公司 920 V200 Ⅱ级 2024年第1号 2024-05-20 27 CPU 麒麟9000C 深圳市海思半导体有限公司 9000C Ⅱ级 2024年第1号 2024-05-20 28 CPU 龙芯2K2000 龙芯中科技术股份有限公司 2K2000 Ⅰ级 2024年第1号 2024-05-20 29 CPU 龙芯3A5000（DA版） 龙芯中科技术股份有限公司 3A5000 DA版 Ⅱ级 2024年第1号 2024-05-20 30 CPU 龙芯3A6000 龙芯中科技术股份有限公司 3A6000 Ⅱ级 2024年第1号 2024-05-20 31 CPU 龙芯3C5000 龙芯中科技术股份有限公司 3C5000 Ⅱ级 2024年第1号 2024-05-20 32 CPU 龙芯3D5000 龙芯中科技术股份有限公司 3D5000 Ⅱ级 2024年第1号 2024-05-20 33 CPU 兆芯处理器KX-6000G 上海兆芯集成电路股份有限公司 KX-6000G I级 2024年第2号 2024-09-30 34 CPU 兆芯处理器KX-7000 上海兆芯集成电路股份有限公司 KX-7000 I级 2024年第2号 2024-09-30 35 CPU 兆芯处理器KX-6940S 上海兆芯集成电路股份有限公司 KX-6940S I级 2025年第1号 2025-03-14 36 CPU 兆芯处理器KX-U6980S 上海兆芯集成电路股份有限公司 KX-U6980S I级 2025年第1号 2025-03-14 37 CPU 申威WY831（GC版） 中电科申泰信息科技有限公司 WY831 GC版 I级 2025年第1号 2025-03-14 38 CPU 申威威鑫H8000 中电科申泰信息科技有限公司 H8000 II级 2025年第1号 2025-03-14 39 CPU 飞腾腾云S5000C-E 飞腾信息技术有限公司 S5000C-E II级 2025年第1号 2025-03-14 40 CPU 麒麟X90 深圳市海思半导体有限公司 X90 II级 2025年第1号 2025-03-14 41 CPU 龙芯3B6000 龙芯中科技术股份有限公司 3B6000 II级 2025年第1号 2025-03-14 42 CPU 龙芯3C6000 龙芯中科技术股份有限公司 3C6000 II级 2025年第1号 2025-03-14 43 CPU 海思麒麟9000X 深圳市海思半导体有限公司 9000X II级 2025年第3号 2025-09-12 44 CPU 飞腾腾锐D3000M 飞腾信息技术有限公司 D3000M I级 2025年第3号 2025-09-12 45 CPU 龙芯2K1500 龙芯中科技术股份有限公司 2K1500 I级 2025年第3号 2025-09-12 46 CPU 龙芯3B6000M 龙芯中科技术股份有限公司 3B6000M II级 2025年第3号 2025-09-12 47 桌面操作系统 方德桌面操作系统 中科方德软件有限公司 V3.1（内核版本4.9） I级 2023年第1号 2023-12-26 48 桌面操作系统 统信桌面操作系统 统信软件技术有限公司 V20（内核版本4.19） I级 2023年第1号 2023-12-26 49 桌面操作系统 银河麒麟桌面操作系统 麒麟软件有限公司 V10（内核版本5.4） I级 2023年第1号 2023-12-26 50 桌面操作系统 方德桌面操作系统 中科方德软件有限公司 V5.0（内核5.4） Ⅰ级 2024年第1号 2024-05-20 51 桌面操作系统 统信桌面操作系统 统信软件技术有限公司 V20（内核5.10） Ⅰ级 2024年第1号 2024-05-20 52 桌面操作系统 银河麒麟桌面操作系统 麒麟软件有限公司 V10 SP1（内核5.4） Ⅰ级 2024年第1号 2024-05-20 53 桌面操作系统 银河麒麟桌面操作系统 麒麟软件有限公司 V10 SP1（内核5.10） I级 2025年第1号 2025-03-14 54 桌面操作系统 方德桌面操作系统（Pro版） 中科方德软件有限公司 V5.0（内核6.6） I级 2025年第3号 2025-09-12 55 桌面操作系统 银河麒麟桌面操作系统 麒麟软件有限公司 V11（内核6.6） I级 2025年第3号 2025-09-12 56 桌面操作系统 HarmonyOS 华为终端有限公司 V1.0（内核HongMeng Kernel 1.11） Ⅱ级 2026年第1号 2026-01-16 57 桌面操作系统 统信桌面操作系统 统信软件技术有限公司 V25（内核Linux Kernel 6.6） I级 2026年第1号 2026-01-16 58 服务器操作系统 方德高可信服务器操作系统 中科方德软件有限公司 V4.0（内核版本4.19） I级 2023年第1号 2023-12-26 59 服务器操作系统 统信服务器操作系统 统信软件技术有限公司 V20（内核版本4.19） I级 2023年第1号 2023-12-26 60 服务器操作系统 银河麒麟高级服务器操作系统 麒麟软件有限公司 V10（内核版本4.19） I级 2023年第1号 2023-12-26 61 服务器操作系统 凝思安全操作系统欧拉版 北京凝思软件股份有限公司 V6.0.99（内核4.19） Ⅰ级 2024年第1号 2024-05-20 62 服务器操作系统 华为云欧拉操作系统 华为云计算技术有限公司 V2.0（内核5.10） Ⅰ级 2024年第1号 2024-05-20 63 服务器操作系统 新支点服务器操作系统 中兴通讯股份有限公司 V6（内核5.10） Ⅰ级 2024年第1号 2024-05-20 64 服务器操作系统 腾讯云Linux服务器操作系统 腾讯云计算（北京）有限责任公司 V3（内核5.4） Ⅰ级 2024年第1号 2024-05-20 65 服务器操作系统 银河麒麟高级服务器操作系统 麒麟软件有限公司 V10 SP3（内核4.19） Ⅰ级 2024年第1号 2024-05-20 66 服务器操作系统 阿里云服务器操作系统 阿里云计算有限公司 V3（内核5.10） Ⅰ级 2024年第1号 2024-05-20 67 服务器操作系统 麒麟信安服务器操作系统 湖南麒麟信安科技股份有限公司 V3（内核4.19） Ⅰ级 2024年第1号 2024-05-20 68 服务器操作系统 天翼云CTyunOS系统 天翼云科技有限公司 V2.0（内核4.19） I级 2025年第1号 2025-03-14 69 服务器操作系统 腾讯云Linux服务器操作系统 腾讯云计算（北京）有限责任公司 V4（内核6.6） I级 2025年第3号 2025-09-12 70 服务器操作系统 银河麒麟高级服务器操作系统 麒麟软件有限公司 V11（内核6.6） I级 2025年第3号 2025-09-12 71 服务器操作系统 华为云欧拉操作系统 华为云计算技术有限公司 V3（内核Linux Kernel 6.6） I级 2026年第1号 2026-01-16 72 服务器操作系统 新支点服务器操作系统 中兴通讯股份有限公司 V7（内核Linux Kernel 6.6） I级 2026年第1号 2026-01-16 73 服务器操作系统 阿里云服务器操作系统 阿里云计算有限公司 V4（内核Linux Kernel 6.6） I级 2026年第1号 2026-01-16 74 集中式数据库 PolarDB 阿里云计算有限公司 V2.0 I级 2023年第1号 2023-12-26 75 集中式数据库 TDSQL关系型数据库管理系统软件 腾讯云计算（北京）有限责任公司 V8.0 I级 2023年第1号 2023-12-26 76 集中式数据库 万里安全数据库软件 北京万里开源软件有限公司 V1.0 I级 2023年第1号 2023-12-26 77 集中式数据库 优炫数据库管理系统 北京优炫软件股份有限公司 V2.1 I级 2023年第1号 2023-12-26 78 集中式数据库 南大通用安全数据库管理系统GBase 8s 天津南大通用数据技术股份有限公司 V8.8 I级 2023年第1号 2023-12-26 79 集中式数据库 海盒通用数据库管理系统（SeaboxSQL） 北京东方金信科技股份有限公司 V11.5 I级 2023年第1号 2023-12-26 80 集中式数据库 海量数据库G100管理系统 北京海量数据技术股份有限公司 V2.2 I级 2023年第1号 2023-12-26 81 集中式数据库 瀚高安全版数据库系统 瀚高基础软件股份有限公司 V4.5 I级 2023年第1号 2023-12-26 82 集中式数据库 虚谷数据库管理系统 成都虚谷伟业科技有限公司 V11.0 I级 2023年第1号 2023-12-26 83 集中式数据库 达梦数据库管理系统 武汉达梦数据库股份有限公司 V8.4 I级 2023年第1号 2023-12-26 84 集中式数据库 金仓数据库管理系统KingbaseES 北京人大金仓信息技术股份有限公司 V8 I级 2023年第1号 2023-12-26 85 集中式数据库 GaussDB（集中式版） 华为云计算技术有限公司 V2.0 Ⅱ级 2024年第2号 2024-09-30 86 集中式数据库 TaurusDB 华为云计算技术有限公司 V2.0 I级 2024年第2号 2024-09-30 87 集中式数据库 海量数据库管理系统G100（Vastbase G100） 北京海量数据技术股份有限公司 V3.0 I级 2024年第2号 2024-09-30 88 集中式数据库 瀚高数据库管理系统 瀚高基础软件股份有限公司 V9.0 I级 2024年第2号 2024-09-30 89 集中式数据库 神通数据库管理系统 天津神舟通用数据技术有限公司 V7.0 I级 2024年第2号 2024-09-30 90 集中式数据库 金仓数据库管理系统 中电科金仓（北京）科技股份有限公司 V9 I级 2024年第2号 2024-09-30 91 集中式数据库 大云海山数据库（He3DB for PostgreSQL） 中移（苏州）软件技术有限公司 V2.0 I级 2025年第2号 2025-08-22 92 集中式数据库 崖山数据库管理系统 深圳计算科学研究院 V23 I级 2025年第2号 2025-08-22 93 集中式数据库 神通数据库管理系统 天津神舟通用数据技术有限公司 V8.0 I级 2025年第2号 2025-08-22 94 分布式数据库 GaussDB（分布式版） 华为云计算技术有限公司 V2.0 I级 2024年第2号 2024-09-30 95 分布式数据库 GoldenDB数据库 中兴通讯股份有限公司 V6 I级 2024年第2号 2024-09-30 96 分布式数据库 OceanBase数据库软件 北京奥星贝斯科技有限公司 V4 I级 2024年第2号 2024-09-30 97 分布式数据库 南大通用大规模分布式并行数据库集群系统 天津南大通用数据技术股份有限公司 V9 I级 2024年第2号 2024-09-30 98 分布式数据库 平凯数据库企业版软件 平凯星辰（北京）科技有限公司 V7.1 I级 2024年第2号 2024-09-30 99 分布式数据库 神通数据库管理系统（MPP集群版） 天津神舟通用数据技术有限公司 V7.0 I级 2024年第2号 2024-09-30 100 分布式数据库 腾讯云分布式数据库TDSQL管理系统 腾讯云计算（北京）有限责任公司 V10.3 I级 2024年第2号 2024-09-30 101 分布式数据库 虚谷数据库管理系统 成都虚谷伟业科技有限公司 V12.0 I级 2024年第2号 2024-09-30 102 分布式数据库 达梦数据库管理系统（分布式版） 武汉达梦数据库股份有限公司 V8.4 I级 2024年第2号 2024-09-30 103 分布式数据库 金仓分布式HTAP数据库集群软件 中电科金仓（北京）科技股份有限公司 V3 I级 2024年第2号 2024-09-30 104 分布式数据库 阿里云PolarDB数据库管理软件（分布式版） 阿里云计算有限公司 V2.0 I级 2024年第2号 2024-09-30 3 个帖子 - 3 位参与者 阅读完整话题
今天跟一位能源专业的同学聊了一些，突然想起高中物理书上说乐观估计本世纪中叶能实现可控核聚变“彻底”解决能源问题，这些年也零零散散听到一些相关好消息，不过貌似还是停留于实验室阶段。而且这位同学表示现在主流还是用上世纪的托卡马克，磁约束是对的，但这个框架方向成本很难降到民用 和现在ai有点像，主流是transformer，但貌似大家都对这个框架持悲观态度，成本高、训练复杂、RL脆弱……好像基本都认为得换框架。不过好像挺多乐观论调2030年就可以实现，比可控核聚变民用乐观多了 不知道AGI先来还是可控核聚变先来 也许真相是还要再等一个世纪 6 个帖子 - 6 位参与者 阅读完整话题
IT之家 4 月 26 日消息，据《科技日报》今天报道，两台 300 吨级矿用卡车动力总成前天（4 月 24 日）创造新纪录，成功通过可靠运行 18000 小时大考， 搭载我国自主可控的潍柴 12M55 动力总成 。 “长期以来，我国 300 吨级矿卡所搭载的发动机多为外资产品。”中国工程机械工业协会副秘书长吕莹表示，本次突破具有里程碑意义，就如同张雪机车在葡萄牙站的双冠打破了欧美日品牌长期主导高端摩托车市场的格局。 据介绍，所谓“300 吨级矿卡”指的是额定载重为 300 吨的矿用自卸卡车，主要用于大型露天煤矿、金属矿等重载运输场景。 其长度为 15.9 米、宽 10.3 米、高 8 米 ， 仅一个轮胎的直径就达 4 米，可谓是“庞然大物” 。 同时，大型矿山动力领域科技含量和产业壁垒极高。搭载外资动力品牌的矿卡其运行数据不与国内共享，证明本次记录刷新具备实际价值。 此外，12M55 发动机在核心系统方面实现了自主可控，其 ECU（IT之家注：电子控制单元）软件可按需优化定制，超高压共轨闭环控制系统实现燃油精准控制，并协同产业链构建起自主可控的供应链体系。
IT之家 4 月 24 日消息，据央视新闻今日报道，我国成功研制并获批新建国家光波长量子基准，总体技术达到国际先进水平。 计量基准是一个国家测量体系的“定盘星”。在此之前，我国的光波长计量长期依赖单点波长基准，测量范围窄、精度有限。 为突破光波长量子计量量值溯源领域的关键技术瓶颈，实现完全自主可控，市场监管总局组织国内科研团队集中攻关，成功攻克了高效率光谱变换和高精度光学锁相激光稳频两大核心技术，研制出新一代覆盖 500nm 至 2350nm（IT之家注：可见光到近红外波段）的光波长量子基准，不确定度水平达到 1.0×10⁻¹³，长度基本单位“米”的复现精度较此前提升了两个数量级，测量范围扩大了约 20 万倍，有效解决了传统基准精度不足的痛点。研究团队推算，如果将月球到地球的距离视为一个光波长，那么测量这个光波长的误差还不到一根头发丝直径的一半。 这项成果标志着我国成为继美国、德国之后，第三个自主研制完成多波长同步锁定的国家，整体技术水平达到国际先进水平。 相关阅读： 《 填补我国相关空白：新建光波长国家计量基准装置获批，准确度提升 2 个数量级 》
士多已经溢出屏幕了 4 个帖子 - 4 位参与者 阅读完整话题
4 月 20 日，华为数字资产继承功能正式上线 HarmonyOS 6.1。该功能支持用户提前指定信任的亲友作为数字资产继承人，将自身存储在华为云空间中的珍贵数字记忆，安全、便捷地传递给最重要的人。在数字资产已成为个人核心人生资产的当下，这一功能的上线精准击中了用户长期存在的数字传承痛点，显得尤为重要且及时。 数字时代传承刚需，亟待可落地的解决方案 当下，我们的人生轨迹正越来越多地沉淀在数字世界之中。无论是记录亲情与生活的照片视频、承载个人思绪的备忘录与录音，还是凝聚了创作心血的各类数字文件，这些数字资产早已超越了数据本身，成为兼具情感价值与财产属性的个人核心资产。但与之相对的，是数字资产长期存在的继承困境。 当前用户的数字资产大多分散在不同平台，各平台关于账号权属、转让与继承的规则各不相同，用户一旦离世，其留存的数字内容很可能因账号被收回、删除而永久灭失，造成个人情感记忆与数字财富的双重折损，数字遗产的继承问题变得愈发刻不容缓。 而目前行业内完善、可落地的数字资产继承范式仍在探索之中，鸿蒙操作系统 6.1 此次上线该功能，也是直面用户的核心焦虑，为仍在蓬勃壮大的鸿蒙用户群体提供了一份可靠的数字资产传承方案。 以安全为核心，全流程用户自主可控的继承方案 对于数字资产继承，用户最关切的，必然是隐私保护与数据安全，鸿蒙数字资产继承功能支持用户在开通云空间后，从图库、联系人、备忘录、录音等数字内容中进行继承范围选择。若用户启用云盘服务，还可将重要的文档、文件等数据上传至云盘，实现更多样化的数字资产继承，覆盖了用户绝大多数的数据场景，充分满足用户的自主性。 此外，用户最多可指定 5 位数字资产继承人，并可为每一位继承人单独设置差异化的数字资产继承范围，保护自己隐私的同时，避免后续可能出现的纠纷。 设置完成后生成的专属访问密钥，由用户本人全权保管，用户可自主选择转交密钥的时间与方式，也可随时移除、重新设置继承人，或是调整继承资产的范围，整个过程无需额外的繁琐流程，所有规则的变更均由用户一手掌控。 而在继承人申请访问的核心环节，系统设置了三重不可缺一的认证关卡，全面防范数据泄露风险。 首先，继承人必须先完成本人的身份证与人脸实名认证，通过后才能启动继承申请流程； 其次，申请人必须提交与该继承权限匹配的专属访问密钥，该密钥仅在用户设置继承人时生成，由用户本人保管转交，与账号一一绑定，错配则无法进入下一环节； 最后，申请人必须上传符合法律规范的逝者死亡证明材料，所有材料均需经过华为法务团队的专业人工审核。 只有三项认证全部通过，继承人才能获得对应数字资产的访问权限。 除此之外，系统还在访问环节设置了多重安全兜底机制。审核通过后，继承人仅能下载用户生前指定范围的数字资产数据包，且必须为该数据包单独设置解密密码；同时，数据包的下载有效期仅为 30 天，过期后将自动失效，进一步缩小了数据泄露的风险窗口，最大程度保障用户的数字隐私与资产安全。 可以看到，依托鸿蒙系统的底层安全架构，数字资产继承功能将安全落实在了功能设置、申请、访问等全流程，为用户数据的传承提供了专属的系统级保障。 结语 数字世界里的每一张照片、每一段录音、每一条备忘录，都是一个个人生轨迹的留存和情感的寄托。 HarmonyOS 6.1 上线的数字资产继承功能，其实就是以技术为桥，打通了数字时代情感与记忆的传承路径。系统还通过架构优化，实现了添加继承人与访问继承资产的入口统一，简化了操作路径，让不同年龄层的用户都能轻松完成相关设置与操作。正是这些有温度的产品设计，让那些珍贵的数字记忆得以被安全托付、跨越时间延续，让用户得以完成了一场数字人生的温暖闭环。
https://www.nature.com/articles/s41564-026-02316-4 [!abstract]+ 细菌利用免疫系统来检测和防御包括噬菌体在内的可移动遗传元件。基因转移因子（GTA）是驯化的原噬菌体，具有噬菌体样特性，包括诱导宿主细胞裂解以进行基因转移的能力。GTA 是否会诱导或逃避细菌免疫系统尚不清楚。本研究利用转座子诱变和深度测序筛选新月柄杆菌（Caulobacter crescentus），鉴定出一个三元系统 LypABC，该系统对于 GTA 介导的细胞裂解和基因转移至关重要。LypABC 类似于 caspase 募集结构域-核苷酸结合富亮氨酸重复序列（CARD-NLR）抗噬菌体防御系统。LypABC 对于 DNA 包装成 GTA 颗粒并非必需，但对于宿主细胞裂解是必需的，该过程涉及 LypA 和 LypC 的肽酶结构域以及 LypB 的 ATPase 结构域。由于 LypABC 过量表达具有毒性，因此需要通过转录抑制因子 CdxB 进行严格调控。 CdxB 与 lypABC 和必需的 GTA 激活基因的启动子结合，将 GTA 激活与宿主细胞裂解偶联起来。我们的研究结果表明，细菌免疫系统可以被 GTA 所利用，从而支持水平基因转移。 2 个帖子 - 2 位参与者 阅读完整话题