用AI开发App真实流程：从想法到上架，六周实践全记录

记录用AI从想法到上架开发App的完整六周流程，涵盖技术选型、Prompt技巧、高频报错排查与App Store上架避坑，真实还原AI协作边界与实操心得。

很多人问“用AI开发一款app”到底是不是真的可行，我的回答是：可行，而且我最近就用这套流程做出了一款已经上架的小工具App。从想法到提交审核，前后花了六周，自己手写的代码不超过200行，其余大量工作都是在和AI“协作”——让它写初稿、我跑起来看效果、报错丢回去让它修、再让它帮我重构和补注释。这篇文章不打算教你如何从零学编程，而是站在一个已经用AI做完整款产品的从业者角度，把真实的流程、真实的坑，以及AI目前帮不上忙的那些环节，全部摊开讲清楚。

先说结论，给还没动手的人一个预期管理：用AI开发app，最核心的变化不是“不用写代码”，而是“一个人就能扛住从前两三个人才做得完的从设计、开发到上架的全流程”。它适合想快速验证产品想法的人，也适合已经有业务需求但不想在人力上砸太多成本的人。前提是你得知道怎么正确地跟AI描述需求、怎么判断它给出的代码有没有暗坑，以及哪些环节必须靠人工而不是靠AI。这篇文章的主体内容全部围绕这三个前提展开，读完至少能帮你少走两个月的弯路。

1. 先泼一盆冷水：AI开发App的真实边界

1.1 六个月前的预期 vs 实际发生的事

我在决定用AI开发app之前，跟大部分人一样带着两个极端想象：一方面觉得AI是不是已经能“一句话生成整个项目”，另一方面又担心它生成的代码根本不能跑。实际做了之后发现，两种情况都是真的，取决于你把它用在哪个环节。

AI在

生成样板代码、把一个功能模块的初版写出来、把常见报错翻译成人话

这三件事上，效率高得离谱。比如我要做一个带本地存储的待办清单功能，把需求描述清楚丢给它，它能在十秒内给我一段可以直接跑起来的页面代码，包括输入框、列表渲染、增删改操作，甚至帮我加上空状态的提示。这种体力活放在以前至少得折腾一晚上。

但AI在

判断业务逻辑是否完整、理解产品背后的用户场景、把控整体架构，以及做上架前的合规检查

这些事上，几乎等于零。它不知道你的用户会在什么奇怪的操作路径下触发bug，它也没办法替你决定“这个按钮放左边还是右边”，更不会主动提醒你隐私政策里需要包含哪些字段。这些坑我全都踩过：AI帮我生成了一版看起来很完整的功能页面，结果用户真的上手用到第三天，才发现数据同步的逻辑根本不对——因为它只写了本地保存，完全没考虑多设备场景。

所以我的真实体会是：

把AI当成一个“响应极快的初级工程师”，而不是“什么都懂的全栈架构师”

。它适合做执行层的工作，比如按照清晰指令写代码、改样式、补测试；而在决策层、体验层和合规层，人类必须全程在场。

1.2 什么类型的App最适合用AI来做

用AI开发app，不是所有类型都合适。我自己做了分类，按“从易到难”排下来大概是这样的：

App类型 | 典型例子 | AI辅助开发的难度 | 说明 |

工具类 | 计算器、单位换算、时间管理、记账本 | 低 | 逻辑简单，页面结构标准，AI生成的代码质量很高 |

内容展示类 | 资讯列表、图片浏览、查询工具 | 低 | 本质是“请求数据+列表渲染”，AI非常擅长 |

表单+存储类 | 打卡记录、轻量CRM、个人日记 | 中低 | 涉及本地或远端存储，AI能写框架，但数据设计要自己把关 |

社交/实时交互类 | 聊天、即时通讯、多人协作 | 中高 | 需要处理实时连接、消息推送、权限，AI容易漏边界情况 |

游戏/复杂动画类 | 带物理引擎的游戏、画板、AR应用 | 高 | 性能优化和渲染细节必须人肉调，AI生成的代码往往能跑但很卡 |

