我用 AI 写仿美团外卖系统，才搞懂什么是 Prompt

一次真实开发经历，重新认识 Prompt｜Prompt 系列第一篇（叙事篇）

---

一、故事的开头：一句话，AI 就开始干活了

前段时间，我在直播里做了一件事——用 AI 写一个仿美团外卖系统。不是 demo，也不是小功能，而是一整个系统：用户端、商家端、骑手端、以及后台管理，全要有。说实话，当时也没想太多。打开 Cursor，在对话框里敲了一句，然后回车：

“帮我设计一个仿美团外卖系统，包含用户端、商家端、骑手端。”

接下来发生的事情让我愣了一下——AI 开始疯狂输出：

• 系统要分哪些模块
• 数据库表结构长什么样
• 用户下单到骑手接单的完整流程
• 每个端需要哪些页面
• 甚至连接口该怎么设计都给你列出来了

直播间的弹幕飘过一句："就这一句话，它就知道要干啥？"我当时也在想这个问题。

更离谱的是，它不光列了功能，还帮你理清了业务逻辑——比如用户下单之后订单状态怎么流转、什么时候通知商家、骑手怎么抢单、超时怎么处理。这些东西我自己都没想到，它先帮你想好了。弹幕又飘过来一句："这 AI 比产品经理还靠谱。"我笑了一下，但心里知道——这不是 AI 靠谱，是我那句话恰好说对了方向。

后来我才知道，我敲下去的那句话，就叫 Prompt。

【插图1】Cursor 对话截图——一句话生成仿美团外卖系统

建议截图内容：Cursor 中输入 Prompt 后，AI 输出系统设计方案的界面截图

---

二、当时的我，根本不知道这是 Prompt

说来惭愧，那会儿我根本不知道"Prompt"这个词。我只知道一件事：跟 AI 说话，它就给你干活。说得越清楚，它干得越好。 在开发仿美团外卖系统的过程中，我反复在做一件事——改我说的话。

最开始我说：

“帮我写个外卖系统。”

AI 给了一坨东西，模块很散，逻辑也不通。给的代码有前端有后端，但对不上。表结构也乱七八糟，一个 order 表里塞了二十多个字段，连商家信息都揉在一起。然后我改了一下：

“仿美团外卖，要有用户端、商家端、骑手端，技术栈用 Spring Boot + Vue。”

这回好多了，模块清晰了，技术选型也对了。表结构开始分离了，商家是商家表，骑手是骑手表，不再糊在一起了。但还不够，我又加了一些东西：

“用户端需要有首页、分类、搜索、购物车、下单、支付、订单追踪。商家端需要有菜品管理、订单管理、营业统计。骑手端需要有接单、导航、送达确认。”

这次，AI 的输出几乎可以直接拿来当需求文档用。它甚至给我画了一个简易的页面导航结构，告诉我每个端有哪些页面、页面之间怎么跳转。我当时的感觉是：AI 变聪明了。但后来我才意识到，不是 AI 变聪明了，是我说的话变清楚了。而我反复修改的那些话，就是在优化 Prompt。只不过那时候的我，不叫它 Prompt，我管它叫"提示词"。

---

三、Prompt 到底是什么？（说人话版）

如果你去搜"Prompt"，大概率会看到一堆解释：

• “Prompt 是给大语言模型的指令”
• “Prompt 是人机交互的输入”
• “Prompt Engineering 是一种新兴的工程范式”

看完之后，你大概率一头雾水。所以我用大白话说一下——

Prompt，就是你给 AI 的说明书。 就这么简单。你可以把它想成几个场景：

场景一：给程序员提需求

你是产品经理，对面坐着一个程序员。你跟他说："帮我做个系统。"他能做出来吗？能。但大概率不是你想要的。你得告诉他：做什么系统、给谁用、有哪些功能、交互怎么走、用什么技术栈。说得越清楚，他做得越对。

Prompt 就是你给 AI 提的需求。

场景二：写需求文档

你写过需求文档吗？PRD 那种。一个好的 PRD，模块清晰、流程完整、边界明确，开发拿到就能干。一个烂的 PRD，三言两语、模棱两可，开发拿到只能猜。

Prompt 就是你给 AI 写的 PRD。

场景三：点外卖写备注

你点外卖的时候，备注栏写过"不要辣"吧？写过"米饭多一点"吧？如果你什么都不写，商家就按默认的来。运气好口味对了，运气不好你不吃香菜结果满盘子都是。如果你写了"不要辣、不要香菜、米饭单独打包、筷子多给一双"，商家就知道你要什么。

Prompt 就是你点外卖时写的备注。

