不会编程用AI写应用靠谱吗

一、问题的提出：不会编程，直接把需求丢给 AI 靠谱吗？

“让 AI 写代码”这件事，过去两年从演示视频走进了日常工具箱。但对没有编程基础的人来说，真正的疑问不是”AI 能不能写出代码”，而是”我能不能把一个真实可用的东西交付出来”。这两者之间存在一道鸿沟：代码片段可以生成，但需求边界、页面联动、数据存储、风格统一、异常处理这些工程性问题，往往在第 3 个小时才开始集中爆发。

本文以一个真实的小型项目为样本，完整复盘一次”零手写代码”的开发过程：为备考 KET 的孩子做一个单词消消乐小游戏，支持选择单词书、保存游戏进度、点击中英文配对消除卡片，并带有”上方卡片下落填补空缺、新卡片从顶部像方块一样掉落”的补充机制。整个项目由非开发者主导，借助具备多模态推理能力的智能编程工具完成，耗时约 3 小时。

结论先放在前面：靠谱，但靠谱的前提不是”AI 强”，而是”人能把需求说清楚、能在正确的节点踩刹车、能设计可验证的验收标准”。 下面按流程逐层拆解。

二、需求建模：把”我想要”翻译成”可开发”

2.1 先切模块，再谈页面

项目初始只有一个模糊想法。有效的做法是先做功能分块，把整体拆成三条主线：

1. 单词书选择页：列出可选词库，展示词条数量与掌握进度，支持进入下一级。
2. 游戏进度页：选择或恢复某一次游戏进度，决定本轮练习的范围。
3. 游戏主页面：卡片配对消除、下落补位、新卡生成、计分与结算。

这种”三页式”划分的价值在于：每一页都有独立的输入、输出与状态，便于逐个对齐、逐个验收，避免一次性把整个应用丢给模型导致上下文失焦。

2.2 数据格式的取舍：先做减法

第一版明确不做后端。这一决策非常关键——一旦引入服务端，就要处理接口设计、鉴权、部署、跨域等一系列与核心玩法无关的问题，对非开发者是巨大的风险敞口。

词库存储方式在讨论中也做了收敛：最初考虑用 PDF 解析，最终改为纯文本格式（每行”英文+分隔符+中文”）。理由是文本格式解析成本低、易人工校对、易版本管理，而 PDF 的版面解析会引入大量不确定性。这是典型的”用工程约束换开发确定性”。

一个示意性的词库格式如下：

apple|苹果
banana|香蕉
library|图书馆
environment|环境

解析逻辑也保持在极简水平：

读取文件 -> 按行切分 -> 按分隔符拆成 (word, meaning) -> 过滤空行与重复项 -> 生成卡片池

2.3 需求文档：让模型先”复述”再”动手”

在进入编码前，要求模型输出一份结构化的需求说明，内容至少覆盖：

• 页面清单与页面间跳转关系；
• 每页的交互元素与状态变化；
• 游戏规则的形式化描述（配对成功/失败的判定、补位规则、结束条件）；
• 数据持久化的字段与时机；
• 视觉风格的关键词约束。

这一步的本质是对齐颗粒度：模型复述得越具体，后续返工越少。经验上，需求文档中每遗漏一个状态分支，编码阶段就可能多出一次整体重构。

2.4 关键技巧：对推理型模型”踩刹车”

推理能力强的模型有一个典型倾向——过于主动，在需求还没讨论完时就开始输出完整代码。这在探索阶段是负资产，因为一旦代码成型，人会不自觉地被现有实现”锚定”，放弃更合理的设计。

有效做法是显式约束节奏，例如在对话中反复声明：

当前阶段只做需求分析与规则确认，不要输出任何代码。
请先用条目化方式复述你理解的功能清单，并列出你认为存在歧义的点。

把”讨论阶段”和”实现阶段”物理隔离开，是本项目效率最高的一个操作习惯。

三、原型输入：多模态识别如何降低表达成本

非开发者最大的障碍往往不是逻辑，而是”说不清界面长什么样”。手绘草图、截图标注、低保真线框都能显著降低沟通成本。

本项目的原型图相当粗糙——手绘的方框、箭头、潦草文字标注。具备多模态推理能力的工具能够从这类草图中提取出：页面分区、控件类型、跳转方向、层级关系。这一点在实际体验中带来的价值远超预期：它把”描述界面”这件事从自然语言的模糊表达，转换为”看图说话”的低成本输入。

但需要注意边界：草图能传达布局意图，却传达不了交互细节。因此原型之后必须补一轮文字说明，明确诸如”点击卡片后是否需要动画””配对失败是否扣分””进度是自动保存还是手动保存”这类问题。

