最近用Paico生成了一套智能电动自行车管理后台，算是拿它做了一次实际项目演练。项目涵盖了仪表盘、车辆管理、路线规划、维护保养和系统设置几个模块，首页能看到实时车况、附近站点、路线推荐、通知和骑行数据。
这类页面模块确实不少，不过决定生成效果的关键，不在提示词长短，而是有没有把业务对象、使用场景和信息之间的关联讲清楚。下面结合这个案例，聊一聊怎么让AI生成的管理后台更贴近真实项目，也更方便后续继续开发。
一、先定义后台在"管理什么"
不少人拿到AI第一句就是"做一个科技感数据大屏"，补上蓝色调、卡片布局、炫酷图表这些要求。这样通常能拿到一个看起来像后台的页面，但内容容易东拼西凑，AI也不知道用户进系统后到底要解决什么问题。
其实更实用的做法，是先想清楚后台涉及哪些核心业务对象。这个案例里主要有四类：车辆、路线、充电站和维护任务。车辆可以继续拆出电量、速度、位置、里程、在线状态和健康度；路线则包含距离、时间、耗电量、难度和碳减排数据。
对象一定下来，页面结构差不多就能顺着业务逻辑理出来了。比如：
- 仪表盘负责呈现整体概况；
- 车辆页用来查找和对比单车状态；
- 路线页负责推荐方案、辅助选择；
- 维护页则处理故障、保养计划和备件库存。
告诉AI"放四个统计卡片"，效果肯定不如说清楚"用户打开首页后，要能快速判断车辆是否正常、缺不缺电、附近哪能充电、有没有待处理的维护问题"。后一种方式给出来的数据排布通常更贴合实际使用。
二、提示词要交代信息层级
业务对象确定了，接着不是列更多功能，而是要定一下信息优先级。后台页面空间就那么多，所有数据都做成一样大的卡片，看起来肯定乱。
拿这个仪表盘来说，首屏最要紧的是实时车辆状态，所以主要展示当前车辆的电量、速度、温度、风速、续航和位置。附近站点地图、推荐路线属于辅助决策，骑行趋势和节能数据更适合放在页面下方，供用户进一步查看。
所以给AI的信息最好能分出这几个层次：
- 第一层是立即需要关注的内容，比如车辆离线、低电量、设备异常和逾期维护；
- 第二层是高频操作，比如查看车辆、开始导航、新增维护任务；
- 第三层是趋势与复盘信息，比如周骑行距离、累计节能和碳减排。
另外还可以把数据之间的关联带一下。比如低电量不能光给个红色数字，最好能关联到附近的充电站；车辆里程到了阈值，要能触发保养提醒；路线推荐也别只列名称，时间、距离和耗电量一并提供才管用。这些关系交代清楚了，AI给出来的就不只是个静态看板，更接近一个能点能用的产品原型。
这次实践里，AI确实生成了完整页面，也把上面说的业务关系落实成交互和React项目结构，可以直接查看。当然，工具能发挥到什么水平，还是看输入信息够不够具体。
三、第一版出来后，按"业务一致性"修改
AI给的第一版一般不用推翻重来，分层检查效率更高。
先过一遍全局结构：看看侧边栏名称、页面标题和导航顺序有没有统一。同一个车辆状态，在首页、车辆页和维护页里是不是一致。比如某辆车在首页显示电量15%、状态离线，车辆列表和告警通知里最好也是同一组信息。要不然单个页面看都还行，整套系统拼起来就对不上了。
然后再检查数据表达：统计项尽量写清楚时间范围和单位，比如"骑行次数"写成"本月骑行次数"更明确，"节能725"不如"累计节省电量725kWh"完整。趋势数字也得有参照，比如"较上月增长12%"，光一个上升箭头没意义。
接着看状态设计：后台不能只有正常状态，低电量、离线、维护中、库存不足、任务逾期、无数据这些情况都得覆盖。颜色也不单为了好看，绿色对应正常，橙色需要关注，红色表示异常或逾期，最好再配上文字标签，别光靠颜色区分。
最后调一下视觉密度：首页做概览，别把所有字段都堆上去，详情页和列表页再展开更完整的数据。卡片间距、标题字号、表格列宽、按钮位置都统一下，但不用为了"高级感"加一堆装饰。管理后台最重要的是方便扫读，视觉风格排第二位。
四、判断React代码能不能继续用
页面能跑起来，不代表代码就适合接着往下做。判断AI生成的React项目质量，先看组件有没有按职责拆开。
从这次案例的代码来看，首页没有把所有内容塞进一个文件，而是把地图、车辆状态卡、路线卡、统计卡、图表、电量指示器这些拆成了独立组件。车辆、路线、维护、设置也各自作为独立页面存在。数据单独放在一个目录里，通过统一入口传给组件。后面接真实接口时，不用再把整张页面拆一遍。
第二个重点是复用。同一种统计卡片只写一套组件就够了，用标题、数值、单位、趋势、图标、颜色这些参数控制内容。四个指标要是复制四段结构，生成那会儿是快，后面改样式就得改四次。路线卡、车辆卡、状态标签也同理。
还有交互状态也得注意。筛选条件、当前选中的路线、通知已读状态、侧栏展开、深色模式这些，都得有明确的数据来源。原型阶段用本地数据和useState没问题，但要给加载中、请求失败、空数据这些状态留好接口。后面接真实接口时，把数据请求抽到hooks或服务层，别让组件同时扛展示、请求和数据转换。
最后再看几个实际问题：列表有没有稳定的key，类型定义全不全，数字单位是不是在数据层统一处理的，窄屏下页面会不会溢出来，按钮点下去有没有反馈。这些细节看着不起眼，但决定了一个生成结果到底是只能看的效果图，还是能继续迭代的React项目。
回过头看这次AI生成后台的实践，关键不是背一句"万能提示词"，而是掌握一套梳理流程：先圈定业务对象，再明确用户任务，接着排信息层级，最后检查跨页面的数据和代码结构。输入里把这些关键信息带到了，换成设备管理、园区运营或者能源监控，这套方法同样能用。