@hemingway 裁判文书网，应该只能查到被执行的了，没结案应该查不到。

不大相信，大厂会出现这种低级错误（当然，也有可能是我视野不够，触及不到这种 bug 出现的其他场景）；不过就看到几个截图，不知道是否必现，如果是必现问题，这锅放到产研线，谁的锅更大点？程序员？测试？

老一辈一般比较固执，但也比较相信权威，虽然很无奈，但有些话换个人说出口，别人可能就信了。换种方式让一些有权威性的人告诉他们：

1.比如约个医生朋友到家或者某天去医院了，让医生跟他们说，不好的饮食习惯容易引发疾病，看一次病要花不少钱。

2.看看网上能否找到有关类似“长期吃剩菜会影响健康”的官方媒体报道，下载放电视上，给父母们看看。

谢谢大家的回复，我看了下，大家好像都集中与前后端校验上，可能我问的方式不对。

我的本意是，前端表单项中，没有发送数据变动的表单项数据有没有必要在编辑时也一起提交上来，打个比方，一个表单中有手机号码和名字，这时候只改了名字，手机号码没改，在提交时，有没有必要把没发生变化的手机号码也一起通过接口提交上来。

因为如果没变化的手机号码也提交上来，并且手机号码必须确保唯一性，后端在校验号码唯一性时，除了判断手机号码是否已经被注册，还得再判断一遍是否等于当前用户的手机号码（ true 的话支持继续修改），后面这个是否等于自己的手机号码的判断是因为前端把没有变化的手机号码也提交上来的，如果约定，数据不发生变化时不需要提交，那后端就只要判断该手机号码是否被注册就行了。

感觉 15 楼明白我在说什么。 @old9

@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 版本。

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