05-前端开发 × AI 协同

💬 一句话读懂本篇：前端是 AI 化最顺滑的岗位——所见即所得，错了立刻看得见；但”看得见”也意味着平庸和毛边直接暴露给用户，验收标准要比你想的更细。

岗位定位：🤖 AI 主导 · AI 承担约 70% 工作量。前端代码风险低于后端（错了通常不丢数据），且 AI 生成→浏览器预览→人工验收的循环极短，是一人公司里人机协作爽感最强的岗位。

一、传统画像：前端工程师原来干什么

二、AI 协同后的新画像

你是”体验守门员”，AI 是全能施工队。 02 分册的设计 token 在这里兑现价值：token 在手，AI 写出的页面天然一致，你的工作重心从”写”移到”挑刺”。

flowchart LR
    subgraph IN["📥 输入（上游分册产出）"]
        I1["设计稿 + token<br>（02 分册）"]
        I2["接口契约<br>（03/04 分册）"]
    end
    subgraph A["🤖 AI 施工队"]
        A1["页面/组件代码"]
        A2["Mock 数据 + 联调层"]
        A3["响应式/暗色适配"]
        A4["动效/交互实现"]
    end
    subgraph H["👤 你：体验守门员"]
        H1["浏览器实测<br>真点真滑真填"]
        H2["细节挑刺<br>间距/状态/键盘/边界"]
        H3["性能与包体把关"]
    end
    IN --> A --> H
    H -.->|"挑出问题，指哪改哪"| A

    classDef human fill:#fff3e0,stroke:#e65100,color:#bf360c
    classDef ai fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    class H1,H2,H3 human
    class A1,A2,A3,A4 ai

三、逐项对比：传统做法 vs AI 协同做法

⚠️ 前端验收的特殊性：后端靠测试通过，前端靠真人真浏览器真操作。AI 说”已完成响应式适配”不算数，你在手机上滑一遍才算数。

四、协同工作流：一个页面的诞生

flowchart TD
    K["📥 设计稿 + token + 接口契约"] --> G["🤖 AI 生成页面组件<br>（模板A，默认态先行）"]
    G --> S["🤖 AI 补齐五态<br>加载/空数据/错误/禁用/成功"]
    S --> M["🤖 接 Mock 数据跑通<br>不等后端"]
    M --> C1{"👤 关口①：桌面浏览器实测<br>真点真填，走完整流程"}
    C1 -->|"毛边"| FIX["🤖 指哪改哪<br>（贴截图+说现象）"]
    FIX --> C1
    C1 -->|"通过"| C2{"👤 关口②：移动真机抽查<br>响应式/触控/键盘弹起"}
    C2 -->|"问题"| FIX
    C2 -->|"通过"| C3{"👤 关口③：代码审查<br>token引用?包体?无障碍?"}
    C3 -->|"不过"| FIX
    C3 -->|"过"| DONE["✅ 合入（标注 AI 辅助）"]

    classDef human fill:#fff3e0,stroke:#e65100,color:#bf360c
    classDef ai fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    class C1,C2,C3 human
    class G,S,M,FIX ai

节奏建议：改前端别打字描述，截图圈问题——”这个按钮”远不如一张画了红圈的图。多数 AI 工具支持贴图，这是前端协同独有的高效沟通方式。

五、提示词模板（直接抄作业）

模板 A · 页面/组件生成

1
2
3
4
5
6
7
8
9
【输入】设计稿：（贴图）；设计 token：（粘贴 JSON）；接口契约：（粘贴）
【任务】用「框架+版本号」实现该页面
【约束】
1. 颜色/字号/间距/圆角一律引用 token，禁止硬编码
2. 组件 props 设计遵循项目现有组件规范：（贴一个现有组件示例）
3. 覆盖五态：默认/加载/空数据/错误/禁用
4. 数据请求走项目统一请求层（贴现有用法），不要直接 fetch
5. 表单校验规则与后端契约一致，错误提示用中文、说人话
【输出】组件代码 + 用到的 Mock 数据 + 与设计稿的差异说明

模板 B · 状态管理设计

1
2
3
4
5
6
7
【输入】页面功能描述：xxx；涉及的接口：（粘贴契约）
【任务】先不要写代码——给出状态设计方案：
1. 状态清单（每个状态：名称/类型/谁写入/谁消费）
2. 服务端状态 vs 客户端状态的划分（哪些该用查询缓存而不是手动 store）
3. 数据流向图（mermaid）
【约束】状态数量最少化：能从已有状态派生的绝不新建；
方案给我看完确认后，再按方案生成代码。

模板 C · 挑刺修复（配合截图）

1
2
3
4
【现象】（贴截图，圈出问题）在 xxx 视口宽度下，xxx 元素出现 xxx 问题
【期望】xxx（描述正确表现，或贴设计稿对应部分）
【输入】相关组件代码：（粘贴）
【约束】只改这个问题，不要顺手重构其他部分；改完说明动了哪几行、为什么。

模板 D · 性能审查

1
2
3
4
5
6
以下是项目的构建产物分析/关键组件代码（粘贴）。
请输出性能优化清单，每条包含：
1. 问题（如：首屏包体过大/不必要的重渲染/图片未懒加载）
2. 用户可感知的后果
3. 修复方法 + 预估收益（大/中/小）
按收益排序，只列值得做的（一人公司：性价比低的直接不列）。

六、验收清单（合入前逐项勾）

实测（浏览器里真操作过）

• 完整用户流程走通：真点、真填、真提交
• 五态齐全：默认/加载/空数据/错误/禁用，且都亲眼看过
• 移动真机抽查：响应式断点、触控目标、软键盘弹起不挡输入
• 极端输入试过：超长文本、特殊字符、连续快速点击

代码

• 样式全部引用 token，grep 无硬编码色值/魔法数字
• 无 AI 夹带的多余依赖（新组件库、新工具包问过自己”项目里没有吗”）
• 列表有 key、图片有 alt、可聚焦元素有 focus 态
• 数据请求走统一请求层，无散落的手写 fetch

性能

• 包体无明显膨胀（新页面引入的依赖 < 预期）
• 长列表有虚拟化/分页，图片有懒加载和尺寸约束
• 无控制台报错和警告（AI 代码常留 warning，别惯着）

七、坑点清单

💬 收尾一句：前端协同的爽点是”生成即所见”，坑点也在”所见即所得”——用户看到的就是你的验收水平。AI 负责快，你负责细。 下一册：06-移动端开发 × AI 协同——跨端方案让一人做 App 成为可能，但上架合规这道坎 AI 替不了你。

• Previous
  运维 DevOps × AI 协同：AI 写 100% 的脚本，你按 100% 的回车
• Next
  16-法务合规 × AI 协同（终册 · 附录级）