The Real Process of Developing an App with AI: A Full Record of Six Weeks of Practice from Idea to Launch

A record of the complete six-week process of developing an app with AI from idea to launch, covering technology selection, Prompt techniques, troubleshooting high-frequency errors, and avoiding pitfalls in App Store submission, faithfully reproducing the boundaries of AI collaboration and practical insights.

Many people ask whether "developing an app with AI" is really feasible. My answer is: it is feasible, and I recently used this process to build a small utility app that has already been launched. From idea to submission for review, it took six weeks in total, with no more than 200 lines of code written by hand; the rest of the extensive work was all "collaboration" with AI—letting it write the first draft, running it myself to see the results, throwing errors back for it to fix, and then having it help me refactor and add comments. This article does not intend to teach you how to learn programming from scratch, but rather, from the perspective of a practitioner who has already used AI to complete an entire product, to lay out clearly the real process, the real pitfalls, and the parts where AI currently cannot help.

Let me start with the conclusion, to give those who have not yet started some expectation management: when developing an app with AI, the most core change is not "not having to write code," but rather "one person can handle the entire process from design and development to launch that previously required two or three people to complete." It is suitable for people who want to quickly validate product ideas, and also for people who already have business needs but do not want to spend too much on manpower costs. The premise is that you must know how to correctly describe requirements to AI, how to judge whether the code it gives has hidden pitfalls, and which stages must rely on humans rather than AI. The main content of this article is all developed around these three premises; after reading it, it can at least help you avoid two months of detours.

1. First, pour a basin of cold water: the real boundaries of AI app development

1.1 Expectations from six months ago vs. what actually happened

Before deciding to develop an app with AI, like most people, I had two extreme imaginations: on the one hand, I wondered whether AI could already "generate an entire project from one sentence"; on the other hand, I worried that the code it generated could not run at all. After actually doing it, I found that both situations are true, depending on which stage you use it for.

AI is in

generating boilerplate code, writing out the first version of a functional module, and translating common errors into plain language

these three things, the efficiency is absurdly high. For example, if I want to make a to-do list feature with local storage, describe the requirements clearly and throw it to AI, and it can give me a piece of page code that can run directly within ten seconds, including input boxes, list rendering, add/delete/edit operations, and even help me add an empty-state prompt. This kind of grunt work used to take at least a whole night of fiddling.

But AI is in

judging whether the business logic is complete, understanding the user scenarios behind the product, controlling the overall architecture, and doing pre-launch compliance checks

these matters, it is almost equal to zero. It does not know under what strange operation paths your users will trigger bugs, it cannot decide for you "whether this button should go on the left or the right," and it will not proactively remind you which fields need to be included in the privacy policy. I stepped on all these pitfalls: AI helped me generate a feature page that looked very complete, but only on the third day after users actually started using it did I discover that the data synchronization logic was fundamentally wrong—because it only wrote local saving and completely did not consider multi-device scenarios.

So my real experience is:

Treat AI as an "extremely fast-responding junior engineer," not an "all-knowing full-stack architect"

. It is suitable for execution-layer work, such as writing code according to clear instructions, modifying styles, and adding tests; while in the decision-making layer, experience layer, and compliance layer, humans must be present throughout.

1.2 What types of apps are most suitable for building with AI

Developing apps with AI is not suitable for all types. I made my own classification, arranged from "easy to difficult" roughly as follows:

App type | Typical examples | Difficulty of AI-assisted development | Description |

Utility | Calculator, unit conversion, time management, expense tracker | Low | Simple logic, standard page structure, AI-generated code quality is very high |

Content display | News lists, image browsing, query tools | Low | Essentially "request data + list rendering," AI is very good at it |

Form + storage | Check-in records, lightweight CRM, personal diary | Medium-low | Involves local or remote storage; AI can write the framework, but data design must be checked by yourself |

Social/real-time interaction | Chat, instant messaging, multi-person collaboration | Medium-high | Needs to handle real-time connections, message push, permissions; AI easily misses edge cases |

