Sahara AI（中文版）
从复杂的 AI 基础设施，到可理解、可扩展的 AI 产品生态
Design Lead · Product Strategy · Product Design · AI UX · Developer Experience · Design System · Brand · Design Leadership
项目概述
我设计的不是一个 AI 产品，而是一套 AI 产品生态
Sahara AI 从早期的 AI / Data 产品逐渐扩展为连接 数据贡献者、开发者、AI Assets、用户与区块链基础设施 的完整生态。
在我参与的阶段，产品逐渐形成：
Data Services → Developer Platform → AI Assets → AI Marketplace → Blockchain
开发者可以使用平台提供的工具和数据创建 AI Assets；数据贡献者通过数据采集、标注和验证参与 AI 开发；用户则可以发现、使用和获取 AI Assets。
Blockchain 则作为底层基础设施，为资产的归属、贡献、授权、交易和价值分配提供可验证的记录。
因此，设计问题已经不再是：
How do we design an AI product?
而变成：
How do we turn a technically complex AI ecosystem into a coherent, understandable and scalable product experience?
我的工作也从单一产品设计，逐渐扩展到：
Product Strategy → Product Design → Design System → Brand → Design Leadership
背景：一个复杂的 AI 生态是如何运转的？
从「使用 AI」到「参与 AI」
Sahara 的核心逻辑不是简单地让用户使用 AI，而是建立一个完整的 AI 价值循环：
Knowledge / Data 👉 Data Services 👉 Developer 👉 Dataset / Model / Agent 👉 AI Marketplace 👉 User 👉 Usage / Value 👉 Contributor / Developer
在这个系统中，不同角色承担不同任务：
Knowledge Provider
贡献数据、知识、标注和专业能力。
Developer
利用数据、模型和开发工具创建 AI Assets。
User
发现、使用、购买或授权 AI Assets。
Sahara Blockchain
记录关键的资产归属、贡献、交易和价值关系。
Sahara 的 Data Services Platform 本身就是为了让非开发者也能参与 AI 数据生产，并通过数据采集、标注、审核等方式获得奖励；官方称这些贡献会被记录在 Sahara Blockchain 上。
我的核心设计挑战
随着产品从单一工具发展成生态，我识别出三个核心问题。
问题一：产品越来越多，但用户感受到的是“一个个孤立的工具”
不同产品处于不同的发展阶段，导致：
Information Architecture 不一致
Navigation 不一致
Components 不一致
Interaction Patterns 不一致
Visual Language 不一致
用户从 Data Services 进入 Developer Platform，再进入 Marketplace 时，很难感受到自己仍然处于同一个生态。
我的设计问题
如何建立统一的生态体验，同时又不强迫不同产品使用完全相同的交互方式？
问题二：复杂度：问题不是减少，而是管理
Sahara 所涉及的对象越来越复杂：
AI · Data · Model · Agent · API · Asset · Project · Task · Contributor · License · Blockchain
这些复杂度并不能简单删除，因为它们本身就是产品能力。
所以我的判断是：
优秀的复杂产品设计，不是消灭复杂度，而是控制复杂度出现的时机。
因此我把设计重点从：
How do we remove complexity?
转向：
How do we make complexity understandable?
问题三：技术应该隐藏，价值应该被看见
Blockchain 是 Sahara 产品的重要底层能力。
但普通用户并不真正关心：
Smart Contract
Hash
Gas
Transaction
Blockchain Architecture
用户真正关心的是：
我的贡献是什么？我的资产属于谁？数据从哪里来？我的贡献有没有被记录？谁在使用？我是否可以获得价值？
因此我提出一个核心设计原则：
Design blockchain without designing for blockchain.
也就是：
不让用户学习 Blockchain，而是让 Blockchain 帮助用户建立信任。
这也是 Sahara AI 设计中最重要的产品思考之一。
Sahara 后续公开的 SIWA Testnet 也进一步验证了这一产品方向：通过区块链记录 AI 数据的 ownership 和 provenance，并逐步引入 licensing 与 revenue distribution。
项目一：AI Marketplace
设计一个 AI Asset Economy
传统 Marketplace 解决的是：
Find → Compare → Buy
但 Sahara Marketplace 交易的不是普通商品，而是：
Dataset · Model · Agent
而一个 AI Asset 的价值可能来自多个角色：
Knowledge Provider
↓
Data
↓
Developer
↓
Model
↓
Agent
↓
User因此我认为 Marketplace 真正需要解决的问题不是：
“如何让用户购买一个 AI 产品？”
而是：
“如何让用户理解 People × AI Assets × Ownership × License × Value 之间的关系？”
官方 Marketplace 目前也明确将 Dataset、Model、Agent 作为核心资产类别，并围绕 license、ownership、creator、My Assets、购买和后续 monetization 建立产品机制。
Marketplace 的产品思考：从「商品信息」重新定义为「资产信息」
我将 AI Asset 的信息结构理解为：
Asset Identity
↓
Creator / Contributor
↓
Data / Model / Agent
↓
Ownership
↓
License
↓
Usage
↓
Transaction
↓
ValueMarketplace 不再只是一个“卖 AI 的地方”，而是 AI Asset 生命周期的一部分。
设计重点：把 Blockchain 转化成 Trust
我没有让用户看到复杂的链上结构，而是将底层能力转化成用户能够理解的产品信息：
Ownership 谁拥有？
Attribution 谁贡献？
Provenance 从哪里来？
Verification 是否经过验证？
License 可以怎么用？
Transaction 发生了什么交易？
因此：
Blockchain 是底层技术，Trust 才是用户体验。
这也是我在 Sahara 中反复使用的设计方法：
把技术能力转换成用户价值，而不是直接把技术暴露给用户。
项目二：AI Developer Platform
从 Developer Tool 到 Creator Platform
传统 Developer Portal 通常解决：
Documentation → API → Integration
但 Sahara 的 Developer Platform 面对的是一个更大的问题：
开发者为什么要在 Sahara 上创建 AI？
如果平台只帮助开发者使用 API，那么产品价值停留在：
Infrastructure
但如果平台能够帮助开发者：
Discover → Build → Create → Release → Distribute → Capture Value
那么它就成为：
AI Creation Layer
策略：重新设计 Developer Journey
我将开发者的核心任务拆解成：
01 Discover 找到数据、模型、工具。
↓
02 Build 组合能力，开始创建。
↓
03 Test 验证 AI 是否达到目标。
↓
04 Create 形成 Dataset / Model / Agent。
↓
05 Release 完成注册、配置和发布。
↓
06 Distribute 进入 Marketplace。
↓
07 Capture Value 通过使用、授权和交易产生价值。
目前对 AI Developer Platform 的定位也已经包含 Agent 创建、Dataset / Model 管理、License、协作、部署以及未来 Marketplace monetization 等能力。
不让用户理解底层架构
Sahara 的底层技术可以拆成：
Application Layer
Sahara Agent · Sahara Toolkits · AI Marketplace · Sahara ID
Transaction Layer
Sahara Blockchain
Data Layer
Data Storage · Data Access
Execution Layer
AI Execution Protocols · AI Execution Abstraction
核心设计原则
我把产品设计从：
Infrastructure-driven
转向：
Intent-driven
用户不应该思考：
“我需要调用哪一个 infrastructure？”
而应该思考：
“我想做什么？”
然后让系统在背后处理：
Data → Model → API → Execution → Blockchain
这就是我在 Developer Platform 中最重要的设计原则：
Design around user intent, not infrastructure architecture.
项目三：Data Services Platform
为复杂的企业级数据生产系统设计体验
Data Services 与 Marketplace、Developer Platform 最大的区别是：
它不是一个单用户产品。
而是一个：
Multi-role + Workflow-driven Platform
一个数据项目可能同时涉及：
Project Owner
Data Requester
Contributor
Reviewer
QA
Admin
所有人使用同一个系统，但每个人的目标完全不同。
用户需求分析
Contributor
我最关心：
我要做什么？
做完了吗？
我的数据是否通过？
我获得了什么奖励？
Reviewer
我最关心：
哪些数据需要审核？
数据质量怎么样？
哪些需要重新处理？
Project Owner
我最关心：
项目进度怎么样？
数据质量怎么样？
Contributor 表现怎么样？
最终数据什么时候可以交付？
因此：
One Platform ≠ One Experience
底层系统可以统一。
但：
Navigation、Information、Actions、Dashboard 必须围绕角色重新组织。
让系统状态变得可见
在复杂工作流中，用户最容易产生的不安全感是：
“我现在到底在哪里？”
因此我重点设计了：
Current Status
Progress
Ownership
Dependencies
Next Action
Data State
让系统从：
“一个复杂的后台”
变成：
“一个可以被理解的工作流程”。
项目四：UI Design System
从统一视觉，到支持产品规模化
随着 Sahara 产品不断扩展，Marketplace、Developer Platform、Data Services 等产品需要保持统一的品牌体验，同时满足不同场景的交互需求。
Challenge
产品之间 UI / Interaction 不一致
重复设计和开发
新产品难以快速复用
AI 产品出现大量新的状态和交互
Approach
我建立了从 Foundation → Components → Patterns 的 Design System：
Foundation
Typography · Color · Spacing · Grid
↓
Components
Button · Input · Card · Table · Navigation
↓
Product Patterns
Onboarding · Asset Management · Workflow · AI Interaction
同时通过 Design Tokens + Component Rules 建立 Design 与 Engineering 的统一语言。
Impact
Unified — 建立跨产品统一的视觉与交互语言
Reusable — 提升组件和设计模式复用
Scalable — 支持产品持续扩展
Efficient — 降低重复设计与开发成本
项目五：Brand × Product
用户对产品的认知，不从打开产品开始
Brand 与 Product 不能完全割裂。
我参与建立从：
Brand Awareness → Product Understanding → Product Adoption
的连续体验。
UI包含：
Branding包括：
Website
Product Launch
Campaign
Landing Page
Social Media
Product Storytelling
Visual Identity
Design Leadership
从“设计页面”到“设计产品”
随着团队扩大，我带领 8 人设计团队，支持：
Product · Platform · Brand · Marketing
我的工作重点逐渐从：
What screens do we need to design?
转向：
Why are we building this product?
我推动团队在设计之前回答：
Problem 我们解决什么问题？
User 为谁解决？
Value 为什么这个问题值得解决？
Logic 产品逻辑是否成立？
Scalability 未来能不能扩展？
Experience 用户是否真正理解？
项目结果
这一部分我建议你一定要放真实数据，而且区分“业务结果”和“设计结果”。
不要写成：
“我让用户增长了 300%”
除非这个数据确实由你的设计直接导致。
更专业的方式是：
Business Scale
Sahara Data Services Platform 在私有测试阶段：
3.8M+
Whitelist Signups
200K
Active Participants
8M+
High-quality Data Points
92–95%
Data Accuracy
这些是 Sahara 官方在 Data Services Platform 公开上线时披露的数据。官方称前三个 Season 共获得超过 800 万个通过质量审核的数据点，准确率达到 92–95%。
此外，在 SIWA Public Testnet 发布时，Sahara 官方披露私有测试网已有：
3.2M+
Accounts with at least one transaction
1.4M+
Daily Active Accounts
200K+
Data Services Users
这些数据非常适合放在 Case Study 前半部分，用来说明：
我设计的不是一个概念型产品，而是一个真实面对大规模用户、多角色和复杂业务流程的 AI 产品生态。
更进一步的业务验证
Sahara 的 Data Services 后续已经被用于真实的企业级 AI 项目。
Sahara 的数据服务已经支持 MIT 的计算机使用 Agent 训练项目，贡献者网络达到：
200,000+
预审核贡献者
35+
国家
45+
语言与方言
并通过多层 QA 对数据进行验证。
这进一步证明 Data Services 不只是一个“用户赚积分的平台”，而是逐渐成为：
AI Data Infrastructure
最终成果
我参与建立的是一个连接起来的 AI 产品系统
Products
AI Marketplace
发现、使用、授权 AI Assets
Developer Platform
创建、部署 AI
Data Services
贡献、生产和验证 AI Data
Infrastructure
Blockchain
Record · Verify · Attribute · Trace
Design System
Shared Language · Patterns · Infrastructure
Brand
Website · Campaign · Launch · Social · Storytelling
Organization
8-person Design Team
Direction · Quality · Collaboration · Product Thinking
最终总结
把复杂系统，转化为简单体验
Sahara AI 的设计挑战，从来不是简单地设计一个漂亮的 AI 产品。
真正困难的是：
如何让用户理解一个复杂的 AI + Data + Blockchain 系统，并让不同角色在其中完成自己的任务。
我的解决方式始终围绕三个层面：
01 / Understand Complexity
先理解业务、技术、用户和整个生态的关系。
02 / Simplify Complexity
不是删除复杂能力，而是通过：
Information Architecture · User Journey · Progressive Disclosure · Intent-driven Design
让复杂度在正确的时机出现。
03 / Build for Scale
通过：
Design System · Product Patterns · Cross-product Principles
让解决方案可以跨产品、跨角色和跨业务持续复用。
最终，我希望设计解决的不只是：
“这个页面应该长什么样？”
而是：
“这个产品为什么存在？用户真正需要什么？我们如何把复杂的业务和技术转化成简单、清晰、可扩展的体验？”