没有运行记录，先查预期事件有没有发生、工作流是否使用了匹配的触发器；有运行记录但没有动作，再看条件路径和每个步骤的数据；显示失败或持续运行，重点检查错误步骤、外部连接器和数据查询范围。不要仅凭工作流的启用状态判断任务已处理。

Shopify Flow 的运行详情可以显示状态、执行路径、步骤结果和步骤数据。你可以在 Shopify Flow 运行记录与监控说明 中核对界面字段。运行记录完成后只保留 14 天，过期后无法再从系统中查看；发现异常时先保存必要证据，别等到排查时才找记录。

没有运行记录时：核对事件、触发器和版本

进入 Flow 的工作流详情，先确认检查的是正确工作流，再按预计发生时间查 Recent runs。可用订单、商品或客户标识缩小范围，并核对记录显示的触发类型；搜索不到时，不要立刻把原因归到浏览器或网络环境。

触发器对应的是特定事件，不是“订单有变化”这种笼统概念。例如，订单创建和订单交易创建代表不同事件。对照 Shopify Flow 触发器说明，确认业务动作确实符合当前触发器定义。若近期有人编辑过工作流，再查看版本历史中的修改人与时间，判断问题是否从某次变更后出现；工作流版本历史说明介绍了如何检查和比较版本。

注意：Flow 测试运行不会出现在常规 Recent runs 列表里。因此，“测试过，但常规记录里找不到”不一定表示测试没运行。测试功能可用于检查路径和变量，但测试模式不会执行会修改店铺数据的动作；参照测试工作流的限制与操作说明。

“Completed”说明该次运行结束，不代表你希望的条件成立。打开运行详情的流程预览，找出实际走过的分支；再展开条件步骤，核对当次数据与比较值。Shopify 的条件说明列出了比较方式和动态值的使用方式。

例如，你期待订单达到某个金额时添加标签，但运行记录中的金额字段不符合条件，流程可能正常完成，却走了“不满足”分支。检查金额字段取值、币种与比较方式；多个判断组合时，也要确认逻辑是 AND 还是 OR，而不是只凭编辑器中的条件文字推断结果。

建议挑选一条可核对的测试事件，逐项比较“预期字段值”和运行详情中的实际值。截图可保留工作流路径、条件结果和步骤数据，但分享前应遮挡顾客姓名、邮箱、地址、订单信息及凭据。需要核对条件和字段时，可先看Shopify Flow 条件设置说明，不要把顾客数据直接贴到公开讨论区。

出现 Shopify Flow 工作流失败时，打开该次运行详情，找到首个失败步骤及完整错误文本。先判断它属于输入或配置问题，还是暂时无法完成的任务；再按下面顺序排查：

1. 检查动作依赖的数据。 例如，添加客户标签的动作需要可用的客户对象。若错误提示资源缺失，检查触发器是否提供了所需对象；查询结果是列表、动作却要求单个对象时，确认是否需要逐项处理。
2. 检查连接器或外部请求。 若失败集中在连接器或 HTTP 请求，确认连接状态、请求参数及错误响应。单次 5XX 只说明该次请求失败，不能单凭它断定平台整体故障；按 Shopify Flow 错误排查说明 区分暂时性错误与不可重试的永久性错误。
3. 检查数据查询和循环。 若显示超时、限流或运行缓慢，检查 Get data 查询是否过宽、条件是否遍历了过多数据，以及列表循环是否无意中处理大范围对象。官方的 工作流优化建议建议给数据查询添加筛选条件，并确认查询确实返回预期数据。
4. 控制仍在运行的影响。 若反复出现同一错误，先检查是否有重复运行、重复通知或重复写入标签等下游影响。运行详情标记为 Rate limited 时，不要持续批量手动触发；先缩小查询范围或检查循环逻辑，再观察后续运行状态。

暂时性错误可能自动重试；永久性错误则需先修复问题。官方资料说明，Flow 的工作流执行阶段存在 36 小时上限，达到限制仍未完成时运行会失败。这个数字是平台执行边界，不是建议你等待的时长：如果同类错误重复出现，应优先修流程或检查外部依赖。

Shopify Flow 运行记录显示运行一直处于 “In progress” 或重试状态时，先打开运行详情查看当前步骤和重复错误。如果是暂时性错误，且下游没有发生重复动作，可先观察是否继续完成；如果显示限流、查询过重或重复执行可能影响业务，应先收窄查询、检查循环，并评估是否需要取消仍在进行中的运行。

修复后，不要把“重试”当作默认按钮。按这个判断顺序处理：

• 先人工补做：原运行中部分动作已经成功，而重复通知、重复标签或重复的外部请求会造成问题。核对业务对象后，只补缺失动作并记录处理结果。
• 修复后重试：失败原因已排除，且确认重复执行对已完成动作没有不可接受的影响。官方说明，手动重试沿用原触发数据，但 Get data 动作会读取最新数据；重试前还需确认工作流处于启用状态、触发器仍匹配，并且原运行不处于运行或等待状态。操作条件见 Shopify Flow 手动重试说明。
• 重新触发或不重试：原事件数据已不适用、触发器不匹配，或重试会产生无法安全处理的副作用。先检查目标对象当前状态，再决定是否通过人工运行或其他业务步骤补救；不要把补救动作和历史运行重试混为一谈。

每次排查至少记下工作流名称与版本、关联对象标识、运行状态、失败步骤、错误文本、已做修改、处理人和下一步责任人。标注记录的时间与时区，避免不同时区的同事把同一事件当成不同运行；不要在交接文档中保留顾客个人信息、订单完整资料或访问凭据。

场景例子：夜间值班人员发现订单没有自动加标，白班同事不应只收到一句“Flow 好像坏了”。交接应说明：是否找到对应运行记录、哪一个条件分支未命中、是否已经修改条件，以及是否重试过。若需要展示后台画面，截取运行路径和出错步骤即可，先脱敏再共享。

远程 Mac 不是 Flow 执行或修复的必要条件，也不会改变平台的运行结果。若团队需要的是跨时区访问后台和交接的环境，可先了解远程 Mac 租赁方案与使用方式；如果确实需要美国节点，再比较美国东部节点的远程 Mac 方案是否符合访问需求。它们的优势是为团队提供可交接的 macOS 后台访问环境；局限也很明确：工作流配置仍要在 Shopify Flow 中排查，环境本身不能保证自动化成功。

如果你现在用个人电脑轮流登录，常见问题是后台状态难交接、操作记录散落，以及访问环境依赖具体员工设备。按月租用 Mac 也并不适合所有团队：如果只需偶尔登录，继续使用现有设备可能更简单；如果业务需要一台团队可持续访问的 macOS 后台环境，再评估 KVMNODE 是否合适。先用运行记录找出真正的故障点，再决定要不要增加远程操作环境。