claude code 在 React Native 项目中的实际代码辅助

别信 AI 能一键生成 App。我用这句话开头，是因为过去三个月，我几乎每周都在 React Native 项目里使用 Claude Code，而它给我的最大教训恰恰是：你越期待它独立完成一个功能，它越容易给你制造一座表面光鲜、内部千疮百孔的代码危楼。

我工作的团队有三个 React Native 项目同时跑迭代，覆盖 iOS 和安卓两端，既有大量 UI 密集的运营活动页面，也有涉及原生相机、蓝牙打印和本地持久化的复杂功能。我刚把 Claude Code 引入团队流程时，同事们的反应几乎是两极分化的，有人当天就跑过来跟我说“这也太神了吧”，也有人安静了三天之后给我看一个连 react-native link 都搞错了的原生模块调用链。

这篇文章不打算告诉你 Claude Code 有多强。我要做的事情更具体：拆出 Claude Code 在 React Native 项目中真实的代码辅助边界，告诉你哪些场景它值回票价，哪些场景你最好手动接管，并给出经过 90 多天迭代验证的协作流程和 Prompt 模板。

整篇文章基于这三个项目的真实日志、代码提交记录和我个人的 debug 笔记。你会读到很多“翻车现场”，但恰恰是这些翻车，让我逐渐摸清了一条底线：Claude Code 是 React Native 前端逻辑的高效加速器，但一旦涉及原生桥接、跨平台差异处理和性能优化，它的角色从“主力输出”立刻退回到“辅助参考”。

一、三个实验项目的基本画像与评估维度

在展开具体实验之前，先交代一下测试环境，否则后面的数据和判断你会不知道参照系在哪。

项目 A 是一个中等体量的电商应用，约 7 万行 JS/TS 代码，使用 React Native 0.72 + TypeScript，状态管理用的是 Redux Toolkit，导航栈是 react-navigation 6。原生模块包括相机、推送、微信/支付宝支付、指纹/面容认证。项目的 Android 和 iOS 原生层分别有约 4 千行和 3 千行 Java/Kotlin/ObjC 代码。

项目 B 是一个内部运营工具，代码量较轻，约 2 万行 TS，React Native 0.76 新架構 + Expo SDK 52。几乎全部依赖 Expo 生态提供的原生能力，没有自行编写原生模块。状态管理用 Zustand。

项目 C 是一个混合现实相关的概念验证项目，约 1.5 万行 TS，用到大量 ARKit/ARCore 的原生桥接，自定义原生 UI 组件较多，对帧率和内存管理有一定要求。

三个项目覆盖了“UI 密集型”、“架构纯 Expo 化”和“原生重度定制”三种典型 RN 项目形态。这对于测试 Claude Code 的多场景表现很有帮助。

我设定的评估维度是五个：

1. 功能完成度：AI 生成的代码是否跑得通，逻辑是否完整。
2. 代码可维护性：命名、结构、注释是否清晰，后续接手的人是否读得明白。
3. 跨平台一致性：iOS 和安卓的表现是否一致，是否存在单平台隐藏 bug。
4. 原生调用正确性：对原生模块的引用、参数、权限、pod 依赖是否正确。
5. 人工介入成本：从 AI 生成代码到实际合入主分支，我需要改多少东西。

每个实验我都会给出这五个维度的主观评分（1-5 分，5 分为最佳），并说明理由。

你一眼就能看出趋势：项目 B（Expo 轻原生）是 Claude Code 的甜蜜区，项目 C（重原生定制）是它的翻车高发区。 这个结论对我后来的技术选型产生了直接影响，后面会细说。

二、实验一：从零生成一个带复杂交互的商品详情页

这个实验是在项目 A 上做的。场景非常典型：产品经理扔过来一个 PRD，要求做一个商品详情页，包含可滑动的图片轮播、规格选择弹窗（BottomSheet 形式）、优惠券领取入口、以及一个固定在底部的购买按钮栏。

我把完整的 PRD 描述稍作转化（去掉敏感业务信息）后，作为一个 prompt 喂给了 Claude Code，要求它直接生成完整的页面组件和相关子组件。

2.1 AI 的第一步：惊人的骨架生成速度

不到 40 秒，Claude Code 生成了以下文件结构：

ProductDetail/
├── index.tsx

├── ImageCarousel.tsx

├── SpecSelector.tsx

├── CouponBanner.tsx

├── BottomBar.tsx

└── types.ts

