企业官网建设流程全解析

这两年做AI应用，我最大的感受是：真正卡住项目的往往不是模型能力本身，而是怎么把模型“可靠地装进业务里”那一段路。开发环节跑通一个对话Demo很快，难的是后面模型选型、成本核算、知识库效果、线上稳定性这一整套事情。阿里云百炼这个平台，从名字就能看出它的定位——不是单纯卖模型API，而是想把模型开发、调试、知识库、工作流编排、应用发布这一整条链路都收进去。它面向的人群也很明确：既要快速验证大模型Demo，又想把应用真正推到生产环境的开发者和小团队。

这篇手册不打算复述官方文档，而是从我实际使用百炼的经验出发，围绕三个主题展开：第一，模型怎么选，不同场景该用通义千问家族的哪个型号；第二，新人免费额度怎么领、怎么用，以及里面藏着的计费陷阱；第三，从Demo到生产落地，你会遇到哪些稳定性、成本和效果问题。文章里的步骤和代码都是我在模拟项目X中实际跑过的，你可以直接参考着操作。

1. 平台定位与入门准备

1.1 百炼到底解决什么问题

先用一句话说明白百炼是干什么的。它本质上是一个大模型应用开发平台，底座是通义千问系列模型，上面长出了一整套应用开发工具。你可以把它理解成“模型中间件”：不用自己部署模型，不用处理GPU资源，也不用从零搭向量数据库和Agent框架，百炼把这些基础设施都包了，你只需要专注业务逻辑。

我最早接触百炼是因为一个跨平台系统的需求——要给企业内部工具加一个智能问答入口。当时对比了几条技术路线：自己部署开源模型、直接调各家模型API、用平台型产品。自己部署开源模型看起来省调用费，但GPU成本和运维成本很快就超过了API调用费，而且效果调优投入巨大。直接调裸API又太“裸”了，知识库要自己处理文档切片和向量化，工具调用要自己写协议，整个开发周期拉得很长。

百炼这种平台型产品恰好卡在中间。它解决了我在实际项目中遇到的四类问题：

• 模型接入问题：基于通义千问多个版本的模型，提供统一的API入口，不用为不同模型维护不同调用代码。
• 知识库问题：内置文档解析、切片、向量化、检索能力，做一个带私有知识库的问答应用，基本不用自己写RAG代码。
• 应用编排问题：工作流画布可以编排“大模型+工具调用+条件分支”，能处理简单的Agent场景。
• 上线交付问题：调试好的应用可以发布成API，直接给前端或业务系统调用。

所以百炼适合的人群很清晰：想快速做出AI应用、又不想陷入底层模型运维的开发者；需要在公司内部快速验证大模型场景的团队；以及预算有限、希望在控制成本前提下把应用跑起来的个人开发者。

1.2 新人免费额度怎么领

这是最多人关心的问题。百炼的新人免费额度不是注册阿里云账号就自动到账的，需要先开通百炼服务。整个流程大概是这样：

第一步，注册并登录阿里云账号。这一步要求实名认证，个人认证或企业认证都可以。企业认证的好处是后续如果涉及发票、对公付款比较方便，个人开发者用个人认证就够了。

第二步，进入百炼控制台，找到“开通服务”之类的入口，点击开通。开通过程不需要付费，属于“开通后按量计费”的模式，但新用户会有赠送额度。

第三步，开通之后，在模型广场里能看到各个模型上标注的“免费额度”。这里要提醒一下：免费额度是按照“每个模型”单独计算的，不是说一个总额度所有模型通用。常见的形态是每个模型赠送一定数量的token，比如百万token级别的体验额度，有效期通常几个月，过期作废。

我自己的经验是，开通后先在控制台的费用相关页面确认两件事：一是赠送额度具体落在哪些模型上，二是赠送额度的有效期截止日。不要等到月底对账才发现，某个模型超额了，另一个模型赠送额度一点没用——这种“偏科”情况在团队项目里很常见。