我在第一版MVP里做的就是一个小工具类app，这是刻意选择的结果。原因是工具类应用的界面不复杂、交互路径很短、几乎没有第三方SDK依赖，适合让AI包揽80%的代码生成工作。如果你一上来就想用AI做一款带实时语音的社交app，建议还是先把这个想法拆小——把最核心的一个功能做成能跑的原型，再逐步扩展，否则AI生成的代码会在复杂依赖中快速失控。

2. 动手之前的技术选型：让AI帮你做决策

2.1 技术栈选择的底层逻辑

很多人在用AI开发app之前，卡死在了第一步：不知道该选原生开发、React Native还是Flutter。我的建议很简单——

先看AI的训练数据里哪种技术的优质样本最多

。这不是开玩笑，这直接决定了你后续跟AI协作的顺畅程度。

目前主流AI对JavaScript/TypeScript生态的熟悉程度是最高的，因为开源社区的海量项目、教程、问答帖都是用JS写的。所以如果你没有特殊理由，选择

React Native（RN）

作为跨平台框架，是跟AI协作时最“顺滑”的一条路。你让它生成一个RN组件，它大概率能给出接近生产质量的代码；但如果你用的是某个小众框架，或者是很新的原生语言特性，AI就很容易给你“一本正经地编一个错误API”，你得反复纠正它，效率会大打折扣。

Flutter的优势是UI渲染性能好、跨端一致性高，AI对Dart语言和Flutter组件的理解也相当不错，只是整体样本量比JS生态少一些，遇到冷门问题时AI给的答案会更“模板化”。原生开发，尤其是Android原生+Kotlin或iOS原生+Swift，AI能处理常见UI，但一旦涉及系统级API、权限适配、厂商碎片化问题，它会频繁翻车，因为这类问题的真实案例很难在公开数据里形成稳定模式。

顺带说一个很多人忽略的点：

AI生成代码的能力，跟你选择的开发环境也有关系

。我最后选的是Expo这套基于RN的托管工作流，理由很实际——它把Xcode、Android Studio的环境配置环节基本抹掉了，我在浏览器里就能预览App效果，手机扫码就能在真机上运行。这对用AI开发app的人来说是巨大的效率提升，因为你不需要处理本地环境配置中90%的报错，这些报错恰恰是AI也帮不上忙的地方（后面我会专门讲环境问题）。

2.2 用AI横向对比不同方案的实操方法

拿“到底选哪个技术栈”这件事来说，我自己做了一个很笨但很有效的方法：把AI当成一个“技术咨询顾问”，让它从多个维度给我做对比。我用的Prompt长这样：

我在开发一个[工具类app]，主要功能是[……]，目标用户是[……]。
请从以下维度对比React Native(搭配Expo)、Flutter和原生开发三种方案：
1. 开发效率（尤其是一个人开发的情况）
2. AI辅助编程的可行性（假设计划大量使用AI生成代码）
3. 上架到App Store和Google Play的难易程度
4. 后期维护成本
5. 对新手友好程度
请用表格形式输出，最后给出你的推荐及理由。

你可能会觉得这个Prompt很简单，但关键在于后续动作。AI给出对比结果之后，我做了三件事：第一，把它的对比结论拆成两个阵营——它说得有道理的地方记录下来；第二，针对我不确定的信息追问“为什么”，比如某个框架在AI辅助编程上有优势，就问它具体是哪些社区资源、哪些常用库支撑了这个优势；第三，把它的推荐结果反过来问一遍——“如果选另一个方案，最大的风险是什么”。这样一轮下来，你对技术栈的判断就不仅仅是“照抄AI的答案”，而是真正理解了各个选项的利弊。

我还想提醒一点：用AI做技术选型时，

不要问“哪个最好”这种开放性问题，而要给它一个具体的评分标准

