我让 AI 编程工具连续写了几轮 React 页面后，才意识到“状态管理是否 AI 友好”有多重要

张一凡93
7 阅读5分钟

以前选技术栈，看的是人好不好写。现在还得看 AI 好不好接手。

这段时间我有个很强的感受：

很多 React 项目后面变难维护，不只是因为业务复杂，也因为代码结构对 AI 不友好。

这话听起来像“硬蹭 AI”，但实际真不是。

因为现在太多项目的真实开发流已经变成这样了：

  1. 自己先写一个方向
  2. 让 Cursor / Copilot / Claude Code 补细节
  3. 自己收口
  4. 再让 AI 扩展下一轮

在这个循环里，如果你的代码结构本身就不容易被模型理解，AI 每一轮都会把项目越补越散。

而我最近在 easy-model 上的体验，恰好相反。

先说结论

如果你的 React 项目有下面这些特点：

  • 页面多
  • 业务状态多
  • 跨组件共享状态多
  • 异步流程多
  • 你还想让 AI 辅助生成大量代码

那你真的应该把“AI 适配性”当成选状态方案的重要指标。

而 easy-model 这种 class-based、语义集中的组织方式，天然就比 Redux 那种多层样板，或者 Zustand 那种容易一路长成“大 store + 大量零散逻辑”的模式，更容易被 AI 持续接力。

为什么很多项目不是 AI 不行，而是代码组织方式不行

很多人吐槽：

  • “AI 写前端很飘”
  • “AI 一改就改乱”
  • “AI 只能写 demo”

我现在越来越觉得，问题经常不全在 AI 身上。

有些代码结构，本来就不适合做持续生成。

比如一个常见 React 项目，业务逻辑可能被拆成：

  • page 组件
  • custom hooks
  • service 请求
  • reducer
  • actions
  • selectors
  • context
  • utils

Redux 项目里这很常见；Zustand 项目则经常换一种形式，把很多东西重新堆回 store 和 hooks。

从“工程分层”的角度看，这么拆没问题。

但从 AI 接力开发的角度看，它会有一个麻烦：

语义上下文太分散。

AI 得来回猜：

  • 这段逻辑应该写进 hook 还是 service？
  • 状态是在本地还是全局？
  • loading 应该归组件管还是归 store 管？
  • 这次改动会影响哪个 selector？

于是你会看到一种很典型的 AI 产物：

能跑，但是散。

easy-model 为什么比较容易让 AI 写对

easy-model 的核心思路其实很简单：

  • 用 class 表达业务模型
  • 字段承载状态
  • 方法承载行为
  • 通过 useModel / useInstance 在 React 中接入

例如一个用户管理页，AI 很容易生成出这种东西：

class UserListModel {
  users: User[] = [];
  keyword = '';
  page = 1;
  pageSize = 20;
  total = 0;

  setKeyword(keyword: string) {
    this.keyword = keyword;
  }

  setPage(page: number) {
    this.page = page;
  }

  @loader.load()
  async fetchList() {
    const res = await api.getUsers({
      keyword: this.keyword,
      page: this.page,
      pageSize: this.pageSize,
    });

    this.users = res.list;
    this.total = res.total;
  }
}

这种结构对 AI 太友好了：

  • UserListModel 一看就知道负责什么
  • users / keyword / page 一看就知道是什么状态
  • fetchList / setPage 一看就知道是什么行为

人看着顺，AI 看着也顺。

它最适合哪种“AI 协作式开发”

我觉得 easy-model 特别适合下面这种节奏：

第一阶段：你先定义业务模型

先把模型类搭出来，不一定写完，只要把领域边界表达清楚：

  • ChatModel
  • UserListModel
  • AgentWorkflowModel
  • SearchPanelModel

第二阶段：让 AI 补页面和方法

这时 AI 能更稳定地补：

  • 列表页
  • 表单页
  • 搜索筛选
  • loading 展示
  • 异步请求
  • 跨组件联动

第三阶段：你来收边界

你只需要把控：

  • 命名是否合理
  • 方法边界是否清晰
  • 副作用有没有乱飞
  • 数据流有没有绕

这个过程，比直接让 AI 在一堆松散 hook 里乱长代码，稳定得多。

对 AI 项目尤其友好

这个点我想单独说。

因为 AI 项目前端往往特别容易失控。

你很少只管理一个简单列表，往往会同时有：

  • 会话状态
  • 流式输出
  • 工具调用过程
  • 多个信息面板同步
  • 操作日志
  • 历史回放
  • 多实例工作区

这类场景最怕“逻辑散”。

而 easy-model 这套写法天生比较适合把复杂状态集中到一个领域对象里。

比如一个 AI 会话模型：

class AgentSessionModel {
  messages: Message[] = [];
  status: 'idle' | 'running' | 'streaming' = 'idle';
  toolCalls: ToolCall[] = [];
  logs: string[] = [];

  @loader.load(true)
  async run(input: string) {
    this.status = 'running';
    this.logs.push(`start: ${input}`);
    // ...
    this.status = 'streaming';
    // ...
    this.status = 'idle';
  }
}

这种代码对人类和 AI 都有一个好处：

定位问题非常快。

你不用问“这个状态到底在哪层处理”，因为它大概率就在模型里。

我现在看状态管理，会多看一个新指标

以前我只看：

  • 好不好学
  • 社区大不大
  • 类型强不强
  • 性能行不行

现在我会多看一个维度：

它是否适合 AI 连续修改。

因为未来越来越多项目，根本不是纯手写。

我们会长期和 AI 共同维护同一套代码。

这时候一个方案的价值，不只是“你第一天写得爽不爽”，还包括：

  • 一个月后 AI 还能不能继续补
  • 三个月后别人接手时能不能快速看懂
  • 项目扩大后结构会不会越来越散

在这个维度上，easy-model 给我的印象确实不错。

easy-model 适合什么人

我觉得它尤其适合：

  • 想让 AI 大量参与 React 开发的人
  • 在做 AI 前端、Agent 前端的人
  • 不喜欢 Redux 样板代码、也不想把复杂业务继续堆进 Zustand store 的人
  • 想保留 TypeScript 类型体验的人
  • 希望业务语义比“状态切片”更清晰的人

最后一句

以前我会说 easy-model 是一个 React 状态管理工具。

现在我更愿意说：

它是一种对人类开发者友好、也对 AI 编程工具友好的业务建模方式。

如果你最近也在折腾 Cursor、Copilot、Claude Code 这类工具，不妨拿 easy-model 试一个真实页面，你会很快感受到差别。

项目地址：

如果你也认同“AI 适配性会成为前端架构的新指标”，欢迎去点个 Star，顺便看看这个项目能不能帮到你。

avatar
文章
阅读
粉丝