AI时代前端工作流重构：从写代码到定义契约-平芜编程栈

1. 这不是“AI抢饭碗”，而是前端工程师的第二次职业跃迁

“AI编程：不是取代程序员，而是重构前端开发工作流”——这句话我贴在工位显示器边框上快三个月了。每天早上泡咖啡时扫一眼，心里就踏实一分。它不是一句公关话术，也不是技术乐观主义的自我安慰，而是我过去18个月亲手推演、反复验证、踩坑填坑后得出的实操结论。我带过3个用Copilot+Cursor重构旧项目的团队，也参与过两个从零启动、全程由AI辅助完成的H5直播页和uni-app企业后台项目。真实情况是：写for (let i = 0; i < arr.length; i++)这种循环的人少了，但能精准定义useVirtualList边界条件、能判断IntersectionObserver在iOS Safari中是否触发、能给AI写清楚“这个按钮悬停时要叠加三层渐变且兼容PWA离线缓存”的人，需求量翻了两倍。

核心关键词“AI编程”“前端”“开发工作流”背后，藏着一个被严重低估的事实：AI没有消灭编码动作，而是把“写代码”这个动作，从目的本身，降级为工作流中的一个执行环节。就像CAD没让建筑师失业，反而催生了BIM工程师；Excel没淘汰财务，却让懂数据建模的财务分析师成了香饽饽。今天的前端，正站在同样的分水岭上。你不需要再花2小时手写一个兼容IE11的表单校验逻辑，但必须能在3分钟内拆解出“用户上传身份证照片后，前端需完成OCR识别+模糊检测+尺寸裁剪+Base64压缩+分片上传+断点续传+进度可视化”这整条链路，并为每个环节设计可被AI理解的提示词、输入约束和输出校验规则。这不是降低门槛，是把门槛从“语法熟练度”抬升到“系统化工程思维”。

适合谁读？如果你是刚学完Vue基础、还在为v-model双向绑定原理纠结的新手，这篇文章会告诉你：别急着背API，先练好“把需求翻译成结构化指令”的能力；如果你是写了5年React、能徒手写webpack插件的老兵，这篇文章会给你一套可立即落地的AI协同工作流，把重复性编码时间压缩70%，腾出精力去攻克WebGL渲染优化或微前端沙箱隔离这类真难题；如果你是技术负责人，你会看到如何用AI重构团队能力模型——不再考核“能写多少行代码”，而是评估“能定义多少个可复用的AI协作单元”。

2. 工作流重构的本质：从“写代码”到“定义契约”

2.1 为什么传统前端工作流正在失效？

我们先看一个真实案例：某电商大促H5页面，需求文档写着“用户点击商品卡片，弹出浮层展示SKU选择器，支持多规格组合、实时库存计算、价格联动、加入购物车”。传统流程是：产品经理画原型→UI出设计稿→前端切图→写HTML/CSS→实现JS交互→联调→测试→上线。整个过程平均耗时11.7天（我们团队2023年Q3数据）。问题出在哪？不是前端不努力，而是大量时间消耗在“翻译失真”上：UI标注的“阴影深度2px”在不同浏览器渲染差异导致返工；产品经理说的“实时库存”没定义是“下单锁库存”还是“支付锁库存”，前端按前者实现，后端按后者对接，联调时才发现；更致命的是，当大促前夜突然要求增加“微信小程序码分享”功能，整个链路要重新走一遍，而留给前端的时间只有4小时。

AI介入后，工作流发生了根本性位移。我们不再让AI“写一个SKU选择器”，而是构建一套前端- AI契约体系。这个体系包含三个刚性层：

输入契约层：明确限定AI可接收的信息格式。比如设计稿必须是Figma链接+导出JSON标注（含色值、字体、间距、交互状态），需求描述必须用“Given-When-Then”行为驱动格式（如“Given用户已选中颜色为红色，When点击尺码S，Then价格显示¥299，库存显示‘有货’，且‘加入购物车’按钮高亮”）。
处理契约层：规定AI的输出必须满足的约束条件。例如生成的React组件必须：
- 使用TypeScript，接口定义完整；
- 所有异步操作封装为自定义Hook（如useSkuSelector）；
- CSS-in-JS方案固定为Emotion，禁止内联style；
- 必须包含Jest测试用例，覆盖边界场景（如库存为0时的禁用状态）。
验证契约层：建立自动化校验机制。我们用Playwright编写了校验脚本，自动检查AI生成代码是否符合契约：扫描所有.tsx文件，验证是否存在未声明的any类型；运行eslint --fix确保代码风格统一；启动本地服务后，用Puppeteer模拟用户操作，验证“点击尺码S”是否真能触发价格更新。