文件组织逻辑清晰，子组件拆分合理，types.ts 里还定义了 ProductDetailParams、SpecOption、Coupon 等类型接口。这个结构我挑不出毛病，甚至比我自己初期做技术方案设计时的组件树更简洁。

最让我满意的是 Claude Code 对 React Native 核心 API 的调用已经很熟练。比如 ImageCarousel 用了 FlatList + pagingEnabled，而不是自己搞一个 ScrollView 手动计算偏移量；BottomBar 用了 StyleSheet.absoluteFillObject + 安全区域适配的 react-native-safe-area-context 的 useSafeAreaInsets hook。这说明它至少“读过”不少 React Native 的最佳实践代码。

但是，这个“但是”马上就来。

2.2 第一处翻车：规格选择器的状态流转逻辑

SpecSelector 是一个 BottomSheet，用户可以在里面选择颜色、尺寸等 SKU 规格，选完后价格和库存要实时更新，且当某个规格组合无库存时，对应选项需要置灰不可点击。

Claude Code 生成的第一版代码里，状态管理全部塞在了 SpecSelector 组件内部用 useState 处理，完全没考虑父组件（ProductDetail/index.tsx）也需要感知当前选中的规格 ID 和对应的价格。 换言之，BottomSheet 里的状态变更根本影响不到底部的购买按钮栏。

这就是 “局部思维”问题：Claude Code 在生成子组件时，倾向于把状态封闭在该组件内部，它不会自动判断哪些状态需要提升到父组件或者放进全局 store。如果你不在 prompt 里明确说明“选中的规格需要同步到父组件”，它默认只保证子组件自己能跑。

2.3 第二处翻车：动画相关的性能陷阱

CouponBanner 组件有一个“点击展开动画”，Claude Code 用了 Animated.timing 来实现高度变化，这没什么问题。问题出在它同时在 FlatList 里嵌套了这个 CouponBanner，而 FlatList 的 item 每次渲染都会重新触发动画。在没有做任何 shouldComponentUpdate 或 React.memo 优化的前提下，滑动列表时出现明显的掉帧。

这里暴露了 Claude Code 的一个盲区：它能写出“正确的代码”（动画能播），但无法感知“在多组件交互场景下的性能后果”。 它不知道这个动画组件会出现在一个高频滚动的列表里，也就不会主动建议你用 useMemo 包裹或者避免不必要的 re-render。

2.4 我最终改了哪些东西？

我统计了一下让这个详情页从“能跑”到“能上生产”所花的改动：

总改动成本约 65 分钟，而如果让我从零手动写，相同界面大概需要 3-4 小时。时间节省约 65-70%，但有经验的开发者一眼就能看出，我花的那 65 分钟，解决的全部是“AI 不知道怎么考虑边界条件”的问题。

以下是我对这个实验的评分：

• 功能完成度：4.0 ， 骨架完整，逻辑缺失需补。
• 代码可维护性：3.5 ， 结构清晰，但状态管理设计需重构。
• 跨平台一致性：3.2 ， iOS 表现正常，安卓上 BottomSheet 手势响应有延迟。
• 原生调用正确性：不涉及原生模块。
• 人工介入成本：3.0 ， 修边界条件花了 1 小时。

三、实验二：修复一个困扰三天的 Android TextInput 布局抖动 Bug

如果说实验一是“正向生成”，实验二就是“逆向推理”。这个 Bug 折磨了我团队一个初级工程师将近三天，最后我把它丢给 Claude Code，想看看它的诊断能力。

3.1 Bug 症状还原

项目 A 的商品搜索页有一个顶部的搜索输入框，下面是一个 FlatList 展示搜索建议。在 Android 设备上，当用户点击输入框唤起键盘时，整个页面会上下剧烈抖动一下，偶尔还会出现输入框被键盘完全遮挡的问题。 iOS 上一切正常。

Android 的 windowSoftInputMode 已经设置为 adjustPan。我和另一个前端同事初步推断是 FlatList 在键盘弹出时触发了布局重计算。

3.2 我把什么信息给了 Claude Code

我把以下上下文打包喂给 Claude Code：

• 搜索页的完整组件代码（约 180 行）
• AndroidManifest.xml 中 activity 的 windowSoftInputMode 配置
• 抖动的录屏（用文字描述了现象）
• 我自己的初步判断：“怀疑 FlatList 的 flex: 1 导致键盘弹出时高度计算异常”

