企业官网建设流程全解析

“AI会不会把我们前端端掉”这个问题，我最近被问烦了，于是找了个下午，把当下热门的AI编程助手和对话式AI挨个试了一遍，并且不是拿什么“写一个Todo List”这种玩具需求去糊弄自己，而是模拟了一个真实业务场景：一个带完整功能的订单管理后台。测试做完之后，我反而淡定了。这篇文章就聊聊我实际测试的过程、AI翻车的现场，以及我最终得出的结论：AI确实干掉了一部分前端工作，但远没有到能颠覆这个职业的程度。

1. 一个无聊下午的实测：我让AI干了一天的活

1.1 为什么选“订单管理后台”当考题

我决定不用那种网上流传的炫酷Demo考题，那些题目AI早就背得滚瓜烂熟，测试不出真实水平。我选了某个项目里真实存在的一个模块：订单管理后台。为什么选这个？因为它够典型、够复杂。

一个订单管理后台，表面上看就是几个表格加几个表单，但真做起来要命：列表要支持多条件筛选、分页、排序；订单状态流转涉及各种按钮的显隐规则；还有弹窗里的联动表单、金额校验、时间范围选择、Excel导出、状态高亮……这些交互拆开看不难，合在一起就是考验工程能力的地方。

我把需求整理成一段描述，丢给了三个不同的AI工具：一个对话式AI，两个编程助手类插件。每个我都给了同样的需求文本，然后看它们的产出。

1.2 第一轮：基础页面生成，AI确实麻利

第一轮我让AI直接生成订单列表页。需求包括了：表格展示、订单编号点击复制、状态标签颜色区分、操作列根据不同状态显隐按钮、分页器。

这个任务AI完成得相当快，大概二十秒就出了一版完整的代码。代码结构清晰，用了主流的组件库，表格列配置、状态映射、分页逻辑都写得有模有样。尤其是状态标签的颜色映射，AI给的方案居然跟我之前项目里的实现思路一模一样，是通过一个状态枚举对象统一管理。我甚至觉得它写得比某些初级工程师还规范。

但这只是第一轮，热身而已。真正的考验在第二轮。

2. 开始上强度：一次对话暴露了AI的本质

2.1 带上下文的联动需求，AI开始露怯

第二轮我加了需求：订单筛选区域里，支付方式选择“线上支付”时，下方要出现支付渠道的二级下拉；选择“线下支付”时，二级下拉消失换成现金收款人输入框。同时，当筛选条件的组合结果为空时，表格区域要显示自定义的空状态组件，并且附带一个“重置所有筛选”按钮。

这个需求不难，但有一个字眼AI理解得不对：联动。它是机械地做了显隐控制，但完全没有考虑到选择“线上支付”再切换回“全部”时，支付渠道字段的值应该重置。我直接回复它：切换回“全部”选项时，二级条件没清空。AI道歉，然后补了一段代码。

补完之后我再测：清空筛选条件后，表格数据死活不刷新，总在那里转圈。我又回复报错信息，AI又道歉，又补了一段。来回三轮，这个小逻辑才算完整跑通。耗时四十分钟。

2.2 现场代码实录：AI写的表面功夫

这里贴一段它第一次生成的代码，你们感受一下：

// 筛选区域联动逻辑 - AI第一版产出（节选） const handlePaymentTypeChange = (value) => { setFormData((prev) => ({ ...prev, paymentType: value })); if (value === 'online') { setFormData((prev) => ({ ...prev, channel: '' })); // 置空渠道 setFormData((prev) => ({ ...prev, cashier: undefined })); } else if (value === 'offline') { setFormData((prev) => ({ ...prev, channel: undefined })); setFormData((prev) => ({ ...prev, cashier: '' })); } else { // 切换为“全部”时，两个字段都没有清理 setFormData((prev) => ({ ...prev, channel: undefined, cashier: undefined })); } };

它这个写法把多个状态切分成了好几个setFormData调用，每个调用之间还有依赖关系。React的状态更新是异步批处理的，这种一串setFormData连写，在极少数情况下会出现更新覆盖问题，但大多数场景能跑。真正的问题在于它完全没考虑“全部”选项下的清理。