场景四：导航输目的地

你开车出门，打开导航。你输入"吃饭的地方"，导航大概率不知道你要去哪。你输入"朝阳区三里屯太古里"，它立马就给你规划路线了。Prompt 就是你输入的目的地。 越精确，路线越靠谱。

说到底——

Prompt = 你对 AI 说的话 = 你给 AI 的说明书。

你说得越清楚，AI 干得越好。你说得越模糊，AI 就越瞎猜。

---

四、为什么很多人觉得 AI 不好用？

我见过很多开发者试了一下 ChatGPT 或者 Cursor，然后得出结论：

“AI 写代码不行，写出来的东西不能用。”

我之前也这么想过。我记得有一次让 AI 帮我写一个登录功能，就说了一句"帮我写个登录"。它给了我一段代码，没有参数校验，没有密码加密，没有 token，甚至连数据库查询都是 mock 的。我看了一眼，关掉了对话框，心想：就这？

但后来我发现，不是 AI 不行，是你说的话不行。 来看一个真实的对比。

第一种说法：

“帮我写一个系统。”

AI 收到之后一脸懵——什么系统？给谁用？什么功能？什么技术栈？前端还是后端？要不要数据库？它只能瞎猜，输出的东西自然一团糟。这就好比你走进一家餐馆，跟服务员说："给我来一份吃的。"服务员能上菜吗？能。但上的大概率不是你想吃的。

第二种说法：

"我要开发一个仿美团外卖系统，使用 Spring Boot + MyBatis-Plus + Vue3 + Element Plus。

系统分为三个端：

1. 用户端：首页推荐、商家列表、菜品搜索、购物车、下单支付、订单追踪、评价
2. 商家端：店铺管理、菜品管理（增删改查）、订单处理、营业数据统计
3. 骑手端：实时接单、订单导航、送达确认、收入统计

请先给出数据库表结构设计，再给出后端模块划分。"

AI 收到之后，输出清清楚楚、条条框框，拿过来稍微改改就能用。同一个 AI，同一个模型，差距在哪？ 差距就在你说的那句话——就在你的 Prompt。你以为是 AI 的问题，其实是你的问题；你以为要换个更好的 AI，其实只需要换一种说法。

【插图2】简单 Prompt vs 结构化 Prompt 对比图

建议内容：左边"帮我写个系统"→ 混乱输出；右边结构化 Prompt → 清晰输出。标题：Prompt 决定输出质量

---

五、我其实不是直接和 Cursor 对话，而是先用 ChatGPT 写 Prompt

很多人看我直播，以为我就是打开 Cursor、敲一句话、然后代码就出来了。其实不是。我的真实流程是这样的：

第一步：先打开 ChatGPT，想清楚要做什么

在动手写代码之前，我会先在 ChatGPT 里跟它聊。不是聊天，而是让它帮我设计 Prompt。你没看错——我用 AI 来写给 AI 的指令。

比如我要做仿美团外卖的订单模块，我不会直接在 Cursor 里说"帮我写订单模块"。我会先在 ChatGPT 里说：

“我要做一个仿美团外卖系统的订单模块。你帮我想一下这个模块需要考虑哪些功能点，我后续要把这些功能点整理成 Prompt，丢给 Cursor 来生成代码。”

ChatGPT 会给我列出来：

• 下单流程（选菜→加购物车→确认订单→选地址→选支付方式→提交）
• 订单状态流转（待支付→已支付→商家接单→骑手接单→配送中→已送达→已完成→已取消）
• 订单超时处理（未支付超时自动取消、配送超时提醒）
• 订单金额计算（菜品金额 + 包装费 + 配送费 - 优惠券 - 满减活动）
• 订单关联关系（和用户、商家、骑手、地址、菜品的关联）
• 退款逻辑（已支付未接单可退、已接单协商退）

这些东西，我自己想的话要半个小时。ChatGPT 两分钟就给我列完了，而且比我想的还全。

第二步：让 ChatGPT 帮我优化 Prompt

有了功能点之后，我会让 ChatGPT 帮我把这些零散的点整理成一段结构化的 Prompt。我会说：

“帮我把刚才梳理的订单模块功能点，整理成一段 Prompt。要求：功能描述清楚、技术栈是 Spring Boot + MyBatis-Plus、要有数据库表设计和接口设计。”

ChatGPT 会输出一段非常工整的 Prompt，层次清晰、逻辑完整。有时候我还会跟它来回几轮，比如：

“配送费的计算规则要加上，按距离阶梯计价。”

“退款流程要细化，区分全额退和部分退。”

“加一个约束：所有金额用 BigDecimal 处理，不能用 double。”

