包含关键字 typecho 的文章

点赞 + 关注 + 收藏 = 学会了

整理了一个NAS小专栏,有兴趣的工友可以关注一下 👉 《NAS邪修》

JSNES 是一款怀旧游戏模拟器,无需安装任何客户端,仅通过浏览器即可运行,支持超级马里奥、魂斗罗等海量经典游戏。可部署到 NAS、服务器等设备打造本地怀旧游戏中心,完全免费无广告,轻松重温童年游戏乐趣。

本次使用飞牛 NAS 部署 JSNES,其他品牌的 NAS 部署流程也是差不多的。

在“文件管理”找到“docker”文件夹,在里面创建一个“jsnes”文件夹。

打开“Docker”,切换到「Compose」面板,创建一个项目。

项目名称填 jsnes

路径选择刚刚在“文件管理”里创建的 /docker/jsnes,具体目录根据你的 NAS 情况来填。

来源选择“创建docker-compose.yml”。

输入以下代码:

services:
  jsnes:
    image: docker.1ms.run/wangz2019/jsnes:1.0.0
    container_name: jsnes
    ports:
      - 3456:80
    restart: always

我给它配置了 3456 端口,你可以自定义。

等 jsnes 下载并构建完成后,切换到「容器」面板,找到 jsnes 点击这个“链接”按钮就可以在浏览器打开 jsnes 了。

支持键盘按键操作。

在手机也可以玩的。

除了马里奥和魂斗罗之外,还有淘金者、功夫、坦克大战等众多经典游戏。


以上就是本文的全部内容啦,有疑问可以在评论区讨论~

想了解更多NAS玩法可以关注《NAS邪修》👏

点赞 + 关注 + 收藏 = 学会了


汉得鲲苍基础架构管理平台的核心目标是为企业的异构系统提供简单高效的一站式统一闭环管理能力,包括统一资源(集群、主机、存储等)管理、统一应用及部署管理、统一监控管理、统一服务治理,帮助企业实现更快、更好、更全面的异构系统管理。

接下来我们将会提供一系列推文,介绍鲲苍平台的使用,帮助您快速了解本平台,给您更好的使用体验。

本文为系列推文的第三十一讲,将介绍如何通过鲲苍监控应用性能,在分布式系统中快速定位性能问题,大大缩短故障排查时间,高效解决性能问题!

本篇概述

在分布式架构时代,一次用户请求的背后,可能历经数十个服务的流转,如何快速洞察系统性能、精准定位性能瓶颈?鲲苍平台「应用性能监控(APM)」能力,为您提供从全局拓扑到代码堆栈的全链路可观测方案,让应用性能问题无处遁形。

功能亮点:应用性能监控接入

1. 新建数据源

服务可观测性/监控数据源配置:新增Skywalking类型数据源。

2. 新建应用性能监控集群

应用性能监控/应用性能监控集群配置:关联数据源。

3. 应用性能监控接入

查看 接入指南 ,按步骤操作:
部署前端应用时,开启 isTrace ,例如:

`ClientMonitor.register({
  accessTokenUrl: http://1.2.3.4:8080/oauth/oauth/token,
  collector:${HOPS_CLUSTER_URL}/v3/segments,
  isAjax: true,
  isTrace: true,
  namespace: '',
  clientId: '';
  clientSecret: '';
})`

部署后端应用时,通过 javaagent 接入应用性能监控,例如:

## 应用启动需要添加以下启动参数
-Xms1024m -Xmx1536m -javaagent:agent_path/skywalking-agent.jar -Dskywalking.agent.namespace=hops-dev -Dskywalking.agent.service_name=hops-dev:hzero-product -Dskywalking.collector.backend_service=127.0.0.1:11800

应用性能监控分析

1. 全景拓扑,一眼看懂服务关系

基于真实的调用链路数据,自动绘制实时服务依赖关系图。节点颜色动态反映服务健康状态,直观呈现系统架构全貌,依赖关系一目了然。

  • 边上可查看服务间平均响应延迟,点击可查看详细的平均响应时间、平均吞吐量、平均SLA、响应时间分布等指标
  • 服务实例上点击可查看服务应用性能指数(APDEX)、响应时间、吞吐量、SLA、响应时间分布等指标

    2. 链路追踪,穿透每一个调用环节

    从入口到数据库,完整记录请求在分布式系统中的流转路径。支持查看每个环节的耗时、状态、异常详情、SQL语句,支持多种视图灵活切换,轻松定位慢调用与异常节点。

    3. 多维监控,关键指标实时掌控

    全局概览:掌握集群整体响应延迟分布、吞吐量排行、慢服务/慢端点排行等。

服务维度:深入查看单服务响应时间、吞吐量、SLA、Apdex满意度指数等。

服务端点及数据库分析:分析接口性能与数据库慢查询,全面覆盖应用层到数据层。

4. 深度剖析,直击性能根源

JVM&实例级深度分析

针对 Java 服务,鲲苍提供实例级 JVM 健康洞察,从“现象”到“根因”,不再依赖经验猜测:

  • CPU 使用率、GC 耗时与次数、线程状态、线程堆栈
  • 堆内存使用情况与对象分布
  • MBean 详情、系统属性与运行环境信息等

服务链路性能剖析
通过采样跟踪与性能剖析任务,鲲苍可对指定 API 在一段时间内进行方法级堆栈分析,并以火焰图形式呈现调用链。宽而平的“平顶”函数,往往就是性能瓶颈所在,问题定位更直接、更高效。

5. 应用性能告警,防患于未然

基于响应时间、成功率、吞吐量等核心指标,灵活配置告警规则与生效范围,实现应用性能的主动感知与提前预警,助您提前发现风险,保障系统持续稳定运行。

联系我们:

  • 如果您想了解鲲苍更详细的功能介绍和产品信息,请登录开放平台查阅我们的产品文档
  • 如果您有疑问,可以通过开放平台进行工单反馈,问题分类请选择【产品/汉得基础架构管理平台】
  • 相关产品咨询或更多信息了解,欢迎联系我们。
    邮箱:openhand@vip.hand-china.com

随着生成式人工智能(AIGC)等技术不断演进,海量镜像与大模型的分发成为 AI 领域的一项关键挑战。这些挑战包括:海量分片(数百万个)、高并发拉取需求、严格的延迟要求,以及动态的网络环境等。如何在兼容 OCI 等主流格式,并且无需侵入性的实现动态、高效、可扩展的大规模镜像与模型文件分发系统,已是云原生应用与 AI 服务的迫切需求。

为了解决这些问题,蚂蚁集团与大连理工大学合作设计了一套动态、高效、可扩展的大规模镜像与模型文件分发系统。近日,由蚂蚁集团与大连理工大学共同撰写关于该系统的论文被 IEEE Transactions on Networking (TON) 期刊录用。TON 是由 IEEE 认可的高影响力学术期刊,在网络与系统领域具有重要影响力。本论文的录用标志着研究成果对行业发展具有前瞻性和创新性。 

论文简介

论文设计构建了一个高效、可扩展的 P2P 模型分发系统,该系统是对 CNCF 孵化项目 Dragonfly 的增强,通过多层次设计实现了资源优化与数据同步的有机结合,旨在解决传统 P2P 文件分发系统在面对 AI 大模型(如千亿参数模型)分发的特定挑战时表现不佳的问题。
图片
论文链接:https://ieeexplore.ieee.org/document/11152005
项目官网:https://d7y.io

技术方案与创新方法

传统的集中式镜像/模型中心(Container/Model Registry)在并发下载高峰期常遭遇单点带宽瓶颈,导致拉取速度下降、任务延迟增加。另一方面,单纯依赖内容分发网络(CDN)或私有链路虽能缓解部分热点问题,却无法充分利用集群内部节点的空闲带宽资源,同时引入额外的成本开销。
图片
 图 1: 文件分发系统架构图

应对这些问题,本方案引入了该方案引入了三个关键设计:首先,引入轻量级的网络测量机制,通过主动探测网络延迟和推断带宽,实时预测网络信息。其次,设计了可扩展的调度框架,通过将推理与调度解耦,提升了调度系统的资源利用率和响应速度。最后,Trainer 模块采用异步模型训练与推理方法,结合图学习算法,实现了基于突发性任务的增量学习。
图片
图 2: 三个关键设计的调度算法

如图 2 所示,轻量级的网络测量机制确保在有限的可用网络资源下对集群中的每个节点进行高效探测。可扩展的调度框架确保足够的可用资源执行调度任务。异步模型训练和推理方法让算法结合节点特性参数进行聚合,以捕捉集群内的相似性,从而提升带宽预测效果。

性能成果

性能评估表明,相较于主流系统和算法,本系统在总加载完成时间上实现了至少 10% 的缩减,同时将节点平均带宽利用率提升约 20%。此外,所提出的轻量级探测机制通过减少探测频率和计算复杂度,相比现有网络探测方法有效降低了资源开销。该系统不仅能满足 AI 对大规模模型分发的高并发、低延迟需求,还能更高效地利用集群资源,希望可以为行业提供参考。

关于我们