且慢，最后一条我故意加进去的，我想看看 Claude Code 是否会被我的错误判断带偏。

3.3 Claude Code 的诊断过程

Claude Code 在读取代码和我的初步判断后，输出了这样一段分析（我原文摘录）：

> “我注意到这个 FlatList 的容器使用了 flex: 1，且它的父 View 也使用了 flex: 1。当键盘弹出时，Android 的 adjustPan 会调整整个 Window 的可视区域，这会导致 View 的 measurement 发生变化。但更根本的问题可能不是 FlatList 本身，而是顶部的搜索栏使用了 KeyboardAvoidingView 但 behavior 设为了 padding。”

>

> “在 Android 上，KeyboardAvoidingView 的 behavior='padding' 与 adjustPan 同时使用会产生冲突，因为两者都在尝试调整布局来适应键盘。建议将 Android 的 behavior 改为 height 或直接不使用 KeyboardAvoidingView，仅在 iOS 上保留 padding 行为。”

它没有被我带偏。 而且它指出的 KeyboardAvoidingView behavior 冲突，是我之前完全没往那方面想的点。

我马上按照它的建议改代码：用 Platform.OS === 'ios' 做条件判断，iOS 保留 KeyboardAvoidingView behavior='padding'，Android 直接不用 KeyboardAvoidingView，只依赖 adjustPan。

改动生效，抖动消失，耗时不到 5 分钟。

3.4 为什么 Claude Code 能快速定位？

事后我复盘了它的诊断逻辑，发现关键点在于：Claude Code 对 React Native 的跨平台差异 API 有“系统性知识”。 它知道 KeyboardAvoidingView 在 Android 和 iOS 上的行为不一致，知道 adjustPan 和 behavior='padding' 的组合会产生布局竞态。

这种知识对经验丰富的 RN 开发者来说可能是常识，但对只做了一两年 RN 的开发者，或者像我这样虽然经验够但没有系统梳理过所有原生交互差异点的人，Claude Code 充当的是一个 “跨平台知识外挂”的角色。

3.5 这个实验的启示：AI 的强项是模式匹配式诊断

Bug 修复这件事，有经验的工程师都是在做模式匹配，把眼前的症状跟脑子里存储的“常见坑”做比对。Claude Code 的优势在于它“读”过的代码量和 issue 讨论远超任何一个人类工程师，所以它的模式匹配库更大。但它的短板同样明显：如果 Bug 涉及运行时环境差异（比如特定厂商 ROM 的 WebView 实现差异），Claude Code 因为没有真实运行环境，只能给出“可能的猜测”，准确性大幅下降。

评分：

• 功能完成度（修复效果）：5.0 ， 直接修好。
• 跨平台一致性：5.0 ， 给出的方案明确区分了平台。
• 人工介入成本：4.8 ， 基本零改动直接生效。

四、实验三：原生支付模块集成，当 Claude Code 暴露“原生盲区”

实验三是三个实验里教育意义最大的一个。我让 Claude Code 尝试在项目 A 中“集成一个基于原生 SDK 的人脸识别支付流程”。这是一个典型的混合技术栈任务：前端是 React Native 的 JS 层，原生层需要接入第三方支付 SDK 的 Face ID 认证模块，涉及 iOS 的 Info.plist 权限声明、Podfile 依赖、以及原生桥接方法的编写。

我把需求描述为：“创建一个 FacePayment 模块，在用户点击支付后调用原生的人脸识别 SDK（假设 SDK 名称为 FacePaySDK），完成认证后回调 JS 层返回支付 token。”

4.1 JS 层：Claude Code 写的代码看起来很“像模像样”

Claude Code 在 JS 层生成了以下内容：

• 一个 FacePaymentButton 组件
• 一个 NativeModules.FacePayBridge 的调用封装
• 成功/失败的回调处理
• 超时处理和 loading 态

代码风格统一，TypeScript 类型定义也完整。如果只看 JS 层，你甚至会觉得它很专业。

4.2 原生层：第一次生成的代码不能直接用

问题出在 Android 原生端。Claude Code 生成的 Kotlin 代码大概是这样的（简化还原）：

class FacePayBridgeModule(reactContext: ReactApplicationContext) :
ReactContextBaseJavaModule(reactContext) {

override fun getName(): String = "FacePayBridge"

@ReactMethod

fun authenticate(promise: Promise) {

// 假设 FacePaySDK 已经初始化

FacePaySDK.authenticate(reactApplicationContext) { result ->

if (result.isSuccess) {

promise.resolve(result.token)

} else {

promise.reject("AUTH_FAILED", result.errorMessage)

}

}

}

}