我指出问题后，它给出的修复是又套了一层useEffect，监听paymentType变化，再在副作用里清空。这当然是能跑的，但这是一个典型的绕路方案。一个熟悉业务逻辑的开发，会在源头的事件处理器里直接处理干净，根本不需要多引入一个副作用钩子。

2.3 一个明显的分水岭：业务复杂度一上来，AI就露怯

测到这里我基本摸清了一个规律：需求描述越靠近“界面长什么样”，AI完成度越高；需求描述越靠近“业务流程怎么走”，AI翻车概率越大。

界面长得什么样，本质上是视觉和布局问题，大模型在训练时见过海量的页面截图和代码，它知道一个表格该长什么样，删除按钮该在什么位置。但业务流程是什么？是状态流转、是边界条件、是异常分支、是数据的契约关系。这些不是“看”出来的，是“推理”出来的，甚至需要跑起来才知道对不对。这恰恰是AI目前最薄弱的环节。

3. 我拿真实项目继续压测，AI在水位线以下的部分

3.1 跨模块的数据流转：AI的“编造”时刻

第三轮，我加大难度，让AI实现一个从我测过的功能里没有出现过的能力：把订单列表勾选的数据，提交到另一个模块生成对账单，并对账结果实时回到订单列表状态列。这个需求涉及多个模块的状态同步、接口字段映射，还带有一定的业务规则。

AI这次产出了一个“看起来很完整”的代码包，但仔细读代码后发现：它调用了两个方法——createReconciliation和fetchReconciliationStatus，然后我翻了整个项目代码，根本不存在这几个方法。也就是说，AI一本正经地虚构了两个接口函数，并且配套写了对应的注释。如果是一个新手直接复制粘贴，跑都跑不起来。

这是AI另一个非常典型的问题：幻觉。它会为了代码的完整性，自动生成不存在的API、不存在的组件、不存在的工具函数，而且生成得一本正经、毫无破绽。

我当时就在想，如果团队里有人没有做代码评审，这段代码合并进主干，调试的成本可能比你从零开始写还高。

3.2 工程化层面的体验：代码质量与维护性

说实话，AI生成的页面代码，在结构上是工整的，组件拆分意识也够用。但如果拿代码评审的标准去挑，问题多得像筛子：

• 命名大量混用data、list、tempData、formValue，含义模糊
• 样式类名随机生成，没有遵循团队已有的命名规范
• 状态管理没有统一方案，有时用 Context、有时用组件内useState、有时用第三方状态库
• 组件拆分的粒度和复用价值经不起推敲，一个页面拆了十几个组件，但换一个需求场景就得重写

这些问题不是“功能能不能跑”，而是“活着的人怎么维护它”。AI不关心这些，它只负责在当前对话的上下文里产出“合理的代码”。至于这个代码在三个月后别人怎么阅读、怎么修改，AI完全无感。

3.3 性能与交互细节的缺失

订单列表页数据量一大，分页和虚拟滚动就是刚需。我让AI优化大数据量渲染，它给出的方案是“建议使用虚拟列表库”。当我明确指定使用某个具体方案后，它在适配过程里又先后踩了滚动容器测量不准、动态行高抖动、分页和虚拟滚动叠加时索引错乱等一系列坑。

这些细节不是靠需求描述能说清的，它们在代码运行期间才会暴露出来。AI被这些运行时问题反复折磨了十几轮，最后还是回到了一个朴素的方案：不加虚拟滚动，老老实实做服务端分页。

这也印证了那句话：AI写代码，节奏是“写写写”，而资深工程师写代码，节奏是“量量量”。测量用户真实使用场景、测量性能数据、测量极端输入，这是AI替代不了的高成本环节。

4. 冷静下来分析：AI到底取代了哪部分前端

4.1 AI做得很好的，是“高确定性”的活

通过几轮测试，我大致把前端的工作分成三类：确定性强、确定性中等、确定性弱。

AI干得最好的，是确定性强的活。比如：

• 中后台的CRUD页面、表格、表单
• 基于设计稿的静态页面还原
• 常见组件库的封装调用
• 代码格式调整、命名重构、散碎逻辑的搬运
• 简单页面性能建议、代码解释

这类工作的共同点是：规则明确、样本量大、可被大量历史数据训练。AI干得比大多数初级工程师快，甚至质量更稳定。

