开源命令行工具

核心要点速览

OpenAI官方推出的命令行界面工具，让开发者无需编写Python代码即可在终端直接调用API接口。这款工具专为技术人员的日常调试、快速功能验证以及API使用量管理而设计，极大简化了开发流程。

项目数据概览

• GitHub星标数：266个
• 项目创建时间：7天前
• 最新发布版本：v1.1.2

一、openai-cli是什么？零基础读懂这款官方命令行工具

简单来说，openai-cli就是OpenAI官方为你打造的一款终端遥控器。在过去，调用OpenAI API要么需要编写Python或Node.js代码，要么就得手动拼接curl命令构造HTTP请求。如今只需安装这个命令行工具，通过简单的指令就能实现全部操作——发起对话、管理文件、查询用量、查看账单，所有功能均在终端内一站式完成。

这款工具的定位非常明确：面向开发者与技术运维人员，而非普通的ChatGPT网页端用户。如果你的日常工作涉及频繁与API交互——例如测试提示词、批量运行补全任务、监控组织级资源消耗——那么这款工具将帮你省去大量编写样板代码的时间成本，让工作流程更加流畅高效。

二、目标用户画像：谁最需要这款工具，谁可以跳过

强烈推荐使用的人群：

• AI应用开发者：需要频繁调用API进行功能测试和调试，快速验证不同提示词和模型行为表现的工程师
• 运维与平台管理员：负责监控组织级API用量、管理月度账单、维护多个项目和密钥的技术管理人员
• 脚本自动化使用者：希望在Bash或Shell脚本中集成AI能力，实现批量内容生成、自动化处理的开发者
• 技术评测与学习人员：想要快速体验对比不同模型输出效果，但不愿意花费时间编写样板代码的研究者

不适合使用的人群：

• 仅通过chatgpt.com网页界面使用AI服务的普通用户，且完全没有API调用需求的人

三、核心功能全面拆解：这款CLI工具能做什么

▸ 资源化的命令结构：采用openai [资源类型] [具体操作] [参数标志]的层级化设计，符合开发者直觉，命令组织逻辑清晰易懂

▸ 多格式输出支持：内置json、yaml、pretty等多种输出格式选项，并集成GJSON转换语法，方便数据解析和管道处理

▸ 智能文件处理机制：独创的@file.ext语法糖，可自动识别并正确传输文件内容，智能判断文本或二进制编码格式

▸ 完整的管理端点覆盖：提供查询组织用量、管理项目配置、验证Webhook签名等全面的后台管理功能

▸ 灵活的API地址定制：通过--base-url参数支持自定义API后端地址，轻松适配代理环境或自托管部署场景

四、三大实战场景：开发者如何真正用上openai-cli

场景一：快速测试新发布模型 每当OpenAI发布新模型时，无需再编写测试脚本，只需执行一行命令即可发送请求并查看效果：openai responses create --model <新模型名称>，验证工作瞬间完成

场景二：批量调试提示词参数 在Shell脚本中使用循环结构多次调用openai responses create命令，通过改变参数组合对比不同配置下的输出质量，大幅提升调试效率

场景三：组织级用量监控 平台管理员可通过单条命令拉取整个组织的API调用数据，按日期或项目维度进行聚合统计，实现账单监控和资源规划的自动化

五、全面对比：openai-cli vs curl vs Python SDK，哪个更适合你

六、项目成熟度评估：openai-cli现状与未来发展

客观评估：openai-cli项目创建于2026年5月1日，截至本文撰写时上线不足10天。仓库已有42次代码提交，来自4位贡献者，获得266个GitHub星标。项目已发布4个版本（最新为v1.1.2），核心的responses create命令及管理功能已可用，但API资源覆盖范围尚未全面。

今天给大家介绍一个极具实用价值的开源工具PandaScrcpy，它能让手机远程控制变得异常简单。完成部署后，您无需在本地计算机配置复杂的ADB环境，仅需使用Chrome或Edge浏览器，通过USB连接Android设备，即可实现投屏显示、远程操控、屏幕录制、快照截取、日志查看以及ADB Shell命令执行等全方位功能。

若从放松娱乐的角度看，这甚至可以成为一个高效的休闲助手。

无论是需要将安卓手机屏幕投射到电脑上进行简单操作、查看日志或截图录屏的普通用户，还是从事安卓应用测试、设备调试以及批量测试的专业开发者，这款工具都能提供显著的价值提升。

核心应用场景

安卓设备画面投射至电脑端

当您需要在电脑大屏幕上展示手机界面、录制操作教程、进行直播演示或提供远程技术支持时，该功能尤为实用。相比传统方式，浏览器端操作更加便捷灵活。

键鼠控制手机操作

连接成功后，您可以直接在浏览器窗口内操控手机，体验与scrcpy高度相似。根据项目文档说明，系统已针对触控操作、键盘鼠标控制进行了焦点管理和指针轨迹优化，确保操作精准流畅。

开发与测试调试专用

内置多项设备端实用工具，包括应用管理器、Logcat日志系统和ADB Shell终端界面，极大简化了开发与测试人员查看系统日志、调试应用程序的工作流程。

屏幕录制与画面截图

支持本地录制手机屏幕动态画面，同时可快速截取静态快照，非常适合制作测试记录、产品演示素材或技术文档配图。

远程画面共享功能

基于PeerJS技术，可将当前手机画面实时分享给其他浏览器端用户，实现远程协作或技术支持场景下的屏幕共享需求。

NAS部署完整流程

本文将以威联通NAS设备为例，详细介绍通过Docker Compose方式部署的完整流程。鉴于原项目未提供官方镜像，我已自行构建并上传至仓库，部署配置如下：

