承渊政道个人主页❄️个人专栏:《C语言基础语法知识》 《数据结构与算法》 《C知识内容》 《Linux系统知识》 《算法刷题指南》 《测评文章活动推广》 《大模型语言路线学习》 《MySQL数据库学习》 《Python知识内容》✨逆境不吐心中苦,顺境不忘来时路!✨ 博主简介:随着大模型能力不断进入真实开发场景,AI 编程工具的价值已经不再局限于代码补全,而是逐渐覆盖需求分析、项目搭建、页面开发和本地预览等完整流程.对于开发者而言,如何选择稳定的模型服务,并将其接入熟悉的开发工具,成为提高实际工作效率的重要一步.本次实践中,我通过蓝耘元生代MaaS平台接入GLM-5.2模型,并将其配置到 WorkBuddy 中,以智能团队项目协作与效能管理平台为业务背景,完成了一个包含首页、关于我们、产品服务和联系我们四个页面的企业官网.从模型服务数据评估、API Key 创建,到模型接入、需求提交和网站生成,整个过程形成了一条完整且可验证的 AI 开发链路.本文将以开发者的第一视角,详细记录蓝耘元生代与 WorkBuddy 的连接配置、实际操作步骤、网站生成效果以及使用过程中的思考,希望为计划使用MaaS模型服务和AI开发工具的读者提供一份可参考、可复现的实践案例.废话不多说,下面跟着小编的节奏一起去疯狂的学习吧!目录一、为什么要做这次实践二、接入之前,我先看了模型服务数据三、在蓝耘元生代MaaS创建API Key四、把GLM-5.2接入WorkBuddy五、我给WorkBuddy的官网开发需求六、从生成代码到启动本地预览七、最终网站效果复盘1.首页:先表达定位,再展示能力2.关于我们:补足企业叙事3.产品服务:围绕业务拆成五个模块4.联系我们:表单、地图和办公地点齐全八、这次实践中,蓝耘元生代解决了什么九、我认为仍然需要人工把关的地方十、总结:一次真正闭环的 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/2. 蓝耘科技官网产品介绍https://www.lanyun.net/3. AI Ping延迟测试https://aiping.cn/真正的勇者不是流泪的人,而是含泪奔跑的人!敬请期待下一篇文章内容每日心灵鸡汤: 别在低回流的关系里,透支你的善良!不要在低回流环境里过度展示自己的美好.这里的低层次,不是贫穷和学历,而是缺乏边界、感恩和规则的关系环境.很多人失败,不是因为不够善良,而是把善良给了不值得的人,把资源暴露给了只会索取的人,把真诚交给了没有回流能力的人.真正的成熟,不是变得冷漠,而是学会筛选:资源不提前暴露,帮助先看回流,善良分层投放,关系没有反馈就及时降级.因为你的时间、能力、资源和真心,都是稀缺资产,不是谁都配拥有.光不需要照亮所有人,只需要照给那些看得懂、接得住、也愿意回馈你的人.
)