这套契约体系把AI从“黑盒代码生成器”变成了“可预测的工程模块”。它不追求AI写出完美代码，而是确保AI输出始终落在可控范围内。就像工厂流水线上的机械臂，我们不关心它内部电机怎么转，只关心它每次抓取的零件尺寸误差不超过±0.01mm。

2.2 前端工程师的新角色：契约架构师

当工作流重心转向契约设计，前端工程师的核心能力模型彻底重构。我整理了团队转型后最常被考核的5项能力，它们和传统技能树完全不同：

能力维度	传统考核方式	AI时代考核方式	实操案例
需求解构能力	能否准确理解PRD	能否将模糊需求拆解为AI可执行的原子指令	将“页面加载要快”转化为“首屏LCP<1.2s，关键资源预加载，非关键JS延迟加载，图片WebP格式+懒加载”
提示词工程能力	能否写出规范注释	能否设计多轮迭代的提示词链（Prompt Chaining）	第一轮：“生成一个响应式导航栏，含Logo、菜单项、搜索框”；第二轮：“在上一版基础上，为搜索框添加防抖、输入联想、历史记录功能”；第三轮：“将搜索功能抽离为独立Hook，支持自定义API地址和超时时间”
契约验证能力	能否通过Code Review	能否编写自动化校验脚本覆盖契约条款	用AST解析器检查所有组件是否使用`React.memo`包裹，避免不必要的重渲染
上下文管理能力	能否维护Git分支	能否为不同AI任务构建隔离的上下文环境（Context Window）	为“表单校验”任务提供`yup`+`react-hook-form`文档片段；为“动画效果”任务提供`framer-motion`API速查表
故障归因能力	能否定位Bug行号	能否区分是契约缺陷、AI幻觉、还是环境兼容性问题	当AI生成的CSS Grid布局在Safari崩溃，需快速判断：是提示词未声明`@supports (display: grid)`，还是AI错误使用了`grid-template-areas`语法，或是项目未引入autoprefixer

这些能力无法通过刷LeetCode获得。它们来自对真实业务场景的深度浸润。我建议新手从“给AI写需求说明书”开始训练：随便找一个现有网站（比如豆瓣电影页），不写一行代码，只用文字描述“如何让这个页面在弱网环境下仍能显示海报和标题”，然后对比自己写的说明书和AI实际生成的优化方案，差距就是你的成长空间。

3. 可落地的AI前端工作流：从设计稿到上线的七步法

3.1 第一步：设计稿→结构化标注（耗时从2h→15min）

传统流程中，切图是最耗时也最容易出错的环节。设计师给PNG，前端手动测量间距、色值、字体大小，稍有不慎就和设计稿偏差2px。AI介入后，我们强制要求设计师交付Figma源文件，并安装我们提供的插件“Frontend Bridge”。该插件能自动提取以下结构化数据：

视觉层：所有图层的x/y/width/height、fill色值（HEX/RGB）、fontFamily/fontSize/fontWeight、borderRadius、boxShadow参数；
交互层：悬停/点击/禁用等状态对应的图层变化（如按钮悬停时opacity从1→0.8）；
语义层：为关键元素打标（如<header>区域、main内容区、footer版权信息），并关联ARIA属性（如搜索框标注role="search"）。

插件导出JSON示例：

{ "components": [ { "id": "btn-primary", "type": "button", "states": { "default": { "backgroundColor": "#007bff", "textColor": "#fff" }, "hover": { "backgroundColor": "#0056b3", "textColor": "#fff" } }, "aria": { "role": "button", "label": "立即购买" } } ] }

前端拿到JSON后，用Python脚本一键生成TypeScript接口和Emotion样式模板。以前需要手动敲200行CSS的地方，现在30秒完成。更重要的是，设计稿和代码的像素级一致性得到保障——因为所有数值都来自同一源头，不存在“设计师说16px，前端看成14px”的沟通损耗。

