零基础用 AI 做出第一个可用 App|完整教程

适用对象：没有编程基础、希望用 AI 做出一个供自己使用的工具的人。

本教程的边界：介绍一个在本机启动、通过浏览器或桌面窗口使用的应用，而不是直接上架 App Store / Google Play 的原生手机应用。本教程完整覆盖从零开发、测试、版本保存、二次迭代与开源项目改造；不覆盖账号系统、在线部署、多人协作和手机商店发布。

把其中的操作拆成一套可复用的工作流、验收清单和提示词模板。你不需要先学会写代码：你的职责是定义问题、做取舍和验收结果；AI 编程智能体负责实现、运行测试与修复。

一、先理解正确的分工

用 AI 做 App 并不等于“一句话生成一个完美产品”。提高成功率流程是：先把模糊想法变成明确需求，再让 AI 规划与实现；每完成一小段就测试；每个可用版本都保存；最后在现有成果上逐项迭代。

关键原则：不要要求 AI “做一个 XX App”后就等待成品。要让它先提问、复述、写 PRD、列计划、分阶段开发、测试、验收与提交版本。视频真正可复制的价值是这条工作流，而不是某个界面样式。

比如“个人工作与生活管理 App”。你可以原样练习，也可以替换为自己的小工具，例如内容选题库、健身打卡器、阅读笔记、客户跟进表、报价管理器或出海选品记录器。

图：人与 AI 的正确分工

二、开始前的准备

你只需要准备一个固定项目文件夹，以及一个能访问本机文件、执行终端命令和预览网页的 AI 编程智能体。工具不必纠结：只要它能够在项目目录内读写文件、运行项目、检查错误并与你持续对话，就可以使用。

请只把项目目录授权给 AI 访问；不要把密码、私钥、支付信息、完整通讯录或生产环境密钥粘贴给 AI。若应用会记录个人数据，在需求阶段就明确数据放在哪里、如何备份、能否导出。

三、先记住这 8 个要点

1. 先建一个空文件夹，再让 AI 在这个目录里工作。 所有代码、需求文档、测试与版本记录都放在同一个项目目录中。

2. 先聊需求，不要立刻写代码。 说清楚你要做什么、有哪些模块、数据要怎样保存，以及第一版暂时不做什么；不清楚的地方让 AI 一次只问一个问题。

3. 先确认页面和使用流程。 在开发前先看导航、首页、列表、新增、编辑、删除、保存和模块联动是否符合你的习惯。

4. 把已确认的需求整理成 PRD.md。 不要把关键决定只留在聊天记录里；以后换对话、换模型，AI 仍能按这份文档继续开发。

5. 让 AI 根据 PRD 生成开发计划。 你重点检查开发顺序是否合理、是否先做核心功能、每一步是否有验证方式；技术细节主要交给 AI 执行。

6. 开发时必须分阶段测试。 每完成一个阶段就运行测试；遇到错误先修复，不能跳过测试、删除测试或降低标准来宣称完成。

7. 首版完成后亲自使用一遍。 新增、编辑、删除、状态变化、首页联动、刷新后数据是否还在、备份和恢复是否可用，都要按真实场景检查。

8. 先保存稳定版本，再逐项迭代。 用 Git 为可用版本建立快照；一次只改一个问题，测试通过后再提交。功能稳定后，再做界面美化或从开源项目继续改造。

最小闭环：需求对话 → 页面方案 → PRD → 开发计划 → 开发与测试 → 人工验收 → 保存版本 → 单项迭代。

图：从想法到可用版本的 8 步闭环

四、实战：做一个“个人工作与生活管理 App”

第 1 步：建立项目目录并让 AI 进入目录

在桌面或你习惯的位置创建空文件夹，例如 个人工作生活App。然后在 AI 编程智能体中选择“打开文件夹”或“添加工作区”，确认它看到的是这个空目录。

第一次不要急着写代码。先把下面的提示词发给 AI。方括号中的内容必须替换成你自己的答案。

“我想做一个仅供自己使用的本地工作与生活管理 App。

我的使用者：[只写我自己 / 也可能给家人或团队使用]

我的核心目标：[例如，把内容创作、开发项目、客户跟进和生活计划放在同一个工具里]

我希望包含的模块：

1. 今日计划：新增、编辑、完成、查看当天事项。

2. 内容创作：灵感、策划、制作、发布和已发布内容的记录。

3. 开发工作：项目、里程碑、需求、Bug 和技术问题。

4. 客户/咨询：客户资料、沟通记录和待跟进事项。

5. 健身与饮食：计划和完成记录。