每加一条要求，Prompt 就更完善一点。这个过程，其实就是在打磨需求。

第三步：把打磨好的 Prompt 丢给 Cursor

等 Prompt 打磨得差不多了，我会把它复制到 Cursor 里，回车。Cursor 拿到这段结构化的 Prompt，输出的代码质量就完全不一样了——表结构是分好的，接口是分层的，Service 和 Controller 是解耦的，甚至连异常处理和参数校验都给你加上了。如果我直接在 Cursor 里写"帮我写订单模块"，大概率给我一个 Order 类加三个接口就完事了。

同一个 Cursor，同一个模型，差距就在 Prompt。

第四步：Cursor 生成代码

Cursor 不只是生成一个文件。你给它一个好的 Prompt，它会帮你生成一整套代码：

• Entity 实体类
• Mapper 接口和 XML
• Service 层业务逻辑
• Controller 层接口
• DTO 和 VO 对象
• 甚至 SQL 建表语句

我做仿美团外卖系统的时候，一个模块的代码大部分都是 Cursor 生成的。我要做的事情是检查逻辑、调整细节、处理模块之间的衔接。这个效率，传统开发根本比不了。

第五步：拿回 ChatGPT 做 Review

代码生成之后，我不会直接就用。我会把关键代码贴回 ChatGPT，让它帮我检查：

“帮我 review 一下这段订单服务代码，看看有没有逻辑漏洞、安全问题、性能隐患。”

ChatGPT 确实能发现一些问题。比如有一次它告诉我，我的订单金额计算没有加分布式锁，高并发下可能出现超卖；还有一次它发现我的退款逻辑没有校验订单状态，已完成的订单居然也能退。这些问题我自己 review 可能要花很长时间，ChatGPT 几秒钟就指出来了。

总结一下这个流程

ChatGPT 负责思考，Cursor 负责执行。 ChatGPT 擅长的是理解需求、梳理逻辑、设计方案，它是军师；Cursor 擅长的是根据 Prompt 快速生成代码，它是执行者。而连接这两个 AI 的桥梁，就是 Prompt。

你在 ChatGPT 里打磨 Prompt，然后丢给 Cursor 执行，执行完了再拿回 ChatGPT 检查。一个循环下来，代码的质量比你自己写的还稳。我后来做仿京东商城和图书商城，也是这个流程。用得越多，越觉得这个工作方式丝滑。

【插图3】AI 开发工作流

ChatGPT → 设计/优化 Prompt
      ↓
Cursor → 根据 Prompt 生成代码
      ↓
ChatGPT → Review 代码、发现问题
      ↓
Cursor → 根据反馈修改代码
      ↓
   完成

标题：AI 开发工作流——ChatGPT 思考，Cursor 执行

---

六、回到仿美团外卖：一个真实案例

让我拿仿美团外卖系统的开发过程，给你看看 Prompt 的差距到底有多大。

第一次：随便说一句

我最早在 Cursor 里输入的是：

“帮我写一个外卖系统。”

AI 给了我什么呢？一个简单的 CRUD 示例。一个 Order 表，一个 User 表，一个 Food 表，加起来就几个接口，连购物车都没有，更别说骑手端了。这东西能叫外卖系统？充其量就是一个"食堂点餐小 demo"。

表结构长这样：

CREATE TABLE user (id, username, password, phone);
CREATE TABLE food (id, name, price, description);
CREATE TABLE order (id, user_id, food_id, quantity, total_price, status);

三张表，完事了。没有商家的概念，没有地址的概念，没有骑手的概念。一个 order 直接关联一个 food——那如果我一单点了三个菜呢？没考虑。代码也是一样，Controller 里直接写 SQL，连 Service 层都没有。

第二次：说清楚一点

我意识到不对，重新组织了一下语言：

"我要做一个仿美团外卖的系统，有三个端：

• 用户端：可以浏览商家、搜索菜品、加入购物车、下单支付、查看订单状态
• 商家端：可以管理店铺信息、管理菜品、处理订单
• 骑手端：可以接单、查看配送路线、确认送达

技术栈：Spring Boot + Vue3
数据库：MySQL

先帮我设计数据库表结构。"

这次，AI 的输出完全不一样了：

• 给了十几张表：用户表、商家表、菜品表、分类表、购物车表、订单表、订单明细表、骑手表、配送记录表、评价表、地址表……
• 每张表字段清清楚楚，主外键关系也标注好了
• 甚至还给了索引建议
• 订单和订单明细分开了，一对多关系
• 地址表独立出来了，支持多地址

同一个 AI，差距就在那几行字。