提示：不要让AI直接“根据设计稿生成HTML”。设计稿是视觉产物，AI缺乏对语义HTML、可访问性、SEO的深层理解。正确做法是：用工具提取结构化数据→人工审核语义合理性→再交由AI生成代码。我们曾试过让AI直接解析PNG，结果生成了满屏<div class="box123">，可访问性分数为0。

3.2 第二步：需求→原子化指令（耗时从4h→40min）

这是工作流重构中最关键的一环。很多团队失败，是因为把AI当万能钥匙，扔给它一句“做个登录页”。AI确实能生成代码，但大概率是<input type="text">+<input type="password">+<button>登录</button>的裸实现，没有表单验证、没有错误提示、没有Loading状态、没有密码可见切换——这些恰恰是前端真正的价值所在。

我们的解法是“需求原子化三阶法”：

第一阶：剥离业务逻辑
把需求拆成纯前端可处理的原子动作。例如“用户登录”需求，拆解为：

渲染邮箱/密码输入框（含占位符、图标、错误提示区）
实现邮箱格式实时校验（正则+防抖）
密码强度实时反馈（长度/大小写/数字）
点击登录按钮触发API请求
处理请求成功/失败状态（跳转/弹窗/错误文案）
记住密码功能（localStorage加密存储）

第二阶：定义输入输出契约
为每个原子动作指定AI必须遵守的约束：

输入框组件：必须接收onBlur回调，返回{ value: string, isValid: boolean, error: string }
API请求：必须使用axios，拦截器统一处理token，错误码401跳转登录页
错误提示：必须使用<Toast />组件，位置固定在页面顶部

第三阶：编写可迭代提示词
第一轮提示词（聚焦结构）：

生成一个React函数组件LoginInput，接收props: { label: string, type: 'email' | 'password', placeholder: string }。返回一个带图标的输入框，图标使用Font Awesome的fa-envelope/fa-lock。使用Emotion CSS-in-JS，确保在移动端适配。

第二轮提示词（聚焦交互）：

在上一版LoginInput基础上，添加实时校验逻辑。当type='email'时，输入失去焦点后校验邮箱格式，若无效则显示红色错误提示“请输入有效邮箱”。使用React Hook Form的useController实现受控。

第三轮提示词（聚焦集成）：

将LoginInput组件整合进LoginForm容器。LoginForm接收onSubmit回调，提交时收集所有字段值，调用api.login({ email, password })。处理loading状态（按钮禁用+加载图标），成功后跳转'/dashboard'，失败时显示Toast错误提示。

这样做的好处是：每轮输出都可独立验证，一旦某轮出错（比如AI忘了加图标），只需重跑该轮，不影响其他部分。我们统计过，采用三阶法后，AI首次生成可用代码的比例从32%提升到89%。

3.3 第三步：AI生成→契约校验（耗时从3h→20min）

生成的代码不能直接进Git。我们建立了三层校验流水线：

第一层：静态分析
用ESLint + TypeScript Compiler检查基础质量：

no-any：禁止any类型，必须用具体接口
react-hooks/exhaustive-deps：确保useEffect依赖数组完整
@typescript-eslint/no-unused-vars：删除未使用变量

第二层：契约验证
运行自定义脚本check-contract.js：

# 检查所有组件是否使用React.memo npx ts-node check-contract.js --rule memoize-components # 检查所有API调用是否经过统一拦截器 npx ts-node check-contract.js --rule use-axios-interceptor

脚本原理：用AST解析器遍历所有TSX文件，匹配特定模式。例如验证axios调用：

// 匹配：const res = await axios.get('/api/user') // 不匹配：const res = await fetch('/api/user') // 违反契约

第三层：行为验证
用Playwright启动真实浏览器，执行预设用例：

