AI开发App怎么落地？从需求拆解到测试上架的实用流程

AI开发App并非让模型一次性生成完整产品，而是将AI用于需求梳理、Flutter跨平台选型、分步编码、数据与接口联调、测试及打包准备。本文以运动打卡App为例，说明如何提供技术栈和业务上下文、检查生成结果，并关注数据库权限、版本适配与隐私材料等环节。

这两年，我经手的大小 App 项目不下二十个，从餐饮店的点单小程序，到为硬件团队开发的蓝牙配置工具，再到培训机构使用的打卡应用。2024年之后，我把 AI 编程工具正式纳入日常开发流程。说实话，刚开始我也半信半疑，觉得 AI 写的代码能跑通就不错了。但实际用下来，尤其是在时间紧张、需要快速做出 demo 的场景里，AI 介入前后的差别，基本就是“熬夜三周”和“准点下班”的区别。

这篇内容，我想把“如何用 AI 开发一款 App”这件事从头到尾讲清楚。注意，不是讲某个 AI 工具的按钮怎么点，而是从需求梳理、技术选型、编码、联调、测试，再到最终上架，讲清楚整条链路中 AI 每一步能做什么、不能做什么，以及你该怎么给它下指令。内容适合正在观望 AI 编程的独立开发者，也适合想压缩成本、加快交付的小团队。对照着就能落地，不整虚的。

1. 用AI做App，先搞懂这件事的本质

1.1 AI在整个开发流程里的真实定位

AI 编程这件事，已经被很多文章包装得玄而又玄。实际上，你只需要理解清楚一个事实：

AI不是替你开发一个App，而是帮助你完成App开发中大量“确定性的重复工作”

。市场上有多类AI工具，作用各不相同。

代码补全类工具，如GitHub Copilot、Cursor的自动补全，主要用于你编写代码时提供提示和补全，能明显提升敲键盘的速度，但不具备全局视野。对话式编程类工具，如大家熟知的ChatGPT、Claude，你提供一段需求或报错信息，它就能给出完整代码或解答，适合解决代码片段级的问题。此外，还有文心快码、通义灵码等针对国内场景优化的工具，它们对中文需求的理解和对国产框架的支持更加细致，尤其在提供开发规范建议时，更贴合部分团队的合规要求。

真正让生产力上一个台阶的，是近两年开始普及的

AI Agent

形态。Agent 化工具（比如 Codex、Cline、开源的 Devine，以及各类 IDE 内置的智能体）可以直接读取本地仓库、跨文件搜索、自行修改代码、执行命令、运行测试，然后根据结果继续迭代。你可以把它想象成一个极其聪明但资历尚浅的实习生：它知识面广、搜索能力强、写代码速度快，但对你的业务背景一无所知，需要你把上下文讲清楚。只要交代到位，它就能把工作做得非常出色。

因此，用AI开发App的首要原则是：

AI 是加速器，而不是替代品。

它负责加速完成“知道怎么做”的事情，而你负责判断“做什么、为什么这么做”。后者才是合格开发者的核心价值。

1.2 贯穿全文的案例：运动打卡App

为了不让内容停留在理论层面，我用一个很有代表性的小项目举例：

运动打卡App

。它的功能不需要太多：用户注册并登录后，可以发起一次运动打卡，填写运动类型、时长和距离，还能拍照留档；主页展示打卡记录，并附带简单的统计图表。这个需求的典型之处在于，麻雀虽小，五脏俱全：有前端UI、数据存储、用户系统、图片上传，以及列表和图表展示，几乎涵盖了开发一款App会遇到的所有环节。

目标平台直接定为 Android 和 iOS 双端。这一点不是拍脑袋，而是当前移动端的基本盘：无论从用户覆盖面还是商业化角度来看，只做一个平台，在起步阶段就会丢掉一半潜在用户。因此，跨平台方案基本是必然选择。后文所有代码和配置都会围绕这个案例展开，方便你对照自己的项目举一反三。

1.3 第一场AI作战：需求拆解

很多人的误区是，一上来就让 AI 写代码。实际上，让 AI 参与需求阶段，能帮你少走很多弯路。我习惯先把脑中模糊的想法转换成一份结构化的 PRD（产品需求文档）。

这里给你一份我的提示词模板：

