最近发现一个 AI 提效神器 ——Skills，用它配合 Cursor 开发，我仅用 5 分钟就帮女友做出了一款塔罗牌 H5 APP！在说如何操作之前，我们先大概了解下 Skills 的原理

一、Skills的核心内涵与技术构成

（一）本质界定

Skills 可以理解为给 AI Agent 定制的「专业技能包」，把特定领域的 SOP、操作逻辑封装成可复用的模块，让 AI 能精准掌握某类专业能力，核心目标是实现领域知识与操作流程的标准化传递，使AI Agent按需获取特定场景专业能力。其本质是包含元数据、指令集、辅助资源的结构化知识单元，通过规范化封装将分散专业经验转化为AI Agent可理解执行的“行业SOP能力包”，让 AI 从‘只会调用工具’变成‘懂专业逻辑的执行者

（二）技术构成要素

完整Skill体系由三大核心模块构成，形成闭环能力传递机制：

1. 元数据模块：以SKILL.md或meta.json为载体，涵盖技能名称、适用场景等关键信息约 100 个字符（Token），核心功能是实现技能快速识别与匹配，为AI Agent任务初始化阶段的加载决策提供依据。
2. 指令集模块：以instructions.md为核心载体，包含操作标准流程（SOP）、决策逻辑等专业规范，是领域知识的结构化转化成果，明确AI Agent执行任务的步骤与判断依据。
3. 辅助资源模块：可选扩展组件，涵盖脚本代码、案例库等资源，为AI Agent提供直接技术支撑，实现知识与工具融合，提升执行效率与结果一致性。

和传统的函数调用、API 集成相比，Skills 的核心优势是：不只是 “告诉 AI 能做什么”，更是 “教会 AI 怎么做”，让 AI 理解专业逻辑而非机械执行

二、Skills与传统Prompt Engineering的技术差异

从技术范式看，Skills与传统Prompt Engineering存在本质区别，核心差异体现在知识传递的效率、灵活性与可扩展性上：

1. 知识封装：传统为“一次性灌输”，冗余且复用性差；Skills为“模块化封装”，一次创建可跨场景复用，降低冗余成本。
2. 上下文效率：传统一次性加载所有规则，占用大量令牌且易信息过载；Skills按需加载，提升效率并支持多技能集成。
3. 任务处理：传统面对复杂任务易逻辑断裂，无法整合外部资源；Skills支持多技能组合调用，实现复杂任务全流程转化。
4. 知识迭代：传统更新需逐一修改提示词，维护成本高；Skills为独立模块设计，更新成本低且关联任务可同步受益。

上述差异决定Skills更适配复杂专业场景，可破解传统Prompt Engineering规模化、标准化应用的瓶颈。

三、渐进式披露：Skills的核心技术创新

（一）技术原理与实现机制

Skills能在不增加上下文负担的前提下支撑多复杂技能掌握，核心在于“按需加载”的渐进式披露（Progressive Disclosure）设计，将技能加载分为三阶段，实现知识传递与上下文消耗的动态平衡：

1. 发现阶段（启动初始化）：仅加载所有Skills元数据（约100个令牌/个），构建“技能清单”明确能力边界，最小化初始化上下文负担。
2. 激活阶段（任务匹配时）：匹配任务后加载对应技能指令集，获取操作规范，实现精准加载并避免无关知识干扰。
3. 执行阶段（过程按需加载）：动态加载辅助资源，进一步优化上下文利用效率。

（二）技术优势与价值

渐进式披露机制使Skills具备三大核心优势：

1. 降低令牌消耗：分阶段加载避免资源浪费，支持单次对话集成数十个技能，降低运行成本。
2. 提升执行准确性：聚焦相关知识组件，减少干扰，强化核心逻辑执行精度。
3. 增强扩展性：模块化设计支持灵活集成新知识，无需重构系统，适配领域知识快速迭代。

四、Cursor Skills

介绍完 Skills 是什么之后，我将使用的是 Cursor 作为我的开发工具。先说明一下，最开始只有 Claude Code 支持 Skills、Codex 紧随其后，口味自己选。

好消息是，Cursor 的 Skills 机制采用了与 Claude Code 几乎完全一致的 SKILL.md 格式。这意味着，你完全不需要从头编写，可以直接将 Claude Code 的生态资源迁移到 Cursor。

（一）Cursor 设置

因为 Cursor 刚支持不久，并且是 Beta 才能使用，所以要进行下面操作

Agent Skills 仅在 Nightly 更新渠道中可用。
要切换更新渠道，打开 Cursor 设置（ Cmd+Shift+J ），选择 Beta，然后将更新渠道设置为 Nightly。更新完成后，你可能需要重新启动 Cursor。 如下图所示

要启用或禁用 Agent Skills：

1. 打开 Cursor Settings → Rules
2. 找到 Import Settings 部分
3. 切换 Agent Skills 开关将其开启或关闭 如下图所示

（二）复制 Claude Skills

然后我们直接去 Anthropic 官方维护的开源仓库 anthropics/skills，里面提供了大量经过验证的 Skill 范例，涵盖了创意设计、开发技术、文档处理等多个领域。

你可以访问 github.com/anthropics/… 查看完整列表。以下是这次用到的 Skills：

• Frontend Design：这是一个专门用于提升前端设计质量的技能。它包含了一套完整的 UI 设计原则（排版、色彩、布局）

然后我们直接把 Skills 里面的 .claude/skills/frontend-design 到当前项目文件下，如图：

模型和模式如下图

提示词如下，不一定非得用我的。

使用 Skill front-design。我要做一个 H5 ，功能是一个塔罗牌。

你是一名经验丰富的产品设计专家和资深前端专家，擅长UI构图与前端页面还原。现在请你帮我完成这个塔罗牌应用的 UI/UX 原型图设计。请输出一个包含所有设计页面的完整HTML文件，用于展示完整UI界面。

注意：生成代码的时候请一步一步执行，避免单步任务过大，时间执行过长

然后 Cursor 会自动学习 Skills，并输出代码

然后就漫长的等待之后，Cursor 会自动做一个需求技术文档，然后会一步一步的实现出来，这时候可以去喝杯茶，再去上个厕所！

最终输出了 5 个页面

1. 首页 (Home)
2. 每日抽牌页 (Daily Draw)
3. 牌阵占卜页 (Spread Reading)
4. 塔罗百科页 (Encyclopedia)
5. 占卜历史页 (History)

最终效果如下,整体效果看起来，完全是一个成熟的前端工程师的水准，甚至还带有过渡动画和背景效。因为掘金无法上传视频，欢迎私信我找我要或者关注我：

扩展阅读

因为 Cursor 目前仅在 Nightly 版本上才可以使用 Skills。如果担心切换此模式会引发意想不到的情况，可以使用另一种方案

OpenSkills 是一个开源的通用技能加载器。

• 完全兼容：它原生支持 Anthropic 官方 Skill 格式，可以直接使用 Claude 官方市场或社区开发的技能。
• 桥梁作用：它通过简单的命令行操作，将这些技能转换为 Cursor、Windsurf 等工具可识别的配置（AGENTS.md），从而让 Cursor 具备与 Claude Code 同等的“思考”与“技能调用”能力。

Incremark 现已支持 Solid，至此完成了对 Vue、React、Svelte、Solid 四大主流前端框架的全面覆盖。

为什么要做框架无关

市面上大多数 Markdown 渲染库都是针对特定框架开发的。这带来几个问题：