services:  
  panda-scrcpy:  
    image: ydxian/panda-scrcpy:latest  
    container_name: panda-scrcpy  
    ports:  
      - "6527:80"  
    restart: always

在威联通系统的Container Station中创建新的应用程序，将上述配置粘贴即可快速启动。

Web端使用详解

服务启动后，在浏览器地址栏输入NAS_IP:6527即可访问主界面。

若在设备选择区域出现"浏览器不支持WebUSB"的提示，这是因为WebUSB API仅在安全上下文环境中生效。解决方案有两种：配置HTTPS反向代理，或直接通过localhost访问。考虑到远程使用的便利性，强烈建议配置反向代理。

完成反向代理配置后，提示信息将消失，页面功能恢复正常。

但此时点击"添加USB设备"仍无法发现手机，原因是尚未完成手机的开发者模式配置。请使用数据线将手机连接至电脑（Mac或Windows均可），进入手机"设置"应用，滑动至"关于手机"选项，连续点击"软件版本号"七次以激活开发者模式，随后在开发者选项菜单中启用USB调试功能。

完成上述设置后，再次点击"添加USB设备"，此时手机将出现在设备列表中。选中目标设备并点击"连接"按钮。

设备配对成功后，点击"连接设备"按钮建立通信。

此时手机端会弹出授权窗口，如经常使用建议勾选"一律允许"以简化后续操作。

注：部分小米手机如遇控制问题，需在开发者选项中额外开启USB调试（安全设置）权限

连接成功后，界面流畅度表现优秀。默认视图显示设备基础信息，中部功能区提供录屏、截图、音量调节等快捷操作。

应用管理模块可读取已安装应用列表，支持对连接设备执行应用的安装、启动和导出操作。

几天前，PostgreSQL生态的顶级开源备份方案pgBackRest突然宣布停止维护，整个社区为之震动。尽管Pigsty项目同样深度依赖pgBackRest，但并未陷入恐慌——如此关键的基础设施，PostgreSQL生态绝不可能任其消亡。当时甚至承诺若无人接手将主动接盘，如今看来这一备用方案已无需启动。

David Steele在GitHub README发布“维护动态”：归档公告发布后，他的邮箱被海量邮件淹没。众多用户与厂商表达强烈挽留意愿，他本人也倾向继续维护。更关键的是，由多家赞助商组成的资金联盟已基本谈妥，几乎可以确定将获得足额资金支持继续pgBackRest的开发。

预计本周结束前将发布更明确的正式公告。从归档到逆转，仅仅七天。

此事的精髓不在于“开源社区充满爱心”这类空泛感慨。真正值得关注的是：当一项关键开源基础设施被维护者推向死亡边缘时，市场终于开始为其定价。

这是一次极为纯粹的开源公地悲剧倒逼定价实验。

七日时间线全复盘

先把关键节点梳理清楚。

4月27日，David Steele同时在GitHub和LinkedIn宣布停止维护pgBackRest并归档仓库。声明措辞克制，既无抱怨也未甩锅，仅强调两点：一是允许分叉但不得继续使用pgBackRest名称；二是归档不代表生命周期终结，现有代码可用，运行中的部署不会立即崩溃。

第一条声明尤为重要。备份工具并非普通玩具，而是供应链攻击的高价值目标。一个继承原品牌信任度的分叉若落入恶意之手，风险远超想象。要求更名是David离场时最负责任的安排。

同日，Christophe Pettus在thebuild.com发表《Notice of Obsolescence》，给出冷静判断：应将pgBackRest视为“落日部署”，等待可信分叉出现后再重新评估。

同日，Lætitia Avrot发布《pgBackRest is dead. Now what?》，标题直截了当。她的措辞更为尖锐：AI淘金热潮已彻底改变企业预算优先级。大公司愿意为内存、GPU、token一掷千金，却不愿为保障数据库灾难恢复的人付费。

这番话刺耳，却道破现实。

4月28日，Percona迅速响应。Jan Wieremjewicz发表《pgBackRest is archived, what now?》，承诺Percona将继续支持pgBackRest，但呼吁暂勿急于分叉。他们正与其他厂商商讨联合维护或基金会托管方案。文中透露关键信息：Jan在归档前一周的PGConf.DE演讲中曾引用David提出的透明出资模型，希望将维护成本分摊给多家依赖方。

此举至关重要。Percona并未宣布独占接盘，也未抢先分叉，而是率先呼吁协同。对商业供应商而言，这种克制实属罕见。

但无人及时响应。

换言之，David并非未尝试“温和定价”，只是无人买账，最终只能走向归档。

4月30日，Percona再发《Open source doesn’t die. It gets unfunded.》，将问题挑明：pgBackRest并非生命终结，而是维护资金断裂；Percona与其他公司正幕后推动解决方案。

5月1日，PGX抢先行动。Christophe Pettus旗下的PGX Inc.发布《pgxbackup: Continuity Support for pgBackRest》，将pgBackRest分叉为pgxbackup，定位专为其支持客户提供连续性版本，仅修复关键bug并兼容新PG版本。

此举合理却暗藏微妙。Percona刚呼吁“别急着分叉”，PGX三天后就推出分叉。不能指责Pettus不负责任——他必须对客户负责；但这恰恰说明所谓的“社区协调”极其脆弱。只要有一家厂商失去耐心，双轨预期立刻形成。

5月4日前后，David发布维护更新：赞助联盟基本成型，资金大概率到位。他还在寻找另一位维护者分担工作，避免项目再次沦为单点故障。

至此，逆转完成。

当年Linux基金会响应Redis协议变更、发起Valkey，按自然日算约八天，按工作日算约六天。pgBackRest此次无基金会介入、无许可证战争、无共同敌人，仅凭PG圈内协调，耗时七天。