后来的开发过程中，我用类似的方式让 AI 帮我做了很多事：设计接口文档、写 Service 层代码、生成前端页面、写测试用例。每次的关键，都是——我怎么跟它说。我说得越清楚、越具体、越有结构，AI 给我的东西就越能直接用。

这就是 Prompt 的力量。不是什么高深的技术，就是把话说清楚。

---

七、我踩过的几个错误 Prompt

在做仿美团外卖系统的这段时间里，我踩过很多 Prompt 的坑。回头看，每一个坑都是同一个问题——说得不够清楚。我把印象最深的几个错误分享出来，你看看有没有似曾相识的感觉。

错误一：“帮我写外卖系统”

这是我最早犯的错误，一句话扔过去，啥也没说清楚。AI 给出来的东西：

• 前后端混在一起，一个 main 方法里又写路由又写 SQL
• 没有分端的概念，用户和商家用同一个页面
• 数据库就三张表，连基本的业务逻辑都承载不了
• 代码风格像是一个大学课设

为什么会这样？因为"外卖系统"这四个字，对 AI 来说信息量太少了。它不知道你要什么级别的系统——是一个课设 demo，还是一个接近生产的项目？是单端的还是多端的？用什么技术栈？你不说清楚，AI 就按最简单的来。

错误二：“写订单模块”

后来我开始一个模块一个模块地写，对着 Cursor 说"写订单模块"。AI 给了我一个 OrderController + OrderService + OrderMapper，能跑，但极度简陋：

• 没有订单状态流转
• 没有订单金额计算逻辑
• 没有和购物车的关联
• 没有和支付的关联
• 甚至没有订单明细——一个订单只能买一个菜

为什么？因为"订单模块"这四个字，对人类来说很明确，但对 AI 来说太模糊了。你没告诉它订单的生命周期是什么、状态有哪些、金额怎么算、和哪些模块有交互。你以为说了个模块名就够了，但 AI 需要的是模块的全貌。

错误三：“设计数据库”

还有一次，我说"帮我设计外卖系统的数据库"。AI 给了一版设计，但问题很多：

• 所有字段都是 VARCHAR，没有合理的数据类型
• 没有创建时间、更新时间
• 没有逻辑删除字段
• 外键关系标注不清
• 表名不规范，有的用下划线有的用驼峰
• 没有考虑索引

这些问题不是 AI 不会，而是我没要求。我就说了一句"设计数据库"，它怎么知道你要不要逻辑删除？怎么知道你要不要时间字段？怎么知道你的命名规范是什么？Prompt 里没提到的东西，AI 就靠猜。而它猜的，大概率不是你想要的。

错误四：“帮我写个页面”

做前端的时候我犯了一样的错。我说"帮我写一个商家列表页面"，AI 给了一个页面，但：

• 没有搜索功能
• 没有分类筛选
• 没有分页
• 没有商家评分显示
• 没有配送费和起送价
• 样式像是上世纪的网页

因为我只说了"商家列表"，它就只给了一个列表。至于列表里展示什么信息、有什么交互、长什么样子，我一个字没提。你觉得理所当然的东西，AI 不觉得。你得明明白白说出来。

这些错误的共同点

回头看这些错误，本质都是一样的：

1. 缺少上下文——没告诉 AI 这个系统的背景和定位
2. 缺少细节——只给了大方向，没给具体要求
3. 缺少约束——没有限定技术栈、命名规范、设计原则
4. 缺少输出要求——没告诉 AI 你希望它输出什么格式、什么粒度

这四个问题，后来我都学会了怎么解决，但那是下一篇要讲的事情。这一篇，我只想让你知道一件事：如果你觉得 AI 给的东西不好，先别急着骂 AI，先回头看看你自己说了什么。

---

八、Prompt 如何一步步变清晰——以商家菜品管理为例

前面说了一堆错误，你可能会想：那到底怎么改？我拿仿美团外卖系统里的"商家菜品管理"功能举个例子，让你看看一个 Prompt 是怎么从模糊变清晰的。

第一版 Prompt：随口一说

“帮我写商家菜品管理功能。”

AI 的输出：一个 Dish 实体类，字段只有 id、name、price、description；一个 DishController，四个接口：增删改查。没有分类，没有图片，没有上下架，没有排序。这东西能叫菜品管理？顶多叫"菜品的增删改查"。

第二版 Prompt：加了一些细节

"帮我写仿美团外卖系统的商家端菜品管理功能。

菜品属性包括：名称、价格、图片、分类、描述、上下架状态。

需要支持：新增菜品、编辑菜品、删除菜品、上下架切换、按分类查询。

