一、大屏开发与CRUD开发本质截然不同

在探讨大屏开发时，首要任务是理清其与CRUD开发的核心区别。两者在产品逻辑和开发模式上，几乎属于完全不同的范畴。

CRUD开发，典型特点是信息明确、需求固定。后端一旦提供完整的字段定义与接口文档，列表、表单、详情页的展示方式便基本确定。在此场景下，AI严格按照模板填空，往往能快速生成可运行的页面。

而大屏开发则面临信息不完备、需求频繁变动的问题。后端仅提供原始数据源，图表呈现方式、色彩搭配、布局细节——这些都需要依赖视觉设计和业务需求，反复进行效果评估与调整。第一版只是起点，真正的开发工作才刚刚拉开序幕。

针对这两种场景，AI的应用策略也截然不同：CRUD的核心在于“如何生成正确的内容”，而大屏开发的核心则是“如何确保频繁改动不引发系统崩溃”。

二、先分清：什么是固定不变，什么是持续变动

在大屏项目中，有些要素一旦确定便很少更改。而另一些要素，则会在整个迭代周期中反复调整。只有将这两类要素清晰分离，才能在稳定的框架基础上，安心地进行后续优化。

不变的部分—通过模板与规约锁定

类型与接口定义：后端提供的字段结构和接口路径一旦确定，便成为静态约定。这部分工作适合AI填空式生成——将字段映射为TypeScript类型，接口映射为API方法。一次生成后，仅在后端字段发生变更时才需要调整。

页面结构拓扑：大屏的Grid布局——顶部一排数字卡片，左侧放置大折线图，右侧上下分布图表组件——这种布局框架一旦确定，基本不会改变。变动的是将某个图表替换为柱状图或饼图，而非推翻整个布局骨架。

整体主题风格：深色或浅色方案、主色调，以及相关颜色变量，集中存放在一个文件中。主题一旦确定，每个图表将使用统一的颜色体系，避免各自为政。

文件结构规范：每个大屏的文件组织方式——index.tsx负责页面和Grid布局，store.ts（按需）管理数据，components/目录下每个图表独立文件，utils.ts处理数据转换。这种规范可跨大屏复用，无需每次重新设计。

ECharts 基础组件：封装一个通用组件，统一处理loading、error、空数据以及resize自适应。所有图表组件均基于此基础组件渲染，无需单独处理各类状态。这是最重要的安全防线——即使AI生成的option存在错误，基础组件也能兜底显示“图表渲染出错”提示，避免直接白屏。

拓扑示例：数据大屏

以一个实际大屏为例，其文字描述如下：

页面布局：

┌──────────────────────────────────────────────────────────┐
│Header: 数据大屏 30s 刷新 · 深色 │
├──────────┬──────────┬──────────┬─────────────────────────┤
│StatCard │StatCard │StatCard │StatCard │
│总数 128│金额 5.2亿 │成交 3.1亿 │ 涨跌 +2.3% │
├────────────────────┬──────────────────────────────────────┤
│                    │                                      │
│ 收益率曲线 (折线图) │ ┌────────────────────────────────┐      │
│                    │ │   评级分布 (饼图)              │      │
│ 1Y ── 3Y ── 5Y ── │ │   AAA 45%  AA 30%  A 20%  BBB 5% │
│                    │ └────────────────────────────────┘      │
│                    │ ┌────────────────────────────────┐      │
│                    │ │   TOP10 成交 (表格)            │      │
│                    │ │   名称│ 金额 │ 涨跌             │      │
│                    │ └────────────────────────────────┘      │
└────────────────────┴──────────────────────────────────────┘

对应的组件树：

index.tsx ← Grid 布局骨架
├── StatCards ← 四个数字卡片（复用 ×4）
│   └── StatCard ← 单个卡片组件
├── YieldCurve ← 收益率折线图
│   └── EChartsBase ← option ← 基座兜底三态
├── RatingDist ← 评级分布饼图
│   └── EChartsBase ← option
└── Top10Table ← 成交 TOP10 表格
    └── SSearchTable

拆分成具体任务：

Task 1 [api] 数据接口 → types.ts + api/index.ts
Task 2 [data-transform] 数据转换 → utils.ts
Task 3 [component-widget] StatCard（1 组件 ×4 实例）
Task 4 [component-chart] YieldCurve
Task 5 [component-chart] RatingDist
Task 6 [component] Top10Table
Task 7 [page-dashboard] 页面骨架 + Store + Grid 组装所有组件

这个拓扑结构一旦确定，基本保持稳定。后续的迭代主要在内容层面——例如“将收益率曲线改为面积图”（Task 6内部调整option）、“新增国债期货行情模块”（新建Task 9图表组件）、“深色主题过暗需要调整”（主题文件统一修改色值）。结构不变，内容持续优化。

变动的部分—AI生成，人在迭代中微调

图表类型与数量：产品经理提出“增加饼图”、“将柱状图替换为折线图”等需求，调整的是图表实例，而非整体架构。由AI生成option对象，由人决策是否需要、如何应用。

