
不少 React 项目发展到一定阶段，都会遇到一个问题：状态到底该放哪里。

最容易上手的答案通常是 Context。它不需要额外引库，接入成本低，语义也很直接，所以不少人会把登录信息、主题、权限、筛选条件、弹窗状态、列表缓存，甚至表单临时值都逐步放进去。

一开始看起来很顺，后面就开始变重。

## Context 真正适合什么

Context 更适合“跨层级共享，但变化频率不高”的信息，例如：

- 主题
- 语言
- 当前登录用户
- 权限配置

这些数据的特点是：

- 很多组件都要读
- 更新频率不算高
- 读比写更常见

如果一个状态既高频变化，又被很多组件订阅，那直接塞进 Context 往往不是最优解。

## 为什么一改就容易整片重渲染

Context 的根本问题不是“不能用”，而是更新粒度比较粗。

当 Provider 的 value 引用变化时，所有消费这个 Context 的组件都会参与更新判断。哪怕某个组件只用到了其中一个字段，也可能被连带影响。

例如：

```javascript
const AppContext = createContext(null);

function AppProvider({ children }) {
  const [theme, setTheme] = useState('light');
  const [keyword, setKeyword] = useState('');

  const value = {
    theme,
    setTheme,
    keyword,
    setKeyword
  };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}
```

这时只要 `keyword` 变化，所有使用这个 Context 的消费者都会受到影响。哪怕某个组件只关心 `theme`，它也逃不掉。

## 最常见的误区

### 1. 把“共享”误解成“全都共享”

很多状态其实只在局部页面或一个模块内使用，却因为“以后可能别处也会用到”，提前被提升成全局状态。结果是维护成本上去了，收益却没有同步增加。

### 2. 一个 Context 放太多字段

把用户信息、UI 状态、搜索条件、弹窗开关全塞进一个对象里，是性能和可维护性双输的起点。

### 3. 频繁变化的数据也放进 Context

输入框内容、拖拽坐标、滚动位置、实时筛选条件，这类高频状态更适合局部管理，而不是广播给全树。

## 更稳的做法：按职责拆 Context

比起“一个大 Context 包天下”，更好的方式通常是按职责拆分。

例如：

- `AuthContext`
- `ThemeContext`
- `SettingsContext`

拆分的价值不只是性能，还有一个更关键的问题是边界更清楚。你会更容易判断某个状态到底该归谁管。

```javascript
const ThemeContext = createContext(null);
const AuthContext = createContext(null);
```

当主题变化时，不应该影响认证相关消费者；反过来也一样。

## 局部状态优先，真的不丢人

不少团队做 React 架构时，容易把“提升状态”当成一种成熟感。但从长期维护来看，局部状态优先往往更健康。

判断一个状态该不该全局共享，可以先问：

1. 这个状态真的被多个远距离组件共同依赖吗？
2. 它的生命周期是否跨页面或跨模块？
3. 它的变化是否会影响多个功能域？

如果三个问题都答不上来，那它大概率不该进 Context。

## 需要更细粒度订阅时怎么办

如果你遇到下面这些问题：

- 某一类状态变化特别频繁
- 组件订阅需求很细
- Context 拆完还是觉得重

那就说明你需要的可能已经不是 Context，而是更细粒度的状态管理方案，比如 selector、store、局部订阅模型等。

重点不是“必须换某个库”，而是要承认 Context 的能力边界。

## 一个简单的经验法则

如果某个状态是“应用配置”，优先考虑 Context。

如果某个状态是“交互过程”，优先考虑局部状态。

如果某个状态是“频繁变化、多人订阅、依赖粒度细”，优先考虑更专业的状态管理方式。

## 写在最后

到了 2025 年，Context 仍然很好用，但它从来都不是“全局状态默认解”。稳定的 React 架构，不是把状态尽可能集中，而是把状态放到最合适的层级。

Context 适合共享，不适合滥用。只要这个边界清楚，项目后面会轻松很多。


React Context 性能优化笔记：2025 年还该不该滥用全局状态


React 里最容易写、也最容易写乱的东西之一，就是表单。

刚开始做简单输入框时，`useState` 足够直接。但一旦表单里出现下面这些需求，复杂度会迅速上升：

- 动态字段
- 联动校验
- 草稿保存
- 分步提交
- 错误提示
- 异步校验

这时如果还坚持“一个字段一个 useState”，代码很快就会失控。

## 最先出问题的通常不是校验，而是状态结构

很多表单越来越难维护，并不是因为规则复杂，而是因为状态没有分层。

