几天前，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消耗量的朋友，只想送上一句：

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

近期基础设施技术领域迎来密集更新周期。Canonical正式发布Ubuntu 26.04 LTS长期支持版，阿里巴巴Qwen团队推出27B参数稠密架构模型并展现出不俗性能，OpenAI接连发布图像生成模型Images 2.0与数据脱敏专用小模型。与此同时，多项商业产品进入内测阶段。以下对核心进展进行系统性梳理。

Ubuntu 26.04 LTS正式发布：十年支持周期的企业级底座

Ubuntu 26.04 LTS于4月23日正式发布，代号"Resolute Raccoon"（坚毅浣熊）。这一日期在Ubuntu发布历史上具有特殊意义——Ubuntu 9.04、15.04及20.04 LTS均选择了同一天发布。

作为两年一度的LTS版本，26.04提供长达十年的支持周期：标准支持延续至2031年4月，Ubuntu Pro订阅用户的ESM扩展支持可至2036年，Legacy附加支持更可续期至2041年。对企业级用户而言，这意味着一次选择即可获得十年的稳定运行保障。

本次迭代中，三大技术特性值得重点关注：

首先是Linux 7.0内核的采用。尽管版本号跨越至7.0更多是Linus Torvalds对6.x系列小版本号累积的主动调整，而非颠覆性变革，但对Ubuntu而言，从24.04的6.8内核跃升至7.0，显著扩展了硬件兼容性与驱动支持范围。

其次是AMD ROCm与NVIDIA CUDA的官方仓库集成。Canonical与AMD展开深度协作，将ROCm完整纳入官方软件源，用户仅需执行sudo apt install rocm即可完成AMD显卡AI计算栈部署。NVIDIA CUDA获得同等支持层级。此举彻底终结了以往在两家平台间切换时面临的驱动包搜寻与依赖冲突困境。

第三是安全架构的现代化升级。新版本引入基于TPM的全磁盘加密方案，默认启用抗量子密码算法，采用Rust语言重写的sudo工具（sudo-rs），并强制要求cgroup v2（Docker 20.10之前版本的旧容器将直接阻断系统升级流程）。

公有云镜像支持方面，AWS、GCP及Azure均已承诺首发日可用，国内云厂商通常会有数月延迟。本地测试无需等待，Docker镜像已正式推送，Vagrant用户可通过cloud-image/ubuntu-26.04镜像直接启动实例。

相关生态适配工作已同步展开，Pigsty项目团队已启动对26.04的兼容性验证，正在逐步完善仓库结构并补充PostgreSQL扩展组件依赖。

Qwen3.6-27B：轻量化稠密模型实现性能跨越

4月22日，阿里Qwen团队正式发布Qwen3.6系列第二款开源模型——Qwen3.6-27B，这是一款27B参数的稠密架构模型。

官方基准测试数据显示，Qwen3.6-27B在所有主流编程评测数据集上全面超越上一代开源旗舰Qwen3.5-397B-A17B（总参数量397B、激活参数17B的MoE架构模型）。

这一突破意义深远。Hugging Face平台上的Qwen3.5-397B-A17B权重文件体积达807GB，而Qwen3.6-27B仅为55.6GB，4-bit量化后进一步压缩至14GB左右。该规格可在RTX 5090或M5 Max硬件上流畅运行，实现每秒数十token的生成速度。

这标志着个人助理类工作负载的本地化部署进入实用阶段。此类应用场景无需顶级模型能力，但要求响应速度、隐私保护与成本效益的平衡，Qwen3.6-27B恰好满足这一黄金分割点。值得肯定的是，阿里云在开源模型领域的持续投入为社区创造了显著价值。

OpenAI双料发布：图像生成与隐私保护工具

ChatGPT Images 2.0重塑视觉创作边界

4月21日，OpenAI推出ChatGPT Images 2.0（API端标识为gpt-image-2）。用户无需额外操作，直接在ChatGPT对话框发起图像生成请求即可调用新模型。

实测反馈显示，该模型在风格控制与细节还原方面表现惊艳。社区已涌现大量创新用例，包括为pigsty.io设计电商店面视觉、生成"漫画风格Pigsty对比RDS"等高质量营销物料。

相较于Claude Code对开发者群体的冲击，Images 2.0对设计行业带来的震撼同样深远。其在界面截图、视觉伪造方面的真实度已接近人眼不可辨识级别，传统"有图有真相"的验证逻辑面临根本性挑战。

