不会编程，直接用 AI 写代码靠谱吗？

一、先给结论：靠谱，但“靠谱”有前提

直接说答案：靠谱，前提是你得把自己摆在正确的位置上。AI 编程解决的是“把明确的需求翻译成可运行代码”这一段，而需求本身是什么、拆成几块、做得对不对，仍然需要人来定义和验收。换句话说，你不会从“不会编程的人”变成“不用干活的人”，而是从“写代码的人”变成“提需求、做决策、做验收的人”。

理解了这一点，剩下的就是方法论问题。下面用一个真实的小项目——零代码基础、全程没有手写一行代码、耗时约三个小时完成一款单词消除类小游戏，来完整拆解这条路径。

二、项目背景与需求拆解

起因很生活化：孩子备考词汇量较大的英语考试，每天抱着词汇表死记硬背，过程枯燥且遗忘率高。市面上的背单词工具要么趣味性不足，要么词库编排与老师要求的版本对不上。于是决定自己动手做一个背单词小游戏，核心玩法是“配对消除”：点击互为对应关系的中英文卡片即可消除，上方卡片下落补位，同时有新卡片从顶部掉落补充，形成持续的“盖楼”式挑战。

功能上锁定三条主线：选择词库 -> 选择游戏进度 -> 进入游戏。加上两条非功能约束：界面风格偏小清新，游戏进度要可保存、可恢复。

三、第一步：和 AI 对齐需求，先别让它写代码

1. 先画原型，再谈细节

随手画了三张页面草图，拍照发给多模态大模型。它不仅准确识别了布局与元素，连潦草的手写字也没认错。多模态理解能力在这里第一次体现出价值：非开发者不需要会用专业设计工具，一张纸、一支笔就足够表达意图。

1. 关键技巧：及时“踩刹车”

实践中最容易踩的坑是：推理模型太“积极”，往往需求刚描述到一半，它就已经撸起袖子开始输出了。生成的代码看似完整，实际建立在大量未经确认的假设之上，返工成本反而更高。因此需求讨论阶段要反复强调“先不要写代码”，可以用这样的提示词收住它：

请先不要写代码。我们要开发一个单词消除小游戏，共三个页面：
1）词库选择页 2）进度选择页 3）游戏页。
请先基于以上信息输出一份 PRD 文档，覆盖页面元素、交互流程、
数据格式与异常处理，经我确认后再进入开发。

1. 让 AI 反向输出 PRD

双方对齐后，让 AI 把讨论结果沉淀成一份 PRD 文档。这一步的价值在于“对齐颗粒度”：人对需求的描述永远是模糊的，AI 对模糊描述的补全方向又是随机的，只有落到白纸黑字的文档上，歧义才会暴露出来。后续每一轮生成代码时，把这份 PRD 一起喂回去，就能保证多次生成之间的一致性。

四、第二步：定义架构与页面间的传参接口

1. 做减法：第一版砍掉后端

讨论中一度考虑过支持更复杂的词库文件格式，但为了把第一版复杂度压到最低，最终决定：不做后端，词库用纯文本文件组织，进度保存在浏览器本地。纯文本词库格式示例如下，每行一个词条，中英文之间用制表符分隔：

apple    苹果
banana    香蕉

格式越简单，AI 生成解析代码的出错概率越低。第一版的目标是“能跑通、能验证”，而不是“功能完备”。

1. 页面划分与传参设计

整个应用拆成三个页面，页面之间通过 URL 参数传递上下文，例如从进度页跳入游戏页：

game.html?book=coreA&level=3

游戏页读取参数的示意代码：

const params = new URLSearchParams(location.search);
const bookId = params.get("book");
const level  = params.get("level");

游戏进度则用 JSON 结构存入浏览器本地存储：

{
  "book": "coreA",
  "level": 3,
  "score": 120,
  "clearedPairs": 24
}

这一步的意义容易被低估：接口约定先行，相当于给 AI 划定了“车道”。三个页面由多轮对话分别生成，如果没有事先统一的参数命名和数据结构，联调时几乎必然出现字段对不上的问题。

五、第三步：分页面实现与三页联调

1. 逐页生成，逐页验证

按照“词库选择页 -> 进度选择页 -> 游戏页”的顺序逐个实现。每完成一个页面，立刻在浏览器里打开验证：交互是否符合 PRD、数据是否按约定格式流转。发现问题时，把现象描述、控制台报错信息，必要时加上截图，一并贴回给 AI，修复效率远高于笼统地说“不对，改一下”。

1. 游戏主逻辑的实现思路

游戏页是复杂度最高的部分。描述需求时不需要写代码，用自然语言把规则讲清楚即可：卡片以网格排布，点击一对匹配的中英文卡片后消除；消除后上方卡片依次下落补位；同时顶部生成一行新卡片掉落，保持棋盘的动态压力。AI 会自行选择合适的数据结构（例如用二维数组表示卡片矩阵）并补全动画逻辑。

1. 联调与风格统一

三个页面单独都正确，不代表拼起来没有问题。联调阶段要做两件事：一是走通“选词库 -> 选进度 -> 开始游戏 -> 保存进度 -> 恢复进度”的完整链路；二是统一视觉风格，把三个页面的代码放在同一段上下文里，让 AI 对字体、配色、按钮样式做一致性重构。这一步改完，产品的“完成度”会上一个台阶。

六、沉淀成方法：让 AI 编程更稳的五条原则

1. 先文档，后代码：需求阶段坚决不让 AI 抢跑，用 PRD 锁定共识；
2. 小步快跑：一次只做一个页面或一个功能点，验证通过再进入下一步；
3. 约束显式化：技术栈、数据格式、命名规则、视觉风格，全部提前写清楚；
4. 反馈带上下文：报错信息、截图、期望行为与实际行为的差异，一起给到 AI；
5. 随时留版本：每完成一个可用状态就备份一份代码，AI 的修改不总是越改越好，要留好回退的退路。

七、能力边界：AI 编程适合做什么、不适合做什么

适合的场景：个人工具、小游戏原型验证、自动化脚本、静态页面、学习性项目。这些项目的共同特点是：需求可以用自然语言讲清楚，出错代价低，验证成本低。

需要谨慎的场景：涉及资金与隐私的后端系统、高并发服务、复杂的状态一致性逻辑。这类系统的难点不在“能不能写出代码”，而在安全设计、边界条件与长期维护，恰恰是当前 AI 编程最容易失守的地方。此外，无论什么场景，最终的测试与验收责任都在人，AI 可以生成代码，但不能替你承担后果。

工具层面，无论是直接与对话式大模型协作，还是使用百度智能云等平台提供的大模型与智能开发能力，流程本质是相通的：工具只是载体，需求拆解与验收方法才是决定成败的关键。

八、写在最后

三个小时、零行手写代码、一个能玩、能存进度的小游戏，这个结果放在几年前是不可想象的。但更重要的收获是过程本身：AI 编程并没有降低“做软件”的思考密度，它只是把“实现”这一环的成本压到接近于零，从而把人的精力逼回到最值钱的地方——想清楚要做什么、拆解成可验证的小块、并对结果负责。

对不会编程的人来说，最好的验证方式不是继续观望，而是找一个自己真正有动力完成的小需求，照着上面的流程跑一遍。跑完你就知道，“靠谱”这个词，到底适不适合用在自己身上。