给 AI 用的
运维

运维长成了第二个系统

过去十年，运维工具一直在做加法。构建、部署、监控、告警、终端、文件、证书、权限、定时任务、DSL，每一样都解决了一个具体问题。

问题解决之后，它们留在了同一个界面里。工具变成平台，平台又长出数据库、队列、账号和升级路径。为了运维一套系统，先要运维一套运维系统。

AI 把速度提了上来。代码写得快，部署变得更密，变化比过去多。此时最贵的东西不是命令，而是知道现在什么是真的。

真相通常散在四个地方：监控面板、日志文件、shell 历史，和某个人的脑子里。人拼不起来，agent 更拼不起来。

把运维收成一份状态

J 的答案不是更大的面板。它把系统状态收成一份东西：服务、部署、健康、权限，写进一个纯文本、可 diff、可执行的文件。

命令行是唯一的写入口，面板只是它的一个视图。每次变更留下事件，而不是只留下截图。

这份状态同时服务两种读者。人读得完：一条命令，几行字，够判断。agent 读得准：同一份数据，稳定的 JSON，明确的退出码，最小权限。

不是给人一套界面，再给 agent 一套 API。是同一份事实，两种读法。

1. 01

   一份事实

   状态是文件，不是数据库里的暗物质。能打开、能 diff、能回滚。

2. 02

   一套接口

   人敲的命令，agent 也能调。输出可读，也可解析；失败有明确的退出码。

3. 03

   小到能读完

   单二进制、一份配置、无外部依赖。这是设计目标，不是营销词。

NAME    STATE     SINCE    OWNER
api     running   2d 04h   core
worker  degraded  12m41s   core
web     running   6d 11h   web

{
  "revision": 184,
  "source": "state.json",
  "services": {
    "api":    "running",
    "worker": "degraded",
    "web":    "running"
  }
}

同一份状态，不是两套系统。示例只表达接口原则，J 尚未实现。 NOT IMPLEMENTED

九年，140 多个版本，
然后停下来。

2017 年，我写下 Jpom 的第一行代码。2018 年正式开源，2019 年发布第一个版本。到 2025 年 5 月，最后一次功能发布停在 v2.11.12；2026 年 2 月 5 日，项目宣布暂停维护。

它是一款简而轻的低侵入式在线构建、自动部署、日常运维、项目监控软件。九年里，它被装进很多人的服务器，也接过很多次凌晨的排障。

暂停不是突然发生的。项目长期由我一个人维护，80% 以上的功能由我设计、开发、维护、测试和运营；贡献者有自己的生活；CDN、OSS、鉴权服务和演示站点都要钱；精力也有用完的时候。公告里把这些写清楚了。

J 不是 Jpom 的 3.0，也不是它的续作。它是我停下来之后，重新想的那件事。

读暂停维护公告 ↗