列状态清单
逐个组件问一遍会出现哪几种样子，再开始写。
开工前把每个元素会出现的样子列成一张表。这张表既是需求，也是验收清单。
你会遇到的现象：
- 做完了自己点一遍没问题，别人一用就撞到没做的状态
- 不知道该测什么，只能凭感觉点几下
- 让 AI 补状态，它补了两个，还有三个没提也没做
状态遗漏的根源是它们不出现在需求描述里。你说「做一个对账页」，脑子里的画面是有数据、一切正常的那一屏。清单的作用就是逼你把其余那些屏也想一遍。清单不是写给别人看的文档，是你自己检查的工具：它把「我记得有这几种状态」变成「这几种状态都列出来了」——前者靠记忆，后者靠纸面。
怎么列
四列就够：元素、状态、触发条件、显示什么。最后加一列打勾，写完的时候当验收表用。列名跟实现和测试里用的词保持一致，免得对不上。
- **按元素列，不按页面列。**一个页面有列表、按钮、输入框，各自有各自的状态，混在一起会漏。
- **触发条件要写具体。**写「出错时」不够，写「接口 500 或超时」才知道怎么测。
- **显示什么要能直接照着做。**写「显示错误提示」不够，写「显示原因加一个重试按钮」才行。
- **列完先自己扫一遍再动手。**这时候加一个状态是改一行表格，写完再加是改代码。
举一个例子。评论列表这一行：元素是评论列表，状态是空态，触发条件是列表接口返回 200 且数据为空，显示什么是一个占位插画加一句「还没有评论，来发第一条」。这一行写完，实现的人不用再猜，验收的人也有依据。
对每个元素问六句
六句对应六种状态，逐个元素问一遍，缺一个就少一屏的设计：
| 问 | 对应的状态 |
|---|---|
| 没有数据时呢 | 空态。要区分「本来就没有」和「筛选筛没了」 |
| 数据还没回来呢 | 加载态。超过一秒才需要显示 |
| 失败了呢 | 错误态。要有原因和重试 |
| 不能点的时候呢 | 禁用态。还要说清为什么不能点 |
| 正在处理的时候呢 | 处理中。按钮要锁住，防重复提交 |
| 数据特别多或特别长呢 | 截断、折叠、分页。极值下布局不能垮 |
| 校验不过呢（输入类） | 校验态。当场指出并说明规则 |
| 只读时呢（输入类） | 只读态。内容可看不可改，样式要区分 |
第六句最容易被跳过。它不是状态，是边界，但表现出来的效果一样——一个四十字的名字能把整行布局挤变形。后两行是输入类元素专属的，列表和按钮用不上，但表单页面离不开。
六句里最核心的是前四句，对应四态齐全——那一篇讲了每种状态各自该回答什么问题。清单的作用，是把它们从概念变成你这份需求里逐条可勾的行。
给 AI 的话
让 AI 先出清单，你改几行，再让它照着实现。比直接要代码稳得多——因为你改的是表格，不是改代码，错得越早改得越便宜。
PROMPT · 状态清单
页面：[页面名和用途]
主要元素：[列表 / 表单 / 按钮 / 筛选器…]
先不要写代码。请输出一张状态清单，表格四列：
元素 | 状态 | 触发条件 | 显示什么
要求：
1. 逐个元素过一遍这六个问题：没数据、加载中、失败、
禁用、处理中、极值（超长内容 / 超多条数）。
2. 输入类元素额外列出：校验失败、只读。
3. 触发条件写具体，比如「接口返回 500 或超时 10s」，
不要写「出错时」。
4. 显示什么要能直接照着实现，包含文案要点。
5. 最后单独列出你不确定的状态，问我要不要做。
我确认清单之后再写代码。实现完成后，
按这张清单逐条自检，报告哪几条做到了、哪几条有偏差。
这张表列完，它同时就是验收清单：让 AI 逐条自检、你逐条打勾，再交付。比上线之后靠用户撞到没做的状态，成本低一个数量级。清单越具体，AI 能自己抓出的偏差就越多，返工就越少。