food-order

核心用法

food-order 是一款面向 Foodora 外卖平台的命令行自动化技能，通过封装 ordercli 工具实现三大核心功能：历史订单复购、实时配送追踪、账户会话管理。用户首次需配置国家代码（如 AT）并完成登录——支持密码输入或更安全的 Chrome 浏览器 Session 导入。日常使用中，可通过 ordercli foodora history 浏览近期订单，选定订单号后先执行预览命令查看商品、金额、配送地址等详情，经用户口头确认后再附加 --confirm 参数完成真实下单。配送阶段支持 orders --watch 实时刷新 ETA 状态。

显著优点

1. 操作闭环完整：覆盖"选餐-下单-追踪"全流程，无需切换 Foodora App 或网页。
2. 安全设计前置：强制预览-确认两步流程，杜绝误触下单；文档明确标注 Hard safety rules，降低 Agent 自主决策风险。
3. 凭证管理灵活：推荐 Chrome Session 登录方式，避免密码硬编码或明文传输。
4. 开发者背书可靠：作者 Peter Steinberger（steipete）为 iOS/macOS 领域知名开源贡献者，项目托管于个人域名 ordercli.sh，具备一定社区公信力。

潜在缺点与局限性

• 地域受限：仅支持 Foodora 覆盖国家（如奥地利 AT），未提及 Deliveroo、Uber Eats 等竞品适配。
• 地址选择复杂：若账户绑定多个配送地址，需用户手动指定 --address-id，对非技术用户不够友好。
• 依赖外部二进制：需预装 Go 环境并编译 ordercli，Windows 用户可能面临路径或权限问题。
• 无价格变动提示：预览仅展示当前订单快照，若商家调价或菜品下架，实际下单时可能失败或金额不符。

适合的目标群体

• 高频外卖用户：固定餐厅、固定餐品的上班族，追求"再来一单"的极致效率。
• 开发者/极客：习惯命令行交互，愿意用 Chrome DevTools 导出 Session 的技术人群。
• 多账户管理者：需通过 --config 切换不同 Foodora 账号（如家庭共享、公司订餐）。

使用风险

• 金融交易风险：尽管有确认机制，Agent 若误判用户意图（如将"看看"理解为"确认"），仍可能导致非预期扣款。
• Session 过期：Chrome Session 登录有效期有限，失效后需重新导出，中断自动化流程。
• CLI 版本漂移：@latest 标签可能引入破坏性更新，建议锁定具体版本号。
• 隐私泄露：订单历史包含精确地址、消费习惯等敏感数据，临时配置文件 /tmp/ordercli.json 需确保权限隔离。