1. 重复造轮子：每个框架社区都在独立实现相似的功能
2. 能力不一致：不同框架的实现质量参差不齐
3. 团队切换成本：换框架意味着重新学习新的 API

Incremark 采用不同的思路：核心逻辑与 UI 框架完全解耦。

@incremark/core 负责所有解析、转换、增量更新的工作，输出的是框架无关的数据结构。各框架包（@incremark/vue、@incremark/react、@incremark/svelte、@incremark/solid）只需要把这些数据渲染成对应框架的组件即可。

这意味着：

• 核心能力一次实现，四个框架同时受益
• Bug 修复和性能优化自动同步到所有框架
• API 设计保持高度一致，切换框架几乎零学习成本

包结构

┌───────────────────────────────┐
│       @incremark/core         │
│                               │
│  增量解析 · 双引擎 · 插件系统  │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│  @incremark/vue               │
│  @incremark/react             │
│  @incremark/svelte            │
│  @incremark/solid  ← NEW      │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│       @incremark/theme        │
│                               │
│     样式 · 主题 · 代码高亮     │
└───────────────────────────────┘

增量解析

传统 Markdown 渲染器在流式场景下存在性能问题：每次新内容到达都要重新解析整个文档，复杂度是 O(n²)。

Incremark 只处理新增内容，已解析的块不再重复处理，复杂度降至 O(n)。

四个框架的用法对比

四个框架的组件 API 完全一致，只是语法风格不同：

Vue

<script setup>
import { IncremarkContent } from '@incremark/vue'
// ...
</script>

<template>
  <IncremarkContent :content="content" :is-finished="isFinished" />
</template>

React

import { IncremarkContent } from '@incremark/react'
// ...

<IncremarkContent content={content} isFinished={isFinished} />

Svelte

<script>
import { IncremarkContent } from '@incremark/svelte'
// ...
</script>

<IncremarkContent content={content} isFinished={isFinished} />

Solid

import { IncremarkContent } from '@incremark/solid'
// ...

<IncremarkContent content={content()} isFinished={isFinished()} />

可以看到，除了各框架本身的响应式语法差异（Vue 的 ref、React 的 useState、Svelte 的 $state、Solid 的 createSignal），组件的使用方式完全统一。

在线演示

• Solid Demo
• Vue Demo
• React Demo
• Svelte Demo

链接

• npm: @incremark/core
• 文档: incremark.com
• GitHub: github.com/anthropics/…

MIT 许可证。

本文字数1400+ ，阅读时间大约需要 4分钟。

【掘金一周】本期亮点：

• 高德地图与Three.js结合实现3D大屏可视化
• 老王请假、客户开喷、我救火：一场递归树的性能突围战
• 一杯茶时间带你基于 Yjs 和 reactflow 构建协同流程图编辑器 😍😍😍
• RocketMQ高性能揭秘：承载万亿级流量的架构奥秘｜得物技术
• 性能提升 4000%！我是如何解决 运营看板 不能跨库&跨库查询慢这个难题的
• Android 12 SplashScreen 一种另类的适配方案
• Android Profiler实战宝典：揪出CPU耗时元凶与内存泄露小偷
• iOS疑难Crash-_dispatch_barrier_waiter_redirect_or_wake 崩溃治理
• Flutter 3.38.1 之后，因为某些框架低级错误导致提交 Store 被拒

「上榜规则」：文章发布时间在本期「掘金一周」发布时间的前一周内；且符合各个栏目的内容定位和要求。 如发现文章有抄袭、洗稿等违反社区规则的行为，将取消当期及后续上榜资格。

一周“金”选

内容评审们会在过去的一周内对社区深度技术好文进行挖掘和筛选，优质的技术文章有机会出现在下方榜单中，排名不分先后。

前端

高德地图与Three.js结合实现3D大屏可视化 @孙_华鹏

通过高德地图与Three.js的深度结合，我们成功实现了3D模型在地图上的实时展示和动画效果，并集成了AI大模型实现智能安全隐患检测。

老王请假、客户开喷、我救火：一场递归树的性能突围战 @不一样的少年_

刚接手时，看着那密密麻麻的代码和满屏的红色 Long Task，心里确实有点发怵。但静下心来，用 Performance 面板这把“手术刀”切下去，病灶其实很清晰：无节制的 DOM 操作 和 昂贵的重排开销。

一杯茶时间带你基于 Yjs 和 reactflow 构建协同流程图编辑器 😍😍😍 @Moment_

通过这个案例，我们不仅学会了如何构建协同应用，更重要的是理解了协同编辑的核心思想：通过 CRDT 算法保证最终一致性，通过增量同步减少网络传输，通过 Awareness 实现实时协作体验。

半年一百个页面，重构系统也重构了我对前端工作的理解 @纸上的彩虹

作为前端开发者我们用着同样的计算机语言，却身处完全不同的业务场景下，重构代码的同时思考如何提升用户的使用体验，才是我们作为前端研发的价值体现。

后端

RocketMQ高性能揭秘：承载万亿级流量的架构奥秘｜得物技术 @得物技术

RocketMQ作为一款高性能、高可用的分布式消息中间件，其核心架构采用了经典的四组件协同设计，实现了消息生产、存储、路由与消费的全链路解耦与高效协同。

性能提升 4000%！我是如何解决 运营看板 不能跨库&跨库查询慢这个难题的 @也无风雨也雾晴

数据库隔离的好处大家都知道：服务独立部署、故障隔离、技术栈灵活。 但有个现实问题：运营报表需要聚合多个库的数据。比如我们要做一个消息评价看板，评价数据在业务库，用户名在用户库，需要 JOIN 才能出报表。

Android

Android 12 SplashScreen 一种另类的适配方案 @Android轮子哥

系统读取 App 主题的时候，是通过读取 xml 文件来获取属性的，在这种情况下，低版本并不会去读取高版本的属性，因为它压根不知道有这几个属性，所以不会有任何问题，经过验证也确实如此。

Android Profiler实战宝典：揪出CPU耗时元凶与内存泄露小偷 @顾林海

Android Profiler是通过与设备的ART虚拟机交互，采集进程的运行数据（比如线程状态、内存分配、函数调用耗时等），然后通过可视化的方式展示给我们。就像医生给病人测心电图、血压，通过数据波动判断身体状况，我们通过Profiler的曲线波动和详细数据，判断APP的性能问题。

IOS

iOS疑难Crash-_dispatch_barrier_waiter_redirect_or_wake 崩溃治理 @货拉拉技术

既然原因锁定在这些安全类里面的通过并行队列来实现的读写锁逻辑，那最好的解决方案就是替换掉这些安全类里面的读写锁逻辑，使用pthread_rwlock_t来代替并行队列实现读写锁功能, 这样就避免了队列提前释放的风险。

Flutter 3.38.1 之后，因为某些框架低级错误导致提交 Store 被拒 @恋猫de小郭

如果你近期已经升级到 3.38.1 之后的版本，包括 3.38.5 ，你就有概率发现，打包提交 iOS 的包会出现 The binary is invalid 的相关错误，简单来说，就是App Store 拒绝了某个二进制文件，因为它包含了无效的内容。

活动日历

活动名称	活动时间
🏆2025 AI/Vibe Coding 对我的影响 年终征文	2025年12月26日-2026年1月25日

📖 投稿专区

大家可以在评论区推荐认为不错的文章，并附上链接和推荐理由，有机会呈现在下一期。文章创建日期必须在下期掘金一周发布前一周以内；可以推荐自己的文章、也可以推荐他人的文章。

