夜雨聆风
普通人现在用 AI 做 App，最容易翻车的地方，居然已经不是“不会写代码”了。
这事听起来有点反直觉。
以前做一个 App，第一道门槛是写代码。你不会前端，不会后端，不懂数据库，不知道怎么部署，基本就只能停在想法阶段。
现在不一样了。
你把需求丢给 AI，它能给你页面，能给你接口，能给你数据库表，甚至还能告诉你怎么上线。很多原来要花几周搭出来的东西，现在一个晚上就能看见雏形。
这当然是好事。
但问题也从这里开始。
当“做出来”变得越来越容易，“确认它真的能用”反而成了新的门槛。
很多人以为自己卡在不会写，其实真正卡在不会验收。
AI 写出来一个登录页面，你一看能输入手机号，能点按钮，能跳转首页，于是觉得成了。
但它有没有处理验证码过期？有没有限制重复发送？有没有防止别人无限撞库？用户换手机了怎么办？接口失败了页面怎么提示？数据库里手机号是不是唯一？管理员能不能查到异常登录？日志里会不会把敏感信息全漏出来？
这些问题不性感。
但一个 App 最后是不是能用，往往就死在这些地方。
AI 最擅长的是“把样子做出来”
先说结论：AI 做 App 很强，尤其强在把一个模糊想法快速变成可见的东西。
你说我要一个记账工具，它能给你首页、分类、金额输入框、统计图。
你说我要一个待办清单，它能给你新增、完成、删除、筛选。
你说我要一个小型 CRM，它也能给你客户列表、跟进记录、状态标签、搜索框。
这就是大模型的优势。
它读过大量代码、文档和界面模式。对常见产品来说，它脑子里有很多“平均答案”。你给它一个方向，它就能沿着最常见的路径，把页面和逻辑先堆起来。
这一步对普通人很友好。
因为普通人最怕的不是“架构不优雅”，而是想法永远停在脑子里。AI 至少把第一块砖搬到了地上。
但这里有一个坑。
AI 很容易把“看起来像一个 App”写成“好像已经是一个 App”。
这两个东西差得很远。
一个能跑的页面，只说明它在一条最顺的路上没有马上摔倒。它不说明数据是安全的，不说明权限是正确的，不说明异常能处理，不说明多人同时用不会乱，不说明你明天改一个字段它还能活。
这就像装修样板间。
灯是亮的，沙发是摆好的，厨房也能拍照。但你真搬进去住，才会发现插座够不够、下水会不会堵、墙里电线有没有按规范走、晚上隔音到底行不行。
样板间解决的是“看见”。住宅解决的是“长期使用”。
AI 做出来的第一个版本，很多时候更接近样板间。
它能让你看见产品方向，但不能自动替你承担验收责任。
验收不是挑毛病，是定义“什么叫能用”
很多普通人一听验收，第一反应是测试工程师拿着表格找 Bug。
这理解太窄了。
验收的本质不是挑毛病，而是回答一个更朴素的问题：这个东西，在真实使用场景里，算不算完成了它该完成的任务。
比如你做一个活动报名 App。
不是页面能提交表单就叫完成。
真正要问的是：一个用户报名后，是否能收到确认？重复报名怎么办？名额满了还能不能提交？管理员在哪里看名单？导出 Excel 时中文会不会乱码？用户填错电话能不能改？活动取消后怎么通知？报名数据是不是会丢？
这些问题没有一个特别高级。
但它们加在一起，才构成“报名”这件事。
说白了，产品不是页面集合，而是责任集合。
登录页负责识别谁进来。
支付页负责钱不能错。
后台负责让运营能查、能改、能追责。
数据表负责长期保存。
权限系统负责不该看的别看，不该改的别改。
验收要验的，就是这些责任有没有真的落下去。
AI 经常会犯一种很隐蔽的错：它把“流程走通”当成“责任完成”。
你让它写支付，它可能写一个按钮，点完显示“支付成功”。
但真实支付不是按钮变绿，而是订单、库存、金额、回调、退款、对账、失败重试这一串东西都不能乱。
按钮是入口，不是结果。
这句话普通人一定要记住。
最大风险不是 Bug，而是你不知道哪里该有 Bug
如果一个 App 明摆着报错，反而不可怕。
页面打不开，按钮没反应，数据库连接失败，至少你知道它坏了。
真正麻烦的是那种“看起来没坏”的坏。
比如用户 A 能看到用户 B 的订单。
比如删除一条记录后，统计数字没有同步更新。
比如管理员改了价格，老订单也被一起改了。
比如你以为数据保存了，其实刷新后就没了。
比如 AI 写了一个“本地演示用”的权限判断，部署到线上以后，任何人改一下请求参数就能看到后台数据。
这些问题不会在首页大喊“我错了”。
它们更像地板下面的漏水。
刚住进去没感觉，过几天墙角开始发霉，等你发现时，楼下已经来敲门了。
所以普通人用 AI 做 App，真正危险的不是 AI 写错一行代码。
写错代码很正常，人也会写错。
真正危险的是：你没有一套方法知道它可能错在哪里。
AI 生成的代码通常很会讨好你的眼睛。
页面干净，按钮顺滑，提示语也像那么回事。
但软件系统的质量，很多都藏在看不见的地方。
边界条件、异常处理、数据一致性、权限隔离、安全策略、日志记录、备份恢复。
这些东西不像首页 Banner 那么显眼，也不像动画效果那么好截图。
但它们才是一个 App 从“玩具”走向“工具”的分界线。
普通人验收，先别上来谈架构
很多人一发现 AI 可能写得不稳，就开始问：那我是不是要学架构？要不要学数据库范式？要不要看完一整套计算机课程？
不用一上来把自己吓死。
普通人的验收，不是让你变成高级工程师。
它更像收房。
你不一定会砌墙，也不一定懂水电图纸，但你至少要知道进门以后检查什么：水能不能流，电能不能用，门窗能不能关，墙面有没有裂，地漏会不会反味。
做 App 也一样。
你可以先抓五类问题。
第一类，主流程。
用户从进入 App 到完成核心任务，每一步是不是都能走通。注册、登录、创建、保存、查询、修改、删除，别只测一次最顺的流程，要用真实数据重复几遍。
第二类，反流程。
也就是用户不按你希望的方式来时，会发生什么。输入为空怎么办？金额填负数怎么办？重复点击按钮怎么办？网络断了怎么办？上传大文件怎么办？返回上一页再提交怎么办？
第三类，权限。
不同身份看到的东西是不是不同。普通用户能不能进管理员页面？用户改地址时能不能改到别人的地址？只改前端按钮隐藏没有用，后端接口也要挡住。
第四类，数据。
保存的数据会不会丢，会不会串，会不会重复，会不会被误改。今天写进去，明天还能不能查到。改了一个字段，相关页面是不是同步变化。删除时到底是软删除还是彻底删除。
第五类，恢复。
出错以后有没有办法回来。支付失败能不能重新支付，提交失败有没有明确提示，管理员误删数据能不能恢复，服务重启后任务还在不在。
这五类问题听起来土。
但非常管用。
因为它们不是按技术名词分类，而是按真实使用里的倒霉事分类。
普通人不一定懂系统设计，但一定懂倒霉事。
验收的第一步，就是把“用户可能怎么倒霉”写下来。
需求写得越像愿望，AI 越容易交差
这里还要说一个很扎心的点。
很多 AI 做 App 项目翻车，不是因为 AI 完全不行，而是因为人给的需求太像愿望。
“帮我做一个好用的会员管理系统。”
“帮我做一个类似小红书的社区。”
“帮我做一个能自动生成报告的工具。”
这些话对人类也不够，对 AI 更不够。
因为“好用”“类似”“自动”，都不是验收标准。
它们只是方向。
AI 会顺着方向生成一个平均答案。你看着还挺像，就以为需求被满足了。
可到真正使用时才发现，会员等级怎么算没说，积分过期规则没说，管理员权限没说，导出格式没说，报告错误时如何处理也没说。
于是 AI 只能猜。
它猜得越自然，你越不容易发现它在猜。
所以，用 AI 做 App 的第一份能力，不是会写 Prompt，而是会写验收条件。
不要只写：
“我要一个客户管理系统。”
要写：
“销售可以新增客户；同一个手机号不能重复创建；客户必须有负责人；普通销售只能看到自己的客户；主管可以看到团队客户；每条跟进记录要保留创建人和时间；删除客户需要二次确认；导出表格包含姓名、手机号、负责人、最近跟进时间。”
这段话不酷。
但它有用。
因为 AI 最怕的不是要求多，而是要求虚。
要求多，它可以逐条实现。
要求虚，它只能用套路填空。
一个能救命的办法：让 AI 先写验收清单
普通人不懂技术怎么办？
先别急着让 AI 写代码。
先让 AI 写验收清单。
你可以这样问：
“我要做一个面向小团队使用的客户管理 App。请不要先写代码，先从用户流程、权限、数据、异常、安全、后台管理、导出、备份这几个角度，列出上线前必须验收的清单。每一条都要能被普通人手动测试。”
这一步的价值很大。
因为它会把“看不见的责任”先摊在桌面上。
然后你再让 AI 根据这份清单写功能。
写完后，再让它反过来逐条说明：哪些已经实现，哪些没有实现，哪些只是前端演示，哪些需要第三方服务，哪些上线前必须人工确认。
注意，这不是让 AI 自己给自己打满分。
AI 的自检只能当初筛，不能当最终结论。
但有了清单以后，你至少知道该问什么。
不会像以前一样，看见页面能点，就不知道还能检查哪里。
这就像体检报告。
你未必懂每个指标背后的医学机理，但报告至少告诉你要看血糖、血脂、肝功能，而不是只看脸色红不红。
验收要用“脏数据”，别只用漂亮样例
AI 写演示时，特别喜欢漂亮数据。
张三、李四、测试客户、订单 001、金额 100。
这类数据很干净，干净到没有现实意义。
真实用户不会这么听话。
有人名字很长。
有人手机号填错。
有人地址里有特殊符号。
有人连续点十次提交。
有人在两个设备同时登录。
有人上传 20MB 的图片。
有人把备注写成一篇小作文。
有人什么都不填就点保存。
你只用漂亮样例测试，等于只在晴天试雨伞。
验收时一定要准备一批“脏数据”。
空值、超长文本、重复数据、特殊符号、错误格式、极限金额、并发操作、弱网状态。
不用一下子搞得特别专业。
但至少别只测最顺的一条路。
很多 AI App 的问题，就是在样例数据里显得很优秀，一碰真实数据就开始露馅。
上线前最少要问的十个问题
如果你觉得前面还是太散，可以记住这十个问题。
第一，这个 App 最核心的一件事是什么？
第二，一个新用户从进入到完成这件事，要走哪几步？
第三，每一步失败时，用户看见什么提示？
第四，哪些数据不能重复、不能为空、不能随便改？
第五，普通用户、管理员、访客分别能看什么、改什么？
第六，用户刷新页面、关闭浏览器、换设备后，数据还在不在？
第七，重复点击、重复提交、网络失败，会不会生成脏数据？
第八，敏感信息有没有暴露在页面、日志或接口里？
第九，管理员有没有办法查问题、改问题、导出数据？
第十，出了事故以后，最坏损失是什么，有没有恢复办法？
这十个问题不能保证你的 App 完美。
但它能把很多“样板间式 App”直接筛出来。
一个 AI 生成的项目，如果回答不了这些问题，就先别急着上线。
你可以把它当原型，当内部工具，当学习材料。
但别把它当已经能对外承诺的产品。
最后真正该升级的，是人的角色
AI 把写代码的门槛降下来了。
但它没有把做产品的责任拿走。
以前普通人做 App，常见身份是“提想法的人”。你说我要什么，工程师来判断怎么做，测试来判断能不能交付。
现在 AI 把中间很多环节压缩了。
你一句话，它就能给你一堆代码。
听起来像是你变轻松了。
其实不是。
你的角色被往后推了一步：从“提需求的人”，变成了“验收结果的人”。
这一步才是最难的。
因为提需求可以很浪漫，验收必须很具体。
提需求可以说我要一个好用的工具，验收要说同一手机号不能重复注册。
提需求可以说我要自动生成报告，验收要说数据缺失时报告应该显示什么。
提需求可以说我要用户体验好，验收要说失败提示、加载状态、权限边界和数据恢复。
所以聊到最后，普通人用 AI 做 App，真正的门槛已经变了。
不是你会不会写那几行代码。
而是当 AI 把一个看起来能跑的东西放到你面前时，你有没有能力问出那句最扫兴、也最值钱的话：
“它到底凭什么算完成？”
问不出这句话，AI 写得越快，坑也可能挖得越快。
问得出这句话，AI 才真的从一个会变魔术的工具，变成你手里能干活的工程队。
App 不是做出来就结束。
能被验收，才算刚刚开始。
