Food Order

核心用法

food-order 是一款命令行驱动的 Foodora 订餐自动化工具，通过 ordercli 实现三大核心能力：历史订单复购、订单状态追踪、以及多账户配置管理。

复购流程：用户先通过 ordercli foodora history 查看近期订单，使用 reorder <orderCode> 进行预览（仅展示购物车内容，不扣款），经用户明确口头确认（"yes"/"confirm"/"place the order"）后，方可追加 --confirm 参数完成下单。多地址场景需用户指定 --address-id。

实时追踪：ordercli foodora orders --watch 提供持续刷新的 ETA 与配送状态，适合等待外卖时的监控需求。

登录方案：支持密码直输（--password-stdin）或推荐更安全的浏览器 Cookie 复用（--url + --profile），后者避免凭证硬编码。

显著优点

• 操作原子化：预览与确认分离，降低误操作风险
• 无头自动化：适合定时脚本或快捷指令集成
• 多国家/多账户：通过 --config 切换配置，支持跨国使用

潜在缺点与局限性

• CLI 门槛：需 Go 环境及命令行基础，非技术用户友好度低
• 地区锁定：依赖 Foodora 覆盖范围（欧洲、亚太部分城市），北美用户无法使用
• 确认语义依赖：规则要求用户说出特定确认词，识别容错性未明
• 支付隐蔽性：最终扣款发生在 Foodora 服务端，CLI 仅提交请求，失败场景（余额不足、餐厅歇业）需二次排查

适合人群

• 高频复购固定餐品的技术用户
• 需批量管理多个 Foodora 账户的运维场景
• 追求「语音/快捷指令→自动下单」效率的进阶玩家

常规风险

• 资金安全：确认词误触发或语义识别错误可能导致非预期下单；建议搭配 --config /tmp/... 沙盒测试
• 隐私泄露：浏览器 Cookie 复用方案若配置不当，可能暴露会话凭证
• 服务依赖：Foodora API 变更可能导致 CLI 失效，维护者为个人开发者（steipete），长期支持存疑
• 地址误选：多地址场景若用户误判 --address-id，餐品可能送至错误地点且无法撤回

核心用法

food-order 是一款基于 ordercli 命令行工具的 Foodora 订餐管理 Skill，主打「预览先行、确认后置」的安全交互模式。用户可通过自然语言触发「订餐」「复购」「查进度」等意图，系统先调用 ordercli foodora reorder <orderCode> 展示订单预览，仅在获得用户明确确认（yes/confirm/place the order）后才附加 --confirm 参数执行真正下单。

显著优点

1. 安全设计领先：硬性规则禁止未经确认的 --confirm 操作，配合「预览→询问→执行」三段式流程，杜绝误触扣款风险。
2. 多因素认证支持：支持密码登录与 Chrome 会话导入两种鉴权方式，后者可避免明文密码交互，提升凭证安全。
3. 实时追踪能力：--watch 模式可持续监听订单状态变更，ETA 动态刷新，媲美官方 App 体验。
4. 可移植与可审计：纯 Markdown 文档型 Skill（T-MD），无动态代码执行，依赖外部可信 CLI 工具，行为完全可预期。
5. 开发者可信：维护者 steipete 为知名开源贡献者，GitHub 账号成熟，无恶意行为记录。

潜在缺点与局限性

• 地域受限：需手动配置 --country（如 AT），且 Foodora 服务覆盖区域决定可用性，非全球通用。
• CLI 门槛：要求本地安装 Go 工具链并编译 ordercli，对非技术用户不够友好。
• 地址管理盲区：多地址场景需用户手动指定 --address-id，Skill 无法自动推断最优配送地址。
• 零容错支付：一旦确认下单即扣款，无内置「取消订单」命令，需跳转 Foodora 官方渠道处理。

适合人群

• 命令行重度用户与自动化工作流爱好者
• 需要频繁复购相同餐品、追求效率的上班族
• 对隐私敏感、不愿在浏览器留存登录态的技术人群
• 熟悉 Go 生态、能自主排查 CLI 依赖问题的开发者

常规风险

• 会话过期：Chrome 导入的 session 可能因 Foodora 服务端策略失效，需定期重新授权。
• 配置漂移：使用 /tmp/ordercli.json 等临时配置调试时，若忘记 --config 参数可能导致生产环境误操作。
• 网络依赖：ordercli.sh 与 foodora.at 均依赖 TLS 加密，但本地网络异常或 DNS 劫持仍可能导致连接失败或中间人风险（虽证书校验可缓解）。