AI 应用的性能直觉,前端工程师其实最敏锐——只是你还没意识到副标题:基于轻辔项目的真实工程实践,讲清前端工程师如何调试、选型、压成本、优化性能,把 Next.js Vercel AI SDK 这套栈的潜力榨干。一、AI 调试,跟传统调试不一样在哪?第一次调一个 AI 应用 bug 的人,大概率会在某个夜里崩溃一次。传统 bug 是确定性的:同样输入,同样输出,你打断点、看 stack、二分定位,总能找到。AI 应用的 bug 是这样的:同一个 prompt,昨天能跑通,今天跑不通同一个 prompt,A 用户跑通了,B 用户没跑通同一个 prompt,前 9 次都对,第 10 次模型突然瞎编你加了一句请更严格一点,其他 case 全坏了这种不确定性 bug,传统调试方法基本没用。但前端工程师有一项被忽略的优势:我们调过最难调的东西——浏览器。浏览器是一个由 V8、布局引擎、网络栈、用户输入、CSS 不确定性、第三方脚本拼成的混沌系统。我们调它调了二十年。这套手感迁移到 AI 调试上,成功率出奇地高。下面是轻辔里实际用过的几招,都能直接抄。二、调试方法论一:把AI当成组件来 observe调一个不确定的东西,第一步是让它先变得可观测。前端调一个 React 组件 bug,你会做什么?加 console.log、看 props、看 state、看 render 次数。AI 调用 bug,流程一模一样,只是变量名换了:prompt → props context → state model output → render result tool calls → side effects token usage → render cost轻辔里每一轮对话,Harness 钩子(src/features/chat/server/hooks/harness-audit.ts)都写一份结构化审计日志(JSON),记录:这一轮路由到哪个 mode、挂了哪些 Skill、用了哪个模型、花了多少 token、流了多久、出错没出错、子代理委托情况。每一条都带X-Request-Id,这是从前端 fetch 一直贯穿到模型响应的那个 trace id。前端 Network 面板看到的请求 id,服务端日志能查到完整链路。这是 AI 版的 React DevTools。实操建议:每一次模型调用都打 traceId(轻辔用X-Request-Id,在src/proxy.ts注入)prompt 和 response 完整存盘(脱敏后),不存就是耍流氓——出问题你拿什么复现token 用量当成性能指标看,跟 LCP / FCP 一样地盯流式中断 / tool 失败 / 超时,各自有独立事件类型,别都塞进 “error”这一套是前端早就在做的事,只不过维度变了。三、调试方法论二:复现,复现,还是复现AI bug 难调,80% 的时间不是花在找原因,是花在我能不能再让它出现一次。前端有一个百试百灵的招数:录制回放。Sentry 录用户操作,Cypress 录测试流程,Replay.io 录浏览器全状态。轻辔的等价物在pnpm harness:eval。这个命令做的事,本质就是prompt 回放:用例集在src/lib/harness/eval/cases.ts每个 case 是一段用户文本 期望的 plan(mode、capability、subagent)实现走plan-core.ts这条纯函数路径,完全不调模型,几秒跑完几百个 case也就是说,Harness 这一层(80% 的工程逻辑)可以像测纯函数一样测。改一行规则、跑一次 eval,绿不绿一目了然。模型那一层呢?那一层我们走的是模型替身回放:用户输入(原文 时间戳)路由决策(Harness plan)system prompt 完整内容(包括动态拼进来的 Skill 说明)历史 messages(原样)模型响应(原样,包括 reasoning)tool 调用序列任何一个 bug,都能用这堆数据原样回放。回放时把模型替换成读取上次的固定响应,就能在不调模型的情况下,复现整条链路。这是前端的肌肉记忆——快照测试。React 用了快十年的快照测试,在 AI 应用里换个名字叫prompt 回放,一模一样的味道。四、调试方法论三:二分,但是二分 promptAI bug 经常出在 prompt 上,但 prompt 一改全身,你不知道是哪一句让它疯了。前端最熟悉的方法论是git bisect——二分定位是哪个 commit 引入的 bug。prompt 也能这么干。轻辔的 system prompt 是动态拼装的(src/features/chat/server/compose-harness-system.ts):基础 system Harness 框架附录(GCCD/五关卡) 子代理附录 当轮挂载的 Skill 说明。每一段都可以单独切下来。具体步骤:把 system prompt 拆成几十个片段(目标、约束、Skill 说明、子代理说明、示例)写一个测试 case,跑当前 prompt,记录输出砍掉一半片段,再跑,看输出有没有变二分到引发问题的那一段改它我们项目有个小工具能批量跑 prompt 变体并 diff 输出,这是前端 A/B 测试基建在 AI 上的复用。五、选型:别看跑分,看你产品的真实输入模型选型这件事,网上一堆评测,但我看完没几个有用的。原因很简单:评测题目跟你产品没关系。轻辔对接四家:模型用途provider 文件Claude (Anthropic)主聊天 / 推理src/lib/ai/providers/anthropic.tsDeepSeek主聊天 / 推理(OpenAI 兼容)src/lib/ai/providers/deepseek.tsCursor AgentAgent 流(不走 LanguageModel)src/features/chat/server/stream-chat-cursor.tsSiliconFlow(硅基流动)媒体能力(转写、Wan T2V/I2V)src/lib/siliconflow/**为什么这四家?选型方法论完全是前端的——用真实流量去打。具体步骤:步骤 1:从生产日志挑 50 条真实 prompt不是构造的,不是 demo 的,是用户真用的。覆盖你产品的常见场景:闲聊 10、改代码 10、生图 10、长文档分析 10、边界 case 10。步骤 2:把这 50 条同时打给候选模型每家都跑一遍,记录:响应时间(p50 / p99)token 用量输出质量(人工打分,1-5)工具调用准确率(模型有没有正确选 Skill)失败率(超时、限流、内容拒绝)步骤 3:做一张表,做一个矩阵不是选最强的,是选最匹配场景的。轻辔最后的结论:闲聊和短问答:DeepSeek 性价比碾压复杂规划、写代码:Claude 综合最稳多步 Agent 任务、子代理委托:Cursor SDK 链路最熟媒体生成:SiliconFlow 性价比所以我们做的是多模型路由——用户输入进来,Harness 在编排层决定本轮用谁。前端工程师做 CDN 多源切换、做 API fallback,这套思维原封不动搬过来就行。步骤 4:每两周重跑一次模型迭代太快,上个月的结论这个月可能就过期。把这 50 条真实 prompt 当成AI 版的回归测试套件,定期跑一遍。这是前端做 visual regression test 的精神继承。六、成本优化:前端工程师天生擅长的事你以为前端跟成本无关?恰恰相反。AI 产品的账单,前端能省下大头。我列几条轻辔验证过有效的方法:1. 上下文裁剪默认大部分对话框会把全部历史消息发给模型。但 90% 的对话只需要最近 3-5 轮。我们做了一个上下文路由器(src/lib/chat/message-routing.ts):根据当前任务类型,只挂相关历史。代码任务挂代码相关的、闲聊挂最近几轮、新主题完全清空。这一下,平均上下文长度降了 60%。2. Skill 懒挂载工具说明本身要进 system prompt——每个 Skill 的 SKILL.md 几百到上千 token。如果默认挂 19 个,光是 Skill 说明就吃掉万级 token。轻辔的做法是关键词预筛(src/features/skills/keyword-routing.ts):用户文本里没出现画、“图”、video这些词,就根本不挂生图 Skill。这是前端 tree-shaking 的精神。3. 流式提前中止模型有时候在前 200 字就给出答案,后面是废话。useChatRunStreamReconnect这个 hook 配合特定场景的答案完整信号(比如代码块已闭合、且后续是套话),能触发 abort。省的不只是 token,还有用户的等待时间。4. Prompt Cache!Prompt Cache!Anthropic / OpenAI 都有 prompt cache——长 system prompt 命中缓存,价格能降到 1/10。但是要命中,system prompt 必须前缀稳定。这件事前端工程师做 HTTP cache 的时候做过一万次:变化的部分往后放,稳定的部分往前放。轻辔的compose-harness-system.ts里,system prompt 的拼装顺序是:[基础人格 始终生效的约束](稳定) ↓ [Harness 框架附录:GCCD / 五关卡](按 mode 组合,半稳定) ↓ [子代理附录](按 hint 组合,半稳定) ↓ [Skill 说明](按当轮路由组合,变化大) ↓ [历史 messages](最不稳定)把稳定的放前面、变化大的放后面,Anthropic / OpenAI 的 cache 命中率从 0 拉到 70%。直接省了一笔钱,而这件事完全是前端工程的功夫——你做过 CDN 缓存策略、做过 Service Worker 缓存,你就知道怎么排这个顺序。5. 廉价模型做路由Harness 路由 80% 走规则。剩下 20% 边界 case 让模型判断时,我们用最便宜的模型(Haiku、DeepSeek-V3)——一次判断几毫秒、几百 token——为后面的贵模型省下大量错误调用。前端做请求聚合、做 prefetch 的思路一致。七、性能:前端最该发力的地方最后聊性能。这一块前端工程师有降维优势,但很多人没用上。关键指标的对应关系:传统前端AI 应用FCP第一个 token 到达时间(TTFT)LCP第一段完整答复时间TTI用户能继续输入的时间CLS流式过程中布局稳定性INP中断/继续的响应延迟每一个都直接影响体验。每一个都可以前端优化。轻辔里几条最有效的:1. 流式渲染节流模型每秒可能吐 30-50 个 token,如果你每个 token 都触发 React 重渲染,中端机器就烫了。轻辔做的是16ms 批合并——一帧内到达的 token 合并成一次更新。ai-sdk/react的useChat在这件事上有内置策略,但你要再叠一层 RAF 节流。2. Markdown 增量解析完整 Markdown 解析是 O(n),每帧重解析就是 O(n²)。react-markdown不是为流式设计的,所以我们包了一层只对新增片段重新 parse、DOM 更新限制在新增节点的逻辑(src/lib/chat/stream-markdown-dedupe.ts顺手处理了重复标题问题)。3. 代码块语法高亮懒加载Prism / Shiki / highlight.js 都不小。轻辔的做法:Markdown 流式中先用pre占位,流式结束后再高亮。用户视觉上没差别,首帧渲染快了一截。4. 长会话虚拟列表聊到 200 轮的长会话不少见。react-virtuoso/react-window直接上,这是前端 10 年前就熟的事。5. Tab 不可见暂停轻辔有一条铁律(写在docs/轻量与简洁原则.md):生产环境零常驻 setInterval / 轮询。健康探活只在 busy / 断连时启动,任务结束立刻停;dev 自我修复 hook(use-chat-run-recovery)仅NODE_ENVdevelopment才挂载。document.visibilitychange切走立即停。pnpm dev:mem这个命令能直接列出当前next-serverRSS、.next/dev大小、node_modules占用——这是前端工程对本地资源占用洁癖的具体落点。6. SSE 重连有讲究SSE 断了怎么办?简单粗暴重连丢字。轻辔的useChatRunStreamReconnect(src/features/chat/client/use-chat-run-stream-reconnect.ts):// 关键逻辑constRECONNECT_COOLDOWN_MS2500;// 检查后台 run 是否仍可 replay,可以则 resumeStream()// 用户手动停止后(pauseReconnect)不自动重连带Last-Event-ID的断点续传——服务端按 ID 续发。这件事跟前端做断点续传上传是一个味道,但因为做了它,我们家 wifi 抖动一下,用户感觉不到。7. dev 内存优化Next.js 16 Turbopack 在 dev 态默认会占用大量内存,我们关了turbopackFileSystemCacheForDev,在pnpm dev前自动 prune.next/dev(脚本scripts/dev-prep.mjs),开发态内存压到 1.5–2.5GB 之间——这是另一个前端洁癖在 AI 项目里的胜利。八、自我演化:Skill 自己会长出来讲一个轻辔里很反直觉、但很值得抄的设计——skill_evolve这个 Skill。它的能力是:用户在使用过程中频繁触发某种没有专用 Skill 的场景,系统会建议把它沉淀成一个新 Skill。模型起草 SKILL.md 和 skill.ts 草稿,落到.self-update/隔离区(走 worktree),用户审过再 promote 到正式 catalog。这是不是有点像前端的 “ergonomics-driven refactor”——你写代码写多了发现某个组件每次都重写一遍,就抽出一个共享组件?是的。只不过这一次,提抽取建议的是 AI 自己。写保护(write-guard)在这条路径上同时生效——.self-update/是隔离 worktree,主分支永远不会被自动改。模型起草、用户审查、显式 promote,三步缺一不可。这套机制证明了一件事:前端那一套开放扩展、封闭修改的工程哲学,在 AI-Native 时代不仅适用,还能做出更激进的形态。九、给后辈的几条肺腑之言写到这里把一年多踩坑的体感浓缩成几条:1. 不要崇拜模型。模型是工具,跟 React 是工具一样。会用、用对、用够,比懂原理重要十倍。2. 也不要轻视模型。它会错、会瞎编、会失忆、会绕路。要像调试浏览器兼容性那样,假设它会出错,在外层做兜底——write-guard/harness:eval/Vault 加密都是这种AI 会犯错假设下的产物。3. 把每一次模型调用看成一次跨网络请求。会失败、会超时、会限流、会变慢。前端处理网络异常的所有经验都用得上——useChatRunStreamReconnect就是 fetch retry 在 SSE 上的对应物。4. 前端的性能直觉在 AI 时代比任何时候都值钱。用户对延迟的感知没变,但延迟变长了——你是中间唯一能补救的人。5. 多读源码,少读营销稿。AI 圈营销稿信息密度极低,但开源项目质量极高。轻辔自己用的就有 Vercel AI SDK 6、cursor/sdk、modelcontextprotocol/sdk、json-render/core——读源码你会发现 80% 是前端工程已经熟悉的模式(状态机、流、协议、插件、路由),剩下 20% 是新东西,值得花时间学。6. 自己用自己做的产品。轻辔团队每个工程师每天用自己做的工具写代码、查资料、做规划。每一次卡了一下、“这个按钮我找不到”——都是 issue。前端的工匠气在这里能直接变成产品力。写到这里,这三篇就完成了。如果让我用一句话收尾:AI-Native 工具不是模型的胜利,是工程的胜利。而工程的主场,从来都是前端。轻辔这个项目的代码不到 5 万行 TypeScript,没有 Python,没有自研模型,没有大规模训练成本——但它能把 Anthropic / DeepSeek / Cursor / SiliconFlow 四家模型统一编排起来,提供 19 个 Skill、五关卡执行链、本地加密 Vault、写保护、自我演化、harness:eval 回归。它证明的一件事是:你已经会的所有前端手艺,只要换一个对象,就能做出一个 AI-Native 工具。区别在于,这一次,你的组件会说话。