6. 设置与数据：备份、导出和恢复。

数据要求：数据必须在本机持久保存；关闭应用、重启电脑或刷新页面后仍可恢复。请设计可备份和可导出的方案。”

第一版暂时不做：登录注册、联网同步、多人协作、支付和复杂权限。

现在不要写任何代码。请先判断你是否完全理解需求：如有不清楚之处，请一次只问我一个最关键的问题；如果已理解，请用自己的话复述需求、列出假设和风险，等待我确认。

这里最重要的不是文案优美，而是包含四类信息：做什么、包含什么、数据怎么保存、不做什么。视频中的 AI 首先追问“数据是放浏览器还是独立保存在电脑中”。这是一个好问题，因为数据存储方式会直接影响后面使用、备份和恢复的设计。

在 AI 提问时，不要只回复“你看着办”。例如它问“数据保存在哪里”，你可以明确回复：

选择独立保存在电脑本地的方案。即使清除浏览器缓存、重启电脑或刷新页面，已有记录也不能丢失；需要支持手动导出备份，并说明恢复方式。

第 2 步：确认页面结构与核心交互

当 AI 已经能正确复述你的需求后，继续发送下面的提示词。此时仍然不写代码。

需求确认后，请先不要开发。请为这个 App 输出一份页面结构与交互设计方案，至少包括：

1. 整体导航结构和每个模块入口；

2. 首页/仪表盘展示哪些最重要的信息；

3. 每个模块的列表页、详情页、新建/编辑动作；

4. 模块之间如何联动；

5. 数据备份、导出和恢复入口；

6. 关键用户流程，例如“新增今日计划—完成计划—在首页看到进度”。

请用清晰的页面树、文字线框说明和流程描述呈现。暂时不要写代码，等待我确认。

方案采用左侧模块导航、中央内容区的经典结构，布局可以根据自己的喜好来，但是必须检查三个问题：第一，常用功能能否在两次点击内到达；第二，新建记录后能否在对应模块和首页看到结果；第三，删除、编辑、保存和导出是否有明确入口。

确认后，把你要修改的地方一次说清楚；例如“今日计划要能按日期查看”“已发布内容需要播放量、点赞和收藏统计”“客户必须能删除”。随后再进入文档阶段。

第 3 步：让 AI 写 PRD，而不是把关键信息留在聊天记录里

PRD（Product Requirements Document，产品需求文档）可以理解成这个 App 的“施工说明书”。特别强调，聊天越来越长、换对话或换模型后，早期信息很容易丢失；将确认过的内容写入项目文件，后续任何 AI 都能继续工作。

请把我们已经确认的全部内容整理成项目根目录中的 PRD.md。它是后续开发的唯一需求依据。

PRD 必须包含：

1. 产品目标、目标用户与典型使用场景；

2. 第一版边界：必须做什么、暂时不做什么；

3. 信息架构与每个页面的用途；

4. 每个模块的核心数据、操作和与其他模块的关系；

5. 本地持久化、备份、导出和恢复要求；

6. 非功能要求：易用性、错误提示、性能和隐私边界；

7. 第一版验收标准，写成可检查的条目；

8. 未确定事项和你的技术假设。

写完后请先展示摘要与文件位置，等待我检查；不要开始开发。

阅读 PRD 时，你不必看懂技术栈或文件结构，但要严格看懂“产品是否是我想要的”。尤其核查每个模块的新增、查看、编辑、删除、状态变化、统计和保存方式。验收标准不要写“界面好用”，而要写成“新增计划后刷新应用，该计划仍存在；标记完成后首页进度随之变化”。

第 4 步：让 AI 根据 PRD 生成开发计划

请只根据当前的 PRD.md，在项目根目录创建 DEVELOPMENT_PLAN.md，列出一份详细、可执行的开发计划。

计划应按阶段拆分，并为每一阶段写明：

- 目标与涉及页面；

- 将创建或修改的核心文件；

- 需要实现的数据模型与交互；

- 自动测试或可验证方式；

- 完成标准、风险和依赖关系。

请优先实现可运行的最小版本，再补模块，最后做数据、错误处理和界面优化。暂时不要开始编码，等待我确认计划。

没有技术背景时，开发计划里有很多术语很正常。你无需逐行理解实现细节，但应检查它是否把核心路径排在前面，并且每一阶段都有“如何验证”。视频的做法很实用：PRD 是给你审的；开发计划主要是给 AI 执行的。

图：PRD、开发计划与验收清单如何接力

五、首版开发：分阶段推进，每一步都要测试和验收

