OpenAI 给开源开发者发福利了！

半年 ChatGPT Pro 免费用，没门槛速领。

就在今天（2026 年 3 月 7 日），OpenAI 搞了个大动作，正式宣布启动 “Codex 开源计划”。这次不玩虚的，直接给全球的开源项目维护者和开发者送福利：免费提供半年的 ChatGPT Pro 订阅！

要知道，ChatGPT Pro 平时可是要花钱买的，这次 OpenAI 大手笔，就是为了让那些在幕后默默付出的开源英雄们，能更顺手地用上好工具。

为什么要这么做？

OpenAI 说得挺实在：开源维护者是整个软件生态的“隐形支柱”。大家平时用的很多软件、库、框架，背后都是这群人在用爱发电，默默修 Bug、加功能。

为了支持他们，OpenAI 旗下的 Codex 开源基金 在过去一年里已经掏了 100 万美元（差不多 692 万人民币），专门资助那些急需 API 支持的开源项目。现在，他们决定把支持范围扩大，直接给人送账号，让大家干活更轻松。

谁能领？门槛高吗？

重点来了：这次真的没什么硬门槛！

不像以前有些活动非要你的项目有多少 Star、多少下载量，这次 OpenAI 把身段放得很低。只要你满足下面 任意一个条件，就能去官网申请：

你是某个开源项目的 核心维护者（哪怕项目不大，只要你在认真管）；
你负责维护或开发的公共项目 被广泛使用（大家都在用，哪怕你没怎么宣传）。

那我的项目既不大也没多少人用，能申请吗？

也能！OpenAI 留了个口子：如果你在开源生态里扮演着其他重要角色（比如文档翻译、社区运营、教程编写等），只要在申请时 详细说明你的贡献和原因，照样有机会获批。主打一个“不拘一格降人才”。

拿到账号能干啥？

这半年的 ChatGPT Pro 可不是只能聊天的。拿到手的开发者，可以畅通无阻地使用一系列强大的编程神器：

Codex：写代码、改 Bug、解释逻辑，一把好手。
OpenCode、pi、OpenClaw：各种辅助编程的工具，让开发效率翻倍。
Codex Security（部分开发者）：运气好的话，你还能拿到这个安全工具的权限，对代码进行更深度的审计和安全检测，把隐患消灭在萌芽状态。

怎么申请？

别犹豫，手慢无！直接去 OpenAI 官网填个表就行。

👉 申请地址：https://openai.com/form/codex-for-oss

总的来说，这是 OpenAI 向开源社区释放的一个巨大善意。不管你是大项目的 maintainer，还是小仓库的独苗作者，只要你在为开源做贡献，这就可能是你提升效率、减轻负担的好机会。赶紧去试试自己符不符合条件吧！

⚙️ PostgreSQL 技术文章

🧩 Admin 4 v9.13 版本发布

pgAdmin 4 v9.13已发布，包含15个错误修复和新功能。主要新增功能包括Core LLM集成基础设施，具备AI驱动的安全、架构和性能分析报告，以及Query Tool的AI聊天功能和EXPLAIN的AI Insights操作。ERD Tool现在支持用户选择表的拖拽功能并显示表间关系，而Index创建对话框新增对'ONLY'子句的支持。错误修复解决了引号字符串配置、工具设置恢复、共享服务器修改、ERD节点中长表名以及物化视图列注释显示等问题。

https://www.postgresql.org/about/news/pgadmin-4-v913-released...

🧩 Swiss PGDay 2026: 宣布和征稿

Swiss PGDay 2026将于2026年6月25-26日在苏黎世附近Rapperswil的OST Eastern Switzerland University of Applied Sciences举办。这个为期两天的会议设有两个分会场，演讲主要使用英语，部分使用德语。第一天会议结束时将举办社交网络活动。演讲者征集开放至2026年4月7日，预计4月底公布日程安排。闪电演讲提交将在会议前一周开放，海报提交截止日期为2026年6月8日。为希望与Swiss PostgreSQL社区建立联系的公司提供赞助机会。参会者注册将于2026年3月开放。

https://www.postgresql.org/about/news/swiss-pgday-2026-announ...

📨 PostgreSQL Hacker 电子邮件讨论精选

🧩 索引预取使用 rdtsc 减少 EXPLAIN ANALYZE 的计时开销？

讨论的重点是实现rdtsc（读取时间戳计数器）来减少EXPLAIN ANALYZE的计时开销。主要挑战是确定不同环境下的TSC频率。Lukas Fittl测试了使用/sys/devices/system/cpu/cpu0/cpufreq/base_frequency，但发现在Azure/HyperV等虚拟化环境中，CPU频率与TSC频率不匹配，因为TSC是虚拟化的。Andres Freund建议放弃基于MSR的方法，认为不实用，并提出一个更简单的校准方法：通过将tsc_via_rdtsc除以转换为纳秒的clock_gettime(CLOCK_BOOTTIME)来计算ns_to_cycles。Fittl指出较新的AMD CPU也不通过CPUID提供TSC频率，需要MSR访问或针对其他时间源进行校准。两人都认为手动GUC配置不值得。讨论倾向于实现基于校准的方法，而不是依赖系统提供的频率值。

https://www.postgresql.org/message-id/caqgbsn6mbkmtqnencdaim7...

🧩 修复 multixact Oldest MXactId 初始化和访问中的错误

讨论跟进了最近推送的一个与OldestMemberMXactId初始化和预备事务处理相关的multixact错误修复。Sami Imseih建议添加一个测试用例来验证对预备事务虚拟进程的正确处理，因为添加的断言不会覆盖这种情况。Yura Sokolov支持为已修复的错误添加测试。Heikki Linnakangas创建了Sami复现案例的简化版本，不需要并发会话，并将其移至主回归测试套件的'prepared_xacts'测试中。Tom Lane建议了一个不相关的改进，通过在禁用预备事务时添加早期退出来减少prepared_xacts_1.out的维护工作。Heikki同意并为此优化提供了补丁，计划将其反向移植到所有支持的版本，以便于将来的测试反向移植。

https://www.postgresql.org/message-id/120550bf-ca50-4a07-91b1...

🧩 消除 xl_heap_visible 以减少 WAL（最终设置 VM on-access）

讨论围绕Melanie Plageman的补丁系列展开，该系列旨在消除xl_heap_visible WAL记录并实现访问时可见性映射设置。Chao Li对多个补丁版本进行了详细代码审查，发现了许多问题，包括函数参数类型、未初始化变量、错误消息格式问题以及heap_page_prune_opt函数调用中的潜在错误。主要关注点包括不必要地使用Buffer指针类型、缺少BlockNumber字段初始化、注释中错误的函数名引用，以及heap_insert()和heap_multi_insert()之间选项检查不一致。Melanie发布了v36版本回应，解决了大部分反馈并提供了性能基准测试结果。微基准测试显示在每个缓冲区都有单个元组的最坏情况下会出现预期的性能下降，但证明了由于使用组合WAL记录方法，vacuum操作变得更快。这些补丁旨在通过在访问时修剪操作期间仔细管理可见性映射来减少WAL量，同时保持正确性。

https://www.postgresql.org/message-id/F5CDD1B5-628C-44A1-9F85...

🧩 在发布中跳过架构更改

讨论重点是完善PostgreSQL发布EXCEPT TABLE功能的语法和错误消息。正在解决的关键问题包括通过删除"before attaching the table"等不必要短语来缩短提示消息，将文档顺序从"tables/except tables/schemas"更正为更易读的格式，以及修复解析器验证中无法到达的错误条件。围绕ALTER PUBLICATION语法替代方案出现了重要争议。与其使用"ALTER PUBLICATION pub1 DROP EXCEPT TABLE t1"来重置异常列表，提出了两个选项：Option-1使用"ALTER PUBLICATION pub1 SET ALL TABLES"清除异常或"ALTER PUBLICATION pub1 SET ALL TABLES EXCEPT TABLE (t1)"设置新列表；Option-2引入"ALTER PUBLICATION pub1 SET EXCEPT TABLE DEFAULT"用于空列表。贡献者倾向于Option-1，因为它与现有CREATE PUBLICATION语法保持一致，维护统一的用户体验。其他反馈涉及文档格式、错误消息大小写以及需要为新支持的命令更新语法文件注释。

https://www.postgresql.org/message-id/CAA4eK1KAq+4aQjyOgzD3hB...

🗞️ 行业新闻

🧩 City Detect 利用AI帮助城市保持安全和清洁，融资1300万美元A轮

City Detect 是一家利用人工智能帮助地方政府预防城市衰退的公司，已成功筹集了 1300 万美元的 A 轮融资。该平台通过 AI 驱动的监控和分析系统协助市政当局维护公共安全和清洁。City Detect 目前在美国至少 17 个城市运营，包括 Dallas 和 Miami 等主要大都市区，为城市管理挑战提供自动化解决方案。

https://techcrunch.com/2026/03/06/city-detect-uses-ai-to-help...

🧩 Claude在五角大楼交易失败后消费者增长激增继续

尽管最近围绕 Anthropic 与 Pentagon 合作失败的争议不断，Claude 的消费者应用程序仍在经历显著的增长势头。这款 AI 聊天机器人应用现在的新安装量超过了 ChatGPT，并在日活跃用户数量方面显示出显著增长。这种消费者成功表明，国防部门的争议并未对 Claude 在普通用户中的吸引力产生负面影响，用户继续在移动和网络平台上以加速的步伐采用这款 AI 助手。

https://techcrunch.com/2026/03/06/claudes-consumer-growth-sur...

🧩 Microsoft、Google、Amazon表示Anthropic Claude仍可供非国防客户使用

Microsoft、Google 和 Amazon 确认，在 Trump 的战争部与 Anthropic 发生争议后，Anthropic 的 Claude AI 助手仍可供其客户使用。这场冲突专门影响国防部门的访问，但不会影响通过这些主要云服务提供商平台使用 Claude 的其他企业客户。在人们担心 Claude 在不同行业和客户群体中可能面临更广泛限制的情况下，这一澄清显得尤为重要。

https://techcrunch.com/2026/03/05/its-official-the-pentagon-h...

🌐 社交媒体动态

🧩 我们的团队成员Jimmy Angelakos将参加#SCALE23x大会！

我们的团队成员Jimmy Angelakos将于3月6日星期五上午11:15至12:15（太平洋标准时间）在SCALE23x大会上发表演讲。他的演讲主题是使用开源CloudNativePG operator在Kubernetes上运行稳健的、自愈的PostgreSQL。与会者可以前往了解PostgreSQL on K8s以及用于Postgres的Cloud…

https://www.linkedin.com/posts/pgedge_cloudnativepg-robust-se...

🧩 PG Phridays 深度回归：全新技术文章

PG Phridays 携全新深度技术文章回归。本教程通过实际操作演示如何使用 Patroni 构建高可用 PostgreSQL 集群，重点介绍 etcd 在协调集群状态和领导者选举中的作用。Patroni 等工具依赖分布式配置存储（如 etcd）来管理复制、监控节点健康状况，并在主节点故障时自动执行故障切换。本指南面向需要在生产环境中构建可靠 Postg…

https://www.linkedin.com/posts/pgedge_postgresql-postgres-hig...

🧩 将企业数据和AI应用投入生产意味着从第一天起就处理身份验证、治理和部署问题

构建企业数据和AI应用需要从一开始就处理身份验证、治理和部署问题。Databricks Apps和新的AppKit通过使用TypeScript和可投入生产的模式进行构建，并让应用程序直接在受治理的数据旁边运行来简化这一过程。Replit集成允许开发者使用自然语言创建数据感知应用程序，并在保持现有身份验证和Unity Catalog控制的同时将其直接部署到D…

