企业官网建设流程全解析

先说个背景。最近两天，一个名叫“死了么”的宠物外卖App在个人开发者圈子里快速传开。起因是有位开发者晒出一段录屏：他用六小时，在AI编程工具的辅助下，从零复刻了一个覆盖商家列表、菜品点选、购物车、结算下单、订单跟踪的完整外卖应用，据说完成后还顺手考了个“标题党”名字——死了么。很多人都被这个名字逗笑了，但笑完之后，真正值得琢磨的问题是：这种六小时复刻爆款的事，到底是怎么发生的？它靠的仅仅是工具变聪明了吗？还是说，2026年的AI编程逻辑，已经悄悄换了一套玩法？

这篇文章就把这个项目从头到脚拆一遍。如果你正准备入坑AI辅助开发，或者已经在用Cursor、Trae、Copilot这类工具但总觉得效率上不去，那这篇内容可以直接当参考。我会把六小时的每个阶段怎么拆、提示词怎么给、架构怎么选、中间踩了哪些坑、哪些事绝对不能甩给AI，全部摊开讲清楚。

1. 六小时复刻“死了么”：一次典型的AI编程实战拆解

1.1 先搞清楚这个项目到底复刻了什么

先说结论：这绝对不是一个生产级商业项目，它是一个带有教学和演示性质的高保真Demo。名字叫“死了么”，定位是外卖类生活服务平台，覆盖的页面包括首页推荐、商家详情页、按分类点菜、购物车、订单确认、模拟支付、订单列表和订单详情。说白了，就是把某外卖App的主要C端流量路径走了一遍。

从技术角度看，它做了三个层面的“复刻”：

• 视觉层：红色主题色、底部Tab导航、卡片式商家列表、菜品加号图标、金额滚动动画，这些用户一眼就能认出来的视觉符号。
• 交互层：加购减购的Toast反馈、购物车展开面板、金额合计实时联动、下单后的状态流转。
• 数据层：商家数据、菜单数据、订单数据分别建模，用mock接口模拟真实请求。

有意思的是，这位开发者并没有逐像素对照原App截图去搬，而是先给出了一个非常口语化的需求描述：“我想要一个外卖App，首页是商家列表，点进去是菜单，加购要能自动计算价格，底部Tab有购物车和订单”。然后把这段话丢给了AI编程工具，让AI先出一版草稿。这个细节很多人没注意到，但它是整件事最重要的分水岭。

1.2 为什么偏偏选外卖场景来复刻

外卖App是一个“信息密度适中、业务链路完整”的典型场景。它既不像简单Todo应用那样只有一个页面的增删改查，也不像大厂全链路系统那样牵扯大量高并发设计。它天然包含了你开发一个真实业务系统要面对的大部分核心问题：

• 多页面导航与路由设计：首页、详情页、购物车、订单确认、订单列表，几个页面之间要正确传参。
• 状态共享与数据一致性：购物车状态既要体现在页面的角标上，又要在购物车面板里保持一致，还要在结算页汇总。
• 列表渲染与性能细节：商家列表、菜单列表的渲染、图片懒加载、滚动吸顶分类导航。
• 交互反馈的完整闭环：加购要有动画效果、减少数量要有限制条件、下单成功要有提示。
• 接口设计与mock数据模拟：前端不可能等后端，自己得先模拟出一套可用的数据接口。

这些恰好是日常Web开发的高频场景。用AI编程，不是让它帮你写一个“Hello World”，而是让它处理这种有真实复杂度、但又能被清晰描述的小型系统。六小时复刻一款爆款App，本质上是在测试AI能不能接得住这种“麻雀虽小五脏俱全”的需求。

1.3 六小时的时间切片

整个复刻过程并不是均匀地写六小时代码，而是可以被切割成几个清晰的时间单元：