。AI的输出非常受问题框架的影响，你给它明确的维度、明确的使用场景，它才能给出有参考价值的答案。否则它只会给你一份四平八稳、没有任何有效信息的“官方废话”。

3. 核心实操：用AI从零搭一个App项目

3.1 写Prompt前必须想清楚的四件事

用AI开发app失败的案例，绝大多数不是因为AI不行，是因为

需求描述太模糊

。我见过很多人给AI丢一句“帮我做一个记账app”，然后抱怨AI写的代码不能用——这个抱怨很正常，因为这句话里没有任何一个能落地的信息。

我在实际操作中总结了一个四步需求拆解法，在给AI写第一段Prompt之前，我会先把这四件事想清楚：

第一，这个App解决什么问题？

不要写“记账”，要写“让用户在每天30秒内记录一笔支出，并统计每月分类开销”。问题描述越具体，AI越容易推断出页面结构和数据模型。

第二，最核心的3个功能是什么？

一个MVP级的app，不要超过3个核心功能。比如记账app的三个核心功能就是：快速记账、账单列表、月度统计。次要功能比如“预算提醒”“导出报告”“多币种支持”，第一版全部不做。AI写代码是按指令执行的，你给它10个功能，它要么把每个都写得很浅，要么生成一堆互相冲突的代码。

第三，用户是怎么操作这个App的？

尽量把操作流程描述出来，比如“用户打开App后先看到今天的账单列表，点右下角加号弹出记账输入页，输入金额和分类后保存，返回到列表并看到新记录出现在顶部”。这种流程描述对AI来说就是一份需求文档，它能直接据此生成符合逻辑的页面跳转。

第四，数据从哪里来？

是用户自己输入的本地数据，还是从接口读取的远端数据？如果是接口数据，接口地址和返回格式是什么？AI生成代码时，最怕的就是数据来源不明确，它只能写一半“假代码”。我在早期就吃过这个亏——我跟AI说“显示用户信息”，结果它给整个页面写死了几条假数据，我还得花时间告诉它数据应该从接口来。

想清楚这四件事之后，你给AI的第一条Prompt就应该是这样的：

我要开发一个记账App，面向个人用户，第一版只做三个功能：
1. 快速记账：用户点击加号，进入记账页，填写金额、选择分类（餐饮/交通/购物/其他）、写备注，保存后返回首页。
2. 当日账单列表：首页按时间倒序展示今天的记账记录，每条显示分类图标、备注和金额。
3. 月度统计：在第二个Tab展示本月的总支出，以及按分类统计的占比。
数据用本地存储，不需要登录，不需要后端。
技术栈使用React Native + Expo。
请先帮我创建一个项目结构说明，再生成首页和记账页的完整代码。

这样一段Prompt，AI生成出来的东西基本上就是一个可用的雏形。我管这个叫“把AI当成外包程序员来管理”：你给外包的Brief越清晰，拿回来的成果就越接近预期。

3.2 一次完整的项目生成实录

我把真实做项目的流程拆给你看，这里面有几个关键节点是必须人工介入的。

第一个节点是

创建项目骨架

。这一步我没有让AI生成，而是直接在终端执行了官方命令创建Expo项目，原因很简单——AI生成的项目配置文件往往会过时，用官方脚手架是最稳的。但如果你完全不会命令行操作也没关系，让AI告诉你每一步该输入什么命令，它能把命令列表给你列得清清楚楚。

第二个节点是

生成第一屏代码

。我会把上一节那段“需求描述Prompt”发给AI，让它先给首页，也就是账单列表页的代码。真实代码大概是这个风格：

import React, { useState, useEffect } from 'react';
import { View, Text, FlatList, TouchableOpacity, StyleSheet } from 'react-native';
import AsyncStorage from '@react-native-async-storage/async-storage';

