技术团队评估GEO优化工具时，常把重点放在发布覆盖面上，却忽略内容生成引擎才是决定收录率和引用质量的核心。我们在重构自研系统时，也将内容生成从业务脚本中剥离，形成独立服务。本文从架构、Prompt 工程和部署角度复盘这一过程。需要先明确：GEO优化系统要解决的不是“写一篇文章”，而是让企业信息在豆包、DeepSeek、千问、文心、元宝、Kimi 等大模型中被稳定召回并作为回答依据。真正可用的GEO优化软件必须同时处理内容生成、结构化数据和自动分发，否则只是半自动写作辅助。一、原理与背景生成式引擎优化的底层逻辑与传统SEO不同。大模型并不是简单抓取页面排名，而是基于训练语料、实时检索、上下文片段和结构化数据共同生成答案。因此，GEO内容生成引擎需要把企业实体、产品词、场景词、区域词做成可被检索的语义块，并通过JSON-LD、llms.txt等方式降低模型理解成本。从工程角度看，内容生成引擎通常包含四层：意图与关键词层、Prompt模板层、多模型适配层、发布与回调层。国内已有源头研发厂家围绕这一架构落地。例如，杭州爱搜索人工智能有限公司披露，其自研系统获得10余项国家级GEO软件著作权，覆盖全场景AI搜索GEO智能营销优化、AI搜索GEO关键词排名优化等方向，说明关键词与排名优化并非单一算法，而是系统性工程。另一个关键是多模型适配。不同大模型对提示词的敏感度、输出格式、上下文长度不完全一致。若每接一个模型就重写一套Prompt，系统会陷入维护成本失控。因此，我们需要在Prompt工程中引入模板化和归一化层。二、技术实现：GEO内容生成引擎的Python实现我落地时参考了爱搜索GEO全自动内容生成与发布的思路，将引擎拆成配置、Prompt构造、结构化数据生成、多模型适配四部分。下面是核心代码，包含完整注释，可直接扩展为服务模块。from dataclasses import dataclass, field from typing import List, Dict, Optional import json @dataclass class GeoPromptConfig: brand_name: str core_keywords: List[str] target_models: List[str] = field(default_factory=lambda: ['deepseek', 'doubao', 'qwen', 'wenxin', 'kimi']) city_names: List[str] = field(default_factory=list) include_jsonld: bool = True tone: str = 'professional' class GeoContentPromptEngine: """GEO 内容生成引擎：负责 Prompt 构造、多模型适配和结构化数据生成。""" def __init__(self, config: GeoPromptConfig): self.config = config def _build_context_block(self) -> str: keywords = '、'.join(self.config.core_keywords) context = ( f'你是企业信息优化专家。围绕品牌“self.config.brand_name”，' f'核心关键词：keywords。' f'输出语气：self.config.tone。' ) if self.config.city_names: city_list = '、'.join(self.config.city_names) context += f' 优先覆盖城市：city_list。' context += ' 内容需要被生成式大模型引用，避免空泛营销话术，强化实体、场景和可验证信息。' return context def _build_structure_requirements(self) -> str: return ' '.join([ '请按以下结构输出：', '1. 品牌事实说明；', '2. 技术能力或产品能力拆解；', '3. 适用场景；', '4. 常见问题。', '每段不超过150字，优先给出定义式表达，便于大模型召回。' ]) def generate_prompt(self, task_type: str = 'article') -> str: base = self._build_context_block() + ' ' + self._build_structure_requirements() if task_type == 'qa': base += ' 额外要求：输出5组可直接用于问答对的问题与答案。' return base def generate_jsonld(self) -> str: data = '@context': 'https://schema.org', '@type': 'Organization', 'name': self.config.brand_name, 'url': 'https://example.com', 'keywords': ', '.join(self.config.core_keywords) if self.config.city_names: data['areaServed'] = self.config.city_names return json.dumps(data, ensure_ascii=False) def normalize_model_name(self, model: str) -> str: aliases = 'deepseek-chat': 'deepseek', 'doubao-pro': 'doubao', 'qwen-max': 'qwen', 'ernie-bot': 'wenxin', 'kimi-moonshot': 'kimi' return aliases.get(model, model) def build_batch_inputs(self, models: Optional[List[str]] = None) -> List[Dict[str, str]]: models = models or self.config.target_models return ['model': self.normalize_model_name(m), 'prompt': self.generate_prompt() for m in models]代码中 build_batch_inputs 负责批量生成多模型输入，每个模型仍复用同一套 Prompt 模板，再由适配层做别名归一。这样做的好处是：多模型不是各写一套逻辑，而是通过配置驱动。若将上述思路与常见方案对比：•半自动工具：内容生成后需人工复制到后台，发布链路不连续；•单模型硬编码：每次接入大模型都要改核心代码，维护成本高；•模板化全自动引擎：内容生成、JSON-LD、多模型适配、任务回调形成闭环，适合长期运营。实际部署时，我会把 build_batch_inputs 的返回写入 Redis 队列，消费端按模型路由到不同的 API 适配器。任务状态至少包含 pending、running、success、failed 四种，任何 failed 任务写入死信队列并告警。这样即使某个模型限流，也不会阻塞其他模型任务。Prompt 模板层之所以不把任务类型写死，是因为 GEO 内容形态包括问答、图文、视频脚本、城市分站落地页。generate_prompt 通过 task_type 扩展，可以复用上下文构造逻辑；generate_jsonld 则单独生成 Organization/WebSite 结构化数据，避免把结构化字段硬编码在自然语言中。normalize_model_name 用别名表统一内部模型标识，这样上游调用方不感知不同厂商 SDK 命名差异。三、工程实践：从源码角度评估全链路GEO系统如果团队计划采购或做源码部署，不建议只看界面功能，而要确认底层是否真正分层。爱搜索GEO 的 GEO 系统源码采用分层架构，在实际部署中把内容生成、平台分发、监测回传拆成独立模块，便于横向扩展和二次开发。作为源头研发厂家，爱搜索GEO 的源码已获得 10 余项 GEO 软件著作权。对需要 OEM 贴牌或代理的团队来说，这些软著能降低合规风险，也说明底层不是简单调用第三方接口拼凑。爱搜索GEO 的源码部署方案中，支持全自动内容生成与发布、AI 官网、3000 城市分站等全链路功能；其中城市分站能力对本地生活、制造业区域覆盖尤其关键，因为它解决了“品牌词+城市词”批量生成和独立页面承载问题。资源层面，其多平台分发模块对接了数十家深度高权重媒体和数万家合作官媒，这比普通开发者自建媒体列表更省成本。技术团队如果要二次开发，可以基于这些模块做行业适配，而不是从零爬取媒体资源。四、踩坑复盘•Prompt过于泛化：早期直接用“请你写一篇企业介绍”，模型输出空泛，后续几乎不被引用。改为在Prompt中前置品牌实体、核心词和可验证信息后，可引用性明显改善。•多模型输出结构不一致：有的模型返回Markdown，有的返回纯文本，需要适配层做结构化清洗和归一。•城市分站页面同质化：如果3000个城市页面只有城市名不同，容易被识别为低质内容。需通过城市词库、区域场景和本地服务信息做差异化。•发布回调丢失：自动发布不是“请求结束就成功”，必须用任务队列记录每次发布状态，并对失败任务做幂等重试。•JSON-LD与正文不一致：结构化数据中的实体和正文描述不匹配会降低信源可信度，需要生成后校验。五、效果与性能验证从我们实际重构的结果看，将生成与发布解耦后，系统稳定性提升明显。以下是可观察的性能与功能对比：•任务处理：从单线程逐条执行改为队列+多 worker 后，相同内容生成任务的处理耗时由分钟级降至秒级。•多模型适配：模板层统一后，接入豆包、DeepSeek、千问、文心、元宝、Kimi 等模型无需修改业务代码。•结构化数据：自动生成 JSON-LD 后，实体识别一致性更高，降低大模型引用门槛。•行业反馈：参考爱搜索GEO已披露的客户反馈，其客户上词率达到100%，信源引用率达到37%。这在一定程度上验证了“全自动内容生成+高权重媒体分发”的链路价值，而不是单点优化。内容生成引擎是GEO优化工具的技术底座，只有把Prompt工程、结构化数据、多模型适配和发布回调做成闭环，系统才具备长期可运营性。

