现在做一个App，看起来从未如此简单。

你只要对AI说：“帮我做一个记账工具，要有登录、分类统计和漂亮的图表。”几分钟后，页面出现了，按钮能点，数据也会变化。

社交平台上，这种演示常常以一句话结束：不会编程的人，也能独立开发软件了。

这句话并不完全错。AI已经大幅降低了把想法变成原型的门槛。但原型能运行，和产品能够安全地交给别人使用，中间还有一段最容易被忽略的路。

AI编程真正降低的是“生成代码”的门槛，却把更大的责任推到了“验证代码”的一边。

这篇文章不比较哪款AI写代码更快，也不承诺用一句提示词创业。我们想做的是拆开“做出一个App”这句话，看看普通人到底可以做到哪里，又必须学会验收什么。

01｜AI编程已经从“补全代码”走向“接任务”

早期的AI编程工具更像输入法：你写出函数开头，它补全后面的几行。今天的代码智能体已经可以读取整个项目、修改多个文件、运行命令、执行测试，并提交一份等待审查的改动。

这是一种工作方式的变化。人不再需要逐行告诉AI写什么，而是可以描述目标：“修复这个登录问题”“增加导出功能”“把旧接口迁移到新版本”。

但任务越完整，AI拥有的操作范围也越大。它可能安装依赖、修改配置、读取环境变量、访问网络，甚至触碰部署流程。能力提升的同时，错误影响也从“一行代码写错”扩大到“整个系统被错误修改”。

因此，GitHub和OpenAI在介绍代码智能体时，都把测试、日志、草稿式提交、权限边界和人工审查放在核心位置。真正的趋势不是AI独自交付，而是AI生成一份可验证、可审查的工作成果。

02｜“做出一个App”，其实包含五层工作

当一个页面出现在屏幕上，我们很容易把它当成产品已经完成。但软件不是一张能交互的海报。

第一层：界面

页面是否好看，按钮能不能点击，手机和电脑上是否正常显示。这是最容易被演示、也最容易被AI快速完成的一层。

第二层：功能

金额如何计算，重复提交怎样处理，不同用户能做什么，业务规则是否前后一致。这里需要的不是代码语法，而是对需求的准确理解。

第三层：数据

数据保存在哪里，刷新后会不会丢，多设备怎样同步，删除、导出、备份和迁移是否可靠。

第四层：安全

用户身份如何验证，普通用户能否看到别人的数据，密钥有没有被写进前端，恶意输入会不会破坏系统。

第五层：交付

如何部署、监控、更新和回滚；服务崩溃后谁会收到提醒；依赖停止维护时怎么办。

AI最容易生成可见界面，产品成本往往藏在界面之下

一个App能打开，只能证明它通过了演示；能被别人长期使用，才说明它接近产品。

03｜为什么AI代码经常“看起来对，实际上不完整”？

AI很擅长生成符合常见模式的代码。登录页像登录页，购物车像购物车，接口也有熟悉的名字。这种“像真的”会给人很强的完成感。

问题在于，AI主要根据你提供的上下文和项目中已有模式做推断。没有写清楚的部分，它只能替你做决定。

你说“支持登录”，它可能默认只做邮箱密码，却没有验证码、找回密码、登录限速和会话失效；你说“保存数据”，它可能只存在浏览器本地；你说“管理员可以查看全部记录”，它可能只隐藏了按钮，却没有在服务器端检查权限。

这些代码往往能通过最表面的演示，因为演示只走了一条正常路径。真正的问题藏在空值、重复点击、断网、并发、权限切换和恶意输入里。

AI不会主动知道你没有说出的业务规则。需求中的空白，最后会变成代码里的默认决定。

04｜一次可复现的验收实验

你可以让任意一款AI编程工具生成一个最小任务管理App：新增任务、修改状态、删除任务，并保存到本地。不要先告诉它测试条件。

页面生成后，不要马上评价“成功”。依次做下面六件事：

创建一个空标题任务；

连续快速点击两次新增按钮；

输入一段很长的文字和特殊字符；

刷新页面、关闭浏览器再打开；

删除一项后尝试恢复；

把存储数据手动改坏，再重新打开页面。

这个实验不需要你懂编程，却能快速暴露产品是否处理了输入校验、重复操作、界面溢出、数据持久化、误删除和异常恢复。