初看没问题，实际上有三个坑：

1. 缺少 SDK 初始化代码。大多数第三方 SDK 需要一个 Application.onCreate 级别的初始化，Claude Code 没有生成这部分，也没有在注释中说明需要在 Application 中调用初始化。
2. 没有在主线程调用。authenticate 的回调可能不在主线程，但 promise 的 resolve 需要在主线程触发 UI 更新。代码里没做线程切换。
3. 没有添加 proguard 规则。第三方 SDK 通常需要 keep 一些类，AI 完全没提这一点。

iOS 端的问题类似：生成的 Objective-C 代码没有处理 Face ID 权限申请的 NSFaceIDUsageDescription 描述，虽然生成了 info.plist 的示例但忘了添加本地化描述。

4.3 “幻觉”问题：向不存在的方法传递了参数

更严重的一个问题是：我在 prompt 里故意写了一个不存在的参数，我说“SDK 的 authenticate 方法接受一个 useLiveness 布尔参数来控制是否使用活体检测”。Claude Code 没有任何质疑，直接在原生代码里加了 FacePaySDK.authenticate(context, useLiveness = true) 这样的调用。

但这个参数在真实的 FacePaySDK 里根本不存在。 如果你直接拿去编译，会直接报错。如果你用的是动态链接的 SDK、编译时没问题，运行时就会崩溃。

这暴露了 Claude Code 在处理“它不熟悉的私有 SDK API”时的核心缺陷：它会假设 prompt 里提到的 API 是真实存在的，不会主动质疑或要求你提供该 SDK 的文档。 这种“听话但不过脑子”的特性，在原生层集成时是致命的。

4.4 我的修复清单

总计修复耗时约 35 分钟，但关键是，这 35 分钟的修复需要你同时懂 Android 和 iOS 的原生开发。如果是一个纯 JS 背景的开发者用 Claude Code 做这件事，ta 可能根本发现不了线程问题和 ProGuard 问题，上线后遇到生产崩溃才回头排查。

4.5 对这个实验的评分

• 功能完成度：2.8 ， JS 层可用，原生层无法直接编译。
• 代码可维护性：2.5 ， 缺少注释，原生代码没有做异常处理。
• 原生调用正确性：2.2 ， 出现了幻觉 API 和遗漏初始化的严重问题。
• 人工介入成本：1.8 ， 需要懂原生开发的工程师逐行修复。

五、性能优化场景：AI 知道怎么写，但不知道什么时候该写

在项目 A 的首页 feed 流优化中，我尝试让 Claude Code 帮我优化一个“加载更多”时的卡顿问题。当时的代码逻辑是：每次上拉加载时，请求 20 条新数据，然后拼接到现有的 FlatList data 数组上。当数据量超过 200 条时，上拉加载出现明显卡顿。

5.1 Claude Code 的建议

它给出了几个优化方向：

• 使用 getItemLayout 来跳过 FlatList 的 item 高度测量
• 给 item 组件加 React.memo
• 使用 windowSize 控制渲染窗口

这三个建议都没错，都是 React Native 性能优化的常见做法。但它没有触及真正的根因，数据拼接时用了展开运算符 [...oldData, ...newData]，导致每次加载更多都会创建一个全新的数组引用，触发 FlatList 的全量 re-render，即使有 React.memo，data 引用变了 memo 也拦不住。

这个坑我最后是自己在 Chrome DevTools 里通过录制组件渲染火焰图才定位到的。Claude Code 不会跑你的代码，它只能给出“统计上最相关的优化建议”。

5.2 AI 在性能优化上的根本局限

性能优化需要两个前提，而 Claude Code 两者都不具备：

1. 量化感知：你不能只告诉我“使用 getItemLayout 会更快”，你得告诉我当前场景下 JS 帧率是多少、掉帧发生时的调用栈是什么。AI 无法获取运行时数据，所以它的优化建议永远是“通用型”的。
2. 因果推断：性能问题的根因往往不是显而易见的。列表卡顿可能是因为数据引用变了，可能是因为某个第三方依赖在 layout 阶段做了耗时计算，可能是因为 Android 的渲染线程被 GC 阻塞。Claude Code 只能从代码文本中推测因果，但文本本身往往没有包含根因。

