企业官网建设流程全解析

1. 从"人挤人"的黄金周说起：为什么需要一个AI行程规划师

每年国庆黄金周，朋友圈里总有两拨人：一拨在景区看后脑勺，另一拨在家里刷着前者的朋友圈暗自庆幸。但说实话，大多数人不是不想出去玩，而是被"规划行程"这件事劝退了。订酒店要比价、查路线要切换三四个App、找餐厅还得翻半天点评、景点之间的通勤时间全靠猜——一趟旅行规划下来，比上班还累。

我身边不少朋友的做法是：在小某书上搜"某地三日游攻略"，然后照着抄。问题是，那些攻略要么是两年前的，要么是博主恰饭的软文，要么完全不适合自己的节奏。有人喜欢一天跑五个景点，有人只想找个咖啡馆坐一下午，同一份攻略根本没法通用。

这就是我想做"AI行程规划师"的出发点。核心逻辑很简单：用户输入出发地、目的地、天数、预算、偏好（比如"带老人""亲子""拍照打卡""美食优先"），系统自动生成一份可执行的行程，包含每天的景点顺序、交通方式、用餐建议、时间分配，甚至备选方案。

为什么选在国庆这个场景？因为黄金周的规划难度是平时的好几倍。平时去一个城市，酒店随便订、餐厅随便吃，但国庆期间热门城市的核心区域酒店可能提前一个月就满了，热门景点需要预约，高速免费但堵车严重，餐厅排队两小时起步。这些约束条件叠加在一起，人工规划几乎不可能做到最优。而大模型恰好擅长处理这种"多约束条件下的方案生成"问题。

技术选型上，我用了蓝耘元生代MaaS平台来调用大模型能力，前端则跑在鸿蒙系统上。为什么这么选？下面会详细拆解。先说说这个"AI行程规划师"到底能做什么、适合谁用。

它适合三类人：一是完全不想做攻略的"甩手掌柜"，输入几个参数直接拿结果；二是做了攻略但想验证合理性的"谨慎派"，把自己的方案丢进去让AI挑毛病；三是旅行博主或定制游从业者，用它来快速生成初稿再人工打磨。不管你是哪种，核心诉求都是一样的：用最少的时间，拿到一份靠谱的、可执行的行程。

2. 蓝耘元生代MaaS凭什么成为我的第一选择

2.1 从"自己搭模型"到"调用即用"的思维转变

一开始我是想自己部署一个开源模型的。毕竟做技术的都有这个执念：能自己掌控的东西才放心。但算了一笔账之后我放弃了。部署一个70B参数级别的模型，至少需要两张A100或者四张A800，光是硬件成本就够我买好几年的API调用量了。而且模型更新迭代太快，今天部署的版本下个月就落后了，维护成本极高。

蓝耘元生代MaaS平台解决的就是这个问题。MaaS的全称是Model as a Service，翻译过来就是"模型即服务"。你不需要关心模型部署在哪个机房、用的是什么显卡、显存够不够，只需要通过API接口发送请求，平台返回结果就行。这种模式对于我这种个人开发者或者小团队来说，是最务实的选择。

具体到蓝耘元生代这个平台，我选它有四个原因。第一，它支持多种主流大模型，包括文本生成、图像理解、语音合成等不同类型，一个平台就能满足行程规划中"文字生成+图片识别+语音播报"的复合需求。第二，它的API接口设计得很规范，文档清晰，接入成本低。第三，按量计费的模式很灵活，国庆期间流量大就多花点，平时流量小就少花点，没有固定的月费压力。第四，平台提供了模型效果对比和调优工具，方便我针对行程规划这个垂直场景做Prompt优化。

2.2 行程规划场景对MaaS平台的特殊要求

不是所有MaaS平台都适合做行程规划。这个场景有几个特殊要求，我在选型时重点考察了。

第一是长文本处理能力。一份完整的行程规划，输出内容通常在2000到5000字之间，包含多天的详细安排。如果模型的上下文窗口太小，或者输出长度受限，就会出现"写到第三天就断了"的情况。蓝耘元生代上我选用的模型支持较长的上下文和输出长度，实测生成一份五天四晚的行程，输出稳定在3000字以上，没有截断。