export default function HomeScreen({ navigation }) {
  const [records, setRecords] = useState([]);

  useEffect(() => {
    loadRecords();
  }, []);

  const loadRecords = async () => {
    const data = await AsyncStorage.getItem('records');
    setRecords(data ? JSON.parse(data) : []);
  };

  return (
    <View style={styles.container}>
      <FlatList
        data={records}
        keyExtractor={(item) => item.id}
        renderItem={({ item }) => (
          <View style={styles.item}>
            <Text style={styles.category}>{item.category}</Text>
            <Text style={styles.note}>{item.note}</Text>
            <Text style={styles.amount}>{item.amount}元</Text>
          </View>
        )}
      />
      <TouchableOpacity
        style={styles.addButton}
        onPress={() => navigation.navigate('AddRecord')}
      >
        <Text style={styles.addText}>+</Text>
      </TouchableOpacity>
    </View>
  );
}

注意，这段代码里AI自动用了AsyncStorage做本地存储，这是我事先没指定但完全合理的选择——因为React Native生态里本地存储最通用的方案就是它。AI替你做了技术决策，你需要做的是检查这个决策是否成立。我当时追问了AI一句“AsyncStorage和用SQLite有什么区别，我这个场景选哪个更合适”，它给了详细的对比，结论是轻量数据用AsyncStorage足够，我也就认可了这个选择。

第三个节点是

把AI生成的多屏代码串起来

。AI第一次生成的代码，往往每个页面是独立的，导航配置和页面之间的参数传递会缺失。你需要让它再生成一个导航配置文件，同时把“从首页跳转到记账页，记账页保存数据后回到首页刷新”这个逻辑讲清楚。这里有一个很容易踩的坑：AI第一次写好的保存逻辑可能不会触发首页刷新，因为它的useEffect只在页面挂载时加载了一次数据。解决方法很简单，把“当页面重新获得焦点时重新加载列表”这个需求告诉AI，它会改成用useFocusEffect来实现。

3.3 核心功能迭代的正确姿势

功能迭代是我用AI开发App这六周里最重要的一课，我把它总结成一句话：

一次只让AI做一个改动，做完立即验证，验证通过再进入下一个改动。

这听起来像是废话，但实际操作中极其容易违反。我犯过一次很蠢的错误：在同一个对话里，让AI“顺便把列表加个下拉刷新”、“顺便改一下金额颜色”、“顺便把标题栏去掉”。结果AI一次性改了三处，其中两处没问题，第三处直接把整个页面的布局挤变形了。我花了一个多小时排查，才发现问题是出在一个我原本觉得完全不相关的样式属性上。

正确做法是严格遵循小步迭代：

- 明确本次迭代的唯一目标，比如“给列表加下拉刷新功能”。

- 让AI给出改动方案，注意是“方案”而不是直接“改代码”——这一步能帮你提前发现它准备在哪里动手，比如它会说“需要给FlatList加refreshing和onRefresh属性，并新增一个加载函数”。

- 确认方案没问题，让它输出改动后的完整文件。

- 贴回项目，跑起来验证。

- 出现任何报错或显示异常，把错误信息原样粘贴给AI，让它修正。

- 功能验证通过后，再进入下一个迭代。

可能有读者会问，为什么不直接让AI同时把好几个功能都改了，然后一次性验证？答案在于：AI修改代码时，它只看到你贴给它的上下文，它看不到你项目里的所有文件。一个改动的副作用往往藏在另一个文件里，如果改动太多，报错的时候你根本不知道是哪一处引起的。小步迭代虽然慢一点，但每一步都是可控的，整体效率反而更高。

4. 联调与排查：AI开发中踩坑的典型场景

4.1 三类最高频报错怎么处理

项目跑起来之后，真正消耗时间的是各种报错。我统计了自己这六周遇到的报错，大概能分成三类，每一类的处理思路都不同。

第一类是

编译报错

，比如少了括号、变量没定义、组件没导入。这种报错AI处理得最好，你只需要把终端里的红色错误信息完整复制给它，它基本能一眼看出问题并立刻给你修正后的代码。我的经验是：

不要只贴报错信息，把相关代码文件也一并贴上

