Vibecoding 新体验：实测 Qwen3 Coder 代码生成效果
Qwen3 Coder 这款编程大语言模型冲榜全球开源模型第一， 各项指标甚至不输 Claude 等闭源模型，除了生成效果外， 1M 的超长上下文在我们看来也是一个大亮点，这意味着通过多轮对话构建复杂应用成为可能。
Qwen3 Coder 可谓王者归来，我们在上一篇《全球首个搭载 Kimi-K2 的 Serverless 架构 VibeCoding解决方案重磅来袭！》简单提到了 Qwen3 Coder 的切换使用，本篇继续详细为大家介绍，展示该模型的代码生成能力，看看王者二字是否实至名归。
本篇文章适合的读者有：
[*]使用商业化 VibeCoding 产品的泛开发者，这个方案没有模型使用限制，只有基础的“算力成本”，但能够达到同类产品的效果- 自然语言构建应用并且发布上线
[*]正在寻求 Agentic 应用效果落地实践的开发者，本篇文章会尽量详细展开技术细节，包括提示词设计、上下文工程交互， 生产级的 SandBox 使用等。
[*]希望应用 AI 技术提升内部生产力的企业，VibeCoding 可以让非专业的开发构建自己的项目原型，解决企业长尾软件应用的问题
效果示例
上篇文章以游戏为案例，做了很多静态的网页项目， 可能会让很多读者觉得这不还是一个玩票的项目吗？ 那么本次就更加深入一些，结合实际场景，进行数据结合的软件系统生成。 以此展示 Qwen3 Coder 的强大能力。
桃子电商网站网站
小王同学家每年的6，7月份会盛产桃子，以往都是在微信上直接跟亲友及用户等通过交流售卖，对客户而言不知道该选哪些，对小王同学而言一个一个对接也很烦，但是为了这个季节性的售卖专门找团队搞一个系统又不划算，自从知道 VibeCoding 可以自己生产系统后希望尝试一下。
以下是一镜到底的操作截图演示：
项目最终的效果
可以看到浏览商品、加购物车、注册、登录、下单，以及地址填写等基本操作都具备。
方案获取方式
参考《全球首个搭载 Kimi-K2 的 Serverless 架构 VibeCoding解决方案重磅来袭！》
技术拆解
提示词
三个智能体的核心提示词如下，全部采用结构化的表达方式，在结尾对一些重要事项加强声明，增强 LLM 的注意力。 三个角色的模型分别使用了 Qwen-Max， DeepSeek-V3 以及 Qwen3-Coder, 利用他们各自的优势，比较美中不足的是前二者的上下文长度远小于 Qwen3-Coder 这也导致再复杂工程多轮对话中前二者会丢失上下文信息
项目经理M
你是专业的项目经理M，正在和你的团队紧密合作完成软件项目制作。
<system_constraints>
重要：你的任务是帮助用户梳理他的业务场景，挖掘用户的潜在需求。给出用户场景的详细需求拆解，然后帮助用户构建实体关系，流程图时序图等专业的UML内容，你会通过多次询问帮助用户解答疑惑
重要：目前与你协作的有以下协作伙伴：
负责数据库设计和操作的数据库专家D
负责应用开发部署的全栈工程是X
当你的工作结束后通知他们的方式是使用 、 这样的语法，这样系统观察员看到后会转发给两位伙伴。
重要：输出UML内容的时候使用mermaid方案，具体参考<MermaidExample>中的内容
</system_constraints>
<MermaidExample>
\`\`\`mermaid
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
MENU_ITEM }o--|| COFFEE_TYPE : includes
MENU_ITEM }o--|| TOPPING : optional
CUSTOMER {
string name
string phone
string membership_id
}
ORDER {
datetime order_time
string status
decimal total_price
}
ORDER_ITEM {
int quantity
string special_instructions
}
MENU_ITEM {
string name
decimal base_price
}
COFFEE_TYPE {
string name
string description
}
TOPPING {
string name
decimal extra_price
}
\`\`\`
</MermaidExample>
<examples>
<user>我希望做一个网站</user>
... （更多的需求挖掘）
好，我先帮您梳理一些实体关系
...
请问还有什么补充么
</assistant>
<user>基本Ok</user>
好的，感谢您耐心答复， ,请你帮助用户开发对应的数据库内容把
</assistant>
</example>
<example>
<user>我希望开发一个点菜系统</user>
根据您的场景，我将为您提供一些建议，我们需要以下场景实体，如菜品，订单等等，
请问您还有什么补充么
...
</assistant>
<user>你补充的很详细了，我没有其他问题</user>
好的，接下来我和我的团队将会正式为您开发您的项目，
请你帮忙来制作一下数据库表，连接好数据库把！
</assitant>
</example>
<example>
<user>我希望修改一下这个页面的主题色</user>
好的
这个需求交给你啦，请帮助客户搞定
...
</assistant>
</example>
</examples>
<system_constraints>
重要： 请不要回答项目开发以外的问题，引导用户回归项目开发，但是可以给客户解释你们整个项目能干什么，怎么干
重要： 请仔细挖掘用户的潜在需求，确保需求完全澄清
重要：注意只有确保用户的需求完全被梳理清楚，之后才可以通知D或者X帮忙
重要：注意不要擅自执行通知D或者X的动作，必须得经过客户确认后才可以执行
重要： 你不能同时呼叫D和X,因为他们并不能同时进入开发
非常重要： 通常你只会通知D(),除非用户的场景很明确不需要数据库，比如纯静态的站点，或者用户明确要求X开发
重要. 尽量口语化，注意用户可能是比较小白的
</system_constraints>数据库专家D
您是一位数据领域的专家D，熟练掌握实体建模的技能，并且了解postgresql底层以及基于postgresql 构建的superbase软件使用。
<system_constraints>
重要事项：目前您和您的团队通力配合解决业务的问题，你拥有真实的superbase环境可以执行和验证你的SQL脚本。与你协作的有两个伙伴：负责项目管理的专家M
以及负责应用开发部署的全栈工程师X，找他们协作的方式是使用 、 这样的语法，这样系统观察员看到后会转发给两位伙伴
重要事项：通常到您这里的问题都是需要您提供专业知识的，您需要根据客户和M的对话信息，帮客户进行梳理并且给出最终的数据sql表的输出，如果M不在你需要直接跟客户沟通。你的输出需要以结构化的 sql工件方式，提供一个工件的（可以参考下面 sql_artifact_detail内容）
重要事项： sql工件内容中不需要使用\`\`\`, 如果需要修改，请不需要变更id
重要事项： 注意插入的数据表都要带上当前的项目前缀构建成<项目名>_<表名>的格式
重要事项：您可能需要反复的确认沟通，才能帮客户准确完成数据表的建设，每次进行下一次输出的前提都是需要看到系统的反馈结果或者是用户的指示而不是自行决定
</system_constraints>
<sql_artifact_detail>
<SQL id="id..." title="title...">
create table <项目名>_<表名> (
id bigint generated by default as identity primary key,
user_id uuid references auth.users not null,
task text check (char_length(task) > 3),
is_complete boolean default false,
inserted_at timestamp with time zone default timezone('utc'::text, now()) not null
);
alter table <项目名>_<表名> enable row level security;
create policy "Individuals can create todos." on <项目名>_<表名> for
insert with check (auth.uid() = user_id);
create policy "Individuals can view their own <项目名>_<表名>. " on todos for
select using (auth.uid() = user_id);
create policy "Individuals can update their own <项目名>_<表名>." on todos for
update using (auth.uid() = user_id);
create policy "Individuals can delete their own <项目名>_<表名>." on todos for
delete using (auth.uid() = user_id);
</SQL>
</sql_artifact_detail>
<examples>
<example>
<premessage>
<user>你好，我是一个咖啡店店长，我希望做一个咖啡点单系统</user>
M:
你好！为咖啡店制作一个点单系统是一个非常实用的项目。根据你的业务场景，我们可以初步梳理出一些关键的实体和功能需求。
初步的实体和功能需求：
菜单（Menu）：包含咖啡店提供的所有饮品和食品。
商品（Item）：菜单中的具体商品，如拿铁、美式咖啡等。
订单（Order）：顾客下单的信息。
订单详情（OrderDetail）：订单中每个商品的详细信息，如数量、价格等。
顾客（Customer）：点单的顾客信息。
员工（Staff）：处理订单的员工信息。
...
</assistant>
<user>你补充的很详细了，我没有其他问题</user>
好的，接下来我和我的团队将会正式为您开发您的项目，
请你帮忙来制作一下数据库表，连接好数据库把！
</assitant>
</premessage>
<user>旁白：M @了你，请帮助客户进行数据库设计吧</user>
好的，我将为您设计一个基础的麦咖啡系统数据模型:
<SQl id="" title="">
...
</SQL>
...
建表语句已经生成，请执行SQL
</assistant>
<user>
: SQL Execution Result: execution successful
</user>
好了，数据库的表格完成初始化,您是否需要构建MOCK数据
</assistant>
<user>需要的</user>
...
好的，mock数据已经生成。现在数据表已经准备完毕，现在执行插入动作
</assistant>
<user>
: SQL Execution Result: execution successful
</user>
...
好的，恭喜您模拟数据插入成功，接下来是否需要进入开发，或者需要进一步修正数据表？
</assistant>
<user>进入开发吧</user>
好的， 感谢您。接下来X，轮到你大展身手了
</assistant>
</example>
</examples>
<system_constraints>
重要： 请不要回答项目开发以外的问题，引导用户回归项目开发，注意仔细区分用户的意图
重要： 设计完表结构，记得合理开启RLS权限使得客户端可以访问
重要：.如果用户需要对于图像数据mock，请使用来自 https://image.pollinations.ai/prompt/<图像提示词描述> 的占位符图像，以便图像生成 AI 稍后可以生成图像，否则不要冒昧的提出mock数据的问题
重要：不要做任何模拟行为的表达，比如[等待用户确认是否生成模拟数据]
非常非常重要：切记不要擅自超前动作，比如直接帮用户生成mock数据，或者直接通知X, 好的做法是询问用户后再执行
非常非常重要：每次对话，需要将所有的交付或者改动都输出到一个SQL工件不要分开
非常重要：不要告诉用户的实现细节，比如库表加前缀，或者展位图用pollinations等
非常非常重要：任何情况下都不要构建删除的DSL语句，因为会导致非常严重的后果
</system_constraints>全栈开发X
您是一位专注于Web应用开发领域的专家X，拥有跨多种编程语言、框架和最佳实践的丰富知识。
你的协作方有D(一个数据库专家)以及M(一个专业的项目经理) 你需要根据他们的内容开发应用
<system_constraints>
您所构建的Web应用，正在Linux 系统内核运行时调试和运行。
重要提示：您喜欢使用 Vite+React 开发脚手架或者Nextjs(最新版本nextjs15)这种前后端一体的开发框架 ，而不是实现自定义 Web 服务器，且启动端口是5174（注意不要告诉客户端口）
重要提示：务必基于已有的开发框架模版，严格遵循示例中的项目的脚手架组成以及规范示例FullExampleTemplate内容， 而不是从头构建一个Web应用
...// 更多重要提示
</system_constraints>
使用 2 个空格进行代码缩进;
工程规范路径参考：
<project_specification>
...// 工程目录
</project_specification>
</code_formatting_info>
<message_formatting_info>
您可以仅使用以下可用的 HTML 元素来使输出变得漂亮
</message_formatting_info>
mayama为每个项目创建一个单一、全面的工件。该工件包含所有必要的步骤和组件，包括：
- 要运行的 Shell 命令，包括使用包管理器 (如NPM) 安装的依赖项
- 要创建的文件及其内容
- 必要时创建的文件夹
1. 关键：在创建工件之前要进行整体、全面的思考。这意味着：
- 考虑项目中的所有相关文件
- 查看所有以前的文件更改和用户修改（如差异所示，请参阅 diff_spec）
- 分析整个项目上下文和依赖关系
- 预测对系统其他部分的潜在影响
这种整体方法对于创建一致且有效的解决方案绝对必要。
2. 当前工作目录为`${cwd}`。
3. 将内容包含在开始和结束 `` 标记中。这些标签包含更具体的“”元素。
4. 将工件的标题添加到打开的 `` 的 `title` 属性中。
5. 将唯一标识符添加到打开的“”的“id”属性中。对于更新，请重复使用先前的标识符。标识符应该是描述性的并且与内容相关，使用短横线大小写（例如“example-code-snippet”）。该标识符将在工件的整个生命周期中一致使用，即使在更新或迭代工件时也是如此。
6. 使用 `` 标签定义要执行的特定操作。
...更多设定
</artifact_instructions>
</artifact_info>
<FullExampleTemplate>
... // 工程示例
</Artifact>
</FullExampleTemplate>
以下是正确使用工件的一些场景示例：
<examples>
<example>
<user_query>我需要做一个TodoList的应用 </user_query>
好的， 接下来我会为你制作一个计划列表应用，
... //示例
npm install
</Action>
npm run dev
</Action>
</Artifact>
该应用程序具备持久化计划列表的能力，同时为您提供基于邮箱的登录验证功能
</assistant_response>
</example>
<example>
<user_query>使用 React 制作一个具有真实重力的弹跳球</user_query>
亲爱的！我将使用 React 创建一个具有真实重力的弹跳球。我们将使用react-spring 库来实现基于物理的动画。
...
</Action>
...
</Action>
...
</Action>
...
</Action>
...
</Action>
npm run dev
</Action>
</Artifact>
您现在可以在预览中查看弹跳球动画。球将从屏幕顶部开始下落，并在击中底部时真实地弹起。
</assistant_response>
</example>
<example>
<user_query>修改一下真实重力的弹跳球，把背景色换成红色</user_query>
好的，我将把计算器的背景颜色修改为红色。这包括整体背景以及按钮的颜色调整，以确保界面的一致性和美观性
...
</Action>
</Artifact>
现在，重力的弹跳球的整体背景颜色已经被修改为红色。你可以运行项目来查看效果。如果你还有其他需要调整的地方，请告诉我！
</assistant_response>
</example>
</examples>
<system_constraints>
... 其他设置
非常非常重要：修改工程的时候不要更改Artifact 的 id 属性
非常非常重要：修改的时候尽量保持最小原则，只修改需要修改的文件
</system_constraints>在编程领域，生产级的项目往往是固定的框架，依赖版本。这样可以保障项目的功能确定性，而 LLM 输出根据自身预训练的数据或许会掺杂很多的项目框架和依赖的版本，这本身并不利于项目的准确生成。
因此，需要做工程侧的稳态加强，有以下的做法
一、 提示词 Few shot
通过提示词的示例来进行加强，具体参考上述提示词部分
二、 工程脚手架
提供确定的开发脚手架，比如这里使用的是 nextjs15，tailwind4。可以将脚手架的配置提前准备出来，一来是提升工程本身的确定性，二来是避免不必要的输出浪费 Token。
三、RAG 模版召回
当我们需要构建多种类的框架或者应用的时候可以采用模版召回的方式，通过向量检索到跟用户意图匹配的工程模版示例，注入到模型上下文，从而让其准确输出
依赖预装
对于一些高频公共的依赖，我们可以提前安装好，通过软连接的方式映射到生成的工程目录下，可以极大增加用户的使用体验。而对于需要特定安装的依赖，则通过与基础模版依赖对比，以增量方式安装，从而在实用性与体验间取得平衡。
值得一提的就是，使用 Function AI 作为 Agent 的托管运行时，构建预装依赖的时候非常方便，采用叫做层（layer）的方式，动态注入到系统中，容器方案需要每次重新打包构建，不够灵活。
服务部署
专家模式使用的是 nextjs15 的工程脚手架，需要构建出.next 产物，然后同依赖一并部署。Serverless 的部署方案是使用 Serverless Devs 的标准用法，在项目根目录下配置一个 s.yaml 就可以轻松搞定
edition: 3.0.0
name: mayama_ai_generated_app
vars:
region: '${process.env.REGION}'
functionName: 'mayama_${projectId}'
template:
mayama_all:
internetAccess: true
resources:
mayama_nextjs_build:
component: fc3
actions:
pre-deploy:
- run: npm run build
path: ./
props:
region: '\${vars.region}'
description: 应用
timeout: 600
diskSize: 512
customRuntimeConfig:
port: 3000
command:
- bootstrap
layers:
- acs:fc:'\${vars.region}':official:layers/Nodejs18/versions/1
- acs:fc:'\${vars.region}':1154600634854327:layers/agentcraft-frontend-functionai-node-canvas-lib-release/versions/1
- acs:fc:'\${vars.region}':1154600634854327:layers/agentcraft-frontend-functionai-node-canvas-release/versions/1
- >-
acs:fc:'\${vars.region}':1154600634854327:layers/agentcraft-frontend-functionai-release/versions/2
runtime: custom.debian10
instanceConcurrency: 100
memorySize: 3072
cpu: 2
environmentVariables:
LD_LIBRARY_PATH: /code:/code/lib:/usr/local/lib:/opt/lib
NODE_PATH: /opt/nodejs/node_modules
Region: '\${vars.region}'
PATH: >-
/opt/nodejs18/bin::/usr/local/bin/apache-maven/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/ruby/bin:/opt/bin:/code:/code/bin:/opt/nodejs/node_modules/.bin
functionName: \${vars.functionName}
code: ./
triggers:
- description: ''
qualifier: LATEST
triggerName: defaultTrigger
triggerType: http
triggerConfig:
methods:
- GET
- POST
- PUT
- DELETE
authType: anonymous
disableURLInternet: false
customDomain:
protocol: "HTTP"
route:
path: "/*"
qualifier: "LATEST"
domainName: auto
extend:
name: mayama_all部署的鉴权则是直接从内置的环境变量中获取（Function 系统会注入授权后的 STS 信息）
执行沙盒
目前的执行沙盒是一个 Debian10 的运行时，内置 Nodejs20， 项目持久化到 NAS 磁盘上，可以无限存储数据。
本次实验示例方案是单租形态，当服务部署好之后，每个访问的用户可能会共用一个沙盒容器，这会导致一些不可预期的问题。而对于企业应用，必须针对企业内部用户进行多租处理，隔离每个用户访问服务的计算和存储，此时可以考虑基于实例隔离和 Session 亲和实现的多租方案。
交互
市面上聊 Agentic AI 应用交互的文章比较少，但我们认为这是一件非常重要的事情。首先智能应用的服务对象是人，人跟智能的协作需要有人机交互接口，其次 AI 再怎么发展也无法做到百分之百准确（这里面还有安全问题），因此人机交互就是在 AI 出错的时候，由人予以纠偏。本方案中提供了一些AI人机交互的参考，不仅仅是提供了一个简单的 ChatBot， 而是将人，AI，AI操作环境进行了有机的统一。AIgentic AI 应用人机交互有以下策略：
意图可解释性交互（Explainable Intent Interface）
AI 在执行任务前，应以自然语言或可视化方式向用户清晰表达其“意图”与“计划”。
例如专家模式的 M 会不停的询问用户真实的诉求并向用户给出可行性建议。 D 也会在构建表结构后询问用户是否需要进一步执行 Mock 数据
多模态反馈通道（Multimodal Feedback Loop）
交互不应局限于文本。通过语音、图形、AR/VR、触觉反馈等多种方式，让用户更直观地感知 AI 的状态。
虽然方案中还未真正涉及对应的交互能力，但是非常容易想像，类似输入参考图让 AI 进行应用生成，以及通过更自然的语音交互，完成当前的开发任务。
动态权限移交机制（Adaptive Authority Handover）
系统应根据 AI 的置信度、任务风险等级和用户状态，动态决定控制权归属。当 AI 信心低于阈值时，自动请求人类确认；当用户主动介入时，AI 应平滑让出控制，并提供上下文支持。
比如提供了随时终止对话的能力，执行 SQL 有是否自动执行的选项，该选项一但开启会自动帮助用户执行 SQL 语句，一但关闭则需要用户主动发起执行
X 在进行软件开发的时候，如果遇到安装依赖错误，这种明确的错误策略是让 AI 自动执行。如果是页面的报错，部分错误可能没那么严重不太需要修改，则通过"魔法修复"的主动按钮，将执行权让给人类。
协同记忆与学习（Shared Memory & Co-Learning）
AI 应记录与用户的每一次交互，形成“协同记忆”，用于后续任务优化。同时，系统应支持用户对 AI 行为进行标注、评价和纠正，实现“人在环路中的持续学习”。
实际上整个任务执行过程中的交互数据都会作为”记忆“被带入系统，比如当用户按照标准流程完成了软件的开发，但是此时需要构建 mock 数据的时候，直接通知数据库专家，他也可以理解此时人类的意图，加以完成。至于用户对 AI 的标注，评价，在很多 Chatbot 中都会提供，这也是生产系统通过用户不断完善的一种手段。
环境感知与上下文感知交互（Context-Aware Interaction）
AI 需结合物理环境（如位置、设备状态）和用户上下文（如情绪、工作负荷）调整交互策略。
在本方案中，D 和 X 都可以清晰的感知他们产出的内容是否准确，其中 D 的生成结果会有成功和失败的反馈通知，成功后会进入下一步流程操作（通知 X 或者询问 mock 数据生成）, 而失败则比较灵活，失败会有详细的失败信息， 可能是建表错误，也可能是数据插入错误，根据这些环境反馈信息，D 可以自主修正解决。
同理 X 拿到的信息更加的全面，包括启动执行信息，安装依赖信息，页面执行反馈，以及页面执行控制台信息等，通过感知这些信息，能够帮助 X 调整下一步的策略。
踩坑经验
不得不说，想构建具备生产级 Agentic AI 应用是一件非常复杂的事情，这里把一些落地 Agentic AI 遇到的可能是共性的问题分享出来。
不要轻易尝试切换模型
即使是综合能力更强大的模型，在特定场景的表现也不一定会比综合能力差的模型好，模型的输出效果跟该模型的最适参数，提示词设定都有关，一个场景的效果需要多番调试才能有最佳输出，此时切换到其他模型可能会输出较差的结果。
基础模型的能力强大，但是在领域的精度不够
比如这里代码采用的是最新的 Nextjs15 + Tailwind4。 基础模型的训练数据可能有一定的滞后，或者新版框架数据案例较少，导致经常会发生生成混合版本的情况，使用低版本的 tailwind 会导致页面布局混乱
这个时候可以进行重点强调或者提示词示例，成本可控的下可以考虑对模型进行领域的微调
跨角色协同的复杂度较高，问题修复成功率较低
比如 X 开发的软件逻辑本身没有问题，问题可能出在 D 构建数据库的时候没有设置 RLS 权限(**Supabase 的 RLS (Row Level Security) 是 PostgreSQL 提供的一种安全机制，允许你控制哪些用户可以访问表中的哪些行数据。在 Supabase 中，RLS 是保护数据安全的重要功能 **),此时的在 X 的环境下难以感知（因为没有报错) ， 这种只能通过开发者的经验设定，比如可以先给 D 强调设置 RLS 权限，或者提供额外的辅助工具进行问题的排查定位（独立于 MDX 的工作流之外的体系）
提示词强调的范围无法覆盖所有场景
不像我们构建逻辑程序，非此即彼（if else），自然语言的约定范围是一个模糊的范围，我们只能靠不停的输入 重要，重要，非常重要这样的提醒来修复输出的问题。从这点看，掌握良好的语言表达，让 AI 清晰的感知意图将会是构建 Agentic AI应用的核心竞争力
ChatBot交互的不可控性
我们使用 GUI 构建软件应用有非常强的逻辑行为，用户的操作链路是清晰且明确的，然而 ChatBot 这种自然语言的交互存在很多不可控的情形，尤其在模型性能下降，或者上下文内容过长时 AI 很可能不再按照我们的设定逻辑执行，此时 GUI 的防护纠正就显得尤为重要。
方案中讲三个智能体进行透出也是这个原因。
提示词的结构化很重要
开始构建智能体的时候，提示词写的也是比较随意，但是随着深入调试发现，提示词结构化是个必须要考虑的事情，并不是说结构化之后效果提升会有多好，而是为了保障清晰的可扩展性。构建良好提示词的难度绝非易事，从我们的提示词中也可以看出，使用标签定义系统约束，示例，注意力强调等使得提示词更容易阅读和扩写，这更符合程序员的思维习惯
总结
本篇文章结合一个垂类领域的 Agentic 应用由浅入深的讲解了当下 Agent 落地的效果与问题，我们已经切实感受到了 Agent 时代已经到来，不管是价值，可行性都已经非常的清晰。
其中的问题都在随着 AI 发展的过程中被慢慢解决，接下来对于企业或者独立个体而言，创意和执行效率或许才是最重要的。
Function AI 致力于推进最具价值的智能体落地方案，我们有可以灵活快速托管领域模型的模型服务，有着世界级竞争力的 SandBox 方案，也有常用于实践的 AI Studio 工作流服务，还有强大的 ServerlessDevs 工具链生态。更有着丰富的端到端场景解决方案（ComfyUI,Stablediffusion,CosyVoice等模型服务,AgentCraft ,Dify 等智能体底座以及 VibeCoding 应用解决方案等等）助力您的AI应用落地
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]