请审计以下页面或组件的设计 token：{{implementation}} 现有规范：{{design rules}} 输出： | Token 类别 | 当前重复或冲突值 | 规范目标 | 受影响位置 | 最小修复方式 | 只检查：颜色、字体层级、字重、行高、间距、圆角、边框、阴影和动效时长。 要求： 优先复用已有 token，不凭空新增同义 token。 说明哪些值是历史兼容，哪些可以安全收敛。 修复建议不能改变业务结构和文案。 如果无法从代码或规范确认，标记为待确认，不猜测。

请为下面的页面生成一页设计 Brief，不要写代码： 页面目标：{{page goal}} 目标用户：{{audience}} 核心任务：{{primary task}} 已有品牌或设计规范：{{design rules}} 输出： 页面唯一主任务和成功信号。 内容层级：必须突出、辅助说明、可以隐藏。 必须覆盖的 loading、empty、error、success 和 disabled 状态。 桌面端与移动端的布局约束。 不采用的视觉模式及原因。 每条结论都要能指导组件、文案或验收；禁止只写“现代、简洁、高级”。

请审计组件或页面 {{component}} 的交互和可访问性：{{implementation}} 输出： 1. 键盘路径：Tab 顺序、焦点可见性、Enter/Space/Escape 行为。 2. 触控路径：目标尺寸、间距、点击反馈和误触风险。 3. 状态闭环：loading、success、error、empty、disabled 是否都有反馈。 4. 语义要求：可访问名称、label、aria 状态、图片替代文本。 5. 按严重程度排序的修复清单，每项给出复现步骤和验收条件。 禁止：删除焦点环、用 hover 代替键盘反馈、用颜色作为唯一状态信号；不要提出与发现问题无关的视觉改版。

请为页面 {{page}} 定义响应式契约，不要修改视觉风格： 页面结构：{{structure}} 内容类型：{{content types}} 目标断点：{{breakpoints}} 输出一张表： | 区域 | 桌面布局 | 平板布局 | 移动布局 | 内容降级/折叠规则 | 验收方式 | 必须检查： 多列布局在移动端如何变为单列或滚动。 导航、按钮、表格和长文本是否仍可操作。 图片、视频和代码块是否保留比例并预留空间。 390px 宽度下不能产生页面级横向滚动。 禁止：只写“使用响应式 CSS”或把断点交给实现者猜测。

请审计页面 {{page}} 的截图或实现：{{reference}} 项目设计规范：{{design rules}} 只输出按优先级排序的视觉问题： | 优先级 | 位置 | 现象 | 违反的规则 | 具体修复 | 验收证据 | 检查： 信息层级、标题与正文宽度、垂直节奏和对齐。 容器、边框、圆角、阴影、颜色 token 和图标的一致性。 交互态、焦点态、空态、错误态和移动端布局。 是否存在重复 CTA、无意义卡片套卡片或装饰性元素。 禁止：只给审美形容词；每条问题必须指向具体位置和可观察修复。

请把以下产品目标改写成可执行的验收标准： 目标：{{goal}} 用户路径：{{user flow}} 约束：{{constraints}} 对每条标准使用以下格式： 场景：{{given}} 行为：{{when}} 可观察结果：{{then}} 失败或边界：{{boundary}} 要求： 结果必须能通过页面、API、数据或用户操作观察。 不使用“更好看”“更流畅”“体验提升”等不可测表述。 如果目标缺少必要信息，列出待确认项，不自行补齐。

请审计下面的产品方案，不要改写方案，也不要新增功能： 方案：{{proposal}} 已知事实：{{facts}} 已有数据：{{data}} 输出一张表： | 假设 | 证据状态（事实/推断/未知） | 失败影响 | 风险等级 | 最小验证动作 | 规则： 只有材料明确支持的内容才能标为事实。 不能用“行业通常如此”替代证据。 优先列出会阻断用户价值、数据安全或交付验收的风险。 验证动作必须能在一次小实验、访谈或数据检查中完成。

请分析以下用户反馈，只输出问题归并，不设计功能： 反馈： {{feedback}} 产品上下文：{{product context}} 输出： 1. 反馈原文中的事实与用户主观判断。 2. 去重后的问题簇，每簇包含代表性原文、受影响用户和触发场景。 3. 每个问题簇的证据强度：单条反馈、重复出现或有行为数据。 4. 可能的根因与仍需验证的部分。 5. 不应直接采纳的功能化表述。 禁止：因为用户提出了某个功能，就直接把该功能列为解决方案。

请为以下需求建立一份范围裁剪结果，不要写详细交互或技术实现： 需求背景：{{context}} 目标用户：{{audience}} 期望结果：{{desired outcome}} 候选需求：{{candidate requirements}} 输出： 一个最小可验证闭环，说明开始条件、关键行为和完成信号。 本期必须做的需求，逐条说明与闭环的关系。 明确不做清单，逐条说明为什么不进入本期。 仍需验证的假设。 禁止：用“后续再说”替代不做理由；禁止为了完整而保留没有验证价值的功能。

请把下面的产品想法改写成一个可验证的问题命题，不要提出功能方案： 想法：{{idea}} 已知用户或场景：{{known context}} 现有证据：{{evidence}} 输出： 1. 目标用户与具体触发场景。 2. 用户当前采取的行为和遇到的阻碍。 3. 阻碍造成的可观察损失；没有证据的地方标记为“待验证”。 4. 如果问题被解决，用户行为或业务结果会发生什么可观察变化。 5. 三个最小验证问题。 禁止：把功能、技术方案或“提升体验”直接当成问题结论。

你是一名严格的产品经理。请先不要写 PRD 或代码，按以下顺序审查我的想法： 1. 目标用户是谁，当前在什么具体场景遇到什么问题？ 2. 这个问题造成的真实损失是什么，为什么现在值得解决？ 3. 解决后用户行为或结果会发生什么可观察变化？ 4. 哪些需求只是偏好、装饰或未经验证的假设？请直接删掉。 5. 给出一个最小可验证闭环，并列出不做什么。 输出：核心问题、关键假设、最小方案、验收信号、明确砍掉的内容。