还有一个特别容易踩的坑：免费额度和按量计费是并存的。也就是说，如果某个模型有免费额度，用完后会自动转为按量计费，可能你还在测试阶段，费用就已经在产生了。新手建议开通“消费额度预警”，或者在项目早期只使用有赠送额度的模型，不要急着绑定支付方式。当然，如果你确认要长期用，绑定支付方式是必须的，到时候重点就不是“怎么不花钱”，而是“怎么把钱花在刀刃上”了。

1.3 首次进控制台应该完成的三件事

拿到百炼控制台权限后，我建议先别急着调模型，花十分钟完成三件基础配置，后面能省很多麻烦。

第一件事，创建API-KEY。百炼的API调用统一使用密钥鉴权。在控制台找到API-KEY管理页面，创建一个Key，把它复制保存好。这个Key只在创建时完整显示一次，后续在控制台只能看到脱敏后的信息，所以创建完立刻存到密码管理器里。千万不要把Key提交到Git仓库或者写死在前后端代码里，这一点再怎么强调都不过分。

第二件事，熟悉模型广场。百炼的模型广场展示所有可用模型，包括通义千问系列、开源模型版本、多模态模型、专有领域模型等。每个模型页面上一般会有“体验”按钮，可以直接对话测试效果；也有模型名称、上下文长度、计费单价等关键信息。这里就是做模型选型的第一现场，我在第2章会展开讲。

第三件事，设置预算与消费预警。在费用中心找到预算管理或消费预警，设置一个阈值。个人开发者的阈值可以设低一点，比如每月50元；团队项目根据预算来。这类设置属于“一次配置，长期受益”，因为百炼的免费额度用完后的按量计费速度，比你想象中快。

另外建议顺手开启日志或调用记录。百炼控制台会记录API调用日志，包含请求时间、模型、输入输出token数等。这个日志在生产环境排障时非常有用，早期就开始积累调用数据，后面做成本分析和效果评测就有依据了。

2. 模型选型：别一上来就用最贵的

2.1 通义千问模型矩阵速览

百炼上最常用的模型是通义千问家族，版本很多，新人很容易看晕。我按自己的理解给你拆一下。

• qwen-turbo：主打低延迟、低成本。日常闲聊、意图识别、信息抽取、简单问答这类任务完全够用。响应速度快，适合高并发、对成本敏感的调用场景。
• qwen-plus：综合能力更强，各项表现均衡，上下文理解、复杂指令跟随、结构化输出都比turbo好一截。我的经验里，绝大多数生产环境场景，plus是性价比最优的选择。
• qwen-max：通义千问能力最强的版本，数学、推理、复杂语义理解、长文本生成都有明显优势。适合对回答质量要求极高、且调用量可控的场景。价格也最高，不要全场都用它。
• qwen-long：面向超长文本设计，上下文窗口很大，适合一次性分析多份文档、超长对话、历史记录压缩等场景。普通模型处理不了的长文本，交给它就行。
• 开源版本：如qwen2.5系列的不同尺寸版本，可以在百炼上以托管模型的方式调用，也可以下载到自己的环境部署。适合有数据合规要求、需要完全掌控模型或做私有化部署的场景。

除了文本模型，百炼上还有视觉模型（qwen-vl系列）、语音模型（qwen-audio系列）、数学和代码专项模型。这些在需要处理图片、音频或生成代码时再考虑，日常文本应用不需要。

2.2 不同场景的选型逻辑

模型选型没有绝对标准，但有一套比较通用的决策顺序：先看任务类型，再看性能要求，再算成本账，最后用真实测试数据说话。

先看任务类型。如果你的场景是高并发的客服问答、文本分类、信息抽取，这类任务难度不高但调用量大，优先考虑qwen-turbo甚至更小的模型，因为每一轮调用省下来的钱都是利润。如果是内容生成、复杂分析、报告撰写这类对结果质量敏感的任务，qwen-plus是起点，效果不够再上qwen-max。

