xiaohack博客专注前沿科技动态与实用技术干货分享，涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容，提供开源项目教程、科技资讯日报、工具使用指南，助力开发者、AI 爱好者获取前沿技术与实战经验。
同事 A 为公司合伙人(技术强、经验丰富)，remote 在城市 B 办公，跟行业内竞争对手公司的销售私下做了无数的私活儿（实体行业，需要出差去支持，在我司的打卡记录正常）
近两年开始当商业间谍帮竞争对手翘公司的大单（项目都是几千万量级，公司跟进大半年，后续会变为他的私活儿）
25 年初公司丢了一单这种性质的，因此公司为了降低他的影响，边缘化一年吧(工资依旧很高)
当下也有一单面临相同的情况，且电话里跟销售同事全都摊牌了，信息是他透露给竞争对手公司（竞争对手直接跟客户讲 A 马上去他们那边入职， 支持都是 A 支持。A 也参加这个项目我们这边的售前工作， 竞争公司没这方面技术猜测售前也是 A 支持）
同事 A 目前已经提出辞职，且说销售同事恐吓他（公司内部一个团队整整跟了半年吧，多少当时有些生气的），直接去翘单公司跟人合伙
OP 同为合伙人，实在忍不了，他个人出行记录 100%有多次肯定跟实际 remote 的地址不一致的，因为工作时基本上都联不上他，有时候手机直接工作时间关机(推测坐飞机)
想听听大佬们的建议！！！
跨境支付、SaaS、出海电商、金融/加密业务的团队都会遇到用户IP是否来自制裁地区的问题，如果判断失误，损失一定的订单事小，出现合规事故后，解决合规事故的精力、损失的时机才是最难以挽回的东西。 其实这个问题源自于，合规问题并不是一个国家维度的问题，举个“栗子”： 所以单单是指判断国家相关，一定是不够的，所以基本做法应该是： 1、第一层：IP→国家/地区（基础过滤） 逻辑应该是-IP是否落在被明确制裁的地理区域内 这一步依赖的是IP地理定位数据的精细度，是否能做到“地区级别”，导入IP数据云IP地址查询定位库，足够用了。 2、第二层：反规避判断（非常容易被忽略） 所以可以导入IP数据云的风险画像系统： 1）、只用免费IP查询接口 2）、规则写死在代码里其实这个问题很多相关业务的团队都会注意到，将有关制裁国家的IP封禁，但后来还是会出现合规问题。为什么？
A国家中有①②③个城市，B国家有④⑤⑥个城市，当业务侧处理A、B国家的合规问题时，不是“IP解析 → A/C国家 ≠/＝ 制裁国 → 放行/拦截”就可以的，因为常常会出现以下情况
1）、A国家不制裁相关产品，但是③城市制止
2）、B国家个人放行，但加密、金融、云服务相关合规
国家（Country）→一级行政区（Region/Province/State）→城市（City）
Country=A
Region=③
→命中制裁
制裁地区用户不会老老实实用本地IP，常见规避方式包括：
V口N/Proxy、云厂商出口IP、Tor/匿口名网络、卫星网络
1）、IP是否为代口理/V口N/IDC/云IP
2）、IP ASN 是否异常
典型策略是：
制裁业务=地理命中+风险IP命中 → 拒绝或人工审核
！注意项
免费库：
地区精度不足（只到国家）
制裁地区更新滞后（版本落后）
免费≠可合规使用（有一些国家需要查看合规IP信息的来源，作为合规证明）
制裁名单是动态变化的（信息更替不及时，触发合规制裁）：
地区新增
限制升级
规则一定要可配置、可更新
最近看到了很多关于 Antigravity 写 commit 很难的评论
我有一个比较成熟的方案，这个方案写的又快又准
大家可以参考一下
在AI计算和大模型训练需求快速增长的当下，成都作为西部算力枢纽的重要性日益凸显。越来越多的企业选择在成都托管GPU服务器，既享受西部地区的成本优势，又能获得专业的数据中心服务。那么成都的GPU服务器托管到底能带来哪些实际价值? 成都GPU托管的独特优势 网络质量是首要考量。成都作为国家级互联网骨干节点，拥有直达东部的低延迟链路。极云科技在成都的机房采用BGP多线接入，到重庆、西安等西部城市的延迟控制在5ms以内，到上海、北京等地也保持在30ms左右，为分布式计算和实时推理提供了稳定保障。 电力保障同样关键。GPU服务器功率密度高，8卡A100/H800集群峰值功耗可达6-7kW。极云科技的成都机房配备2N冗余供电系统，智能PDU支持每端口电流监控，确保高功率设备稳定运行。我们还为GPU集群设计了独立的电力回路，避免不同设备间相互干扰。 专业运维团队不可或缺。GPU服务器的运维比普通服务器复杂得多，从驱动版本兼容到多卡通信优化都需要专业知识。极云科技的工程师团队熟悉各类AI框架和GPU应用场景，提供从硬件监控到性能调优的全方位服务，确保客户的训练任务高效完成。 典型应用场景 AI模型训练与推理：成都相对较低的综合成本使其成为模型训练的理想选择，极云科技为客户提供从单机8卡到多机集群的不同配置。 影视渲染与数字内容制作：借助GPU强大的并行计算能力，渲染任务完成时间可缩短60%以上。 科学计算与仿真模拟：在生物医药、气象预报等领域，GPU加速能显著提升计算效率。 选择托管服务的关键点 首先要评估机房的真实能力：不仅仅是看Tier等级，更要了解实际电力密度、散热方案和网络架构。极云科技的成都机房支持单机柜15kW功率密度，采用冷热通道隔离和精准送风设计。 其次要测试网络性能：特别是跨区域访问质量。我们提供测试机服务，客户可以在部署前实际验证到目标用户群的网络表现。 还要关注增值服务：比如是否支持混合云架构、是否有容灾方案。极云科技为客户提供与公有云打通的专线连接，构建灵活的混合算力架构。 总的来说，成都GPU服务器托管正在成为西部地区的优选方案。它既保留了本地部署的数据控制权，又提供了专业数据中心的设施保障。 如果您正在规划GPU算力部署，欢迎了解极云科技成都机房的GPU托管服务。我们提供从咨询规划、部署实施到持续运维的全流程支持，帮助您的AI业务在西部稳健落地、高效运行。
我们很高兴地宣布 Rspress 2.0 的正式发布！ Rspress 是基于 Rsbuild 的静态站点生成器，专为开发者打造的文档站工具。自 2023 年正式发布以来，Rspress 1.x 累计迭代 144 个版本，共有 125 位贡献者 参与项目开发。越来越多的开发者选择 Rspress，借助其高效的编译性能、约定式路由和组件库预览等功能，构建了可靠的文档站点。 根据社区的反馈和建议，Rspress 2.0 在 主题美观度、人工智能原生、文档开发体验、与 Rslib 一起使用 等方面进行了更深入的研究。 Rspress 1.x 已经解决了文档站框架编译性能的问题，但仍然存在一些问题影响着作为文档开发工具的核心体验。2.0 版本将不仅仅针对编译性能的追求，也侧重于文档站体验的其他方面： 主题风格：一套更美观的默认主题，并提供了多种自定义主题方式，解决了 1.x 在主题定制上缺乏稳定 API 的问题； AI-native：文档不仅服务于人类读者，也需要被 Agent 更好地理解和使用。Rspress 现在内置了 llms.txt 生成并从 SSG 衍生出的 SSG-MD 功能，生成高质量的 Markdown 渲染内容供 Agent 读取； 双击编译，瞬间启动：默认启用 lazyCompilation，配合链接悬停时对资源的预加载功能，仅在访问特定路由时构建所需文件，无论实现项目规模大小，dev 也可瞬间启动； Shiki 代码高亮：默认集成 Shiki，在构建时完成语法高亮，支持主题切换、变压器扩展，比如 @rspress/plugin-twoslash，带来更丰富的代码块展示效果； 文档开发体验：优化 Rslib 集成：现在可以在使用 这是一次对现有架构的全面升级，下面将介绍 Rspress 2.0 及其 全新主题、高质量 llms.txt 生成、集成 Shiki、后续编译等重要功能。 2.0 默认主题令人期待的一次系统性升级，它由团队设计师 @Zovn Wei 整体设计，在视觉效果和阅读体验上都有较轻的提升，并且每个组件需要独立替换，拥有非常多的可定制性。 主题定制 按照定制化程度从低到高，有 CSS 变量、BEM 类名、ESM 重导出覆盖、组件弹出四种自定义主题[11]方式。 CSS 指标：新主题涉及了更多 CSS 指标，覆盖主题颜色、代码块、首页等样式。您可以在 CSS 指标[12] 页面进行预览并调整所有 CSS 指标，找到满意的配置后直接复制到项目中使用。 BEM 类名：内置组件现在均采用 BEM 命名规范。这是十分之一 Old School 的选择，但也是我们深思熟虑的决定。用户可以通过 CSS 选择器精准调整样式，HTML 结构更加清晰；同时与 Rspress 用户自身使用的 CSS 框架解耦合，用户可以任意选择 CSS 框架（Tailwind [14]、Less [15]、Sass [16] 等），比如使用 Tailwind V4 或 V3 而不用担心版本，也不用担心与 Rspress 内置 CSS 产生冲突。 ESM 重导出覆盖：如果 CSS 上的修改无法满足定制需求，可以通过 JS 进行更深度的定制。在 修改组件弹出：你可以使用全新的 `rspress pop [组件]` 命令，这个命令将指定的组件源代码复制到 导航栏、侧边栏标签 Rspress 2.0 实现了 Tag 组件[19]，现在可以使用 frontmatter 中的标签属性，在侧边栏或导航栏进行 UI 标注。 内置多语言支持 在 1.x 版本中，Rspress 仅内置了中文，如果使用其他语言如 zh，必须对所有的文本都进行配置，使用起来更繁琐。现在 2.0 主题内置了 zh、en、ja、ko、ru 等多种语言的翻译文本，系统会根据语言配置自动进行“Tree Shaking”，仅限你使用到的文本及语言，未内置的语言会兜底到 en 文本。您也可以通过 `i18nSource` 配置项扩展或覆盖翻译文本。 Rspress 未来会支持更多内置语言，如果你有兴趣，请参考 这位贡献者的 Pull Request [21]。 Rspress 现在将 llms.txt [22] 生成能力集成到 core 中，并实现了全新的 SSG-MD（Static Site Generation to Markdown，静态站点 Markdown 生成）能力。 在基于 React 动态渲染的前端框架中，往往存在静态信息无法提取的问题，Rspress 也面临同样的挑战。Rspress 用户通过 MDX 片段[23]、React 组件、Hooks 以及 TSX 路由等动态特性来增强表现力。但这些动态转换在 Markdown 文本内容时会面临以下问题： 直接将 MDX 输入给 AI 会包含大量代码噪音，并丢失 React 组件内容； 将 HTML 转为 Markdown 往往效果不佳，信息质量难以保证。 为了解决这个问题，Rspress 2.0 引入了 SSG-MD [24] 特性。这是一个全新的功能，它类似于 静态站点生成（SSG）[25]，但不同的地方相当于你的页面渲染为 Markdown，而不是文件 HTML 文件，并生成 llms.txt [26] 及 llms-full.txt 相关文件。 相比于将 HTML 转化为 Markdown 等传统方式，SSG-MD 在渲染期间拥有更优质的信息源，比如 React 虚拟 DOM，从而保证更高的静态信息质量和灵活性。 启用方式非常简单： 构建后将生成如下结构： 若想定制自定义组件的渲染内容，可通过环境变量控制： 这样既保证了文档的交互体验，也能帮助 AI 理解组件的语义信息。 参见 SSG-MD 使用指南[27] Rspress 2.0 默认使用 Shiki [28] 进行代码高亮。相比 1.x 的 prism 运行时高亮方案，Shiki 在编译时完成高亮处理。 支持多种主题样式，比如在 CSS 变量[29] 页面可以交互式切换和预览不同的 Shiki 主题。 同时 Shiki 也允许使用自定义的 变压器[30] 进行扩展来丰富的写作，例如 twoslash 等。 引入编程语言，不增加运行时间和包体积。 基于 TextMate 语法实现与 VS Code 一致的准确语法高亮。 下面是一些 Shiki Transformer 的视觉，仔细感受 Shiki 带来的文档创意： 使用 @rspress/plugin-twoslash [31] 使用 transformerNotationFocus [32] 参见 代码块[33] Rspress 2.0 底层由 Rsbuild 和 Rspack 2.0 预览版本驱动，同时默认开启了后续编译[34] 和 持久化存储[35]。 编译 默认开启 dev.lazyCompilation [36]，只有当你访问某些页面时，该页面才会被编译，大幅提升了开发速度启动，甚至实现了数十级的冷启动。Rspress 同时实现了路由的预加载策略，当鼠标暂停在链接上时会预先加载目标路由页面，搭配 lazyCompilation 实现稀疏的开发体验。 持久化存储 2.0 默认同时开启了 持久化服务器[37]，在热启动中复用上次编译的结果，提升了 30%-60%的构建速度。这意味着在首次运行 默认开启死链检查 Rspress 2.0 默认开启死链检查功能。在构建过程中，会自动检测文档中的无效链接，帮助你及时发现和修复。 参见 链接[38] 文件代码块 您可以使用 file="./path/to/file" 属性来引用外部文件作为代码块的内容，将示例代码放在单独的文件中维护中。 请参阅 文件代码块[39] 预览 更灵活的元用法 @rspress/plugin-preview [40] 现在基于元属性使用，更加灵活，也可以殴打文件代码块。 下面是一个使用 iframe 预览代码块的示例： 它将会渲染为： 并且 @rspress/plugin-playground [41] 现在支持和 plugin-preview 一起使用，通过 meta 属性切换即可，例如 支持 HMR 的一些配置文件 基于 Rsbuild 重新设计的 虚拟模块插件[42]，现在支持 在使用 执行 模版中内置了 rsbuild-plugin-workspace-dev [43] 插件，可在启动 Rspress 开发服务器的同时自动运行 Rslib 的 watch 命令。 直接运行 Rspress 2.0 新增了多个官方插件： @rspress/plugin-algolia：支持替换 Rspress 的内置搜索为 Algolia DocSearch （感谢 @algolia 团队的帮助）； @rspress/plugin-twoslash：为 TypeScript 代码块添加类型提示； @rspress/plugin-llms：为不支持 SSG 和 SSG-MD 的项目提供 llms.txt 生成能力； @rspress/plugin-sitemap：自动生成 Sitemap 文件，用于优化 SEO。 如果您是 1.x 项目的用户，我们准备了一份升级的迁移文档，帮助您从 1.x 升级到 2.0。 你可以直接使用 Pages 中的“复制 Markdown”功能，将其输入给你常用的编码代理（如 Claude Code 等）来完成迁移。 请参考 迁移指南[51]。 我们注意到很大一部分 1.x 用户为了使用 Shiki、组件库预览功能和自定义评论/rehype 插件，而主动关闭 为了换取更好的扩展性和可维护性，我们决定在 Markdown/MDX 编译流程中不再使用 Rust 版本的 MDX 解析器（ Rspress 2.0 要求 Node.js 版本 20+，React 版本 18+。 Rspress 将 如果你开发了 Rspress 插件，那么该插件的 peerDependency 从 Rspress 2.0 的发布只是一个新的起点。本次发布后，Rspress 将持续迭代： 推进生态集成：与 Rslib、Rstest 更深度地结合，提供接入组件项目和库项目的标准化开发体验； 探索 AI 与文档更复杂的集成：如智能问答、自动摘要等；完善 SSG-MD 决策并更加自动化。 感谢所有为 Rspress 做出贡献的开发者和用户！如果您在使用过程中遇到问题或有任何建议，欢迎在 GitHub Issues [52] 中反馈。 立即使用或升级到 Rspress 2.0，体验全新的文档开发之旅！ 博客原文链接：https://rspress.rs/zh/blog/rspress-v2 参考资料 [1] Rsbuild：https://rsbuild.rs/ [2] 自定义主题： https://v2.rspress.rs/zh/guide/basic/custom-theme [3] llms.txt： https://llmstxt.org/ [4] SSG-MD： https://v2.rspress.rs/zh/guide/basic/ssg-md [5] 懒加载编译： https://rspack.rs/guide/features/lazy-compilation [6] @rspress/plugin-twoslash: https://v2.rspress.rs/zh/plugin/official-plugins/twoslash [7] json 模式： https://v2.rspress.rs/zh/guide/basic/auto-nav-sidebar #json -schema-type 提示 [8] @rspress/plugin-preview: https://v2.rspress.rs/zh/plugin/official-plugins/preview [9] @rspress/plugin-playground： https://rspress.rs/plugin/official-plugins/playground [10] @Zovn 魏： https://x.com/wei_zhong41532 [11] 自定义主题： https://v2.rspress.rs/zh/guide/basic/custom-theme [12] CSS 变量： https://v2.rspress.rs/zh/ui/vars [13] BEM 命名规范： https://getbem.com/ [14] Tailwind： https://tailwindcss.com/ [15] Less： https://lesscss.org/ [16] Sass： https ://sass-lang.com/ [17] ESM 重新导出： https://v2.rspress.rs/zh/guide/basic/custom-theme #reexport [18] [19] 标签组件： https://v2.rspress.rs/zh/ui/layout-components/tag [20] [21] 贡献者的 Pull 请求： https://github.com/web-infra-dev/rspress/pull/2827 [22] llms.txt： https://llmstxt.org/ [23] MDX 片段： https://v2.rspress.rs/zh/guide/use-mdx/components [24] SSG-MD： https://v2.rspress.rs/zh/guide/basic/ssg-md [25] 静态站点生成（SSG）： https://v2.rspress.rs/zh/guide/basic/ssg [26] llms.txt： https://llmstxt.org/ [27] SSG-MD 使用指南： https://v2.rspress.rs/zh/guide/basic/ssg-md [28] Shiki： https://shiki.style/ [29] CSS 变量： https://v2.rspress.rs/zh/ui/vars [30] 变形金刚： https://shiki.style/guide/transformers [31] @rspress/plugin-twoslash: https://v2.rspress.rs/zh/plugin/official-plugins/twoslash [32] transformerNotationFocus： https://v2.rspress.rs/zh/guide/use-mdx/code-blocks #transformernotationfocus [33] 代码块： https: //v2.rspress.rs/zh/guide/use-mdx/code-blocks #shiki -transformers [34] 编译： https://rspack.rs/zh/guide/features/lazy-compilation [35] 持久化服务器： https://rsbuild.rs/zh/config/performance/build-cache [36] dev.lazyCompilation： https://rsbuild.rs/zh/config/dev/lazy-compilation [37] 持久化服务器： https://rsbuild.rs/zh/config/performance/build-cache [38] 链接： https ://v2.rspress.rs/zh/guide/use-mdx/link [39] 文件代码块： https: //v2.rspress.rs/zh/guide/use-mdx/code-blocks #file -code-block [40] @rspress/plugin-preview: https://v2.rspress.rs/zh/plugin/official-plugins/preview [41] @rspress/plugin-playground: https://v2.rspress.rs/zh/plugin/official-plugins/playground [42] 虚拟插件模块： https://github.com/rstackjs/rsbuild-plugin-virtual-module [43] rsbuild-plugin-workspace-dev： https://github.com/rstackjs/rsbuild-plugin-workspace-dev [44] @rspress/plugin-algolia： https://v2.rspress.rs/zh/plugin/official-plugins/algolia [45] Algolia DocSearch： https://docsearch.algolia.com/ [46] @algolia： https://x.com/algolia [47] @rspress/plugin-twoslash： https://v2.rspress.rs/zh/plugin/official-plugins/twoslash [48] @rspress/plugin-llms： https://v2.rspress.rs/zh/plugin/official-plugins/llms [49] @rspress/plugin-sitemap： https://v2.rspress.rs/zh/plugin/official-plugins/sitemap [50] 网站地图： https://www.sitemaps.org [51] 迁移指南： https://v2.rspress.rs/zh/guide/migration/rspress-1-x [52] GitHub Issues： https://github.com/web-infra-dev/rspress/issues为什么是 Rspress 2.0
_nav.json、_meta.json 文件的 HMR 等并新增 json schema 用于 IDE 内的代码提示；默认开启死链检查功能；新增文件代码块语法，支持外部引用文件；@rspress/plugin-preview 和 @rspress/plugin-playground 支持同时使用等；create-rslib 创建组件库项目时，选择 Rspress 作为文档工具，快速构建组件库项目站点。
2.0 新特性
全新主题
:root { /* 自定义主题色 */ --rp-c-brand: #3451b2; --rp-c-brand-dark: #2e4599; /* 自定义代码块样式 */ --rp-code-block-bg: #1e1e1e;}复制代码/* BEM 命名规范 */.rp-[component-name]__[element-name]--[modifier-name] {}/* 根据 BEM 类名轻松覆盖组件样式 */.rp-nav__title { height: 32px;}.rp-nav-menu__item--active { color: purple;}复制代码theme/index.tsx 中使用 ESM 重导出[17]，可以覆盖任意一个 Rspress 的内置组件。
theme/components/ 目录下，你可以自由这些代码，甚至直接替换 AI，来实现深度定制。# 将 DocFooter 组件导出到 theme 目录rspress eject DocFooter复制代码---tag: new, experimental # 会在 H1 和 Sidebar 进行显示---import { Tag } from '@rspress/core/theme';# Tag## Common tags <Tag tag="new" /> {/* 会在右侧 outline 进行显示 */}复制代码
llms.txt 支持
import { defineConfig } from '@rspress/core';export default defineConfig({ llms: true,});复制代码
Shiki 编译时代码块高亮
const hi = 'Hello';const msg = `${hi}, world`;// ^?复制代码console.log('Not focused');console.log('Focused'); // [!code focus]console.log('Not focused');复制代码构建性能提升
rspress dev 或 rspress build 之后，后续启动速度都会明显提升。文档开发体验
import { defineConfig } from '@rspress/core';export default defineConfig({ markdown: { link: { checkDeadLinks: true, // 默认开启，可通过 false 关闭 }, },});复制代码
```ts file="./_demo.ts"```复制代码```tsx file="<root>/src/components/Button.tsx"```复制代码```tsx preview="iframe-follow" file="./_demo.ts"```复制代码
```tsx playgroundi18n.json、_nav.json、_meta.json文件代码块以及 @rspress/plugin-preview 中 iframe 相关的 HMR。修改这些配置文件后，页面会自动热更新，无需手动刷新。Rslib 和 Rspress
create-rslib 项目项目时，您现在可以选择 Rspress 工具。这让您能够在开发组件库的同时，快速搭建搭建的文档站点，用于编写创建组件的使用说明、展示 API 参考，或实时预览组件效果。npm create rslib@latest 并选中 Rspress，会生成下方的文件结构：├── docs│ └── index.mdx├── src│ └── Button.tsx├── package.json├── tsconfig.json├── rslib.config.ts└── rspress.config.ts复制代码npm run doc 启动 Rspress 的开发服务器对 Rslib 组件库进行预览：{ "scripts": { "dev": "rslib build --watch", "doc": "rspress dev" // 执行该命令 }}复制代码更多 Rspress 官方插件
其他重大变化
从 Rspress 1.x 迁移
删除 mdxRs 配置
mdxRs，并且在开启循环编译和持久化缓存后，即使使用 JS 版本的 mdx 解析器，性能优化效果已经非常显着。@rspress/mdx-rs）。这使得 Rspress 能够更好地集成 Shiki 等 JavaScript 生态的工具。Node.js 与下游依赖版本要求
包名及导入路径变更
rspress、、、@rspress/runtime都 整合进了 中，项目@rspress/shared和 插件现在只需安装一个包即可。@rspress/theme-default@rspress/core@rspress/core{ "dependencies": {- "rspress": "1.x"- "@rspress/shared": "1.x"+ "@rspress/core": "^2.0.0" }}复制代码- import { defineConfig } from 'rspress/config';+ import { defineConfig } from '@rspress/core';复制代码- import { useDark } from 'rspress/runtime'- import { PackageManagerTabs } from 'rspress/theme';+ import { useDark } from '@rspress/core/runtime'+ import { PackageManagerTabs } from '@rspress/core/theme';复制代码rspress 更改为 @rspress/core：{ "peerDependencies": { "@rspress/core": "^2.0.0" }}复制代码下一步
npm create rspress@latest复制代码rspress eject [component]: https://v2.rspress.rs/zh/api/commands #rspress -ejecti18nSource： https://v2.rspress.rs/zh/api/config/config-basic #i18nsource
2023 年，在百模大战正激烈的时候，面壁智能突然转向端侧大模型，这一战略决策受到了外界不少质疑，直到次年苹果的入局才让市场相信他们的判断。3 年后，面壁的打法和认知更为坚定和清晰，并火力全开：发布首个可以“即时自由对话”的大模型、年中发布首款 AI 硬件松果派（Pinea Pi）以支持硬件场景的全栈开发。 2 月 4 日，面壁正式发布并开源了新一代全模态旗舰模型 MiniCPM-o 4.5。作为原生全双工的全模态大模型，MiniCPM-o 4.5 新引入了一种端到端的“边看、边听、主动说”的全模态能力：模型可以进行即时、自由的对话交互，弱化了传统对话中“一问一答”的轮次概念，而是允许模型根据语义和场景，自主判断是否发起对话。 直接看具体效果： 上述展示中模型一直在观察，且没有涉及复杂的调度 “全模态能力是 AI 进入人类物理世界所必备的一项基础能力。这一次的全模态模型，最大的特色在于高度拟人、自然的交互方式，也就是说，看、听、说是并行发生、互不阻塞，不再采用过去那种回合制交互。这在技术上是一次非常重要的跨越，也是未来 AI 真正进入物理世界所必须具备的基本能力。”面壁智能联合创始人兼首席科学家刘知远说道。 清华大学人工智能学院助理教授、面壁智能多模态首席科学家姚远，主要负责 MiniCPM-o 4.5 的研发。他介绍，该模型主要依赖两项核心创新：一是全双工机制，多模态输入和输出彼此不阻塞，模型可以持续感知外界的视频和音频流，同时进行语音或文本输出，不会因“正在说话”暂停对外界的感知；二是全模态的自主交互机制，模型会持续判断当前语义是否已经成熟，是否达到了适合触发自身输出的时机。 他坦言，目前市面上大多是将图像模型、语音模型，甚至 instruct 模型和 thinking 模型拆分为不同的模型分别训练。面壁这次尝试将所有能力统一训练到一个模型中，面临了不小的挑战。 首先就是多维度一起训练，整体难度会急剧上升，再加上端到端的多模态训练，本身就会显著增加系统负担；其次 9B 参数规模下，要在语音、全模态交互以及视觉能力等方面取得不错效果，就要对模型如何学习和吸收知识有更深入的理解，能够更精细地把握模型在不同训练阶段的学习动态，避免新引入的知识与已有能力之间产生冲突。这期间，技术团队克服了大量困难。 最后，团队能够在多模态训练过程中较好地保持文本能力，instruct 能力没有明显损失，甚至实现小幅提升。此外，模型通过更低的显存占用、更快的响应速度，确保在提供 SOTA 级全模态表现的同时，实现了最佳的推理效率和最低的推理开销。 Github：https://github.com/OpenBMB/MiniCPM-o Hugging Face: https://huggingface.co/openbmb/MiniCPM-o-4_5 体验链接：https://minicpm-omni.openbmb.cn/ 目前，模型记忆大概在一分钟左右，也模型推理的最佳“舒适区”。姚远表示，Infra 层虽然可以支持更长时间的训练和推理，但如果模型未来要承担更长期、甚至接近全天候陪伴式的使用形态，就必然要在方法和机制上做更多创新。 端侧对低延时要求非常高。这次，模型侧的低延迟优化主要来自两点：首先，在全双工状态下，模型不再依赖外部的微型工具或小模型来判断“什么时候开始推理”，传统逻辑里需要固定等待的时间被去掉，模型可以直接基于语义判断无缝生成回应。其次，现在不少方案会把语音 token 直接放进一个大模型里统一生成，这会带来非常沉重的计算开销。面壁技术团队采用的方式是，一个大的主干模型加一个轻量级语音生成模块，在保证效率的同时，两者通过稠密的隐藏层连接，把主 token 与各个头部 token 紧密关联起来，因此实现控制能力不受影响。 而使用侧的系统层面，则依赖于高效的推理框架 llama.cpp-omni 和低延迟的交互系统。 姚远指出，多模态数据本身并不是最大的问题。预训练阶段“数据燃料耗尽”主要指文本数据；而在多模态领域，当前的挖掘程度远远不够，甚至都还没有真正找到一种非常有效的方式系统利用这些数据。而全双工、全模态的自主交互机制，可能正是未来新的学习与增长方式。 当前，如何在不牺牲单任务性能的前提下，实现统一建模、高效泛化以及理解生成一体化，是当前业内积极探索的研究方向，如今面壁也迈出了自己的关键一步。 端侧领域，除了开发端原生的模型，与芯片厂商的合作也越来越重要。 一方面，芯片厂商非常希望从前沿端侧模型的公司，获取未来训练模型的规划和展望，这有助于设计新的芯片；另一方面，模型公司在设计和训练新模型时，也希望能够提前了解芯片的特性，说明需要的算子类型和架构特点，以确保训练出的模型在这些芯片上运行时效率最高。 面壁如今就在成为连接芯片厂商和终端厂商的重要媒介，而且还要连接更多的开发者：今年面壁发力的重点之一便是开发者生态。 25 年上半年，面壁投资人在深圳调研发现，在深圳做 AI 硬件的项目，凡涉及端侧模型的，超过一半以上都在使用 MiniCPM。这是面壁今年开始建设开发者生态、提供硬件的根本原因。 面壁智能联合创始人兼 COO 雷升涛解释，单纯依靠商业化，把 MiniCPM 部署到数百亿台设备上会比较困难，而通过生态建设可以让开发者一起参与推动。生态的优势在于自然生长，只要有好的基础，它就会衍生出许多依赖性的、难以想象的应用。对于“应该能开发出哪些硬件”的问题，面壁没有设定特别明确的规划或期待，而是把答案留给了开发者。 面壁践行这一策略的首个举措就是发布松果派：一款 AI 原生 (AI Native) 的端侧智能开发板。 这背后的逻辑是：推广语言模型相对容易，但当模态增加、要在设备上运行、进行微调、完成对齐后再开发应用，难度就显著提升，这部分难度需要依靠工具和软硬件来解决，承载这部分功能的就是松果派。未来面壁模型发布时，就会针对指定硬件进行优化，减少用户在适配上消耗的大量精力。 松果派构建了一套软硬一体、全栈覆盖的端侧 AI 软件体系。其基于 NVIDIA Jetson 系列模组打造，内置麦克风、摄像头、丰富的接口等多模态硬件组件，以便开发者高效开发和调用。 松果派计划在年中正式量产上市，但它今年不会承担面壁特别强的商业化诉求，更多是承担市场教育作用：让更多的人能更快体验模型能力，并在各类场景中应用起来。打通端侧模型到应用的最后一公里硬件、实现对用户痛点的覆盖，就是面壁今年的目标。 面壁目前并未透露具体价格，但肯定地表示不会以盈利为主要目的。最初版本选择了在全球范围内相对成熟的方案，接下来会陆续推出相应的国产化版本以及不同算力的版本，并根据开发者反馈进行规划和调整。 这次松果派的硬件本身是由合作伙伴完全设计，面壁主要将其整合应用。面壁智能联合创始人兼 CEO 李大海强调，面壁最重要的是做端侧原生，聚焦端侧模型研发。“端侧模型的商业化落地，本身既是对我们模型能力的验证，也是为端侧模型建立数据飞轮，形成完整的闭环。从核心来看，我们的工作一直很专注。在过去，虽然出现了许多看似有吸引力的机会，但我们始终坚持取舍，最终选择聚焦在端侧模型这件事情上。” 面壁的核心理念是大模型“知识密度定律（Densing Law）”，即大模型的知识密度大约每 100 天提升一倍。这引发了一个重要推论：大模型的保鲜期非常短。换句话说，任何一家大模型公司都必须持续不断地推出优秀的大模型。回顾国内外所有模型厂商，没有任何例外。 “如果一个厂商只能在某一个时间点推出一个模型，那么它实际上无法在行业前沿持续存在；半年、一年之后，用户很可能就会忘记这个模型。因此，关键不在于推出单一优秀模型，而在于能够持续不断地推出优秀模型。”李大海说道，“面壁的目标是打造一个能够持续训练出高知识密度大模型的系统。这才是我们认为最重要的产品、技术层面的核心。” 雷升涛补充道，在模型之外，把底层的 Infra 模型跑到极致也是延长模型领先时间的关键，毕竟端侧的算力很小、内存有限，各种约束都非常严苛，要做好是非常困难的。另外，产品化能力也非常关键。现在单靠模型领先已经无法持续保持竞争优势，需要通过底层基础设施、产品设计、品牌建设以及模型能力的结合，来更大程度地延长模型的“保鲜期”。 虽然面壁正在同步将商业优势、生态优势、品牌优势等单一优势转化为综合性优势，但作为创业公司，如何避免被大厂围剿仍是一个现实问题，李大海对此较为乐观。 他解释道，大厂不会放弃通用且规模巨大的市场，因此竞争激烈。相比之下，端侧是另一个重要方向。“端侧包含非常多不同的终端，每个终端面向的应用场景各不相同，因此它不是一个统一的市场，创业公司有更多机会去切入不同细分领域，而不需要像大厂那样争夺整个市场。”背后的逻辑是：端侧市场分散且长尾，同时存在许多高价值的应用场景，这正是创业公司在初期更适合重点攻克的领域。 此外，终端本身就是高度差异化的，涵盖了各种各样的类型。刘知远强调，面壁关注的是终端发展的核心需求：高效，即用尽可能少的参数实现尽可能强的能力。“从商业角度来看，面壁不会去和很多厂商打阵地战，这种做法在创业阶段并不聪明。这是一个蓝海市场，没有必要在这方面过多纠结。” 李大海也补充称，即使是在同一个领域内，要解决的客户或用户问题也是非常多样化的。同一个领域并不意味着大家一定是你死我活的竞争关系。尤其端侧市场，覆盖了非常多应用场景，能够容纳很多创业公司，让大家都有良好的发展空间。 另外，一个值得关注的现象是，面壁内部也逐渐出现了“one person company（一人公司）”趋势。 面壁内部过去十个月一直在推动全公司的 AI 原生计划。不到两百人的团队，在十个月内写了 2000 万行代码。如果按传统方式手写，这些大概需要 700 人才能完成。 其中，团队中最核心、最重度投入的一位员工，一个月就写了 65 万行代码，他把核心系统接入 AI，并重构了一遍。“未来的企业，尤其是 AI 企业，一定会是高度 AI 赋能的，也就是我们所说的 AI Native 模式。”刘知远说道。 小团队甚至个人都可以完成过去需要团队数月才能完成的工作，这是一个非常明显的发展趋势。面壁目前就在朝这个方向发展，这种模式和以往的大公司有很大的不同。 雷升涛解释，面壁内部对“AI Native”的定义包括两个方面：第一，接到任务后，第一反应是能否用 AI 来完成；第二，如果任务原本人来完成的，那么用 AI 完成后，能否做得更好。他表示，AI 已经渗透到面壁业务的各个层面，它不仅被广泛使用，还深刻地影响了大家的思维方式、工作模式乃至协作方式。 这也反映在了面壁招人的具体要求中。李大海表示，面壁一直希望能够吸引 AI 原生的人才，即在思考和解决任何问题时，都能够将 AI 能力视作自身的内在工具去应用。这背后反映的，是人才是否具备发现问题和提出问题的能力，这一点在如今时代尤为重要。同时，他们还需要能够利用 AI 快速解决问题，并具备足够强的判断能力，去评估工具产出的结果是否高质量。 “一个公司的核心竞争力，很大程度上取决于人才的密度和质量。换句话说，所谓 AI 原生，不只是态度上愿意使用 AI，更重要的是通过这个过程展现出个人的综合能力。”李大海说道。 对于未来端侧智能的发展，面壁形成了一个明确判断：端侧与云端的协同，将成为未来长期存在的主流形态。 无论是豆包手机、具身智能，还是引发广泛关注的 OpenClaw，这些爆火的案例都在验证一个趋势：智能终端正在成为大模型能力向用户延伸的重要载体。刘知远认为，这些探索共同指向一个核心愿景：大模型将越来越贴近用户。 但从现实情况来看，大部分产品目前仍主要依赖云端模型运行，由此带来了反馈延迟、隐私保护和安全性等一系列问题。因此，这一方向虽然正确但还不成熟，它只是这场大戏的序幕，甚至连序幕的开端可能都刚刚开始。 面壁判断，随着模型逐步进入物理世界，尤其是在对实时性要求极高的任务中，端侧模型将不可或缺。在本地即时处理大量数据、快速做出响应，是端侧模型的核心价值所在，这也是端云协同中，端侧不可替代的意义。 从具体终端形态来看，李大海指出，手机在大模型应用上仍有巨大的拓展空间。目前的探索更多集中在“输出”侧能力，但同样重要的还有“输入”侧。如果手机能够直接感知并理解现实环境，就可以更自然地与用户共享上下文，实现更贴近人类认知方式的交互。但这也意味着更高的技术与工程挑战：在资源受限的终端上实现复杂感知与理解能力，需要更长时间的打磨与更精细的系统优化。 而在另一个同样火热的具身智能领域，行业面临的核心挑战依然是模型的通用性与泛化能力，即能否让同一模型稳定运行在不同类型的本体之上。多模态大模型被普遍视为突破这一瓶颈的关键，为跨场景、跨本体的适应能力提供基础支撑。 在刘知远看来，多模态乃至全模态能力，正是未来多智能体体系的基础。未来将存在大量分布在不同环境中的智能终端，每个终端的感知条件、背景信息各不相同，正是这种差异性，使得终端之间的协同成为必然选择。 他解释道，从结构上看，一个智能体至少可以抽象为三个核心要素：输入 x、输出 y 和模型 m。输入天然是全模态的，人类正是通过多模态感知世界；模型负责思考、推理与决策；输出则作用于物理世界，完成各种具体行为。未来智能体能力的演进，正是围绕这三个要素不断强化与耦合，最终实现真正面向物理世界的智能行动。 在更宏观的层面，刘知远将通用人工智能的发展总结为两条主线：一是智能能力持续增强，二是智能的实现与使用不断变得高效。面壁未来的技术突破，也将围绕这两个方向同步推进。 他进一步判断，在接下来一到两年内，模型的专业能力和与现实世界交互的能力将快速提升，作为智能体，模型将逐步具备更强的自主学习与自我成长能力；当模型能够在特定领域中自主探索与进化后，多智能体协同将成为下一阶段的重要突破，不同智能体将像人类团队一样高效协作，完成单一个体难以完成的复杂任务；更长远来看，模型还将逐步展现出创新与创造能力。 与此同时，智能终端本身也将随之发生变化。“一旦终端侧模型具备自主学习与协同能力，就会形成一个关键基点：每个人都将拥有一个持续成长、越来越懂自己的大模型助手。未来三到五年，这一愿景很可能成为现实。”刘知远说道。首次手搓全双工全模态模型
让开发者回答，AI 硬件该是什么样
如何从各种竞争中突围？
内部的“一人公司”趋势
走向 AGI 的两条发展主线
一级甲等医疗事故，医方承担主要责任，网传“不缝合伤口”和“止血海绵”都属于常规操作。
春节旅行一个月,期间办公可能需要连接部分 gov 平台,国外 IP 可能会遇到各种错误,所以想备一个中国手机卡的漫游包
虽然出国过很多次,但是每次都是用国外 SIM 卡,不知道国内卡在外的 IP 是不是回属地,还是当地,还是第三地
有用过的同学推荐下用哪家比较好,包括价格和 IP 稳定性
谢谢大家
之前购买 Anthropic 官网的 tokens
用了 2 天就 This organization has been disabled.
后面感觉 claude 写后端还不错
用了蛮多的代理，蛮多不稳定有的还跑路了有的令牌分组还关闭了
https://ai.jiexi6.cn/register?promo_code=C1BECB2A9A339C5F 目前用这个还不错，推荐下~
2 月 5 日，米兰冬奥会开幕在即，国际奥委会主席柯丝蒂·考文垂在国际转播中心举行的活动中宣布，国际奥委会已基于阿里千问大模型打造了奥运史上首个官方大模型。这一奥运官方大模型将在专业赛务与公众服务双端同步落地。 在赛务侧，国际奥委会在其面向各国奥委会工作人员的网站上线了“国家奥委会 AI 助手”。该助手依托千问大模型强大的多语言理解能力，并通读数百万字官方手册。代表团成员只需用母语提问，即可获取从资格审核到后勤调度等各项问题的精准解答。这一应用有效消除了语言与地域隔阂，大幅提升了全球代表团的备赛协同效率。 （国家奥委会 AI 助手） 在公众侧，国际奥委会也将在官网（Olympics.com）上线基于千问大模型打造的“奥运 AI 助手”。该助手将面向全球观众开放，能够实时、精准地解答关于赛事规则与奥运历史的各类提问，通过 AI 技术拉近大众与奥运的距离。 考文垂在现场高度评价了 AI 技术对本届冬奥会的变革性意义。她表示，得益于千问大模型的技术支撑，2026 米兰冬奥会展现了奥林匹克运动的智能化未来，将成为史上“最智能”的一届奥运会。 据介绍，基于千问大模型 Qwen-VL 开发的自动媒体描述系统也在直播生产环节投入运行，实时识别进球、犯规等关键事件并生成描述。此外，AIGC 技术也首次大规模应用于冬奥会的内容生产环节。米兰冬奥组委会基于阿里万相大模型，高效创作了一系列面向全球粉丝的多媒体宣传素材。 除了大模型应用，阿里云 AI 增强的转播特效技术渗透率也在本届冬奥会上创下新高。针对冬奥会特有的“雪地背景纹理单一、缺乏特征点导致视觉盲区”的问题，阿里云采用多模型融合算法，攻克了雪地场景的高精度重建难题。该技术已部署于米兰冬奥的 10 个核心竞赛场馆，覆盖高山滑雪、跳台滑雪、冰球等超三分之二的比赛项目。全球观众将在转播中看到更清晰的“子弹时间”定格画面及新增的“时间切片”特效，身临其境地看清运动员在空中极速翻转的完整轨迹。 此外，作为史上赛区地理跨度最广的一届冬奥会，阿里云支撑构建了交通管理系统，在风雪交加的阿尔卑斯山区打通了从城市进入山区的“最后一公里”。同时，阿里云“能耗宝”持续运行，新增“能源问题追踪系统”，以数字化手段支撑米兰冬奥实现更可持续化的目标。 “每一届奥运会都会留下独特的遗产。而米兰冬奥会的遗产将是智能化，具体来说，是人工智能驱动的智能化。”考文垂在演讲最后总结道，“这份 AI 能力，正是米兰冬奥会留给世界的‘永恒礼物’，它将重塑奥林匹克运动会的未来。” 
在大数据平台高速发展的当下，生态扩张与业务量激增，致使大数据分布式组件问题愈发棘手，传统专家运维模式捉襟见肘。以腾讯大数据庞大的规模为例，面对海量计算单元、繁杂技术栈以及千万级任务管理，借助 AI 驱动实现大数据系统的故障和问题的快速洞察与自治能力，已成为行业迫切需求。 在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，腾讯专家工程师熊训德做了专题演讲“AI 驱动的大数据自治：智能应对复杂运维挑战”，他介绍了如何通过可拔插的决策引擎、以及数据专家自治智能体构建大数据智能管家，让企业能够理解如何高效、智能地处理复杂的运维场景，从而大幅提升大数据场景下运维效率与准确性，引领大数据线上系统迈向全面自治的实践。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 首先，我简要介绍一下整个大数据系统，以及其在自治背景下的相关挑战。大数据系统本身组件众多，涵盖了从底层的 IaaS，到存储、计算框架，以及上层的工具层等多个层面。具体来说，IaaS 层面涉及到机器本身的网络和性能，而存储层则包括分布式文件系统（如 HDFS）和对象存储等。在调度方面，我们有 Kubernetes 和 Hadoop- 体系，以及针对 AI 方面的特定调度机制。再往上一层则是计算框架，例如 Spark 和 Flink 等流计算框架。最上层则是各种工具，这些工具在不同方面的使用都使得整个大数据系统的复杂性显著增加。 大数据系统本质上是一个分布式系统。如果单机系统已经如此复杂，那么分布式系统则需要考虑数据的溯源以及在不同机器上的分布情况，无论是主从结构（master 和 slave）还是多工作节点（worker）的协作模式，都会使得整个系统在处理问题、查找根源以及故障恢复时变得极为困难。此外，大数据系统的数据处理链路通常非常长。例如，数据采集可能来源于多种源头，如代理（Agent）、MySQL 数据库，或者在物联网场景下，可能是汽车或传感器等设备。采集到的数据需要通过数据接入层，目前常见的架构包括 Kafka 或其他消息队。接入后，数据会进入计算阶段，可能是实时计算（如 Flink）或离线计算（如 Spark）。计算完成后，数据需要存储到 HDFS 系统或对象存储中。最后，在数据应用层面，我们可能需要进行预处理以供 AI 使用，进行训练或推理工作，或者生成商业智能 BI 报表。因此，整个数据链路非常长，这也使得我们在进行故障根因分析或自治处理时，需要综合考虑所有相关场景。 当我们处理大数据故障时，业务部门或客户往往会提出一个关键问题：“何时能够恢复？能否实现自动恢复，以尽快减少损失？”然而，我们在进行故障恢复或诊断时，高度依赖于运维 SRE 的专家经验。通常情况下，如果没有三年以上的大数据运维经验，很难有效且完善地处理复杂的大数据故障。此外，由于整个诊断和故障恢复的时间链路非常长，导致整体效率低下。更糟糕的是，故障可能已经结束，而我们只能进行事后处理，此时大数据系统可能已经遭受了实际的损失。 基于这些背景，我们团队在大约五年前提出了构建大数据智能管家 TCInsight 的想法，致力于解决大数据系统自治相关的工作。我们的大数据智能管家整体技术架构分为三层。 第一层是观测层。它主要负责监控基础设施即服务（IaaS），包括主机网络等的监控数据，同时采集日志和关键事件。我们还将大数据组件，如 HDFS、Spark、Hive 和 YARN 等的关键监控日志事件进行统一上报。 第二层是服务分析层，主要负责数据实时处理和算法决策洞察。服务分析层分为三个部分。第一部分是实时分析，主要目的是快速处理数据，包括异常收敛。例如，当事件或告警过多时，我们需要迅速整合，否则会给运维 SRE 或研发人员带来较大挑战。我们会对数据进行基础预处理。第二部分是离线服务，主要用于根因分析或自治服务时的离线分析和定时巡检。在数据量较大时，离线分析尤为重要。第三部分是算法决策，主要涉及模型和算法库的分析，以及知识库和评测库的建设，还包括离线训练等工作。 第三层是应用层，主要负责大数据运维自治，并对外提供接口。应用层分为两大块：自治修复和自治决策。例如，以 Hive 为例，当业务侧编写了一个 SQL 查询，可能会导致 HDFS 存储空间被占满，从而影响其他任务的提交。此时，我们需要快速对该 SQL 进行限制，或者在业务非常关键且不能直接终止的情况下，预测可能得存储和计算量，进行自助弹性伸缩。此外，我们还需要进行冷热数据分离，以实现成本分析和自助转冷操作。在自治决策方面，我们需要判断是否进行参数调优，因为某些参数调整可能需要重启系统才能生效，这可能会扩大故障范围。此时，我们需要做出关键决策，例如选择扩容，或者让 AI 参与具体工作。我们还可以进行错峰执行，例如在 YARN 的多个队列中，调整队列的执行时间，以优化资源分配。 应用层还包括业务洞察部分，主要用于预测分析、成本分析和根因分析等工作。这些工作相对滞后，我们的目标是先恢复系统，然后再进行深入分析。此外，我们还会生成巡检报表，并进行一键健康评估。健康评估在我们的系统中非常重要，它综合评估了 IaaS、存储、调度和计算等各个部分的健康状况，为关键自治决策提供依据。 在架构的中间部分是我们的算法或引擎层。引擎分为两部分：规则引擎和我们自主研发的元启引擎。元启引擎结合了 AI 算法和我们内部的混元大模型。规则引擎主要用于执行明确的操作，例如扩容，以缓解问题。对于复杂或关联性较高的场景，我们会接入算法或大模型，以提升系统的健康状况。 接下来，我会详细说明我们在大数据智能管家过程中的一些关键思考和实现能力。 由于大数据体系的复杂性，TCInsight 实现自治的是一个渐进式的过程。当我们接手一个系统时，不能期望所有大数据运维工作能够立即实现完全自治。实际上，我们基于一个较为普遍的理念：在没有一线专家或专业人才的情况下，一线人员或客户也能够实现自治处理。 我们根据问题的复杂程度进行分类处理：对于简单重复且解决方案确定问题，我们直接采用 AI 驱动的方式进行处理。目前，这类问题大约占我们总问题的 10% 左右。然而，剩下的 90% 问题尚未能完全实现自治。对于这部分问题，我们希望通过售后体系中的专项人员和 SRE 的共同努力，借助我们之前提到的平台层，利用大模型和 AI 增强能力，持续为系统提供支持。 在此基础上，我们期望通过三年以上经验的产研人员或 SRE 专家，进一步强化知识库和工具建设。通过这种逐步积累和优化我们的产品能力，我们希望能够逐步提高自治的比例，最终使其达到 90% 以上。 在业界，主要有三种常见的方法：显式编程、基于优化方法的处理以及专家系统。第一种显式编程对于研发人员来说并不陌生，它本质上是通过编写规则或工作流来构建一个简单的规则引擎，从而实现直接的决策。例如，当存储使用率超过 75% 时，系统自动触发扩容操作。这种方法简单直接，但灵活性有限。 第二种是基于优化方法的处理。在大模型尚未普及的时代，我们通过优化模型来提升系统性能。例如，原本只能优化 40% 的系统，通过采用贪婪算法或聚合模型等技术，可以将其优化效果提升至 80% 以上。这种方法更多地依赖于深度学习和大模型的强大能力，能够更好地处理复杂的优化问题。 第三种是智能全自治域系统。全自治域系统的核心在于利用专家的经验和知识，尽管专家人数有限，但他们的经验可以通过系统化的方式赋予平台更强的能力。专家系统的关键在于如何将专家的经验转化为可操作的决策逻辑。 在明确了这些决策引擎的技术路径后，我们进一步思考了在大数据领域构建智能决策系统的关键问题。首先，数据的可用性至关重要。无论是基于 AI 的训练还是大模型的应用，数据标注的准确性和完整性是基础。如果数据标注不足，可能会导致模型出现幻读甚至错误的输出，从而影响决策的准确性。 其次，系统的可解释性也是一个关键问题。专家和文档作者需要确保知识库中的内容不仅系统能够理解，而且一线人员和客户也能够轻松掌握。这一点直接关系到决策的准确性和适用范围。 最后，实时性要求也不容忽视。我们的目标是先快速恢复系统，后续再进行深入分析。这就要求决策过程和最终的行动必须足够迅速，以满足实时性的需求。 综合考虑以上因素，在决策引擎的选择上，我们决定结合规则引擎和专家系统的智能决策引擎共同构建了全自治域系统 TCInsight。这种方法既能够利用规则的明确性和可操作性，又能借助专家系统的灵活性和经验优势，逐步提升系统的自治能力和决策准确性。 在构建基于规则引擎的知识系统时，我们首先对系统中的各类数据进行了统一管理。这些数据包括指标（metrics）、日志（log）以及事件（event），我们会将它们统一上报至我们内部构建的数据库适配系统。该系统是基于 Inpara 和 Flink 构建的，数据最终会被存储到时序数据库中。随后，我们利用 Flink 对数据进行预处理，并结合训练好的模型以及特征库，对数据进行特征分析。基于这些分析，我们会进行基础的异常检测、关联分析以及趋势预测等工作，从而形成初步的告警摘要和预测摘要。 例如，我们可能会收到告警信息，提示 HDFS 存储空间即将用尽，或者 YARN 队列的等待时间过长，又或者 StarRocks 或 Trino 的 CPU 占用率过高，某个 SQL 查询扫描的数据量过大，超出了设定的阈值。基于这些信息，我们会生成整体的告警或预测摘要。如果预测显示 HDFS 的增长趋势过快，可能会在 5 分钟内被填满，我们就会对 IaaS、存储、引擎和调度等各个层面进行评估，计算它们的健康分数。如果健康分数低于某个阈值，或者即将达到该阈值，我们就会启动规则引擎进行处理。例如，我们可能会尝试简单的扩容操作来缓解问题，或者在业务允许的情况下，直接终止一些不关键的 SQL 查询或任务，以减少资源占用。 在执行这些操作后，我们会制定一个详细的执行计划。以扩容为例，在执行扩容操作之前，我们需要先检查 HDFS 的整体状态是否正常，数据是否均衡分布，以及 NameNode 和 DataNode 之间的流量是否稳定。因为如果流量过大，可能会导致 DataNode 负载过高，甚至引发更严重的问题。只有在确认一切正常后，我们才会通过 IaaS 层扩容机器，并在扩容完成后进行数据均衡操作，以确保系统恢复正常。 完成这些操作后，我们会记录整个过程的状态，并进行反馈。如果扩容后监控数据显示系统恢复正常，那么我们认为这次自治决策是成功的，并将结果记录下来作为后续处理的参考。然而，如果扩容后情况反而恶化，例如数据倾斜导致 SQL 查询速度变慢，引擎侧的健康分数急剧下降，那么我们会紧急通知专家介入，重新审查整个分析过程。 这种基于规则引擎的处理方式具有高效和准确的特点。目前，在我们系统中，基础指标的覆盖率达到 90%，存储场景的覆盖率为 50%，任务场景的覆盖率为 30%。在周期性任务的处理上，我们已经能够覆盖 90% 的场景。在异常诊断方面，我们能够处理 70% 的异常场景，整体数据表现良好。 这并不意味着我们的工作已经完成。实际上，大数据系统的复杂性远超我们的预期。例如，我们在两年前曾遇到一个问题：在对 HDFS 进行扩容后，发现数据分布不均衡，导致 Spark 任务的执行速度反而变慢。从常理来看，扩容后资源增加，任务执行速度应该加快，但实际上并非如此。原因在于扩容后数据的均衡性并没有达到预期，同时业务侧提交了大量任务，导致系统整体性能下降。这说明我们目前只能处理已知的情况，而对于一些未考虑到的复杂场景，我们还需要进一步优化和改进。 基于上述思考，我们提出了一个全新的全自治系统概念。与之前的方法不同，我们在决策过程中引入了大模型的相关分析。无论是当前备受关注的 DeepSeek，还是此前我们接触过的其他类似模型，其核心优势在于执行步骤和推理能力。因此，我们开始尝试将大模型的相关功能融入整个自治决策系统中。 在预测和分析阶段，系统仍然会进行数据预处理和特征分析，并开展异常检测、关联分析以及趋势预测等工作。这些信息汇总后，会生成初步的概述信息。然而，与以往不同的是，由于引入了大模型，我们需要构建一个“优先级与目标系统”（以下简称“目标系统”）。我们会在这个目标系统中预先定义优先级和目标。例如，对于存储系统，我们设定存储使用率不得超过 80%，并且数据不能快速转冷；对于引擎，我们希望优化其执行时间；对于上层应用，我们要求其不能出现错误。这些优先级和目标会被配置到目标系统中，生成诊断建议。 随后，我们会将这些数据输入到混元模型中，并结合我们之前的决策分析结果，生成具体的执行步骤。这些执行步骤融合了传统执行引擎、规则引擎以及传统深度学习算法或基础算法的执行计划。执行计划生成后，我们会重新预检测系统状态，重新评估预测分析结果以及执行计划可能带来的状态变化。 如果发现执行该计划后系统健康分数可能更低，即情况可能恶化，那么我们的专家团队会介入。我们会创建一个专家工单，让专家对执行计划进行评估，并决定是否停止执行。相反，如果预测和状态评估显示执行计划后系统健康分数将高于目标值，那么我们会执行该计划，并将执行计划标记后存入知识库。 执行完成后，我们会继续进行预测分析、异常检测以及整体状态评估。如果系统健康度如我们预测的那样有所提升，我们会重新进行标记和分析，以便系统能够继续执行后续操作。 在构建整个系统的过程中，我们花费了大量时间进行调试，尤其是在系统上线试运行阶段。现在，我想重点介绍一下我们在调试过程中采取的关键措施，这些措施让系统更加稳定，并显著提高了预测的准确率。 对于从事时序预测研究的人员来说，一个常见的问题是如何处理上报数据中的断点。这种情况可能由多种原因引起。例如，当系统发生故障时，机器的 CPU 或内存可能已经满负荷运行，导致在关键时刻数据丢失。在分布式系统中，这种数据丢失可能会引发上层系统的乱序操作。假设我们上报的时间是 12 点整，但由于长时间的内存不足（OOM）或 CPU 负载过高，数据可能直到 12 点零 5 秒甚至 12 点零 1 分才上报。然而，故障的实际发生时间并非 12 点零 1 分，但上报时间却显示为 12 点零 1 分，这就导致了数据的乱序问题。此外，还可能出现重复上报的情况，即同一条日志或指标连续上报多次，这使得我们难以确定真正的时间点或事件。 这些问题引发了几个关键的挑战。首先，当数据出现断点时，我们需要决定是否进行插值。目前业界常用的算法包括直接丢弃数据或采用简单的插值方法。对于故障场景来说，直接丢弃数据可能并不是一个好方法，因为这些数据代表了当时关键的监控指标。即使进行插值，如果处理不当，也可能导致数据不准确。此外，如果数据质量不佳，将严重影响我们的预测能力和关键异常处理能力。 我们重点对数据质量进行了优化，主要从三个方面入手。首先，我们对时序指标或日志的有效性进行评估。以往最简单的评估方式是检查数据是否超过完整性阈值。另一种常见的做法是检查数据是否满足差分阈值，或者在 IoT、时序场景中直接进行简单的拼凑。我们提出了一种基于完整性的实际评估方法。具体来说，我们将每个数据进行分段处理，然后基于自回归模型对每个分段进行评估检测。如果数据通过了自回归分析的评估，我们认为这些数据是可用的。 在确认数据可用之后，我们面临的另一个问题是数据的补齐和连接。目前常用的方法包括直接进行差分或简单的拼接。我们的思路是采用自回归预测和自回归拼接的方法。这种方法的优势在于处理速度快，能够快速对分段数据进行处理。此外，这种方法既能进行预测，又能完成数据合并操作。通过这种方法，我们显著提升了数据的有效性，整体提升了 10%。在周期性任务和异常诊断方面，准确性提高了 30% 以上。同时，时序预测的时间也缩短了 28%。 我们在构建大数据专家库智能体的过程中，尝试了一种与业界常见的做法略有不同的方案。我们不仅实现了向量检索，还引入了文本检索。这种设计的选择源于我们在构建知识库时对传统向量检索方法的深入思考。 传统向量检索在相关性分析方面表现出色，例如在使用 FastText 等工具时，能够快速识别出与查询相关的数据。然而，这种方法存在一个明显的局限性：它无法直接反映召回数据的质量，也就是说，在检索过程中，我们难以预估数据的相关性是否真正符合需求。为了解决这一问题，我们引入了文本检索机制。通过文本检索，我们能够更清晰地理解数据之间的关联性，尤其是在知识库的构建过程中。 当我们构建知识库时，一个常见的思路是将操作步骤进行分层。以扩容操作为例，它可能与存储层有很强的相关性，但这种相关性背后的原因并不明确。通过文本检索，我们可以补充这些缺失的上下文信息，从而更全面地理解数据之间的关系。 大数据系统通常分为多层，包括大数据存储层、调度、和引擎等等。这些层之间的相关性可能很强，但它们之间的索引空间检索范围并不像我们想象的那么大。基于这些考虑，我们采用了腾讯的 ES 的架构，结合文本分析和向量检索的优势。这种架构不仅支持大规模的读写操作，还具备高效的检索能力。 通过这种方式，我们能够更好地处理组件之间或分层之间的关联关系，使得各部分之间的距离更近，从而提高系统的整体效率。在故障恢复之后，除了通过冷启动将知识库连接起来，我们还利用工单系统、客户反馈和专家系统，结合混元大模型，实现自动化的分类和归纳，持续完善知识库的建设。 我们来看基于 HDFS 存储规则引擎的自治。这里的关键在于如何快速抽取和分析 HDFS 的 FSImage，以及如何准确把握特征点。我们知道，HDFS 的源数据是以树形结构存储的，而现有的工具无法对这种树形结构进行并行化处理。为了解决这个问题，我们将工作拆分为两部分：第一部分是直接分析源数据的表结构，这样就不需要处理整个树形结构；第二部分是将树形结构手动拆分为多个并行部分，从而实现并行化处理。 通过这种方式，我们能够对表分区和关联分区进行拆分，并进行关联分析。同时，我们还能观察到数据的整体冷热分布，以及后续一段时间内的增长趋势。基于这些信息，我们利用规则引擎做出决策，确定关键目标。例如，如果当前存储的健康状况良好，但成本健康分较低，我们可能会自动执行降冷操作。如果发现整个系统的扩容必要性较高，我们可能会进行柔性扩容或自动剔除操作。 接下来分享一个关于 Spark 自动调优的案例。这个想法最初是在项目立项时提出的，当时的想法非常直接：将 Spark 的所有相关信息，包括 SparkSQL、配置信息、上下文信息，以及存储和引擎等，全部整合到一个系统中。我们甚至将所有的 Executor、逻辑计划和物理计划等也纳入其中。初步测试结果显示，这种方法的准确率大约为 30%。然而，我们发现其中约 30% 的结果与实际需求并无相关性，还有 20% 到 40% 的结果存在明显问题。究其原因，通用的大模型缺乏专家级的领域知识，这导致了准确性的不足，同时还出现了幻觉问题。所以我们引入了贝叶斯和 RL 专家系统建议的优化提升 sparksql 的调优效果。在 POC 和线上，目前实现无人工值守自治调优性能效果比工作五年经验还好 10%。 在降本效果相当不错，之前主要关注的 SparkSQL 本身，没有考虑存储和 IaaS 层面的相关影响。在最近我们又升级了这个系统，会将 YARN 调度、HDFS 存储以及相关的管控日志等信息统一汇总，形成一个详细的概述。我们的目标是通过调优实现时间消耗的最优化。为此，我们将这些上下文信息输入模型，并进行在线分析。分析结果不仅包括计算相关的最优参数，还涵盖了调度配置、内核参数的配置下发等。然而，这些配置下发后并不能立即生效，可能需要执行 SQL 控制操作，或者在某些情况下，进行刷新操作。基于这些分析结果，我们会生成一个调参执行计划，然后重新提交任务，并对时间消耗的最优化和系统的整体健康度进行评估。 目前我们在自治虽然有些突破，但还远远不够。正如之前提到的，我们已经解决了关键的 10% 的知识问题，这确实帮助我们解决了许多难题。然而，我们还有许多需要思考和改进的地方。 首先，我们需要持续优化路径。以 SparkSQL 为例，虽然我们已经对 SQL 进行了优化，但关键信息之间的互联性仍然不足。例如，当我们直接将 HDFS 的最大存储容量纳入考量时，其时间和空间的关联性处理得并不理想。目前，我们主要依赖简单的专家系统来判断优化效果，而这种判断往往缺乏系统化的分析。因此，我们计划在未来持续加强这方面的建设。 其次，我们在决策时的目标相对单一。目前，我们的决策主要基于时间预测和健康分的调度，但对于复杂的大数据系统来说，多链路决策的完善性仍有待提高。例如，在关键决策时刻，我们会引入多智能体。目前，我们对决策准确性的把握还不够高，准确率可能只有 70% 到 80%。因此，我们需要持续优化决策过程，以提高准确率。 最后，关于专家系统，虽然我们在最后一步会强制让 SRE 专家介入，但在实际操作中，我们发现专家介入的时机和方式需要进一步优化。例如，在配置下发后，我们可能需要再次介入，因为有些系统配置是立即生效的，而有些则需要存储后才能生效。因此，我们需要在关键节点上进行更精准的知识干预。 除了上述问题，我个人以及我们团队还需要持续思考和探索后续的应用方向。首先是 agent-Drive 的根因定位（RCA）。我们在故障恢复和根因定位方面还有很大的提升空间。一方面，我们需要更快地响应问题，避免客户受到影响；另一方面，我们需要提高根因分析的效率。 其次，我们希望实现逐步缓解的操作。目前，我们的操作通常是直接针对目标进行的，但我们认为应该分阶段、分层次地观察和评估每个环节的动作是否对整体健康服务和知识系统有效。虽然我们已经有了一个反应式（Reactive）模型，但它主要集中在直接缓解问题上。我们希望通过逐步缓解的方式，更全面地评估和优化系统。 最后，安全性是我们需要持续关注的一个重要方向。在大模型 RL 或智能体的开发过程中，我们可能会面临各种安全风险。一方面，我们需要确保优化操作不会引入更大的问题；另一方面，由于多个团队之间可能共享知识库，我们需要防止信息泄露或因幻觉问题导致其他团队误读知识库信息。这将是我们在未来持续探索的方向。 嘉宾介绍 熊训德，腾讯专家工程师，腾讯云 EMR 技术负责人，有丰富的大数据领域系统架构、开发、专家系统调优经验。 会议推荐 复杂任务，不再主要依赖冗长提示词硬扛了。Agent Skills 将专家流程与工具能力封装为可复用数字技能，由大模型按需调用，推动 AI 从通用助手迈向稳定的专业执行体。围绕 Skills 平台化、模型推理增强与垂直场景落地，Agent 时代正在加速到来。 为了深入探讨 Agent Skills 在实际应用中的潜力与挑战，在 4 月 16 日 -18 日举办的 QCon 北京大会上，我们特别邀请了 Ubiquiti Quality Assurance 蔡明哲带来专题演讲《从单点辅助到 Agent 闭环：基于 Agent Skills、MCP 与 Playwright 的全链路智能化测试实践》。他将聚焦智能化测试在质量保证中的落地实践，详细拆解 Agent Skills、Playwright Agent 与 MCP 的职责分工与组合范式，并介绍如何从案例生成到自动修复实现全流程工程实践落地。大数据系统自治背景与挑战
大数据智能管家技术框架及关键实现路径
腾讯大数据智能管家 TCInsight 技术架构
分层的大数据运维框架 - 渐进式自治
多智能决策引擎思考和设计一问题域
Al 驱动的规则引擎自治系统
Al 驱动的全自治域系统
数据质量对预测影响 & 优化
实践效果与案例分享
AI 驱动的 HDFS 存储规则引擎自治
AI 驱动的 SparkSql 调优全自治域
后续发展和思考
如今，浏览器插件已经成为我们日常上网的好帮手，从广告拦截到密码管理，插件让我们的浏览体验更顺畅。但你有没有想过，这些小插件其实也可能带来安全风险？ 尤其是那些不明来源或者权限过大的插件，一旦被滥用，就可能泄露你的隐私信息。今天，就跟大家聊聊浏览器插件检测以及如何掌握自己的权限风险。 很多人只关注插件的功能，却忽略了安全问题。一个普通的插件可能请求访问你所有网站的数据，甚至获取浏览器指纹信息。通过浏览器指纹检测，黑客可以追踪你的上网行为，甚至进行精准广告投放或者身份攻击。 所以，了解插件权限，定期做安全检测，是保护隐私的第一步。 想要做到浏览器插件安全，首先要知道插件到底在干什么。这里给大家介绍几种常用的检测方法： 最简单的方法就是打开浏览器的插件管理界面，例如： Chrome：chrome://extensions/ Edge：edge://extensions/ 在这里，你可以看到插件的权限信息，包括访问网站数据、修改网页内容等。通过检查这些权限，你可以判断插件是否过于“贪心”。 市面上也有一些工具可以帮你更专业地检测插件权限。例如，ToDetect检测浏览器指纹收集情况，同时分析插件可能带来的隐私风险。它不仅能显示插件的权限，还能帮助你判断哪些插件可能影响你的安全。 如果你有一定技术基础，可以通过手动测试插件的网络请求来判断它是否收集过多信息。打开浏览器的开发者工具（F12），查看插件是否在后台发送不必要的数据。虽然这个方法有点费劲，但对于追求安全的用户来说非常有效。 很多人以为只要插件权限不大就安全，其实不然。即便一个插件权限有限，也可能通过浏览器指纹技术收集你的设备信息。浏览器指纹检测可以帮你发现哪些插件在悄悄收集这些信息。 比如：屏幕分辨率、字体、操作系统、浏览器版本等等，这些看似无害的信息加起来就能形成一个“唯一标识”，让你的上网行为被追踪。使用ToDetect指纹查询，可以清楚看到哪些插件在收集这些数据，从而及时调整或卸载不安全插件。 为了更直观地了解插件可能带来的风险，我给大家整理了几个常见类型： 数据访问类：允许插件访问你访问的所有网页数据，包括表单内容、账户信息。 浏览器行为监控类：追踪你打开的网页、点击行为，用于广告或者统计分析。 指纹收集类：通过浏览器指纹收集设备信息，甚至可能用于身份识别。 后台执行类：插件在后台偷偷运行脚本，可能发送数据到第三方服务器。 了解这些风险后，你就能更有针对性地选择和管理插件。 总结一下，想要轻松掌握浏览器插件权限风险，可以按照以下步骤操作： 定期检查插件权限：通过浏览器自带管理或者ToDetect指纹查询查看插件权限。 卸载不必要或权限过大的插件：功能重复或者来源不明的插件，直接卸载最安全。 关注浏览器指纹检测：即便插件权限不高，也可能通过指纹技术追踪你，ToDetect可以检测。 保持浏览器和插件更新：更新不仅带来新功能，更重要的是修复安全漏洞。 养成安全意识：安装插件前先看权限说明，避免盲目点击“添加到浏览器”。 总的来说，浏览器插件检测不仅能让你了解插件权限，还能让你更清楚哪些插件可能影响浏览器插件安全。 记住，安全意识比什么都重要，别等到数据被泄露才后悔。定期做插件检测，卸载不安全插件，让你的上网环境更安全、更安心。为什么浏览器插件安全这么重要
浏览器插件检测有哪些方式？
浏览器指纹检测的重要性
浏览器插件权限风险分类
如何轻松掌握插件权限风险？
总结
目前在 Windows 系统下，打开本地文件，可以通过 Proxifier 正常加载模型列表并提问。
但是用 SSH 连接远程服务器时，远程的文件夹能打开，"tab"和“Edit”功能也正常，但右侧 Agent panel 的模型列表加载不出来，导致"Chat"功能不能用。
尝试了给远程服务器设置 HTTP_PROXY 等一系列环境变量和 Antigravity 设置里 proxy ，都不行。有没有知道怎么办呀？
最近更新 windows 系统之后，鼠标在白色背景黑文字的场景下，鼠标指针 "工" 显示为白色的，跟本看不清楚鼠标在移动到哪里了，
目前发现是在 Chrome 浏览器或者使用 Chrome 内核的应用 vscode 以及各大 AI IDE 等出现的概率非常大，基本影响使用了，不知道大家有没有遇到这样的情况的……
在人工智能快速发展的今天，掌握Prompt工程已成为有效使用大语言模型的关键技能。本文将深入探讨两个最重要的Prompt技术：Few-shot Learning和Chain-of-Thought，帮助你从入门到精通。 Prompt工程是设计和优化输入指令的艺术，目的是引导AI模型产生更准确、更有用的输出。就像与人交流一样，提问的方式直接影响得到的答案质量。 Few-shot Learning是一种通过提供少量示例来指导模型行为的技术。相比直接下达指令，示例能让模型更好地理解你的期望。 Few-shot的核心思想是"示范胜于说教"。通过展示输入-输出对，模型能够识别模式并应用到新任务中。 Zero-shot（无示例）： Few-shot（有示例）： Few-shot版本会产生更符合预期的正式表达，因为模型已经从示例中学到了转换的具体风格。 Chain-of-Thought（CoT）是一种促使模型展示中间推理步骤的技术，特别适用于需要复杂推理的任务。 大语言模型在直接回答复杂问题时容易出错，但如果要求它们逐步推理，准确率会显著提升。这类似于人类解决问题时在纸上演算的过程。 不使用CoT： 使用CoT： 将Few-shot和CoT结合使用，效果更强大： 1. 自我一致性（Self-Consistency） 2. 零样本CoT（Zero-shot CoT） 3. 分解复杂任务 以下是一个综合应用Few-shot和CoT的高级示例： 选择合适的技术： 迭代改进： Prompt工程是一门平衡艺术与科学的技能。Few-shot Learning教会我们通过示例沟通意图，Chain-of-Thought则揭示了引导模型深度思考的力量。掌握这两项技术，你就拥有了驾驭大语言模型的核心能力。 记住，最好的prompt往往来自不断实验和迭代。开始尝试，记录你的发现，逐渐建立自己的prompt工程工具箱。在AI时代，善于提问的人将获得最大的优势。什么是Prompt工程？
Few-shot Learning：通过示例教会AI
基本原理
实践示例
将以下句子翻译成正式商务语气：
"嘿，会议推迟到明天了"将以下句子翻译成正式商务语气。
示例1：
输入："嘿，项目搞定了"
输出："尊敬的各位，项目已圆满完成。"
示例2：
输入："老板说行"
输出："管理层已批准该提案。"
现在请转换：
"嘿，会议推迟到明天了"Few-shot最佳实践
应用场景
Chain-of-Thought：让AI展示思考过程
为什么CoT有效？
基本形式
问题：一家商店打7折，再用20元优惠券，原价300元的商品最终多少钱？问题：一家商店打7折，再用20元优惠券，原价300元的商品最终多少钱？
请逐步思考并展示计算过程：Few-shot CoT：终极组合
请解决以下数学应用题，展示完整的推理过程。
示例：
问题：小明有15个苹果，给了小红1/3，小红又吃了2个，小红还剩几个？
思考过程：
1. 小明给小红的苹果数 = 15 × 1/3 = 5个
2. 小红吃了2个后剩余 = 5 - 2 = 3个
答案：3个
现在请解决：
一辆车以60公里/小时的速度行驶了2.5小时，然后以80公里/小时又行驶了1.5小时，总共行驶了多少公里？CoT的变体技巧
让模型生成多个推理路径，然后选择最常见的答案：请用3种不同的方法解决这个问题，然后比较答案是否一致。
仅需添加"让我们一步步思考"这样的提示：问题：[你的问题]
让我们一步步思考这个问题。请按以下步骤分析：
1. 识别问题中的关键信息
2. 确定需要使用的公式或原理
3. 逐步计算
4. 验证答案的合理性实战：结合两种技术
你是一个数据分析助手。请分析用户评论的情感，并解释判断理由。
示例1：
评论："虽然价格有点贵，但质量真的很好，很满意！"
分析过程：
- 负面因素：价格贵（权重：低）
- 正面因素：质量好、很满意（权重：高）
- 整体倾向：正面情感占主导
结论：正面（积极）
示例2：
评论："发货快，但产品完全不符合描述，非常失望。"
分析过程：
- 正面因素：发货快（权重：低）
- 负面因素：不符合描述、非常失望（权重：高）
- 整体倾向：负面情感占主导
结论：负面（消极）
现在请分析：
"客服态度不错，但等了两周才到货，包装也破损了。"常见错误与避免方法
性能优化建议
工具与资源
结语
苹果不允许主 App 自动把前台切回原宿主 App （没有公开 API 能做到这一跳），但是微信输入法或一些第三方输入法却可以精准做到这一点，他们是怎么实现跳转到主 app 然后又跳回键盘宿主 App 的？难道是通过私有 Api （例如 LSApplicationWorkspace 之类）按 bundle id 拉起的吗？
2025 年收益不好整天瞎忙，2026 可能没有开发项目
我开始感觉这是给部门施压，试图掉一部分人，工作强度上来了，不适应的自然会选择离开。
后来听说公司年后还要招两个实习生，低成本劳动力替代一部分正式员工？这点让我有点奇怪
全文链接：https://tecdat.cn/?p=44938 在人工智能技术飞速发展的今天，大语言模型（LLM）已成为各类智能应用的核心，但模型 hallucination（幻觉）和知识滞后问题始终制约着其在实际业务中的可靠性。检索增强生成（RAG）技术的出现，通过在生成响应前从外部知识库检索信息，有效缓解了这两大痛点，成为连接LLM与真实世界数据的关键桥梁。 <pre data-index="0" name="code" style="color: rgb(0, 0, 0); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><img alt="" height="1464" src="https://i-blog.csdnimg.cn/direct/7cd474de17b34ea8922ede13e3d82f0a.png" width="648" style="border: 0px;"> 传统RAG通过将文本转换为向量，利用余弦相似度等算法检索相关文档，但这种方式存在明显短板：面对“某企业的核心产品由哪位负责人主导研发”这类需要关联多个实体的查询时，由于无法识别“企业-产品-负责人”的关系链条，往往只能返回孤立的文档片段，导致LLM生成的答案缺乏连贯性和完整性。 无需提前耗费大量资源构建完整图谱，而是根据用户查询实时识别实体与关系，动态生成或扩展临时图谱。这种方式既避免了静态图谱的维护成本，又能确保图谱与查询场景高度相关，比如在处理新兴技术概念时，可快速将其与已有知识关联。 通过命名实体识别（NER）技术提取关键实体（如企业、人物、概念），并建立语义层面的关联。例如自动识别“谷歌”与“桑达尔·皮查伊”的“CEO所属”关系，而非单纯的关键词匹配，为后续推理奠定基础。 依托图谱中的明确关系，实现多步骤推理检索。面对“某行业龙头企业的核心技术来源于哪些科研机构”这类查询，可通过“企业-核心技术-科研机构”的路径遍历，精准聚合分散在不同文档中的关联信息。 为图谱中的实体关系分配置信度分数（基于信息来源可靠性、关系强度等因素），检索时优先选择高分路径，过滤低质量信息，避免无关数据干扰LLM决策。 相关文章 原文链接：https://tecdat.cn/?p=44707 本节将通过简化的实操案例，展示Graph RAG的核心实现步骤，涉及实体提取、文档检索、图谱构建、图遍历等关键环节。所用到的工具中，NetworkX、spaCy、scikit-learn均为国内可直接安装使用的Python库，无需特殊访问权限；若需替代Colab的在线运行环境，国内百度飞桨AI Studio、阿里云PAI-DSW均能提供同等功能。 通过NER技术从用户查询中提取核心实体，为后续检索和图谱构建提供基础。 运行结果： 通过TF-IDF向量检索，初步筛选与查询相关的文档集合，减少后续图谱构建的计算量。 运行结果： 基于提取的实体和候选文档，构建包含实体、关系的知识图谱，这是Graph RAG的核心环节。 运行结果： 通过图谱遍历，获取与查询实体相关的上下文信息，实现多跳推理。 运行结果： 将图谱上下文与候选文档整合为增强提示词，输入LLM生成最终响应。 运行结果： 通过可视化直观呈现实体间的关联关系，助力调试和结果验证。 运行结果： 大型企业的知识库往往分散在文档、邮件、工单等多种载体中，Graph RAG可动态构建跨载体的知识图谱，员工查询“某项目的合规要求及相关负责人”时，系统能快速关联项目文档、合规条款和员工信息，返回结构化答案，大幅提升信息获取效率。 在金融、法律领域，Graph RAG可从合同、法规文件中提取关键条款、责任主体等实体，构建“条款-责任-主体”的关系图谱。面对“某合同中的数据隐私条款是否符合最新法规要求”这类查询，系统能通过图谱遍历关联相关法规和条款，给出精准分析。 传统客服机器人难以处理复杂查询，Graph RAG可整合产品手册、历史工单、用户反馈等数据，构建产品-问题-解决方案的知识图谱。当用户咨询“某产品更新后无法连接网络的解决办法”时，系统能关联产品型号、更新版本、网络问题类型等信息，提供个性化 troubleshooting 步骤。 相比传统RAG，Graph RAG的核心优势在于具备关系推理能力。通过知识图谱明确实体间的关联，可处理多跳复杂查询，避免检索结果碎片化，让LLM生成的答案更全面、逻辑更连贯。 依托动态图谱构建机制，Graph RAG无需重新构建整个图谱，可根据新查询、新文档实时提取实体和关系，更新临时图谱。例如遇到新兴技术概念时，能快速将其与已有知识关联，确保信息时效性。 文中所用工具均支持国内直接使用：NetworkX可替换为Neo4j（国内有云服务版本），spaCy的实体识别功能可替换为百度飞桨的PaddleNLP；LLM可选用通义千问、文心一言等国内模型，无需依赖国外API。 关键在于实体关系提取的准确性和图谱的高效遍历。实际应用中需结合行业词典优化NER模型，针对大规模数据可采用图数据库分片技术提升遍历效率；同时要建立置信度评分体系，过滤低质量关系数据。 Graph RAG通过将知识图谱与检索增强生成技术结合，解决了传统RAG在复杂关系检索中的短板，为LLM提供了更结构化、更全面的上下文支撑。其动态图谱构建、多跳推理等核心特性，使其在企业知识管理、合规风控、智能客服等多个领域具备广泛的应用价值。 [1] Lewis P, et al. 检索增强生成技术在知识密集型自然语言处理任务中的应用[J]. 人工智能学报, 2021.
原文出处：拓端数据部落公众号
专题名称：GraphRAG技术进阶：动态知识图谱驱动的智能检索实践
引言
然而，传统RAG依赖的向量相似度检索，往往只能捕捉文本表面的语义关联，难以挖掘数据中隐藏的实体关系，导致检索结果碎片化，无法满足复杂场景下的深度信息需求。正是在这样的行业痛点驱动下，我们在为某大型企业提供知识管理系统咨询服务时，沉淀出Graph RAG（图检索增强生成）这一创新解决方案。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。
本文将从技术演进角度，先梳理RAG技术的发展脉络，再深入解析Graph RAG的核心创新点——动态知识图谱构建、智能实体链接、多跳图遍历推理与置信度评分机制，随后通过Python+NetworkX+spaCy的实操案例，展示Graph RAG的实现流程，最后介绍其在企业知识管理、合规风控等领域的实际应用，帮助读者快速掌握这一提升智能检索效果的关键技术。技术脉络流程图
</pre>一、Graph RAG的核心创新与技术原理
1. 技术背景：从传统RAG到Graph RAG的演进
Graph RAG的核心突破在于将知识图谱融入检索流程，不再将信息视为孤立的文本块，而是通过实体节点与关系边构建结构化的知识网络，让检索过程具备“推理能力”，从而精准捕捉复杂的语义关联。2. Graph RAG的四大核心创新点
（1）动态知识图谱构建
（2）智能实体链接
（3）多跳图遍历推理
（4）置信度评分优化
上图清晰展示了Graph RAG的架构逻辑：通过知识图谱将分散的文本信息结构化，实现从“文本检索”到“关系检索”的升级，让LLM获得更全面的上下文支撑。
Python可口可乐股票交易数据分析：KMeans-RF-LSTM多模型融合聚类、随机森林回归价格预测与交易模式识别
二、Graph RAG的实操实现（Python核心代码）
1. 环境准备与依赖安装
# 安装所需依赖库（国内镜像源加速）!pip install spacy networkx scikit-learn -i https://pypi.tuna.tsinghua.edu.cn/simple# 下载spaCy英文模型!python -m spacy download en_core_web_sm2. 关键步骤实现
（1）查询分析与实体提取
import spacyimport networkx as nxfrom sklearn.feature_extraction.text import TfidfVectorizerfrom sklearn.metrics.pairwise import cosine_similarity# 加载spaCy自然语言处理模型nlp = spacy.load("en_core_web_sm")# 定义实体提取函数：筛选人物、组织、地点类实体def extract_key_entities(user_query): doc = nlp(user_query) # 过滤关键实体类型，省略自定义实体类型扩展代码 target_ents = ["PERSON", "ORG", "GPE"] return [(ent.text.strip(), ent.label_) for ent in doc.ents if ent.label_ in target_ents]
从结果可见，系统成功识别出“谷歌”（组织实体），为后续关联“CEO”信息奠定基础。（2）候选文档检索
# 初始化TF-IDF向量器，省略停用词过滤、文本预处理等优化代码vectorizer = TfidfVectorizer()doc_embeddings = vectorizer.fit_transform(doc_collection)# 定义候选文档检索函数
（3）动态知识图谱构建
# 定义图谱构建函数：从文档中提取实体关系并添加到图谱def build_dynamic_graph(graph, entities, docs): # 添加查询中的实体到图谱 for ent_text, ent_type in entities: graph.add_node(ent_text, type=ent_type)# 从候选文档中提取实体关系，省略复杂关系抽取规则代码 for doc in docs: doc_nlp = nlp(doc) person_ent = None org_ent = None for ent in doc_nlp.ents: if ent.label_ == "PERSON": person_ent = ent.text.strip().strip(".") elif ent.label_ == "ORG": org_ent = ent.text.strip().strip(".") # 识别"CEO"关系并添加边 if person_ent and org_ent and "CEO" in doc: graph.add_node(person_ent, type="PERSON") graph.add_node(org_ent, type="ORG") graph.add_edge(person_ent, org_ent, relation="CEO所属") return graph# 初始化图谱并构建kgraph = nx.Graph()kgraph = build_dynamic_graph(kgraph, extracted_ents, candidate_docs)
（4）图遍历与上下文提取
# 定义图遍历函数：从起始实体出发，获取指定深度的关联信息def traverse_graph(graph, start_node, depth=2): context_info = set() visited_nodes = set() queue = [(start_node, 0)]
（5）提示词合成与LLM响应生成
（6）知识图谱可视化
import matplotlib.pyplot as plt# 设置中文字体（避免中文显示乱码）plt.rcParams['font.sans-serif'] = ['SimHei']
三、Graph RAG的实际应用场景
1. 企业知识管理系统
2. 合规风控与合同分析
3. 智能客户服务
四、常见技术疑问解答
核心优势是什么？
如何适配新的信息？
国内落地时工具如何选择？
实施过程中需注意哪些问题？
六、结论
本文通过简化的实操案例，展示了Graph RAG的核心实现流程，所涉及的代码和技术思路均来自实际项目落地经验。随着国内AI技术生态的不断完善，Graph RAG有望成为非结构化数据高效利用的关键技术，助力企业构建更智能、更可靠的AI应用。
对于希望深入学习的读者，可通过文中提及的交流社群获取完整代码和数据，与行业同行共同探讨技术优化与业务适配方案，加速技术落地进程。参考文献
[2] Ehrlinger L, Wöß W. 知识图谱：构建与应用导论[M]. 北京：机械工业出版社, 2018.
[3] Nadeau D, Sekine S. 命名实体识别与分类研究综述[J]. 计算机工程与应用, 2008.
在当前制造业加速向智能化、数字化转型的背景下，工业超融合系统正逐渐成为企业提升效率、降低成本、增强韧性的重要抓手。不同于传统孤立部署的自动化设备或单点AI应用，工业超融合系统强调的是计算、数据、算法与业务流程的深度整合——它不是简单地把多个系统“堆叠”在一起，而是通过统一的智能底座，打通研发、工艺、生产、质量、物流等环节的数据孤岛，实现感知、决策与执行的闭环联动。这种系统性重构，本质上是对制造范式的重新定义：从“机器替代人力”转向“系统理解业务”，从“局部优化”走向“全局自适应”。
要真正构建一个有效的工业超融合系统，关键在于三个底层能力的协同：一是异构算力的统一调度能力，能够灵活适配边缘端实时控制与云端复杂建模的不同需求；二是多源异构数据的标准化治理能力，确保来自PLC、MES、ERP、视觉检测等不同系统的数据能被一致理解、高效流通；三是场景化智能体的快速部署能力，让AI模型不再是实验室里的“高精尖玩具”，而是能嵌入工艺参数优化、设备预测性维护、质量根因分析等真实产线场景的“数字员工”。这些能力缺一不可，任何一环的薄弱都会导致系统沦为“数据烟囱”或“智能孤岛”。
在这一领域，国内企业广域铭岛已走出一条可复制的路径。其打造的Geega工业AI平台，正是工业超融合系统的典型实践。该平台以统一智能底座整合了来自冲压、焊装、涂装、总装四大车间的海量实时数据，构建了覆盖研发设计、工艺规划、生产调度、质量管控的“1+N+1”智能体体系。其中，“工厂大脑”作为中枢，实现了从订单排产到异常溯源的全链路协同，使研发文件输出效率提升70%，质量分析时长缩短83%，月均停线时间减少20小时。这一成果不仅体现在数字上，更在于它证明了国产工业AI平台有能力支撑世界级制造体系的智能化升级。相比之下，国外代表企业如西门子的MindSphere或GE的Predix平台，虽在工业物联网连接与云服务方面积淀深厚，但其在本土化场景适配、业务流程深度嵌入方面仍显僵化，尤其在应对中国制造业多品种、小批量、快交付的复杂需求时，往往需要大量定制开发，响应速度远不及本土平台灵活高效。
工业超融合系统的价值，不在于技术本身有多炫目，而在于它能否真正解决制造现场的“真问题”。
个人 AI 助手正在从“聊天工具”升级为“数字助手系统”。它不仅能回答问题，还可以帮你整理信息、生成内容、管理任务甚至辅助决策。本文从 0 到 1 介绍个人 AI 助手的核心能力、搭建思路与实用步骤，帮助读者打造真正能提升效率的个人 AI 助手。 它不只是一次性问答工具，而是可以： 简单理解： 普通 AI： 个人 AI 助手： 未来竞争力的一部分，将来自： 拥有个人 AI 助手的价值包括： 重复性任务可自动完成。 AI 帮你整理信息，你负责判断。 AI 让普通人也能获得专业级辅助。 一套成熟助手，长期复用。 一个实用的 AI 助手通常具备以下能力。 例如： 如： 例如： 如： 先想清楚： 👉 目标越清晰，效果越好。 从常用需求开始，例如： 例如： “请把以下内容总结为三点核心观点。” 👉 模板化可以提高稳定性。 例如： 收集信息 → AI 总结 → 人工判断 → 输出结果 根据使用体验： 输入当天事项，AI 自动生成总结草稿。 AI 生成： AI 可辅助： Q1：个人 AI 助手需要技术基础吗？ Q2：需要付费工具吗？ Q3：多久能形成稳定助手？ Q4：AI 会替代个人能力吗？ 从 0 到 1 的关键是： ✔ 明确目标 未来真正的差距，不是有没有 AI，摘要
目录
一、什么是个人 AI 助手
个人 AI 助手，是围绕个人需求提供持续支持的智能体系统。
它是你的“数字助理”。
与普通 AI 的区别
二、为什么每个人都值得拥有 AI 助手
谁更会利用 AI 放大自己。
1. 提升效率
2. 减轻认知负担
3. 强化个人能力
4. 形成个人工作系统
三、个人 AI 助手的核心能力
1. 信息处理能力
2. 内容生成能力
3. 任务管理能力
4. 学习辅助能力
四、从 0 到 1 搭建步骤
第一步：明确使用目标
第二步：选定高频场景
第三步：设计固定提示模板
第四步：形成个人流程
第五步：持续优化
五、实用应用场景示例
场景 1：每日工作总结
场景 2：学习新领域
场景 3：内容创作
六、QA 问答
A：不需要，大部分通过自然语言即可搭建。
A：基础使用很多工具已足够，进阶再考虑付费。
A：持续使用与优化，一般数周即可形成习惯。
A：不会，它更像能力放大器。七、总结
个人 AI 助手，本质是你的效率系统。
✔ 选好场景
✔ 固定流程
✔ 持续优化
而是：谁更会用 AI。
参考文献