• 第0~1小时：需求梳理、技术选型、项目初始化、基础脚手架搭建。这一步基本都是人工决策，AI在这里起辅助作用。
• 第1~3小时：页面结构与数据模型定义。这一步AI承担了最多工作，按照提示词生成商家列表页、菜单页、购物车组件的初版。
• 第3~5小时：核心业务逻辑与交互联动。包括购物车加减逻辑、价格计算、订单状态管理，这是AI最容易翻车的区域，也是最考验人机配合的阶段。
• 第5~6小时：样式打磨、细节修复、README补全、部署上线预览。

这个时间分配很有代表性。前一个小时和后一个小时，人力参与度是满格的。中间四个小时AI是主力。这和两年前“AI写代码”给人的印象已经完全不是一回事。

2. 2026年AI编程的核心逻辑：从“写代码”变成“提要求”

2.1 意图表达取代了语法表达

如果你用过早期的代码补全工具，你会记得那种感觉：AI只是一块更聪明的“自动补全键盘”。你在一个函数中间停留，它帮你续写后面几行。这种模式有一个致命限制：AI永远不会比你多懂一步，因为它的上下文只有你光标前几百个字符。

但在2026年的AI编程工作流里，最核心的变化是你要写的是“意图”，而不是语法。你在对话框里描述：“我希望用户点击菜品加号时，购物车图标上的数字加一，如果同一个菜品再点一次，购物车里应该合并数量而不是新增一项。”AI就直接帮你把Zustand的store、加购函数、UI角标联动全部实现。

这种转变的意义在于：你不再需要把“怎么做”翻译成代码语法，而是把“要什么”表达成清晰可执行的需求。一个像“死了么”这种体量的App，看起来要写几千行代码，但真正需要人工一行一行敲进去的，反而只占一小部分。

2.2 架构设计依然是人类的核心壁垒

AI能做的事情变多了，但有一个边界从未模糊，那就是架构决策。举个例子：是选择Next.js还是Vite + React？要不要用Zustand做购物车状态？mock数据放在内存里还是单独抽出json文件？订单状态是用静态字段模拟还是引入状态机？

这些问题，AI会根据你给的上下文给出建议，但最终拍板的必须是人。就算你完全不懂代码，AI也能帮你生成一套能跑的页面，但一旦遇到“这里购物车为什么要抽成全局状态而不放在组件内部”这种问题，AI的解释只是为了让你好理解，真正做架构权衡的依然是人。

在“死了么”这个项目中，技术栈选型是这样的：

这套选型几乎没有任何冷门技术，都是当前生态里最主流、AI语料最充分的选项。这是刻意为之的。AI编程的一大原则就是：尽量选择稳定的、资料充足的主流技术，不要为了一时炫技去碰冷门框架，冷门框架会让AI变成半个“文盲”。

2.3 Agent化：AI从“写代码”进化到“做事”

“死了么”这个项目能六小时完成，光有生成代码的能力是远远不够的。真正让效率暴增的是工具已经具备了“Agent化”的能力。什么意思？就是它不只是在你提问后生成一段代码，而是能自主地：

• 识别当前项目使用什么框架后，自动安装依赖、启动开发服务器。
• 在编译报错之后，直接打开报错文件，分析报错日志，尝试修复并重新运行验证。
• 当你要求新增页面时，自动创建对应目录和文件，并顺手把路由配置补好。
• 跑完测试后，如果发现控制台警告，主动提出优化建议。

这种模式已经接近“你和一名初级工程师坐在同一台电脑前工作”的体验。你负责说“接下来把购物车金额在结算页也显示出来”，它负责读文件、找位置、写代码、跑验证、回来跟你汇报。

但注意，Agent化也带来了新的信任问题。AI主动去改文件时，改的不一定是你要它改的那一处。所以，在2026年做AI编程，最核心的能力反而变成了“审查AI的改动”。你需要能快速看出它改了几处、改了哪些文件、有没有把不相关的东西弄坏。

3. 六小时憋出来的实操流程：从需求拆解到部署上线

3.1 第一步：把需求拆到AI能理解的最小粒度

很多人用AI编程第一步就卡住了，拿着一个巨大的需求“帮我做一个外卖App”直接丢进去。AI给你生成了一个花花绿绿的页面，看起来还行，但功能几乎没有。这就是需求拆解没做好的表现。

