Rork 教程：从提示词到 React Native App 与 App Store 提交

Rork 可以把自然语言需求快速变成 React Native/Expo 项目，但高质量移动应用并不是“写一句提示词，然后直接提交商店”。可靠的流程应把需求收敛、生成、真机测试、后端安全、代码接管和商店材料拆成清晰阶段。本教程以一个“个人习惯记录 App”为例，目标是得到可测试的 iOS/Android MVP，并为后续 App Store 提交做好准备。

第 1 步：先写一页产品约束

在打开生成器前，用一页文字回答五个问题：用户是谁、每天完成什么任务、成功状态是什么、哪些数据必须保存、第一版明确不做什么。示例：

• 用户：想建立每日阅读习惯的个人用户
• 核心任务：选择目标、每天打卡、查看连续天数
• 成功状态：30 秒内完成一次打卡
• 数据：账号、目标、打卡日期、提醒时间
• 第一版不做：社交、排行榜、付费订阅、复杂成就系统

这一步能防止提示词同时塞入十几个功能。AI 在边界清楚时更容易生成一致的数据结构和导航。

第 2 步：定义页面与导航

将 MVP 控制在四到六个页面：欢迎/登录、今日、目标列表、目标详情、统计和设置。先决定底部导航与页面层级，再要求 Rork 实现。推荐首轮提示词：

“创建一个移动端优先的习惯记录应用，使用底部三栏导航：今日、目标、我的。今日页显示当天目标和打卡按钮；目标页可新增、编辑和暂停目标；我的页显示连续天数和提醒设置。先使用本地模拟数据，不接支付和推送。所有按钮提供加载、成功、失败和空状态。”

不要只描述视觉风格。状态、边界和失败行为比颜色更影响可用性。

第 3 步：先跑通一个主闭环

第一轮生成后，只验证“创建目标—今日显示—完成打卡—统计更新”这一条路径。发现问题时一次只发一个修改请求，并说明验收条件，例如：

“修复今日页打卡：连续点击只能写入一次；保存期间按钮禁用并显示进度；失败时保留未提交状态并允许重试；成功后连续天数只增加一次。”

每完成一个可用节点就保存版本或同步到自己的 Git 仓库。不要让十次大范围修改叠加后才做第一次回退测试。

第 4 步：用 Expo Go 做真机测试

桌面预览无法完整反映手机行为。按照 Rork 与 Expo 的当前指引，在测试设备安装 Expo Go，并在同一网络或可访问环境中打开项目。至少检查：

• 小屏和大屏上的文字换行、底部安全区和触控区域
• 输入框聚焦后软键盘是否遮挡按钮
• iOS 滑动返回与 Android 系统返回键
• 滚动位置、弹窗关闭和横竖屏行为
• 网络变慢、断网和恢复后的状态
• 权限拒绝后是否有解释和替代入口
• 应用切到后台再回来时数据是否重复提交

iOS 和 Android 都要测试。相同 React Native 代码不代表所有交互完全相同。

第 5 步：设计数据模型与后端边界

原型数据稳定后，再定义后端。习惯记录至少需要 users、habits、check_ins 和 reminder_settings。为每张表写出归属关系、唯一约束和删除策略。例如 check_ins 应对 user_id、habit_id、date 建立防重复约束，避免用户快速点击产生重复记录。

认证、支付、管理操作和第三方密钥必须放在服务端。移动应用包可以被下载和反编译，因此任何写入客户端的密钥都不能视为秘密。前端只使用可公开的配置；高权限操作通过服务端 API 完成，并验证当前用户身份。

如果使用 Supabase 或其他托管后端，不要把默认策略当作安全完成。逐表检查行级权限：用户只能读取和修改自己的目标与打卡；管理员能力使用独立服务端凭据；对象存储限制文件类型、大小和访问范围。

第 6 步：处理离线、重试与令牌过期

移动网络经常中断。为写操作分配客户端请求 ID，服务端执行幂等处理；失败时区分可重试网络错误与不可重试业务错误。不要无限自动重试，以免产生重复数据或额外费用。

