先交代一下背景最近我用 AI 编程工具从零搭了一个电商网站这是第一次完全靠“对话来写代码”完成一个能跑通购买全流程的 Web 应用。整个过程跌跌撞撞踩了不少坑但也拿到了一个超出了预期的结果。这篇文章把我完整的实操过程、对 AI 生成代码的理解、以及遇到问题时的排查思路全部记录下来。如果你想了解“AI 现在到底能不能扛起一个真实项目”或者正打算用 AI 辅助做一个小型 Web 应用这篇文章应该能帮你省下大量试错时间。全文围绕电商网站这个场景展开不讲虚的全部是能直接上手参考的内容。1. 别急着写代码先把需求拆成 AI 能理解的块在我动手输入第一句需求之前我花了将近一天时间做一件事把“电商网站”这个词拆成一张功能清单。这一步决定了后面 AI 能帮上多少忙。1.1 电商网站的核心模块到底有哪些我在拆解时采用了“最小可用品”的思路就是先想清楚一个电商网站的最核心链路是什么。最终我确定的标准是用户进来能看到商品、能点进详情、能加入购物车、能下单、能在订单列表里看到自己买过的东西。这五件事连起来就是一条完整闭环任何一步断了这个网站都算不上真正的电商项目。围绕这条链路我把系统拆成了六个功能模块商品模块负责商品列表展示、商品详情页、商品基础数据名称、价格、库存、图片。购物车模块负责加购、修改数量、删除条目、计算总价。订单模块负责创建订单、订单列表、订单状态流转。用户模块负责注册、登录、获取当前用户信息。数据存储模块所有业务数据落库提供读写接口。前端页面模块用户实际看到的界面和交互逻辑。我在跟 AI 协作时没有一次性把六块需求全部丢给它而是按依赖关系分成了三个阶段来推进第一阶段做商品展示第二阶段做购物车第三阶段做下单和订单。这种拆分方式背后有一个很现实的考虑——AI 的上下文窗口是有限的一次性铺太多需求它生成的代码大概率会在某个环节“断片”要么少了某个字段要么接口路径前后对不上。1.2 技术选型决定了 AI 帮你实现一半还是一成技术选型这一步比我想象中更重要。同样的需求不同技术栈下 AI 能输出的质量差距非常大。我用的是被 AI 训练语料覆盖次数极多的主流组合前端用 React 加 Vite后端用 Node.js 加 Express数据库用 SQLite。选这套组合有三个理由。第一React 和 Express 是互联网上存量代码最多的技术之一AI 对它们的理解最深生成的代码从语法到模式都更可靠。第二Vite 启动速度快改完代码刷新就能看到效果非常适合快速验证 AI 产出的结果。第三SQLite 是零配置的单文件数据库不需要单独安装服务对前期专注功能验证非常友好。我的建议是在跟 AI 协作做一个真实项目时尽量不要选小众框架或者冷门语言。这不是说冷门技术不行而是 AI 在生成代码时更容易出现“一本正经地胡说八道”的情况——它会按照自己的理解生成一段结构正确但 API 完全不存在的代码这种问题在今天仍然高发。如果你准备用这套方法论去做别的项目选型时先问自己一句“这个技术栈互联网上的存量代码多不多”答案越确定AI 的发挥越稳定。2. AI 生成代码的正确姿势提示词设计很多人用 AI 写代码时直接把需求甩过去“帮我写一个电商网站”然后等着奇迹发生。但实际得到的结果往往是一段看上去很完整、但到处跑不起来的伪代码。我这次意识到跟 AI 协作的本质不是“命令它干活”而是“把一个模糊的想法翻译成精确的工程描述”。2.1 给 AI 下达任务的通用模板经过反复调整我总结了一套有效传达需求的模板它包含四个固定部分角色设定明确告诉 AI 现在充当什么角色比如“你是熟悉 React 和 Express 的全栈工程师”。技术约束说清楚代码要符合哪些技术前提比如“使用函数式组件和 Hooks不使用类组件”。功能需求用“输入、处理、输出”的逻辑来描述你想要的接口或页面。输出格式说明代码要包含什么以及哪些部分不需要比如“只返回接口代码不要生成页面”。举个例子我第一次请求后端商品接口时给出的提示词是这样的你是一名熟悉 Node.js 和 Express 的工程师。现在需要编写一个商品列表查询接口。接口路径是 GET /api/products返回 JSON 格式为 { code: 0, data: [ { id, name, price, stock, imageUrl } ] }。要求使用 sqlite3 模块直接执行 SQL 查询不引入 ORM。请只输出 JavaScript 代码不用做额外解释。这套写法比“帮我写商品接口”要好得多原因在于它把业务意图、输出格式、技术约束全部锁死了AI 没有发挥空间去自由发挥。我在整个项目里所有请求都遵循了这个模板生成代码的一次通过率显著提高。2.2 从后端接口到前端页面的递进生成我的实际推进顺序是先让 AI 生成后端接口再用真实的接口数据驱动前端页面。这个顺序的核心在于前端页面必须建立在实际存在的接口之上否则页面做完了却接不上数据纯属白忙。生成后端接口时我会一个模块一个模块地来。比如先让 AI 生成商品相关的全部接口列表、详情、库存扣减跑通后再让 AI 生成购物车接口最后生成订单接口。每个接口生成的代码我都要先手动验证一遍确认能返回正确的数据再进入下一个任务。生成前端页面时我会提供更具体的界面描述。比如请求一个商品卡片组件时我会告诉 AI这是一个展示商品缩略信息的卡片包含图片、商品名称、价格和加入购物车按钮点击按钮向 /api/cart 发送 POST 请求。接口数据和字段名我还会专门附在原请求里这样 AI 生成的前端代码才能和后端字段精确对应。整个过程中我最大的体会是AI 擅长的是从精确的需求描述生成对应的代码而不是替你做产品设计和系统设计。需求描述得越细代码质量越高需求描述得越模糊AI 生成的代码就越像是“课文背诵”——结构完整但经不起运行。3. 实操过程与关键环节实现理论和铺垫说了很多接下来到实际操作环节。我会把这次项目中从零到一实现的过程拆成几个关键环节每个环节都标明我当时是怎么操作 AI、在哪一步手动介入了代码以及这样做的原因。3.1 初始化项目和搭建基础框架项目最开始的结构是我手动搭的没有让 AI 代劳因为这一步做的是基础工程问题。我用 Vite 的初始化命令创建了前端项目然后在项目根目录下手动创建了 server 文件夹作为后端服务。初始化的具体操作如下# 创建 React 项目模板为 react npm create vitelatest my-shop -- --template react # 进入项目目录 cd my-shop # 安装前端依赖 npm install # 安装后端依赖在根目录操作 npm install express sqlite3 cors搭好骨架后我手动创建了一个最小化的 Express 服务目的就是先保证“点击按钮能看到一个页面”和“浏览器能访问一个后端接口”这两件事都能成立。在这个阶段我没有让 AI 介入原因是项目初始化涉及特定工具的当前版本兼容性AI 容易基于过期知识给出错误命令而人工操作反而更快更稳。基础框架跑通后我再把后端结构调整成适合后续扩展的模式。我把服务入口设置为一个主文件业务逻辑按照路由模块来划分。这样一来每个功能模块商品、购物车、订单都有独立的文件AI 生成的代码只需要通过标准方式挂载到入口文件中就能被正确加载。3.2 商品模块AI 生成接口与人工验证商品模块是电商系统的地基我选择先从这里作为 AI 协作的第一块试验田。我先用提示词模板让 AI 生成一张商品表结构和商品列表接口。AI 生成的建表 SQL 大致是这样的CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, price REAL NOT NULL, stock INTEGER NOT NULL, image_url TEXT, description TEXT );第一次生成的建表语句没有给价格字段设置默认值也没有对库存做非负约束。这些我在实际验证阶段发现后做了手工修正。AI 生成的代码骨架是可用的但业务细节需要人工把关——这个判断我在整个项目中反复验证基本是个定律。商品列表接口生成后我看到它已经能正确处理“没有数据时返回空数组”的情况。做好一个空状态是很容易被遗漏的细节AI 生成的代码在这个方面帮了大忙。我当时往表里手动插入了六条测试商品并使用了占位图片服务来模拟真实商品图片跑通了列表接口。商品列表页面的界面部分我同样把需求描述得很具体卡片式布局、商品名称加粗、价格用红色显示、点击卡片跳转到详情页。AI 在前端页面上的完成度同样不错。3.3 购物车模块状态管理的重头戏购物车模块是整个项目中技术含量最高的部分因为它牵涉到前端状态同步。用户在商品列表页点击“加入购物车”页面上的购物车数量角标要即时增加用户进入购物车页面要能看到完整的条目和总价用户修改数量前端界面要立刻重新计算。我让 AI 分别生成了购物车的后端接口和前端页面。后端接口相对简单围绕购物车表做增删改查。前端页面则复杂很多因为购物车数据是跨组件共享的我决定在全局层级管理购物车状态。在请求 AI 生成购物车前端逻辑时我明确指出使用 React 的 Context 管理购物车状态提供添加、修改数量、删除条目、计算总价的方法用 useEffect 在组件挂载时从后端拉取购物车数据。AI 生成的这部分代码基本可用但有两个问题需要手工修复。第一个问题是初始状态未处理。AI 生成的代码中购物车初始状态是空数组但未考虑加载状态时页面会闪现空画面的情况。我自己补了一个数据未加载时的占位提示。第二个问题是数量修改接口没有做防抖用户连续点击加号时可能发出多个并发请求造成数据错乱。我为修改数量的操作加了一个短暂的操作间隔避免并发问题。这里有一个值得分享的判断凡是涉及用户交互频率高、状态变化频繁的场景AI 生成代码通常只能给一个“能用但不够稳”的版本。生产级的前端交互细节还是要靠人来补充打磨。3.4 下单流程AI 容易“想当然”的业务逻辑下单流程是整个项目里 AI 生成代码时出错最多的地方。原因很简单下单涉及到库存扣减、订单创建、购物车清空三件事而且这三件事对一致性有要求——下单成功后库存必须扣减订单必须存在购物车必须清空不能出现“订单创建了但库存没减”的情况。AI 最初生成的代码是按顺序写完这三个操作没有任何机制来保证数据一致性。我在审查代码时发现了这个隐患如果第三步购物车清空失败整个请求已经向用户提示了“下单成功”但用户下次进入购物车仍然看到旧条目这个体验是很差的。我的修复方案是分两步走。第一步把库存扣减单独提取出来在扣减前先检查库存充足第二步在服务端用一个布尔变量记录整个流程是否全部成功任一步失败则整体判定为失败并尝试回滚已扣减的库存。虽然方案简单但它至少保证了单用户下单场景下的数据一致。AI 在订单模块帮我节省了大量时间的地方在于订单号生成、订单状态流转规则、前端订单列表展示这些标准功能它几乎一次就生成到了可运行的水平。这种“标准功能强、自定义业务弱”的分工我认为是当前 AI 编程的真实边界。3.5 前端的联调与真实体验前后端代码全部生成之后我进入了一个新的阶段真正的联调。之前的工作是分开验证后端接口可访问、前端页面可渲染而联调则是把两者在真实浏览器中连起来跑一遍完整链路。我重点验证了这批核心场景初始化状态下进入商品列表能看到商品点击商品卡片进入详情页点击加入购物车后页面上的购物车数量变为 1进入购物车页面能正确看到商品信息和总价修改商品数量后总价实时更新点击结算生成订单库存减一进入订单列表能看到唯一的待付款订单。在所有验证中最容易出问题的地方是跨域请求。前端跑在 Vite 的 5173 端口后端跑在 3000 端口浏览器默认会拦截这种跨域访问。我提前在后端代码中引入了跨域中间件并且配置了允许前端源访问才避免了进入环境后到处报错的情况。如果你是跟着复现一定别忘了这一步。整个联调过程我大概花了两个小时。速度比传统开发方式快了非常多但也确实暴露了一个现实问题AI 生成的代码跑通主流程很容易但出问题时的报错信息往往比较晦涩排查起来并不轻松。这个内容我在后面专门展开。4. 常见问题与排查技巧实录这部分我把真实遇到过的、以及基于同类项目判断最容易遇到的高频问题整理成清单。如果 AI 帮你生成一个类似项目你在复现时也碰到类似情况可以直接对照排查。4.1 AI 生成的组件库代码版本不匹配AI 生成前端代码时倾向于引用常见的第三方组件库但组件库本身迭代快AI 的训练数据往往滞后于当前版本。我在过程中遇到过一次AI 生成了一段按旧版 API 方式调用弹出提示组件的代码而我本地安装的已经是新版组件库两者的调用方式完全不同结果页面直接白屏。排查思路先看控制台报错确认是“某个组件没有导出”或者“方法不存在”这类提示。然后打开本地安装的组件库文档用文档中的写法替换 AI 给的旧写法。这里分享一个经验技巧让 AI 生成代码之前先在请求里单独声明一句“不要使用任何第三方 UI 组件库全部用原生 HTML 和 CSS 实现”。这样能避免大部分版本不匹配问题代价是页面美观程度有所下降但项目跑通优先。4.2 后端接口字段和前端字段对不上前端和后端由 AI 分两次生成时极容易出现字段名不一致的问题。比如后端返回的字段叫 stock前端页面读取的字段叫 inventory。这种情况在运行时会表现为页面有输入框但总是显示“未定义”或数量为空。排查思路打开浏览器开发者工具在网络面板里查看接口实际返回的 JSON 结构再对照前端代码中读取的字段名。找到不一致的地方统一改成同一套命名。为了避免这个问题再次发生我在后续请求 AI 生成前端页面时都会直接把后端接口返回的 JSON 示例粘贴进提示词里强制 AI 按真实字段名来写前端逻辑。4.3 购物车状态不同步的问题这个现象比较隐蔽在商品列表页面点击了“加入购物车”但购物车页面上看不到新增的商品。原因是 AI 生成的前端代码中列表页的点击事件和购物车页面的数据读取逻辑并不共享同一份状态导致一个页面写了数据另一个页面读的是另一个来源。排查思路先确认前端是不是用了全局状态管理。如果没有使用 Context 或状态管理库而是每个页面各自从后端读取数据那么在商品列表页操作写后端虽然成功了但购物车页面没有触发重新拉取界面自然不变。我的方案是让购物车页面在每次挂载时都从后端重新拉取购物车数据不去依赖前端某个全局变量的即时通知。4.4 库存扣减后商品列表数量没变化下单成功后商品详情页里的库存数依然和之前一样。这个问题我们在联调时也碰到过原因很直白商品详情页的数据是页面加载时从后端拉取的下单操作成功后页面没有重新获取最新数据。有两种修复方式我选的是“下单成功之后页面显示保存成功提示并在提示弹出时直接从后端拉取一次最新商品信息”。这种方式不需要引入复杂的前端状态机制对一个小型电商项目来说足够用。4.5 AI 生成代码里常见的边界情况缺失AI 对“主流程”完成得很好但对“流程之外”的情况经常忽略。我在代码审查中至少发现了这些缺失用户未登录直接访问购物车时接口是否返回友好错误消息商品库存为 0 时是否禁止点击加入购物车购物车为空时下单接口是否直接拒绝数据库表里没有数据时页面是否显示了没有商品的占位信息。这些问题我都手动补上了。给大家一个实用技巧每让 AI 完成一个接口或页面后立刻自己追问一遍——空数据情况、异常输入情况、未登录情况这三种边界条件有没有处理没有就让 AI 继续生成补丁或者自己手动补齐。这一步是 AI 编码项目里绝对偏不了的质量核心。5. 我的一些实操体会整个项目跑下来我对 AI 编程工具能做到什么程度、不能做到什么程度有了更真实的认知。AI 最好的应用场景是快速生成标准功能代码尤其是 CRUD 接口、列表展示、表单提交这类需要花费大量时间但不涉及复杂业务逻辑的代码。我把这些工作交给 AI 后大约节省了六成左右的编码时间。但注意这些代码并非拿来就能用像我前面提到的需要人工维护数据一致性、补齐边界情况、统一字段命名。这个过程需要你有一定的前后端基础至少能读懂每段代码在做什么。如果要给一个刚上手 AI 编程的人一个建议我会说别一上来就让它做一个完整系统而是先拆出一个小模块试水。让 AI 帮你生成一个商品列表接口然后你在浏览器里手动访问它亲手验证返回的数据让 AI 帮你生成一个商品列表页面然后你在真实接口上跑一下看看它是渲染成功还是白屏。当你对这个过程有了手感再去尝试完整的项目链路会踏实很多。我也要坦白说一个自己的体会就是从第一天起我就没抱着“AI 全自动完成一个网站”的天真念头。我的预期是——AI 能帮我把 60% 到 70% 的常规代码写掉剩下的 30% 到 40% 由我来负责设计业务规则、保证系统稳定、修补 AI 遗漏的细节。这个预期最终落地得很准所以整个过程我一直保持着平和的节奏AI 出代码我出判断两边协作着把东西做完。6. 这个项目的后续扩展方向走到这里你用 AI 搭出来的电商网站已经构成了一个最小可用产品。如果你有心把这个项目继续往前推下面几个方向可以按需选择它们都是我判断可以在现有代码上稳妥扩展的路线。第一个方向是接入真实的支付流程。当前的订单流程止步于“创建订单”并没有实际收钱的环节。你可以选择接入常见的支付服务把下单成功后的页面改成跳转到支付页面支付成功后再更新订单状态。这个扩展最能把一个雏形项目变成一个真正有商业意义的闭环。第二个方向是给商品模块增加后台管理能力。目前的商品数据是手动初始化的没有运营人员能操作的录入界面。你可以做一个简单的管理端具备商品的新增、编辑、上下架功能。如果不想重新造轮子也可以直接让 AI 生成一套基于同一套后端接口的管理页面。第三个方向是内容层面的扩展。电商网站不只是卖货还需要商品分类、搜索、推荐等模块。你可以在现有商品表里加上分类字段在列表页增加分类筛选和按名称搜索的功能。这类需求对 AI 来说非常友好它们有标准化的实现套路整个扩展过程会比你想象中顺。第四个方向是工程化强化也就是让项目向“真正可上线”的方向迈进。目前的数据库是 SQLite适合本地验证如果要部署到云服务器建议换成更通用的关系型数据库。访问量上来之后还要引入缓存机制和更严格的安全校验。这些内容已经超出 AI 协作的舒适区每走一步都需要更强的工程经验来支撑。扩展方向的优先级可以根据你的目标来决定想做演示就用第一个方向尽快闭环想做日常练习就优先做后台管理和搜索分类想贴近真实部署就重点走工程化强化的路。无论选哪条现有代码都提供了一个干净的起点这一点才是 AI 协作方式最有价值的地方。