5.3 我的使用策略：AI 给方向，人来验证

经历过这次之后，我确立了在性能优化上使用 Claude Code 的原则：让它列出可能的优化方向和代码改写方案，但绝不直接合入，必须先用 React DevTools Profiler 或 Flipper 验证根因，再选择适用方案。

六、重构与迁移：Claude Code 的“工程理解力”有多深？

实验项目 B 有一个需求是把旧版的 react-navigation 5 升级到 react-navigation 6，同时把类组件全部改为函数组件。这个任务的工作量大致是：

• 12 个页面组件
• 4 个导航器配置文件
• 涉及 navigation 相关 props 类型的全部修改

6.1 迁移执行过程

我把整个 src/navigation 和 src/screens 目录的代码作为上下文喂给 Claude Code，告诉它“把这些文件从 react-navigation 5 迁移到 6，类组件改为函数组件，保持原有业务逻辑不变。”

Claude Code 的输出质量让我有些意外：

• 正确地处理了 navigationOptions 到 options 的 API 变更
• 正确地处理了 navigation.navigate 的类型从可选变为必传的泛型参数
• 正确地将类组件的生命周期方法映射到了 useEffect（包括 componentDidMount -> useEffect(fn, []) 和带有 cleanup 的 componentWillUnmount -> useEffect return）
• 正确处理了 this.props.navigation 到 useNavigation hook 的迁移

13 个文件、总计约 2800 行代码的迁移，Claude Code 的生成结果里我只发现了 2 处需要手动修复的问题：

• 一处是 navigation.setParams 的调用在函数组件中应该用 navigation.setOptions（AI 没改过来）
• 另一处是一个深层嵌套的路由监听器在 useEffect 里的依赖数组设置不完整，导致状态更新时可能出现闭包陷阱

6.2 为什么这次表现这么好？

因为这个任务是 “规则明确、有大量公开文档可循”的结构化迁移。react-navigation 5 到 6 的变更在官方文档、社区博客和 GitHub issues 里有海量讨论，Claude Code 在训练数据中一定见过大量类似的迁移代码。加上函数组件的转换模式也非常固定，AI 的模式匹配优势可以充分发挥。

与实验三（原生支付集成）对比，你会发现一个规律：当任务的标准答案存在于公开的训练语料中时，Claude Code 表现优异；当任务依赖私有 SDK、特定运行时环境或者需要原创性工程判断时，它的表现明显下滑。

6.3 迁移任务的评分

• 功能完成度：4.5
• 代码可维护性：4.0
• 跨平台一致性：4.2（导航行为在两端一致）
• 人工介入成本：4.3（只改了 2 处，约 10 分钟）

七、不同项目形态下的 Claude Code 使用策略

基于三个项目的实验，我整理出了针对不同 React Native 项目形态的 Claude Code 使用建议。先直接给出结论，再分别解释。

7.1 Expo 项目：Claude Code 的甜蜜区

项目 B 的表现足够说明问题。Expo 生态把原生层的复杂度抽象掉了，Claude Code 不需要理解 Bridge 的细节，只需要在 JS/TS 层工作。 这就是为什么它在项目 B 上的功能完成度达到了 4.5，原生调用正确性也高达 4.5。

对于 Expo 项目，我现在的使用方式是：大胆让 Claude Code 生成 UI 页面和业务逻辑，人工只做 code review 和边界条件补全。 效率提升稳定在 40%-60% 之间。

7.2 混合原生项目：建立明确的“AI 禁区”

项目 A 属于这个形态。经过实验一和实验三的教训，我定了三条硬规则：

1. 所有涉及原生模块的 import 和调用，必须人工 review 每一个参数和回调。
2. 所有 Android 的 proguard 规则、iOS 的 Podfile 变更和 Info.plist 权限声明，禁止让 AI 直接生成后不经检查合入。
3. 所有涉及多线程的代码（比如原生层的异步回调），AI 生成的代码必须在架构评审中逐行检查。

7.3 重度原生定制项目：降低期望，把 AI 当“高级搜索”

项目 C 是典型的“JS 只是壳，原生代码是核心”的项目。在这种项目上，我几乎不让 Claude Code 写原生代码，而是让它做这些事情：

• 帮助理解 ARKit/ARCore 官方文档中的某个 API 用法
• 生成 TypeScript 的类型定义文件（因为原生模块需要类型声明）
• 帮助排查 JS 层的调用语法问题

