Zun：一门为轻量服务而设计的语言

Zun 是一门面向独立开发者、用于脚本和轻量网络服务的语言。我希望它保留脚本的直接手感，同时把写接口时反复要用到的能力放在一起，让一个想法更快成为能运行的服务。

先把服务跑起来

我做 Zun，关心的是一个独立开发者从想法到可运行结果，要经过多少准备。

写一个小接口，也常常要先选框架、组织路由、补服务器入口，再把数据库和认证接起来。这些工作有价值，但在验证想法的时候，我希望能少一点前置准备，先把最小的服务跑起来。

所以 Zun 的范围会有所取舍：脚本、小工具、轻量 API、内部服务。它可以从一个文件开始，需要时再拆模块。工程结构可以随着问题长出来，不必在写第一段业务逻辑之前就全部铺好。

把 HTTP 放进语言

Zun 把 HTTP 路由放进了语法。$GET、$POST 直接声明接口，函数里返回结果，用 zun serve 启动服务。这里说的“函数即接口”，指的是语言能识别服务入口，不是替你完成云端部署。

底层由 Rust 实现，Zun 程序目前仍然解释执行。现有能力已经包括 HTTP 服务端和客户端、SQLite、PostgreSQL，以及 Session、JWT、密码哈希、授权和 CSRF；还有模块、测试入口、REPL 和 LSP。常用能力集中在一起，是为了少做一些接线工作。当前项目介绍

内建能力也会增加语言本身的维护责任。每收进来一种能力，就要一并考虑错误行为、配置方式和测试，而不只是把调用写得更短。

需要约束时再加类型

我希望快速验证和明确边界可以放在同一门语言里。

不写类型注解时，变量默认动态；写了注解，就在运行时校验。函数参数、返回值和自定义类型也可以逐步加上约束。这里要说准确：这是运行时保护，不是完整的静态编译期检查。

$Type 也有明确的身份边界。声明了 User，就需要真正的 User 实例，不能因为一个普通 Map 恰好有相同字段，就把它当成同一种类型。渐进类型说明

$ 背后的想法

$ 最初带着一点玩的意思：“写代码，就是赚钱。”放在独立开发者的语境里，我想强调的是尽快验证价值，而不只是完成代码。

早期设想还包括把支付、Webhook 和 API 暴露更自然地融入语言，让一个文件、一条命令最终能成为可收费的服务。这是更远的产品愿景，目前不能当作已有能力，也不是确定的近期路线承诺。早期设计想法

接下来探索 AI Agent

仓库现在的方向很直接：HTTP 是现在，AI Agent 是下一步。我想继续探索这门小语言在 Agent 服务里能承担什么，但现有的 HTTP、JSON、数据库能力，还不能等同于已经实现了一套 Agent 运行时。

目前公开仓库还没有给出稳定的 AI 接口或具体机制。这部分仍是待探索的方向，不能因为已有网络和数据能力，就把尚未落地的 Agent 功能也算进去。当前方向说明

此前的“网络函数编程”草案里，还探索过超函数链、异步和 WebSocket。这些写法属于设计探索，不能直接照着当成当前可运行的语法。网络函数编程草案

仍然在早期

Zun 还有不少边界要补齐。包生态没有成形，可观测性仍弱，语言也可能继续发生不兼容变化。

尤其要说明，当前运行时没有沙箱，脚本能使用宿主进程可访问的文件、环境变量和网络能力。已有认证和授权，不代表可以安全地执行不可信代码。当前安全边界

我想继续检验的，就是这件事：在能力逐渐增加的同时，Zun 能不能仍然保持简单，把一个人从想法走到服务的那段路，再缩短一点。