Yachtxchange：一个按角色授权的应用、五项 AI 功能，以及面向游艇经纪公司的近零闲置技术栈
开发日志，来自 Yachtxchange ——SEYSO 面向游艇经纪公司的 B2B SaaS。买家获得 YachtWorld 级别的浏览体验，而经纪公司购买的是分级软件：一个移动应用覆盖两大商店，一个可在三分钟内根据照片起草刊登信息的经纪人门户，以及经纪公司休息时几乎归零的基础设施账单。
1 app
双商店发布，按角色授权
5
多种角色，一套代码库
30→3
每条刊登所需分钟数
~$0
每租户闲置基础设施
切入点：经纪公司购买软件，买家获得交易市场
游艇市场靠刊登收费；实际工作的经纪公司仍依赖电子表格、照片文件夹和复制粘贴的 Word 描述。为每艘船写好一份刊登——标题、面向买家的文案、设备清单、状况说明——大约需要三十分钟，这也造成各经纪公司页面内容参差不齐。
Yachtxchange 改变了这一模式： 经纪公司才是客户 。他们订阅套餐，获得代劳繁琐工作的门户，库存则支撑起一流交易市场般的买家体验——同时覆盖 Web 和原生移动端，经纪公司无需自行开发。
四档套餐，由代码执行，而非写在 PDF 里
Solo 每月$99（5条刊登、1个席位），Pro $299（25条刊登、3个席位、潜客评分），Brokerage $799（100条刊登、10个席位、价格情报），以及提供 API 访问和白标的定制 Enterprise 套餐。关键在于限制的执行位置： ensureCanCreateListing , ensureCanAddSeat 和 ensureAiCreditsAvailable 是在 Server Actions 和 API 路由内部调用的守卫，以 Stripe 为权威数据源 ，并通过 webhook 将订阅状态同步到本地。不靠自觉遵守额度，也不需要夜间对账作业。
AI 用量以同样方式计量——每次助手调用都在 usage_events 表写入一行，因此套餐额度从第一天起就可计数、可计费、便于审计。
五种角色，一套代码——经纪公司自行组织团队
两大商店中只有一个移动应用，一个域名上只有一个 Web 应用。您看到什么，取决于您的身份：
buyer自行注册。浏览、保存搜索、联系经纪人。
broker_lead使用经纪公司邮箱域名注册的首位用户。拥有完整经纪人权限，以及账单和团队管理权限。
broker_backup同一域名注册的第二位用户。拥有完整权限，负责人离开时自动晋升为负责人。继任是账户配置规则，无需提交支持工单。
broker_agent由负责人或候补负责人邀请。管理刊登与潜客，可逐用户配置。
adminYachtxchange 员工。拥有完整平台管理权限。
经纪公司映射为 Clerk Organizations ，负责人/候补/经纪人的协作逻辑集中在一个配置模块中。一个小而重要的保护措施是：gmail 等免费邮箱域名绝不会自动匹配已有经纪公司，因此使用 Gmail 地址的陌生人无法进入他人的租户。
单仓库：以 Zod 模式作为契约
两个应用—— apps/web （Next.js 16 App Router，营销、买家、经纪人和管理员各有路由组）以及 apps/mobile （Expo + EAS）——基于六个共享包： db （Neon 上的 Drizzle ORM）、 auth （Clerk 封装与账户配置）、 ai, billing , ui 和 types 。types 包是核心： Zod 模式是统一契约 ，由 Web Server Actions、API 路由、移动 API 客户端及 AI 工具共享。一次模式变更会传播到编译器所能检查的所有位置。
超越刊登信息的数据模型
模式目录揭示了产品的真实方向：刊登、潜客、报价、预约、验船师和文档保险库。Yachtxchange 正悄然构建交易室，而不只是展示橱窗。
以严谨规范实现多租户
每条租户所属记录都携带 brokerage_id ，每次查询都据此筛选，或受管理员守卫保护。金额以分为单位存储为 bigint ——绝不用浮点数。
AI 层：五项功能，不绑定供应商
所有请求都路由经过 Vercel AI Gateway ，使用普通的 "provider/model" 字符串——代码库不内嵌供应商 SDK，因此切换模型或进行 A/B 测试只需修改字符串，并自带可观测性与回退能力。
刊登助手——从30分钟到3分钟的功能
经纪人上传照片与要点规格；视觉模型通过 generateObject 按 Zod 模式返回结构化草稿：SEO 标题、3–5段面向买家的描述、首屏亮点、从照片推断的设备清单、状况等级及自动标签。两项设计最为关键：提示词禁止编造规格，只允许使用已提供或可从图像推断的信息；模式中还包含一个 warnings 数组，指出矛盾和需要核实的陈述，使经纪人专注检查提示，而不是逐字校对。刊登创建时间由约30分钟降至约3分钟。
语义搜索
利用 pgvector 对刊登嵌入向量进行余弦搜索——可搜索“40万以下、适合大环线航行的稳定拖网式游艇”，不只是按品牌/型号筛选。
潜客评分
为询盘给出0–100评分及建议下一步行动——Pro 套餐经纪人不再凭直觉整理收件箱。
验船报告提取
从验船报告 PDF 中提取结构化数据——这份关系每笔交易的文档，终于可以被机器读取。
验船师审核
验船师名录中的背景信号接入预约流程——将信任落实为代码。
已搭建框架的后续功能：价格情报、照片增强与自动标记、以图搜索、翻译，以及重复照片欺诈检测。
经济性：闲置成本归零的技术栈
B2B SaaS 的利润空间来自基础设施选择。经纪公司每天可能活跃八小时——我们选择的技术栈让其余十六小时不产生成本：
Vercel Active CPU 定价 — 仅为实际工作期间的 CPU 使用付费——函数等待数据库或 AI 调用时不收费。
Neon 缩容至零 — Postgres 计算费用在闲置时降至 $0。每天活跃 8 小时的经纪公司只需支付 8 小时的费用。
单一多租户部署 — 所有经纪公司共享一个项目和一个数据库，通过 brokerage_id 隔离——无需逐租户照管基础设施。
Fluid Compute 实例复用 — 并发请求共享已预热的实例；冷启动是例外，而非常态。
真正的成本上限在照片和视频存储——游艇刊登的媒体体积很大。我们已采取缓解措施（上传时缩放并转为 AVIF、积极缓存），并预先约定触发条件：若出站流量账单超过约$500/月，存储迁至 R2。在账单到来前决定退出条件，是成本最低的架构评审。
当前状态
目前 Web 和移动端都运行于实时数据模式之上——买家浏览、带刊登助手的经纪人门户、套餐计费和按角色授权的移动应用，已在内部开发环境中可用。EAS 构建配置已接好商店提交流程。交易室功能（报价、预约、验船师排期、文档保险库）将基于已就位的模式交付。
如果您经营经纪公司，觉得值得用自己的库存测试“30分钟缩短至3分钟”的刊登效率，我们正开放少量试点洽谈。
与我们洽谈试点
Yachtxchange 由打造 LiftCrew AI、Sentinel 和 Liftline 的团队构建——我们的移动应用即服务业务也采用同样的订阅模式。