你是一名资深产品经理和独立开发顾问。请基于以下描述，为我的App输出一份精简的PRD：
- 产品名称：运动打卡App（暂定）
- 目标用户：有日常运动习惯、希望记录和激励自己的年轻人
- 核心功能：注册登录、运动打卡（类型/时长/距离/照片）、打卡记录列表、运动统计
- 商业模式：免费使用，后续考虑会员订阅
- 优先级要求：先保证MVP最小可用，暂不做社交和分享
请输出：用户故事、功能模块清单、MVP范围的优先级排序、非功能需求（性能/安全/隐私）

AI会给你一份结构清晰的需求文档。这个步骤的意义在于：

让AI帮你把大脑里零散的想法显性化、条理化

。我实测，AI列出的用户故事比你凭空想的全面得多，比如它会提醒你处理离线状态下的打卡记录缓存、异常运动数据的手动修正等细节。但你要注意，AI列出的功能会非常丰富，你要是全做，MVP将遥遥无期。所以你需要人工裁剪，只保留最核心的路径：注册登录、打卡、列表、统计，其他全部砍掉或延后。

这个环节，我的实操建议是：把 AI 生成的功能清单分为“必须有、可以有、先不做”三档，再结合投入产出比进行二次删减。独立开发最怕功能蔓延，删除功能几乎总是比增加功能更正确。

2. 技术选型：把选择题交给AI，但拍板的人是你

2.1 跨平台框架对比：为什么我选了Flutter

技术选型非常适合先让 AI 整理一轮信息。你只需列出约束条件，让它进行对比并输出结果，效率比自己翻阅文档高很多。下面这个表格是我让 AI 做选型分析后，再结合自身实际经验修订的结论。

对比维度 | Flutter | uni-app | React Native |

开发语言 | Dart | Vue/JS 语法 | JavaScript/TypeScript |

UI一致性 | 自绘引擎，双端一致性强 | 依赖编译转换，接近原生 | 依赖原生组件，存在差异 |

性能表现 | 高，流畅度接近原生 | 中高，复杂动画有损耗 | 中高，交互复杂时有瓶颈 |

原生能力扩展 | 插件丰富，适合定制 | 插件生态偏国内平台 | 社区成熟，生态最全 |

对 AI 编程的友好度 | Dart 语法相对统一，上下文清晰，AI 生成质量高 | 多端编译风格混杂，AI 生成时容易串场 | 状态管理库选择过多，AI 生成的代码风格分散 |

学习曲线 | 中等，需要熟悉 Dart | 较低，会前端就行 | 中等，前端知识复用率高 |

这一轮AI生成的对比表格，帮我们省去了很多翻资料的时间。但最终拍板，还需要结合你自己的实际情况。我选择Flutter有两个原因：一是它自绘UI的特性保证了双端体验高度一致，对独立开发者非常友好，不用分别调整Android和iOS的控件细节；二是从AI编程的角度看，Flutter的Dart语言语法相对克制，代码范式统一。使用同样的提示词时，AI生成的Flutter代码出错的概率明显更低。

2.2 后端与数据库：别一上来就自建服务器

很多刚开始做App的新手，会习惯性地租一台云服务器，安装MySQL，再部署一套后端接口。这个思路本身没错，但成本偏高，运维压力也大。作为一种关注效率和成本的方案，我建议优先考虑后端即服务（BaaS）平台，包括Supabase、Firebase、微信云开发，以及其他国内云服务商提供的云数据库方案。这类平台的优势是开箱即用，用户体系、数据库、对象存储、云函数等功能都由平台管理，免费额度对个人项目来说，完全够支撑初期使用。

而且，这些平台对AI编程极其友好。比如，Supabase底层使用PostgreSQL，AI训练语料中相关模板足够多。你告诉它“为运动打卡设计users表和workouts表，并生成RLS策略”，它给出的DDL和行级安全策略基本可以直接使用，只需要根据业务做小部分调整。云函数也一样，让AI生成一段用于“查询用户近30天打卡统计”的云函数代码，通常会比较简洁可靠。

就我的体验来说，采用BaaS方案配合AI开发，独立开发者一个人完全可以完成过去需要一名后端工程师负责的工作。当然，如果你的App数据极其敏感（比如金融类），或者对高并发的预期非常明确，再考虑自建服务端也不迟。但对于绝大多数MVP阶段的项目来说，BaaS是投入产出比最高的选择。

2.3 成本估算：开发一个App并上架大概要多少钱