这个速度已属罕见。

谁在为续命买单：公开信号与推测

正式赞助名单尚未公布，但现有信号已能勾勒大致轮廓。

Supabase是目前最可能被视作核心金主。

根据pgBackRest官网及README的赞助商列表，当前赞助商正是Supabase。更关键的是，Supabase在4月的Developer Update - April 2026中宣布开源Multigres Kubernetes operator，该系统直接内置pgBackRest的PITR备份功能。

这已超越“支持开源”范畴，属于产品路线深度绑定。当你将未来押注在某个备份工具上，而该工具突然失去维护者时，不出资谁出资？

以Supabase当前的估值与融资规模，供养一位pgBackRest核心维护者根本不是资金问题，而是是否愿意承担责任的问题。至于它是否为联盟中最大出资方，仍需等待正式公告。

Percona极可能是核心协调方。 Percona已公开承诺继续支持pgBackRest，且其Percona Distribution for PostgreSQL长期将pgBackRest作为推荐备份方案。客户SLA绑定于此，不可能袖手旁观。但具体出资金额与方式，同样待正式披露。目前其角色更像此次协调的组织者之一。

Cybertec、Timescale、Resonate均有可能参与。 Cybertec的容器化PG产品使用pgBackRest；Lætitia的文章也专门指出Cybertec与Data Egret拥有可临时处理pgBackRest问题的专家。 Timescale拥有公开分叉，这是依赖或评估信号，但不足以单独证明Timescale Cloud的备份链路深度绑定pgBackRest。其具备出资能力，但历史上对上游开源基础设施的投入不算特别主动，因此无法完全确定。

Pigsty v4.3 正式亮相。如果说上一版本 v4.2 的核心亮点在于"十二款内核齐发"，那么本次迭代的主题词无疑是"扩展生态密度"。

此次更新将 PostgreSQL 扩展的支持数量从 460 款激增至 510 款，创下历史新高。在操作系统兼容性方面，Ubuntu 26.04 被纳入官方支持列表，同时 Ubuntu 20.04 正式退出历史舞台。此外，Supabase、pgEdge、PolarDB、Grafana、MinIO 等核心组件也完成了集中式版本升级。

跨越式发展：迈入主流开源阵营

在 GitHub 生态中，5000 Star 标志着项目进入主流视野。这一里程碑带来的最直接福利是可获得免费的 ChatGPT / Claude 订阅资格。

Pigsty 近期成功跨越这一门槛，当前 Star 数已达 5066。在 GitHub 全平台中，Star 超过 5066 的仓库约有 11621 个，这意味着 Pigsty 已跻身全球 Top 1 万项目行列，位列前 0.005%。对于数据库发行版这一细分领域而言，Star 的含金量更为显著——按此指标，Pigsty 已成为 PostgreSQL 发行版赛道前三甲，并在 Linux 原生 PostgreSQL 发行版中独占鳌头。

更令人瞩目的是 Pigsty.IO 官网的流量表现。三月份月独立访客尚不足两千万，至四月底已突破一亿大关，其中 99% 以上流量源自 AI/Agent 访问。这表明 Pigsty 网站已成长为主流 AI 模型的关键训练语料和 AI Agent 的重要基础设施。对于个人主导的开源项目而言，这一成就尤为难得。

David Steele 亲笔：十三年心血之作正式落幕

2026年4月27日，PostgreSQL生态系统中最重要的备份解决方案pgBackRest被其创始人David Steele正式归档。

相关声明同时在GitHub和LinkedIn平台发布，措辞简洁而决绝：

pgBackRest已停止维护。若您基于此项目创建分支，请为您的项目重新命名。

经过深思熟虑，我决定终止对pgBackRest的后续开发。这绝非草率之举。过去十三年间，pgBackRest始终是我倾注心血的个人项目；在相当长的一段时间里，我幸运地获得了企业赞助支持，但我也付出了无数深夜与周末的时光，与众多贡献者携手将其打造成今日的模样。每位开源开发者都深知这种状态意味着什么，也明白一个被珍视的项目会在生命中占据何等分量。

自Crunchy Data被收购以来，我仍在持续维护pgBackRest，同时也在寻找能让我继续这项事业的职位，但迄今未果。同样，我为项目争取独立赞助的努力，也远未达到支撑其可持续运营所需的水平。

与所有人一样，我需要维持生计。而与pgBackRest相关的职业机会极为稀缺。如今我可以考虑更广泛的就业选择，但这些工作无法留给我足够时间继续投入pgBackRest。项目的日常维护、缺陷修复、PR审查、问题响应等都需要耗费大量精力，更不必说我真正热爱的新功能开发。与其勉强维持、断断续续地低效运作，不如明确画上句号。

我相信pgBackRest终将出现分支版本。但那将是全新维护者主导的新项目，他们必须像我们当年一样，从零开始重建社区信任。

最后，再次感谢多年来所有为pgBackRest贡献力量的开发者。与诸位共事，是我职业生涯的荣幸。

PostgreSQL社区遭遇重大冲击：当事实标准成为孤儿

对PostgreSQL用户群体而言，此事绝非等闲。pgBackRest早已成为PostgreSQL备份恢复领域的事实标准，更是众多DBA心目中最值得信赖的灾难恢复工具。大量PostgreSQL DBaaS服务均将其作为核心备份方案，Pigsty发行版也默认采用该工具。

pgBackRest将PostgreSQL备份技术推向了极致境界：