第二是结构化输出能力。行程规划不是写散文，它需要按天、按时间段、按项目来组织。我需要在Prompt里明确要求模型按照JSON或者Markdown表格的格式输出，方便前端解析和展示。蓝耘元生代的模型对格式指令的遵循度不错，实测在Prompt里给出明确的格式模板后，输出结果的结构化程度能达到90%以上。

第三是响应速度。用户输入参数后，如果等30秒才出结果，体验就很差。蓝耘元生代的推理速度在我可接受的范围内，一份三天行程的生成时间大约在8到15秒，五天行程大约15到25秒。这个速度对于"规划"这个场景来说是够用的，毕竟用户不是在聊天，而是在等一份方案。

第四是并发能力。国庆期间如果用户量上来，同时有几十个人在生成行程，平台能不能扛住？蓝耘元生代支持弹性扩容，我实测在模拟并发20个请求的情况下，响应时间没有明显劣化。当然，正式上线前还需要做压力测试，但至少从架构上它是支持的。

2.3 接入蓝耘元生代MaaS的完整配置流程

下面是我实际接入的步骤，你可以照着操作。

首先，在蓝耘元生代平台注册账号并完成实名认证。然后进入控制台，创建一个应用，获取API Key和Secret Key。这两个Key是调用接口的凭证，务必保管好，不要写在前端代码里。

接下来是选择模型。平台上有多个模型可选，我选的是通用文本生成能力较强的那一个。选好之后，在控制台的"模型详情"页面可以看到该模型的接口地址、请求参数说明和计费标准。

然后是配置调用环境。我用的是Python做后端服务，先安装依赖：

pip install requests

然后写一个最简调用示例：

import requests import json API_KEY = "你的API_KEY" SECRET_KEY = "你的SECRET_KEY" MODEL_ENDPOINT = "平台提供的接口地址" def generate_itinerary(prompt): headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" } payload = { "model": "你选择的模型名称", "messages": [ {"role": "system", "content": "你是一个专业的行程规划师，擅长根据用户需求生成详细、可执行的旅行计划。"}, {"role": "user", "content": prompt} ], "temperature": 0.7, "max_tokens": 4000 } response = requests.post(MODEL_ENDPOINT, headers=headers, json=payload) return response.json()

这里有几个参数需要重点说明。temperature控制输出的随机性，行程规划场景我建议设在0.6到0.8之间。太低会导致每次生成的行程几乎一样，太高又会出现不靠谱的建议。max_tokens要设得足够大，否则输出会被截断。我设的是4000，实测五天行程够用。

注意：API Key和Secret Key绝对不能暴露在前端代码或客户端里。我的做法是后端服务做一层代理，鸿蒙端只调用我自己的后端接口，由后端去请求蓝耘元生代的API。这样即使客户端被逆向，也拿不到平台的密钥。

2.4 踩过的坑：计费、限流与错误处理

接入过程中我踩了几个坑，这里分享一下。

第一个坑是计费单位。蓝耘元生代按Token计费，输入和输出的Token都算。我一开始没注意，Prompt写得很长，导致输入Token消耗很大。后来我优化了Prompt，把不必要的说明删掉，输入Token减少了大约40%。

第二个坑是限流。平台对免费额度和付费额度有不同的QPS限制。我在测试阶段用免费额度，并发稍微高一点就返回429错误。解决办法是在后端加一个简单的队列，控制请求频率，同时做好重试逻辑。

第三个坑是错误处理。网络请求可能因为各种原因失败，必须做好兜底。我的做法是：如果第一次请求失败，等待1秒后重试；如果连续三次失败，返回一个预设的"简化版行程模板"给用户，同时记录日志。这样至少不会让用户看到白屏。

3. 鸿蒙端开发：为什么选它，以及怎么落地

3.1 鸿蒙在出行场景中的独特优势

选鸿蒙作为前端载体，不是因为它"新"，而是因为它在这个场景下确实有优势。

第一个优势是分布式能力。鸿蒙支持跨设备流转，用户在手机上生成行程后，可以一键流转到平板或者车机上查看。国庆自驾游的场景下，车机大屏显示行程比手机方便得多。这个能力在安卓和iOS上实现起来要麻烦很多。

第二个优势是原子化服务。鸿蒙的原子化服务不需要用户下载安装完整的App，通过卡片或者扫码就能直接使用。对于"AI行程规划师"这种低频但刚需的场景，用户可能一年就用几次，让他专门下载一个App不现实。原子化服务的形式更轻量，用户用完即走。

