很多团队以为日期选择器只是个小控件真正上线后才发现它经常是浏览器 Agent 最隐蔽的误提交入口。⚠️ 页面上明明高亮了5 月 12 日提交到后端的却可能是5 月 13 日界面里看着选中了“下周一上午”最终落库的却是默认时段。图 1日期选择器的风险不在能不能点到而在点到后是不是同一个时间语义问题的根子在于日期控件同时存在视觉层和提交层两套时间语义。 Agent 如果只盯着某个可点击单元格就会把“点中了一个格子”误当成“提交时间已经对齐”。 这种错最容易出现在跨月翻页和预约场景里。日期选择器为什么比普通表单字段更容易失真第一层偏差来自日历网格。️ 很多组件把上个月尾巴和下个月开头一起渲染在同一屏单元格文本都叫1、2、3如果没有把“日期数字”绑定到“当前月份标题”执行器就很容易点到相邻月份。第二层偏差来自时段默认值。⏰ 页面显示的是“已选日期”真正提交还要拼上默认开始时段一步没校验就会把正确日期提交成错误时间。[外链图片转存中…(img-ktctgiRr-1777947346894)]图 2日期数字、月份标题和时段选项必须一起做 Grounding更麻烦的是禁用规则和异步刷新。 不少业务系统会在状态返回后重新禁用部分日期用户看见的高亮态不一定等于最终可提交态。✅ Agent 如果没有在点击后再次读取组件值和隐藏字段就会带着旧选择继续点击“确认”。一组回放把 Calendar Grounding 和 Slot Commit 的收益量化出来这次回放了72条真实任务覆盖会议预约、客服回访、门诊挂号和发版窗口四类场景。 基线方案按可见文本点击日期再直接提交改进方案在点击前绑定month_label day_cell timezone disabled_state点击后再校验组件输出值并把最终预约时段写入slot_commit。方案任务成功率跨月误点率错时段提交率人工接管率文本命中后直接点击68%11%14%18%Calendar Grounding Slot Commit93%2%3%6%这组差距说明日期控件的问题不在识别按钮而在提交前能不能证明“当前高亮日期”和“最终提交时间槽位”是同一个对象。 当系统把月份标题、ISO 日期值和时段字段一起校验后很多错误都能稳定拦截。️defcan_commit_slot(month_label,expected_month,picked_date,expected_date,slot_id,expected_slot):return(month_labelexpected_monthandpicked_dateexpected_dateandslot_idexpected_slot)图 3真正稳定的日期自动化要把视觉选择和提交值做成同一条证据链真正该补的是提交前时间语义闭环很多团队一遇到日期误选就去补更多 XPath 或把点击延迟拉长。⏱️ 这只能提高“控件展开后不报错”的概率不能证明提交的是不是用户要的那个时间。更稳的做法是把calendar grounding视为前置校验把time slot commit视为提交闸门只要月份标题、选中日期和时段值有一项不一致系统就回退到确认而不是继续提交。笔者认为未来3到6个月浏览器 Agent 在业务表单里的真正分水岭不是谁先学会点日期而是谁先把时间语义治理做成默认能力。 日期控件会继续叠加库存刷新、跨时区展示和相对时间文案没有 Calendar Grounding 与 Time Slot Commit所谓“已选成功”往往只是界面错觉。⭐图 4日期选择器要稳定闭环关键是月份、日期、时段与最终提交共用同一时间口径一句话总结日期选择器最难的不是点击哪一天而是让“看到的日期”和“提交的时间”始终保持同义。 你们现在的 Agent能证明页面上高亮的那一天和最终写进后端的预约时段真的是同一个时间对象吗