https://www.linkedin.com/posts/databricks_shipping-enterprise...

HOW 2026 议题招募中

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

自开启征集以来，HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度，我们诚邀您提交前沿技术实践与洞见，共同打造高质量议题内容。

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

在低代码平台层出不穷的今天，如何平衡可视化开发的便利性与代码的灵活性、可控性，一直是行业难题。VTJ.PRO 作为一个面向 Vue 3 开发者的 AI 驱动开发平台，给出了一个独特的答案：双向代码转换。它不仅支持从 Vue 源码到低代码 DSL 的“向上”转换，也支持从 DSL 到标准 Vue 源码的“向下”生成，并且两个方向可以反复进行，实现了真正意义上的“代码双向自由”。

本文将深入剖析 VTJ.PRO 双向代码转换系统的核心原理，揭开其如何实现 Vue SFC（单文件组件）与平台内部 DSL 之间无损、可逆转换的技术面纱。

1. 双向转换系统架构总览

VTJ.PRO 的代码转换系统由两大核心模块构成：

• Parser（解析器）：将 Vue SFC 源码解析为平台内部的 BlockSchema DSL 对象。
• Generator（生成器）：将 BlockSchema DSL 对象重新生成为标准 Vue SFC 源码。

这两个模块共同构成了一个闭环，使得开发者可以在“源码编辑”与“可视化设计”两种模式间无缝切换，且任意一方的修改都能被另一方完整理解和承载。

整体工作流程如下图所示：

flowchart TD
    A[Vue SFC 源码] -->|输入| B[Parser 解析器]
    B -->|输出| C[BlockSchema DSL]
    C -->|输入| D[Generator 生成器]
    D -->|输出| E[Vue SFC 源码]

    B -.->|验证/修复| A
    D -.->|格式化/平台适配| E

2. 解析器：从 Vue SFC 到 DSL

解析器的入口是 parseVue 函数，它接收 Vue 源码，经过多阶段处理，最终输出一个结构化的 BlockSchema 对象。整个过程可以分为：输入验证与自动修复、SFC 拆分、脚本解析、模板解析、上下文跟踪与代码修补五个主要阶段。

2.1 输入验证与自动修复

在解析之前，系统会使用 ComponentValidator 对源码进行质量检查，确保其符合平台的预期格式。验证规则包括：

• SFC 结构完整性：必须包含 <template>、<script> 和 <style> 块。
• JavaScript 语法正确性：使用 Babel 检查脚本部分是否有语法错误。
• setup 函数格式：setup() 必须恰好包含三句代码（provider 初始化、state 声明、return）。
• 图标名称合法性：检查 Vant 和 VTJ 图标库的图标名是否在白名单内。

如果检测到可自动修复的问题（如非法的图标名、模板中缺少 state. 前缀），AutoFixer 会介入修正。例如，checkAndFixStatePrefix 函数会遍历模板中的插值、绑定、指令，自动为响应式变量添加 state. 前缀：

// 修复前
<div>{{ username }}</div>
<button @click="count++">Click</button>

// 修复后
<div>{{ state.username }}</div>
<button @click="state.count++">Click</button>

2.2 SFC 解析

通过 Vue 官方编译器将源码拆分为 <template>、<script> 和 <style> 三部分。parseSFC 函数会优先识别 <script setup>，并收集所有样式块（支持多 <style>）。

2.3 脚本解析：Babel 提取

parseScripts 函数利用 Babel 对脚本代码进行 AST 遍历，提取组件逻辑元数据。关键提取点包括：

• 状态（State）：识别 const state = reactive({...}) 语句，提取初始状态对象。
• 方法（Methods）：收集 methods 对象中的函数。
• 事件处理器（Event Handlers）：方法名若匹配特定后缀模式（如 click_abc123），会被归类为事件处理器，并生成唯一 ID。
• 计算属性（Computed）：提取 computed 对象中的函数。
• 侦听器（Watchers）：方法名以 watcher_ 开头则视为侦听器源。
• 数据源（Data Sources）：识别调用 provider.apis 或 createMock 的方法，并解析其 transform 逻辑。
• 生命周期（LifeCycles）：提取 mounted、created 等方法。

这些提取出的信息将分别存入 BlockSchema 的 state、methods、computed、watch 等字段。

2.4 模板解析：AST 转换

模板解析是核心中的核心，parseTemplate 函数将 Vue 模板 AST 转换为平台内部的 NodeSchema 节点树。转换过程中，每个 AST 节点都会调用 transformNode，生成对应的 NodeSchema 对象，并递归处理子节点。

关键转换规则：

• 属性（Props）：静态属性直接转为键值对；动态绑定（v-bind）转换为 JSExpression 类型；同时处理 class/style 的合并。
• 事件（Events）：v-on 指令转换为 events 对象，事件表达式会被包装成函数，并与脚本中提取的事件处理器 ID 关联。
• 指令（Directives）：v-if、v-for、v-model、v-show 等都被提取为 directives 数组，保留其表达式和参数。
• 插槽（Slots）：识别 <template #slotName> 和组件上的 v-slot，生成 slot 元数据。

模板解析流程图如下：

flowchart TD
    A[模板源码] -->|Vue Compiler| B[AST]
    B --> C[transformNode 递归转换]
    C --> D{节点类型}
    D -->|元素节点| E[getProps 提取属性]
    D -->|元素节点| F[getEvents 提取事件]
    D -->|元素节点| G[getDirectives 提取指令]
    D -->|文本节点| H[生成文本节点]
    E --> I[创建NodeSchema]
    F --> I
    G --> I
    H --> I
    I --> J[递归处理子节点]
    J --> K[输出NodeSchema树]

2.5 上下文跟踪与代码修补

在模板中，变量可能来自多个作用域：组件状态（state）、计算属性（computed）、v-for 循环变量、插槽作用域变量等。为了保证在运行时能正确访问这些变量，解析器必须记录每个节点的上下文。

pickContext 函数在遍历 AST 时动态维护一个上下文映射：遇到 v-for 时，将迭代变量（如 item, index）加入当前上下文；遇到具名插槽时，将插槽参数加入子节点上下文。

随后，系统调用 patchCode 对所有 JavaScript 表达式（如 JSExpression 和 JSFunction）进行上下文注入。注入的核心是 replacer 函数，它通过一个状态机逐字符扫描表达式，智能地决定哪些标识符需要添加前缀（如 this.context. 或 this.）。判断规则包括：

• 字符串字面量内：不替换。
• 对象属性访问：.key 形式不替换，[key] 形式替换。
• 变量声明：不替换。
• 函数参数：不替换。
• 展开运算符：...key 替换。
• 正则表达式内：不替换。

这种精细的替换策略确保了修补后的代码既能正确引用上下文，又不会破坏原有的语法结构。

2.6 输出 BlockSchema

经过上述所有阶段，解析器最终组装出一个完整的 BlockSchema 对象。该对象包含了组件的所有信息：ID、名称、状态、方法、计算属性、侦听器、数据源、生命周期、节点树以及 CSS 样式。这个 DSL 对象可以被可视化设计器直接消费，也可以存入数据库或文件。

3. 代码生成器：从 DSL 到 Vue SFC

代码生成器是解析器的逆过程，其核心函数 generator() 接收 BlockSchema 对象，输出格式化的 Vue SFC 源码。生成过程分为模板生成、脚本生成、样式生成和格式化四个阶段，并支持多平台适配。

3.1 生成器架构

flowchart TD
    A[BlockSchema] --> B[模板生成]
    A --> C[脚本生成]
    A --> D[样式生成]
    B --> E[组合SFC]
    C --> E
    D --> E
    E --> F[Prettier格式化]
    F --> G[平台适配转换]
    G --> H[最终Vue源码]

3.2 模板生成

模板生成器遍历 BlockSchema.nodes 树，为每个 NodeSchema 节点生成对应的 Vue 模板标签。生成规则如下：

• 标签名：根据节点 name 和 from（组件来源）决定标签名。
• 静态属性：直接输出 key="value"。
• 动态属性：v-bind:key="表达式" 或 :key="表达式"。
• 事件：v-on:click="handler" 或 @click="handler"。
• 指令：将 directives 数组还原为 v-if、v-for、v-model 等指令。
• 插槽：为带有 slot 元数据的节点生成 <template #slotName> 包裹。

特别地，v-for 指令需要根据其 iterator 结构还原出 (item, index) in list 的语法。

3.3 脚本生成

脚本生成的目标是输出一个符合 Vue 3 选项式 API 或组合式 API 的 <script> 块。VTJ.PRO 默认采用组合式 API 风格，但最终输出会根据配置选择。

脚本生成的步骤包括：

1. 导入语句生成：根据组件使用的物料（UI 库、自定义组件）生成 import 语句，并处理平台依赖（如 @element-plus/icons-vue 可能被映射为 @vtj/icons）。

2. setup 函数构造：

   • 调用 useProvider 初始化 provider。
   • 声明 reactive 的 state 对象。
   • 定义计算属性、方法、侦听器、生命周期函数。
   • 返回需要暴露给模板的变量（state、props、provider 等）。
3. 方法体生成：methods、computed、watch 等字段中的 JSFunction 对象会被还原为函数代码，并经过 patchCode 的逆过程（移除上下文前缀）吗？实际上，生成器不再需要逆向 patch，因为 DSL 中的表达式已经是经过上下文修补的，生成器只需直接输出这些表达式即可，但在输出前会确保它们符合 Vue 运行时的要求（例如，模板中访问 state.xxx 是合法的，而在 methods 中可能需要通过 this.state.xxx 访问，这取决于最终代码的结构）。生成器会依据上下文适当调整引用方式。

3.4 样式生成

样式生成最简单：直接将 BlockSchema.css 字符串插入 <style scoped> 块中。若存在多个样式块，则会合并或分别输出。

3.5 格式化与平台适配

所有生成的代码都会通过 Prettier 进行格式化，确保缩进、引号、分号等风格一致。VTJ.PRO 内置了 vueFormatter、tsFormatter、htmlFormatter、cssFormatter，分别处理不同类型的代码块。

最后，根据目标平台（web、h5、uniapp）对标签和依赖进行适配转换。例如，在 UniApp 平台下，<div> 会被转换为 <view>，<span> 转换为 <text>，并且只导入支持该平台的依赖包。

4. 关键数据结构与设计哲学

理解双向转换，必须掌握几个核心数据结构：

• BlockSchema：整个组件的 DSL 表示，包含元数据、逻辑、节点树和样式。
• NodeSchema：单个节点的 DSL 表示，包含标签名、属性、事件、指令、子节点等。
• JSExpression / JSFunction：包裹 JavaScript 表达式的类型，带有 type 和 value 字段，便于序列化和解析。

VTJ.PRO 的双向转换设计遵循以下哲学：

• 无平台锁定：生成的是标准 Vue 源码，开发者可以随时脱离平台手工修改，修改后的代码仍可被平台重新解析利用。
• 可逆性：parseVue 和 genVueCode 构成一对可逆操作，多次转换后语义保持不变（通过测试用例保证）。
• 开发者友好：所有转换都尽可能保留原代码的格式和注释，生成的代码可读性强，符合开发者的编码习惯。

5. 总结与展望

VTJ.PRO 的双向代码转换系统，通过在抽象语法树层面的精细操作，实现了低代码 DSL 与标准 Vue 源码之间的双向映射。它不仅为可视化设计器提供了数据基础，也确保了开发者随时可以“下车”手写代码，享受完整的开发自由度。