第三个优势是开发效率。鸿蒙的ArkTS语言和声明式UI框架，写起来比传统的Android XML布局简洁很多。我一个后端出身的人，花了两天时间就搭出了可用的界面。

当然，鸿蒙也有它的局限。生态还在建设中，一些第三方库的支持不如安卓完善。但我的这个项目依赖的外部库不多，主要是网络请求和JSON解析，鸿蒙原生都支持，所以影响不大。

3.2 鸿蒙端与MaaS后端的通信设计

鸿蒙端不直接调用蓝耘元生代的API，而是通过我自己的后端服务中转。这样做有三个好处：一是保护API密钥，二是可以在后端做缓存和限流，三是方便做数据统计和用户行为分析。

通信流程是这样的：用户在鸿蒙端填写表单（出发地、目的地、天数、预算、偏好标签），点击"生成行程"按钮。鸿蒙端把表单数据打包成JSON，通过HTTPS POST请求发送到我的后端。后端收到请求后，先检查缓存，如果相同参数的行程在24小时内已经生成过，直接返回缓存结果。如果没有缓存，则构造Prompt调用蓝耘元生代MaaS，拿到结果后解析、格式化，再返回给鸿蒙端。

鸿蒙端的网络请求代码大致如下：

import http from '@ohos.net.http'; async function requestItinerary(params: ItineraryParams): Promise<string> { let httpRequest = http.createHttp(); let response = await httpRequest.request( "https://你的后端域名/api/generate", { method: http.RequestMethod.POST, header: { 'Content-Type': 'application/json' }, extraData: JSON.stringify(params), connectTimeout: 60000, readTimeout: 60000 } ); httpRequest.destroy(); return response.result as string; }

这里connectTimeout和readTimeout都设成了60秒，因为大模型生成需要时间，设太短会导致请求超时。实测下来，大部分请求在20秒内完成，但偶尔会有慢请求，留足超时时间更稳妥。

3.3 界面交互中的几个关键决策

界面设计上我做了几个取舍，这里说一下背后的思考。

第一，表单字段不是越多越好。一开始我想让用户填很多信息：出发时间、返回时间、交通偏好、住宿档次、饮食禁忌、体力水平……后来发现字段太多用户会烦。最终精简到五个必填项：出发地、目的地、天数、预算范围、偏好标签（多选）。其他信息通过偏好标签来间接表达，比如选了"带老人"就自动降低行程强度。

第二，生成过程要有进度反馈。大模型生成需要十几秒，如果界面一直转圈，用户会以为卡死了。我的做法是显示一个分阶段的进度提示："正在分析目的地信息……""正在规划每日路线……""正在优化时间分配……"虽然这些阶段实际上是一起完成的，但给用户的心理感受好很多。

第三，结果展示要分层。生成的行程很长，全部铺开用户看不完。我把它分成三层：第一层是"行程概览"，用卡片展示每天的核心安排；第二层是"详细日程"，点开某一天可以看到具体的时间点和项目；第三层是"备选方案"，针对每个时段提供一两个替代选项。这样用户可以先看概览，感兴趣再深入。

第四，支持手动调整和重新生成。AI生成的行程不可能100%符合预期，用户可能需要把某个景点换掉，或者调整某天的节奏。我提供了"重新生成这一天"和"替换这个景点"的功能，让用户可以在AI结果的基础上做微调，而不是全部推倒重来。

3.4 鸿蒙原子化服务的上架与分发

鸿蒙的原子化服务需要通过应用市场审核才能上架。审核过程中我遇到的主要问题是权限说明。因为需要网络请求权限，审核方要求详细说明为什么需要这个权限、数据用来做什么、是否涉及用户隐私。

我的处理方式是：在隐私政策里明确写清楚，用户填写的行程参数仅用于生成行程，不会用于其他目的，也不会与第三方共享。同时，在后端做了数据脱敏，日志里不记录用户的出发地和目的地具体名称，只记录参数类型。

另外，原子化服务的包大小有限制，不能太大。我把不必要的资源都删了，最终包大小控制在2MB以内，顺利通过审核。

4. Prompt工程：让大模型输出真正可用的行程

4.1 行程规划Prompt的核心结构

Prompt写得好不好，直接决定输出质量。我经过几十次迭代，总结出一个比较稳定的Prompt结构，包含五个部分。

