更适合 VibeCoding 的应用部署平台 - AppLab

这是一个开源项目 https://github.com/shaowenchen/applab

1. 使用 AppLab 开发一个应用

克隆仓库

1
git clone https://x:xxx@applab.chenshaowen.com/applab/git/app.git

让 Agent 开发

1
claude

描述需求之后，只需静静等待，会看到如下输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
构建成功，镜像已产出（shaowenchen/applab:demo-myapp1-cb6c88944e41）。但 deploy 那次只是触发了构建，应用还没部署。再部署一次复用这个镜像。

  Thought for 3s, ran 2 shell commands

部署成功：1/1 就绪，0 次重启。现在对线上地址做端到端验证。

  Thought for 2s, ran 1 shell command

线上服务已跑起来。现在测完整的上传→列表→下载→删除链路，重点验证中文文件名（走 filename*）和二进制的类型嗅探。

  Thought for 2s, ran 1 shell command

路径里的空格把我的 curl 参数拆散了，换个无空格的临时文件名。

⏺ Running 1 shell command…
  ⎿  $ BASE=https://applab.chenshaowen.com/applab/apps/myapp1
     printf 'hello 文件上传\n第二行\n' > /tmp/src.txt
     NAME=$(python3 -c "import urllib.parse;print(urllib.parse.quote('测试 文档.txt'))")
     echo "=== 上传中文名文本 ==="
     curl -sS -X POST "$BASE/api/upload?name=$NAME" -H "Content-Type: text/plain" \
     --data-binary @/tm…

✶ 部署上线… (5m 42s · ↓ 61.0k tokens · thinking with medium effort)
✔ 用 Python 重写文件上传服务
✔ 改 Dockerfile 为单阶段 Python 构建
✔ 改前端上传为原始请求体
✔ 删除 Go 源码并更新 README
◼ 推送构建并部署上线

不需要在各种 Web、Agent 端来回切换，基于一个 Git 仓库，在一个 CLI 端就能完成应用的完整开发和部署上线。

查看应用

在平台也能查看应用的配置信息

2. VibeCoding 之后为什么更累

VibeCoding 只是解决了代码编写的问题，并没有覆盖完整的应用开发生命周期。

一个应用从需求到线上持续运营，中间会经过很多的环节，包括中间件的管理、应用的扩缩容、监控与告警、异常的排查等。

开发人员不仅仅需要写代码，而且还需要保证功能的上线和服务的稳定，冰山之下还有庞然大物。

而且随着 VibeCoding 的普及，线上的稳定性岌岌可危。项目的复杂度在急剧增加，人在逐步失去审查能力。

现状与趋势如此，我们无力改变。

3. AGI 下个体也有机会

面对代码的失控，我们可能会想到 AGI 马上到来，全都交给 AI 就行。应用的发布、部署、运维、变更，只要 Agent 足够强，都能够实现自动化。实现不了，那是因为模型和 Agent 不够强。

这我很难反驳，但也无法证伪，就像在说子弹打不死跑得快的人，打死了那是因为他跑得不够快。

我认为真正重要的是边界，哪些事情交给 Agent，哪些事情需要我们控制。这需要我们不断地尝试和探索。

当有新事物时，我们很容易放大短期的影响，矫枉过正。

AGI 来临之际，我们要多和 AI 抢事情干，才能找到自己的位置。

我不会将整个 Kubernetes 集群直接交给 Agent，但可以通过 AppLab 规范和约束之后，再交给 Agent。

4. 我们需要新的基础设施

早期为了接入模型，我们增加适配层，开发了各式各样的 CLI。

基于这些 CLI，Agent 借助人工复检、反馈修复驱动整个开发的工作流。

这种拼接的系统，显然不是原生的 AI 系统，CLI 过多导致的环境依赖问题、Token 消耗问题、响应慢的问题、维护发布慢的问题，都需要庞大的人力成本。

上图是我提供的一个新的思路，每个应用都值得一个自己的 CLI。如果 CLI、MCP 能直接驱动应用，为什么不能在应用出生时，就提供呢？

5. 仓库即全部

应用所需的全部依赖都在代码仓库。不仅仅是代码、配置文件、环境变量，还有对线上发布、变更、运维、故障排查的能力。

静态的代码加上动态的运行时，才能快速有效地让 Agent 驱动飞轮迭代。

新建的应用仓库目录下，平台会初始化一个应用专属的 applab.sh 文件，包含了全部的平台操作。

克隆仓库，就能完整地操控应用，包括访问的凭证。密钥不入库的老传统，可能需要解除，毕竟我们在 AI Chat 窗口已经泄漏了那么多，对内部的自己人还不能多一点信任吗？

6. 让 CLI 成为一等公民

我在 VibeCoding AppLab 时，就一直强调要三端对等。Web、API、CLI 三个操作终端的功能要完全一致。

传统的方式，延续的是先优先实现自己的 Web，然后筛选一部分对外开放 API 调用，最后基于开放 API 再去封装 CLI。这是将 CLI 当成了三等公民，适应不了 Agent 时代。

Agent 是一场生产效率革命，任何的设计都要优先 Agent 的使用。人用不用已经不再重要，重要的是 Agent 能交付最终的结果。