数据处理与Store结构：数据从API响应转换为图表所需格式的方式，以及Store（按需）中筛选条件与数据切片的组织方式。大屏的接口数量和嵌套深度各不相同，数据流模式（简单/中等/复杂）也因此差异明显。这并非一次就能敲定，而是随着接口逐步到位而逐渐清晰。

Option配置：ECharts的option对象涉及颜色、间距、动画、tooltip格式等细节。这部分可交由AI直接生成JSON，再由人工根据实际效果进行调整。

三、四条边界确保改动不引发问题

大屏开发中最频繁的操作是更换图表和调整参数。如果一个图表的改动会牵连其他组件，那么每次迭代都如同排雷。下面四条规则能有效守住边界。

1. 组件独立：删除一个组件，其余能否正常运行？

图表组件之间不应存在互相引用。每个图表仅被页面组件引用，删除一个组件只需在JSX中移除一行代码，并删除对应文件。新增图表也是在Grid布局中添加一行，无需修改已有图表。这才是真正的“解耦”。

2. 数据与展示分离：修改数据源时，是否需要改动UI？

图表组件内部不应直接调用接口。数据需从外部传入——通过props传递，或从Store（按需）订阅。数据转换逻辑应集中放置在独立的utils.ts文件中。当后端接口字段发生变化时，只需修改转换函数，图表组件完全不受影响。

3. Option外提：调整配置无需翻阅JSX

ECharts的option应抽取为独立的变量或函数，避免内联在JSX中。要修改图表配置——例如将折线图改为柱状图，或调整颜色——只需修改option定义处，无需触碰渲染部分。

4. 颜色集中管理：更换主题仅需修改一处

所有颜色值都应引用一个统一的theme文件，避免在组件中硬编码。更换主题时，仅需修改这一处，全局即可生效。

四、哪些工作交给人工，哪些工作交给AI

分工的依据不是“能不能做”，而是“反复修改的次数”和“出错后的影响成本”。

适合人工完成的工作

局部微调——修改颜色、更换图表类型、调整间距。这类小范围调整，人工手动修改效率更高。让AI读取代码、理解上下文、定位修改点，其成本远超手动操作。

架构决策——确定数据流采用简单模式还是复杂模式，Store是否需要分片。这些需要人理解整体大屏的接口数量和嵌套关系，AI最多提供参考建议。

风格判断——“这个颜色太暗了”、“这个字体太小了”。视觉审美的主观判断，AI难以胜任。

适合AI完成的工作

生成option对象——ECharts的option本质上是JSON，AI生成JSON的能力毋庸置疑。给出文字描述（“折线图，三条线分别为1Y/3Y/5Y收益率，x轴为日期，y轴为百分比”），AI即可直接生成option。

数据转换函数——API返回的字段名与图表所需格式之间的映射关系。让AI读取types.ts和接口文档，生成转换逻辑。

单个图表的大幅改造——“将收益率曲线改为面积图，并增加均线”。这属于D2修改路径——定位到YieldCurve.tsx的option变量，替换配置即可。

向已有大屏中添加新图表——这属于D1修改路径。AI生成新的图表组件，人工在Grid布局中添加一行引用，不触碰已有图表。

什么情况下不建议使用AI

修改一个间距、调整一个色值——直接打开文件，手动修改，保存即可。如此简单的操作，完全没有必要借助AI。

五、迭代优化才是主战场

大屏真正的开发时间并非集中在第一版生成，而是集中在后续无数次反复调整中。

每一次改动都不能打破既定的数据流模式，也不能牵连其他图表。修改一个图表仅动一个文件，修改布局仅动Grid，修改数据仅动转换函数。这才是理想中的开发状态。

六、ECharts基础组件：不依赖AI自觉的最后防线

AI生成图表代码时，最容易遗漏三个方面：loading状态、error状态、空数据占位。指望AI自觉“记得加上”？十张图表里总有一张会遗漏。

最简单的解决方案，就是封装一个EChartsBase基础组件，内置这三种状态处理。所有图表都基于它进行渲染：

    option={option}
    loading={loading}
    error={error}
    empty={!data.length}
    height={300}
/>

AI无需特意记忆异常处理逻辑——这是基础组件的职责。AI只需正确传递props即可，基础组件会兜底处理所有异常状态。这才是可靠的做法，而不是依赖AI的“自觉”。

七、总结

大屏AI辅助开发的核心，并非追求“AI一次生成完全正确”，而是设计一套让AI“无论怎么修改都不会引发问题”的边界规则。

• 将不变的部分锁定到模板和规约中，将变动的部分交给AI生成，再由人在迭代中调整
• 组件独立、数据分离、option外提、颜色集中管理——四条边界确保每次改动不牵连其他组件
• 局部调整手动操作，单个图表大幅改造借助AI，架构决策由人拍板
• EChartsBase基础组件兜底处理loading/error/empty状态，不依赖AI自觉地记得处理

最终的衡量标准非常简单：删掉一个图表，页面是否还能正常运行？修改一个数据源，UI是否需要跟着变动？如果答案都是否，说明你的架构设计是正确的。