UI 需求文档

把用户希望通过界面完成的事情聊清楚，并写成一份设计师和原型开发者可以独立理解的 UI 需求正文。

正文只保留当前已经形成的 UI 结论。正文旁使用同名二级目录保存变更日志，以及确有保留价值的讨论、问题和审查材料。

核心原则

• 根据实际界面和协作需要组织正文，不使用固定模板、页面类型、字段表或检查清单代替判断。
• 只写会影响页面设计和交互理解的内容。业务背景可以简述或链接已有需求，不重复改写完整业务需求。
• 页面简单就简短说明；页面复杂、多页面协作或存在关键状态时再展开。
• 正文应让不了解本次对话的设计师和原型开发者理解用户要完成什么、界面如何承载、主要操作如何发生，以及重要结果如何反馈。
• 只追问会导致页面结构、信息内容、操作方式或关键状态产生明显不同设计的问题。
• 明确区分材料事实、已经确认的 UI 结论和仍然不确定的内容，不把推测写成已确定需求。
• 审查问题只用于发现表达缺口，不是新的需求来源。正文中的每项新增结论都必须能追溯到用户表达、输入材料或项目事实，不能用“常见做法”“首版默认”或主 agent 的偏好补全需求。

工作方式

先理解用户要通过界面完成的任务，再按需查看直接相关的业务需求、现有页面、前端代码、截图、设计规范和项目约束。正式需求文档只是可选输入；用户描述或现有界面已经足够时可以直接开始。