Games/complex animation category | Games with physics engines, drawing boards, AR applications | High | Performance optimization and rendering details must be tuned by hand; AI-generated code often runs but is very laggy |

What I built in the first MVP was a small utility-type app, and this was a deliberate choice. The reason is that utility apps have uncomplicated interfaces, very short interaction paths, and almost no third-party SDK dependencies, making them suitable for letting AI handle 80% of the code generation work. If you want to use AI from the start to build a social app with real-time voice, I suggest first breaking this idea down into smaller pieces—turn one core feature into a working prototype, then gradually expand, otherwise the AI-generated code will quickly spiral out of control amid complex dependencies.

2. Technology selection before getting started: let AI help you make decisions

2.1 The underlying logic of technology stack selection

Many people get stuck at the very first step before using AI to develop an app: they don't know whether to choose native development, React Native, or Flutter. My suggestion is simple—

First look at which technology has the most high-quality samples in AI's training data

. This is not a joke; it directly determines how smoothly you will collaborate with AI afterward.

Currently, mainstream AI is most familiar with the JavaScript/TypeScript ecosystem, because the massive number of open-source community projects, tutorials, and Q&A posts are all written in JS. So if you have no special reason, choosing

React Native（RN）

as a cross-platform framework is the smoothest path when collaborating with AI. If you ask it to generate an RN component, it will most likely give you code close to production quality; but if you use some niche framework, or very new native language features, AI can easily "confidently make up a wrong API," and you have to repeatedly correct it, which greatly reduces efficiency.

Flutter's advantages are good UI rendering performance and high cross-platform consistency. AI's understanding of the Dart language and Flutter components is also quite good, but the overall sample size is smaller than the JS ecosystem, so when encountering obscure problems, AI's answers will be more "template-like." For native development, especially Android native + Kotlin or iOS native + Swift, AI can handle common UI, but once system-level APIs, permission adaptation, or vendor fragmentation issues are involved, it frequently fails, because real cases of such problems are hard to form stable patterns in public data.

By the way, one point many people overlook:

AI's ability to generate code is also related to the development environment you choose

. In the end, I chose Expo, this managed workflow based on RN, for a very practical reason—it basically eliminates the environment configuration steps of Xcode and Android Studio. I can preview the app's effect in the browser, and run it on a real device by scanning a QR code with my phone. For people developing apps with AI, this is a huge efficiency boost, because you don't need to deal with 90% of the errors in local environment configuration, and these errors are exactly where AI can't help either (I will specifically discuss environment issues later).

2.2 A practical method for using AI to compare different solutions side by side

Take the question of "which technology stack to choose." I myself used a very dumb but very effective method: treat AI as a "technical consulting advisor" and have it compare options for me from multiple dimensions. The Prompt I used looked like this:

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

You may think this Prompt is simple, but the key lies in the follow-up actions. After AI gave the comparison results, I did three things: first, I split its comparison conclusions into two camps—recording where it made sense; second, for information I was unsure about, I asked "why," for example, if a framework has an advantage in AI-assisted programming, I asked it specifically which community resources and which commonly used libraries support this advantage; third, I reversed its recommendation and asked again—"if I choose the other option, what is the biggest risk." After one round of this, your judgment about the technology stack is no longer just "copying AI's answer," but truly understanding the pros and cons of each option.

I also want to remind you of one point: when using AI for technology selection,

don't ask open-ended questions like "which is the best," but give it specific scoring criteria

. AI's output is greatly influenced by the framing of the question. Only when you give it clear dimensions and clear usage scenarios can it give answers with reference value. Otherwise it will only give you a bland piece of "official nonsense" with no useful information.

3. Core practice: using AI to build an app project from scratch

3.1 Four things you must think clearly about before writing a Prompt

The vast majority of failed cases of developing apps with AI are not because AI is incapable, but because

the requirement description is too vague

. I have seen many people throw a line at AI like "help me make a bookkeeping app," and then complain that the code AI wrote is unusable—this complaint is very normal, because there is not a single piece of actionable information in that sentence.