蚂蚁集团容器镜像与存储团队,主要参与
Dragonfly(https://github.com/dragonflyoss/dragonfly)、
Nydus(https://github.com/dragonflyoss/nydus)、
Harbor(https://github.com/goharbor/harbor)和
ModelPack(https://github.com/modelpack/model-spec) 等开源项目在内部的开发落地和上游项目的维护。我们致力于打造业内顶尖的容器镜像服务,并推动云原生场景下 AI 模型和镜像分发的社区标准化。

点赞 + 关注 + 收藏 = 学会了

整理了一个NAS小专栏,有兴趣的工友可以关注一下 👉 《NAS邪修》

tldraw 是一款开源免费的轻量级协作白板工具,NAS 可以通过 Docker 就能一键部署,群晖、绿联、极空间等主流 NAS 全适配,无需复杂配置。它拥有无限手绘画布,支持画笔、形状、连线、文本便签等实用功能。

这次我用绿联 NAS 部署,其他品牌的 NAS 操作步骤也是差不多的。

打开“Docker”应用,在“镜像”页面搜索“tldraw”,下载红框选中的那个 ratneo/tldraw

下载完成后,切换到“本地镜像”页面,点击 ratneo/tldraw 旁边的加号,创建容器。

在创建容器这页,容器名称可以自定义,我就不改了。

自动重启可以勾选上。

往下滑,”NAS端口“这项可以自定义,我这里选的是 39445 这个端口。

部署完成后,浏览器输入 NAS的IP:39445 就能使用 tldraw 了。

它支持将画布内容导出为 SVGPNGJSON 这几种格式。


以上就是本文的全部内容啦,有疑问可以在评论区讨论~

想了解更多NAS玩法可以关注《NAS邪修》👏

点赞 + 关注 + 收藏 = 学会了

在大语言模型的技术版图中,自回归(AR)架构长期占据主导地位,而扩散模型则被视作一条充满挑战的“非共识”路线。LLaDA2.0 已经成功证明了扩散语言模型(dLLM)规模化至 100B 参数的可行性,但生成速度与生成质量的平衡始终是横亘在扩散模型面前的核心难题。

2月11日,我们正式发布 LLaDA2.1,通过可纠错编辑机制,首次让扩散语言模型在保持高质量的同时,将推理速度推至 892 TPS的新高度,让扩散语言模型从“研究探索”向“真正可用”迈进了一大步。

创新“可纠错编辑”机制 Error-Correcting Editable, ECE

作为实现飞跃的最核心创新,它赋予了扩散模型一种前所未有的“智慧”——像人类专家一样“起草-编辑”。

传统自回归模型像是一个不允许带草稿纸、不允许带提纲的考生,它下笔无悔,不允许修改自己写好的答案。LLaDA2.1 从根本上重构了这一范式。我们提出了 Token-to-Token(T2T)编辑机制,让模型具备「起草-编辑」的双重能力,在毫秒级的闪电采样中完成“草稿”到“正卷”的转身:

  • 起草阶段:模型以较低的置信度阈值快速并行生成初始草稿;
  • 编辑阶段:模型启动自我纠错,对已生成的 Token 进行回溯检查和迭代修正。
    图片
    图 1:传统吸收态范式 vs LLaDA2.1 可纠错编辑机制

这种设计让扩散模型首次拥有了类似人类的「修改草稿」能力,解决了并行生成的误差累积问题,为高速解码奠定了理论基础。

灵活“双模式”设计 Speedy Mode vs Quality Mode

基于可纠错编辑机制,LLaDA2.1 提供了两种截然不同的运行模式,将速度与生成的选择权交还给用户:
| Speedy Mode(极速模式)
采用激进的低阈值策略进行 M2T 解码,以最大化并行度生成初始草稿,随后依赖 T2T 编辑机制进行精炼修正。这一模式实现了快速的推理速度,在代码生成等结构化任务中,仅带来可接受的性能折损。

| Quality Mode(质量模式)
采用保守的高阈值策略,优先保证解码的精确性。在这一模式下,LLaDA2.1 在 33 项基准测试上全面超越 LLaDA2.0,并超越同类型扩散语言模型:
代码能力:HumanEval+ 89.63%,CRUXEval-O 87.50%
数学推理:AIME 2025 63.33%,GSM-Plus 89.69%
智能体任务:BFCL v3 75.61%,IFEval 83.55%

双模式设计让用户真正成为速度与质量的决策者 —— 需要实时响应时选择 Speedy Mode,需要精确输出时则可以切换 Quality Mode,满足不同场景下的真实需求。

业界首个 dLLM 大规模 RL 框架

如果说“可纠错编辑”让模型变得“可用”,那么强化学习则让模型变得更“聪明”、更“可靠”,体感更强。LLaDA2.1 实现了首个专为 dLLM 设计的大规模强化学习框架。
图片
图 2:LLaDA2.1 训练与推理框架概览

扩散模型的策略优化面临一个根本性障碍:序列级对数似然无法直接计算。在 100B 规模的扩散模型上跑通 RL 绝非易事。它不仅需要极强的工程底层支撑,要求我们从块状扩散(Block-diffusion)的条件概率转移视角,提出稳定的梯度估计算法,即 EBPO(ELBO-based Block-level Policy Optimization):

  • 使用 Evidence Lower Bound (ELBO) 作为似然的合理代理;
  • 结合 Vectorized Likelihood Estimation,实现边界估计的并行计算;

EBPO 不仅提升了训练效率,更为 dLLM 的后训练优化提供了稳定、可扩展的解决方案。这一突破让强化学习首次能够稳定地扩展到扩散语言模型的后训练阶段,显著提升了模型的指令遵循能力和人类意图对齐度。

性能表现
LLaDA2.1 开源两个版本:
图片

LLaDA2.1 在保持高质量生成的同时,实现了突破性的推理速度 —— 892 TPS,是传统自回归模型的数倍。在多个生成场景中,它都能以闪电般的速度完成;尤其是在代码领域,平均达到了 600-700 的 TPS,让用户体验如丝般流畅。

图片
图 3:LLaDA2.1 在 Mini 和 Flash 系列上的吞吐量对比

图片
表 1:在不同场景上,LLaDA2.1 在 Mini 和 Flash 系列上的吞吐量

892 TPS 意味着什么?相当于每秒生成近 900 个 token,足以支撑实时交互、大规模部署等工业级应用场景。
这一速度飞跃的背后,正是可纠错编辑机制的支撑 —— 正因为模型具备自我修正的能力,才敢在初始阶段采用激进的低阈值策略快速生成,而不必担心错误累积导致质量崩塌。

结语

LLaDA2.1 的意义不仅在于 892 TPS 的速度数字,更在于它证明了:通过技术创新,扩散语言模型完全可以在保持并行生成优势的同时,克服质量与速度的传统权衡。

可纠错编辑机制的引入,让 dLLM 第一次拥有了“自我修正”的智慧;双模式设计让用户真正成为速度与质量的决策者;强化学习框架则为扩散模型的后训练开辟了新的可能性。

我们诚挚邀请社区开发者体验 LLaDA2.1,也欢迎有志于探索 LLaDA 模型的同学加入我们,共同探索扩散语言模型的边界。蚂蚁技术研究院招聘火热进行中!多个研究课题,等你挑战!

项目介绍

最近做了个练手项目,用来实践 GitHub Actions 的自动化能力。核心功能是让 CI/CD 流程完全无人值守地完成:数据爬取 → AI 预测生成 → 自动提交 → 部署上线。

GitHub 仓库https://github.com/sinyu1012/Double-Color-Ball-AI 在线演示https://double-color-ball-ai.vercel.app

效果展示

项目截图

AI 预测策略

每个 AI 模型会生成 5 组预测,分别采用不同策略:

策略 说明
热号追随者 选择最近 30 期高频号码,追踪热门趋势
冷号逆向者 选择最近 30 期低频号码,期待均值回归
平衡策略师 综合奇偶比、大小比、和值、连号等多维度平衡
周期理论家 选择短期频率上穿长期频率的号码
综合决策者 融合以上所有策略的综合方案

技术实现

自动化流程

通过 2 个 GitHub Actions 工作流 实现全自动运行:

  1. 数据爬取:每天 22:00 自动爬取最新开奖数据,有更新则提交到仓库
  2. AI 预测:每周一/三/五调用 4 个 AI 模型生成预测,自动部署到 Vercel

整个过程零人工干预,从数据获取到网站更新全部由 CI/CD 完成。

技术栈

  • Python 爬虫 + OpenAI SDK + 纯 JS 前端
  • GitHub Actions 定时任务 + Vercel 自动部署

开源亮点

  • 完整的自动化实践:从定时任务、数据处理到自动部署的完整流程
  • 多 AI 模型对接:统一接口同时调用 GPT/Claude/Gemini/DeepSeek
  • 开箱即用:提供了环境变量模板、启动脚本、详细文档

适合学习

如果你想了解:

  • GitHub Actions 的定时任务和自动提交
  • Python 爬虫 + AI API 集成
  • 纯前端数据可视化(无框架)
  • Vercel 部署 + CI/CD 实践

可以参考这个项目的实现。


免责声明:AI 预测仅供娱乐和技术学习,不构成任何购彩建议。彩票具有随机性,请理性对待。

欢迎 Star / Fork / PR

GitHub 仓库https://github.com/sinyu1012/Double-Color-Ball-AI 在线演示https://double-color-ball-ai.vercel.app

场景:

  • 浏览帖子或者回复之后要滑到顶部切换或者回首页
  • 鼠标可以回退返回首页,但是又不会自动刷

建议:

  • 是否可以固定,或者设置里添加一个开关,可以单独设置
  • 右下方添加一个回到顶部的功能

一点小建议smirk

要成为鸿蒙开发团队的架构师,需要从知识储备、技能提升、经验积累、职业素养培养等多个方面进行努力,以下是具体的建议。

扎实的知识储备

鸿蒙开发团队的架构师需要具备扎实的知识储备。

  • 操作系统知识:深入掌握操作系统的基本原理,包括进程管理、内存管理、文件系统、网络协议栈等。了解Linux内核的相关知识也很有帮助,因为鸿蒙系统与Linux有一定的渊源。
  • 鸿蒙系统知识:全面学习鸿蒙系统的架构、特性、开发框架和工具。熟悉鸿蒙的分布式技术、HarmonyOS应用开发语言(如ArkTS、仓颉编程语言等)、应用开发框架以及系统服务等内容。
  • 编程语言:熟练掌握至少一种鸿蒙应用开发语言,如ArkTS、C++、仓颉等,同时要对JavaScript、TypeScript等前端语言有一定的了解,以便进行跨平台开发和与Web技术的交互。
  • 硬件知识:了解硬件体系结构、芯片原理、传感器原理等硬件基础知识,有助于更好地理解鸿蒙系统与硬件的交互,以及在不同硬件平台上进行系统优化。

丰富的提升技能

鸿蒙开发团队的架构师需要具备丰富的提升技能。

  • 架构设计能力:通过学习架构设计模式和原则,如微服务架构、分层架构等,提升系统架构设计能力。能够根据业务需求,设计出合理、高效、可扩展的鸿蒙系统架构方案。
  • 开发与调试能力:具备熟练的鸿蒙应用开发能力,能够独立完成应用的编码、调试和测试工作。掌握调试工具和技巧,能够快速定位和解决开发过程中出现的问题。
  • 性能优化能力:学习性能优化的方法和技术,如代码优化、算法优化、资源管理优化等。能够对鸿蒙系统和应用进行性能分析和调优,提高系统的运行效率和响应速度。
  • 安全与隐私保护能力:了解安全与隐私保护的相关知识和技术,如数据加密、身份认证、访问控制等。能够在鸿蒙系统和应用的设计和开发中,充分考虑安全与隐私问题,确保用户数据的安全。

经验的积累

鸿蒙开发团队的架构师需要具备丰富的项目经验。

  • 项目实践:积极参与鸿蒙相关的项目开发,从简单的应用项目开始,逐步积累经验。在项目中,承担不同的角色和任务,如模块开发、架构设计、项目管理等,全面提升自己的能力。
  • 社区贡献:参与开源鸿蒙社区的开发和维护工作,贡献自己的代码和技术方案。通过与社区中的其他开发者交流和合作,学习先进的技术和经验,提高自己的知名度和影响力。
  • 技术分享与交流:积极参加鸿蒙技术相关的研讨会、讲座、线上论坛等活动,与同行进行技术分享和交流。了解行业的最新动态和技术趋势,拓宽自己的技术视野。

职业素养的培养

鸿蒙开发团队的架构师需要注重职业素养的培养。

  • 学习能力:鸿蒙技术在不断发展和更新,需要具备良好的学习能力,能够快速掌握新的技术和知识。保持学习的热情和好奇心,不断提升自己的技术水平。
  • 沟通能力:作为架构师,需要与团队成员、产品经理、其他部门等进行频繁的沟通和协作。具备良好的沟通能力,能够清晰地表达自己的想法和观点,倾听他人的意见和建议,推动项目的顺利进行。
  • 团队合作精神:在团队中,要能够与不同背景和专业的人员合作,发挥自己的技术优势,共同完成项目目标。具备团队合作精神,能够关心和帮助团队成员,营造良好的团队氛围。
  • 问题解决能力:在项目开发过程中,会遇到各种各样的问题和挑战。具备较强的问题解决能力,能够迅速分析问题的本质,提出有效的解决方案,确保项目的顺利进行。

综上,要成为团队的架构师,“打铁还需自身硬”,除了下苦功夫,还需要针对性的对自身能力进行不断打磨。

这里推荐 《鸿蒙架构师修炼之道》(北京大学出版社)这本书。本书不但通过真实案例讲解架构设计流程和经验,还总结了丰富的鸿蒙架构师工作原则和技巧,读者可以对照本书内容进行查漏补缺,提升自身能力,早日踏上鸿蒙架构师修炼之道。

年关将至,此时此刻,不同部门的战壕里,大家都在为了“圆满收尾”而全力冲刺:

财务部需要严谨核算:查凭证、平账目、出年报,容不得半点差错;

市场部正在灵活复盘:看转化、析渠道、定策略,急需洞察明年的先机。

如何让一个智能体,既能满足财务的严谨,又能适应市场的灵活?白泽SmartBI近期上线的“智能体快捷方式”功能,为您提供了一种极简解法。快来“马”住这份攻略,让您新的一年“马”力全开!

01 业务痛点:不同部门个性化需求如何满足?

在实际业务中,不同角色的关注点截然不同,通用配置的智能体往往难以解决个性化的提效需求:

财务部门:

日常聚焦于查凭证、看余额、审报表,高频使用“财务会计模型”和“资金管理模型”,需要一个专注财务领域的纯净入口,告别手动切换的繁琐。

市场部门:

核心关注客户价值与渠道转化,依赖“客户生命周期价值模型”和“渠道引流模型”来支撑决策,渴望一个能够直达业务核心、快速获得答案的智能体。

业务人员都希望能对智能体做轻量化调整,以满足自己个性化需求(如预设常用模型、简化交互流程),又需要一直保持智能体最新版本,享受升级带来的新功能。

如何能够同时满足统一维护与个性体验?白泽SmartBI给出了解决方案。

02 解决方案:快捷方式 + 参数配置

现在,通过“快捷方式 + 参数配置”的组合,您可以将一个核心智能体,快速为不同部门“分发”专属入口。它既保留了“开箱即用”的便捷,又能实时同步底层的每一次能力升级。真正实现了 “千人千面,常用常新”。

快捷方式

低成本实现一个智能体、N个“分身”

  • 它是指向原智能体的链接,不是复制粘贴,低成本实现千人千面;
  • 原智能体有任何升级优化,所有快捷方式自动同步,功能永远保持最新;
  • 支持基于同一智能体创建多个不同快捷方式,实现“一对多”个性化配置。

参数配置

给每个“分身”设定专属性格

  • 每个快捷方式都可以独立配置运行参数(如限定数据模型范围、调整反问规则、联网等设置)。
  • 通过提前预设,就能让同一个智能体在不同部门面前,展现出完全不同的“专属性格”,同时满足企业权限管控的需求。

接下来我们从实际业务场景出发,三步带您解锁智能体专属用法。

03 实操流程:3步打造专属智能体入口

Step1:创建快捷方式

在“智能助理”下,创建两个快捷方式,命名为:智能助理_财务、智能助理_市场。

图片

Step2:配置专属参数

智能助理_财务:数据模型列表设为财务常用的【财务会计模型】和【资金管理模型】,并开启自动选择数据模型。

智能助理_市场:数据模型列表设为市场常用的【客户生命周期价值模型】和【渠道引流模型】,并开启自动选择数据模型。

图片

同时还可以对联网、文件上传、反问等多项参数进行自定义设置。

Step3:设置权限

完成配置后即刻启用,将“智能助理_财务”权限开放给财务部,“智能助理_市场”权限开放给市场部。

效果:开箱即用,马上见效!

财务小王和市场小林登录后,只需选择自己的专属入口,直接输入问题即可。所有模型切换自动完成,他们得到的是最精准、最直接的答案。

图片

图片

04 体验升维:提效立竿见影

通过“快捷方式+参数配置”,我们解决的不仅是模型切换的操作痛点,更构建了一种可持续的个性化能力:各业务部门能获得量身定制的智能体验,而所有定制入口都能随原智能体同步进化,保障了企业整体迭代的效率与一致性,效果立竿见影。

SmartBI在不断拓展智能体能力边界的同时,也从未停止对“交互体验”的微调与打磨。这不仅是产品从可用迈向易用的关键,更是SmartBI能够承载大型企业复杂需求、交付可靠服务的最佳证明。

欢迎免费试用白泽SmartBI!开启您的专属智能之旅!

在开发实践中,经常会遇到一个问题:如何在不修改 PostgreSQL 内核代码的前提下,为数据库对象附加自定义元数据。本文展示了一种基于 PostgreSQL SECURITY LABELS 机制的可行方案,用于实现自定义属性。这种方式具备事务性、与数据库对象强关联,并且能够与标准 PostgreSQL 操作良好协同。

问题背景:复制冲突的管理

在一个典型的两主节点向第三节点复制数据的架构中,UPDATE/UPDATE 冲突较为常见。复制冲突的处理本身较为复杂,且在多数场景下并无通用解法,但某些列类型可以采用更简单的处理思路。

例如,在银行业务场景中,账户余额字段通常只允许增减操作。此时可以采用基于增量(delta)的方式:不在冲突时选择某个绝对值,而是分别计算两次更新的变化量并进行叠加。该方法仅需进行基础校验(如溢出检查、余额不小于 0),即可确保所有更新均被正确计入。

难点在于:如果 PostgreSQL 本身不支持此类机制,如何标记特定列以启用基于 delta 的冲突解决策略?理想状态下,可以直接通过类似以下语法完成:

ALTER TABLE accounts ALTER COLUMN balance SET delta_apply = 'true';

但这种深度集成 SQL 语法的方式实现难度较高,且对可移植性意义有限。更现实的需求是通过扩展接口完成设置,例如:

SELECT my_extension.set_delta_apply('accounts', 'balance', true);

社区中曾多次讨论为数据库对象引入自定义属性的提案,也曾提交过内核补丁,但实现代码规模较大,而应用场景相对有限,合入内核的可行性存疑。此外,有时需要为索引、大对象或数据类型等非表对象附加属性,这进一步增加了复杂度。更重要的是,即便补丁被接受,也只能影响未来版本,而现实需求往往是“当下可用”。

功能需求

实现该功能前需明确相关需求:

  • 对象生命周期绑定:属性必须与数据库对象建立内部依赖关系。例如,在执行 DROP … CASCADE 删除父对象时,属性也应随之自动删除。
  • 扩展关联性:属性需要与扩展建立明确关联,以便在扩展被卸载时由数据库系统正确处理。
  • 事务性行为:对象属性需满足事务规则与可见性约束,并行事务修改时,新属性值仅在当前事务内可见,提交前回滚则恢复原值。
  • 升级与迁移支持:在 pg_upgrade 以及 dump/restore 过程中,属性应随数据库对象一并正确迁移。

理想情况下可实现类似 PostgreSQL GUC 的会话级特性,但实现难度显著提升。

方案评析

以对象 OID 为键的简易全局哈希表无法满足需求,属性值可为变长类型(如字符串),对象与属性的关联实现复杂,且无法保障事务特性与 MVCC 机制。

另一种思路是在扩展中创建一张 <key, value> 表存储属性,由扩展在运行时查询该表。这在理论上可行,但实践中问题较多:涉及升级、dump/restore、复制一致性等一系列复杂问题,同时还需持续校验对象是否存在,并引入额外的查询开销,整体可靠性较差。

实现思路

具体目标是为任意表的列定义一个 delta_apply 属性,用于逻辑复制场景下的 UPDATE/UPDATE 冲突处理。当该属性启用时,订阅端不采用传统冲突解决策略,而是计算新旧值之间的差量,并将其累加到订阅端当前值中。

在 PostgreSQL 中,唯一同时满足上述全部需求的机制是 SECURITY LABELS。尽管该机制最初用于安全模块,但并未限制其仅用于安全相关元数据。需要注意以下事项:

  • 面向安全的工具可能会检查或校验标签内容。
  • 需要使用独立且唯一的 provider 名称,以避免冲突。

它是如何工作的?让我们看看这张图:

extension_side.jpg

实现的核心依赖于系统表 pg_seclabel。该表中的记录与数据库对象天然绑定,对其的增删改通过 SECURITY LABEL … 工具命令完成。扩展可以通过 utility hook 监听这一过程。

SECURITY LABEL 支持多种对象类型,包括视图、函数等,基本覆盖常见需求。每条标签记录包含对象的 OID 及对象类型(表、列、函数等),并通过文本字段存储任意自定义数据,同时通过 provider 字段区分不同模块生成的标签。

由于每次访问都直接查询 pg_seclabel 成本较高,且目前尚无系统级缓存,引入本地哈希缓存以降低开销:

typedef struct PropertyCacheEntry {
    Oid classId;
    Oid objectId;
    char *propertyValue;
    bool valid;
} PropertyCacheEntry;
static HTAB *property_cache = NULL;

通过注册 RelcacheCallback 实现缓存失效管理,对象执行 ALTER TABLE 操作时标记对应缓存条目无效。缓存填充策略可根据使用场景调整。例如,在核心 hook 中访问对象时加载,或在扩展提供的用户接口函数中主动加载。

属性增删的实现细节

为了保持各后端缓存一致性,每次属性变更都需要向其他进程发送失效通知。对象本身发生变化时,可通过 RelcacheCallback 处理;但属性变更本质上只是对 pg_seclabel 的 DML 操作,如何通知其他后端成为问题。

PostgreSQL 提供了 CacheInvalidateRelcacheByRelid,但仅适用于 pg_class 中的对象,对于数据类型等对象无效。因此,在实际实现中,属性变更时会触发一次对象自身的“无实质变更更新”,以借此触发相应的失效回调,从而刷新扩展内部缓存。

扩展通过 set_property() 接口向用户暴露能力,用于为指定对象设置 SECURITY LABEL。标签文本中描述属性值,例如 delta_apply: true。在扩展中实现的 seclabel_provider 回调负责校验对象类型及属性合法性。

标签文本字段具备高度灵活性,允许存储复杂结构,例如以 JSON 形式描述属性逻辑。

通过该机制,客户端与扩展之间建立了一种相对原生的通信方式。扩展可在运行时判断属性是否存在,并据此调整行为。

delta_apply 的具体实现中,逻辑复制订阅端在处理 UPDATE 记录时,会同时查询对应表的属性缓存。若存在标记为增量属性的列,则计算新旧值差量并累加到订阅端当前值。即便在冲突解决策略(如 last-update-wins)下决定拒绝整条更新,增量列的变更仍会被应用,从而降低冲突概率并确保增量更新不丢失。

外部干扰处理

pg_seclabel 仍然是系统目录表,具备足够权限的用户(如 DBA)可以直接修改其内容。为降低风险,可在扩展中引入内部 GUC,例如 myextension.call_guard。在扩展 UI 函数执行前将其置为 true,结束后重置为 false,并在关键路径中校验其状态是否符合预期。

理论上,超级用户仍可能通过手段绕过该限制。虽然可以进一步为该 GUC 设置 hook 进行防护,但实现复杂度显著提高,容易演变为过度设计。

总结

PostgreSQL SECURITY LABELS 机制提供了一种可靠、事务安全的方式,用于在不修改内核的情况下为数据库对象添加自定义属性。尽管该机制最初面向安全模块,但同样适用于扩展级元数据管理,且具备良好的生命周期管理与 MVCC 支持。

该方案支持多种对象类型,具备事务一致性,并可正确参与 dump/restore 与升级流程。

原文链接:

https://www.pgedge.com/blog/custom-properties-for-postgresql-...

作者:Andrei Lepikhov


HOW 2026 议题招募中

2026 年 4 月 27-28 日,由 IvorySQL 社区联合 PGEU(欧洲 PG 社区)、PGAsia(亚洲 PG 社区)共同打造的 HOW 2026(IvorySQL & PostgreSQL 技术峰会) 将再度落地济南。届时,PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。

自开启征集以来,HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度,我们诚邀您在 2026 年 2 月 27 日截止日期前,提交您的技术见解。

投递链接:https://jsj.top/f/uebqBc

在 HarmonyOS 生态蓬勃发展的今天,应用上架是开发者面临的关键一环。不少作品因触碰 3.5 条款(应用价值与独特性) 被拒,常见的困惑包括:为何被判“功能单一”或“缺乏实质服务”?
本专题复盘近期审核数据,深度解析 3.5 条款 Top 10 驳回问题,为您提供:

  • 问题预警: 详解高频被拒问题,提前预警
  • 调优路径: 给出应用从纯展示向强交互的实操路径
  • 通关范本: 参考标杆案例,让优化有据可依
    读懂 3.5,上架更有数。优化应用实用性,助您的作品顺利开启鸿蒙之旅。

问题1:不收录应用功能与手机系统自带的功能重复,缺乏独特价值。如简易计算器、桌面时钟、加密备忘录、天气、手电筒、指南针、镜子、日历、计时类等。

【改进建议】
明确应用的独特价值,确保其核心功能与系统功能非完全重叠,强化在垂直领域的专业能力;交互设计与用户体验优化,通过清晰的界面布局与突出的重点功能,降低用户认知与操作成本,确保其价值能被用户快速感知和顺畅使用。

【驳回示例】
image.png

【优化后成功上架案例】
优化前:与系统备忘录功能相似,只能简单记录。
image.png
优化后:丰富应用核心功能,优化首页打卡统计展示,及新增“膳食食材、养生知识”等养生内容及“组队打卡、隔空传送”等趣味内容。
image.png

问题2:应用为有限的信息内容罗列不收录,如信息介绍,生活指南、法律案例展示、书籍推荐、诗词罗列等。
【改进建议】
聚焦应用核心功能,避免信息的简单堆砌与罗列,需打造差异化内容,增强交互设计与闭环体验,提升用户使用体验。
【驳回示例】
image.png

【优化后成功上架案例】
优化前:仅少量菜谱信息罗列,UX设计略显欠缺。
image.png

优化后:丰富应用核心功能,新增“做饭计划、上传菜谱、菜篮子”等模块,满足多种用户使用场景,优化整体界面设计展示,凸显菜品,使应用具有实用性的同时更加美观。
image.png

问题3:单一界面的恶作剧恶搞类应用不收录,如屏幕破裂、屏幕鬼魂、模拟打嗝等。
【改进建议】
通过整合多种恶作剧类型,增强应用场景适配性与趣味性。结合创意互动与交互创新,在丰富功能的同时保持界面简洁,提升娱乐性。
【驳回示例】
image.png

问题4:单一H5/Web页面应用不收录,如一张图片,一首音乐、一本书、一个主题、单一影视剧集类、单一非官方游戏攻略类等。
【改进建议】
聚焦应用核心功能,构建复合型功能体系,避免功能单一化;深化内容价值,丰富交互场景与功能闭环,持续提升用户体验。
【驳回示例】
image.png

问题5:不收录企业黄页类应用,仅展示文字信息、图片介绍,不提供用户服务。
【改进建议】
强化功能深度,增加功能实用性,提供实际可使用有价值的功能,不能仅企业文字信息、图片介绍,未提供实际的用户服务。
【驳回示例】
image.png

问题6:不收录应用内容均为各种广告推广。
【改进建议】
删除广告推广内容
【驳回示例】
image.png

问题7:不收录应用页面仅提供简单的预约功能,但未对预约内容进行详细说明,未体现功能的实质价值,未给到用户清晰、准确的服务预期。
【改进建议】
优化功能设计,确保功能闭环完整,消除使用断点,提供清晰明确的功能内容。
【驳回示例】
image.png

问题8:不收录应用无实质功能,仅记录想对自己说的话。
【改进建议】
围绕核心功能深化与拓展实用场景,突出差异化设计理念,强化技术业务协同能力,优化数据存储机制,提升操作便捷性与界面友好度,打造流畅舒适的用户体验。
【驳回示例】
image.png

问题9:不收录应用无实质功能和真实用户使用场景,如纯虚构内容。
【改进建议】
围绕真实用户的实际使用场景进行功能规划与设计,提供满足实际使用需求的可用功能;深度优化应用的核心使用场景体验,打磨并升级用户界面的设计质感与交互流畅度。
【驳回示例】
image.png

问题10:不收录资讯类应用内容老旧、过时,最新资讯模块展示过时的新闻报道。
【改进建议】
建立资讯内容定期更新机制,定期对资讯内容进行动态更新与优化,确保信息时效性,保持内容新鲜度与吸引力,避免陈旧内容影响用户体验。
【驳回示例】
image.png

➡️ 原贴指路

本地大模型神器来了!Ollama 一键部署 30B 模型实战指南


一、认识这只"羊驼"

如果你最近在研究本地大模型,那你一定绕不开它。

它叫 Ollama

官网地址:\
https://ollama.com

一句话总结:

Ollama = 本地大模型运行与管理工具

它的核心目标非常简单:

让你在自己的电脑上,像用 Docker 一样管理和运行大语言模型。


二、为什么 Ollama 这么受欢迎?

以前部署大模型通常有三种方式:

  • 调用 API(长期成本高)
  • 自己编译部署(流程复杂)
  • 各种依赖冲突(容易踩坑)

Ollama 做了一件非常关键的事情:

把复杂的模型部署,变成一行命令。

例如:

ollama run qwen3:8b

自动下载\
自动加载\
直接进入对话

对开发者来说,体验非常流畅。


三、安装与使用

1. 下载安装

访问官网下载安装即可。

支持系统:

  • Windows
  • macOS
  • Linux

安装完成后即可开始运行模型。


2. 第一次下载模型的注意事项

首次运行模型时会自动下载。

强烈建议:

在设置中将模型下载目录改到 D 盘或其他大容量磁盘。

原因:

  • qwen3:30b 等模型体积较大
  • 下载后可能占用十几 G 甚至几十 G 空间
  • 默认路径在 C 盘容易导致磁盘爆满

提前规划好存储路径非常重要。


四、模型区别与推荐

1. GPT-OSS 系列

包含:

  • gpt-oss:120b
  • gpt-oss:20b

特点:

  • 通用对话模型
  • 适合写作、问答、知识整理

推荐建议:

  • 16GB 内存以下建议选择 20b
  • 高性能设备可以尝试 120b

2. DeepSeek 系列

包含:

  • deepseek-v3.1:671b-cloud
  • deepseek-r1:8b

特点:

  • 推理能力较强
  • 数学与逻辑能力表现不错

说明:

  • 671b 为云端模型
  • 本地可选择 r1:8b 体验推理能力

适合对逻辑思考要求较高的场景。


3. Qwen3 系列(当前主流推荐)

包含:

  • qwen3:4b / 8b / 30b
  • qwen3-coder:30b / 480b-cloud
  • qwen3-vl:4b / 8b / 30b / 235b-cloud
(1)qwen3 ------ 通用模型

适合:

  • 日常聊天
  • 写文章
  • 知识问答
  • 代码辅助

推荐配置参考:

  • 8GB 内存 → 4b
  • 16GB 内存 → 8b
  • 32GB 内存以上 → 30b

(2)qwen3-coder ------ 专业代码模型

专为程序员优化:

  • 代码生成
  • 代码补全
  • Bug 修复
  • 项目结构生成

推荐:

  • 本地优先选择 30b
  • 480b 为云端版本

如果你是开发者,这个系列非常值得长期使用。


(3)qwen3-vl ------ 视觉语言模型

VL = Vision + Language

可以实现:

  • 图片识别
  • 图文问答
  • 图片分析

推荐:

  • 8b 起步
  • 追求更好效果可选择 30b

4. Gemma3 系列(Google 系)

包含:

  • gemma3:1b / 4b / 12b / 27b

特点:

  • 体积小
  • 运行速度快
  • 资源占用较低

适合:

  • 轻量电脑
  • 老设备
  • 快速测试

推荐:

  • 4b 或 12b 更均衡

五、如果只推荐三个模型

综合考虑性能与实用性,建议优先尝试:

  • 日常聊天:qwen3:8b
  • 写代码:qwen3-coder:30b
  • 轻量体验:gemma3:4b

如果你的机器配置较高:

可以直接尝试 qwen3:30b。

六、一个必须说明的事实

蒸馏模型并不是满血模型。

参数规模不等于能力等同于顶级闭源模型。

实际表现取决于:

  • CPU / GPU 性能
  • 显存大小
  • 内存容量
  • 是否开启量化

同一个模型,在不同设备上的表现差距可能非常明显。

因此建议多尝试不同模型,找到最适合自己机器的版本。


七、本地部署真正的意义

本地运行大模型,并不是为了与顶级闭源模型直接竞争。

它的真正价值在于:

  • 数据隐私
  • 零 API 成本
  • 企业内网部署
  • 本地知识库整合
  • 可深度定制

对于开发者而言,这是可控、可扩展的能力。


结语

当你第一次在本地成功运行一个 30B 模型时,那种掌控感非常真实。

Ollama 的出现,让本地大模型真正进入"普通开发者可用"阶段。

如果你正在探索 AI 工具链,本地部署值得认真体验一次。


作者:程序员小崔日记

本文由mdnice多平台发布

Andrej Karpathy刚发布了一个仅用约 250 行纯 Python 代码就实现了 GPT 训练和推理全过程的演示,非常适合用来理解大型语言模型底层的数学原理。
image.png
源文件在这里:https://gist.github.com/karpathy/8627fe009c40f57531cb18360106ce95
我用AI添加了注释并手动整理了一下:

# 导入所需依赖库
import torch # PyTorch核心库,用于张量计算和神经网络构建
import torch.nn as nn # PyTorch的神经网络模块,包含层、损失函数等
from torch.nn import functional as F # PyTorch的优化器模块,用于模型参数更新
import torch.optim as optim # GPT2的分词器,用于文本的编码和解码
from transformers import GPT2Tokenizer # 从huggingface/transformers导入GPT2分词器,适配英文文本

# 定义全局超参数,控制模型训练和结构
batch_size = 16 # 每次训练的样本数,小批量梯度下降用
block_size = 32 # 上下文窗口大小,模型能看到的最大文本长度
max_iters = 5000 # 训练的最大迭代次数
eval_interval = 100 # 每多少轮迭代评估一次模型性能
learning_rate = 1e-3 # 优化器的学习率,控制参数更新步长
device = 'cuda' if torch.cuda.is_available() else 'cpu' # 模型运行的设备,优先使用GPU(cuda),无则用CPU
eval_iters = 200 # 每次评估时的迭代次数,取平均减少波动
n_embd = 64 # 嵌入层的维度,模型中隐藏层的特征维度
n_head = 4 # 注意力头的数量,实现多头自注意力
n_layer = 4 # Transformer解码器的层数

# 固定随机种子,保证实验结果可复现
torch.manual_seed(1337)

# 加载GPT2分词器,设置为不使用填充(padding)和未知词(unk)的特殊处理
# GPT2分词器基于BPE(字节对编码),适配英文自然语言,词表大小约50k
tokenizer = GPT2Tokenizer.from_pretrained('gpt2')
# 禁用填充token,因为本微型GPT不做批量填充对齐
tokenizer.pad_token = None
# 禁用未知token,遇到未登录词时直接拆分为子词
tokenizer.unk_token = None

# 加载训练数据:这里使用经典的莎士比亚文本作为训练语料
# 从github拉取原始文本文件,读取为字符串格式
with open('https://raw.githubusercontent.com/karpathy/char-rnn/master/data/tinyshakespeare/input.txt', 'r', encoding='utf-8') as f:
    text = f.read()

# 对原始文本进行分词编码,将字符串转换为模型可处理的整数张量
# return_tensors='pt':返回PyTorch张量;truncation=True:超长文本截断
# max_length=None:不限制单条文本长度,后续按block_size切分
encoded_text = tokenizer(text, return_tensors='pt', truncation=True, max_length=None)
# 提取编码后的输入id,展平为一维张量(shape: [总词数])
data = encoded_text.input_ids.flatten()

# 划分训练集和验证集:90%数据用于训练,10%用于验证
n = int(0.9 * len(data))
train_data = data[:n]
val_data = data[n:]

# 数据加载函数:随机生成一批训练/验证样本
# split:指定数据集('train'/'val'),控制加载训练集还是验证集
def get_batch(split):
    # 根据split选择对应的数据集
    data = train_data if split == 'train' else val_data
    # 随机生成batch_size个起始索引,范围:[0, 数据长度-block_size),保证能取到连续的block_size个词
    ix = torch.randint(len(data) - block_size, (batch_size,))
    # 构造输入张量x:取每个起始索引后连续的block_size个词,shape: [batch_size, block_size]
    x = torch.stack([data[i:i+block_size] for i in ix])
    # 构造目标张量y:取每个起始索引后偏移1的block_size个词(语言模型的预测目标是下一个词),shape: [batch_size, block_size]
    y = torch.stack([data[i+1:i+block_size+1] for i in ix])
    # 将张量移到指定设备(GPU/CPU)
    x, y = x.to(device), y.to(device)
    return x, y

# 定义评估函数:计算模型在训练/验证集上的平均损失(无梯度计算,提升效率)
# model:待评估的模型实例
@torch.no_grad()  # 装饰器,禁用梯度计算,减少内存占用
def estimate_loss(model):
    # 初始化损失字典,存储训练集和验证集的损失
    out = {}
    # 将模型设为评估模式,关闭Dropout等训练特有的层
    model.eval()
    # 遍历训练集和验证集
    for split in ['train', 'val']:
        # 初始化损失数组,存储每次迭代的损失
        losses = torch.zeros(eval_iters)
        # 循环eval_iters次,计算平均损失
        for k in range(eval_iters):
            # 获取一批样本
            X, Y = get_batch(split)
            # 前向传播,得到模型输出和损失
            logits, loss = model(X, Y)
            # 记录当前迭代的损失
            losses[k] = loss.item()
        # 计算该数据集的平均损失,存入字典
        out[split] = losses.mean()
    # 将模型恢复为训练模式,开启Dropout等层
    model.train()
    return out

# 定义单头自注意力层:实现自注意力的核心逻辑(缩放点积注意力)
class Head(nn.Module):
    def __init__(self, head_size):
        super().__init__()
        # 定义查询(q)、键(k)、值(v)的线性投影层,将n_embd维映射到head_size维
        self.key = nn.Linear(n_embd, head_size, bias=False)
        self.query = nn.Linear(n_embd, head_size, bias=False)
        self.value = nn.Linear(n_embd, head_size, bias=False)
        # 注册三角掩码张量,用于遮蔽未来的词(自回归语言模型,不能看到未来信息)
        # tril:下三角矩阵,upper三角部分填充为-∞,后续softmax后为0
        self.register_buffer('tril', torch.tril(torch.ones(block_size, block_size)))
        # 定义Dropout层,防止过拟合,随机失活20%的神经元
        self.dropout = nn.Dropout(0.2)

    def forward(self, x):
        # x:输入张量,shape: [batch_size, block_size, n_embd]
        B, T, C = x.shape
        # 线性投影得到q、k、v,shape均为[batch_size, block_size, head_size]
        k = self.key(x)
        q = self.query(x)
        v = self.value(x)

        # 计算注意力权重:q @ k.T / sqrt(head_size)(缩放点积)
        # wei shape: [batch_size, block_size, block_size]
        wei = q @ k.transpose(-2, -1) * C**-0.5
        # 应用掩码:将上三角部分设为-∞,遮蔽未来的词
        wei = wei.masked_fill(self.tril[:T, :T] == 0, float('-inf'))
        # softmax归一化,得到注意力权重(每行和为1)
        wei = F.softmax(wei, dim=-1)
        # 应用Dropout,随机失活部分注意力权重
        wei = self.dropout(wei)
        # 注意力加权求和:权重 @ v,得到输出,shape: [batch_size, block_size, head_size]
        out = wei @ v
        return out

# 定义多头自注意力层:将多个单头注意力的输出拼接,实现多维度的特征提取
class MultiHeadAttention(nn.Module):
    def __init__(self, num_heads, head_size):
        super().__init__()
        # 创建num_heads个单头注意力层,存入nn.ModuleList(可被PyTorch识别的层列表)
        self.heads = nn.ModuleList([Head(head_size) for _ in range(num_heads)])
        # 线性投影层,将拼接后的特征映射回n_embd维
        self.proj = nn.Linear(head_size * num_heads, n_embd)
        # Dropout层,防止过拟合
        self.dropout = nn.Dropout(0.2)

    def forward(self, x):
        # 拼接所有单头注意力的输出,dim=-1表示在最后一维拼接
        # 输出shape: [batch_size, block_size, head_size*num_heads]
        out = torch.cat([h(x) for h in self.heads], dim=-1)
        # 线性投影+Dropout,完成多头注意力的输出变换
        out = self.dropout(self.proj(out))
        return out

# 定义前馈网络层:Transformer解码器中的全连接层,实现特征的非线性变换
class FeedFoward(nn.Module):
    def __init__(self, n_embd):
        super().__init__()
        # 两层线性层+ReLU激活+Dropout,隐藏层维度设为n_embd*4(Transformer原论文设定)
        self.net = nn.Sequential(
            nn.Linear(n_embd, 4 * n_embd),  # 升维
            nn.ReLU(),  # 非线性激活
            nn.Linear(4 * n_embd, n_embd),  # 降维回原维度
            nn.Dropout(0.2),  # 随机失活,防止过拟合
        )

    def forward(self, x):
        # 前向传播,输入输出shape均为[batch_size, block_size, n_embd]
        return self.net(x)

# 定义Transformer解码器块:由「多头自注意力 + 前馈网络」组成,带残差连接和层归一化
class Block(nn.Module):
    def __init__(self, n_embd, n_head):
        super().__init__()
        # 计算每个注意力头的维度:总嵌入维 / 头数
        head_size = n_embd // n_head
        # 多头自注意力层
        self.sa = MultiHeadAttention(n_head, head_size)
        # 前馈网络层
        self.ffwd = FeedFoward(n_embd)
        # 层归一化层(Pre-LN架构,Transformer原论文是Post-LN,Pre-LN更易训练)
        self.ln1 = nn.LayerNorm(n_embd)
        self.ln2 = nn.LayerNorm(n_embd)

    def forward(self, x):
        # 残差连接 + 层归一化 + 多头自注意力:x = x + sa(ln1(x))
        # 残差连接缓解深度网络的梯度消失问题
        x = x + self.sa(self.ln1(x))
        # 残差连接 + 层归一化 + 前馈网络:x = x + ffwd(ln2(x))
        x = x + self.ffwd(self.ln2(x))
        return x

# 定义微型GPT模型核心类,继承自nn.Module(PyTorch所有网络的基类)
class GPTLanguageModel(nn.Module):
    def __init__(self, vocab_size):
        super().__init__()
        # 词嵌入层:将词的整数ID映射为n_embd维的向量,vocab_size为词表大小
        self.token_embedding_table = nn.Embedding(vocab_size, n_embd)
        # 位置嵌入层:将位置索引映射为n_embd维的向量,捕捉文本的位置信息
        # 因为Transformer是并行计算,无内置位置信息,需手动加入
        self.position_embedding_table = nn.Embedding(block_size, n_embd)
        # Transformer解码器块序列:n_layer个Block堆叠
        self.blocks = nn.Sequential(*[Block(n_embd, n_head=n_head) for _ in range(n_layer)])
        # 最后的层归一化层
        self.ln_f = nn.LayerNorm(n_embd)
        # 输出线性层:将n_embd维的特征映射回词表大小,用于预测下一个词的概率
        self.lm_head = nn.Linear(n_embd, vocab_size)

        # 初始化模型参数:使用自定义的初始化方式,提升训练稳定性
        self.apply(self._init_weights)

    # 模型参数初始化函数
    def _init_weights(self, module):
        # 如果是线性层,初始化权重为正态分布(均值0,标准差0.02),偏置为0
        if isinstance(module, nn.Linear):
            torch.nn.init.normal_(module.weight, mean=0.0, std=0.02)
            if module.bias is not None:
                torch.nn.init.zeros_(module.bias)
        # 如果是嵌入层,初始化权重为正态分布(均值0,标准差0.02)
        elif isinstance(module, nn.Embedding):
            torch.nn.init.normal_(module.weight, mean=0.0, std=0.02)

    # 模型前向传播函数:输入x(词ID),y(目标词ID,可选),返回预测logits和损失
    def forward(self, idx, targets=None):
        # idx shape: [batch_size, block_size]
        # targets shape: [batch_size, block_size]
        B, T = idx.shape

        # 词嵌入 + 位置嵌入,shape均为[batch_size, block_size, n_embd]
        tok_emb = self.token_embedding_table(idx)
        pos_emb = self.position_embedding_table(torch.arange(T, device=device))
        # 嵌入层输出:词嵌入+位置嵌入,捕捉词的语义和位置信息
        x = tok_emb + pos_emb

        # 经过Transformer解码器块序列,输出shape不变:[batch_size, block_size, n_embd]
        x = self.blocks(x)
        # 最后的层归一化
        x = self.ln_f(x)
        # 输出线性层,得到logits(未归一化的概率),shape: [batch_size, block_size, vocab_size]
        logits = self.lm_head(x)

        # 如果没有目标值,仅返回logits(用于生成文本)
        if targets is None:
            loss = None
        else:
            # 重塑logits和targets,适配交叉熵损失的输入格式
            # cross_entropy要求输入为[B*T, vocab_size],目标为[B*T]
            B, T, C = logits.shape
            logits = logits.view(B*T, C)
            targets = targets.view(B*T)
            # 计算交叉熵损失(语言模型的核心损失,预测下一个词的概率)
            loss = F.cross_entropy(logits, targets)

        return logits, loss

    # 文本生成函数:基于当前输入idx,生成后续max_new_tokens个词
    # 自回归生成:每次预测一个词,拼接到输入后,继续预测下一个
    def generate(self, idx, max_new_tokens):
        # idx: 初始输入张量,shape: [batch_size, block_size]
        for _ in range(max_new_tokens):
            # 截取最后block_size个词,保证输入长度不超过模型的上下文窗口
            idx_cond = idx[:, -block_size:]
            # 前向传播,得到logits(无目标值,loss=None)
            logits, loss = self(idx_cond)
            # 取最后一个时间步的logits(预测下一个词的logits),shape: [batch_size, vocab_size]
            logits = logits[:, -1, :]
            # softmax归一化,得到下一个词的概率分布
            probs = F.softmax(logits, dim=-1)
            # 根据概率分布随机采样一个词ID(也可以用argmax取最可能的词,即贪心生成)
            idx_next = torch.multinomial(probs, num_samples=1)
            # 将采样的词ID拼接到输入后,更新输入张量
            idx = torch.cat((idx, idx_next), dim=1)
        # 返回生成后的完整词ID张量
        return idx

# 主程序入口:实例化模型、优化器,开始训练和生成
if __name__ == "__main__":
    # 获取GPT2分词器的词表大小,作为模型的vocab_size
    vocab_size = tokenizer.vocab_size
    # 实例化微型GPT模型,移到指定设备
    model = GPTLanguageModel(vocab_size).to(device)
    # 打印模型参数量,查看模型规模
    print(f"Model parameters: {sum(p.numel() for p in model.parameters())/1e6:.2f}M")

    # 定义优化器:使用AdamW(Adam的改进版,带权重衰减,防止过拟合)
    optimizer = optim.AdamW(model.parameters(), lr=learning_rate)

    # 训练循环:迭代max_iters次
    for iter in range(max_iters):
        # 每隔eval_interval次迭代,评估模型损失并打印
        if iter % eval_interval == 0:
            losses = estimate_loss(model)
            print(f"step {iter}: train loss {losses['train']:.4f}, val loss {losses['val']:.4f}")

        # 获取一批训练样本
        xb, yb = get_batch('train')
        # 前向传播,得到logits和损失
        logits, loss = model(xb, yb)
        # 梯度清零:PyTorch梯度会累加,每次迭代前需清零
        optimizer.zero_grad(set_to_none=True)
        # 反向传播:计算损失对模型参数的梯度
        loss.backward()
        # 优化器步骤:更新模型参数
        optimizer.step()

    # 训练完成后,进行文本生成
    # 初始化输入:<|endoftext|>是GPT2的特殊起始token,编码为张量并移到设备
    # shape: [1, 1](batch_size=1, block_size=1)
    start_idx = tokenizer.encode("<|endoftext|>", return_tensors='pt').to(device)
    # 生成max_new_tokens=500个词
    generated_ids = model.generate(start_idx, max_new_tokens=500)
    # 将生成的词ID解码为字符串,跳过特殊token
    generated_text = tokenizer.decode(generated_ids[0], skip_special_tokens=True)
    # 打印生成的文本
    print("\nGenerated text:\n")
    print(generated_text)

专题介绍

当我们对 AI4SQL/AI4DB/DB4AI 类产品进行研究时,我们发现 SQL 领域应用能力的提升很大程度上依赖于高质量的数据集。

还需要在此基础上进行数据合成,生成针对特定问题的训练集和评估集。为了帮助更多开发者快速获取资源,我们将近年来公开的 Text2SQL/NL2SQL 数据集进行了整理清单,持续分享给大家!

本期为系列文章的第六期,将介绍 大模型在地理空间查询 SQL 生成提高 NL2SQL 精准度 方面的两款数据集:GeoSQL-EvalDeKeyNLU

GeoSQL-Eval / GeoSQL-Bench

GeoSQL-Eval 是首个面向 PostGIS 环境的端到端自动化评估框架,旨在衡量大型语言模型在 地理空间 数据库查询生成(GeoSQL)方面的性能。

该研究还包括发布 GeoSQL-Bench 基准测试数据集,其中包含 14,178 个实例、340 个 PostGIS 函数和 82 个专题数据库。

image2026-2-2 10_41_56.png

论文意图

本文主要针对现有大型语言模型在生成 PostGIS 空间查询(GeoSQL)方面的性能评估难题,探讨如何系统地衡量这些模型的性能,因为目前 缺乏专门的评估基准和框架。传统的 NL2SQL 基准测试无法涵盖空间数据类型、函数和坐标系等复杂元素,导致在实际应用场景中出现函数错觉和参数误用等错误。

为了解决这一问题,论文提出了:

  • GeoSQL-Bench 基准测试
  • GeoSQL-Eval 评估框架

这些框架旨在为 NL2GeoSQL 任务建立一个标准化、多层次且可执行的评估系统,支持模型能力诊断和优化,并降低不同领域用户使用空间数据库的门槛。

数据集分析

GeoSQL-Bench 数据集 采用多源结构化方法构建,涵盖三种类型的任务:

  1. 多项选择题和判断题(2380 道),基于 PostGIS 3.5 官方手册,测试函数功能、参数顺序、返回类型以及是否符合规范;
  2. 语法级 SQL 生成题(3744 道),源自手册示例,包含显式提示和欠规范提示,验证模型生成可执行查询的能力;
  3. 表结构检索题(2155 道),基于使用联合国全球地理信息管理 (UN GGIM) 主题和 ISO 19115 分类构建的包含 82 个真实场景的空间数据库,要求模型使用表结构生成复杂查询。

所有任务均在 GPT-4o 的辅助下生成,并经过领域专家的三重审核,以确保准确性、多样性和真实性。

小结

本研究使用 GeoSQL-Eval 框架 系统地评估了六大类共 24 个主流模型。

实验表明,推理增强型模型(例如 GPT-5 和 o4-mini)在复杂的空间查询和多轮查询生成方面表现出色,尤其是在几何任务中展现出显著的准确率优势。通用非推理模型(例如 Claude3.7-Sonnet)在执行效率和语法正确性方面表现更佳。然而,函数调用和参数匹配错误仍然是核心瓶颈,约占 70%,而表结构检索任务由于多表连接逻辑的复杂性而面临最大挑战。

这项工作建立了首个针对 NL2GeoSQL 任务的标准化评估系统,为自然语言与空间数据库的交互提供了关键的基准和优化方向。

DeKeyNLU

DeKeyNLU 通过三层人工交叉验证,实现了任务分解和关键词提取的联合细粒度标注。在此基础上,DeKeySQL 框架创新性地将一个专门的理解模块深度集成到 RAG(结果生成)过程中,建立了一种 “优先考虑精确语义解析” 的新范式,显著提高了复杂查询 SQL 生成的准确性和领域适应性。

image2026-2-3 14_41_56 (1).png

论文意图

本文旨在解决当前 RAG(检索增强生成)和 CoT(思维链)技术在 NL2SQL(自然语言 SQL 生成)任务中遇到的主要瓶颈:

通用大模型在任务分解和关键词提取方面的准确性不足。

现有的数据集在任务分解方面往往过于碎片化,且缺乏特定领域的关键词标注。为了解决这些问题,作者提出了 DeKeyNLU 数据集DeKeySQL 流程(包含三个模块:用户问题理解、实体检索和生成)。通过对模型进行微调以优化问题理解阶段,最终生成的 SQL 语句的准确性得到了提升。

数据集分析

DeKeyNLU 数据集 包含 1500 个高质量标注的问答对,数据来源于 BIRD 基准数据集,涵盖金融、教育等多个领域的真实数据库场景,数据集按 7:2:1 的比例划分为训练集、验证集和测试集。

数据合成采用 “LLM 预标注 + 人工润色” 的混合工作流程:

  • 第一步:使用 GPT-4o 自动生成每个问题的初步任务分解(主任务/子任务)和关键词提取(对象/实现);
  • 第二步:三位专家标注员进行三轮交叉验证和修订确保标注质量。

小结

论文通过引入 DeKeyNLU 数据集DeKeySQL 框架,证明了 针对性的任务分解和关键词提取训练能够有效提升 NL2SQL 的性能。

实验结果表明,利用 DeKeyNLU 对 “用户问题理解” 模块进行微调后,模型在 BIRD 开发集上的准确率从 62.31% 提升至 69.10%,在 Spider 开发集上的准确率从 84.2% 提升至 88.7%。

在 NL2SQL 流程中,实体检索被认为是影响整体准确率的最关键环节,其次是用户问题理解和修正机制。这些发现凸显了以数据集为中心的方法和精心设计的流程对于提升 NL2SQL 系统能力的重要价值,并为用户实现直观、准确的数据交互铺平了道路。

前期功能规划架构设计,包括完成开发,用上 spec 和 superpowers 之类的插件,代码和功能开发都没什么问题。加上现在 agent teams 出来,开发起来飞快。

后期的测试才是最烦人的,项目大部分时间都花在了测试和反馈然后跟 AI 反复对话,他修好之后再测试再反馈,总要来回的话很多轮。随着功能越来越多,流程越来越多,分支也越来越多,相信大家都体验过新功能做好了,旧功能又有小问题。

为了解决这些测试问题,在开发的时候我就让 AI 在写功能的时候顺便写上测试用例,然后调用一个 agent 最后来统一跑这些测试用例,发现问题之后丢到一个统一的类似 issue 的地方,这里会触发 claude code 来进行修复,修复之后又让这个测试 agent 来测试。

如上他们自己跑一天,基本大部分的问题都能自动化解决,最后再人工测试,工作量减轻了很多,并且如果在外面或者哪位同事发现问题,我可以直接发到 issue 上,AI 先跑一轮尝试修复,完美闭环。

所以现在的问题是,这个测试用 opus 或者 sonnet 太奢侈了,大部分都是调用接口或者操作浏览器点按,比如注册登录账户下单什么的,想找一个便宜的,能力又还可以的模型来跑这个,核心代码开发和修复还是走 opus 。


量比较大所以找有 coding plan 的,目前测试了 GLM4.7, kimi k2.5, minimax M2.1 ,今天 GLM 和 minimax 都发新版了还没测。

测试下来 GLM 有点傻,因为不是多模态,无法对 css 布局这些浏览器结果截图进行分析。
K2.5 很好,但他们家的套餐用量太少了,99 一个月的基本 1-2 个小时就干完 5 小时用量,周用量更加不够,目前他家还是搞活动目前是 3 倍用量,活动结束后就更不够用了,要想畅用就得买那个 699 的,699 那我不如走 sonnet 了还能一站式解决。
minimax 跟 GLM 一样,但跑起来比较慢,对图片识别也不友好,并且他是按 promt 次数来计费,这种情境下用量也是很少。

其实写到这里,也有答案了,最好的就是 K2.5 ,就是比较贵,新出的 GLM5 和 minimax M2.5 不知道能力如何。


各位有什么好的方案建议?完成编码的最后一步:测试。

在很多情况下,您需要将文件从手机传输到笔记本电脑,但您可能没有方便的 USB 数据线。那么,您知道如何在没有USB的情况下将文件从手机传输到笔记本电脑吗?在本指南中,我们将探索 6 种无线移动设备到笔记本电脑文件传输的简单方法,以便您可以方便地了解它们。

图片

第 1 部分:如何通过云存储服务将文件从手机传输到笔记本电脑

Google Drive、Dropbox 和 OneDrive 等云存储服务提供了一种无需 USB 即可将文件从手机传输到笔记本电脑的便捷方式。此方法非常适合传输各种类型的数据,包括文档、照片和视频。

以下是使用云服务从手机到笔记本电脑的文件传输:

步骤 1:在手机上打开云存储应用(例如 Google Drive),然后使用您的帐户登录。

步骤 2:点击“ + ”将手机上的文件上传至云存储。

步骤 3:通过网站或应用程序登录笔记本电脑上相应的云存储服务。

步骤 4:找到上传的文件并将其下载到您的笔记本电脑上。

图片

第 2 部分:如何通过 iReaShare Android Manager 将数据从 Android 传输到笔记本电脑(无需电缆)

iReaShare Android Manager是一款适用于Android设备的综合传输工具,支持Wi-Fi连接,因此您可以使用它将不同的文件从Android手机传输到笔记本电脑,而无需USB。通过此程序,您可以 传输照片、视频、音乐、联系人、应用程序、文档等。此外,您还可以一键将所有 Android 文件备份到计算机上。

iReaShare Android 管理器的主要特点:

  • 无需电缆即可将数据从 Android 无线传输到笔记本电脑。
  • Android 文件预览可在您的笔记本电脑上使用。
  • 轻松地将 Android 文件备份到 PC 。
  • 顺利地将文件从备份恢复到您的 Android 手机,而不会覆盖文件。
  • 传输图片、音乐、通话记录、视频、短信等。
  • 支持Android 6.0及以上版本,包括Android 15。

下载 iReaShare Android 管理器。

下载 Win 版下载 Mac 版

以下是如何使用此软件将手机连接到不带 USB 的笔记本电脑:

步骤 1:下载软件后,请在您的笔记本电脑上安装该软件。然后运行它,点击“通过 Wi-Fi 连接”将 Android 手机和笔记本电脑连接到同一个 Wi-Fi 网络。

步骤 2:然后它会要求您在手机上安装Android版本。请打开应用程序,然后单击“扫描”图标扫描笔记本电脑上的二维码。

步骤 3:连接后,选择需要的文件类型,并选择具体数据。然后单击“导出”将数据传输到您的笔记本电脑。

图片

第 3 部分:如何使用 AirDroid 在没有 USB 的情况下将文件从手机共享到笔记本电脑

AirDroid 允许您将移动设备无线连接到笔记本电脑,使文件从手机传输到笔记本电脑变得快速、轻松。只要您的网络可用,您就可以直接在设备之间发送文件。但发送大文件时速度稍慢。

操作方法如下:

步骤 1:从 Google Play Store、Apple App Store 或其网站下载应用程序并将其安装到您的手机和笔记本电脑上。

步骤 2:在手机和笔记本电脑上登录AirDroid帐户,并确保两台设备处于同一网络以启用文件传输。

步骤 3:单击“传输”选项卡,选择您的笔记本电脑设备,然后点击“ Paperclicp ”以选择要从手机传输的文件。

步骤 4:发送文件,您可以在笔记本电脑上接收文件。

图片

第 4 部分:如何使用蓝牙在没有 USB 的情况下将文件从手机传输到笔记本电脑

蓝牙提供了一种简单便捷的方式,无需 USB 电缆即可将小文件从移动设备传输到笔记本电脑。它也不需要任何网络。顺便说一句,请注意,虽然您可以建立蓝牙连接,但其与 iPhone 传输文件的功能有些有限。

步骤如下:

步骤 1:在手机和笔记本电脑上启用蓝牙。

步骤 2:在手机的蓝牙菜单上,选择笔记本电脑的名称以建立连接。然后选择您要传输的文件并选择“共享”>“蓝牙”,然后选择您的笔记本电脑。

步骤 3:在笔记本电脑上,选择“接收文件”以接受传入的文件传输。

图片

第 5 部分:如何使用 Phone Link 在没有 USB 的情况下将文件从手机传输到笔记本电脑

Phone Link 是 Microsoft 推出的一款应用程序,可让您无需 USB 数据线即可将 Android 或 iPhone 连接到 Windows 笔记本电脑,但它需要稳定的网络,并且仅支持 Windows 10 或更高版本。

以下是如何使用 Phone Link 将照片从手机发送到不带 USB 的笔记本电脑:

步骤 1:确保您的 Windows PC 上已安装并设置Phone Link应用程序。在您的 Android 手机上,您需要“链接到 Windows ”应用程序(某些设备上可能已预装)。

步骤 2:按照屏幕上的说明,通过扫描二维码来配对两个设备。

步骤 3:连接后,在手机上选择“照片”。然后查看并选择您最近的照片,并将它们拖放到您的计算机上。

步骤 4:您还可以转到图库应用程序,然后使用 Phone Link 应用程序将所需的照片发送到笔记本电脑。

图片

第 6 部分:如何通过电子邮件将数据从手机共享到笔记本电脑

如果您只需要传输几个文件,电子邮件可能是一个简单而快速的解决方案。您可以将照片、文档和视频等数据直接发送给自己。

方法如下:

步骤 1:在手机上撰写电子邮件并附加要传输的文件。

步骤 2:将电子邮件发送到您的电子邮件地址。

步骤 3:在笔记本电脑上登录您的电子邮件帐户,打开电子邮件并下载附件。然后您的照片将存储在您的笔记本电脑上。

图片

第 7 部分:有关手机到笔记本电脑文件传输的常见问题解答

Q1:无线文件传输安全吗?

安全性取决于方法。云服务通常具有很强的安全性,但请确保您使用强密码。蓝牙对于短距离传输来说相对安全。使用应用程序时,请确保您使用的是信誉良好的应用程序,例如 iReaShare Android Manager。此外,请勿连接到那些未知的网络。

Q2:无线传输的文件大小有限制吗?

这取决于。电子邮件有严格的大小限制。根据您的计划,云服务可能有限制。但iReaShare Android Manager对文件大小没有限制,因此只要您的网络强大,您就可以轻松传输大文件。

结论

不再需要寻找电缆!通过利用 iReaShare Android Manager、云存储等无线传输工具,您无需电缆即可轻松发送文件。如果您想享受无缝批量传输的便利, iReaShare Android Manager是最好的,它可以一次备份您的所有文件。

1月31日-2月2日,由杭州师范大学与浙江大学联合承办的第50届ICPC国际大学生程序设计竞赛东亚区总决赛,在杭州圆满举行。306支参赛队伍同台竞技,展开了一场关于逻辑、速度与创新的巅峰对决。作为赛事的重要支持方,非凸科技再度深度参与,既是对计算机科学基础领域的长期践行,更是对行业人才根基的持续深耕与生态建设。
image.png
闭幕式现场,非凸科技首席运营官郑媛姿受邀出席并分享行业洞见。她表示,ICPC赛场上的极限博弈与协同攻坚,淬炼的正是应对现实世界复杂难题的核心素养。非凸科技是一个能把算法能力“价值最大化”的舞台,企业的发展阶段是同学们也应该纳入就业考量的标准之一。非凸科技期待与青年才俊携手,将赛场上的卓越智慧,转化为赋能行业发展、塑造未来格局的实干力量。

五个小时的赛程紧凑激烈、扣人心弦。选手们或并肩研讨、激荡思维,时而凝神笃行、专注编码。每一次正确提交的背后,是默契协作的积淀;每一次错误反馈之后,是冷静复盘的坚守。经过激烈角逐,清华大学“零基础新生1队”摘得冠军,上海交通大学“夏日影”队与北京大学“飞带不长队”分获亚、季军。
image.png
东亚赛场终章落幕,全球逐梦新程将启。非凸科技祝贺所有获奖队伍,并期待青年学子们在全球总决赛中再创佳绩。未来,非凸科技将持续深耕产学研融合,以顶尖赛事为纽带,搭建青年人才成长平台,汇聚全球科创力量,共赴数智时代的全新征程。

今天这些内容都是豆包输出,我就直接复制 Markdown 文本过来,都不用自己动脑了,这一篇应该算是豆包写的哈哈~ 🤣🤣🤣

话说,这个回顾总结不错,你也可以试试问一下常用的 AI,看看自己的用户画像是什么模样?

豆包懂我:AI 给我总结的用户画像


豆包懂我:AI 给我总结的用户画像

豆包豆包,帮我回顾一下,最近一年以来,我都问了你哪些问题?其中主要侧重什么方面?有什么样的代表性?然后根据这些问题给出我的人物画像。

640

我帮你把 近一年来 和我聊过的内容,完整梳理、提炼、总结成一份清晰的 「年度回顾 + 人物画像」,全是你真实聊过的内容,不啰嗦、只抓核心。

一、你最近一年问过的核心问题

1. 游戏攻略

  • 《暗黑破坏神 4》赛季玩法、装备、任务、高效攻略
  • 要求精准、可操作、信息准确、用中文游戏术语

2. 数码硬件 & 科技

  • PC 硬件:显卡、CPU 性能天梯、型号对比、购买 / 升级建议
  • 国产大飞机 C919:技术细节、运营、乘坐体验、内容创作素材

3. 内容创作

  • 文章结构、标题、文案、科普 / 散文类内容整理
  • 配图需求:动漫风格、精细化元素(四只猫等)

4. 生活与美食

  • 东北菜:菜品、做法、文化背景(如雪衣豆沙)
  • 健康问题:身体症状、原因与处理建议

5. AI 与工具使用

  • 图片生成、多轮精细化调整
  • 功能规则、活动相关咨询

6. 职业相关

  • 新能源汽车业务相关思考

二、你的问题侧重什么

1. 硬核信息 > 情绪安慰

你更爱问 原理、数据、对比、准确性,不喜欢模糊笼统的回答。

2. 实用导向 > 闲聊

问攻略、硬件、技术、写作,都是为了 直接能用

3. 深度探究 > 浅尝辄止

会追问细节、查证来源、要结构化清单 / 对比,是典型的 求知型人格

4. 兴趣非常垂直且稳定

游戏、硬件、科技、阅读、写作、美食,长期围绕这几类深耕。

三、你的人物画像

1. 核心标签

理性技术控 + 深度内容创作者 + 精致生活者 + 资深游戏玩家

2. 性格特质

  • 逻辑强,重视 准确、严谨、细节
  • 做事有条理,喜欢 结构化、可落地 的内容
  • 有探索欲,对感兴趣的领域会 钻得很深
  • 温和内敛,不浮躁,偏爱高质量信息与生活

3. 生活状态

  • 住在城市,生活稳定,有自己的爱好空间
  • 已婚,丁克,和四只猫一起生活,温柔有耐心
  • 一边做管理工作(新能源汽车行业),一边坚持内容创作
  • 喜欢游戏放松,也喜欢美食、健康、科技这类真实质感的东西

4. 思维模式

  • 擅长 对比、分析、总结
  • 遇到问题先找 原理、数据、最优方案
  • 输出欲强,喜欢把知识整理成 能分享的内容

四、一句话总结你

你是一位理性、严谨、有深度、热爱生活与知识的「技术 + 文化」复合型管理者 —— 既能啃得动硬件与攻略,也写得了公众号,过得精致又有态度。


全文链接 豆包懂我:AI 给我总结的用户画像