说实话，这事儿听起来有点像科幻小说里的桥段。前阵子我遇到一个让人头秃的性Neng瓶颈，那个业务工作台页面一打开，内存就像坐了火箭一样直冲云霄，差点把我的浏览器给干崩了。实在没招了我把这烂摊子丢给了一个大模型，然后心安理得地去午休。等我端着咖啡回来屏幕上不仅显示着问题Yi定位，连代码dou给我改好了。这哪是辅助工具，简直就是个随叫随到的资深架构师。

今天咱们不聊虚的，就来复盘一下这场“人机协作”的硬核排查过程。kankan当AI真正接管浏览器，开始自己跑Playwright、自己kanTimeline的时候，我们以前那些苦哈哈的手动调试日子，是不是真的要一去不复返了。

当内存飙升到900MB：午休前的绝望时刻

事情起因hen普通，甚至有点老套。我手头这个后台工作台页面逻辑稍微有点复杂。页面主体大概Ke以拆解成三个核心区域，数据流转非常密集。Zui要命的是这不仅仅是一个简单的“填完表单点搜索就结束”的页面而是多个区域dou会读写同一套查询状态。这种架构设计，稍有不慎就会埋下隐患。

那天下午，我刚刷新页面Chrome的任务管理器就给了我当头一棒。内存占用直接飙升到了900MB左右，而且这高水位一直维持着，直到大概30秒后才慢慢回落到正常水平。虽然我知道这30秒后回落的现象确实存在可Neng是垃圾回收机制在起作用，但这次排查的重点不是解释“它为什么回落”，而是先找出“为什么峰值会被顶到这么离谱”。因为哪怕后面会掉下来开发态里先冲到900MB也足够把热geng新和页面稳定性一起拖垮了。

我盯着屏幕发了一会儿呆，心里盘算着又要开始漫长的Performance面板分析。就在那一瞬间，我鬼使神差地想：既然现在大模型这么火，为什么不试试让它自己来搞定这事儿？

把问题描述变成“可执行指令”

hen多人用AI辅助编程失败，原因往往在于提示词太模糊。比如你问“为什么我的页面hen卡”，它大概率只Neng给你一堆通用的优化建议。但这次我决定换个思路，把大模型当成一个会用浏览器、会自己验证结果的工程执行者，而不只是一个会聊天的分析助手。

我给它的信息其实hen朴素，但非常具体：

场景定义页面是一个业务工作台页面现象是内存大约900MB、30秒后才回落。

Yi知范围Yi知范围是查询表单，我Yi经查到是查询表单导致的，但具体原因还没找到。

证据入口证据入口是bootstrap.tsx里那段内存日志，要求它必须直接用Playwright打开页面去kan，而不是只给我猜测。

Ru果你以后也想照着Zuo，输入里至少要把几件事说清楚。不要说“帮我kankan”，要说“这是一个带复杂查询联动的后台页面现象是页面打开后内存升到900MB左右，30秒后才回落。我Yi经确认问题大概率和查询表单有关。证据入口是启动入口里的内存日志。请你先用浏览器复现，再定位原因，改完以后给我修复前后的对比数据。”

AI的排查路径：从猜测到实证

把指令发出去后我就去睡觉了。但事后kan日志，它的操作流程简直比hen多初级工程师还要规范。它没有在整页里乱翻，而是顺着“查询表单”这个线索，一步步把链路串了起来。

第一步：用Playwright建立基线

它没有上来就瞎猜代码逻辑，而是先拿/indexZuo基线。通过Playwright自动化脚本，它确认首页内存大约在110MB到127MB之间。这个数据非常关键，说明不是整个站点天然就高，也不是浏览器环境有问题，问题就出在那个具体的工作台页面上。

接着，它让Playwright打开那个业务工作台页面。hen快，异常就被稳定复现出来了：内存一路冲到839MB到887MB之间，并且一直到30秒左右才掉到79MB左右。到这一步，问题就从“感觉不对”变成了“机器也Neng稳定kan到”的数据事实。

第二步：顺藤摸瓜，锁定Formily

既然问题大概率率和查询表单有关，它就开始审查表单的实现细节。这里有个背景：我们的项目里用了Formily这个表单库，配合ZustandZuo状态管理。

这里先补一句：为什么问题会收敛到query form？因为不同模块dou想访问同一个表单实例，Zui容易出现“顺手把form放进全局store”这种设计。这kan起来hen方便，全项目douNeng拿到form实例，但这其实是个巨大的坑。

AI在分析代码时发现，Formily form这种重量级运行时实例，本来就不适合放进会被devtools观察、快照和序列化的store state。而devtools又把这个问题放大成了900MB级高峰。所以这事不是“表单字段太多”，而是“重对象被放错了位置，而且被devtools放大了”。

第三步：理解DevTools的“副作用”

这里有个技术细节值得展开说说。我们在开发时习惯开启Redux DevTools或者Zustand DevTools，它们会自动对store里的state进行序列化以便展示时间旅行调试功Neng。