未来，随着 AI 能力的进一步集成（如通过自然语言生成代码片段），这种双向转换能力将成为连接人类开发者与 AI 助手的桥梁，让软件开发进入“随心所欲、不逾矩”的新时代。

参考文档

• VTJ.PRO 源码仓库：https://gitee.com/newgateway/vtj
• 《Code Transformation System》
• 《Parser: Vue SFC to DSL》
• 《Code Generator: DSL to Vue》

起因

我平时写技术文章用 Markdown，写完之后要往十几个平台搬运。

知乎粘贴一遍，公众号粘贴一遍，掘金再贴一遍……每个平台的编辑器还不一样：知乎不认 GitHub Alerts，公众号只吃富文本，B站和头条的图片得手动传。

同样的内容，光搬运就得花半小时以上。

后来我写了个 Chrome 插件来干这件事—— Markdown Paste Helper，把粘贴和格式转换的活儿全自动化了。

怎么用

智能粘贴

在支持的平台编辑器里直接 Ctrl+V（Mac 是 Cmd+V），插件自动识别剪贴板里的 Markdown，转成对应平台能用的格式，然后替你粘进去。

不用改操作习惯，该怎么粘贴还怎么粘贴。

一键分发

点插件图标 → 选「一键分发」→ 把 Markdown 贴进去 → 勾上要发的平台 → 点「开始分发」。

插件会依次打开每个平台的编辑器，自动转换格式并粘贴进去。右下角有个悬浮按钮显示当前进度。

每个平台你扫一眼内容没问题，点发布就行。

公众号样式配置

公众号对排版要求高，插件内置了 4 种主题：

• 简约 — 无衬线字体，干净
• 醒目 — 大标题，强对比
• 精致 — Georgia 衬线，典雅
• 聚焦 — Optima 字体，紧凑

字体、字号、行间距、主题色都能自己调。

样式直接内联到 HTML 里，粘贴到公众号编辑器就是最终效果。下方是一种效果示例：

支持的平台

图片处理

B站、头条号这些平台不支持外链图片。插件碰到图片链接会自动下载图片，再模拟粘贴操作触发平台的原生上传。

Markdown 里的图片只要是在线 URL（比如图床链接）就能自动处理。

我自己用 PicGo + Cloudflare R2 搭了个免费图床，截图后自动上传、生成链接，配合这个插件刚好形成闭环。

技术细节

每个平台的编辑器框架都不一样，得逐个适配：

• 知乎 — 自研 Markdown 编辑器，拦截 Ctrl+V，预处理后写回剪贴板
• 公众号 — 自研富文本编辑器，keydown 阶段把带 inline styles 的 HTML 塞进剪贴板
• 飞书 — Slate.js，合成 ClipboardEvent 注入 HTML
• B站 — Tiptap/ProseMirror，HTML 粘贴加图片异步上传
• X Articles — Draft.js，代码块和图片没法直接粘贴，改成自动操作原生插入对话框

每个平台都是单独写的适配逻辑。Content Script 注入页面后，拦截粘贴事件，根据平台选不同的转换策略。

安装

还没上 Chrome 商店（免费项目，暂时没预算交开发者账号的钱），开发者模式装一下就行：

1. GitHub 下载项目：https://github.com/zuogl/Markdown-Paste-Helper
2. Chrome 地址栏输入 chrome://extensions/
3. 右上角打开「开发者模式」
4. 点「加载已解压的扩展程序」
5. 选 browser-extension 文件夹

最后

项目开源，MIT 协议，免费用。

GitHub：https://github.com/zuogl/Markdown-Paste-Helper

多平台发文的朋友可以试试，有问题直接提 Issue。觉得有用的话，Star 一下。

随着家里智能设备越来越多，智能家居系统也逐渐成熟，我决定从最常出入的玄关开始，把家里的灯光控制变得更智能、更省心。

目标很简单：一开门进家，玄关筒灯和书房灯自动亮起。至于为什么不亮客厅灯？因为我回家第一件事就是去书房学习😎。

要实现这个效果，核心离不开几个关键设备。下面是我踩过坑、试过方案后总结出的完整搭建过程。

小米中枢网关（必须）

为什么需要它？

中枢网关是整个小米智能家居系统的“大脑”。不同类型的智能设备通过它进行通信、联动和统一调度。没有它，很多高级自动化根本没法实现。

它内置了 小米 Mesh 2.0 网关模块，蓝牙设备配网更快，连接更稳。官方数据说能同时连 200 个蓝牙 Mesh 设备 + 100 个普通蓝牙设备，对于普通家庭完全够用。

目前小米官网发布了四款带网关功能的产品：

• 小米中枢网关（推荐）
• 小米智能多模网关2（商城搜索不到了）
• Xiaomi 路由器 BE6500 Pro（集成网关）
• Xiaomi 路由器 BE10000 Pro（集成网关）

我的建议是：别选路由器集成网关的型号。万一路由器坏了，等于网关也瘫了，得不偿失。

最关键的是，中枢网关支持“米家自动化极客版”。这个功能开放了所有设备的底层属性、事件和方法，还能做逻辑判断、条件查询、复杂流程控制——很多原生米家做不到的联动，靠它都能搞定。

接入建议

包装盒里自带一根扁平网线，强烈建议用网线把中枢网关接到路由器上。我实测过，有线连接比 Wi-Fi 稳定太多，尤其在执行自动化时几乎零延迟。

小米智能中控屏（可选，但很香）

⚠️ 注意：安装位置的底盒必须有零线，否则无法使用。

如果你预算有限，也可以用 人体传感器 + 智能开关 的组合来替代，成本更低，但折腾起来要麻烦些。

它能做什么？

• 安防联动：接入小米摄像头后，有人异常移动时可以直接在屏幕上查看实时画面。

• 场景模式一键切换：

  • 阅读模式：关窗帘、开阅读灯
  • 睡眠模式：灯光渐暗、营造氛围
  • 离家模式：关闭所有灯光电器，扫地机开始工作
• 墙面也能变艺术：内置 45 款动态屏保，支持天气、家庭照片、文字标签等，让开关面板不再只是工具。
• 智能感应：采用 24GHz 毫米波雷达，人靠近自动亮屏；屏幕亮度还能根据环境光自动调节。
• 语音交互更自然：支持小爱同学多轮对话，可以连续提问、随时打断、自由切换话题。
• 安装方便：适配标准 86 型底盒，内置三路继电器，能直接控制三盏灯，也可以当“虚拟开关”控制其他智能设备。

目前小米有三款中控屏：

• 小米智能家庭面板（不支持 Mesh 2.0，不推荐）
• 小米智能中控屏（主力型号）
• 小米智能中控屏 Max（更大屏，功能更强）

我选的是 小米智能中控屏。

我的安装经历

我把中控屏装在了玄关筒灯原来的开关位置。但问题来了：原底盒只有两根线——一根火线，一根灯控线，没有零线。

为了能让中控屏正常工作，我不得不重新穿一根零线。最简单的办法是从筒灯那边的零线引过来。但实际操作非常折腾：筒灯开孔太小，手伸不进去，穿线神器的牵引头卡在管子里出不来。最后靠一个钩子+内窥镜才勉强把线拉出来。

⚠️ 重要提醒：接线前务必拉闸断电！安全第一。

接线很简单：火线、灯控线、零线分别对应接入中控屏的端子，拧紧螺丝就行，一定压紧不要虚接。

拆筒灯的时候千万小心卡扣别打到手！别问我手疼不疼……😭

无线开关功能很实用

我家玄关只有一路灯控线，所以中控屏只接了一盏筒灯（最多支持三路）。但它的“无线开关”功能弥补了这个限制。

我在屏幕上设置了三个虚拟按钮：

• 客厅灯（装修时没做双控，现在终于能玄关开客厅灯了）
• 离家模式（一键关闭指定设备）
• 筒灯（本地物理控制）

出门前点一下“离家模式”，所有该关的灯和电器自动关闭，省心又节能。

小米智能开关（可选，强烈推荐）

有句话说得好：家里的灯可以不是智能的，但开关一定要能被智能控制。

优势在哪？

• 单火/零火都兼容：就算你家底盒没零线，也能用。功耗极低，基本不会出现“关灯后灯微亮”的问题。
• 支持 Mesh 2.0：响应更快，信号更稳，和中枢网关配合默契。

安装很简单

同样要先断电。把火线和灯控线接入对应端子就行，一定要压紧。有零线更好，没零线也能用，对老房子特别友好。

米家极客版自动化配置（核心逻辑）

补充说明：我家一厅三室的灯当初装的是欧普智能灯，所以在部分自动化里直接用了“智能灯”作为执行对象。如果你用的是普通灯+智能开关，把动作对象换成对应的开关即可。

1. 用中控屏无线开关控制客厅灯

我把中控屏的左键设为“无线开关”，通过中枢网关触发客厅智能灯的开启/关闭。

这样即使客厅灯没做双控，也能在玄关一键控制。

2. 人在时自动开灯（带时间段限制）

为了避免半夜或白天误触发，我加了时间条件：

• 17:00 ~ 次日 08:30：检测到有人，自动打开玄关筒灯
• 17:00 ~ 22:00：检测到有人，自动打开北卧灯

中控屏右键物理控制的就是玄关筒灯，所以这里直接调用设备状态。

3. 无人时自动关灯

配合人体存在传感器（或中控屏自带的毫米波雷达），一旦检测到玄关区域长时间无人，就自动关闭筒灯，避免浪费电。

总结

这套玄关智能化方案核心是 中枢网关 + 中控屏（或人体传感器+智能开关），配合 米家极客版自动化，实现了“进门即亮灯、离家一键关、按需智能控”的体验。

虽然前期穿线、调试花了不少时间，但用起来真的方便。尤其是下班回家，门一开灯就亮，不用摸黑找开关——这种细节带来的幸福感，只有用过才知道。

后续我还会继续改造其他区域，洗手间浴霸、厨房、卧室无线开关等等，欢迎关注更新！

***文末有源码下载链接***

一、为什么需要泛型高阶实战？

写泛型不难，难的是写”好“泛型。

你会遇到如下情况：

• 如何设计一个真正可复用的约束？
• 一个泛型容器应该如何实现并发安全、零拷贝、友好API？
• 如何抽象出可复用算法而不是写一堆if/else？
• 如何让泛型代码不慢？

今天的内容旧让你做到：能写工具库、能写自己的容器、能写可复用的算法。

二、构建泛型工具库

    工具库是泛型最适合发挥的地方：类型无关、逻辑可复用

    2.1 Maybe[T]:一个常用的函数式泛型工具

        类似Option类型，避免nil

type Maybe[T any] struct {
    v  T
    ok bool
}
func Some[T any](v T) Maybe[T] { return Maybe[T]{v, true} }
func None[T any]() Maybe[T]    { return Maybe[T]{ok: false} }
func (m Maybe[T]) Get() (T, bool) { return m.v, m.ok }
func (m Maybe[T]) Or(defaultV T) T {
    if m.ok {
        return m.v
    }
    return defaultV
}
// 查找map中是否存在key
func lookupMaybe[T comparable, U any](m map[T]U, k T) Maybe[U] {
    if v, ok := m[k]; ok {
        return Some(v)
    }
    return None[U]()
}

users := map[int]string{
        100: "Codee君",
        200: "詹姆斯邦德",
        300: "乔治华盛顿",
    }
    res1 := lookupMaybe(users, 100)
    if name, ok := res1.Get(); ok {
        fmt.Println(name)
    }
    res2 := lookupMaybe(users, 011)
    nameOrDefault := res2.Or("未知")
    fmt.Println(nameOrDefault)
    nameOrDefault2 := res1.Or("未知")
    fmt.Println(nameOrDefault2)
