①状态变更必须有明确触发源（如@input/@change事件、watch响应式依赖）；②按钮可用性必须由单一响应式变量控制（不得分散在多个ref或computed中）；③“已保存”提示必须通过独立class或aria-live区域实现，不可仅靠文字颜色变化。const formState = reactive({ name: '', email: '', phone: '' });const isSubmitting = ref(false);const hasUnsavedChanges = computed(() => { return formState.name !== '' || formState.email !== '' || formState.phone !== '';});watch(formState, () => { console.log('form changed');}, { deep: true });const handleSubmit = async () => { isSubmitting.value = true; await api.save(formState); isSubmitting.value = false;};请逐条对照上述三项标准，对以下代码进行校验。每条标准后标注‘符合/不符合’，不符合项须注明具体行号及缺失的实现方式（例如：标准二不符合，第42行button:disabled绑定的是isDirty || isSubmitting，未收敛至单一变量）。标准一：不符合（第10行watch仅执行console.log，未驱动任何UI状态变更；无事件监听或响应式依赖更新按钮启用态，触发源缺失） 标准二：不符合（第7行hasUnsavedChanges为computed，但按钮disabled未绑定它；
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Gemini生成的前端交互说明具备可验证性，但每次输出都停留在“点击后状态变化”这类模糊描述，无法用于开发自测或QA用例编写。
先锁定三项可核查的检查标准
请先列出用于判断本交互说明是否合格的三项检查标准。每项必须满足：①能对应到具体代码行或DOM节点（例如“每个按钮状态变更必须绑定到v-if/v-show指令所在行”）；②能通过人工翻查源码直接确认符合/不符合（例如“所有loading态切换必须调用同一处useLoading()组合函数”）；③任一标准不满足即判定该说明无效（例如某处写“自动更新”，但源码中无watch、无事件监听、无定时器，则此项不合格）。
【禁止跳过标准环节】
输入：用户在表单页修改任意字段→顶部“保存”按钮由禁用变为启用→点击后触发提交→成功后按钮恢复禁用并显示“已保存”。
立即学习“前端免费学习笔记（深入）”；
输出示例：①状态变更必须有明确触发源（如@input/@change事件、watch响应式依赖）；②按钮可用性必须由单一响应式变量控制（不得分散在多个ref或computed中）；③“已保存”提示必须通过独立class或aria-live区域实现，不可仅靠文字颜色变化。
用真实代码片段驱动标准落地
第一步：把实际组件的setup()函数或useForm逻辑块完整粘贴进提示词，紧接在检查标准之后，不加任何过渡句。
第二步：追加指令：“请逐条对照上述三项标准，对以下代码进行校验。每条标准后标注‘符合/不符合’，不符合项须注明具体行号及缺失的实现方式（例如：标准二不符合，第42行button:disabled绑定的是isDirty || isSubmitting，未收敛至单一变量）。”
第三步：若代码中存在watch但未监听所有相关字段，或computed返回值被多处复用却未设缓存标记，【必须指出该行为导致标准一失效】。
使用固定的 Next.js/Tailwind/Prisma 技术栈构建并记录独立 SaaS 项目，仅将 FastAPI 用于 Python 工作负载，并遵循严格的架构规范。
强制输出结构化校验结果
方法一：按标准编号分组输出
标准一：符合（第18行watch监听了formState对象全量）
标准二：不符合（第33行按钮disabled绑定isSubmitting，第47行又单独判断!hasUnsavedChanges，状态源分裂）
标准三：符合（第52行使用包裹提示文案）
方法二：按代码行号锚定问题
第33行：违反标准二，按钮禁用逻辑与第47行重复且不一致
第61行：违反标准三，“已保存”仅通过text-green-500 class呈现，无语义化播报
【所有不符合项必须附带修复建议，格式为“应改为xxx”】
