1. 先聊清楚这次到底在解决什么问题说起来挺有意思我在浏览器里刷到一条帖子问的是“AI 到底能不能自己把一个看得见的 UI 设计稿变成能跑的小程序代码”。底下评论吵成一锅粥有人说 AI 生成界面早就是标配了有人说生成出来全是“豆腐块工程”压根没法用。我手上的活正好撞在这个问题上——新项目的用户端需要一个微信小程序的登录页设计搞定了但前端排期排到两周之后。我等不了那么久于是动了“用 Codex 把即时设计里的登录页 UI 自动变成代码”的念头。先交代下背景。这里说的 Codex 是 OpenAI 出的 AI 编程助手它的工作逻辑和普通对话式 AI 不太一样更像一个“能读代码库、能自己动手改文件”的编程智能体。你可以让它直接在一整个项目里做深度修改而不只是像聊天框那样一问一答给你几段代码。而即时设计是国内团队做的在线 UI 设计工具和 Figma 属于同类产品优势在于国内直连、中文环境友好、支持多人协同。这两个东西凑一块儿能不能解决我的痛点我的痛点很具体设计那边已经输出了一张完整的小程序登录页设计稿包含手机号输入框、验证码按钮、登录按钮、协议勾选还有底部的第三方登录图标。我要做的事情是让 AI 不仅仅“照着截图生成一坨静态 HTML”而是真正理解设计稿里的布局、间距、组件层级然后在小程序项目结构里生成一套能用的、符合 WXML/WXSS 规范的页面文件。这个目标听起来不复杂但里面埋了很多坑。比如AI 能不能从小程序设计稿的“图片”里精准提取颜色值和字号AI 能不能正确使用小程序独有的button、input组件而不是生成一堆divAI 生成出来的rpx单位换算准不准页面里的交互逻辑比如获取验证码倒计时、勾选协议它会不会顺带写好带着这些问题我花了大概一天半时间完整跑了一遍“设计稿 → AI 阅读理解 → 自动生成 → 人工修正”的流程。这篇文章就是这次全过程的记录包括我用到的工具链、每一个关键操作步骤、踩过的坑以及最终这套流程到底可不可复制的判断。如果你也面临“设计图有了但前端排期不够”的处境这篇文章应该能让你少走不少弯路。2. 为什么选 Codex 即时设计而不是别的方案2.1 Codex 和普通 AI 编程工具有什么本质区别在开始之前我觉得有必要把 Codex 的工作方式讲透。拿大家最熟悉的 ChatGPT 来对比ChatGPT 是一个“建议者”你给它一个问题它给你一段回答但如果这段回答里包含了改动五个文件的要求你得自己把每个改动手动复制到对应位置。Codex 在这一点上完全不同它被设计成一个“执行者”你授权它可以读取仓库文件、修改代码、执行命令、运行测试它是一个完整的 agent。实际用下来的体验差异非常大。你给它一个任务比如“把项目里的登录页改成这种风格”它会自己去翻找相关的 WXML 文件、去查 app.json 里的页面注册配置、去全局样式文件里确认颜色变量改完之后还会跑一遍检查脚本。这个体验和过去“AI 输出代码片段、人来做整合”的方式相比少了大量机械搬运工作。再说为什么选 Codex 来生成小程序代码而不是通用的 Web 代码生成工具。小程序本身有很强的生态封闭性它的样式单位是rpx它的组件是view、text、input、button它的登录逻辑绕不开wx.login和wx.getUserProfile它甚至连事件绑定都长这样bindinputhandleInput。这些细节刚接触小程序的人可能意识不到但如果 AI 不懂这套规则生成出来的东西基本就是废的。Codex 的优势在于它能够通过读取项目文件来“学习”当前项目的技术栈和约定。只要你给它一个真实存在的小程序项目它就能从现有代码里推断出该用rpx还是px、该用wx:for还是Array.map而不是照搬 Web 开发的习惯。这一点在后面的实操中多次得到了验证。2.2 即时设计在这场流程里的不可替代性很多人会问既然是要让 AI 写代码那我直接给 AI 一张设计稿截图不就行了吗何必还要用即时设计。这个问题的答案藏在小程序的 UI 还原精度要求里。登录页作为小程序最基础的页面之一看着简单实际还原起来很抠细节输入框的 placeholder 颜色、验证码按钮的倒计时态灰色禁用、文字变化、协议勾选的对勾是否垂直居中、底部图标和文字之间的间距……这些细节如果只靠一张位图截图AI 很难精确提取。设计稿文件里藏着的信息远比截图多字号、行高、边框圆角、背景色值、内边距、甚至组件切图资源。即时设计在这条链路里承担的角色是作为“信息提取层”。我把设计稿的链接分享给 Codex 的会话——没错实践发现这种做法是可行的——Codex 可以直接查看设计稿中各个元素的结构和样式数值。相当于你把一张“只有图”的设计稿变成了一份“标注好尺寸和颜色的零件图纸”AI 能读到的信息量和准确度完全不一样。如果有人此刻用的是 Figma 或其他设计工具思路也是通用的核心在于“让 AI 读取设计文件的结构化信息”而不是喂一张截图了事。至于为什么我这次选择即时设计纯粹是因为项目组的协同已经在这个平台上了国内环境访问稳定、分享权限也方便控制没有额外的迁移成本。2.3 为什么选择“登录页”作为试水项目坦白说拿登录页作为 AI 自动生成 UI 的首个试水目标是刻意为之的。原因很简单登录页是小程序里结构相对标准、交互边界清晰、出镜率最高的基础页面之一它的信息层级不复杂但对代码规范的要求很高。说得专业一点登录页是一个很好的“AI 生成能力基准测试用例”。它会逼着 AI 处理这样几类典型问题如何处理输入框的状态管理如手机号位数限制、验证码发送后的倒计时禁用如何处理条件渲染协议勾选前按钮置灰如何组织表单提交逻辑如何处理设计稿中不存在的“交互态”需求。这些问题是任何小程序 UI 页面都绕不开的基本功。如果你的目标是测试 AI 到底能不能干活别一上来就让它生成数据可视化大屏或复杂交易页面那属于“地狱难度开局”。从标准页面入手你才能更清楚地判断哪些环节 AI 表现得像专家哪些环节它还是一个“玩具”然后用最小成本建立一套自己可控的协同流程。3. 前置准备搭建可用的小程序环境和 Codex 环境3.1 准备一个可以被 Codex 操作的小程序项目骨架这一步是整个流程里最容易被忽略、也最容易导致翻车的环节。很多人拿到 Codex 之后第一反应是找一个空目录让 AI “从零开始生成一个完整小程序”。我个人实测下来这个做法的成功率很低。原因在于小程序项目的“约定大于配置”色彩非常重project.config.json里的appid、miniprogramRoot路径、sitemap.json文件这些东西如果缺失AI 生成的代码无法在微信开发者工具里顺利跑起来。更稳妥的做法是先手工创建一个最小可运行的小程序项目骨架让 AI 在这个已有框架内“填充页面”而不是让它从零搭建整个项目。操作上我习惯在微信开发者工具里新建一个“不使用云服务”的空白模板项目确认首页能正常编译运行之后再把这个项目目录交给 Codex。创建完之后有几个文件结构上的关键点值得确认。第一app.json里需要注册页面路径Codex 新增页面文件时如果它不主动修改app.json小程序运行时会找不到页面第二project.config.json里建议设置compileType: miniprogram这能保证开发工具的行为更可预期第三尽量在项目根目录放一个README.md里面用文字说明“这是一个微信小程序项目使用原生框架样式单位是 rpx”这个信息对 Codex 调整生成风格很有帮助。3.2 Codex 的安装和会话配置要点说完了项目再聊聊 Codex 环境。Codex 的安装方式在其官方文档里有详细说明我这里只强调几个实际使用中的关键经验。Codex 的命令行工具安装之后一般是通过在项目目录下启动交互式会话来使用它会基于当前目录的代码上下文来理解任务。这意味着你在启动会话前最好先cd到项目根目录然后再开启新会话。在会话里我通常会在第一轮先给出一段“系统提示词”——这一步决定了整个任务的方向所以我会写得格外仔细。比如这样一段话当前项目是一个微信小程序原生项目使用 WXML WXSS JS 构建项目内页面均采用 rpx 作为尺寸单位。 请先阅读项目内 app.json 和现有页面的代码理解项目的目录结构和代码风格。 接下来我会给你一个设计稿链接请你根据设计稿生成一个新的“登录页”页面路径为 pages/login/login。这段提示词传达了几个关键信息技术栈是什么、尺寸单位是什么、我期望的行为是什么先读项目、再动手。Codex 对这种“先探索、后执行”的指令响应得相当好生成代码前它会自动阅读项目文件整体产出质量比“跳过上下文直接生成”高出一个量级。另外我强烈建议在首次对话就把“多检查、少臆断”的原则写进去。比如要求它“生成完页面后检查 app.json 中是否已注册新页面路径如果没有请自动补充”。这类显式的指令能有效减少生成完成之后“页面白屏”这类低级但烦人的问题。3.3 获取并整理设计稿链接设计稿环节有一个很容易踩的细节链接权限。Codex 去读取即时设计页面时相当于一个“外部访客”在访问你的文件所以你必须确保分享出去的链接是“任何人可查看”的状态而不是“仅项目成员可查看”。否则 Codex 抓取到的内容会是“无权限访问”整个对话就卡在这一步了。在即时设计中正确的操作方式是在文件分享设置里选择“获得链接的人可查看”并复制出分享链接。把链接发给 Codex 时建议把它粘贴到对话中间靠前的位置不要在长篇幅的描述之后才给出链接因为 Codex 的注意力范围有限链接位置越靠前后续生成时引用设计稿信息的概率越大——这是我跑了多轮之后总结出来的结论。顺带说一句如果设计稿还没有最终定稿建议等设计稿状态标识改为“已定稿”之后再启动生成流程。原因很实际AI 读取和生成代码是有时间成本的如果设计侧还在频繁调整颜色和间距你把“最终稿”喂给 AI 没几个小时又变了反复重跑的时耗远不如等设计稳定一天再动手。4. 实测全流程从设计稿到小程序登录页的完整落地4.1 第一步让 Codex 读懂设计稿结构我的工作流程是从一句非常具体的指令开始的请先查看这个设计稿https:// 即时设计分享链接 这是一个小程序的登录页面。请简要描述你在设计稿中看到的整体布局结构并明确指出页面包含哪些模块各模块的配色、字号、间距等关键设计数值。这个“让 AI 先描述所见”的动作看起来多此一举其实是整个流程中最关键的一道质检关卡。AI 如果连设计稿里有哪些模块都说不清楚、颜色数值都提取不对那么后续生成的代码必然跑偏而且这种跑偏会被埋藏在大量代码里最后排查起来极其痛苦。我实际跑下来的结果是Codex 对设计稿的解析相当到位。它清楚地识别出了页面从上到下依次是顶部的品牌 Logo 和标语区、中部手机号输入框和验证码获取按钮组成的表单区、底部的登录按钮、协议勾选区域、以及分隔线下面的“其他登录方式”区域。同时也提取到了几个关键色值主按钮背景色是#3478F6协议勾选状态下文字的颜色是#666666主标题字号是48rpx等等。这个描述和我自己在设计稿里肉眼看到的基本一致。有一说一这种结构化描述的准确度已经超过了市面上多数“图片生成代码”工具的水平它更像是一个谨慎的初级前端在看设计稿干活。如果你的项目要求更高精度比如视觉走查严格到 2px 偏差建议在让 AI 生成代码之前先明确要求它“将设计稿中所有颜色数值整理成表格输出”这样可以顺手生成一份可直接给团队其他成员同步的颜色规范。4.2 第二步制定明确的生成约束AI 生成代码时最大的风险不是“它不会写代码”而是“它以自己最熟悉的方式写代码”而这个方式不一定符合你项目的规范。所以在让 Codex “开干”之前我通常会在提示词里做一次“约束收敛”把生成规则一次性说清。我这次给出的约束是这样写的请按照以下规则生成登录页面 1. 必须在 pages/login/login 路径下创建 login.wxml、login.wxss、login.js、login.json 四个文件。 2. 全部尺寸使用 rpx 单位颜色只能使用设计稿中提取到的色值禁止自行发明新颜色。 3. 手机号格式校验规则11位纯数字输入框限制最大长度为11位。 4. 获取验证码按钮在未输入有效手机号时保持置灰点击获取验证码后进入60秒倒计时状态按钮文字随倒计时变化。 5. 登录按钮在协议未勾选时保持置灰点击登录时先校验协议状态未勾选时弹出 wx.showToast 提示。 6. 代码风格参照本项目已有页面比如 pages/index/index.wxss 的风格。这些约束背后都有明确的意图。第 1 条是路径约定小程序页面必须有四个配套文件漏一个就报错第 2 条是防止 AI 自由发挥替换颜色设计还原的第一步就是颜色准确第 3、4、5 条是把“设计稿里看不到的交互细节”显式补全因为设计稿通常是静态的而登录页这类页面交互状态极多AI 如果不被告知状态规则它可能会忽略置灰和倒计时的实现第 6 条是为了让代码风格和已有页面统一方便后续维护。这段提示词的效果比我想象中还要直接。Codex 在生成代码时真的会先打开pages/index/下的文件模仿了项目已有的命名风格和样式组织方式生成出来的界面代码和项目原有代码放在一起几乎看不出是两拨人写的。4.3 第三步一次真实的辅助生成过程回放下面把具体的对话过程回放出来让大家直观感受一下 Codex 的工作状态。第一轮对话我发出的是“解读设计稿”的指令Codex 返回了一段结构化的页面描述和设计数值表。我在逐项核对无误后紧接着发起了第二轮指令也就是上面那段“生成约束”。Codex 收到后先是阅读了app.json和pages/index目录下的文件然后开始创建登录页的四个新文件。大概过了不到一分钟Codex 返回了第一版页面代码。我选择了“查看 diff”来检查它的改动内容。从 diff 里可以看到它自动在app.json的pages数组里添加了pages/login/login这一步帮我省了手动修改的时间。生成的四份代码文件初看结构和思路是对头的login.wxml使用了view、text、input、button等小程序原生组件login.wxss里大部分尺寸也是rpx结尾的。但说实话第一版代码拿到手我并不急着直接进微信开发者工具预览因为有些问题在代码层面就能看出来。比如我注意到它的“验证码倒计时”逻辑写在Page对象外面定义了一个全局定时器变量这种做法在只有一个使用实例的时候没问题但小程序的 Page 实例在 cool reload 时可能被重构定时器变量容易丢失。这个属于“能用但不推荐”的范畴。我把它作为一个反馈意见发给了 Codex倒计时逻辑建议写进 data 里管理同时确保页面卸载时清除定时器。请在 Page 的 onUnload 中清除定时器。Codex 对这个反馈的处理非常快直接更新了login.js文件把计数器变量和clearInterval逻辑都加了进去。这种“能听懂修改意见并落实”的体验是单纯“生成一把梭”的 AI 工具完全做不到的也是 Codex 这类 agent 工具最值钱的地方。4.4 第四步人工走查与调整的四个检查点代码生成完毕之后我习惯性地进入“人工走查”环节。所谓人工走查就是不开微信开发者工具直接用肉眼和基础逻辑去检查代码里有没有明显问题。这一步不是不信任 AI而是尊重一个现实AI 写的代码和同事写的代码一样需要 code review。我这次走查重点看了四个地方这里也分享给大家第一login.wxml里的事件绑定。小程序的事件绑定语法是bindinput、bindtap、catchtap这类如果 AI 误用了 Web 习惯的onClick或addEventListener运行时会直接报错。我检查的结果是 Codex 全部使用了正确的绑定语法。第二login.wxss里的单位。小程序的rpx是自适应单位设计稿一般是 750px 宽的画板所以 AI 从设计稿里直接把px数值抄过来理论上 1:1 还原。但有些地方如果提取到的是小数比如17.5px生成的rpx就会是17.5rpx这在渲染上没问题但不够整洁。我在检查时顺手把这些数值做了取整处理。第三login.js里的data结构。因为登录页涉及输入框受控组件模式所以phone、code、agreed、countdown这些字段必须都预先定义在data里。AI 在第一版生成时漏掉了agreed字段的默认值导致页面首次渲染时勾选状态是undefined好在这个问题在代码走查时被我发现了手动补上之后运行正常。第四login.json文件。小程序的页面配置文件里可以设置页面标题、导航栏样式等。我要求页面标题显示为“登录”并且背景色和设计稿保持统一。Codex 第一版生成时没有设置导航栏自定义样式我补充了一条指令后它顺利加上了navigationBarTitleText: 登录。这轮走查花了大概二十分钟。二十分钟的人工检查避免了后续在“开发者工具白屏”和“控制台报错”之间反复横跳这笔时间花得非常值。4.5 第五步微信开发者工具中的运行验证代码走查通过之后我把项目目录重新导入微信开发者工具顺利看到登录页渲染了出来。第一眼的视觉效果相当不错顶部 Logo 和标语居中展示手机号输入框的边框和圆角与设计稿基本一致主按钮的蓝色用的是#3478F6勾选协议的文字说明也能看清。简单测试了几条核心交互链手机号输入框输入 11 位数字后验证码按钮从置灰状态变为可点击状态点击“获取验证码”按钮进入倒计时文字从“获取验证码”变为“60s 后重新获取”不勾选协议直接点击登录wx.showToast正常弹出“请先阅读并同意用户协议”勾选协议后再点登录控制台输出登录流程触发了后续的wx.login逻辑预留。这轮测试跑下来页面本身的功能闭环是完整的没有出现事件冲突或数据同步的严重 bug。从“拿设计稿”到“页面能跑”这次完整流程中途还穿插了两三处修改和重新生成总体耗时控制在半天以内。这个速度如果用传统“人工照着设计稿写页面”的路径来估算大致要一个全职前端一天半到两天还不含联调和走查。AI 带来的效率提升是实打实的。5. 实战中容易掉进去的坑三个“看着小、影响大”的教训5.1 设计稿链接权限不足导致 Codex 读取失败这个坑发生在我第一次尝试和 Codex 协作时。我把即时设计里面的文件链接直接粘贴给了 Codex心想设计稿就在那里它应该能自己看到。结果 Codex 返回的信息非常有限它说“无法访问该页面内容”我一开始还怀疑是工具限制后来排查才发现是即时设计的分享链接设置为“仅项目成员可查看”。解决方式有两种大家可以按自己的安全要求选择。如果你的设计稿不涉及机密信息最省事的方式是直接把分享权限调整为“获得链接的人可查看”如果设计稿包含未公开的产品信息不想完全公开也可以单独复制一个只包含登录页的 frame 链接在即时设计里对单个画板创建分享链接这种分享方式在安全上更收敛一些。这个问题的教训在于AI 工具的访问权限体系和普通浏览器不同你不要默认“我在浏览器里能看到的AI 就一定能看到”。拿一个单独链接先在另一个浏览器的无痕窗口里测试一下能否正常打开就能避免不少白费的对话轮数。5.2 用“px”还是“rpx”AI 的初始假设总是错的第一次让 Codex 直接生成登录页时它在 WXSS 文件里混用了一部分px单位。这些Text组件之间的间距或者细边框它是用px写的。在 iOS 设备上px在小程序中不会自适应缩放看起来可能和设计稿接近但在安卓机型上不同屏幕宽度会导致这些px单位元素显得偏大或偏小视觉上就会“走样”。根治这个问题的方案不是靠“逐条修改”而是在前置提示词里加一条强约束“全部尺寸使用 rpx 作为单位除非是 1px 的细边框线这类场景可以保留 px。” 有了这条约束之后后续生成的样式文件里的单位就基本没有混用的问题了。顺带说一句即使是1px细边框在小程序里也建议用rpx配合transform: scaleY(0.5)实现否则部分安卓机上看起来会特别“粗壮”。这些细节如果 AI 不提人工走查时也容易忽略。5.3 AI 生成的“按钮”组件可能是 Web 思维有一个特别有意思的问题Codex 在“登录”按钮上第一版用的是button组件这是对的但它在“获取验证码”按钮上也用了button组件并且里面塞了一个input组件的兄弟结构不对它实际上是把“获取验证码”做成了button把手机号输入框做成了input整体看起来没问题。真正的问题出在“协议勾选”的交互上。Codex 第一版用了view组件加catchtap事件来模拟勾选状态这在小程序里其实完全可以但因缺少aria无障碍标签部分辅助功能无法识别这个区域是“可交互控件”。按小程序无障碍访问的最佳实践这种语义化的问题在代码走查阶段很难靠肉眼发现容易在内部测试时才被提出来。解决方案是在走查的时候专门检查所有可点击元素确保它们要么是button组件要么在view组件上添加hover-class和合适的语义属性。这个优化点严格来说不算 bug但它直接关系到小程序的体验完整度和审核质量。6. 工具链选型盘点Codex 的能力边界和替代方案6.1 Codex 在小程序场景下的能力边界经过这轮完整实战我对 Codex 在小程序 UI 生成场景下的表现有了更具体的认识可以归纳成一张“能做什么、不能做什么、做得一般般”的表格能力类型表现使用评价读取设计稿结构并提取数值能准确识别布局、色值、字号非常强值得依赖生成标准原型页面代码结构完整组件用词规范可用需人工走查处理交互状态能在指令下实现置灰、倒计时等依赖提示词约束的质量项目内代码风格统一会阅读已有文件后模仿表现超出预期接管复杂业务逻辑登录鉴权、数据请求、路由跳转能写但需要详细设计输入这里单独说下数据请求和页面跳转的体验。我让 Codex 生成的登录页只是 UI 呈现和前置校验实际的wx.login换取 code、后端登录接口调用、跳转主页逻辑等我是用“预留接口”的方式让 Codex 生成一个handleLogin空壳方法里面的具体实现由我来写。不是 Codex 写不了而是这些逻辑和业务强相关项目里的 API 封装、错误码处理规则 AI 无法从设计稿里读到让 AI 硬写反而会创造出大量“假逻辑”。6.2 如果不用 Codex还有什么组合能用肯定有人想问“我不想装 Codex有没有别的工具能做类似的事” 我实测后可以说市面上有一些平替方案但各有取舍。如果你用的是即时设计可以试一下即时设计自带的“设计转代码”能力它可以直接把设计稿导出为 HTML/CSS 代码但导出结果的组件语义化程度不高很多标签需要手动改成小程序的view、text。这个方案的场景定位是“拿 HTML 作为参考实现”并不是“直接生成可运行小程序”。如果你比较熟悉 Comfy UI 或者 Stable Diffusion 这类图像生成工具也可以先把 UI 截图做视觉美化再用该图像上标注识别数据来辅助开发建模但这个路径适合设计探索不适合“像素级还原”建议还是让位给专业设计工具和生成 agent 的组合。相对成熟且轻量的路径是在 Codex 这类 agent 工具上再加一层“自定义小程序 UI 组件库”。比如我把项目中常用的按钮、输入框、单元格、弹窗封装成了独立的组件文件后续再让 Codex 生成新页面时会要求它优先引用这些组件而不是重新生成基础元素。这条路走通之后生成效率会再上一个台阶而且代码一致性更好。6.3 一个小建议别让 AI 独自完成“设计到代码”的最后一公里写到这里我忍不住想给后来者泼一盆冷水用 Codex 自动生成 UI最强的地方其实不在“最终代码”而是在“第一条骨架代码”的快速成型最需要人工介入的环节也不是生成本身而是“设计稿和交互规则之间的信息补全”和“代码走查”。很多交互细节在静态设计稿里是不可见或二义性的。举几个例子验证码按钮在未输入手机号时是否置灰点击登录时协议未勾选是否应该出现轻提示手机号输入框应该用什么键盘类型这些问题Codex 无法从设计稿里读到它只能从你的指令里读到。如果指令里没提它就会猜而猜的准确率完全取决于它的训练数据里“同类项目一般怎么处理”的统计结果。所以在图稿之外给每一个“显式交互状态”列出规则才是指挥 agent 的正确姿势。代码走查则是兜底的防线。我不建议把 AI 生成的代码未经 review 就推到仓。毕竟 AI 的“自信”不代表“正确”它生成的代码也许能跑但潜在里可能存在定时器泄漏、事件绑定隐患、外部依赖缺失等问题。AI 解放了你的“写码手”但从来不会替代你的“走查眼”。7. 这次全流程跑完我对 AI 辅助 UI 开发的感受流程跑完之后我盯着屏幕上那个登录页看了好一会儿。有一瞬间我确实恍惚了一下这个页面从设计稿到可运行的小程序页面我只写了不到三十行代码。剩下的是 Codex 生成的再加一点我的人工修正。但我心里很清楚这不叫“AI 替我做完了工作”更准确的说法是“AI 帮我把重复劳动压缩到了最短”。设计稿的布局还原、样式书写、组件结构搭建这些本质上属于“信息搬运”和“模式套用”的环节AI 做得比人快得多也稳得多但理解产品的意图、定义交互的边界、做代码质量兜底这些仍然需要人的判断和参与。未来的工作流大概率会稳定在“人在回路中心”的形态上设计稿产出 → AI 快速生成初稿 → 人来修订交互规则和代码细节 → AI 再执行修订 → 人走查验收。这个循环里人的角色不再是“写代码的”而是“做决策的”。对于团队中和我一样长期处于“需求多、开发少”状态的人来说这意味着一种关键的杠杆效应少量的技术人手借助 agent 执行层可以覆盖更大的界面开发范围。最后分享一个真实的小细节流程收尾后我给项目组的同事发过去演示链接他们一时没看出来这个页面是 AI 自动生成的只觉得“这次登录页提测的速度也太快了吧”。我听完忍不住笑——对于用 AI 干活的人来说这大概就是最顶级的夸奖了。