用 Agent 开发 React 项目，页面能打开之后还要检查什么？

让 Agent 做一个 React 页面，第一眼看着挺完整：布局有了，按钮也齐，终端没有报错。

接着多操作几下，问题才冒出来。搜索词已经换了，列表却跳回上一次的结果；数据更新了，旁边的统计数字还停在原地；请求失败以后，提交按钮一直转圈。

这时再丢一句“帮我修一下”，Agent 可能会继续加状态、补 Effect。眼前的问题消失了，组件里的执行顺序也更难看懂了。

所以，用 Agent 开发 React 项目，我更想把检查往前挪一点：写页面时就说明操作前后应该发生什么，改完再沿着这些变化去核对。

把一张页面，讲成一段操作过程

截图能说明按钮放在哪里，却很难说明按钮点下去以后怎么办。

交给 Agent 的需求里，我会多补几句：加载时还能不能继续操作？失败后要保留哪些输入？切换对象以后，上一份数据是否应该清空？这些信息不多，却决定了状态怎么设计。

比如检查一个带请求的页面，可以从这些动作开始：

这张表不是要求所有页面采用同一种行为。列表、表单、详情页各有自己的需要，关键是别把决定留给 Agent 猜。

也可以直接这样交代：

先把本次功能涉及的用户操作、状态变化和异常情况列出来，再实现。完成后按同一份操作清单检查；没有实际验证的部分，单独说明。

这样看结果时，就有东西可以对照，不必只盯着一张“效果不错”的截图。

状态变多了，先看看有没有重复记账

React 组件里出现好几个 useState，本身不是什么问题。我会让 Agent 解释的是：每一份状态分别在记什么，有没有两份其实是同一件事。

假设页面已经拿到了本地任务列表，旁边要显示未完成数量。可以直接根据列表计算：

// 组件内的片段：tasks 是当前已有的任务数组
const unfinishedCount = tasks.filter(task => !task.done).length;
const hasUnfinished = unfinishedCount > 0;

如果又给数量、是否有未完成任务各存一份 state，再用 Effect 同步，修改任务时就多了几处需要保持一致的地方。

这里的前提是：显示结果确实能从当前数据算出来。独立编辑中的表单草稿，或者服务端返回的全量统计，不能因为看着相似就一起删掉。特别是分页列表，当前页的数量不等于全部数据的数量。

React 官方的状态设计指南也强调避免冗余和重复状态。实际让 Agent 修改时，我会把要求写得更具体：

标出哪些值必须单独保存，哪些可以由当前 props 或 state 计算。先解释它们的关系，再决定是否增加状态或 Effect。

要检查的是数据有没有重复维护，而不是把 useState 的数量压到最少。

请求出了问题，顺着触发和返回各看一次

接口相关的问题，我通常会拆成两件事：请求为什么发出去，结果回来以后又改了什么。

先看触发位置。 点击“保存”才应该发生的提交，就沿着对应的事件处理逻辑找。把“用户点了保存”绕成“先更新一个状态，再由 Effect 观察状态并提交”，会让这次操作更难追踪。

而随当前查询条件变化去获取数据，是另一种需求。可以使用 Effect，也可以沿用项目已有的路由加载、数据请求 Hook 或缓存方案。不能把所有请求都搬到同一个位置。React 的事件与 Effect 指南解释的也是这个区别：先弄清执行原因，再选择实现方式。

再看返回顺序。 用户先选 A，紧接着改成 B。B 的请求先完成，A 却晚一步回来。如果代码收到什么就直接更新列表，页面可能又被 A 的结果覆盖。

这种问题不一定需要继续调接口参数。更值得让 Agent 检查的是：过期的请求结果，还能不能修改当前页面？

React 官方的数据获取示例介绍了在清理阶段取消请求或忽略过期结果的做法。具体到现有项目，先看已有请求工具是否处理了这些情况；关键是让旧结果失效，别再覆盖新状态。

给 Agent 的反馈，也可以从“搜索有 bug”改得更清楚一点：

先切到 A，再立即切到 B。让 A 的响应晚于 B 返回，检查最终页面是否仍然对应 B。修复后，用同样的顺序再验证一次。

另外，如果开发环境启用了根级 StrictMode，Effect 会额外经历一次设置、清理、再设置的检查。看到两次请求记录时，先确认是否与这段开发检查有关，再排查真实的重复触发。直接关闭 StrictMode，会把本来可以发现的清理问题藏起来。官方说明也明确，这个额外检查属于开发环境。

让 Agent 沿着同一个问题查到底

这类交互问题，往往要经历复现、读代码、修改、再复现几轮。每次反馈都把“刚才做了什么、实际发生什么、预期是什么”留下来，比不停追加“还是不对”更容易推进。

如果 Agent 正在排查这个问题，却因为模型请求失败停了下来，就需要另外检查开发工具的模型连接。使用支持自定义模型服务的编程 Agent 时，模型服务配置在开发工具里，帮助它分析和修改 React 项目。你的 React 应用本身不需要增加 AI 接口，模型密钥也不该放进前端代码。

在这条开发链路中，可恢复的模型通道异常可以交给模型服务处理。拿我们 XylemNode 的 Auto 分组来说，它会根据通道健康状态选择调用路径，通道异常时支持跨组重试，调用方继续使用原来的模型名称。通道就是处理模型请求的一条路径，这类能力能减少人工切换连接的操作。

前面说的 A、B 请求覆盖，则属于 React 页面自己的业务请求。Auto 不会替页面修复状态逻辑，也不会替 Agent 保管已经改过的文件。开发过程中如果中断，仍然要先核对文件差异和工具记录，再接着处理未完成的步骤。

最后，让 Agent 交代清楚：复现问题用了什么操作，修改了哪里，又用什么方式确认问题已经解决。项目已有相关测试，就补上这次暴露的行为；暂时只能手动检查，也把实际结果留下。

我觉得 Agent 真正省时间的地方，是能跟着一个问题走完这几步。页面能打开只是开始，连续操作以后，数据、提示和按钮状态仍然对得上，才更接近可以交付的功能。

作者：XylemNode 团队。

本作品采用《CC 协议》，转载必须注明作者和本文链接