In actual practice, I have summarized a four-step requirement decomposition method. Before writing the first Prompt for AI, I first think through these four things clearly:

First, what problem does this App solve?

Do not write "bookkeeping"; write "let users record an expense within 30 seconds every day, and calculate monthly categorized spending." The more specific the problem description, the easier it is for AI to infer the page structure and data model.

Second, what are the 3 most core features?

For an MVP-level app, do not exceed 3 core features. For example, the three core features of a bookkeeping app are: quick bookkeeping, bill list, and monthly statistics. Secondary features such as "budget reminders," "export reports," and "multi-currency support" should all be omitted in the first version. AI writes code by executing instructions. If you give it 10 features, it will either write each one very shallowly or generate a bunch of mutually conflicting code.

Third, how does the user operate this App?

Try to describe the operation flow, for example: "After the user opens the App, they first see today's bill list, tap the plus sign in the lower right corner to pop up the bookkeeping input page, enter the amount and category, save, return to the list, and see the new record appear at the top." This kind of flow description is a requirements document for AI, and it can directly generate logical page navigation based on it.

Fourth, where does the data come from?

Is it local data entered by the user, or remote data read from an API? If it is API data, what are the API address and return format? When AI generates code, what it fears most is unclear data sources; it can only write half of the "fake code." I suffered this loss early on - I told AI to "display user information," and as a result it hardcoded several fake data entries for the entire page, and I still had to spend time telling it that the data should come from an API.

After thinking through these four things clearly, your first Prompt to AI should be like this:

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

With such a Prompt, what AI generates is basically a usable prototype. I call this "managing AI as an outsourced programmer": the clearer the Brief you give the outsourced programmer, the closer the result you get back is to expectations.

3.2 A complete record of one project generation

Let me break down the real project process for you. There are several key nodes in it where manual intervention is necessary.

The first node is

creating the project skeleton

. At this step, I did not let AI generate it. Instead, I directly executed the official command in the terminal to create the Expo project. The reason is simple - AI-generated project configuration files are often outdated, and using the official scaffold is the most stable. But if you do not know command-line operations at all, it does not matter. Let AI tell you what command to enter at each step; it can list the commands for you very clearly.

The second node is

generating the first screen code

. I will send the "requirements description Prompt" from the previous section to AI and let it first provide the code for the home page, that is, the bill list page. The real code is roughly in this style:

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>
  );
}

Note that in this code, AI automatically used AsyncStorage for local storage. This was a choice I had not specified in advance but was completely reasonable - because in the React Native ecosystem, the most common solution for local storage is it. AI made a technical decision for you; what you need to do is check whether this decision holds. At the time, I asked AI one more question: "What is the difference between AsyncStorage and using SQLite, and which is more suitable for my scenario?" It gave a detailed comparison, and the conclusion was that AsyncStorage is sufficient for lightweight data, so I accepted this choice.

The third node is

connecting the multi-screen code generated by AI

. In the code AI generates the first time, each page is often independent, and the navigation configuration and parameter passing between pages will be missing. You need to have it generate a navigation configuration file, and at the same time explain clearly the logic of "jumping from the home page to the bookkeeping page, and after the bookkeeping page saves data, returning to the home page to refresh." There is a pitfall here that is very easy to fall into: the save logic AI writes the first time may not trigger a home page refresh, because its useEffect only loads data once when the page mounts. The solution is simple: tell AI the requirement "reload the list when the page regains focus," and it will change it to use useFocusEffect.

3.3 The correct posture for iterating core features

Feature iteration is the most important lesson I learned in these six weeks of developing an App with AI, and I sum it up in one sentence:

Let the AI make only one change at a time, verify it immediately after it's done, and only move on to the next change after verification passes.

This sounds like stating the obvious, but in actual practice it's extremely easy to violate. I once made a very stupid mistake: in the same conversation, I had the AI "by the way, add pull-to-refresh to the list," "by the way, change the amount color," and "by the way, remove the title bar." As a result, the AI changed three places at once; two of them were fine, but the third directly squashed and distorted the entire page layout. It took me over an hour of troubleshooting to discover that the problem came from a style property I had originally thought was completely unrelated.

