作为一种供用户自制的自动化工具，Shortcuts 一旦出问题，例如卡死、无响应，通常不需要承担付费软件那样的严重后果。
早期，Shortcuts 动作跑不动，多半是用户设计不当。例如老维蒂奇的那个套壳截图动作，步骤多达几百个，估计也就是每年换最新设备的他本人未察觉异样，起码我这种旧设备用户，并不配运行（我设计了自己版本的套壳截图动作）。
后来，逐渐有人意识到 Shortcuts 有内存限制，大意是在 Share Sheet 等页面，不能运行太复杂的动作，最好在 Shortcuts 主程序中跑。
这些历史成了 Shortcuts 的免死金牌，除了我，几乎无人质疑过 Shortcuts 本身（最多只是抱怨新功能太少）。毕竟，用户还有最后一根救命稻草嘛——关机重启。
但自 iOS 引入锁屏小组件以降，Shortcuts 动作无响应的问题日益严重（或许和 Share Sheet 背后的内存限制有所关联），例如我最常用的实时公交查询，经常在运行一两次之后就无响应，当我想查另一趟线路时，无论点击锁屏界面的按钮，还是尝试切到 Shortcuts 软件，都无济于事。
虽说关机重启必然能够解决问题，但很不巧，需要查询公交的时候，往往正值上下班，也是甲方客户来电的小高峰（尤其是早晨），关机唯恐漏接电话。即便没有这种职业迫害妄想，我也不希望频繁开关机，这意味着我根本没有找到病因，只是胡乱涂抹万金油。
线索恰恰在“无响应”这三个字上。你可以做一个实验，将问题确定到具体的 Shortcuts 动作，而非整个 Shortcuts 软件：尝试运行另一个动作。通常，出问题的只有最初的动作，其他并不受影响，这强烈暗示了只是某个 Shortcuts 动作进程运行受阻。当然，退出 Shortcuts 软件并无助益，因为进程和软件本就有所分离，即便 Shortcuts 软件已经退出重启，后台陷入麻烦的动作也没有得救。
答案简单到令人发笑：在 Shortcuts 主程序中，复制（Duplicate）问题动作，然后运行复制后的，问题解决。其实，原动作也可以正常运行了。
一个 Shortcuts 动作，大致相当于电脑上的一个或一扎进程，如果电脑上有软件（进程）卡死，稍有经验的读者都知道呼出进程管理器，有些人甚至已经养成了肌肉记忆，可以在默认的电脑上闭着眼睛按下快捷键、调出管理界面（macOS 没有原生图形界面，我写了一个）。但是，iOS 从未有过、以后也不太可能会有——毕竟连 macOS 都慢慢失去了这些基础工具——这反过来导致，我们很少从进程的角度考虑 Shortcuts。
傻瓜式工具给用户的智力截肢。