• 并行化备份与增量恢复，将恢复时间窗口压缩至最小
• 将原本复杂的PITR（基于时间点恢复）操作简化为单条命令
• 完美解决了备份归档、仓库管理、对象存储集成等棘手问题
• 全量、差异、增量备份，块级压缩与加密，多仓库异步归档，从备库执行备份……几乎所有DBA能想象到的备份需求，它都已实现，且表现稳定、品质卓越

笔者十年前首次为生产数据库选型备份方案时便选择了它，近期重新评估市面上所有活跃方案后，结论依然是它。当年2.0版本发布时，我甚至手动翻译了其完整文档。上个月刚借助Claude将相关文档连同Patroni、PgBouncer一起重新翻译了一遍。

这个工具我已稳定使用近十年，对其信赖有加。如今唯一的维护者却将仓库归档了。

资本游戏下的牺牲品：Snowflake收购Crunchy Data始末

David在告别信中说得直白：他未能筹集到足以维系开发的经费。

David此前担任Crunchy Data的架构师，这是一家专业的PostgreSQL服务提供商。2025年6月，数据湖仓领域的巨头Snowflake以2.5亿美元收购了Crunchy Data。

收购完成后，David花费数月时间试图在新东家或其他地方寻找能延续该项目的岗位，但最终失败。他也曾尝试独立筹措赞助资金，但距离维持生计的目标差距甚远。他需要养家糊口，因此选择果断终止，而非敷衍了事。

这里存在一个令人不安的事实：Snowflake是当前数据基础设施领域市值最高的企业之一，公开宣称要打造"AI原生Postgres"，斥资2.5亿美元收购Crunchy。但从结果看，却未继续支持David维护pgBackRest。一家小公司尚能承担的开发者成本，进入大公司后反而无法覆盖。

若此推测属实，其行为的短视程度远超商业理性的范畴。Snowflake节省的成本微不足道，却亲手抽掉了PostgreSQL生态最关键的承重支柱之一，这并非精明的商业决策，而是吃相过于难看。

本轮AI淘金热潮已彻底重塑企业预算清单。采购内存、GPU、tokens等投入能讲出清晰的ROI故事；而雇佣一名确保数据库崩溃后可恢复的专家，却无法量化回报——“坏事未发生"在董事会面前等于零价值。

社区大讨论：开源项目生死劫的三重困境

事件发酵数日以来，PG社区已沸腾：Hacker News上超过200分的讨论串、各大厂商博客的连续回应、邮件列表中"接下来怎么办"的激烈辩论。讨论主要围绕三个层面展开。

第一层：开源可持续性诊断。主流观点认为健康模式应形成良性循环：“企业投资工程师→软件创造价值→用户购买商业支持→企业再投资”。pgBackRest的困境在于该闭环未能建立——仅依赖单一公司工程师维护，未形成多厂商商业支持网络。一旦该公司被并购或战略调整，整条链路即时断裂。

**第二层：是否立即分叉。**大厂态度高度一致：暂缓分叉。 “不应出现十个分叉、每个仅一人维护"的碎片化局面才是最差结果。Linux Foundation推出Valkey替代Redis耗时六天紧急协调，多厂商共治事宜，慢而稳优于快而乱。

**第三层：分叉命名问题。**David在声明中明确表态：“我希望它被分叉，但那将是新项目、新维护者，需如我们当初般重建信任。“这意味着新项目不得继续使用pgBackRest名称。

笔者个人支持David的要求，这恰是他离场时最负责任的举措。备份工具是供应链攻击的最高价值目标之一：一个被广泛信任的备份程序若在升级中被植入恶意代码，可获取几乎所有部署实例的核心权限，接触全部历史数据。将"数千星标积累的信任"直接转让给未知继任者不是慷慨，而是不负责任。强制分叉改名，是促使用户重新进行信任评估，此乃安全工程的基本准则。

亲历者视角：pgBackRest的未来何去何从

笔者得知此消息时深感遗憾。

作为pgBackRest的深度用户，若无人接手，我本人也愿意扛起维护重任。

此前我已接手MinIO的维护，因自身需求在原厂放弃后fork维护至今。我认为在不新增功能的前提下，接手pgBackRest维护并非不可行。

不过，我认为pgBackRest未必会走到那一步，其未来存在几种可能路径。

可以确定的是，5月温哥华PGConf.Dev大会极可能将此作为核心议题讨论。涉及PG生态主要厂商核心利益的工具，社区不会坐视不管。

现实预期是，社区协商产生新分叉，类似Redis改协议后社区另立Valkey。鉴于不可沿用原名，新项目可能命名为pgbackrest-ng、pgbacknext或其他。此方向的关键在于需要一家或多家厂商作出长期承诺并达成共识。

较坏情况是，既无牵头者，也未进PGDG，厂商间未达共识，陷入"各维护内部fork"状态：Percona一份、EDB一份、各云厂商一份。此结局最糟糕，真正的"Fork战争”。

最理想结果是PGDG内核团队接手，作为contrib模块或纳入PGDG全球开发组项目集。但实话实说难度较大，且其他备份工具维护者未必乐见。

当前现状是，Percona已明确表态将继续为自家客户提供pgBackRest支持。这意味着至少在企业客户层面，pgBackRest不会立即失去所有支撑。Crunchy现有产品与文档仍深度集成pgBackRest，但截至目前未见其对项目长期维护作出新的公开承诺。

笔者也在此明确表态：若无他人维护，我将自己接手。当然若他人维护得当，我也乐见其成为上游，专注验证、打包分发及用户反馈。

用户行动指南：冷静评估而非恐慌性迁移

短期来看，我给诸位PostgreSQL DBA的建议是：若您正在使用pgBackRest，无需过度担忧。切勿恐慌，更无需急于迁移。