技术栈：Spring Boot + MyBatis-Plus。"

AI 的输出好多了：

• Dish 实体类字段齐全了
• 多了一个 Category 分类表
• 支持上下架状态切换
• 按分类筛选也有了
• 代码分层了，Controller → Service → Mapper

但还有一些问题：图片上传没有处理、菜品规格没有考虑（大份/小份/加料）、没有价格校验（价格不能为负）、批量操作没有（批量上架/下架/删除）。

第三版 Prompt：接近真实需求

"我在做一个仿美团外卖系统，现在需要开发商家端的菜品管理模块。

技术栈：Spring Boot + MyBatis-Plus + Vue3 + Element Plus

功能要求：

1. 菜品信息：名称、主图（支持上传）、价格（BigDecimal，不能为负）、分类、描述、上下架状态
2. 菜品规格：每个菜品可以有多个规格（如大份/小份），每个规格有独立的价格
3. 菜品分类：支持一级分类，商家可以自定义分类
4. 菜品操作：新增、编辑、删除（逻辑删除）、上架、下架、批量上下架
5. 菜品查询：支持按名称搜索、按分类筛选、按上下架状态筛选、分页查询
6. 菜品排序：支持手动拖拽排序

请先设计数据库表结构（包括菜品表、分类表、规格表），再给出后端接口设计，最后给出 Service 层核心代码。

要求：

• 使用 MyBatis-Plus 的逻辑删除和自动填充功能
• 所有金额使用 BigDecimal
• 接口遵循 RESTful 规范
• 返回统一响应格式 R"

AI 这次的输出，几乎可以直接用：三张表设计合理、字段完整、索引到位；接口设计覆盖了所有 CRUD 和状态切换操作；Service 代码有参数校验、有异常处理；逻辑删除和自动填充都用上了；统一响应格式也按要求来了。

三个版本的 Prompt，同一个 AI 模型，输出质量天差地别。

这个进化过程告诉我们什么？Prompt 不是写一次就完事的，它是需要迭代的。 就像写代码一样，第一版能跑就行，第二版优化结构，第三版才是生产级的。Prompt 也一样——第一版让 AI 知道你要什么，第二版告诉它细节，第三版给它约束和标准。每迭代一次，输出质量就上一个台阶。

---

九、不同 Prompt，输出差异到底有多大？

为了让你直观感受 Prompt 的差距，我再举几个仿美团外卖系统开发中的真实例子。

案例一：用户注册接口

简单 Prompt：

“帮我写个注册接口。”

AI 输出：

@PostMapping("/register")
public String register(String username, String password) {
    User user = new User();
    user.setUsername(username);
    user.setPassword(password);
    userMapper.insert(user);
    return "success";
}

问题一大堆：密码没加密、没有参数校验、没有重复用户名检测、没有手机号、返回格式不统一、没有异常处理。

结构化 Prompt：

"帮我写仿美团外卖系统的用户注册接口。

要求：

1. 注册信息：手机号、密码、验证码
2. 手机号格式校验（正则匹配11位手机号）
3. 密码使用 BCrypt 加密存储
4. 手机号不能重复注册
5. 验证码从 Redis 中获取并校验
6. 注册成功返回 JWT token
7. 使用统一响应格式 R
8. 使用 @Validated 做参数校验

技术栈：Spring Boot + MyBatis-Plus + Redis + JWT"

AI 输出： 一套完整的注册逻辑——DTO 参数校验、手机号唯一性校验、Redis 验证码校验、BCrypt 密码加密、JWT 生成、统一异常处理、完整的 Service 层代码。

差距在哪？全在 Prompt 里。

案例二：购物车功能

简单 Prompt：

“帮我写购物车。”

AI 输出： 一个 Cart 表，就两个字段：user_id 和 food_id。一个 add 接口，一个 list 接口，完事。没有数量的概念，没有商家隔离（不同商家的菜品在一个购物车里），没有合计金额，没有清空操作。

结构化 Prompt：

"帮我开发仿美团外卖用户端的购物车模块。

业务规则：

1. 每个商家的购物车独立（切换商家时清空当前购物车，或提示用户）
2. 同一菜品同一规格可叠加数量
3. 不同规格视为不同条目
4. 购物车要实时计算合计金额（菜品小计 + 包装费）
5. 支持修改数量、删除单个菜品、清空购物车
6. 购物车数据存 Redis（用户未下单前保留）

需要的接口：

• 添加菜品到购物车
• 修改购物车中菜品数量
• 删除购物车中单个菜品
• 清空购物车
• 查看当前购物车（含合计金额）

