@rabbbit 嗯嗯，不过这个判断交给后端去判断感觉也怪怪的，相当于把这个数据是否变化的判断交给后端去做了。当然你列举里面的很多字段是不需要判断数据是否发生变化的，因为没有手机号码有特殊的唯一性要求，其他数据提交上来直接覆盖就行了。

@LuffyPro 不传上来，后端当作你不想改手机号码，传上来表示你想改手机号码。

@facebook47 @IDAEngine @InDom @lneoi @Removable @rabbbit 谢谢大家回复
当然这里后端是要校验数据的，但我的意思不是后端不做校验，而是有没有必要特殊处理这种数据没变化但又把数据提交上来的场景，比如上面例子说的手机号码，手机号码是唯一的，如果你传过来的手机号码，数据库中已经存在了，后端就不给提交，但现在后端需要校验多一次传过来的手机号码是否等于他自己的手机号码，如果是这种特殊情况，能让他提交。如果前端校验该表单项没发生数据变化不提交上来，后端就不需要做这层校验了，接口传上来的手机号默认都是当作想要修改的。不过这样前端需要提交前判断相关表单项，而且不大可能每个表单项都去做这种数据无变化的判断，来决定要不要将手机号码传给接口。

@matrix1010 @yinmin @maymay5 谢谢回复，这几天忙其他的，后面看看大家说的这些方案。

谢谢大家的回复！
@renmu 谢谢建议，回头我试一下。
@Trinityuan 嗯嗯，你的补充是我现有方案正在执行当中的优化版。
@vacuitym 提示语里面确实没提供实例，返回格式这点是有规范要求的，我尝试过，数量不等时，带上上下文，同时强化提示语，结果返回还是数组长度不一致的结果。

@matrix1010 嗯嗯，目前暂时是这么做的，然而，这样会有两问题😂：
1.调用次数增加，耗时增多，延迟加大，用户体验不好；
2.增加 token 消耗量。

@LuffyPro 外键约束请忽略，用 gpt 帮我生成表结构的

不知道我理解的对不对，假设你的组织架构跟你的业务是多对多的关系，是否可以这样（简化版）：
1.domain 表（组织架构）：
CREATE TABLE domain (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
parent_id BIGINT,
level TINYINT,
name VARCHAR(255),
is_deleted TINYINT
);

2.business 业务表：
CREATE TABLE business (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(255),
is_deleted TINYINT
);

3.business_domain 表：
CREATE TABLE business_domain (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
domain_id BIGINT,
business_id BIGINT,
is_deleted TINYINT,
FOREIGN KEY (domain_id) REFERENCES domain(id),
FOREIGN KEY (business_id) REFERENCES business(id)
);


功能：
修改：
1.删除，is_deleted=1;
2:换名字
扩充：
1.加多一级，level+1

换种思路，一个个转成 pdf ，然后批量合成一个。两个都有线上的，但好像没看到两功能合到一起的在线工具。

@Akiya 谢谢回复，这个听起来不错。

@guangming3055 是的，es 是考虑之一，不过基于我们现状，成本稍微高点，不过好奇，你们用 es 实现的类似需求，数据表现怎么样？

@xuanbg
简单举个例子，需要实现的逻辑大致如附言图，每个查询都有纵向多条件查询，和横向单条件多级查询，最终 sql 如果拼一起类似一个树状的查询结构，并且树的深度不限（实际取决于业务，但一般也不会太夸张）

@goodhawk 嗯嗯，差不多，谢谢建议，确实，实现是一个，但重点是性能不能太拉跨😂。

谢谢大佬们的回复。
@shm7 主要是想在分割的同时，尽量保留上下文语义关系或者逻辑关系。
@SpacyTextSplitter 效果怎么样？可惜目前仅看到 py 版本。

个人觉得挺好的，一句简单的话，就能过滤掉一个“志同道合”的人，为以后人际关系问题排除一个本可能存在的可能性。