手机里躺着一百多条捷径真正每天点开的不到八条——这是我用了大半年 iOS 12 捷径之后最真实的感受。网上流传的最全整理一百多个捷径打包看着很爽保存下来那一刻成就感拉满但过两周你再打开捷径应用会发现列表长得像一条没有尽头的走廊找一个视频下载要往下滑三屏最后干脆放弃还是老老实实打开应用手动操作。问题从来不是捷径不够多而是捷径库没有结构加上相当一部分下载类、解析类捷径依赖的外部接口早就变了点下去只会转圈然后报错。这篇内容想聊的是整理这件事本身一百多条捷径该怎么分层、怎么命名、怎么判断哪条值得留视频下载类捷径的内部链路长什么样为什么它最容易集体失效地图导航类捷径怎么把三四步操作压成一次点击以及装别人分享的捷径之前怎么花两分钟做一次体检。适合两类人看——刚升级到 iOS 12、对捷径还停留在点一下试试阶段的新手以及已经存了一堆捷径、但用得一团乱、想重新梳理一遍的老用户。下面所有操作步骤和参数都是我在实际配置过程中跑通并反复验证过的涉及第三方接口的部分我会讲原理和思路不会给出会立刻过期的具体地址。1. 收藏一百多条捷径之后真正的问题不是少而是乱先说个反直觉的结论捷径这种东西数量超过三十条之后你的使用频率会开始下降超过六十条基本就只剩收藏这个动作了。原因很简单捷径应用的列表是线性排列的没有搜索框至少在 iOS 12 那个版本的使用体验里翻找成本很高你每次想用一条捷径都要经历回忆名字—滑动寻找—犹豫是不是这条的三步流程。三步加起来超过五秒人就会本能地选择更熟悉的原生操作路径。所以整理的核心目标不是把一百条都留着而是把高频的那十条顶到最容易触碰的位置把低频的几十条折叠到不影响视线的角落。1.1 捷径库失控通常经历三个阶段第一个阶段叫尝鲜期看到什么有意思就存什么天气查询、汇率换算、随机点名、生成二维码一天能存二十条。这个阶段其实无害因为你在建立对捷径能力的认知边界。第二个阶段叫功能重叠期你会发现列表里躺着四条都能下载视频的捷径、三条都能查快递的捷径它们唯一的区别是分享者不同。这时候开始出现选择困难每次用都要想上回哪条是能用的。第三个阶段叫失效堆积期某天你点开一条以前好用的捷径它报无法连接到服务器你没删想着以后再说再过一个月失效的、能用的、没试过的混在一起整个库就废了。我自己是在第二阶段末期意识到问题的。当时为了下载一段短视频连续点了四条捷径两条报错、一条下载下来是张空白图、最后一条成功了但我已经花了两分钟。那天晚上我把整个库清空重来用的就是下面这套结构。1.2 我用的四层分类法按触发场景分不按功能分大多数人分类是按功能分的工具类、娱乐类、效率类、图片类。这套分法听着合理实际用起来很别扭因为你使用捷径的那一刻脑子里想的是我现在在干什么而不是这属于哪个类别。所以我改成按触发场景分层级定位数量控制命名前缀典型内容第一层每天必用5 到 8 条01-一键导航回家、剪贴板存文本、快速记账第二层每周用几次10 到 15 条02-视频下载、图片压缩、批量重命名第三层场景触发20 条以内03-会议录音转文字流程、旅行清单生成第四层试验与参考不限但独立存放09-从网上存的、还没验证过的关键在命名前缀。捷径应用按名称排序数字前缀能把顺序彻底锁死01-开头的永远在最上面09-开头的永远沉底。这个技巧看起来土但效果立竿见影——你不需要记名字只需要记住我要的东西在列表前五个。第四层的处理方式我要单独说一下。我建了一个叫试验田的文件夹所有从外部导入、还没跑通的捷径全部扔进去命名统一加09-前缀。这个文件夹的作用不是使用而是隔离。它保证你的主列表永远是干净的同时又不至于让你因为舍不得删而把垃圾留在视线里。每个月我会清理一次试验田跑通的升到第二层或第三层跑不通的直接删。这条规则执行下来我的主列表从来没超过三十条但覆盖了九成以上的日常需求。还有一个容易被忽略的细节给高频捷径配图标和颜色。iOS 12 的捷径支持自定义图标我给自己定的规则是同一层的捷径用同一色系——第一层全用深色图标第二层用浅色第三层用图案类。这样你在小组件里扫一眼就能定位比读文字快得多。2. 捷径在 iOS 12 上到底是怎么跑起来的很多人把捷径当成手机上的小程序觉得点一下就该有结果。但捷径的本质是一串动作Action按顺序执行的脚本它没有自己的服务器所有能力都来自两类东西系统内置动作以及对外部服务的网络请求。理解这一点你才能明白为什么有些捷径必须联网、为什么有些动作在锁屏状态下点不动、为什么同一条捷径换个网络环境表现完全不同。2.1 动作、变量和 URL Scheme三个绕不开的基础概念动作是捷径的最小执行单元比如获取当前位置获取网页内容存储到相册显示结果。每个动作有输入和输出上一个动作的输出会自动成为下一个动作的输入这条隐式的数据流是捷径最优雅也最容易出错的地方。新手最常犯的错是插入了一个不需要输入的动作导致整条链路的数据流断掉——比如在提取网址之后插了一个显示提醒提醒不吃网址输入链路就断了后面的动作全部拿不到数据。变量用来在动作之间显式传递数据。捷径里有两种一种是设定变量你手动命名后面用获取变量取回另一种是魔法变量它指代的是某一个特定动作的输出你在输入框里点一下就能选。我的经验是短链路五个动作以内用魔法变量更省事长链路一定要用命名变量否则一旦中间插入或删除动作魔法变量的指向会悄悄错位排错时极其痛苦。URL Scheme是捷径调用其他应用的钥匙。几乎所有主流应用都注册了自己的 scheme格式大致是应用标识://路径?参数值。捷径里的打开 URL动作可以直接唤起这些应用把参数带过去。这是导航类捷径能一键跳转的根本原因。需要注意的是scheme 里的中文和特殊字符必须做 URL 编码否则应用收到的是乱码。捷径里有一个专门的URL 编码动作把它插在拼接地址和打开 URL 之间能解决绝大部分跳转失败的问题。2.2 那些反复弹出的权限询问其实是设计如此第一次跑一条涉及位置的捷径系统会弹窗问允许访问位置吗第一次跑一条要写入相册的捷径会问允许访问照片吗。这些弹窗看着烦但它们是捷径安全模型的基础——每个动作在第一次访问敏感资源时都要单独授权。这里有几个实际使用中的坑值得记一下。第一授权是按捷径记录的你复制一条捷径改个名字新的一条要重新授权一遍这不是 bug。第二如果你在设置里关闭了允许不受信任的捷径从外部导入的捷径根本不会出现在列表里会卡在导入页面很多人以为是文件损坏其实是这个开关没开。第三某些动作在锁屏状态或通知中心小组件里执行时会被静默拦截表现为点了没反应这时候要解锁后手动跑一次确认捷径本身没问题。还有一个 iOS 12 特有的体验细节捷径在后台执行较长的网络请求时如果你是切到其他应用再切回来可能会看到进度卡住。这不是捷径挂了而是系统对后台任务的调度策略导致的。我的习惯是涉及到网络请求的捷径跑的时候不要立刻切走等它出结果再说尤其是下载类的中途切走失败率会明显上升。3. 视频下载捷径一条链路里有四个断点短视频平台上的内容想存到本地官方应用里通常不提供直接下载于是下载捷径成了捷径库里最热门的一类需求也是被分享得最多、失效得最快的一类。网上那些一百多个捷径的打包里下载类往往占十几条看起来覆盖了各个平台实际能用的一两条就不错了。3.1 为什么下载类捷径最容易集体失效要理解失效先得理解它怎么工作的。绝大多数下载捷径的核心链路是这样的从剪贴板或分享表单拿到分享链接用正则从链接里提取出内容 ID把 ID 拼进一个第三方解析接口的地址请求这个接口拿到返回的 JSON 或 HTML从返回内容里取出真正的媒体直链再次请求直链拿到二进制文件保存到相册。这条链路里第 3 步和第 5 步依赖的是外部服务和平台页面结构这两样东西都不在你手里。解析接口可能明天就关停平台的分享链接格式可能下个月就改页面里的字段名一换你的正则就匹配不到东西。所以下载类捷径的保质期天然就短这不是分享者偷懒是技术路径决定的。我在实际使用中的做法是只保留自己维护的下载捷径外部导入的一律扔进试验田跑通一次记录下当时的接口和正则失效了就自己改不指望它长期有效。3.2 把一条下载捷径拆成动作看拿我自己维护的一条通用视频下载捷径举例它的动作序列大致是获取剪贴板—— 拿到用户复制的分享文本注意分享文本里往往夹杂一堆描述文字不纯粹是链接从输入中获取 URL—— 这个动作能从一段混杂文字里揪出网址比手写正则稳匹配文本—— 用正则从网址中提取内容 ID正则大致形如/([a-zA-Z0-9]{8,20})具体位数看平台设定变量—— 把 ID 存成命名变量vid文本—— 拼接解析接口地址形式如https://接口域名/parse?id后面接变量获取 URL 内容—— 请求解析接口方法选 GET从输入获取词典值—— 如果接口返回 JSON用这个动作取出直链字段获取 URL 内容—— 请求直链这一步拿到的就是媒体二进制存储到相册—— 把上一步的结果写进相册。中间还要插几个如果动作做分支判断如果剪贴板里没有网址就提示先复制分享链接如果解析接口返回的字段为空就提示解析失败接口可能已失效。这些提示看着是小事但没有它们失败的时候你面对的就是一个没有任何反馈的转圈界面根本不知道断在哪。3.3 自己改一条下载捷径的实操顺序改捷径比从零写要快得多我的顺序是这样的。第一步先用浏览器手动跑一遍链路把分享链接粘进解析接口地址看看返回的 JSON 长什么样直链字段叫什么名字。这一步在手机上用浏览器的开发者工具不方便我会先在电脑上确认把返回的结构记下来。第二步回到捷径里把从输入获取词典值的键名改成你看到的实际字段名这是最容易出错的地方字段名差一个下划线就不通。第三步在获取 URL 内容动作里检查请求方法有些接口要求 POST 并携带表单参数用 GET 会返回空。第四步处理返回格式不是 JSON 的情况——如果是 HTML就要用匹配文本配合正则去抠正则可以先用一段固定样本在本地测试确认能匹配到再放进捷径。有几个实操心得值得单独说。其一获取 URL 内容这个动作在 iOS 12 里对返回内容的大小有限制特别大的媒体文件直接拿可能会失败稳妥的做法是拿到直链后用快速查看展示让用户手动保存。其二保存到相册这一步在某些系统版本上对视频格式有要求如果下载下来是特殊封装的流媒体格式相册可能拒收表现为存了但相册里找不到。其三务必在捷径末尾加一个显示结果把下载状态、文件名或失败原因显示出来这是排错时唯一的线索来源。提示涉及第三方解析接口的捷径我建议自己搭一份备注记录最后一次跑通的时间和当时用的接口特征。接口失效时你能立刻判断是接口问题还是自己的正则问题这个习惯能省掉大量排查时间。4. 地图导航捷径把四步操作压成一次点击导航类捷径是另一大热门也是最能体现捷径到底省了什么的一类。平时导航的完整流程是解锁、找到地图应用、点开、等定位、输入目的地、从候选列表里选中正确的那条、点开始导航。七步。捷径能把中间五步全部省掉只留点捷径和确认。4.1 三个高频场景的动作设计我把导航捷径按场景拆成了三条而不是做成一条万能入口原因后面会说。第一条一键回家。动作序列是获取当前位置→获取行程时间目的地填家庭地址 →显示结果。这条不直接跳地图只告诉你现在回去要多久适合下班前看一眼决定走哪条路。要真正导航就在后面接在地图中显示路线目的地填家庭地址起点用当前位置。第二条从剪贴板地址导航。这条适合在聊天里收到一个地址的场景。序列是获取剪贴板→从输入中获取地址→在地图中显示路线。从输入中获取地址这个动作很关键它能从明天下午三点在某某路 88 号 3 楼见这种句子里把地址部分识别出来比你自己写正则省事得多。第三条周边搜索。序列是询问输入提示语写想找什么 →获取当前位置→ 拼接第三方地图的搜索 scheme →打开 URL。这条依赖第三方应用的 scheme参数里要带上关键词和当前坐标中文关键词必须过一遍 URL 编码。为什么不做成一条万能入口因为我试过。用从菜单中选取把三个场景串起来每次点捷径先弹一个菜单让你选多了一步选择实际体验反而比三个独立图标差。捷径的价值在于零思考直达一旦引入菜单思维成本就回来了。我的原则是一个捷径只服务一个意图意图有分支就拆成多条。4.2 中文地址与坐标转换的几个坑导航类捷径踩的坑八成集中在地址处理上。第一个坑是 URL 编码。中文地址直接拼进 scheme很多应用收不到表现为应用打开了但目的地是空的。解决办法是在拼接和打开之间插入URL 编码动作把整个地址字符串过一遍。第二个坑是坐标系差异。系统定位返回的坐标和某些第三方地图使用的坐标系不是同一套直接把系统坐标喂给第三方应用位置会偏移几百米。这个偏移在国内地图服务里是普遍现象处理方式有两种要么在第三方应用的 scheme 里直接用地址文本而不是坐标让应用自己解析要么在捷径里加一段坐标转换的数学运算把偏移量补回去。前者简单可靠我推荐优先用地址文本。第三个坑是地址识别的精度。从输入中获取地址有时候会把时间、门牌号、楼层混进地址里导致导航到错误位置。我的处理办法是在识别之后加一个显示结果让人确认一眼虽然多了一步但比导航到隔壁小区强。如果地址里包含明显的时间词比如下午三点可以在识别之前用替换文本把这些词先删掉。第四个坑是地图应用的选择。系统自带地图和第三方地图的 scheme 不一样参数名也不一样。我建议把常用的一两个应用的 scheme 记在备忘录里改捷径的时候直接复制别每次现查。scheme 的具体格式各应用不同你在应用里分享一次位置、看看生成的链接结构基本就能反推出规律。5. 装别人分享的捷径之前我必做的五项体检从外部导入捷径本质上是把一段你不认识的脚本放进手机而这段脚本可能请求网络、读取剪贴板、访问相册、获取位置。这不是危言耸听最全整理类打包里的捷径来源复杂有些是二次修改过的动作列表里可能藏着一条你没注意的上传动作。所以我现在形成一个固定习惯导入之后先不跑先读一遍动作。5.1 逐条读动作时重点盯这几类读动作不需要懂编程抓住几个关键点就行。看网络请求类动作获取 URL 内容出现在哪里请求的地址是什么域名有没有把剪贴板内容、位置信息作为参数拼进去。看读写类动作有没有删除照片删除备忘录覆盖文件这类动作如果有它删的是什么。看跳转类动作打开 URL跳去的地址是不是你认识的服务。看循环类动作对每个项目重复里面包了什么如果循环体里是网络请求跑起来可能非常慢甚至卡死。5.2 一份可疑动作对照表动作或特征可能的风险处理建议网络请求里带剪贴板变量剪贴板内容被发送到外部删除该动作或整条弃用请求地址是短链接真实目标不可见先在浏览器展开短链接再判断循环体里套网络请求大量请求、执行超时改成单次请求或分批处理出现删除照片且无确认误删风险加确认步骤或弃用跳转到不明 scheme可能唤起其他应用执行动作只保留你认识的应用 scheme请求参数里带设备标识信息外泄直接弃用这张表不是让你疑神疑鬼而是提供一个快速判断的抓手。我的实际做法是导入后先看动作总数超过二十个动作的捷径我会格外仔细因为动作越多越容易藏东西动作少于五个的通常一目了然扫一眼就能判断。注意读动作的时候不要只看动作名称点进去看参数。有些动作名称是获取网页内容参数里却把剪贴板拼进了请求地址只看名字是看不出来的。6. 跑不通的时候三条排查链路和几个真实的坑捷径报错的信息往往很含糊无法完成操作这种提示几乎不提供任何线索。这时候需要一套固定的排查顺序而不是碰运气地乱改。6.1 先分清是没触发没数据还是没权限我习惯把故障分成三类判断方式完全不同。没触发表现为点了捷径毫无反应或者图标闪一下就没了。这一般是触发入口的问题在锁屏或小组件里执行了需要解锁的动作、或者捷径本身被系统判定为不受信任。判断方法很简单解锁后从捷径应用里直接跑一次能跑就是入口问题跑不了才往下查。没数据表现为跑到一半停了或者结果为空。这一类最常见根源是上游动作没拿到输入。排查方法是把捷径拆开在可疑位置插入快速查看动作把中间变量显示出来看一眼。我经常在匹配文本之后插一个快速查看确认正则到底匹配到了什么——十次里有六次是正则没匹配上因为源文本的格式变了。没权限表现为明确提示没有访问权限。这一类最好查去设置里看对应资源有没有给捷径授权或者把捷径删掉重装一遍重新走授权流程。6.2 我踩过的四个具体坑第一个坑URL 编码漏了。一条导航捷径死活跳不到目的地我把拼好的地址用快速查看打出来发现地址里的中文全变成了问号。加上URL 编码动作后立刻正常。这个坑我后来在三条不同的捷径上重复踩过现在形成肌肉记忆只要拼 URL先想编码。第二个坑正则贪婪匹配。提取内容 ID 的正则写成了(.*)结果把整个链接后半段全吞进去了拼出来的解析地址自然无效。改成限定字符集和长度之后就稳了。正则这个东西宁可写窄一点匹配不到至少能看出问题写太宽反而会拿到一段看起来正常实际错误的数据。第三个坑变量作用域。在一个如果分支里设定的变量在分支外面取不到值这是捷径的执行模型决定的。我一开始把变量设定放在条件分支里主流程取的时候永远是空排查了半天才发现。解决办法是变量在主流程顶层设定分支里只做赋值。第四个坑网络请求的返回类型判断错。有些接口在失败时也返回 200 状态码内容是{code:-1,msg:...}捷径照样往下走到从输入获取词典值取直链时取到空然后保存相册失败。这种问题的排查方式是先把返回的原始内容完整显示出来看它到底返回了什么结构再决定用哪个字段。我给所有涉及接口的捷径都加了一段如果字段为空则提示失败原因的分支虽然多了几个动作但排错效率提升明显。还有一类不是 bug 的假故障值得一提捷径执行到一半切到其他应用回来发现进度卡住。这种情况多半是系统在后台限制了网络请求重新跑一次通常就好不必大改捷径。分清真故障和调度问题能省掉很多无谓的改动。7. 让一百多条捷径真正用起来的两个日常习惯库建好了、捷径跑通了最后能不能用起来取决于触发入口的设计和定期的维护节奏。7.1 触发入口要跟着手的动作走捷径的触发方式有好几种应用内点击、通知中心小组件、分享表单、Siri 语音、主屏幕图标。我的分配原则是高频的放小组件场景相关的放分享表单偶尔用的留在应用内。通知中心小组件是最顺手的入口下拉就能点但它能显示的捷径数量有限所以我只放第一层那五到八条而且顺序按使用频率排最常用的放第一个。分享表单触发适合处理当前内容的捷径比如看到一条视频想下载、看到一段文字想存起来这类捷径配一个分享表单接收项比复制粘贴再打开捷径快得多。Siri 语音我只给两三条用比如回家其他条目的语音触发识别率不稳定喊半天不如手动点。主屏幕图标我基本不用占位置而且图标多了会有视觉噪音。这里有个小技巧给第一层的每条捷径录一句简短的语音触发词别用完整句子用两三个字的短词识别率高很多。触发词之间要有明显区分别都用帮我……开头容易互相干扰。7.2 每月花十分钟做一次捷径体检我给自己定的节奏是每月第一周抽十分钟做三件事清空试验田文件夹里跑不通的、检查第一层捷径是否都还能正常跑、把新发现的高频捷径从第二层升到第一层。这个动作看着简单但它是整个库能持续可用的关键——捷径不是一次性配置好的东西它依赖的外部环境一直在变不定期维护就会慢慢腐烂。体检时我会按一个固定顺序跑一遍第一层的每条捷径遇到报错的当场修修不好就临时降级到第二层避免下次急用的时候发现它坏了。同时我会看一眼试验田的文件数量如果超过二十条说明最近存得太多、消化得太少该停下来清理了。我个人的体会是捷径这个东西的价值不在多而在顺手。一百多条捷径摆在那里你每次用都要找、都要判断能不能跑那它带来的负担已经超过了便利。真正好用的捷径库里每条捷径你都能说出它解决什么问题、什么时候用、断了怎么修。把数量砍到三十条以内把高频的几条打磨到几乎不失败剩下的时间拿去干正事——这才是整理的意义。至于那些打包分享的一百多个捷径我的建议是当作素材库看待挑几条看得懂动作、验证过能跑的留下其余的真不必全存。 
长河君 · 2026/10/31 9:47:10 · 阅读 1.2k iOS 12捷径库整理：视频下载、导航与失效排查
手机里躺着一百多条捷径真正每天点开的不到八条——这是我用了大半年 iOS 12 捷径之后最真实的感受。网上流传的最全整理一百多个捷径打包看着很爽保存下来那一刻成就感拉满但过两周你再打开捷径应用会发现列表长得像一条没有尽头的走廊找一个视频下载要往下滑三屏最后干脆放弃还是老老实实打开应用手动操作。问题从来不是捷径不够多而是捷径库没有结构加上相当一部分下载类、解析类捷径依赖的外部接口早就变了点下去只会转圈然后报错。这篇内容想聊的是整理这件事本身一百多条捷径该怎么分层、怎么命名、怎么判断哪条值得留视频下载类捷径的内部链路长什么样为什么它最容易集体失效地图导航类捷径怎么把三四步操作压成一次点击以及装别人分享的捷径之前怎么花两分钟做一次体检。适合两类人看——刚升级到 iOS 12、对捷径还停留在点一下试试阶段的新手以及已经存了一堆捷径、但用得一团乱、想重新梳理一遍的老用户。下面所有操作步骤和参数都是我在实际配置过程中跑通并反复验证过的涉及第三方接口的部分我会讲原理和思路不会给出会立刻过期的具体地址。1. 收藏一百多条捷径之后真正的问题不是少而是乱先说个反直觉的结论捷径这种东西数量超过三十条之后你的使用频率会开始下降超过六十条基本就只剩收藏这个动作了。原因很简单捷径应用的列表是线性排列的没有搜索框至少在 iOS 12 那个版本的使用体验里翻找成本很高你每次想用一条捷径都要经历回忆名字—滑动寻找—犹豫是不是这条的三步流程。三步加起来超过五秒人就会本能地选择更熟悉的原生操作路径。所以整理的核心目标不是把一百条都留着而是把高频的那十条顶到最容易触碰的位置把低频的几十条折叠到不影响视线的角落。1.1 捷径库失控通常经历三个阶段第一个阶段叫尝鲜期看到什么有意思就存什么天气查询、汇率换算、随机点名、生成二维码一天能存二十条。这个阶段其实无害因为你在建立对捷径能力的认知边界。第二个阶段叫功能重叠期你会发现列表里躺着四条都能下载视频的捷径、三条都能查快递的捷径它们唯一的区别是分享者不同。这时候开始出现选择困难每次用都要想上回哪条是能用的。第三个阶段叫失效堆积期某天你点开一条以前好用的捷径它报无法连接到服务器你没删想着以后再说再过一个月失效的、能用的、没试过的混在一起整个库就废了。我自己是在第二阶段末期意识到问题的。当时为了下载一段短视频连续点了四条捷径两条报错、一条下载下来是张空白图、最后一条成功了但我已经花了两分钟。那天晚上我把整个库清空重来用的就是下面这套结构。1.2 我用的四层分类法按触发场景分不按功能分大多数人分类是按功能分的工具类、娱乐类、效率类、图片类。这套分法听着合理实际用起来很别扭因为你使用捷径的那一刻脑子里想的是我现在在干什么而不是这属于哪个类别。所以我改成按触发场景分层级定位数量控制命名前缀典型内容第一层每天必用5 到 8 条01-一键导航回家、剪贴板存文本、快速记账第二层每周用几次10 到 15 条02-视频下载、图片压缩、批量重命名第三层场景触发20 条以内03-会议录音转文字流程、旅行清单生成第四层试验与参考不限但独立存放09-从网上存的、还没验证过的关键在命名前缀。捷径应用按名称排序数字前缀能把顺序彻底锁死01-开头的永远在最上面09-开头的永远沉底。这个技巧看起来土但效果立竿见影——你不需要记名字只需要记住我要的东西在列表前五个。第四层的处理方式我要单独说一下。我建了一个叫试验田的文件夹所有从外部导入、还没跑通的捷径全部扔进去命名统一加09-前缀。这个文件夹的作用不是使用而是隔离。它保证你的主列表永远是干净的同时又不至于让你因为舍不得删而把垃圾留在视线里。每个月我会清理一次试验田跑通的升到第二层或第三层跑不通的直接删。这条规则执行下来我的主列表从来没超过三十条但覆盖了九成以上的日常需求。还有一个容易被忽略的细节给高频捷径配图标和颜色。iOS 12 的捷径支持自定义图标我给自己定的规则是同一层的捷径用同一色系——第一层全用深色图标第二层用浅色第三层用图案类。这样你在小组件里扫一眼就能定位比读文字快得多。2. 捷径在 iOS 12 上到底是怎么跑起来的很多人把捷径当成手机上的小程序觉得点一下就该有结果。但捷径的本质是一串动作Action按顺序执行的脚本它没有自己的服务器所有能力都来自两类东西系统内置动作以及对外部服务的网络请求。理解这一点你才能明白为什么有些捷径必须联网、为什么有些动作在锁屏状态下点不动、为什么同一条捷径换个网络环境表现完全不同。2.1 动作、变量和 URL Scheme三个绕不开的基础概念动作是捷径的最小执行单元比如获取当前位置获取网页内容存储到相册显示结果。每个动作有输入和输出上一个动作的输出会自动成为下一个动作的输入这条隐式的数据流是捷径最优雅也最容易出错的地方。新手最常犯的错是插入了一个不需要输入的动作导致整条链路的数据流断掉——比如在提取网址之后插了一个显示提醒提醒不吃网址输入链路就断了后面的动作全部拿不到数据。变量用来在动作之间显式传递数据。捷径里有两种一种是设定变量你手动命名后面用获取变量取回另一种是魔法变量它指代的是某一个特定动作的输出你在输入框里点一下就能选。我的经验是短链路五个动作以内用魔法变量更省事长链路一定要用命名变量否则一旦中间插入或删除动作魔法变量的指向会悄悄错位排错时极其痛苦。URL Scheme是捷径调用其他应用的钥匙。几乎所有主流应用都注册了自己的 scheme格式大致是应用标识://路径?参数值。捷径里的打开 URL动作可以直接唤起这些应用把参数带过去。这是导航类捷径能一键跳转的根本原因。需要注意的是scheme 里的中文和特殊字符必须做 URL 编码否则应用收到的是乱码。捷径里有一个专门的URL 编码动作把它插在拼接地址和打开 URL 之间能解决绝大部分跳转失败的问题。2.2 那些反复弹出的权限询问其实是设计如此第一次跑一条涉及位置的捷径系统会弹窗问允许访问位置吗第一次跑一条要写入相册的捷径会问允许访问照片吗。这些弹窗看着烦但它们是捷径安全模型的基础——每个动作在第一次访问敏感资源时都要单独授权。这里有几个实际使用中的坑值得记一下。第一授权是按捷径记录的你复制一条捷径改个名字新的一条要重新授权一遍这不是 bug。第二如果你在设置里关闭了允许不受信任的捷径从外部导入的捷径根本不会出现在列表里会卡在导入页面很多人以为是文件损坏其实是这个开关没开。第三某些动作在锁屏状态或通知中心小组件里执行时会被静默拦截表现为点了没反应这时候要解锁后手动跑一次确认捷径本身没问题。还有一个 iOS 12 特有的体验细节捷径在后台执行较长的网络请求时如果你是切到其他应用再切回来可能会看到进度卡住。这不是捷径挂了而是系统对后台任务的调度策略导致的。我的习惯是涉及到网络请求的捷径跑的时候不要立刻切走等它出结果再说尤其是下载类的中途切走失败率会明显上升。3. 视频下载捷径一条链路里有四个断点短视频平台上的内容想存到本地官方应用里通常不提供直接下载于是下载捷径成了捷径库里最热门的一类需求也是被分享得最多、失效得最快的一类。网上那些一百多个捷径的打包里下载类往往占十几条看起来覆盖了各个平台实际能用的一两条就不错了。3.1 为什么下载类捷径最容易集体失效要理解失效先得理解它怎么工作的。绝大多数下载捷径的核心链路是这样的从剪贴板或分享表单拿到分享链接用正则从链接里提取出内容 ID把 ID 拼进一个第三方解析接口的地址请求这个接口拿到返回的 JSON 或 HTML从返回内容里取出真正的媒体直链再次请求直链拿到二进制文件保存到相册。这条链路里第 3 步和第 5 步依赖的是外部服务和平台页面结构这两样东西都不在你手里。解析接口可能明天就关停平台的分享链接格式可能下个月就改页面里的字段名一换你的正则就匹配不到东西。所以下载类捷径的保质期天然就短这不是分享者偷懒是技术路径决定的。我在实际使用中的做法是只保留自己维护的下载捷径外部导入的一律扔进试验田跑通一次记录下当时的接口和正则失效了就自己改不指望它长期有效。3.2 把一条下载捷径拆成动作看拿我自己维护的一条通用视频下载捷径举例它的动作序列大致是获取剪贴板—— 拿到用户复制的分享文本注意分享文本里往往夹杂一堆描述文字不纯粹是链接从输入中获取 URL—— 这个动作能从一段混杂文字里揪出网址比手写正则稳匹配文本—— 用正则从网址中提取内容 ID正则大致形如/([a-zA-Z0-9]{8,20})具体位数看平台设定变量—— 把 ID 存成命名变量vid文本—— 拼接解析接口地址形式如https://接口域名/parse?id后面接变量获取 URL 内容—— 请求解析接口方法选 GET从输入获取词典值—— 如果接口返回 JSON用这个动作取出直链字段获取 URL 内容—— 请求直链这一步拿到的就是媒体二进制存储到相册—— 把上一步的结果写进相册。中间还要插几个如果动作做分支判断如果剪贴板里没有网址就提示先复制分享链接如果解析接口返回的字段为空就提示解析失败接口可能已失效。这些提示看着是小事但没有它们失败的时候你面对的就是一个没有任何反馈的转圈界面根本不知道断在哪。3.3 自己改一条下载捷径的实操顺序改捷径比从零写要快得多我的顺序是这样的。第一步先用浏览器手动跑一遍链路把分享链接粘进解析接口地址看看返回的 JSON 长什么样直链字段叫什么名字。这一步在手机上用浏览器的开发者工具不方便我会先在电脑上确认把返回的结构记下来。第二步回到捷径里把从输入获取词典值的键名改成你看到的实际字段名这是最容易出错的地方字段名差一个下划线就不通。第三步在获取 URL 内容动作里检查请求方法有些接口要求 POST 并携带表单参数用 GET 会返回空。第四步处理返回格式不是 JSON 的情况——如果是 HTML就要用匹配文本配合正则去抠正则可以先用一段固定样本在本地测试确认能匹配到再放进捷径。有几个实操心得值得单独说。其一获取 URL 内容这个动作在 iOS 12 里对返回内容的大小有限制特别大的媒体文件直接拿可能会失败稳妥的做法是拿到直链后用快速查看展示让用户手动保存。其二保存到相册这一步在某些系统版本上对视频格式有要求如果下载下来是特殊封装的流媒体格式相册可能拒收表现为存了但相册里找不到。其三务必在捷径末尾加一个显示结果把下载状态、文件名或失败原因显示出来这是排错时唯一的线索来源。提示涉及第三方解析接口的捷径我建议自己搭一份备注记录最后一次跑通的时间和当时用的接口特征。接口失效时你能立刻判断是接口问题还是自己的正则问题这个习惯能省掉大量排查时间。4. 地图导航捷径把四步操作压成一次点击导航类捷径是另一大热门也是最能体现捷径到底省了什么的一类。平时导航的完整流程是解锁、找到地图应用、点开、等定位、输入目的地、从候选列表里选中正确的那条、点开始导航。七步。捷径能把中间五步全部省掉只留点捷径和确认。4.1 三个高频场景的动作设计我把导航捷径按场景拆成了三条而不是做成一条万能入口原因后面会说。第一条一键回家。动作序列是获取当前位置→获取行程时间目的地填家庭地址 →显示结果。这条不直接跳地图只告诉你现在回去要多久适合下班前看一眼决定走哪条路。要真正导航就在后面接在地图中显示路线目的地填家庭地址起点用当前位置。第二条从剪贴板地址导航。这条适合在聊天里收到一个地址的场景。序列是获取剪贴板→从输入中获取地址→在地图中显示路线。从输入中获取地址这个动作很关键它能从明天下午三点在某某路 88 号 3 楼见这种句子里把地址部分识别出来比你自己写正则省事得多。第三条周边搜索。序列是询问输入提示语写想找什么 →获取当前位置→ 拼接第三方地图的搜索 scheme →打开 URL。这条依赖第三方应用的 scheme参数里要带上关键词和当前坐标中文关键词必须过一遍 URL 编码。为什么不做成一条万能入口因为我试过。用从菜单中选取把三个场景串起来每次点捷径先弹一个菜单让你选多了一步选择实际体验反而比三个独立图标差。捷径的价值在于零思考直达一旦引入菜单思维成本就回来了。我的原则是一个捷径只服务一个意图意图有分支就拆成多条。4.2 中文地址与坐标转换的几个坑导航类捷径踩的坑八成集中在地址处理上。第一个坑是 URL 编码。中文地址直接拼进 scheme很多应用收不到表现为应用打开了但目的地是空的。解决办法是在拼接和打开之间插入URL 编码动作把整个地址字符串过一遍。第二个坑是坐标系差异。系统定位返回的坐标和某些第三方地图使用的坐标系不是同一套直接把系统坐标喂给第三方应用位置会偏移几百米。这个偏移在国内地图服务里是普遍现象处理方式有两种要么在第三方应用的 scheme 里直接用地址文本而不是坐标让应用自己解析要么在捷径里加一段坐标转换的数学运算把偏移量补回去。前者简单可靠我推荐优先用地址文本。第三个坑是地址识别的精度。从输入中获取地址有时候会把时间、门牌号、楼层混进地址里导致导航到错误位置。我的处理办法是在识别之后加一个显示结果让人确认一眼虽然多了一步但比导航到隔壁小区强。如果地址里包含明显的时间词比如下午三点可以在识别之前用替换文本把这些词先删掉。第四个坑是地图应用的选择。系统自带地图和第三方地图的 scheme 不一样参数名也不一样。我建议把常用的一两个应用的 scheme 记在备忘录里改捷径的时候直接复制别每次现查。scheme 的具体格式各应用不同你在应用里分享一次位置、看看生成的链接结构基本就能反推出规律。5. 装别人分享的捷径之前我必做的五项体检从外部导入捷径本质上是把一段你不认识的脚本放进手机而这段脚本可能请求网络、读取剪贴板、访问相册、获取位置。这不是危言耸听最全整理类打包里的捷径来源复杂有些是二次修改过的动作列表里可能藏着一条你没注意的上传动作。所以我现在形成一个固定习惯导入之后先不跑先读一遍动作。5.1 逐条读动作时重点盯这几类读动作不需要懂编程抓住几个关键点就行。看网络请求类动作获取 URL 内容出现在哪里请求的地址是什么域名有没有把剪贴板内容、位置信息作为参数拼进去。看读写类动作有没有删除照片删除备忘录覆盖文件这类动作如果有它删的是什么。看跳转类动作打开 URL跳去的地址是不是你认识的服务。看循环类动作对每个项目重复里面包了什么如果循环体里是网络请求跑起来可能非常慢甚至卡死。5.2 一份可疑动作对照表动作或特征可能的风险处理建议网络请求里带剪贴板变量剪贴板内容被发送到外部删除该动作或整条弃用请求地址是短链接真实目标不可见先在浏览器展开短链接再判断循环体里套网络请求大量请求、执行超时改成单次请求或分批处理出现删除照片且无确认误删风险加确认步骤或弃用跳转到不明 scheme可能唤起其他应用执行动作只保留你认识的应用 scheme请求参数里带设备标识信息外泄直接弃用这张表不是让你疑神疑鬼而是提供一个快速判断的抓手。我的实际做法是导入后先看动作总数超过二十个动作的捷径我会格外仔细因为动作越多越容易藏东西动作少于五个的通常一目了然扫一眼就能判断。注意读动作的时候不要只看动作名称点进去看参数。有些动作名称是获取网页内容参数里却把剪贴板拼进了请求地址只看名字是看不出来的。6. 跑不通的时候三条排查链路和几个真实的坑捷径报错的信息往往很含糊无法完成操作这种提示几乎不提供任何线索。这时候需要一套固定的排查顺序而不是碰运气地乱改。6.1 先分清是没触发没数据还是没权限我习惯把故障分成三类判断方式完全不同。没触发表现为点了捷径毫无反应或者图标闪一下就没了。这一般是触发入口的问题在锁屏或小组件里执行了需要解锁的动作、或者捷径本身被系统判定为不受信任。判断方法很简单解锁后从捷径应用里直接跑一次能跑就是入口问题跑不了才往下查。没数据表现为跑到一半停了或者结果为空。这一类最常见根源是上游动作没拿到输入。排查方法是把捷径拆开在可疑位置插入快速查看动作把中间变量显示出来看一眼。我经常在匹配文本之后插一个快速查看确认正则到底匹配到了什么——十次里有六次是正则没匹配上因为源文本的格式变了。没权限表现为明确提示没有访问权限。这一类最好查去设置里看对应资源有没有给捷径授权或者把捷径删掉重装一遍重新走授权流程。6.2 我踩过的四个具体坑第一个坑URL 编码漏了。一条导航捷径死活跳不到目的地我把拼好的地址用快速查看打出来发现地址里的中文全变成了问号。加上URL 编码动作后立刻正常。这个坑我后来在三条不同的捷径上重复踩过现在形成肌肉记忆只要拼 URL先想编码。第二个坑正则贪婪匹配。提取内容 ID 的正则写成了(.*)结果把整个链接后半段全吞进去了拼出来的解析地址自然无效。改成限定字符集和长度之后就稳了。正则这个东西宁可写窄一点匹配不到至少能看出问题写太宽反而会拿到一段看起来正常实际错误的数据。第三个坑变量作用域。在一个如果分支里设定的变量在分支外面取不到值这是捷径的执行模型决定的。我一开始把变量设定放在条件分支里主流程取的时候永远是空排查了半天才发现。解决办法是变量在主流程顶层设定分支里只做赋值。第四个坑网络请求的返回类型判断错。有些接口在失败时也返回 200 状态码内容是{code:-1,msg:...}捷径照样往下走到从输入获取词典值取直链时取到空然后保存相册失败。这种问题的排查方式是先把返回的原始内容完整显示出来看它到底返回了什么结构再决定用哪个字段。我给所有涉及接口的捷径都加了一段如果字段为空则提示失败原因的分支虽然多了几个动作但排错效率提升明显。还有一类不是 bug 的假故障值得一提捷径执行到一半切到其他应用回来发现进度卡住。这种情况多半是系统在后台限制了网络请求重新跑一次通常就好不必大改捷径。分清真故障和调度问题能省掉很多无谓的改动。7. 让一百多条捷径真正用起来的两个日常习惯库建好了、捷径跑通了最后能不能用起来取决于触发入口的设计和定期的维护节奏。7.1 触发入口要跟着手的动作走捷径的触发方式有好几种应用内点击、通知中心小组件、分享表单、Siri 语音、主屏幕图标。我的分配原则是高频的放小组件场景相关的放分享表单偶尔用的留在应用内。通知中心小组件是最顺手的入口下拉就能点但它能显示的捷径数量有限所以我只放第一层那五到八条而且顺序按使用频率排最常用的放第一个。分享表单触发适合处理当前内容的捷径比如看到一条视频想下载、看到一段文字想存起来这类捷径配一个分享表单接收项比复制粘贴再打开捷径快得多。Siri 语音我只给两三条用比如回家其他条目的语音触发识别率不稳定喊半天不如手动点。主屏幕图标我基本不用占位置而且图标多了会有视觉噪音。这里有个小技巧给第一层的每条捷径录一句简短的语音触发词别用完整句子用两三个字的短词识别率高很多。触发词之间要有明显区分别都用帮我……开头容易互相干扰。7.2 每月花十分钟做一次捷径体检我给自己定的节奏是每月第一周抽十分钟做三件事清空试验田文件夹里跑不通的、检查第一层捷径是否都还能正常跑、把新发现的高频捷径从第二层升到第一层。这个动作看着简单但它是整个库能持续可用的关键——捷径不是一次性配置好的东西它依赖的外部环境一直在变不定期维护就会慢慢腐烂。体检时我会按一个固定顺序跑一遍第一层的每条捷径遇到报错的当场修修不好就临时降级到第二层避免下次急用的时候发现它坏了。同时我会看一眼试验田的文件数量如果超过二十条说明最近存得太多、消化得太少该停下来清理了。我个人的体会是捷径这个东西的价值不在多而在顺手。一百多条捷径摆在那里你每次用都要找、都要判断能不能跑那它带来的负担已经超过了便利。真正好用的捷径库里每条捷径你都能说出它解决什么问题、什么时候用、断了怎么修。把数量砍到三十条以内把高频的几条打磨到几乎不失败剩下的时间拿去干正事——这才是整理的意义。至于那些打包分享的一百多个捷径我的建议是当作素材库看待挑几条看得懂动作、验证过能跑的留下其余的真不必全存。