角色设定。开头明确告诉模型它是什么角色："你是一位有十年经验的旅行规划师，熟悉中国各大旅游城市的最佳路线和隐藏玩法。"角色设定越具体，输出的专业度越高。

任务描述。清晰说明要做什么："根据用户提供的参数，生成一份详细的行程规划，包含每天的景点顺序、交通方式、用餐建议和时间分配。"

约束条件。这是最关键的部分。我会把用户参数和通用约束都列出来。通用约束包括：每天安排的景点不超过4个，景点之间的通勤时间要合理，要预留用餐时间，要标注每个景点的建议游玩时长，要提供至少一个备选方案。

输出格式。明确要求输出的结构。我通常要求按天分节，每天包含"上午""中午""下午""晚上"四个时段，每个时段列出活动内容、地点、预计时长、交通方式。最后附上"实用提示"，包括天气提醒、预约提醒、避坑建议。

示例。给一个简短的输出示例，让模型知道期望的格式和详细程度。示例不需要很长，一两天的内容就够。

4.2 不同偏好标签对应的Prompt变体

用户选择的偏好标签不同，Prompt也要相应调整。我整理了几个常见的变体。

这些变体不是互斥的，用户可以多选。多选时，Prompt里会同时包含多个追加指令，模型会尝试平衡。实测下来，同时选三个以上标签时，输出质量会有所下降，因为约束条件太多。我的建议是用户最多选三个标签。

4.3 处理模型"胡说八道"的几种策略

大模型有个通病：它会编造不存在的信息。比如推荐一个已经关门的餐厅，或者给出错误的公交线路。这在行程规划场景里是致命的。

我的应对策略有三个。第一，在Prompt里明确要求模型标注不确定性。比如："如果你不确定某个信息是否准确，请标注'建议核实'。"这样用户看到标注就知道需要自己确认。

第二，在后端做二次校验。对于模型输出的景点名称和地址，我会调用地图服务的API做一次校验，如果地址不存在或者名称匹配不上，就在结果里标注"该地点信息可能有误"。

第三，提供用户反馈入口。每个行程结果下面都有"报错"按钮，用户如果发现信息有误可以反馈。这些反馈数据我会定期整理，用来优化Prompt。

提示：不要指望大模型100%准确。行程规划的场景下，AI的角色是"提供思路和框架"，具体的营业时间、门票价格、预约方式，用户还是需要通过官方渠道确认。我在每个行程的末尾都会加一句："以上信息由AI生成，出行前请通过官方渠道核实。"

4.4 输出格式的强制约束技巧

为了让模型稳定输出结构化内容，我用了几个技巧。

技巧一：用Markdown表格约束。在Prompt里给出表格的列名和示例行，模型会倾向于按照表格格式输出。比如：

请按照以下格式输出每天的行程： | 时段 | 活动 | 地点 | 时长 | 交通 | |------|------|------|------|------| | 上午 | 游览 | XX景区 | 3小时 | 打车 |

技巧二：用分隔符标记每天的开始。要求模型在每天的内容前加上"===第X天==="这样的分隔符，方便后端解析。

技巧三：限制输出长度。在Prompt里明确说"总字数控制在3000字以内"，避免模型生成过于冗长的内容。但也不能太短，否则信息量不够。3000字左右是一个比较平衡的值。

技巧四：要求模型先输出大纲再输出详细内容。这样如果生成过程中被截断，至少还有大纲可用。我在Prompt里会写："先输出行程大纲，再逐天展开详细安排。"

5. 实测中的意外与优化：从能用 to 好用

5.1 国庆期间的真实压力测试

国庆前一周，我把这个工具分享给了几个朋友试用。结果第一天就出了状况：同时有8个人在生成行程，后端响应时间从平均15秒飙升到45秒，有两个人直接超时了。

排查后发现两个瓶颈。第一个是后端服务的并发处理能力不足。我用的是一台低配云服务器，同时处理8个请求就已经吃满了CPU。解决办法是把后端服务改成异步处理：收到请求后立即返回一个任务ID，然后后台慢慢处理，处理完了通过WebSocket推送给前端。这样用户不用一直等着，可以先去干别的，生成好了再通知。

第二个是MaaS平台的调用频率限制。我的账号QPS上限是5，同时8个请求过来，有3个被限流了。解决办法是在后端加了一个请求队列，超过QPS限制的请求排队等待，而不是直接失败。同时做了重试机制，被限流的请求等待1秒后自动重试。

