做开发十几年我见过太多团队从零搭一个订单管理系统要花多久——需求梳理两周原型一周前后端开发一个月联调再来两周中间还夹着数不清的需求变更。这次我给自己出了个不太一样的题全部交给 AI从零开始看我有没有能力把需求说清楚。订单管理系统是典型的看起来简单、做起来全是细节的项目。用户账号、商品、客户、订单、支付状态、库存扣减、统计报表每一个环节单独拎出来都不难合在一起就是一场持久战。而恰恰是这种不难但繁琐的特性让它成为测试 AI 编程能力的绝佳标尺。这篇文章是我用 AI 从零开发订单管理系统系列的第一篇核心只讲一件事写一份能让 AI 从零开工的提示词Prompt。别小看这一步后续所有代码质量、迭代效率都取决于你在这份提示词里埋了什么。如果你是编程新手或者正在犹豫要不要用 AI 做自己的第一个全栈项目这篇应该能帮你少走不少弯路。1. 项目背景为什么偏偏是订单管理系统1.1 选这个项目的三个理由先说为什么是订单管理系统而不是AI 帮我也做个网站这种模糊需求。选这个项目我考虑了三层。第一层它足够完整。一个能自圆其说的订单系统至少涉及商品、客户、订单三个核心实体还要处理状态流转、金额计算、列表筛选这些真实业务逻辑。麻雀虽小五脏俱全用它来检验 AI 的全栈能力再合适不过。如果只是做个静态页面那你根本看不出提示词写得好不好但一个订单系统会把所有短板都放大出来。第二层它足够典型。订单系统是几乎所有企业级应用的缩水版——有增删改查有业务规则有统计汇总有界面交互。在这个项目上积累的提示词工程经验可以直接迁移到库存、财务、CRM 等其他系统上。说白了只要你把订单系统啃下来其他管理类系统对你来说就是换皮。第三层它适合迭代。订单系统可以无限简化也可以无限复杂。我今天只做 MVP最小可用版本但后面随时可以加权限、加报表、加消息通知。这种能小能大的项目恰好适合写成一个系列来记录每一篇都有明确的交付物。基于这三点我敲定了这个题目。整个系列的最终目标不是做出来一个完美系统而是完整记录一个非 AI 专业背景的人如何用提示词驱动 AI 完成一个真实可用的业务系统。1.2 我给项目划的 MVP 边界需求如果不划边界AI 根本不知道该先做什么。我给自己列了一个特别明确的 MVP 清单商品模块名称、SKU、价格、库存数量、上下架状态。客户模块名称、联系方式、备注。订单模块选择客户和商品自动计算订单金额支持状态流转待付款、已付款、已发货、已完成、已取消。订单列表按状态筛选、按客户搜索、按日期范围过滤。首页统计订单总数、今日销售额、待发货数量三项指标。在这个清单之外的东西比如用户登录、权限控制、供应商管理、退货流程第一版一概不做。这个决定特别关键——AI 一旦生成太多无关功能代码复杂度会急剧上升调试成本翻倍。我把这份清单看作是给 AI 的施工图。写提示词的时候我等于把这张图纸的语言翻译成 AI 能听懂的命令。很多人在这一步偷懒觉得AI 自己会判断结果就是 AI 替你做了太多你根本不需要的东西。1.3 整体路线图提示词开工后面分模块迭代整个项目的推进节奏是这样的先写一份总提示词要求 AI 输出项目结构、数据模型和接口清单通过评审后再动手。按商品、客户、订单的顺序分模块实现每完成一个模块就做一次验证。最后做汇总联调补首页统计跑通完整流程。后续系列文章会按这个节奏展开。这一篇先把开工提示词这部分讲透因为它决定了后面所有对话的基调。提示词指令的作用对象不只是某个文件而是整个项目的框架认知——AI 在接下来的每一轮对话里都会基于你最初给它的这份约束来组织代码。所以这份提示词宁可多花一小时打磨也不要图快直接开跑。2. 开工前最重要的一件事写提示词2.1 一份能开工的提示词长什么样很多人用 AI 写代码上来就一句帮我做个订单系统。这相当于你跟一个外包团队说帮我做个系统然后要求第二天交活——对方大概率会反过来问你一百个问题或者干脆给你一个没法用的骨架。我在这次项目里总结出的经验是一份合格的开发提示词至少要包含五个部分——角色定义、项目目标、功能范围、技术约束、开发方式。这五部分对应的是你是谁、要做什么、做到什么程度、用什么做、怎么干活。换句话说写提示词不是写需求说明书而是写给 AI 的工作简报。它不需要像正式文档那样冗长但必须把关键决策写清楚减少 AI 的猜测空间。你对项目的每一分模糊最终都会变成 AI 生成代码里的 bug 或返工成本。2.2 我发给 AI 的第一版开工提示词可直接抄下面这份提示词是我实际使用的第一版原样贴出来。你可以根据自己的技术栈和需求做修改# 角色 你是一名拥有10年经验的全栈工程师擅长使用 Next.js、TypeScript、Prisma 和 SQLite 开发中小型业务系统。 # 项目目标 从零开发一个订单管理系统OMS用于小型电商团队管理客户订单。 # 功能范围MVP不额外扩展 1. 商品管理商品增删改查字段包括名称、SKU、价格、库存数量、状态上架/下架。 2. 客户管理客户增删改查字段包括名称、联系方式、备注。 3. 订单管理创建订单时选择客户和商品自动计算订单金额支持修改订单状态待付款、已付款、已发货、已完成、已取消。 4. 订单列表支持按状态筛选、按客户搜索、按日期范围筛选。 5. 首页统计展示订单总数、今日销售额、待发货数量三项指标。 # 非功能要求 1. 界面使用 Ant Design 组件库中文文案。 2. 数据模型用 Prisma 定义数据库使用 SQLite方便本地运行。 3. 接口遵循 RESTful 风格统一返回格式 { code, message, data }。 4. 项目结构清晰包含前端页面目录、后端接口目录、数据模型目录。 # 开发方式 1. 在动手写代码前先输出项目目录结构、Prisma 数据模型和接口列表等待确认后再开始。 2. 按模块逐步实现先商品模块再客户模块最后订单模块。 3. 每个模块完成后用一两句话说明如何验证功能。 # 验收标准 1. 运行开发命令后能直接访问系统。 2. 商品、客户、订单三个模块可以完成完整的增删改查。 3. 创建订单后列表页和统计数字能实时更新。这份提示词不到 500 字但信息密度极高。下面我逐段解释它每一部分的设计意图这部分是整篇的关键。2.3 提示词各部分的设计意图拆解先说角色定义。这一步很多人会忽略但 AI 大模型对角色设定非常敏感。当你告诉它你是全栈工程师时它输出的代码风格、架构意识、对边界情况的考虑明显比把它当通用助手时强一截。我的经验是角色描述越具体越好——10 年经验中小型业务系统这些限定词会引导模型往工程化方向走而不是写玩具代码。这就好比你在公司里跟资深架构师说话和跟实习生说话表达方式天然不同AI 也吃这一套。再说功能范围。我特意加了MVP不额外扩展几个字这是我用了几次长对话之后才学到的。AI 特别喜欢自由发挥——你让它做个订单系统它可能顺手给你加个权限管理或者搞一个数据大屏。听起来很酷但对第一版来说全是负担。把范围锁死等于给施工队一张红线图超出范围的部分不做。如果你发现自己遇到的 AI 经常加戏第一件事就是回去检查功能范围写没写清楚。非功能要求这一层其实是给系统定技术基调。用什么框架、什么数据库、什么组件库这些如果不由你来定AI 每次对话都可能换一种方案。我在提示词里明确锁定了 Next.js、TypeScript、Prisma、SQLite、Ant Design就是为了让后续所有对话都在这条技术路线上展开。这里有个小建议如果你是新手技术栈的选择别太纠结直接跟 AI 说你熟悉的、网上资料多的那一套。没有绝对最好只有对你更顺手的组合。开发方式是我这次特别想强调的部分。我做了一个很重要的设置先让 AI 输出整体方案确认之后再动手。这一步可以理解为先画图纸再施工。如果让 AI 上来就写代码它很可能边想边写写到一半推翻重来对话历史里全是废弃方案既浪费资源又污染上下文。先出方案还有个好处你可以在这时候纠正方向比如调整数据模型、改接口风格而不是等代码写完再去返工。验收标准是很多人写提示词时容易漏掉的一环。没有验收标准的提示词就像没有比赛规则的球赛AI 写出来的东西你可能根本不满意。我明确写了三条能访问、能增删改查、统计能实时更新。这保证了第一版做出来至少是能用的而不是能看的。后续每轮对话我都拿这组标准去卡 AI凡是达不到的就让它继续改不再需要临时想怎么验收。2.4 提示词常见的翻车现场我在这轮开发前后试过好几版提示词踩过的坑很有代表性整理出来给你避雷。第一类是需求太笼统。只写帮我做一个订单系统AI 会直接懵掉或者生成一个什么功能都有一点的四不像。解决办法就是把功能范围精确到字段级别——连商品的 SKU、价格、库存这些字段都写在提示词里AI 就没有自由发挥的空间了。你给它越多的确定性它还你越少的惊吓。第二类是目标太宏大。一次对话里要求 AI 同时实现登录、权限、订单、库存、报表结果就是每块都做得很浅而且代码互相耦合。我后来学乖了MVP 永远只锁核心链路多余的功能排到下一个版本。把目标拆细还有一个好处每一轮的代码量小AI 出错的概率也小你检查起来不费劲。第三类是没有上下文约束。AI 的上下文窗口有限对话超过一定长度后它会忘记最开始的要求。这就是为什么我要把功能范围、技术栈、验收标准全部写进提示词——哪怕对话到第 100 轮你也可以随时把这份提示词再发一遍把它拉回正轨。说白了这份提示词就是整个项目的宪法其他的对话都是围绕它展开的司法解释。第四类是没有迭代节奏。让 AI 一口气产出全部代码得到的往往是一堆互相引用了但还没定义的文件。正确的做法是让它分模块交付每个模块验证通过再继续就像瀑布开发一样每道工序验收完再往下走。我在实践里会明确告诉 AI完成商品模块后先停下来等我确认这样整个开发过程完全在我的掌控里。3. 从提示词到第一版可运行代码3.1 工具选择Cursor、Codex 还是网页版大模型写提示词之前先得选一个施工场地。市面上现在主流的 AI 编程工具有三类。第一类是集成开发环境型代表是 Cursor。它把 AI 深度嵌进了代码编辑器你能选中代码片段让 AI 修改也能开启 Agent 模式让它自动执行命令、安装依赖、跑测试。写完整项目我首推这一类因为它能看到你的项目文件实时变化代码自动同步不用来回复制粘贴。第二类是命令型智能体代表是 OpenAI Codex 这类工具。你给它一个任务它自己建文件、跑命令、迭代修复。优点是自动化程度高缺点是出了问题你不太容易插手调试适合有一定基础的开发者。第三类是网页版大模型比如 ChatGPT、Claude 的网页端。优点是门槛低缺点是代码需要来回复制粘贴对话一长上下文容易乱。新手练手可以先用这个但做完整项目建议尽快切换。我在这个项目里用的是 Cursor。原因很简单它能直接操作本地文件AI 生成的代码立刻出现在项目目录里我可以随时打开文件查看、修改、调试。整个流程基本是提示词驱动 人工审查的配合AI 负责生产我负责验收。3.2 第一次对话让 AI 先交方案按照提示词里的开发方式我和 AI 的第一次对话目的不是要代码而是要方案。我把它想象成一次需求评审会AI 是乙方我是甲方。第一轮我发完整提示词要求它输出项目目录结构、Prisma 数据模型和接口列表。它很快给出了目录src/ app/ # 前端页面 page.tsx # 首页统计 products/ # 商品管理 customers/ # 客户管理 orders/ # 订单管理 server/ # 后端接口 routes/ # 路由 lib/ # 公共逻辑 prisma/ schema.prisma # 数据模型数据模型部分它设计的三个核心表是model Product { id String id default(cuid()) name String sku String unique price Float stock Int status String default(on) createdAt DateTime default(now()) } model Customer { id String id default(cuid()) name String phone String? remark String? createdAt DateTime default(now()) } model Order { id String id default(cuid()) customerId String customer Customer relation(fields: [customerId], references: [id]) total Float status String default(pending) createdAt DateTime default(now()) items OrderItem[] } model OrderItem { id String id default(cuid()) orderId String productId String product Product relation(fields: [productId], references: [id]) quantity Int price Float }这里有个细节我特意确认过订单明细为什么要单独建一张表而不是直接把商品信息塞在订单里。原因是同一个订单可能包含多个商品而每个商品的单价、数量都必须独立记录否则后续没法做数据统计。让我比较满意的是AI 在方案里主动把订单明细拆了出来说明角色定义里的全栈工程师设定起到了作用。接口列表它规划了 RESTful 风格的几组接口商品的 POST/GET/PUT/DELETE客户的 POST/GET/PUT/DELETE订单的创建、查询、状态更新外加首页统计接口。看到这个方案后我确认了一遍数据模型和接口清单然后才让它进入按模块实现阶段。这一步我花了大概二十分钟但省掉了后面可能两小时的返工。3.3 分模块落地商品、客户、订单的推进顺序方案确认之后我按提示词里的要求让 AI 先做商品模块。这里有个执行层面的细节我会在每条消息里把当前任务说得很具体比如请实现商品模块的所有接口和页面完成后告诉我如何在浏览器里验证。AI 会生成代码文件然后我需要做一次人工调试验证。商品模块做完后客户模块基本是复制同样的模式——数据模型加两张表接口加一组路由页面加一个列表和表单。AI 生成的速度很快但真正花时间的环节反而是我手动验证创建商品、编辑商品、删除商品每个操作都要在页面上点一遍。这个环节不能跳过AI 生成的代码里经常有我没注意到的小问题。订单模块是整个系统最复杂的部分AI 在这里也最容易出错。创建订单时要同时写订单主表和订单明细表还要计算总金额。我先让 AI 把创建订单这一个接口单独实现再让它实现订单列表和状态更新。这样把大任务拆小出错概率明显下降定位问题也容易。你如果自己实操一定不要催 AI快点把订单模块全部做完越急越容易拿到一堆纠缠不清的文件。3.4 首次跑通完整流程的那天把三个模块都做完之后我清空了一次数据库从首页开始走了一遍完整流程添加商品、添加客户、创建订单、修改状态、查看统计。第一次真正跑通的时候我其实还挺意外的——不是因为 AI 写得多完美而是因为我只写了一份提示词加十几条跟进指令它就完成了传统开发需要好几天的量。不过别高兴太早跑通和跑对是两码事。这句话在后面几天的调试里被反复验证。第一次跑通后我很快发现订单金额偶尔算不对、刷新页面后统计数字不一致这些问题。这些细节问题让我意识到提示词能帮你把项目搭起来但搭起来和能用之间还隔着一层认真的测试和规则补充。好消息是这些问题都很具体把规则一条条补进提示词再让 AI 改效率依然很高。4. 踩坑实录与排查方法4.1 提示词层面的五类翻车现象原因解决办法AI 自作主张加功能功能范围没锁死在提示词里写明“MVP不额外扩展”代码风格前后不一致技术约束不完整明确框架、组件库、返回格式对话到后期偏题上下文被污染把原始提示词重新发给 AI 对齐生成的方案不可用没先出方案就写码要求先输出结构、模型、接口清单测试标准不清楚没有验收标准写清楚“能访问、能增删改查、能实时更新”这五类问题我几乎每类都踩过。印象最深的是AI 自作主张加功能——第一版提示词没写限制AI 自动给我加了一个登录页面。登录本身是好事但 MVP 阶段加登录就意味着要处理用户表、密码校验、会话保持整个系统的复杂度直接上升一个量级。后来我果断砍掉让 AI 删掉了相关代码。这也验证了一件事AI 编程的原则不是多给而是精确地给。4.2 代码层面的典型问题代码层面的坑主要集中在三处。第一处是数据关联。AI 生成的 Prisma 模型如果外键关系没写对运行时会直接报错。我遇到的是订单删除时外键约束冲突——客户删不掉因为订单还引用着它。解决办法是在模型里加上onDelete: SetNull或者onDelete: Cascade的关联策略具体用哪个取决于业务需求。如果你不想让订单跟着客户一起被删就选 SetNull如果订单本身就是依附于客户存在的那就选 Cascade。第二处是金额计算。订单金额是浮点数运算AI 生成的代码里直接用price * quantity看起来没问题但涉及浮点精度时可能出岔子。我在第二版里把金额全部改为以分为单位存整数彻底绕开了浮点数精度问题。这个建议对任何做业务系统的人都适用——钱相关的字段一律用整数保存最小单位展示时再除以 100。第三处是状态更新。AI 一开始允许把订单状态从已发货改回待付款这在业务上不合理。我就在提示词里补充了一条状态流转规则待付款到已付款已付款到已发货已发货到已完成或者已取消只能按顺序往前走。把这个规则写得越明确AI 后续实现的校验逻辑就越准确。业务规则的表达不能靠模棱两可的注意一下必须写成 AI 能直接翻译成代码的逻辑。4.3 让 AI 干活更靠谱的四个习惯经过这轮项目我总结出四个能明显提升 AI 编程质量的习惯。第一每次对话只交代一个明确任务。与其说你顺便把统计页也做了不如明确说完成订单列表的筛选逻辑包括状态、客户、日期三个条件的组合查询。任务越小AI 越容易做对。第二用给方案再动手来兜底。凡是涉及新模块、新数据表、新页面都先让 AI 拿出方案你确认后再让它写代码。这个习惯能拦下大量方向性错误因为方案阶段改几行字比代码写完再推倒重来要省事得多。第三关键业务规则要写进提示词。比如金额精度、状态流转、删除策略这些规则如果只放在某一条对话里AI 很可能下次就忘了。正确的做法是写进提示词的功能范围或非功能要求真正做到规则不缺席。我后来养成了一个习惯每次让 AI 改代码时如果涉及新规则我会先更新原始提示词再开新一轮对话保证所有约束始终在上下文里。第四版本控制不能少。AI 每次改动可能同时动了 10 个文件如果直接改坏你根本不知道哪里出了问题。我会在让 AI 动手前先手动提交一次代码万一改乱了可以随时回滚。就这一个简单的习惯至少帮我省出了两三个小时的排查时间。4.4 对话上下文失控时的补救最后一个提醒几乎每个长项目都会遇到对话到中间AI 开始失忆。你可能发现它新生成的代码跟最开始定的技术栈不一致或者它忘了某个模块已经实现过重复生成了一遍。遇到这种情况我的办法是分两步。第一步把原始的开工提示词原封不动再发一次让 AI 重新对齐目标和约束。第二步明确告诉它以上是项目总要求现在请你基于已存在的 src 目录完成 XXX 功能不要重新创建已经存在的文件。把不要重复造轮子这句话直接说给 AI 听很多时候比你自己手动清理代码要快得多。如果你的对话已经乱到无法挽救干脆新建一个会话把原始提示词加上当前项目的关键文件结构一起贴进去重开一局通常比抢救一局更省事。5. 这一篇的最后几句这篇先写到这里。说实话从零到第一版可运行的订单管理系统我只用了一天其中真正花在提示词上的时间可能只有一两个小时剩下的时间全耗在验证、修 bug 和补规则上。写这篇文章时我又回头复盘了一遍整个过程最大的感受是AI 编程的能力边界比大多数人想象的要宽但它的下限完全取决于你输入的提示词质量。提示词它不是玄学就是把你想清楚的事用 AI 能理解的方式说清楚。接下来这个系列我会继续写数据模型设计的细节、订单状态机的实现、统计报表怎么让 AI 帮你做、以及最终怎么部署让系统可以被多人访问。如果你在跟着做建议先把这一篇的开工提示词改成你自己的业务场景——换一套商品字段、换一个技术框架都不重要重要的是先让 AI 跑通一次从提示词到可运行系统的完整流程你有了这个底子后面再慢慢打磨就是水到渠成的事。 用AI从零开发订单管理系统：一份好提示词是成功的关键
做开发十几年我见过太多团队从零搭一个订单管理系统要花多久——需求梳理两周原型一周前后端开发一个月联调再来两周中间还夹着数不清的需求变更。这次我给自己出了个不太一样的题全部交给 AI从零开始看我有没有能力把需求说清楚。订单管理系统是典型的看起来简单、做起来全是细节的项目。用户账号、商品、客户、订单、支付状态、库存扣减、统计报表每一个环节单独拎出来都不难合在一起就是一场持久战。而恰恰是这种不难但繁琐的特性让它成为测试 AI 编程能力的绝佳标尺。这篇文章是我用 AI 从零开发订单管理系统系列的第一篇核心只讲一件事写一份能让 AI 从零开工的提示词Prompt。别小看这一步后续所有代码质量、迭代效率都取决于你在这份提示词里埋了什么。如果你是编程新手或者正在犹豫要不要用 AI 做自己的第一个全栈项目这篇应该能帮你少走不少弯路。1. 项目背景为什么偏偏是订单管理系统1.1 选这个项目的三个理由先说为什么是订单管理系统而不是AI 帮我也做个网站这种模糊需求。选这个项目我考虑了三层。第一层它足够完整。一个能自圆其说的订单系统至少涉及商品、客户、订单三个核心实体还要处理状态流转、金额计算、列表筛选这些真实业务逻辑。麻雀虽小五脏俱全用它来检验 AI 的全栈能力再合适不过。如果只是做个静态页面那你根本看不出提示词写得好不好但一个订单系统会把所有短板都放大出来。第二层它足够典型。订单系统是几乎所有企业级应用的缩水版——有增删改查有业务规则有统计汇总有界面交互。在这个项目上积累的提示词工程经验可以直接迁移到库存、财务、CRM 等其他系统上。说白了只要你把订单系统啃下来其他管理类系统对你来说就是换皮。第三层它适合迭代。订单系统可以无限简化也可以无限复杂。我今天只做 MVP最小可用版本但后面随时可以加权限、加报表、加消息通知。这种能小能大的项目恰好适合写成一个系列来记录每一篇都有明确的交付物。基于这三点我敲定了这个题目。整个系列的最终目标不是做出来一个完美系统而是完整记录一个非 AI 专业背景的人如何用提示词驱动 AI 完成一个真实可用的业务系统。1.2 我给项目划的 MVP 边界需求如果不划边界AI 根本不知道该先做什么。我给自己列了一个特别明确的 MVP 清单商品模块名称、SKU、价格、库存数量、上下架状态。客户模块名称、联系方式、备注。订单模块选择客户和商品自动计算订单金额支持状态流转待付款、已付款、已发货、已完成、已取消。订单列表按状态筛选、按客户搜索、按日期范围过滤。首页统计订单总数、今日销售额、待发货数量三项指标。在这个清单之外的东西比如用户登录、权限控制、供应商管理、退货流程第一版一概不做。这个决定特别关键——AI 一旦生成太多无关功能代码复杂度会急剧上升调试成本翻倍。我把这份清单看作是给 AI 的施工图。写提示词的时候我等于把这张图纸的语言翻译成 AI 能听懂的命令。很多人在这一步偷懒觉得AI 自己会判断结果就是 AI 替你做了太多你根本不需要的东西。1.3 整体路线图提示词开工后面分模块迭代整个项目的推进节奏是这样的先写一份总提示词要求 AI 输出项目结构、数据模型和接口清单通过评审后再动手。按商品、客户、订单的顺序分模块实现每完成一个模块就做一次验证。最后做汇总联调补首页统计跑通完整流程。后续系列文章会按这个节奏展开。这一篇先把开工提示词这部分讲透因为它决定了后面所有对话的基调。提示词指令的作用对象不只是某个文件而是整个项目的框架认知——AI 在接下来的每一轮对话里都会基于你最初给它的这份约束来组织代码。所以这份提示词宁可多花一小时打磨也不要图快直接开跑。2. 开工前最重要的一件事写提示词2.1 一份能开工的提示词长什么样很多人用 AI 写代码上来就一句帮我做个订单系统。这相当于你跟一个外包团队说帮我做个系统然后要求第二天交活——对方大概率会反过来问你一百个问题或者干脆给你一个没法用的骨架。我在这次项目里总结出的经验是一份合格的开发提示词至少要包含五个部分——角色定义、项目目标、功能范围、技术约束、开发方式。这五部分对应的是你是谁、要做什么、做到什么程度、用什么做、怎么干活。换句话说写提示词不是写需求说明书而是写给 AI 的工作简报。它不需要像正式文档那样冗长但必须把关键决策写清楚减少 AI 的猜测空间。你对项目的每一分模糊最终都会变成 AI 生成代码里的 bug 或返工成本。2.2 我发给 AI 的第一版开工提示词可直接抄下面这份提示词是我实际使用的第一版原样贴出来。你可以根据自己的技术栈和需求做修改# 角色 你是一名拥有10年经验的全栈工程师擅长使用 Next.js、TypeScript、Prisma 和 SQLite 开发中小型业务系统。 # 项目目标 从零开发一个订单管理系统OMS用于小型电商团队管理客户订单。 # 功能范围MVP不额外扩展 1. 商品管理商品增删改查字段包括名称、SKU、价格、库存数量、状态上架/下架。 2. 客户管理客户增删改查字段包括名称、联系方式、备注。 3. 订单管理创建订单时选择客户和商品自动计算订单金额支持修改订单状态待付款、已付款、已发货、已完成、已取消。 4. 订单列表支持按状态筛选、按客户搜索、按日期范围筛选。 5. 首页统计展示订单总数、今日销售额、待发货数量三项指标。 # 非功能要求 1. 界面使用 Ant Design 组件库中文文案。 2. 数据模型用 Prisma 定义数据库使用 SQLite方便本地运行。 3. 接口遵循 RESTful 风格统一返回格式 { code, message, data }。 4. 项目结构清晰包含前端页面目录、后端接口目录、数据模型目录。 # 开发方式 1. 在动手写代码前先输出项目目录结构、Prisma 数据模型和接口列表等待确认后再开始。 2. 按模块逐步实现先商品模块再客户模块最后订单模块。 3. 每个模块完成后用一两句话说明如何验证功能。 # 验收标准 1. 运行开发命令后能直接访问系统。 2. 商品、客户、订单三个模块可以完成完整的增删改查。 3. 创建订单后列表页和统计数字能实时更新。这份提示词不到 500 字但信息密度极高。下面我逐段解释它每一部分的设计意图这部分是整篇的关键。2.3 提示词各部分的设计意图拆解先说角色定义。这一步很多人会忽略但 AI 大模型对角色设定非常敏感。当你告诉它你是全栈工程师时它输出的代码风格、架构意识、对边界情况的考虑明显比把它当通用助手时强一截。我的经验是角色描述越具体越好——10 年经验中小型业务系统这些限定词会引导模型往工程化方向走而不是写玩具代码。这就好比你在公司里跟资深架构师说话和跟实习生说话表达方式天然不同AI 也吃这一套。再说功能范围。我特意加了MVP不额外扩展几个字这是我用了几次长对话之后才学到的。AI 特别喜欢自由发挥——你让它做个订单系统它可能顺手给你加个权限管理或者搞一个数据大屏。听起来很酷但对第一版来说全是负担。把范围锁死等于给施工队一张红线图超出范围的部分不做。如果你发现自己遇到的 AI 经常加戏第一件事就是回去检查功能范围写没写清楚。非功能要求这一层其实是给系统定技术基调。用什么框架、什么数据库、什么组件库这些如果不由你来定AI 每次对话都可能换一种方案。我在提示词里明确锁定了 Next.js、TypeScript、Prisma、SQLite、Ant Design就是为了让后续所有对话都在这条技术路线上展开。这里有个小建议如果你是新手技术栈的选择别太纠结直接跟 AI 说你熟悉的、网上资料多的那一套。没有绝对最好只有对你更顺手的组合。开发方式是我这次特别想强调的部分。我做了一个很重要的设置先让 AI 输出整体方案确认之后再动手。这一步可以理解为先画图纸再施工。如果让 AI 上来就写代码它很可能边想边写写到一半推翻重来对话历史里全是废弃方案既浪费资源又污染上下文。先出方案还有个好处你可以在这时候纠正方向比如调整数据模型、改接口风格而不是等代码写完再去返工。验收标准是很多人写提示词时容易漏掉的一环。没有验收标准的提示词就像没有比赛规则的球赛AI 写出来的东西你可能根本不满意。我明确写了三条能访问、能增删改查、统计能实时更新。这保证了第一版做出来至少是能用的而不是能看的。后续每轮对话我都拿这组标准去卡 AI凡是达不到的就让它继续改不再需要临时想怎么验收。2.4 提示词常见的翻车现场我在这轮开发前后试过好几版提示词踩过的坑很有代表性整理出来给你避雷。第一类是需求太笼统。只写帮我做一个订单系统AI 会直接懵掉或者生成一个什么功能都有一点的四不像。解决办法就是把功能范围精确到字段级别——连商品的 SKU、价格、库存这些字段都写在提示词里AI 就没有自由发挥的空间了。你给它越多的确定性它还你越少的惊吓。第二类是目标太宏大。一次对话里要求 AI 同时实现登录、权限、订单、库存、报表结果就是每块都做得很浅而且代码互相耦合。我后来学乖了MVP 永远只锁核心链路多余的功能排到下一个版本。把目标拆细还有一个好处每一轮的代码量小AI 出错的概率也小你检查起来不费劲。第三类是没有上下文约束。AI 的上下文窗口有限对话超过一定长度后它会忘记最开始的要求。这就是为什么我要把功能范围、技术栈、验收标准全部写进提示词——哪怕对话到第 100 轮你也可以随时把这份提示词再发一遍把它拉回正轨。说白了这份提示词就是整个项目的宪法其他的对话都是围绕它展开的司法解释。第四类是没有迭代节奏。让 AI 一口气产出全部代码得到的往往是一堆互相引用了但还没定义的文件。正确的做法是让它分模块交付每个模块验证通过再继续就像瀑布开发一样每道工序验收完再往下走。我在实践里会明确告诉 AI完成商品模块后先停下来等我确认这样整个开发过程完全在我的掌控里。3. 从提示词到第一版可运行代码3.1 工具选择Cursor、Codex 还是网页版大模型写提示词之前先得选一个施工场地。市面上现在主流的 AI 编程工具有三类。第一类是集成开发环境型代表是 Cursor。它把 AI 深度嵌进了代码编辑器你能选中代码片段让 AI 修改也能开启 Agent 模式让它自动执行命令、安装依赖、跑测试。写完整项目我首推这一类因为它能看到你的项目文件实时变化代码自动同步不用来回复制粘贴。第二类是命令型智能体代表是 OpenAI Codex 这类工具。你给它一个任务它自己建文件、跑命令、迭代修复。优点是自动化程度高缺点是出了问题你不太容易插手调试适合有一定基础的开发者。第三类是网页版大模型比如 ChatGPT、Claude 的网页端。优点是门槛低缺点是代码需要来回复制粘贴对话一长上下文容易乱。新手练手可以先用这个但做完整项目建议尽快切换。我在这个项目里用的是 Cursor。原因很简单它能直接操作本地文件AI 生成的代码立刻出现在项目目录里我可以随时打开文件查看、修改、调试。整个流程基本是提示词驱动 人工审查的配合AI 负责生产我负责验收。3.2 第一次对话让 AI 先交方案按照提示词里的开发方式我和 AI 的第一次对话目的不是要代码而是要方案。我把它想象成一次需求评审会AI 是乙方我是甲方。第一轮我发完整提示词要求它输出项目目录结构、Prisma 数据模型和接口列表。它很快给出了目录src/ app/ # 前端页面 page.tsx # 首页统计 products/ # 商品管理 customers/ # 客户管理 orders/ # 订单管理 server/ # 后端接口 routes/ # 路由 lib/ # 公共逻辑 prisma/ schema.prisma # 数据模型数据模型部分它设计的三个核心表是model Product { id String id default(cuid()) name String sku String unique price Float stock Int status String default(on) createdAt DateTime default(now()) } model Customer { id String id default(cuid()) name String phone String? remark String? createdAt DateTime default(now()) } model Order { id String id default(cuid()) customerId String customer Customer relation(fields: [customerId], references: [id]) total Float status String default(pending) createdAt DateTime default(now()) items OrderItem[] } model OrderItem { id String id default(cuid()) orderId String productId String product Product relation(fields: [productId], references: [id]) quantity Int price Float }这里有个细节我特意确认过订单明细为什么要单独建一张表而不是直接把商品信息塞在订单里。原因是同一个订单可能包含多个商品而每个商品的单价、数量都必须独立记录否则后续没法做数据统计。让我比较满意的是AI 在方案里主动把订单明细拆了出来说明角色定义里的全栈工程师设定起到了作用。接口列表它规划了 RESTful 风格的几组接口商品的 POST/GET/PUT/DELETE客户的 POST/GET/PUT/DELETE订单的创建、查询、状态更新外加首页统计接口。看到这个方案后我确认了一遍数据模型和接口清单然后才让它进入按模块实现阶段。这一步我花了大概二十分钟但省掉了后面可能两小时的返工。3.3 分模块落地商品、客户、订单的推进顺序方案确认之后我按提示词里的要求让 AI 先做商品模块。这里有个执行层面的细节我会在每条消息里把当前任务说得很具体比如请实现商品模块的所有接口和页面完成后告诉我如何在浏览器里验证。AI 会生成代码文件然后我需要做一次人工调试验证。商品模块做完后客户模块基本是复制同样的模式——数据模型加两张表接口加一组路由页面加一个列表和表单。AI 生成的速度很快但真正花时间的环节反而是我手动验证创建商品、编辑商品、删除商品每个操作都要在页面上点一遍。这个环节不能跳过AI 生成的代码里经常有我没注意到的小问题。订单模块是整个系统最复杂的部分AI 在这里也最容易出错。创建订单时要同时写订单主表和订单明细表还要计算总金额。我先让 AI 把创建订单这一个接口单独实现再让它实现订单列表和状态更新。这样把大任务拆小出错概率明显下降定位问题也容易。你如果自己实操一定不要催 AI快点把订单模块全部做完越急越容易拿到一堆纠缠不清的文件。3.4 首次跑通完整流程的那天把三个模块都做完之后我清空了一次数据库从首页开始走了一遍完整流程添加商品、添加客户、创建订单、修改状态、查看统计。第一次真正跑通的时候我其实还挺意外的——不是因为 AI 写得多完美而是因为我只写了一份提示词加十几条跟进指令它就完成了传统开发需要好几天的量。不过别高兴太早跑通和跑对是两码事。这句话在后面几天的调试里被反复验证。第一次跑通后我很快发现订单金额偶尔算不对、刷新页面后统计数字不一致这些问题。这些细节问题让我意识到提示词能帮你把项目搭起来但搭起来和能用之间还隔着一层认真的测试和规则补充。好消息是这些问题都很具体把规则一条条补进提示词再让 AI 改效率依然很高。4. 踩坑实录与排查方法4.1 提示词层面的五类翻车现象原因解决办法AI 自作主张加功能功能范围没锁死在提示词里写明“MVP不额外扩展”代码风格前后不一致技术约束不完整明确框架、组件库、返回格式对话到后期偏题上下文被污染把原始提示词重新发给 AI 对齐生成的方案不可用没先出方案就写码要求先输出结构、模型、接口清单测试标准不清楚没有验收标准写清楚“能访问、能增删改查、能实时更新”这五类问题我几乎每类都踩过。印象最深的是AI 自作主张加功能——第一版提示词没写限制AI 自动给我加了一个登录页面。登录本身是好事但 MVP 阶段加登录就意味着要处理用户表、密码校验、会话保持整个系统的复杂度直接上升一个量级。后来我果断砍掉让 AI 删掉了相关代码。这也验证了一件事AI 编程的原则不是多给而是精确地给。4.2 代码层面的典型问题代码层面的坑主要集中在三处。第一处是数据关联。AI 生成的 Prisma 模型如果外键关系没写对运行时会直接报错。我遇到的是订单删除时外键约束冲突——客户删不掉因为订单还引用着它。解决办法是在模型里加上onDelete: SetNull或者onDelete: Cascade的关联策略具体用哪个取决于业务需求。如果你不想让订单跟着客户一起被删就选 SetNull如果订单本身就是依附于客户存在的那就选 Cascade。第二处是金额计算。订单金额是浮点数运算AI 生成的代码里直接用price * quantity看起来没问题但涉及浮点精度时可能出岔子。我在第二版里把金额全部改为以分为单位存整数彻底绕开了浮点数精度问题。这个建议对任何做业务系统的人都适用——钱相关的字段一律用整数保存最小单位展示时再除以 100。第三处是状态更新。AI 一开始允许把订单状态从已发货改回待付款这在业务上不合理。我就在提示词里补充了一条状态流转规则待付款到已付款已付款到已发货已发货到已完成或者已取消只能按顺序往前走。把这个规则写得越明确AI 后续实现的校验逻辑就越准确。业务规则的表达不能靠模棱两可的注意一下必须写成 AI 能直接翻译成代码的逻辑。4.3 让 AI 干活更靠谱的四个习惯经过这轮项目我总结出四个能明显提升 AI 编程质量的习惯。第一每次对话只交代一个明确任务。与其说你顺便把统计页也做了不如明确说完成订单列表的筛选逻辑包括状态、客户、日期三个条件的组合查询。任务越小AI 越容易做对。第二用给方案再动手来兜底。凡是涉及新模块、新数据表、新页面都先让 AI 拿出方案你确认后再让它写代码。这个习惯能拦下大量方向性错误因为方案阶段改几行字比代码写完再推倒重来要省事得多。第三关键业务规则要写进提示词。比如金额精度、状态流转、删除策略这些规则如果只放在某一条对话里AI 很可能下次就忘了。正确的做法是写进提示词的功能范围或非功能要求真正做到规则不缺席。我后来养成了一个习惯每次让 AI 改代码时如果涉及新规则我会先更新原始提示词再开新一轮对话保证所有约束始终在上下文里。第四版本控制不能少。AI 每次改动可能同时动了 10 个文件如果直接改坏你根本不知道哪里出了问题。我会在让 AI 动手前先手动提交一次代码万一改乱了可以随时回滚。就这一个简单的习惯至少帮我省出了两三个小时的排查时间。4.4 对话上下文失控时的补救最后一个提醒几乎每个长项目都会遇到对话到中间AI 开始失忆。你可能发现它新生成的代码跟最开始定的技术栈不一致或者它忘了某个模块已经实现过重复生成了一遍。遇到这种情况我的办法是分两步。第一步把原始的开工提示词原封不动再发一次让 AI 重新对齐目标和约束。第二步明确告诉它以上是项目总要求现在请你基于已存在的 src 目录完成 XXX 功能不要重新创建已经存在的文件。把不要重复造轮子这句话直接说给 AI 听很多时候比你自己手动清理代码要快得多。如果你的对话已经乱到无法挽救干脆新建一个会话把原始提示词加上当前项目的关键文件结构一起贴进去重开一局通常比抢救一局更省事。5. 这一篇的最后几句这篇先写到这里。说实话从零到第一版可运行的订单管理系统我只用了一天其中真正花在提示词上的时间可能只有一两个小时剩下的时间全耗在验证、修 bug 和补规则上。写这篇文章时我又回头复盘了一遍整个过程最大的感受是AI 编程的能力边界比大多数人想象的要宽但它的下限完全取决于你输入的提示词质量。提示词它不是玄学就是把你想清楚的事用 AI 能理解的方式说清楚。接下来这个系列我会继续写数据模型设计的细节、订单状态机的实现、统计报表怎么让 AI 帮你做、以及最终怎么部署让系统可以被多人访问。如果你在跟着做建议先把这一篇的开工提示词改成你自己的业务场景——换一套商品字段、换一个技术框架都不重要重要的是先让 AI 跑通一次从提示词到可运行系统的完整流程你有了这个底子后面再慢慢打磨就是水到渠成的事。