The correct approach is to strictly follow small-step iteration:

- Clarify the single goal of this iteration, for example "add pull-to-refresh to the list."

- Have the AI give a change plan, and note that it's a "plan" rather than directly "changing the code"—this step helps you discover in advance where it plans to make changes, for example it will say "need to add refreshing and onRefresh properties to FlatList, and add a new loading function."

- Confirm the plan is fine, and have it output the complete modified file.

- Paste it back into the project and run it to verify.

- If any error or display anomaly appears, paste the error message as-is to the AI and have it fix it.

- After the feature verification passes, then move on to the next iteration.

Some readers may ask, why not just have the AI change several features at once and then verify them all at once? The answer lies in this: when the AI modifies code, it only sees the context you paste to it, and it cannot see all the files in your project. The side effects of one change are often hidden in another file; if there are too many changes, when an error occurs you have no idea which one caused it. Although small-step iteration is a bit slower, every step is controllable, and the overall efficiency is actually higher.

4. Joint debugging and troubleshooting: typical scenarios of pitfalls in AI development

4.1 How to handle the three most frequent types of errors

After the project runs, what really consumes time is all kinds of errors. I counted the errors I encountered in these six weeks, and they can roughly be divided into three categories, each with a different approach to handling.

The first category is

compilation errors

, such as missing parentheses, undefined variables, or components not imported. The AI handles this kind of error best; you only need to copy the red error message from the terminal to it in full, and it can basically spot the problem at a glance and immediately give you the corrected code. My experience is:

Don't just paste the error message; paste the relevant code files as well

, otherwise the AI can only guess and may give you new code that "looks changed but wasn't actually fixed correctly."

The second category is

runtime errors

, typically things like "null is not an object." This kind of error means that some link in the code logic itself did not get the expected data. When handling this kind of error, just pasting the error message is far from enough; you need to clearly explain the operation path that triggered the error—for example, "I clicked the plus button on the home page, then entered an amount and saved it, and it crashed when returning to the home page." The AI needs to know the complete chain to locate the problem.

The third category is the most troublesome:

dependency/version compatibility issues

For example, a certain third-party library is incompatible with the current Expo version. AI can give you a direction for troubleshooting this kind of problem, but it cannot verify it for you, because it cannot see the real environment on your machine. My approach is to use the "have AI give me two paths" method: have it first give the "most likely cause," then give "if the cause is wrong, what I should check next." This way, even if AI does not guess right, I still get a sequence for troubleshooting on my own.

4.2 The correct way to use AI as a debugging partner

Many people use AI for debugging in an ineffective way, because they ask a question that AI simply cannot answer—"My code won't run, why?" This is no different from going to the doctor and saying "I feel unwell." In actual use, I have summarized a highly efficient debug Q&A template:

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

This template has three layers of use. The first layer has AI locate the error; the second layer directly produces usable corrected code; the third layer is a learning opportunity I leave for myself—every time there is an error, I spend two minutes reading AI's explanation. After six weeks, although I still am not very good at writing code myself, I have developed a strong ability to judge common React Native error patterns, and later, when AI gives a wrong answer, I can immediately identify it.

In addition, I strongly recommend

opening a dedicated conversation window for AI specifically for debugging

, and not mixing it with conversations for feature development. The reason is very practical: debugging conversations contain a large amount of pasted error information, and this information pollutes AI's understanding of the project's overall requirements. If you discuss both requirements and errors in the same conversation, AI can easily focus on one and neglect the other, which shows up in the code as "fixing feature A, but changing away the logic of feature B."

4.3 Environment problems are the biggest time killer

Using AI to develop an app, my biggest realization is:

AI can hardly help with the pitfalls of environment configuration, but these pitfalls are also the easiest to make people give up

。

