企业官网建设流程全解析

1. 先聊清楚：这次到底在解决什么问题

说起来挺有意思，我在浏览器里刷到一条帖子，问的是“AI 到底能不能自己把一个看得见的 UI 设计稿变成能跑的小程序代码”。底下评论吵成一锅粥，有人说 AI 生成界面早就是标配了，有人说生成出来全是“豆腐块工程”，压根没法用。我手上的活正好撞在这个问题上——新项目的用户端需要一个微信小程序的登录页，设计搞定了，但前端排期排到两周之后。我等不了那么久，于是动了“用 Codex 把即时设计里的登录页 UI 自动变成代码”的念头。

先交代下背景。这里说的 Codex 是 OpenAI 出的 AI 编程助手，它的工作逻辑和普通对话式 AI 不太一样，更像一个“能读代码库、能自己动手改文件”的编程智能体。你可以让它直接在一整个项目里做深度修改，而不只是像聊天框那样一问一答给你几段代码。而即时设计是国内团队做的在线 UI 设计工具，和 Figma 属于同类产品，优势在于国内直连、中文环境友好、支持多人协同。

这两个东西凑一块儿，能不能解决我的痛点？我的痛点很具体：设计那边已经输出了一张完整的小程序登录页设计稿，包含手机号输入框、验证码按钮、登录按钮、协议勾选，还有底部的第三方登录图标。我要做的事情，是让 AI 不仅仅“照着截图生成一坨静态 HTML”，而是真正理解设计稿里的布局、间距、组件层级，然后在小程序项目结构里生成一套能用的、符合 WXML/WXSS 规范的页面文件。

这个目标听起来不复杂，但里面埋了很多坑。比如：AI 能不能从小程序设计稿的“图片”里精准提取颜色值和字号？AI 能不能正确使用小程序独有的button、input组件而不是生成一堆<div>？AI 生成出来的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，它甚至连事件绑定都长这样：bindinput="handleInput"。这些细节，刚接触小程序的人可能意识不到，但如果 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 干活的人来说，这大概就是最顶级的夸奖了。