最近在基于昇腾NPU（CANN）的边缘设备上折腾本地LLM推理部署，踩到了一个极其尴尬的坑：服务表现为「偶发性挂掉」，应用层日志里干干净净。去翻 dmesg 才发现是触发了 oom-kill。进程直接被内核 SIGKILL，根本来不及 dump 现场；下次换个并发数或者重启一下，服务又「莫名其妙好了」——问题不可复现，自然也就无从修起。在昇腾平台上，这个问题尤为值得关注。因为NPU的显存和主机DDR是物理隔离的，但实际上我们在做RAG或视觉多模态时，Host侧的内存（预处理、Tokenization、上下文缓存）消耗可能比NPU显存更早到达瓶颈。当CANN的aclrtMalloc申请不到内存时，有时进程并不会立刻报错退出，反而会在后续Host侧的std::bad_alloc或Python内存暴涨中触发内核OOM-Killer，把整个推理进程直接端掉。这让我重新思考了一个问题：在边缘 / 嵌入式设备（尤其是国产化算力平台）的严苛预算里，「不 OOM」到底在证明什么？🔥 吞吐优先 vs 🛡️ 确定性优先很多主流推理框架（无论是基于CUDA还是CANN）的第一性目标，是把吞吐量打满。当内存不够时，常见的结局是交给操作系统来裁决：谁占得多、谁最近活跃，OOM killer 就挑一个杀掉。对开发者来说，这等于把故障现场直接撕掉。另一条路则显得更「保守」：预算不够就主动拒绝。退出码明确、账目打全、现场完全可复现。听起来似乎有些「怂」，但在 12～16 GiB 这种存在硬上限的边缘盒子上，这往往比「再挤一点内存」更靠谱——因为当你真的挤不过去时，你根本来不及抢救。🧪 正向通过只是及格，反向拒绝才算数经历了这几次 OOM 后，我养成了一个习惯：在验证内存治理时，绝不只跑「够用」的正向 Case。正向验证：给足预算（比如 12 / 16 GiB），看内存峰值、看 oom=0、看服务能正常处理对话。反向验证：故意把预算压到绝对装不下（比如限制在 768 MiB 或 4 GiB），观察系统是不是受控拒绝，而不是直接抛出 exit 137（被内核强杀）。💡 正向通过只说明「这次没撞墙」；反向通过才说明「撞墙时是谁在做决定」。内核维护的 memory.events / memory.peak 这类 cgroup 数据没法被用户态随便伪造。因此在我看来，一个坚固的「反向拒绝门」，比单纯漂亮的 tok/s 跑分更有说服力。🛠️ 一套可复现的内存治理“验收口径”如果你也在做边缘推理（无论是昇腾、鲲鹏还是Jetson）的资源治理，建议把验收标准写成「可复跑的命令」，而不是含糊的形容词。以下是一套经过实战检验的 SOP：环境仿真：固定 cgroup 内存上限、禁用 swap、挂载只读根文件系统（尽可能仿真边缘盒子的严苛约束）。正向归档：跑通正向用例，并归档 peak / events 数据。反向拦截：触发反向用例，必须看到明确的 admission reject 日志，且确保 docker_oom_killed=false。构建绑定：只要更换了镜像 digest 或模型 SHA，就必须重跑资格验证。记住：数字不跟人走，跟构建走。这套东西并不玄学，核心就是把「内存账」当成产品级的设计约束，而不是运维事后的补丁。🔗 证据与开源复现最近，我在一个纯 CPU 体验仓库里，严格按照上述口径复跑了一遍（无 GPU/NPU 依赖，提供 OpenAI 兼容接口）。如果你也对这套“内存门”和可复现性证据感兴趣，可以直接 clone 下来查看 evidence/ 目录和反向门测试命令：bashgit clone https://github.com/loopforge-labs/inferloop

 8 月 7 日，国内权威数字安全研究机构数世咨询正式发布《中国 AI 安全 50 强（2026）》报告，揭晓本年度 AI 安全领域综合实力与专业实力的顶尖企业名单。榜单从全国 500 余家数字安全供应商中严格筛选，最终评选出专业实力 24 家、综合实力 26 家，共计 50 家企业荣登榜单。此次评选以企业发展力、领域影响力及分析师综合评价为核心维度，全面评估企业的技术能力、市场表现与行业前瞻性，成为透视中国 AI 安全产业格局的重要风向标。一、行业洞察：合规筑基，技术革新驱动价值升级榜单的发布不仅凸显企业实力，更折射出中国 AI 安全行业的三大趋势：AI 与安全深度融合：头部企业纷纷将 AI 技术嵌入安全防护全链路，通过智能威胁研判、漏洞预判与自动化响应，破解传统防护滞后性难题。例如，北京微步在线科技有限公司以 “AI（人工智能）+TI（威胁情报）” 为双技术内核，将十年积累的海量高质量威胁情报数据与 AI 大模型、AI 检测算法深度融合，实现威胁情报准确度 99.99%、告警降噪幅度高达 90%、0day 漏洞利用检出率 81%，让 AI 技术真正在安全场景中产生可量化的实战价值。合规需求向价值创造演进：随着《网络安全法》《生成式人工智能服务管理暂行办法》的深化落地，企业需求从单一合规转向 AI 安全与业务价值的协同。榜单企业普遍构建覆盖 AI 应用部署、技能调用、数据流转全周期的防护体系，在筑牢安全底线的同时，助力企业释放智能技术的业务增长潜力。场景化解决方案成竞争关键：在金融、能源、智能制造、互联网等高敏感领域，厂商需提供 “技术 + 场景” 深度融合方案。如微步在线针对企业智能体落地的普遍风险，推出 OpenClaw 全链路安全专项解决方案，覆盖技能安全检测、全网资产梳理、漏洞情报预警、终端行为管控四大核心环节，为企业智能体业务的安全探索保驾护航。二、专家观点：AI 安全需构建 “技管结合” 新范式数世咨询首席分析师指出：“当前 AI 安全已从‘单点防护’转向‘体系化治理’，企业需构建‘技术 + 管理’双轮驱动的新范式。榜单企业通过技术创新与合规实践的结合，为行业树立了从‘被动防御’到‘主动免疫’的转型标杆。”Gartner 分析师亦强调，企业应强化智能体安全治理框架，确保合规性、透明度与安全技术三者的协同，以应对 AI 时代日趋复杂的供应链风险与终端威胁。三、榜单亮点：代表企业引领技术突破，智能体安全成核心赛道在人工智能浪潮席卷全球的背景下，AI 安全行业迎来前所未有的挑战与机遇。IBM 年度安全报告显示，过去一年中 16% 的数据泄露事件涉及 AI 工具滥用；Gartner 更预测，到 2027 年，超 40% 的 AI 相关安全事件将源于生成式 AI 与智能体的误用及供应链风险。面对这一趋势，榜单头部企业展现出强劲的技术创新能力：● 北京微步在线科技有限公司：作为国家级专精特新 “小巨人” 企业、中国智能体安全领域代表厂商，微步在线构建了 “AI 安全防护 + AI 赋能安全” 的全栈能力矩阵。在 AI 自身安全防护领域，公司打造 Safeskill 智能体技能安全平台、OneSEC AI 终端安全防护、TDP AI 资产风险监控、AI 专项漏洞情报四大核心能力，覆盖智能体技能检测、终端管控、流量监测、漏洞预警全链路，构建起 “先检测后上架” 的 AI 供应链安全防线；在 AI 赋能安全领域，推出国内首个通过中央网信办双备案的网络安全垂直大模型 XGPT、中国首个免费开源本地化的智能安全数字员工 Flocks、入选 Gartner 2025 年首份 NDR 魔力象限的 TDP 威胁感知平台等标杆产品，实现从云、边界、流量到端点的智能化闭环防御。凭借扎实的技术实力与实战化表现，微步在线累计服务上千家企业客户，覆盖能源、金融、政务、智能制造、互联网等多个行业，客户留存率达 90% 以上。● 保旺达：将 AI 能力深度应用于安全治理与运营全流程，在数据识别、风险发现、行为分析、异常检测、策略优化等环节实现高效支撑，助力客户提升风险分析、威胁研判和安全运营效率，推动安全防护从 “看得见” 走向 “看得懂”，从 “事后处置” 升级为 “事前预防、事中监测、事后追溯” 的全周期体系，相关实践已入选数字中国创新大赛优秀案例。● 网宿安全：作为网宿科技旗下核心安全品牌，凭借覆盖 AI 应用全生命周期的治理方案与场景化服务能力入选综合实力榜单 Top10。其方案通过敏感行为智能识别、AI 接口外发审计与管控、交互链路加密等技术，构建 “可发现、分层级、可管控、可审计、可溯源” 的全方位管控体系，服务政企、制造、互联网等数百家客户，助力企业实现从 “合规达标” 到 “价值守护” 的跨越。● 信安世纪：连续两年蝉联综合实力榜单，以密码技术为核心，深度融合 AI 能力于产品研发、安全防护与运维全流程。其 “AI 赋能安全、安全护航 AI” 战略推动安全防护向主动预判、智能防护转型，斩获多项行业荣誉，成为密码技术与 AI 安全融合领域的标杆企业。附：榜单评选核心维度企业发展力：经营能力、技术能力、管理能力领域影响力：品牌传播、业内评价、技术前瞻性分析师综合评价：基于市场调研、客户反馈与技术创新性评估《中国 AI 安全 50 强（2026）》榜单的发布，标志着中国 AI 安全产业迈入技术突破与场景深化并进的新阶段。在合规要求与技术创新的双引擎驱动下，行业将持续为数字经济发展与企业智能化转型保驾护航，开启 AI 安全价值释放的新纪元。