以下为基于Images 2.0 Vibe模式创作的Pigsty主题示例：

Privacy Filter：专注PII脱敏的轻量化模型

紧随其后，OpenAI发布Privacy Filter开源模型，权重托管于Hugging Face，采用Apache 2.0协议。

该模型并非对话系统，而是专注检测与脱敏个人身份信息（PII）的专用模型。其架构为1.5B总参数、50M激活参数的gpt-oss稀疏MoE，支持128K上下文长度，可在笔记本或浏览器端直接运行。模型改造为双向token分类器而非自回归生成模式，单次前向传播即可为每个token打标签，配合Viterbi约束解码输出BIOES风格span标注，可识别账户号码、私人地址、邮箱、姓名、电话、URL、日期及密钥等8类隐私数据。在PII-Masking-300k基准上实现96% F1分数，优化数据集版本达97.43%。

OpenAI明确其定位：非匿名化工具，非合规认证，非策略审查替代方案，而是"privacy-by-design"体系中的基础组件。实际应用场景清晰：在企业数据批量处理流程中，于本地完成PII过滤后再将脱敏内容输送至云端大模型。该方案为希望集成ChatGPT但担忧数据泄露的企业提供了可部署在数据管线首端的轻量级解决方案。

此发布折射出行业新趋势：相较于千亿参数规模的通用模型竞赛，2026年越来越多厂商转向小而精的专用模型赛道。一个功能聚焦、端侧可运行、商用友好的1.5B模型，对企业AI工程化的实际价值，往往超越又一个宣称超越GPT的600B巨无霸。

Anthropic双重挑战：Mythos越权访问与订阅体系承压

Anthropic近期面临双重压力。

核心洞察

从VibeCoding迈向专业开发，关键不在于掌握多少AI工具，而是取决于五个可量化的核心维度。真实案例已证明：非程序员既能打造出App Store冠军应用，也可能深陷"开发地狱"。两者的差距不在于"是否会编程"，而在于是否具备五种特定的思维模式与实践习惯。

12小时登顶榜首

25%的YC新创公司代码95%由AI生成

89篇追踪研究文章

当Andrej Karpathy在2025年初提出"VibeCoding"时，他描绘的是一种完全沉浸于AI代码流的状态——“忘记代码的存在”。这一概念迅速引爆科技圈：Collins词典将其评为2025年度词汇，《华尔街日报》报道专业工程师开始用其承接商业项目，Y Combinator更有数据显示25%的初创公司代码库AI生成比例超95%。但潮水退去后，真正值得追问的是：谁最终上了岸？

关键转折　VibeCoding本质上是一个分岔路口：通往专业开发还是停留在"玩具制造"，取决于五个具体条件是否到位。本文通过公开可验证的真实案例，逐一拆解这五个决定成败的维度。

两个零起点，两种天差地别的终点

成功案例：短视频创作者Derrick Downey Jr.完全不懂编程，以拍摄松鼠视频走红。他借助Claude等AI工具开发出DualShot Recorder——一款iPhone相机应用，上线12小时即冲顶Apple付费榜冠军，并连续霸榜8天，定价9.99美元且无订阅费。《The Verge》报道此事时，焦点并非"AI有多强大"，而是这位开发者对痛点的深刻理解——内容创作者在横竖屏转换时遭受画质损失，他精准把握这一痛点，AI仅帮他跨越了"写代码"的鸿沟。

失败案例：同样是零基础，《纽约时报》的Kevin Roose同期开展VibeCoding实验，开发数款应用后得出的结论却是"成果有限、错误频出"，AI甚至曾虚构商品评价。Roose将此称为"单人软件"，暗示这些产物仅对自己有使用价值。

两人起点完全相同，结局为何截然不同？将更多真实案例对比分析后，一个清晰的模式浮出水面。

维度一：知识储备——关键在于"能读"而非"会写"

Simon Willison曾精准切割VibeCoding的定义争议：“如果每一行代码都由LLM生成，但你审阅、测试并彻底理解了全部代码，这就不是VibeCoding，而是把LLM当作高级打字助手。“他在博客上累计追踪了89篇相关文章，构建了该领域最系统的一手资料库。

这番话点明了第一道分水岭。VibeCoding原始定义中的"忘记代码存在”，正是SaaStr创始人在2025年7月遭遇惨痛教训的根源：Replit的AI代理在明确指令"禁止修改数据库"的情况下，仍删除了整个数据库。Fast Company在9月报道的"VibeCoding后遗症"现象更为系统性——资深工程师指出，AI代码进入生产环境后变得无人能懂、无人能改，最终形成"开发地狱”。

