Harness Engineering落地前先想清楚这几个问题传统数据中台往往系统功能强大但门槛也是真的高。对于熟悉数据分析、SQL、指标体系的用户来说数据中台是效率工具。但对于更多的新手/小白用户来说它更像是一套需要先学会使用才能开始解决问题的系统。用户需要知道数据在哪、表怎么关联、SQL 怎么写、结果怎么看甚至还要理解图表配置和看板搭建逻辑上手成本那是相当高。近两年 AI 带来了近乎完美破局路径自然语言提问 → 生成 SQL/Python → 查询数据 → 展示数据 → 可视化图表。这条链路的价值不只是帮用户写 SQL更重要的是把原本需要专业知识才能完成的完整数据分析流程改造成了更自然的对话式交互门槛大幅降低。Dola 将这条链路跑通之后在持续打磨产品体验的过程中前端很快暴露出两类全新的问题一类是AI产品形态变了传统前端架构跟不上另一类更隐蔽——当我们开始大量用 CodeBuddy、Cursor 来协作开发时发现多年来习以为常的优雅写法在 AI Coding 协作中反而成了拖累。这两类问题逼着我重新思考前端在 AI 时代的定位。结论很简单也是这篇文章想聊的两件事第一件事服务好 AI 产品 —— 当产品形态变了前端架构必须跟着变第二件事服务好 AI Coding —— 当协作对象变了编码范式也有必要跟着变插个题外话随着 AI 破局而出世的还有我们 PCG 大数据平台部的新一代数据分析 AI 助手——DolaDola 是一款基于 Agentic AI 能力开发的数据分析助手用户只需要引入个人的数据表就能得到一枚专属的 AI 分析师。它不仅能够完成日常的取数、跑数等基础任务还能自主规划并执行复杂场景的数据分析例如异动归因、画像对比分析、股票基金回测、房价预测等。Dola 可以自行编写 SQL、纠正 SQL 错误、执行查询、使用 Python 进行数据处理与可视化并最终生成一份完整的分析报告。全程无需编写一行代码只需通过自然语言对话你就能拥有一个全自动工作的数据小黑工。这里以 1 个股票回测的例子看看 dola 的效果可以看到 dola 在接收到金叉买入法回测这个问题之后首先能自己生成一个计划包括了需要进行的数据准备、策略实现、回测实现和结果分析等详细内容。在按照自己的计划执行完毕后dola 最终产出回测结果完成可视化并进行深入分析总结产出一份完整的回测报告。同时还可以将分析的报告做成一个美观的可视化插画/静态网页/看板大大增加了报告的可读性上图左为 Dola 生成的插画报告右为静态网页。仅做样例展示参考不构成分析建议这里只是以股票回测这样一个比较复杂的案例场景展开大家应该可以想象到在工作场景中Dola 对于日常数据分析工作的提效程度是显而易见的。回到本期主题对前端开发新范式感兴趣的同学欢迎接着往下阅读01 服务好 AI 产品之一AI 数据分析可视化优化这条链路里自动生成可视化图表是用户感知比较强的环节。因为用户最终并不是为了看一段 SQL也不是为了看一张原始表格而是希望快速理解分析结论。图表推荐得准不准、展示得清不清楚直接决定了用户对AI 数据分析的第一印象。1.1 让大模型直接生成图表配置最自然的做法是让大模型在生成完 SQL、拿到数据之后再吐一份图表配置出来。实际尝试之后碰到两个绕不开的问题生成速度慢、复杂图表配置容易出错。所以我们考虑把策略改成工程化推荐 大模型微调。也就是前端基于已有上下文快速给出推荐配置用户立刻就能看到一张相对合理的图如果不满意再让 AI 介入修改。这样既能拿到工程化的速度和稳定性也能保留 AI 的灵活性。1.2 主流图表推荐库为什么不够用要做工程化推荐第一反应是看看业界已有方案能不能直接用。我们调研了 AntV/AVA 这类主流图表推荐库结论是——在我们的场景下不太够用。这类库的核心思路是完全基于数据特征推荐图表看字段类型、看字段数量、看基数、看分布然后匹配规则。这个思路在传统 BI 场景里是合理的。用户上传一份 Excel或者手动选择了表系统不知道用户在想什么只能从数据特征出发猜一个相对合理的图表。但放到 AI 对话数据分析链路里这套假设就不太成立了。比如 AI 生成了一段 SQL。SELECT查询结果包含 date 、 channel 、 gmv 、 order_count 、 conversion_rate 五个字段。仅看字段类型可以判断出一个时间字段、一个分类字段、三个数值字段。那应该推荐什么图用户想看 GMV 趋势看不同渠道的 GMV 对比看转化率随时间的变化还是看 GMV 和订单数的关系只看数据特征传统库只能挑一个最常见的方案比如默认按时间画折线图把所有数值字段都画上去。但这不一定是用户真正想看的。也就是说仅凭数据特征不一定能准确推断出用户的分析意图这导致图表类型、维度、度量的推荐准确率都偏低。1.3 其实我们手里其实有更多上下文当我重新审视这条链路后发现和传统 BI 场景相比AI 对话数据分析场景有个巨大的优势前端拿到的上下文更完整。在图表绘制之前除了数据本身对话上下文里还能拿到生成数据的 SQL以及用户的原始 prompt。这正好能增强传统方案里用户意图识别这块的不足SQL 里藏着维度、度量和意图SQL 不只是拿数据的工具它本身就是一份结构化的分析意图描述。举几个直接的例子GROUP BY dt → 用户想看的维度很可能就是 dt 而不是其他分类字段ORDER BY gmv DESC LIMIT 10 → 这是典型的 TopN 分析柱状图比折线图更合适SUM(gmv) 、 COUNT(DISTINCT user_id) → 这些聚合函数本身就是度量不需要再去字段里猜WHERE dt BETWEEN 2026-04-01 AND 2026-04-30 → 时间范围明确趋势分析的可行性高出现 SUM(a) / SUM(b) → 计算字段往往是核心关注指标应该优先作为主度量这些信息在传统 BI 场景里完全拿不到但在 AI 链路里缺是天然可见的。用户 prompt 里藏着分析目标用户的原始问题里也经常包含意图关键词趋势、变化、最近一个月 → 倾向时间序列对比、哪个更高、排名 → 倾向分类对比占比、构成、比例 → 倾向饼图、堆叠图分布、区间 → 倾向直方图、箱线图下降最明显、异常 → 倾向带标注的对比图。同样是查 GMV用户问最近一个月各渠道 GMV 趋势和最近一个月哪个渠道 GMV 下降最明显SQL 结果可能完全一样但期望的图是不一样的。如果只看数据这两种意图就被抹平了。如果把 prompt 也纳入推荐它们就能被区分。1.4 三维评分推荐引擎基于这个思路我尝试开发了图表三维评分推荐工具。核心思路是维护一套评分机制把 数据特征 SQL 特征 Prompt 特征 综合起来给候选图表打分最终推荐得分最高的图表类型并生成配置。评分规则覆盖时间趋势、分类对比、占比分析、TopN、分布、相关性、多维探索等典型分析任务每条规则都会从三个维度出发综合判断。举个简化的规则示例——时间趋势规则数据特征存在时间字段且时间点数量适中 → 分SQL 特征 GROUP BY 中包含时间字段或 ORDER BY 时间字段 → 分Prompt 特征包含趋势、变化、增长、下降等关键词 → 分反向条件分类字段基数极高且 prompt 偏向对比 → -分。分类对比规则类似数据特征存在低/中基数分类字段 至少一个聚合度量 → 分SQL 特征 GROUP BY category 、 ORDER BY metric DESC LIMIT N → 分Prompt 特征包含对比、哪个、排名、TopN → 分。每条规则不会单独决定推荐结果而是统一汇总到打分模型里择优输出。效果上复杂多维数据场景下推荐准确率从 55% 左右提升到近 90%对维度和度量的识别准确性也明显提升。1.5 几个有用的特色能力在评分推荐之上还做了一些工程层面的细节体验差异其实主要来自这些地方。比如支持交互式二次探索。再比如数据量大的时候自动开启采样和缩略图导航、多度量量纲差异大的时候自动启动双 Y 轴、数值字段方差极大的时候自动启用对数坐标等这些规则看似琐碎但对最终展示效果影响很大。在 Dola 项目中如果对工程化推荐还是不满意用户可以通过 AI 直接改配置——这时大模型只需要在已有配置基础上做局部修改速度快、准确性也更可控。做完这些之后我自己的体感是AI 把自然语言变成 SQL、把 SQL 变成数据已经干了最重的活。但用户最终看到的不是 SQL 也不是数据表而是那张图。这一步与其再让大模型推一轮不如交给前端用工程化的方式收尾——快、稳、准。02 服务好 AI 产品之二LLM 流式对话代码展示体验攻坚这一章想聊的事其实可以用一句话概括当产品形态从静态展示变成流式增量输出渲染架构的底层假设也得跟着重写。下面是我们一路踩坑的过程。2.1 Markdown 流式选中复制问题最早的用户反馈很朴素——AI 正在回答的时候我想把上一段复制出来一松鼠标选区就没了。这是早期 AI 大模型对话产品的通病原因是传统 Markdown 解析工具并不是为流式输出设计的在流式过程中频繁 re-render 导致 Selection API 引用失效。这个问题我们团队小伙伴通过在 Markdown 渲染层做增量输出解决了——让 DOM 在流式过程中尽量只追加、不重建。以为就此结束但很快发现代码块的增量渲染是另一个量级的难题。2.2 代码高亮的增量渲染几乎无法实现主流代码高亮库 highlight.js、Prism、Shiki 等也都是为已经写好的代码设计的每次调用都吐出一整棵span树由调用方用 innerHTML 替换回去。流式场景下每个 chunk 到达时都触发一次完整重写用户的选区、搜索命中、光标位置在每次重建时瞬间清空。我们调研过给这些库打增量补丁结论是着色与 DOM 的耦合让稳定节点引用在现有架构上几乎无法实现。举个最直接的例子流式输出const result await fetch(...)这一行代码会以 chunk 切片到达chunk 1: const re第 1 个 chunk 到达时 re 会被 hljs 当作普通标识符着色为黑色第 2 个 chunk 拼上sult 后 result 的语义才完整整段需要重新判定为变量名蓝色第 3 个 chunk 出现await关键字时前面的语法判定可能再次变化。Token 边界不和 chunk 边界对齐是流式场景的常态——每一帧都要撤销前一帧的着色判定而撤销的实现就是销毁旧 span、重建新 span。这不是改个调度器或加个缓存能绕开的它是高亮算法和 DOM 输出耦合的必然结果。2.3 另一条线用户反馈的卡顿真正原因是 DOM 规模差不多同时期有另一类反馈——对话久了页面开始卡。我通过 Chrome DevTools MCP 排查了用户提及的这个典型长对话页多轮对话每轮含若干代码块总 DOM 元素 33612 个其中代码高亮相关节点占绝大多数。Style recalc 单次涉及上万元素主线程持续承压低端机和长会话场景尤其明显。传统代码高亮工具每一个语法元素着色都会成为一个独立的 DOM 节点高亮前代码段只有一个 textNode高亮后 DOM 数量爆炸。两条看似独立的反馈线汇到了同一个根因社区高亮库的 DOM 模型与 AI 对话的流式、多块、长会话场景架构错配。2.4 阶段一自研代码高亮组件 2.x我们没有立刻重新造轮子。先复用自研的代码高亮组件——它基于 Worker OffscreenCanvas 离屏渲染原本用于大规模代码展示场景。我们针对 AI 对话场景做了些针对性的优化和升级发布了 2.x 版本补齐代码流式输出能力支持流式过程中的选中和组件内搜索。新增智能静态图片模式代码块稳定后降级为图片节省内存鼠标交互时瞬间恢复 Canvas 画布组件。智能静态图片模式下代码块稳定无交互时会自动从 Canvas 画布转换为一张静态图片释放资源仅保留少量事件监听。静态图片模式下当鼠标交互时瞬间恢复 Canvas 画布组件。这一阶段基本拉平了体验问题但实际用下来又发现几个新的不匹配该组件是为单块大代码场景设计的而 AI 对话是多块小代码——每块代码都要启动 Worker、初始化 OffscreenCanvas固定成本被放大Canvas 里的代码不是原生 DOM 文本用户想把代码块内容和外部正文一起复制时体验欠佳——而这在 AI 对话里恰恰是高频动作不支持浏览器原生页面搜索CtrlF——Canvas 里的文字对浏览器只是像素。我们虽然在组件内做了独立搜索框但用户的肌肉记忆是 CtrlF这个落差很难通过教育解决2.5 阶段二3.0双模渲染 多线程3.0 的核心改造不是把 Canvas 换成 DOM而是把两者收编成同一个门面下的两个 renderer对外 API 一致内部各擅其场。DOM 模式的底层是 CSS Custom Highlight API——代码以单个 textNode 存在着色通过CSS.highlights注册的 Range ::highlight()伪元素完成不创建任何span。流式追加只是textNode.appendData()DOM 结构始终不变选区、CtrlF、屏幕阅读器全部基于原始文本节点工作重新着色不影响其中任何一个。这一刀直接打掉了 AI 对话场景下流式选中丢失和长会话 DOM 爆炸两个老问题。通过一个 textNode DOM 节点实现代码语法高亮上色过程中 DOM 结构不变。Canvas 模式作为 3000 行以上超大代码、以及需要水印防复制的兜底保留并继承了 2.x 的智能静态图片模式。多线程是两个模式共同的底盘但分工不同Canvas 模式 Worker 里跑 tokenize 绘制到 OffscreenCanvas整套主线程只转发消息DOM 模式 Worker 只做 tokenizetoken 流回主线程后交给CssHighlightPainter转成 Range 注册到CSS.highlights绘制还给浏览器合成层。hljs.highlight()这个最重的活无论走哪条路都不再压在主线程上。关键不是多线程三个字而是三件事配合文本同步追加 着色异步节流双轨让用户永远先看到字、再看到颜色绝不卡白屏rAF 而非 setTimeout 做节流后台 tab 不漂移、前台帧对齐合成Worker 启动期的小代码主线程兜底、大代码等齐 Worker 的策略把首次 tokenize 卡顿挡在用户感知之外。业务侧无论 chunk 切得多碎只需要持续调updateCode(完整代码)token 边界与 chunk 边界对齐这件事完全交给调度器——这正是阶段一被 DOM 耦合卡死、做不到的事。2.6 实际收益指标highlight.js自研组件 2.x自研组件 3.0DOM 节点数20 轮对话~15000~300Canvas 节点~500稳定 DOM 骨架主线程长任务50ms12 次3 次1 次流式选中保留不支持支持Canvas 模拟支持原生选区CtrlF 可检索代码不支持支持组件内支持原生选区内存占用30 分钟对话~180MB~90MB~55MB03 服务好 AI Coding 之一用 Harness Engineering 的思路改造存量项目3.1 改造存量项目前两部分讲的是前端如何服务 AI 产品体验。但 AI 时代还有另一条变化正在发生研发过程本身也在被 AI 改造。在新项目里使用 AI Coding / Vibe Coding 时体验往往不错。因为新项目上下文干净、约束少、代码风格统一AI 很容易生成一套看起来还不错的实现。但一旦落到存量项目里问题就会明显变多命名风格和历史代码不一致组件 import 五花八门样式硬编码满天飞明明项目有封装组件AI 却直接引用底层三方库生成代码看似能跑但评审时大量细节被打回很多时候我们会把这些问题归因于模型还不够强。但深入排查后会发现根因往往不完全在模型而在于项目本身缺少一套机器可读、可被 AI 稳定遵循的工程约束。AI 看到的是历史代码里参差不齐的事实它只能在这些事实里取一个平均值。如果一个项目里有三种按钮写法、五种颜色使用方式、两套请求封装、若干隐式团队约定那么 AI 很难凭空推断出当前团队真正希望它怎么写。所以要让 AI 真正写出可合入的代码存量项目需要做一定的 AI Coding 适配改造。3.2 把规则变成 AI 的上下文而不是只写在文档里团队规范如果只躺在 iwiki、腾讯文档、README 或大家的脑子里AI 是看不到的。因此规则需要进入代码仓库成为项目的一部分。我们的做法是在版本库里建立一份真相源例如openspec/rules/用结构化的.mdc文件沉淀编码铁律样式规范组件使用约束第三方库使用边界反模式清单再通过一个轻量同步脚本配合postinstall和 Git Hooks自动分发到.cursor/rules/、.codebuddy/rules/等各类 AI 工具识别的目录。规则只在一处维护全员、全工具零漂移。新人 clone 项目后第一次installAI 就已经读过了所有团队规范。3.3 给 AI 一个收敛的代码出口AI 出错的高发区往往是项目里存在太多都能用但只有一种最推荐的写法。比如业务代码里直接写import { Button } from antd;这在短期看没什么问题但在存量项目里很容易造成风格失控。未来要替换组件库或定制交互改造成本也会成倍放大。我们把 UI 组件统一收口到src/components/ui/作为业务代码访问 UI 的唯一入口封装层承接默认样式、统一交互、对接 Design Token用 ESLintno-restricted-imports在工具链层强约束杜绝绕过封装层直接引antd的写法。AI 在只有一条正确路径的环境下准确率显著提升。这类收敛对人也有价值我们不需要每次纠结到底该用哪个 Button评审的时候也不用再反复指出同类问题。3.4 把视觉决策从代码里抽离成 Design Token颜色、间距、字号、圆角、阴影等以 TS 为真相源沉淀在src/themes/tokens/通过脚本生成 less 变量、CSS 变量与 antd 主题配置三端共享同一份数据。AI 不再需要猜该用#1677ff还是#1890ff而是从一张明确的 token 表里选。写出来的样式天然一致、可主题化、可演进。对于存量代码我们采用增量扩展策略存量文件原样保留不动结构新代码强约束接入 token老代码通过硬编码预算机制逐迭代收敛。我们做这套适配不是想把项目改干净存量项目永远干净不了只是想让它别越长越歪。存量项目适配 AI Coding 的核心不是加一个插件也不是写几句 prompt而是把项目改造成 AI 容易写对的样子。规则机器可读、入口足够收敛、决策足够显式——AI 的输出方差就会大幅下降评审成本随之降低团队对 AI Coding 的信任才能真正建立起来。04 服务好 AI Coding 之二重新审视编程语法与范式项目适配之外还有一个更底层的问题我们过去推崇的很多语法习惯和编程范式在 AI Coding 时代是否还成立一个很小的例子是 Sass 里的-嵌套拼接。.user-card {最终生成的类名是.user-card-header {}这在过去看起来很优雅少写重复前缀结构也清楚。但问题是当你在浏览器里看到.user-card-header回到代码里全局搜索这个完整类名可能搜不到。因为源码里不存在完整字符串它是拼接出来的。人要脑内推导AI 也要推导。类似问题还有很多JS 里过度复杂的解构、重命名、默认值混写Python 里多层列表推导式TypeScript 里炫技式类型体操过度抽象导致一个简单逻辑需要跨多个文件理解极致 DRY 让局部变化变成全局影响。这些写法的共同点是写起来省事读、找、改、协作都变贵。4.1 旧范式的底层初衷减少人工手写成本我们过去喜欢语法糖、缩写、嵌套、抽象、DRY有其历史合理性。因为在很长一段时间里编程的主要成本之一就是人手写代码。所以旧审美是短小 优雅抽象 高级复用 成熟少写 高效这些原则并没有错。它们确实帮助我们减少了重复劳动提高了局部开发效率。但 AI Coding 改变了成本结构。4.2 AI Coding 带来的成本结构反转当 AI 可以快速生成代码后少打几个字符不再是最稀缺的能力。真正稀缺的是代码是否容易理解是否容易搜索是否容易让 AI 定位是否容易 review是否容易局部修改是否容易验证正确性我现在写代码越来越多在想这件事我到底要解决什么边界在哪怎么算做完了反而怎么写这一步AI 比我快多了。 这意味着过去一些为了减少输入成本而牺牲可读性的写法需要重新评估。4.3 新标准显式、可搜索、直白、适度重复我自己最近写代码会下意识做几件事没什么大道理纯粹是被 AI 教出来的肌肉记忆。显式优于隐式不要让关键信息藏在推导里。比如 CSS 类名如果最终使用的是.user-card-header源码里最好也能直接搜到.user-card-header。这对人有好处对 AI 也有好处。可搜索优于可推导搜索是理解大型项目最重要的入口之一。如果一个变量名、类名、事件名、接口名在运行时才拼出来那么它就会降低可定位性。过去我们觉得能推导出来就行但 AI Coding 时代更重要的是能直接匹配到。直白实现优于巧妙炫技聪明代码的问题在于它往往依赖作者当时的灵感。但工程代码不是智力竞赛而是长期协作资产。AI 生成、AI 修改、人类 review都更喜欢直白的控制流和清晰的数据结构。适度重复优于过度抽象DRY 仍然重要但不是所有重复都应该立刻抽象。有些重复只是看起来相似业务变化方向并不一致。过早抽象会让后续修改变得更困难。在 AI Coding 场景下适度重复反而能让局部改动更安全因为 AI 可以在明确上下文内完成修改而不是牵动一套复杂抽象体系。4.4 不是反语法糖而是反为了写得爽牺牲读得懂需要强调的是这并不是说所有语法糖、抽象和 DRY 都过时了。在这些场景里旧范式依然成立领域核心模型层DRY 依然是底线系统边界处抽象依然有巨大价值表达力关键场景适当语法糖可以显著提升清晰度稳定公共能力复用仍然比复制更好真正需要反思的是我们是否为了写得爽牺牲了读得懂、搜得到、改得动。AI Coding 时代代码不仅要对人友好也要对 AI 友好。4.5 前端开发者角色的变化在这个变化里前端开发者的角色也会发生变化。过去我们很大一部分能力体现在熟悉语法和框架 API、手写代码快、能快速堆出页面等方面。这些能力仍然有价值但不再是全部。未来更重要的是能不能准确拆解问题、定义清楚边界能不能判断 AI 生成方案是否合理能不能设计可维护的架构能不能让项目持续适合人机协作。也就是说前端开发者会从语法工匠逐步转向意图拆解者、架构决策者、AI 编码验收者——落到日常就是少写几行炫技代码多花点时间想清楚到底要做什么。05 总结写到这里其实就一句话——前端在 AI 时代要做好两件事对外把 AI 能力变成顺滑的产品体验对内把工程体系改造成适合 AI 协作的新形态。服务好 AI 产品也服务好 AI Coding。
