Harness Engineering落地前，先想清楚这几个问题

一句话概括

从数据中台 AI 助手 Dola 的实践出发，讨论两个问题：AI 产品形态变化后前端架构如何适配（流式渲染、图表推荐），以及存量项目如何用 Harness Engineering 思路改造以服务 AI Coding。

问题：传统代码高亮库的 DOM 模型与 AI 对话的流式、多块、长会话场景架构错配
解决方案：
- 放弃给现有库打增量补丁
- 重新设计流式 chunk 到 DOM 的映射
- 着色与 DOM 解耦

策略：工程化推荐 + 大模型微调
1. 前端基于已有上下文快速给出推荐配置
2. 用户立刻就能看到一张相对合理的图
3. 不满意再让 AI 介入修改
优势：工程化的速度和稳定性 + AI 的灵活性

核心思路：把项目改造成 AI 容易写对的样子
1. 规则机器可读：配置、约束用结构化格式而非注释
2. 入口足够收敛：减少 AI 需要理解的入口点
3. 决策足够显式：隐式规则变成显式检查
效果：AI 输出方差大幅下降，评审成本降低

发现：多年习以为常的"优雅写法"在 AI Coding 协作中反而成了拖累
原因：AI 需要的是明确、可预测的模式，而非需要上下文理解的"巧妙"设计

当我们开始大量用 CodeBuddy、Cursor 来协作开发时，发现多年来习以为常的”优雅写法”，在 AI Coding 协作中反而成了拖累。这两类问题逼着我重新思考前端在 AI 时代的定位。

存量项目适配 AI Coding 的核心，不是加一个插件，也不是写几句 prompt，而是把项目改造成 AI 容易写对的样子。规则机器可读、入口足够收敛、决策足够显式——AI 的输出方差就会大幅下降，评审成本随之降低，团队对 AI Coding 的信任才能真正建立起来。