，否则AI只能靠猜，可能给你一个“看起来改了但根本没改对”的新代码。

第二类是

运行时错误

，典型的就是“null is not an object”这种。这类错误意味着代码逻辑本身的某个环节没拿到预期数据。处理这类报错时，光贴报错信息远远不够，你要把触发这个报错的操作路径讲清楚——比如“我点击了首页的加号按钮，然后输入金额保存，返回首页时崩溃了”。AI需要知道完整链路才能定位问题。

第三类是最麻烦的

依赖/版本兼容问题

，比如某个第三方库和当前Expo版本不兼容。这类问题AI能给你排查方向，但它无法替你验证，因为它看不到你机器的真实环境。我的处理办法是用“让AI给我两条路”的方法：让它先给出“最可能的原因”，再给出“如果原因不对，我下一步应该检查什么”。这样即便AI没猜中，我也能获得一套自己排查的顺序。

4.2 把AI当成调试搭档的正确用法

很多人用AI调试的方式是无效的，因为他们问了一个AI根本没法回答的问题——“我的代码跑不起来了，为什么？”这跟去医院跟医生说“我不舒服”没区别。我在实际使用中总结了一套高效的debug问答模板：

我在跑React Native + Expo项目时遇到了以下错误：
[粘贴完整错误信息]
这是我的相关代码：
[粘贴相关代码文件]
我做的操作是：[描述操作路径]
请帮我：
1. 指出最可能的问题原因
2. 给出修正后的完整代码
3. 用通俗的语言解释为什么会出现这个错

这个模板有三层用途。第一层让AI定位错误；第二层直接产出可用的修正代码；第三层是我自己给自己留的学习机会——每一次报错，我都会花两分钟读一遍AI的解释。六周下来，虽然我自己还是不太会写代码，但我对React Native的常见错误模式已经有了很强的判断力，后面AI给错答案的时候，我能立刻识别出来。

另外，我强烈建议

给AI开一个专门用于调试的对话窗口

，不要跟功能开发的对话混在一起。原因很实际：调试对话里会粘贴大量报错信息，这些信息会污染AI对项目整体需求的理解。如果你在同一个对话里又聊需求又聊报错，AI很容易顾此失彼，表现在代码上就是“修好了A功能，但把B功能的逻辑改没了”。

4.3 环境问题才是最大的时间杀手

用AI开发app，我最大的一个感悟是：

环境配置的坑，AI几乎帮不上忙，但这类坑又最容易让人劝退

。

举个我亲身经历的例子。我的电脑是Mac，但在某一次更新Expo版本之后，项目突然无法启动，终端报了一个和watchman相关的错误。我把错误丢给AI，它给了我四种解决方案，内容包括安装某个工具、清缓存、重启服务等。我逐一试下来，花了差不多三个小时，最后发现问题是系统升级后目录权限变了。这种问题没有任何通用答案，因为它跟你的操作系统版本、目录结构、甚至安装时机都有关。

所以我的建议是：

在项目开始第一天，就把环境配置的所有步骤写入一个本地文档

。包括你安装了什么、选了什么版本、执行过哪些命令、遇到了什么怪异问题是怎么解决的。这个文档在后期换机器或者重装环境时会救你命。同时，尽量选托管环境来减少环境出错的概率。我用Expo其实就是这个逻辑——它把原生构建环境托管到云端，本地只需要一个Node环境，大幅减少了需要自己排查的环境问题。

在推进项目时，

不要选择“最新版本”的依赖库。

AI训练数据里最常见的是稳定版本，你选最新的，AI给出的兼容方案大概率是错的。我当时把Expo锁定在一个已经发布了半年的稳定版本上，整个开发周期里几乎没有遇到因为版本导致的兼容问题。

5. 上架发布：AI覆盖不到的最后一公里

5.1 上架前必须过的人工审查清单

App做出来只是第一步，真正让很多人卡住的环节是上架。AI在这件事上的帮助非常有限，因为应用商店审核的核心是“你的产品是否合规、是否有足够的功能完整性、是否对用户有价值”，这些本质上都是人的判断。