一个更清晰的做法通常是把表单拆成三类状态：

1. 表单值
2. 校验状态
3. 提交流程状态

例如：

```javascript
const [values, setValues] = useState({
  name: '',
  email: '',
  company: ''
});

const [errors, setErrors] = useState({});
const [isSubmitting, setIsSubmitting] = useState(false);
```

如果把这些状态混在一起，后面几乎必然出现“改一个字段，顺手影响整个提交流程”的耦合问题。

## 表单值适合集中，交互状态适合分开

`values` 可以集中管理，因为它们本质上属于一份数据快照。

但像下面这些状态，不建议都塞进一个大对象里：

- 当前是否提交中
- 哪个字段正在异步校验
- 是否显示确认弹窗
- 当前步骤是否可前进

这些属于流程或 UI 状态，和表单值不是一个层次。

## 复杂表单更适合 reducer

当字段很多、更新动作明确时，`useReducer` 往往比一堆 `setState` 更稳。

```javascript
function formReducer(state, action) {
  switch (action.type) {
    case 'update_field':
      return {
        ...state,
        values: {
          ...state.values,
          [action.name]: action.value
        }
      };
    case 'set_errors':
      return {
        ...state,
        errors: action.errors
      };
    case 'set_submitting':
      return {
        ...state,
        isSubmitting: action.value
      };
    default:
      return state;
  }
}
```

`reducer` 的价值不只是“统一写法”，而是把状态变化变成显式动作，后面调试和扩展都会更容易。

## 校验不要写成“哪里触发就在哪里拼”

表单校验最容易烂掉的方式，是在 `onChange`、`onBlur`、`onSubmit` 里各写一份条件分支。

更靠谱的方式是：

- 把校验逻辑提成单独函数
- 明确区分字段级校验和表单级校验
- 不同触发时机复用同一套规则

例如：

```javascript
function validate(values) {
  const errors = {};

  if (!values.name.trim()) {
    errors.name = '姓名不能为空';
  }

  if (!values.email.includes('@')) {
    errors.email = '邮箱格式不正确';
  }

  return errors;
}
```

这样至少能保证规则只有一个来源，而不是散落在多个事件里各写一份。

## 异步校验一定要考虑竞态

很多表单会在输入用户名、邮箱、邀请码时做异步校验。

这类场景最容易出现的问题是：

- 用户输入 A，发请求
- 很快又输入 B，再发请求
- A 的结果后回来，把 B 的结果覆盖了

所以异步校验至少要考虑：

- 请求取消
- 只处理最新一次响应
- 加上最小防抖

否则你看到的并不是“校验结果”，而是“返回顺序”。

## 提交流程不要只维护一个 loading

很多表单最后只有一个 `loading` 状态，这在简单场景没问题，但复杂一点就不够了。

例如提交过程里可能有：

1. 本地校验
2. 图片上传
3. 主表提交
4. 成功回跳

这些阶段都叫 loading，等于没有信息。

更实际的做法是用阶段状态来表达：

- `idle`
- `validating`
- `uploading`
- `submitting`
- `success`
- `error`

一旦流程出问题，你会更容易定位卡在哪一步。

## 什么时候该用表单库

如果你的表单有这些特征：

- 字段数量多
- 规则复杂
- 需要和 UI 组件库深度整合
- 多个页面都有类似模式

那引入表单库通常是合理的。

但核心依然不是“为了用库而用库”，而是你是否已经清楚：

- 状态怎么分层
- 校验怎么组织
- 提交流程怎么表达

如果这些都没想清楚，换什么库也只是在换一种混乱方式。

## 写在最后

复杂表单的难点从来不只是输入和提交，而是状态、规则和流程三者的组织方式。

在 React 里，表单写得稳不稳，关键不在于用了多少 Hook，而在于你有没有把“数据”“校验”“流程”分开建模。只要这一步做对，后面的代码会清爽很多。


React 表单状态管理经验总结：复杂表单不该一路 useState 写到底


每隔一段时间，就会有人说 Prompt 工程不重要了。

理由也总是类似：

- 模型更强了
- 指令理解更好了
- 多模态更完整了
- 工具调用更成熟了

这些判断不算错，但如果因此得出“Prompt 随便写就行”，那通常会在业务落地时很快吃亏。

## Prompt 真正的价值，不是花哨，而是约束

一提到 Prompt 工程，想到的是：

- 角色扮演
- 语气模板
- 一长串提示词咒语

这些东西有时有用，但不是核心。