pgBackRest是极其成熟的软件，归档的是代码仓库——不再接受PR、不再修复bug、不再发布新版本，但代码本身依然存在，今天运行良好的系统，明天仍可继续运行。

当前使用pgBackRest会有什么问题？ 如果您一直使用PostgreSQL 18配合pgBackRest v2.58，这套组合可运行至天荒地老。

风险的出现需要时间，可能是数月乃至数年后。例如今年9月PG19发布，或后续大版本引入需适配的内核改动，抑或对象存储、依赖库、安全漏洞需要后续修复时，问题才会显现。pgBackRest当前版本兼容PG18，但新大版本若需内核层适配，或出现必须修复的安全问题，情况将变得棘手。然而这是中长期担忧，而非当下危机。

更重要的是，目前没有任何工具能完全平替pgBackRest的功能完备度：

• Barman（EDB维护）是最可靠备选之一，3.18版本新增云存储块级增量备份能力，但该特性较新，成熟度与一体化体验距pgBackRest尚有差距
• WAL-G是实用的云归档与恢复工具，在K8s/云原生场景应用广泛，但在完整备份仓库治理能力上与pgBackRest并非完全重叠
• pg_probackup（Postgres Professional出品）曾是唯一能在功能维度与pgBackRest抗衡的对手，其块级PTRACK增量备份甚至更激进。但作者公司为俄罗斯背景，2022年后处境复杂；更关键的是该工具历史上曾出现恢复后数据丢失、无效页面等严重问题（如#474[1]、#249[2]）。对备份工具而言，这是致命污点，令我个人在推荐时极为慎重

从一个化学扩展说起

一切始于两天前的一则GitHub Issue。一位用户在使用RDKit——化学信息学领域无可争议的标准库时遇到了难题。虽然该库能在PostgreSQL中实现分子结构存储、子结构检索和相似性计算等核心功能，但PGDG官方打包版本竟然缺失了关键的InChI功能。这位用户花费了大量时间折腾编译参数，最终虽勉强跑通，但仍希望Pigsty能提供原生支持。

RDKit确实是一块难啃的硬骨头。大约两年前我曾尝试将其纳入Pigsty的扩展仓库，目标是从Debian移植到EL系列系统。但现实很残酷：Boost、Eigen、RapidJSON、Cairo等依赖项环环相扣，再加上InChI、Avalon等可选模块，每个组件都有独立的编译开关和操作系统兼容性问题。几番尝试未果后，我只能暂时搁置。

然而这次情况截然不同——Coding Agent时代已经到来。

借助Codex / Claude Code处理这类"构建系统考古"任务堪称降维打击。过去需要反复试错数周的工作，如今只需一两轮对话就能自动完成。在最新版本中，我不仅解决了PGDG打包的InChI支持问题，更将编译参数优化做到了极致。整个流程顺畅得令人难以置信，用户反馈也极为满意。

这种来自开源社区的积极互动总能带来最大的成就感。

趁热打铁

既然构建流程已经跑通，我索性将积压已久的几个"历史遗留难题"一并解决。

plv8扩展首当其冲。这个V8引擎的PostgreSQL绑定之前在EL10上始终无法编译通过，此次通过打上多个补丁终于实现了稳定构建。

duckdb_fdw的兼容性难题也得到了优雅解决。该扩展允许从PG内部直接读写DuckDB文件，但此前会与DuckDB官方的pg_duckdb扩展发生共享库冲突，我不得不暂时将其隐藏。新版本通过将duckdb_fdw作为pg_duckdb的子扩展，共享同一份libduckdb库，彻底消除了冲突，两个扩展终于能够和平共处。

工具链已然成熟，我萌生了一个更大胆的想法：何不将PostgreSQL生态中那些值得收录但一直未能攻克的扩展全部纳入？于是催生了这次史诗级更新——新增32个扩展，更新22个扩展，Pigsty扩展仓库总量正式突破500大关，达到惊人的504个。

完整扩展目录: pigsty.cc/ext[2]

这五百多个扩展的构成颇具深意：约70个是PostgreSQL自带的Contrib扩展，150个来自PGDG官方打包，剩下的330个全部由我个人维护构建。可以说，在PostgreSQL扩展生态这个赛道上，Pigsty已经做到了前所未有的深度和广度。

横向对比更能体现这一成就的分量。主流云服务商如Supabase，在去除PG自带的35个Contrib扩展后，实际提供的第三方PG扩展不足30个。这意味着Pigsty的扩展数量是商业产品的十倍以上。

新扩展全景扫描

本次新增的32个扩展技术密度极高，可归为四大类别：

数据域革命：将化学分子、RDF三元组、BSON、Protobuf、循环日程等复杂对象提升为数据库一等公民，彻底打破传统关系模型的边界。

查询能力跃升：涵盖稀疏线性代数与图算法、Datalog图查询引擎、全文检索增强、混合排序融合、递归SQL模板引擎等前沿能力。

近期AI领域涌现出一种奇特现象：各类数字化角色模板层出不穷，例如同事.skill、产品经理.skill、运营总监.skill乃至销售冠军.skill。这些数字人格包装看似创新，实则暗藏风险——当某个.skill文件宣称"精通刑法与刑事诉讼法"时，你是否真的敢让其承担法律判断职责？

更值得关注的是，有从业者宣称已将顶尖客服或销售专家的能力"蒸馏"为.skill文件。这种说辞在行业内行看来颇具争议，因为所谓"蒸馏"往往仅提取了工作流程中最易自动化、最易结构化的表层环节，而非真正的专业判断力。

透过现象看本质，这类.skill文件复制的并非人类专家的核心能力，而是将其工作流程化、规则化。真正的专业判断源于隐性知识——包括产品细节参数、客户采购习惯、历史成交案例、承诺边界等无法完整写入prompt的复杂信息。