这个话题在社区里常年被讨论，恰好可以借助AI辅助算一笔账。以运动打卡App为例，我们将开发方式分成三种情况进行对比。

成本项 | 纯外包 | 模板套壳 | AI辅助自主开发 |

人力成本 | 5万—20万元，取决于功能复杂度 | 模板费用为3000—2万元，基本不具备二次开发能力 | 投入自己的时间：利用一两周的业余时间即可做出MVP |

工具成本 | 基本为0（外包全包） | 模板授权费 | AI编程工具免费版或低配版，或订阅国内工具的月度服务 |

Apple开发者账号 | 费用包含在外包报价中，或自行承担 | 99美元/年 | 99美元/年 |

Google 开发者账号 | 同上 | 一次性 25 美元 | 一次性 25 美元 |

服务器/云服务 | 外包报价包含半年到一年 | 视模板而定 | 从 BaaS 免费额度起步，用量增加后每月几十到几百元 |

软件著作权 | 包含在报价中或登记在公司名下 | 代办费用 500–1500 元 | 可自行申请或委托代办；大多数应用商店需要 |

结论很直观：选择 AI 辅助自主开发，硬性成本主要是开发者账号和云服务费用，

几千元以内基本就能覆盖首期上架的全部费用

，最大的一项投入是你自己的时间。这是过去几年移动开发成本结构变化最大的方面之一。独立开发者其实不必被外包报价吓退，用 AI 补足工程能力上的短板后，剩下的就是产品力和运营问题。

3. 编码实战：AI写代码的正确打开方式

3.1 给AI下达需求的提示词模板

很多人说AI生成的代码不专业。我看了他们与AI的对话记录，基本都是“帮我写一个登录页”。这种指令信息量太低，AI缺少上下文，只能输出一个最普通、最模板化的结果。正确做法是给AI提供完整的约束和上下文。我常用的代码生成提示词模板是这样的：

你是一名有10年经验的Flutter开发工程师。请为运动打卡App编写一个登录页。
技术栈：Flutter 3.x，使用Provider做状态管理，HTTP库使用dio。
页面要求：
- 输入手机号和密码，密码使用 obscured 输入框
- 登录按钮在输入为空时置灰
- 点击登录后显示全屏Loading，调用 /auth/login 接口
- 成功后将 token 存入 shared_preferences，并跳转到主页面
- 失败时用 SnackBar 展示后端返回的 message
- 验证码登录入口放在页面底部
UI风格：页面清爽，主色为蓝色系，适配 iPhone 14 和主流 Android 屏幕
请给出完整代码，并对关键代码添加中文注释。

这条提示词的关键在于，你交代了

技术栈、页面结构、交互逻辑、状态处理和UI风格

在这种输入下，AI生成代码的可用性会大大提升。每次对话前，先花两分钟写好这个模板，效果比跟AI反复沟通十轮要好得多。

3.2 实操：用AI跑通登录页

以登录功能为例，实际操作流程一般如下。第一步，把上面的提示词发给AI，获取一个Dart文件。第二步，将文件放入Flutter项目的lib/pages/login_page.dart中，先静态检查结构。第三步，运行程序查看效果。在没有复杂依赖的情况下，AI生成的代码大概率第一次就能编译通过。如果报错，把报错信息直接发给AI，让它修正。

一个非常关键的经验是：

不要尝试让AI一次性生成整个App。

我见过有人让 AI“写一个完整的运动打卡 App”，结果 AI 生成了一大堆代码，目录结构混乱、依赖繁杂，最后根本无法维护。正确的方式是分模块对话：登录页面单独一个会话，打卡页面单独一个会话，统计图表单独一个会话。每个模块都让 AI“按功能交付”，然后你在本地把各个部分组装起来。AI 在清晰的功能边界内发挥得最好，因此在方法上要顺应它的能力边界。

3.3 多AI协作：让不同的模型互相挑刺

用 AI 开发 App 时，你很容易陷入一种“AI 写的代码我都信”的状态。这里我强烈建议引入

多AI协作

机制。市面上有很多AI模型和工具，它们的能力侧重点不同：有的擅长架构设计，有的代码生成质量更稳定，有的在代码审查方面表现出色。完全可以把它们组合成一条流水线：A模型负责整体架构和需求分析，B模型负责具体功能的代码生成，C模型负责Code Review，专门找出B模型生成代码中的问题。