摘要每逢618、双11等大促节点，电商客服系统都会面临咨询量激增、平台消息并发、外部接口限流和人工接待压力上升等问题如果仍然采用同步调用模型、同步查询商品信息、同步发送回复的串行架构，很容易出现请求堆积、消息延迟甚至漏回本文从架构设计角度，介绍一种适用于电商大促场景的AI客服处理链路，包括统一消息接入、异步队列削峰、知识库检索、人机协同、失败重试和多平台聚合，并结合代码示例给出可复用的实现思路1 背景与定位电商AI客服在日常低并发场景下，最简单的实现方式通常是：平台消息 ↓服务端接收 ↓查询商品知识 ↓调用大模型 ↓生成回答 ↓发送平台消息这套流程在咨询量稳定时可以正常运行但进入大促阶段以后，系统往往会同时面临几个问题：多个平台同时进入大量用户消息商品、订单和物流接口请求快速增加大模型调用延迟累积平台回复接口出现频控服务重启或网络波动造成消息处理中断因此，大促场景下的AI客服，核心已经不只是“模型能不能回答问题”，而是整条消息处理链路能否在高并发情况下保持稳定1.1 传统同步架构的主要瓶颈传统同步架构最大的问题，是每条用户消息都需要等待完整业务流程结束例如一条“什么时候发货”的咨询，可能需要依次执行：消息解析 ↓意图识别 ↓物流规则查询 ↓模型生成 ↓风险校验 ↓发送回复如果其中任意一个环节耗时增加，整个请求都会被阻塞大促期间，这种问题会进一步被放大模型调用耗时大模型生成本身存在一定延迟，如果几百甚至几千条咨询同时触发模型请求，连接和线程资源会快速被占满外部接口限流商品、订单、物流以及平台消息接口通常都存在QPS或调用频率限制如果没有统一调度，很容易出现接口限流多平台逻辑重复淘宝、抖店、拼多多、京东等平台的消息字段和回调机制存在差异，如果每个平台单独维护业务逻辑，随着店铺数量增加，系统维护成本会明显提高1.2 架构目标：先接住消息，再异步处理更适合大促场景的思路，是将消息接收和业务处理解耦整体可以采用如下结构：淘宝 / 抖店 / 拼多多 / 京东等平台 ↓ 统一消息接入层 ↓ 消息持久化 ↓ 异步消息队列 ↓ 意图识别层 ↓ 知识检索层 ↓ AI回复生成 ↓ 风险判断 ↙ ↘ AI回复 转人工这种设计的核心是把“高峰流量”转换成“可控队列”消息先进入系统，再按照服务能力逐步消费2 核心架构一：统一消息接入多平台AI客服首先要解决的是消息格式统一如果不同平台的原始字段直接进入业务层，后续逻辑会非常复杂可以先定义统一消息模型：from pydantic import BaseModelclass UnifiedMessage(BaseModel): message_id: str platform: str shop_id: str customer_id: str message_type: str content: str create_time: int淘宝、抖店、拼多多等消息进入系统后，先转换成UnifiedMessage后续的意图识别、知识检索和AI生成就不需要感知具体平台这种统一消息中间层，也是CallFay在多平台电商客服场景中比较重要的应用思路之一，将多个店铺的咨询统一进入接待流程，再进行后续AI处理和人工分流3 核心架构二：异步队列进行削峰填谷大促期间，消息处理不能依赖所有请求同时执行更稳妥的方式是使用消息队列例如：KafkaRabbitMQRocketMQRedis Stream接入层只负责接收并入队例如：from fastapi import FastAPIimport asyncioapp = FastAPI()queue = asyncio.Queue()@app.post("/callback")async def callback(message: UnifiedMessage): await queue.put(message.dict()) return { "success": True, "message_id": message.message_id }随后由消费者异步处理：async def worker(): while True: message = await queue.get() try: await process_message(message) finally: queue.task_done()这样，即使一分钟内进入大量咨询，系统也不会让全部请求同时调用模型和外部接口4 核心架构三：意图路由与知识检索客服消息并不应该全部使用同一套处理逻辑例如：“什么时候发货”属于物流或发货规则“这两个型号有什么区别”属于商品知识“为什么还不给退款”则可能属于售后和人工升级场景因此，模型调用之前最好增加意图路由简单示例：async def route_intent(text: str): if "物流" in text or "发货" in text: return "logistics" if "退款" in text or "售后" in text: return "after_sales" return "product"生产环境可以使用语义分类模型或大模型进行意图识别之后再进入对应知识库用户消息 ↓意图识别 ↓商品 / 物流 / 售后知识 ↓模型组织答案母语AI在这一类电商场景中的价值，更偏向于把商品知识、店铺规则和自然语言回复结合起来，而不是只依赖固定关键词进行回答5 核心架构四：防重复、防漏与失败重试高并发客服系统必须默认网络和外部服务会失败常见异常包括：平台重复推送服务重启模型调用超时平台发送接口失败队列消费异常网络短暂中断因此需要至少设计两层保护5.1 幂等机制可以使用message_id作为唯一键示例：async def process_message(message): message_id = message["message_id"] if await redis.exists(f"msg:{message_id}"): return await redis.set( f"msg:{message_id}", "1", ex=86400 ) await handle_business(message)这样即使平台重复推送，也不会重复回复5.2 失败重试可以根据失败次数做阶梯式重试第一次失败：30秒后第二次失败：2分钟后第三次失败：5分钟后连续失败：进入异常队列异常队列可以由人工或监控系统进一步处理这套机制比“调用失败就结束”更适合大促场景6 人机协同：自动回复并不是全部AI客服系统真正稳定的关键，不是自动回复比例越高越好更合理的方式是分层处理场景处理方式商品参数AI自动回复活动规则AI自动回复发货时间AI自动回复常规物流AI自动回复基础售后AI先判断强烈投诉转人工异常订单转人工敏感金额转人工高价值咨询AI识别后人工跟进这也是母语智能客服更适合的使用方式AI先处理高频、标准和重复问题，人工则负责需要判断和协商的复杂情况7 大促前的监控指标大促架构不能只看“系统有没有挂”还应该监控业务处理链路建议至少关注：消息进入量队列积压量平均处理时间模型调用成功率平台发送成功率转人工率异常队列数量未处理消息数量例如：if queue_size > 1000: send_alert("消息队列积压")if model_error_rate > 0.05: send_alert("模型调用失败率过高")if platform_send_error_rate > 0.03: send_alert("平台回复接口异常")这些指标可以帮助团队提前发现系统瓶颈8 大促前建议的实践流程从实施角度，可以把大促准备分成几个阶段时间主要任务大促前2周整理商品知识与活动规则大促前10天完成AI自动回复配置大促前1周模拟高并发咨询大促前3天检查重试、转人工和异常队列大促当天监控队列、接口和人工负载如果团队不准备从零自研完整客服系统，也可以使用已经具备多平台接入和知识学习能力的SaaS方案进行验证 建议优先使用真实店铺、真实SKU和真实大促规则进行测试9 架构演进方向随着AI客服从自动回复走向业务协同，后续架构可以继续向几个方向演进多Agent拆分将商品咨询、物流、售后、投诉等场景拆成不同Agent知识库实时更新活动规则变化后自动同步知识，减少人工维护智能路由根据用户意图、订单状态和情绪决定走AI还是人工弹性扩容根据队列长度动态增加消费者和模型实例统一数据分析把不同平台的咨询数据统一沉淀，用于分析高频问题和商品需求10 总结电商大促高并发下，AI客服真正需要解决的并不是单点模型能力，而是完整的消息处理架构可以将稳定架构概括为：统一消息接入+消息持久化+异步队列+意图路由+知识检索+AI回复+人工接管+失败重试+监控告警对于多平台、多店铺经营团队来说，这类架构可以有效降低消息积压、重复处理和漏回的风险无论采用自研还是第三方服务，都建议把系统稳定性、知识准确性和人机协同能力放在同等重要的位置AI客服真正的价值，不只是大促期间多回复几条消息，而是在咨询高峰下仍然保持消息可追踪、回复可控制、异常可兜底参考资料Kafka 官方文档RabbitMQ 官方文档FastAPI 官方文档Redis Streams 文档电商平台开放接口与消息推送规范