Incremark: 增量式 Markdown 解析器，专为 AI 流式输出设计，极致性能体验。 增量解析，流式友好精确边界检测，精确边界检测，框架无关，高度可定制，SSR 友好，支持国际化与无障碍

目的与范围

本文档描述了 VTJ.PRO 平台的前端架构，涵盖五个不同的 HTML 入口点、它们的初始化流程以及如何与 @vtj/renderer 引擎集成。前端设计为一个多上下文系统，每个入口点服务于特定目的：主应用（管理后台和工作台）、平台运行时（Web、H5、UniApp）、开发环境和独立项目模板。

有关特定路由配置的信息，请参阅路由系统。有关 VTJ 渲染器页面渲染过程的详细信息，请参阅多平台运行时系统。有关后端模块架构的信息，请参阅后端模块系统。

架构概述

前端包含五个架构上下文，每个上下文都有自己的入口点和初始化逻辑：

入口点对比

每个入口点服务于不同的目的并具有不同的初始化要求：

入口点	HTML 文件	主脚本	用途	路由模式	访问控制	VTJ 提供者
主应用	frontend/index.html	src/main.ts	管理后台、工作台、认证页面	Hash 或 History	是（含白名单）	否
Web 运行时	frontend/web/index.html	src/platform/web/main.ts	部署 Web 应用程序	Hash	是（运行时模式）	是
H5 运行时	frontend/h5/index.html	src/platform/h5/main.ts	部署 H5 应用程序	Hash	是（运行时模式）	是
开发环境	frontend/dev/index.html	src/platform/dev/main.ts	应用/模板设计器	Hash	是	否（由设计器添加）
认证流程	frontend/auth.html	src/auth.ts	独立认证流程	Hash 或 History	是	否

主应用架构

主应用入口点服务于三个主要上下文：管理后台、工作台和认证页面。

初始化流程

路由结构

主应用定义了三个布局上下文及其相应的路由：

访问控制集成

主应用使用基于白名单的访问控制系统：

• whiteList 函数：对路径 ['/login', '/unauthorized', '/register', '/password'] 返回 true
• unauthorized 行为：设置为 undefined，允许自定义处理
• 存储键：来自共享配置的 STORAGE_KEY
• 私钥：用于令牌加密的 ACCESS_PRIVATE_KEY

平台运行时架构

Web、H5 和 UniApp 平台运行时共享通用的架构模式，但在平台特定实现上有所不同。

运行时初始化流程

提供者配置

createProvider() 函数使用平台特定配置调用：

Web 平台配置

createProvider({
  nodeEnv: preview ? NodeEnv.Development : NodeEnv.Production,
  mode: ContextMode.Runtime,
  service,
  project: {
    id: code,
    platform: AppPlatform.Web
  },
  materialPath: MATERIAL_PATH,
  dependencies: {
    Vue: () => import('vue'),
    VueRouter: () => import('vue-router'),
    Pinia: () => import('pinia')
  },
  router,
  enableStaticRoute: true,
  routeAppendTo: ROUTER_APPEND_TO,
  adapter: {
    notify,
    loading,
    alert,
    useTitle
  }
});

H5 平台配置：

• 与 Web 几乎相同，平台参数为：AppPlatform.H5
• 使用移动端优化的适配器函数

UniApp 平台配置：

• 不包含 router 或 routeAppendTo（路由由 UniApp 框架处理）
• 使用 @vtj/uni 处理平台特定组件
• 需要通过 setupUniApp() 进行特殊初始化

平台路由

平台运行时使用最小化路由，因为页面由 VTJ 渲染器动态创建：

Web/H5 路由器：

createRouter({
  history: createWebHashHistory(),
  routes: [
    {
      path: '/',
      component: Page,
      name: ROUTER_APPEND_TO // 渲染器将路由追加到这里
    },
    {
      path: '/:pathMatch(.*)*',
      name: 'NotFound',
      component: NotFound
    }
  ]
});

支持的 URL 模式：

• 生产环境：/web/:code/#/page/:fileId
• 预览环境：/web/:code/preview/#/page/:fileId
• 版本环境：/web/:code/version/:versionId/#/page/:fileId

上下文模式

平台运行时使用不同的上下文模式：

模式	值	使用场景	描述
运行时	ContextMode.Runtime	Web/H5/UniApp 平台	部署应用程序的生产运行时
开发环境	NodeEnv.Development	预览模式 (preview=true)	启用开发功能
生产环境	NodeEnv.Production	生产部署	优化的运行时

开发环境架构

开发环境提供用于创建和编辑应用程序和模板的设计器界面。

设计器路由

设计器初始化

设计器 URL 模式

设计器支持平台特定的 URL：

• Web 应用开发：/dev/web/#/app/:code?id=xxx
• H5 应用开发：/dev/h5/#/app/:code?id=xxx
• UniApp 应用开发：/dev/uniapp/#/app/:code?id=xxx
• Web 模板开发：/dev/web/#/template/:id
• H5 模板开发：/dev/h5/#/template/:id
• UniApp 模板开发：/dev/uniapp/#/template/:id

项目模板架构

templates/ 目录包含可以独立生成和使用的独立项目模板。

模板类型

系统提供三种模板类型：

模板初始化模式

所有模板都遵循使用 LocalService 的类似初始化模式：

Web 模板：

const app = createApp(App);
const adapter = createAdapter({ loading, notify, Startup, useTitle });
const service = new LocalService(createServiceRequest(notify));
const { provider, onReady } = createProvider({
  nodeEnv: process.env.NODE_ENV as NodeEnv,
  mode: ContextMode.Raw,
  modules: createModules(),
  adapter,
  service,
  router,
  dependencies: {
    Vue: () => import('vue'),
    VueRouter: () => import('vue-router'),
    Pinia: () => import('pinia'),
    VueI18n: () => import('vue-i18n')
  },
  project: {
    id: vtj?.id || name
  },
  enableStaticRoute: true
});

与平台运行时的关键区别：

• 使用 LocalService 而不是远程服务
• 模式为 ContextMode.Raw（非 ContextMode.Runtime）
• 包含模块：createModules() 用于本地模块定义
• 项目 ID 来自 package.json（vtj.id 或 name）
• 在生产环境中启用自动更新

模板路由配置

模板使用最小化路由，因为 VTJ 提供者管理页面路由：

Web/H5 模板路由器：

createRouter({
  history: createWebHashHistory(),
  routes: [
    {
      path: '/unauthorized',
      name: 'Unauthorized',
      component: () => import('@/views/unauthorized.vue')
    },
    {
      path: '/:pathMatch(.*)*',
      name: 'NotFound',
      component: () => import('@/views/not-found.vue')
    }
  ]
});

共享基础设施

前端在所有入口点使用共享的基础设施组件。

服务层

访问控制系统

来自 @vtj/renderer 的访问控制系统在所有入口点进行配置：

配置参数：

• alert：用于显示消息的警告函数
• storageKey：localStorage 令牌存储的键（STORAGE_KEY）
• privateKey：令牌加密的密钥（ACCESS_PRIVATE_KEY）
• whiteList：确定公共路由的函数（仅主应用）
• unauthorized：自定义重定向行为

连接方法：

• connect({ request, router, mode })：将访问控制连接到路由器和请求处理器
• 模式选项：ContextMode.Runtime（平台运行时）或 undefined（主应用）

TypeScript 配置

所有前端上下文共享类似的 TypeScript 声明：

Vue 组件类型增强：

declare module 'vue' {
  interface ComponentCustomProperties {
    $uploader: any;
    $reqeust: any;
    $apis: any;
    $libs: any;
  }
}

