AI小工具断网后,还能做什么

你让AI做了一个活动登记工具：提交报名后，保存记录，再发送通知。演示时一切正常，可如果通知服务暂时不可用，页面应该显示什么？

“提交失败，请重试”可能让用户再报一次；“全部成功”又可能让负责人以为通知已经送达。问题不只是网络，而是需求没有说清每一步失败后怎么办。

先把外部依赖列出来

课程关于需求设计的方法，要求提前说明外部接口、责任方和运行环境，并记录故障时的提示或降级需求。它不是某一套软件的专属技巧，而是开工前就要说明的工作规则。

先列出工具实际依赖哪些服务：数据保存在哪里，通知靠什么发送，是否需要登录，是否必须联网。只写真实需要的项目，别为了显得完整加入支付、短信等额外功能。

下面使用自拟报名工具讲解，不表示已经开发或测试过这一程序。这里假设保存报名和发送通知是可以分别记录结果的两个环节；实际能否分开，要由实现方案确认。

给每项依赖写一条失败规则

把一项依赖写成四个问题：什么情况下不可用，哪些动作受影响，现有数据停在哪里，用户和负责人看到什么提示。

以通知服务中断为例，如果报名记录确已保存，可约定显示“报名已保存，通知待处理”，并让负责人看到待处理记录。如果保存结果也无法确认，就应显示待确认，先查询实际记录，不能直接当成保存成功。

再说明中断时仍允许做什么。查看已有记录能否继续，取决于数据是否仍可访问；离线保存能否使用，取决于是否专门设计并验证了本地存储。不能因为这是一个网页，就默认它能离线运行。

把成功、失败和待确认分别写清楚。页面提示要对应实际状态，而不是仅看最后一个按钮有没有报错。

自动重试也要单独约定：重试对象是哪一步，最多尝试到什么程度，怎样避免重复记录或重复通知。没有确认实现方式前，先保留人工处理路径。

沿着中断和恢复走一遍

在隔离的测试环境里，准备没有真实个人资料的样本。先确认正常流程，再按方案允许的方法模拟某项外部服务不可用；不要直接切断正式业务服务。

检查用户看到的提示、实际保存的记录和负责人看到的状态，三者是否一致。若无法查看某一处，就标为未验证。

接着检查恢复后如何继续。已经保存的报名，应先定位原记录，再决定是否补发通知；不应为了补发又新建一条报名。补发能否去重，需要实际实现和验证。

至少留下四条测试题：正常提交；保存成功而通知失败；保存结果未知；服务恢复后的再次处理。每条都写清输入、预期状态和实际证据。

这不是完整的系统可靠性测试。它先检查最容易被一句“失败请重试”混过去的状态差别；复杂工具还需结合自身依赖补充场景。

开发前，先发这段需求

请列出本工具实际依赖的外部服务。逐项说明不可用时受影响的功能、数据状态、用户提示和人工处理路径。保存与通知结果要分开记录；无法确认保存结果时保留待确认。重试和恢复规则先写进需求，再说明实现与测试方法。

看完AI给出的方案，由业务负责人确认哪些动作可以暂停，哪些必须保留人工入口，再进入开发。某个建议若超出第一版范围，就记录为后续需求，不顺手扩大项目。

交付时，还要留下维护说明：谁查看异常记录、谁处理补发、哪些依赖故障需要联系管理员。这些人选不能由AI猜测。

一个小工具是否可靠，不只看网络正常时能否跑通。把中断时的状态和恢复后的动作讲清楚，下一位使用者才知道该等、该查，还是该找人处理。

课程完整介绍与学习入口，请点击文末“阅读原文”。