4.2 AI做得勉强的，是“需要取舍”的活

第二类，它做得勉勉强强：

• 页面交互的复杂联动
• 多端适配的兼容问题
• 需要同时权衡体验/性能/成本的技术选型
• 旧项目里基于历史遗留代码的功能扩建

这些不是单纯“写代码”，而是“做决策”。比如一个页面到底用前端渲染还是服务端渲染，要结合项目团队的技术栈、运维能力、内容形态等多个变量。AI能给你列出各自的优缺点，但它没法替你做决策，因为决策需要的是对它完全未知的组织信息和业务信息。

4.3 AI做不了的，是“沟通和定义”的活

第三类，AI目前完全无能为力：

• 跟业务方聊天，把一句“这里要更高级一点”翻译成具体功能点
• 跟UI设计师讨论一个组件边框的颜色在暗色模式下的对比度问题
• 跟后端协商一个字段到底是status还是state，以及取值范围的语义边界
• 跟测试同学解释某个边界情况的预期行为，并确定是否属于缺陷

这些事有一个共同点：它们没有一个唯一正确的答案，需要人类在模糊信息里做判断和承担后果。AI可以在你判断完之后帮你生成代码，但它在没判断之前，生成的代码只是无数种可能性里的一个平庸样本。

我画了一张对照表，方便你们参照：

5. 前端工程师的护城河：不是写代码，是确定性兜底

5.1 一个稳定性问题直接问倒AI

我不死心，又试了一轮更贴近生产的问题。我问AI：订单列表页目前加载时间在弱网环境下不稳定，你能给出分阶段优化方案吗？

它给了我一个还挺像样的回答：首屏去掉非核心模块、列表分页改成接口分页、图片懒加载、加骨架屏、压缩请求体积。但你拿到这个方案，能直接用吗？不能。因为这些优化项对于当前项目各自的收益大小、实施成本和影响范围，是完全未知的。AI不知道这个项目是体量多大、团队人手如何、历史包袱多深、那些据说“很慢”的接口，是不是真的是因为页面代码导致的。它给的是一个放之四海皆准的“健康建议”，不是针对这个病情开的处方。

真正的前端工作，是在不确定性的泥潭里帮团队摸出一条确定路径。这个确定性来自对业务的深度理解、对运行逻辑的亲手调试、对线上问题的敏锐嗅觉。这些能力只能靠真实项目反复捶打出来，没法靠喂训练数据获得。

5.2 人是问题的定义者，代码只是答案的投影

我在公司带过一个新来的实习生，他某天特别焦虑地问我：哥，AI写代码这么快，我每天练的这些基础还有意义吗？

我当时帮他把自己的工作拆开看了一遍。他一天干了六件事：调页面样式、修一个跨浏览器兼容问题、跟运营对接了一个数据展示的需求、排查了一个线上数据对不上的问题、给测试同学演示了新功能、顺带优化了一个列表查询接口的请求参数。

这六件事里，第一件、第六件AI确实能干，而且干得不差。但中间四件呢？AI一点也插不上手。因为它需要的是：了解这个公司的业务是什么、知道用户为什么会对不上数、能和运营聊清楚那个“展示数据”的真实含义、在测试面前说服对方某个行为是预期内的设计。

我后来跟他讲：你发现没有，你一半以上的时间不是在“写前端”，而是在“搞清楚前端应该怎么写”。这个“搞清楚”的动作，才是这个岗位真正的价值。

AI生成的是答案，而答案的基座是问题；问题是人类独有的领域。

5.3 前端从“翻译设计稿”走向“定义交互模型”

过去十年，前端工程师很大一部分工作是把设计稿翻译成界面，把接口数据渲染成图形。这两件事恰好是AI最擅长的：从一种结构化描述转到另一种结构化描述。

但前端这个岗位一直在进化。以前切图仔时期，切图是核心；后来工程化时期，性能优化和架构是核心；现在AI把“翻译”干掉了，这个岗位的核心必然转向更有难度的方向——交互模型的设计。

什么叫交互模型？举个例子：一个表单，到底该分几步填完？每一步的校验规则该怎么设计，用户才能既有安全感又不觉得繁琐？出错提示应该出现在哪个时机，崩溃恢复后该回到什么状态？这些东西设计稿上不会画，接口文档上不会写，它们需要前端工程师去定义，再用代码实现。而AI能帮你实现，但很难帮你定义。