在真实业务里，Prompt 更重要的作用通常是三件事：

1. 定义任务边界
2. 约束输出格式
3. 降低不必要的自由发挥

大模型本质上非常擅长“补全一个看起来合理的答案”。如果你不给边界，它往往就会把“有帮助”理解成“多说一点也没关系”。

这在聊天场景可能还好，在业务系统里就不稳定了。

## 业务系统里的 Prompt，首先要解决“不要乱答”

比如一个工单分类系统，如果你的目标是输出固定标签，那么最重要的就不是“写得像资深分析师”，而是：

- 只输出枚举值
- 不要附加解释
- 信息不足时返回兜底项

例如：

```text
你需要判断用户问题所属类别。

可选类别只有：
- 退款
- 发货
- 售后
- 账户
- 其他

只返回一个类别名称，不要返回解释。
如果信息不足，返回“其他”。
```

这个 Prompt 的重点不是优雅，而是稳定。

## 输入结构比形容词更重要

不少 Prompt 效果不稳定，不是因为措辞不够“高级”，而是输入结构太乱。

例如下面两种写法：

```text
帮我总结这段内容。
```

和：

```text
任务：总结以下用户反馈
目标：提炼 3 条主要问题
输出要求：
1. 使用中文
2. 每条不超过 20 字
3. 不要复述原文

原始内容：
...
```

后者更稳定，不是因为字更多，而是因为结构更清楚。

在业务里，模型通常更怕“输入混乱”，而不是“提示词不够华丽”。

## 输出格式必须显式

如果结果要被后续程序消费，Prompt 里一定要明确输出格式。

例如：

- JSON
- Markdown 表格
- 固定字段列表
- 单标签结果

否则模型很容易：

- 多加说明文字
- 改字段名
- 改层级结构
- 在某些边缘输入下换一种表达

这些变化对人看问题不大，对程序来说却可能直接出错。

## 少承诺，多兜底

一个成熟 Prompt 的特征，不是“无论什么问题都答得像专家”，而是：

- 知道什么时候该回答
- 知道什么时候该拒答
- 知道什么时候该返回不确定

例如加入这样的约束：

- 如果缺少必要信息，明确说明信息不足
- 如果输入超出知识范围，直接返回兜底结果
- 不要猜测未提供的事实

这类约束看起来保守，但在业务里通常更值钱。

## Prompt 需要和系统设计一起看

Prompt 工程从来都不只是写一段文本。

在真实系统里，它通常要和下面这些东西一起设计：

- 上下文拼装
- 检索结果质量
- 工具调用协议
- 输出解析器
- 错误重试策略

如果上游上下文已经很差，Prompt 再精致也救不了。

反过来，如果上下文质量高、输入结构清晰、输出格式受控，Prompt 往往不需要特别花哨也能很稳定。

## 什么时候应该“少写 Prompt”

这点也很重要。

如果你发现一个 Prompt 越写越长，加入了大量例外条件、补丁规则和边缘说明，通常意味着问题不只是 Prompt 的问题，而是：

- 任务定义不清
- 类别设计有歧义
- 系统边界没划清
- 上下文输入不稳定

这时继续堆提示词，收益往往越来越低。

更有效的方式通常是回头改任务设计，而不是继续往 Prompt 里加 paragraph。

## 写在最后

到了 2025 年，Prompt 工程当然还重要，但重要的不是“提示词玄学”，而是约束设计。

如果你把 Prompt 当成系统边界的一部分，而不是一句自然语言指令，它的价值会非常稳定。真正好用的 Prompt，往往不是最花哨的，而是最清楚地告诉模型：

- 该做什么
- 不该做什么
- 输出必须长什么样


Prompt 工程在 2025 年还有价值吗：真正有用的不是技巧，而是约束


去年做一个 AI 写作辅助功能的时候，我们前后换了两次模型。第一次是因为结果不稳，第二次是因为延迟偏高。换完以后效果确实有变化，但那种“有时很好，有时很飘”的感觉一直没有消失。

最开始团队里很自然地把问题归到模型头上。毕竟结果是模型吐出来的，出问题先怀疑模型很正常。可后来排查得越多，我越觉得另一个东西更像根源：上下文。

那个功能的目标并不复杂，用户给一个主题，系统结合历史记录、模板偏好和参考资料，帮他起草一段内容。听上去很像是一个“选模型 + 写 prompt”的问题，实际做下来，最难控的反而是给模型喂什么。

## 我第一次意识到问题不在模型，是在一次线上回放里

