2026年3月

最近越来越不想当程序员了,写代码都感到一阵厌恶,刚好最近自己做自媒体搞起来了,全网粉丝破 80w+了,还在上涨期,有了另一份职业的支撑,我是越来越想转行了,真不再想继续在这代码世界转了。

1 、先说说为什么入编程的坑吧:大学学的机械,大三 20 年疫情那会为了以后赚钱,努力在家学了半年,自学了前端就入行了,没有一丁点热爱,单纯就是为了赚钱。

2 、开始 1-2 年那会还学点技术,现在 AI 出来了,我也几年没学技术了,越来越觉得没啥意思,与其花这 8 小时去换那点薪资(税前 16k ),不低了,我纠结也是纠结这 16k 的薪资,但仔细想想,与其在这里继续坐牢,不如去做一些能够提升自己,以及未来 AI 不能替代的东西(后面提到)。

3 、未来做什么?

3.1 、首先自媒体这行肯定继续做,这是我的保底(目前稳定 14k 左右),能够保证我饿不死,是我支撑我去做其他事情的基石。

3.2 、去做假发主播。之前我本人一直都在戴假发,也认识杭州本地的一个假发实体店大老板,本来去年他就叫我去全职当主播的,那会因为没有副业不敢,现在有了,有底气了,就重新联系了他,如果他愿意给我机会,就算薪资减半(底薪+提成),我都愿意去。因为我个人脱发+戴假发的特点+我喜欢说话,这种独特性保证了 AI 无法替代我,我自己本身日常就街头卖艺了,不怕丢脸哈哈哈,感觉做主播还挺有意思的,真的很锻炼人。希望那个老板也能够给我一个机会。( ps:以后别人问我干啥的,我就说我是假发主播,假发主播戴假发是不是很合理??🤣)

3.3 、如果不给我机会,那么我会尝试去做销售,即使是从零开始,也愿意,我是真心不想和机器、和 AI 打一辈子交道了( ps:假发主播本质也算是销售的一种)


其实我想转行,也仅仅是有了自媒体这个兜底,如果没有自媒体,我是不敢去想的~

大家觉得怎么样?

13 年入行前端到现在,因为比较佛系不争不抢,至今还是一线开发。
有老有小有房贷,二三线省会城市。
如今 AI 盛行,感觉有点力不从心,不知道往哪个方向去走了。
目前公司还算比较安逸,如果不给大礼包,能混到退休那种。
铁子们,该如何破局呢?

在数字化浪潮席卷各行各业的今天,网站启用HTTPS加密协议已从“可选”变为“标配”。然而,对于许多个人站长、中小企业乃至政务教育单位来说,SSL证书的选择往往陷入两难:国际免费证书(如Let‘s Encrypt)有效期仅90天,频繁续期让人疲于奔命;而付费证书每年上千元的成本,又让预算有限的用户望而却步。进入2026年,随着国产密码算法的普及和合规要求的提高,哪里还能申请到稳定的一年期免费证书?  答案指向了国产SSL证书品牌——JoySSL。

为什么是JoySSL?

在当前的免费SSL证书市场中,JoySSL凭借其独特的一年期免费策略国密算法支持脱颖而出。相较于国际主流CA机构将免费证书有效期缩短至200天甚至维持90天的做法,JoySSL提供的免费证书单次有效期为365天,且支持无限次续签,真正实现了“一次申请,长期使用”。

更值得关注的是,JoySSL积极响应国家《密码法》和“等保2.0”的合规要求,为政务、教育、金融等关键领域提供免费国密SSL证书。其采用的SM2/SM3/SM4国产算法,不仅能有效抵御量子计算攻击,确保证据链的自主可控,还通过“SM2+RSA双证书”模式完美解决了国密算法在国际浏览器(如Chrome、Firefox)上的兼容性问题。

手把手教你申请一年期免费证书

免费SSL证书申请入口

第一步:注册账号并解锁权益
访问JoySSL官网,点击注册新账号。在注册过程中,务必填写特定的推荐注册码2309670 ,这是解锁一年期免费证书申请权限的关键。填写该邀请码后,用户不仅可以免费领取政务版或教育版国密SSL证书,还能享受一次免费的安装技术支持服务。

第二步:选择证书并提交申请
登录后台,在证书产品页面选择“免费体验版”、“政务版”或“教育版”SSL证书。根据你的需求选择单域名证书(保护一个域名)、通配符证书(保护主域名及所有二级子域名)或多域名证书。输入需要加密的域名,并填写单位基本信息(如为组织申请,需确保信息与组织机构代码证一致)。

第三步:完成域名所有权验证
这是确保证书只能由合法持有者申请的核心环节。JoySSL通常提供两种验证方式:

  • DNS验证(推荐):  在域名管理后台(如阿里云、腾讯云DNSPod),根据JoySSL提供的记录值添加一条TXT解析记录。
  • 文件验证:  将系统生成的验证文件上传至服务器指定目录下。
    添加完成后,返回JoySSL后台点击“验证”,通常几分钟内即可通过审核。

第四步:下载证书并部署
验证通过后,证书即刻签发。用户可以下载适配Nginx、Apache、IIS、Tomcat等主流服务器的证书文件包。以Nginx为例,将证书文件上传至服务器,修改配置文件指向正确的.crt和.key文件路径,重启服务后,网站即可实现HTTPS加密访问。

独立开发日记:今天给「静听」音乐播放器做了十几个优化

项目背景

「静听」是我独立开发的一款 iOS 本地音乐播放器,主打无损格式支持、WiFi 传歌、无广告体验。开发一年多了,一直在持续优化。

今日优化清单

