上周接了个后台管理系统的UI调整需求本来预估要耗费一整个下午的活儿结果用了glm-5.3-flash之后20分钟改完核心界面API账单显示只花了1.7元。说实话这个效率有点超出预期比我手动改快了不止一个量级关键是改出来的效果还像那么回事。这篇就记录一下我是怎么用这个模型快速完成UI修改的包括具体的prompt写法、完整的操作流程、成本测算以及踩过的几个坑。先说下背景。这个需求是给一个内部运营后台的订单列表页换皮肤——不是简单的换颜色而是要把原来挤在一起的表格改成卡片式布局同时调整筛选区的排列方式还要给不同状态的订单加上醒目的标签色。这种活儿说难不难但特别琐碎尤其是涉及到多个组件和样式表的联动修改纯手动改非常费神。我一开始的打算是自己硬写改到一半觉得实在枯燥就想着干脆让大模型来试试。结果一试下来整体体验确实不错。在动手之前我对比了几条路线本地部署开源模型、用通用型大模型API、用专门的UI生成工具。最终选glm-5.3-flash主要是看中它三点一是它的长上下文能力足够覆盖一个中等规模的Vue组件文件二是它在代码生成上的稳定性比我预期要好生成的HTML和CSS结构很少出现嵌套错乱三是它的调用成本非常低而且响应速度很快改一轮UI几乎不需要等待。当然最重要的是它的API接起来毫无门槛几分钟就能跑通。这次需求是什么一份“不想干”的UI改造单1.1 需求背景先把这个任务说清楚。这是一个基于Vue 2 Element UI搭建的后台管理系统列表页原本的结构是标准的表格形式顶部一个搜索筛选区下面是一个table组件。问题出在字段太多一共有14列小屏幕上横向滚动很痛苦运营同学每次看数据都要来回拖滚动条反馈过很多次。这次要求的改动包括把表格的主展示区改成卡片流每张卡片展示一个订单的核心信息放不下的次要字段收进“更多”里。筛选区从一行平铺改成“收起/展开”模式默认只显示3个高频筛选项。订单状态从纯文字改成彩色标签不同状态用不同颜色且要符合团队现有的设计规范。分页器挪到卡片列表底部居中且要固定高度避免列表内容变化时页面跳动。说实话这种需求技术难度几乎为零就是脏活累活。唯一的难点是项目是两年前的里面有不少历史遗留的样式覆盖全局样式和组件内样式混在一起直接改容易踩到样式冲突的坑。1.2 为什么想到用AI改UI我平时也会用大模型写代码但多数是写一些独立的函数、正则表达式或者让我解释报错信息。像这种需要同时改动模板、脚本、样式三个部分还要求尽量保持项目现有代码风格的任务我一开始并不认为AI能做好。转变发生在改到一半的时候。我发现自己花了大半个小时其实一直在重复做“复制粘贴—改类名—调样式—看效果”的机械操作。这个过程中几乎没有需要动脑的地方那为什么不把这段工作交给AI呢于是我把项目相关的代码片段、需求描述和约束条件整理出来丢给了glm-5.3-flash让它先出一个改版方案。结果它给出的方案在整体思路上很合理包括卡片信息的层级怎么排、收起展开怎么实现、状态标签用什么颜色体系都考虑到了。这让我决定继续往下试。工具选型为什么是glm-5.3-flash而不是别的2.1 对比过的几条路线在确定用这个模型之前我花了十几分钟评估了其他选项。第一条路是用本地开源模型。我电脑配置一般跑7B级别的量化模型都费劲生成速度慢不说效果还不太稳定。让它写个简单函数可以让它保持长上下文的代码结构一致就很难了。改UI恰恰需要模型记住前后文的类名、变量名和样式变量一旦记混了生成的代码基本没法用。第二条路是用通用的商业大模型API。这类模型对话能力很强但价格相对高一些。按照这次任务的token消耗量估算用通用模型的成本大约是3到5倍虽然绝对花费也不算多但既然有更划算的选择没必要多花钱。第三条路是UI生成工具比如各种AI设计转代码平台。这类工具适合从零生成漂亮的页面但不太适合“在现有代码上做局部调整”因为它们不理解你项目里的组件库和现有代码结构。如果我用这类工具几乎等于整个页面重新做迁移成本太高。最终我选择了glm-5.3-flash。从实际效果来看它在代码类任务上的针对性确实做得比较足尤其是对现有代码片段的遵循程度比通用对话模型更可靠很多细节不需要我反复提醒它也能自己保持住。2.2 flash版本的优势GLM系列本身有几个不同规格的版本。这次用的是5.3-flash这个版本的特点在名字里就写得很明白——flash快。响应速度确实快。我统计了一下从发出请求到收到完整响应平均在10到15秒之间即便是我一次性给了它几十行现有代码作为上下文也没有出现长时间等待的情况。这种速度在来回调优的交互场景里很重要等得越久人的耐心就越少越容易放弃多轮迭代。价格方面更是便宜。我这次一共做了4轮对话累计消耗的token量如果按官方API定价折算下来总成本才1.7元。这种量级的费用用“几乎免费”来形容都不夸张。不过我也要说句公道话flash版本不是没有短板。在特别复杂的逻辑推理上比如需要设计一个完整的状态机或者写一个涉及多层继承的组件它就不如更大规格的模型。但在UI修改这个场景里绝大部分工作都是结构替换和样式调整并不需要太深的逻辑推理能力flash版本的能力边界刚好覆盖住了需求。2.3 环境准备与调用方式我实际使用的是API调用方式整体环境搭建时间不超过5分钟。官方提供的SDK安装很简单pip install zhipuai然后设置API Key写一个最基础的调用函数from zhipuai import ZhipuAI client ZhipuAI(api_key你的API Key) def chat_with_glm(messages): response client.chat.completions.create( modelglm-5.3-flash, messagesmessages, temperature0.3, ) return response.choices[0].message.content温度参数这里我特意设置了0.3因为修改UI代码这个任务需要的是精确和稳定不希望模型有太多创造性发挥。如果设成0.8甚至更高生成的代码风格可能会飘出现一些“看起来很有想法但实际没法用”的写法。第一轮对话的时候我直接把相关代码喂给模型并告诉它我需要哪些改动。有一个小技巧是喂给模型的代码不需要是整个文件只要把模板部分和样式部分的关键代码段截取出来就行。描述得越聚焦模型的输出就越不容易跑偏。20分钟实操从接到需求到提交代码3.1 第一步把需求转成清晰prompt这一步是整个流程里最重要的一环prompt写得好不好直接决定了后续要改几轮。我见过很多人用AI改UI失败原因是prompt写得太过模糊比如“帮我美化一下这个页面”“把界面改得好看一点”。这种描述模型根本无法执行AI不是人它不知道你心里的“好看”是什么标准它只能根据有限的词汇去猜结果自然不可控。我给glm-5.3-flash的prompt分成了四个层次背景信息说明这是一个Vue 2 Element UI项目现有代码是什么结构。问题描述明确当前页面存在的问题是什么比如表格列太多、筛选区太占空间。需求清单用编号列出每一条具体的改动要求越细越好。约束条件哪些不能动比如“保留现有的分页接口逻辑”“不要改动状态字段的取值”。当时我实际使用的prompt大致如下这是一个Vue 2 Element UI的后台订单列表页。以下是当前页面的模板代码和样式代码[代码粘贴] 当前存在这几个问题 1. 表格有14列小屏下横向滚动严重需要改成卡片式布局。 2. 筛选区字段太多希望默认收起只展示前3个其余放到展开区域。 3. 订单状态目前是纯文本需要改成彩色标签状态值为success、pending、failed、cancelled。 4. 分页器需要在卡片列表底部居中显示。 约束条件 - 保留现有请求数据和分页逻辑不要改动脚本部分。 - 颜色需要延续项目现有的主题色不要引入新的色系。 - 不要使用任何新的依赖包。这样的prompt信息密度很高模型只需要做一件事——把现有代码按照需求清单翻译成新代码。它不需要猜也不需要创造成功率高了很多。3.2 第二步多轮对话改UI第一轮反馈下来的结果基本达到了80%的预期。模型把表格整体替换成了卡片流筛选区的收起展开逻辑也实现了状态标签用了Element UI的tag组件颜色分配也很合理。剩下的20%问题包括几个细节卡片里的商品信息排列有点乱主次不分明。收起筛选区时没有加过渡动画展开收起比较生硬。卡片点击区域没有关联到详情跳转事件。这些问题都是小修小补也不需要再写复杂的prompt直接针对问题让模型改就行。比如第二条我直接问筛选区收起来的时候太突兀能不能加一个简单的展开收起动画保持在Element UI现有能力范围内实现。模型给了基于el-collapse-transition组件的方案正好是这个项目已经在用的组件改动量很小。第二轮、第三轮都是这样的小调整每轮响应时间基本在10秒左右整体体验非常流畅。3.3 第三步手动收尾AI虽然完成了我期望的大部分改动但最后的代码检查是没法省掉的。原因很简单模型理解的是“代码的语义”但它看不到“页面渲染出来的真实效果”。有些问题在代码层面看不出来必须要跑起来才能发现。举个例子改完卡片布局后我在浏览器里检查发现卡片容器在中等屏宽下出现了换行错位的问题。原因是卡片的最小宽度和容器的栅格宽度没有对齐。这种问题纯粹是响应式细节模型很难光靠代码想象出所有屏幕宽度下的表现。所以我手动给卡片容器补了几行媒体查询确保不同屏宽下都能正常排列。这个手工修复花了大约3分钟是整个流程中唯一需要我亲自动手的地方。除此之外我还检查了一遍模型生成的代码确认没有引入额外的依赖也没有破坏原有的数据绑定逻辑。检查通过之后直接提交到分支完成了这次改动。3.4 时间线与成本记录最后梳理一下这次操作的耗时分布整理需求与写prompt约8分钟第一轮AI生成约15秒等待人工检查约5分钟第二轮、第三轮细节调整每轮约2分钟人工交互手动修复响应式问题约3分钟浏览器验证与最终检查约5分钟从动工到提交代码总共花了差不多20分钟。成本明细API账单显示累计消耗了大约130万token的输入和8万token的输出折算费用1.7元。说实话这个数字让我对AI辅助开发这种模式的可行性有了新的认知——过去总觉得“AI写代码”是大公司才会认真考虑的事但这个成本水平个人开发者也可以完全无压力地用起来。成本拆解1.7元到底花在哪了4.1 Token用量与定价逻辑很多人可能会好奇为什么这次改动这么便宜。这里简单算一笔账。我每次调用都要把当前的代码片段、之前的对话历史、以及当前的需求描述一起发给模型作为输入所以输入token的消耗量远大于输出token。第一次请求发了比较多的代码大约是3万token的输入加上需求描述和之前的对话记录后续每轮调用输入token也会在2万到3万左右。输出端则相反AI生成的代码每次只有几百到一两千行按token算大概每次1到2万。累计下来输入约130万token、输出约8万token。按照glm-5.3-flash的API定价——输入价格远低于输出价格而且flash版本本身就主打低价——这次总共1.7元在合理范围内。对比一下如果这个改动完全用人来写按照我当时的效率至少需要2到3小时。按开发成本折算这两三个小时的价值远超1.7元。所以在我看来这1.7元买到的不只是“改完UI”这个结果更重要的是省出的2个多小时时间成本。4.2 什么时候适合用AI改UI有了这次成功体验后我也在思考这个方法的适用边界。不是所有UI需求都适合让AI来做下面几类场景效果最好局部样式调整改间距、调整字体大小、替换颜色、调整布局方式这类需求规则清晰AI很容易理解。组件替换比如把表格换成卡片把下拉框换成单选按钮组。只要给出现有代码和明确的目标结构AI能生成很工整的代码。页面风格统一当你有一个标准的页面模板想让多个页面保持同样的风格可以让AI参照模板代码批量修改。不适合的场景则包括需要高度定制交互动效的页面、涉及复杂状态管理的组件重构、以及依赖大量设计稿精确还原的页面。这类任务还是需要人工精细控制。4.3 免费额度与成本控制这次用完我还特意看了下平台的免费额度情况。新用户通常会有一定的免费token额度足够支撑小规模的UI修改尝试。如果只是临时体验一下其实连1.7元都不用花。但如果是要长期用建议还是按量付费毕竟自由度高很多不用担心额度用完。成本方面也不必担心从这次实测看即使每天改一个类似规模的页面一个月的花费也就几十块钱对个人开发者来说完全在可接受范围内。踩坑记录AI改UI的典型翻车现场5.1 框架风格不匹配第一次用AI改UI时踩过最大的坑就是模型没有遵循项目现有的组件库规范生成了大量自定义DOM结构和内联样式。比如项目里明明用的是Element UI正常情况下应该用el-collapse-transition来实现折叠动画但第一版方案它给的却是手写的transition和transform代码。不是说代码有问题而是风格和项目其他部分不一致看代码的时候会有很强的割裂感后续维护也困难。这个问题在prompt里加一句“优先使用项目现有的XXX组件库规范”就能有效缓解。如果项目里针对某些组件有二次封装最好在prompt里把封装的组件名和用法也交代清楚。5.2 上下文太长被截断在一次尝试中我图省事把一个完整页面的所有代码模板、脚本、样式加起来大概5000多行一次性喂给模型结果它只回复了一半就停了后半段直接没生成。查了下原因应该是超出了上下文窗口限制。这个坑的解决办法很简单拆块。一个页面不要整体上而是按功能区块拆成头部筛选区、主体列表区、分页区域三个部分分别让AI生成然后自己简单拼接对齐。这样既不会超长生成效果也更稳定因为模型在短上下文中更容易保持代码一致性。5.3 样式覆盖失效还有一个很经典的问题生成的代码在本地跑不起来样式完全没有生效。排查后发现根因是项目里有一个全局样式文件给某个元素设了很高的优先级。AI并不知道这个全局文件的存在所以生成的局部样式没法覆盖全局样式。解决方式有两种。一种是在prompt里提醒模型“注意项目存在全局样式覆盖建议使用BEM模式命名类名避免冲突”这种做法能在一定程度上减少覆盖失败的概率。另一种是手动给关键样式加上特定的选择器权重或使用样式隔离方案。这个部分没有固定解法需要根据项目的具体情况来处理。5.4 排查方法总结如果AI生成的UI代码效果不对我建议按这个顺序排查看浏览器控制台有没有报错如果是JS报错打断渲染先解决脚本问题。确认组件是否真的被渲染出来打开Vue Devtools看组件树确认结构正确。检查样式表是否被加载切换到Sources面板看对应的CSS文件是否包含期望的规则。对比需求的描述和最终代码的差异有时候是模型理解偏了调整prompt重新生成甚至不如自己手动改两行来得快。这四步能解决绝大多数AI改UI的诡异问题。5.5 几条独家技巧最后分享几个我实际操作中总结出的技巧。第一改动之前先拍照或截图记录原始效果。AI改完代码后对比“改前”和“改后”的渲染效果差异能快速发现AI无意中改坏了的地方。第二要求AI只输出变动部分的代码而不是全部代码。在prompt里明确“只输出需要修改的template片段和对应的style片段不要输出完整文件”。这能让输出变得更短减少token消耗同时降低模型在生成不相关内容时引入错误的风险。第三如果一个需求的改动点超过5个不要指望一次对话搞定。拆成2到3轮每轮聚焦2到3个改动点效果远好于一次性要求所有改动。模型在小步快跑的交互模式下出错的概率低得多。第四每次生成完代码后务必在本地跑一遍dev server确认效果。AI不可能替你做视觉验收最终的渲染效果还是需要用人眼来判断。这次改完UI之后我最大的感触是AI写代码这件事正在从“玩具”变成“工具”。尤其是像glm-5.3-flash这种低价高响应速度的模型把AI辅助开发的门槛拉到了几乎为零。以后遇到类似的大型UI调整第一反应不会再是挽起袖子硬写而是先想想这活儿能不能分工出去——AI出初稿我做审核和收尾这才是效率最大化的协作模式。