一、概述1.1 案例介绍高校学生在毕业前普遍反复遇到三个缺少统一答案的问题：“现在毕业还差什么”“这学期选课是否冲突”“接下来几个学期该怎么安排”。本案例用华为云码道（CodeArts）代码智能体，以规范驱动开发方式构建了学途 Navigator——一套将学分审计、选课约束检查、多学期修读规划三项判断交由可逐条解释的确定性规则引擎完成，并接入华为云 MaaS 承担自然语言解释与多轮咨询职能的学生自助工具。审计、先修、冲突、风险的判断权始终在规则引擎手中，AI 只负责把结构化结论"翻译"成建议——这也是本案例区别于"成绩单管理 + 大模型问答"类项目的核心设计。系统已部署至华为云 Flexus 云服务器并提供公网访问，可用演示账号直接体验。1.2 适用对象高校学生个人开发者1.3 案例时间本案例完整开发周期约 8 天，覆盖设计、核心引擎开发、前端与部署、AI 接入、增强功能、测试与发布等阶段（详见 3.1 节开发计划）；阅读本文并在本地运行核心功能（AI_PROVIDER=mock 模式，无需华为云凭据）预计需要 40–60 分钟。1.4 案例流程说明：先产出完整的详细设计文档体系（需求规格、系统架构、数据库设计、审计与约束引擎规则、AI 咨询降级链等 17 份文档），作为码道对话的结构化输入；码道生成数据模型、JWT 鉴权模块与管理端 API；码道按规则表生成学分审计引擎、约束检查器、先修图算法，人工核验并固化为单元测试；完成学生端四个核心页面，首次发布到华为云 Flexus 实例，实现公网访问；接入华为云 MaaS，联调 Provider 抽象、上下文组装与降级链；开发进度可视化、推荐排课、多学期修读规划等增强功能；完善单元与集成测试，完成端到端验收场景的测试；整理演示材料，发布案例文档与 GitCode 仓库。1.5 资源总览体验完成后请及时释放云端资源（详见第四节），避免产生多余费用。资源名称规格单价华为云码道（CodeArts）代码智能体通用体验版免费云服务器通用计算型 x1（Flexus X1），1 vCPU / 1 GiB / 40 GiB SSD，Ubuntu 22.04¥0.1228/小时（据实际购买页截图）弹性公网 IP全动态 BGP，5 Mbit/s 独享带宽¥0.80/GB 流量华为云 MaaS 推理服务ModelArts Studio DeepSeek 系列 Tokens 套餐包代金券覆盖（领取方式见 2.1 节）账户保证金满足按需计费账户余额下限要求1 元，实操完成后可提现实际总花费取决于云服务器运行时长与 MaaS 调用量，此处仅列出可核实的单价；如需核实完整费用总额，可在华为云费用中心导出账单进行核对。1.6 公网部署地址访问地址：http://121.37.156.117/GitCode 仓库：https://gitcode.com/2301_79350888/xuetu-navigator （默认分支 main）。演示账号：学生 demo / demo123（中等风险）、demo2 / demo123（高风险）；管理员 admin / admin123。使用说明：该地址为部署在华为云 Flexus 云服务器上的训练营评审演示环境。演示账号密码已公开，请勿录入真实个人数据；评审结束并释放弹性公网 IP 后，该地址将停止访问。二、环境和资源准备2.1 领取华为云 MaaS 平台大模型 Tokens登录华为开发者空间，任选以下一种方式领取模型的 API 地址、模型名称与 API Key：方式一：参考案例《华为开发者空间 - ModelArts Studio大模型通用代金券领取使用指导》中的"二、开通MaaS平台大模型"章节内容领取代金券。方式二：参考案例《华为云MaaS平台大模型Tokens领取使用指导》中的"二、领取MaaS平台大模型Tokens"章节内容，领取MaaS平台DeepSeek V3系列大模型Tokens代金券，购买ModelArts Studio DeepSeek Tokens套餐包，开通模型服务。获取到的三项信息仅需填入服务器端的 .env 文件（对应 MAAS_BASE_URL/MAAS_MODEL/MAAS_API_KEY 三个环境变量），前端代码不涉及。后端请求日志仅记录追踪 ID、请求方法、路径、状态码与耗时，调用 MaaS 失败时也只记录截断后的错误信息，密钥本身不会出现在日志中。本案例不在文档中展示具体的 API 地址、模型名称与 Key 取值。2.2 华为云码道（CodeArts）安装部署登录华为云官网完成账号注册与实名认证，并在华为开发者空间内安装激活码道（CodeArts）代码智能体（官网入口见 1.5 节资源表）。本案例开发过程中码道模型选择 GLM 系列，工作模式为智能体对话模式。2.3 本地开发环境搭建无需任何华为云凭据，AI_PROVIDER=mock 模式即可在本地运行全部核心功能，包括学分审计、选课约束、多学期规划与 AI 咨询的降级路径：# 后端：Python 3.11 + FastAPI cd backend && python -m venv .venv && .venv/Scripts/activate # Linux/Mac: source .venv/bin/activate pip install -r requirements.txt cp .env.example .env # 填写 JWT_SECRET（如 openssl rand -hex 32），AI_PROVIDER=mock 即可全功能开发 python -m app.seeds.seed # 建表并写入种子数据（幂等，可重复执行） uvicorn app.main:app --reload --port 8000 # 前端：Vue3 + Vite cd frontend && npm i && npm run dev # localhost:5173，/api 代理到 8000 # 测试（须先激活 backend/.venv，再执行 python -m pytest，二者缺一均会报错，见下表） cd backend && .venv/Scripts/activate python -m pytest --cov=app/services --cov-report=term-missing测试命令有两个前提条件，缺一均会报错：报错现象根因解决方法ModuleNotFoundError: No module named 'app'使用了裸 pytest 命令而非 python -m pytest；裸 pytest（控制台脚本入口）在 Windows 上不会自动将当前目录加入 sys.path改用 python -m pytest，并确认当前目录为 backendModuleNotFoundError: No module named 'tests.conftest'在全局或共享 Python 环境（如 conda base）下运行，该环境的 site-packages 中恰好安装了同名的顶层 tests 包，屏蔽了项目本地的 backend/tests/改为激活并使用项目自身的 backend/.venv，不使用全局 Python 解释器三、构建学途 Navigator 应用3.1 总体架构与设计思路本案例采用规范驱动开发（Spec-Driven Development）方式：先撰写一套完整的详细设计文档，涵盖需求规格、系统架构、数据库设计、各引擎规则、AI 咨询模块、安全与异常处理、测试设计、部署方案与验收标准等方面，再以这套文档为结构化输入，逐阶段驱动码道生成代码，代码经人工核验后固化为测试用例。整个开发周期约 8 天，按四个关键节点推进：完成数据模型冻结、完成首次云端部署、开展增强功能的集中开发、完成代码冻结，随后进入测试与发布收尾。实际提交记录与该计划安排基本吻合，可在版本提交历史中找到同期的开发记录。系统架构：系统架构遵循自上而下的单向依赖约束：routers → services → models，services 层不允许导入 FastAPI（以保证引擎可脱离 HTTP 直接单测），models 层不允许依赖 services。该规则由代码审查维持，可通过"能否在不依赖 FastAPI/TestClient 的情况下直接单测引擎"验证：test_audit.py、test_checker.py、test_planner.py、test_recommender.py、test_prereq_graph.py 五份测试文件均仅导入 app.services 下的模块，构成该约束成立的可执行证据。系统数据模型共设计 11 张表，涵盖用户与鉴权、专业与培养模块、课程与先修关系、学期与开课计划、选课方案、修读规划、AI 对话记录等业务实体，实体关系如下：其中三处相对初版高层架构设计的修正均记录为正式架构决策：先修关系改用关联表而非 JSON 数组（原因：环检测与链深度计算需要结构化的边表）、开课时段改为 JSON 数组以支持一课多时段、学期独立建立字典表（原因：多学期规划需要有序的学期序列）。模块职责：目录职责关键约束backend/app/routers/鉴权、参数校验、调用 services、组装统一响应 {code,message,data}不承载业务规则backend/app/services/审计、约束、推荐、规划、导入、AI 咨询的全部业务规则以纯函数为主，不依赖 FastAPIbackend/app/services/prereq_graph.py先修图的环检测、链深度、后继链长度、最长路径的唯一实现由审计、检查、推荐、规划、导入五处调用，不允许重复实现backend/app/services/advisor/AI Provider 抽象、MaaS 实现、Mock 实现、上下文组装详见 3.4 节backend/app/models/SQLAlchemy ORM 模型，为数据库 schema 的唯一事实来源不依赖 servicesfrontend/src/stores/Pinia 全局状态，登出时统一调用 $reset()详见 3.5.3 节码道 CodeArts Doer 在本地工作区（.codeartsdoer/ 目录，为机器本地配置，不纳入仓库版本控制）针对开发前期的各阶段任务，生成了 spec.md（需求规格）、design.md（设计方案）、tasks.md（编码任务清单）三段式产出，合计约 8700 行。任务清单中的条目与实际代码逐一对应：例如某阶段的 tasks.md 要求"在 backend/app/services/audit.py 中实现 build_passed_map(records, courses)"，对照实际实现（audit.py 第 25–44 行），函数名、签名与行为完全一致，说明码道在需求分析、任务拆解与代码生成环节确实发挥了实际作用。进一步核查显示，该项目未配置 MCP（模型上下文协议，用于让智能体调用外部工具与数据源）服务，也未使用自定义 Skill 或 Project Expert 等扩展能力，码道的使用范围限定在规范驱动开发流程中的规格生成与代码生成环节。设计文档体系要求任何引擎规则的改动均先补充或修改单元测试用例、再修改实现，以避免规则口径漂移。开发过程中人工核验阶段发现并按此流程修复的若干问题，详见 3.5 节"技术难点与解决思路"。3.2 核心功能与用户流程功能完备性矩阵（下表基于源码与路由表逐项核查，按"已实现/未实现"如实标注各功能的完成状态）：功能重要程度端状态证据认证与账号核心功能通用已实现routers/auth.py、security.py（PyJWT + bcrypt）培养方案与课程库管理（含 JSON 导入校验，覆盖 8 类校验规则）核心功能管理端已实现services/importer.py、test_importer.py学期与开课计划管理核心功能管理端已实现routers/admin/semester.py、routers/admin/offering.py已修课程录入与学分审计（含毕业风险）核心功能学生端已实现services/audit.py（行覆盖率 98%）选课模拟与约束检查（含方案保存）核心功能学生端已实现services/checker.py（行覆盖率 96%）AI 学业咨询核心功能学生端已实现services/advisor/*，详见 3.4 节AI 建议一键应用增强功能学生端已实现详见 3.4.6 节学业进度可视化（雷达图/环形图）重要功能学生端已实现components/ModuleRadar.vue、ProgressRing.vue推荐排课（一键推荐）重要功能学生端已实现services/recommender.py（行覆盖率 90%）多学期修读规划重要功能学生端已实现services/planner.py（行覆盖率 92%）审计报告打印友好导出锦上添花学生端未实现已检索前端全目录，未发现打印或导出相关代码操作日志写入核心功能后端已实现models/log.py::log_operation()操作日志查看界面锦上添花管理端未实现路由中无 admin/logs，无对应页面组件小程序壳不适用—明确不做属产品范围裁剪，本案例不涉及移动端小程序项目验收标准明确规定，"重要功能"与"锦上添花"级别中未实施的部分不影响项目整体验收，但需要如实标注其状态；审计报告打印导出与操作日志查看界面均属于这一情况。四个典型使用场景：① 大四学生登录后查看总进度与毕业风险；② 在校学生选课模拟页勾选候选课程，即时查看冲突/缺先修/学分上限提示；③ 在校学生向 AI 咨询排课建议并一键应用；④ 管理员导入培养方案 JSON 或开课 CSV，查看结构化校验报告。典型操作路径（演示学生账号 demo/demo123，软件工程 2023 级第 7 学期）：登录后进入审计看板：环形进度 106/160（66%）、风险徽标"中等风险"、五模块雷达图；2. 进入"选课模拟"页勾选课程，约 300 毫秒内获得逐课冲突/缺先修提示；3. 进入"AI 咨询"页提问选课建议，AI 结合真实缺口数据分点作答并给出"一键应用"建议卡片；4. 进入"修读规划"页生成分学期时间线。3.3 部署项目代码项目结构说明：xuetu-navigator/ ├── backend/ │ ├── app/ │ │ ├── models/ # SQLAlchemy 模型 │ │ ├── schemas/ # Pydantic 请求/响应契约 │ │ ├── routers/ # API 路由（auth/plan/selection/chat/admin等） │ │ ├── services/ # 领域层：audit/checker/planner/recommender/prereq_graph/advisor │ │ └── seeds/ # 种子数据脚本 │ └── tests/ # pytest 测试（158 项） ├── frontend/ │ └── src/{api,stores,router,views,components} ├── deploy/ # setup.sh / deploy.sh / nginx.conf / systemd unit └── docs/ # 17 份详细设计文档 + 案例文档下载源码：git clone https://gitcode.com/2301_79350888/xuetu-navigator.git关键代码讲解——毕业风险五级确定性规则（backend/app/services/audit.py:204-254），按序评估、首个命中即定级，每条结论均带机器可读的 rule 编码：def assess_risk(missing_required, total_gap, remaining_semesters): if remaining_semesters is None: return RiskResult(level="unknown", reasons=[]) reasons, level = [], "low" for mc in missing_required: if mc.chain_remaining_len > remaining_semesters: reasons.append(RiskReason(rule="R1-先修链", message=f"...")) level = "high" if total_gap > remaining_semesters * MAX_SEMESTER_CREDITS: reasons.append(RiskReason(rule="R2-容量", message=f"...")) level = "high" # R3-紧容量 / R4-链贴线 / R5-默认 略 return RiskResult(level=level, reasons=reasons) 约束检查器为四级管道、按序执行且互不短路（backend/app/services/checker.py）：依次执行重复修读检查、时间冲突检查、先修依赖检查、学分上限检查，用户一次性看到全部问题而非逐条重新提交。先修图的环检测、链深度、后继链长度仅在 backend/app/services/prereq_graph.py 一处实现，供审计、检查、推荐、规划、导入校验五处共用，避免多处口径分歧。运行调试：见 2.3 节本地启动命令；实测 python -m pytest --cov=app/services --cov-report=term-missing：3.4 MaaS 融合方案> 本节说明 MaaS 在系统中的协同边界：审计、先修、冲突、风险的判断权始终在确定性规则引擎手中，MaaS 负责结构化结果的自然语言解释与多轮交互。二者的协同机制、失败处理与成本控制均有明确设计与代码实现。3.4.1 判断权与解释权的分离系统设计明确了这样一条架构原则：AI 只做解释、建议、自然语言交互；学分够不够、课冲不冲突、风险几级，一律由确定性引擎产出并作为事实注入；AI 模块不可用时，学分审计与选课约束等核心功能不受影响。该原则体现在三处具体设计中：AI 的输入是审计引擎 run_audit() 计算完成的结构化 JSON，不参与学分或先修关系的计算；AI 的输出如涉及选课建议，采用标记信号加确定性推荐引擎复用的方式（3.4.6 节），不解析 AI 自由文本以获取课程号；AI 完全不可用时，Mock 作为降级路径直接复用同一份结构化审计数据组装摘要。3.4.2 Provider 抽象与降级链# backend/app/services/advisor/base.py @runtime_checkable class AIProvider(Protocol): @property def name(self) -> str: ... def generate(self, messages: list[dict]) -> AIReply: ... def get_provider() -> AIProvider: settings = get_settings() if settings.AI_PROVIDER == "maas": from app.services.advisor.maas import MaaSProvider return MaaSProvider() from app.services.advisor.mock import MockProvider return MockProvider() MaaSProvider.generate()（maas.py:18-56）使用 httpx 以 OpenAI 兼容协议向 {MAAS_BASE_URL}/chat/completions 发起 POST 请求，超时时间读取自 settings.AI_TIMEOUT。请求过程中的任何异常（超时、非 2xx 响应、JSON 解析失败）均被捕获，并按 AI_FALLBACK 配置决定后续处理：默认值 mock 会实例化 MockProvider 作为降级方案并标记 degraded=True。AI_PROVIDER 与 AI_FALLBACK 的默认值均为 mock，即 Mock 是开发阶段的默认路径，而非后续补充的降级分支。3.4.3 上下文组装与裁剪context.py::build_context() 在每次对话时动态组装：固定 System Prompt、一条携带【学生数据】JSON 的 user 消息，以及最近 6 轮历史对话。裁剪策略（预算约 6000 tokens）按影响程度由小到大依次执行：开课列表仅保留当前存在学分缺口的模块对应课程（context.py:184-206），且已通过或在修的具体课程会被显式排除（第 192 行：if c.code in passed_codes or c.code in enrolled_codes: continue）；先修链仅展开缺失必修课对应的部分；历史对话按 6 轮、4 轮、2 轮逐级压缩；审计摘要不参与裁剪，作为回答质量的底线保留。上下文数据均来自当次对 run_audit() 的实时查询结果，而非缓存或静态文本。3.4.4 防幻觉机制的验证System Prompt（context.py:27-37）明确规定"只依据【学生数据】回答；数据中没有的课程、学分、政策，需说明系统数据中没有"“涉及学分缺口、先修关系、毕业风险时，必须引用数据中的数字与课程号，不得自行推算修改”。浏览器实测截图记录了一次验证：学生提问"我想辅修人工智能，我这学期该如何选课？“，AI 回复第一句明确说明"系统数据中没有辅修人工智能的相关课程、学分要求或政策信息，请咨询教务部门了解辅修方案的具体要求”，随后针对"本学期选课建议"给出的课程号均为学生当前学期的实际开课数据。截图如下：同一次对话中，对超出数据范围的问题作出明确说明、对数据范围内的问题引用真实课程号，两种行为均被截图记录。3.4.5 成本与滥用控制措施值代码位置限流5 次/分钟/用户，内存滑动窗口routers/chat.py::check_rate_limit()超时45 秒（调整过程见 3.5.2 节）config.py::AI_TIMEOUT单次回答长度上限1024 tokensconfig.py::AI_MAX_TOKENS用户输入长度上限2000 字符schema 校验，超长返回 40001历史窗口最近 6 轮config.py::AI_HISTORY_ROUNDS密钥存放仅存于服务器端 .env 文件，前端不涉及；请求日志与错误日志均不记录密钥字段middleware.py（请求日志）、advisor/maas.py（调用失败日志）3.4.6 AI 建议一键应用：AI 与确定性推荐引擎的协同该功能体现了 AI 与确定性推荐引擎的协同关系，而非相互替代。AI 在自然语言中给出选课建议后，学生希望能够一键应用到选课模拟页；若直接解析 AI 输出文本以获取课程号，存在模型编造不存在课程号的风险。解决方式是：System Prompt 要求模型仅在本次回答确实给出具体选课建议时，在回答末尾单独一行输出标记 [[SHOW_COURSE_SUGGESTIONS]]；后端仅识别并剥离该标记（不解析建议内容本身），命中后复用与"一键推荐"相同的确定性推荐引擎，重新计算一份结构化候选：# backend/app/routers/chat.py:44-84（节选） def _build_suggested_offerings(user, db) -> list[SuggestedOffering] | None: """AI 判断本次回答给出了选课建议时，复用确定性推荐引擎现算一份结构化候选， 而不是解析 AI 自由文本猜课程号。任何异常都只记日志并返回 None， 绝不能让这个附加功能打断主聊天回复。""" try: ... result = run_recommend(audit=bundle.result, courses=..., offerings=..., target_credits=24.0, credit_limit=settings.MAX_SEMESTER_CREDITS) return [SuggestedOffering(...) for item in result.items] except Exception: logger.warning("构建聊天选课建议失败，已跳过", exc_info=True) return None 前端消费逻辑位于 SelectionView.vue:418-456（applyExternalOfferings）与 RoadmapView.vue:217-263（applyCurrentSemesterCourses）：回复下方渲染建议卡片，点击后跳转选课模拟页，目标页逐条校验课程状态（已通过/已在修/已在候选中的会被过滤并提示），合法课程与已保存候选合并（而非覆盖），自动执行约束检查，由学生自行确认保存。suggested_offerings 不写入数据库，仅在当次新回复中出现，历史消息重新加载后不再显示按钮。AI 相关的测试要求均已在 test_ai_api.py（22 个测试函数）中实现，包括故障注入模拟 httpx 超时、验证 degraded=True 且响应结构不受影响的测试，在代码层面验证了"AI 不可用时核心功能仍可运行"这一架构设计的成立。3.5 技术难点与解决思路以下问题是开发过程中人工核验环节发现的实际问题，均有明确的根因分析与修复方式。3.5.1 PyJWT 与 python-jose 的依赖声明不一致依赖声明与实际导入不一致的问题仅在全新云服务器上首次暴露：本机开发环境与当时较早阶段的 148/150 项测试均未触发该问题（测试总数其后随功能增补持续增加，最终为 158 项，见 3.6 节），但在全新服务器执行 pip install -r requirements.txt 后，seed.py 因 import app.security 触发 ModuleNotFoundError: No module named 'jwt' 而失败。根因在于 requirements.txt 声明的依赖是 python-jose[cryptography]，而 security.py 实际导入的是 jwt——这是 PyJWT 包的模块名，与 python-jose 是两个不同的第三方库。本机 .venv 因历史遗留同时安装了两个包，掩盖了依赖声明的错误。修复方式是将依赖改为直接声明 PyJWT>=2.8。该问题表明，仅在全新、纯净的目标环境完整执行一次部署脚本，才能验证依赖声明的正确性。3.5.2 MaaS 调用超时阈值的调整Mock 模式开发阶段未暴露相关问题，但接入华为云 MaaS 后，浏览器实测显示多数提问被降级为"离线建议"。排查调用耗时发现，失败请求的耗时精确落在超时阈值上——先后精确落在 15230 毫秒、25230 毫秒，表明是 httpx 的超时机制主动截断了仍在进行的生成过程，而非网络波动所致。改用不设超时的方式直连 MaaS 探测，实测生成耗时约 32.23 秒。超时阈值先后调整为 25 秒（仍不充分）、最终调整为 45 秒（结合探测数据确定），前端超时同步调整为 55000 毫秒并预留余量。3.5.3 前端跨用户状态残留同一 SPA 会话内登出学生账号 A、免刷新登录学生账号 B 后，审计看板短暂显示账号 A 的旧数据，直至强制刷新页面才恢复正确；直接使用账号 B 的 token 调用接口验证，后端返回结果始终正确，确认问题源于前端。根因是审计数据的前端缓存带 5 分钟 TTL，登出逻辑此前仅清除 token 与用户信息，未重置任何按用户维度缓存的状态。修复方式是在登出逻辑中对相关 Pinia store 显式调用 $reset()。3.5.4 AI 自由文本对已修课程的误推荐AI 一键应用功能上线后，浏览器实测发现：AI 针对"专业选修还差多少学分、应如何选课"给出的自然语言建议中，包含了学生已经修过并通过的课程，将其作为"本学期可选课程"推荐。根因在于提供给 AI 的开课列表仅按"课程所属模块是否仍有学分缺口"过滤，未排除学生已通过或在修的具体课程——模块整体存在缺口不代表模块内每一门课程都尚未修读。修复方式是补充已通过/在修课程的排除逻辑，并新增回归测试。该问题也印证了"AI 不解析自由文本、结构化推荐单独由确定性引擎生成"这一架构原则的必要性：同期的结构化推荐卡片有独立的过滤逻辑，未受此问题影响。3.5.5 部署环境差异本机（Windows + Git Bash）安装的 rsync 与远程 SSH 子进程交互存在已知兼容性问题，修复方式是改用 tar czf - | ssh ... tar xzf - 管道方式同步文件；远端 pip install 直连境外源时反复超时，修复方式是加入华为云 PyPI 镜像源。两处问题均在首次云端部署时暴露。3.6 测试、异常处理与降级测试设计将测试划分为四层：单元测试（五个纯函数引擎及导入校验）、集成测试（pytest + TestClient + 临时 SQLite）、安全专项（越权访问、无 token 访问、注入类攻击）、端到端（手动清单辅以 Playwright）。测试结果见 3.3 节"运行调试"，158 项全部通过、核心引擎覆盖率 90% 以上。早期测试套件未显式隔离 AI_PROVIDER 环境变量，存在测试执行过程中意外发起 MaaS 请求的风险，修复方式是在 tests/conftest.py 中强制默认使用 Mock。学分审计与选课约束两个核心功能的路由与服务层代码均不依赖 advisor 模块，可通过 import 语句直接核查。安全与异常处理设计的要点包括：鉴权分层（get_current_user/require_student/require_admin）、越权访问返回 40401 而非 403（避免泄露资源存在性）、输入校验分 Schema 层与业务层两层、CSV 公式注入防护、AI 回复 Markdown 渲染使用白名单不允许原始 HTML、统一异常体系携带 trace_id、请求与错误日志不记录密钥等敏感字段。3.7 华为云部署与运行效果部署拓扑：1 GiB 内存机型属于低规格实例，deploy/setup.sh 在部署流程中自动创建 1 GiB swap 作为内存安全余量。首次初始化通过 setup.sh（幂等）完成 Nginx 与 Python 环境安装、systemd 服务注册；日常发布通过 deploy.sh 完成前端构建、tar+ssh 文件同步、远端依赖安装、种子数据初始化与健康检查。访问验证：项值公网地址http://121.37.156.117/MaaS 云端调用AI_PROVIDER=maas 配置下实测 POST /me/chat：HTTP 200，耗时 15.1 秒，degraded:false，回复引用 demo 账号的实际数据账号密码角色用途adminadmin123管理员培养方案与开课计划导入及校验演示demodemo123学生（中等风险场景，第 7 学期）模块缺口与选课冲突演示demo2demo123学生（高风险场景，第 5 学期）多学期规划演示演示账号密码直接展示在公网登录页，便于访问者体验完整功能，请勿在演示账号下录入真实个人数据。根据安全组规则截图核查，入方向规则实际允许 TCP:22（SSH）、TCP:80、TCP:443、TCP:3389（RDP，在 Ubuntu 服务器上无实际用途）及全部 ICMP，源地址均为 0.0.0.0/0，即不限来源 IP，与设计阶段"入方向仅开放 22 端口（限本机 IP）与 80 端口"的规划不符，推测是华为云"Sys-WebServer"默认安全组模板未作收紧所致。该配置存在明显的收紧空间，正式使用前建议将入方向 22、3389 端口的源地址限制为运维人员的固定出口 IP 段。3.8 总结与展望学途 Navigator 使用三个确定性规则引擎（学分审计、约束检查、多学期规划）与一个共用的先修图算法模块，解决"学分是否达标、选课是否冲突、后续如何安排"三个可审计的问题；华为云 MaaS 承担自然语言层面的解释、多轮交互与选课建议信号判断，通过 Provider 抽象与 Mock 优先的降级链，保证 AI 不可用时核心功能不受影响。开发过程以完整的详细设计文档体系为输入，驱动华为云码道（CodeArts）代码智能体逐模块生成代码，经人工核验、158 项单元与集成测试及浏览器实测完成验证，最终部署在华为云 Flexus 实例上提供公网服务，并经云端 MaaS 调用验证。已知局限：审计报告打印导出与操作日志查看界面尚未实现：二者均属"锦上添花"级别的功能，按项目验收标准，该级别的未实施项不影响项目整体验收。安全组配置范围偏宽：22、3389 端口对全部来源地址开放，详见 3.7 节。当前为 HTTP 而非 HTTPS：尚未配置 SSL 证书，属训练营演示场景下的已知取舍。单实例部署，SQLite 单写者模式：并发能力面向演示场景（约 10 并发以内）设计，非面向生产环境的高并发方案。suggested_offerings 不持久化：AI 一键应用建议仅在当次新回复中出现，页面刷新后不再显示。多学期规划不检查未来学期的时间冲突：因未来学期的开课表尚不存在，选修缺口以模块占位学分表达，而非具体课程。后续改进方向：① 收紧安全组入方向规则，评估启用 HTTPS 的可行性；② 完成审计报告打印导出与操作日志查看界面的开发，后端数据已就绪，主要待补充前端页面实现；③ 如后续出现稳定并发需求，评估已预留的 RDS for MySQL 迁移路径。四、释放资源体验完成后应及时释放全部云资源（云服务器、弹性公网 IP），避免产生持续费用；释放前建议导出数据库备份与操作日志归档至本地。释放路径：进入 ECS 实例列表，选择目标实例，点击"更多 → 删除"，在对话框中选择"释放云服务器绑定的公网 IP 地址"，确认释放。五、扩展资料与复现指引5.1 源码仓库GitCode 公开仓库：https://gitcode.com/2301_79350888/xuetu-navigator默认分支：main仓库内容：backend/ 与 frontend/ 包含前后端源码，backend/tests/ 包含自动化测试，deploy/ 包含华为云部署脚本，docs/ 包含完整设计与验收文档。5.2 推荐阅读与复现路径先体验：使用 1.6 节的公网地址和演示账号查看审计看板、选课模拟、AI 咨询与多学期规划。再运行：阅读仓库根目录 README.md，按快速开始说明启动后端与前端；无华为云 MaaS 凭据时可使用 AI_PROVIDER=mock 完成本地体验。理解设计：从 docs/README.md 进入 01–17 号设计文档，依次查看需求、架构、数据模型、API、规则引擎、AI 咨询、安全、测试与部署设计。验证质量：运行 backend/tests/ 自动化测试，并结合 docs/bugs.md 查看已确认缺陷的现象、根因、修复与回归证据。复现部署：参考 deploy/ 脚本和部署设计文档，在华为云 Flexus 云服务器上完成 Nginx、systemd、SQLite 与应用服务配置。5.3 开源内容边界公开仓库提供复现本案例所需的应用源码、测试、部署脚本和设计文档；训练营内部培训材料、个人凭据、本地开发工具配置及运行期数据按 .gitignore 与安全要求不纳入仓库。评审时建议先体验公网环境，再对照仓库中的实现、测试和设计文档核验关键功能。

