🔥承渊政道： 个人主页
❄️个人专栏: 《C语言基础语法知识》 《数据结构与算法》 《C++知识内容》 《Linux系统知识》 《算法刷题指南》 《测评文章活动推广》 《大模型语言路线学习》 《MySQL数据库学习》 《Python知识内容》
✨逆境不吐心中苦,顺境不忘来时路!✨ 🎬 博主简介:
随着大模型能力不断进入真实开发场景,AI 编程工具的价值已经不再局限于代码补全,而是逐渐覆盖需求分析、项目搭建、页面开发和本地预览等完整流程.对于开发者而言,如何选择稳定的模型服务,并将其接入熟悉的开发工具,成为提高实际工作效率的重要一步.本次实践中,我通过蓝耘元生代MaaS平台接入GLM-5.2模型,并将其配置到 WorkBuddy 中,以"智能团队项目协作与效能管理平台"为业务背景,完成了一个包含首页、关于我们、产品服务和联系我们四个页面的企业官网.从模型服务数据评估、API Key 创建,到模型接入、需求提交和网站生成,整个过程形成了一条完整且可验证的 AI 开发链路.本文将以开发者的第一视角,详细记录蓝耘元生代与 WorkBuddy 的连接配置、实际操作步骤、网站生成效果以及使用过程中的思考,希望为计划使用MaaS模型服务和AI开发工具的读者提供一份可参考、可复现的实践案例.废话不多说,下面跟着小编的节奏🎵一起去疯狂的学习吧!
目录
- 一、为什么要做这次实践
- 二、接入之前,我先看了模型服务数据
- [三、在蓝耘元生代MaaS创建API Key](#三、在蓝耘元生代MaaS创建API Key)
- 四、把GLM-5.2接入WorkBuddy
- 五、我给WorkBuddy的官网开发需求
- 六、从生成代码到启动本地预览
- 七、最终网站效果复盘
- 八、这次实践中,蓝耘元生代解决了什么
- 九、我认为仍然需要人工把关的地方
- [十、总结:一次真正闭环的 AI 开发体验](#十、总结:一次真正闭环的 AI 开发体验)
一、为什么要做这次实践
我平时接触企业官网项目时,真正耗时的环节往往不只是"把页面写出来",而是需求拆解、页面规划、文案组织、样式统一以及多轮修改.尤其是小型企业官网,功能并不复杂,但首页、关于我们、产品服务、联系我们几个页面仍要保持一致的视觉语言,导航和交互也必须能够正常使用.
这次我想验证一个具体问题：能否把国内 MaaS 平台提供的模型能力接入AI开发工具,让模型从一句相对完整的业务需求出发,直接完成一个可预览的多页面网站?
我最终选择的组合是：
- 模型服务平台：蓝耘元生代 MaaS;
- 接入模型：GLM-5.2;
- AI 开发工具：WorkBuddy v5.2.6;
- 实践任务：开发"智能团队项目协作与效能管理平台"企业官网;
- 交付页面：首页、关于我们、产品服务、联系我们;
- 技术形式：HTML、CSS、JavaScript,并启动本地预览服务.
这不是只让模型写一个代码片段,而是让它完成从需求理解、页面规划、文件生成到本地预览的完整链路.
二、接入之前,我先看了模型服务数据
模型能不能"回答问题"和能不能稳定承担开发任务,是两件不同的事.开发场景通常会带入较长的工程上下文,也可能连续修改多个文件,因此我在接入之前重点关注了上下文长度、吞吐、延迟和可靠性.
在AI Ping的 GLM-5.2 服务商数据页面中,显示蓝耘元生代提供的上下文长度为1000k;页面当时展示的输入价格为8元/百万tokens,输出价格为28元/百万tokens.右侧的最新一次监测数据为吞吐51.40 tokens/s、延迟 15.03 秒、近 6 小时可靠性 100%.
需要特别说明,单次"最新数据"容易受当时网络、排队和测试方式影响,所以我又查看了近 7 日统计.图中所示时间窗口为7月9日06:00至7月16日06:00,蓝耘元生代的吞吐最低值为 33.18 tokens/s,最高值为 78.31 tokens/s,平均值为 53.39 tokens/s.
延迟方面,近7日P90数据页面显示,蓝耘元生代对应的最低值为0.74 秒、最高值为4.13 秒、P90 为 4.06 秒.
这里不能把15.03 秒的"最新一次延迟"与4.06秒的"近 7 日 P90"直接当作同一种指标比较,因为两张图的统计口径和时间窗口不同.对我而言,这些数据的价值不是得出"永远最快"的结论,而是帮助我在正式接入前了解服务的大致表现和波动范围.
三、在蓝耘元生代MaaS创建API Key
确定模型服务后,我进入蓝耘元生代 MaaS 平台.在左侧导航栏找到"API KEY 管理",然后点击"创建API KEY".这个入口很直观,页面也明确提示 API Key 属于安全鉴权凭证,不应上传或公开分享.
创建完成后,平台列表中会显示 Key 的状态、备注、监控地址、创建时间和最后使用时间.我将备注设置为 GLM-5.2,便于后续区分用途.图中Key已经脱敏,正文也不会展示完整接口地址或任何可用凭证.
这一环节看似简单,但有三个细节值得注意：
- 不要把API Key写进公开文章、前端代码或 Git 仓库;
- 不同项目最好使用不同的 Key 或备注,方便排查调用记录;
- 如果 Key 曾在未脱敏截图中出现,应立即停用并重新创建,而不是只删除截图.
四、把GLM-5.2接入WorkBuddy
打开 WorkBuddy 后,默认任务页右下角可以选择模型.为了使用蓝耘元生代提供的 GLM-5.2,我先进入 WorkBuddy 的模型设置.
在"添加模型"窗口中,我选择"自定义/Custom".图中的窗口提示该入口支持 OpenAI 兼容协议 API,因此需要依次填写：
- 接口地址：蓝耘元生代提供的兼容接口地址;
- API Key：上一步创建的鉴权密钥;
- 模型名称：GLM-5.2;
- 高级配置：根据实际能力启用工具调用等选项.
这次实践中我勾选了"工具调用",然后保存配置.接口地址与 API Key 在截图里均已遮挡.
完成配置后回到新建任务页,模型选择区已经显示 GLM-5.2.这意味着蓝耘元生代提供的模型调用链路已经进入 WorkBuddy,接下来可以直接用自然语言下达开发任务.
五、我给WorkBuddy的官网开发需求
为了避免模型只生成一个空泛首页,我没有只输入"帮我做个官网",而是明确给出公司定位、主营业务、页面范围和视觉要求.实际输入的需求如下：
帮我开发一个企业官网,公司名称是【智能团队项目协作与效能管理平台】,主营业务是【为企业提供任务管理、项目协作、团队沟通、工时统计及工作效能分析等一体化数字办公服务】.要求：包含首页、关于我们、产品服务、联系我们页面，风格简约大气.
输入需求前,我在 WorkBuddy 中选择了"网站开发"能力,并确认当前调用模型为 GLM-5.2.
这段提示词并不长,但它包含了四类关键约束：
- 主体约束：网站属于什么类型的企业;
- 业务约束：产品围绕任务、项目、沟通、工时和效能展开;
- 结构约束：必须生成四个指定页面;
- 视觉约束：整体风格简约、大气.
如果没有页面范围,模型可能只做单页落地页;如果没有业务描述,生成的模块和文案就容易脱离实际.我的体会是,与其堆很多形容词,不如先把"谁、做什么、要哪些页面、希望什么风格"说清楚.
六、从生成代码到启动本地预览
WorkBuddy 完成任务后给出了一份成果概览.根据实操截图,本次任务耗时12分32秒,生成内容位于 website/ 目录,并启动了 http://127.0.0.1:8000 本地预览服务.
成果中列出的四个页面文件分别是：
| 页面 | 文件 | 主要内容 |
|---|---|---|
| 首页 | index.html |
首屏介绍、任务看板、核心业务、产品亮点、数据展示与行动按钮 |
| 关于我们 | about.html |
公司简介、愿景使命价值观、发展历程、团队与企业文化 |
| 产品服务 | products.html |
任务管理、项目协作、团队沟通、工时统计和效能分析 |
| 联系我们 | contact.html |
联系方式、在线留言表单、地图占位与办公地点 |
从结果说明看,页面采用 HTML、CSS 和 JavaScript 实现,加入了响应式布局、移动端导航、滚动效果、数字动画、FAQ 折叠和表单交互等内容.对一次企业官网原型开发来说,WorkBuddy 不只是返回了代码文本,还把文件结构和预览入口组织了起来.
不过,12分32秒只能代表本次任务在当时环境中的一次执行结果,不能当作所有模型、所有网络条件下都能复现的固定耗时.
七、最终网站效果复盘
1.首页:先表达定位,再展示能力
首页采用蓝白配色,首屏用"让团队协作更简单,让工作效能看得见"概括产品价值,右侧配合项目进度卡片,使"协作"和"效能"两个概念有了直观载体.页面继续向下展示任务管理、项目协作、团队沟通、工时统计、效能分析和数据安全等模块.
从信息结构看,首页遵循了"定位---能力---场景---数据---转化"的顺序,已经具备企业官网常见的完整叙事链路.导航、按钮、卡片和页脚也使用了统一的颜色与圆角风格.
2.关于我们:补足企业叙事
"关于我们"页面不是简单放一段公司介绍,而是包含愿景、使命、价值观、发展历程、核心团队和企业文化等模块.对演示项目来说,这种结构能够快速形成完整页面;如果用于真实企业,则应由企业负责人对历史、团队成员和经营数据逐项确认.
3.产品服务:围绕业务拆成五个模块
产品服务页围绕需求中的五项主营业务展开,每项能力都有单独的说明和界面示意,包括任务管理、项目协作、团队沟通、工时统计与效能分析.页面还加入开放平台和 FAQ 区域,使产品介绍不只停留在功能列表.
4.联系我们:表单、地图和办公地点齐全
联系我们页面包含客服热线、商务邮箱、总部地址、服务时间、在线留言表单、地图占位以及多地办公点.表单还区分团队规模和咨询意向,已经具备线索收集页面的基本结构.
必须强调：页面中的公司名称"智效云"、用户数量、服务企业数量、电话号码、邮箱、办公地址、团队成员和发展年份等,是本次生成式原型中的演示占位内容,不是我核验过的真实企业资料,也不应直接用于商业发布.正式上线前,应统一替换为企业真实信息,并检查隐私政策、表单去向、ICP备案、地图服务和数据合规要求.
八、这次实践中,蓝耘元生代解决了什么
如果只看最终网页,很容易把注意力全部放在WorkBuddy上.但在这条开发链路里,蓝耘元生代承担的是模型服务入口：它提供 GLM-5.2 的调用能力、API Key 管理和兼容接口,使WorkBuddy 能够调用模型完成需求分析与代码生成.
我感受到的价值主要有三点.
第一，接入路径比较清晰.从MaaS平台创建API Key,再到 WorkBuddy 选择自定义模型、填写接口地址和模型名称,整个过程没有要求我修改 WorkBuddy 源码.
第二，模型服务可以被现有开发工具复用.只要工具支持对应的兼容协议,就能把平台侧的模型能力带入熟悉的开发流程,不必重新搭建一套交互界面.
第三，模型能力真正落到了可预览产物.这次任务的终点不是一段建议,而是四个页面文件和一个本地预览地址.对开发者而言,"能打开、能检查、能继续修改"比单纯输出代码更有价值.
九、我认为仍然需要人工把关的地方
这次结果已经可以作为官网原型或演示版本,但AI完成首版并不等于项目可以直接上线.至少还要做以下检查：
- 真实性检查：替换模型生成的企业名称、团队成员、发展历程、客户数量、地址和联系方式;
- 功能检查：确认表单是否真正提交到后端,按钮是否有有效跳转,移动端菜单是否可用;
- 安全检查：确保 API Key 未进入前端文件、日志、截图和版本库;
- 兼容性检查：在不同尺寸和主流浏览器中检查排版、字体和交互;
- 上线检查：补充域名、HTTPS、备案信息、隐私政策、用户协议和统计工具配置;
- 代码审查：检查重复样式、可访问性、SEO 元信息、资源体积以及后续维护成本.
AI 开发工具更适合把"从零到第一版"的时间压缩下来,而需求责任、内容真实性、安全与上线质量仍然需要开发者负责.
十、总结:一次真正闭环的 AI 开发体验
这次实践走完了一个相对完整的闭环：
查看第三方监测数据 → 选择蓝耘元生代的 GLM-5.2 服务 → 创建 API Key → 接入 WorkBuddy → 提交企业官网需求 → 生成四个页面 → 启动本地预览 → 人工复核结果。
最终结果表明,蓝耘元生代与 WorkBuddy 的组合能够完成一次具体的网站开发任务.蓝耘元生代把模型能力以 API 形式提供出来,WorkBuddy 则把模型能力组织成开发流程,帮助我生成文件、汇总结果并启动预览.两者结合后,AI不再只是聊天窗口里的问答工具,而是进入了真实的项目执行环节.
对我来说,这次实践最有价值的地方并不是"AI 一次生成了多少页面",而是验证了一条可以继续复用的路线：先用可观测数据了解服务,再把模型接入现有工具,最后用具体任务检验效果.下一步如果继续完善,我会优先替换全部演示数据、接入真实表单后端、增加多浏览器测试,并让 WorkBuddy 根据人工评审结果进行第二轮定向修改.
相关参考资料链接
1.蓝耘元生代 MaaS 平台：https://maas.lanyun.net/
-
蓝耘科技官网产品介绍：https://www.lanyun.net/
-
AI Ping延迟测试：https://aiping.cn/
🚀真正的勇者不是流泪的人,而是含泪奔跑的人!
敬请期待下一篇文章内容
每日心灵鸡汤: 别在低回流的关系里,透支你的善良!
不要在低回流环境里过度展示自己的美好.这里的低层次,不是贫穷和学历,而是缺乏边界、感恩和规则的关系环境.很多人失败,不是因为不够善良,而是把善良给了不值得的人,把资源暴露给了只会索取的人,把真诚交给了没有回流能力的人.真正的成熟,不是变得冷漠,而是学会筛选:资源不提前暴露,帮助先看回流,善良分层投放,关系没有反馈就及时降级.因为你的时间、能力、资源和真心,都是稀缺资产,不是谁都配拥有.光不需要照亮所有人,只需要照给那些看得懂、接得住、也愿意回馈你的人.