我上架时踩过最大的一个坑，是App Store审核直接给我发了拒绝通知，理由写的是“Your app has very minimal functionality”。我第一反应是莫名其妙——我明明做了三个功能啊？后来跟做开发的同行聊完才明白，问题出在：我的App只有一个页面、几个按钮，功能虽然够用，但从审核员角度看，它看起来更像一个demo，而不是一个完整产品。

这个案例给我的教训是：

上架前，至少要从用户视角确认三件事。

第一，App是否有一个完整的核心体验闭环——用户打开它，不需要任何说明就知道能干什么、怎么干，一个新手在5分钟内能否完成一次完整操作。第二，是否有足够的“完成度”——包括空状态页面、错误提示、加载动画这些细节，AI生成的代码里通常没有这些，需要单独补。第三，是否有隐私政策和用户协议——这是硬性要求，任何一个上架的App都必须有。

我把上架前的人工检查做成了一个清单，每次准备提审之前都过一遍：

检查项 | 具体内容 | 是否依赖AI |

功能完整性 | 核心流程闭环可达，没有“点了没反应”的死按钮 | 否 |

页面完成度 | 空状态、加载中、网络错误等状态齐全 | 部分，可让AI补代码 |

隐私合规 | 隐私政策链接、权限说明、数据收集声明 | 否，需人工撰写 |

视觉规范 | 图标、启动页、截图尺寸符合商店要求 | 否 |

账号与证书 | 开发者账号、Bundle ID、签名证书有效 | 否 |

元数据 | App名称、副标题、关键词、描述要准确且不违规 | 部分，可让AI帮写文案 |

5.2 证书、签名与审核的那些坑

应用商店上架的整个流程里，最不AI友好的部分是证书签名和账号体系。AI可以帮你生成一堆命令行序列去创建签名证书，但它没法帮你理解Apple Developer网站的各个配置页面，更没法替你处理审核被拒之后的申诉沟通。

这里我特别想提醒没用过iOS开发工具的人：

Apple开发者账号一年的费用是99美元，而且从你注册到通过审核，需要走一套企业认证流程，急不来

。所以如果你准备上架，第一步应该先去把开发者账号注册了，而不是等项目做完了再注册。我身边就有朋友项目都做完了，卡在账号审核上等了两周。

另外，上架之前请一定先用TestFlight做一轮真机测试。我自己在用TestFlight测试时发现了一个极其尴尬的bug：在开发模式下App运行正常，但通过TestFlight安装后，第一次点击存储按钮直接闪退。原因是一个本地存储的初始化时序问题，在开发模式的懒加载机制下不会暴露。这类问题AI完全没有办法帮你发现，只有真实的真机用户测试才能暴露。我后来养成的习惯是：每一次实质功能完成，都立刻打包给好友做真机测试，收集两三个人的使用反馈，再进下一轮迭代。

还有一类高频被拒理由是

权限描述不够具体

。如果你的App用了相册权限，但权限说明只是简单写了“需要使用相册”，审核员大概率会拒。正确做法是让权限说明精确到使用场景，比如“用于选择App内的头像图片”。AI能帮你润色话术，但前提是你得先告诉它你的App到底要这个权限干什么。

6. 实操心得与避坑清单

6.1 给不同阶段入局者的建议

如果想把“用AI开发App”这件事付诸实践，我根据不同基础把读者分成三类，每类的发力点完全不同。

第一类是完全没有任何编程经验的人。我的建议是：

不要从Android Studio或者Xcode开始

，直接用Expo这类托管工作流，配合AI生成代码，按部就班做一款小工具。你要投入的学习时间不是用来学编程，而是用来学“怎么理解AI给你的代码”——包括知道每个文件大概负责什么、改哪个文件会影响哪个页面。这个理解门槛很低，但极其关键。我有朋友就是这么做的，他用三周做出一款自己的记账app，上架后虽然下载量不大，但完整走通了这个流程，收获非常大。

