上传已经100%，为什么提交时还没有附件？

先问清楚，哪里才算完成

一开始可能觉得加个进度条就能解释等待。但如果看到100%的人提交后发现没有文件，问题就在于他认定完成的时点。需要先检查选择文件、发送字节、服务器确认接收和检查通过，是不是都用了同一个“完成”。

本例要求工作坊提案上传一个不超过10MB的PDF，不收空文件或加密文件。这里10MB明确为10,000,000字节，其他提案信息仍留在表单中。这些是独立设置的示例条件。真实服务还要先说明为什么必须上传PDF：审核者是否需要保留原文档形式，是否重复要求了已经填写的内容。把必要性写进需求文档，而不只写上传按钮。

同一个文件，对照界面与服务器结果

只记录“偶尔附件失败”，接手的人还得从头问。把选择时刻、100%出现时刻、接收确认和检查结果放在同一条时间线上。使用新建测试文件，把界面文件名与服务器给附件的标识对应起来，才能区分名字相同但内容不同的两份文档。

GOV.UK用于确认上传必要性和具体错误提示，OWASP则支持服务器内容及权限检查，不能只相信扩展名或浏览器给出的类型。由此修改最初方案：完成文字应当跟随服务器确认当前文件可用，而不是跟随进度条到终点。这里改变的不只是一句话，还包括提交按钮和验收条件。

确定完成标准，再决定文案与按钮

一选择文件就显示名称没有问题，但不能让这个列表看起来全是已完成附件。第一个方案是在100%时开放提交，看起来快，却可能还没有确认接收或检查。第二个方案把传输与检查分开，等服务器确认后才允许提交。本例选择第二个。

也可以直到最后才显示文件，但失败后就更难知道要替换哪一份。因此保留早期文件名并标注状态。若服务器尚不支持检查，不要先上线一个假装已经检查完成的界面；应当和开发确认真实能力，缩小本次范围。需求文档保留选择原因，设计说明明确哪些响应条件才算完成。

正在检查，与不知道结果，是两回事

100%时若不知道服务器是否收到，就显示“正在确认传输”。已确认收到但检查未完成，则是“正在检查文件”。两者都不能提交，但应查的地方不同。文件太大需要减小或更换；检查服务没有响应，不能直接说文件本身有问题。

完成响应也必须属于当前选择和上传尝试。服务器附件标识、提案关联和检查通过都确认后，才显示附件完成。同一尝试中迟到的旧检查中响应，也不能把较新的完成状态回退，因此还要比较服务器状态版本。这样，设计条件能够对应到开发需要保证的数据，以及QA可以调换的响应顺序。

已经移除的文件，不能被迟到响应加回来

检查时移除文件，之后成功响应回来又把它放进列表，就等于撤销了用户的操作。应让删除和替换使旧选择失效。仅取消文件选择窗口时保留原状态；真正选了新文件才排除旧附件。新文件不合格，也不能偷偷恢复旧文件。

同名文件可能内容已变，因此新选择需要新版本和新尝试，服务器也要排除旧选择。中止传输请求并不证明已接收的服务器字节已经删除。界面移除、传输中止和临时文件清理应分别记录。临时文件寿命需要按实际运营规则另行确认，只能在有证据的范围内说明删除完成。

重传和提交，也用同样的判断标准

连接断开不等于服务器没有收到。先查原上传尝试，仍在处理就不创建新传输。确认失败或未收到后，才考虑重传；同一内容和同一尝试如何避免重复，要让开发确认。如果没有这项约定，就提供结果查询和明确的新文件选择，不自动重传。

提交服务器也不能只相信界面上的“附件完成”。需要在受理时一致地复查当前归属、提案关联、选择版本和检查通过。受理中不允许改附件，响应丢失时查同一个受理标识。受理后的附件与编辑中的选择分开，本例不提供受理后替换；如有需求，应另行设计修改流程。

让AI检查交错顺序，而不只是成功页面

只说“写个文件上传设计”，可能得到按钮和错误文案，却漏掉核心问题：响应顺序变了，提交的还是正确文件吗？先提供虚构条件、完成标准和删除、替换规则，再要求列出起始状态和迟到响应，才容易逐项检查遗漏。

如果回答允许100%后提交，就不能整段直接采用。要求分开接收未知与等待检查，再补上删除后成功的顺序。只按文件名关联的建议，也要改成选择版本与服务器附件标识。实际服务器是否支持仍交给开发确认，修正后的条件同时进入文案和QA。这里的指令是可复用示例，不是已经执行过的AI交流。

