这篇先回答一个最直接的问题：
能不能用 Codex 辅助，把 Grafana 前端从 React 迁到 Vue？
我的答案是：可以，但不是一键迁移。
我基于 Grafana 开源能力体系迁移和改造出了现在的 HInsight。它已经进入真实生产场景使用，并不是几个页面的 demo。
但这件事真正有价值的地方，不是“AI 生成了多少代码”，而是：
AI 辅助编码工具如何被纳入复杂工程迁移的闭环。
1. 迁移范围不是几个页面
HInsight 的迁移范围包括前端和后端两部分。
前端侧，已经基本继承并适配了原有可观测系统的核心能力：
- Dashboard
- DataSource
- Panel
- Explore
- 权限
- 日志
- 配置
- 常用插件能力
- packages 目录下的所有分包体系
- UI 组件能力，尤其是
grafana-ui相关能力
后端侧，也不是完全不动。
Go 后端代码、运行配置、工程结构、构建链路、demo 验证链路，都做了相应修改和适配。
所以这不是简单的：
React Component → Vue Component
而是一个成熟复杂系统的整体迁移。
2. 为什么这件事难？
从零开发时，可以自己定义边界。
但迁移 Grafana 这类成熟系统时，真正难的是：
不能破坏原有行为。
Dashboard 要能跑。
Panel 要能渲染。
DataSource 要能查询。
Explore 要能用。
权限和日志不能断。
packages 体系不能散。
UI 组件能力要能承接。
后端运行配置和前端构建链路要能闭合。
这就是它和普通 demo 的区别。
3. Codex 不能直接放开干
我在迁移过程中主要使用 Codex。
但真实体验是：Codex 不能直接放开干。
当时经常遇到：
- 长任务跑偏；
- 上下文丢失；
- 掉线后接不上；
- 新会话需要重新建立背景；
- 为了尽快完成选择短平快方案；
- 修改范围扩大；
- 页面实际运行和汇报不一致；
- 花很久修一个问题，最后回到原点。
所以我后来不再让它直接执行大任务，而是先把任务纳入流程。
4. 后来形成的 AI 工程闭环
我最终形成的流程是：
这套流程的核心是：
不是让 AI 自由发挥，而是把 AI 纳入工程闭环。
5. 其中最关键的是差异表和验收标准
验收标准
必须先定义什么叫完成。
例如：
- 是否构建通过；
- 是否 typecheck 通过；
- 是否单测通过；
- 是否 e2e 通过；
- 目标页面是否可用；
- 核心交互是否一致；
- 是否允许改接口；
- 是否允许引入新依赖。
如果不定义验收标准，AI 很容易给出一个“看起来完成”的结果。
差异表
差异表用于记录：
- 当前实现是什么；
- 目标实现是什么；
- 差异在哪里；
- 哪些文件需要改；
- 哪些逻辑必须保留；
- 哪些风险需要注意。
差异表能防止 AI 一开始方向偏了，后面越改越远。
6. 方法论不绑定 Codex
这篇文章提 Codex，是因为 HInsight 迁移过程中我主要使用的是 Codex。
但这个方法论不只适用于 Codex。
Claude Code、Cursor、Copilot，以及未来其他 AI 辅助编码工具，只要进入复杂工程，都会遇到类似问题：
上下文保持
任务拆分
边界控制
自动化测试
人工验收
中断交接
经验沉淀
所以我真正关注的是：
AI coding agent 如何参与复杂工程交付。
7. 后续会继续写什么？
后续这个系列会继续展开：
- Grafana 能力体系到 HInsight 的迁移；
- React → Vue 的具体迁移规则；
- packages 分包体系和
grafana-ui相关能力； - Go 后端和运行配置；
- Dashboard / DataSource / Panel / Explore；
- Codex 跑偏和返工案例；
- 差异表和交接书模板；
- 本地记忆机制；
- e2e 测试血泪史；
- HInsight Core 开放核心版本。
HInsight Core 后续会整理为开放核心项目，预计包含：
- Go 后端；
- Vue 前端；
- 核心 packages；
- Docker demo；
- 模拟数据源；
- 示例 dashboard。
但不会包含真实生产数据、客户信息、现场接口、控制策略、内部算法和生产部署配置。
小结
能不能用 Codex 辅助迁移 Grafana 前端 React → Vue？
我的结论是：
能，但前提不是“让 AI 一键完成”，而是把 AI 纳入可控工程闭环。
这也是 HInsight 后续复盘的主线。