// 输出
Codee君
未知
Codee君

    Maybe[T] 类型的主要优势在于它使代码流更清晰，特别是通过 Or() 这样的方法，将 缺失值处理逻辑（提供默认值）与操作逻辑（查找） 优雅地结合起来，避免了每次查找后都写 if ok { ... } else { ... } 这样的样板代码。

    2.2  转换函数与过滤器

package main
// 切片A转切片B
func SliceA2B[A any, B any](a []A, f func(A) B) []B {
    b := make([]B, len(a))
    for i, v := range a {
        b[i] = f(v)
    }
    return b
}
// 切片过滤
func Filter[T any](in []T, f func(T) bool) []T {
    out := make([]T, 0)
    for _, v := range in {
        if f(v) {
            out = append(out, v)
        }
    }
    return out
}

func main() {
    fmt.Println("Hello, Codee君!")
    numbers := []int{1, 2, 3, 4, 5}
    // 转换成字符串
    strings := SliceA2B(numbers, func(i int) string {
        return fmt.Sprintf("ID=%d", i)
    })
    fmt.Println(strings)
    // 过滤出偶数
    even := Filter(numbers, func(i int) bool {
        return i%2 == 0
    })
    fmt.Println(even)
}
//输出
Hello, Codee君!
[ID=1 ID=2 ID=3 ID=4 ID=5]
[2 4]

三、泛型容器

    容器是泛型最能发挥威力的地方。

    3.1 泛型栈：并发安全，零拷贝，API友好

type Stack[T any] struct {
    data []*T
    mu   sync.Mutex
    len  atomic.Int64
}
func NewStack[T any]() *Stack[T] {
    return &Stack[T]{
        data: make([]*T, 0),
    }
}
func (s *Stack[T]) Push(v *T) {
    s.mu.Lock()
    defer s.mu.Unlock()
    // 避免元素复制：直接存储指针*T
    s.data = append(s.data, v)
    s.len.Add(1)
}
func (s *Stack[T]) Pop() *T {
    s.mu.Lock()
    defer s.mu.Unlock()
    if s.len.Load() == 0 {
        return nil
    }
    v := s.data[len(s.data)-1]
    s.data = s.data[:len(s.data)-1]
    s.len.Add(-1)
    return v
}
// 辅助API
// 返回栈当前元素数量
func (s *Stack[T]) Len() int64 {
    return s.len.Load()
}

// 栈
    stack := NewStack[string]()
    wg := sync.WaitGroup{}
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            value := fmt.Sprintf("value-%d", i)
            stack.Push(&value)
        }(i)
    }
    wg.Wait()
    fmt.Println("栈元素数量:", stack.Len())
    if itm, ok := stack.Pop(); ok {
        fmt.Println(*itm)
        fmt.Println("栈元素数量:", stack.Len())
    }
// 输出
栈元素数量: 100
value-99
栈元素数量: 99

     3.2 并发安全的泛型Map

type CodeeMap[K comparable, V any] struct {
    data map[K]V
    mu   sync.RWMutex
}
func NewCodeeMap[K comparable, V any]() *CodeeMap[K, V] {
    return &CodeeMap[K, V]{
        data: make(map[K]V),
    }
}
func (m *CodeeMap[K, V]) Set(k K, v V) {
    m.mu.Lock()
    defer m.mu.Unlock()
    m.data[k] = v
}
func (m *CodeeMap[K, V]) Get(k K) (V, bool) {
    m.mu.RLock()
    defer m.mu.RUnlock()
    v, ok := m.data[k]
    return v, ok
}

// 映射
    m := NewCodeeMap[int, string]()
    m.Set(1, "ID=1")
    m.Set(2, "ID=2")
    m.Set(3, "ID=3")
    fmt.Println(m.Get(1))
    fmt.Println(m.Get(2))
    fmt.Println(m.Get(3))
    fmt.Println(m.Get(4)) 
// 输出
ID=1 true
ID=2 true
ID=3 true
 false

四、泛型算法

    4.1 定制可排序泛型函数

// 需要导入内置包golang.org/x/exp/constraints
// 定制可排序约束
func Max[T constraints.Ordered](a, b T) T {
    if a > b {
        return a
    }
    return b
}
// Ordered的意义：支持数字、string、rune等，只要是可用比大小的类型都可以

    4.2 泛型二分查找

// 泛型二分查找
func BinarySearch[T constraints.Ordered](arr []T, target T) int {
    left, right := 0, len(arr)-1
    for left <= right {
        mid := left + (right-left)/2
        if arr[mid] == target {
            return mid
        } else if arr[mid] < target {
            left = mid + 1
        } else {
            right = mid - 1
        }
    }
    return -1
}

4.3 泛型归约运算

// 泛型归约算法
func Reduce[T any, R any](arr []T, init R, f func(R, T) R) R {
    acc := init
    for _, v := range arr {
        acc = f(acc, v)
    }
    return acc
}

sum := Reduce([]int{1, 2, 3, 4}, 0, func(a, b int) int { return a + b })
    fmt.Println(sum)
    mult := Reduce([]int{1, 2, 3, 4}, 1, func(a, b int) int { return a * b })
    fmt.Println(mult)
//输出
10
24

   4.4 泛型优先队列

// 泛型优先队列
type Item[T any] struct {
    value    T
    Priority int
}
type PriorityQueue[T any] []*Item[T]
func (pq PriorityQueue[T]) Len() int {
    return len(pq)
}
func (pq PriorityQueue[T]) Less(i, j int) bool {
    return pq[i].Priority < pq[j].Priority
}
func (pq PriorityQueue[T]) Swap(i, j int) {
    pq[i], pq[j] = pq[j], pq[i]
}
func (pq *PriorityQueue[T]) Push(x interface{}) {
    item := x.(*Item[T])
    *pq = append(*pq, item)
}
func (pq *PriorityQueue[T]) Pop() interface{} {
    old := *pq
    n := len(old)
    if n == 0 {
        var zero T
        return zero
    }
    item := old[n-1]
    *pq = old[0 : n-1]
    return item
}
func NewPriorityQueue[T any]() *PriorityQueue[T] {
    return &PriorityQueue[T]{}
}
type Task struct {
    Name    string
    DueDate time.Time
}

import "container/heap"
// 优先队列
    pq := make(PriorityQueue[Task], 0)
    tasks := []Task{
        {
            Name:    "任务1",
            DueDate: time.Now(),
        },
        {
            Name:    "任务2",
            DueDate: time.Now().AddDate(0, 0, 2),
        },
        {
            Name:    "任务3",
            DueDate: time.Now().AddDate(0, 0, 1),
        },
    }
    for _, task := range tasks {
        // 将Task包装在Item中，并根据DueDate设置优先级（时间越早优先级越高）
        priority := int(time.Since(task.DueDate).Milliseconds())
        if priority < 0 {
            priority = -priority // 确保过期时间越早，优先级越高
        }
        heap.Push(&pq, &Item[Task]{
            value:    task,
            Priority: priority,
        })
    }
    for pq.Len() > 0 {
        item := heap.Pop(&pq).(*Item[Task])
        fmt.Println(item.value)
    }
//输出
{任务1 2025-12-02 11:01:56.3726019 +0800 CST m=+0.001558601}
{任务3 2025-12-03 11:01:56.4072894 +0800 CST}
{任务2 2025-12-04 11:01:56.3726019 +0800 CST}

五、性能：泛型是不是会变慢？

    泛型不会让性能变差，通常比空接口更快。原因是：

• 泛型是编译期静态展开的
• 没有运行时类型断言
• 没有接口装箱
• 编译器能内联

    在容器、工具库中几乎都是净性能收益。

六、总结

    以上这些模式广泛应用于：微服务框架、数据库驱动、ORM、业务工具库、缓存系统、并发数据结构，掌握这些方法，对你今后的工作和学习有巨大帮助！

*源码地址*

1、公众号“Codee君”回复“每日一Go”获取源码

2、https://pan.baidu.com/s/1B6pgLWfSgMngVeFfSTcPdg?pwd=jc1s 

如果您喜欢这篇文章，请您（点赞、分享、亮爱心），万分感谢！

Microsoft AutoGen 曾是构建 LLM 多智能体系统的标杆性开源框架。2023 年末由 Microsoft Research 发布后迅速成为研究人员和开发者的默认选择：智能体之间可以互相对话、调用工具、编写并执行代码、在流程中引入人类审批，以对话式的协调方式取代了单条长 Prompt 链条。

到 2026 年初，AutoGen v0.4（2025 年初重新设计的版本）是其技术上的巅峰之作。但是 2025 年末 Microsoft 正式把 AutoGen 与 Semantic Kernel 合并，统一为 Microsoft Agent Framework（MAF）。不过，很多人在谈到源自 AutoGen 的多智能体编排风格时依然习惯说"AutoGen"。本文梳理 AutoGen 的来龙去脉：它是什么、为什么重要、哪些核心设计在 2026 年仍然存续、v0.4/v0.7 时代的架构与典型用法、代码示例、利弊，以及当前的整体现状。

AutoGen 为什么在 2023–2024 年迅速走红

AutoGen 出现之前，LLM 的主流用法只有两种：单线程链式调用（LangChain 风格）和简单的工具调用智能体（ReAct 循环）。

AutoGen 带来了一套完全不同的心智模型——智能体是对话的参与者，整个系统就是一个群聊，有时有结构，有时自由发挥。智能体之间可以委派任务、互相批评与纠正、调用工具、编写并执行代码、向人类发起询问，在目标达成后自行终止。没有任何一个中央控制器需要提前知晓完整计划。

这套流程和人类解决复杂问题的方式高度吻合：分工、讨论、审查输出。早期几个病毒式传播的 demo（编码者 + 评审者 + 执行者联合解数学题、网络研究小组、股票分析团队）在许多任务上展现出比单智能体高 2–10 倍的表现。

AutoGen v0.4——大改版（2025）

v0.4（2025 年初发布）本质上是 AutoGen 2.0。旧的阻塞式同步 GroupChat 被三层新架构取代：autogen-core 负责底层事件驱动原语（RoutedAgent、订阅、发布/订阅消息传递）；autogen-agentchat 是大多数人实际使用的高层 API（AssistantAgent、UserProxyAgent、GroupChat、initiate_chat）；autogen-ext 则是可插拔的扩展层（OpenAI Assistant API、MCP 工作台、gRPC 分布式智能体等）。

核心改进包括完全异步化带来的更好可扩展性与可观测性、模块化的自定义组件（内存、模型、编排）、改进的错误恢复与检查点机制，以及跨语言支持的尝试——当然 Python 始终是主力。

2025 年末 / 2026 年初的典型安装方式：

 
 pip install -U"autogen-agentchat""autogen-ext[openai]"
 

经典双智能体模式（2026 年仍在使用和教学中）

 
from autogen import AssistantAgent, UserProxyAgent, config_list_from_json

# Usually load from OAI_CONFIG_LIST or env

config_list = config_list_from_json("OAI_CONFIG_LIST")

assistant = AssistantAgent(

name="helpful_engineer",

llm_config={"config_list": config_list},

system_message="You are a senior Python engineer. Write clean, efficient code."

)

user_proxy = UserProxyAgent(

name="user",

human_input_mode="NEVER", # NEVER / ALWAYS / TERMINATE

max_consecutive_auto_reply=10,

code_execution_config={"work_dir": "coding", "use_docker": False},

)

user_proxy.initiate_chat(

assistant,

message="Write a Python class that downloads daily OHLCV data from Yahoo Finance for any ticker and caches it in parquet."

)
 