6. 我的实际转向：把AI当成免费劳动力，而不是替代者

6.1 我现在怎么用AI干活的

既然AI写不了决策和沟通，那我把它用在它擅长的维度，效率反而是几十倍的提升。

我现在的工作流变成了这样：

1. 让AI产出骨架：接一个新需求，先给AI一段口语化的需求描述，让它给我产出一个包含数据结构、页面结构、组件划分的方案初稿。把方案里的坑挑完之后，再让AI生成初版代码，能省下去一大半的重复劳动。

2. 拿AI当代码评审的第二双眼睛：我自己写完代码之后，把代码贴给AI，问它有没有边界漏洞、有没有更优的写法。虽然它的建议经常只对一半，但它提醒我注意的地方往往是我自己惯性思维漏掉的。

3. 让AI补全重复性工作：比如写一堆表单项的校验规则、生成不同状态下的测试数据、批量生成通用组件的类型定义。这些工作量大但不需要思考的事，AI干得又快又稳。

4. 用AI学新东西：遇到没接触过的框架API，直接让AI用类比的方式给我讲清楚，比翻文档效率高几倍。

我试过一段时间下来，个人体感效率提升了约30%以上，尤其在写重复性中后台页面的场景下，节省的时间非常可观。但这里有一个前提：你得能判断AI产出的代码到底对不对，你得能看穿它代码里藏着的雷。

6.2 新人如果现在入行，反而要抓这件事

如果你现在刚踏入前端这行，我反而认为这是个不错的时机。理由是：AI把低水平重复劳动的门槛打下来了，那些过去需要花一两年反复练习的“搬砖活”，现在可以快速跳过，直接进入更高阶的业务理解、架构设计和技术决策。

但前提是你得有一个强判断力的人带你，帮你纠正AI给你的错误答案。如果自己一个人闷头用AI，很可能养成一个习惯：代码能跑就行，从不追问为什么。这个习惯一旦养成，你的职业生涯会很危险。因为“能跑”是AI的下限，而“为什么这么写更好”才是你的价值。

7. 几个压箱底的实操建议

7.1 用AI的正确姿势

• 需求描述越具体，产出越靠谱。不要写“做个订单列表页”，要写清楚有哪些字段、什么状态、哪些操作权限、数据从哪来、异常怎么处理。你对需求的定义越完整，AI的输出偏差越小。

• 验证接口字段是否存在，特别是AI自己“发明”的接口。每次拿到AI生成的代码，第一件事是全局搜索它调用的接口方法，确认不是幻觉产物。

• 要求AI“想一想再回答”。在提问时加上约束词，比如“请先列出边界情况，再写实现”，会让它的产出质量上一个台阶，虽然偶尔还是在胡扯，但胡扯概率明显变低。

• 多轮对话及时止损。如果一个逻辑AI连续两轮都没改对，别再继续了。它不是不会，是根本没理解你的上下文。果断自己在代码里改，改完之后可以丢给它复盘，让它告诉你它错在哪。

7.2 能力升级的优先级排序

我自己的排序是这样的，按投入产出比排：

1. 需求分析和沟通能力（跟业务方对话、拆解问题）
2. 系统设计能力（页面结构、状态管理、数据流设计）
3. 代码评审能力（读懂别人的代码，发现潜在问题）
4. 性能调试和问题排查能力（线上问题找根因）
5. 写代码本身（这个反而可以适当依赖AI）

大多数前端从业者过去把95%的精力花在第5项，而AI恰好把第5项打骨折价了。把自己的重心挪到前四项上去，才是这个时期最划算的投资。

7.3 给还在焦虑的朋友一句话

如果你还在纠结“AI会不会取代我”，我的建议是：别光看网上那些“AI写代码有多强”的演示视频。去把AI接进你手头的真实项目里，让它去写你要写的那个页面，去修你要修的那个bug，去完成那个需要和业务方来回确认三天的需求。

实测一次，你心里那杆秤就稳了。AI确实是好工具，但它更像一个学得很快、偶尔会一本正经撒谎的实习生。你得有监工的本事，才能真正用好它。而监工的本事，就是前端这个职业正在重新定价的核心能力。