实际操作中，我一个很常用的做法是：在B模型完成一个模块的编码后，把代码贴给C模型，指令是“请从安全性和边界条件的角度审查这段Flutter代码”。C模型往往能挑出很多被忽略的问题，比如网络异常没有兜底、存在内存泄漏风险、敏感信息被硬编码并存储在本地等。多模型交叉验证的效果，确实比单模型单打独斗强很多，因为不同模型的训练数据和偏好都不一样，它们之间的盲区恰好可以互补。

3.4 调试报错：把日志喂给AI的正确姿势

调试是开发中最耗时的环节，也是AI最能帮你节省时间的环节。但很多人向AI提供报错信息的方式不对，直接把几十行堆栈全部贴进去，容易让AI的分析偏离重点。正确的做法是

先提炼关键信息，再让AI辅助定位。

以一个非常常见的报错为例（使用AI辅助排查时，也经常会遇到类似的依赖解析问题）：

Could not determine the dependencies of task ':app:compileDebugJavaWithJavac'.
> Could not resolve all task dependencies for configuration ':app:debugCompileClasspath'.

处理步骤是：先看报错的第一行和最后一个Cause，确认出错环节；然后截取核心错误段落发给AI，并附上关键上下文信息，比如“Android Gradle Plugin版本是7.4.2，Gradle版本是7.5，最近新增了某SDK依赖”。让AI分析可能的原因，并按概率排序。AI会给出一些方向，比如依赖版本冲突、仓库源找不到、缓存问题等，这些方向往往比你自己盲目搜索快得多。我在实际项目中，靠这种方式解决过好几次让人头大的构建问题，从排查到解决，耗时基本都在半小时以内。

4. 从单机到联调：数据、接口与AI生成的后端

4.1 用AI设计数据库表结构

运动打卡App的数据模型并不复杂，但设计得好不好，会直接影响后续的开发体验。AI在这里可以充当你的数据库设计顾问。我常用的提示词是：

为运动打卡App设计Supabase（PostgreSQL）数据库表结构。
需要支持的场景：
- 用户可以注册、登录、维护个人资料
- 用户每天可以多次打卡，每次记录运动类型、时长（分钟）、距离（公里）、运动照片URL、打卡时间
- 需要查询某用户最近30天的运动总时长和总次数
请设计表、字段类型、索引、外键关系，并给出建表SQL。附上RLS（行级安全策略）建议。

AI给出的表结构通常包含users表、workouts表，以及合理的索引设计。不过在实际使用中，我也提醒你，AI生成的表最后一定要检查两个地方：一是必填字段的默认值，比如照片URL是否为可空字段，打卡数据在同步时是否允许暂时为空；二是RLS策略是否覆盖了所有读写场景。AI对业务的理解只有你交代的那部分，数据边界和异常情况必须由你来把关。

4.2 让AI生成接口文档和Mock数据

前后端联调是另一个重灾区，尤其是后端接口还没就绪时，前端开发很容易被卡住。AI可以帮你快速生成一份接口文档和配套的Mock数据，让前端开发不必再干等。让AI生成接口文档的提示词如下：

为运动打卡App定义REST API接口文档，要求如下：
- 接口列表：注册、登录、创建打卡、获取打卡列表、获取用户统计（按天聚合）
- 使用 JSON 格式：字段统一为大写驼峰命名
- 统一响应体格式为 { code, message, data }
- 需要包含鉴权Header：Authorization: Bearer Token
请输出接口路径、请求方法、请求参数、成功响应示例、失败响应示例

把输出交给AI Mock工具或后端云平台，就能直接生成一套可调用的Mock服务。前端照着文档开发，等真实后端准备好后再进行替换。这个动作能省去大量沟通成本和联调返工时间。

4.3 联调期最常见的三个坑

联调阶段我踩过不少坑，这里直接列出最具共性的三个，提前避开即可。

第一个坑是

字段命名风格不一致

。AI生成接口文档时，默认使用了大驼峰命名，而Supabase这类数据库默认返回的是小写字母加下划线。前端如果不做映射，就会发现获取到的数据全是空值或undefined。解决方式是在设计接口文档和数据库时，一开始就统一约定命名风格，并在AI提示词中明确写出：“请保证所有接口字段与数据库字段保持一致，通过数据库视图直接映射，不额外转换字段名。”

第二个坑是

时间与时区问题