“死了么”这个项目的需求拆解，是拆成了这样一层一层的结构：

1. 业务模块拆解：外卖App包含四个业务模块：商家浏览、菜品点选、购物车结算、订单管理。
2. 页面清单拆解：首页（商家列表）、商家详情（菜品分类+列表）、购物车（侧边面板+确认页）、订单列表+详情。
3. 交互行为拆解：加购、减购、清空购物车、金额合计、下单确认、订单状态切换。
4. 数据字段拆解：商家（id、名称、评分、月售、起送价、配送费、距离、图片）、菜品（id、名称、价格、图片、分类、销量）、订单（id、商品列表、金额、状态、时间）。

拿这些拆解后的信息去和AI沟通时，不是一次性全塞给它，而是分阶段给。第一阶段只给页面和导航描述，让它搭建骨架；第二阶段才给交互规则，让它实现购物车逻辑。每一步都有明确验收标准，这样AI输出的产物才不会被前一步的问题污染。

3.2 第二步：用一份“项目简报”初始化AI对项目的认知

这一步非常关键，但很多人的做法是错的。最常见的错误是：让AI编程工具“新建一个Next.js项目”，然后就开始对话。你把项目初始化交给了AI，但AI对项目没有任何背景认知，后面你每说一句需求，它都要重新猜测上下文。

正确做法是：初始化项目之后，先创建一份项目上下文文档，内容大致如下：

# 项目简报：死了么外卖App Demo ## 项目定位 一个高保真外卖平台前端Demo，模拟真实外卖App的核心交互。 ## 技术栈 - Next.js 14 App Router - Tailwind CSS - Zustand（购物车状态管理） ## 目标用户 演示与学习，不接入真实支付。 ## 页面清单 1. 首页：商家列表（支持搜索、筛选） 2. 商家详情页：菜品分类、菜品加载、加购 3. 购物车：侧边滑出面板、商品增减、金额合计 4. 结算页：地址选择（mock）、支付按钮 5. 订单列表：订单卡片、状态标签 ## 数据要求 使用本地mock数据，接口路径为 /api/shops、/api/shops/[id]、/api/orders ## 视觉风格 红色主题，卡片式布局，App风格体验，移动端优先。

然后新建一个项目文档文件，把这段内容固定住。每当AI“跑偏”时，就把这份简报重新引入对话，让AI回到正轨。这比我见过的任何所谓“超级提示词”都管用。AI不是需要一个大而全的提示词，它需要的是你对项目的清晰定义。

3.3 第三步：让AI先画骨架，再填肉

主流程大概可以分成三轮对话：

第一轮：页面骨架

“根据项目简报，先创建五个页面的基础布局，使用App Router对应的路由结构。页面先用占位内容填充，不实现业务逻辑。商家详情页的路由参数是商家id。”

这一轮跑完之后，项目根目录下会出现对应的目录结构，每个页面能打开看到占位UI。这时候要做的事是启动开发服务器，人肉检查每一个路由能不能正常访问。这步不能省，因为路由配错是AI最常犯的低级错误，而一旦路由错了，后面所有业务逻辑都会串线。

第二轮：数据模型与接口

“在 /api 目录下创建商家列表接口和商家详情接口，返回mock数据。数据结构为：商家包含id、name、rating、monthlySales、deliveryFee、minOrder、distance、imageUrl、categories。categories是一个对象数组，每个分类包含name和dishes，dishes包含id、name、price、imageUrl、sold。”

AI会生成接口文件和mock数据。你打开接口地址，人工校验数据返回是否正确。很多时候，AI生成的mock数据存在大量重复或字段不一致，这一轮不检查，后面页面渲染出来就会是一堆“undefined”。

第三轮：核心交互

这是最核心的一轮：

“先为购物车创建一个Zustand store。状态包含items、isCartOpen、addItem方法、removeItem方法、clearCart方法。items的结构是{id: dishId, name, price, quantity, shopId}。注意：不同商家的菜品不能混在同一购物车里，如果从一个商家切换到另一个商家，清空原购物车，并给出提示。购物车面板做成右侧滑出的抽屉组件。”