短短几行代码就已经具备了完整的闭环：一个能做规划的 LLM 智能体、代码编写与本地执行、自动重试/错误修复循环、终止条件判定。

群聊——AutoGen 的标志性模式

 
from autogen import GroupChat, GroupChatManager

researcher = AssistantAgent(name="Researcher", system_message="Find latest information.", llm_config=llm_config)

critic = AssistantAgent(name="Critic", system_message="Be skeptical and point out flaws.", llm_config=llm_config)

writer = AssistantAgent(name="Writer", system_message="Write in engaging blog-post style.", llm_config=llm_config)

user_proxy = UserProxyAgent(name="User", code_execution_config=False, human_input_mode="TERMINATE")

groupchat = GroupChat(

agents=[user_proxy, researcher, critic, writer],

messages=[],

max_round=12

)

manager = GroupChatManager(

groupchat=groupchat,

llm_config=llm_config,

# speaker_selection_method="auto" / "round_robin" / custom func

)

user_proxy.initiate_chat(

manager,

message="Write a 800-word article about newest developments in small modular nuclear reactors in 2026."

)
 

2025–2026 年的实际项目中，5–12 个智能体的配置很常见：规划者 → 研究者 → 编码者 → 测试者 → 评审者 → 文档编写者 → 用户审批者，或干脆由智能体自行决定何时拆分子团队。

AutoGen 的突出优势

涌现行为是 AutoGen 最令人意外的特质：智能体经常以出乎预料的方式完成分工。人机协作的颗粒度做到了任意节点的审批与编辑，而非仅在流程末尾给一个是/否。代码执行能力让智能体能自己修复 bug形成"编写-运行-修复"的闭环。框架本身对实验非常宽容，规则容易打破，适合快速试错。社区围绕它衍生出了 MCP 支持、Perplexity 研究智能体、gRPC 扩展等一系列生态。

痛点（2024–2025）

成本是最直接的问题：一次 8 个智能体参与的 GPT-4o 对话，处理复杂任务时费用可达 5–30 美元。非确定性带来的复现与测试困难、长对话导致的 Token 爆炸和上下文窗口耗尽、调试时难以追溯"谁在什么时候说了什么"，以及 v0.4 后期补丁出现之前几乎不存在的检查点/恢复机制，这些都是真实落地时绕不开的问题。

2025–2026 年的过渡——Microsoft Agent Framework（MAF）

2025 年 10 月，Microsoft 宣布 AutoGen 不再作为独立库接收重大功能更新。取而代之的是：AutoGen 的概念并入 Microsoft Agent Framework（Python 与 .NET 双语言支持），Semantic Kernel 负责企业级规划基础，AutoGen 部分则承载多智能体编排和对话模式。

MAF 延续了 AutoGen 的核心精神——对话式智能体、群聊编排、工具调用——但在此基础上补齐了工程化短板：内置检查点与恢复、基于 OpenTelemetry 的可观测性（追踪与指标）、对 MCP（Model Context Protocol）/A2A/OpenAPI 的原生支持、与 Azure AI Foundry / Dynamics 365 / M365 Copilot 的深度集成，以及将 Semantic Kernel 规划器与 AutoGen 风格团队混用的统一 SDK。

迁移指南很快就出现在 Microsoft Learn 和 GitHub 上。不过在 2026 年初仍有大量开源项目在使用旧的 autogen-agentchat 包——对于原型开发来说，它足够熟悉，也确实还能用。

当前状态（2026 年 3 月）

在原型开发、研究和教学场景中，经典 AutoGen v0.4 / v0.7 的代码依然随处可见。生产和企业环境则几乎全面转向 Microsoft Agent Framework，或正在迁移途中。社区围绕 MAF + AutoGen 风格模式保持着很高的活跃度。CrewAI、LangGraph、OpenAI Swarm、Magentic-One 等后来者，都或多或少借鉴了 AutoGen 率先提出的多智能体协作理念。

AutoGen 留下了什么

AutoGen 的贡献不止于一个库。它从根本上改变了开发者对 LLM 应用的认知框架——从"一个 Prompt 统治一切"转向"组建一支 LLM 专家团队，让它们彼此对话"。多智能体协作作为一等原语，到 2026 年已经渗透到整个行业。即便不再写一行 AutoGen 代码，日常使用的系统里大概率已经携带着 AutoGen 的基因。

框架本身作为独立产品已经"退役"，但其架构思路深度嵌入了 Microsoft Agent Framework 和更广泛的智能体生态。2026 年 3 月起步的新项目应直接从 Microsoft Agent Framework 文档开始；维护旧代码或偏好原始简洁性的场景下，v0.4 agentchat API 大概率还能继续运行多年。

Microsoft Agent Framework（MAF）

Microsoft Agent Framework（MAF）是 Microsoft 当前一代的开源智能体框架，覆盖构建、编排、部署与管理的全流程，尤其面向多智能体系统。2025 年 10 月进入公开预览，它是两个前代项目的官方继任者：AutoGen 带来了对话式多智能体编排、涌现团队行为和面向研究的灵活性；Semantic Kernel 则贡献了企业级基础——类型安全、中间件、可观测性、插件/连接器体系以及生产稳定性。

到 2026 年初，MAF 已被定位为 Python 与 .NET 双语言智能体开发的统一长期路径，与 Azure AI Foundry 深度绑定，但同时保持完全开源和模型无关。

MAF 要解决的，正是 2024–2025 年开发者不断碰到的那道两难题：想快速做原型、让多个智能体自由协作，选 AutoGen；想要生产级的可靠性、追踪、持久化、类型安全和企业连接器，选 Semantic Kernel。MAF 在单个 SDK 和运行时中把两边的能力合到了一起——来自 AutoGen 的简洁智能体/团队抽象，来自 Semantic Kernel 的会话状态管理、中间件管道、OpenTelemetry、过滤器和检查点，再加上全新的一层：基于图的显式工作流，用于确定性的多智能体编排。

Python最小单智能体

 
from agent_framework import AIAgent

from azure.ai.openai import AzureOpenAIClient # or openai.OpenAI etc.

import os

client = AzureOpenAIClient(

endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),

credential=…, # DefaultAzureCredential() etc.

)

agent = client.get_chat_client("gpt-4o-mini").as_ai_agent(

instructions="You are a concise technical writer.",

name="TechWriter"

)

response = await agent.run("Explain Microsoft Agent Framework in one paragraph.")

print(response.content)
 

C#类似的最小智能体

 
using Azure.AI.OpenAI;

using Azure.Identity;

using Microsoft.Agents.AI;

var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT");

var client = new AzureOpenAIClient(new Uri(endpoint), new AzureCliCredential());

var chatClient = client.GetChatClient("gpt-4o");

var agent = chatClient.AsAIAgent(

instructions: "You are a friendly assistant. Keep answers brief.",

name: "HelloAgent"

);

var response = await agent.InvokeAsync("Hello! Tell me about yourself.");

Console.WriteLine(response.Content);
 

多智能体群聊（风格上仍然很 AutoGen）：2026 年初的多数示例在模式上与 AutoGen 0.4 群聊高度相似，区别在于底层多了持久性支持：

 
from agent_framework import GroupChat, GroupChatManager, AssistantAgent

# … define researcher, critic, writer agents …

group = GroupChat(

agents=[user_proxy, researcher, critic, writer],

max_rounds=15,

# now supports persistent session id, checkpointing, etc.

)

manager = GroupChatManager(group=group)

await user_proxy.initiate_chat(

manager,

message="Research & write 600-word post on SMR nuclear progress in 2026"

)
 

对话式群聊之外，MAF 新增了基于图/DAG 的工作流编排。节点可以是智能体、函数、条件判断或循环，执行路径是确定性的——非常适合业务流程与合规场景。单个节点内部仍然可以使用对话模式，类型安全的输入/输出在 .NET 中尤其顺手。Azure AI Foundry 在 2026 年初还提供了可视化工作流设计器的预览版。

GroupChat 和 Workflow 面向的场景有明确区分：前者适合开放式研究和调试，后者用于订单处理、贷款审批、事件响应一类必须按严格顺序和分支逻辑运行的流程。

继承自 AutoGen 的能力（在 MAF 中延续）

整合之前AutoGen 在 2024–2025 年多项学术/研究 Benchmark 上处于领先或并列位置。GAIA 基准测试（开放式推理）中，AutoGen 多智能体团队在 2024 年至 2025 年初频繁占据榜首，困难子集上的成功率通常在 70–85% 区间，单智能体同期为 40–60%。SWE-bench Verified（软件工程）上，多智能体 AutoGen 变体在代码修复任务中比单智能体高出 25–40%。Microsoft 的行业案例（如 Novo Nordisk 的数据科学流水线）报告了约 25% 的迭代周期缩短。

MAF 保留了这些对话/群聊模式，涌现能力基本得以继承，而新增的确定性图编排与持久化机制预计会在不过多牺牲灵活性的前提下提升整体可靠性。

总结

看学术/研究 Benchmark（GAIA、WebArena 等）经典 AutoGen 积累的排行榜成绩更多；MAF 因为发布晚（RC 阶段），相关数据还不充分。看生产可行性、一致性、延迟、可调试性、持久化、Azure 集成等早期数据指向 MAF RC 在开发者综合 Benchmark 和企业指标上领先多数替代方案。多数谨慎的采用者在等 3 月底的 GA 版本，届时 API 将稳定，文档和示例也会更完整，预计会带出一波来自 Foundry 和第三方的正式 Benchmark。

https://avoid.overfit.cn/post/c00881ddd6f34c5ebcb34c4a862cc977

by JOLALF

大家好，这里是 3GPP 仿真实验室。

平时我们聊了太多 5G/6G、空天基网络和信道编解码。今天我们稍微跨个界，来拆解一个在自动驾驶、无人机甚至是智能家居里杀疯了的物理层传感器——毫米波雷达。

你可能会嘀咕，现在满大街都是高清摄像头和动辄上百线的激光雷达（LiDAR），毫米波雷达还有什么戏份？原因很简单：摄像头一到黑夜和雨雪天就容易“致盲”，激光雷达成本高昂且同样怕大雾。而毫米波雷达就像个不挑环境的“全天候战士”，穿透力强、测速极准，更重要的是，硬件成本已经被打下来了。

在当今的毫米波雷达界，绝对的统治者只有一种技术体制：FMCW（Frequency Modulated Continuous Wave，调频连续波）。

今天，我们就撇开那些封装好的 API，直接下沉到信号处理的最底层，硬核拆解 FMCW 雷达是如何利用电磁波，把真实世界的 3D 坐标精准还原出来的。

打破“一问一答”：为什么是 FMCW？

老派的脉冲雷达（Pulse Radar）原理很直白：大吼一声（发射极短的高功率脉冲），然后掐着秒表等回音。算出一来一回的时间差，距离就有了。但这就带来两个致命伤：一是盲区大，吼的时候听不见，离得太近就瞎了；二是瞬时峰值功率极其恐怖，射频前端成本压不住。

FMCW 换了一种极其优雅的降维打击思路。

它不吼，而是像吹滑音笛一样，持续不断地发射一种频率随时间线性攀升的信号——也就是大家常听说的 Chirp（啁啾信号）。

正因为发射频率在均匀增加，当这个信号打到目标弹回来时，我们只要拿“此刻正在发射的频率”去减“刚刚接收到的回波频率”，就能算出这个信号在空中飞了多久，进而推断出距离。

测距：混频器里的降维魔法

我们把这个过程翻译成数学语言。假设发射的一个 Chirp 信号，其频率的爬升斜率为 $S$：

