先和大家打个招呼
我是谁：一名有十多年经验的程序员、独立开发者。
我是怎么用 TRAE 把 Demo 做出来的：说实话，一开始我没指望 TRAE 能干到"获客"“客情"这种非技术的活，以为它顶多是帮我把代码写快一点。最意外的是第二步——把一份需求文档丢给它，说"帮我设计此应用的所有页面”，22 分钟后它自己产出了 13 屏完整设计，还在浏览器里验证通过。这是我以前觉得"这活儿我肯定得外包给设计师"的坎，就这么被它跨过去了。
再往后，用 Computer Use 自动去天眼查找目标客户、一句话让它自主完成服务器部署、甚至在客户对价格提出异议时帮我想怎么得体地回复……每一步都是我把脑子里的想法一句话一句话讲给它听，然后它自己去拆解、去执行、还会自己验证结果对不对。最真实的感受是：一个人从 0 到 1 做成一个真正商业化的产品，以前根本不敢想——除了写代码，还得会设计、会营销、会运维、会哄客户开心，一个人哪忙得过来。这次是 TRAE 陪着我，把这些原本以为搞不定的坎，一个一个迈过去了。
1. Demo 简介
是什么：apkgo-cloud 是一个应用多渠道发布管理平台（SaaS + 支持私有化部署）。团队打开浏览器，就能把 APK / IPA 一键发布到国内主流安卓应用商店，以及 iOS App Store、鸿蒙 HarmonyOS，不用再逐个渠道手动上传。
面向谁：企业和团队里的发布运营、产品经理、测试同学——尤其是没有专职运维/发布人员的中小团队。
主要功能：
- 浏览器端一键多渠道发布，凭证云端加密托管，不用团队成员人手一份签名文件
- 可视化 Console：发布历史、渠道状态、失败诊断一目了然，出问题不用翻日志
- 团队协作与权限管理，支持私有化部署，凭证和数据可以不出企业内网
2. Demo 创作思路
灵感来源：我是一名有十余年经验的程序员，之前在 GitHub 开源维护了 CLI 工具 https://github.com/KevinGong2013/apkgo，把安卓全渠道发版的时间从 1 小时压缩到 5 分钟以内。但这个工具只有程序员会用命令行操作，运营、产品同学完全用不了——团队发版效率的瓶颈其实一直都在，只是从"技术活儿慢"变成了"只有一个人会干"。
想解决的问题：真正想验证的问题不是"要不要做个网页版"，而是"一个技术人员发现的真实痛点，能不能借助 AI 独立走完从想法到商业化的全过程"——这是我这次参赛真正想回答的问题。
(最近以Trae为代表的一系列AI工具的兴起，让App的开发门槛进一步降低，让apkgo能再次发光发热)
为什么做这个方向：这次比赛对我来说不是做一个技术 demo，而是一次完整的创业实验：我想验证 TRAE 能不能在发现问题 → 做出产品 → 找到客户 → 持续运营 → 赚到第一笔真实收入的每一个阶段都成为真正的帮手，而不只是一个写代码的工具。目前 apkgo-cloud 已经有接近 100 个正式用户，其中包含订阅付费用户和私有化部署客户——这不是一个停留在概念阶段的 demo，而是一个已经在真实跑收入的产品。
3. Demo 体验地址
提供三个可公开访问的入口，覆盖 Demo 体验、私有化部署预览、正式产品，评审可以任选其一直接点开体验：
-
快速体验版：https://apkgo.demo.baici.tech
任意邮箱 + 任意密码即可登录进入 Console，最快 1 分钟看到产品长什么样。 -
私有化部署公开预览版：https://apkgo.onprem.baici.tech
账号 demo@apkgo.local 密码 apkgo-demo-2026
这是企业私有化部署方案的真实预览环境，对应第 5 部分 Q2 里提到的私有化部署能力。 -
正式产品入口：https://apkgo.baici.tech
已经是正式对外服务的版本，可以直接注册账号使用——单个应用完全免费，评审可以真实体验一次完整的多渠道发布流程。
4. TRAE 实践过程 —— 商业闭环的每一步，TRAE 都在场
下面每一步都按"做什么 → 用了 TRAE 的什么能力 → 关键操作/Prompt → 结果"来写，方便评审快速看懂 TRAE 具体做了什么，而不是只看到一个结论。
第一步：把一个人的经验，变成一份完整的产品需求
- 做什么：基于 CLI 版本三年多的真实用户反馈，把"我脑子里知道该做什么"转成结构化产品需求
- 用了 TRAE 的什么能力：TRAE Work 的需求梳理/产品规划能力
- 关键操作：分析apkgo代码库，帮我梳理出 apkgo-cloud 的完整 PRD
- 结果：apkgo-cloud-PRD.md
第二步：从需求到设计
- 做什么：把第一步产出的 PRD 文档直接丢给 TRAE，一句指令——“请依照此需求文档，帮我设计此应用的所有页面”——让它把一份文字需求，转成一整套可交互的产品界面。
- 用了 TRAE 的什么能力：TRAE Design——遵循 Vercel Design System（暗色单色主题、Geist 字体、8px 圆角、细边框），一次性产出 13 个页面的完整设计，并在浏览器中验证通过：
- 公开页面：Landing Page（Hero 区"上传一次，分发到一切"、动效 Console 预览、11 家应用商店跑马灯、5 张功能卡片、3 步流程图、4 档定价网格）、登录页（微信 OAuth / 邮箱密码 / GitHub）
- Dashboard（11 屏，共享侧边栏+顶栏）：Uploads 上传管理、New Upload 三步向导、Apps 应用与商店版本、Credentials 凭证管理、Members 成员与权限、Referral 邀请返利、API Keys（含 curl 示例和 AI Agent Prompt 卡片）、Audit Log 审计日志、Billing 账单与订阅、Settings 等
- 耗时：22 分 11 秒，一次任务产出全套设计并在浏览器验证通过
- Session ID：3059281268578572:8ddb946322fcffae24fb54e103be5efc_6a4f3b5ba237e846f28f74ed.6a4f3b5ba237e846f28f74f0.6a4f3b5ba237e846f28f74ee（TRAE Design，2026/7/9 14:10）
- 结果：设计稿最终落地为可交互体验版 —— https://apkgo.demo.baici.tech （任意邮箱+任意密码即可登录，1 分钟看到完整 Console 界面）
第三步：从设计到能上线运行的真实产品
- 做什么：一句指令——“用 Go 语言，帮我根据需求文档完成后端开发”——把 PRD 交给 TRAE，让它自己读文档、理解范围、规划架构、再动手写代码。
- 用了 TRAE 的什么能力：TRAE Work 的自主规划 + 全流程开发能力。先用 Plan Agent 读完 PRD 后自主拆解出完整的后端实现计划，再按计划逐项落地：
- 项目骨架：go.mod、目录结构、config、main.go、统一响应/错误处理、GORM 数据模型层与 RBAC 权限系统、API Key 认证、OrgContext、限流中间件
- 数据库迁移文件：完整 schema SQL（全部数据表 + 种子数据）
- 认证服务：注册/登录/OAuth/邮箱验证/JWT 签发
- 组织与成员服务：App / Credential / Binding CRUD + AES 加密
- 上传与分发服务：三步直传 + Worker + 商店适配器
- 套餐计费、审计日志、API 密钥、通知 Webhook、运营管理、License 等剩余模块
- 最后自主完成编译验证与集成修复，确保代码能跑通，而不是只生成、不校验
- Session ID：3059281268578572:960b241c7bc911db712db916735e4d9f_6a51e13b5ec02a47c3d84544.6a51e13b5ec02a47c3d84547.6a51e13b5ec02a47c3d84545（TRAE Work，2026/7/11 14:22）
- 结果：现在正式对外服务的版本 —— https://apkgo.baici.tech （已开放注册，单个应用完全免费）
第四步：从产品到第一个客户 —— 让 TRAE 自己去找目标客户
- 做什么：获客最难的部分从来不是"发邮件"，而是"找对人"。一个人工卖过东西的人都知道，把邮件发给不对的对象，转化率再优化也没用。所以这一步我没有让 TRAE 帮我写文案，而是直接把"找客户"这件事本身交给它——目标客户不是随便找的企业，而是精确圈定"有软件发布需求、但没有专职发布运维"的中小研发团队；过滤掉大厂，是因为大厂大概率已经有自己的 CI/CD 和发布体系，不会为这个痛点买单。这个"识别谁是目标客户"的判断逻辑，是我给的，但从搜索、筛选到抓取，全部由 TRAE 自主完成。
- 用了 TRAE 的什么能力：TRAE Work 的 Computer Use 能力——让 TRAE 像一个真人一样自动打开浏览器，去天眼查用"软件开发"“APP 开发”"小程序开发"等多个关键词交叉检索企业，逐个判断经营范围和规模是否符合"目标客户"画像、按规则过滤掉大厂，再抓取企业名称和公开邮箱、整理成结构化数据。换句话说，TRAE 干的不是"发邮件"这种执行层的活，而是"谁值得发"这种本该由销售/运营人工判断的筛选工作——这才是这一步真正的价值所在。筛出的名单接入腾讯 Agent Mail 后，设置成每天自动发送 50 封推广邮件，全程不需要人工一家家去找、一封封去发。
- 关键操作/结果：一次任务耗时 8 分 52 秒，自动完成 100 条企业邮箱采集，按关键词分布如下：
| 搜索关键词 | 收集数量 | 说明 |
|---|---|---|
| 软件开发 | 38 条 | 主要来源，涵盖各地软件开发公司 |
| APP 开发 | 19 条 | 移动互联网开发相关企业 |
| 小程序开发 | 13 条 | 微信小程序开发企业 |
| 手机软件开发 | 8 条 | 手机应用开发工作室/公司 |
| 移动应用开发 | 3 条 | 补充来源 |
| 互联网软件开发 | 2 条 | 最后补充 |
数据覆盖广州、深圳、上海、北京、长沙、西安、苏州、武汉等全国多地从事软件/APP/小程序开发的中小企业，自动导出为结构化 CSV，直接对接到 Agent Mail 的发送队列。
- Session ID：3059281268578572:3b61ede17979c1107c7909305bd873c5_6a5063be9a1f74881d804131.6a509563bebc05560b437fe2.6a5095620858a69762e66adf（TRAE Work，2026/7/10 14:55）
- 转化结果：目前转化率约 0.2%（按每天 50 封计算）。这个数字不高，但胜在完全自动化、零边际人力成本——从"找线索"到"发邮件"整条链路不再需要人工介入，种子用户里有相当一部分就是这样"睡后"积累出来的。
第五步：从上线到能稳定跑 —— 运维
- 做什么：把"改代码 → 连服务器 → 配置 HTTPS → 验证上线"这条最容易出错、最花时间的环节交给 TRAE。我在本机配置好 SSH 免密登录和域名解析后，只说了一句"Caddy 是使用 workspace 目录下的 docker-compose 部署的"，剩下的全部交给 TRAE 自主完成。
- 用了 TRAE 的什么能力：TRAE Work 的智能体自主执行能力——TRAE 能理解本机已有的 Caddy/docker-compose 部署架构，自己规划并执行完整的远程部署流程，全程零人工干预。
- 关键操作：1 分 44 秒内自主完成 4 步操作：
- 将 HTML 文件上传到服务器 /root/workspace/data/apkgo-demo/index.html
- 在 Caddyfile 末尾追加 apkgo.demo.baici.tech 的静态站点配置（不修改任何已有域名配置，避免影响正式环境）
- 执行 caddy reload 使配置生效，Caddy 自动申请 HTTPS 证书
- 主动验证 https://apkgo.demo.baici.tech 已正常返回页面内容，确认部署成功
- Session ID：3059281268578572:1b7ac2b3f48c9e46039426c70ddf03a5_6a51ec2d5ec02a47c3d849be.6a51ec945ec02a47c3d84a2d.6a51ec945ec02a47c3d84a2b（TRAE Work，2026/7/11 15:11）
- 结果：一次部署从"人工操作 10+ 分钟、容易漏步骤"变成"一句话，TRAE 1 分 44 秒自动跑完全流程并自我验证"，这也是能让我一个人同时兼顾开发、获客、客情、还能稳定维护线上服务的关键——这个部署对象正是第 3 部分体验地址里的快速体验版 https://apkgo.demo.baici.tech 。
第六步：从成交到留住客户 —— 客情维护
- 做什么：官网定价页出过一次真实的乌龙——私有化部署本应单独报价，却被误写进了 599 元/年的高级版套餐里。一位做矩阵 App 的企业客户按 499 元的口径来询价，收到正式报价单后发现比预期高，当场提出异议。这种时候回复的分寸很关键：既不能回避问题，也不能让客户觉得"价格随口就能变"，从而动摇后续信任。
- 用了 TRAE 的什么能力：TRAE Work 的客户应答策略生成能力。把情况原样描述给 TRAE 后，28 秒内给出了三套可选回复策略——① 诚恳说明情况 + 给出专属补偿价（推荐）② 强调私有化部署与云端订阅的价值差异 ③ 直接让利拉平心理落差，并分别给出了对应话术模板。
- 关键操作：采用了 TRAE 推荐的策略①，实际发给客户的回复：
不好意思，之前官网定价页确实有个信息错误，把私有化部署写进了 599/年的高级版套餐里，这是我们的疏漏。私有化部署实际上属于企业版范畴，除了软件功能本身，还包含部署到你们自己服务器环境、专属 1v1 技术支持、以及 SLA 保障，这部分需要持续投入人力维护，所以单独定价，跟云端订阅版本不是一回事。不过这次确实是我们页面信息误导了你的预期，也很感谢你愿意成为我们私有化部署客户——这次给你一个专属优惠价：首年 1999 元（含部署），次年续费 799 元/年。这个价格只对你这次开放，后面正式对外报价会是 2999 元首年 + 999 元/年。
- Session ID：3059281268578572:ae9c10d949abc54a911d71e0c4182033_6a51e92a5ec02a47c3d848de.6a51e92a5ec02a47c3d848e1.6a51e92a5ec02a47c3d848df（TRAE Work，2026/7/11 14:56）
- 结果：客户回复"我试用下，然后也跟我们老板同步下这个情况"——价格异议没有演变成信任危机，反而顺势推进到了下一步试用环节。这次乌龙也顺带定下了 apkgo-cloud 私有化部署的正式报价体系：首年 2999 元 + 次年 999 元/年。
结果：目前已有接近 100 个正式用户，其中包含订阅付费用户和私有化部署客户——从"发现一个程序员才懂的痛点"到"做出所有人都能用的产品"再到"赚到第一桶金"，TRAE 陪着走完了这个商业闭环的每一步。
5. 两个绕不开的问题
Q1：GitHub 上就有免费开源的 CLI，为什么还要用收费的 Cloud 版？是不是在制造信息差？
这其实是个很常见的误判。多数情况下闭源反而会降低付费率，原因有三点：
第一，愿意自己搭建、维护凭证和脚本的开发者，就算把代码闭源，他们也不会因此付费，而是直接换一个别的开源工具——闭源换不来这批人的钱，只会失去他们的好感。
第二，开源本身就是最重要的获客渠道。apkgo 在 GitHub 上积累的 200+ star 用户，很多都是通过开源仓库发现这个工具的，apkgo-cloud 后来能靠一封推广邮件触达第一批种子用户，靠的正是这批开源社区攒下来的信任。如果一开始就闭源，这个自然传播入口根本不存在。
第三，用户愿意为 Cloud 版付费，付的从来不是"没有选择"，而是"懒得自己折腾"：省下自建服务器和维护凭证的时间、多人协作、稳定可靠、遇到问题有人兜底。就算开源代码摆在眼前，这批用户依然会选择付费——Supabase、GitLab、Sentry 走的都是这条路。
所以我们没有选择闭源，而是把"开源 CLI"和"Cloud 版"做出清晰的差异化：开源版功能完整，适合会自己折腾的技术团队自托管；Cloud 版则提供多账号管理、团队协作、自动化集成和更完善的 Dashboard。让人愿意付费的是价值差，不是信息差。
Q2：大企业注重隐私安全，不愿意把凭证放到别人的云上怎么办？
我们提供了私有化部署方案，企业可以把 apkgo-cloud 完整部署在自己的内网环境里，凭证、数据都不出企业边界。这部分的使用说明、功能介绍和报价物料，也是借助 TRAE Work 整理产出的——从一份技术工具的私有化部署方案，变成一套能直接发给客户的销售物料，这也是这次用 TRAE 做获客环节的一部分实践。
PS: 本报名贴也是由TRAE Work润色后发布