🎵 播放体验修复

  1. 单曲循环 bug:之前循环播放时只重复最后几秒,现已修复
  2. 随机播放逻辑:优化了算法,现在是真正的全曲库随机
  3. 播放连续性:歌曲播完后自动切下一首,逻辑更符合直觉
  4. 播放时间显示:修复了偶尔「卡住」不走的罕见问题

🎧 蓝牙交互优化

  1. 蓝牙自动恢复:连接蓝牙耳机自动继续播放,断开自动暂停
  2. Siri 兼容性:修复了唤起 Siri 时闪退的问题
  3. 音频中断处理:微信语音等中断后智能恢复播放位置

📱 UI/UX 细节

  1. 歌单封面:无封面歌单自动显示第一首歌的封面
  2. 静默刷新:修改歌曲信息后列表自动刷新,无闪烁
  3. 播放队列定位:新增「一键定位」到当前播放歌曲
  4. 工具栏同步:底部工具栏播放模式修改即时生效

🔧 核心功能

  1. WiFi 传歌:增加取消导入功能,修复重复导入跳过逻辑
  2. 编辑页面:优化封面保存逻辑,不再保存占位图
  3. 歌词显示:修复导入的歌词文件显示空白的问题

🛠️ 技术底层

  1. 音频引擎:换用 ffmpeg ,支持更多音频格式
  2. 状态同步:播放模式修改后全局同步更新
  3. 状态恢复:重启 App 正确记住播放状态和队列
  4. 批量管理:页面底部显示筛选后的歌曲总数

技术细节分享

单曲循环修复

问题出现在 AVPlayertimeObserver 回调时机处理上。原逻辑在歌曲即将结束时就开始准备循环,导致只播放最后几秒。

解决方案:

// 修复后的逻辑
player.addPeriodicTimeObserver(forInterval: CMTime(seconds: 0.5, preferredTimescale: CMTimeScale(NSEC_PER_SEC)), queue: .main) { [weak self] time in
    guard let self = self else { return }
    let currentTime = CMTimeGetSeconds(time)
    let duration = CMTimeGetSeconds(self.player.currentItem?.duration ?? CMTime.zero)
    
    // 在歌曲结束前 0.1 秒开始准备循环
    if duration - currentTime < 0.1 && self.playMode == .singleLoop {
        self.seek(to: 0)
        self.play()
    }
}

蓝牙中断处理

iOS 的音频会话管理比较 tricky ,特别是蓝牙设备连接/断开时的状态恢复。

关键代码:

// 监听蓝牙状态变化
NotificationCenter.default.addObserver(
    self,
    selector: #selector(handleAudioRouteChange),
    name: AVAudioSession.routeChangeNotification,
    object: nil
)

@objc func handleAudioRouteChange(notification: Notification) {
    guard let userInfo = notification.userInfo,
          let reasonValue = userInfo[AVAudioSessionRouteChangeReasonKey] as? UInt,
          let reason = AVAudioSession.RouteChangeReason(rawValue: reasonValue) else {
        return
    }
    
    switch reason {
    case .newDeviceAvailable: // 新设备可用(如连接蓝牙)
        if shouldResumePlayback {
            resumePlayback()
        }
    case .oldDeviceUnavailable: // 旧设备不可用(如断开蓝牙)
        pausePlayback()
        savePlaybackPosition()
    default:
        break
    }
}

播放模式全局同步

使用 UserDefaults + NotificationCenter 实现状态同步:

// 设置播放模式时
UserDefaults.standard.set(playMode.rawValue, forKey: "currentPlayMode")
NotificationCenter.default.post(name: .playModeChanged, object: playMode)

// 各处监听
NotificationCenter.default.addObserver(
    self,
    selector: #selector(updatePlayModeUI),
    name: .playModeChanged,
    object: nil
)

遇到的问题和解决方案

1. 随机播放只在几首歌里随机

问题:原算法使用了 Array.shuffled(),但在每次切歌时都重新 shuffle ,导致随机性不够。

解决:改为一次性 shuffle 整个播放队列,然后顺序播放。

2. 播放时间偶尔不走

问题AVPlayertimeObserver 在某些情况下(如后台播放、网络波动)会停止回调。

解决:增加保活机制,定期检查播放状态,必要时重新添加 observer 。

3. 编辑页面封面逻辑

问题:用户不选择封面时,系统会保存一个占位图,导致不必要的存储。

解决:判断用户是否真的选择了新封面,如果没有,保持原封面或使用默认 App logo 。

开发感悟

做独立开发最有趣的地方就是这些「小修小补」。每个 bug 的修复、每个体验的优化,都能让产品更接近「完美」。

今天修复的这些问题,大多都是用户反馈或自己使用中发现的。有时候一个看似简单的「继续播放」逻辑,背后涉及音频会话管理、状态恢复、用户体验等多个方面。

下一步计划

  1. 批量管理筛选:增加按专辑、艺术家、最近播放等筛选功能
  2. 播放列表管理:优化播放列表的创建、编辑、分享功能
  3. 音频效果:考虑增加更多均衡器预设和音效
  4. 多设备同步:研究 iCloud 同步播放列表和播放进度的可行性

讨论点

  1. 大家在使用音乐播放器时,最在意哪些功能或细节?
  2. 对于本地音乐播放器,还有什么功能是你们觉得必备的?
  3. 在音频播放和蓝牙设备兼容性方面,有什么经验或坑可以分享?


静听 - 无损音乐播放器 & 本地传歌
App Store: [搜索「静听」即可下载]
GitHub: [暂未开源,考虑中]

欢迎交流讨论!

大家好,我是良许

在嵌入式开发领域,处理器架构的选择直接影响着系统的性能、功耗和开发成本。

作为一名从事嵌入式开发多年的程序员,我经常需要在不同架构的处理器上进行开发工作。