示例提问，并非已执行的AI对话：
请检查虚构工作坊提案的必填PDF附件。只收一个PDF，允许1到10,000,000字节，拒绝空文件和加密文件，还要通过服务器内容检查。
传输100%不等于附件完成。服务器接收未知时显示正在确认传输；确认接收但检查未结束时显示正在检查文件。完成需要当前选择与上传尝试匹配、服务器附件标识、提案关联及检查通过。
实际选择新文件会排除旧附件；仅取消文件选择窗口则保持原样。删除或替换后的旧响应不能生效。同名不代表同一内容。
结果未知不能视为确定失败，先查询原上传尝试。重传同一内容和尝试前，确认服务器的去重规则。提交时再次检查归属、提案关联、当前版本和检查结果。
按起始状态、操作、迟到响应、界面文案、能否提交列出顺序。未定义的服务器能力写成待确认。
修改指示示例：如果100%就允许提交，请改正。补上检查时删除、同名替换后旧成功返回的顺序。保留其他提案输入，并在QA中写出实际提交哪个附件。

QA不能只上传一次小文件

检查大小边界、空文件、迟到响应和同名替换。对照预期附件标识与实际受理的标识，才能发现名字正确却提交了旧内容的问题。延迟、断线和旧响应应在可控测试环境重现并留下真实结果，不能只看正常网络下的截图。

参考W3C状态消息说明，用文字表达传输、检查和完成，不无故移动焦点。还要确认键盘选文件及错误后的返回路径。下表是预期结果；文章资料可操作，不等于真实受理服务器、文件检查和辅助技术已经通过集成验收，两者应分别记录。

需求文档留原因，设计说明留变化条件

需求文档记录为什么要PDF、要解决的问题，以及选择服务器确认为完成标准的理由。设计说明再展开状态、文案、操作和例外。不只列页面编号，而要写清“检查中删除后，迟到响应不恢复附件”，接手的人才能沿着已经确定的判断继续。

开发确认检查、权限、去重、并发和临时文件寿命；QA对照界面顺序与实际附件；运营需要可追溯状态，不能把未知结果说成失败。发布后分别看拒绝原因、结果未知时离开、附件关联错误等情况，不把文件内容写入统计事件。数量降低本身不能证明改善，先核对附件缺失是否真正解决。

必填PDF附件交接说明——虚构工作坊提案
目的：只有当前选中且服务器检查通过的文件进入提交。选择、传输、检查和提案受理分开处理。
输入：一个PDF，允许1～10,000,000字节，含上下限。界面显示不超过10MB，此处10MB为10,000,000字节。空文件、加密文件和检查未通过的文件不能完成。浏览器限制是提示，服务器仍须验证。
选择：取消选择窗口保留原附件。实际选择新文件则排除原附件并更新选择版本。新文件不合格也不自动恢复旧文件，其他表单输入保持。
状态：未选择→传输中→确认接收→文件检查中→当前附件可用。100%时接收未知显示正在确认传输；确认接收但检查待定显示正在检查文件，两者均不能提交。
完成：当前选择和上传尝试一致，服务器附件标识、提案关联、检查通过均已确认。比较服务器状态版本，防止旧的检查中响应把完成状态回退。
拒绝：类型、大小、空文件、加密、检查未通过分别提供修改方法。检查服务故障不代表文件有缺陷；保持未批准并提供状态查询或恢复路径。
删除/替换：立即使旧响应和本地可用状态失效，服务器也废弃或排除原选择。迟到成功不能恢复已删除附件。界面移除、中止传输、服务器临时文件删除是不同结果。
同名：替换也是新版本和新尝试，通过服务器附件标识关联，不仅按文件名覆盖。
未知：先查原尝试；正在处理时不重传。确认失败或未收到后，只有开发确认同一内容、同一尝试的去重及状态规则才提供重传。更换文件属于新尝试。没有该能力时提供状态查询和明确重新选择，不自动重传。
提交：必填附件未准备好时解释原因并阻止提交。服务器在受理时一致地复查归属、提案关联、选择版本和检查通过。受理中不能改附件；结果未知时查同一提案受理标识，不能重复申请。
受理后：已受理附件独立于编辑中的选择。本例不提供受理后替换。临时过期、正式保留和删除时点需要按实际服务另行确认。
无障碍：保留原生文件输入和键盘操作。进度与状态用文字提示，不无故移动焦点。错误后的说明和文件输入仍可访问。
文档/职责：需求文档保留附件必要性、完成标准和方案选择；设计说明保留状态、文案、版本、请求/响应和例外。开发确认内容检查、权限、并发、去重和临时文件寿命；QA核对操作顺序与实际附件标识；运营需要可追溯状态及处理说明。
验收：执行大小边界、100%、拒绝、检查故障、同名替换、删除后迟到成功、旧状态响应、结果未知、权限变化、受理中修改及重复操作。记录环境、版本、负责人、预期/实际和证据。本文不是实际服务器已通过集成验收的记录。

来源与示例条件

根据2026年9月30日核实的GOV.UK、OWASP、W3C公开文档制作的独立虚构案例。一个PDF、10MB、完成与替换规则均为本例设计选择。由WekeyLab AI编写，不使用公司资料，不虚构个人经历或成果。AI提问为未执行示例，英文及中文均是同一韩语案例的本地化。文章资料界面检查与真实接收系统集成验收分开。

GOV.UK Design System — File upload

OWASP — File Upload Cheat Sheet

W3C — Understanding WCAG 2.2, Status Messages