$$
S = \frac{B}{T_c}
$$

这里面 $B$ 是扫频带宽，$T_c$ 是一个 Chirp 的持续时间。

雷达发出去的波，飞到目标再弹回来，飞行时间设为 $\tau$。很显然：

$$
\tau = \frac{2R}{c}
$$

（$R$ 是目标距离，$c$ 是光速）。

此时，雷达射频链路里的核心器件——混频器（Mixer）登场了。它在模拟域直接把发射信号和接收回波“相乘”，经过低通滤波后，直接拍出了一个差频信号（中频信号 IF）。这个中频信号的频率 $f_b$ 就是两者的频率差。

既然频率是线性增加的，那时间差 $\tau$ 对应的也就是频率差：

$$
f_b = S \cdot \tau = \frac{S \cdot 2R}{c}
$$

稍微挪一下位置，FMCW 最底层的测距公式就出来了：

$$
R = \frac{c \cdot f_b}{2S}
$$

在数字信号处理（DSP）流水线中这意味着什么？ 意味着距离 $R$ 和中频频率 $f_b$ 是严格绑定的。我们只需要对 ADC 采样后的中频数据跑一次 1D FFT（Range FFT），频谱上哪个频点冒了尖（峰值），目标就在那个距离上！

测速：捕捉相位的微小涟漪

测距搞定了，那速度怎么算？如果只发一个 Chirp，你其实是测不出速度的。

FMCW 的聪明之处在于，它会密集地连发一串（比如 128 或 256 个）一模一样的 Chirp，这就构成了一帧（Frame）。

想象一下，如果目标在动，那么在相邻两个 Chirp 之间，目标的距离 $R$ 会发生极其微小的位移（通常是毫米级）。这点位移，在刚才的 1D FFT 频谱上根本看不出频偏（频率分辨率不够），但是！它会剧烈地改变回波信号的相位（Phase）。

物理常识告诉我们，微小的距离变化 $\Delta R$ 对应着多大的相位差 $\Delta \phi$ 呢？

$$
\Delta \phi = \frac{4\pi \Delta R}{\lambda}
$$

而 $\Delta R$ 不就是速度 $v$ 乘以两个 Chirp 之间的间隔时间 $T_c$ 吗？代入进去，速度 $v$ 就呼之欲出了：

$$
v = \frac{\lambda \cdot \Delta \phi}{4\pi T_c}
$$

在算法实现上，这步操作丝滑得让人拍案叫绝：我们在做完 1D FFT 的基础上，沿着 Chirp 索引的维度，再跑一次 2D FFT（Doppler FFT）。

算完之后，你就会得到一张经典的距离-多普勒热力图（Range-Doppler Heatmap）。图上的高亮像素点，直接同时锁死了目标的两个维度：离我多远，以及相对我跑得多快。

测角：天线阵列的几何学

有了距离和速度，最后一块拼图就是角度（方位角与俯仰角）。这就不是单根天线能搞定的了，我们需要请出 MIMO 天线阵列。

测角的底层逻辑依然是“玩弄”相位。

当回波以某个角度 $\theta$ 拍到天线阵列时，到达相邻两根接收天线（间距设为 $d$）的路径长度会有微小的波程差，大小为 $d \sin\theta$。

这个多跑的路程，同样会造成两根天线接收信号之间的相位差 $\Delta \omega$：

$$
\Delta \omega = \frac{2\pi d \sin\theta}{\lambda}
$$

反解一下，角度 $\theta$ 就拿到手了：

$$
\theta = \arcsin\left(\frac{\lambda \cdot \Delta \omega}{2\pi d}\right)
$$

在基带处理代码里，我们在 2D FFT 找到目标峰值后，沿着天线维度（Antenna Index）再抡一次 3D FFT（Angle FFT）。至此，FMCW 雷达经典的 3D FFT 处理链路就彻底闭环了。

写在最后：从公式到代码变现的距离

复盘一下，FMCW 雷达的物理机制其实充满了一种对仗的数学美感：

• 距离，映射到了单个 Chirp 内的中频频率上。
• 速度，映射到了多个 Chirp 间的多普勒相位上。
• 角度，映射到了多根天线间的空间相位上。
  而这所有的一切，最后都被伟大的 FFT 统一在了矩阵运算里。

不过，推导公式只是键盘侠的狂欢，真正的工程落地才刚刚开始。在实际的物理层仿真和基带芯片开发中，你马上就会被一堆现实问题糊一脸：

• 底噪太高怎么办？怎么手写 CFAR（恒虚警率） 算法从杂波里抠出真实目标？
• 目标跑得太快，相位转了一圈以上，速度模糊（Velocity Ambiguity）怎么解？
• 天线阵列太少，角度分辨率不够，怎么利用 MIMO 体制做虚拟孔径合成？

这才是真正拉开算法工程师段位的地方。

开发者朋友们大家好：

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@koki、@鲍勃

01 有话题的技术

1、OpenAI 正式推出 GPT-5.4

当地时间 3 月 6 日，OpenAI 正式推出 GPT-5.4，这是其最新一代 AI 旗舰模型。据该公司介绍，新模型在推理能力、编程能力，以及处理涉及电子表格、文档和演示文稿等专业办公任务方面均取得明显进步，并且在完成任务时需要用户反复交互的次数更少。同时，这也是 OpenAI 首款具备原生计算机使用能力的模型，这意味着它可以代表用户操作电脑，在不同应用程序之间执行任务并完成工作流程。

目前，OpenAI 正将 GPT-5.4 向其 API 接口及 AI 编程工具 Codex 开放，同时将推理模型 GPT-5.4 Thinking 部署至 ChatGPT 平台。据 OpenAI 介绍，GPT-5.4 不仅能够编写代码来操控计算机，还能根据屏幕截图发出键盘和鼠标指令。该模型在使用网页浏览器、调用工具及 API 以辅助任务完成方面，也展现出更高的准确性和效率。此外，GPT-5.4 在处理需要整合多源信息的复杂查询时表现更为出色。OpenAI 表示，该模型「能够进行多轮持续搜索，精准识别最相关的信息源，尤其擅长解答‘大海捞针’式的难题，并将搜索结果整合为清晰、条理分明的答案」。

OpenAI 宣称 GPT-5.4 是其「迄今为止事实性最强的模型」，单个陈述的失实概率较 GPT-5.2 降低了 33%。在 ChatGPT 内部，GPT-5.4 Thinking 针对复杂查询将提供工作思路大纲，同时允许用户在模型生成回应的过程中随时调整或修改请求。该功能目前已上线 ChatGPT 网页端及安卓应用，iOS 版本则「即将推出」。GPT-5.4 现已面向 ChatGPT、Codex 及 API 全面推出，其中 GPT-5.4 Thinking 模型将向 Plus、Team 和 Pro 用户开放。此外，针对「复杂任务最高性能需求」的 GPT-5.4 Pro 模型也将通过 API 上线，并向 ChatGPT 企业版和 Edu 用户开放。

以下是 GPT-5.4 较之前版本的提升：

（@雷锋网）

2、Lightricks 正式发布 LTX-2.3 音视频模型及开源编辑器

LTX 团队今日同步发布 LTX-2.3 核心模型架构升级及基于该引擎构建的生产级视频编辑器 LTX Desktop。本次更新标志着 LTX 从纯模型提供方转向「引擎+工具」的完整生态布局。

TX-2.3 核心架构演进：

• 重建 Latent Space 与 VAE：通过更高质量数据重新训练 VAE 架构，提升了纹理与边缘的保留能力，显著改善了前代版本在低分辨率下发丝等细节「过软」的问题。
• 增强型 Text Connector：扩大了文本连接器容量并优化桥接架构。提升了对复杂提示词（多主体、空间关系、特定风格指令）的语义理解准确度，降低了生成偏移。
• I2V（图生视频）算法重构：针对前代常见的「画面冻结」或单纯「平移（Ken Burns Effect）」问题进行了训练修正，增加了动态幅度并减少了意外切镜。
• 音频质量优化：通过清洗训练集中的噪点与伪影，并引入全新 Vocoder（声码器），实现了更稳定的音视频同步（A2V）与更低的背景杂讯。
• 原生纵向支持：支持最高 1080x1920 的原生竖屏视频生成，而非横屏裁剪。

与此同时，LTX 团队首次发布基于自身引擎构建的桌面端应用，旨在验证 LTX 引擎的商业化能力。其支持在本地机器全权运行，无需联网，无单次生成费用，可直接访问模型权重，同时亦可接入 API 作为后端。对个人及年营收 1000 万美元以下的企业免费开源；大型企业需商业授权。

Huggingface 链接：

https\://huggingface.co/Lightricks/LTX-2.3

（@LTX Models）

3、FireRedVAD：业界领先的语音活动检测与音频事件检测方案

FireRedVAD 是一种业界领先（SOTA）的工业级语音活动检测（VAD）和音频事件检测（AED）解决方案。其支持非流式/流式 VAD 以及非流式 AED 以及 100 多种语言的语音/歌唱/音乐检测。在 FLEURS-VAD-102 数据集上，非流式 VAD 的 F1 分数达到 97.57%。

Github 链接：

https\://github.com/FireRedTeam/FireRedVAD

Huggingface 链接：

https\://huggingface.co/FireRedTeam/FireRedVAD

( @xukaituo\@ModelScope)

02 有亮点的产品

1、出门问问发布全球首款 4G AI 录音耳机 TicNote Pods，联合 Alpha 派推出金融投研版「涨听」

近日，人工智能公司出门问问发布全球首款 4G AI 录音耳机 TicNote Pods 中国版。这款继年初在 CES 2026 全球首发并完成海外众筹发货后备受瞩目的 AI 硬件，正式进入国内市场。TicNote Pods 的发布，标志着 AI 耳机正式进化为具备独立能力的「AGI 硬件终端」，通过内置 4G 模块与「Shadow AI」双引擎，它摆脱对手机和 Wi-Fi 的依赖，为用户构建起「记录-分析-洞察-协作」的完整智能化体验。

与此同时，其联合金融 AI 应用 Alpha 派推出 TicNote Pods 金融投研版——命名为「涨听」的 AI 耳机，将独立 AI 能力注入投研场景。

TicNote Pods 内置的「Shadow AI 2.0」具备强大的听觉、记忆与思维能力，而 TicNote Cloud 则是这一切智慧的沉淀池。两者的结合，让录音不再是沉睡的文件，而是围绕「项目」持续演进的工作资产。

其主要体现为：

• 项目驱动的知识组织： 在 TicNote Cloud 中，用户可将录音、PDF、Word 等文件归入不同项目空间，让散落的信息围绕核心任务形成结构化上下文。
• Agent 级执行能力： Shadow AI 2.0 不仅能理解与问答，更具备高效的执行能力，可根据指令生成新文件、更新现有文档，甚至将多个会议纪要自动转化为 HTML 落地页或 PPT，直接交付项目成果。
• 团队×Agent 协作： 团队成员与 Shadow AI 2.0 共享同一项目空间，每一个想法、每一次修改实时同步。Agent 不再是个人助手，而是团队的「数字伙伴」，在无缝协作中推动项目持续演进。

这一能力在金融投研场景中尤为关键。当用户进行线下调研或电话访谈时，无需依赖手机或 Wi-Fi，即可独立完成音频采集并上传云端。依托 4G 网络，上传与 AI 处理速度提升可达 50%，会议结束的瞬间，投资纪要摘要与待办事项便已生成。这种「独立自主」的硬件能力，让 AI 真正随叫随到。

（@出门问问）

2、Cluely 首席执行官 Roy Lee 承认去年公开谎报营收数据

