一条任务状态应该回答三个问题

一个桌面工具在提交文件后显示“处理中”，几分钟后又显示“失败”。用户最想知道的往往不是错误编号，而是：文件到底交出去没有？还要继续等吗？再点一次会不会做出两份？

这篇笔记给需要设计任务列表的人一个小方法：把状态写成能够回答问题的句子。下面都是设计示例，不是对某款软件已有功能的承诺。

第一问：事情走到了哪里

“未开始”“已发送”“已完成”看起来清楚，却容易把不同事实混在一起。准备好本地文件，不等于远端收到了它；远端接受请求，也不等于最终页面已经能打开。

可以先列出实际能观察到的事实，再决定标签：

这张表不要求所有产品采用同一套术语。它提醒的是：标签应当与证据对应。进度条走到末尾，是界面动画完成；它不能替代服务端回执。

状态只有一个形容词，用户仍然需要猜。把下一步放在同一行会更实用。

例如：“平台已接收，正在检查公开页面。暂时无需操作。”这句话同时交代了已经完成的步骤、正在进行的步骤和用户是否需要参与。

如果必须验证身份，就写清楚具体动作：“账号资料已保存，请完成邮箱验证。验证后从当前步骤继续。”避免只显示“账号异常”，也避免让用户误以为必须重新注册。

如果程序不再自动尝试，应当直接说明：“自动核验次数已用完，稿件与回执已保留。可在任务详情中重新检查原页面。”这里的“重新检查”只读取既有结果，与“重新发布”不是同一个动作，按钮名称也应该区分。

网络断开时，客户端可能不知道请求是否抵达了平台。把这种情况一律写成“失败”，容易诱使用户再次提交。

更诚实的提示是：“连接中断，尚不能确认平台是否已接收。已保留本次记录，先核对原提交结果。”如果没有安全的核对途径，也应保留这种不确定性，而不是把猜测改写成成功或失败。

同样，页面可以打开，不代表搜索引擎已经收录；今天正常，也不能证明未来一直有效。任务详情可以分别记录最近检查时间、访问结果和内容是否匹配，让不同结论各自有依据。

给同事看任务列表前，可以拿三种情形试读：第一次使用的人、隔了一天才回来的人、操作中途断网的人。让他们只看这一行文字，回答：

如果答案依赖开发者在旁边解释，就把缺少的那句话补到界面里。错误堆栈和详细日志仍可放在详情中，列表先负责让人做对下一步。

写作背景：这份笔记来自整理自动发布工具任务流程时遇到的界面问题。相关项目是外链助手的公开代码仓库，本文由该项目的开发协作助手整理；上述建议可独立使用，不表示文中每项设计都已在该项目实现。