这些全局属性由 VTJ 渲染器注入，在所有 Vue 组件中可用。

依赖管理

前端使用动态导入核心依赖以实现代码分割：

提供者依赖

平台运行时和模板为 VTJ 提供者配置依赖：

Web/H5 平台依赖：

dependencies: {
  Vue: () => import('vue'),
  VueRouter: () => import('vue-router'),
  Pinia: () => import('pinia')
}

模板依赖：

dependencies: {
  Vue: () => import('vue'),
  VueRouter: () => import('vue-router'),
  Pinia: () => import('pinia'),
  VueI18n: () => import('vue-i18n')
}

UniApp 依赖：

dependencies: {
  VueI18n: async () => VueI18n;
}

目的：这些懒加载的依赖允许 VTJ 渲染器使用与宿主应用程序相同的版本，防止版本冲突。

平台特定适配器

每个平台提供用于平台特定 UI 操作的适配器函数：

适配器接口

总结

VTJ.PRO 前端架构设计为一个多上下文系统，具有五个不同的入口点：

• 主应用：具有全面路由和访问控制的管理后台和工作台
• Web/H5 平台：使用 @vtj/renderer 部署应用程序的运行时环境
• UniApp 平台：具有特殊初始化的跨平台移动运行时
• 开发环境：用于构建应用程序和模板的设计器界面
• 项目模板：使用 LocalService 的独立启动项目

所有上下文共享通用基础设施（服务层、访问控制、TypeScript 配置），同时保持平台特定的实现。VTJ 渲染器（@vtj/renderer）作为核心渲染引擎，在所有平台上将 DSL 定义转换为功能性的 Vue 应用程序。

VTJ.PRO引擎源码仓库：gitee.com/newgateway/…

在过去的几年中，AI 始终占据着科技界最耀眼的 C 位。但站在 2026 年的起点回看，我发现一个显著的转折：从 2025 年末开始，人们对“万亿参数”或“榜单跑分”的狂热逐渐褪去，取而代之的是对

本期共有 39 个项目，包含 C 项目 (2)，C# 项目 (3)，C++ 项目 (1)，Go 项目 (4)，Java 项目 (2)，JavaScript 项目 (5)，Kotlin 项目 (2)，PHP 项目 (1)，Python 项目 (5)，Rust 项目 (2)，Swift 项目 (1)，人工智能 (5)，其它 (6)

岁末年初，朋友圈又开始了年度报告的大赛。各个平台都拿出了各种设计、交互、数据，势必要占领你的朋友圈。

拜托，现在 AI 已经这么好用了，为什么不能自己做一个呢？尤其是这一年，有大量的时间正是花在这些 AI 工具里。

没想到，这一个小小的念头，引发了一场我在 AI studio 里埋头苦干了两天，先后完成了两个版本：一个是基于静态和简单互动的「传统版」。

另一个是具备动态效果、可无限缩放、结合 3D 粒子和互动的「技能版」。

更没想到的是，整个经过改变了以往我对与 AI 协作互助的理解：万能咒语什么的不存在的，真正的魔法武器只有一个。

自己做一个技能版「年终总结」

在开始之前，先准备好你最常用的 AI chatbot——一定要是最常用的，几乎每天都要聊个两句的那种。数据不够不仅做不了有意思的总结，还可能被硬塞不存在的数据。

我准备的是 ChatGPT，直接起一个新窗口，输入以下 prompt：

请基于这一年的对话内容，从“数量、主题、时间、情绪、使用习惯、人格特征”等维度，构建数据感的总结，包含模拟数据以及 ASCII 图表，请严格按以下结构生成：
【1. 年度总览】
今年与 GPT 的总互动次数
发送消息总字数 + 接收消息总字数
最常互动的时段
最长连续对话时长
【2. 互动类型分布（饼图）】
请用 ASCII 图展示：
情感类、讨论类、创作类、学习类、角色扮演类、其他类
【3. 高频主题排行（TOP 10）】
以排行榜形式展示，并给每个主题一句点评。
【4. 我的年度情绪轨迹（线形图）】
模拟分析我在对话中的情绪曲线
【5. 用户行为画像（雷达图）】
雷达图维度包括：
好奇心、依赖度、分析深度、 表达欲、情绪敏感度、 自我剖析频率
【6. 使用时段与频率（柱状图）】
柱状图展示我全年最常用来找 GPT 的时间段： 凌晨、上午、下午、晚上、深夜
【7. 我的互动习惯标签】
请根据全年模式，为我生成 6-10 个类似“APP 年度画像”的标签。并设计 6 个带名称的年度成就徽章
【8. AI 眼中的我（数据 + 叙事结合）】
结合年度模式，写一段带数据隐喻的：
“我是怎样的人，我的灵魂像什么，我为什么值得这样的总结。”
【9. 年度一句话总结】

总体风格要求：
数据可视化 + 年度回顾混合风， 图表使用 ASCII，可视化要清晰、好看、易读，文案具有科技感、沉浸感、叙事感，避免大众化套话。

这些就是接下来的基础素材了，在上述这种 prompt 的指令下，GPT 只会输出纯文本，图也是草草画一画。所以接下来要转移到 Gemini/AI Studio 上去做进一步的排版。

AI Studio 依然是最推荐的地方，除了可以选择更多模型、互动过程更直观，还有一个更重要的原因后面讲。

年终总结里，数据只是素材，更重要的是排版——这一项已经卷出花来了，充分地进入了 AI 的数据库，用几行基础 prompt 就可以实现。

帮我以可交互式 H5 的形式，制作一个年终总结页面。总结文案我将会在下面给出，形式要求：1. 可交互式，交付可本地打开的 html 网页 2. 根据文案内容拆分版块，在需要使用图表的部分制作图表 3. 版式要求：文字使用衬线体，背景色彩可以自主调节。总结文案如下：（补充你的文案）

很多人抱怨， AI 生成的视觉图表有一股廉价的「塑料感」，效果不坏，但也说不上好——这就是基础 prompt 的缺点。所以，在制作报告时我直接放弃了使用「大气、高级」这类模糊的形容词。AI 听不懂这些，它只能精准执行参数，拆分成一步步会更加有效。

比如，为了达到最终那种深邃优雅的视觉效果，我将需求拆解成了具体的描述：背景为深紫色渐变与暗灰色的色块晕染，晕染效果随机变化——具体的颜色、形态，而非空洞的叙述「大气」「高级」，AI 弄不明白的。

类似的，微调图表时，也要尽可能的具体：雷达图需要呈现出磨砂玻璃般的半透明质感。

加入交互时，描述你想要实现的效果——尽可能地细致，比如：将「年度十大主题」按照十宫格排列，点击来使每一个格子反转，文案始终置于居中位置。

这种调校的过程，本质上是在用你的审美，去 battle AI 的执行效率。不过，现在 Gemini 的审美远比我想象的要好，比如我提了一个多出几个配色的要求，它给出的三种配色都还不错。

隐藏武器：「回滚」

做传统的年终总结，整体过程比较像和设计师合作，这里改改颜色、哪里换个版式。但「技能年终总结」，就是和工程师合作了。

在重新研究了一遍 GPT 给出的文字总结后，我第一时间想到的是和网上流行的圣诞树做结合。

但是在对比之后，发现年终总结高度格式化的章节、数字，并不适合用圣诞树这样的形式去呈现。所以我先是参考圣诞树的设计 prompt，但把主体改为了结构更清晰的雪花结晶。prompt 如下：