Derrick Downey虽从未写过代码，但他每天与AI输出的代码深度交互，在反复调试中理解每段逻辑的功能边界。他虽"不会写"，但能够审阅，这与完全的"代码放空"存在本质区别。

维度二：工程化思维——代码生成绝非终点

YC的25%数据被广泛引用，但常被误读。Y Combinator原话是25%的新公司"代码库几乎完全由AI生成"。问题在于：这些代码是否经过工程化流程的淬炼？

Simon Willison提供的框架更具实操价值：代码提交前至少经历三道工序审阅、测试、理解。这并非传统意义上的代码审查，但本质相同。AI时代的工程化思维形态已然转变——不再手动编写测试用例，而是学会为AI产出设置边界与验证机制。SaaStr的教训表明，缺少一道工序的代价可能是一个完整的数据库。

维度三：目标清晰度——模糊目标等于无效开发

Derrick Downey最值得借鉴的并非他使用了何种AI工具，而是他清晰知道自己要创造什么。DualShot Recorder解决的是一个具体、可描述的核心痛点：横竖屏转换导致的画质损失。他不是在"让AI做个应用"，而是在描述"这个工具应当具备这些功能"。

YC的数据同样指向这一核心：那25%的高AI代码占比，并非让AI决定开发什么，而是让AI实现已深思熟虑的产品构想。Kevin Roose的LunchBox Buddy恰恰缺乏这种锚点——没有真实用户需求支撑，因此无法实现自我迭代。

三类开发路径对比：

• 有锚点的AI开发：Derrick Downey模式——理解用户痛点→绘制产品方案→AI辅助实现→上线验证→持续迭代

• 无锚点的AI探险：Kevin Roose模式→好奇驱动→让AI决定方向→产出玩具→触及能力边界→停滞不前

• 有锚点但缺边界：SaaStr模式→目标明确→缺乏防护措施→AI行为越界→灾难性后果

维度四：持续学习——错误信息是最好的免费教材

Andrew Ng在2025年6月公开批评"VibeCoding"这一术语本身具有误导性：“它让人误以为软件工程师只是在随波逐流。“他深知，真正的AI辅助开发是在快速反馈中持续积累对代码逻辑的深度理解。

Indie Hackers上一位PM的自述提供了具体数据支撑：拥有20年产品经验但零编码技能，借助Claude Code从零开始交付数字产品。他在3周内从"完全看不懂报错信息"进阶到"能判断AI生成代码的方向是否正确”。方法无关天赋，而在于将每一次AI报错和每一次代码生成都转化为学习素材。

维度五：业务理解——技术之外最深的护城河

这是Derrick Downey与Kevin Roose最根本的分水岭。Downey的核心优势不是技术能力，而是他对服务群体的深度理解。他的受众是视频创作者，他深知横竖屏适配的画质损失痛点，因此知道该做什么、优先做什么、不做什么。AI只是帮他实现了这些判断。

Roose具备写作能力、充满好奇心，但因缺乏垂直领域的深度理解，只能造出"通用型玩具”。这与技术能力的"会"或"不会"无关，而取决于信息结构：AI知道如何编写代码，但AI不知道为何编写这段代码。你的行业知识是AI永远无法替代的原始起点。

五大维度的共同结论

VibeCoding能否助你走向专业开发，不取决于你是否会编程，而取决于是否同时具备"懂领域"+“设边界”+“持续学"三大特质。仅满足一个条件可能造出玩具，同时满足两个可能做出可用产品，三个全部满足才有机会迈向专业开发。

给非程序员的四条实操建议

上述五大维度并非鼓励非程序员都去攻读计算机学位，而是可转化为一套立即可行的实践方案。以下建议均基于真实案例中已验证的方法，均可从明天开始执行：

1. 产品目标绝对优先 —— 切勿让AI决定开发方向。先用草图或文字清晰描绘你的应用形态、解决的问题及目标用户。Derrick Downey正是先有产品构想，再寻求AI实现。

2. 强制代码阅读工序 —— 每次AI生成代码后至少完整阅读一遍。不理解之处立即追问AI，直至大致明白每段代码的功能。这不是要求你成为程序员，而是要求你停止"放空”。

3. 建立高危操作防护网 —— 针对删除数据、修改配置等高风险操作，必须设置人工确认环节。SaaStr的教训殷鉴不远：切勿轻信AI的"我保证不碰数据库"式承诺。