技术栈：Spring Boot + Redis
数据结构建议使用 Redis Hash"

AI 输出： 完整的购物车方案——Redis Hash 存储设计、商家隔离逻辑、数量叠加、规格区分、金额实时计算、五个接口的完整实现。

同一个 AI，差距肉眼可见。

案例三：订单列表页面

简单 Prompt：

“帮我写订单列表页面。”

AI 输出： 一个 el-table，几列数据。没有筛选、没有分页、没有订单状态标签、没有操作按钮，像一个学生作业。

结构化 Prompt：

"帮我写仿美团外卖用户端的订单列表页面。

页面要求：

1. 使用 Vue3 + Element Plus
2. 顶部有 Tab 切换：全部、待支付、待接单、配送中、已完成、已取消
3. 每个订单卡片显示：商家名称、商家logo、菜品摘要（最多显示2个+剩余数量）、订单金额、下单时间、订单状态
4. 订单状态用不同颜色的标签区分
5. 每个订单有操作按钮：待支付→去支付、配送中→查看配送、已完成→再来一单、已完成→去评价
6. 列表支持下拉加载更多（移动端风格）
7. 空状态显示"暂无订单"插图

请给出完整的 Vue 组件代码。"

AI 输出： 一个完整的、接近美团风格的订单列表组件——Tab 切换、卡片布局、状态标签、操作按钮、下拉加载、空状态处理，全都有。

你看，AI 的能力一直在那里。你给它什么质量的 Prompt，它就给你什么质量的输出。

---

十、Prompt 在整个开发过程中的作用

做完仿美团外卖系统之后，我回头看了一下整个开发过程，发现了一件有意思的事：整个开发流程的每一步，都是从一段 Prompt 开始的。 让我带你走一遍。

第一步：竞品分析——Prompt 帮我拆解美团

在动手写代码之前，我需要搞清楚美团外卖到底有哪些功能。传统做法是什么？下载 App，一个页面一个页面地截图，自己整理功能列表。我的做法是，在 ChatGPT 里写了一段 Prompt：

“请帮我分析美团外卖 App 的核心功能模块，分为用户端、商家端、骑手端三个维度，列出每个端的一级功能和二级功能。”

两分钟，ChatGPT 给了我一份清晰的功能清单。从首页推荐到搜索筛选，从购物车到支付，从商家接单到骑手配送，全都列好了。我对着这份清单做了一些裁剪（毕竟是仿写，不需要做到 100%），就拿到了项目的功能范围。传统竞品分析要一两天，Prompt 帮我两分钟搞定。

第二步：产品设计——Prompt 帮我拆模块

功能范围确定后，我需要把它拆成具体的模块。我又写了一段 Prompt：

"基于上面的功能分析，帮我把用户端的功能拆成以下模块，并列出每个模块的核心功能点和页面列表：

1. 用户模块（注册、登录、个人信息）
2. 首页模块（推荐、分类、搜索）
3. 商家模块（商家列表、商家详情、菜品列表）
4. 购物车模块（添加、修改、删除、结算）
5. 订单模块（下单、支付、订单列表、订单详情、订单追踪）
6. 评价模块（评价列表、发表评价）
7. 地址模块（地址列表、新增地址、编辑地址）"

ChatGPT 帮我把每个模块细化到了页面级别，包括每个页面需要哪些交互元素、调用哪些接口。这份东西拿出来，跟一个初级产品经理写的 PRD 差不多了。

第三步：技术设计——Prompt 帮我设计架构

模块拆好了，下一步是技术方案：

"我要基于以上模块设计，做一个仿美团外卖系统。

技术栈：Spring Boot 2.7 + MyBatis-Plus + MySQL + Redis + Vue3 + Element Plus

请帮我设计：

1. 后端项目结构（包名规范）
2. 数据库表结构（所有表，包含字段、类型、注释）
3. 通用组件设计（统一响应、统一异常处理、JWT鉴权、Redis 配置）"

AI 给了完整的技术方案。项目结构分 controller、service、mapper、entity、dto、vo、config、common、utils；数据库十几张表设计合理；通用组件该有的都有。

第四步：开发编码——Prompt 驱动 Cursor 生成代码

这一步我已经讲过了。把在 ChatGPT 里打磨好的 Prompt 丢给 Cursor，一个模块一个模块地生成代码。每次生成代码，我都会在 Prompt 里明确：

• 这个模块的业务逻辑
• 关联的其他模块
• 技术要求和约束
• 需要生成哪些文件

第五步：测试验证——Prompt 帮我写测试

代码写完了，测试也不能少：

"帮我为订单服务写单元测试。

测试框架：JUnit5 + Mockito

