1. 从一张截图到自动化流程：这个快捷指令到底解决了什么
每到学期中后段，校园里总有一类重复度极高、却又不得不做的事——临时出校申请。尤其是那些实行相对封闭管理的校区，出门一趟要在手机上点开某个应用或网页，登录、选校区、填事由、选时间、提交、等审批，一整套下来少说也要一两分钟。如果一天要出去两三次，或者临时被叫去校外取个快递、办个事，这种重复操作就很磨人。
我最早注意到这个需求，是因为身边不少同学在群里问“有没有办法一键提交出校申请”。后来我自己动手做了一套基于 iPhone 快捷指令的自动化方案，把原本需要手动点七八下的流程压缩到一次点击，甚至配合自动化触发做到“到点自动填好、只需确认提交”。这篇文章就把整套思路、实现细节、踩过的坑和优化技巧完整拆开讲一遍。
需要先说明的是，这类申请本质上是一个“表单提交”行为，核心难点不在于技术有多复杂，而在于如何稳定地复用登录态、如何正确构造请求、以及如何应对页面结构变化。我见过太多人一上来就想用纯 UI 自动化去点按钮，结果页面一改版就全废。所以这套方案的设计原则是：能走接口就走接口，UI 自动化只作为兜底。
这篇文章适合三类人看：一是想直接抄作业、快速用上现成快捷指令的同学；二是想理解背后原理、自己动手改造成其他类似申请流程的进阶用户；三是对 iOS 快捷指令自动化感兴趣、想拿一个真实场景练手的技术爱好者。不管你属于哪一类，我都会把每一步讲清楚，包括为什么这么选、参数怎么算、哪里容易翻车。
2. 整体方案设计与技术选型拆解
2.1 为什么优先选“接口直连”而不是“模拟点击”
做任何自动化之前，第一件事是判断目标系统的交互方式。校园出校申请通常有两种形态：一种是纯网页表单（H5 或 PC 端页面），另一种是封装在某个 App 里的原生页面。前者对我们最友好，因为可以用 HTTP 请求直接提交；后者如果 App 没有做防护，也可以通过抓包拿到接口。
我实测下来，绝大多数高校的这类申请系统，底层都是一个普通的 HTTP 表单提交，登录态靠 Cookie 或 Token 维持。这意味着只要我们能拿到登录后的凭证，就可以用快捷指令里的“获取 URL 内容”动作直接发 POST 请求，完全绕过 UI 点击。这样做的好处非常明显：
- 速度快：一次请求几百毫秒，比模拟点击快十倍以上。
- 稳定性高：不受页面渲染、网络波动导致的元素定位失败影响。
- 可复用：同一套逻辑稍作修改就能迁移到请假、报备、打卡等场景。
当然，接口直连也有前提：你得先抓到正确的请求。这一步我会在下一节详细讲。如果目标系统做了较强的签名校验或动态 Token，那接口方案成本会陡增，这时候再退回 UI 自动化。
2.2 快捷指令在整个链路中的角色定位
很多人对快捷指令有误解，觉得它只能做“打开某个 App”这种简单事。实际上，快捷指令的“获取 URL 内容”动作支持完整的 HTTP 方法、请求头、请求体，配合“文本”“词典”“变量”等动作，完全可以承担一个轻量级 API 客户端的角色。
在这套方案里，快捷指令负责四件事：
- 维护登录凭证：把抓到的 Cookie 或 Token 存成变量或文本，供后续请求复用。
- 构造请求体：把出校事由、时间、校区等字段拼成目标接口需要的格式（通常是 JSON 或表单编码）。
- 发送请求并解析响应：判断提交是否成功，失败时给出提示。
- 对外暴露入口：可以放在主屏幕、小组件，或者用“嘿 Siri”唤醒。
至于登录态怎么获取、请求怎么抓，这些是在电脑上完成的准备工作，属于“一次性成本”。做完之后，日常使用就只剩点一下。
2.3 方案选型对比：三种实现路径的取舍
为了让你心里有数，我把常见的三种实现路径列出来对比一下：
| 方案 | 实现难度 | 稳定性 | 维护成本 | 适用场景 |
|---|---|---|---|---|
| 接口直连 | 中 | 高 | 低（接口不变则长期可用） | 网页表单类申请 |
| UI 自动化（快捷指令打开 App 后模拟操作） | 低 | 低 | 高（页面一改就废） | 无接口可抓的 App |
| 半自动（快捷指令预填，手动提交） | 低 | 高 | 低 | 有强校验、无法直连 |
我的建议是：先花二十分钟尝试抓包，能抓到接口就坚决走接口方案。抓不到再考虑半自动。纯 UI 自动化我一般不推荐，因为校园系统的页面改版频率虽然不高，但一旦改了，你之前录制的所有点击步骤都要重来，非常折磨。
3. 核心细节解析与实操要点
3.1 抓包前的准备工作与工具选择
要拿到提交接口，第一步是抓包。这里我用的是电脑端的抓包工具配合手机代理的方式。具体来说，需要在电脑上运行一个抓包软件，把手机的网络请求代理到电脑上，这样手机上发生的所有 HTTP 请求都能在电脑上看到。
注意：抓包涉及网络流量的中间人解析，请仅用于自己账号的合法调试，不要用于任何未经授权的场景。另外，部分校园系统可能启用了证书校验，需要额外安装根证书才能解密 HTTPS 流量，这一步按抓包工具的官方指引操作即可。
准备工作清单：
- 一台电脑（Windows 或 Mac 均可）
- 抓包工具（常见的有几款，选你顺手的）
- 手机和电脑连在同一个局域网下
- 手机端在 Wi-Fi 设置里配置好代理地址和端口
配置完成后，先在手机上正常走一遍出校申请流程，同时在电脑上观察抓到的请求。重点找那个“提交”动作对应的请求，通常是一个 POST 请求，URL 里带有 submit、apply、save 之类的关键词。
3.2 如何从一堆请求里精准定位提交接口
抓包界面里请求很多，怎么快速找到目标？我的经验是分三步筛：
- 按时间排序，找提交那一刻的请求。你可以在点击“提交”按钮的瞬间留意电脑屏幕，新冒出来的请求大概率就是。
- 看请求方法。提交表单通常是 POST，而页面加载、图片、样式这些多是 GET。
- 看请求体。点开请求详情，如果 Body 里包含了你填写的“事由”“时间”“校区”等字段，那就找对了。
找到之后，把这几样东西记下来：
- 完整的请求 URL
- 请求方法（POST）
- 请求头里的关键字段，尤其是 Cookie、Content-Type、以及可能的 Token 字段
- 请求体的完整内容
这里有个细节很多人会忽略：请求体里除了你填的字段，往往还有一些隐藏字段，比如表单 ID、校区编码、时间戳等。这些字段必须原样带上，否则接口会报错。所以抓包时一定要把整个 Body 完整复制下来，不要只抄你认识的那几个。
3.3 登录态维持：Cookie 与 Token 的取舍
登录态是整套方案能否长期运行的关键。校园系统的登录态一般有两种形式：
- Cookie：登录成功后服务器下发一个会话 Cookie，后续请求带上它就算已登录。
- Token：登录接口返回一个字符串，后续请求放在请求头或参数里。
Cookie 的优点是抓一次能用一段时间，缺点是会过期，过期后需要重新抓。Token 类似，但有些系统 Token 有效期更短。
我的处理方式是：把 Cookie 或 Token 单独存成一个文本变量，放在快捷指令的开头。这样过期时只需要改这一个地方，不用动整个流程。同时我会在快捷指令里加一个判断：如果响应里出现“未登录”“请重新登录”之类的字样，就弹窗提醒我去更新凭证。
实操心得：Cookie 的有效期通常和服务器配置有关，有的几天，有的几周。我建议每隔一段时间主动测试一次，别等到急着出门时才发现失效。可以在快捷指令里加一个“测试登录态”的分支，平时偶尔跑一下。
3.4 请求体的字段构造与编码问题
构造请求体是第二个容易翻车的地方。目标接口通常接受两种格式：
- JSON：
{"reason": "取快递", "campus": "1", "startTime": "..."} - 表单编码：
reason=取快递&campus=1&startTime=...
快捷指令里，JSON 用“词典”动作配合“获取词典值”来构造比较直观；表单编码则直接用文本拼接。关键是要和抓包看到的格式完全一致，包括字段名的拼写、大小写、顺序（有些系统对顺序敏感）。
还有一个坑是中文编码。表单编码里的中文需要做 URL 编码，否则可能乱码。快捷指令的“获取 URL 内容”动作在发送时通常会自动处理，但如果你手动拼接字符串，最好用“URL 编码”动作处理一下中文和特殊字符。
时间字段也经常出问题。有的系统要求2024-01-01 10:00:00这种格式，有的要求时间戳。抓包时看清楚原始格式，然后在快捷指令里用“格式化日期”动作生成对应格式。
4. 完整实操流程：从零到一键提交
4.1 第一步：抓取并验证提交请求
假设你已经在电脑上抓到了提交请求，现在要做的第一件事是在电脑上先验证这个请求能不能成功。这一步非常关键，能避免你把错误的东西搬进快捷指令。
验证方法：用抓包工具自带的“重放”功能，或者用命令行工具（如 curl）手动发一次同样的请求。如果返回成功，说明你抓到的请求是完整可用的；如果失败，检查是不是漏了请求头或字段。
curl -X POST 'https://example.edu/api/apply/submit' \ -H 'Content-Type: application/json' \ -H 'Cookie: sessionid=xxxxxxxx' \ -d '{"reason":"取快递","campus":"1","startTime":"2024-01-01 10:00:00"}'上面是一个示意，实际 URL 和字段以你抓到的为准。验证通过后，把这些内容整理成一份“请求模板”，后面直接往快捷指令里填。
4.2 第二步：在快捷指令里搭建请求骨架
打开快捷指令 App，新建一个快捷指令，按下面的顺序添加动作：
- 文本：存放 Cookie 或 Token。
- 文本：存放请求 URL。
- 词典：构造请求体，键值对对应抓包看到的字段。
- 获取 URL 内容：方法选 POST，请求体选 JSON（或表单），请求头里加上 Cookie 和 Content-Type。
- 显示结果：把响应内容显示出来，方便调试。
第一次搭建时，建议所有字段都写死（比如事由固定为“取快递”），先跑通再说。跑通之后，再把需要变化的部分改成“询问输入”或“从剪贴板获取”。
注意：快捷指令的“获取 URL 内容”动作在不同 iOS 版本里界面略有差异，但核心字段（URL、方法、请求头、请求体）是一致的。如果找不到某个选项，检查一下是不是被折叠在“显示更多”里。
4.3 第三步：加入动态输入与时间计算
固定字段跑通后，就可以让它变得实用。我通常会把“事由”做成一个菜单，列出几个常用选项（取快递、办事、就医等），用户点一下即可。时间字段则用“当前日期”加上“调整日期”动作，比如默认出校时间设为当前时间，返校时间设为当前时间加两小时。
这里有个计算细节：如果系统要求的时间格式是yyyy-MM-dd HH:mm，就用“格式化日期”动作，格式字符串填yyyy-MM-dd HH:mm。如果要求时间戳，就用“获取日期的秒数”之类的动作转换。不同系统要求不同，以抓包看到的为准。
4.4 第四步：响应解析与成功失败判断
提交之后，服务器会返回一段内容，可能是 JSON，也可能是 HTML。我们需要判断这次提交到底成没成功。常见做法是：
- 如果返回 JSON，用“获取词典值”取出状态码字段，判断是否等于成功值。
- 如果返回 HTML，用“文本匹配”或“如果”动作检查是否包含“成功”“已提交”等关键词。
判断完成后，用“显示通知”或“显示提醒”告诉用户结果。我一般会做成：成功就弹一个简短通知，失败就把完整响应显示出来，方便排查。
4.5 第五步：放到主屏幕与 Siri 唤醒
最后一步是让它变得触手可及。长按快捷指令，选择“添加到主屏幕”，这样桌面上就多了一个图标，点一下就能提交。还可以在“快捷指令”App 的自动化标签里，设置特定时间或特定条件触发。
如果想让 Siri 也能调用，给快捷指令起一个顺口的名字，比如“提交出校申请”，然后说“嘿 Siri，提交出校申请”即可。实测下来识别率还不错，前提是名字别太长太绕。
5. 常见问题与排查技巧实录
5.1 提交失败但看不出原因怎么办
这是最常见的问题。我的排查顺序是：
- 先看响应内容。把“显示结果”动作放在请求之后，看看服务器到底返回了什么。很多时候错误信息就写在响应里。
- 对比抓包请求。把你快捷指令里发的请求和抓包看到的原始请求逐字段对比，重点看请求头、Content-Type、字段名。
- 检查 Cookie 是否过期。如果响应提示未登录，那就是凭证失效了。
- 检查时间格式。时间字段格式不对是高频错误，尤其是跨天、跨月的时候。
下面这张表可以帮你快速定位：
| 现象 | 可能原因 | 解决方向 |
|---|---|---|
| 返回“未登录” | Cookie/Token 过期 | 重新抓包更新凭证 |
| 返回参数错误 | 字段名或格式不对 | 对比抓包原始请求 |
| 返回 404 | URL 变了 | 重新抓包获取新地址 |
| 请求超时 | 网络问题或接口限流 | 检查网络，降低频率 |
| 中文乱码 | 编码问题 | 对中文做 URL 编码 |
5.2 Cookie 频繁失效的应对策略
如果发现 Cookie 没几天就失效，有几个方向可以尝试：
- 检查是否有“记住我”选项。登录时勾选后，服务器可能下发有效期更长的凭证。
- 看是否有刷新接口。有些系统提供 Token 刷新接口，可以用快捷指令定时调用。
- 退而求其次做半自动。如果实在无法长期维持，就把快捷指令改成“预填表单 + 打开网页”，最后一步手动点提交。虽然多一步，但比全手动快很多。
实操心得：我一般会在快捷指令里加一个“凭证更新”分支，把新抓到的 Cookie 直接粘贴进去就能替换，不用重新搭整个流程。这个设计能省下大量维护时间。
5.3 页面改版后如何快速修复
校园系统改版是迟早的事。改版后通常表现为：URL 变了、字段名变了、或者多了新的校验字段。修复流程和第一次搭建一样：重新抓包、重新验证、更新快捷指令里的对应部分。
为了降低修复成本，我在搭建时会把“易变部分”集中放在快捷指令开头，比如 URL、Cookie、字段名都放在前几个动作里。这样改版时只需要改开头几处，后面的逻辑不用动。
5.4 几个容易被忽略的细节
- 请求频率：不要短时间内反复提交，有些系统会限流甚至封号。测试时也要克制。
- 重复提交：如果网络慢，用户可能连点两次，导致重复申请。可以在快捷指令里加一个简单的防抖，比如提交后显示“已提交，请勿重复操作”。
- 隐私：Cookie 和 Token 等同于你的登录凭证，不要分享给他人，也不要把带凭证的快捷指令直接发给别人。
- 合规：这套方案只是把你自己手动做的事自动化，申请内容必须真实，不要用它来伪造事由或绕过正常管理。
6. 进阶玩法：把这套思路迁移到其他场景
这套“抓包 + 接口直连 + 快捷指令”的组合拳，其实不限于出校申请。我后来把它迁移到了好几个类似场景，效果都不错。
比如每日健康打卡，很多系统的打卡接口就是一个简单的 POST，把打卡状态提交上去。用同样的方法抓包、构造请求，配合“个人自动化”里的“特定时间”触发，可以做到每天早上自动打卡（当然，前提是打卡内容真实，且学校允许自动化）。
再比如图书馆座位预约，如果预约接口没有强校验，也可以用快捷指令定时提交。不过这类场景往往有并发竞争，成功率不一定高，需要配合重试逻辑。
还有请假申请、访客报备、物品借用登记等，只要是网页表单类的重复提交，思路都是通用的。核心就三步：抓包找接口、验证请求、搬进快捷指令。
我个人在实际操作中的体会是，这套方案最大的价值不在于省下那几十秒，而在于把一件需要记着去做的事，变成了一件不需要记的事。尤其是配合自动化触发后，很多重复操作在你不经意间就完成了，这种体验上的提升是很实在的。
最后再分享一个小技巧：如果你不确定某个接口能不能长期用，可以先做一个“只读”版本的快捷指令，比如只查询当前申请状态而不提交。这样即使接口有变动，也不会造成实际影响，等确认稳定后再做提交版本。这个习惯帮我避免了好几次因为接口变动导致的误提交。