今天,我想和大家聊聊处理器架构中的两大流派:RISC(精简指令集计算机)和 CISC(复杂指令集计算机)。

这两种架构各有千秋,理解它们的差异对于我们选择合适的硬件平台至关重要。

1. 什么是 RISC 和 CISC

1.1 CISC 架构的诞生背景

CISC 架构诞生于计算机发展的早期阶段,那时候内存非常昂贵,程序员主要使用汇编语言编程。

为了减少程序占用的内存空间,处理器设计者们想出了一个办法:让单条指令能够完成更复杂的操作。

这样一来,原本需要多条指令才能完成的任务,现在只需要一条指令就能搞定,程序的体积自然就小了。

典型的 CISC 处理器包括 Intel 的 x86 系列,这也是我们日常使用的 PC 机所采用的架构。

CISC 指令集包含了大量的指令,有些指令非常复杂,可以直接操作内存,甚至能完成循环、字符串处理等高级操作。

1.2 RISC 架构的设计理念

到了 20 世纪 80 年代,随着编译器技术的进步和内存成本的下降,研究人员发现,程序中实际使用频率高的往往是那些简单的指令,而复杂指令的使用频率很低。

于是,RISC 架构应运而生,它的核心思想是:简化指令集,让每条指令都能在一个时钟周期内完成,通过提高指令执行效率来提升整体性能。

ARM 处理器就是 RISC 架构的典型代表,在嵌入式领域占据着统治地位。

我们常用的 STM32 系列单片机,采用的就是 ARM Cortex-M 内核,这是一种 32 位的 RISC 架构处理器。

此外,MIPS、RISC-V 等也都属于 RISC 架构。

2. 指令集设计的核心差异

2.1 指令数量和复杂度

CISC 架构的指令集非常庞大,x86 架构的指令数量可以达到数百条甚至上千条。

这些指令的长度不固定,有的只有 1 个字节,有的可能长达 15 个字节。

指令的功能也千差万别,从简单的加法运算到复杂的字符串搜索,应有尽有。

相比之下,RISC 架构的指令集要精简得多,通常只有几十到一百多条指令。

以 ARM Cortex-M3 为例,它的指令集大约包含 100 多条指令。

更重要的是,RISC 指令的长度是固定的,ARM 架构大多数指令都是 32 位(4 字节),Thumb 指令集则是 16 位(2 字节)。

这种固定长度的设计大大简化了指令的译码过程。

2.2 寻址模式

CISC 架构支持非常丰富的寻址模式,x86 架构可以支持十几种寻址方式。

这意味着一条指令可以直接访问内存、使用基址加偏移、间接寻址等多种方式来获取操作数。

例如,在 x86 架构中,你可以写出这样的指令:

MOV EAX, [EBX + ECX*4 + 0x1000]

这条指令直接从内存地址(EBX + ECX*4 + 0x1000)读取数据到 EAX 寄存器,一条指令就完成了复杂的地址计算和内存访问。

RISC 架构则大幅简化了寻址模式,通常只支持几种基本的寻址方式。

在 ARM 架构中,内存访问必须通过专门的加载/存储指令(Load/Store)来完成,而算术逻辑运算只能在寄存器之间进行。

这就是著名的"Load-Store 架构"。

例如,要完成上面类似的操作,在 ARM 中需要这样写:

ADD R0, R1, R2, LSL #2  ; R0 = R1 + R2*4
ADD R0, R0, #0x1000     ; R0 = R0 + 0x1000
LDR R3, [R0]            ; R3 = *R0

虽然需要多条指令,但每条指令都很简单,执行速度快。

2.3 指令执行周期

CISC 架构的指令执行周期差异很大。

简单的指令可能只需要 1-2 个时钟周期,而复杂的指令可能需要几十甚至上百个时钟周期。

这种不确定性给流水线设计带来了很大的挑战。

RISC 架构追求的目标是让大部分指令都能在一个时钟周期内完成(在理想的流水线情况下)。

虽然实际上由于流水线冒险、分支预测失败等原因,并不是所有指令都能达到这个目标,但 RISC 的指令执行时间相对更加可预测,这对于实时系统来说是一个重要优势。

3. 硬件实现的差异

3.1 芯片复杂度

CISC 处理器为了支持复杂的指令集,需要更复杂的译码逻辑和微代码控制单元。

一条复杂的 CISC 指令在执行时,实际上会被分解成多个微操作(micro-ops),这需要额外的硬件资源。

因此,CISC 处理器的晶体管数量通常更多,芯片面积更大。

RISC 处理器的设计相对简单,指令译码器的逻辑更加直接。

由于指令格式规整,可以使用更高效的流水线设计。

在相同的制程工艺下,RISC 处理器可以用更少的晶体管实现相同的功能,或者在相同的芯片面积下集成更多的核心。

这也是为什么 ARM 处理器能够在移动设备和嵌入式系统中占据主导地位的重要原因之一。

3.2 功耗特性

功耗是嵌入式系统设计中的关键考量因素。

RISC 架构由于硬件结构相对简单,指令执行效率高,通常具有更好的能效比。

这对于电池供电的设备来说至关重要。

以 STM32 系列单片机为例,它们采用 ARM Cortex-M 内核,在低功耗模式下可以将功耗降到微安级别。

我在做一个电池供电的物联网项目时,使用 STM32L 系列超低功耗单片机,通过合理的功耗管理,让设备在一颗纽扣电池的供电下运行了两年多。

这在 CISC 架构的处理器上是很难实现的。

3.3 寄存器数量

CISC 架构通常提供较少的通用寄存器。

例如,x86 架构在 32 位模式下只有 8 个通用寄存器(EAX、EBX、ECX、EDX、ESI、EDI、EBP、ESP),而且其中一些还有特殊用途。