这揭示了一个关键认知：Workflow不等于Judgement。skill文件能指导AI如何执行操作，却无法赋予其理解操作背后逻辑的能力。若要真正"蒸馏"人类专家知识，必须依赖RAG（检索增强生成）技术。

RAG技术核心价值辨析

当前业界对Skills的认知普遍存在偏差，常将其与知识库功能混为一谈。从技术范式角度看：

skill解决的是流程复制，而RAG解决的是知识调用

skill定义操作步骤序列，RAG则提供执行依据——包括参考资料、历史经验及信息溯源。二者结合才接近真正的"能力蒸馏"。

以销售冠军能力复制为例：收集话术、跟进流程、异议处理规则并投喂模型，这仅能复现外显行为。真正的销冠决策依赖五大隐性知识体系：

1. 全产品线技术参数图谱
2. 跨行业客户采购行为模式
3. 历史成交案例库
4. 承诺权限边界清单
5. 竞品动态情报网络

这些无法完整prompt化的隐性知识，正是RAG的核心价值所在。最终结论清晰呈现：

skill负责复刻动作框架，RAG负责补足认知缺口

完整的AI同事能力架构需三层支撑：Workflow层（流程执行）、Knowledge层（知识调用）、Judgement层（复杂权衡）。skill覆盖第一层，RAG支撑第二层，第三层依赖模型能力、业务边界设定与人工兜底机制。

Dify平台实现AI知识库路径

尽管Agentic RAG框架尚未出现理想的开源方案（若NoteBookLM开源将成首选），但基于当前生态，Dify在企业级知识库建设中表现相对均衡：

1. 完整知识库管理闭环
2. 可视化编排体验友好
3. 开源特性保证可控性
4. 支持私有化部署
5. 深度适配企业场景

企业落地AI知识库时，常陷入Dify配置项迷宫：分块策略、索引模式、检索方式、Top K值、Score阈值、Rerank开关等参数相互关联，孤立调整难以奏效。

理解完整技术链路才能理清配置逻辑：

离线阶段：文档解析 → 数据清洗 → 智能分块 → 向量化 → 索引构建

在线阶段：查询接收 → 语义改写 → 多路召回 → 精排过滤 → 上下文拼接 → 生成回答

以AI客服场景为例，解析售后手册PDF后，需准确回答退货时效、SKU特殊规则、大促条款等复杂问题。

传统LLM仅能输出"建议联系客服"等正确但无用的通用回复，而RAG应给出：

根据《售后政策》第3.2条，普通商品签收后7天内支持无理由退货；
SKU-20260315属定制类商品，不适用无理由退货条款；质量问题可在15天内申请售后。

数据入库关键工序拆解

文档解析质量决定天花板

上传PDF后显示的"嵌入处理中"并非简单存储，而是包含四重深度加工：

1. 解析：PDF内含正文、表格、页眉页脚、水印、图片说明、脚注、目录等混杂元素，需精准提取有价值内容。扫描件需OCR识别，易现字符混淆、表格结构丢失、多栏排版错乱等问题。

2. 清洗：去重页眉页脚、版权声明、连续空格、无效URL、邮箱地址等噪音。系统内置清洗能力有限，过期条款、版本冲突、内部备注等业务噪音需人工前置处理。

3. 分块：定义知识检索最小单元，平衡精准度与完整性。过大赛义模糊，过小信息残缺。

4. 索引：构建高效检索结构，支撑毫秒级相似度匹配。

核心原则：知识库效果上限不由模型决定，而由入库质量决定。80%精力应投入数据处理，避免"垃圾进，垃圾出"。

文档格式优先级排序：Markdown > 纯文本 > Word > PDF > Excel > PPT > 扫描件。高要求场景务必预处理文档格式。

Raspberry Pi Connect推出三大实用更新：设备标签分类管理、组织强制双重身份验证，以及移动端屏幕键盘支持

Raspberry Pi Connect作为一款强大的远程访问工具，允许用户通过网页浏览器随时随地连接并管理Raspberry Pi设备。自该服务推出以来，开发团队持续优化功能体验。近期发布的三项重要更新进一步增强了平台实用性，特别是针对采用Connect for Organisations方案管理大规模设备集群的专业团队，带来了更高效的管理能力。

设备标签化管理与智能筛选功能

当组织内部的Raspberry Pi设备数量增长至多台时，快速定位目标设备成为管理效率的关键。本次更新引入的标签系统支持为每台设备分配多个自定义标签，实现精细化分类管理。管理员可按照地理位置（如伦敦、剑桥）、运行环境（如生产环境、测试环境）或具体职能（如销售终端、信息亭）等维度创建标签体系。这些标签将醒目地展示在设备详情页及设备列表的名称下方，便于直观识别。添加或移除标签的操作非常便捷，既可在设备绑定账户时预先设置，也能随时通过设备"设置"页面进行修改，赋予管理员完全灵活的管理权限。

升级后的设备列表顶部搜索框集成了智能文本匹配与结构化筛选双重功能。用户只需输入特定参数加冒号的格式，如model:5筛选型号、memory:4gb匹配内存规格、os:raspios-13指定操作系统版本，或tag:production选择特定标签，系统便会实时动态过滤显示结果。更强大的是，支持组合多重条件进行精准查询——例如输入model:5 tag:production dashboard可快速锁定所有搭载Raspberry Pi 5型号、带有生产环境标签且设备名称包含"dashboard"的设备。此外，在设备列表界面直接点击任意标签，该标签将自动追加到当前搜索条件中，实现一键式快速筛选，极大提升了操作便捷性。

