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