你花一个周末用 TRAE 做出了第一个 App。然后呢？
想发给朋友试试——安装链接怎么生成？想正式上架——却发现要注册八九家商店的开发者账号、办软件著作权、做应用核准，再把同一个包往每家后台各传一遍……做 App 的兴奋，往往就卡死在这"最后一公里"。
apkgo cloud 就是为这最后一公里而生的。核心能力一句话：一次上传，自动分发到 11 个应用商店。 在此之上，它还陪你走完从第一个预览链接到全网上架的每一步。
AI 让人人都能做出应用。但做出来之后呢？怎么让别人用上？怎么上架？怎么合规？从第一个预览链接到全网上线，这条路上的每一步，apkgo cloud 都在打通。
一、关于我
我是一名连续创业者，做过多个从 0 到 1 的产品，从需求洞察、产品设计到落地上线、商业化，完整链路都亲历过。这次做 apkgo cloud，是想验证一件事：借助 AI，能不能由一个人完整跑通一个产品的从 0 到 1——从想法、架构、编码，到上线生产、接入支付、跑出真实付费。
这条路的终点不是 Demo，是一个已上线生产环境并有真实付费客户的完整 SaaS。apkgo cloud 就是这场实验的答卷。
二、产品简介
是什么
apkgo cloud 是一个应用分发与上架平台（Web 控制台 + CLI + AI Skill）。目前已覆盖 Android 11 个商店渠道与 iOS 分发。 底层采用可插拔渠道适配器架构，新增渠道只需实现适配器，不动平台主体——这个架构为后续扩展 Web 部署、桌面端分发而设计。
一次上传，自动并发分发到 Android 11 个商店与渠道：华为 AppGallery、小米、OPPO、vivo、荣耀、魅族 Flyme、腾讯应用宝、三星 Galaxy Store、Google Play，以及蒲公英 / fir.im 内测渠道。加上 iOS 分发，覆盖移动端全平台。把"每次发版重复多遍的手工上架"压缩成一次操作、分钟级完成。
分发是当前的主场景。从做出 App 到全网上线，这条路上的每一段，apkgo cloud 都打通了：
- 让 App 先被用起来：CLI 一条命令上传，秒级拿到内测分发预览 / 下载链接，刚做好的 App 立刻分享给朋友、种子用户；
- 陪你跨过上架门槛：商店开发者账号注册 → 软件著作权 → 应用核准（原备案），这些最容易卡住也最不透明的环节，平台全程引导协助；
- 一键分发全网：回到主舞台——一次上传，多端抵达用户。
面向谁
覆盖三层人群，构成商业漏斗：
- 中小开发者 / 团队（核心主力） ——持续发版、被多商店手动上传折磨的人。核心价值：一次上传、多端分发，统一查看各商店审核状态与拒审原因，不再逐家后台巡检；
- Vibe Coding 新手（增长入口） ——刚做出 App、不知道怎么让别人用上、更不懂国内上架流程。CLI / Skill 一句话拿到内测链接，平台协助完成第一次上架；
- 中大型企业客户（价值高地） ——对数据出网与合规有硬要求。提供私有化定制部署，把整套分发能力搬进客户内网。
完整功能清单
分发核心
- 一次上传，并发分发到 11 个 Android 商店 / 渠道 + iOS 分发，每商店进度实时展示、失败原因逐条回传；
- 客户端直传对象存储，APK 不经过 API 服务器，1–2GB 大包稳定可靠；
- 定时发布（指定时刻上架，支持的商店自动排期）；
- 发版通知 Webhook（飞书 / 钉钉 / 企业微信）。
CLI + AI Skill 双入口（Agent 友好）
- Agent 友好，一句话接入：TRAE Skill 开箱即用，Claude Code、TRAE Work、Dify 工具节点只需读取一份
setup.md即可完成接入。无论哪种 Agent 环境，核心交互都是一条 apkgo-cloud CLI 命令——“上传 → 拿链接 → 全网分发”。CLI 输出结构化、可被 Agent 稳定解析与串联，不需要额外封装或适配层； - apkgo-cloud Skill：在 TRAE IDE 里用一句"把这个 App 传上去，给我个链接"就能完成全流程。Skill 自带版本控制与自动更新体系，能力升级后各 Agent 侧平滑获取，用户无感；
- 首次上架引导：协助完成商店开发者账号注册、软著代提交、应用核准，直到具备上架资格。
凭证安全
- 各商店开发者凭证集中托管，AES-256-GCM 信封加密（每条凭证独立数据密钥，主密钥永不离开服务器），明文仅在上传瞬间存在于内存。
多租户与协作
- 组织 / 成员 / 角色权限（Owner / Admin / Member / Viewer），一人可属多个组织，数据按组织隔离。
商业化闭环
- 免费 / 专业 / 高级 / 企业四档套餐；
- 微信支付 + 对公转账 + 运营手动开通；发票申请、自动邮件送达；
- 邀请奖励解锁额度，按套餐控制月上传额度。
运营后台
- 用户与组织总览、收入统计看板、上传 Worker 监控、私有化 License 签发、开票申请处理。
私有化与内测分发
- 企业单租户私有化部署（Ed25519 离线授权 + 心跳回连）；
- 自托管内测分发（下载页 + 二维码）。
三、产品演示视频
四、产品创作历程
灵感来源：3 年前带团队做技术 leader，每次发版最痛的就是"一个包手动传遍所有国内商店"——华为、小米、OPPO、vivo、荣耀、魅族、应用宝、三星，每家后台各不相同、光上传就要大半天，还容易漏传、填错。市面上要么没有覆盖这么全的一键分发，要么是重后台、重接入的大平台，对中小团队不友好。于是先做了一个内部工具给自己团队提效。
打磨 3 年，选择开源：把最难的一环啃了下来——把各家商店五花八门的上传 API 抽象成统一接口，沉淀为 Go SDK（apkgo）。它经受了自己团队多年真实发版的检验，最近开源，GitHub 上积累 200+ star。apkgo cloud 的云端只依赖其稳定接口，新增商店不动云端主体。
从初赛到复赛——两个月的脱胎换骨：初赛时提交的是一个"能把包传到几家商店"的核心 Demo，功能跑通了，但离一个真正能用的产品还差得远。复赛这段时间，我以 TRAE 为主力工具，一个人完成了从 Demo 到生产级平台的跨越——多商店并发与实时进度、凭证信封加密、多租户与计费闭环、运营后台、CLI 与 Skill 双入口、iOS 分发、私有化部署……每一块都是从零到上线，中间经历了无数次"TRAE 生成了 80% 但剩下的 20% 花了三天调试"的真实循环。最终的结果是：一个在生产环境稳定运行、并有真实付费客户的完整 SaaS。这不是一个为参赛做的 Demo，而是一个按真实用户反馈持续迭代的活产品。
从内部工具到复赛完整作品，背后是四个关键抉择：
- 从工具到平台：多租户、计费、发票、运营后台一应俱全，让它真正跑得起来、活得下去；
- 从服务老手到陪伴新手：AI 让越来越多的人能做出 App，但"做出来"和"上线"之间隔着一整套资质与流程。真正的空白不在老手，而在"做出了 App、却不知道怎么上架"的新手。于是把产品重心大幅扩展到 CLI + Skill + 首次上架全流程引导；
- 把 AI 时代的开发者当一等公民：CLI 从设计之初就面向 Agent，Skill 可被 AI IDE 直接调用，让"上架"这件事第一次可以整体交给 AI 完成；
- 以真实可用、能赚钱为唯一标准：全程对着真实用户和真实付费打磨，上线生产、持续迭代，而不是做一个只为参赛的漂亮 Demo。
五、TRAE 实践过程
用 TRAE 完成开发的典型工作流：
-
完成cli和skill的开发
3059281268578572:a1e370432b08cf15fcc657ce72695f9c_6a61edcae09462327f8b093a.6a61edcbe09462327f8b093d.6a61edcae09462327f8b093b:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/7/23 18:32:43) -
完成私有化定制版本的裁剪与开发
3059281268578572:f29f06a7d8a960c7bfef55847db0910d_6a62d59ee09462327f8b0b5d.6a62d59ee09462327f8b0b60.6a62d59ee09462327f8b0b5e:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/7/24 11:01:50) -
onboarding页面和setup文档开发
3059281268578572:5f36b0a5ca4933210e35e135dbf27dc6_6a63439fe09462327f8b0d4c.6a648c36e09462327f8b1162.6a648c36e09462327f8b1160:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/7/25 18:13:10)
六、技术方案
架构：单 Go 二进制（--mode=api|worker|all 一键切换角色）+ Next.js 静态导出前端（由 Go 直接托管）+ PostgreSQL + Redis + 对象存储。单二进制设计让本地开发一把启动、企业私有化部署极其简单。
可插拔的渠道适配器架构：所有分发渠道（商店、内测、Web 部署）抽象为统一的适配器接口。新增渠道只需实现适配器，不动平台主体。当前 Android 11 个商店 + iOS 分发是第一批适配器，Web 部署、桌面端打包是后续适配器。Agent 调用侧不感知底层差异——上传一个 APK、一个 iOS 包还是一个 Web 项目，交互模式完全一致。
- 上传链路：客户端签名直传对象存储（APK 不过 API 服务器）→ 任务入 Redis 队列 → worker 取任务、拉包、解密凭证 → 经 apkgo SDK 受控并发提交各商店 → 进度与结果实时回写；
- 商店适配解耦：所有商店上传逻辑沉淀在开源 apkgo SDK，云端只依赖其稳定接口；
- Agent 友好，一句话接入：TRAE Skill 开箱即用，Claude Code、TRAE Work、Dify 工具节点只需读取一份
setup.md即可完成接入。无论哪种 Agent 环境，核心交互都是一条 apkgo-cloud CLI 命令——“上传 → 拿链接 → 全网分发”。CLI 输出结构化、可被 Agent 稳定解析与串联，不需要额外封装或适配层； - Skill 版本控制：apkgo-cloud Skill 自带版本体系，能力升级后各 Agent 侧平滑获取新版，用户无感；
- 安全：商店凭证 AES-256-GCM 信封加密（每条独立 DEK，主密钥不出服务器）；运营模拟登录强制只读保护；
- 可靠性：worker 崩溃自动恢复孤儿任务，优雅停机保证在途上传不被部署打断；
- 交付：Docker + CI —— push 主干即自动测试、构建镜像、部署上线，数据库迁移随启动自动执行。
七、商业与社会价值
AI 让"人人都能做应用"成为现实，应用数量激增是确定性趋势。当前 apkgo cloud 已服务 Android + iOS 的分发需求；随着 Web、桌面端的覆盖，平台将逐步从一个分发工具生长为一个覆盖所有应用类型的交付层。当分发产生的供给以可搜索、可浏览的形式呈现，平台将获得网络效应——这是我们瞄准的终局：所有 Vibe Coding 的最后一站。
Android 上架需要商店凭证和资质；iOS 分发有证书和审核门槛；Web 部署在国内还面临 Vercel、Netlify 等海外平台的访问不稳定与 ICP 备案缺失。每一条路都有足够的复杂性把新手劝退。apkgo cloud 要做的，就是统一收口所有这些"最后一公里"。
真实痛点、真实付费：面向每天都在多商店发版的开发者，已在生产运行并产生真实营收。商业模型已初步验证：免费引流 → 订阅付费 → 私有化大单。
两个绕不开的问题
Q1：GitHub 上有免费开源 CLI，为什么还要用收费的 Cloud 版？
开源本身就是最重要的获客渠道。apkgo 在 GitHub 上积累的 200+ star 用户，很多是通过开源仓库发现这个工具的；apkgo cloud 第一批种子用户，靠的正是开源社区攒下来的信任。如果一开始就闭源，这个自然传播入口根本不存在。
用户为 Cloud 版付费，付的从来不是"没有选择"，而是"懒得自己折腾"：省下自建服务器和维护凭证的时间、多人协作、稳定可靠、遇到问题有人兜底。就算开源代码摆在眼前，这批用户依然会选择付费——Supabase、GitLab、Sentry 走的都是这条路。
Q2：大企业注重隐私安全，不愿意把凭证放到别人的云上怎么办？
我们提供私有化部署方案：企业把 apkgo cloud 完整部署在自己的内网里，凭证与数据都不出企业边界。这部分的销售物料，也是借助 TRAE 整理产出的——AI 不只写代码，连卖它的物料也一起做了。
八、迭代规划
已交付
- Android 11 个商店渠道并发分发，实时进度与拒审原因回传
- iOS 分发
- CLI + AI Skill 双入口，Agent 友好，一句话接入
- 凭证 AES-256-GCM 信封加密、多租户、计费闭环、运营后台
- 私有化部署（Ed25519 离线授权 + 心跳回连）
进行中
- Web 端部署与分发：国内服务器、ICP 备案与合规，填补海外平台在国内的空白
- 桌面端打包分发：macOS / Windows / Linux 签名、公证、多格式安装包
- AI 过审助手：结构化解析拒审原因，给出整改建议
长期目标
- 全端覆盖后，所有 Vibe Coding 产物汇聚于此，自然生长为一个搜索和发现最新 AI 应用作品的入口。分发是供给，发现是需求，二者互为引擎——当这个飞轮转动起来，apkgo cloud 就会成为 Vibe Coding 的最后一站。
感谢评审读到这里。apkgo cloud 想做的事，一句话就能说清：让每一个认真做出来的 App——无论出自十年老手，还是第一次 Vibe Coding 的新手——都能顺利抵达用户手中。
给 TRAE 社区的彩蛋：在 apkgo cloud 的服务订购页面添加客户经理微信，发送暗号「TRAE AI 创造力大赛」，即可享受首年 88 折优惠。也欢迎来聊聊你的 App 上架路上踩过的坑。