硅谷明星初创公司 Cluely 再次陷入舆论风暴。周四，其联合创始人兼 CEO Roy Lee 在社交平台 X 上正式撤回此前言论，承认其去年向《TechCrunch》披露的 700 万美元年度经常性收入（ARR）纯属虚构。

Roy Lee 在 X 上称，去年的营收数据是他唯一一次「公开且露骨的谎话」，并对此表示正式撤回。讽刺的是，他在承认造假的同时，还试图通过贬低媒体来「甩锅」——称当时只是接到了一个「陌生女性的骚扰电话」并随口胡编。

然而，调查显示这并非意外：事实证明，该采访是由 Cluely 的公关团队主动联络媒体并安排的深度专访。有趣的是，Lee 在去年 10 月的 TechCrunch Disrupt 大会上曾告诫创业者「永远不要分享营收数字」，如今看来，这更像是为了掩盖之前言而释放的烟雾弹。

回顾过去，Cluely 的崛起路径似乎一开始就带有浓厚的「投机」色彩，最初，他因开发一款能让用户在视频面试中秘密检索答案的工具而走红，两位创始人甚至因该工具被哥伦比亚大学停学。凭借「作弊神器」带来的病毒式流量，公司先后斩获 Abstract Ventures、Susa Ventures 的 530 万美元种子轮，以及 Andreessen Horowitz （a16z） 领投的 1500 万美元 A 轮融资。 但随着作弊争议和合规压力，公司现已转型为大众化的「AI 会议笔记助手。」

( @TechChurch)

03 有态度的观点

1、马斯克：特斯拉将是首个以人形机器人形式实现 AGI 的公司

近日，马斯克在 X 发文表示，特斯拉将是首个以「人形机器人」形式实现 AGI 的公司。

此前，他旗下的 AI 公司 xAI 一直被外界视为其 AGI 野心的主要载体。而在 xAI 被 SpaceX 收购、转型专注于太空算力基础设施建设之后，特斯拉正式接过了「具身 AGI」这一定位。

据 not a tesla app 报道，在马斯克的构想中，特斯拉通向 AGI 的路径与 OpenAI 等大语言模型路线截然不同。

特斯拉多年来通过 FSD 项目积累了海量真实道路视频数据，并自研 AI 芯片，训练的是一个能够理解物理规律、在复杂现实环境中做出决策的系统。

马斯克将这种「原子塑造」能力视为通往真正 AGI 的关键，而非单纯的语言或推理能力。

根据特斯拉最新计划，今年第一季度将发布 Optimus Gen 3 量产意向原型，中期开始在特斯拉工厂内部小批量部署，年底进入大规模量产阶段，长期目标是年产 100 万台，售价压至约 2 万美元。

为此，特斯拉已停产 Model S 和 Model X，将弗里蒙特工厂产线腾出用于 Optimus Gen 3 的生产。

在时间节点上，马斯克维持了此前的预测——AGI 将于今年实现，并在 2030 年前超越全人类智能的总和。

不过，这一判断与主流 AI 研究界存在显著分歧：去年一项覆盖逾 8500 名 AI 研究人员的调查显示，AGI 在 2040 年前实现的概率仅约 50%；AI 学者吴恩达则明确表示，AGI 的到来还需数十年。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

原文地址 https://feinterview.poetries.top/blog/openclaws-skills-fronte...

接上篇 OpenClaw搭建24小时帮你干活的AI员工,支持本地/云服务并打通飞书/Telegram/Discord

部署好OpenClaw后，很多人会发现它还只是个"聊天机器"。其实，OpenClaw真正强大的地方在于Skills生态——通过不同的技能插件，你的AI助手可以具备代码生成、UI设计、性能优化、调试排错等前端开发能力。

本文不打算重复那些基础配置操作，而是聚焦于：如何针对前端开发场景，构建真正有用的技能矩阵。

一、按需构建：前端开发者的Skills选择策略

不要看到什么Skill都想安装。更好的方式是：根据你的技术栈和业务场景，按需选择。

不同技术栈对应的Skills组合

技术栈

推荐Skills组合

React 全栈开发

React + Frontend Design + UI/UX Pro Max + Zustand Patterns

Vue 开发

Vue + Component Api Design + Frontend Design

移动端开发

React Native Skills + Radon AI

UI/UX 设计

UI/UX Pro Max + UI Audit + Frontend Design Extractor

性能优化

Frontend Performance + Browser Devtools Inspector

二、Skills安装全攻略

万事开头难，很多人一听到要配置Skills就头大。其实OpenClaw提供了多种安装方式，总有一款适合你。

方法一：使用OpenClaw自带的53个Skills

OpenClaw内置了一批基础Skills，包含飞书、Discord、ClawHub等常用能力：

# 列出所有技能
openclaw skills list


# 查看当前可用的skills
openclaw skills list --eligible


# 查看技能详细信息（技能介绍、技能细节、必备库）
openclaw skills info <技能名称>


# 启用技能
openclaw skills enable <技能名称>


# 禁用技能
openclaw skills disable <技能名称>


# 检查技能状态
openclaw skills check <技能名称>

方法二：ClawHub安装（推荐）

ClawHub是OpenClaw官方维护的Skills注册中心，目前已有17000+ Skills，是最推荐的安装方式。

# 安装 ClawHub 服务
# 使用 npm 安装
npm i -g clawhub


# 或使用 pnpm 安装
pnpm add -g clawhub

安装完成后，管理Skills非常简单：

# 搜索技能
clawhub search "react"


# 安装技能
clawhub install <skill-slug>
clawhub install <skill-slug> --version <版本号>  # 安装指定版本
clawhub install <skill-slug> --force  # 强制覆盖已存在文件夹


# 更新技能
clawhub update <skill-slug>           # 更新单个技能
clawhub update --all                  # 更新所有已安装技能


# 查看已安装技能
clawhub list

方法三：GitHub手动安装

对于GitHub上直接托管的Skills，可以手动克隆到本地：

# 进入到工作区的Skills文件夹下
cd ~/.openclaw/workspace/skills


# 克隆技能仓库到本地
git clone https://github.com/BankrBot/openclaw-skills.git ./skills

方法四：直接对话安装（最推荐�❤️）

最简单的方式——直接告诉OpenClaw你要安装什么：

请帮我安装这个skills，github链接是 xxxx

这种方式对新手最友好，无需记忆任何命令。

安装后的安全检查

在安装任何第三方Skills之前，安全必须是第一优先级：

Skill-Vetter — 安装任何Skills之前，用它扫描检测恶意代码：

# 安装
clawhub install skill-vetter


# 使用
skill-vetter <skill-name>

三、这些前端Skills值得优先安装

💡 强烈建议：先安装 Skills 安装方法中列出的安全类Skills，确保后续安装其他Skills的安全性。

1. React 全栈开发

React — 全栈React 19工程能力，涵盖Server Components、hooks、性能优化、测试和部署：

# 安装
clawhub install react


# 地址
https://clawhub.ai/ivangdavila/react

React Production Engineering — 生产级React应用构建方法论，包含架构决策、组件设计、状态管理：

# 安装
clawhub install react-production


# 地址
https://clawhub.ai/1kalin/afrexai-react-production

React Component Generator — 一键生成React组件模板，支持Function/Class组件、Hooks、TypeScript：

# 安装
clawhub install react-component-generator


# 地址
https://clawhub.ai/Sunshine-del-ux/react-component-generator

Zustand Patterns — Zustand状态管理实战模式，适合React项目：

# 安装
clawhub install zustand-patterns


# 地址
https://clawhub.ai/bingfoon/zustand-patterns

2. UI/UX 设计相关（强烈推荐）

🎨 特别推荐：Canvas Design — AI Logo设计神器

Canvas Design — 这是一个颠覆传统设计方式的Skill！和一般设计工具不同，Canvas Design可以从哲学思想到视觉设计进行深度沟通后直接出图。它不是简单的你让画啥就画啥，而是先从灵魂深层理解你的诉求最后再完成设计。

最关键的是，一键生成PNG、SVG以及各种布局和尺寸。

# 安装
npx skills add https://github.com/anthropics/skills --skill canvas-design --agent claude-code -y

📺 实际案例：小米当时花了几百万请日本设计师改Logo，最后大家评价改了个寂寞。而使用Canvas Design，从哲学思想到视觉设计30分钟就搞定了，而且设计效果非常令人满意！

UI/UX Pro Max — 顶级UI/UX设计智能助手，支持React、Next.js、Vue、Svelte、Tailwind等9种技术栈：

# 安装
clawhub install ui-ux-pro-max


# 地址
https://clawhub.ai/xobi667/ui-ux-pro-max

这个Skill堪称全能：

• 50+设计风格（玻璃拟态、粘土风、极简主义、粗野主义等）
• 21种配色方案
• 50种字体搭配
• 支持生成落地页、Dashboard、电商、SaaS等各类项目

UI/UX Design Guide — 移动优先的UI/UX设计指导，包含WCAG 2.2无障碍规范：

# 安装
clawhub install ui-ux-design


# 地址
https://clawhub.ai/itsjustdri/ui-ux-design

Frontend Design — 使用React、Next.js、Tailwind CSS构建生产级界面：

# 安装
clawhub install frontend


# 地址
https://clawhub.ai/ivangdavila/frontend

UI Audit — 自动化的UI审核工具，基于Nielsen Norman可用性原则：

# 安装
clawhub install ui-audit


# 地址
https://clawhub.ai/tommygeoco/ui-audit

3. 性能优化

Frontend Performance — 分析前端性能问题（LCP、FCP、CLS、Bundle Size），提供优化建议：

# 安装
clawhub install frontend-performance


# 地址
https://clawhub.ai/wangzhiming1999/frontend-performance

Browser Devtools Inspector — 通过浏览器DevTools调试前端问题（Console、Network、Performance）：

# 安装
clawhub install qtada-browser-devtools-inspector


# 地址
https://clawhub.ai/QtadaGM/qtada-browser-devtools-inspector

4. 组件库相关

Ant Design Skill — 高效构建Ant Design v5+ React组件库：

# 安装
clawhub install ant-design-skill


# 地址
https://clawhub.ai/FelipeOFF/ant-design-skill

Component Api Design — 可复用组件API和文件结构设计：

# 安装
clawhub install component-api-design


# 地址
https://clawhub.ai/wangzhiming1999/component-api-design

5. 移动端开发

React Native Skills — React Native和Expo最佳实践：

# 安装
clawhub install vercel-react-native-skills


# 地址
https://clawhub.ai/xaiohuangningde/vercel-react-native-skills

Radon AI — React Native开发AI工具，支持查看日志、网络请求、组件树检查：

# 安装
clawhub install radon-ai


# 地址
https://clawhub.ai/latekvo/radon-ai

四、重头戏：如何自定义开发一个Skill

官方提供的Skills再多，也不可能覆盖所有场景。这时候，你需要自己动手开发定制技能。

Skill的基本结构

一个标准的OpenClaw Skill通常包含以下文件：

my-custom-skill/
├── SKILL.md          # Skill的元信息和使用说明
├── skill.json        # 配置文件
├── main.py           # 主逻辑（或其他语言实现）
└── requirements.txt  # 依赖列表

快速创建一个前端组件生成Skill

第一步：创建SKILL.md

---
name: my-component-generator
description: 自定义前端组件生成器
---


# My Component Generator


用于快速生成前端组件代码。


## 使用方法


`gen component [组件名] [类型]` - 生成指定类型的组件


示例：
- `gen component Button primary` - 生成主按钮组件
- `gen component Card dark` - 生成暗色卡片组件