那次用户问的是一个非常具体的问题，理论上系统应该直接围绕当前主题写。结果模型先引用了上一次会话里的偏好，又混进了一段不相干的参考资料，最后写出来的内容语气对、格式也对，但方向完全偏了。

如果只看最终结果，你会觉得是模型在胡说。可把整条输入链路拆开看，其实它只是很认真地在错误材料上做推断。

那一刻我才真正意识到：模型根本不“知道自己在哪个产品里”，它只知道当前这坨上下文长什么样。

你给它干净输入，它就大概率干净输出。

你给它混乱输入，它再强也很难一直稳。

## 上下文管理最容易出问题的地方，不是少，而是乱

最开始我们总怕模型信息不够，于是策略非常朴素：尽量多给。

历史对话带上。
用户偏好带上。
参考资料多拿几段。
系统规则写长一点。
模板说明也顺手塞进去。

表面上看很周全，实际效果却越来越不稳定。后面回头看，这种“尽量多给”的思路有两个明显问题。

第一，重要信息比例被稀释了。

用户当前真正的问题，可能只占整个上下文的一小截。模型当然能看到它，但也同样看到了很多次要甚至过期的信息。

第二，旧信息会持续污染新任务。

一旦历史里有过错误判断、过时意图或者已经无效的中间结论，它们就可能继续影响当前回答。你以为自己是在做“多轮记忆”，实际上是在把噪声不断续上去。

## 后来我们做的第一件事，不是换模型，而是拆信息层级

那次改完之后，我们不再把所有信息简单拼成长文本，而是先把上下文按层次拆开。

我现在做 AI 应用时，基本都会先把输入分成这几层：

1. 系统规则
2. 当前任务目标
3. 用户本轮输入
4. 历史记忆
5. 外部检索或工具结果

这几层最重要的价值，不是格式好看，而是你终于能问自己一句：这个信息到底为什么出现在这里？

比如：

- 系统规则是长期边界，不该混进具体任务噪声
- 当前任务目标应该比历史会话优先级更高
- 历史记忆只保留必要背景，不该变成聊天记录堆积
- 检索结果必须为当前问题服务，而不是“顺手都带上”

一旦这么拆，很多以前糊在一起的问题会立刻显形。

## 历史记忆不是越长越好，这一点我后来感受很深

做对话型 AI 功能时，最容易陷进去的就是“记忆越多越聪明”。

实际并不是这样。

我们后面专门抽了一批失败样本看，发现最容易出问题的往往不是信息太少，而是带着一堆不该留下来的历史过程：

- 上一轮试错里的错误结论
- 已经被用户否定的方向
- 某次临时偏好
- 中间工具返回的半成品数据

这些东西只要留在上下文里，模型就有可能继续把它们当真。

后来我们把历史记忆改成“只保留长期偏好和关键事实”，效果反而稳了很多。比如保留：

- 用户偏好中文输出
- 用户正在做 React 项目
- 当前会话在写技术博客

而不是把整段过程都背下去。

## 检索上下文也一样，重点不是多，而是贴题

RAG 场景下这个问题会更明显。

以前我们的做法是召回多一点，觉得总比漏掉好。结果经常出现一种情况：模型拿到了十段资料，里面只有两段真有用，剩下八段只是“看着也有点关系”。这些噪声不会直接报错，但会把注意力拉散。

后来我越来越认可一个更朴素的判断标准：

- 这段内容是不是和当前问题强相关
- 它能不能减少模型猜测

如果答案都是否定的，那它就不该进上下文。

这也是我现在看检索系统时最在意的地方。它不是负责“多给内容”，而是负责“别把不该给的内容也塞进去”。

## 工具调用结果如果不清洗，也是在制造噪声

另一个很容易被低估的点，是工具结果。

很多 Agent 类应用会把工具输出原样拼回模型，图省事，但这一步经常会埋雷。

例如一个搜索工具可能返回：

- 大量无关字段
- 多个候选结果
- 冗长元数据
- 不统一的格式

模型当然可以继续读，但这等于又把一轮筛选工作丢给它了。这样不只是浪费上下文窗口，更会让后续推理开始飘。

我们后来处理工具结果时，会先做一轮清洗：

- 只保留关键字段
- 统一格式
- 必要时做小摘要

这一步做完之后，模型输出明显稳了一截。不是因为它突然更聪明了，而是因为前面的输入终于更像人给它整理过的材料。

## 我现在看 AI 应用，越来越像在看一个信息编排系统