优化之后，再模拟20个并发请求，响应时间稳定在20到30秒之间，没有出现超时。

5.2 用户反馈驱动的三次迭代

第一批用户反馈回来后，我做了三次比较大的迭代。

第一次迭代：解决"行程太赶"的问题。很多用户反馈AI安排的景点太多，一天跑四个景点根本跑不完。我调整了Prompt，把每天的景点上限从4个降到3个，并且要求模型在景点之间预留至少30分钟的通勤时间。调整后，行程的可行性明显提高。

第二次迭代：增加"雨天备选方案"。国庆期间很多地方会下雨，用户希望有室内活动的备选。我在Prompt里增加了"如果当天有雨，提供室内替代方案"的指令，并且在输出格式里增加了"备选"一栏。

第三次迭代：优化餐厅推荐。一开始模型推荐的餐厅很多是网红店，排队时间长、价格贵。我调整了Prompt，要求"推荐本地人常去的餐厅，避免纯网红店，标注是否需要排队"。调整后，餐厅推荐的实用性好了很多。

5.3 成本控制：Token消耗的优化实践

蓝耘元生代按Token计费，虽然单价不高，但如果用户量大了，成本也不容忽视。我做了几项优化来降低Token消耗。

优化一：精简Prompt。最初的Prompt有800多字，后来精简到400字左右，去掉了重复的说明和冗余的示例。输入Token减少了约50%。

优化二：缓存重复请求。相同参数的行程在24小时内只生成一次，后续请求直接返回缓存。国庆期间热门城市（比如某热门旅游城市）的行程被反复请求，缓存命中率大约30%，节省了不少Token。

优化三：分级输出。用户第一次请求时只生成"行程概览"（约500字），如果用户点击"查看详细日程"，再生成详细内容。这样大部分用户只消耗了概览的Token，只有真正感兴趣的用户才会消耗更多。

优化四：设置max_tokens上限。根据行程天数动态设置max_tokens，三天行程设2500，五天行程设4000，避免模型生成过多无关内容。

5.4 从工具到产品：还差哪些关键能力

目前这个工具已经能用了，但离"产品"还有距离。我总结了几个需要补齐的能力。

第一是用户系统。现在没有登录功能，用户生成的行程无法保存和跨设备同步。下一步需要接入账号体系，让用户可以保存历史行程、收藏喜欢的方案。

第二是行程的协作编辑。国庆出行往往是多人一起，如果能让同行的人一起编辑行程、投票选择景点，会实用很多。这需要实时同步能力，鸿蒙的分布式特性在这里可以发挥作用。

第三是与日历和地图的深度集成。生成的行程如果能一键导入手机日历，或者在地图上直接显示路线，用户体验会好很多。鸿蒙的系统能力支持这些集成，但需要额外的开发工作。

第四是多模态输出。现在只有文字行程，如果能生成一张可视化的行程图，或者用语音播报每天的安排，对老年用户会更友好。蓝耘元生代MaaS平台支持图像和语音能力，技术上可行，主要是产品设计的问题。

6. 一些踩坑之后的真心话

做这个项目的过程中，我最大的体会是：大模型不是万能的，但用对了场景，它能解决很多以前解决不了的问题。行程规划这个场景，以前要么靠人工（费时费力），要么靠规则引擎（死板不灵活），大模型的出现让"个性化+可执行"同时成为可能。

另一个体会是：MaaS平台的选择比模型本身更重要。模型能力固然重要，但对于个人开发者来说，平台的稳定性、计费方式、文档质量、技术支持响应速度，这些"非模型因素"往往决定了项目能不能顺利推进。蓝耘元生代在这些方面做得比较均衡，没有明显的短板。

最后说一个具体的技巧：不要试图一次性生成完美的行程。我的做法是先让模型生成一个"骨架"，然后通过多轮对话逐步细化。比如第一轮生成每天的景点安排，第二轮针对某一天调整餐厅，第三轮补充交通细节。这样每次请求的Token消耗更少，输出质量也更高。用户端看起来是一次性生成，实际上是后端做了多次调用和拼接。

如果你也想做类似的项目，我的建议是：先从一个小场景切入，把Prompt调好，把流程跑通，再考虑扩展。不要一上来就追求大而全，那样很容易卡在半路。行程规划这个场景足够具体，也足够有需求，是一个很好的练手项目。