但是form不是一个轻量对象，它里面带着大量字段状态、reaction、effect、schema和联动信息。一旦进了store，又被devtools观察、快照、序列化，内存就会被瞬间放大。这就像你只想搬一个箱子，结果箱子里不仅装满了书，还连着整个图书馆的书架系统，一搬起来整个屋子dou塌了。

根因与修复：划清“轻”与“重”的边界

确定根因之后它没有停在“给建议”，而是直接把代码改了。这种改法本质上是在重新划清边界：轻状态进store，重实例不要进会被调试链路持续观察的状态面。

修复前的代码逻辑

在修复前，查询表单把Formily form直接塞进Zustand store state。这意味着每次状态geng新，DevToolsdou要尝试序列化这个庞大的对象。这也就是为什么我们在Performance面板里Nengkan到大量的红点，那是Chrome给出的可Neng的性Neng瓶颈点，在它下面绿色的起伏状线条则是浏览器在那时的帧频，可见非常之低。

修复后的代码逻辑

修复后store state里只保留轻量的hasForm，真正的Formily实例改成闭包保存，通过getForm按需读取。再把依赖state.form的地方一起改掉。

geng准确地说这里的问题不是“Zustand绝对不Neng放Formily对象”，而是要避免把这种重量级运行时实例暴露给需要深度序列化的中间件。通过闭包保存实例，这个对象依然存在依然Ke以被访问，但它不再进入store state的快照和调试链路。真正重新划清的边界就在这里：数据状态和运行时实例，本就该分道扬镳。

验证结果：数据不会撒谎

改完代码，它没有急着交差，而是又回到同一个页面再用Playwright复验一遍。这一步非常关键，也是我们平时容易忽略的。

修完之后页面打开时的内存降到了165MB到207MB，30秒左右会进一步降到96MB左右。也就是说这不是“kan起来像修好了”，而是前后数据Neng直接对上。整个排查、修改和验证的闭环，大约就用了十来分钟。

这里的数字口径dou来自同一套页面内存日志采样，重点是kan同一页面、同一种采样方式下的前后差异，不是拿它去Zuo跨页面的精确内存对账。虽然这里的数字来自页面里Yi有的内存日志采样，主要用来Zuo同一场景下的前后对比，不是一份精确的heap profile，但这个降幅Yi经足够说明问题了。

一句话说这次真正Neng抄作业的地方就是：把大模型当成一个会用浏览器、会自己验证结果的工程执行者。那个Zui扎眼的“900MB级内存高峰”，确实被打下来了。

反思：如何评估大模型的工程Neng力？

这次经历让我对“如何评估微调后的盘古大模型是否正常”或者geng广泛地“如何评估AI Agent性Neng”有了新的理解。评估模型效果的方法有hen多，通常Ke以从Loss曲线、模型评估功Neng等方面去考量。但在实际工程场景里闭环Neng力才是核心。

它Zuo的事情其实hen像一个靠谱的前端同学在接手问题：

先复现，不瞎猜。

kan数据，凭证据说话。

改代码，兼顾架构合理性。

Zuo验证，确保修复有效。

这类输入的核心不是“怎么把提示词写得像魔法”，而是把问题描述成一个Ke以执行、Ke以验证、Ke以收敛的任务。Ru果你懒得自己组织，Ke以直接按那个Zui小模板来但一定要记住把上下文交代清楚。

当然这也不代表把实例移出state就万事大吉了后面依然要按组件生命周期处理好它的创建、读取和清理。闭包保存实例也不是说这个对象突然就不存在了只是它换了一种geng隐蔽、geng安全的方式存活。

未来的开发模式：AI与浏览器的深度耦合

Zui近遇到不少类似的问题，从浏览器时频繁遭遇页面卡顿、无响应，到远程调用本地大模型的网络配置。我自己在尝试了多种组合后发现这种让AI直接操作环境的方案，是目前解决复杂问题Zui高效的路径之一。

以前我们排查问题，可Neng要手动打开Chrome Performance窗格，kan页面何时导致强制同步布局，分析Web的布局模型中元素之间的相互影响。现在这些脏活累活，完全Ke以交给AI去干。它完美地解决了“模型在本地，访问在云端”或者“逻辑在AI，执行在浏览器”的核心矛盾，让AI开发环境真正具备了移动性和执行力。

这次Zui值得复用的，不是一条具体的性Neng结论，而是这套工作方式：让大模型配合浏览器，自己完成复现、排查、修改和验证。当采样至一定的时间段后点击暂停，浏览器会生成图表，发现红点，分析瓶颈……这些以前需要我们盯着屏幕揉眼睛的活儿，现在douNeng自动化了。

所以回到 刚睡醒，大模型Yi排查完页面性Neng问题？这不再是天方夜谭。只要你把任务描述得足够清晰，把工具链给它配齐，剩下的，真的只需要去睡个午觉就够了。当然醒来后记得检查一下代码，毕竟作为工程师，我们还是要对Zui终交付的质量负责，不是吗？

---