type
Post
status
Published
date
Mar 28, 2026
slug
summary
tags
产品设计
category
行业观察
icon
password
Property
Mar 27, 2026 10:24 PM
文章来源
背景
阿里云百炼很像大模型领域的比亚迪——技术能力强、性价比极高，模型能力和价格都在国内第一梯队，是实打实的"卷王"。但就像早期的比亚迪，技术领先却被吐槽内饰粗糙、交互体验跟不上，百炼目前也面临同样的问题：东西都有，但产品体验和信息架构没有跟上技术实力。 实在让人痛心疾首，呜呼哀哉。
比亚迪后来请了奔驰设计总监艾格，把设计语言理顺后销量直接起飞。百炼的底子比大多数竞品都好，缺的不是功能，而是一次信息架构层面的"艾格式"梳理——把已有的能力用更合理的方式组织和呈现出来。
本文从 Web 信息架构、AI 编程场景、多层次用户需求三个角度，提出系统性建议。
一、核心建议
核心建议一：建立清晰的三层产品架构
现状问题
目前阿里云的 AI 产品存在分层不清、边界模糊的问题。用户面对千问、百炼、阿里云控制台三个入口，不知道该去哪里、从哪里开始。
具体表现为：
- 千问（tongyi.ai）是独立的对话产品，和百炼平台没有打通
- 百炼平台首页不是对话界面，开发者进来要自己找模型体验入口
- 百炼同时承载了 API 开发者和模型调优/部署用户的需求，两头都不够深入
- 阿里云控制台的计费、资源管理和百炼的关系不够直观
为什么这是核心矛盾
AI 产品的用户天然分为三个层次，每一层的需求和技术水平完全不同：
用户层次 | 典型用户 | 核心需求 | 技术水平 |
第一层：尝鲜者 | 普通用户、非技术人员、初次接触 AI 的人 | 打开就能用，零门槛对话 | 无需技术背景 |
第二层：API 开发者 | 程序员、AI 编程用户、创业团队 | 调 API、看文档、管理 Key、调参测试 | 有开发能力 |
第三层：深度用户 | 企业客户、ML 工程师 | 模型微调、私有化部署、购买云资源 | 专业技术团队 |
这三层用户应该有清晰对应的产品入口和使用路径：
用户层次 | 对应产品 | 核心页面 |
尝鲜者 | 千问 | 对话页面，打开即用 |
API 开发者 | 百炼平台 | 对话 + API 配置 + 文档 |
深度用户 | 阿里云控制台 | 模型调优、部署、资源管理 |
竞品参考：Google AI Studio 的做法
Google AI Studio 用一个 Playground 页面，通过渐进式披露同时覆盖了前两层用户：
- 默认状态（服务尝鲜者）：输入框 + 模板卡片，任何人打开就能对话
- 右侧面板展开（服务开发者）：模型切换、Temperature、Thinking level、联网搜索/代码执行等工具开关
- Get code 按钮：试完直接导出可运行的 API 调用代码，从体验到开发的转化路径极短
一个页面、不同深度。新手不会被吓到，开发者不需要跳转。
建议方案
1. 千问页面：对标 Google AI Studio，做渐进式 Playground
千问目前的对话页面已有基础（输入框、能力标签、联网搜索等），但缺少开发者侧的配置能力。建议：
- 保持默认简洁：用户进来就是干净的对话界面，和现在一样
- 增加可展开的配置面板：模型选择、Temperature、Thinking level 等参数调节
- 增加 "获取代码" 按钮：用户在 Playground 试完效果后，一键导出 Python/Node.js/curl 的 API 调用代码
- API Key 直接可见：在配置面板显示当前用户的 Key（或引导创建），而不是让用户去别的页面找
这样千问就从一个"聊天工具"升级为"AI 开发者的第一站"。
2. 百炼平台：首页默认就是千问的对话页面
这是最关键的改动。百炼作为开发者平台，首页不应该是一个需要用户自己找入口的仪表盘，而应该：
- 默认展示千问对话界面（可以是嵌入或同构），让开发者进来第一件事就是试模型
- 顶部/侧边导航逐步展开更多能力：API 文档、模型广场、应用管理、计费等
- 主线清晰：试模型 → 拿代码 → 看文档 → 部署应用，这是开发者的自然动线
而不是现在的：进百炼 → 看到一堆入口 → 不知道先点哪个 → 找模型广场 → 找体验入口 → 试完 → 去文档页 → 找代码示例。
3. 阿里云控制台：只承载基础设施需求
阿里云控制台专门负责服务器、域名购买、企业级资源管理等基础设施操作。如非必要，用户不需要到阿里云去。大模型相关的体验、开发、计费，都应该在千问和百炼内完成。
总结：主线清晰 + 渐进式披露
每一步都是用户主动选择"我要更多"，而不是一上来就把所有复杂性扔给用户。
核心建议二：阿里云能力外露，品牌藏于水下
现状问题
千问、百炼、阿里云控制台目前是三个割裂的产品，各自有独立的账号体系、充值入口和使用门槛。用户想充个钱要跳转到阿里云控制台，想拿 API Key 也要去阿里云后台，整个过程充满了摩擦。
但本质上，这三个产品背后都是同一个阿里云。
核心原则：能力外露，品牌藏水下
阿里云应该把自己的底层能力（计算、计费、账号、API 管理）暴露给千问和百炼使用，但阿里云本身作为基础设施藏在水面之下。用户在千问里充钱、在百炼里管 Key，感受到的是流畅的产品体验，而不是"我又被踢到了另一个系统"。
类比：用户用支付宝付款时，不需要知道背后是网商银行在清算。
阿里云需要外露的三个核心能力
要让千问和百炼在不跳转的情况下提供完整体验，阿里云需要将以下三个核心能力以 API/组件的形式开放给前端产品调用：
核心能力一：账户
目标：用户在千问或百炼页面内完成注册登录，无需跳转阿里云。
环节 | 用户感知 | 后台实际动作 |
注册 | 千问/百炼页面输入手机号，收验证码 | 阿里云后台静默创建关联账号 |
登录 | 手机号 + 验证码，一步完成 | 自动关联阿里云身份 |
进阶 | 想用阿里云其他产品时，用同一手机号登录阿里云控制台 | 账号已存在，无缝衔接 |
用户从头到尾不需要知道阿里云账号的存在，直到他主动想要使用更多阿里云服务。对阿里云而言，每一个千问注册用户都自动成为阿里云用户池的一部分，后续转化为 ECS、OSS 等产品客户的路径已经铺好。
核心能力二：支付
目标：用户在千问或百炼页面内完成充值，资金直接进入阿里云账户。
现状问题：
目前百炼平台模型体验页顶部有一行提示：
"模型体验将会消耗免费额度或产生按量付费账单，费用以实际发生为主（模型部署-算力时长计费模型除外）"
这个设计非常不明智。用户点进来的页面叫"体验"，心智预期就是"免费试试"。但实际上，一旦免费额度用完，系统会在用户没有任何主动确认的情况下自动产生付费账单。用户可能完全不知道自己的免费额度已经耗尽，继续"体验"就在持续扣钱。
一行小字提示不等于用户知情同意。这种"静默扣费"的体验会严重损害用户信任，尤其对于新用户和非技术用户来说，他们甚至可能没注意到那行提示就开始操作了。可以预见，阿里云在这个点上已经或将会收到大量用户投诉。
正确的做法：免费额度耗尽时，应该暂停服务并主动提示，让用户自己选择是否继续付费使用，而不是默默开始计费。
用户完整体验路径（建议方案）：
各阶段的设计要点：
- 免费阶段：新用户注册即获得免费额度，无需关心 API Key，后台自动分配临时凭证，对话直接可用
- 额度耗尽时的分流设计：不是简单的"请充值"，而是给用户选择——可以换个模型继续免费体验（降低流失），也可以充值解锁更多额度（提升转化）。这个设计让用户感到被尊重，而不是被逼付费
- 充值落账：千问里充的钱、百炼里充的钱，都直接进入用户的阿里云账户余额。阿里云作为底层计费系统存在，但用户在前端产品里完成所有操作
- API Key 是主动引导配置，不是自动生成：充值后引导用户自己创建 API Key，并清楚说明其作用（保护账户安全、防止滥用）。让用户理解 API Key 的意义，而不是莫名其妙多了一串字符
- API Key 的使用不靠复制粘贴：当用户在千问或百炼中需要使用自己的 API Key 时，系统直接展示用户名下所有的 Key 供选择，下拉搜索即可，不需要去别的页面复制再粘贴回来
核心能力三：统计
目标：用户在千问或百炼页面内直接查看用量和花费明细，不跳转阿里云控制台。
这是体验提升非常明显的能力——让用户对自己的花费一目了然。
现状问题：
目前阿里云支持以"项目"维度统计开支，但粒度不够细。用户知道某个项目花了多少钱，但不知道具体哪个 API 调用、在什么时间段、因为什么事情花了多少钱。
建议做法：
- API 级别的费用统计：在每个 API Key 旁边直接显示累计消费金额，用户点击金额即可展开明细
- 时间维度下钻：支持按天/周/月查看某个 API Key 的消费趋势
- 用途维度标记：允许用户给 API Key 打标签（如"实验项目A"、"生产环境"），按标签汇总统计
- 单次调用可追溯：在对话历史或调用日志中，每条记录标注本次调用消耗的 token 数和对应费用
理想体验：
用户不需要打开阿里云控制台、找到费用中心、再筛选百炼产品，才能知道自己花了多少钱。花了多少钱应该和 API Key 在同一个视野里。
为什么值得做：
- 调用数据、token 消耗、计费数据在阿里云后台已经存在，具备数据基础
- 用户对费用的透明度感知，直接影响信任和续费意愿
- 费用可视化做得好，能显著降低用户因"不知道钱花哪了"产生的投诉和流失
三个核心能力如何支撑前端体验
有了账户、支付、统计这三个能力的外露，千问和百炼就可以在页面不跳转的情况下完成用户的完整使用闭环：
用户操作 | 调用的核心能力 | 用户感知 |
注册/登录 | 账户 | 手机号一步完成 |
充值 | 支付 | 页面内支付，不跳转 |
创建/管理 API Key | 账户 + 支付 | 充值后引导配置，配置面板内管理 |
查看花了多少钱 | 统计 | 点击 API Key 旁的金额即可查看 |
这个设计的本质
水面上的产品各自独立、体验流畅；水面下是同一套阿里云能力在支撑。用户从免费到付费、从对话到开发、从百炼到阿里云，是一条没有断点的路径。
对阿里云的商业价值：每一个千问用户都是潜在的阿里云客户——注册即沉淀账号，充值即沉淀余额，用户后续需要 ECS、OSS 等服务时，账户和资金都已经在了。
二、关于百炼的具体优化建议
核心诊断
百炼目前最大的问题是从生产者的角度组织信息——想的是"我有哪些东西"，而不是从消费者的角度想"用户要完成什么任务"。
现有的 6 个 Tab（模型、应用、Coding Plan、体验、文档、API 参考）本质上是阿里内部的功能模块目录，不是用户的行动路径。用户不关心你有几个模块，只关心"我怎么用"。
设计原则
- 主线清晰：用户从体验→付费→选模型调API→管理应用的路径不能断
- 渐进式披露：新手看到简洁界面，高级用户展开更多配置
- 吸引优先：进门先闻到食物的香味、看到厨房，而不是锅炉房和管道系统
导航结构总览
基于上面的原则，实在手痒难耐，简单梳理下。现有 6 Tab → 重组为 5 Tab：
Tab 1：体验（默认首页）
定位：所有用户的统一入口，打开就是对话框，零门槛上手。
Tab 2：订阅及费用
定位：用户了解价格、管理套餐、查看账单的统一入口。紧跟体验 Tab，因为用户试完模型最自然的下一个问题就是"多少钱"。有问题要扯皮，直接在这里提交工单。
重要原则：只要是同一个手机号（阿里云账号）下、涉及大模型的付费产品，都应该在这里统一看到费用。包括但不限于：百炼 API 调用、Coding Plan、通义灵码插件、Qoder 等。用户不应该去不同的产品后台分别查账单——一个账号下花的钱，一个地方看清楚。
Tab 3：模型及 API
定位：模型浏览与 API 开发的一站式工作区。选模型、管 Key、查接口文档都在这里。
重点优化（参考火山引擎）：用户在复制接口示例代码时，可以下拉选择自己的 API Key，复制出来的代码直接包含真实 Key，开箱即用。同时标注提示："当前方式仅用于调试，生产环境请将 API Key 保存到配置文件或环境变量中"。
Tab 4：应用
定位：应用管理，保持现有内容不变。
Tab 5：文档
定位：文档问题也很大，但不在此展开。保持现有内容不变，具体建议见下方补充建议章节。
右上角附属区（精简）
现有 7 项（阿里云logo、费用、服务、华北2-北京、默认业务空间、设置、主账号头像）→ 精简为 3 项：
项目 | 说明 |
阿里云图标 | 点击跳转阿里云控制台，作为生态连接入口 |
业务空间 | 下拉切换项目空间（含地域信息） |
头像 | 下拉展开账号菜单 |
头像下拉菜单：
用户动线
三、补充建议
补充建议一：新手保护模式
笔者算是老司机了，就在 Claude Code 里面接入过百炼 API，半个小时花了 80 块。
而在小红书、B站、知乎上，多处看到很多尝鲜的小白，稀里糊涂就花了大几十、上百，投诉无法解决，然后就开始发帖骂阿里。本质是产品路径没有梳理清楚，颗粒度没有更细。
建议做法
对于新手（首次使用百炼或阿里云的用户），默认开启新手保护模式：
- 默认消费上限 20 元：新用户首次使用，累计消费达到 20 元时自动暂停服务
- 多渠道通知：网页弹窗、API 返回错误提示、短信通知，三管齐下，确保用户知道 20 元额度用完了
- 主动选择继续：用户需要手动关闭新手模式，或开启下一个 20 元额度，才能继续使用
- 不是限制，是保护：这个功能的定位是保护新用户不会在不知情的情况下产生大额账单，而不是限制用户使用
这个功能能直接减少大量用户投诉和负面口碑，对品牌形象的保护价值很高。
补充建议二：引导用户尝试其他大模型
阿里有很多赠送的免费额度，但就我的观察，这一块利用得非常不充分。很多用户只用过一个模型，额度用完就走了，根本不知道还有其他模型的免费额度可以用。
建议做法
当用户某个模型的免费额度用完时，除了引导充值，还应该主动引导尝试其他大模型：
- 体验页面内引导：额度用完时，弹出提示"你还有 XX 模型的免费额度可以体验"，一键切换
- API 报错引导：当 API 返回额度不足的错误时，在错误信息中附带推荐："您还可以免费试用 qwen-turbo / deepseek-v3 等模型，切换模型名称即可"
- 短信/站内信通知："您的 qwen3.5-plus 免费额度已用完，您还有 3 个模型的免费额度未使用，点击查看"
这样做的好处：
- 降低用户流失：不是"没额度了再见"，而是"换一个继续体验"
- 提升模型覆盖率：让更多模型被用户实际试用，产生真实的使用数据和口碑
- 增加付费转化：用户试的模型越多，越有可能找到适合自己场景的模型，从而产生付费意愿
补充建议三：模型推荐的渐进式展开
目前的模型列表，一堆东西铺上去，看得头皮发麻，信息密度又极低。每个模型一张卡片，写几句干瘪的描述，用户根本无法做出选择。
问题本质
模型列表的组织方式还是"生产者视角"——"我有这些模型，你自己看"。但用户的正常思维逻辑是：
- 我要干什么（写代码？画图？翻译？）
- 什么东西能满足我的需求（哪个模型擅长这个？）
- 满足需求的同时，哪个便宜点（同样能干，选性价比高的）
又或者，听别人推荐说某个模型很牛，直接搜索找到它。
建议做法：三层渐进式推荐
第一层：只推荐一个
进入模型目录，默认只展示一个最全能的多模态模型。什么都能干，不用切换就能让用户知道阿里的模型足够强，能满足大部分需求。
第二层：每个能力方向推荐一个最强的
用户想看更多时，按能力方向展开——文本一个、图像一个、语音一个、视频一个。每个方向只推最强的那一个，不要一上来就列一堆。其他的模型，用一行小字引导："需要更快或更便宜的？查看该方向所有模型 →"
第三层：完整列表，按场景和性价比排序
点进去才看到某个方向的所有模型，并且按"场景适用性 + 性价比"排序，而不是按发布时间或字母排序。每个模型标注清楚：擅长什么、每百万 token 多少钱、速度如何。
搜索兜底
对于"听说某个模型很牛，直接来找"的用户，提供搜索功能即可。不需要为这类用户把所有模型铺满页面。
补充建议四：文档结构应避免使用 Tab，改用多章节平铺
现状问题
文档中大量使用 Tab（选项卡）组织内容（如 Python / Node.js / curl 代码示例的切换），导致信息在 Markdown 导出时丢失。
为什么这很重要
当前主流开发者的工具链已经变成：
越来越多的开发者不直接看文档网页，而是：
- 用工具将文档以 Markdown 形式保存到本地项目目录
- 让 AI 智能体直接阅读文档、基于文档编写代码
Tab 组件在网页上看着整洁，但转成 Markdown 后，被折叠的 Tab 内容会丢失，AI 拿到的是残缺信息。
建议做法
将 Tab 内容改为多级标题（## / ###）平铺展示。Markdown 天然支持多章节结构，既适合人阅读，也适合 AI 处理，不会丢失任何信息。
补充建议五：提供文档的直接获取链接，让 AI 可自动拉取
进化路径
当前阿里云文档的 Markdown 支持可以分三步进化：
阶段 | 能力 | 状态 |
第一步 | 复制 Markdown | 已实现 |
第二步 | 下载整个 Markdown 文件 | 待实现 |
第三步 | 提供可被 AI 直接拉取的文档链接 | 待实现 |
类似 GitHub 获取项目的方式——开发者不需要手动打开网页复制，而是给 AI 一个链接，AI 就能自动将文档下载到本地项目中，直接作为上下文使用。
安全方案
这个能力的安全性很容易保障：
- 身份验证：用户填写了阿里云 API Key 即视为有效身份
- 频次限制：对单个 Key 做请求频率限制，防止滥用
- 安全可控：不需要复杂的鉴权体系，API Key + 频次限制已足够
这个能力对开发者体验是质的提升，能让阿里云文档在 AI 编程时代占据先发优势。
补充建议六：把填写 API Key 这一关干掉
API Key 是目前劝退新手最大的门槛之一。复制一串字符、粘贴到配置文件、还要小心不能提交到 GitHub——对非技术用户来说，这一步就足以让他们放弃。
建议做法
借鉴 SSH 登录和 AWS 凭证文件的原理，让用户下载一个凭证文件放到本地，就能直接调用，不需要手动填写任何 Key。
最理想的方案：阿里已经有通义灵码这个 VSCode 插件了，可以直接在插件里加一个功能，或者单独开发一个轻量插件——用户用手机号登录，插件自动把凭证文件下载到本地指定路径，百炼 SDK 自动识别。用户全程不需要知道 API Key 是什么、凭证文件在哪。
这个方案的原理并不新鲜——AWS 的
~/.aws/credentials、GCP 的 service account JSON、阿里云自己的 ~/.aliyun/config.json 都是凭证文件的模式，跑了很多年了。区别在于，传统方式需要用户手动下载和放置文件，而通过插件可以把这一步也干掉，真正做到零门槛。写在最后
写这篇文章的初衷，是真心希望阿里云和百炼能变得更好。毕竟其他家的模型太贵了，烧得肉疼，阿里的性价比是实打实让我们这些开发者受益的。
文中如有用词不当，亦或者受限于个人专业见识、考虑不周之处，敬请谅解。毕竟，还是接触过不少阿里的高手的。
- 作者:Blacksmith
- 链接:https://www.lhuafmaof.cn//article/3302fd79-8cf0-80f5-8467-dd974feb0d0f
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