再看性能与成本平衡。我做过一个模拟项目X，是一个类似“智能文档问答助手”的应用。最初全部用qwen-max跑，效果确实好，但成本完全压不住，调用一次长文档问答要消耗大量token，团队每天测试几十次，额度肉眼可见往下掉。后来我们把策略调整为：普通问答走qwen-plus，只有长文档总结和复杂推理走qwen-max，整体成本降了六成以上，用户感知的质量差别很小。

还要提醒一个场景：长上下文任务千万不要用普通模型硬撑。曾经我把一份几万字的合同丢给qwen-plus做分析，结果要么超出上下文长度限制，要么模型“忘记”了前面内容。换成qwen-long之后再也没出现过这个问题。面向不同任务选不同工具，才是正确的省钱思路。

如果你是做Agent或工作流应用，选型还要考虑工具调用能力。通义千问近几个版本的模型对function calling的支持都比较成熟，但仍然建议在选型阶段用你自己的工具函数集跑一遍，看看模型能不能正确理解工具描述、生成合法参数。不同模型在同一组工具上的表现差异，有时比单项分数更能说明问题。

2.3 选型对比表与成本意识

我整理了一个快速参考表，基本覆盖文本类应用的常见选型需求：

关于成本，有几个最基础的认知必须建立。第一，大模型API按token计费，而token不是按“字数”算的，是模型对文本的切分单位。中文字符和token的大致比例需要实测，同一个字符串在不同模型上的token消耗可能不一样。第二，输入和输出token是分开计价的，通常输入价格低于输出。也就是说，你要在应用里尽量减少输出长度，比如让模型只输出结构化JSON而不是长篇大论，省的钱非常可观。第三，上下文越长，每次调用的基础成本越高，因为你每次请求都会把历史消息全部算进去。长对话场景，要么做消息裁剪，要么引入向量检索只塞相关片段，不能一股脑把整段历史都丢给模型。

这些成本意识，在模型选型阶段就要建立起来。不要只看模型单价，要看你的具体调用模式下，一个请求平均花费多少钱。

3. 核心开发能力与实操步骤

3.1 三种接入方式怎么选

百炼提供了不止一种调用方式，我实际用过三种，各有各的适用场景。

第一种是控制台在线体验。不需要写代码，在模型广场选一个模型直接对话。适合选型阶段做效果对比，快速验证某个模型能不能完成特定任务。我经常用它在开会时临时演示，或者给不懂技术的业务同事看效果。

第二种是DashScope原生SDK。支持Python、Java等主流语言，功能最完整，与百炼平台的集成度最高。适合正式项目中按百炼生态的方式深度使用，比如要用到知识库、工作流等平台能力时，原生SDK对接最顺畅。

第三种是OpenAI兼容模式。百炼提供了一个兼容OpenAI接口格式的访问地址和协议，也就是说，你原来写OpenAI SDK的代码，只需要改一下base_url和api_key，就能换成通义千问模型。这个设计对老项目迁移非常友好，我接手过一个原本基于OpenAI接口的项目，迁移到百炼大概只花了半天。如果你的项目已经用了OpenAI的SDK，优先走这条路，改动最小。

简单总结：控制台在线体验用于选型，原生SDK用于新项目深度集成，OpenAI兼容模式用于存量项目迁移。

3.2 第一次API调用跑通

选好模型之后，第一件事就是跑通一次API调用。我以Python为例，演示最简洁的流程。

安装SDK：

pip install dashscope

然后写一个最小调用：

import dashscope from dashscope import Generation dashscope.api_key = "sk-xxxxxxxx" resp = Generation.call( model="qwen-plus", prompt="你好，请用一句话介绍一下你自己。", ) print(resp.status_code) print(resp.output["text"])

这个例子跑通之后，你就有了一条可用的模型调用通道。走OpenAI兼容模式的代码也不复杂：