。用户打卡的日期是按用户本地时区计算，还是按服务器时区计算？如果没有提前约定清楚，统计图表中出现“少一天”或“错两天”的数据就很正常。正确做法是，所有接口统一传递时间戳，或使用带时区偏移的 ISO 8601 字符串；前端展示时再转换为本地时区。AI 在生成代码时不太会主动处理时区逻辑，你需要在需求中明确要求，并补充边界情况说明。

第三个坑是

图片上传与鉴权的顺序

。运动打卡要上传照片，很多 App 直接拿 Token 调用云存储接口，容易出现 401 鉴权失败。更稳妥的做法是走“获取上传凭证”的流程：客户端携带 Token 向服务端申请一个短期有效的上传凭证，再使用凭证通过对象存储上传路径完成上传。在接口文档阶段设计好这一步，能为后续联调节省大量时间。

5. 测试、打包与上架：AI覆盖最后20%

5.1 AI生成单元测试与测试用例

上架前的测试环节中，AI的辅助价值相当突出。编写单元测试既耗时，模式化程度也很高，因此很适合交给AI辅助完成。以登录功能为例，AI生成单元测试的提示词如下：

为以下Flutter登录页面写单元测试和Widget测试：
- 核心逻辑：输入框为空时登录按钮置灰；输入非空时点击触发登录；登录接口调用中显示Loading；接口成功保存token并跳转；接口失败展示SnackBar
- 要求使用 mockito 模拟 LoginApi 类
- 请包含成功、失败、输入为空三个场景的测试用例
请输出完整可运行的测试代码。

AI生成的测试代码虽然不够全面，但可以先搭建常规路径的覆盖。人工补充时，重点应放在异常路径和边界条件上，比如弱网超时、接口返回格式异常、重复提交等。我在实际项目中养成的习惯是：先让AI为每个核心模块生成测试骨架，再补充边界用例。半天时间就能让手头模块达到不错的基础覆盖率。

此外，对于产品验收测试，也可以让AI帮你整理一份测试用例清单，列出正常流程、异常流程以及不同机型的适配项。你可以按清单逐条手动执行并勾选，这比盯着页面发呆、临时找灵感高效得多。

5.2 Android打包与iOS配置里的普遍细节

打包配置是整个流程中最琐碎的部分，AI也能帮上忙，但你必须清楚关键点在哪里。如果使用Flutter开发跨平台App，Android端要处理签名、权限声明和版本号管理；iOS端要处理Bundle Identifier、权限用途描述和隐私清单。你提问时，AI可以准确告诉你某项具体配置的写法，但需要提前准备好这些配置项。

以Android为例，运动打卡App需要拍照上传，就要在AndroidManifest中声明相机权限。这里很容易踩坑：Android 12以上的系统，除了运行时权限声明，还需要在manifest中声明相关权限，但不同SDK版本对权限文案的要求不一样。一旦漏掉声明，或者代码中的权限请求与manifest声明不一致，上架后就可能出现闪退问题。我一向建议把这类声明工作交给AI处理，并清楚描述需求。AI能给出准确配置，但你仍要逐条核对，因为漏掉任何一项，都可能在审核阶段或用户的实际使用环境中付出更大代价。

iOS端的隐私描述同样容易出问题，尤其是涉及相册访问时。如果App需要读取相册或保存图片，就必须在Info.plist中配置相应的用途描述文案。如果打算在App内跟踪用户位置以记录运动路线，还需要配置定位权限说明。配置文案要让审核人员和用户都能看明白。AI可以帮你起草，但最终文案仍要人工润色，使其符合产品定位。

5.3 上架审核材料清单与隐私合规

上架并不是代码完成后就结束了。无论是国内应用市场还是海外应用商店，所需材料大同小异，核心包括：

软件著作权证书（国内多数渠道需要）、隐私政策、用户协议、应用截图与预览图、各尺寸的App图标。

隐私政策这类文档，用AI起草效率很高。将你的App收集了哪些数据、用于什么目的、如何存储、是否与第三方分享、用户如何注销账号等关键信息提供给AI，它就能快速生成一份结构完整、符合常见规范的隐私政策。这里给你一个操作提醒：

不要原样照搬 AI 生成的隐私政策。

你应逐条核对其中的内容是否与 App 的实际行为一致，例如“是否使用第三方统计 SDK”“是否收集设备标识”等。如果 AI 写入了你根本没有实施的隐私能力，审核时可能不会发现，但如果被抽查，就会涉及诚信问题；反之，如果漏写了你正在使用的能力，审核则可能直接驳回。