标签功能也已全面整合至Management API接口中，这意味着开发者在创建身份验证令牌时即可预先定义设备标签。这一特性在通过自动化脚本批量部署新设备的场景中尤为实用，能够实现标签的预分配和标准化管理，显著提升大规模设备部署的效率与规范性。

组织级强制双重身份验证机制

Connect for Organisations新增强制性安全策略设置，允许组织管理员统一要求所有成员启用Raspberry Pi ID的双重身份验证（2FA）。在组织管理界面的"设置"标签页下，新增的"身份验证"专区提供了便捷的开关控制。该功能构建了一道坚实的安全防线，有效防范因成员账户泄露而导致的未授权设备访问风险，为组织资产提供企业级的安全防护保障。

当管理员激活该安全策略后，系统将自动启动为期14天的宽限缓冲期。在此期间，尚未配置2FA的成员登录时会看到醒目的提示横幅，清晰显示剩余宽限天数，并提供直达Raspberry Pi ID账户设置页面的快速链接以便立即启用双重验证。已配置2FA的成员则完全不受影响，可正常使用所有功能。宽限期届满后，仍未完成2FA设置的成员将被自动阻断访问权限，直至其完成双重验证配置方可重新进入组织平台。在此期间，这些成员将无法查看或操作任何设备，也无法访问其他组织资源，确保安全策略的严格执行。

若组织后续需要调整安全策略，管理员可随时在设置界面关闭强制2FA要求。值得注意的是，当关闭后再次重新启用时，系统会重置14天宽限期计时器，这意味着管理员可以为成员提供额外两周的配置缓冲时间，灵活应对特殊情况或人员变动需求。

移动端屏幕键盘支持功能

Connect的屏幕共享功能原本就同时支持桌面端和移动端设备访问，但早期版本在智能手机或平板等触控设备上输入文本时，必须依赖外接物理键盘，限制了便捷性。此次更新在屏幕共享工具栏中集成了全新的"Keyboard"虚拟键盘开关，该按钮与原有的Ctrl、Alt、Esc、Tab等快捷按键并列排布。激活此功能后，用户可直接调用移动设备自带的屏幕虚拟键盘进行文本输入，彻底摆脱对额外硬件的依赖，真正实现随时随地的全功能远程管理体验。

立即体验全新功能

Raspberry Pi Connect面向个人用户完全免费使用。Connect for Organisations组织方案则提供长达四周的免费试用期，试用结束后采用基于设备注册峰值数量的按量计费模式，每月结算一次。如需了解标签管理、双重验证配置及其他功能的详细操作指南，建议访问官方文档中心查阅完整说明，或直接登录connect.raspberrypi.com开启使用之旅。

从 Slack 大中华区停摆事件，透视数字时代最易被轻视的基础设施风险

2026 年 4 月 1 日，愚人节的玩笑并未如期而至。

对于成千上万依赖 Slack 开展协作的香港、澳门及内地团队来说，这一天没有丝毫幽默可言。Slack，这款被视为海外版飞书与钉钉的协作工具，给用户留下了一份冰冷的“愚人节礼物”。

清晨，用户打开 Slack，迎接他们的不再是同事间的日常问候，而是一行冷酷无情的系统提示：你的工作区已被停用。经年累月沉淀下来的组织记忆——所有消息、文件、频道和工作流程——瞬间变得遥不可及。一位名为胡老板的朋友因此焦头烂额，不得不匆忙转战 Discord，试图在一片混乱中重建与客户的连接。

整个过程没有商量的余地，没有平缓的过渡期，数据直接进入了删除倒计时。

一、事件始末：一纸通知背后的冰火两重天

早在 2025 年 11 月，Salesforce 旗下的 Slack 便向大中华区用户发出通告，解释由于 Salesforce 与阿里巴巴在 2019 年达成的战略合作，Slack 将不再直接续签该区域的订阅服务，用户需在 2026 年 2 月前自行做出安排。（信息来源：The Information 报道[1]；Hacker News 讨论帖[2] 中亦包含两封内容截然不同的通知邮件全文）

https://news.ycombinator.com/item?id=45961519[3]

然而，不同体量的用户收到的却是冰火两重天的信件。

大客户收到的邮件中，尚有一条出路：通过阿里云的经销商（reseller）继续购买 Slack 服务。而小团队面对的则是一封纯粹的告别信，信中明确写道：“你的服务将于 2026 年 2 月 1 日终止，工作区及全部数据将在停用后 90 天内予以删除。”这意味着没有任何替代方案，也没有任何可操作的迁移路径。（HN 用户贴出的小团队终止通知原文[4]）

2026 年 4 月 1 日，工作区被实质性关闭。众多用户在 Reddit 上反馈：当日登录时发现工作区已被锁定，而在此之前未收到任何形式的通知。更确切地说，通知仅被送达至工作区的 Owner 与 Admin，普通成员完全被排除在通知对象之外；而即便是 Owner 和 Admin 群体，也有大量人员声称从未见过那封邮件。（gizchina 报道[5]；yage.ai 长文分析[6]）

硅谷新潮流：Tokenmaxxing现象深度剖析

某位企业主最近养成了在社群中炫耀Token消耗量的习惯。他时常截图展示单日数亿Token的使用记录，并配文"完了，又有新想法了"——时而搭建本体论数据库，时而用Go语言复刻项目。那种自豪感，宛如在朋友圈晒跑步里程，让人哑然失笑。

科技巨头的隐秘竞赛

上周，Meta内部名为"Claudeonomics“的排行榜意外曝光。这个名称颇具讽刺意味——用竞争对手Anthropic的产品命名自家榜单，堪称当代行为艺术。