from openai import OpenAI client = OpenAI( api_key="sk-xxxxxxxx", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", ) completion = client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": "请用三句话解释什么是RAG。"}, ], temperature=0.3, ) print(completion.choices[0].message.content)

有几个参数在第一次调用时就要养成习惯。temperature控制随机性，做客服、问答等确定性优先的场景，建议设置成0.3或更低；做创意写作再调高。max_tokens限制最大输出长度，防止模型偶尔“话痨”导致费用飙升。系统提示词（system message）放在messages列表的第一条，用来固定模型身份和输出规则，这是生产级应用和随手Demo的核心区别之一。

3.3 知识库与RAG应用搭建

光会调模型API，做不出有业务价值的应用。因为模型不知道你的内部资料、产品文档、历史工单，而这些恰恰是问答应用的核心资产。RAG（检索增强生成）是解决这个问题的标准方案，百炼把它做成了平台能力。

在百炼控制台的“知识库”功能里，大致流程是这样：

1. 创建知识库，填入名称和描述。
2. 上传文档，支持PDF、Word、TXT、Markdown等常见格式。
3. 系统自动完成文档解析、清洗、切片、向量化。这一步通常不需要人工介入，但你可以调整切片参数，比如最大分段长度、分段重叠长度。
4. 等文档状态变成“就绪”，知识库就建好了。

接下来把知识库挂到应用上。创建一个应用，选择“知识库检索增强”模式，关联刚才建好的知识库，然后测试问答效果。这里有几个参数会直接影响效果，需要重点调：

• 召回数量（top_k）：每次问答检索几个文档片段。太小了信息不够，太大了无关内容会干扰模型回答。
• 相似度阈值：低于阈值的片段不召回，能过滤掉一批弱相关的噪音。
• 引用来源：生产环境建议开启，让模型回答时附带引用来源，便于查证和追责。
• 仅从知识库回答：如果不希望模型“自由发挥”，可以限制它只能依据知识库内容作答，超出范围就明确拒绝。

我在模拟项目X里跑知识库问答时踩过一个坑：刚开始把切片长度设得很大，想“一段多放点内容”，结果检索回来的片段互相之间有重复和逻辑断层，模型回答反而变乱。后来把切片长度调短一些，同时提高top_k，让模型综合多个精确片段作答，效果明显改善。RAG的调优本质上是“切多大、取多少、怎么拼”这三件事之间的平衡。

3.4 工作流与工具调用

知识库解决的是“让模型知道该说什么”，工具调用解决的是“让模型能做事”。比如让模型查询天气、查询数据库、调用内部接口，这些动作靠模型自己做不到，需要通过function calling机制把外部工具接进去。

百炼的工作流画布把这类编排变成了可视化操作。你可以创建一个大模型节点，定义Prompt模板；再挂一个工具节点，指向某个HTTP接口；然后用条件分支控制逻辑走向，比如当模型判断需要查库时走工具调用分支，否则直接回答。完成之后，整个工作流可以发布成API，像调用一个普通接口一样被外部系统调用。

框架层面，function calling的通用流程是：你先把“有哪些工具、每个工具的入参是什么”描述给模型，模型在回答时如果认为需要调用工具，就返回一个结构化的调用请求；你的代码收到请求后真正执行这个工具的调用，把结果送回给模型，由模型基于工具结果生成最终回复。

百炼在这一块降低了门槛。遇到简单场景，直接在控制台配工作流就行；遇到复杂场景，也可以通过SDK在代码里手动管理工具调用循环。我建议初学者两种都试一下。先在工作流里把业务逻辑跑通，再阅读底层API文档理解每一步发生了什么。只停留在可视化界面，出了问题会不知道去哪排查；只写代码不看工作流，又会错过平台已经帮你封装好的能力。

4. 生产落地：稳定、成本与效果

4.1 稳定性保障：限流、超时、重试与降级