关于用户协议，也可以用 AI 生成框架，再由人工补充退款政策、免责声明、联系方式等细节。账号注销功能在多数应用商店已成为硬性要求。如果你的 App 支持注册登录，就必须提供注销入口并确保流程畅通。

6. 实录：AI开发App时常见的坑与排查方法

6.1 Gradle配置报错的一线排查实录

开发阶段难免会遇到构建问题，几乎每位 Android 开发者都见过类似报错。先说结论，这类问题九成出在

依赖版本冲突或依赖仓库源不全。

遇到这类问题，我推荐按以下五步排查。第一步，确认 Java JDK 版本和 Android Gradle Plugin 版本是否匹配；两者不匹配会引发许多难以解释的编译异常。第二步，检查所有依赖库的主版本是否冲突，尤其是在借助 AI 选择依赖版本时。AI 可能会照搬大型项目中的所有库，导致部分传递依赖版本冲突。第三步，执行一次 Gradle clean 并重新加载项目。第四步，检查 Maven 仓库源是否完整；如果缺少特定仓库源，依赖解析就会失败。第五步，如果以上步骤都无法解决问题，就从版本名中寻找线索，通常是某个库的发布版和快照版混用所致。

用AI排查这个报错时，只需提供报错信息和配置文件中的相关片段，它就会按照前面类似的思路给出优先级建议。相比自己逐条搜索，AI能将半小时的排查时间缩短到五分钟。

6.2 AI生成代码的版本适配问题

AI训练数据的时效性天然存在滞后，你会发现它经常生成旧版本API的代码。例如，Flutter框架升级到3.10之后，旧的初始化流程发生了变化，AI生成的代码可能仍在使用已废弃的API，编译时会直接报错或出现deprecated警告。

应对策略有三个。首先，在提示词中明确写出使用的框架版本，例如“Flutter 3.13，Dart 3.1”，让AI尽量生成适配该版本的代码。其次，遇到编译错误后，将错误信息和版本号一并提供给AI，让它使用当前版本的API重写相关代码。最后，如果经常使用某个框架，建议选择持续更新的AI工具，或设置自定义上下文规则，将项目的语言版本、依赖清单和项目结构作为固定上下文资料，在每次生成代码时提供给AI，以大幅降低版本错配的概率。

6.3 AI设计数据库造成的业务偏差

AI设计数据库时，最典型的失误就是

只生成满足字面需求的结构

，却缺少对业务场景的预判。比如设计打卡表时，你只说“记录运动类型、时长、距离”，AI可能就会设计成每次打卡记录一条数据，完全不会考虑“用户可能需要记录一次跑步中的多个分段配速”这类更细致的业务扩展。这不是AI能力不足，而是它缺乏对实际运动场景的领域理解。

我的建议是，在数据库设计这一步，给它提供更多业务细节。你可以补充：“运动类型包括跑步、骑行、游泳等；跑步需要记录配速数据，骑行需要记录爬升高度，而且用户偶尔会补录前一天的打卡数据。”这样，AI就能把字段设计得更贴近实际需求。数据建模和代码生成不同：代码出错可以马上编译报错，但表结构设计有误，往往要等数据录入后才会发现，返工成本高出很多。因此，这一步值得多花时间，和AI来回推敲几轮。

一篇文章说不完，但这就是我现在的完整工作流

聊到这里，基本把我用AI开发一款App的完整流程都讲出来了。回头看，我从最初把AI当作高级搜索引擎，到现在把它融入需求、编码、测试、上架的每一步，最大的体会是：

AI真正改变的，不是写代码的方式，而是你作为开发者的时间分配结构。

以前我一个人要花一个多月才能做完的 MVP，现在借助 AI，两个周末就能搭出可演示的版本。省下来的时间可以用来跑市场、聊用户，做真正决定产品命运的事。

如果你看完这篇文章后觉得思路通了，我给一个具体的行动建议：不要拿复杂的老项目做试验，而是选一个类似运动打卡、边界清晰的小需求，从写 PRD 开始，全程用 AI 走一遍，包括上架到一个应用商店。完整经历一次，你就能真切感受到 AI 哪一步最能帮你、哪一步最需要你盯着。下次无论是给自己做工具，还是接外包，心里就有底了。