这意味着编译器在生成代码时,经常需要将变量存储到内存中,导致频繁的内存访问。

RISC 架构则提供了更多的通用寄存器。

ARM 架构有 16 个通用寄存器(R0-R15),RISC-V 架构有 32 个通用寄存器。

更多的寄存器意味着编译器可以将更多的变量保存在寄存器中,减少内存访问,从而提高程序的执行效率。

4. 编程和开发的影响

4.1 汇编语言编程

在汇编语言层面,CISC 架构的指令更接近高级语言的语义,一条指令可以完成更多的工作。

对于手写汇编代码的程序员来说,CISC 指令集可能更加直观。

但是,由于指令复杂,程序员需要记忆大量的指令和寻址模式,学习曲线较陡。

RISC 架构的汇编语言虽然指令简单,但要完成同样的功能可能需要更多的指令。

不过,由于指令规整,学习起来相对容易。

在实际的嵌入式开发中,我们很少直接编写大量的汇编代码,通常只在启动代码、中断处理等关键部分使用汇编。

下面是一个简单的例子,展示在 STM32 上使用内联汇编来实现原子操作:

// 使用ARM汇编实现原子加法
uint32_t atomic_add(volatile uint32_t *ptr, uint32_t value)
{
    uint32_t result;
    uint32_t tmp;
    
    __asm__ volatile(
        "1: LDREX %0, [%2]\n"        // 独占加载
        "   ADD %0, %0, %3\n"         // 加法运算
        "   STREX %1, %0, [%2]\n"     // 独占存储
        "   CMP %1, #0\n"             // 检查是否成功
        "   BNE 1b\n"                 // 失败则重试
        : "=&r" (result), "=&r" (tmp)
        : "r" (ptr), "r" (value)
        : "cc", "memory"
    );
    
    return result;
}

这段代码使用了 ARM 的 LDREX/STREX 指令来实现原子操作,这是 RISC 架构中实现同步原语的典型方式。

4.2 编译器优化

现代编译器技术的发展,使得高级语言程序员不再需要过多关注底层指令集的差异。

编译器会根据目标架构的特点进行优化。

对于 CISC 架构,编译器需要在众多复杂指令中选择最合适的指令组合,这增加了编译器的复杂度。

而且,由于指令执行时间不确定,编译器很难准确估计代码的执行时间。

对于 RISC 架构,编译器的优化工作相对更加直接。

由于指令简单规整,编译器可以更好地进行指令调度、寄存器分配等优化。

在嵌入式开发中,我们使用 GCC 或 Keil 等工具链编译代码时,编译器会针对 ARM 架构进行各种优化,比如循环展开、函数内联、常量传播等。

4.3 代码密度

代码密度是指单位内存空间能存储多少有效代码。

在嵌入式系统中,Flash 存储空间往往是有限的,代码密度就显得尤为重要。

CISC 架构由于指令长度可变,且单条指令功能强大,理论上可以获得更高的代码密度。

但实际情况并非总是如此,因为复杂指令的使用频率可能不高。

RISC 架构虽然指令长度固定,但为了提高代码密度,也发展出了一些变体。

例如,ARM 的 Thumb 指令集使用 16 位编码,可以显著减小代码体积。

在 STM32 开发中,我们通常会启用 Thumb-2 指令集,它混合使用 16 位和 32 位指令,既保证了性能,又提高了代码密度。

// 在STM32项目中,编译器选项通常会包含:
// -mthumb -mthumb-interwork
// 这样编译出来的代码会使用Thumb指令集
void delay_ms(uint32_t ms)
{
    uint32_t i, j;
    for(i = 0; i < ms; i++) {
        for(j = 0; j < 1000; j++) {
            __NOP();  // 空操作,编译为Thumb指令
        }
    }
}

5. 性能和效率对比

5.1 计算性能

在计算性能方面,不能简单地说哪种架构更优秀,这取决于具体的应用场景和实现方式。

CISC 架构的复杂指令可以在某些特定任务上展现优势。

例如,x86 架构的 SSE、AVX 等 SIMD 指令集,可以一次处理多个数据,在多媒体处理、科学计算等领域表现出色。

RISC 架构通过提高时钟频率和优化流水线来提升性能。

在嵌入式领域,ARM Cortex-M 系列处理器虽然主频不高(通常在几十到几百 MHz),但由于指令执行效率高,在实际应用中性能表现良好。

我在使用 STM32F4 系列单片机(主频 168MHz)开发音频处理项目时,通过合理的算法优化和 DMA 配置,可以实时处理 48kHz 采样率的音频信号。

5.2 实时性能

在嵌入式系统中,实时性能往往比平均性能更重要。

RISC 架构的指令执行时间更加可预测,这对于硬实时系统来说是一个重要优势。

例如,在电机控制应用中,我们需要在精确的时间点更新 PWM 占空比。

使用 STM32 单片机时,我可以比较准确地估算中断服务程序的执行时间,因为每条 ARM 指令的执行周期是相对确定的。

这在 CISC 架构上就比较困难,因为指令执行时间的变化范围较大。

5.3 中断响应

中断响应时间是嵌入式系统的关键指标之一。

RISC 架构通常具有更快的中断响应速度,因为中断处理的硬件逻辑相对简单。

在 STM32 中,中断响应包括以下步骤:保存当前程序状态、跳转到中断向量表、执行中断服务程序、恢复程序状态。

由于 ARM Cortex-M 的硬件设计优化,这个过程可以在很短的时间内完成。以下是一个典型的中断服务程序示例:

// STM32的外部中断处理
void EXTI0_IRQHandler(void)
{
    // 检查中断标志
    if(__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_0) != RESET) {
        // 清除中断标志
        __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_0);
        
        // 执行中断处理逻辑
        // 由于ARM指令简单,这里的代码执行时间可预测
        HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
    }
}

6. 实际应用场景

6.1 嵌入式系统

在嵌入式领域,RISC 架构占据绝对主导地位。

ARM 处理器几乎统治了整个嵌入式市场,从简单的 8 位单片机替代品(Cortex-M0),到高性能的应用处理器(Cortex-A 系列),都能看到 ARM 的身影。

我在做嵌入式 Linux 开发时,使用的是基于 ARM Cortex-A 系列的处理器。

这些处理器不仅性能强大,而且功耗控制得很好,非常适合汽车电子等对可靠性和功耗都有严格要求的应用。

6.2 服务器和数据中心

传统上,服务器市场一直是 x86 架构的天下。

但近年来,ARM 架构也开始进军这个领域。

AWS 的 Graviton 处理器就是基于 ARM 架构的服务器芯片,它在能效比方面表现出色,对于云计算这种需要大规模部署的场景来说,能效比的提升意味着巨大的成本节约。

6.3 移动设备

智能手机和平板电脑几乎全部采用 ARM 架构的处理器。

苹果的 A 系列芯片、高通的骁龙系列、华为的麒麟系列,都是基于 ARM 架构。

这些处理器需要在有限的电池容量下提供强大的性能,RISC 架构的高能效比优势在这里得到了充分体现。

7. 架构融合的趋势

7.1 CISC 向 RISC 学习

现代的 x86 处理器已经不是纯粹的 CISC 架构了。

从 Pentium Pro 开始,Intel 就在处理器内部将复杂的 x86 指令转换成类似 RISC 的微操作(micro-ops),然后用 RISC 风格的执行引擎来执行这些微操作。

这种设计既保持了对 x86 指令集的兼容性,又获得了 RISC 架构的性能优势。

7.2 RISC 的扩展

RISC 架构也在不断发展,增加了一些复杂指令来提高特定任务的性能。

例如,ARM 架构增加了 NEON SIMD 指令集,用于加速多媒体处理;增加了 DSP 指令,用于数字信号处理。

这些扩展指令虽然增加了指令集的复杂度,但都是在保持核心设计理念的基础上进行的。

7.3 新兴架构

RISC-V 是近年来备受关注的开源指令集架构。

它继承了 RISC 的设计理念,同时吸取了过去几十年处理器设计的经验教训。

RISC-V 采用模块化设计,基础指令集非常精简,用户可以根据需要添加扩展指令集。

这种灵活性使得 RISC-V 在物联网、嵌入式等领域展现出巨大潜力。

8. 总结

RISC 和 CISC 代表了处理器设计的两种不同哲学。

CISC 追求用复杂的指令来简化编程,RISC 则追求用简单的指令来提高执行效率。

经过几十年的发展,两种架构都在相互借鉴,界限已经不再那么清晰。

在嵌入式开发领域,我们更多地接触到的是 RISC 架构,特别是 ARM 处理器。

理解 RISC 和 CISC 的差异,可以帮助我们更好地理解处理器的工作原理,写出更高效的代码。

无论是在做 STM32 的裸机开发,还是在做嵌入式 Linux 的应用开发,这些底层知识都是非常有价值的。

选择哪种架构,最终还是要根据具体的应用需求来决定。

对于需要高性能计算、兼容性要求高的场景,x86 架构可能是更好的选择;对于功耗敏感、实时性要求高的嵌入式应用,ARM 等 RISC 架构则更有优势。

作为嵌入式开发者,我们需要根据项目的具体需求,选择最合适的硬件平台,并充分发挥其优势。

更多编程学习资源

各位大佬,2026 年了 claude 稳定的订阅方式是啥?

美区 apple store 购买,google 账号登录,新加坡 ip ,买完就 disable 了。

现在马到成功勋章佩戴后会高亮为金色,更显眼,建议 Pro 用户默认高亮,但是没什么颜色可选了。提供更多的个性化功能,有助于提升 Pro 用户数。

去年十月搞了个邀请链接,费劲吧啦写了 50 字小作文注册上了,没发过贴,然后有段时间没咋登,昨天想登上去看看,结果发现号已经没了。。。。。。

从昨天开始日历无法同步,今天还是不行,刚去看了一下。

icloud.com 正常,但是 icloud.com.cn 打不开,云上贵州挂了?

你们的正常吗?

ScreenShot_2026-03-10_091556_151

QQ 管家出品了 QClaw 可以微信直连,当前内测用户 mac 端已经可以使用了。
腾讯云出了 Workbuddy

微信直连的垄断技术能够完全替代 OpenClaw 吗

阿里巴巴达摩院发布脂肪肝筛查 AI 模型 MAOSS

3 月 9 日,阿里巴巴达摩院发布文章,宣布于近日联合中国医科大学附属盛京医院、南京大学附属鼓楼医院等机构研发出脂肪肝筛查 AI 模型 MAOSS。该模型通过平扫 CT 影像、血清指标等常见检查,可精准筛查肝脂肪分期、评估肝纤维化进展,将高风险患者检出率从 16.6% 提升至 52.4%,为早期干预提供预警信号,实现慢性肝病管理「关口前移」。论文已发布于《Nature Communications》。来源


华硕 NUC 16 Pro 迷你主机上市