把期望从“让 AI 帮我写代码”调整为“让 AI 帮我查信息和补全类型”，体验会好很多。

八、给 React Native 开发者的 Claude Code 协作模板

经过三个月的反复磨合，我总结出了一套适用于 React Native 项目的 Claude Code Prompt 模板。这套模板的核心逻辑是：用“角色界定 + 平台约束 + 边界条件显式声明”的方式，最大化降低 AI 自由发挥带来的风险。

8.1 基础 Prompt 模板

你是一位有 5 年经验的 React Native 开发工程师，擅长 TypeScript、React Navigation 6 和 react-native-reanimated 动画库。
现在请完成以下任务：[具体的任务描述]

在生成代码时，请严格遵守以下约束：

所有涉及 iOS 和 Android 行为不一致的 API（如 KeyboardAvoidingView、Shadow、StatusBar），必须用 Platform.OS 做平台区分。
所有第三方原生模块的调用，必须包含 try-catch 异常处理，并在注释中说明该模块可能需要的权限和 pod 依赖。
组件的状态需要考虑加载态、空态、错误态和正常态四种情况，分别对应不同的渲染分支。
列表组件的 item 必须使用 React.memo 包裹，并提供稳定的 keyExtractor。
样式使用 StyleSheet.create 定义，不使用内联样式对象。
所有涉及原生模块的代码，在注释中标注需要人工验证的部分。

这个模板里每一条都是我用“血的教训”换来的。第 2 条来自实验三的原生调用崩溃，第 3 条来自实验一的 happy path 遗漏，第 4 条来自实验二的列表性能问题。

8.2 针对不同任务的模板变体

生成新页面时，追加以下约束：

- 页面的状态如果需要在多个子组件间共享，请将状态提升至父组件并通过 props 传递。

如果使用了 react-navigation 的 screenOptions，确保在函数组件模式下使用 useLayoutEffect 或 navigation.setOptions。

修复 Bug 时，追加：

- 请先列出可能的原因（按概率排序），然后针对最可能的原因给出修复方案。

如果修复方案涉及原生配置变更（AndroidManifest、Info.plist、Podfile、build.gradle），请在注释中明确标注变更项。

在给出修复代码前，先用 1-2 句话解释根因。

集成第三方原生 SDK 时，追加：

- 如果你不知道该 SDK 的具体 API，请不要猜测，而是在代码中留下 [TODO: 需要查阅 SDK 文档] 的注释。

所有原生层的代码必须包含完整的主线程切换处理（Android: runOnUiThread 或 Handler；iOS: dispatch_async to main queue）。

必须在注释中列出所有需要添加的权限声明。

8.3 一个真实的协作案例

说一个上周刚发生的事情。产品要求加一个“手势密码解锁”功能，需要用到 react-native-gesture-handler 和 react-native-reanimated。我在 Claude Code 里使用了上面的“生成新页面”模板变体，追加了“手势识别需要用 Reanimated 2 的 worklet 来处理动画，避免 JS 线程阻塞”的具体要求。

AI 生成的代码质量明显比不加约束时高了一截：动画逻辑正确地放在了 worklet 里，手势状态的管理也没有像之前那样全塞在组件内部，而是抽象了一个自定义 hook。最终我改动了不到 5 行代码就合入了主分支，耗时 8 分钟。

如果你只记一件事，请记住这句话：Claude Code 的输出质量，70% 取决于你的 Prompt 质量。 它不是一个能读懂你心思的魔法师，它是一面镜子，你给它什么样的约束和上下文，它就还你什么样质量的代码。

九、团队落地 Claude Code 的四个关键决策

如果你读完这篇文章，觉得 Claude Code 可以尝试引入团队，下面这四个决策点你必须先想清楚。它们直接决定引入之后到底是提效还是添乱。

9.1 决策一：谁可以用？，不是每个人都适合用 AI 写代码

我在团队里做了一个月的观察后，决定暂时只让有 2 年以上 React Native 经验的工程师使用 Claude Code。原因很简单：Claude Code 生成的代码有太多“看起来对、实际埋了坑”的情况。如果你没有足够的经验识别这些坑，AI 不是在帮你，而是在帮你更快地写出 bug。

初级工程师最容易踩的坑是“信任过度”，看到 AI 输出的代码语法正确、风格统一，就默认它逻辑也正确。而实际上，正如实验三展示的那样，AI 可能会调用不存在的 API、遗漏异常处理、或者忽略跨平台差异。