角色设定：你是一位精通 React 19、TypeScript 和 Three.js (R3F) 的 3D 创意开发专家。 任务目标： 构建一个名为“圣诞雪花”的高保真 3D Web 应用。视觉风格主色调为深祖母绿和高光金色，并伴有电影级的辉光效果。 技术栈： React 19, TypeScript, React Three Fiber, Drei, Postprocessing, Tailwind CSS。

雪花结晶体的结构可以更清晰的展示出节点，这样，就可以用红宝石不同的年度总结板块。点击时，散落在夜空中的粒子和红宝石，共同组成了一朵雪花——就像一个个重要的事件、习惯、统计数字，构成了这一整年。

然后就是漫长……漫长……漫长……的修改流程。在我的预想里，每一个红宝石封装了一部分内容，一次性把完整的总结文案喂进去是行不通的。这也是很多人写 prompt 时的「毛病」，喜欢一下子把所有需求堆上去，结果 AI 给的代码往往漏洞百出。这边给到的一个建议是： 先定骨架，再调动作。比如一个雪花的动效，我分了三步：

第一步： 先让它把雪花的 3D 形状写出来，只要形状对了，先下载一个版本，你可以在这里找到下载按钮。

第二步： 让它加上自转和红宝石节点，不急着塞内容，只是把几个节点改成红宝石的形状。

第三步： 最后才去磨那个点击缩放的逻辑，放大时是什么效果、要不要加返回键……

每一步只要达成预期，就别乱动。一旦发现没有效果，让 Gemini 自行 debug 也无效的话，启动武器：

这是我做这个项目时最重大的发现：回滚。功能越复杂，需求越多，AI 越容易出错。完成一个新需求的时候，无法避免要「重新生成」一些东西，所以整个代码的其它地方本来是没问题的，改完却出现新的 bug。

结果就是，越在错误的代码上缝缝补补，加的补丁越多，bug 就出现得越多。所谓「按下葫芦浮起瓢」，是最劝退的一步。

所以，效率最高的做法是，当你发现 AI 为了加一个新功能（比如换个颜色），把之前已经调好的交互逻辑给「洗」掉时，不必执着于在对话框里跟它吵架，让它「改回来」。最快的方法是直接回退到上一个版本，再输入新指令——记住，你是指挥官，它是执行者，AI 乱了，你要把它拉回到正确的轨道上。

 

这对零码选手尤其有意义，作为一个很少去翻看冗长代码、只看预览效果的普通用户，这就是最简单粗暴的「咒语」：别去纠结它哪行代码写错了，直接回滚。

这个项目里我的整个工程一度崩溃过：中间我提出，「优化一下红宝石的材质，让它看起来更透亮」，看代码预览 Gemini 是在跑，但是回到预览页却没有一丝变化。

一运行，材质没有大变化，点击缩放的功能还给废了。AI 在重写材质代码时，顺手把我调了一下午的点击交互给抹掉了。这种时候，在对话框里跟它大发雷霆其实没有用，提出「缩放功能没有了补回去」，也很容易卡死，AI 会一边道歉一边给你补一个更烂的 Bug。

与其纠结，不如一键 restore，回滚到那个「材质虽丑但交互正常」的版本，这种对预览效果的「死守」，比任何高级 prompt 都管用。

不过要注意的是，回滚只有上一个版本，更远一点的版本是不支持的。可以把它理解为「退回到上一步」，类似 Ctrl+Z 这样的操作。

到了后面，我的想法越来越被耗尽，所幸让 Gemini 自主完成一些设计工作。在整体视觉已经完全确定的情况下，它的发挥其实还不错。比如这个年度成就徽章「英灵殿」，就是完全由它设计的。

鼠标悬停即展示具体的成就名称，也是 Gemini 想出来的主意。另一张统计里，它还自己画上了心跳图。

最后一颗宝石里装载的是「一句话」总结，Gemini 把最后这颗宝石改成了白色的锥型晶体，跟其它的红宝石区别开来。

在制作这篇年终总结时，我被问到最多的问题是：「Prompt 是什么？」

也不意外，AI 用到现在，这已经成了大家下意识就要问的问题。但是说句掏心窝子的话，真的没有什么一键成型的魔法咒语。

每个人的 2025 都是独一无二的，每个人想要通过 AI 记录的转折点、战绩和情绪也都不一样。你喜欢一棵挂满礼物的圣诞树，而我喜欢这片在星空中转动的雪花。每个人都有自己的审美偏好，而 AI 最大的魅力，绝不是让你能复制出一份和我一模一样的报告。

相反，AI 最大的意义是：它第一次抹平了「想得到」与「做出来」之间的鸿沟。 以前你受限于不会代码、不会设计，只能接受千篇一律的模板；而现在，只要你愿意花点时间去跟它「死磕」，去描述你脑海中那个具体的画面，AI 就能帮你把那个只属于你的世界折叠出来。

Prompt 是冷的，但你的记忆和审美是有温度的。

如果非要总结出一个公式，那可能就是：一点点想象力 + 几十次耐心回退 + 绝不向平庸效果妥协的审美。

别再到处找「万能指令」了。新的一年，试着去跟 AI 聊聊天，去「嫌弃」它的平庸，去坚持你的直觉。你会发现，正如同每一年里不停止的自我更新和挑战，对这一年最好的总结，恰恰就是你不断推倒重来的过程本身。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

导读

本文深入介绍了百度一站式全业务智能结算中台，其作为公司财务体系核心，支撑多业务线精准分润与资金流转。中台采用通用化、标准化设计，支持广告、补贴、订单等多种结算模式，实现周结与月结灵活管理。通过业务流程标准化、分润模型通用化及账单测算自动化，大幅提升结算效率与准确性，确保数据合规与业务稳健发展。未来，中台将推进全业务线结算立项线上化、数据智能分析，进一步提升数据分析智能化水平，为公司业务发展提供坚实保障。

01 概述

结算中台作为公司财务体系的核心组成部分，承担着多业务线分润计算、结算及资金流转的关键职能。采用通用化、标准化的设计理念，结算中台能够高效支撑公司内数十个业务线的分润需求，确保广告收入、订单收入、内容分发的精准结算，为公司的财务健康与业务稳健发展提供坚实保障。结算中台建设的核心目标是: 构建高效、标准化、智能化的结算中台体系，支撑多业务线分润计算与资金流转，确保结算数据准确性、高时效披露及业务快速迭代能力，同时降低运维复杂度，推动全业务线结算线上化管理。

结算中台已对接了百家号业务、搜索业务、智能体业务、小说等多个业务线的结算需求， 支持广告分润、补贴分润、订单分润三种结算模式。不同业务线根据各自的业务场景使用不同的结算模式，确保每个业务的收益分配准确无误。结算中台功能分层如图：

02 基本功能

1. 结算模式

结算中台支持三种结算模式，以适应不同业务场景的结算需求：

• 订单结算：基于直接订单数据，按照订单实际金额与分成策略进行分润计算。

• 补贴结算：针对特定业务或用户群体，提供额外的收益补贴，以增强业务的市场竞争力。

• 广告结算：根据分发内容的广告变现与渠道分成比例，精确计算媒体与内容的实际收益。

2. 结算能力

结算中台支持周结与月结两种结算能力：

• 周结：适用于需要快速资金回笼的业务场景,比如短剧快速回款以后能够再次用于投流, 确保资金流转的高效性。

• 月结：作为默认的结算周期，便于公司进行统一的财务管理与账务处理。

3. 账单测算自动化

