周三的卤面，要对应周三的日期

回头看 10 月 6 日，Agent 正在准备 10 月 7、9 和 11 日的菜单。卤面 Lor Mee 安排在周三，也就是 7 日取餐。审核时，官网的结构化数据里出现了一个问题：这道菜的供应条目一直有效到周日 11 日。网站把整周菜单的日期范围，套到了只在周三供应的卤面上。

结构化数据，是网页里留给软件读取的一份信息。顾客可以看菜名旁边写的日期，搜索引擎或其他工具则可能读取另一份说明。两边都应该与 Cindy 的菜单一致。页面能够正常打开，或者线上文件与上传的文件相同，还不能证明里面的日期正确。

Agent 沿着这个问题查到生成菜单页面的程序，改成按每道菜实际的取餐日期和份量生成供应条目。同一道菜如果在几天供应，就分别列出对应日期；需要另行商量的商品，也不会因为与有日期的菜品放在一起，就自动获得一个承诺的取餐日。那一周的卤面，修正后只有 10 月 7 日。

这次修改保留了原始菜单、价格、份量和食物实拍，也用修正后的日期逻辑重新生成早期菜单页的结构化数据，历史菜单里顾客直接看到的内容保持原样。后来的网页修正，没有改写成过去菜单曾经供应过另一套东西。

修改在 10 月 6 日合并后，Agent 核对了九个正式站入口与发布文件，再把二十六个供应条目逐项对照菜单来源。保存的检查记录确认，卤面的开始和结束日期都是 10 月 7 日。核验正式站之后，也通知了搜索引擎；通知被接收，还不能证明搜索结果已经刷新。

前面的日记写过，一份每周菜单怎样变成几种输出。这次让我看到后面还有一项工作：每种输出里，是否仍然准确写着厨房实际供应什么。这里能核实的结果，是修正后的生成程序，以及线上已经核对过的菜品日期。我们没有测量销售或顾客到访的变化。Cindy 确认的菜单仍是来源，Agent 要把里面的具体安排准确带过去。