ChefShot · AI 商业视觉引擎
一句话量级
请一次商拍 $500 起（行业报价，非我方实测）还得等排期，而这条管线把出图变成按张计费：单张成本落在美分区间（图像 API 单价 × 张数，以你的账单为准），一次拍摄自动出齐 4 个外卖平台的合规尺寸（UberEats 5:4 / DoorDash 16:9 / Grubhub 1:1 / TikTok 9:16）。
商拍 $500 起/次 = 行业报价，非我方实测。另一边是「图像 API 单价 × 张数」；自托管则「GPU 电费 + 折旧 ÷ 张数」——两边都以你的实际账单为准。一次拍摄输出 4 个平台规范：UberEats 5:4 / DoorDash 16:9 / Grubhub 1:1 / TikTok 9:16。
你买的到底是什么
ChefShot 把手机随手拍变成能直接上架外卖平台的商用菜品图——iOS 端侧采集 + AISwarm 多智能体视觉管线的自研产品（in-house product），一次拍摄自动出齐各平台合规尺寸。
它替代的是什么
- 场景：一家幽灵厨房，老板一个人盯店。菜单要上新汉堡，他要一张能挂上外卖页的图。可一次商拍 $500 起（行业报价），还不是想拍就能拍——要等摄影师排期，拍完还要等后期。对一家单店，这笔钱摊不平，等的时间也等不起。
- 于是他掏出手机，在杂乱厨房里拍一个汉堡：背景是油渍和不锈钢台面，顶上的冷白灯把肉饼照成灰色。图挂上外卖页转化就掉；尺寸和风格不合平台规范，还有被平台下架的风险。通用大模型也不敢直接用——Midjourney 这类模型会给牛肉汉堡幻觉出培根，菜里没有的食材出现在商品图上，一次客诉就是一条平台违规记录；而非技术老板也驾驭不了复杂的 Prompt 工程。
- 技术上真正的坎是「等待」：生图是几十秒级的长等待请求，iOS 原生网络栈在这种长连接上会 -1005 超时断连。按「调一次 API」的写法，用户等到一半就白等。
架构
一条横向主线：设备端采集 → AISwarm → 云端。NON_FOOD 拦截落在两个 Agent 之间，向下引虚线支路至 refund_credit_logic；末端 SwiftData 本地图库以回环虚线指回手机，所以断网也能翻图库。
防护栏
- 长连接可靠性——针对 iOS -1005 重写网络层：生图属于长等待请求，iOS 原生网络栈会 -1005 超时断连；已重写网络层：独立 URLSession 实例 + httpShouldUsePipelining = false + 指数退避重试，让生图的几十秒等待不断线。
- 防幻觉与商业合规——Prompt 引擎硬编码 [CRITICAL IDENTITY LOCK]（主体身份锁）与 [GEOMETRIC & ANATOMY LOCK]（几何与解剖锁），只允许对盘面光影做文章，绝不凭空捏造食材。
- 账单零差错（状态机回滚与事务补偿）——Agent A 拦截非食物（NON_FOOD）或网络波动时，触发云端 Supabase 存储过程 refund_credit_logic 自动退费补偿，前端同步触发降级 UI 兜底。
你最终拿到手的东西
- iOS 原生应用——基于 SwiftUI / SwiftData 的 Local-First 客户端，集成苹果原生支付（StoreKit 2）与 Sign In with Apple。这些是产品自身的资产，不是客户交付物。
- 高并发 API 网关——基于 FastAPI、部署于 Vercel 的服务端点。
- DB 与对象存储配置——完整的 Supabase Schema、RPC 函数（含 refund_credit_logic）及 Vercel Blob 权限体系。
技术栈
- 编排层
- AISwarm multi-agent pipeline (Agent A · Qwen-VL-Plus visual review / Agent B · FLUX.1-Kontext-dev light reconstruction) · FastAPI streaming gateway
- 数据层
- Supabase (PostgreSQL + RPC stored procedure refund_credit_logic) · Vercel Blob · SwiftData local vector store
- 呈现层
- iOS · SwiftUI · AVFoundation (AVCaptureSession, CMMotionManager) · Apple Vision · CoreImage · StoreKit 2 · Sign In with Apple
数字，以及它的算式
- 商拍 $500 起 / 次
- 行业报价（外部市场价，非我方实测）。一次拍摄还要等排期，单店摊不平。
- 单张成图边际成本 = 美分到十几美分
- 按量计费：图像 API 单价 × 张数；自托管：GPU 电费 + 折旧 ÷ 张数（以你的实际账单为准）。从「一次拍摄」变成「按张计费」。
- 4 个平台尺寸自动合规
- 结构化事实，非实测：UberEats 5:4 / DoorDash 16:9 / Grubhub 1:1 / TikTok 9:16，按预设规范自动输出。不用再手动裁图。
- 端侧抠图（原图不上云）
- 实现事实：iOS Vision 在设备端完成主体抠图与蒙版剥离，发生在任何上传之前。隐私 + 速度。
- -1005 断连重写
- 实现事实：独立 URLSession + httpShouldUsePipelining = false + 指数退避。生图的几十秒等待不断线。
同一个形状，另外三个问题
如果你的事不是上面那个场景，这一段才是重点：同一套架构指向三个互不相关的场景，都不是上一个案例的变体，也不需要从零重建。这些是**可平移的方向，不是已交付的项目**——上面那套系统是我们真跑过的，下面这三条是它的形状接下来能解决什么。这个区别我们标出来，不含糊过去。
电商 / 独立站商品展示
手机绕拍首饰或美妆，端侧剥离杂乱背景，按材质（金属反射、玻璃透光）分配专属 Prompt 生成商业主图。
二手车出海交易平台
车库拍摄车辆，管线自动识别车型并打标、替换极简展厅背景、屏蔽车窗反光中的路人隐私。
房地产与室内软装
拍摄毛坯房，多模态引擎识别房间结构，生成带光影追踪的整套风格化渲染图。
有系统要做？
把情况写下来。你拿到的是针对你情况的书面回复——没有日历、没有 discovery call、没有十五分钟的寒暄。
状态
已上线 iOS App Store——我们唯一一个已公开发布的产品。除此之外仍是 Built in-house 自研体系：这是我们给自己造的工具，不声称在为客户生产运行。
已上线 iOS App Store。自研产品，不是客户案例。