讲清这个需求后，AI生成购物车逻辑。你需要逐个验证：加购按钮是否调用了addItem、数量是否合并、角标数字是否正确、切换商家是否清空购物车。这些逻辑互相耦合，一旦某一处AI理解有偏差，后续联调就是大型事故现场。

3.4 第四步：样式打磨与细节补全

骨架和业务逻辑跑通之后，还剩大量看着不起眼、但直接影响“像不像爆款”的工作：

• 首页卡片阴影与圆角调整、图片加载状态样式、空购物车时的占位插画。
• 商家详情页的分类滚动联动、菜品卡片的加号位置对齐、金额颜色变化。
• 结算页的金额明细排版、下单按钮的loading状态。
• 底部Tab栏的选中态图标变化、下拉刷新效果。

这里有一个非常推荐的技巧：不要直接对AI说“做得好看一点”，而是给它一个具体参照物。比如：“首页的商家卡片参考美团外卖的风格，卡片白底、圆角16px、阴影用浅灰色、评分星星用橙色。”这样AI才有落笔的依据。

我实测下来，样式类需求是AI最容易连续翻车的区域。它经常会把一个样式调整影响到了另一个组件，或者反复改但始终无法精确定位到像素级。有一个比较实用的策略是：把视觉问题拆成一条一条极小的指令，一次只改一个样式属性，例如“把结算页按钮的文字改成白色、背景红色、加圆角”。每一条改完，刷新页面看效果，确认了再发下一条。虽然看起来琐碎，但比一次列十条让AI改要快得多。

3.5 第五步：测试、打包与部署

这一步很多人会遗忘，但它才是6小时闭环的临门一脚。提交前的验证清单大致如下：

• 浏览器里走一遍完整链路：首页=>进店=>加购=>查看购物车=>去结算=>提交订单=>查看订单列表。
• 在手机上用移动端模式打开页面，检查布局是否错位。
• 检查Networks面板里有没有请求报错。
• 跑一遍构建命令，确认生产环境能正常打包。
• 部署到线上预览环境，把链接发到群里，让朋友实测打一遍。

我见到过太多“开发时一切正常、部署后白屏”的情况。原因五花八门，有的是环境变量没配、有的是API路径写成了绝对地址，但共同点是开发环境里没暴露出来。所以，最后一步的线上真机验证绝不能省。AI能帮你把代码写完，但它没法替你完成“把链接丢到手机微信里打开手机版浏览器去点一遍”这一步。

4. 真实踩坑记录：AI编程翻车现场与排查思路

4.1 最容易翻车的几个场景

六小时复刻过程中，表现得最像“新手程序员”的部分，往往集中在下面几个场景：

其中，AI“幻觉”第三方库这一条特别典型。AI可能会在生成的代码里引入一个看着很合理但实际上并不存在的包，然后告诉你“安装这个依赖即可”。一旦遇到安装报错，不要盲目追问AI，先自己搜索确认这个包是否存在。因为AI会为了“让代码顺利通过审查”而反复编造解决方案，陷入循环。处理这种问题，最稳的办法是用npm view 包名确认，或者直接搜索官方文档。

另一个高发问题是“文件覆盖”。AI为了完成“把购物车金额也显示在结算页”这个目标，可能顺带重构了整个页面文件。如果不对Git差异逐行检查，你怎么丢的代码都不知道。习惯用Git是你跟AI协作的底线，没有版本控制，就别开工。

4.2 让AI自己修Bug的正确姿势

很多人遇到AI生成的代码报错，第一反应是把报错信息整段贴回去，然后AI回答一段分析性文字，但问题没改。这个流程错在：AI在这里充当的是“顾问”而不是“执行者”。

更高效的做法是这样：

“运行 npm run build 报错了，错误信息如下：[贴报错]。请先运行 npm run build 复现这个错误，查看对应的文件内容，找到报错原因，然后直接修改代码。修改完后再重新运行构建，确认通过。”

