Skip to main content

难点：ai 组织代码不够好

下面帮你整理成面试里可以直接说的版本，围绕「AI 写代码能跑，但组织方式不符合项目规范」这个难点。

30 秒版（开场）​

我们在 React Native 项目里有一套明确的代码组织规范：样式和颜色要分层，组件要复用主题体系。AI 生成的代码常见问题不是语法错误，而是能运行但不符合团队约定——比如手动拉 7 个主题色、在组件内部 createStyles、用原生 Text/View 而不是 ThemedText/ThemedView。这类问题在 Code Review 里比 bug 更难发现，因为编译能通过，但长期会导致主题不一致、性能浪费、维护成本上升。

1 分钟版（问题 + 举例）​

我举个真实反例：ChainList.tsx。

第一，颜色管理混乱。 组件顶部连续调了 7 次 useThemeColor，再传给 createStyles。项目里已经有 ThemedText 的 colorVariant、ThemedView 的 backgroundVariant，颜色应该在组件层消化，而不是每个列表项自己管一套。

第二，样式组织反模式。 createStyles(colors) 在组件函数体内每次 render 都会执行，StyleSheet.create 本应只做布局（flex、padding、fontSize），颜色不该写进 StyleSheet。规范是：结构样式放组件外静态 StyleSheet.create，颜色用主题组件或少量 inline。

第三，没用项目基建。 用了原生 Text、View、Pressable，规范要求 ThemedText、ThemedView、TouchableOpacity。

第四，代码冗余。 createStyles 里还有 header、searchBar 等未使用样式，像是复制粘贴残留，增加阅读成本。

第五，硬编码颜色。 比如 iconText 里写死 #fff，暗色模式会出问题。

深入版（面试官追问「为什么这样不好」）​

问题 1：组件内 createStyles + 传颜色​

  const styles = createStyles({
    background,
    textPrimary,
    textSecondary,
    primary,
    surface,
    border,
    placeholderColor,
  });

可以说：

StyleSheet.create 的设计意图是创建一次、多次复用。把颜色注入 StyleSheet，等于每次主题变化或 re-render 都可能重建样式对象。React Native 的 StyleSheet 优化（样式 ID 缓存）就失效了。

正确做法：结构样式静态化，颜色交给主题层。

问题 2：手动管颜色 vs 主题组件​

  const background = useThemeColor("background");
  const textPrimary = useThemeColor("text");
  const textSecondary = useThemeColor("textSecondary");
  const primary = useThemeColor("primary");
  const surface = useThemeColor("surface");
  const border = useThemeColor("border");
  const placeholderColor = useThemeColor("inputPlaceholder");

可以说：

这是 AI 常见模式：「把所有可能用到的颜色先取出来」。但在有 Design System 的项目里，这是重复劳动。ThemedText colorVariant="primary" 已经封装了颜色映射，组件只关心语义（primary / secondary），不关心具体 hex 值。

问题 3：硬编码 + 死代码​

    iconText: {
      color: "#fff",
      fontSize: 16,
      fontWeight: "bold" as const,
    },

可以说：

AI 容易生成「看起来完整」的代码块，包括未使用的 style 和 magic number。Review 时要问：这个 style 有没有被引用？颜色能不能走主题？ 否则 dark mode 和后续换肤都会踩坑。

对比：正确组织方式（面试加分）​

可以说：

我会按三层组织：

  1. 结构层 — 组件外 StyleSheet.create，只放 layout / typography，不放颜色
  2. 主题层 — ThemedView、ThemedText 的 variant 表达语义
  3. 业务层 — 组件只管 props、状态和列表逻辑

重构后大概是这样：

// Structure only — created once, outside component
const styles = StyleSheet.create({
  chainItem: {
    flexDirection: "row",
    alignItems: "center",
    paddingVertical: 10,
    paddingHorizontal: 4,
  },
  assetSymbol: {
    fontSize: 16,
    fontWeight: "bold",
  },
  assetName: {
    fontSize: 14,
  },
});

// Component — colors via themed primitives
<Pressable style={styles.chainItem} onPress={...}>
  <ThemedText style={styles.assetSymbol} colorVariant="primary">
    {item.name}
  </ThemedText>
  <ThemedText style={styles.assetName} colorVariant="secondary">
    {item.derivation?.[0]?.path}
  </ThemedText>
</Pressable>

和 ThemedText.tsx 一样：颜色在主题组件内部消化，StyleSheet 只负责结构。

方法论（体现你「会用 AI，也会管 AI」）​

面试官如果问「你怎么避免 AI 写出这种代码」，可以这样说：

步骤做法
给约束在 prompt / .cursorrules 里写死：必须用 Themed 组件、StyleSheet 禁止写颜色、样式放组件外
给范例指名一个好文件（如 ThemedTextInput.tsx）当 template，比抽象规则更有效
Review 清单颜色是否硬编码？StyleSheet 是否在 render 内创建？是否有未使用代码？是否用了项目组件？
小步迭代不让 AI 一次生成整屏，先 skeleton + 主题，再补业务逻辑

一句话总结：

AI 擅长补全「能跑的 UI」，但不天然理解「团队怎么组织代码」。我的做法是：规范前置 + 范例约束 + Review 清单，把 AI 当 junior，而不是当架构师。

可能的追问 & 回答​

Q：createStyles 传颜色是不是为了支持 dark mode？

支持 dark mode 应该走 useThemeColor 或 Themed 组件的内部机制，而不是每个业务组件自己 factory 一套 StyleSheet。否则每个列表、每个 modal 都复制同样模式，主题改一处要改 N 处。

Q：性能影响大吗？

单组件可能不明显，但 FlatList 里嵌套、页面多、频繁 re-render 时会叠加。更关键是一致性和可维护性——新人看代码不知道 follow 哪套模式。

Q：你会怎么改 ChainList？

  1. 删掉 createStyles 和 ThemeColors
  2. 未使用的 header/search 样式删掉
  3. Text → ThemedText，View → ThemedView
  4. 静态 StyleSheet.create 放文件底部
  5. Icon 颜色用 useThemeColor("primary") 一处即可，不必注入整个 styles

如果你需要，我可以再帮你写一版英文面试回答，或者直接把 ChainList.tsx 按规范 refactor 一版当对比 demo。