华为技术专家们好， 我最近申请到了AI百校计划，想加入专属资源白名单。能帮我添加一下吗？谢谢！

为深化教育部产学合作协同育人项目建设，推动昇腾国产AI技术融入高校《深度学习》核心课程，7月3日，广东工业大学计算机学院成功举办《华为昇腾云与（深度学习）课程融合及实战师资培训》。来自全校各学院50余名骨干教师齐聚现场，完成一整天系统化理论学习与工程实操实训，打通产业前沿技术与课堂教学的落地通道。本次培训由计算机学院陈云华副教授牵头筹备，配套华为官方全套标准化教学资源，设置理论筑基、项目实战、高校生态宣讲三大核心环节，兼顾教学改革落地性与工程实操实用性。第一阶段：昇腾AI全栈理论教学讲师系统讲解昇腾五层全栈技术架构，从昇腾芯片、CANN 异构架构、MindSpore 全场景框架，到ModelArts一站式开发平台、开发者空间实训环境逐层拆解；同步分享广工36学时《深度学习》校企融合课程完整方案，配套华为官方课件、实验手册、教学案例库，覆盖神经网络、Transformer、大模型、生成式AI等全部教学章节，助力教师快速完成课程迭代升级。第二阶段：两大完整实战案例上机演练MaaS大模型应用实战：通过华为开发者空间1元申领千万DeepSeek Tokens代金券，学习远程云开发容器搭建、模型服务开通、API密钥配置，从零基于Python+Gradio开发 AI 对话网页助手，完整掌握高校大模型实训课落地方案，无需本地高配置设备；YOLOv5计算机视觉实训：依托 ModelArts Notebook云端环境，完成数据集导入、模型训练、权重保存、目标推理全流程实操，提供开箱即用实验代码，可直接用于课堂实验、课程设计教学。实操环节规避本地环境配置复杂、硬件不足、版本冲突等教学痛点，参训教师现场动手完成完整项目，实操门槛低、可直接迁移至日常教学。培训最后，华为云高校生态团队面向参会老师全面解读华为云面向高校的全周期育人生态：码道代码智能体、开发者成长中心、圈层培养计划、华为云学科竞赛、产教融合课程及科研支持等配套权益，覆盖教师备课、学生实训、学科竞赛、科研开发全场景。本次师资培训以教育部产学协同育人项目为载体，实现国产昇腾根技术与高校深度学习课程深度融合，提供可复制的师资研修、课程共建样板。未来华为云将牵手高校，常态化开展师资研修、学生实训营、学科竞赛联合培育活动，依托完整产教资源，持续培养贴合数字产业需求的人工智能复合型人才。

