需求表单填写到一半关闭了，哪些内容应该恢复，不能只用“自动保存”四个字决定。需求表单草稿恢复需要明确保存对象、位置、有效范围，以及再次打开时如何让用户确认。文本、已选择文件和已经提交的记录，也要分别处理。
企业可以先围绕填写任务列出中断场景，再选择保存方式。目标是减少重复填写，同时避免在共享设备上恢复不属于当前用户的资料，或让一份草稿看起来像已经提交的需求。
先确定用户要从哪一种中断继续
刷新页面、切换服务、关闭标签和换一台设备，是不同情境。只测试刷新后文字还在，不能承诺关闭浏览器或跨设备都能恢复。需求应逐项写清支持哪些路径。
假设负责人填写官网改版需求，中途需要查找产品资料，暂时离开当前页面。返回后恢复项目描述很有帮助；若他使用公共电脑，离开后下一位使用者不应直接看到这份资料。这是假设情境，说明便利与恢复范围需要一起确定。
可以先记录填写耗时、是否需要准备材料、是否通常在同一设备完成，以及有没有登录身份。较短的联系表单可能只需在一次操作中保留输入，长需求收集则可以评估更明确的草稿能力。
“恢复到哪里”也要说明。返回表单开头但保留全部答案，与回到上次步骤并提示未完成字段不同。页面位置和内容恢复各自核对，不能只因为输入值存在就认定恢复体验完整。相关操作可参阅《多步骤表单怎么设计？Step 不是越清楚越好，先判断用户到底需不需要“步骤条”》。
完成标志是团队能列出支持和不支持的中断路径，页面说明与实际行为一致，不向用户承诺系统没有实现的恢复范围。
草稿保存在设备还是后台，决定怎样再次找到它
在当前浏览器保留草稿，可以降低恢复操作，但不等于后台已经收到需求。用户换设备、清理浏览数据或使用不同浏览方式，能否继续要按实际实现确认。
如果只保存在当前页面会话，刷新与关闭标签后的表现可能不同。例如采用浏览器会话存储时，其范围与标签会话有关，不能把它宣传成长期跨设备保存。具体选择由实施方结合需求决定。
后台草稿则需要确认身份、查看权限和取回方式。没有登录的表单，可以评估恢复链接等方案，但链接是否能被转发、如何限制访问、什么时候失效，都需要进一步设计，不能只提供一个地址就结束。相关操作可参阅《B端复杂表单怎么设计？分组、联动、保存与校验方法》。
保存时间根据实际填写与数据处理需要决定。不要为了方便统一写成永久保留，也不随意复制别站期限。团队应说明何时清理、用户如何主动清除，页面只展示真实规则。
保存动作本身失败时，也需要给出真实反馈。正在输入的页面内容可能还在，却没有写入预定位置；用户离开后再回来，恢复结果就不同。可以提示哪些输入尚未保留，并让用户按约定继续等待、重试或复制自己的内容，不能一直显示上一次的已保存状态。
保存状态应能被理解：哪些答案已经保留、何时保留、是否仅在本设备。用户知道范围后，才会合理安排准备资料，而不会因为看到“已保存”就以为可以放心换电脑继续。
文本答案与附件，需要分别说明状态
文本草稿可以保留项目描述、已选择服务和其他允许保留的输入。附件则要区分本地选择、临时上传和已经关联到后台草稿，不能仅凭文件名仍显示，就说明文件本身保存完整。
普通文件选择控件不能由页面脚本任意填回用户的本地路径。因此，如果系统只保存文本，刷新后附件可能需要重新选择。这个限制应在恢复时明确提示，避免用户直接提交后发现资料缺失。
如果文件已经上传至临时位置，应说明是否能恢复、保留范围和后续关联方式。临时上传成功也不代表最终需求提交完成。文件与草稿对应关系需要后台确认，不能让另一份需求误引用同一附件。
恢复后的页面可以显示哪些文本已找回、哪些文件仍需选择，用户完成附件步骤后再进入核对。必要资料缺失时按规则提示，不把输入恢复成功写成全部资料已经就绪。
不需要保存的敏感内容应单独定义，避免“恢复全部字段”把本来只应在当前操作中使用的信息一起留下。具体范围按业务与网站规则确认，不由默认模板决定。
切换服务后，旧草稿只能按当前范围恢复
多服务需求表单中，共用资料与服务专属答案的处理不同。联系人与公司介绍可能共用，网站栏目、UI 页面或品牌应用等专属问题，则应关联对应服务，不能全部拼到一次提交里。
如果用户先填写网站需求，再改为品牌需求，可以保留旧网站草稿便于返回，但提交时应只包含当前服务的有效答案。隐藏与删除不同，保留与提交也不同，需求里要分别写清。
恢复时还需使用当前问题结构。如果表单更新了选项或字段规则，旧草稿中的值可能不再适用。页面应提示重新确认相关内容，不能把旧答案悄悄塞入已经变化的问题。
假设草稿里选择了过去存在的服务项，后来该项调整，系统可以保留用户原来的表达供核对，再让其选择当前范围。直接映射到看起来相近的新选项，可能改变需求含义，应避免无依据替用户决定。
核对摘要应忠实显示当前有效答案与尚未确定的项目。恢复后一次完整的检查，比立即提交更能帮助用户发现原来填写时的遗漏和后来发生的变化。
恢复、重新开始与提交完成，要有不同反馈
再次进入页面时，可以提示发现未完成草稿，并允许继续或重新开始。不要默认加载后就让用户以为这是当前已经确认的答案，尤其在共享设备或多人轮流填写的情形。
主动清除草稿应说明会影响哪些内容，避免只清空页面，却留下下次仍会恢复的值。反过来，也不要在返回上一步时自动清除所有输入，让用户误把导航当作重新开始。
最终提交成功后，草稿如何处理要明确。可以按规则清除，或保留与回执对应的记录，但下一次打开不应无提示地把上一次已完成需求作为新稿。用户需要知道自己正在发起新任务，还是查看旧任务。
提交结果未知时，也不宜直接清除草稿。保留输入方便核对，但同时标明是否已经提交尚待确认，避免重新恢复后再次生成相同记录。草稿恢复与防重复提交需要一起设计。
文案应使用用户理解的范围，不必把内部存储术语直接放到页面。例如“已保留本设备上的文字输入，附件需重新选择”，比一个没有边界的绿色“全部已保存”更准确。
用实际恢复路径检查内容与边界
验收时先填写不同类型的答案并选择附件，分别测试刷新、切换服务、返回步骤、关闭标签和再次进入。记录每条路径恢复了什么，没有恢复什么，页面提示是否准确。
再检查清除草稿、提交成功后返回、表单问题更新后的旧草稿，以及共享设备换人填写。需要登录的系统还要核对不同账号不能误取彼此内容。测试范围跟着实际方案走，不用一个刷新截图代表所有场景。
检查附件时查看实际文件状态与最终记录，不只看名称列表。恢复文本之后，提交的服务范围、核对摘要和后台记录应一致，隐藏旧答案不应混进来。
测试数据应明确标识，完成后按网站规则处理。故障情境在受控环境验证，记录中不包含对外公开的私有资料。发现未实现路径时，就修正能力或说明，而不是继续使用过宽的承诺。
需求表单草稿恢复的成功标志，是用户知道找回了什么、还要补什么，以及怎样继续或清除。保存得更多未必更合适，保存范围与实际填写任务一致，才容易长期维护。
常见问题
文字刷新后还在，说明后台已经收到需求了吗？
不一定。文字可能只保存在当前设备。提交记录和草稿状态需要分别核对，页面应说明保存位置与范围。
关闭标签后，草稿一定还能恢复吗？
取决于实现和会话范围，不能仅凭刷新测试判断。需求里明确这条路径是否支持，再用实际环境验证。
草稿恢复能把附件也一起找回来吗？
只有系统实际上传并保留相应文件时才可能按规则恢复。仅记录文件名或本地选择，不代表文件已经保留，应明确重新选择提示。
共享电脑上应该默认恢复上一份草稿吗？
应先评估资料范围与身份识别，提供清楚的恢复和重新开始选择。不能把别人的输入无提示地当成当前用户答案。
提交成功后还保留草稿，会不会重复提交？
可能造成误解，需要定义成功后的清除或查看方式，并区分新任务与已有回执。不能只保留输入却让状态回到尚未提交。
链接复制成功