需要覆盖的场景：

1. 正常下单流程
2. 库存不足时下单失败
3. 订单状态非法流转（如已完成→待支付）
4. 订单金额计算准确性
5. 超时未支付自动取消"

AI 直接给了一套测试代码。测试用例覆盖了核心场景，MockBean 注入、Assertions 断言，写得比我自己写的还规范。

你发现规律了吗？

竞品分析——Prompt。产品设计——Prompt。技术设计——Prompt。开发——Prompt。测试——Prompt。 每一步的起点，都是一段 Prompt。

传统开发流程里，不同的阶段需要不同的人来推动：产品经理推需求、架构师推设计、开发推代码、测试推验证。AI 开发流程里，推动每一步的，是开发者自己写的 Prompt。

Prompt 不是一个环节，它是贯穿整个研发流程的主线。以前，开发者只需要会写代码。现在，开发者还需要会写 Prompt——因为 Prompt 决定了 AI 帮你做什么、做到什么程度、做成什么样子。

【插图4】传统研发流程 vs AI 研发流程对比图

建议内容：

传统流程（上方）：
产品经理（PRD）→ 架构师（技术方案）→ 开发（写代码）→ 测试（写用例）→ 运维（部署）

AI 流程（下方）：
开发者（Prompt）→ AI（竞品分析）→ AI（产品设计）→ AI（技术设计）→ Cursor（代码）→ AI（测试）

标题：Prompt 串联研发流程

---

十一、那个让我真正重视 Prompt 的瞬间

说一个让我印象很深的瞬间。

在做仿美团外卖系统的时候，有一次我需要让 AI 帮我写订单状态流转的逻辑——用户下单之后，订单要经历"待支付→已支付→商家接单→骑手接单→配送中→已送达→已完成"这样一系列状态变化。

第一次，我跟 AI 说：

“帮我写订单状态管理。”

AI 给了一个简单的枚举类和一个 update 方法。能用，但很粗糙，没有状态校验，没有异常处理，也没有考虑并发。代码大概长这样：

public void updateStatus(Long orderId, Integer status) {
    Order order = orderMapper.selectById(orderId);
    order.setStatus(status);
    orderMapper.updateById(order);
}

就这？任何状态都能改成任何状态？已完成的订单还能改回待支付？这不是 bug 制造机吗？

第二次，我重新组织了语言：

"订单状态包括：待支付、已支付、商家已接单、骑手已接单、配送中、已送达、已完成、已取消。

要求：

1. 状态只能按顺序流转，不能跳跃
2. 已取消是终态，任何状态都可以取消（但配送中和之后的状态取消需要走退款）
3. 已完成是终态，不能再变更
4. 状态变更需要记录日志（包含操作人、操作时间、原状态、新状态）
5. 需要考虑并发安全（使用乐观锁）
6. 不合法的状态流转要抛出业务异常

请用状态机模式实现。"

这次，AI 给了一套完整的方案：

• 状态枚举类，定义了所有状态和允许的转移关系
• 状态机实现，用一个 Map 存储合法的状态转移
• 乐观锁实现，用 version 字段防止并发冲突
• 操作日志记录，每次状态变更自动写入日志表
• 业务异常定义，非法状态流转时抛出自定义异常

我当时的第一反应是：哇，AI 变聪明了。 但冷静下来想了想，不对——AI 的模型没变，版本没升级。变的是我的 Prompt。 我从"帮我写订单状态管理"，变成了一段有上下文、有约束、有要求、有边界条件的结构化描述。AI 没有变聪明，是我学会了怎么跟它说话。

那一刻，我第一次真正意识到：Prompt 比 AI 本身更重要。

因为 AI 的能力是固定的，但 Prompt 决定了你能调动多少能力。就像一辆车，发动机是固定的，但你踩油门的方式决定了它跑多快。Prompt，就是油门。你踩一半油门，它就跑一半速度；你把油门踩到底，它就给你飞起来。而大多数人用 AI，油门只踩了 10%。

---

十二、从仿京东到图书商城——Prompt 认知的迁移

做完仿美团外卖系统之后，我又接着做了两个项目：仿京东商城和图书商城。有意思的是，虽然三个项目的业务完全不同，但我的开发方式是一模一样的：

1. 先在 ChatGPT 里梳理需求、设计 Prompt
2. 把 Prompt 丢给 Cursor 生成代码
3. 拿代码回 ChatGPT review
4. 根据反馈修改

而且，因为做仿美团外卖的时候积累了经验，做后面两个项目的效率明显更高了。不是因为我写代码更快了，是因为我写 Prompt 更好了。

