阿拉丁神灯 产品与技术路线设计
设计日期:2026年11月5日。状态:待评审的产品方案,尚未进入开发。
本文件保留为V1历史;当前范围、开源选型、先企业工具后扩大社交的实施顺序,以及任务和验收以设计任务书V2为评审基线。原品牌与视觉仍是待定概念。
阿拉丁神灯面向全球用户,围绕真实需求,让来自不同市场的人、企业、能力与项目彼此发现。个人、企业和在地伙伴都能发布需求、提供能力、发起项目或回应合作,同一账号可以同时是采购方、供应方和协作者。市场表示机会在哪里发生,用户可选择合作地区、界面语言和阅读语言。智能体协助理解、寻找和澄清,交流由双方共同决定。
1 产品原则与首期切口
| 用户提出的方向 | 产品中的具体体现 |
|---|---|
| 回归真实需求 | 用“我需要、我能提供、一起做”表达意图,允许预算和交期未知;不把负面情绪、浏览或点赞推断成采购意向 |
| 社交性质 | 人、项目、话题、关注、评论和有上下文的连接请求;作品与讨论也能形成关系,不强迫每条动态变成询价单 |
| 全球双向奔赴 | 同一账号可以同时有需求和能力;供需双方都能解释为什么想联系,接收者决定是否交流 |
| 极客精神 | 展示作品、设计过程、测试记录和可交付内容;优先以可验证的贡献建立信任,后续保留开放接口与个人数据导出路线 |
| 自由贸易 | 用户自主选择地区、语言和合作方式;匹配理由可见,可关闭个性化推荐;跨境约束如实呈现而不擅自代用户作出承诺 |
| 熟悉的语言 | 界面、公开内容和对话分别按偏好展示;译文可与原文对照,交易条件保留原值 |
首期建议先验证创客、开源硬件与小团队的打样、小批量制造和工程协作。这里的需求有规格、数量、作品和交期,容易判断一次连接是否有用,也能体现双方互相采购与共创。产品的数据模型保留服务、软件、货物与合作类型,不把长期范围限定为硬件。
这是冷启动假设,需要用户决定;它不是已经完成的市场研究。全行业同时启动会让内容、术语、身份和供需密度更难验证。
2 用户闭环
- 用户以母语描述需求、能力或共创想法。神灯只补充问题和建议,明确预算、交期等未知项。
- 用户确认结构化信息、公开范围和原文后发布。普通经验分享仍作为普通动态存在。
- 关注流和发现流展示站内内容;需求广场提供地区、服务范围、类型、状态与时间筛选。
- 站内匹配返回具体依据和缺项;公开网页仅以外部线索出现,保留原链与时间。
- 用户围绕某张需求卡发起连接请求,对方接受后进入会话。对外部线索只提供查看来源及研究,不假装对方已注册或同意私聊。
- 双方在双语会话中澄清规格、数量、预算与下一步。AI可以整理问题和拟草稿,发送由本人决定。
- 需求方标记继续寻找、已解决或关闭;双方反馈相关性和沟通结果,用于纠正后续匹配。
示例:墨西哥团队需要200套低功耗门锁,深圳工程师能做小批量打样;同一工程师又需要海外伙伴完善西语文档。两张需求和能力可以交叉连接,关系不固定为买家或卖家。
3 社交对象与页面
| 对象 | 关键内容 |
|---|---|
| 人与组织 | 自述身份、地区或服务范围、语言、作品、擅长事项;身份声明和已核实信息分开 |
| 动态 | 原文、语言、内容版本、作者、可见范围、附件、评论与引用;可关联项目或需求 |
| 需求和能力 | 类型、具体事项、规格、预算及币种、数量及单位、时间要求、地区、当前状态;未知字段可空 |
| 项目 | 目标、阶段、需要的伙伴与已有能力、关联动态和资料 |
| 外部线索 | 原始来源、发布时间与发现时间、采集方式、授权范围、提取状态;不能自动生成站内作者 |
| 匹配候选 | 关联双方、满足的条件、未知项、不适配项、依据及用户反馈;它是推荐,不是已确认商机 |
| 连接与会话 | 邀请所关联的需求、双方接受状态、成员、消息、消息版本、译文、屏蔽与举报 |
公开、仅关注者、项目成员和仅本人等范围需要在发布前明确。外部公开资料与会话中的私人资料分别授权,私人报价和需求不会被默认拿去做公开匹配。
桌面导航建议为“发现、需求广场、消息、神灯助手、我的主页”,配独立发布按钮;手机底栏为“发现、需求、发布、消息、我的”,助手从需求详情或上下文进入。导航名称和图标在开发前统一。
首页以可交流的动态为主体,右侧呈现匹配解释与机会地图入口。地图是发现视角,展示用户自愿公开的地区或服务范围,不推断个人实时位置,也不以点位数量证明市场规模。
4 语言展示和实时翻译
共享试点的登录、全局导航和发现页已接入简体中文与英文。发现页的当前成员帖子可按账号阅读语言请求原位译文,登录前则使用设备选择或浏览器语言。站内消息继续使用独立的阅读设置,目标语种可配置中、英、德、西、葡,自动翻译须经本人开启。资料正文和官方公告的通用翻译仍待接入,部分公告已有绑定证据版本的中文简报。 现有界面 · 消息翻译 · X 帖子译文交互
4.1 语言、地区和偏好
| 设置 | 定义与保存 |
|---|---|
界面语言 uiLocale |
值为 auto 或应用已发布的 BCP 47 语言标签,控制界面文案、表单、无障碍标签与格式化。登录前按同源设备保存,默认 auto,从浏览器的语言顺序选择已有语言包。 |
内容阅读语言 readingLocale |
值为 follow-ui 或一个 BCP 47 标签,控制内容译文。语言包和翻译语对分别登记,界面支持该语言并不代表能翻译到该语言。 |
无需翻译语言 excludedSourceLocales |
保存标准化语言标签列表,按确切标签排除。排除规则只影响自动译文,保留按需翻译操作。 |
内容源语言 sourceLocale |
每个原文版本记录 BCP 47 标签或 und,并记录作者、官方来源或自动识别的依据。无法确定的语种以「原文语言未确认」标记。 |
登录后的语言偏好由账号跨设备同步,包含 uiLocale、readingLocale、excludedSourceLocales、autoTranslatePublic 和并发修订号 revision。新账号默认跟随界面语言、排除列表为空,用户可在首次使用时选择是否自动翻译公开内容。设备侧只记登录前的界面选择,登录后采用账号已保存偏好,并允许用户主动同步当前选择。保存冲突提示重新载入,切换界面语言保留当前页面、筛选和编辑草稿。现有会话阅读语言及自动翻译开关独立保留。单个会话可临时切换阅读语言,私聊自动翻译仍由本人授权。
语言标签按 BCP 47 标准化,先匹配明确选择的完整标签,再匹配已登记的回退语言包。首批提供 zh-Hans 和 en,浏览器语言无匹配时采用英文。保留用户的原选择,在语言控制处标明实际使用的界面语言及回退状态。目标语种或语对尚不可用时,内容保留原文并说明状态,译文不会切换到另一语种。简繁或地区变体只有在相应语言包与译文质量通过验收后才开放。 BCP 47
界面文案集中为按语义索引的语言包,用参数格式化状态、复数和可访问名称。页面设置 lang、dir,布局使用 CSS 逻辑属性。买方名称、公告编号、型号等混合书写内容使用独立方向标记。阿语等从右至左语言启用前,验证桌面和手机的导航、地图控件、表单、键盘操作和焦点顺序。日期、数字和市场名称用所选地区格式显示。金额、币种、单位、数量、日期和型号沿用原始结构化字段,官方时区缺失时保留公告原文及待核对提示。若提供本地时间换算,须同时展示官方所列时刻及其时区。 W3C 文本方向指南 · ECMAScript 国际化 API
4.2 每条机会的原文与译文
发现页在每张机会卡和详情中按阅读语言呈现标题与范围。优先使用同一证据版本下的官方目标语文本,其次使用已核对的目标语简报,再使用有机器译文标记的翻译。没有适用译文时显示原文。每张显示译文的卡片均可原位切回原文。详情保留来源、证据日期、原文链接,并提供双语对照和译文纠错入口。发布者自述与官方材料分开显示。译文、地区格式化和摘要不改变原始价格、资格、递交时间或官方链接。
翻译任务由服务端按内容 ID、字段和当前版本读取有权查看的原文。缓存键包含原文版本或摘要指纹、源与目标语言、术语表和提供方版本。作者编辑、官方公告修订、内容撤回或授权失效后,旧译文退出当前卡片,迟到的旧响应不得覆盖新版本。已保存的证据快照保留其版本及原文。自动翻译只处理当前可见内容,后台调用设并发、时限和成本上限。消息先可靠送达,随后按授权异步显示译文。公开卡、授权资料和会话分别使用其原有读权限,私有正文、原件与消息不得进入公开译文缓存。发送前的译文预览只读,原文仍由作者确认和发送。
4.3 交付与验收顺序
| 阶段 | 范围和出口条件 |
|---|---|
| L1 登录与发现 | 先交付中英语言包,覆盖登录、全局导航、发现页地图、筛选、卡片和详情。实测浏览器默认、手动选择、刷新、登录后双端同步、未支持的语言及可访问标签。公开机会用隔离样本验证原位译文、切回原文、失败提示和旧译文失效。 |
| L2 发布与资料 | 覆盖供需发布、编辑、撤回、机会清单、市场情报、资料审核和授权交付。用真实获准样本核对官方原文、价格币种、日期与公告截止。测试源语言声明、双端修订、权限撤销、原件保持和账户导出。 |
| L3 消息与扩展 | 完成会话、通知、翻译设置、错误状态和运营端本地化。分别测量消息送达与译文可见时延、翻译失败率和调用成本。逐个开放通过语对质量、地区格式、桌面和移动视口、方向布局及键盘测试的语种。 |
Cloudflare 伙伴评审站公开完整设计、英文导览和概念图。地图、分类机会流和译文切换使用独立演示素材。伙伴可按设计主题提交意见,由项目运营人员查看。实际应用的登录、共享数据库、实时发布、私有资料和消息翻译使用隔离服务单独验收。 完整设计 · English guide
5 三个项目的评估
以下版本观察截至2026年11月5日,设计阶段只读核查,没有升级本地依赖。
| 项目 | 当前核对结果 | 适合承担的职责 | 不能直接视为已有的能力 |
|---|---|---|---|
| 官方DSH | 雷达内置rc.2;本地官方仓库rc.3。官方npm latest为0.2.1-rc.5,next为0.2.2-rc.1 | 受控工具调用、需求理解、公开Search/Fetch、研究会话、匹配解释和沟通草稿 | 社交账号、租户授权、消息持久化、公共翻译服务、可靠全局调度 |
| BettaFish | 官方README徽标v1.2.1;Query、Media、Insight、Report与Forum协作 | 借鉴多来源研判、证据整理、研究简报;经许可确认后的可替换研究组件 | 真人社区、关注关系、私聊、采购意向模型;Forum是模型协作,情绪并非需求 |
| WorldMonitor | 本地2.6.5;官方main清单2.11.8,未据此认定为最新正式Release | 全球发现、来源分类、去重、缓存、新鲜度、地图和采购机会结构 | 完整供需社交关系、端到端双语私信、所有平台全网搜索 |
版本来源:DSH官方npm元数据、BettaFish README、WorldMonitor package.json。本地DSH核对提交为 1f81c047fc48fa190a683e469daa699857e9afe8,本地WorldMonitor核对提交为 824b8cac99de9d2ccfb2b453eed1ede8fbaaebb8。
DSH的运行边界
DSH放在云端隔离worker。业务服务把已授权的需求快照交给worker,并仅开放读取需求、检索公开资料、查询候选、生成建议与草稿等工具。模型不直接访问数据库或通用社交账号,也不由手机常驻运行完整DSH。
发布需求、发起连接、发送消息和提交报价必须经过用户确认后的业务接口。确认绑定用户、对象版本、动作和草稿内容,重复请求以幂等键消重。授权身份来自服务端会话,不相信模型传入的用户或组织ID。
官方SDK的SessionTree通知过滤不是租户授权;Schedule依赖Host运行,派发记录也不等于任务已执行。因此持久队列、outbox、重试、任务状态、配额和跨worker的全局限流需要业务层负责。参考DSH架构、SDK契约、Schedule及安全边界。
新版官方master的Search/Fetch配置已分离为searchBaseURL/searchApiKeyEnv与fetchBaseURL/fetchApiKeyEnv,旧配置可加载但不再生效。当前rc.2桥接不能简单换包沿用;进入开发时应在适配层迁移并固定经验证的官方版本,而不是追随浮动next标签。Web Provider文档
WorldMonitor的可借鉴点
其全球采购模块将公开招标与历史中标分开,保留买方、截止日期、金额、原链和来源状态,很适合需求卡建模。模块存在Pro权限边界,不能假定官方服务是免费后端。账号与订阅设施也不能直接替代本产品的社交授权模型。采购模块、架构
官方X数据接入为预置新闻账户的官方API采集,并非任意用户监控或全网获客搜索。外部平台只能按实际可用、获准的公开数据接入,保留逐来源失败和过期状态;来源失败不能显示为该地区没有需求。数据来源
商业复用的许可路线
官方DSH主许可为MIT,复制或分发时需要保留版权及许可声明,第三方依赖另见其THIRD_PARTY_NOTICES;这与其他项目的源码和数据许可分别处理。DSH LICENSE
BettaFish的主许可文件包含GPL及其他第三方许可,涉及MediaCrawler的非商业学习条件,README也有明确学习研究用途声明。不能按GitHub的单一许可证标签推定整套可商用,也不能假定套一层API便能解决授权。WorldMonitor应用源码为AGPL-3.0-only,代码、官方服务、数据与商标是不同的权利范围。
建议新产品业务核心独立实现;现有研究能力以可替换接口接入。开发前建立逐组件来源与许可清单,决定采用相应开源履约方式、取得授权,或独立实现需要的能力。评估研究与设计可以继续,这里不提前确认商业授权结论。依据:BettaFish LICENSE、MindSpider LICENSE、WorldMonitor LICENSE、官方许可说明。
6 推荐技术架构
推荐从模块化业务服务开始,按执行与数据权限拆分worker,避免首期就引入一套庞大的微服务平台。现有Vue3响应式经验可以延续;DSH的TypeScript接缝与Python研究组件通过受控接口连接。
图表文字 · Diagram source
flowchart TD Clients[Web与手机客户端 桌面Tauri壳] --> API[业务API 鉴权与配额] API --> Social[身份 关系 动态 项目 需求] API --> Chat[连接请求 会话 消息] API --> Match[条件过滤 候选匹配 解释与反馈] Social --> DB[(PostgreSQL 业务数据与权限)] Chat --> DB Match --> DB API --> Queue[持久任务队列与Outbox] Chat --> Queue Queue --> Translate[独立翻译worker 版本化译文] Queue --> Discovery[公开来源连接器 去重与新鲜度] Queue --> Agent[隔离DSH worker 工具白名单] Agent --> Tools[Search Fetch 匹配查询 研究建议 草稿] Tools --> Research[可替换研究服务 BettaFish候选] Translate --> Events[WebSocket与平台通知] Agent --> Events Events --> Clients
| 模块 | 首期方案 | 扩展边界 |
|---|---|---|
| 客户端 | 复用Vue3知识和通用组件,重做社交信息架构;响应式Web先验证,桌面沿用Tauri经验 | 手机端按推送、附件、离线和商店要求评估Capacitor,现有工程不等于已完成新App |
| 业务API | TypeScript模块化服务与WebSocket,统一账号、组织、会话、授权和配额 | 不复用当前PIN登录和内存会话作为全球账号系统 |
| 数据 | PostgreSQL存用户、动态、需求、关系、消息及版本;附件走受控对象存储 | 首期不需要图数据库;多语言检索成熟后再选择向量索引 |
| 匹配 | 明确条件过滤、全文检索、人工反馈,先展示满足条件与缺项 | 数据充足后引入跨语言向量召回与重排;保留最新和关注视图 |
| 翻译 | 独立提供方适配与版本化缓存,区分公开和会话可见范围 | 行业术语表、纠错和语言质量按场景评估;不与DSH研究链耦合 |
| 异步任务 | 业务持久队列、outbox、幂等、重试、取消与审计 | Redis等缓存/全局限流按负载引入,DSH Schedule不替代业务队列 |
| 研究 | DSH worker独立会话和凭据,按任务读取已授权快照;保留来源、截断、失败和成本记录 | 深度Betta分析为按需任务,可替换且受许可前置条件约束 |
| 外部发现 | 小规模可核对的公开来源与用户导入原链,逐源记录授权、新鲜度和失败 | 博查、AnySearch、DSH可作为连接器候选;全球覆盖、价格与语言质量另评估,不承诺全平台抓取 |
普通社交用户不需要填写模型Key。平台服务端管理提供方凭据、用户配额和成本;原型中当前Windows用户的加密Key方式不能直接变成多租户凭据系统。私有部署与自带Key是否进入商业版本留待后续决定。
7 匹配与神灯助手
匹配先使用双方明确写出的条件:事项、交付能力、地区或可服务范围、数量、预算与币种、时间以及可沟通方式。未知项提示待确认,不把未知当作不满足;同样不能把未知补成已满足。
推荐结果给出“相符依据、仍需确认、不适配原因、来源与更新时间”,不以虚构的成交概率或未经校准的百分比包装可信度。排序不能把付费能力或平台曝光量伪装成需求真实性。用户能切换关注、最新和自选条件,反馈不相关、已经解决或不希望被推荐。
首期神灯助手围绕具体需求提供四类动作:
- 帮我说清楚:补充规格与问题,形成待本人确认的需求草稿。
- 找找合适的人:在获准的站内能力及公开资料中找候选,解释依据和缺项。
- 帮我核实:按需Search/Fetch,保留原链、来源时间、原文/摘要区别和读取状态。
- 帮我聊明白:整理双方已确认与未确认事项,生成回复草稿;未发送的建议始终与会话消息分开。
现有“1次Search、最多3次Fetch”可以延续为单次主动研究的初始预算。持续发现需要独立调度、去重、账户级限流和来源预算,不能把每个用户、每条帖子的滚动都变成联网研究。
8 当前框架的复用清单
| 资产 | 处理建议 | 理由 |
|---|---|---|
| URL归一化、来源时间、证据快照、失败与截断标记 | 复用契约与经验;代码逐项查清来源 | 从新闻迁移为可追溯的需求依据 |
| DSH Search/Fetch桥接、请求预算、阶段记录 | 迁移适配后延续 | 新旧Provider配置存在明确兼容变化 |
| 安全Markdown、受控报告预览、原链打开 | 通用自写部分经来源确认后复用 | 适合研究资料与公开内容,但仍需社交内容权限 |
| Vue3与Tauri、Capacitor经验 | 复用基础能力和壳思路 | 社交界面、账号和推送需新设计,桌面后台不再是全球服务中心 |
| BettaFish Query/Report与Forum方法 | 研究参考;授权明确后作为可替换组件 | 不承担社交关系、每条消息翻译或需求真实性判断 |
| WorldMonitor地图、来源健康与公开采购模式 | 优先借鉴设计,复制代码另评许可 | 上游前端体系不同,官方Pro接口有权限边界 |
| 中国省份地图、房地产关键词与热榜公式 | 保留在原应用,新产品重新建模 | 不能作为全球需求或意向模型 |
| SQLite通用对象库、双线程队列、PIN会话 | 留作旧原型 | 多用户权限、消息可靠性和服务连续运行需要新后端 |
| 身份、关注、评论、连接、私信、翻译、通知、举报屏蔽 | 新开发 | 三个项目均不能直接提供该产品完整社交核心 |
9 分阶段决策和实施建议
| 阶段 | 交付 | 继续投入的判断依据 |
|---|---|---|
| 当前设计评审 | 产品定位、三张界面概念、Logo、运行框架与许可边界 | 确定首期人群、语言、社交形态及品牌方向 |
| 人工验证 | 一批自愿参与的真实需求与能力卡,由人工协助双向介绍 | 是否有人愿意公开表达需求,双方是否愿意围绕具体机会交流 |
| 核心MVP | 账号、需求/能力与动态、关注评论、连接请求、双语会话、基本匹配解释 | 完成发布、匹配、同意交流、澄清和反馈的闭环,消息及权限可靠 |
| 研究与外部发现 | 官方DSH迁移适配、按需取证、可替换研判、少量获准外部来源 | 外部线索能带来有用上下文,来源、延迟、失败和费用可解释 |
| 扩大场景 | 更多行业/语言、组织协作、平台通知与更深匹配 | 有稳定供需密度和质量反馈,再投入更复杂的推荐与运营 |
人工验证可先邀请约20个需求方和30个能力提供者,组织10次双方同意的项目介绍。这些数值是实验建议,不是已有用户、订单或市场规模。有效对话定义为双方接受联系且至少完成一次与需求有关的实质澄清。
观察有效对话率、首次实质回复时间、需求方确认的解决状态、翻译纠错和误解、屏蔽举报率,以及每次有效连接的研究/翻译成本。需求未解决不等于平台无效,项目周期需单独记录;抓取联系人数量、浏览量与模型热度不作为首期成功指标。
首期不包含支付托管、跨境履约承诺、自动报价、自动群发、全行业全平台抓取和语音同传。基础发布、关注和双向交流应先形成价值;研究额度或团队工作区的付费方式等有真实使用反馈后再决定。
10 本轮评审需要决定的事项
- 是否采用“全球需求社交网络”的主线,以及创客/小团队作为首期切口;也可改为软件服务或另一明确行业。
- 是否采用神灯与对话气泡的品牌方向,以及白底信息流和双语会话的视觉结构。
- 首期先中英,还是同时把西语纳入质量与成本验证。
- 新业务核心独立建设、研究组件可替换的路线,是否符合商业化预期;逐组件许可需要在复制代码前澄清。
本轮仅创建设计分支和设计材料。原BettaFish应用、phase1_lab框架、安装包、模型配置与外部DSH/WorldMonitor仓库均未在本轮改动或升级。原有phase1_lab在Git中仍是未跟踪内容,本轮设计提交不会将其运行时、安装资源或用户数据一并归档。
11 工作台主题与阅读层级
发现页按用户提供的黑金稿组织。桌面横向导航,手机保留底部导航。首屏依次为徽标、神灯地球插画、机会搜索、快捷入口及简短机会列表。列表优先显示已有明确采购标的的真实记录,分别标记用户需求、能力卡、在招公告和历史采购证据。地图可从摘要直接跳转,图例、数据来源和详情仍贴近地图。研究、基建、收藏和复核等桌面工作页使用同色侧栏。
工作台与独立证据复核页共用主题。默认以炭黑承载内容,暖白用于文字,黄铜金用于主要动作、导航和细分隔线。地图保留有区分度的数据颜色。暖浅色与跟随系统仍可在「外观」切换。界面徽标使用用户提供的 logo.png,首屏插画另用透明资源。产品组件、表单和弹窗使用同一套主题变量。
使用项目内的 Impeccable 4.8.0 检查界面,并在 1440 像素桌面和 390 像素窄屏验证主题切换、地图、首屏搜索与来源详情。窄屏验收来自桌面浏览器视口。 Impeccable 项目