我的建议：新人先用 Claude Code 做“代码解释”和“文档查询”，至少 3 个月后再让它辅助写代码。

9.2 决策二：哪些环节必须人工 Review？

我定了一个铁律：所有 AI 生成的代码，合入主分支前必须经过至少一个人工 Review，且 Reviewer 不能是生成这段代码的人。 Review 的重点不是检查语法（语法 AI 基本不出错），而是检查以下几项：

1. 边界条件是否处理？，空数组、null 值、网络超时、用户快速点击。
2. 跨平台行为是否一致？，有没有只处理了 iOS 没处理 Android 的情况。
3. 是否有潜在的内存泄露？，useEffect 的 cleanup 是否完整？定时器和监听器是否在组件卸载时清除？
4. 原生配置是否正确？，如果有原生层代码变更，权限、依赖、版本号是否都齐全？

9.3 决策三：要不要让 AI 直接操作 Git？

Claude Code 支持直接执行终端命令。我的建议是：不要让 AI 自动执行 git commit 和 git push。 它可以帮你生成 commit message，可以帮你创建分支，但最终的提交动作必须由人完成。

这不仅是安全考虑，更是一种“责任边界”，当你亲手敲下 git commit 的那一刻，你承担了这段代码的全部责任。如果让 AI 自动提交，开发者很容易产生“这是 AI 写的，出了问题不是我的锅”的心态，而这对代码质量文化是毁灭性的。

9.4 决策四：哪些任务类型分配给 Claude Code？

我在团队里帮他们做了一个简单的决策矩阵：

这个矩阵贴在团队看板上之后，Claude Code 的使用效率明显提升了，因为大家不再把时间浪费在“让它做它做不好的事情”上。

十、Claude Code 让我更确信一件事

写到这儿，我已经把三个月来踩过的坑、验证过的结论、建立起来的协作流程全部摊开在桌上了。如果你回头翻翻，会发现一条暗线始终贯穿全文：Claude Code 不是在取代 React Native 开发者，而是在拉大“会用 AI 的开发者”和“不会用 AI 的开发者”之间的效率差距。

这和“人人都能编程”的叙事是相反的。AI 降低了写代码的门槛，但提升了写“可维护代码”的门槛，因为现在你需要的能力不只是写对语法，还包括：

• 在 30 秒内判断 AI 生成的 200 行代码里哪个地方可能埋了跨平台兼容性 bug
• 知道怎样用 6 条约束把一个模糊的需求转化成 AI 能高质量执行的任务
• 能分辨“这代码看起来对”和“这代码实际上对”之间的微妙差别

这些能力，恰好落在有经验的 React Native 开发者的技能带上。所以 Claude Code 对资深开发者的赋能远大于对新手。

10.1 下一步你可以做什么

如果你看完这篇文章想立刻动手试试，我会建议你按这个顺序来：

第一步：从 UI 骨架生成开始。 找一个你熟悉的功能，把设计稿描述扔给 Claude Code，按第八节的基础模板写 Prompt，观察它的输出质量。重点关注边界条件是否覆盖、状态管理设计是否合理。记录你实际改动了几行代码。

第二步：用 Claude Code 诊断一个你已知根因的历史 Bug。 不要告诉它答案，只给它症状和代码，测试它的诊断能力是否到位。这个练习能帮你快速建立对 AI 诊断准确率的直觉。

第三步：明确你项目的“AI 禁区”。 根据你的项目形态（Expo / 混合 / 重度原生），参考第七节的表格，划定哪些任务让 Claude Code 做，哪些必须纯手动。

第四步：迭代你的 Prompt 模板。 我的模板不是你项目的模板。你需要把 Claude Code 在你的代码库里犯过的错，转化成约束写进你的模板里。每次它犯一次错，你就加一条约束。三个月后，你的模板会非常贴合你的项目。

10.2 最后一句话

在 AI 工具快速迭代的今天，三个月前的体验和今天的体验可能已经天差地别。这篇文章记录的只是我在特定时间窗口内的观察和判断。如果你想获取最新的、关于 AI 辅助 React Native 开发的实践更新，建议关注相关的开发者社区和官方发布日志。

但有一点我不认为会变：工具在进化，但“理解工具的边界并善用它”的能力，永远是工程师最核心的竞争力。 Claude Code 没有改变这个规则，它只是把这个规则变得比以往任何时候都更明显。