背景
“今晚吃什么”和“聚会谁带什么菜”是两个真实的高频问题：拿手菜散落在各人的脑子里，聚一次餐要在群里翻几十条消息才能凑齐菜单，买菜还总是漏项。现有菜谱产品偏“看教程”，缺一个“菜单册 + 点菜 + 备料 + 留存”的轻协作闭环。嗨吧啦下厨就是我为这个问题自研的微信小程序，从 PRD、设计到开发完全独立推进。
问题定义
产品定位是个人主体可上线的免费下厨协作工具，这带来两类约束：一是合规边界——个人主体小程序不允许站内交易，产品里必须彻底没有支付、会员、抽成的影子；二是协作体验——家庭日常点菜和聚会合厨看似两个场景，本质都是“选菜 → 汇总 → 备料 → 留档”，需要用一个统一模型支撑。
方案
产品设计。核心是一个统一的「点菜会话」模型：家庭日常（family）与聚会合厨（party）只是场景分型。参与者从菜单册、自己发布的菜、平台菜品里选菜，系统按 dish_id 去重合并总菜单，再按同名食材自动汇总备料清单（单位不一致时分列提示人工确认），结束后留存快照，支持“再来一单”。内容侧是菜品社区 + 多本菜单册 + 单向订阅（刻意不做互关社交），还有可引用的配方模块（比如“辣椒油”做成模块被多道菜引用），支持试做/定稿版本管理。
合规工程。点赞/收藏/评论做成“工程预留、首发关闭”：表结构、API、管理端验证全部就绪，但 C 端入口由 feature flag 控制，默认全关——既满足审核期的简洁，也为后续一键开放留好路径。PRD 层面明确禁止任何支付相关表与接口进入本期工程。
技术实现。Monorepo 三端：apps/api 是 NestJS REST API（统一包络、Bearer 鉴权、资源复数路径），Prisma 接阿里云 RDS PostgreSQL；apps/mobile 用 uni-app（Vue 3）同时出微信小程序与 H5；apps/admin 是 Vue 3 管理端，覆盖审核队列、举报处理与下架。共享包沉淀类型与“青灶”设计 Token，保证三端视觉一致。
多 Agent 并行开发。整个项目用 7 个 AI Agent 在 git worktree 里并行推进：每个 Agent 认领明确的目录所有权（脚手架、账号、内容、聚会、配方模块、移动端、管理端），公共文件由编排者收口，最后完成 H5/Admin 端到端真接口联调与种子数据。这是我把 AI Coding 从“辅助写代码”用到“组织工程”的一次完整实验。
我的角色
独立负责产品定义（PRD 三版迭代）、视觉风格定稿、技术选型与架构、多 Agent 任务拆解与合并验收，以及部署上线的全流程。
结果
核心功能全部走通：账号、菜品发布与浏览、菜单册、家庭/聚会点菜、备料清单、历史留存、管理端审核，小程序端编译就绪并完成联调。目前正在办理备案与合法域名，准备提审上架。
复盘
这是第一个完全按产品思路做的独立作品，最大的收获在两点：一是合规不是上线前补的手续，而是从数据模型开始就要参与的约束；二是多 Agent 并行的可行性高度依赖“所有权边界 + 接口先行”，这套经验直接改变了我组织个人项目的方式。