从零搭建 React 电商前端：智能编程工具的能力边界与工程化实践

一、背景：当”生成式 IDE”进入真实项目

近两年，集成在编辑器中的智能编程工具快速普及。它们普遍提供两类核心能力：一是基于自然语言的代码补全与片段生成，二是面向整任务的自然语言驱动开发——用户描述需求，工具自主规划文件、编写代码、安装依赖甚至运行调试。后者常被称为”智能体模式”或”任务模式”，是当前各工具差异化竞争的主战场。

但工具的宣传语和真实项目之间往往存在落差。本文不复述任何具体产品的评测结论，而是把”用智能编程工具从零搭建一个电商前端站点”作为一次可控的实验场景，抽象出这类工具在需求理解、任务编排、代码质量、界面完成度、工程结构五个维度上的共性表现，并给出可复用的实践方法。选择电商前端作为实验载体，是因为它同时具备三个特征：页面数量适中（可在一个任务内完成）、业务链路完整（浏览—购买—支付—账户管理）、对界面友好度要求高（直接面向终端用户），恰好能压测工具的综合能力。

二、实验设计：十个页面的购物站

2.1 需求拆解

实验目标是使用 React 构建一个前端购物站，包含十个页面：

1. 产品列表/首页
2. 产品详情页
3. 产品购买页（下单确认）
4. 产品购买成功页
5. 用户登录页
6. 用户注册页
7. 用户中心 - 概览面板
8. 用户中心 - 订单页
9. 用户中心 - 钱包与卡券包
10. 用户中心 - 设置页

技术栈约束为：React 函数组件 + 路由 + 基础状态管理，样式与逻辑分离，使用模拟数据先行驱动界面。这一约束是刻意的——它模拟了真实项目中”先出可交互原型、再对接后端”的常见节奏，也便于观察工具是否会在缺乏真实接口时自行编造不存在的 API。

2.2 提示词设计

提示词的质量直接决定生成结果的上限。实践中有效的写法是把需求拆成”角色—范围—约束—验收”四段：

角色：你是一名前端工程师，负责交付一个可运行的 React 电商前端原型。
范围：实现以下 10 个页面（逐一列出），路由可跳转，购物流程从详情页到下单成功页闭环。
约束：
- 使用函数组件与 Hooks，样式与 JS 逻辑分文件存放；
- 商品、订单、用户数据使用本地模拟数据模块，集中放在 data 目录，不得散落在组件内；
- 表单需包含基础校验（必填、格式、长度）；
- 界面需做移动端优先的响应式适配，桌面端可用。
验收：npm install && npm run dev 可启动，主流程无阻断性报错。

这段提示词的价值在于把”架构过于简单””模拟数据耦合在代码中”这类常见缺陷提前写成约束条款。实测经验表明，若不显式要求数据层分离，生成结果大概率会把 mock 数组直接写在组件文件顶部。

三、协作模式的选择：直连生成 vs 多智能体编排

当前智能编程工具在任务执行上大致分为两条路线。

路线一：单智能体直连生成。 用户提交任务后，由一个智能体顺序完成规划、写文件、装依赖。优点是链路短、响应快，适合中等规模、结构清晰的任务；缺点是缺乏交叉校验，错误容易累积。实验中发现，该路线在一次性完成十页面任务时表现稳定，服务器响应无明显卡顿，产物可以直接跑起来。

路线二：多智能体编排。 工具将任务分派给规划、编码、审查等不同角色的智能体，甚至提供多种预设模式（如强调快速产出的模式、强调复杂任务拆解的模式）。理论上质量更高，但实践中暴露出两个问题：其一，模式过多导致用户选择困难，而不同模式的实际效果差异并不透明；其二，部分模式响应明显偏慢，且生成的项目结构反而更混乱——例如在项目根目录内又嵌套了一层同名目录，导致入口路径错位、项目无法启动。另有模式在生成后遗留较多报错，多轮修复仍无法收敛。

