这是另一种开发模式的尝试：面向云端Runtime模式。
不是本地写代码然后部署到云端，而是直接在云端声明业务逻辑，平台负责把它跑成API。
怎么做？
把互联网应用里最基础、最通用的能力——用户、支付、订单、计费、消息、推送、物流、认证等等——封装成原子化接口。每个接口都有完整的业务语义，比如“短信验证码登录”、“创建订单”、“微信支付下单”等等。
然后你只需要用JSON描述业务逻辑，把这些原子接口串联起来。平台负责解析、执行、运维，产生的数据与平台无关。
一个例子：60行JSON实现“新用户登录送资源点”（只需要使用5个节点）
{
"variable": { // 全局变量
"secret": "00000000000000000000",
"subResourceId": 1
},
"trigger": { // 调用请求工作流接口的定义
"type": "api",
"method": "POST",
"path": "/wf/v1/exec/smsLogin",
"body": {
"mobile": "{{request.body.mobile}}",
"code": "{{request.body.code}}"
}
},
"nodes": [ // 业务逻辑实现
{
"id": "node_01",
"type": "HTTP",
"name": "短信验证码登录",
"nextNode": "node_02",
"api": {
"url": "/uc/v1/jiguang/{唯一标识}/smsLogin",
"method": "post"
},
"body": {
"mobile": "{{trigger.body.mobile}}",
"code": "{{trigger.body.code}}"
}
},
{
"id": "node_02",
"type": "HTTP",
"name": "获取用户信息",
"nextNode": "cond_01",
"api": {
"url": "/uc/v1/token/getuserinfo",
"method": "get"
},
"headers": {
"access-token": "{{node_01.output.body.data.accessToken}}"
}
},
{
"id": "cond_01",
"type": "CONDITION",
"name": "判断是否新用户",
"expression": "${{{node_01.output.body.data.new}}}",
"trueNext": "node_03",
"falseNext": "end1"
},
{
"id": "node_03",
"type": "HTTP",
"name": "赠送资源点",
"nextNode": "end1",
"api": {
"url": "/billing/v1/master/recharge",
"method": "post"
},
"authorization": {
"state": true,
"secret": "{{variable.secret}}"
},
"body": {
"unionId": "{{node_02.output.body.data.uid}}",
"subResourceId": "{{variable.subResourceId}}",
"payAmount": 0
}
},
{
"id": "end1",
"type": "END",
"output": {
"token": "{{node_01.output.body.data}}",
"userInfo": "{{node_02.output.body.data}}"
}
}
]
}
这段JSON（工作流）都做了什么？
- 定义了一个POST接口，接收mobile和code
- 调用短信登录接口（平台内置）
- 用登录返回的token获取用户信息
- 判断是否新用户（登录接口返回了new字段）
- 如果是新用户，调用充值接口送资源点
- 返回token和用户信息 发布后得到什么？
一个HTTP端点：https：//your-domain/wf/v1/exec/smsLogin (平台为每个项目分配了一个域名)
可以直接给前端调用。不需要写代码、不需要部署、不需要运维。
这就是完整的实现过程，此时，你已经拥有了一个生成级的“新用户登录送资源点”API接口。
两种模式的对比：
| 传统模式 | AI生成代码模式 | 面向云端开发模式 | |
|---|---|---|---|
| 代码编写 | 手动写 | AI生成 | JSON声明 |
| 调试环境 | 本地搭建 | 本地搭建 | 云端实时 |
| 测试 | 自己写 | 自己写/AI写 | 平台保障 |
| 部署 | 手动/CI | 手动/CI | 一键发布 |
| 运维 | 自己负责 | 自己负责 | 平台负责 |
| 通用能力 | 自己实现 | 自己实现/AI生成 | 原子接口开箱即用 |
AI生成代码提高了“写代码”的效率，但没有改变开发模式本身。你还是在本地写代码、调试、部署，只是写的那部分被AI替代了。
面向云端开发改变的是模式本身：不把代码拉到本地，直接在云端声明业务逻辑；不关心运行环境，只关心业务本身。
为什么是Runtime模式：
Runtime平台面向开发者，提供完整的编程模型（HTTP、变量、条件分支、结束、错误处理），同时把基础设施（审计日志、域名管理、SSL免费证书和自动延期、IP白名单）都封装好。开发者声明逻辑，平台负责运行。
现在能做什么？（上线的原子接口）：
- 用户中心：微信登录、短信登录、获取用户信息、修改用户信息、登出、注销、URL访问权限校验等
- 计费中心：预计费、扣费、充值、查询余额、查询流水、资源包管理、计费规则、扣费规则等
- 订单中心：创建订单、查询订单、更新订单状态、取消订单、订单审批、退单申请等
- 支付中心：微信支付下单、退款申请、关闭订单、查询支付结果、支付/退款回调处理等
体验：
即调官网地址：www.jidiao.fun
写在最后
我们做即调，是因为相信：开发模式的下一次演进，不是更好的代码生成，而是重新思考“开发”本身。
AI生成代码固然大大提高了开发效率，但开发的目的是让其呈现出想要的结果。那么面向云端Runtime模式，未必不是一条演进路径。
欢迎来试，欢迎给反馈。