结算中台支持重点业务账单自动测算，通过预设的分润模型，自动计算每个渠道、每位作者的应得收益，生成测算报告。这一自动化过程显著提升工作效率，减少人为错误，确保结算数据的绝对准确。

03 需求分析

在推进公司结算业务时，我们致力于实现统一化、标准化，规范业务流程，并确保数据合规化治理，我们面临着诸多问题与挑战，具体表现如下：

1. 流程与规范缺失

• 结算流程管理混乱：存在结算需求未备案即已上线的情况，或者备案内容与实际实现不一致，甚至缺乏备案流程。

• 日志规范陈旧：广告分润场景中，内容日志打点冗余，同时缺少扩展性，导致对新的业务场景无法很好兼容。

2. 烟囱式开发成本高

• 标准化与统一化需求迫切：之前，各个结算业务维护各自的结算系统，涉及不同的技术栈和结算模型，线下、线上结算方式并存，导致人工处理环节多，易出错，case多，管理难度大。为提高效率，需实现结算业务的标准化与统一化，并拓展支持多种业务结算模式。

• 分润模型通用化设计：多数业务结算方式相同，同时账单计算逻辑也相似或者相同，没有必要每个业务设计一套逻辑，需要做通用化设计。

3. 业务迭代中的新诉求

• 测算系统需求凸显：在业务快速迭代的过程中，许多业务希望尽快看到结算效果，以推进项目落地。因此，构建高效的测算系统成为迫切需求，以加速业务迭代和决策过程。

• 提升作者体验：为提升作者等合作伙伴的满意度和忠诚度，结算数据需实现高时效披露，确保他们能及时、准确地获取收益信息。结算账单数据的产出依赖百余条数据源，要保证数据在每天12点前产出,困难重重

• 数据校验与监控机制：结算数据的准确性和质量直接关系到公司的财务健康和业务发展。因此，需建立完善的数据校验和监控机制，确保结算数据的准确无误和高质量。

04 技术实现

根据结算中台建设的核心目标，结合业务痛点，在结算系统建设中，基于通用化、标准化的理念，从以下五个方面来搭建统一的、规范化的结算中台。

• 业务流程标准化：建设一套标准来定义三类结算模式下每个数据处理环节的实现方式，包括业务处理流程、数据处理过程。

• 分润模型通用化：实现不同的账单计算算法，支持各个业务的各类作者收入分配诉求，并且实现参数配置线上化。

• 技术架构统一：统一整个结算业务的技术栈、部署环境、功能入口和数据出口。

• 建设账单测算能力：模拟线上结算流程的账单测算能力，支持业务快速验证分润模型参数调整带来的作者收入影响效果。

• 建设质量保证体系：建设全流程预警机制，通过日志质检、自动对账、数据异常检测来保障账单产出数据时效性、准确性。

1. 业务流程标准化

不同业务场景，采用了通用化、标准化的设计来满足业务的特异性需求，下面是三大结算模式业务流程简图：

在广告模式、补贴模式、订单模式结算流程设计中, 从日志打点、线上化、计算逻辑等方向考虑了通用化、标准化设计, 具体如下:

(1) 日志打点统一化

统一日志标准, 针对业务日志规范陈旧问题，要求所有接入的业务方严格按照统一格式打点日志，删除冗余字段, 确保数据的规范性与一致性,同时保证设计能够覆盖所有业务场景，为后续处理奠定坚实基础。

针对某些业务定制化的需求, 在广告模式、补贴模式、订单模式三种结算方式中，在设计日志打点规范时, 会预留一些扩展字段, 使用时以 JSON 形式表示, 不使用时打默认值。

(2) 账单计算线上化

在补贴结算模式中，之前不同业务都有各自的账单格式设计，同时存在离线人工计算账单的非规范化场景，账单无法统一在线计算、存储、监管。新的结算中台的补贴结算模式，将所有离线结算模式，使用统一的账单格式，全部实现线上化结算，实现了业务结算流程规范化。

(3) 账单计算逻辑优化

比如在广告模式中，百家号业务的公域视频、图文、动态场景中，由于收入口径调整，迭代效率要求，不再需要进行广告拼接，所以专门对账单计算流程做了优化调整。不仅满足业务诉求，同时做了通用化设计考虑，保证后续其他业务也可以使用这套流程的同时， 也能兼容旧的业务流程。

广告模式结算流程优化前：

广告模式结算流程优化后：

2. 分润模型通用化

不同业务场景，不同结算对象，有不同的结算诉求，不仅要满足业务形态多样化要求，还要具有灵活性。因此抽取业务共性做通用性设计，同时通过可插拔式设计灵活满足个性化需求。

(1) 基于流量变化模型

以合作站点的优质用户投流方为代表的用户，他们在为百度提供海量数据获得收益的同时，也有自己的诉求，那就是自己内容的收益不能受到其他用户内容的影响。自己优质内容不能被其他用户冲淡，当然自己的低质内容也不会去拉低别人的收益水平。

对于此部分用户我们提供“基于流量变现的分润”策略，简单来说就是，某一篇内容的收益仅仅由它自己内容页面挂载的广告消费折算而来，这样就保证了优质用户投流方收益的相对独立，也促使优质用户产出更加多的内容。

(2) 基于内容分发模型

• 部分作者只关注收益回报: 对百家号的某些作者来说，他们的目的很单纯，他们只关注产出的内容是否获得具有竞争力的收益回报，至于收益怎么来他们并不关心。

• “基于流量变现”策略不妥此时，我们再使用“基于流量变现”的策略的话，就有些不妥，举个极端里的例子，有一个作者比较倒霉，每次分发都没有广告的渲染，那他是不是颗粒无收？这对作者是很不友好的。

• “基于内容分发的分润”模型: 基于收益平衡性考虑，我们推出了更加适合百家号用户的“基于内容分发的分润”模型。在这种模型下，只要内容有分发，就一定有收益，而不管本身是否有广告消费。

• 策略平衡考虑: 当然，为了防止海量产出低质内容来刷取利润，在分润模型上，我们同时将内容质量分和运营因子作为分润计算的权重，也就是说作者最终的收益由内容的质量和内容的分发量共同决定，以达到通过调整分润来指导内容产出的目的。

(3) 基于作者标签模型

为了实现对百家号头部优质作者进行激励，促进内容生态良性发展, 会对不同的作者进行打标, 并且使用不同的分润模型, 比如对公域的百家号作者进行打标, 优质作者, 通过动态单价及内容质量权重策略来给到他们更加的分成, 其他的普通作者, 通过内容分发模型来分润。这样不仅保证了优质作者取得高收益，也保证了其他作者也有一定的收益

另外，出于对预算的精确控制，发挥每一笔预算的钱效，优质的作者会占用较大的预算资金池，而普通作者使用占用较少的预算资金池。同时也会对每类资金池进行上下限控制，保证预算不会花超。

(4) 基于运营场景模型

为了实现对百家号作者的精细化运营，比如对一些参与各类短期活动的作者给予一定的阶段性的奖励，可以通过补贴模型来实现。在一些运营活动中，需要控制部分作者的分成上限，分润模型会进行多轮分成计算，如果作者的收益未触顶并且资金池还有余额的情况下，会对余额进行二次分配，给作者再分配一些收益。此类模型主要是为了实现灵活多变的作者分润策略。

3. 技术架构统一

根据业务流程标准化、分润模型通用化的设计原则，建设统一的结算中台。以下是结算中台统一结算业务前后的对比：

4. 建设账单测算能力

为各个需要测算能力的业务，设计了一套通用的测算流程，如下图：

