一个项目管理工具，能不能算 2+3？
Nicolas Seriot 最近给了一个很黑客的答案：能。他用 Jira Automation 搭出了一台 Minsky 双计数器机器。初始 A=2、B=3，经过一串状态跳转，A 归零，B 变成 5。
这不是 Atlassian 官方宣布 Jira 成了编程平台。也不是说 Jira 性能强、适合写程序。真正扎眼的是：一个本来管工单、催进度、转状态的工具，被证明可以在计算理论约定下执行通用计算。
这个证明像个玩笑，但它戳中的不是笑点。
它戳中的是企业自动化的老毛病：工具说自己只是流程胶水，用久了却变成一门没人愿意承认的编程语言。
Jira 是怎么被搭成一台计算机的
Minsky 机器很小。
两个无界计数器，加一组有限指令，就已经被证明图灵完备。指令也很朴素：给计数器加一，或者减一，并根据是否为零跳到不同状态。
Seriot 的 Jira 映射并不玄：
| Minsky 机器 | Jira 里的对应物 |
|---|---|
| 寄存器 A | Epic 下链接的 Bug 数量 |
| 寄存器 B | Epic 下链接的 Task 数量 |
| 程序计数器 | Epic 的状态 |
| 指令表 | Jira Automation 规则 |
| 时钟 | 状态跳转触发规则，或人工重新触发 |
加法程序也很经典：不断从 A 减 1，同时给 B 加 1。A 为 0，就停机。
落到 Jira 里，删除一个 Bug 就是 DEC A。创建一个 Task 就是 INC B。Epic 从 TODO 跳到 DEV，再跳回 TODO，就是程序在执行下一条指令。
Seriot 给出的轨迹是：
(2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD
结果很直白：A=0，B=5。2+3 算完。
他还做了 Fibonacci 示例，用 Bug、Task、Story 三种 issue type 当三个寄存器，并借助 issue type 转换压缩移动计数的循环。Task 数量里会出现 1、1、2、3、5、8、13……
但限制要讲清。
Jira Cloud 有规则链深度上限。文中提到 Fibonacci 跑到链深度 cap 10 后会停，需要人工改状态继续触发。Jira Data Center 的相关执行超时和限制可配置。
再往根上说，所有物理系统都有限。这里说“图灵完备”，是在标准计算理论约定下成立：假定可用资源不封顶。
所以别把它读成“Jira 很适合通用编程”。更准确的读法是：Jira Automation 已经强到足以表达计算。
这就够吓人了。
图灵完备不是奖章，是债务提示
我不太买账“哈哈 Jira 居然能编程”的段子式理解。笑一下可以，但别笑完就过去。
企业工具最常见的演化路线是这样的：
| 阶段 | 看起来是什么 | 实际长出来的东西 |
|---|---|---|
| 初期 | 少写代码，拖几条规则 | 简单自动化 |
| 中期 | 状态、字段、权限开始联动 | 隐形业务逻辑 |
| 后期 | 规则互相触发，没人敢删 | 没有工程治理的程序 |
这条路，太熟了。
一开始只是“工单转到 Done 就发通知”。后来变成“客户等级不同，审批路径不同，SLA 不同，通知对象也不同”。再后来，某条规则一删，下游报表、客服提醒、交付节奏全受影响。
这时它已经是程序。
只是没有 IDE，没有单元测试，没有版本治理，也没有一个明确背锅的开发者。
图灵完备不是夸 Jira 强。它更像一盏红灯：你给了用户足够多的条件分支、状态跳转和副作用，复杂度就会自己长出来。
“天下熙熙，皆为利来。”企业软件卖的是效率，用户买的也确实是效率。但账不会消失，只会换地方记。少写的代码，可能变成更多配置。少找的程序员，可能变成更多管理员、流程 owner 和救火会议。
Jira 不是孤例。
Excel 宏、Zapier 流程、Notion 数据库、CRM 自动化，都走过类似的路：说是让业务自己动手，结果把编程藏进表格、按钮、审批流和权限矩阵里。
早期铁路公司也有一点相似处。铺轨不等于管好铁路。真正难的是时刻表、调度、信号和事故责任。今天的低代码当然不等同于铁路系统，但重复的是同一种治理难题：网络一复杂，规则本身就变成基础设施。
界面再友好，状态爆炸也不会因为按钮更圆润而消失。
受影响的不是普通用户，而是管规则的人
这件事对普通 Jira 用户影响很小。该提工单提工单，该改状态改状态。
真正该紧张的是两类人。
一类是工程团队和产品团队。只要 Jira 自动化已经影响交付流、发布节奏、SLA、客户通知，就别再把它当“小配置”。它已经在参与生产系统。
另一类是企业软件管理员和 IT 治理团队。采购低代码、自动化平台、流程工具时，不能只问“能不能拖拽”“能不能省开发”。还要问四个更硬的问题：
- 规则有没有测试环境？
- 变更有没有审计和回滚？
- 链式触发、循环触发有没有上限？
- 谁能解释一个状态为什么变成了另一个状态？
这些问题不性感，但决定出事时能不能止血。
更现实的动作也不复杂。
已经大量使用 Jira Automation 的团队，应该做一次规则盘点。把影响交付、计费、SLA、客户通知的规则标出来。给它们命名，写清 owner，记录变更原因。
如果准备上低代码平台，采购可以慢一点。不要只看演示里的“十分钟搭好流程”。要看异常处理、权限边界、日志、配额、规则链深度和 Data Center / Cloud 的限制差异。
开发者也要调整心态。别把这些东西都当“业务同学自己玩的配置”。当配置开始有条件分支、状态机和副作用，它就进了软件工程的地盘。
接下来最该观察的，不是有没有人继续用 Jira 写更复杂的算法。那只是黑客趣味。
真正该看的是企业软件会不会把自动化当代码管理：有没有测试、版本、审计、配额意识；有没有人对一条规则的后果负责。
如果没有，提效工具最后会变成组织里的暗河。平时看不见，出事时谁也说不清水从哪来。
Jira 被证明图灵完备，听起来像一则工程师冷笑话。落到企业现场，它是一句提醒：自动化不会消灭复杂度，只会决定复杂度藏在哪里。