AI提示词学习

1、分库

背景：首先，现某企业级的中台数据系统针对它的其中一个对接方数据量的快速增长已经无法满足其性能和稳定性的需求，于是内部决定对其底层数据库进行分库分表（针对该对接方拆分一个新库独立维护）。其次，作为它的对接方（即目标业务系统）应该如何与其相互配合，将它自身的业务对象或属性从原库进行完全分离。问题：由于中台数据系统的数据库表字段的设计比较抽象，且接口（通过接口暴露服务）也比较灵活，以至于所有针对字段（表字段非常多，有些表字段甚至达到1000多字段）的业务逻辑都是目标业务系统自身加以校验和控制，而中台数据系统主要专注于数据库底层的高性能、高可用及高扩展（所谓的三高）层面，建设企业内部的数据底层基础能力。正因如此，作为提供方的数据中台很难去分库过程中完全识别所有未知风险，那么作为对接方的目标业务系统就更加难以保证分库过程中的数据迁移万无一失（即做到平滑迁移），所以现如今最大的问题就在于双方如何能够通过某种机制将所有未知风险或问题都在测试环境暴露出来，避免将未知风险或问题引入到生产环境

2、JSONObject整改

springboot工程中，由于历史原因引入了net.sf.json.*包，导致历史存量代码中包含大量的getXXX()、optXXX()、opt()、get()、optJSONObject()、getJSONObject()、optJSONArray()、getJSONArray()、fromObject()等跟现主流的alibaba的fastjson包的类名及方法名命名不同，以致于现在无法保证快速且无风险的整改，而且如果直接无脑将所有导包路径以及类名和方法名进行替换也会存在未知风险。于是想请问一下，目前业界有没有一种既改动范围小（不需要全工程改动），又风险小的合适方案。当前采用的一种方案是通过自定义JSONObject和JSONArray两个类，然后类内部通过借鉴设计模式中的装饰器模式来操作com.alibaba.fastjson包下的JSONObject和JSONArray

3、优化codefree首页

角色：你是一位拥有3年经验的Java软件开发工程师
背景：基于若依微服务版框架开发个人网站
风格：偏向B站、抖音
网站类型：社交网站
具体操作：参考B站首页的走马灯优化个人网站codefree.cn首页
输出内容：Vue组件，文件后缀为.vue，且文件内容包含三部分，template、script、style
兼容性：完美兼容若依微服务版前端vue框架

4、优化登录：区分公共API和受保护API

基于若依微服务版框架，请你依据videoDetail现有组件的代码逻辑结构，帮我做以下几点：

1、完善类似B站视频详情页的功能，包括视频播放器区域、评论区域等功能

2、交互效果类似B站，即公开API和受保护API需要进行隔离，例如：

  2.1 没有登录时，评论区域的发布按钮不可点击，且显示请先登录后发表评论 (・ω・)

  2.2 没有登录时，评论区的评论内容被遮罩层遮住，且显示登录后查看所有评论

3、基于以上2.1和2.2两小点，当用户点击登录按钮时，页面正中间弹出登录组件框提示用户登录。当用户登录成功后，则继续且自动执行登录前需要做的操作。例如：评论区域的遮罩层自动消失，评论列表重新刷新

5、微服务的功能拆分和迁移

1、问题：目前线上环境遇到一个单点问题，但是导致了整个系统崩溃。
2、背景：由于A服务做的一个新需求，需要调用B服务(系统的基础且核心服务)获取数据，而因为B服务中的关键代码缺少了非空判断，导致了两次全表查询，进而导致两个ArrayList相互做removeAll操作的时候非常难，本地debug验证时花了将近两分钟左右，根据线上环境的APM调用链路来看，从全表查询出来到最后事务回滚一共花了10分钟左右，导致占用的数据库连接数一直没有释放，且该应用服务集群的实例数为8，又恰好每台实例设置的数据库连接池的最大连接数又只有8，总共一起才64个连接数，但又恰好此时用户发起的请求数达到了60个左右，就导致在一定十分钟内这64个数据库连接一直没有释放，导致新请求也一直在等待且处理不了，进而导致B服务几乎所有实例的http nio异步并发线程数也达到200(打满)，进而B服务崩溃，最终导致系统崩溃。
基于以上背景，你作为一个拥有 3 年左右经验的 Java 软件开发工程师，现在需要对 B 服务进行微服务的功能拆分和迁移，请帮忙输出一份能够完美落地的企业级实现方案

6、数据中台接口限流

背景：在基于springboot框架的企业级系统中，核心功能强依赖数据中台（即通过其注册在API网关的接口进行数据的基本增删改查操作）。但是由于数据中台服务的用户量非常大，所以为了保障系统的可靠性和稳定性，就对大多数高频接口进行了多层限流配置，例如：API网关限流、Auth限流等，这就导致了该系统的生产环境日志中会时不时出现大量接口限流的报错日志，其中某几个高频接口限流（功能强大）特别严重，这是由于有部分用户对数据进行了大批量操作，于是接口调用量急剧上升，进而触发了第三方接口限流。每当限流一触发，依赖这些高频接口的其他功能也会接踵而至的受到影响，例如：用户保存数据时可能会偶发报错等等一系列的连锁反应。以上现象归根结底，主要的原因是由于历史代码中调用上述所说的高频接口的场景是相当的错综复杂，大致分析的原因可能有：

　　1、原先的业务场景需要

　　2、原先的开发人员图方便就直接使用高频接口，也不考虑功能是否臃肿。

任务：如何对该类接口调用的历史技术债进行代码重构

你作为一个拥有10年丰富经验的Java高级开发工程师，现在请给我一个业界合理且完美落地的实现方案

7、XXX评分统计看板需求

7.1 员工能力评分

背景：一个企业中的老板下面管理着很多部门，每个部门下又有一大群员工（该企业中总共几万人左右）。现如今为了整个企业的长远发展，老板想要关注每个周期内该整个企业所有员工的平均水平的整体趋势，所以现在老板决定让每个部门的部长分别安排手底下的人依据每位员工的能力进行评分，且评分人每天都可能分别给每位员工打零到多次评分（分数在0~100之间），并且需要将整体趋势以折线图的方式展示到系统中，便于老板查看。

需求：做一个员工能力评分统计看板。

主要功能：可以筛选一个周期（如：按年、按月等），并查看该周期内每天所有员工的平均得分

工作能力：你现在是一个拥有10年经验的Java架构师

目的：需要后台微服务提供一个新接口：返回指定周期内每天所有员工的平均得分（若当天某位员工没有评分，则需要取小于等于当天最近的一次评分数据）

后端微服务框架：SpringBoot+MyBatis

数据库：PostgreSQL

输出内容：

  1、接口响应体

    格式：数组

    内容：指定周期内每天所有员工的平均得分

    样例：

[
    {
        "date": "2025-12-18",
        "avgScore": "60.5"
    },
    {
        "date": "2025-12-19",
        "avgScore": "72"
    },
    {
        "date": "2025-12-20",
        "avgScore": "80"
    }
]

  2、前端UI：折线图

特别注意：接口数据不分页

任务：请你帮忙设计一个高性能且稳定性强的RESTFul风格接口

解释说明：

  1、高性能：接口响应在300ms以内

  2、稳定性强：无需将数据一次性加载到内存进行计算，即高并发场景下不会导致服务器内存利用率骤升