Master Connecter：生意伙伴与圈子协作平台

传统名片解决“我是谁”，却很少回答“我适合谁、需要谁、怎样被引荐”。项目先把一次合作从认识到继续协作的路径拆开：业务画像如何形成，哪些字段可以被谁看到，关系怎样建立，AI 建议如何交给人确认。

随后，Web、微信小程序与 FastAPI 后端围绕生意名片、Business DNA、伙伴关系和圈子协作搭建最小闭环，并把字段可见性、成员角色和邀请边界放在产品核心，而不是在上线后再补隐私设置。

商业人脉往往停留在通讯录和一次性介绍里，合作双方需要反复追问彼此卖什么、服务谁、缺什么资源。没有结构化业务上下文，搜索结果很难转成有质量的引荐，圈子也容易退化成一张没有下一步的群成员列表。

更重要的是，手机号、位置、客户画像和合作意向并不应该默认公开。AI 如果读取了未授权的字段，哪怕给出的合作建议听起来合理，也会把信任成本转嫁给平台和用户。

Master Connecter 先让用户填写核心业务、目标客户、资源需求和引荐触发词，形成可继续维护的 Business DNA。每个字段都可以设置全网、会员、伙伴或仅自己可见，业务名片因此成为带权限的协作上下文，而不是一张静态海报。

伙伴模块支持搜索、添加和关系状态；在双方建立关系并授权后，BizMatch AI 才对业务画像做合作可能性分析，输出理由与下一步行动建议。圈子模块再承接成员、角色、邀请和资源互换，让一次介绍有机会继续变成协作。

Vue Web、微信小程序和 FastAPI / SQLModel API 共享 Supabase / PostgreSQL 数据边界。AI 撮合目前以规则和 Mock 演示为主，最终是否联系、引荐或合作仍由用户和圈子负责人决定。

名片、联系方式、位置、伙伴和圈子数据按字段可见性与成员关系隔离；AI 撮合只应读取双方已授权的业务上下文。公开案例不包含手机号、联系人、密钥或真实合作记录。

项目把名片从“我是谁”扩展为“我卖什么、适合谁、需要谁、如何引荐和如何验证”：业务上下文先得到结构化，再由伙伴与圈子关系承接。AI 的位置是帮助人看见可能性，而不是替人建立关系。

当前公开材料不包含真实用户数据、联系人、手机号或合作记录；撮合逻辑也尚未形成可公开的成功率、收入或转化基线。案例只说明权限模型、多端协作和下一步建议机制。

本案例基于 Master Connecter 当前 Web / 小程序与 FastAPI 产品骨架。业务名片、伙伴关系、圈子和 AI 撮合用于说明协作机制，不构成真实人脉规模、撮合成功率、合作收入或商业转化结果。