Let me give an example I experienced personally. My computer is a Mac, but after a certain Expo version update, the project suddenly could not start, and the terminal reported an error related to watchman. I threw the error to AI, and it gave me four solutions, including installing a certain tool, clearing the cache, restarting the service, and so on. I tried them one by one, spending almost three hours, and finally found that the problem was that the directory permissions had changed after a system upgrade. This kind of problem has no universal answer, because it is related to your operating system version, directory structure, and even the timing of installation.

So my suggestion is:

On the first day of the project, write all the environment configuration steps into a local document

. This includes what you installed, what version you chose, what commands you executed, and what strange problems you encountered and how they were solved. This document will save your life later when you change machines or reinstall the environment. At the same time, try to choose a hosted environment to reduce the probability of environment errors. The reason I use Expo is actually this logic—it hosts the native build environment in the cloud, and locally you only need a Node environment, greatly reducing the environment problems you need to troubleshoot yourself.

When advancing the project,

do not choose the "latest version" of dependency libraries.

The most common versions in AI training data are stable versions. If you choose the latest one, the compatibility solutions AI gives are most likely wrong. At the time, I locked Expo to a stable version that had already been released for half a year, and throughout the entire development cycle I almost never encountered compatibility problems caused by versions.

5. Publishing and release: the last mile that AI cannot cover

5.1 The manual review checklist that must be passed before release

Building the app is only the first step. The stage that really gets many people stuck is release. AI's help with this matter is very limited, because the core of app store review is "whether your product is compliant, whether it has sufficient functional completeness, and whether it is valuable to users." These are essentially human judgments.

The biggest pitfall I stepped into when releasing was that App Store review directly sent me a rejection notice, with the reason written as "Your app has very minimal functionality." My first reaction was that it made no sense—I had clearly built three features, right? Later, after talking with a peer who does development, I understood that the problem was: my app had only one page and a few buttons. Although the functionality was sufficient for use, from the reviewer's perspective it looked more like a demo than a complete product.

The lesson this case taught me is:

Before release, at least confirm three things from the user's perspective.

First, whether the app has a complete core experience loop—when users open it, they know what it can do and how to do it without any explanation, and whether a beginner can complete a full operation within 5 minutes. Second, whether there is sufficient "completeness"—including details such as empty state pages, error prompts, and loading animations. AI-generated code usually does not have these, and they need to be added separately. Third, whether there is a privacy policy and user agreement—this is a hard requirement, and any app that is released must have them.

I turned the manual checks before release into a checklist, and I go through it every time before preparing to submit for review:

Check item | Specific content | Whether it depends on AI |

Functional completeness | The core process is closed-loop and reachable, with no dead buttons that "do nothing when clicked" | No |

Page completeness | States such as empty state, loading, and network error are all complete | Partially, AI can be asked to supplement the code |

Privacy compliance | Privacy policy link, permission descriptions, data collection statement | No, it needs to be written manually |

Visual specifications | Icons, launch screen, and screenshot sizes meet store requirements | No |

Account and certificate | Developer account, Bundle ID, and signing certificate are valid | No |

Metadata | App name, subtitle, keywords, and description must be accurate and not violate the rules | Partially, AI can be asked to help write the copy |

5.2 The pitfalls of certificates, signing, and review

In the entire app store release process, the least AI-friendly part is certificate signing and the account system. AI can help you generate a bunch of command-line sequences to create signing certificates, but it cannot help you understand the various configuration pages on the Apple Developer website, let alone handle the appeal communication after a review rejection for you.

Here I especially want to remind people who have never used iOS development tools:

An Apple developer account costs 99 USD per year, and from registration to approval, you need to go through a corporate verification process, so you cannot rush it

. So if you are preparing to release, the first step should be to register the developer account, not wait until the project is finished to register. I have a friend around me whose project was already done, but got stuck waiting for two weeks on account review.