第二步：编写配置文件 skill.json

{
  "name": "my-component-generator",
  "version": "1.0.0",
  "description": "自定义前端组件生成器",
  "entry": "main.py",
  "dependencies": ["jinja2"]
}

第三步：编写主逻辑 main.py

import json
from jinja2 import Template


# 组件模板
BUTTON_TEMPLATE = '''
import React from 'react';
import './{{ name }}.css';


interface {{ name }}Props {
  variant?: 'primary' | 'secondary' | 'ghost';
  onClick?: () => void;
  children: React.ReactNode;
}


export const {{ name }}: React.FC<{{ name }}Props> = ({
  variant = 'primary',
  onClick,
  children
}) => {
  return (
    <button 
      className={`btn btn-${variant}`}
      onClick={onClick}
    >
      {children}
    </button>
  );
};
'''


CARD_TEMPLATE = '''
import React from 'react';
import './{{ name }}.css';


interface {{ name }}Props {
  title: string;
  content?: string;
  variant?: 'light' | 'dark';
}


export const {{ name }}: React.FC<{{ name }}Props> = ({
  title,
  content,
  variant = 'light'
}) => {
  return (
    <div className={`card card-${variant}`}>
      <h3 className="card-title">{title}</h3>
      {content && <p className="card-content">{content}</p>}
    </div>
  );
};
'''


def handle(request):
    message = request.get("message", "").lower()
    
    # 解析命令: gen component Button primary
    parts = message.split()
    if len(parts) < 4 or parts[0] != "gen" or parts[1] != "component":
        return {
            "status": "error",
            "message": "请使用格式：gen component [组件名] [类型]\n例如：gen component Button primary"
        }
    
    component_name = parts[2]
    component_type = parts[3]
    
    # 选择模板
    templates = {
        "button": BUTTON_TEMPLATE,
        "card": CARD_TEMPLATE,
    }
    
    template_key = component_type if component_type in templates else "button"
    template = Template(templates[template_key])
    
    code = template.render(name=component_name)
    
    return {
        "status": "success",
        "message": f"生成的 {component_name} 组件代码：\n\n```{code}```"
    }


if __name__ == "__main__":
    test_request = {"message": "gen component MyButton primary"}
    print(handle(test_request))

Skill的触发机制

OpenClaw的Skills通过关键词匹配或意图识别触发。配置时需要注意：

1. 明确的触发词 — 在SKILL.md中用 \`code\` 格式标注命令格式
2. 合理的参数解析 — 用户输入可能有多种表达方式，需要兼容
3. 清晰的错误提示 — 当用户指令不明确时，给出正确的使用方式

发布你的Skill

开发完成后，可以通过以下方式分享：

1. 提交到ClawHub — 让更多开发者可以使用你的Skill
2. GitHub仓库 — 符合OpenClaw的目录结构后分享
3. 直接安装 — 告诉朋友"请帮我安装这个skills，github链接是xxx"

五、进阶技巧：前端Skills组合使用

单个Skill的能力有限，但组合使用会产生意想不到的效果。

示例：自动化组件开发工作流

用户输入：帮我创建一个用户列表页面


→ UI/UX Pro Max 确定页面布局和设计风格
→ React 生成列表组件代码
→ Frontend Performance 检查性能问题
→ UI Audit 最终体验审核

示例：技术调研自动化

用户输入：调研React 19的Server Actions


→ GitHub 获取官方文档和RFC
→ multi-search-engine 搜索技术博客讨论
→ playwright-scraper-skill 抓取关键页面详情
→ Summarize 生成调研报告

六、避坑指南

1. 不要安装来源不明的Skills — 安装前用skill-vetter扫描
2. 定期更新 — 使用auto-updater保持Skills最新，但更新前做好测试
3. 注意API配额 — 很多Skills依赖第三方API，免费额度用完会失效
4. 敏感信息处理 — 涉及API Key等敏感信息时，务必谨慎
5. 测试环境先行 — 新安装的Skills先在非关键场景测试，确认稳定后再用于核心任务

七、更多前端Skills资源

如果你在寻找特定功能的Skills，以下资源值得收藏：

资源站

链接

ClawHub 官网

https://clawhub.ai/

Awesome OpenClaw Skills

https://github.com/VoltAgent/awesome-openclaw-skills

OpenClaw 官方 Skills

https://github.com/openclaw/skills

其他常用检索/效率类Skills

# 网页检索
clawhub install multi-search-engine
clawhub install agent-reach


# 代码调试
clawhub install playwright-scraper-skill


# 内容处理
clawhub install summarize
clawhub install humanizer


# 自我学习
clawhub install self-improving-agent

结语

OpenClaw的Skills生态为前端开发者提供了强大的能力扩展。从基础的React/Vue组件生成，到复杂的UI设计系统，再到性能优化和调试——你的AI助手能帮你做多少事情，取决于你愿意投入多少精力去配置和打磨。

不要试图一步到位。从最需要的1-2个Skills开始，在使用中学习，在学习中扩展——这才是真正有效的进阶路径。

作为前端开发者，我个人最推荐优先安装：UI/UX Pro Max + React + Frontend Design，这个组合已经能覆盖大部分日常开发需求。

3月6日，腾讯总部吸引了上千名AI用户前来排起长队，他们在工程师的协助下完成OpenClaw的云端安装。显然，海外这股OpenClaw“龙虾”热潮，仍在国内蔓延。
热潮背后，海外方案的复杂部署流程及云端安全隐患，让多数普通用户对“养虾”望而却步。社交平台上因此频频出现了收费上门安装“龙虾”的第三方服务。国内各大厂也紧急推出云端部署方案，但用户仍需自行配置环境才能运行这款全职AI助手。
继枫清科技（Fabarta）在春节前夕发布Fabarta个人智能体龙虾版（即中国版“龙虾”）Mac版本后，适配Windows的中国版“龙虾”今日正式上线，让零门槛使用成为现实——国内用户无需调试和部署，一键即可拥有高效且安全的专属“龙虾”。

开箱即用，告别选择困难

与海外版本需要的复杂配置不同，Fabarta个人智能体龙虾版真正实现了"开箱即用"。产品内置周报整理、数据抓取、智能写作、翻译助手等高频办公场景，并支持多种大模型API渠道的无缝切换，用户无需在不同模型间纠结选择，系统会自动匹配最优能力。中国版“龙虾”让非技术背景的普通用户也能零门槛享受AI自动化红利。

本地运行，安全可控

在赋予AI操作权限的同时，枫清科技将"安全"作为底层架构的核心。海外方案普遍采用“云端推理+本地执行”模式，而这款Windows版“龙虾”采用全本地化部署，所有数据处理、记忆存储均在用户本地设备完成，配合沙箱隔离机制，确保敏感数据永不离开电脑。
更重要的是系统内置的"人工终审"机制：面对高危操作（如文件删除、邮件发送），AI会自动暂停并等待用户确认，同时全程记录操作日志，形成可追溯的审计链条。这些双重保障，将最终决策权交还到用户手中。

长期记忆与短期工作流融合，越用越懂你

中国版“龙虾”不仅是一个执行工具，更是一位了解你工作习惯的私人助理。依托本地长期记忆文件，系统会持续记录用户的常用术语、项目背景、文件路径及个人偏好，构建起具有用户特色的"记忆库"。
当用户启动新任务时，AI能将历史背景与当前工作流实时融合，用户则无需重复交代背景。长期记忆与短期工作记忆的有机融合，让每次交互都基于上下文语境，实现"越用越懂你"的个性化体验。

云边端协同：从个人助手到企业级智能体的无缝延伸

Windows版本的上线，不仅完善了中国版“龙虾”在主流操作系统生态的布局，更打通了个人与企业的协同链路。
虽然在本地运行，但这款“龙虾”的能力也完全不会受限。基于云边端架构，这款“龙虾”可无缝连接企业知识中台，在本地安全环境下调用企业在云端的共享知识库，同时支持私有化模型部署。因此，员工可在本地完成敏感操作，数据全程闭环，权限精细可控。
目前，枫清科技官网已开启“龙虾”权益码限时发放活动，用户领取权益码后即可激活使用，体验期结束后可购买权益包继续享受服务。

即刻登录枫清科技官网（https://fabarta.com/my-agent）或扫描下方二维码下载Fabarta 个人专属智能体，把工作放心交给你的 “个人超级智能体”！

HTML 里只有 3 种列表标签。它们的作用主要是告诉浏览器和机器这些数据是什么关系。

1. 无序列表 <ul>：并列关系

这玩意是干嘛的：
当一组数据完全不分先后顺序时使用。比如导航菜单、商品标签。

怎么写：
用 <ul> (Unordered List) 划定区域，数据必须包裹在 <li> (List Item) 中。

<!-- 导航菜单 -->
<ul>
  <li>首页</li>
  <li>关于我们</li>
  <li>联系邮箱</li>
</ul>

效果：

核心定律：只要元素的顺序打乱也不影响对整体内容的理解，就应该用 <ul>。

2. 有序列表 <ol>：步骤与排名

这玩意是干嘛的：
当且仅当数据必须按照特定顺序展示时使用。比如操作步骤、排行榜。

怎么写：
用 <ol> (Ordered List) 划定区域，数据依旧包裹在 <li> 中。

<!-- 操作步骤 -->
<ol>
  <li>点击右上角登录</li>
  <li>输入验证码</li>
  <li>完成绑定</li>
</ol>

效果：

3. 描述列表 <dl>：键值对映射

这玩意是干嘛的：
专门用来展示术语 + 解释的问答关系。实际业务中常用于 FAQ 详情解答或电商商品参数说明。

怎么写：
这需要一套组合拳标签。

• <dl> (Description List)：声明描述区域。
• <dt> (Term)：你要解释的术语。
• <dd> (Definition)：对术语的具体解释文字。

<!-- 商品参数 -->
<dl>
  <dt>保质期</dt>
  <dd>冷藏保存1个月</dd>
  <dd>冷冻保存6个月</dd> <!--  一个术语可以对应多条解释 -->
</dl>

效果：

常见错误：浏览器默认会给 <dd> 加上视觉缩进效果。绝不要为了白嫖这个缩排效果去滥用 <dl>。样式排版交给 CSS，标签只负责数据关系。

4. 嵌套列表：层级结构

当列表的某一项内容里还需要包含次级列表时，必须遵守唯一的嵌套规则：子组件列表必须完整包裹在一个父级 <li> 标签内部。

<ul>
  <li>前端语言
    <!--  正确做法：子列表完整包裹在 li 内部 -->
    <ol>
      <li>HTML</li>
      <li>CSS</li>
    </ol>
  </li>
  <li>后端语言</li>
</ul>

效果：

常见错误：千万不能在 <ul> 里直接塞入一个 <ol> 或另一个 <ul>，<ul> 和 <ol> 的直接子元素只能且必须是 <li>。

总结：

• <ul> = 无序并列（打乱顺序也不影响理解，如导航栏、商品平铺）
• <ol> = 有序步骤（必须按先后排布，如排行榜、操作步骤）
• <dl> = 键值对映射（解释名词短语、Q&A问答，必须配合 dt 和 dd）
• 铁律：<ul> 和 <ol> 的直接儿子只能且必须是 <li>！

➡️ 下期预告：

掌握了列表的“结构语义”后，如果你遇到需要特殊排版的文字片段，该怎么办呢？
比如化学公式的上下标、界面快捷键按键提示、名人的大段引用语……遇到这些场景怎样写才能既少写冗余 CSS，又能让搜索引擎精准抓取？
请看下一章👉 【大白话前端 08】HTML 文本语义化：6 类非 div 标签的速查指南