针对每个测算业务，设计了独立的测算参数管理后台，用于管理业务相关的分润模型参数，如下图：

测算流程设计

(1) 功能简述: 每个测算业务, 产品需要登录模型参数管理后台,此后台支持对分润模型参数进行创建、查看、编辑、测算、复制、上线、删除，以及查看测算结果等操作, 出于业务流程合规化的要求, 每次模型参数上线前, 需要对变更的参数完成线上备案流程才可以上线，实现分润流程合规线上化。

(2) 流程简述

• 流程简述概览: 每次测算时， 产品需要先创建一个版本的账单模型测算参数，并发起参数测算，参数状态变成待测算 。

• 离线任务与收益计算: 此后，离线任务会轮询所有的待测算参数，提交Spark任务，调用账单计算模型来计算作者收益，最后生成TDA报告。

• 查看与评估测算报告: 产品在管理平台看到任务状态变成测算完成时, 可以点击 TDA 链接来查看测算报告, 评估是否符合预期。

• 根据预期结果的操作:如果不符合预期，可以编辑参数再次发起测算；如果符合预期，则可以发起备案流程，流程走完后可以提交上线。

(3) 收益明显: 通过账单测算建设, 不仅解决结算需求未备案即已上线或者备案内容与实际实现不一致，甚至缺乏备案流程的业务痛点问题,  而且把业务线下账单计算的流程做到了线上, 做到留痕可追踪。同时也满足了业务高效迭代的诉求, 一次账单测算耗时从半天下降到分钟级, 大大降低了账单测算的人力成本与时间成本。

5. 建设质量保障体系

为了保证业务质量，从以下几方面来建设：

(1) 建设数据预警机制：为保证作者账单数据及时披露, 分润业务涉及的 百余条数据源都签订了 SLA, 每份数据都关联到具体的接口人, 通过如流机器人来监控每个环节的数据到位时间, 并及时发出报警信息, 并推送给具体的接口负责人。对于产出延迟频次高的数据流，会定期拉相关负责人相关复盘，不断优化数据产出时效，保证账单数据在每天如期产出

(2) 数据异常检测机制：对账单数据进行异常波动性检测, 确保数据准确性 ,及时发现并处理潜在异常问题

(3) 自动对账机制：每天自动进行上下游系统间账单明细核对,保证出账数据流转的准确无误。

(4) 日志质检机制：每日例行对日志进行全面质检分析, 及时发现日志打点日志。

05 中台收益

结算中台作为公司财务体系的核心，承担多业务线分润计算与资金流转重任。

(1) 通过通用化、标准化设计，高效支撑数十个业务线的精准结算，确保广告、订单、内容分发的业务结算稳定、健康。近一年，结算业务零事故、零损失。

(2) 中台支持多种结算模式与灵活周期管理，实现账单测算自动化，账单测算时间从天级降到小时级。提升效率并减少错误，提升业务需求迭代效率。

(3) 通过业务流程标准化、分润模型通用化、账单测算能力建设及质量保证体系，解决了结算业务规范缺失、业务形态多样等问题。累计解决历史结算case数十个，涉及结算金额达千万级。

未来，结算中台将推进全业务线结算立项线上化、周结与测算能力落地、项目全生命周期管理，并依托大模型能力实现数据智能分析，进一步提升数据分析智能化水平，为公司业务稳健发展提供坚实保障。

06 未来规划

1、推进全业务线结算实现立项线上化；

2、推进周结 、测算能力在各业务线上落地；

3、推进项目全生命周期管理，实现项目从上线到下线整体生命周期变化线上化存档，可随时回顾复盘。

4、数据智能分析，依托公司大模型能力，实现通过多轮对话问答来进行数据分析，针对业务问题进行答疑解惑，提升数据分析的智能化水平。

Swift、SwiftUI 与 SwiftData：走向成熟的 2025

在过去的几天里，我回顾了这一年来 Swift、SwiftUI 以及 SwiftData 的演进。总的感觉是：惊喜虽不算多，但“成熟感”却在不经意间扑面而来。

毋庸置疑，Swift 今年的重头戏在于改善并发编程的体验。尽管新增的选项和关键字在短期内又给开发者带来了不小的困扰，但经过这几个月的讨论与实践，社区已经显现出逐渐总结出新范式实践路径的趋势。我不认为新范式被确立且广泛接受会是一个简单、迅速的过程，但或许再过一两年，开发者对 Swift 的讨论重心将从并发转向跨平台，届时 Swift 也将迈入全新的发展阶段。

今年 SwiftUI 的更新重心大多集中在 Liquid Glass 的适配上。受限于系统初期的实现，显示效果起初并不尽如人意，但在 iOS 26.2 版本发布后，性能与稳定性都有了显著改善。坦率地说，对于今年 SwiftUI 没有引入更多革命性的新功能，我个人是挺高兴的。这让框架团队和开发者都能获得一点喘息之机，去进一步消化这个框架。在现阶段，解决遗留问题、优化性能与稳定性，远比一味堆砌新特性更有意义。

“变化较小”在 SwiftData 身上体现得尤为明显。但我认为 SwiftData 今年的表现尤为值得肯定，特别是许多改进与新功能都向下适配到了更早的系统版本。真希望它在三年前初次发布时，就能具备现在的状态。尽管 SwiftData 目前仍缺失一些关键功能，但对于相当比例的项目而言，它已经足以胜任。有了这个稳固的基础，其未来几年在性能与功能上的提高非常值得期待。

对于 2025 年 Swift 三件套的交出的答卷，我个人是满意的，不知你的感受如何？

这是本年度的最后一期周报，由衷感谢各位一年的陪伴与厚爱。

祝大家新年快乐，Happy Coding!

本期内容 | 前一期内容 | 全部周报列表

🚀 《肘子的 Swift 周报》

每周为你精选最值得关注的 Swift、SwiftUI 技术动态

• 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
• 👥 加入社区 | Discord 与 2000+ 开发者交流
• 📚 深度教程 | fatbobman.com 探索 200+ 原创文章

活动

iOS Conf SG 2026

下个月（1 月 21 日 - 23 日），iOS Conf SG 将在新加坡举行。我也将前往现场，并作为嘉宾进行主题为 “Using SwiftUI as a Language” 的演讲——不仅关于代码，更是关于思维方式的转换。

如果你也在附近，或者计划前往，欢迎来现场打招呼！组委会专门为我的读者提供了优惠：Fatbobman 读者专属九折优惠链接

近期推荐

我和 CloudKit 的这八年：从开源 IceCream 到商业应用实战

我一直认为，所谓的苹果生态是由很多的硬件、软件、服务、人文、气质等综合构建起来的。在这其中，CloudKit 无疑是非常重要的一环。而且对于开发者来说，用好 CloudKit 不仅可以给用户更好的体验，也能低成本的为自己的应用带来创新。

IceCream 作者 Cai Yue 分享他与 CloudKit 八年的开发历程：从 2017 年开源 IceCream 并获得 Apple 官方认可，到将 CloudKit 应用于 Music Mate 和 Setlists 等商业项目的实战经验。文章深入探讨了 CloudKit 的核心优势、关键局限以及进阶玩法。

---