In addition, before releasing, be sure to first use TestFlight for a round of real-device testing. When I was testing with TestFlight myself, I found an extremely awkward bug: in development mode the App ran normally, but after installing through TestFlight, the first tap on the save button crashed directly. The reason was an initialization timing issue with local storage, which would not be exposed under the lazy-loading mechanism in development mode. AI has no way at all to help you discover this kind of problem; only real real-device user testing can expose it. The habit I later developed is: every time a substantial feature is completed, immediately package it and give it to friends for real-device testing, collect usage feedback from two or three people, and then move on to the next round of iteration.

There is also another type of high-frequency rejection reason:

permission descriptions are not specific enough

. If your App uses photo album permission, but the permission explanation simply says "needs to use the photo album," the reviewer will most likely reject it. The correct approach is to make the permission explanation precise to the usage scenario, for example, "used to select an avatar image within the App." AI can help you polish the wording, but the premise is that you must first tell it what your App actually needs this permission for.

6. Practical experience and pitfall-avoidance checklist

6.1 Advice for entrants at different stages

If you want to put "developing an App with AI" into practice, I divide readers into three categories based on different foundations, and the focus of each category is completely different.

The first category is people with no programming experience at all. My advice is:

do not start from Android Studio or Xcode

, directly use a managed workflow like Expo, work with AI-generated code, and build a small tool step by step. The learning time you need to invest is not for learning programming, but for learning "how to understand the code AI gives you"—including knowing roughly what each file is responsible for and which file to change to affect which page. This threshold of understanding is very low, but extremely critical. I have a friend who did exactly this. He spent three weeks making his own accounting app. Although the download count after release was not large, he fully went through the process and gained a great deal.

The second category is front-end developers. You will find that your efficiency in collaborating with AI is astonishingly high, because React Native itself is a front-end tech stack. What you need to pay attention to instead are architectural issues: in order to "run," AI-generated code often ignores reusability. It will directly copy and paste repeated parts across several pages, making it very painful to change styles later. I suggest that after functional acceptance passes, you spend a dedicated afternoon having AI help with code refactoring, extracting repeated logic into shared components and separating business code from data requests.

The third category is backend developers. Your advantage is strong logical thinking and data modeling skills; your weakness is that you are unfamiliar with mobile-specific page lifecycles, device adaptation, and app store review. The mistake you are most likely to make is over-engineering—introducing a user system, server-side sync, and encrypted transmission into a simple note-taking app, which ends up doubling the development cycle. My advice is: if the first version can work with local storage, absolutely do not add a backend; if AI can generate a page, absolutely do not write it from scratch yourself; put your energy into the most core product logic.

6.2 Several Prompt templates I have been using long-term

This part is probably the most "copy-the-homework-directly" section of the entire blog post. I have organized the several Prompt templates I repeatedly used throughout the entire development cycle into fixed formats, so that each time I start a new feature, I can just slightly modify the specific requirements and use them directly.

Project kickoff template

：

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

Single-feature generation template

：

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

Bug fix template

：

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

Code review template

：

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

After using this set of templates, the greatest value is not that AI gives standard answers, but that the information AI provides each time has a controllable structure. You will find that when you describe requirements in this format, the quality of the code AI returns improves very noticeably, because it receives all the information you need.

Finally, let me share one of my personal habits: every time I finish a feature, I have AI generate a short technical note recording how the feature was implemented, which files are involved, and where to start if it needs to be modified later. This note is enormously valuable after the middle stage of the project—when there are more and more project files, it is easy to forget how a certain feature originally organized its code. The technical note AI writes for you may not be perfect, but as an index it is already good enough.

My biggest takeaway after personally going through the entire process is: AI does not turn you into a "god who does not need to understand technology," but rather lets you focus your energy on real product thinking. In the last two weeks of development, I almost stopped caring about how to write the interface or adjust styles, and instead spent most of my time polishing the experience and preparing app store assets—this is the key to whether an App can get users to stay. Building and shipping an App in six weeks is something I would not have dared to believe a year ago, but after actually finishing it I found that the hardest part was never the code, but whether you have thought the requirements through clearly and whether you have the courage to go through that complete process once.