该榜单覆盖Meta 8.5万名员工，30天累计消耗超60万亿Token。榜首员工月均烧掉2810亿Token，系统还设置了从青铜到翡翠的勋章体系，头衔涵盖"缓存巫师"到"会话不朽者”，顶级称号为"Token传奇"。

颇有些传奇色彩。

刷榜手段层出不穷：有员工让AI Agent空转数小时执行"研究任务"以累积消耗量。消息泄露仅两天，Meta便紧急关闭该榜单，留下一句耐人寻味的公告：“初衷是娱乐，但数据外泄，暂停服务。”

Meta并非孤例。OpenAI内部也有类似机制，曾有员工周消耗达2100亿Token。硅谷将这种现象命名为Tokenmaxxing——Token最大化运动。

行业领袖纷纷表态支持。黄仁勋在GTC大会上宣称，未来每位工程师都应拥有相当于年薪一半的年度Token预算；若50万美元年薪的工程师一年烧不掉25万美元Token，他会"极度不安"。Shopify CEO更直截了当：拒绝使用AI就请离职。据内部人士透露，某些公司已设立每周AI使用量的硬性门槛，未达标者面临淘汰。

一场新型办公室政治运动就此轰轰烈烈展开。

古德哈特定律的幽灵

在管理学领域，这种现象有经典定义——古德哈特定律：

当某个指标沦为考核目标时，它便失去作为指标的价值。

Token消耗量作为过程指标，被用作衡量"AI使用深度"与"生产力提升"的代理变量，从提出到腐败耗时不足一个季度，可能是管理学史上崩坏最快的KPI之一。

沃顿商学院教授Ethan Mollick援引了Steven Kerr 1975年的经典论文《论奖励A行为却期待B结果的愚蠢性》。企业真正追求的是生产力跃升，奖励的却是Token消耗量，二者间的因果关系从未被验证。大家默认"用得多=用得好"，便开始搞排名竞赛。

消耗Token何其简单。指令AI"编写一个操作系统，未完成不得停止"，并行运行数个实例，一日之内可耗尽任意数量Token。若规则是"消耗多者胜"，实习生也能在榜单上碾压Linux之父。

这与用代码行数评价程序员能力有何区别？执行一次npm install就能引入数百万行代码到项目，提交至GitHub后，难道就能证明自己比170万行代码的PostgreSQL项目更厉害？

正规软件公司早已摒弃代码行数考核，这种指标只会让内行笑掉大牙，却恰好迎合了外行管理者的偏好。比喻再贴切些，这无异于用油耗量评判赛车手水平。

隐藏的受益者

深思一个问题：Tokenmaxxing的最大赢家是谁？

答案显而易见：AI服务商与云厂商。

Ramp数据显示，企业Token支出自2025年1月起增长13倍。黄仁勋鼓吹Token预算，本质是在推销自家GPU。Sam Altman畅想"全民基本算力"，实则为未来向每个人收取"电费"铺路。

这是一场卖铲人激励众人疯狂购铲的游戏。每个Token都对应真实的GPU算力与电力消耗。空转的Agent不创造价值，却产生实实在在的成本。将Token浪费在无意义任务上，如同打开水龙头看着水流便自我安慰"我在用水"一样荒诞。

这种表演式消费确实放大了AI需求泡沫的信号。CNBC曾专题探讨：若硅谷企业的AI用量中有相当比例源于刷榜，华尔街所见的需求增长数据又有多少是真实的？

尽管如此，这仍是一场真实的生产力革命。Tokenmaxxing虽掺杂水分，但AI Agent的价值创造能力毋庸置疑。泡沫终将破灭，趋势不可逆转。

Token的价值标尺

以每月450美元的MAX订阅为例，可撬动价值约2.2万美元的算力。真正的使用者不会刻意关注Token消耗，而是专注于产出。最近这些Token被用于：收录40余个PG扩展，修复移植老旧扩展，将Pigsty可用扩展数提升至503个。

同时接盘了濒临废弃的开源项目MinIO（千星级别、万级下载量，曾登上HN头条），翻译PG官网并收录500个扩展，整理重要生态项目的文档。这些都是可验证的价值产出，订阅费物超所值。

核心在于：每项工作都有明确、可验证的交付物。扩展收录数量一目了然，翻译质量读者立判，代码能否运行由CI验证，影响力则体现为Star数与PV/UV数据。

文档站点月PV已达6000万（大部分来自Agent请求）

反观Tokenmaxxing选手：让AI"写个数据库"跑整夜生成垃圾代码，或执行"深度研究"空转数小时产出无人阅读的报告。Token计数器狂转，rm -rf也频繁运行。这不是使用AI，而是能源浪费。

带着目标使用工具，还是为使用工具而制造目标？ 前者是生产力，后者是行为艺术。

个体与组织的结构性矛盾

道理都懂，为何Tokenmaxxing仍在大厂盛行？

个人使用AI是产出驱动的，产出质量心中有数，无需代理指标，无法自我欺骗。

组织却陷入困境。平庸管理者无法直接感知每个成员的产出质量，必须依赖可量化的中间指标进行考核激励。而这些指标恰恰最易被操纵，这是科层制的结构性缺陷。代码行数、PR数量、会议时长，如今轮到Token消耗量，不过是同一剧本的不同演员。

平心而论，企业从0到1推广AI使用的初衷可以理解，许多人确有惰性需要推动。但一旦演变为榜单与考核，必然走向荒谬。

这种管理无能终将只是过渡阶段。正如正规软件公司迅速抛弃代码行数考核，未来衡量AI使用效果的方式必将回归本质：你用这些Token创造了什么、交付了什么、节省了多少时间与成本。

至于热衷炫耀Token消耗量的朋友，只想送上一句：

别秀油耗了，不如晒晒你到哪了。