关键区别在于：要求AI“先复现，再审读，再修改，再验证”，而不是“分析一下”。如果当前使用的AI编程工具没有自主执行命令的能力，那你就需要手动把文件内容、错误堆栈、运行环境信息、历史改动都贴给它。给它一个完整上下文，比扔给它一句“为什么报错”有效得多。

4.3 哪些事现阶段别指望AI

AI编程有一点很像刚毕业的员工：创意类工作干得很漂亮，但干杂活经常丢三落四。以下几类任务你最好全程把关：

• 多文件大规模重构：涉及几十个文件同时改动的重构，AI很容易改一半留一半，导致项目处于中间状态无法运行。
• 版本兼容性判断：升级某个依赖后，AI不确定哪些地方会受影响，因为它没有完整的运行时排查能力。
• 需要业务领域知识的功能：比如“配送费根据距离动态计算”“满减优惠叠加规则”。这些规则背后是业务逻辑，AI能写代码，但规则是否正确需要人来定。
• 复杂的动画细节：AI能写出CSS过渡，但要实现那种“丝滑的手感”，还是需要人反复调整参数。

5. 实操心得：在AI协同时代提前打个总结

5.1 提问的质量决定产出的质量

从前大家说“代码写得不好，是人不行”，现在应该改成“提示词给得不清，是需求不明确”。同一个AI，在不同人的手里产出天差地别。什么决定差异？是你对业务目标的拆解是否清晰、验收标准是否可执行、上下文是否足够完整。

我见过最高效的用法，是像写代码注释一样去写需求说明。把“做一个页面”改成“做一个商家详情页，上方是头图信息区，包含了商家的名称、评分、月售、配送信息，下方是菜品分类栏，点击某分类，右侧菜品列表滚动到对应区域”。当需求描述本身已经不需要代码就能被别人执行时，AI生成的代码基本一次过。

5.2 代码审查能力是AI时代的硬通货

Git diff是人机协作的第一道防线。每次让AI改完东西，第一件事不是夸它，是看diff。我给自己定的规矩是：AI每完成一次改动，我必须先看diff，再点刷新页面。时间久了你会发现，大部分AI引入的问题在diff阶段就能发现，根本轮不到运行时调试。

这个习惯还能帮你持续积累“AI更容易犯什么错”的直觉。比如它特别容易把类型定义改了但实际调用没改，或者把一个公共组件的样式调整连带影响了页面上的其他区域。这些直觉不是天生的，就是一次次看diff看出来的。

5.3 上下文管理决定协作深度

AI和人的一次对话窗口是有限的，项目越大，越不可能把所有代码都塞进去。所以在实操时，要刻意训练“把问题描述得更利于AI定位”的能力。不要只说“购物车有问题”，要说“购物车组件在src/components/CartDrawer.tsx，问题是在切换到另一家店后没有清空items，这个store在src/stores/cartStore.ts里，麻烦先看一下这两个文件再修改”。当你主动给AI指路定位文件时，它的准确率会成倍提升。

再分享一个经验：把那些经常要跟AI重复交代的上下文固化成项目文档，放进项目根目录。这样每次开启新对话时，直接把文档路径指给AI就行，不用重复粘贴。这相当于给你的AI编程建了一个“长期记忆”。

我看到这个“死了么”项目之后，其实最高兴的不是它6小时做出来了，而是它清楚地向大家展示了一点：2026年，做开发的门槛已经从“能不能写出代码”转移到了“能不能把要做的事情讲清楚”。代码生成能力越来越便宜，而理解需求、拆解问题、审查质量的能力，依然是每个开发者真正值钱的地方。

最后再分享一个小技巧：如果你准备尝试这种几天做完一个项目的AI工作流，别一上来就挑战大而全的东西。先挑一个你日常使用频率最高的应用，用周末时间复刻它最核心的70%，把需求拆解、AI对话、Git审查这套流程完整走一遍。走完你自然就知道，六个月后的AI编程会是什么样子。