核心用法
food-cal-order 是一个日历触发的自动化外卖订购 skill，通过浏览器自动化完成 DoorDash、Uber Eats、Grubhub 三大平台的点餐流程。设计为两种工作模式：
直接模式：日历标题格式为 {Service}: {Restaurant}，如 "DoorDash: Chipotle"，系统直接跳转指定平台完成订单。
发现模式：标题为纯条件描述，如 "Thai food, high ratings, under $30, food for 2"，系统并行搜索三大平台，按评分、预算、配送时间、过敏安全等维度智能比价后下单。
日历描述字段承载订单详情与约束条件，包括：餐品内容、份数、过敏信息（关键安全字段）、饮食禁忌、偏好、预算、配送备注等。系统强制解析全部字段，尤其将过敏/饮食禁忌标记为 CRITICAL — never violate。
执行层面采用子代理架构：直接模式单代理完成；发现模式分三阶段——并行侦察（各平台 Top 3 餐厅）、聚合决策、单代理下单。状态持久化至 memory/food-order-state.json，24 小时自动清理。
显著优点
1. 多平台覆盖与智能比价：打破单一平台锁定，自动对比 DoorDash/Uber Eats/Grubhub 的实时选项，优化性价比与配送效率。
2. 深度日历语义解析：不仅识别时间触发，更解析自然语言描述的复杂约束（预算、评分、份数、偏好），降低用户操作成本。
3. 严格的 allergy/dietary 安全机制：将过敏和饮食禁忌设为最高优先级约束，明确指令 "If unsure whether an item is safe, skip it"，并要求子代理在加购前检查配料表、必要时移除冲突食材。
4. 透明的决策可追溯性：侦察阶段要求返回结构化报告（评分、人均价格、过敏原安全等级、适配性判断），决策阶段明示选择理由，订单结果持久化便于审计。
5. 健壮的异常处理：覆盖未登录、餐厅关闭、超预算、菜品不可用、过敏原信息模糊等场景，均定义明确的降级策略而非静默失败。
潜在缺点与局限性
- 浏览器自动化依赖：需预登录 Chrome 保存的账号与支付信息，首次使用存在冷启动门槛；遇到验证码、人机检测或 UI 改版时可能中断。
- 过敏信息依赖平台标注：若餐厅未完整标注配料或交叉污染风险，系统只能标记 "unclear" 并跳过，可能导致可用选项缩减。
- 语义匹配的模糊性："burrito bowl, chicken, guac" 等描述依赖子代理的语义理解与菜单项匹配，存在误选或定制化遗漏风险。
- 无实时价格锁定：侦察到下单存在时间窗口，价格与配送时间可能变动，尤其在高峰时段。
- 状态文件无加密：
food-order-state.json明文存储订单历史与地址信息，存在本地隐私泄露风险。
适合人群
- 日程密集、希望"日历到餐桌"零操作的白领用户
- 有稳定饮食偏好或固定餐厅习惯的重复性订餐场景
- 对过敏/饮食禁忌有严格要求的用户（如坚果过敏、素食、清真饮食）
- 愿意预先配置浏览器账号与默认地址的技术接受型用户
常规风险
| 风险类别 | 说明 |
|---------|------|
| 账号安全 | 依赖 Chrome 保存的登录态与支付信息，建议开启设备锁与支付二次验证 |
| 食品安全 | 平台标注遗漏或餐厅操作失误可能导致过敏原暴露，系统已设多重校验但无法完全消除 |
| 隐私泄露 | 订单历史、地址以明文 JSON 存储，多用户设备需注意隔离 |
| 订单错误 | 自动化流程可能因页面异常、网络延迟导致未成功下单或重复下单，建议首次使用后人工复核 |
| 预算超支 | 配送费、小费、动态定价可能导致最终金额超出预算描述，建议预留 25% 缓冲 |
该 skill 将外卖订购从主动操作转为被动触发，适合嵌入智能日程工作流，但需在安全性与便利性之间保持警觉，特别是对过敏原的处理需用户二次确认。