5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
2026-06-10 发布 Claude Fable 5 2026-05-29 发布 Claude Opus 4.8 价格和opus4.8 两倍 价格来源： Pricing - Claude API Docs Fable is the most capable model and draws down usage 2× faster than Opus Fable 是功能最强大的模型，其使用量比 Opus 快 2 倍 客户端/终端已可用 模型能力对比 3 个帖子 - 3 位参与者 阅读完整话题
今天偶然看到一个佬友成功申请的帖子，按照帖子的步骤，终于申请成功了，之前申请搞了半天都是abc（万恶的abc ），总结下来，网络占很大的原因，之前是用公司网络和家庭带宽，结果都不行，还试着开vpn尝试，无一例外全部失败，甚至QQ邮箱因为过多申请被禁止使用了，于是选择了163邮箱，参考帖子如下， https://linux.do/t/topic/2189248 。最后，问下各位佬友，拿到账号之后要升级吗？怎么开服务器哇，目前就想搞一个vps和挂个个人网站用 14 个帖子 - 8 位参与者 阅读完整话题
在高端iPhone产品线里，苹果上一次正式使用Touch ID指纹识别功能，还是在2017年发布的iPhone 8和iPhone 8 Plus两款机型上。 从iPhone X开始，所有定位高端的iPhone机型全部标配Face ID人脸识别方案，指纹识别就从高端产品线的功能列表里彻底消失了，这一用就是接近八年时间。 但是到了今年，即将发布的苹果首款折叠屏iPhone Ultra，将会重新回到指纹识别的怀抱，直接放弃这么多年一直沿用的Face ID生物识别方案。 这款新机虽然被冠以定位顶级的Ultra之名，却没有配置以往高端iPhone标配的Face ID，不少网友得知这个消息之后都感觉十分费解，完全摸不清苹果的产品设计逻辑。 知名苹果产业链分析师郭明錤给出了明确答案，苹果之所以主动抛弃用了多年的Face ID，完全是被折叠屏机身的内部空间限制倒逼做出的选择。 虽然苹果能把全套Face ID组件塞进去年发布的超薄机型iPhone Air里，但是iPhone Ultra的整机厚度比iPhone Air还要薄，单边机身厚度仅有4.5mm，内部空间的紧张程度远超以往所有机型。 退一步说，即便苹果想方设法把Face ID塞进了更薄的折叠机身里，也需要占用双倍的空间资源，因为iPhone Ultra是两块独立屏幕，内外屏各自都需要一套完整的Face ID组件才能实现不同状态下的人脸识别解锁。 受限于机身厚度和空间，苹果只能退而求其次，选择回归侧边指纹识别的成熟方案，把省出来的宝贵空间用来塞进容量更大的电池和VC散热板，在续航和散热体验上拿到更多优化空间。 这次折叠屏iPhone放弃Face ID回归指纹识别，本质上并不是技术倒退，反而是苹果为了实现产品形态突破做出的务实妥协。 查看评论
Snippai 0.3.0 本次更新功能包括： 1 、更智能的 Auto 自动模式，目前 Auto 模式现在会返回多个候选项，并支持候选快速切换预览 2 、支持自定义 prompts （欢迎各位尝试和分享好用的 prompts ） 3 、支持使用系统自带的截图工具进行截图 4 、支持自定义模型服务提供商 （强烈建议各位自定义自己的模型服务提供商已获得最佳体验） 5 、支持禁用快捷键 6 、允许设置默认自动复制识别结果还是截图本身 7 、支持截图历史记录保存（测试，后续可能会有大更改，请不要依赖此功能保存重要信息，可能会在后续版本更新中丢掉历史截图） 8 、新增 日程 识别/导出能力 9 、新增拖拽图片分析：可以直接把图片拖入软件进行识别。 10 、新增本地打开图片文件支持：支持通过系统右键菜单分析图片。 11 、UI 界面整体重构，添加更多动画细节 12 、支持更多的操作系统和处理器架构 下载地址： https://snippai.de/ 0.3.0 版本主题曲： 《 Snippai：灵感不坠悬崖》
IT之家 6 月 4 日消息，川崎昨日正式发布了 2027 款 KX327 与 KX327X 越野摩托车，标志着川崎在阔别二十多年后，重返 250cc 以上排量二冲程发动机的研发领域。 受近年来 KTM 250/300SX、胡斯瓦纳、GASGAS、Beta RX 2T 及雅马哈 YZ250 等车型推动的市场需求复苏影响，川崎此次推出的全新车型，反映了二冲程发动机越野车在不受严格排量限制的公开越野赛中的持续受欢迎程度。 新车核心在于川崎首款燃油喷射式 327cc 水冷单缸二冲程发动机，这也是川崎二十多年来首款全新研发的大排量二冲程动力总成。 该发动机采用燃油喷射系统和电子控制技术，相比传统化油器版本，能够在不同海拔和天气条件下提供更稳定的燃油供给，无需繁琐的喷油嘴调整。 川崎声称其搭载了新设计的排气阀系统，配合优化的扭矩曲线，能够提供从极低转速到中段易于掌控的动力输出特性，避免了老式二冲程发动机过于突兀的动力爆发。 川崎此次同步推出了两款设定不同的车型。KX327 为场地越野版，配备密齿比五速变速箱，专注于场地赛道竞技。KX327X 则面向林道和耐力赛用途，搭载六速变速箱，其中一档采用超低齿比以适应低速技术路段，同时配备 21 英寸前轮和耐冲击的 18 英寸后轮。两个版本均标配电启动系统，左手把位设有开关可切换两种动力模式，并采用液压离合器以提供一致精准的操控手感。 车架方面，发动机固定于源自四冲程 KX450F 设计的铝合金环抱式车架上，采用锻造、挤压与铸造铝段组合而成。 得益于二冲程发动机本身简洁轻巧的结构，KX327 的整车干重约为 106 公斤，与川崎 250cc 级别四冲程车型相当。 KX327X 虽配备了六速变速箱、护手、加厚发动机下护板、连杆护罩和后刹车盘保护罩等额外装备，但川崎官方公布的整车重量数据与标准版相同。KX327X 还配备了容量更大的 2.25 加仑（约 8.5 升）半透明油箱，便于骑手观察剩余油量。 悬挂系统采用 KYB 提供的 48mm 空气-油分离倒立前叉，支持压缩和回弹阻尼调节；后悬挂为川崎 Uni-Trak 多连杆结构，配备独立的高速和低速压缩阻尼调节、回弹可调和预载调节功能。 刹车系统采用日信（Nissin）卡钳，前 270mm 碟刹盘，后 240mm 碟刹盘。人机工程学方面，两款车型均提供四种车把位置和两种脚踏位置可供调节，以适应不同骑手的骑行姿态。 此外，车辆支持通过川崎 RIDEOLOGY THE APP KX2 手机应用进行连接，可查看车辆设置、骑行日志以及保养提醒信息。 在美国市场，2027 款 KX327 的建议零售价为 9099 美元（IT之家注：现汇率约合 61767 元人民币），KX327X 为 9699 美元（现汇率约合 65840 元人民币），预计将于 2026 年底开始交付。 日本市场方面，KX327X 的售价为 108.9 万日元（现汇率约合 46201 元人民币），预计于 2026 年冬季左右发售。目前川崎尚未公布该系列车型在欧洲及其他市场的具体上市时间与售价。
本次更新功能包括： 1、更智能的Auto自动模式，目前Auto 模式现在会返回多个候选项，并支持候选快速切换预览 2、支持自定义prompts（欢迎各位佬友尝试和分享好用的prompts） 3、支持使用系统自带的截图工具进行截图 4、支持自定义模型服务提供商**（强烈建议各位佬友自定义自己的模型服务提供商已获得最佳体验）** 5、支持禁用快捷键 6、允许设置默认自动复制识别结果还是截图本身 7、支持截图历史记录保存（测试，后续可能会有大更改，请不要依赖此功能保存重要信息，可能会在后续版本更新中丢掉历史截图） 8、新增 日程 识别/导出能力 9、新增拖拽图片分析：可以直接把图片拖入软件进行识别。 10、新增本地打开图片文件支持：支持通过系统右键菜单分析图片。 11、UI界面整体重构，添加更多动画细节 12、支持更多的操作系统和处理器架构 3 个帖子 - 2 位参与者 阅读完整话题
IT之家 6 月 4 日消息，据外媒 VGC 当地时间 3 日报道，爆料人 Nate the Hate 透露，新一期任天堂直面会“很快”就会到来。 他表示：“现在已经是 6 月，外界都在期待任天堂近期举行直面会。这些说法到底有没有根据？在《星际火狐》《节奏天国》和《斯普拉遁 Raiders》之后，任天堂什么时候会开始谈 2026 年的安排？今年剩下的阵容将会是怎样？答案很快就会揭晓。根据我听到的消息，任天堂直面会将在下周举行，也就是 6 月第二周 。说清楚一点，就是 6 月 8 日开始的那一周。” 如果消息属实，这将是任天堂 9 个月来 首次举行大型综合性直面会 。上一场同类直面会播出于 2025 年 9 月，主题聚焦《超级马力欧兄弟》40 周年。 IT之家从报道中获悉，在那次直面会之后，任天堂还举行过九场发布活动，内容分别聚焦于合作伙伴展示会、独立游戏直面会、宝可梦发布会，或围绕《星之卡比 Air Riders》《Tomodachi Life 朋友收集梦想生活》《星际火狐》和《超级马力欧银河大电影》等单款作品展开。 目前，任天堂正式确认的 Switch 2 第一方新作并不多。其中，只有《节奏天国 Groove》也会登陆初代 Switch，发售日期为 7 月 2 日。 Switch 2 阵容方面，《星际火狐》定于 6 月 25 日发售，《斯普拉遁 Raiders》将于 7 月 23 日跟进，《火焰纹章：万缕千丝》计划在今年晚些时候推出。
几个月前不知道为啥any把我的账户给封禁了，但我当时几乎没有怎么使用any。前些天opus4.8上线，我抱着试一试的心态再次登录any站，没想到成功了。爽！爽！爽！ 1 个帖子 - 1 位参与者 阅读完整话题
“IT早报”时间，大家好，现在是 2026 年 6 月 3 日星期三，今天的重要科技资讯有： 1、多家地方性银行推出微信提现手续费补贴活动，争夺用户零钱存款 广西农商联合银行介绍，活动期间，储蓄卡持卡人访问“微信支付提现笔笔省”小程序，有机会随机领取 1666 元、6666 元额度的广西农商专属提现券，持卡人将微信零钱提现至该行储蓄卡时可抵扣相应额度的提现服务费。>> 查看详情 2、腾讯客服：微信正与华为、荣耀、小米、OPPO、vivo 等合作，通过手机语音助理发起音视频通话或向指定好友发送消息 用户可以通过手机语音助理发起微信音视频通话或向指定好友发送消息。该功能基于 A2A（Agent-to-Agent）协作机制，由厂商 AI 助手向微信发起指令，微信负责执行并返回结果，全程采用双重授权机制，保障数据安全与隐私合规。>> 查看详情 3、我国“玻璃硬盘”率先小规模量产：一片能存 360TB 数据、近乎永久保存，微软前首席研究员也加盟 这张仅 2 毫米厚、看似普通的透明圆盘，一张碟片最大可以存储 360TB 数据，相当于 2.5 万部高清电影。更让人惊喜的是，它的成本只有传统硬盘的十分之一，而且不需要通电，耐潮耐高温。>> 查看详情 4、孙正义时隔 26 年再登亚洲首富：身家突破 1000 亿美元大关，软银市值已超越丰田成日本第一 孙正义身家突破千亿美元，软银因 AI 布局市值超越丰田登顶日本。软银已构建完整 AI 产业链，投资 OpenAI 获高额回报。>> 查看详情 5、中国“三蹦子”全球爆单，欧美市场一辆普通电动三轮车可卖 3000-6000 美元 央视新闻报道提到，锡山区一家给电动车配套电机的企业表示，在过去一年里“催货”已经成为常态。由于订单暴增，为了满足客户的加急船期，“抢舱位”“赶船期”成了行业里最高频的词。>> 查看详情 6、索尼 PS5 第一方新作《战神：劳菲》正式公布，依旧由圣莫尼卡游戏工作室操刀 本作由圣莫尼卡工作室开发，改为以劳菲为主角，战斗偏向高速灵活风格，同时索尼还在推进《战神》真人剧集项目。>> 查看详情 7、微软推出基于安卓的“Project Solara”智能体操作系统，同步展示桌面终端、智能胸牌概念设备 微软在 Build 2026 上发布专为 AI 智能体打造的操作系统“Project Solara”，该系统基于 Android 定制，旨在运行于小型低功耗设备。现场还展示了桌面终端和可穿戴智能胸牌两款概念设备，作为硬件厂商的参考设计。>> 查看详情 8、鸿蒙智行智界神秘新车再曝：俯冲姿态设计，跟 R7 风格完全不一样 博主 @羊驼的睡衣 6 月 2 日发文透露了鸿蒙智行智界品牌的一款神秘新车。他表示，新车很帅，跟 R7 完全不一样的风格，是俯冲的姿态，除了车标没有任何相似的地方。>> 查看详情 9、比亚迪：5 年前投资深汕的决定“无比正确”，第二代刀片电池即在此生产 比亚迪股份有限公司副总裁罗忠良表示，5 年前比亚迪投资深汕的决定“无比正确”。目前，比亚迪深汕产业园一期已全面达产，二期产能稳步提升，三、四期于去年投产，今年 3 月发布的第二代刀片电池即在深汕生产。>> 查看详情 10、消息称腾讯正测试微信 AI 智能体原型，官方已将其列为最高战略优先级 腾讯正为微信测试内嵌式 AI 智能体原型，用户右滑即可调出对话窗口，通过指令调用海量小程序完成点单等任务。此举旨在应对豆包、千问等竞品的迅猛增长，但面临算力供给和成本回收挑战。>> 查看详情 11、QQ 鸿蒙版 App 体验官再招新，新一轮邀测报名开启 据华为官方分享，QQ 鸿蒙版 App 体验官招新，已开启新一轮邀测报名。据介绍，活动名额有限，会优先选取参与积极性最高的前 10000 名用户，通过短信或邮件通知（华为账号需绑定手机方可接收）。>> 查看详情 12、微信鸿蒙版 App 消息通知显示联系人头像功能重启灰度测试 根据用户反馈，微信鸿蒙版 App 正在灰度的功能之一 —— 消息通知显示联系人头像功能目前仍在继续放量，陆陆续续有用户获得了体验资格。不过需要注意的是，也有此前灰度到该功能的用户被收回体验资格。>> 查看详情 13、英伟达 CEO 黄仁勋大赞 Marvell 美满将成下一家万亿美元公司，后者股票大涨 25% 黄仁勋认为，美满将成为“下一家万亿美元公司”，其网络和连接芯片对数据中心至关重要。究其原因，在于数据中心的计算任务会被拆分到数千个相互连接的芯片上运行，而这些芯片需要高速共享数据。>> 查看详情 14、AMD 公布锐龙 AI Max+ 电脑阵容：含小米、海盗船、联想等 AMD 官宣锐龙 AI Max+ 处理器电脑产品阵容，宏碁、华硕、惠普、联想等传统大厂在列，小米、海盗船等新面孔加入引发关注。该处理器拥有 16 核 32 线程、40CU 显卡、50 TOPS NPU，最高可选 128GB 统一内存，主打本地 AI 体验。>> 查看详情 15、长江存储国产致态硬盘官宣出海：打到三星、SK 海力士老家韩国，TiPro9000 华硕吹雪联名版亮相 长江存储（YMTC）旗下零售存储品牌“致态”6 月 2 日宣布启动亚太市场布局，在今年 COMPUTEX 2026 台北国际电脑展期间，首次携三款新一代 SSD 亮相，包括 TiPro9000、TiPlus9100 与 TiPlus7100s。>> 查看详情 16、莲花跑车 CEO 冯擎峰：有车企把跑车做到两吨，说明它对跑车没有理解，只要超过 1.8 吨就是菜车 他表示，不管它马力多大，哪怕是 2000 匹马力，只要重量超过 1.8 吨，就是菜车。“我们也看到一些竞争对手，甚至于跑车做到了两吨，不可思议，说明它对跑车是没有理解的。”>> 查看详情 17、消息称小鹏发起离职人员竞业调查，已有人被索赔近千万 知情人士表示，自其离职起，小鹏集团已按月足额支付竞业限制补偿金。然而，该员工在离职后短期内即加入竞争对手公司，继续从事相关研发工作，涉嫌严重违反协议约定。>> 查看详情 18、消息称苹果 iPhone 18 Pro 国行版打样电池容量约 4056mAh，美版机型约 4288mAh iPhone 18 Pro 电池容量信息曝光，国行版 4056mAh，美版 4288mAh，Pro Max 则达 5000mAh 左右。该机还将升级 2nm A20 Pro 处理器，引入 48Mp 可变光圈，并可能大幅涨价。主打色为深酒红色的“深樱桃”。>> 查看详情 19、消息称红杉资本将收购徕卡相机公司，估值 10 亿欧元并考虑重新上市 黑石集团正与红杉资本谈判出售所持股份，红杉同时有意收购考夫曼家族持有的股份，还考虑让退市多年的徕卡重新上市，官宣或在数周后公布。>> 查看详情 20、BOSS 直聘：有人发“学生兼职”实为诱导大学生违规代抢茅台，已处置超 6000 个违规账号 BOSS 直聘发布专项公告，揭露暑期线上兼职骗局新花样。除了常见的刷单引流，还出现了诱导大学生实名代抢茅台、假借 AI 编剧名义收取押金等新型陷阱。平台已处置超 6000 个违规账号。提醒求职者，尤其是学生群体，警惕高回报低门槛的“兼职”，保护个人信息与财产安全。>> 查看详情 21、《英雄联盟》LPL 第二赛段决赛落地武汉：6 月 13 日华中科技大学光谷体育馆开战，特邀若风、草莓、微笑等 WE 名宿 2026 年 LPL 第二赛段决赛将于 6 月 13 日至 14 日在武汉华中科技大学光谷体育馆举行，胜者将代表 LPL 征战季中冠军赛。现场不仅有激烈对决，还有若风、草莓等 WE 名宿及众多现役选手互动。购票通道 6 月 3 日开启。>> 查看详情 22、比亚迪 5 月销量明细：宋元“两大家族”破 5 万辆，腾势 Z9 系列近 6000 辆 6 月 2 日上午，@小迪快报 公布了比亚迪乘用车 2026 年 5 月的销量明细：王朝 | 海洋 330215 辆，方程豹汽车销售 30186 辆，腾势汽车销售 16303 辆，仰望汽车销售 286 辆，海外销售 160177 辆。>> 查看详情 23、美团 CEO 王兴：外卖行业竞争趋于理性，单纯依靠补贴拉动订单增长的模式难以为继 王兴称，下半年 UE（单均利润）走势仍取决于行业竞争格局的变化。“在行业竞争持续趋于理性的前提下，叠加季节性利好，预计今年二季度 UE 较一季度将出现明显改善。”>> 查看详情 24、美团 CFO 陈少晖回应抖音团购竞争：美团已构筑起无法单纯依靠流量复制的核心竞争力 有分析师问及抖音在到店业务上与美团的竞争，美团 CFO 陈少晖表示，到店业务依托线下履约能力与消费者信任，仅凭流量无法直接转化为实际交易。在这项业务上，美团已构筑起无法单纯依靠流量复制的核心竞争力。>> 查看详情 25、最高降 97.5%：腾讯云智能体开发平台 DeepSeek-V4 系列模型 6 月 3 日起大幅降价，持平官网 腾讯云智能体开发平台宣布，自 6 月 3 日 0 时起，DeepSeek-V4 系列模型价格大幅下调。其中 V4-Pro 缓存命中价格降幅高达 97.5%，V4-Flash 缓存命中价格降幅达 90%。>> 查看详情 26、宇树单款人形机器人累计生产下线约 11000 台 Unitree 宇树官方公众号发文宣布：截至 2026 年 5 月，宇树单款人形机器人累计生产下线约 11000 台。该数量为一款双足人形的数量，不含其他型号人形机器人或轮式底盘人形。>> 查看详情 27、实测圈速 9 分 29 秒 14：华为乾崑 | 启境 GT7 无改装拿下天门山 99 弯量产车最快圈速认证 由华为乾崑和广汽联合打造的启境汽车 6 月 2 日宣布，启境 GT7 以 9 分 29 秒 14 完成天门山 99 弯全赛道全速挑战，并获得量产车最快圈速认证。>> 查看详情 28、消息称 OPPO ColorOS 17 融入更多类液态玻璃 UI，苹果风格加倍 博主爆料 ColorOS 17 将融入更多类液态玻璃 UI、和谐圆角与光场渲染，通知弹窗等场景加入实时光效，风格向苹果靠拢。据传新系统将随一款下半年发布的四曲面设计手机一同亮相，实现软硬结合。>> 查看详情 29、英伟达 CEO 黄仁勋力挺 SK 海力士高薪政策：公司“应尽可能多地奖励员工” 对于此前三星电子和 SK 海力士因员工奖金过高而受到批评，黄仁勋认为公司“应该尽可能多地奖励员工”，称“评论其他公司的薪酬制度是不合适的”，并引用了英伟达自己的做法。>> 查看详情 30、小米 17T Pro 手机官宣支持跨平台互通，兼容苹果隔空投送 小米 @XiaomiHyperOS_ 6 月 1 日在 X 平台发布推文，分享了一段视频，在小米 17T Pro 手机上通过 Quick Share，可以隔空投送（AirDrop）内容到苹果 iPhone 17 上。>> 查看详情 31、停车场扫码缴费不得强制关注公众号、不得利用领取优惠券误导消费者，成都市场监管发布合规提示 成都市场监管 5 月 29 日发布合规提示，近期，成都市部分停车场扫码缴费页面利用领取优惠券信息等误导消费者，影响消费者缴费体验。>> 查看详情 32、京东物流“京宠达”宠物专送服务正式上线，可实现“今日下单、明日送达” 京东物流上线“京宠达”宠物专送服务，聚焦猫狗，覆盖北上广深等核心城市，实现“今日下单、明日送达”。服务采用自营专送、前置检疫、全程溯源模式，司机与管家均为自营人员，并严格执行送宠上门。目前已建成标准化“宠物之家”，并搭建“航空 + 高铁”立体化运输网络，满足不同距离寄宠需求。>> 查看详情 今天就先聊到这里，IT早报，咱们明天见。
IT之家 6 月 2 日消息，福布斯实时富豪榜数据显示，软银集团创始人兼 CEO 孙正义的个人净资产攀升至 1004 亿美元，超越印度富豪穆克什 · 安巴尼，时隔 26 年后再次登上亚洲首富宝座。 孙正义目前持有软银集团约 33.74% 的股权，软银股价前一交易日一度大涨 14.71%，使其个人财富单日增值超过 120 亿美元（IT之家注：现汇率约合 813.71 亿元人民币）。 孙正义此番重返亚洲首富之位，背后最为直接的催化剂是其于本周在法国巴黎“选择法国”招商峰会上宣布的一项重磅投资计划 —— 软银将投资 750 亿欧元在法国建设 AI 数据中心，首期投资 450 亿欧元，计划到 2031 年建成 3.1 吉瓦的算力容量，后续还可扩展至 5 吉瓦。这也是软银继参与美国 Stargate 超级算力项目后，在欧洲落地的最大单笔 AI 投资。 孙正义近年来的财富跃升，与他在 AI 全产业链的大规模布局密不可分。软银累计已向 OpenAI 投资超 640 亿美元（现汇率约合 4339.78 亿元人民币），拿下后者约 13% 的股权，成为仅次于微软的第二大外部投资方。受 OpenAI 投资价值大幅增长推动，软银愿景基金在 2025 财年实现 460 亿美元的投资收益，仅第四季度便获利约 200 亿美元，几乎全部来自对 OpenAI 的投资。 在芯片领域，软银于 2025 年 3 月以 65 亿美元全现金收购了美国安培计算公司，后者主营基于 Arm 架构的高性能数据中心 CPU；同时，软银旗下 Arm 在 2026 年 3 月发布了自研 AI 芯片。从底层算力基建到芯片硬件再到 AI 应用，软银已构建起一套完整的 AI 产业链布局。 软银市值也在此轮 AI 浪潮中实现了历史性的突破。软银集团 6 月 1 日盘中股价一度大涨 14.71%，市值达 48 万亿日元（现汇率约合 2.04 万亿元人民币），一举超过丰田汽车的约 46 万亿日元，终结了丰田连续二十余年霸占日本上市企业市值榜首的纪录。截至 6 月 2 日东京股市收盘，软银市值进一步攀升至 49.30 万亿日元，而丰田市值为 44.92 万亿日元。软银 5 月披露的 2025 财年全年业绩显示，该公司归母净利润达到 5508 亿日元，同比上涨 4.7%，创下公司成立以来年度净利润的历史新高。 公布报道显示，在 20 世纪 90 年代末，孙正义通过四处大举投资雅虎等几百家默默无闻的互联网初创企业，使得软银股价在 2000 年 2 月达到历史巅峰。他的个人资产在当时一度膨胀至近 700 多亿美元并成功荣膺亚洲首富，甚至在极短时间内成为全球富豪。 随着 2000 年互联网泡沫破裂，全球科技股全面崩盘。软银集团的股票暴跌了近 99%，孙正义在短短数月内亏损了超过 590 亿美元，这也让他创下了当时“人类历史上个人财富损失最惨重”的吉尼斯世界纪录，自然也彻底失去了亚洲首富的头衔。 2014 年，随着阿里巴巴在美国挂牌上市，软银作为早期最大投资方迎来了史诗级的回报，孙正义个人净资产飙升至 166 亿美元，重新登顶日本首富并跻身亚洲富豪第一梯队。但由于软银整体负债过高以及其他投资项目缩水，其最终身家仍未能超越当时的亚洲首富李嘉诚。 此后多年，受 WeWork、共享出行等愿景基金投资项目连续大额亏损拖累，叠加阿里股价大幅回调，孙正义身家连续数年缩水，长期被优衣库创始人柳井正以及印度实业富豪压制。 相关阅读： 《 软银 CEO 孙正义：AI 革命规模将是互联网泡沫时期的 50 倍 》 《 超越丰田，软银成为日本市值最高公司 》 《 软银豪掷 750 亿欧元，在法国建设 5 吉瓦 AI 数据中心 》 《 投资超 600 亿美元，孙正义豪赌 OpenAI 引发内部质疑“迷信奥尔特曼如追星” 》 《 消息称软银寻求 400 亿美元贷款投资 OpenAI，规模创纪录 》
还记得这个天涯论坛吗，时隔三年，它又回来了。这意味着什么呢？ 2 个帖子 - 2 位参与者 阅读完整话题
IT之家 6 月 1 日消息，网易旗下临安 24 工作室于 2025 年 6 月 20 日公布了 单机动作冒险游戏《归唐》预告片 ，该作定位“大历史中的小人物叙事”，确认为普通买断制，登陆 PC 及主机平台，面向全球发行。 此后的一年时间里，《归唐》官方就再也没有发布过任何消息。 预告片公开一周年之际，《归唐》官方今日突然发布了一段 6 秒的预告，并配文“ 长风几万里 ”。 与此同时，2026 夏日游戏节的主持人 Geoff Keighley 也发布了该视频， 确认《归唐》将在 2026 夏日游戏节登场 。 在游戏中，玩家成为送信者中的一员，扮演“ 无名英雄 ”，可为石匠、农夫、僧侣，可为老者、壮士、孩童，踏入漫天黄沙，拯救河西、回归大唐。 官方称，本作将对标国际主流叙事向 3A 作品水准，游戏由网易集团执行副总裁胡志鹏担任制作人，团队核心成员多数有丰富 3A 单机研发经验，项目灵感源于胡志鹏首次接触“沙州归唐”历史故事时的情感触动，强调“历史故事改编”，在战斗风格方面也更注重“写实搏杀”。 IT之家附游戏图赏：