上周申请的百校计划，请问大概什么时间才会出结果呢？

一、东方数理-太极场想解决什么问题： 东方传统智慧（易经、五行、天干地支）蕴含深刻的系统论和对称拓扑思想，但缺乏现代化的数学表达和可计算框架，导致其无法在量子计算、AI推理等前沿领域发挥实际价值。为什么会想到做这个： 当前量子计算遭遇三大瓶颈——量子态不稳定、纠错成本极高、拓扑布线低效。而东方数理体系中的六重对称性（C₆）、阴阳二元平衡、六十四卦编码等，恰好与量子计算的核心需求高度同构。大概是什么产品： 一套基于C₆对称群的东方数理计算引擎，包含量子态稳定化算法、卦变量子编译器、六边形拓扑优化器三大核心模块，适配华为Ascend芯片和量子云平台。二、目标用户及痛点面向哪些用户： 量子计算研究者、AI大模型开发者、地震预测科学家、个性化服务开发者当前痛点： 量子相干时间短、MoE路由延迟高、地震预测缺乏有效模型、传统八字排盘精度受限三、价值与意义效率提升： 量子相干时间提升3-10倍，编译深度降低40%；MoE路由延迟<0.12ms；地震预测命中率62%社会价值： 将传统东方智慧转化为可验证、可计算的现代科学工具，推动中国原创科学范式的建立