做仿京东商城的时候，我一开始就知道要把 Prompt 写清楚。商品模块，我直接告诉 AI：

“仿京东商城的商品模块。商品有 SPU 和 SKU 的概念。SPU 是商品，SKU 是具体规格。一个商品可以有多个规格组合（如颜色+尺码）。需要支持规格选择器、库存管理、价格策略。”

AI 一次性就给了一套合理的方案。如果我只说"帮我写商品模块"，它大概率会给一个没有 SKU 概念的简化版。

做图书商城的时候更快了。图书商城比外卖和京东都简单，但我依然用结构化 Prompt 来驱动开发。连图书的分类体系、搜索过滤、购物流程，都是 Prompt 一步到位的。

三个项目做下来，我最大的感受是：Prompt 的认知是可以迁移的。 你在一个项目上学会了怎么写好 Prompt，到了另一个项目，同样的思路照搬就行。因为底层逻辑是一样的——把需求说清楚、把约束讲明白、把输出格式定好。不管你做外卖系统、电商系统、还是其他任何系统，Prompt 的核心就一件事：让 AI 明确知道你要什么。

---

十三、总结：Prompt 就是你给 AI 的说明书

回顾这段时间用 AI 开发仿美团外卖系统、仿京东商城、图书商城的经历，我最大的感受就一句话：

AI 好不好用，80% 取决于你怎么跟它说话。

很多人觉得 AI 不行，其实是 Prompt 不行。很多人觉得 AI 变聪明了，其实是 Prompt 写清楚了。很多人觉得 Cursor 不如 ChatGPT，或者 ChatGPT 不如 Claude，其实工具都差不多，差距在于你给它的 Prompt。

Prompt 不是什么高深的技术。它就是：

• 你给 AI 的说明书
• 你对 AI 提的需求
• 你跟 AI 说的话

但就是这么简单的东西，很多人忽略了它。我以前也忽略，以为关键是选对模型、选对工具、学对框架。后来才发现，工具都一样，差距在于你怎么用。而怎么用，就体现在 Prompt 上。

这段时间的开发经历让我明白了几件事：

第一，Prompt 不是一次性的，它需要迭代。 第一版 Prompt 往往是粗糙的，你需要根据 AI 的输出不断优化、补充、细化。这个过程就像写代码一样，需要反复打磨。

第二，ChatGPT 和 Cursor 各有所长。 ChatGPT 擅长思考和规划，适合设计 Prompt、review 代码；Cursor 擅长执行，适合根据 Prompt 生成代码。把它们组合起来，效率远超单独使用。

第三，Prompt 串联了整个研发流程。 从竞品分析到产品设计，从技术方案到代码实现，从测试到 review，每一步的起点都是 Prompt。它不是一个工具，是贯穿整个开发过程的主线。

第四，Prompt 的认知可以迁移。 你在一个项目上学会了写好 Prompt 的方法，到了另一个项目照样管用。这是一项通用技能。

如果你也在用 AI 辅助开发，不管是 ChatGPT、Cursor、Copilot 还是其他什么工具，我建议你认真对待你输入的每一句话。因为那句话，就是 Prompt。

它决定了 AI 给你的一切。

【插图5】Prompt 概念总结图

建议内容：

中心：Prompt = 你给 AI 的说明书

四个方向：

• 上：需求描述（告诉 AI 做什么）
• 右：上下文（告诉 AI 背景是什么）
• 下：约束条件（告诉 AI 限制是什么）
• 左：输出要求（告诉 AI 给什么格式）

底部一行字：说得越清楚，AI 越好用

---

十四、下一篇预告

这篇文章，我讲了什么是 Prompt，以及它为什么重要。我用仿美团外卖系统的真实开发经历，让你看到了 Prompt 的力量：

• 同一个 AI，不同的 Prompt，输出天差地别
• Prompt 不是一次性的，需要迭代优化
• ChatGPT 设计 Prompt，Cursor 执行代码，两者配合是最佳实践
• Prompt 串联了从竞品分析到测试的整个研发流程

但我没有讲怎么写好一个 Prompt。因为这是一个大话题，值得单独用一篇文章来聊。

下一篇，我会分享：

• 一个好的 Prompt 到底长什么样？
• 有没有固定的结构和套路？
• 怎么从"随便说一句"进化到"结构化 Prompt"？
• 我在实际开发中总结的 Prompt 写法

如果你对 AI 辅助开发感兴趣，或者也在用 Cursor 写代码，下一篇应该会对你很有帮助。

我们下篇见。

---

Prompt 系列第一篇完。

下一篇：《一个好的 Prompt 怎么写？》