确认计划后，发送下面这段核心提示词。对零基础用户来说，最稳妥的方式不是让 AI 一口气做完全部功能，而是把计划切成能独立验证的小阶段：每完成一段，就先看测试结果并亲自验收，再决定是否继续。

请严格依据 PRD.md 与 DEVELOPMENT_PLAN.md 开始开发。

执行规则如下：

1. 每次只完成一个阶段；完成后暂停，汇报改动、测试结果和人工验收步骤，等待我确认；

2. 每完成一个阶段，都要添加并运行与该阶段相匹配的有效测试；

3. 如果测试失败，先复现、定位根因并修复，再进入下一阶段；

4. 不允许通过删除测试、跳过测试、忽略报错或降低验收标准来宣称完成；

5. 开发结束后，启动应用并按 PRD 的验收标准进行一次端到端自检；

6. 最后输出：运行方式、访问地址或启动文件、测试结果、已实现清单、已知限制和下一步人工验收步骤。

现在只执行第一阶段。完成后请汇报改动、测试结果和人工验收步骤；等待我确认后，再进入下一阶段。

图：一阶段、一测试、一验收

开发完成后，先检查 AI 的最终报告是否回答了以下问题：应用怎么启动？访问地址是什么？测试实际运行了吗？哪些 PRD 条目已实现？有哪些限制？如果它只给出“已完成”，但没有运行方法和验证记录，就要求它补齐。

首版人工验收清单

自动测试不能替代真实使用。视频中做法是亲自点击首页和每个模块，新增样例数据，观察是否联动，然后记录问题。你可直接复制这张清单到项目的 ACCEPTANCE.md。

请把所有问题按“事实—影响—期望”记录，而不是写“感觉不好”。例如：“开发工作页面没有新增 Bug 的入口，导致我不能记录测试发现的问题；希望在项目详情页加入 Bug 和技术问题两个可添加列表。”

六、AI 辅助编码的高频报错与解决方法

当 AI 报错或做出的功能不符合预期时，最容易犯的错误是把一句“报错了，修一下”发给 AI。这样 AI 往往只能猜测，容易顺手改动无关文件，甚至用临时绕过掩盖问题。更可靠的方法是：稳定复现 → 收集证据 → 分类定位 → 最小修复 → 自动测试与人工复测 → 保存版本。

1. 先把“报错证据包”交给 AI

无论是哪一类错误，在让 AI 修改前，尽量提供下面四项信息：发生了什么、如何从零复现、完整报错文本、你希望看到什么结果。不要只截取红色错误的最后一行，也不要把 API 密钥、密码或个人数据一并发出。

应用出现问题。请先不要修改代码，也不要猜测原因。

请按以下顺序诊断：

1. 从项目根目录复现问题；

2. 记录我执行的命令、完整终端输出、浏览器控制台错误和触发步骤；

3. 将问题归类为环境/依赖、启动/端口、页面/功能、数据持久化、配置密钥或改动回归；

4. 说明最可能的根因、受影响文件和最小修复方案；

5. 等我确认方案后再修改。

问题现象：[粘贴现象]

复现步骤：[第 1 步、第 2 步……]

完整错误：[粘贴完整日志；已删除敏感信息]

预期结果：[应该发生什么]

图：先交证据包，再做最小修复

2. 高频报错速查表

npm install 会根据项目中的 package.json 安装依赖；若存在 package-lock.json，它会参与确定已解析的依赖版本。遇到依赖冲突时，先分析版本关系而不是盲目删锁文件或强制安装，通常更容易得到可重复的环境。3 运行 Node 项目时，入口文件和相对路径也依赖当前工作目录解析，因此“先确认自己所在目录”是最基础、却最常被忽略的一步。4

3. 三个最常用的修复提示词

依赖或环境错误。当你遇到安装失败、找不到包或版本冲突时，使用下面这段，而不要要求 AI “把所有依赖升级到最新”。

请处理当前的依赖/环境错误，但不要使用 --force、--legacy-peer-deps、删除锁文件或全量升级作为第一选择。

请先：

1. 输出 Node、npm（或项目实际包管理器）版本；

2. 确认当前目录、package.json、锁文件和安装日志；

3. 找出冲突的直接原因与涉及的包；

4. 给出最小、可逆的修复方案，并说明副作用；

5. 经我确认后再改动；

6. 修复后执行安装、构建、测试和启动验证。

完整日志如下：

[粘贴已脱敏的日志]

功能失效或白屏。核心是要求 AI 先复现和定位，而不是一次修改几十个文件。

点击 \[按钮/页面\] 后出现 \[白屏/无反应/报错\]。请不要立刻重构。