结论是：模式数量不等于能力。选型时应关注三点——任务是否一次成型、报错是否可定位可修复、项目结构是否符合常识。对于十页面级别的原型任务，单智能体直连往往性价比更高；对于涉及构建配置、跨模块重构的复杂任务，再考虑引入编排能力，并预留人工介入的修复时间。

四、生成结果的典型缺陷与修复

4.1 界面层

生成产物的界面风格普遍偏”工程感”，缺乏面向消费者的视觉温度。实验中出现的具体问题包括：

• 布局整体偏移动端，桌面端仅做简单自适应，登录与注册页在宽屏下出现元素错位变形；
• 配色以单一品牌色铺满，按钮出现白底白字导致文字不可见；
• 图片资源全部使用占位符，未提供可替换的图片组件抽象；
• 详情页信息密度过低，仅有名称、价格与一个购买按钮，缺少规格、库存、评价等常见模块。

修复建议：在提示词中明确”配色需满足对比度要求””图片使用统一的 Placeholder 组件并暴露 src 属性””详情页需包含至少五个信息区块”。把视觉要求写成可检查的条目，比笼统地说”界面友好”有效得多。

4.2 代码层

较优的产物通常能做到样式与逻辑分离、组件职责基本清晰；较差的产物则问题集中：

• 表单校验缺失或仅有点击态的假校验；
• 项目结构过浅，所有页面平铺在同一目录，无 pages/components/hooks/data 分层；
• 模拟数据与组件强耦合，后续对接真实接口需大面积改动；
• 存在重复目录、路径引用错误等结构性问题，直接导致启动失败。

一个可参考的目标结构如下：

src/
  pages/          # 十个页面，按路由组织
  components/     # 通用组件：按钮、表单控件、占位图
  data/           # 集中管理的模拟数据
  hooks/          # 表单校验、购物车等复用逻辑
  styles/         # 全局变量与主题
  routes.jsx      # 路由表

4.3 流程层

购物主流程（详情→下单→成功）在多数产物中是完整的，但账户体系往往被简化：登录注册无状态保持、用户中心各子页之间缺少导航联动、钱包与卡券仅有静态展示。这说明工具擅长”页面级生成”，不擅长”跨页状态设计”。补救方式是在提示词中显式定义状态模型，例如用一份轻量的全局 store 描述用户、购物车、订单三类状态，并要求各页面从 store 读取而非各自维护副本。

五、把生成结果推进到可交付：四步复核法

1. 启动即验收：先跑通构建与启动，任何路径、依赖问题优先修复，避免在跑不起来的项目上继续加功能。
2. 结构体检：检查目录分层、数据是否集中、是否存在重复嵌套目录，结构问题越早改成本越低。
3. 流程走查：按用户真实路径手动点一遍十个页面，记录断链、错位、不可见文字等界面问题，形成清单后批量提交给工具修复，而非逐个对话。
4. 质量兜底：对表单校验、路由守卫、空状态展示做人工补写——这三处是生成产物最薄弱的环节，也是真实用户最容易踩到的地方。

六、选型建议

面向国内开发者选择此类工具时，建议以能力维度而非品牌维度评估：

• 任务一次成型率：同等提示词下，能否一次产出可启动、主流程可走通的项目；
• 响应稳定性：长任务过程中是否卡顿、中断，失败后能否从断点续做；
• 结构合理性：产物目录是否符合前端工程常识，是否便于二次开发；
• 修复效率：报错信息是否可读、修复轮次是否可控；
• 中立性提示：工具是否会在缺少接口时编造 API，这直接关系到后续对接成本。

对于本文这类十页面原型任务，可以优先选择直连生成能力成熟、响应稳定的方案；对于需要复杂拆解的任务，再评估多智能体编排的实际收益，并始终保留人工复核环节。工具负责把重复劳动压缩，工程判断仍然在人这一侧——这正是当前阶段智能编程工具最合理的定位。