某天，你让 Claude 帮你写个购物车功能，它给你生成了一套完整的 Redux。你看着满屏的 action、reducer、selector，心想：真的需要这么复杂吗？
AI 工具确实能快速生成状态管理代码，但它生成的方案，真的适合你的项目吗？这篇文章是我在 AI 辅助开发中，重新思考"状态管理选择"的过程。我想搞清楚：哪些工具是 AI 擅长的，哪些是我真正需要的。
从一个计数器开始：状态管理的起点
最简单的需求
让我们从最基础的开始。
// Environment: React
// Scenario: A simple counter
function Counter() {
const [count, setCount] = useState(0);
return (
<div>
<p>Count: {count}</p>
<button onClick={() => setCount(count + 1)}>+1</button>
</div>
);
}
这里的"状态"是什么？
-
count 这个数字
- 它会随着用户点击而变化
- 只在这个组件内部使用
AI 友好度：⭐⭐⭐⭐⭐
为什么 AI 在这里表现完美？
-
useState 是最基础的模式，训练数据充足
- 模式简单统一，不容易出错
- 生成的代码几乎不需要修改
结论：如果状态只在单个组件内使用，useState 就够了，不需要其他工具。
需求升级：父子组件通信
当状态需要在多个组件间共享时，事情开始变复杂。
// Environment: React
// Scenario: State lifting to parent component
function Parent() {
const [count, setCount] = useState(0);
return (
<div>
<Display count={count} />
<Controls count={count} setCount={setCount} />
</div>
);
}
function Display({ count }) {
return <h1>{count}</h1>;
}
function Controls({ count, setCount }) {
return (
<>
<button onClick={() => setCount(count + 1)}>+1</button>
<button onClick={() => setCount(count - 1)}>-1</button>
</>
);
}
思考点：
- 状态"提升"到父组件
- 通过 props 传递给子组件
- 这样做的问题是什么？
AI 友好度：⭐⭐⭐⭐
AI 能正确生成状态提升的代码，Props 传递逻辑清晰。但如果层级更深，AI 可能生成冗长的代码——它会"老实地"逐层传递，不会主动建议更好的方案。
第一层复杂度：Props Drilling 让人崩溃
问题场景：深层嵌套的组件树
想象一下存在这样的组件结构：
// Scenario: User info needed in multiple deeply nested components
<App>
<Layout>
<Header>
<Navigation>
<UserMenu /> {/* needs user info */}
</Navigation>
</Header>
<Sidebar>
<UserProfile /> {/* needs user info */}
</Sidebar>
<Main>
<Content>
<Article>
<AuthorInfo /> {/* needs user info */}
</Article>
</Content>
</Main>
</Layout>
</App>
Props Drilling 的痛苦：
// Environment: React
// Scenario: Props drilling problem
// Every layer must pass user prop
function App() {
const [user, setUser] = useState(null);
return <Layout user={user} />;
}
function Layout({ user }) {
return (
<>
<Header user={user} />
<Sidebar user={user} />
<Main user={user} />
</>
);
}
function Header({ user }) {
return <Navigation user={user} />;
}
function Navigation({ user }) {
return <UserMenu user={user} />;
}
function UserMenu({ user }) {
// Finally used here!
return <div>{user.name}</div>;
}
问题分析：
- Layout、Header、Navigation 都不需要 user
- 但为了传递给深层组件，它们都要接收这个 prop
- 代码冗余，维护困难
AI 生成这种代码时的特点：
- ⚠️ AI 会"老实地"逐层传递 props
- ⚠️ 不会主动建议使用 Context 或状态管理
- ⚠️ 生成的代码"能用"，但不优雅
解决方案1：Context API
// Environment: React
// Scenario: Use Context to avoid props drilling
// Create Context
const UserContext = createContext();
// Wrap root with Provider
function App() {
const [user, setUser] = useState(null);
return (
<UserContext.Provider value={{ user, setUser }}>
<Layout />
</UserContext.Provider>
);
}
// Deep component directly consumes
function UserMenu() {
const { user } = useContext(UserContext);
return <div>{user?.name}</div>;
}
// Middle components don't need to know about user
function Layout() {
return (
<>
<Header />
<Sidebar />
<Main />
</>
);
}
Context 的优势：
- ✅ 解决了 Props Drilling
- ✅ 中间组件不需要关心数据传递
- ✅ React 原生 API，无需额外依赖
Context 的问题：
// Environment: React
// Scenario: Performance issue with Context
function UserProvider({ children }) {
const [user, setUser] = useState(null);
const [theme, setTheme] = useState('light');
// ❌ Every time user or theme changes, all consumers re-render
return (
<UserContext.Provider value={{ user, setUser, theme, setTheme }}>
{children}
</UserContext.Provider>
);
}
// Even if component only needs theme, it re-renders when user changes
function ThemeToggle() {
const { theme, setTheme } = useContext(UserContext);
// Re-renders when user changes!
}
AI 友好度：⭐⭐⭐
AI 生成 Context 代码的特点：
- ✅ AI 能正确生成 Context 的基本用法
- ⚠️ AI 经常忽略性能优化（split context、useMemo）
- ⚠️ AI 可能把所有状态都放在一个 Context 里
- ❌ AI 生成的代码需要人工审查性能问题
我的经验是：让 AI 生成 Context 代码后，需要手动检查：
- 是否需要拆分成多个 Context？
- value 对象是否需要 useMemo？
- 是否有不必要的重渲染？
Context 的适用场景：
- ✅ 数据变化不频繁（主题、语言、用户信息）
- ✅ 只需要跨 2-3 层组件
- ✅ 简单项目，不想引入额外依赖
- ❌ 数据频繁变化（表单输入、动画）
- ❌ 需要复杂的状态更新逻辑
第二层复杂度：状态更新逻辑变复杂
问题场景：购物车的复杂状态
// Environment: React
// Scenario: Shopping cart with complex operations
function Cart() {
const [items, setItems] = useState([]);
// Add item
const addItem = (product) => {
const existing = items.find(item => item.id === product.id);
if (existing) {
setItems(items.map(item =>
item.id === product.id
? { ...item, quantity: item.quantity + 1 }
: item
));
} else {
setItems([...items, { ...product, quantity: 1 }]);
}
};
// Remove item
const removeItem = (id) => {
setItems(items.filter(item => item.id !== id));
};
// Update quantity
const updateQuantity = (id, quantity) => {
setItems(items.map(item =>
item.id === id ? { ...item, quantity } : item
));
};
// Clear cart
const clearCart = () => {
setItems([]);
};
// Calculate total
const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0);
// ... component render logic
}
问题分析：
- setState 逻辑散落在各个函数中
- 每个函数都要处理不可变更新
- 复杂的条件判断和数组操作
- 难以追踪状态变化
解决方案2：useReducer
// Environment: React
// Scenario: Manage complex state with Reducer
// Define Action Types
const ACTIONS = {
ADD_ITEM: 'ADD_ITEM',
REMOVE_ITEM: 'REMOVE_ITEM',
UPDATE_QUANTITY: 'UPDATE_QUANTITY',
CLEAR_CART: 'CLEAR_CART'
};
// Reducer: Centralized state change logic
function cartReducer(state, action) {
switch (action.type) {
case ACTIONS.ADD_ITEM: {
const existing = state.items.find(item => item.id === action.payload.id);
if (existing) {
return {
...state,
items: state.items.map(item =>
item.id === action.payload.id
? { ...item, quantity: item.quantity + 1 }
: item
)
};
}
return {
...state,
items: [...state.items, { ...action.payload, quantity: 1 }]
};
}
case ACTIONS.REMOVE_ITEM:
return {
...state,
items: state.items.filter(item => item.id !== action.payload)
};
case ACTIONS.UPDATE_QUANTITY:
return {
...state,
items: state.items.map(item =>
item.id === action.payload.id
? { ...item, quantity: action.payload.quantity }
: item
)
};
case ACTIONS.CLEAR_CART:
return { ...state, items: [] };
default:
return state;
}
}
// Use in component
function Cart() {
const [state, dispatch] = useReducer(cartReducer, { items: [] });
const addItem = (product) => {
dispatch({ type: ACTIONS.ADD_ITEM, payload: product });
};
const removeItem = (id) => {
dispatch({ type: ACTIONS.REMOVE_ITEM, payload: id });
};
// State update logic centralized in reducer
// Component only dispatches actions
}
useReducer 的优势：
- ✅ 状态更新逻辑集中，易于维护
- ✅ Action 类型明确，易于追踪
- ✅ 测试友好（Reducer 是纯函数）
- ✅ 适合复杂的状态转换
AI 友好度：⭐⭐⭐⭐
AI 能生成结构清晰的 Reducer，Switch-case 模式是 AI 熟悉的。但 AI 可能生成过于冗长的代码，Action types 和 actions 的组织方式可能不够优雅。
我的经验是：AI 生成的 Reducer 代码通常可用，但需要人工优化：
- 提取重复的逻辑
- 简化不可变更新（考虑 Immer）
- 优化 Action 的组织方式
解决方案3：Zustand（AI 最爱）
// Environment: React + Zustand
// Scenario: More concise global state management
import { create } from 'zustand';
// Everything visible in one file
const useCartStore = create((set, get) => ({
items: [],
addItem: (product) => set((state) => {
const existing = state.items.find(item => item.id === product.id);
if (existing) {
return {
items: state.items.map(item =>
item.id === product.id
? { ...item, quantity: item.quantity + 1 }
: item
)
};
}
return {
items: [...state.items, { ...product, quantity: 1 }]
};
}),
removeItem: (id) => set((state) => ({
items: state.items.filter(item => item.id !== id)
})),
updateQuantity: (id, quantity) => set((state) => ({
items: state.items.map(item =>
item.id === id ? { ...item, quantity } : item
)
})),
clearCart: () => set({ items: [] }),
// Derived state (auto-calculated)
get total() {
return get().items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}
}));
// Use in component (very concise)
function Cart() {
const { items, addItem, removeItem, total } = useCartStore();
return (
<div>
{items.map(item => (
<CartItem key={item.id} item={item} onRemove={removeItem} />
))}
<p>Total: ${total}</p>
</div>
);
}
// Other components can easily access
function CartBadge() {
const itemCount = useCartStore(state => state.items.length);
return <span>{itemCount}</span>;
}
Zustand 的优势：
- ✅ 无需 Provider 包裹
- ✅ 代码量少，一个文件搞定
- ✅ 性能好（组件级别的精确订阅）
- ✅ API 简单，学习成本低
- ✅ TypeScript 支持好
与 useReducer 对比：
| 特性 |
useReducer |
Zustand |
| 样板代码 |
较多 |
很少 |
| 跨组件共享 |
需要 Context |
原生支持 |
| 学习曲线 |
中等 |
低 |
| DevTools |
需要自己实现 |
内置支持 |
AI 友好度：⭐⭐⭐⭐⭐（最高）
为什么 AI 最爱 Zustand？
- ✅ 单文件可见全貌，AI 容易理解上下文
- ✅ 模式统一，生成代码质量高
- ✅ 没有跨文件引用，不会遗漏关联
- ✅ TypeScript 类型推断友好，AI 生成的类型也准确
我的实际体验：
我：帮我用 Zustand 写个购物车状态管理
Claude：[生成完整、可用的代码]
我：几乎不需要修改，直接能用 ✅
我：帮我用 Redux 写个购物车
Claude：[生成 actions、reducers、types...]
我：需要检查各个文件的关联，修改不一致的地方 ⚠️
Zustand 的适用场景：
- ✅ 中小型项目
- ✅ 需要全局状态，但不想写太多代码
- ✅ 与 AI 协作开发（AI 生成质量高）
- ✅ 团队成员 React 经验参差不齐
- ⚠️ 超大型项目可能需要更严格的规范（考虑 Redux）
第三层复杂度：服务端数据的特殊性
问题场景：数据同步的困境
// Environment: React
// Scenario: Product list + product detail
// Problem: How to keep data consistent?
function ProductList() {
const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(false);
useEffect(() => {
setLoading(true);
fetchProducts()
.then(setProducts)
.finally(() => setLoading(false));
}, []);
// Problem 1: Data may be stale when returning from detail page
// Problem 2: Other users modified product, I see old data
// Problem 3: Same product may show different data in list vs detail
}
function ProductDetail({ id }) {
const [product, setProduct] = useState(null);
useEffect(() => {
fetchProduct(id).then(setProduct);
}, [id]);
const updateProduct = async (data) => {
await updateProductAPI(id, data);
setProduct(data); // Update detail page
// Problem: What about the list page data?
};
}
传统方案的问题：
- 数据缓存：什么时候重新请求？
- 数据同步：多个组件如何共享同一份数据？
- 加载状态：每个组件都要写 loading/error 逻辑
- 数据过期：如何判断数据需要刷新？
解决方案4：React Query
// Environment: React + React Query
// Scenario: Elegantly manage server state
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
// List page
function ProductList() {
const { data: products, isLoading, error } = useQuery({
queryKey: ['products'],
queryFn: fetchProducts,
staleTime: 5 * 60 * 1000, // Consider data fresh for 5 minutes
});
if (isLoading) return <div>Loading...</div>;
if (error) return <div>Error: {error.message}</div>;
return (
<div>
{products.map(product => (
<ProductCard key={product.id} product={product} />
))}
</div>
);
}
// Detail page
function ProductDetail({ id }) {
const queryClient = useQueryClient();
const { data: product } = useQuery({
queryKey: ['product', id],
queryFn: () => fetchProduct(id),
});
const updateMutation = useMutation({
mutationFn: (data) => updateProductAPI(id, data),
onSuccess: (updatedProduct) => {
// Update detail cache
queryClient.setQueryData(['product', id], updatedProduct);
// Invalidate list, trigger refetch
queryClient.invalidateQueries(['products']);
// Data auto synced!
},
});
return (
<div>
<h1>{product.name}</h1>
<button onClick={() => updateMutation.mutate(newData)}>
Update
</button>
</div>
);
}
React Query 的优势：
- ✅ 自动管理缓存
- ✅ 自动重新获取（窗口获得焦点时、网络恢复时）
- ✅ 自动去重（多个组件请求同一数据时只发一次请求）
- ✅ 乐观更新、失败回滚
- ✅ 分页、无限滚动支持
- ✅ 内置 loading/error 状态
与 Zustand 的分工：
| 状态类型 |
工具选择 |
示例 |
| 客户端状态 |
Zustand/Context |
Modal switch, theme, form draft |
| 服务端状态 |
React Query |
User info, product list, order data |
重要的认知转变：
- React Query 不是"状态管理库"
- 它是"服务端状态同步工具"
- 服务端数据有特殊的生命周期（获取、缓存、失效、重新获取）
AI 友好度：⭐⭐⭐⭐
AI 生成 React Query 代码的特点：
- ✅ AI 能生成标准的 useQuery/useMutation 代码
- ✅ 常见模式（loading、error、success）AI 很熟悉
- ⚠️ 复杂的缓存策略 AI 可能生成不当
- ⚠️ optimistic updates 的逻辑 AI 容易出错
我的经验是：
- 让 AI 生成基础的 useQuery 代码：质量很高 ✅
- 涉及复杂的 cache invalidation：需要人工审查 ⚠️
- Mutation 的 onSuccess/onError 逻辑：AI 可能不够完善 ⚠️
SWR vs React Query
// Environment: React + SWR
// Scenario: SWR syntax (more concise)
import useSWR from 'swr';
function ProductList() {
const { data, error } = useSWR('/api/products', fetcher);
// Simpler, but slightly less powerful
}
对比：
| 特性 |
React Query |
SWR |
| 功能完整度 |
更强大 |
够用 |
| API 复杂度 |
稍复杂 |
更简洁 |
| 社区规模 |
更大 |
较小 |
| AI 生成质量 |
⭐⭐⭐⭐ |
⭐⭐⭐⭐ |
AI 对两者的支持：
- 两者都是声明式 API，AI 都能生成好
- SWR 更简单，AI 生成的代码更"干净"
- React Query 功能更强，但 AI 可能用不到高级特性
第四层复杂度：Redux 真的需要吗？
Redux 的定位
// Environment: React + Redux Toolkit
// Scenario: Modern Redux (already much simpler)
import { createSlice, configureStore } from '@reduxjs/toolkit';
// Slice: combines actions and reducer
const cartSlice = createSlice({
name: 'cart',
initialState: { items: [] },
reducers: {
addItem: (state, action) => {
// Redux Toolkit supports "mutable" syntax (uses Immer internally)
const existing = state.items.find(item => item.id === action.payload.id);
if (existing) {
existing.quantity += 1;
} else {
state.items.push({ ...action.payload, quantity: 1 });
}
},
removeItem: (state, action) => {
state.items = state.items.filter(item => item.id !== action.payload);
},
},
});
// Store
const store = configureStore({
reducer: {
cart: cartSlice.reducer,
},
});
// Use in component
function Cart() {
const items = useSelector(state => state.cart.items);
const dispatch = useDispatch();
return (
<button onClick={() => dispatch(cartSlice.actions.addItem(product))}>
Add to Cart
</button>
);
}
Redux 的优势：
- ✅ 强大的 DevTools（时间旅行调试）
- ✅ 严格的状态管理规范（适合大团队）
- ✅ 中间件生态丰富（redux-saga、redux-thunk）
- ✅ 社区最大，资源最多
Redux 的问题：
- ❌ 即使用了 Toolkit，代码量仍然多
- ❌ 学习曲线陡峭
- ❌ 简单功能也需要完整的流程
AI 友好度：⭐⭐⭐（中等）
AI 生成 Redux 代码的特点：
- ✅ Redux Toolkit 的 createSlice AI 能正确生成
- ⚠️ 但跨文件的关联（types、actions、selectors）容易出问题
- ⚠️ 中间件、异步 action 的逻辑 AI 容易生成过时的写法
- ❌ 大型项目的文件组织 AI 可能不够合理
我的实际体验：
我：用 Redux Toolkit 写个购物车
Claude：[生成 slice、store 配置...]
我：代码能用，但需要检查：
- 是否遵循了项目的文件组织规范？
- Selector 是否需要用 reselect 优化？
- 异步逻辑是否应该用 createAsyncThunk？
何时真正需要 Redux？
我的思考（不一定准确）：
✅ 适合 Redux 的场景：
- 超大型项目（100+ 组件，10+ 开发者）
- 需要严格的代码规范和审查
- 需要时间旅行调试
- 复杂的状态依赖关系
- 需要中间件（日志、埋点、权限控制）
❌ 不需要 Redux 的场景：
- 中小型项目（Zustand 够用）
- 快速迭代（Redux 太重）
- 团队 React 经验不足（学习成本高）
- 主要是服务端数据（React Query 更合适）
一个判断标准：
如果你不确定是否需要 Redux，那你可能不需要它。 — Dan Abramov（Redux 作者）
AI 协作的建议：
- 与 AI 协作时，Zustand 的开发效率更高
- Redux 需要更多人工审查和调整
- 除非项目确实需要 Redux 的严格性，否则优先 Zustand
决策树：如何选择状态管理方案
完整的决策流程
graph TD
A[需要管理状态?] --> B{状态类型?}
B --> |服务端数据| C[React Query / SWR]
B --> |客户端状态| D{使用范围?}
D --> |单个组件| E[useState / useReducer]
D --> |多个组件| F{层级关系?}
F --> |父子2层内| G[Props传递]
F --> |跨3层以上| H{项目规模?}
H --> |小型| I{数据变化频率?}
I --> |低| J[Context]
I --> |高| K[Zustand]
H --> |中型| K[Zustand]
H --> |大型| L{团队规模?}
L --> |小于5人| K
L --> |大于5人| M[Redux]
style C fill:#e1f5dd
style E fill:#e1f5dd
style G fill:#e1f5dd
style J fill:#fff4cc
style K fill:#d4edff
style M fill:#ffe0e0
方案对比表
| 方案 |
学习成本 |
代码量 |
性能 |
AI友好度 |
适用场景 |
| useState |
⭐ |
最少 |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
单组件状态 |
| Context |
⭐⭐ |
少 |
⭐⭐⭐ |
⭐⭐⭐ |
跨层级、低频变化 |
| useReducer |
⭐⭐ |
中 |
⭐⭐⭐⭐ |
⭐⭐⭐⭐ |
复杂状态逻辑 |
| Zustand |
⭐⭐ |
少 |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
全局状态（推荐） |
| React Query |
⭐⭐⭐ |
中 |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐ |
服务端数据（必选） |
| Redux |
⭐⭐⭐⭐ |
多 |
⭐⭐⭐⭐ |
⭐⭐⭐ |
大型项目、严格规范 |
我的推荐组合
小型项目（个人项目、demo）：
useState + Context + React Query
中型项目（几人小团队）：
Zustand (client state) + React Query (server data)
大型项目（跨团队协作）：
Redux (complex logic) + React Query (server data)
AI 协作优先：
Zustand (most efficient) + React Query
延伸与发散：AI 时代的状态管理思考
AI 生成代码的特点总结
通过前面的分析，我发现 AI 在状态管理方面有明显的倾向：
AI 擅长的：
- ✅ 模式统一的代码（Zustand、React Query）
- ✅ 单文件可见全貌（不需要跨文件理解）
- ✅ 声明式 API（useQuery、useState）
- ✅ 结构清晰的 Reducer
AI 不擅长的：
- ❌ 跨文件的依赖关系（Redux 的 actions/reducers 分离）
- ❌ 性能优化细节（Context 的 split、memo）
- ❌ 复杂的缓存策略
- ❌ 架构级别的决策（该用哪个工具）
AI 会"骗"你什么？
问题1：AI 可能推荐过于复杂的方案
你：帮我做个 todo list
AI：[生成完整的 Redux 方案]
实际：useState 就够了
为什么？
- AI 的训练数据中，Redux 的示例很多
- AI 倾向生成"完整"的解决方案
- 但不一定考虑你的项目规模
问题2：AI 可能忽略性能问题
// Environment: React + Context
// Scenario: AI generated Context code
const AppContext = createContext();
function AppProvider({ children }) {
const [user, setUser] = useState(null);
const [theme, setTheme] = useState('light');
const [cart, setCart] = useState([]);
// ❌ AI may not tell you: this causes all consumers to re-render
return (
<AppContext.Provider value={{ user, theme, cart, setUser, setTheme, setCart }}>
{children}
</AppContext.Provider>
);
}
应该做的：
// Split into multiple Contexts
const UserContext = createContext();
const ThemeContext = createContext();
const CartContext = createContext();
问题3：AI 可能生成过时的写法
// AI may generate old Redux pattern
const ADD_TODO = 'ADD_TODO';
function addTodo(text) {
return { type: ADD_TODO, text };
}
function todoReducer(state = [], action) {
switch (action.type) {
case ADD_TODO:
return [...state, { text: action.text }];
default:
return state;
}
}
// Actually Redux Toolkit's createSlice is more concise
如何与 AI 更好地协作
策略1：明确告诉 AI 项目规模
❌ Not good: Help me with state management
✅ Better: I'm building a medium-sized project (20 components),
need to manage user info and cart, use Zustand
策略2：要求 AI 说明选择理由
你：为什么选择 Redux 而不是 Zustand？
AI：因为你提到了需要时间旅行调试和中间件...
你：哦我不需要这些，那用 Zustand 吧
策略3：分步骤验证
-
让 AI 生成基础代码
-
自行检查性能和安全性
-
让 AI 优化特定部分（而非完全重写）
策略4：建立自己的代码模板
-
将已验证的优秀代码保存为模板
-
下次让 AI “基于此模板生成代码”
-
AI 将模仿你的模板，而不是使用其默认模式
未来的思考
问题：AI 时代，状态管理会如何演进？
我的一些猜想（不一定对）：
-
更简洁的 API
- AI 友好的工具会越来越流行（Zustand、Jotai）
- 复杂的样板代码工具可能被淘汰
-
智能化的状态管理
- AI 能否自动判断何时需要状态管理？
- AI 能否自动优化性能问题？
-
本地优先（Local-first）架构
- 离线优先的应用越来越多
- 状态同步会变得更复杂
- 需要新的工具和模式
-
AI 原生的状态设计
- 如果从一开始就考虑 AI 协作
- 状态管理工具会如何设计？
待探索的问题：
- Signals（SolidJS）会成为主流吗？
- 服务端组件（RSC）如何改变状态管理？
- AI Agent 执行多步骤任务的状态如何设计？
小结
这篇文章更多是我在 AI 协作开发中的思考和实践。
核心收获：
- 状态管理不是"选库"，而是"理解需求 → 选择合适方案"
- AI 擅长生成简洁、统一的代码（Zustand、React Query）
- AI 不擅长架构决策和性能优化
- 与 AI 协作时，人类需要把控方向，AI 负责执行
实用建议：
- 优先选择 AI 友好的工具（Zustand + React Query）
- 明确告诉 AI 项目规模和具体需求
- 审查 AI 生成的代码（尤其是性能和架构）
- 建立自己的代码模板，让 AI 模仿
开放性问题：
- 你在 AI 协作开发中遇到过哪些坑？
- AI 生成的状态管理代码，你会直接用还是会修改？
- 如果让你设计一个"AI 友好"的状态管理库，你会怎么做？
参考资料
登录