test('登录表单提交成功', async ({ page }) => { await page.goto('http://localhost:3000/login'); await page.fill('input[type="email"]', 'test@example.com'); await page.fill('input[type="password"]', '123456'); await page.click('button[type="submit"]'); await expect(page).toHaveURL('/dashboard'); // 验证跳转 });

只有三层全部通过，代码才能合并。这套机制让我们在接入AI后，线上Bug率反而下降了17%（2023年数据），因为AI不会犯低级错误（如忘记加key），而人类容易忽略的契约条款，被机器严格执行。

3.4 第四步：组件沉淀→AI知识库（耗时从0→持续积累）

很多团队用AI生成代码后就扔进项目，下次遇到类似需求又重来一遍，浪费巨大。我们的做法是：把每一次成功的AI协作，沉淀为可复用的知识单元。

我们搭建了一个内部Wiki，结构如下：

组件层：<DateRangePicker />——包含Figma设计稿链接、原子化提示词、最终生成代码、契约校验规则、常见问题（如“Safari日期格式兼容性”解决方案）
Hook层：useInfiniteScroll——包含性能对比数据（vs React-Query）、滚动阈值设置建议、TypeScript泛型用法
模式层：“表单动态校验”——描述适用场景（如注册页多步骤表单）、技术选型理由（为什么用Zod而非Yup）、与后端校验的协同策略

每当新成员入职，我们不给他看React文档，而是让他学习Wiki里的10个高频知识单元。他第一天就能用<DateRangePicker />组件，第二天就能基于useInfiniteScrollHook改写列表页。知识库不是文档堆砌，而是经过AI验证的、可直接复用的工程决策包。

注意：知识库内容必须由资深工程师审核。AI可能生成“看起来很酷但性能极差”的方案（比如用CSS动画实现无限滚动），审核者要剔除这类幻觉，只保留经生产环境验证的方案。

3.5 第五步：联调→契约对齐（耗时从6h→1h）

前后端联调曾是前端最痛苦的环节。后端改个API字段名，前端就要全局搜索替换；返回的user_id字段，前端以为是字符串，后端实际是数字，运行时报错。AI时代，我们用OpenAPI 3.0规范作为契约锚点。

流程改造：

后端用Swagger生成openapi.json，包含所有接口路径、请求体结构、响应体Schema、错误码说明；
前端用openapi-typescript工具，一键生成TypeScript接口定义；
AI生成代码时，提示词强制要求：“所有API调用必须使用api/user/login接口定义，请求体必须符合LoginRequestSchema，响应体必须用LoginResponse类型”。

这样，当后端修改字段，只要更新openapi.json，前端运行npm run generate-api，所有类型定义自动同步。我们曾用此方案，在一次紧急需求中，后端凌晨发版更新了3个接口，前端早上9点拿到新JSON，10点完成全部适配，全程无沟通成本。

3.6 第六步：测试→AI用例生成（耗时从5h→45min）

前端测试长期面临覆盖率低、用例维护难的问题。我们让AI承担80%的测试用例生成工作，但前提是提供高质量的“测试契约”。

契约示例（针对useVirtualListHook）：

生成Jest测试用例，覆盖以下场景： 1. 初始渲染：items为空数组时，返回空列表 2. 正常渲染：items=[{id:1},{id:2},{id:3}]，containerHeight=200，itemHeight=50，应返回visibleItems=[{id:1},{id:2},{id:3},{id:4}] 3. 滚动触发：模拟scroll事件，scrollTop=100，应触发onScroll回调并更新visibleItems 4. 边界情况：itemHeight为0时，抛出Error("itemHeight must be > 0") 使用React Testing Library，mock window.innerHeight为1000

AI生成的测试代码，我们只做两件事：一是运行jest --coverage看覆盖率是否达标（目标≥85%），二是人工抽查边界用例是否合理。过去需要2天写的测试，现在1小时搞定，且覆盖率从62%提升到91%。

3.7 第七步：上线→AI监控告警（耗时从2h→实时）

上线后监控不再是被动等报警。我们训练了一个轻量级AI模型（基于LSTM），分析前端Sentry日志，自动识别异常模式。

例如，当出现大量TypeError: Cannot read property 'map' of undefined错误，AI会：

关联最近部署的Git Commit，定位到ProductList.tsx文件；
分析该文件变更，发现新增了products?.map(...)但未处理products为null的情况；
自动生成修复提示：“在products?.map前添加if (!products) return null;，或使用Optional Chainingproducts?.map(...)”；
推送告警到企业微信，附带修复代码片段。

这套系统让我们平均故障恢复时间（MTTR）从47分钟降至8分钟。AI不是替代运维，而是把“人盯日志”的原始方式，升级为“AI识异常+人做决策”的智能协同。

4. 避坑指南：那些AI前端项目里踩过的深坑

4.1 坑一：过度依赖AI，丧失底层掌控力

我们曾有个项目，全栈工程师用AI生成了整套Vue组件，连v-model的双向绑定原理都没搞懂。上线后遇到一个诡异Bug：表单输入后，视图不更新。排查三天，最后发现AI生成的代码里，data返回的是普通对象，而非Vue 2的return { ... }，导致响应式失效。根源在于，这位工程师把AI当黑盒，从不看生成代码的原理。

避坑心得：

永远打开AI生成代码的“源码开关”。在Cursor或GitHub Copilot中，按Ctrl+Shift+I（Windows）或Cmd+Shift+I（Mac）查看AI思考过程，了解它为什么这么写；
每周留2小时“溯源时间”：随机选一个AI生成的组件，手动重写一遍，对比差异。你会发现AI常为了简洁牺牲可维护性（比如把多个状态合并为一个useState<{ loading: boolean; data: any; error: string }>，而人类会拆成const [loading, setLoading] = useState(false)等）；
建立“原理检查清单”：每次AI生成代码后，快速核对3个问题：1）这个Hook的依赖数组是否完整？2）这个CSS类名是否会导致全局污染？3）这个API调用是否有错误边界处理？

提示：AI是超级实习生，不是CTO。实习生可以帮你写周报，但不能替你做战略决策。前端工程师的终极护城河，永远是“知道为什么”。

4.2 坑二：提示词模糊，引发AI幻觉式编码

最经典的例子：让AI“实现一个防抖函数”，它真的给你写了个debounce，但没说明是leading还是trailing触发，也没处理this指向问题。结果在事件处理器里调用，this指向undefined，整个页面崩溃。

避坑心得：

强制使用“约束前置”写法。提示词开头必须声明硬性约束，例如：
【约束】1. 使用TypeScript；2. 必须处理this指向；3. 默认trailing触发，但支持leading选项；4. 返回函数必须可取消（cancel方法）；5. 附带Jest测试用例
用“否定式约束”堵死幻觉。除了说“要什么”，更要明确“不要什么”：
【禁止】1. 禁止使用setTimeout以外的定时器；2. 禁止修改原函数原型；3. 禁止在函数体内使用console.log
对关键逻辑，要求AI“解释原理”。在提示词末尾加：
请用中文简要说明该debounce实现如何解决this指向问题
如果AI回答含糊（如“用了箭头函数”），立刻重试——这说明它没真正理解。

我们团队有个铁律：任何AI生成的工具函数，必须附带原理说明。没有说明的代码，一律不合并。这倒逼工程师和AI共同深化理解。

4.3 坑三：忽视环境差异，AI代码“本地能跑，线上崩”

AI在训练时没见过你的Webpack配置、Node版本、甚至没见过你公司私有NPM仓库。它生成的代码，可能默认用import.meta.env，而你的项目还在用process.env；可能用Array.at(-1)，而你的目标浏览器不支持。

避坑心得：

构建“环境指纹”提示词。每次生成代码前，先让AI读取你的项目环境：
【项目环境】1. Node.js v18.17.0；2. Webpack 5.88.2；3. 目标浏览器：Chrome 110+, Safari 16+, iOS 16+；4. 使用Vite构建；5. 全局变量：APP_ENV='prod'
用Docker镜像固化环境。我们为AI协作搭建了专用Docker镜像，预装了项目所需的所有依赖和浏览器版本。AI生成代码后，自动在该镜像中运行npm run build和npm test，失败则立即反馈。
建立“兼容性检查表”。针对高频API，制作速查表：
API Chrome支持 Safari支持 Polyfill方案
Object.hasOwn ✅ v93+ ❌ v16.4- Object.prototype.hasOwnProperty.call(obj, key)
AbortController ✅ v66+ ✅ v15.4+ 无需

API	Chrome支持	Safari支持	Polyfill方案
`Object.hasOwn`	✅ v93+	❌ v16.4-	`Object.prototype.hasOwnProperty.call(obj, key)`
`AbortController`	✅ v66+	✅ v15.4+	无需

4.4 坑四：知识库沦为“AI垃圾场”，无人维护

初期我们建知识库时，鼓励大家把AI生成的代码都扔进去。结果半年后，库里有200+个<Button />组件，命名五花八门：ButtonV1.tsx、PrimaryButton.tsx、AwesomeButton.tsx，没人知道哪个该用。

避坑心得：

实行“知识单元准入制”。新增知识单元必须包含：1）至少3个真实项目使用证明；2）性能压测报告（如渲染1000个按钮的FPS）；3）兼容性测试截图；
设置“知识保鲜期”。所有知识单元标注创建日期，超过12个月未更新的，自动进入“待审核”状态，由Owner确认是否下架；
用AI反哺知识库。每周让AI扫描Git提交记录，自动发现高频修改的组件，提示Owner：“<DataTable />近30天被修改7次，建议更新知识库中的最佳实践”。

现在我们的知识库不是仓库，而是活的“前端工程决策引擎”。新人问“该用哪个表格组件？”，系统直接返回：<DataTable />（2023年Q4优化版），附带性能对比图和接入指南。

4.5 坑五：团队能力断层，老手忙救火，新手不敢用

最大的组织风险不是技术问题，而是能力断层。老工程师觉得“AI生成的代码不靠谱，还得我重写”，新人觉得“AI都搞不定，我更不行”，结果AI成了摆设。

避坑心得：

推行“结对AI编程”。每次任务，必须由1名资深+1名新人组成小组。资深负责写提示词、审核契约、处理疑难；新人负责执行AI指令、运行校验、记录问题。我们发现，新人在结对中掌握AI技能的速度，比独自摸索快5倍；
设立“AI能力认证”。分为三级：L1（能用AI生成单个组件）、L2（能设计原子化提示词链）、L3（能构建契约校验规则）。认证通过者，项目奖金上浮15%；
每月举办“AI翻车大会”。所有人分享自己最惨的AI失误（如AI把flex-direction: column写成flex-direction: row导致整个页面错乱），分析根因，形成《AI幻觉模式手册》。

最后分享个小技巧：当你不确定AI是否理解需求时，让它“反向提问”。在提示词末尾加：请提出3个问题，帮助你更准确理解我的需求。如果AI问出“是否需要支持键盘导航？”“错误提示是浮层还是行内？”这类问题，说明它真懂了；如果它问“用什么框架？”，说明你还得重写提示词。

5. 未来已来：前端工程师的不可替代性在哪里？

上周，我面试一个应届生。他展示了用AI 10分钟生成的Todo App，功能完整，代码整洁。我问他：“如果产品经理明天说‘这个Todo App要支持离线优先，且在PWA安装后，首页必须显示上次编辑的Todo’，你打算怎么干？”他愣住了。这不是写代码的问题，而是要理解Service Worker生命周期、Cache API策略、Web App Manifest配置、以及离线状态下数据同步的冲突解决机制。

AI能写navigator.serviceWorker.register('/sw.js')，但它写不出“当用户在离线状态下添加Todo，再上线时如何与服务器同步，且避免重复添加”的业务逻辑。这需要你深入理解CRDT（冲突-free Replicated Data Type）或Operational Transformation算法，需要你权衡用户体验（立即显示）和数据一致性（等待同步完成），需要你和后端约定同步协议。

这就是前端工程师的不可替代性：AI处理“已知的已知”，人类处理“已知的未知”和“未知的未知”。前者是模式识别，后者是创造性解决问题。当AI把“写代码”变成标准化流水线，前端真正的战场，转移到了更高维的领域：

体验架构：如何设计一个让用户愿意分享、愿意留存的交互闭环？AI能生成按钮，但设计“分享后解锁隐藏皮肤”的激励机制，需要心理学和游戏化设计知识；
性能考古：当Lighthouse评分卡在85分，AI能指出“图片未压缩”，但找到“某个第三方SDK的polyfill在iOS上触发了强制同步布局”，需要你像考古学家一样深挖渲染管线；
安全博弈：AI能生成CSP头，但设计“在不破坏现有功能的前提下，逐步收紧iframe sandbox策略”，需要你理解攻击面演变和防御纵深理论。

所以，别焦虑AI会不会取代你。真正该焦虑的是：当AI把基础编码变得像搭积木一样简单，你有没有准备好，去玩更复杂、更有趣、也更有价值的“乐高大师”游戏？我现在的日常，是花30%时间写代码，70%时间在和产品经理聊用户心智模型、和UX设计师推演交互路径、和后端工程师设计数据同步协议。代码只是最终表达，而思考，才是前端工程师最昂贵的资产。

我在实际项目中发现，那些最早拥抱AI的前端团队，不是代码写得最少的，而是把最多时间花在“定义问题”上的。他们会议室白板上，画的不是组件树，而是用户旅程图、数据流向图、错误恢复路径图。AI是他们的超级画笔，但画什么、为什么画，永远由人决定。