Swift 2025 年度总结 (What's new in Swift: December 2025 Edition)

这是一篇面向 Swift 社区的年度收官综述文章，由 Tim Sneath 和 Dave Lester 撰写，系统回顾了 2025 年 Swift 生态在语言特性、平台覆盖与社区建设方面的关键进展。

文章不仅总结了 Swift 6.2 在并发模型上通过更温和的默认策略降低使用门槛，同时继续推进 C++ 互操作与内存安全能力；更重要的是，从 Android、WASM、Windows、BSD、嵌入式到 AWS 等方向的持续投入，反复强化了一个清晰信号——Swift 已不再只是围绕 Apple 平台展开的语言。

或许你未必会认同其中的每一项变化，但在迈入第二个十年后的第一个年头里，Swift 依然交出了一份相当扎实的答卷。

---

关于 SwiftUI 的讨论 (My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you'd expect)

几天前无意间在 Reddit 上看到的帖子，作者对 PM 轻易选择 SwiftUI 有所抱怨，认为其无法胜任他们一个七年前开发的应用转换。对于这个观点我不置可否，但评论区的走向却出乎意料——绝大多数参与者都坚定地站在了 SwiftUI 的一边。

大量开发者认为：

• SwiftUI 本身已经足够成熟，问题出在实施方式上
• 应该渐进式迁移，而不是一次性重写
• 避开 SwiftUI 的弱项——比如可以保留 UIKit 导航，只迁移视图层
• 多个大型项目（10+ 年历史）已成功完成迁移

这个帖子展现了一个出乎我预料的现实：SwiftUI 在实际生产环境中的采用率比我们想象的高得多；开发者社区对 SwiftUI 的信心已经建立。在 2025 年底，“SwiftUI 难堪大任”的论调或许已经站不住脚了。

作为 SwiftUI 框架的推崇者，我既喜欢该框架，也很清楚它仍有很长的路要走。如果你仍在犹豫是否应该在 SwiftUI 上下功夫，或许可以看一下我在去年写的《几个常见的关于 SwiftUI 的误解》——这篇文章讨论的很多误解，恰好在这次 Reddit 讨论中得到了印证。

---

非 Sendable 优先设计 (Non-Sendable First Design)

随着 Swift 6 时代的到来，开发者逐渐养成了一种惯性：要么让类型符合 Sendable，要么给它套上 @MainActor 或 actor。在这篇文章中，Matt Massicotte 提出了一个极具启发性的哲学：“非 Sendable 优先设计”。

这一思路的关键在于对“隔离（Isolation）”的重新认识：隔离本身是一种约束。当一个类型被标记为 @MainActor，它实际上就失去了在非 UI 环境下进行同步调用的自由度。相比之下，一个非隔离、非 Sendable 的普通类型反而具有更高的通用性——它可以被任意 Actor 持有，并在其内部安全地进行同步访问，同时也更容易遵循 Equatable 等基础协议，而无需处理跨隔离域带来的复杂性。

随着 Swift 引入 NonisolatedNonsendingByDefault，这种“非 Sendable 优先”的设计路径不再像过去那样笨重或别扭，反而逐渐显现出其优势：以更少的隔离、换取更清晰的语义与更低的架构负担。这或许并非适用于所有场景，但在 Swift 6 之后，它已经成为一种值得认真考虑的、符合语言直觉的“减法”方案。

---

使用 Registry 加速依赖解析 (Resolving Swift Packages faster With Registry from Tuist)

传统的 SPM 依赖解析是基于 Git URL 的，Xcode 需要克隆整个 Git 仓库来获取版本信息和代码，这在依赖较多（如 Firebase）时非常耗时。而 Registry 是苹果定义的另一种规范：通过包的标识符（ID）直接下载特定版本的归档文件，跳过了繁重的 Git 操作。Tuist 最近宣布将其 Swift Package Registry 功能向所有开发者开放，最大的变化是现在无需登录或创建 Tuist 账号即可使用。

Lee Young-jun 实测发现，使用 Registry 后，依赖解析（Installation）时间缩短至原来的约 35%；但项目生成与构建阶段并未获得同等收益，甚至略有回退。在 GitHub Actions 中配合缓存使用时，二次构建的依赖安装时间则从 53s 降至 11s，优势主要体现在 CI 场景。

总体来看，Tuist Registry 并非“全流程加速器”，而是一个专注于依赖解析与缓存友好性的优化点。如果你的项目依赖数量庞大、CI 成本较高，它值得优先尝试。

---

iOS Timer 与 DispatchSourceTimer 选择与安全封装技巧｜有限状态机防止闪退

很多开发者在处理 DispatchSourceTimer 时，最头疼的就是它那“易碎”的状态：调用顺序稍有不对便会引发闪退。ZhgChgLi 在本文中针对这种极其敏感的状态管理提出了工程化的解决方案。文章详尽列举了导致崩溃的五大常见场景（如重复 resume、suspend 状态下直接释放等），并分享了如何利用有限状态机 (FSM) 封装操作，从逻辑层屏蔽非法调用，同时配合私有串行队列确保多线程环境下的调用安全。

这是一篇引导读者从“写代码”转向“做设计”的实战案例。它不仅讲清了 GCD 定时器的正确使用方式，更展示了如何借助设计模式，将一个“危险”的底层 API，封装为语义清晰、使用安全、可长期维护的工业级组件。在 Swift Concurrency 日益成为主流的今天，理解并优雅地封装这些底层 GCD 工具，依然是高级 iOS 开发者的重要基本功。

工具

ml-sharp：照片秒变 3D 场景

苹果在上周开源了 SHARP (Sharp Monocular View Synthesis)，一个能在不到 1 秒内将单张 2D 照片转换为 3D 场景的 AI 模型（模型大小 2.8 GB）。相比之前的最佳模型，视觉质量提升 25-34%，速度提升 1000 倍。

社区普遍认为 SHARP 可能用于未来版本的空间照片功能。目前 iOS 26 的 Spatial Scenes 使用 Neural Engine 进行深度重建，而 SHARP 采用更先进的 3D Gaussian Splatting 技术，质量显著提升。

模型支持 CPU/CUDA/MPS 运行，已有开发者在 M1/M2/M3 Mac 上成功运行。输出的 .ply 文件兼容各种 3DGS 查看器，Vision Pro 用户可通过 Metal Splatter 直接查看效果。

尽管苹果在通用语言大模型上不如竞争对手惊艳，但在垂直场景的 AI 模型上，凭借硬件深度整合与明确的应用导向，依然展现出强大的竞争力。

---

MaterialView: 突破 NSVisualEffectView 限制的毛玻璃视图

Oskar Groth (Sensei 作者)开源了 MaterialView，一个能够突破 NSVisualEffectView 限制的高度可定制毛玻璃视图库。通过逆向 Control Center 的实现，Oskar 实现了对模糊半径、饱和度、亮度和色调的完全控制，并撰写了详细的技术文章讲解实现原理。

与系统原生材质只能“选类型”不同，MaterialView 将模糊效果彻底参数化，允许开发者精确控制模糊半径、饱和度、亮度、tint 颜色与混合模式，并支持 active / inactive / emphasized / accessibility 等状态配置。这使得它非常适合用于侧边栏、浮层面板、工具窗口等对视觉一致性要求极高的场景。

该库同时支持 SwiftUI 与 AppKit，并提供了一个可实时调参的 Demo App，方便快速探索不同材质组合的效果。

需要注意的是，它依赖部分未公开的 Core Animation 能力（如 CABackdropLayer、CAFilter 等）。尽管这些 API 多年来相当稳定，但仍存在未来系统版本变动的潜在风险。

往期内容

• 周日小插曲 - #115
• 挖掘“沉默的专家”- #114
• 当 Android 手机『强行兼容』AirDrop - #113
• 毕业 30 年同学群：一场 AI 引发的“真假难辨”危机 - #112

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践