第二类是前端开发者。你会发现自己跟AI协作的效率高得惊人，因为React Native本身就是前端技术栈。你要注意的反而是架构层面的问题：AI生成的代码为了“能跑”，往往会忽略复用性，几个页面里重复的部分它会直接复制粘贴，导致后期改样式时非常痛苦。建议你在功能验收通过之后，专门花一个下午让AI帮忙做代码重构，把重复逻辑抽成公共组件，把业务代码和数据请求分离开。

第三类是后端开发者。你的优势是逻辑思维和数据建模能力强，弱势是对移动端特有的页面生命周期、设备适配、商店审核不熟悉。你最容易犯的错误是过度设计——给一个简单的记笔记App引入了用户系统、服务端同步、加密传输，结果是开发周期被拉长了一倍。我的建议是：第一版能用本地存储就绝不加后端，能让AI生成页面就绝不自己从零写，把精力放在最核心的产品逻辑上。

6.2 我长期在用的几套Prompt模板

这段内容算是整篇博文里最“可以直接抄作业”的部分。我把整个开发周期里反复在用的几套Prompt模板整理成固定格式，每次新建一个功能时稍微修改具体需求就能直接使用。

项目启动模板

：

我要开发一个[App名称]，面向[目标用户]，解决[核心问题]。
第一版只做[3个以内核心功能]，分别描述如下：
1. [功能一]，具体表现是[……]
2. [功能二]，具体表现是[……]
3. [功能三]，具体表现是[……]
技术栈为[React Native + Expo]。
请先给出项目的整体结构说明，包含需要哪些文件、每个文件的职责，然后从第一个功能对应的页面开始，逐屏生成代码。

单功能生成模板

：

请为[某个页面/某个功能]输出完整代码。
需求：[详细描述功能行为和交互细节]
已知条件：[数据来源、已有的其他页面、使用的组件库等]
注意事项：[比如“金额保留两位小数”“列表按时间倒序”等]
输出要求：请返回修改涉及到的完整文件内容，不要省略已有代码。

Bug修复模板

：

我在[操作路径]时遇到了一个问题。
报错信息：
[粘贴报错]
相关代码：
[粘贴文件]
请分析可能的原因，然后给出修复后的完整代码。如果可能的原因有多个，请先给出最可能的一个，并告诉我如果修复后仍然存在问题，下一步应该检查什么。

代码审查模板

：

请以资深移动端开发者的身份，审查我贴出的这段代码：
[粘贴代码]
请从以下几个角度给意见：
1. 是否存在潜在bug或边界情况
2. 是否存在内存泄漏或性能问题
3. 代码风格是否规范
4. 是否遵循了[React Native/Expo]的最佳实践
最后给出修改建议，按优先级排序。

这套模板用下来，最大的价值不是让AI给出标准答案，而是让AI每次给出的信息结构可控。你会发现，当你按这种格式描述需求时，AI返回的代码质量会有非常明显的提升，因为你需要的信息它全都收到了。

最后再分享一个我的个人习惯：每次完成一个功能，我都会让AI生成一份简短的技术说明，记录这个功能的实现方式、涉及的文件、后续如果要修改应该从哪里入手。这份说明在项目中期之后价值巨大——当项目文件越来越多时，你很容易忘记某个功能当初是怎么组织代码的。AI帮你写的技术说明可能不够完美，但作为索引已经足够用了。

我个人在整套流程走完之后最大的体会是：AI不是让你变成“不用懂技术的神”，而是让你可以把精力集中在真正的产品思考上。我在开发的最后两周，几乎不再关心怎么写界面、怎么调样式，而是把大部分时间花在了体验打磨和商店素材的准备上——这才是决定一个App能不能被用户留下来的关键。六周做出一个上架App，放到一年前我自己都不敢相信，但真正做完之后我发现，最难的部分从来不是代码，而是你有没有把需求想清楚、有没有勇气去走一遍那个完整的流程。