不会写代码的人,也能通过描述需求让 AI 逐步完成界面、业务逻辑和数据功能。然而,当应用开始保存真实用户资料或承载团队业务时,仅凭页面能够正常操作远远不够。代码是否安全、权限是否严谨、故障能否回退,以及后续由谁维护,都会成为交付前必须回答的问题。
先说结论: 完全不懂代码,也可以用 AI 做出能用的网页、小程序或 App。但“功能能跑”不等于代码结构清晰、权限安全、数据可靠、系统可维护。个人工具可以大胆尝试;一旦开始承载他人数据和团队业务,就必须有人对生成代码和长期运行负责。
我不懂代码,但之前也让 AI 帮我写过一个自己想用的学英语 App。
这件事一开始真的很奇妙。我不会写函数,也不懂数据库,但可以像一个用户或产品经理一样告诉 AI:我想记录学过的单词,希望按日期查看,这个按钮不好用,那里的流程再简单一点。
然后,我看界面、试效果,它继续往下写。
但做着做着,痛苦也出现了:只要问题进入代码内部,我就无法判断它到底改了什么。
修好一个页面,会不会让另一个功能失效?用户 A 能不能看到用户 B 的数据?密码和接口密钥存在哪里?如果更新后崩了,能不能回到上一个版本?
我看不懂代码,也就无法独立验证这些问题,只能继续问 AI。
这让我意识到:AI 降低了把想法变成产品的门槛,但没有自动消除软件的工程责任。
这里的“黑盒”,不是指源代码不可见,而是使用者只能描述输入、观察输出,无法理解内部结构,也无法评估一次修改会影响哪些地方。
零基础用户能直接看到的,通常只是最上面一层:
可见层:页面、按钮、操作流程
↓
应用层:业务逻辑、接口、异常处理
↓
数据层:数据模型、校验、备份
↓
安全层:登录、鉴权、权限、密钥
↓
运行层:部署、日志、监控、回滚
AI 可以生成后面几层的代码,但“被生成”不等于“被理解、测试和接管”。
所以,当有人问“我完全不懂代码,能不能用 AI 学开发”时,我会先想了解:
目标不同,需要承担的责任完全不同。
| 目标 | 主要风险 | 建议 |
|---|---|---|
| 个人自用工具 | 改一处坏一处、不会排查报错 | 直接做,边做边学 |
| To C 原型或小产品 | 个人信息、账号、支付和稳定性 | 公开上线前加入技术审查 |
| 团队业务系统 | 权限越界、数据泄露、无日志和备份 | 使用成熟平台或由专业开发者接管 |
| 学习开发或职业转型 | 会生成,不会判断和维护 | 把 AI 当老师,不只当代写 |
这不是行业标准,只是我根据个人实操和企业数字化工作经验,用来判断责任边界的一个框架。
如果只是做单词记录器、读书清单或自己用的小网页,我会建议直接开始。只要损失是自己可以承受的,边做边学非常有价值。
但当陌生人开始注册、保存资料,甚至支付费用,问题就不只是功能好不好用。至少要检查用户数据是否隔离、敏感信息是否暴露、输入是否经过服务端校验,以及数据能否备份和恢复。
如果是 CRM、合同、费用、生产协同或员工管理系统,还必须说清楚:
如果这些问题都没有答案,系统即使能演示,也还不具备交付条件。
这类项目不一定都要从头手写。可以选择已经承接数据模型、角色权限、工作流、日志和运行环境的成熟平台,再让 AI 辅助扩展;也可以由专业开发者审查并接管生成代码。
重点不是一定选哪条路,而是不能让“AI 说已完成”成为唯一验收标准。
如果你还想真正学会开发,可以改变和 AI 的协作方式:
如果这些问题永远都答不上来,自己获得的主要还是一个产品结果,而不是开发能力。
原型:验证问题是否值得解决
↓
可用产品:账号、数据校验、异常处理、基础测试
↓
生产系统:权限、日志、监控、备份、回归测试与长期维护
AI 很适合帮我们快速通过第一道门,也能在后两个阶段大幅提效。但项目越接近生产环境,“由谁验证、由谁接管、由谁负责”就越重要。
用 AI 写代码当然可以,也值得每一个有兴趣的人尝试。
如果只是个人小工具,尽管去做。如果要面向真实用户、团队和业务,那么“能做出来”只是第一步。