以前我会更多地把注意力放在模型本身：哪个版本更强，哪个延迟更低，哪个价格更合适。

现在还是会看这些，但我更先问的是：

- 当前任务到底需要哪些信息
- 这些信息谁先谁后
- 哪些该长期保留，哪些只对本轮有效
- 哪些内容可能污染后续回答

如果这些问题没想清楚，换再好的模型也很难彻底解决“有时很好，有时很怪”的波动。

## 写在最后

我现在越来越相信，AI 应用里真正难的，不是把模型接上，而是把上下文管住。

模型当然重要，但很多所谓“模型不稳定”的问题，最后都能追溯到输入组织得不够干净。谁能把对的内容、按对的层级、在对的时机交给模型，谁的系统通常就更稳。模型选型会变，上下文治理能力才是更长期的竞争力。


做 AI 应用时，为什么上下文管理比模型选型更容易决定成败


AI 应用最容易被高估的阶段，就是 Demo 阶段。

因为 Demo 天然会挑选：

- 最能体现效果的输入
- 最干净的上下文
- 最理想的执行路径

这当然能说明“系统有潜力”，但说明不了“系统已经稳定可用”。

真正要落地，一个更现实的问题是：这个系统在反复运行、面对不同输入、进入边缘场景后，还能不能保持可接受质量。

## 为什么演示效果不等于真实效果

原因很简单，真实业务里的输入不会像 Demo 一样配合你。

真实用户会：

- 描述不完整
- 问题跳跃
- 混用口语和专业词
- 给出错误信息
- 连问多个目标

如果评估数据过于理想，最终得到的不是能力判断，而是乐观幻觉。

## 有意义的评估至少要看三件事

### 1. 准确性

系统答得对不对、分类准不准、提取结果是否符合事实。

### 2. 稳定性

同类输入下输出是否波动过大，是否经常忽好忽坏。

### 3. 可复现性

你是否能解释为什么这次成功、下次失败，以及失败集中在哪些场景。

如果只有准确率，没有稳定性和可复现性，那系统仍然很难真正用于业务。

## 建评估集时，不要只挑“漂亮样本”

评估集最好至少包含三类数据：

- 常规样本
- 边缘样本
- 对抗样本

常规样本保证你知道系统在主流程里的表现。

边缘样本保证你知道它在复杂输入下的下限。

对抗样本则能帮助你发现：

- 容易误判的词
- 容易被带偏的提示
- 容易失败的工具调用路径

如果只评估“漂亮样本”，最后上线时通常会被现实教育。

## 评估指标要贴近任务本身

不少团队会问：AI 应用到底该用什么统一指标？

其实大部分时候没有统一答案，因为任务不同，指标就不同。

例如：

- 分类任务看准确率、召回率、误判类型
- 提取任务看字段正确率、漏提率、格式合法率
- 问答任务看事实一致性、引用命中率、拒答合理性
- Agent 任务看任务完成率、路径长度、失败恢复率

真正关键的是：指标能不能反映业务风险。

## 评估一定要带失败分析

很多报表会给出一个总体分数，比如 82%、87%、91%。

这对趋势判断有用，但不够指导优化。

更关键的是把失败分出来看：

- 是检索错了
- 是上下文污染了
- 是 Prompt 边界不清
- 是工具参数传错了
- 还是模型本身就难以处理

只有把失败原因拆开，你才知道下一步该优化哪里。

## 人工评估仍然有价值

虽然大家都想自动化评估，但在很多任务上，人工评审仍然非常重要。

尤其是这些场景：

- 输出质量很主观
- 结果不只是对错，而是好坏程度
- 需要结合业务背景判断

自动评估适合规模化监控，人工评估适合建立判断标准。两者最好结合，而不是互相替代。

## 一个更实用的目标：持续评估，而不是一次评估

AI 应用不是“测完一次就结束”的系统。

因为它依赖的很多变量都会变：

- 模型版本
- Prompt
- 检索内容
- 工具输出
- 用户输入分布

所以真正稳的做法是持续评估：

- 新版本上线前回归
- 核心样本集定期复跑
- 线上失败样本持续回灌

只有这样，你才知道系统是在进步，还是只是“碰巧这周看起来不错”。

## 写在最后

AI 应用评估最怕的不是分数低，而是评估方式本身无法反映真实能力。

如果你只看演示效果，很容易高估系统；如果你开始看稳定性、失败分布和可复现性，才算真正进入工程阶段。能不能落地，实际开发中不取决于最好的那次表现，而取决于最差的时候系统还能不能被信任。