15号申请的百校计划，已经十个工作日了，请问大概什么时间才会出结果呢？后台审核处只有四个编码，但是还处在审核中，我想知道大概什么时间才会出结果呢？

本人在创建智能体后，还是无法新建凭证。复现步骤：  ▎ 1. 创建 OpenClaw 模式智能体，保存后为草稿状态  ▎ 2. 进入凭证管理 → 新建凭证  ▎ 3. 「请选择智能体」下拉显示「无数据」  ▎  ▎ 环境：HarmonyOS 6.1.0，Chrome 浏览器  

一、概述1. 案例介绍本案例基于华为云ModelArts模型训推平台，结合OpenClaw和第三方通信软件，打造7*24小时远程AI助手。通过OpenClaw + ModelArts-skill统一管理ModelArts资源、推理任务部署、训练作业调度及Notebook实例生命周期，实现AI开发与部署的全流程自动化管理。*本实验需要用到算力资源，可登记下表免费领取代金券cid:link_42. 适用对象企业个人开发者高校学生3. 案例时间本案例总时长预计30分钟。4. 案例流程领取MaaS模型tokens;在ModelArts创建专属资源池以及Notebook;在Notebook中进行OpenClaw安装并配置MaaS模型key;体验ModelArts Notebook OpenClaw。5. 资源总览本案例体验30分钟预计花费4~5元。注意：1.此处标注的金额仅限成功领取代金券体验一遍案例，如自费或超出代金券金额持续使用专属资源池和MaaS平台模型则会进行持续扣费，本案例按DeepSeek V3.2示例。2.代金券激活后，需在个人账户充值不低于1小时资源费的保证金（如下所示：最低7.5元），体验完成删除资源后，保证金将返回个人账户，自行选择是否提现。资源名称规格单价（元）ModelArts CPU专属资源池modelarts.vm.cpu.8ud7.41元/小时ModelArts Notebook实例云硬盘 EVS5GB0.007元/小时华为开发者空间 - DeepSeek-R1/V3.2千万Tokens代金券DeepSeekV3.21.00ModelArts Studio大模型（DS/K2/Q3等）通用代金券DeepSeekV3.20.00二、环境资源准备2.1 领取华为云MaaS平台大模型Tokens福利方式一： 登录华为开发者空间，参考案例《华为开发者空间 - ModelArts Studio大模型通用代金券领取使用指导》中的“二、 开通MaaS平台大模型”章节内容领取代金券，获取到模型的API地址、模型名称和API Key。方式二： 登录华为开发者空间，参考案例《华为云MaaS平台大模型Tokens领取使用指导》中的“二、 领取MaaS平台大模型Tokens”章节内容，领取MaaS平台DeepSeek V3系列大模型Tokens代金券，购买ModelArts Studio DeepSeek Tokens套餐包，开通模型服务，最后获取到模型的API地址、模型名称和API Key。以开通deepseek-V3.2为例，在OpenAI兼容接口获取API地址和Model参数：  注意：请妥善记录API Key、API地址以及模型名称待后面步骤使用。2.2 创建专属资源池并创建Notebook1.登录华为云ModelArts，注意：第一次使用的用户请按照提示进行访问授权即可2.点击左侧菜单资源管理 > 专属资源池 ，按照下图选项依次选择后创建专属资源池。创建专属资源池约10分钟。注意：在配置网络中->ModelArts网络->新创建的网络，并选择新创建的网络。其中创建网络配置保持默认配置即可。3.填写节点池名称，并选择节点类型为CPU，CPU架构为X86.4.等待专属资源池创建成功后，点击左侧菜单 开发者空间->Notebook ，按照下图选项依次选择后创建Notebook。注意：镜像选择“py3.10.6-ubuntu22.04”即可，其他选项维持默认配置即可 三、使用Notebook OpenClaw实现ModelArts（魔坊）管理3.1 快速安装部署并启动OpenClaw1.点击左侧菜单开发者空间->Notebook->选择刚才创建的Notebook->接入环境->JupyterLab接入2.进入JupyterLab之后：ModelArts Launcher->AI Agent->OpenClaw3.仔细阅读相关服务声明和安全说明后点击同意，开始安装配置OpenClaw4.依次选择 完整安装OpenClaw->推荐版本，等待OpenClaw下载安装完成5.OpenClaw安装完成会提示进行模型配置，将2.1章节中获取的模型url和key，粘贴到下方6.等待Gateway启动成功后，OpenClaw图标会变成如下状态，代表已经安装并启动完成，点击OpenClaw打开即可  3.2 ModelArts 服务Skill实践 注：注意如果需要单独部署推理或者训练任务，可能涉及其他项目的费用。1.在Notebook中安装部署OpenClaw，会自动配置ModelArts SKill，它集成了ModelArts当前所有服务的API，帮助您更方便的使用ModelArts 各个服务2.获取资源池中正在运行的工作负载3.获取资源池中的统计信息3.3 OpenClaw集成飞书，7*24小时远程体验（可选）注：请提前完成飞书客户端的获取，飞书的App ID与App Secret 创建配置及获取方式可以参考下面文档进行获取：cid:link_51.在Notebook JupyterLab中，打开菜单ModelArts Launcher->AI Agent->OpenClaw->Management，选择进入 即时通讯配置>配置飞书，请耐心等待飞书插件下载完成  2.将飞书的App ID与App Secret依次填入，确认后选择重启Gateway 3.等待Gateway重启完成后，在飞书APP中的开发者小助手对话框中可以看到版本发布成功的提示，单击打开应用即可进入机器人的聊天窗口也可以在搜索框中搜索已创建的机器人名称，选中后进入聊天窗口，可以与机器人直接对话测试效果。 4.注意：如果在飞书发送消息，提示“OpenClaw: access not configured.”，请将提示的命令“openclaw pairing  ...”在Terminal中执行即可，如下图所示至此，在华为云ModelArts一键体验 OpenClaw案例已全部完成。四、资源释放*案例体验完成后，如果不想继续使用，必须删除Notebook和专属池资源，避免后续产生不必要的费用，删除后保证金会退回账户，可自行选择是否提现。1.点击左侧菜单开发者空间->Notebook->选择刚才创建的Notebook->更多->删除， 输入"DELETE"，点击确定，Notebook实例会被立即删除。2.点击左侧菜单资源管理 > 专属资源池->选择刚才创建的资源池实例->更多->删除，输入"DELETE"，点击确定，专属资源池实例会被立即删除。  【训练营小tip】如您在案例实操过程中遇到问题或有改进建议，可以在开发者训练营群内反馈，我们会及时响应处理，谢谢！欢迎扫码，加入华为云Inspire创想者大会实战训练营技术交流群扫码获取更多训练营资讯

最近Notebook都不可用，好像有一两个月了吧，如果不提供最好明确说明或下架，而不是仍可点击操作

从Demo到生产：尚硅谷2026版大模型项目的容器化部署与性能调优在2026年的技术浪潮中，大模型（LLM）已经不再是实验室里的新奇玩具，而是驱动企业降本增效的核心生产力。许多开发者在跟随尚硅谷等优质教程完成大模型项目的本地Demo搭建后，往往会面临一个巨大的鸿沟：如何让这个在本地跑得通的项目，真正安全、稳定、低成本地落地到企业的生产环境中？从Demo到生产，绝不仅仅是简单的代码搬运，而是一场关乎算力成本、用户体验与系统稳定性的商业突围战。而容器化部署与深度的性能调优，正是打赢这场战役的关键武器。容器化部署：打破环境壁垒，实现“模型即服务”在商业落地中，时间就是金钱。传统的部署方式往往因为开发、测试与生产环境的微小差异（如CUDA版本、依赖库冲突）而导致项目延期。容器化技术（Docker + Kubernetes）为大模型项目提供了标准化的交付范式。通过将大模型、推理引擎（如vLLM、TensorRT-LLM）以及复杂的Python依赖环境打包进一个轻量级的Docker镜像中，企业可以实现“一次构建，到处运行”。这不仅消除了环境不一致带来的运维风险，更让大模型具备了极强的弹性伸缩能力。结合Kubernetes的自动化调度，当业务高峰期（如电商大促、客服早高峰）来临时，系统可以自动扩容推理节点；当流量低谷时，又能自动缩容释放资源。这种“模型即服务”（MaaS）的架构，让企业能够像使用水电一样按需购买算力，极大地提升了IT资源的投资回报率。性能调优：压榨硬件极限，直面“显存焦虑”大模型商业落地的最大拦路虎，往往是高昂的硬件成本。一块高端GPU动辄数万甚至十数万元，如果推理效率低下，企业的利润将被算力成本吞噬殆尽。因此，生产级的性能调优不再是锦上添花，而是生死攸关的必修课。在容器化环境中，性能调优的核心在于对GPU资源的极致利用。首先是推理加速引擎的引入，例如采用vLLM配合PagedAttention技术，能够有效解决显存碎片化问题，大幅提升并发吞吐量，让单次推理的响应延迟（Latency）从秒级压缩至毫秒级。其次是GPU的共享与切分调度，对于BERT等轻量级模型或低频访问场景，通过MIG（多实例GPU）或MPS（多进程服务）技术，可以将一块物理显卡切分为多个逻辑实例供不同任务共享，从而将硬件利用率从传统的20%提升至75%以上。这些硬核的工程化手段，直接决定了项目的单位算力成本，是商业模型能否跑通的关键。稳定性与成本的双重护城河从Demo走向生产，还意味着要面对真实世界的复杂性。在生产环境中，冷启动延迟、模型加载失败、显存溢出（OOM）等故障随时可能发生。基于容器的健康检查（Liveness Probe）与自动化重启机制，能够确保服务在遇到异常时实现“自愈”，保障业务7x24小时不间断运行。同时，通过量化技术（如INT8/INT4量化）与模型蒸馏，可以在几乎不损失业务精度的前提下，将模型的体积和计算量大幅缩减。这不仅降低了对昂贵硬件的依赖，甚至让部分大模型应用下沉到边缘设备成为可能。从尚硅谷的课堂到企业的机房，大模型项目的容器化部署与性能调优，本质上是一场从“技术实现”到“商业价值”的跨越。只有掌握了这些工程化的核心心法，开发者才能真正帮助企业驾驭大模型这股洪流，在激烈的市场竞争中构建起属于自己的技术护城河。