Demo能跑通和线上能扛住是两码事。大模型API的调用模式和传统接口不一样：单次调用耗时更长，token消耗更大，而且外部API的可用性不在你的控制范围内。所以生产环境必须做好四件事：超时控制、重试策略、并发限制、降级方案。

超时控制是第一步。我记得第一次上线模拟项目X时，没设置超时时间，结果某个模型偶发变慢，前端请求挂了一分多钟，用户在页面上等得直接关掉了。后来统一设置了30秒超时，并且把超时后的错误提示改成“答案生成中，请稍后重试”，体验才算正常。

重试策略要讲究，不能用暴力重试。模型服务偶发失败是正常的，但持续重试会加重服务端压力，甚至触发限流。推荐指数退避策略：第一次失败等1秒再试，第二次等2秒，第三次等4秒，最多重试三次。

降级方案是我强烈建议每一个生产应用都准备的东西。你的主模型可能因为限流、故障、配额耗尽等原因不可用，这时候需要一个备用模型顶上。百炼上最简单实用的降级策略是：主模型用qwen-max，降级到qwen-plus；或者主模型用qwen-plus，降级到qwen-turbo。效果会差一点，但服务不会中断。线上宁可给用户一个稍差的答案，也不能给用户一个白屏。

4.2 成本控制三板斧

生产环境的大模型成本增长，往往比业务增长更早到来。我在第2章说过选型本身省钱，这里再讲三层更具体的控制手段。

第一板斧是模型分层。把应用里的所有调用场景列出来，按“对回答质量的敏感程度”和“调用频率”分成不同层级。高频低难度场景固定走便宜模型，低频高要求场景才走贵模型。这需要你在代码里把模型名做成可配置项，而不是到处硬编码。

第二板斧是上下文瘦身。大模型按token计费，上下文里的每一个字都要算钱。长对话系统里，历史消息不可能无限累积，一定要做裁剪。我常用的策略是：只保留最近的几轮对话，更早的对话做摘要压缩，当摘要本身也很长时，只保留摘要中的要点。另一个技巧是，凡是能从知识库里检索到的内容，就不要在历史消息里反复存，用检索命中片段替换掉之前的长文本。

第三板斧是缓存与预算预警。重复的问题不要每次都调模型。比如“这个产品的退款政策是什么”这种高频问题，完全可以把同一个问题的标准答案缓存起来，命中缓存就直接返回，只有未命中时才调用模型。百炼控制台和阿里云费用中心都支持消费预警，把月预算阈值设好，一旦接近阈值立刻收到通知。别等账单出来再喊“怎么花了这么多”，预警能给你足够的时间做策略调整。

4.3 效果评测与调优

模型的效果不是一锤定音的，上线前测试没问题，不代表上线后用户怎么问都没问题。我做项目时养成了一个习惯：准备一套固定的评测集，每次改动Prompt或切换模型，都拿同一套问题去跑，对比输出质量。

评测集不需要很大，二三十条就够用。关键是覆盖你的核心业务场景和容易出错的边界情况。比如问答应用至少包含：正常业务问题、复杂多跳问题、知识库内问题、知识库外问题、诱导性问题。每条问题记录模型回答是否准确、是否完整、是否符合格式要求。

有了评测集，调优就有据可依。反复出现的badcase不要靠感觉改Prompt，先把失败案例聚成几类再做针对性优化。比如某类问题总是回答不完整，就在Prompt里加“请分条回答，并给出具体结论”；某类问题总是编造知识库没有的内容，就加强“仅依据知识库作答，不确定时明确说不知道”的约束。

还有一类效果问题跟模型没关系，是检索侧出了问题。模型回答核心依赖知识库的召回结果，如果召回的内容压根不对，Prompt写得再好也没用。检查方法是在控制台的调试日志里看实际召回了哪些文档片段，如果召回片段和问题明显不相关，问题出在切片参数或相似度阈值，而不是模型。

4.4 安全与合规：内容安全与数据授权

