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

过去一年，大模型在代码生成方向的能力快速跃升，越来越多的非专业开发者开始尝试一种新路径：不手写代码，借助 AI 完成一个可运行的小项目。但一个绕不开的问题是——这条路到底靠不靠谱？

本文不讨论空泛的“AI 会不会取代程序员”，而是以一个真实完成的小项目为例，把需求讨论、架构设计、页面传参、多页联调这些环节逐一拆解，看看在“不敲一行代码”的前提下，AI 编程能做到什么程度，以及哪些地方仍然需要人来把关。

一、先谈可行性：AI 编程的边界在哪里

在动手之前，需要先建立一个合理预期。当前大模型在代码生成上的能力，大致可以这样理解：

• 能胜任的部分：单页面交互逻辑、样式布局、状态管理、本地数据存取、页面间参数传递、常见算法的实现；
• 需要人介入的部分：需求边界的界定、整体架构的取舍、接口约定的定义、风格一致性的把控、错误定位与调试方向；
• 容易翻车的部分：需求描述含糊时模型会自作主张、页面增多后上下文容易丢、跨页面数据结构不统一、对“先做什么后做什么”缺乏全局节奏。

换句话说，AI 更像一个执行力极强但需要明确指令的协作者。你给它的约束越清晰，产出越稳定；你越指望它猜，结果越随机。

下面用一个具体项目来说明这套协作方式。

二、项目背景：一个记单词小游戏

需求的起点很日常：孩子备考需要每天背单词，词汇量大、过程枯燥、容易遗忘。市面上的相关应用要么趣味性不足，要么词表顺序与教学版本对不上。于是决定自己做一个轻量的记单词小游戏。

目标功能拆成三块：

1. 选择词书：从本地词库文件中选一本作为本次练习范围；
2. 选择进度：决定从哪个位置继续，或重新开始；
3. 开始游戏：进入核心玩法，边玩边记。

核心玩法是“配对消除”：屏幕上同时出现中文与英文卡片，点击匹配的一对即可消除；上方卡片下落填补空位，同时新卡片从顶部掉落，类似方块下落填充的节奏。

技术约束也很明确：第一版不做后端，词库用纯文本文件存储，游戏进度保存在本地。

三、阶段一：需求澄清比写代码更重要

很多人用 AI 编程的第一个误区，是上来就说“帮我写一个 XX”。正确的做法恰恰相反：先把需求聊清楚，明确要求它暂时不要写代码。

原因在于，推理能力较强的模型往往“太积极”，一旦看到需求描述就会直接进入实现，把很多本该由人决定的细节替你定了。所以在这个阶段，需要反复“踩刹车”：

• 明确告诉它：现在只讨论需求，不要输出代码；
• 让它先复述理解，确认没有偏差；
• 逐条对齐关键点，例如页面风格、进度存储方式、游戏规则边界。

一个容易被忽略但极其重要的环节是产品需求文档的整理。让模型把讨论结果梳理成一份结构化文档，包括：

• 每个页面的职责与入口出口；
• 用户操作流程；
• 数据结构定义（词书格式、进度格式）；
• 异常情况的处理方式（词库为空、进度损坏等）。

这一步的“对齐颗粒度”直接决定了后续开发的顺畅程度。需求阶段省下的十分钟，往往会在调试阶段变成一小时。

四、阶段二：架构与接口约定

即使是 AI 编程，架构设计依然不能省。它相当于小说的大纲——没有大纲，写到中途必然崩盘。

这个项目的架构相对简单，但几个关键决策必须提前定下：

1. 页面划分

• 词书选择页
• 进度选择页
• 游戏主页面

2. 数据流向与传参约定

页面之间的参数传递是最容易出问题的地方。如果每个页面各自定义数据结构，联调时必然对不上。因此需要先定义统一的接口约定，例如：

// 词书选择页 -> 进度选择页
{
  bookId: string,      // 词书唯一标识
  bookName: string,    // 词书显示名称
  totalWords: number   // 总词数
}
// 进度选择页 -> 游戏页
{
  bookId: string,
  startIndex: number,  // 起始位置
  mode: 'new' | 'review'  // 新学或复习
}

3. 本地存储结构

进度数据需要持久化，结构同样要提前定好：

{
  bookId: string,
  lastIndex: number,
  updatedAt: number
}

这些约定看起来琐碎，但它们是后续所有代码的“契约”。让模型基于这份契约分别生成各页面代码，比让它自由发挥要可靠得多。

4. 风格基线

小清新风格意味着配色柔和、圆角、留白充足、动效轻量。可以先用一个页面作为风格样板，确认后再让其余页面复用同一套样式变量，避免三页风格各走各的。

五、阶段三：分页面实现与联调

有了需求和接口约定，实现阶段反而变得机械。推荐的做法是逐页生成、逐页验证，而不是一次性让模型吐出全部代码。

词书选择页：读取本地词库目录，列出可选词书，点击后携带参数跳转。这一页的重点是数据读取的健壮性——文件不存在、格式异常时要有兜底提示。

进度选择页：根据传入的词书信息，读取本地保存的进度记录，展示“继续上次”和“重新开始”两个选项。这里的关键是进度数据的容错，例如记录的索引超出当前词书范围时的处理。

游戏页面：核心逻辑集中在三件事上——卡片池的初始化与洗牌、点击匹配的判定、消除后的下落与补充。下落补充的逻辑可以用一个简化的网格模型来描述：

// 伪代码示意
function refill(grid) {
  for (let col = 0; col < grid.cols; col++) {
    // 将现有卡片下落到底部
    compactColumn(grid, col);
    // 从顶部补充新卡片
    fillTop(grid, col);
  }
}

三页联调：这是最容易暴露问题的地方。常见问题包括参数命名不一致、数据结构层级不同、跳转时漏传字段、返回上一页时状态未重置。逐一核对接口约定，基本都能定位。风格一致性则通过统一样式变量来收敛，必要时让模型统一替换颜色、圆角、字号等值。

六、写在最后：靠谱与否，取决于怎么用

回到最初的问题：不会编程，直接用 AI 写代码靠谱吗？

结论是：对于功能边界清晰、规模可控的小项目，是靠谱的；但前提是使用者能承担“架构师”和“产品经理”的角色。

AI 在这个过程中的价值，是把“想清楚”之后的部分快速落地，省去大量查文档、调样式、写重复逻辑的时间。但它无法替代的，是需求判断、结构设计和质量把关。

几条可以直接复用的经验：

• 需求阶段多踩刹车，明确要求它先不写代码；
• 接口约定先行，页面越多越要统一数据结构；
• 逐页生成、逐页验证，不要一次性要全部代码；
• 风格用变量统一，避免多页各写各的；
• 保留人工审查环节，尤其是边界条件和异常处理。

把这几点做到位，AI 编程就不是“碰运气”，而是一种可以稳定复用的开发方式。