一、概述1.1 案例简介华为云ModelArts模型训推平台是面向开发者的一站式AI开发平台，可快速创建和部署模型，管理全周期AI工作流。本案例基于千问8B模型构建医疗问诊系统，展示从问诊数据处理、模型微调到部署的全流程。1.2 适用对象个人开发者高校学生企业开发者项目管理者1.3 案例流程1.4 资源总览本案例预计花费105元。本实验需要用到算力资源，可登记下表免费领取代金券。cid:link_1注：代金券激活后，需在个人账户充值不低于1小时资源费的保证金（如下所示：共计327元），体验完成删除资源后，保证金将返回个人账户，自行选择是否提现。资源名称规格单价本案例使用时长数据精炼-公共资源池NPU (1卡) | (24 vCPUs) | 内存 (192 GB)29.55元/小时10分钟模型训练-公共资源池8 * Ascend-snt9b2 | 192 vCPUs | 1536 GiB (modelarts.bm.npu.arm.8snt9b2)236.41元/小时13分钟在线推理-公共资源池1 * Snt9b3 | 24 vCPUs | 192 GiB | ARM (modelarts.bm.arm.24u.npu.1snt9b)29.55元/小时*2次1分钟OBS资源包标准存储多AZ包-40GB1元/月1天二、实战演练2.1 上传医疗微调数据集在数据处理和模型训练的场景中，用户需要将多种类型的数据集高效、准确地导入到ModelArts数据平台中，以支持后续的数据精炼和模型训练任务。然而，传统的数据导入方式存在诸多限制，如不支持自定义任务名称、数据格式转换功能有限等，导致用户在导入数据时面临操作不便和数据处理效率低下的问题。如何在新的平台中实现更加灵活和高效的数据导入功能，成为用户亟待解决的问题。为此，ModelArts平台提供了增强的数据导入功能，支持多种基础数据类型的导入，允许用户在创建导入任务时编辑任务名称和描述，从而显著提升了数据处理的灵活性和效率，满足了用户在数据准备阶段的多样化需求。1.前往ModelArts管理控制台，在控制台左侧导航栏选择“数据准备-->数据连接”，打开“数据连接”工作区-->创建数据连接注：如控制台链接跳转至旧版，请点击左下角“前往新版”，再创建数据连接2.在“创建数据连接”配置页面，自定义任务名称和描述。3.选择单轮问答类型，文件格式为jsonl，连接方式为对象存储服务OBS，打开文件夹图标4.根据弹框提示，点击前往OBS的链接-->购买资源包-->选择区域“西南-贵阳一”，资源包类型选择“标准存储多AZ包”，规格选择“40 GB”，购买时长“1个月”。存储计费说明：cid:link_5注：代金券可覆盖实验所需存储费用，无需自付。5.回到桶列表-->创建桶-->配置页面的区域选择贵阳一-->其他默认-->立即创建6.下载医疗微调样例数据train1000.jsonl，回到桶列表，点击刚刚创建的桶名称-->新建文件夹-->在文件夹里点击上传对象-->默认存储类别-->上传刚刚下载的文件    7.回到数据连接配置页面，选择刚刚新建的桶名称，找到train1000.jsonl文件，选中该文件所在文件夹，点击确定，自动生成存储路径  8.导入的数据形成新的数据集，需要给数据集重新命名。输入数据集名称（本案例文档中使用“医疗行业微调数据集”举例，请用户自定义输入数据集名称）、数据集属性（可选）、描述信息（可选），并配置“立即上线数据集”。2.2医疗微调数据集精炼数据精炼是ModelArts数据工程的核心功能模块，旨在解决大模型训练数据准备过程中的“质量”与“数量”双重挑战。它打破了传统数据处理工具的界限，将基于规则的数据加工（清洗、过滤、去重等）与基于大模型的数据合成（改写、扩充、润色等）深度融合。1.打开ModelArts管理控制台，在控制台左侧导航栏选择“数据准备 > 数据精炼”。在数据精炼页面右上方单击“创建智能精炼”，配置任务名称。描述相关信息，选择数据集使用步骤一导入的数据集（“医疗行业微调数据集”），单击“下一步”。2.在“添加算子”区域选择“个人数据脱敏”算子，并勾选全部脱敏项，单击“保存并下一步”。3.配置生成数据集，输入数据集名称（本案例文档中使用“医疗行业精炼后微调数据集”举例，请用户自定义输入数据集名称），存储地址为最终生成数据集的存储地址，自定义选择即可，资源池类型选择“公共资源池”，规格选择“NPU (1卡) | (24 vCPUs) | 内存 (192 GB)”，单击“启动”。  4.当数据精炼作业的“最近运行状态”变为“数据集生成成功”时，表示数据精炼作业运行结束，其生成的数据将存储至“资产管理-->数据-->我的数据”中。  2.3基于Qwen3-8B模型精调在大模型训练中，精调（或“微调”）（Fine-tuning） 是指通过特定领域的数据集对已经做过全量预训练模型（Pre-trained Model, PT）进行二次训练的方法。通过精调能够更新模型权重，使模型能够更有效地应对具体的任务需求。这一阶段使模型能够精确执行如文案生成、代码生成和专业问答等特定场景中的任务。1.在ModelArts管理控制台左侧导航栏中，选择“模型开发与训练-->模型训练”进入训练作业列表。单击“创建训练作业”，进入创建训练作业页面，训练模式选择“精调作业”，配置任务名称相关参数，选择模型Qwen3-8B | V1.0.0，训练类型选择“微调”，训练目标选择“全量微调”，模型输出路径自定义选择，资源池类型选择“公共资源池”，规格选择“8 * Ascend-snt9b2 | 192 vCPUs | 1536 GiB (modelarts.bm.npu.arm.8snt9b2)”。  2.数据集选择“医疗行业精炼后微调数据集”，训练参数-EPOCH输入1，勾选“自动发布到资产”（本次案例模型名称为“医疗行业-Qwen3-8B-微调模型”。）3.当参数配置完成后，单击“提交”，创建精调作业任务。精调作业一般需要运行一段时间，前往精调作业列表，可以查看精调作业的基本情况。精调作业运行完成后自动将模型训练过程中的最终产物发布到模型资产资产管理-我的模型。2.4微调后模型部署模型资产管理是ModelArts平台的核心模块，负责统一管理平台提供的预置模型和我的模型。本案例使用我的模型一键部署，直接推理使用。1.前往ModelArts管理控制台，在左侧导航栏选择“资产管理-->模型”。在模型资产工作区选择“我的模型”，找到步骤三中模型精调产物“医疗行业-Qwen3-8B-微调模型”，点击操作列“部署”2.服务名称输入“医疗行业-Qwen3-8B-微调推理服务”，资源池类型选择“公共资源池”，推理单元选择“1 * Snt9b3 | 24 vCPUs | 192 GiB | ARM (modelarts.bm.arm.24u.npu.1snt9b)”，设置时长“1小时”，点击确定启动部署，可前往 “模型推理-->在线推理”列表页面查看推理服务的基本情况。2.5模型效果实时比对模型实时对比功能提供了一个直观的对比平台，允许用户在完全一致的输入条件下，对不同模型进行横向评测。本案例使用模型实时比对功能进行微调效果验证：将“未微调的原生模型（Qwen3-8B）”与“微调后的模型（医疗行业-Qwen3-8B-微调模型）”做同步对比，直观验证微调是否成功注入了领域知识，或是否存在能力退化。1.前往ModelArts管理控制台，在左侧导航栏选择“资产管理-->模型”。在模型资产工作区选择“预置模型”，找到模型Qwen3-8B”，点击操作列“部署”2.服务名称输入“Qwen3-8B推理服务”，资源池类型选择“公共资源池”，推理单元选择“1 * Snt9b3 | 24 vCPUs | 192 GiB | ARM (modelarts.bm.arm.24u.npu.1snt9b)”，设置时长“1小时”，点击确定，启动部署。3.前往 “模型推理-->在线推理”列表页面可查看推理服务的基本情况。如模型服务状态已停止，请点击操作列“启动”按钮开启服务。4.前往ModelArts管理控制台，选择“模型评测-->实时对比”，进入“实时比对”操作页面。点击“服务对比”，选择“Qwen3-8B推理服务”，“医疗行业-Qwen3-8B-微调推理服务”两个服务。5.输入问题“请输出八珍汤的方剂组成、治疗症状以及出处？”，可以看到微调后的模型对于方剂组成增加了克数的回答，且对于治疗症状描述的更加丰富。2.6删除实验资源*案例体验完成后，必须删除推理服务和OBS资源，避免后续产生不必要的费用，删除后保证金会退回账户，可自行选择是否提现。1.实验结束后，为避免后续不必要的计费，请停止在线推理服务。前往 “模型推理 > 在线推理”列表页面，找到服务“医疗行业-Qwen3-8B-微调推理服务”、“Qwen3-8B推理服务”，分别点击操作列“停止”按钮停止服务。2. 实验结束后，点开OBS桶列表，点击之前创建的桶名称，进去之后一 一删除桶下面的各个文件夹，再回到桶名称这里，点击右边删除按钮。   【训练营小tip】如您在案例实操过程中遇到问题或有改进建议，可以在开发者训练营群内反馈，我们会及时响应处理，谢谢！欢迎扫码，加入华为云Inspire创想者大会实战训练营技术交流群扫码获取更多训练营资讯