这篇连载计划的开端其实不是代码也不是 AI 工具而是一张让我头疼的账单。我有个做小餐饮的朋友店里每天用微信接单、拿本子记账到了晚上对账经常差个几十块。他随口问我能不能搞个“能记单子的东西”我说行。于是就有了这个系列我用 AI 从零开发一个订单管理系统。更准确地说是我只写提示词让 AI 负责写代码从空目录一路把系统搭出来。这篇文章是第一篇核心就一个词开工。我要分享的是在目录还是空白的时候我给 AI 的那份提示词到底是什么样、为什么要这么写、AI 拿到之后又给我交了哪些作业。适合谁看想用 AI 做项目但不知道怎么开头的人尤其是没有系统学过全栈开发、又想自己搞定一个小工具的人。你可以不用懂 Flask 和数据库但你得能看懂“AI 到底给你生成了什么”这是用 AI 开发的第一课。1. 为什么用 AI 从零开工先想清楚这三点1.1 一个人想干全栈的尴尬如果你没体会过“想做个系统却不知道从哪下手”的感觉可能很难理解我为什么非要找 AI 帮忙。传统开发流程摆在那里需求分析、画原型、建数据库、写后端接口、做前端页面、联调、测试、部署。这几个环节随便拎一个出来都能让业余选手劝退。我这次的需求其实很小就是一个店里用的订单管理工具但小归小前后端、数据库、页面一个都少不了。一个人做全栈的尴尬在于你不可能每个环节都熟。我本身会一点 Python写过点脚本但前端布局对我来说就是天书数据库设计勉强能懂可一写 SQL 就露怯。放在以前这个项目大概率会烂在某个“周末先学一下 HTML”的环节里。AI 出现之后这件事的解法变了。我不需要先成为全栈工程师再开工我只需要把需求描述清楚让 AI 把第一版骨架搭出来然后我负责验收、反馈、让它改。听起来很美好但实际操作起来有一个容易被忽略的分水岭AI 生成一段代码很容易AI 从一个空目录里“开工”却没那么简单。1.2 AI 辅助不等于AI全自动我对“AI 开发”的理解可能和很多人一开始的期待不太一样。它不是你说一句“帮我做个订单系统”然后 AI 噼里啪啦给你一个完整产品的过程。真要这么干你大概率会得到一堆看起来像那么回事、实际跑不起来的文件。我自己的定义是AI 是那个“干活很快但需要你盯着的实习生”。你给它一个描述清楚的任务它能快速产出但如果你自己都不知道要什么、验收标准是什么它产出的东西就是一团浆糊。所以“从零开工”和“AI 自动写完全部”完全是两码事。这个项目里我做的最重要的一件事是在动手前一晚把需求、技术栈、功能边界全部定好然后写成一份提示词。这份提示词的目的不是让 AI“自由发挥”而是让它“按照我的图纸开始搭第一块地基”。AI 能不能开工、开工质量怎么样九成取决于这份提示词里给的约束够不够清楚。1.3 这个订单管理系统到底要做什么既然是“从零开发”最开始要明确系统边界。我要做的不是一个对标商用 SaaS 的订单系统而是一个小餐饮店内部用的工具。核心流程是这样的店员在页面上看到菜品列表客人点单后把菜加入订单选择桌台确认下单厨房或者吧台能看到订单状态客人结账后更新为已收款每天打烊后看一眼当天的营收统计。有人说这有什么难的一个 Excel 表也能干。但细想一下Excel 没法多人同时操作没法方便地管理菜品上下架也没法自动汇总每个桌台的消费记录。问题不大但是真实存在。我决定让 AI 来写还有一个隐藏原因我想验证一下一个不太会前端的人能不能靠提示词驱动 AI 完成一个“能用的系统”。所以这篇的侧重点不是在讲代码细节而是在讲怎么让 AI“动起来”。等系统真的在本地跑起来的那一刻你会觉得这个门槛确实被 AI 踩低了一大截。2. 开工前不写代码先做需求清单与技术栈决策2.1 用一句话定义核心场景准备提示词之前我先做了一件看起来很笨但特别有用的事用一句话把系统要解决的场景写清楚。我的原话是“店里客人点了菜店员在电脑上一个页面里完成点单、确认收款、查看当天营收。”这句话后来直接被我塞进了提示词里作为项目背景。为什么必须做这一步因为 AI 对“订单管理系统”这个词的理解太宽了它默认你会想到电商订单、物流状态、售后流程、多角色权限……如果你不限定场景它生产出来的第一版绝对跑偏。我见过太多人抱怨“AI 生成的东西没法用”其实不是 AI 不行是你没告诉它“这是给谁、在什么场景下、解决什么问题用的”。一句话场景描述就是给 AI 划定了一个网格。它后面的所有设计决策包括数据表、接口、页面布局都会基于你这句话来推导。这句话写得越具体AI 跑偏的概率就越小。2.2 功能清单列到“够用”为止我见过很多人做需求清单的时候恨不得把所有能想到的功能都塞进去结果项目做了三个月还没上线。这次我有意控制功能数量第一版只保留了四个核心功能每个功能都能在一天内实现完并且验证完毕菜品管理维护菜品名称、价格、是否上架。桌台与点单选择桌台勾选菜品并下单。订单列表查看所有订单标记为已收款、已完成。营收统计按当天日期汇总已收款金额和订单数量。你没看错没有库存、没有会员、没有图表大屏、也没有权限管理。这些功能不是说不需要而是它们不属于“从零开工”的第一批任务。第一版的核心目标只有一个让订单数据能录进去、能查出来、能统计出来。这个闭环跑通系统就有了生命后面加功能都是顺水推舟的事。我也把这些约束直接写进了提示词里明确告诉 AI“当前只做这些不考虑库存和会员”。这条约束很关键它避免了 AI 自作主张在数据表里塞一些你还用不上的字段也避免系统一开始就被设计得过于复杂。2.3 技术栈怎么选AI 才不容易跑偏技术栈的选择直接决定了后续开发体验。我不是为了炫技完全是从“AI 最容易写对、我最容易验证”的角度来选。后端我用 Python 的 Flask 框架。理由很简单Flask 足够轻单文件就能起一个服务AI 相关的语料非常多生成质量相对稳定。数据库选了 SQLite单文件数据库不需要安装任何服务端本地开发零成本数据量不大的个人工具完全够用。前端没有用现在流行的前后端分离方案而是传统的服务端渲染页面配合一点原生 JavaScript 和 Tailwind CSS 的 CDN 引入。这样前端不需要构建工具不需要 node_modulesAI 生成的代码也更好理解。有朋友问我为什么不用 Vue 或 React 加 Docker 加 MySQL 那套“企业级方案”。坦白说那套方案当然更“正规”但对一个刚开始的项目来说太重了。前端构建链一旦出问题排查成本比写业务代码还高Docker 和 MySQL 配置也会消耗大量体力。我要的是“快速看到界面、快速跑通流程”而不是“一开始就具备生产级高可用”。我在提示词里也把技术栈写死了Flask 2.x、SQLite、Jinja2 模板、Tailwind CDN、原生 JS。这么做的目的是减少 AI 自由发挥的空间。AI 在技术选型上如果自由发挥真会给你整出各种花活来。三点都定清楚之后我再开始动手写提示词。页面、数据表、接口这些具体方案全部留在提示词里让 AI 去出第一稿。3. 一份提示词让 AI 从零开工模板、拆解与迭代3.1 我发给 AI 的第一版提示词这是我确切发给 AI 的那份提示词原文为了方便大家阅读我把它整理在下面。你可以把它当成一个基础模板改成自己的业务场景直接用。你是一名全栈开发工程师请帮我从零开发一个订单管理系统用于一家小餐饮店日常点单和营收统计。 项目背景店里客人点了菜店员在电脑上完成点单、确认收款、查看当天营收。 技术栈要求 - 后端使用 Python Flask - 数据库使用 SQLite - 页面使用服务端渲染 Jinja2 模板 - 前端样式使用 Tailwind CSS CDN不要在本地安装 node_modules - 不要做前后端分离不要引入 Vue 或 React 第一版只需要实现以下功能 1. 菜品管理支持维护菜品名称、价格、上架状态 2. 桌台点单选择桌台如 A1、A2、B1勾选菜品提交生成订单 3. 订单列表展示所有订单支持将订单标记为已收款 4. 营收统计首页展示当天的已收款总额、订单数量、待收款订单数量 我目前还没有任何代码目录也是空的。请你直接生成整个项目的第一版骨架包括 - 项目目录结构与说明 - SQLite 数据表的建表语句包含菜品表、桌台表、订单表、订单明细表 - Flask 后端路由包含页面渲染和表单提交接口 - Jinja2 模板页面包含菜品管理页、点单页、订单列表页、首页营收统计 注意 - 订单金额全部用整数“分”存储避免浮点数精度问题 - 生成的数据表要包含示例菜品数据方便我本地直接运行验证 - 生成的文件要放在项目根目录下最后告诉我如何在本地启动运行 - 不要反问我会员、库存、打折等扩展需求先把上面四个功能做完看起来不长但每个句子都是有用的。我后面拆解一下为什么这版提示词能让 AI 直接开工而不是站在那儿跟你来回确认。3.2 为什么这版提示词会让 AI 直接开工很多人用 AI 写代码时都有过这种经验你提了一句“帮我做个点单系统”AI 反问你“你需要哪些角色要支付功能吗订单状态有哪些”按理说它问得也没错但高效率的开发节奏里这是在浪费你的时间。AI 不是不能问你而是你可以用一份完整的提示词直接省掉它追着你问的环节。我这份提示词里有几个关键设计缺一不可第一是明确技术栈。很多人生成了半天发现代码跑不起来原因不是 AI 写错了而是它默认采用的方案和你的运行环境不匹配。我在提示词里把 Flask、SQLite、Jinja2、Tailwind CDN 全部写死AI 就没有太多偏离空间。第二是明确目录状态。我特别强调“目录也是空的”这句话很关键。AI 看到这句话后会从零开始给你生成一个完整骨架而不是假设你已经有了某段代码。不少人在已有项目里让 AI 加功能AI 会基于它“脑补”的现状写代码结果当然接不上。目录是空的就等于告诉它不要脑补从地基开始盖。第三是明确交付物。我不要它只给我一个 app.py 加一句“你再配置下数据库”我要求它一口气输出建表语句、路由、模板页面、示例数据、启动说明。说白了我要的是开箱即用。只要你敢提这种要求AI 是能做到的。第四是明确边界。最后一句“不要反问我会员、库存、打折等扩展需求”直接掐断了 AI 发散问题的欲望。同时这句话也在排序优先级先把核心闭环做出来。还有一个容易被忽略的点我在提示词里要求订单金额用整数“分”存储。这不是随手写的约束而是因为浮点数做金额计算会产生精度问题用分存储是后端开发的基础常识。写进提示词后AI 生成的所有金额逻辑都会按整数处理能少踩很多坑。3.3 真实开工记录AI 给我的第一版交付物提示词发出去之后我等了大概一分钟AI 返回了一张项目结构图。我把它简化成下面这样方便你理解它当时的思路order_system/ ├── app.py ├── schema.sql ├── seed.py ├── templates/ │ ├── index.html │ ├── dishes.html │ ├── order.html │ └── orders.html └── static/它没有写很多额外说明很直接地告诉我先运行python seed.py初始化数据库并写入示例菜品再运行python app.py启动服务打开本地页面就能用。当时我按照它的指引操作第一遍真的就把首页打开出来了数据也都在。这个交付物的设计是正确的。schema.sql 管建表seed.py 管初始化数据app.py 管路由和业务逻辑templates 目录放页面模板。所有东西各司其职没有乱七八糟的嵌套结构。它对“从零开工”的理解到位了。但我也发现了一些问题。第一个明显问题是没有做统一入口用户初始化数据库的流程不够友好。我后来让 AI 在 app.py 里自动检测数据库文件如果没有就自动执行 schema 和 seed这样启动命令就变成一个了python app.py。第二个问题是订单状态只有“已收款”和“待收款”但实际店里还需要一个“制作中”的状态。这个改动涉及订单列表页和状态流转逻辑我在后面的迭代里让 AI 补上了。第一次开工能达到这种程度已经很符合我的预期。你要知道传统方式下我从创建虚拟环境、写 Flask 配置文件、设计第一个数据库表、写第一套模板页面到真的能打开首页不说三天至少一个下午是要的。AI 把它压缩到了一分钟剩下的是不断的修改和完善。3.4 让 AI 持续迭代的几个小习惯第一版骨架能跑之后剩下的工作就是不断提出修改需求。很多人这时候容易犯一个错误一次性把十个修改需求打包丢给 AI然后等一个“完美版本”。我踩过这个坑结果 AI 改着改着把自己绕晕经常出现“这个需求忘了改”“那个需求改了但影响了另一个功能”的情况。我后来养成了一个习惯一次只让 AI 改一个模块改完立刻验证。比如“把订单状态加上‘制作中’这个值并让订单列表里的状态展示对应标签”测试通过之后再提下一个需求。这种节奏看起来很慢实际上整体速度比“一次性大改”快得多因为每次改动的影响范围都清清楚楚出了问题能立刻定位。还有一个习惯是明确告诉 AI“在哪个文件里改、不要动什么”。比如新增一个菜品分类功能我会说“请在 schema.sql 新增 category 字段在 dishes.html 的菜品表单增加一个分类输入框在 app.py 的菜品新增路由里同步处理”。设定好修改范围AI 就不会像脱缰野马一样顺手把你的页面布局也重构了。版本管理也非常重要。每次给 AI 提新需求之前我会把当前的代码目录做一个快照或者直接整体复制一份到文件夹里。AI 改出问题的时候我能一秒还原到上一个可用版本。对于没有用 Git 习惯的人来说这一步至少能救你很多次。4. 开工之后怎么验收不盲信 AI 输出的实操方法4.1 跑通核心流程手工点一遍AI 给了你代码不代表交付完成。我见过太多人在“AI 写出代码”这一步就放松了结果一运行全是报错。验收的第一件事永远是手工把核心流程完整跑一遍。我当时的验收步骤是这样的启动服务打开点单页选中“A1 桌台”勾选两个菜品提交订单打开订单列表页确认这笔订单出现在列表里且状态是“待收款”回到首页查看营收统计是否显示“待收款订单数量 1”然后在订单列表页把状态更新为“已收款”回到首页看统计数字是否更新。这一圈走下来如果全部符合预期说明系统的主链路是通的。任何一步出问题都要把报错信息截图或者复制下来直接丢给 AI 让它分析修复。手工走一遍还有一个好处你会从用户视角感受这个系统好不好用。我当时就发现点单页的菜品列表太长不便于快速找到菜品后来让 AI 加了分类筛选这是只看代码根本发现不了的问题。4.2 看数据库表的字段是否合理页面能跑通之后还得打开数据库看看它的结构是否符合预期。毕竟是 AI 生成的建表语句页面流程能通不代表数据设计合理。我用的命令很简单进入 SQLite 控制台后用.schema查看每张表的定义。如果前期已经建立过数据库文件可以用sqlite3 order.db打开再敲.schema 表名查看。这一步能看到 AI 给每张表设计的字段、类型和约束。我注意到 AI 把订单金额存在了订单表里同时在订单明细表里也存了菜品单价和数量。这个设计乍看没问题但有一个隐患如果后续修改了菜品价格历史订单里的金额会不会变因为订单表存了下单时的总金额订单明细表存了下单时菜品单价所以历史订单不会受影响这是合理的。如果 AI 把金额设计成实时关联菜品表那历史订单的统计就会出错。另一个容易踩坑的点是字段类型。确认金额字段是不是整数类型确认状态字段有没有默认值确认时间字段是不是自动写入。这些细节如果设计不好后续写统计逻辑会有很多麻烦。这也是我在提示词里强调金额用“分”存储的原因等到写统计报表时你会发现整数运算比浮点运算省心太多了。4.3 让 AI 自己解释代码再补一轮边界测试页面流程和数据表都验证完我会再做一步挑一段我觉得最重要、又没完全看懂的代码让 AI 解释它为什么要这么写。比如我让 AI 解释过“提交订单”这个接口的执行流程它是这样回复的先接收前端表单解析菜品 ID 列表并查询菜品价格计算出订单总额在订单表插入一条记录并返回订单 ID再把菜品明细逐条插入订单明细表。整个过程要放在一个事务里只要任意一步出错就回滚所有操作避免产生“有明细没订单”或“有订单没明细”的脏数据。这个解释让我确认了它确实理解了事务的重要性。如果 AI 给出的逻辑有问题这个时候发现了还来得及改起来成本很低。最后我会补一轮边界测试。包括不选择桌台就提交订单选了一个桌台但没选任何菜品就提交连续点击两次下单按钮看会不会生成两条重复订单菜品价格输入负数会怎样后端有没有做校验。这些边界情况很容易暴露系统的脆弱之处。我把发现的问题全部反馈给 AI让它逐个修复效果立竿见影。5. 踩坑实录AI 辅助开发常见问题与排查技巧5.1 提示词写得太大项目直接失控我第一次尝试用 AI 开发时给的提示词是“帮我做一个功能完整的订单管理系统包含库存、会员、报表、权限”。结果 AI 生成了一堆互相矛盾的代码后端文件十几个数据库表二十多张我根本不知道该从哪个文件开始跑页面也是乱糟糟的。那次项目最后被我整个删掉了。后来我总结出一个规律AI 开发项目的成功率和提示词的颗粒度成反比。第一次开工你只需要让它做最小闭环能把一个核心流程跑通就行。功能越多系统越复杂AI 出现互相干扰的概率就越大。如果你也遇到项目失控的情况建议回到原点把需求拆成几个“垂直切片”。每个切片都包含一个完整的功能闭环比如“能从列表页创建一条订单并在列表里看到它”。先让 AI 完成最小切片验收通过后再加下一个。不要奢望一份提示词换一个完整产品。5.2 系统改大了AI 改不动怎么办项目进行到中后期文件越来越多代码越来越长你会发现 AI 渐渐“记不住”之前的改动或者明明让它在 A 文件改它却跑到了 B 文件里开了一条新逻辑。这不是 AI 变笨了是上下文窗口装不下整个项目了它对全局的掌控力变弱了。这时候我常用的方法是缩小任务粒度。不再让 AI“把订单模块优化一下”而是明确告诉它“在 app.py 的/orders路由里把订单列表的排序方式从创建时间倒序改成状态优先再按创建时间倒序”。任务越小它出错的概率越低。另外如果项目里某一块逻辑反复出问题我会考虑把这一块提炼成单独的模块文件或者直接重写一部分。让 AI 在混乱的代码上打补丁不如给它一个干净的小范围接口去实现。重构的成本在 AI 时代被大大降低了遇到烂代码别硬扛重写可能更省钱。5.3 重复造轮子与静默改坏有些功能 AI 明明之前已经实现过但你在新需求里没有提及它它可能就会重新造一个。最常见的表现是项目里多了重复的页面、重复的路由或重复的工具函数。这个问题不是不能忍但会让项目越来越臃肿最后连 AI 自己都分不清该调哪个函数。我的习惯是在每个新需求里主动提醒 AI“优先复用已有代码不要新增重复的模块”。虽然不能保证每次都生效但至少能减少一半的冗余。更危险的是“静默改坏”AI 在实现一个新功能时悄悄改掉了之前一个已经正常的功能。因为你可能没有每次都完整验收这个问题可能好几天之后才发现。现在我的应对办法是每次 AI 改完代码我都把核心流程重新跑一遍哪怕只是快速点一圈。不回归测试就不算改完。5.4 快速自查清单我整理了一份每次用 AI 开发都在用的自查清单分享给你照着检查基本不会大翻车检查项操作出现问题的概率核心流程手工把点单→收款→统计走一遍中数据库字段打开 SQLite 查看字段与类型高金额精度确认金额字段为整数“分”存储高边界情况测试空桌台、空菜品、重复提交中提示词范围确认任务是否只聚焦一个模块高版本回退修改前对当前可用版本做快照中我把“版本回退”也放在清单里。用 AI 开发最怕的不是没代码而是代码被 AI 改成一坨屎之后你找不到之前的可用版本。养成改前备份的习惯等于给自己买了一份保险。这个订单管理系统从空目录到第一版跑起来我用了一份提示词和一个下午。写这篇文章的时候系统已经能管理菜品、记录订单、统计营收了。后面我准备继续写这个系列的第二篇把营收统计页面做得更直观点顺便加上日期筛选和日报导出。但说实话这些都是后话对一个新项目来说最难的不是功能多丰富而是先让它跑起来。我个人在实际操作中的体会是用 AI 开发最值钱的能力不是会写代码而是能说清楚想要什么、能验证 AI 给的东西对不对。提示词不是魔法咒语它只是把你的验收标准提前翻译给了 AI。下次你准备用 AI 开工一个项目时别急着打开工具反复追问先坐下来写三行字这个系统给谁用解决什么问题第一版做到什么程度算完。这三行字想明白了提示词自然就有了。