ARTICLE · 1078247
零基础用 AI 做一个 App:成品像不像你想的,取决于这五步
"脑子里想的是一个样子，AI 最后交给我的，是另外一个样子。"
这句话几乎是每个刚上手 AI 编程的人都会撞上的一堵墙。工具明明越来越强，为什么做出来的东西还是不像自己想要的？
最近我完整跑了一遍：从一个模糊的想法，到一款能打开、能导入文件、能真正用起来的笔记 App，全程没写一行代码。跑完之后，我最大的收获不是"AI 能做 App"——这个已经不算新闻了，而是我大概弄明白了那堵墙在哪，以及怎么绕过去。
这篇就把整个过程写下来。我尽量说大白话，并把每个节点的提问原话都给你，你换个工具也能照着走。
◆ 一、为什么"做出来不是我想的样子"
先承认一件事：门槛确实已经低到任何人身上了。就拿今天的 AI 工具来说，我们任何人都能实现一个简单项目。
但门槛低，不等于结果可控。
偏差是怎么产生的？我拿自己的经历说。我说"我想做一个笔记软件"，这句话在我脑子里其实是一团模糊的雾——我知道要能记东西，但记成什么样、核心场景是手机速记还是桌面长文、基本形态是列表还是卡片，我全都没想。
而 AI 不会等你把这些想清楚。它会用自己的默认值，把这团雾补成一份完整方案交给你。它不会先问你"你的核心使用场景是什么"，它会直接选一个市面上最常见的笔记软件形态，做完，然后笑着告诉你"已完成"。
所以偏差不是 AI 不听话，也不是它能力不行。偏差是因为，这一路上的决策权，在你自己没察觉的时候，全都交出去了。
那对零基础、没经验的我们来说，就真没办法了吗？有的。这篇文章要讲的五步，本质上就是五个"把决策权收回来"的时机。你不需要懂代码，你只需要在正确的时间，说一句正确的话。
◆ 二、开工前：先把工具选对，但别在这一步卡太久
动手之前，得先有工具。
如果条件允许，用 Codex 和 Claude 会相对好一些，这两个既有桌面端，也有 CLI。如果朋友们用这两个有卡点——网络、付费、账号这些都算——那智谱的 Zcode、阿里的 Qoder、Kimi Code 也完全能用，都非常不错。
我要特别说一句：这几款工具的原理都是一样的，都是把大模型接上一个能读写文件、能跑命令的工作环境，所以朋友们不必担心选错就学不会。
我下面演示用的是 Codex，但我会尽可能避开它独有的功能。也就是说，你手上是别的工具，这套流程照样能跟着走。
◆ 三、第一步 环境搭建：只做两件事，但这两件事最不能省
选好工具之后是搭环境。听着吓人，其实只有两件事：一个 git 仓库，一份项目规则文件。
先创建项目存储目录
第一步，先建一个专门的项目目录，用来存放我们开发过程中生成的所有文档和代码。
建之前可以先想一个名字。名字统一，后续管理起来会省很多事。我这里把它叫作 Forma 笔记，朋友们按自己的需求起就好。
熟悉一下界面，然后建项目
以 Codex 桌面端为例，界面分三栏：左侧是项目和会话管理，中间是对话与工作区，右侧是动态区域，主要用来预览文件树和产物。
这三栏只要知道各自管什么就够了，不用记菜单。新建项目的操作也不复杂：把模式切到 Codex 模式 → 创建新对话 → 在新对话里选择项目 → 新建项目 → 填项目名称 → 添加文件夹时选中刚才创建的那个目录 → 创建 → 点击 Trust。
最关键的一步：把项目初始化为 git 仓库
项目建好之后，接下来是最关键的一步——把项目初始化为 git 仓库。
操作上极其简单，我们只需要给 AI 说一句话：
请把这个项目文件夹初始化为 git 仓库它就会告诉你已经成功。
这里得停一下，说说 git 是什么，很多朋友对它不熟。git 就是一个版本管理工具：我们的项目每往前推进一步，就可以让它提交一次，把新的改动存成一个新的版本。
好处很实在。如果哪一次修改错了，或者 AI 把原本能跑的功能改坏了，你可以通过 git 一键回退到任何一个正确的版本状态。所以建议朋友们养成一个好习惯：每次项目开发前，都先把仓库初始化为 git。
和 git 强关联的还有一个东西，叫 GitHub。简单理解，它相当于 git 的云端。我们可以把本地仓库脱敏后一键 push 上去。这样即便本地的代码仓库完全丢了，也能从 GitHub 把仓库重新拉下来。
验证方式也很简单：打开终端，进入 Forma 笔记这个文件夹，执行：
git status看到正常的输出，就说明初始化成功了，代码从此进入 git 的版本管理。
再建一份 AGENT.md：给 AI 立规矩
git 有了，接下来第二件事：创建项目规则文件。
我们到 Codex 这里，给它说：
请帮我按照规范创建一个 AGENT.md 文件，并把下面这句话追加进去："仓库每改动一次，都需要创建对应的 git commit 提交，便于后续追踪回滚"这个文件相当于一份项目规则。我们有什么要求是它开发过程中必须遵守的，就追加到这个文档里。以后在这个项目里，即使是新开一个对话，它也会先读取这份规则文档，然后照着执行。
我这句话的意思就是：以后只要做一次代码修改，就提交一次 git 版本。当然 AGENT.md 能写的远不止这一条，它有自己的一套规范写法，我们把这句话追加进去就够了。
创建好之后，到项目文件夹根目录就能看到这个文档。
环境搭建的收尾
到这里，环境搭建就完成了。说是搭建环境，其实就是两件事：仓库初始化为 git，创建 AGENT.md 规则文件。
另外提一句，如果你之前没做过开发，电脑里可能还没装 git，那需要先装一下。
环境是地基的问题，看起来慢，其实这一步是最省时间的——后面每一次"改坏了能退回去""新开对话它还守规矩"，都是从这里来的。
◆ 四、第二步 产品设计：先脑暴，再逼 AI 自曝缺陷
环境好了，可以进入开发。但等一下——我们现在只知道"要做一款笔记软件"，具体做出来长什么样，其实心里还不知道。这种情况下，我不会直接让它写代码，而是先和 AI 做一次脑暴。
我给它的提示词是这样的：
我想做一个笔记软件，先做 MVP（最小可用版），你认为哪些功能是必须要做的，哪些功能可以延迟做？请你全网调研笔记软件，给我输出一版可行方案。等它执行结束，方案就出来了。这次调研它一共看了 11 个产品（这是它当次会话自己报告的调研范围），输出了一份功能清单。
你要逐条看，然后拍板
这一步最容易被跳过，但它是整篇里最重要的一句提醒：方案出来之后，你要仔细看一遍，看它是不是和你脑子里那个雏形一致。不一致，就告诉它改。
我当时的例子很典型。它在方案里把"标签""同类笔记关联推荐"放进了"延迟功能"，可这两样正是我想要的。于是我直接说：
MVP 版本中我希望加入标签、同类笔记关联推荐的功能。它改完，你可以留意一下仓库——每发生一次改变就多一次提交，下方那串字符就是这一版的版本识别码。回头想看看"我什么时候改的主意、改之前长什么样"，翻提交记录就行。
从它的方案能看出来，一款笔记软件该有的功能其实都已经具备了。因为我们这次是做最小可用版本的方向验证，所以不用追求功能多。
更关键的一问：逼它自己说缺陷
方案看着挺好，但这时候先不要着急让它开发。
我当时看到方案里完全没有提到 UI，觉得不稳妥，于是又问了一句我认为非常有价值的话：
方案我已经查阅，我没有看到 UI 视觉方面的内容。你认为除了 UI 视觉方面的缺失外，还有什么设计上的缺陷或者不足吗？它的回答让我有点意外：它承认了，而且一口气指出好几个缺陷——比如核心使用场景仍然太宽、笔记的基本形态没有确定等等。
你看，这些缺陷原本就藏在它的方案里，只是它不会主动说。你追问，它才说；你说"可以了"，它就带着这些洞往下走。它修改之后，产品明显更紧凑了。于是我们按它的下一步建议继续推进。
Demo 是用来验视觉的，不是成品
接着它直接把 demo 做出来了。朋友们要注意：这个 demo 本质是一个可以交互的 HTML 页面，作用只是让我们看视觉效果和布局，不是成品。
我看下来，作为 demo 是满意的，但有两个问题：一是不喜欢它的颜色搭配，二是原型里没办法粘贴图片。于是我把问题写清楚，让它改：
原型已经体验结束，我发现的问题：1. 颜色我不建议采用深绿色作为强调色，我们的视觉固定为采用白色和灰色为主色调。2. 笔记中无法插入图片，图片需要通过剪切板粘贴或者用户选择插入。其他方面验证通过。它改完之后，我重新测了颜色，也测了插入图片，都正常了。
产品设计文档：这是后面所有工作的底稿
到这一步本该单独去做产品设计文档，但现在这类工具已经比较智能了——它在前面已经顺手帮我把文档同步写好了，就在项目的 docs 目录里。
如果你用的是别的工具，记得检查一下项目目录里有没有 docs 文件夹，如果还没有产品设计文档，就让它根据你们的对话生成一份。
这份文档是后续开发和功能迭代的底稿。以后无论是做技术方案，还是让别的 AI 工具接力开发，都有统一的依据。说简单点：它把 MVP 的边界定死了。
◆ 五、第三步 技术设计：方向错了，返工代价最大
产品设计回答的是"做什么、不做什么"，技术设计回答的是"怎么实现"——尤其是技术栈和架构。
这一步在零基础的朋友那里最容易被砍掉，理由是"我又不懂技术，让 AI 决定就好"。但它的特点是：产品设计错了，改的是需求文档；技术设计错了，改的是整个项目结构。
所以我建议的姿势不是"我来定技术细节"，而是"我来确认方向"。你要看的不是它选了哪个库，而是它给的整体方案是否符合你的要求——比如它是一个纯本地应用还是需要服务器、数据存在哪里、以后想加个手机端会不会推翻重来。
确认方向没问题，再进入实现。方向有问题，这时候改的成本最低。
◆ 六、第四步 产品实现：让 AI 自己写、自己测
配色验证通过、图片粘贴和插入验证通过之后，我正式让它进入开发阶段。
这一轮的做法值得说一下。我没有一步一步盯着它，而是让它把接下来的计划做成一个完整的目标，以目标模式执行——这样中途我就不用再参与，它会自己写代码、自己测试，直到开发完成。
这里是它最需要能力的地方，也正好是 AGENT.md 发挥作用的地方。
关于测试，有一条规则一定要提前写进去
我在 AGENT.md 里写的第二条是：每次改动后都必须编写或更新相关的测试，并在交付给用户前，确保所有测试和验证全部通过。
它后来交付的时候，不仅把产品做完了，各种自测也一起做了。这说明规则是有效的，你写进去，它就会照做。
说句实话：我跑到一半，额度用光了，只能先停在这里。等额度重置之后我继续把它跑完。这也算整个过程里的一个真实提醒：用这类工具要留意额度，长任务的消耗并不小。
但自测不等于没问题
它们做的这些测试，能尽可能提高代码的可靠性，帮 AI 提前发现一些明显的问题。但并不能保证最终交付出来的产品就一定没有 bug。
真正用起来怎么样，还是得我们自己亲自验证之后才知道。
◆ 七、第五步 人工验证：报错那一刻，才是真正的开始
所以接下来我实际跑了一遍。
它最后提到执行 npm start就可以启动。我一跑，上来就报了一个错。
你看，AI 确实不是百分之百靠谱的，即使它自己能验证，也未必完全可靠。
我们让 AI 修一下。把报错原文原样丢给它：
打开之后直接显示了一个报错：操作失败，请稍后重试。它把错误修好之后，我再跑一次——错误消失了。然后我导入一本 TXT 文件试了试，看起来是可以用的。
到这里，这个产品的 MVP 才算彻底做完。
◆ 八、这套流程不是死的：按需求决定你参与多深
回头看一下整个过程，一共是五步：
- 环境搭建
：初始化 git 版本控制、写一份基本的 AGENTS.md； - 产品设计
：明确要做什么、不做什么，跟 AI 探讨方案，必要时出一份 demo； - 技术设计
：确定技术方案，尤其是技术栈和架构，确保整体方向没问题； - 产品实现
：让 AI 写代码，同时给它自测的能力，让它写完自己测、把明显问题先修掉； - 人工验证
：我们亲自上手体验，发现问题就让 AI 改，直到完全符合预期。
这五步里，只有第一步环境搭建是一次性的，后面四步其实是我们开发每一个新功能时的标准流程。
比如你后续想给阅读器加一个全文搜索：同样先做产品设计，确定搜索入口放在哪里、结果怎么展示；再出技术方案，确定文本怎么索引、搜索怎么实现；接着让 AI 开发并自测；最后我们亲自验证一遍。一模一样。
但这五步不必每条都走满
这里要说明一个取舍。这几个步骤并不是死板的流程，具体做到什么程度，取决于你想对最终结果保留多少掌控力。
如果你并不在意产品具体怎么设计，只要功能能用就行，那产品设计这一步完全可以交给 AI； 如果你也不关心代码怎么实现，技术方案同样可以让 AI 自己决定。
这么做并没有什么太大问题，只是意味着你把更多的决策权交给了 AI，你对最终结果的掌控自然就少一些，做出来的东西可能也就没那么贴合你的预期。
所以这里面就是一种取舍：
- 你参与得越多
，对最终结果的把控越强，但需要投入的时间和精力也越多； - 你参与得越少
，开发过程更省事更快，但最终结果和你预期之间出现偏差的可能性也越高。
这个度没有特别固定的标准。我一般会根据需求的复杂度和重要性来判断。两种情况最典型：
- 简单且不重要的需求
：我一般会跳过产品设计和技术设计这两个环节，搭好环境、发出指令，直接让 AI 实现，实现完我做一次验证就结束，整个流程非常快； - 复杂且重要的需求
：我会参与产品设计和技术设计，走完整整五个环节，尽可能保证最终产品的质量。
说到底，就是在开发效率和结果的可控性之间做取舍。
◆ 九、无论怎么省，这三件事不能省
流程可以灵活调整，但有三条原则，我建议大家尽量坚持。
第一，必须有版本管理工具。
用最流行的 git 就可以。AI 写代码不可能每次都完全正确，有时候甚至会在修改的过程中，把原本能够正常运行的功能改坏。用了 git，我们每完成一个功能都可以保存一个对应的版本，后面一旦出了问题，就能很方便地恢复到之前正常的状态。另外如果条件允许，我也建议把代码同步到 GitHub 类的远端仓库，这样即使本地代码不小心丢了，也能从远端恢复。
第二，必须给 AI 自测的能力。
很多人只让 AI 写代码，却不给它验证的环境，结果自己就沦为了测试员，来回帮 AI 找 bug，极其浪费时间。我们应该把相关的工具和插件开放给 AI，让它自己写完、自己测，这样交付出来的代码质量会高很多。
第三，必须做人工验证。
AI 自测再充分，也不可能把所有问题都覆盖到——像交互体验，或者一些不容易想到的边界情况，就很容易被漏掉。所以产品到底好不好用、是不是你真正想要的，最终还是要自己试一遍才知道。
总结一下：真正不能省的，就是这三件事——用 git 搭建好环境，让 AI 具备自测能力，最后还一定要人工验证。至于产品设计和技术设计要做得有多细，大家看情况决定就好。
◆ 写在最后
最后我想说，这套流程只是我现阶段探索出来的比较合理的方法，但并不是唯一的标准答案。随着大模型能力的不断进化，AI 编程的模式肯定还会发生变化，我也会持续去尝试其他可行的方案。
如果让我只留一句话给零基础的朋友，那大概是：AI 编程真正的分水岭，不在"它能不能生成代码"，而在"你有没有在关键节点，把自己的判断插进去"。
那三句提问——"MVP 里哪些必须做、哪些可以延迟""除了 UI，还有什么设计缺陷""原型的问题我列在这里"——它们听起来一点都不技术，但它们才是决定成品像不像你想的那个样子的东西。
这是跑出来的成品：