华硕于 3 月 9 日在国内电商平台上架 NUC 16 Pro 迷你主机,该机采用英特尔酷睿 Ultra X7 358H + 32GB RAM + 1TB 存储规格,定价为 10999 元。该机尺寸为 14.4 x 11.7 x 4.2mm,正面带有华硕徽标及 2 个 USB-A 3.2 Gen 2 10Gbps 接口、1 个 USB-C Gen 2 10Gbps 接口。机顶左上角带有 NUC 标识,机背提供 2 个雷电 4 接口、2 个 HDMI 2.1(可选 2 个 DP)、2 个 USB-A 3.2 Gen 2 10Gbps 接口、2 个 2.5G 网口。配置上,该机搭载 16 核心英特尔酷睿 Ultra X7 358H 处理器,使用双风扇散热,板载 32GB LPDDR5x 8533MHz RAM。该机支持 PCIe 5.0 SSD,支持免工具快拆升级。机身网卡支持 Wi-Fi 7 和蓝牙 6.0 技术。来源


微软推出包含新 AI 功能的订阅服务 Microsoft 365 E7

3 月 9 日,微软推出一系列与 AI 相关的新服务产品,均为其企业「前沿转型」理念下的产品,并全部放入将于 5 月 1 日上线的新等级订阅服务 Microsoft 365 E7: The Frontier Suite 内。Microsoft 365 Copilot 第三波更新将实装于 Word、Excel、PowerPoint 与 Outlook,更新引入全新的 Work IQ 智能层,可以在处理任务时综合考虑员工工作形式、工作对象与合作工作内容等,更深入工作环境。同时,该等级的 Copilot 聊天引入来自 Anthropic 的 Claude 模型,OpenAI 的模型也将更新至最新一代。AI 助手 Claude Cowork 也以 Copilot Cowork 的形式整合进 Microsoft 365 Copilot 服务。微软还发布了可以监管全组织内部 AI 代理状态的 Agent 365 控制平台。Microsoft 365 E7 订阅价为每名用户每月 99 美元。来源


OpenAI 推出应用安全智能体 Codex Security

近日,OpenAI 宣布推出应用安全智能体 Codex Security。OpenAI 称 Codex Security 可以构建关于项目的深层上下文,识别被其他工具遗漏的复杂漏洞,并提供更高置信度的分析结果与修复方案。Codex Security 前身为去年在小部分客户中私测的 Aardvark 功能,与测试版相比,目前漏洞严重性虚标比例降低了 90% 以上,全量代码仓库检出误报率下降 50% 以上。Codex Security 即日起向 ChatGPT Enterprise、Business 与 Edu 客户推送,并提供为期一个月的免费使用。OpenAI 还向开源维护者发出首批 Codex for OSS 计划邀请,提供免费的 ChatGPT Pro 与 Plus 账户、代码评审与 Codex Security 工具支持开源生态。来源


Mozilla 与 Anthropic 使用 Claude 发现多个 Firefox 安全漏洞

近日,Anthropic 发布博文,宣布与 Mozilla 的研究员合作使用 Claude Opus 4.6,在两周内发现 Firefox 浏览器 22 处安全漏洞,其中有 14 处被 Mozilla 定级为高严重性漏洞,数量约等于 2025 年全年修复的高严重性 Firefox 漏洞的五分之一,包括一个可能导致攻击者用任意恶意内容覆盖数据的 User After Free 内存漏洞。这些漏洞已于 Firefox 148.0 中修补。Anthropic 还另外测试了 Claude 针对漏洞创造滥用程序的能力,结果显示 Opus 4.6 发现漏洞的能力远强于利用漏洞的能力。Anthropic 称还使用 Claude Opus 4.6 发现了如 Linux 内核等重要开源项目中的漏洞。来源


不妨一看的简讯

  • 据 Z Finance 消息,腾讯最近在研发一款 OpenClaw 的一键启动包产品 QClaw,一键安装后可快速关联 QQ 与微信使用。另据《科创板日报》报道,企业微信官方推送消息,宣布已接入 OpenClaw 关联功能,同时支持通过 OpenClaw 快速接入并将数据写入智能表格。来源 来源2
  • 3 月 8 日,百度智能云在北京、上海等多地举办 OpenClaw 开发者快闪活动,为参与者安装 OpenClaw。来源
  • 3 月 9 日,字节跳动火山引擎正式上线 ArkClaw,为云上 SaaS 版 OpenClaw 服务,可于网页端在线使用。ArkClaw 已支持多种主流即时通讯 app,兼容 GLM、MiniMax、Kimi 等主流模型。火山方舟 Coding Plan 用户可抢先体验。来源
  • 3 月 9 日,腾讯云上线全场景 AI 智能体 WorkBuddy。据介绍,WorkBuddy 完全兼容 OpenClaw 技能,内置了超 20 种 Skills 技能包与 MCP 协议。支持多窗口、多 Agent 并行工作,国内版支持 Hunyuan、DeepSeek、GLM、Kimi、MiniMax。接入平台上支持企业微信、QQ、飞书、钉钉等工具。来源
  • 3 月 9 日,微博接入 Kimi Claw,可在微博私信微博龙虾助手使用。来源
  • 3 月 9 日,国家超算互联网平台宣布升级 OpenClaw 服务,打通飞书与企业微信。来源
  • 3 月 9 日晚,安世中国宣布自主研发的「12 英寸平台」已成功实现 12 英寸晶圆双极分立器件小批量量产。安世半导体公众号原文于一段时间后删除。安世中国曾在 3 月 6 日发布公告,称 Nexperia B.V. 于 3 月 3 日批量禁用中国区所有员工办公账号,导致中国区运营异常,中国区 IT 与业务部门已启动应急预案并基本恢复业务运行。来源
  • 3 月 9 日,X 平台为图片推文发布设置新增一项「禁止 Grok 更改」选项。经测试,该功能只能阻止其他用户在推文回复中通过 @Grok 功能编辑图像。来源


少数派的近期动态

  • 少数派年度征文投稿窗口最后一周!古法手搓大战人工智能,你会是哪条赛道的大赢家?参与一下