登录令牌过期时，应安全刷新或要求重新登录；退出后清理本地敏感缓存。若提供离线草稿，要说明同步时如何处理冲突。第一版无法实现完整离线，也至少要显示明确错误并保留用户输入。

第 7 步：代码审查与依赖治理

将项目导出或同步到团队仓库，完成以下检查：

1. 运行类型检查、lint 和构建，清除阻断错误。
2. 删除未使用依赖与重复组件，固定关键依赖版本。
3. 检查所有环境变量，确认没有生产密钥进入客户端。
4. 检查日志，避免记录令牌、邮箱、位置或用户内容。
5. 为登录、创建目标、重复打卡、删除账号编写测试。
6. 记录数据库迁移、回滚方式和第三方 SDK 清单。
7. 检查字体、图标、图片与开源包许可证。

生成代码可以作为起点，但生产责任仍属于发布者。涉及支付、医疗、金融或儿童数据时，应增加专业安全和法律审查。

第 8 步：准备商店身份与构建

创建并保管 Apple、Google 开发者账号，确定唯一包标识、应用名称、版本号和签名责任人。使用个人账号还是组织账号会影响展示名称与验证材料，最好在正式构建前决定。

根据 Rork 和 Expo 的最新官方文档选择构建与提交方式。配置应用图标、启动画面、权限说明和环境变量，先生成内部测试构建。不要把开发环境 API 地址或测试密钥带入生产包。每次构建都记录提交版本、环境和变更说明。

第 9 步：隐私政策与数据披露

列出应用和所有 SDK 收集的数据：账号、设备标识、崩溃日志、分析事件、位置、照片、联系人或支付信息。隐私政策应说明收集目的、保存期限、共享方、删除方式和联系方式，并与应用实际行为一致。

Rork 官方隐私政策说明项目提示词、代码、资产、消息和输出会随账户保存，并可能进入常规备份。因此，不应将真实敏感数据作为生成素材。必要时使用虚构或脱敏数据，并按官方流程处理删除请求。

如果应用允许创建账号，提前实现账号删除入口与服务端数据清理。仅提供“联系客服”而没有可执行流程，可能带来审核和用户信任问题。

第 10 步：准备 App Store 审核包

提交前准备应用描述、关键词、截图、支持网址、隐私政策网址、审核联系人和演示账号。截图必须来自真实运行版本，不要展示尚未实现的功能。若核心功能需要登录，提供稳定的审核账号和清晰步骤。

涉及订阅或购买时，测试商品状态、价格展示、恢复购买、取消说明和失败流程。不要使用外部支付绕过商店规则。涉及用户生成内容时，准备举报、屏蔽和内容治理机制。

先通过 TestFlight 或内部测试邀请真实用户完成主任务。记录崩溃、卡点和权限拒绝率，修复后再正式提交。审核被拒时按具体条款逐项回应，不要只重新提交同一构建。

第 11 步：上线后的运营与回滚

发布不是终点。启用崩溃监控、API 错误率、登录成功率和关键任务完成率；为数据库建立自动备份与恢复演练；保留上一稳定版本和服务端兼容窗口。移动商店更新有审核延迟，服务端变更不能假设所有用户立即升级。

按周审查用户反馈和异常日志，优先修复数据丢失、登录失败、支付与崩溃问题，再迭代新功能。若 Rork、Expo、依赖或后端调整价格和能力，团队控制的代码仓库、文档与备份将决定迁移成本。

完成交付的判断标准

一个可提交的 MVP 至少应满足：主流程在 iOS 与 Android 真机可完成；断网和权限拒绝有反馈；没有客户端生产密钥；用户数据权限经过测试；账号删除可执行；隐私披露与实际 SDK 一致；构建可从指定 Git 版本复现；团队知道如何回滚。

按这套流程使用 Rork，AI 负责压缩初始开发与重复修改时间，团队负责需求、工程、安全和合规。两者边界清楚，才更可能把“能演示”推进到“能长期运行”。