四、逐页实现与联调：工程性问题的集中区

4.1 单页实现：先跑通再美化

建议顺序是：数据结构 → 交互逻辑 → 视觉样式。先让页面”能操作”，再让它”好看”。原因在于样式调整的迭代成本低、可反复微调，而逻辑错误的定位成本高，二者混在一起排查会显著拖慢进度。

以游戏主页面为例，核心状态可以抽象为：

cards: 卡片池（每张卡含 id、文本、类型、位置、状态）
board: 当前可见的卡片矩阵
progress: 已消除数量 / 总数量
combo: 连击或计分状态

配对判定采用”点击两张卡，比对是否为同一词条的中英文”这一最简规则，避免引入拖拽、连线等复杂交互。

4.2 下落与补位：把动画问题转化为数据问题

“上方卡片下落填补空缺、新卡片从顶部掉落”看起来是动画需求，实际上是一个数据结构更新问题。把逻辑拆成三步：

1. 消除后将该位置标记为空；
2. 对每一列自下而上做一次”压实”，把非空卡片下移；
3. 在顶部空位按需生成新卡片。

这样动画只是对状态变化的可视化呈现，逻辑层保持纯粹，便于测试与调试。示意性伪代码如下：

for each column:
    writeIndex = bottom
    for readIndex from bottom to top:
        if cell[readIndex] is not empty:
            cell[writeIndex] = cell[readIndex]
            writeIndex -= 1
    fill remaining top cells with new cards

4.3 进度存取：本地持久化即可满足需求

第一版采用本地存储保存进度，字段包括：当前词库标识、已掌握词条列表、当前轮次、更新时间。写入时机选择”每完成一次配对”与”离开页面”，避免高频写入。

这里要强调一个常见陷阱：非开发者容易把”保存进度”理解为”保存整个界面状态”。正确做法是只保存可重建界面的最小状态，其余由初始化逻辑推导，这样即使后续调整了界面结构，旧存档也不会失效。

4.4 三页联调与风格一致性

三页分别开发完成后，联调阶段的重点不是功能，而是一致性。具体包括：

• 视觉一致性：主色、圆角、阴影、字号层级、间距节奏统一；
• 交互一致性：返回入口位置一致、按钮反馈一致、加载与空状态处理一致；
• 文案一致性：术语统一（如”词库”与”单词书”不要混用）。

实操上，最有效的办法是先抽取一份”设计约定”清单，在联调时逐条比对，而不是凭感觉判断”哪里不太对”。风格关键词（如”小清新””低饱和””大圆角”）应在需求阶段就固定下来，并在每次页面生成时重复引用，防止模型在不同页面间自由发挥。

五、能力边界：哪些环节 AI 仍然帮不上忙

客观评估，这类协作模式的短板集中在三处：

第一，需求表达的完整性依赖人。 模型不会主动追问”孩子误触返回键时进度是否保留”这类问题，遗漏即缺陷。因此验收清单必须由人列出。

第二，验收测试无法外包。 功能是否真的可用，需要人逐条点击验证。建议在开发前就写好验收项，例如”选择词库后进入游戏，卡片数量与词库条目数一致””中途退出再进入，已消除的卡片不再出现”。

第三，复杂度存在明显天花板。 单机、无后端、状态简单的小型应用是舒适区；一旦涉及多用户、实时同步、权限体系、性能优化，非开发者主导的协作模式会迅速失效，因为此时的核心难点已从”写代码”转为”做架构决策”。

六、可复用的协作方法论

把上述经验抽象成一套可迁移的流程：

1. 定边界：明确第一版做什么、明确不做什么（如不做后端）。
2. 切模块：按页面或功能单元拆分，保证每个单元可独立验收。
3. 降格式：选择解析成本最低的数据格式与存储方式。
4. 先对齐：要求模型复述需求并列歧义，讨论阶段禁止输出代码。
5. 控节奏：显式”踩刹车”，把讨论与实现分阶段隔离。
6. 定约定：抽取视觉与交互规范清单，联调时逐条比对。
7. 写验收：开发前完成验收项列表，逐项人工验证。

七、结语

回到最初的问题：不会编程，直接用 AI 写应用靠谱吗？答案是——在边界清晰的小型项目上，靠谱程度远超预期；而决定成败的，是需求工程能力而非编码能力。 三小时做出一个可玩的单词消消乐并非奇迹，它真正验证的是：当人能把”要什么”说清楚、把”不要什么”守住、把”做好了没”验明白，智能编程工具就能把实现成本压到极低。反过来，需求含糊、边界失控、验收缺位时，再强的模型也只会更快地产生返工。