你可能错过的文章

> 下载 少数派 2.0 客户端、关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀

    这个大模型就是 MiniMax M2.5 。

    上线不到一个月,用量甚至都超过 GPT 、Claude 、Gemini 。

    不光是排第一,比第二名多将近 50%。

    OpenClaw 的亲爹 Peter Steinberger ,最近也在推特上连续推荐它。

    我研究了一下,为什么 MiniMax M2.5 能拿下全球用量第一?

    俩字:便宜。

    agent 跑一小时,1 美金左右。低速模式,0.3 美金。
    对开发者来说,够用加够便宜,就够了。

    Minimax 港股 1 月上市,发行价 165 港元,
    现在 800 出头,
    两个月不到涨了近 5 倍。
    股价起飞了。
    ![image]( https://im.gurl.eu.org/file/AgACAgEAAxkDAAEBcjNpr2qmYZnRXPYuclHjCy6EhCUC1gACeAtrG9kFgEW8Uj8jYDrFowEAAwIAA3kAAzoE.png)

    过年前在路过发生了一起小事故,等红绿灯时副驾开门下车,车门撞到路过的电瓶车.
    
    因为双方都有事,看着也不严重,于是当场给了 150 块钱私了.
    

    以上是背景.

    5 天后,交警给我打电话,说对方报警了...

    然后约了在交警队碰面,我路上就报了保险.去了之后查监控,出责任认定书一同搞下来,大概情况如下:

    对方 76 岁女性,退休没啥钱,开个体理发店的,手痛了几天一直没见好,去医院拍片发现骨折了.
     
    现在手又痛,班也不能上(春节正是做头发人多的时候),觉得需要误工费,就又找上我了.
    

    我没啥可说的,交警定了全责,我又有保险,那就保险沟通呗.

    之后就是和保险拉了个群,偶尔在微信上听她诉苦,我就搭个话,给些治疗建议啥的.


    转眼就过完年了,一个月过去,手还不见好,并且开始跟保险谈误工费.

    保险的意见:

    1. 你这个年纪,退休了,按道理是没有误工费的.但是考虑实际情况可以给误工费.
    2. 骨折的是掌骨,不是手指,按法律规定最多 3 个月误工.

    综合算下来给了个 1w 的赔偿额.结果对方想要 4-5 万....


    于是约了在交警大队的调解室去调解.

    调解员的意见跟保险一致,甚至很诧异保险居然在没调研她工作环境的情况下就给出了 1w 误工费的条件.

    这里说下她的工作情况,最令人头大的地方,因为完全无法证明她的收入:

    个体理发店,客户大多是附近的中老年熟客,收费几乎全是现金,有个小本本记账,有营业执照但没有交税.
    

    调解员说按照当地服务业标准,140/天的误工费.
    她当场就炸毛了.说平时一个月都是 6000-7000,春节上万都有.家里还有 90 多的父亲,儿子也生活压力大.

    于是调解员让我们找诉前调解室去,看看能不能通过诉讼解决.


    诉前调解是个男的,直接问诉求:"你要多少啊?"
    "2,3 万吧"
    调解员:"2 万和 3 万隔了 1 万呢,你说精确点.或者 1 万 8 行不行?行我就去跟保险说"
    "行吧"
    结果调解员出去回来:"保险那边 1 万 8 都给不了,只能给 1 万 3."

    然后就散了.


    我的感受:

    1. 我不想出钱,毕竟买了保险.但是私了的钱我也没打算要回来.
    2. 看病随便看,该咋检查就咋检查,保险都会报销.
    3. 她期望的误工费怕是很难拿到了,收入受影响是事实.

    然后我给她查了上诉流程,介绍了附近的律师事务所.希望能多争取一点误工费.毕竟保险公司还得听法官的不是.

    当然重点是:要带上我的保险公司(太平洋保险)一起告.


    教别人告自己,也是头一遭了...

    闲下来一直在想,到底是哪里的问题呢.

    对我:虽然是全责,但是该道歉就道歉,该慰问就慰问,只是金钱方面,我交给保险公司.
    对保险公司:付款需要有凭据,医疗费有发票,误工费则是要合法合规.
    对受害者:无妄之灾,不仅身体受到伤害,赔偿也不足以弥补对工作的影响.

    手持越狱版的 iPhone14 ,电量 80%了,估计等不到新版本的越狱了,前天刚下单一台 iqoo15 ,准备试试,正好,听说小米 17 可以无痛 root 了,遂去手机店体验了一把小米 17 和 vivo x300 ,还是使用哔哩哔哩刷视频,结果还是跟以前一样的失望,向上刷视频的时候单击屏幕尝试让页面暂停滑动,使用这两款机器大概率会直接进入视频,而不是暂停滑动,对比之下,iPhone 这边明显好太多了。

    突然想到 ai 很適合處理後事,例如只有一個人維護的網站突然死了怎麼辦,可以拜託 ai 處理,銷毀資料什麼的都做得到

    阿迪达斯对其数据平台的基础设施交付方式进行了全面改革,从集中式的 IaC 模型转向去中心化模式。此次变革将基础设施定义的所有权从中央平台团队转移到按业务域划分的团队,体现了行业向“产品化平台工程”转型的趋势。该转型旨在在治理与自治之间取得平衡,以应对数据平台在多个团队与多种使用场景扩张过程中暴露出的扩展性挑战。

     

    在原有模式下,单一的平台工程团队负责 IaC 仓库、管理部署流水线,并在整个组织内执行统一标准。这种集中式结构在早期增长阶段确保了一致性与合规性。然而,随着多个领域团队陆续接入平台,请求数量不断增加,待处理积压逐渐扩大,团队间的协调也带来了额外开销。工程师们指出,这种限制源自交付模型本身,而非底层工具问题。

     

    Jose Moreno强调:

    核心问题在于交付模型本身——它已无法支撑组织当前所需的速度与自治程度。

     

    为解决这些约束,阿迪达斯数据平台团队重新定义了基础设施的交付方式以及交付主体。新的运营模式将责任下放给领域团队,使其能够在预定义边界和标准化模式下,自主创建与管理基础设施。平台工程师不再执行具体的基础设施变更,而是转向维护可复用的构建模块、工具框架和治理策略,以支持自治式交付。

     

    此次重构引入了分层的 IaC 结构:可复用模块封装资源定义;“栈”将模块组合为可部署单元;消费配置则引用经批准的栈用于生产部署。这种分层设计在允许非生产环境实验的同时,限制对基础组件的直接修改。在去中心化环境中,明确哪些内容可以修改、由谁修改、在哪个环境中修改,是安全扩展的关键。

    图示:基础设施组件类型及其对应的开发者需求与职责,来源:阿迪达斯博客

     

    团队还开发了一个定制的命令行工具(CLI),用于抽象底层复杂性,并将治理机制嵌入日常工作流程。通过标准化状态管理、强制命名与标签规范,并与持续集成、持续交付(CI/CD)流水线集成,该工具在无需集中式人工审核的情况下实现了一致性保障。自动化的流水线负责部署编排,确保了跨环境的可追溯性与可复现性。

     

    组织结构方面也进行了重新划分与职责明确。框架负责人负责维护共享工具与标准;领域团队中的开发者使用经过批准的模式组合基础设施;使用方通过自动化流水线部署生产配置。职责边界的清晰划分不仅强化了问责机制,也降低了对单一中央团队的依赖。

     

    图示:围绕去中心化基础设施交付的工作模型,来源:阿迪达斯博客

     

    工程师们表示,去中心化显著缓解了中央团队的积压压力,并使多个团队能够独立交付基础设施。这一转型表明,IaC 交付的去中心化不仅是技术变革,更是一种文化与组织层面的重塑,需要共享工具、自动化优先的治理方式,以及清晰的所有权边界。

     

    这一实践也与更广泛的平台工程趋势相契合。越来越多的企业在通过标准化抽象与自动化策略保障运行安全的同时,推动自助式基础设施能力。通过围绕自治团队进行重组,并辅以共享框架与 CI/CD 编排支持,阿迪达斯的数据平台为复杂环境下的基础设施规模化交付提供了一个可借鉴的模式。

     

    原文链接:

    https://www.infoq.com/news/2026/03/adidas-decentralized-platform/

    来自谷歌麻省理工学院的研究人员发表了一篇论文,提出了一个用于扩展多智能体系统的预测框架。该框架揭示了工具使用与系统协同之间存在权衡关系,可用于为特定任务选择最优的智能体架构。

    该扩展模型依赖于系统的多个预测因素,包括底层大语言模型的智能指数、单智能体的基线性能、智能体数量、工具数量以及协调指标。研究人员发现模型中存在三种主导效应:工具‑协调权衡——对工具需求较高的任务,在多智能体带来的开销下表现会更差;能力饱和——当单智能体基线性能超过某一阈值后,增加智能体的收益会逐渐递减;以及拓扑依赖的错误放大——集中式编排能够减轻这种错误放大效应。他们还发现,最优的协调策略取决于任务类型:金融推理任务更适合采用集中式编排,而网页导航任务在分散式策略下表现更佳。在独立测试集上进行评估时,该扩展框架对最优协调策略的预测准确率达到 87%。谷歌表示:

    随着 Gemini 等基础模型的持续进步,我们的研究表明:更智能的模型并不会取代对多智能体系统的需求,反而会加速其发展——前提是采用正确的架构。从启发式方法转向定量原则,我们便能构建出下一代 AI 智能体,它们不仅数量更多,而且更智能、更安全、更高效。

    谷歌团队根据智能体的不同协调方式将多智能体架构分为以下几类:独立式——智能体之间无协调;集中式——智能体仅与中央编排器通信;分散式——点对点协调;混合式——兼顾集中式与分散式。每种架构都包含若干配置参数,如智能体数量、单个智能体的迭代次数等,且在计算复杂度、内存占用与大模型调用次数上各不相同。

    多智能体架构,图片来源:Google Research

    研究人员开发的扩展模型是一个包含 20 项的回归模型,基于 9 个预测变量及其交互项构建。他们剔除了“无明确机制支撑的交互项……以避免过拟合”。谷歌指出,该模型确实存在一定局限性。研究团队特别发现,“工具密集型”任务会导致多智能体协调效率降低,并提出需要“为工具密集型任务设计专门的协调协议”。

    在 Hacker News 上关于这篇论文的讨论中,多位用户分享了他们在多智能体工作流方面的实践经验。一位用户写道:

    我在日常工作中构建了大量智能体工作流。在确定编排策略时,我发现一个非常有效的方法:在规划阶段让智能体给出推荐方案。这种借助智能体自身来提升性能的技术,是我高效运用这项技术的关键。当然,效果因人而异。我主要使用 Claude Code,因此其他模型的效果如何尚不明确。

    多智能体系统的协作与编排策略是当前活跃的研究方向。2025 年,InfoQ 曾报道亚马逊为 Amazon Bedrock 推出的多智能体协作框架,该框架可让专业智能体在主管智能体的协调下协同工作。今年年初,InfoQ 还报道了谷歌发布的多智能体系统八大基础设计模式指南,指南对每种模式给出了详细说明,并附带谷歌智能体开发套件(ADK)的示例代码。

    原文链接:

    https://www.infoq.com/news/2026/03/google-multi-agent/