Plan2meal

核心用法

Plan2Meal 是一个面向食谱管理与购物清单生成的 ClawdHub Skill。用户可通过自然语言指令完成以下操作：

• 食谱管理：从 URL 导入食谱（add）、浏览全部（list）、关键词搜索（search）、查看详情（show）、删除（delete）
• 购物清单：创建清单（list-create）、查看清单（lists / list-show）、将食谱加入清单（list-add）
• 身份认证：支持 GitHub（必需）、Google、Apple 三种 OAuth 登录方式

显著优点

• 结构化食谱存储：支持从网页 URL 自动解析并保存食谱，便于长期收藏管理
• 购物清单自动化：可将食谱一键加入购物清单，简化备餐流程
• 多平台 OAuth：提供灵活的登录选项，降低单点登录失败风险

潜在缺点与局限性

• 后端依赖性强：核心功能完全依赖 Convex 云服务（https://gallant-bass-875.convex.cloud），非本地处理，网络中断即不可用
• 共享后端风险：默认使用共享后端，需显式设置 ALLOW_DEFAULT_BACKEND=true 才能启用，存在数据隔离和隐私顾虑
• 配置门槛高：需配置 5+ 个环境变量（含 OAuth 密钥、回调 URL、ClawdBot URL），对普通用户不够友好
• 生态封闭：明确拒绝通用烹饪建议或与其他系统（如 Apple Reminders）集成，功能边界严格限定

适合人群

• 已有 Plan2Meal 账户且习惯命令行/聊天界面管理食谱的技术用户
• 需要批量整理网络食谱并生成购物清单的备餐规划者
• 愿意自建 Convex 后端以替代共享服务的隐私敏感用户

常规风险

• 数据路由不透明风险：Skill 强制要求披露后端调用，但用户易忽略共享后端的数据托管性质
• OAuth 配置泄露风险：GitHub/Google/Apple 密钥若配置不当可能被暴露
• 供应商锁定：深度绑定 Convex 生态，迁移成本较高
• 共享后端数据安全：未明确说明数据加密、访问控制及合规认证（如 SOC 2）

核心功能与用法

Plan2Meal 是一个专为食谱管理和购物清单设计的对话式技能，让用户无需离开聊天界面即可完成料理规划全流程：

食谱管理：通过 plan2meal add <url> 导入网络食谱，系统自动解析并存储；使用 list 查看全部食谱，search <关键词> 快速查找，show <id> 查看详情，delete <id> 删除不需要的条目。

购物清单：list-create <名称> 创建新清单，list-add <清单ID> <食谱ID> 将食谱食材批量加入购物清单，lists 和 list-show <id> 管理查看现有清单。

认证流程：支持 GitHub（必需）、Google、Apple 三种 OAuth 登录，通过 login/logout 命令管理会话。

显著优点

• 一站式整合：食谱采集→存储→搜索→购物清单生成形成完整闭环，无需多应用切换
• 多平台 OAuth：提供三种主流登录方式，降低用户使用门槛
• 透明数据披露：明确告知共享后端地址（gallant-bass-875.convex.cloud）和使用条件
• 清晰路由边界：文档严格限定使用场景，避免与通用烹饪建议、营养咨询等功能混淆

局限性与注意事项

依赖外部服务：核心功能完全依赖 Convex 后端，离线或后端故障时不可用；共享后端需显式开启 ALLOW_DEFAULT_BACKEND=true，自托管需要额外配置。

会话管理限制：当前 OAuth Token 采用内存存储，进程重启会导致会话丢失，不适合长期生产环境部署。

URL 验证待加强：仅基础 URL 格式校验，未限制协议类型和域名白名单，存在潜在 SSRF 风险。

环境配置复杂：除主环境变量外，需配置多组 OAuth 凭证和回调 URL，初次设置门槛较高。

适合人群

• 需要集中管理网络食谱的料理爱好者
• 希望从食谱直接生成购物清单的效率用户
• 已使用或愿意使用 Convex 作为后端的技术接受型用户

常规风险

• 数据持久性风险：内存会话存储可能导致意外登出
• 后端依赖风险：功能完全依赖 Convex 服务可用性
• 输入验证风险：URL 解析可能被恶意利用
• 日志泄露风险：错误日志可能包含敏感请求参数