如果AI修复了这些问题，再让它为每个场景补自动测试。然后故意改坏一个关键判断，确认测试真的会失败。测试始终显示绿色，不代表它覆盖了重要风险；测试能在错误出现时变红，才有意义。

05｜普通人也能掌握的五层验收法

第一层：需求验收

先不看代码，只问：它解决的是原来的问题吗？把需求写成“谁，在什么情况下，要完成什么，成功标准是什么”。

第二层：功能验收

从用户角度走通最重要的三条路径，并记录每一步预期结果。不要只点一次按钮，要检查刷新、返回和重复操作。

第三层：边界验收

主动输入空值、极长内容、错误格式和重复数据；模拟断网、超时、权限不足和服务不可用。验收的核心不是证明它能工作，而是寻找它不能工作的地方。

第四层：安全验收

确认密钥不在前端代码中，不同用户的数据真正隔离，敏感操作需要再次确认，外部输入会被验证。涉及付款、医疗、身份和隐私数据时，还需要专业审查。

第五层：交付验收

检查部署说明、自动测试、日志、备份和回滚。问清楚：如果明天更新失败，怎样恢复到今天的版本？

五层验收法：从“是否能用”走向“是否可交付”

06｜不会读代码，怎样监督AI写代码？

不会逐行阅读代码，并不等于完全无法验收。普通人可以把抽象的技术判断，转成可观察的证据。

让AI先复述需求，并列出它做了哪些假设；

要求它先给修改计划，再开始写代码；

每个功能都配一组正常、异常和权限测试；

要求提供变更清单、运行日志和测试结果；

让第二个模型或静态扫描工具做独立检查；

高风险功能交给有经验的开发者审查。

这里最重要的能力不是背诵术语，而是提出可验证的问题。例如，不要问“安全吗”，而要问“普通用户能否通过修改网址看到管理员页面的数据”。

同样，不要接受“已完成测试”这句话。要让AI说明运行了哪些测试、哪些没有运行、失败时看到了什么，以及测试环境与真实部署有什么差别。

07｜AI编程真正抬高了哪一种门槛？

AI确实降低了语法门槛。过去需要搜索文档、搭建框架和反复调试的工作，现在可以由智能体快速完成。

但当生成速度提高十倍，审查压力也会迅速增加。一个人一天能手写的代码有限，却可能让AI生成几十个文件。代码越多，隐藏问题、重复实现和未来维护成本越难看见。

于是，稀缺能力从“能不能把代码写出来”，转向了三件事：能否定义问题，能否设计验证，能否为上线结果负责。

AI编程没有让工程消失，只是把工程的重心从生产代码，移到了约束、验证和维护。

08｜什么项目适合用AI快速做，什么项目不要冒进？

适合快速尝试

个人使用的小工具和一次性数据处理；

原型、内部演示和需求验证；

影响范围小、数据可恢复的自动化；

有清晰输入输出、容易测试的功能。

需要谨慎或专业审查

支付、账户、权限和用户隐私；

医疗、法律、金融等高风险决策；

连接生产数据库或能够删除重要数据；

大量用户依赖、无法轻易回滚的服务；

你无法说明失败后果的项目。

一个简单判断是：如果这个App出错，你能否在十分钟内发现、停止并恢复？如果不能，就不要只凭“页面看起来正常”上线。

09｜普通人使用AI编程的最小安全闭环

写清目标、用户、数据和不可接受的失败；

让AI先列计划、假设和风险，不要直接生成；

在隔离环境或测试项目中运行；

为核心路径和异常情况建立自动测试；

人工走查界面、权限和数据变化；

先小范围发布，并保留备份；

监控错误，确认能够快速回滚。

让AI生成、测试和修正，但把最终发布留在可控闭环中

结尾｜真正的“不会编程也能做App”，缺的不是下一句提示词

不会编程的人，今天确实可以做出过去难以独立完成的原型和小工具。这不是营销幻觉，而是一次真实的生产力变化。

但我们需要重新定义“做出”。生成一个能运行的页面，是开始；理解用户需求、保护数据、覆盖异常、完成部署并承担维护，才是交付。

AI可以帮你写代码、补测试、查漏洞，甚至解释每一次修改。可它不会自动知道你的业务底线，也不能替你决定哪些风险可以被用户承担。

所以，下一次AI在几分钟内生成一个App，不妨先别问“它写得有多快”，而是问：我有什么证据相信它在真实世界里不会轻易出错？

未来真正拉开差距的，不是谁最会让AI生成，而是谁最会让AI证明。