请先复现以下最短路径：

1. [步骤 1]

2. [步骤 2]

3. [步骤 3]

然后检查浏览器 Console、Network、终端日志和相关测试。请输出：根因假设、证据、最小改动文件清单、验证方案。待我确认后仅做最小修复；修复后同时给出自动测试结果和人工复测步骤。

担心改坏现有功能。当 AI 将改动扩大，或新版本不如旧版本时，先把项目拉回安全状态再继续。

最近改动可能破坏了已有功能。请立即停止新增功能，不要继续叠加修改。

请执行只读检查：

1. 显示当前 Git 状态、最近 5 个提交和本次变更摘要；

2. 指出最后一个已人工验收的稳定提交；

3. 比较当前版本与该稳定提交，按功能列出风险；

4. 给出两个方案：A. 回退到稳定版本；B. 保留必要改动并做最小修复。

先等待我选择；未经确认，不要执行回退、重置、删除文件或推送远程仓库。

4. 三条“不要做”的安全规则

第一，不要为了让安装命令“绿了”就默认使用 --force、--legacy-peer-deps 或删除锁文件；这些手段有时可用于临时诊断，但会掩盖真实版本冲突，必须先让 AI 解释原因和后果。第二，不要把 .env、API Key、Cookie、密码、私人数据库或聊天截图原样提交到仓库或粘贴到提示词里；让 AI 使用 .env.example 占位模板即可。第三，不要在没有稳定提交时做大规模重构；先提交一个能用的版本，后续每次修改只处理一个问题。

判断修复是否合格的标准不是“AI 说已经修好”，而是“同一条复现路径无法再触发问题，自动测试与人工复测都通过，并且有可回退的 Git 提交”。

七、先保存首版，再开始二次开发

第二轮修改前必须先保存一个稳定版本。Git 把每次 commit 视为项目在某一刻的快照；即便不联网，本地仓库也能保存这些版本记录。1 这正是视频在大规模二次开发前先引入 Git 的原因：如果新修改破坏了已有功能，可以回到此前可用的版本。

先让 AI 检查 Git，不要自行盲目执行来源不明的安装脚本。

请检查当前系统是否已安装 Git。

如果已安装：告诉我版本号，并继续下一步。

如果未安装：先说明推荐的官方安装方式、将执行的命令及其作用；只有在我确认后再执行安装。

不要修改项目代码。

安装确认后，执行初始化和首版提交：

请在当前项目中初始化本地 Git 仓库，并在提交前完成以下检查：

1. 确认不把密钥、环境变量、数据库备份、大文件依赖目录或个人数据提交进去；必要时创建或更新 .gitignore；

2. 显示将要提交的文件摘要；

3. 创建首次提交，提交信息使用：feat: 完成第一版个人工作生活管理 App；

4. 输出提交编号、当前分支和工作区状态；

5. 不要推送到任何远程仓库，也不要创建公开仓库。

Git 的最低理解成本：把每一次 commit 当作“当前可运行状态的一张快照”。Git 官方文档说明，提交会保存项目在该时刻的状态；这也是它能够支持回看与回退的基础。1

图：稳定快照、单项迭代与安全回退

首版提交后再做迭代。每次只处理一个小问题，能减少变更之间相互干扰。视频中的典型改进包括：给已发布内容加数据统计、补上 Bug 入口、允许删除客户、把健身与饮食改成日历形式、增加手动保存按钮。

请处理 ITERATION_BACKLOG.md 中的第 [编号] 项，除此之外不要顺手重构或修改其他功能。

本项问题：

[事实—影响—期望]

完成要求：

1. 先阅读 PRD、开发计划和当前相关代码，说明影响范围与实现方案；

2. 实现后添加或更新测试，并实际运行；

3. 启动应用，按本项验收步骤验证；

4. 确认没有破坏既有核心流程；

5. 创建一次 Git 提交，提交信息清楚说明该项改动；

6. 输出改动文件、测试结果、人工验收步骤和提交编号。

当 AI 提出要做多项改动时，仍然要求“一项一验收、一项一提交”。这比一次堆十几个需求更容易发现问题，也更容易回退。

八、界面美化：参考风格可以，功能边界必须锁住

视频在功能问题解决后才做视觉优化，并展示了磨砂玻璃、笔记风与新粗野主义等风格。这个顺序是对的：先保证数据和流程可靠，再改变外观。否则你很难判断“好看”背后是否藏着功能退化。

你可以上传喜欢的 App 截图，或直接说明风格。无论哪种方式，都要加入“只改外观、不改功能”的保护条款。

