文章核心内容：作者通过构建Minsky寄存器机，证明Atlassian的项目管理工具Jira具有图灵完备性。具体方法是将Minsky机的指令映射到Jira自动化功能中，展示了如何用Jira实现计数器增减和条件跳转等基本计算操作，从而完成图灵完备性的验证。

标题：Jira具备图灵完备性

作者：Nicolas Seriot

发表日期：2026年5月22日

工程界一直有传言称，Atlassian的项目管理工具Jira具备图灵完备性。但此前的说法仅模糊地指向自动化功能，未提供具体证明。本文通过构建一个Minsky寄存器机，完整展示了Jira如何实现图灵完备的计算模型。

计算模型映射

Minsky寄存器机仅需两个无限计数器和有限的状态指令集：
- 增量指令：INC r; goto S
- 减量指令：DEC r; if r == 0 goto S else goto S'

在Jira中的实现方式如下：
| Minsky机器 | Jira对应 |
|------------|----------|
| 寄存器A | 关联的Bug类型问题计数 |
| 寄存器B | 关联的Task类型问题计数 |
| 程序计数器 | 单个Epic问题的状态 |
| 指令表 | 每条状态对应的自动化规则 |
| 时钟信号 | 自动化触发或手动重启 |

Epic的状态编码当前指令，自动化规则通过检查关联问题数量决定状态跳转。增量/减量操作通过创建/删除对应类型问题实现，条件分支则通过JQL条件规则完成。

加法实现案例

核心步骤：
1. 创建工作流：创建含BACKLOG、TODO、DEV、PROD状态的Epic
2. 设置规则：
- TODO状态：删除一个Bug（减量A），若无Bug则跳转至PROD终止
- DEV状态：创建一个Task（增量B），返回TODO
3. 初始化：关联2个Bug（A=2）和3个Task（B=3）
4. 启动：将Epic设为TODO，最终得到0个Bug和5个Task（2+3=5）

操作视频展示了实际运行过程。

斐波那契数列实现

通过问题类型转换优化指令集，仅需三个状态：
- TODO：将Task转为Story并增量Bug
- QA：将Bug转为Task
- DEV：将Story转为Bug

初始值A=1, B=1, C=0时，Task计数将输出斐波那契序列1, 1, 2, 3, 5...。由于Jira Cloud的链深度限制为10，需人工触发继续运行，但这不影响图灵完备性证明。

结论

Jira的自动化语言在允许无限问题创建和规则执行的假设下，可完整实现两计数器机器。尽管实际系统存在资源限制，但按照计算机科学惯例，Jira具备图灵完备性。那些复杂的Jira自动化流程，本质上就是程序。

（注：保留核心证明逻辑与关键实现细节，删减了部分技术配置说明和次要注释）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 对Jira的负面评价（主要观点）

• 批评Jira用户体验差、操作复杂："Feels like programming in assembly"（评论4）/ "突然进入编辑模式的双击操作令人崩溃"（评论7）
• 抱怨性能问题："JIRA is so slow... I have trauma from using it!"（评论9）/ "布局频繁变动导致误操作"（评论14）

2. 对Jira的积极利用

• 自动化改善体验："通过自动化实现子任务故事点自动汇总"（评论10）
• 作为职场防御工具："用数百条Jira更新记录保护自己"（评论5）

3. 技术性讨论

• 图灵完备性争议："所有工作流引擎本质都是图灵完备的"（评论1）vs "系统需要即时可用性才符合图灵测试"（评论8）
• 复杂度质疑："真正的成就是构建复杂而非图灵完备的系统"（评论16）

4. 改进建议

• AI整合需求："需要AI原生支持自动设置工作流"（评论12）
• 轻量替代方案："60%公司用Trello可能更合适"（评论13）/ "寻求低成本本地替代品"（评论11）

5. 讽刺性评论

• 极端比喻："比Brainfuck语言更令人作呕"（评论6）
• 玩笑式吐槽："等不及在上面运行DOOM游戏"（评论15）

关键矛盾点体现在：工具本身的缺陷（7条负面评论）vs 用户通过技术手段的改造能力（3条正面案例），同时有4条评论聚焦技术特性讨论。