大模型应用上线，安全合规这一关绕不过去。百炼本身提供内容安全检测能力，可以在应用配置里开启，用于拦截输入或输出内容中的风险信息。个人开发者和企业内部应用都建议开启，一方面是合规需要，另一方面也能防止你的应用被恶意输入利用。

数据层面，涉及敏感数据时要注意授权问题。如果你的知识库包含客户隐私、内部经营数据，先确认使用平台服务是否满足你的数据管理要求。百炼也提供私有化部署方案，把模型部署在客户自己的环境中，适用于严格的合规场景，但成本会比调用公共API高不少，需要团队有模型运维能力。选不选私有化，本质上是“合规风险成本”和“模型运维成本”之间的权衡。

还有一条容易被忽略：你上传到知识库的文档，要确保有合法使用权。尤其是从公开渠道抓取或第三方购买的资料，版权风险不会因为上传到AI平台而消失。这部分合规工作，建议在项目立项时就让法务或管理方介入，不要等应用火了再处理。

5. 常见问题与排查技巧实录

5.1 高频错误码与处理思路

线上跑久了，一定会遇到各种调用异常。我遇到过的问题里，这几种最高频：

遇到错误码，第一件事建议去控制台的调用日志里查request_id。百炼的日志会记录每次调用的详细信息，拿着request_id能最快速地定位问题。另外，把日志和错误信息串联起来看，本质上和排查传统接口问题没有区别，只是把“数据库报错”换成了“模型服务报错”。

5.2 免费额度与计费相关疑问

免费额度相关的疑问非常多，我把最常见的几个问题集中回答一下。

第一个问题：免费额度为什么不见了？大概率是过期了。百炼赠送额度通常有有效期，过期自动清零，不管你有没有用完。上线前建议把这些“不花钱”的额度充分利用起来做充分的Prompt调试，不要浪费在无效测试上。

第二个问题：免费额度抵扣顺序是怎么样的？每个模型赠送额度只对应该模型自身调用，不同模型之间不能混用。而且如果你同时绑定了支付方式，系统会优先抵扣赠送额度还是按量计费，不同时间可能不一样，不要凭记忆猜，去控制台的费用页面看明细。

第三个问题：免费额度用完了怎么办？两种选择：一是充值转按量计费，适合正式生产环境；二是换一个还有赠送额度的模型继续体验测试。如果只是测效果，我建议优先用后者，等到确认了模型选型、准备上线时再正式充值。

5.3 生产上线的最终检查清单

最后给一张我每次上线百炼应用都会过一遍的检查清单，新手照着核一遍，能避免很多低级问题：

• API-KEY已放到环境变量或密钥管理平台，没有硬编码在代码仓库里。
• 每条调用都有超时设置和重试机制，重试采用指数退避。
• 已配置备用模型，主模型异常时能自动降级。
• 预算预警已开启，月消费阈值已设置。
• 应用已开启内容安全检测。
• 日志记录完整，包括request_id、模型名、输入输出token数、耗时。
• 知识库召回参数已按业务调优，关键场景有评测记录。
• 上线前用评测集跑了一遍全量回归，确认切换模型或修改Prompt后没有效果回退。
• 免费额度有效期已确认，正式收费路径已在费用中心做了解。

这张清单看起来琐碎，但每一条背后都有真实踩坑的代价。我第一次上线时缺了“备用模型”这一项，主模型因为限流停了近两小时，业务侧直接中断，那次之后我把清单补全了，后面再没出过同类事故。

还有一个个人习惯分享给你。每次给新的百炼应用定模型前，我会先拿业务里最难的那几个问题，让候选模型各跑一遍，把回答并排放在一起对比，而不是只看参数和价格表。模型能力是不是适合你的场景，跑一次真实业务问题比看十篇评测文章都管用。这个习惯帮我避开了不少“看起来很强、落地却不行”的模型陷阱，也让我每次选型的底气更足。