请在不改变现有功能、数据结构、页面信息层级、路由、接口、测试和保存逻辑的前提下，只升级视觉设计。

目标风格：[例如，克制的 macOS 磨砂玻璃；或干净的笔记软件风格；或高对比的新粗野主义]

主题要求：[浅色 / 深色 / 两者都支持]

请先输出一份视觉改造方案，说明：色彩、字体层级、间距、卡片、按钮、图标、动效和深浅色策略。待我确认后再实施。

实施完成后请：

1. 对照改造前后的核心流程进行回归测试；

2. 检查小屏幕下是否可用；

3. 明确确认没有删除或弱化任何原有功能；

4. 创建一个独立的 Git 提交。

若 UI 被改坏，最稳妥的处理不是继续让 AI “再修修”，而是先检查刚刚的提交、回退到稳定版本，再用更小的视觉改动重试。不要在功能问题尚未稳定时混合做大规模重构、数据迁移和样式替换。

九、第二条路线：从开源项目开始改造

如果你不想从空文件夹开始，可以下载一个接近目标的开源项目，然后用同样的工作流改造。视频中演示了在 GitHub 上搜索作者名与项目名、点击 Code → Download ZIP，解压后再交给 AI 启动。

GitHub 官方说明，下载 ZIP 得到的是某个仓库版本的源代码快照，并不包含完整提交历史；若你想保留完整历史或持续同步，才需要使用 git clone。2 对初学者“先下载、运行、改造”的目标来说，ZIP 是低门槛入口。

解压项目并在 AI 中打开该文件夹后，先不要要求“帮我加功能”。先让它阅读说明、安装依赖、运行原项目并建立基线。

这是一个已有项目。请先不要修改功能，按以下顺序完成：

1. 阅读 README、依赖清单、启动脚本和许可证文件；

2. 用简单中文说明它是什么、如何运行、数据存在哪里、主要模块和已知风险；

3. 按项目文档安装依赖并启动；若命令不一致，先解释原因和计划，不要猜测；

4. 在浏览器中确认原项目能正常运行；

5. 记录当前启动方式、测试方式与初始 Git 状态；

6. 为原始可运行状态创建一个本地 Git 提交或标签，以便后续回退。

请不要修改业务功能，完成后等待我给出定制需求。

然后像处理自己首版项目一样，一次只提出一个改造需求。视频示例是增加“阅读”模块，包含读过的书、统计和笔记。你可以使用下面的通用模板。

请为当前项目新增 \[模块名称\] 模块。

用户目标：[用户能用它完成什么]

需要记录的数据：[字段与例子]

核心动作：[新增、编辑、删除、筛选、统计、导出等]

它应出现的位置：[导航、首页卡片、项目详情页等]

与旧数据的关系：[是否独立；是否需要首页统计联动]

验收标准：[至少 3 条可点击、可观察的结果]

请先说明会影响哪些文件、数据迁移是否需要、测试计划是什么；确认后再开发。完成后运行测试、进行人工验收说明，并创建独立 Git 提交。

开源不等于可以忽略规则。改造前请阅读项目许可证；不要把带有私人数据、第三方密钥或商业素材的版本直接公开。

十、遇到问题时，直接使用这些“纠偏提示词”

图：两条起步路线，汇合到同一套完成标准

十一、最终交付前的完成定义

“页面能打开”不等于 App 完成。请在你认为完成前，要求 AI 根据下面的标准做最终检查，并把结果写入 FINAL_CHECK.md。

最后可发送：

请对照 PRD.md、验收清单和当前代码做最终发布前检查，并生成 FINAL_CHECK.md。

报告必须区分：

- 已验证通过；

- 未验证；

- 已知限制；

- 后续建议。

请列出实际运行与测试命令、数据备份验证结果、最近稳定 Git 提交、启动步骤和首次使用说明。不要把“未测试”写成“通过”。

十二、把这套方法记成一句话

你负责定义问题与验收结果；AI 负责实现、测试与修复；每一个可用状态都先保存，再进入下一轮改动。

从视频提炼出的最小闭环是：需求对话 → 页面方案 → PRD → 开发计划 → 分阶段开发与测试 → 人工验收 → Git 保存 → 单项迭代 → 视觉优化 → 再验收。

第一次项目不必追求“做一个大而全的超级 App”。先让自己真正用起来：例如完成“记录一个内容灵感、安排今天任务、查看进度、重启后数据还在”这个闭环。只要这个小闭环可运行、可保存、可迭代，你就已经具备用 AI 开发个人工具的基础能力。