我没有全栈开发经验，HTML、CSS、JavaScript 和 Python 都只会一些基础语法。但我想做一个给真实门店使用的点餐系统：顾客扫码选咖啡、饮品、甜品和轻食，同桌可以一起点，店员在后台接单、处理订单、结账。
AI 让我有能力开始这个项目。做下去之后我才发现，代码生成得快，和一个系统真正好用，是两回事。
同桌两个人同时加菜，购物车听谁的？提交订单时网络断了，这单到底算没算？上一桌结完账，下一桌扫码进来，会不会看到之前的订单？这些问题，光看一个漂亮的页面是看不出来的。
最近读了宝玉的《AI 原生思维——像训练大模型一样训练自己》，我把其中适合拿来做项目的思路，和自己的开发经历放在一起重新看了一遍。这篇文章记录的，就是需求怎么收住、问题怎么暴露，以及我怎么逐渐学会验收 AI 的工作。
根据阅读与实践整理的方法总览。下面的点餐案例，是我对这些方法的具体理解。
先把一桌饭的流程走通
宝玉在文章里讲了一个天气图的例子：早期需要用户手动提供天气信息，后来模型能自己搜索，只输城市名就能生成图片，参与的人随之增加。这个例子让我想到，少让用户折腾几步，产品的使用感受就会不同。
放到点餐系统里，顾客想点杯咖啡，店员想知道哪桌下了什么单。顾客的备注能不能传到后台、店员在手机上操作方不方便，都比用了什么框架更直接。
顾客端 H5 网页预览版实拍，不是微信原生小程序运行环境截图。
所以第一版的范围定在一家店的堂食点餐：顾客扫码、选商品、提交订单，店员接单，线下收款后在后台结账。先把这一桌饭从头到尾走通。
先做线下收款，是一个很实际的取舍。接入在线支付，还要处理支付结果、退款、对账。眼前顾客怎么点、店员怎么接，已经有不少细节需要磨。
AI 写代码快，我反而更需要想清楚范围。每多做一块，后面就多一块要检查、要维护的地方。功能能不能加，和现在值不值得加，需要分开判断。
后台实拍：顾客看到的商品、分类、价格和规格，在这里维护。
三个 Bug，让我重新理解“功能完成”
备注能输入，还得让店员收得到
顾客填写了整单备注，后台却看不到。页面有输入框，也能输入，单看顾客这一侧，好像功能已经存在。但备注没有完整保存到订单里，到了店员那边就断了。
假设顾客写的是“有一杯不要冰”，店员看不到，这个输入框做得再好看也没用。
修复时，需要把备注保存进订单，再检查后台能不能正确显示。只有把顾客到店员这一路走完，才能说这件事做好了。
当前购物车实拍。截图展示备注入口，备注是否传递成功还需要完整下单验证。
购物车变了，和提交结果未知，是两种情况
共享购物车里，一个人准备提交，另一个人又加了东西，前一个人手里的购物车就旧了。系统拒绝旧版本，本身可以理解，但当时页面没有正确更新，再点提交，还是拿着旧内容继续试，于是卡在那里。
这里必须分清两种情况：
- 已确定购物车发生变化：刷新内容，让顾客重新确认后再提交。
- 网络超时，提交结果未知：先确认这次请求的结果，不能随便再建一单。
第二种情况涉及“幂等”：同一笔下单请求重复处理，也不应该多出订单或重复扣库存。以前我觉得这个词很绕，放进点餐场景就具体了——顾客可以多点几次按钮，店里不能因此多做几杯咖啡。
数字最终要正确，输入过程也要顺手
后台还有个小问题：在手机上填写规格加价，明明还没输完，数字就可能被自动处理成零。
后来改成先保留输入内容，等保存时再统一转换，操作才顺了。这个问题让我意识到，最终保存的数字正确是一回事，输入到一半时会不会被打断，是另一回事。自己拿手机填一次，感受特别明显。
图中的 0.00 是截图时的现有配置，并非 Bug 复现，也不是修复前后对比。
这三个问题给我的共同提醒是：验收要沿着真实使用流程走，不能只看某一页上有没有这个功能。
给 AI 具体的验收题
宝玉重做字幕工具的经历也给了我启发：他重新安排翻译与时间对齐，让 AI 调用工具检查结果，减少了逐步人工校对的工作。案例出处
对应到我的项目，我也得把需求、实现和检查连起来。只让 AI 写完，再等它告诉我“完成了”，心里其实没底。
比如要做库存，光说一句“加上库存管理”就太宽了。换成具体场景，验收才有落点：
| 场景 | 要检查的结果 |
|---|---|
| 只剩最后一份甜品，两个人同时下单 | 只能有一个订单成功，另一个不能把库存或订单改乱 |
| 同一笔订单重复提交 | 不重复创建订单，不再次扣减库存 |
| 售罄后补货 | 补货后能够恢复销售 |
项目里的库存验证检查了这些情况。看到具体的结果，比看到一句“库存功能已完成”踏实多了。
不过，有测试也不代表所有地方都没问题。网页预览版曾遇到购物车首次加购失败、刷新后内容丢失。后来排查发现，测试环境里的一段模拟处理，把真实运行时的问题盖住了。
所以测试怎么测，也得看一眼。我还需要在真实运行环境里操作：刷新页面、反复点击、换个屏幕尺寸，看看结果和测试里的说法是否一致。
把文档留给下一次开发
项目里逐渐有了需求文档、分步计划、测试记录和 Bug 复盘。它们帮我回答几个很实际的问题：之前定了什么？现在做到哪里？哪些地方还没有验证？
下次接着做时，把已经确认的规则交给 AI，可以少一点来回解释。规则变了，文档也要跟着改，否则它拿着旧要求继续做，还是会跑偏。
我现在更愿意把一次修改留下来的内容整理成三部分：
- 当时想解决什么：用户遇到了什么问题，这次做到哪里为止。
- 实际改了什么：问题原因、处理方式，以及为什么这样取舍。
- 用什么证明：跑过哪些检查，实际试过什么，还有哪些情况没确认。
这些记录以后既能帮我继续开发，也能变成可分享的知识。修过的问题留下来，下次修改相关功能时，我和 AI 都有东西可以参考。
AI 帮我执行，我练习判断
自己复盘时，整理出的修复类提交有 89 个。其中有些是同一个问题的多次处理，不能把它们算成 89 个独立 Bug。但这个数字至少说明，开发过程里确实有很多修修补补。
用 AI 做项目是不是轻松，要看说的是哪一部分。代码可以很快写出来，但我还是得花时间把需求讲清楚，去试，去发现不对的地方，再让它改。有些报错还要来回排查，才能找到原因。
对我来说，AI 的帮助很大。以前缺少全栈经验，做这样的项目会有很多地方卡住。现在我可以带着具体问题，边做边弄明白：为什么要防止重复下单，为什么不同桌的数据不能混在一起，为什么电脑上能跑还要到手机上再试。
这些概念单独学，可能过两天就忘了。自己遇到一次，理解就具体多了。
这个项目做下来，我还有很多细节不懂，但我能提出的问题比刚开始具体了。看一个功能时，也会多想几种真实使用的情况。这是我目前最大的收获。
留给下一个项目的检查清单
下一次用 AI 做项目，我会先拿这几条对照：
- 用户想完成的那件事，能不能用一句话讲清楚？
- 第一版的范围有没有收住，能不能从头到尾用起来？
- 每个需求有没有对应的验收场景，尤其是并发、重复操作和网络异常？
- 测试之外，有没有在真实环境和手机上亲自试过？
- 这次确认的规则、修过的问题和未验证的部分，有没有留下记录？
如果你也想用 AI 做点东西，可以找一件自己确实需要的小事先试试。范围不用太大，先用起来。哪里不顺就继续改，等做完一轮，再回头看那些原来不懂的概念，很多就能对上了。
阅读来源：宝玉《AI 原生思维——像训练大模型一样训练自己》。文中的点餐系统经历与实践清单来自我自己的项目复盘。
图片说明：实拍截图采集于 2026 年 10 月 7 日，顾客端为 H5 网页预览版。截图展示当时的界面状态，不单独作为历史 Bug 已修复或并发正确性的证明；顾客端右侧的粉色悬浮图标来自浏览器翻译扩展。