Make a State Checklist
Before starting, list the states each element can appear in, as a table. This table is both the spec and the acceptance checklist.
- 做完了自己点一遍没问题，别人一用就撞到没做的状态
- 不知道该测什么，只能凭感觉点几下
- 让 AI 补状态，它补了两个，还有三个没提也没做
The root cause of missing states is that they don't show up in the requirement description. You say "build a reconciliation page," and the picture in your head is the screen with data, all normal. The checklist's job is to force you to think through all those other screens.
How to make it
Four columns is enough: element, state, trigger, what's shown. Add a checkmark column at the end to use as an acceptance sheet when you're done.
- List by element, not by page. A page has lists, buttons, inputs — each with its own states. Mix them together and you'll miss some.
- Write trigger conditions concretely. "When an error occurs" isn't enough; "API returns 500 or times out" tells you how to test it.
- What to display should be directly actionable. "Show an error hint" isn't enough; "show the reason plus a retry button" is.
- Scan the list yourself before building. Adding a state now is one line in a table; adding it after it's built is a code change.
Six questions for each element
| 问 | 对应的状态 |
|---|---|
| 没有数据时呢 | 空态。要区分「本来就没有」和「筛选筛没了」 |
| 数据还没回来呢 | 加载态。超过一秒才需要显示 |
| 失败了呢 | 错误态。要有原因和重试 |
| 不能点的时候呢 | 禁用态。还要说清为什么不能点 |
| 正在处理的时候呢 | 处理中。按钮要锁住，防重复提交 |
| 数据特别多或特别长呢 | 截断、折叠、分页。极值下布局不能垮 |
Input-type elements need two more questions: what shows when validation fails, and what the read-only state looks like.
Note for the AI
Have the AI produce the checklist first, you tweak a few lines, then let it implement against it. Much steadier than asking for code directly.
页面：[页面名和用途] 主要元素：[列表 / 表单 / 按钮 / 筛选器…] 先不要写代码。请输出一张状态清单，表格四列： 元素 | 状态 | 触发条件 | 显示什么 要求： 1. 逐个元素过一遍这六个问题：没数据、加载中、失败、 禁用、处理中、极值（超长内容 / 超多条数）。 2. 输入类元素额外列出：校验失败、只读。 3. 触发条件写具体，比如「接口返回 500 或超时 10s」， 不要写「出错时」。 4. 显示什么要能直接照着实现，包含文案要点。 5. 最后单独列出你不确定的状态，问我要不要做。 我确认清单之后再写代码。实现完成后， 按这张清单逐条自检，报告哪几条做到了、哪几条有偏差。