分类与边界

本章主题：根据需要选择分类依据，理解类别之间的交叉、包含与排斥，处理边界对象，并让分类支持查找、统计和行动。

本章另设小叶整理校园AI使用问题库的案例。问题、编号、标签、状态、数量、时间门槛与后续变化均为原创教学设定，不是真实用户记录、模型测评或平台规则。

一、把资料分好了，为什么反而更难找

小叶收集了一些同学使用AI时遇到的问题，希望建一个小型互助问题库。他先设置五个栏目：文本、图像、代码、紧急、已解决。

刚放入几条，困难就出现了。“修复网页表单报错”既涉及代码，又很紧急；“修改活动海报标题和配图”同时涉及文本与图像。已经解决的代码问题应该留在代码栏，还是搬进已解决栏？一条录音降噪问题如果不紧急，又该放在哪里？

目录看起来有结构，但这些栏目回答的不是同一个问题。文本、图像、代码在描述工作涉及什么；紧急在描述处理优先程度；已解决在描述当前状态。把它们放成互相替代的位置，会让对象的不同方面相互遮挡。

小叶也可以把每条问题复制到多个栏目，这样似乎哪里都能找到。但如果正文复制了三份，修正其中一份以后，其他位置可能还保留旧内容；统计时又容易把一条问题算成三条。

分类的意义，在于根据某种区别把对象组织起来，帮助查找、比较、解释或处理。这个区别应当与用途有关，类别之间的关系也应当清楚。一个目录并不会因为层级多、名字整齐，就自动成为有用的分类。

上一章讲怎样说清一个概念。本章接着问：当我们同时使用多个概念组织对象，它们之间是什么关系？一个对象能属于几类？没有放进去的对象是真的不符合，还是我们还没有决定怎么处理？

这些问题会影响AI的工作。如果分类规则含混，AI可能把同一类问题分散到不同位置，也可能为了凑齐栏目把不相似的问题放在一起。使用者需要理解规则的结构，才能判断结果是否支持原来的目的。

二、先确定对象与分类依据

1. 一条记录代表什么

本章用十二条问题作为讨论范围。每个编号表示一条完整请求，不按一句话、一个附件或一个子任务分别计数。它可以同时需要修改文案和图片，也仍然是一条请求。

如果以后为了执行而拆成子任务，应保留它们与原请求的关系。拆分以后可以统计子任务数，但不能把原请求和它的所有子任务都放进同一个总量而不作说明。

还要固定观察时点。下面的状态表示同一个时点的工作情况，不是把某条问题前天未处理、昨天处理中、今天已解决三个历史状态同时列为当前状态。

分类之前做这两项约定，是为了让所有类别指向同一种对象和同一个观察范围。否则，即使各标签单独解释得很好，合在一起也难以比较。

2. 把不同问题分成不同维度

小叶决定分别记录主题、当前状态和是否紧急。这里的主题按需要实际处理的内容来标记：文本涉及文案或语言内容，图像涉及画面内容，代码涉及程序及其行为，音频涉及声音材料。一个请求可以有多个主题。

“解释程序错误信息”标代码，不因为最后用中文解释就再标文本；“录音转文字并润色”则同时涉及音频与文本。这说明主题依据是需要处理的内容，而不是回答最终使用了哪种媒介。

三个状态约定为：尚未开始实质处理、已经开始但尚未按约定解决、已经按本条请求的要求确认解决。在这十二条给定记录中，分别简称未处理、处理中、已解决。是否紧急是另一个给定信息，不从主题或状态自动推导。

这张表允许小叶分别查“涉及图像的请求”“尚未解决的请求”或“紧急且未处理的请求”。不同需要可以组合条件，不必每出现一种查找方式就重新搬动全部资料。

3. 同一批对象，可以有几套合理分类

如果问题库主要用于安排答疑，小叶可能关心主题与所需能力；如果用于复盘，可能关心错误来自资料缺失、任务理解还是执行过程；如果用于新生学习，可能关心基础操作与综合任务。

这些分类可以对同一条请求作出不同组织。它们是否合理，需要看依据是否清楚、是否与用途相连，不能仅凭相互不同就判定其中一套必然错误。

但使用一套分类时，应保持依据一致。例如按“当前问题涉及什么”分组，就不能把某个栏目突然改成“我最喜欢的工具”。需要后者时，可以增加一个工具信息维度。

同一分类维度内部也可能继续细分，不过同一层级的类别应当能够回答相应的共同问题。这个要求让使用者知道每个位置意味着什么，帮助AI在新对象出现时沿着同样的依据判断。

三、需要每条恰好归一类时，检查互斥与覆盖

1. 互斥意味着同一对象不会同时归入这些类别

对于本章的当前状态，小叶希望每条请求只有一个状态。同一时点、同一条请求，如果“已解决”已经表示全部约定问题得到确认，就不能又以相同口径说它“处理中、尚未解决”。

这种类别之间不共享对象的关系，称为互斥或不相交。它依赖当前定义和观察范围，不是类别名称不同就自动成立。

若Q09的一部分已经处理、另一部分仍未完成，可以把整条请求记为处理中，同时另记子任务进展。不是为了强求整齐忽略进展，而是让整条请求的状态与部分工作的状态分别表达。

如果确实存在暂停、取消、等待信息等情况，可以增加状态或重新安排状态说明。当前三个状态适用于本章已经给定的十二条记录，不保证未来任何问题都天然落在这三个名称中。

2. 覆盖意味着讨论范围内没有对象被漏掉

互斥解决重复归类，覆盖解决有没有遗漏。假如只设“未处理”和“已解决”，四条正在处理的请求就没有合适位置。两类之间可以互不重叠，却仍不能完整描述当前问题库。

在本章给定状态下，未处理是Q01、Q04、Q07、Q09；处理中是Q02、Q03、Q06、Q08；已解决是Q05、Q10、Q11、Q12。三组各四条，合起来覆盖十二条，每条恰好出现一次。

如果用 $U$ 表示这十二条请求，用 $S_1,S_2,S_3$ 表示三个状态集合，可以把要求写成：

第一行说三组并起来覆盖全部对象，第二行说任意不同两组没有共同对象。这里的并集、交集分别表示归并对象和取共同对象，空集表示没有成员。

对一个集合，若若干非空子集相互不重叠、合起来又覆盖全部，就构成这个集合的一种划分。本例三个状态组提供了这样的结构。实际表格仍可预留当前数量为零的状态栏，只要不把空栏目当成已经出现的对象。

3. 总数相加正确，还不足以确认分类正确

假设登记时把Q03同时记入处理中与已解决，又漏掉Q07。三栏数量相加仍可能等于十二，因为一次重复和一次遗漏在数字上相互抵消。

所以，核查需要回到编号：每个应该出现的对象是否都出现，各对象是否只出现在允许的位置。仅检查合计数字，很容易让关系错误藏在正确总数中。

另外，编号完整也不代表状态判断一定符合事实。如果Q05尚未修好，却被误标已解决，列表仍然可以不重不漏。结构检查与内容判断需要分别成立。

4. 互斥与覆盖是服务一种需要，不是所有分类的通用命令

小叶需要计算当前各状态占多少请求时，互斥且覆盖的结构很有帮助。但如果需要查找所有涉及代码的请求，同时也能从图像入口找到Q06，多标签反而更符合用途。

因此，看到一个对象跨类，先问当前分类本来要求什么。如果要求每条只有一个状态，跨类可能是错误；如果主题允许多个标签，跨类可能正是保留信息的方式。

“每条恰好一类”是一种明确的结构选择。我们应当知道何时需要这种结构，而不把它作为整理所有知识的固定形式。

四、允许交叉时，怎样理解标签与数量

1. 一条请求可以真实涉及多个主题

Q04既需要改标题，又需要调配图。给它文本与图像两个标签，表达的是同一请求的两个有关方面。只选一个标签，会让另一个入口无法完整找到相关请求。

这种多标签安排可以在同一条记录上保存多个主题，无需复制多份正文。记录编号仍然只有一个，不同入口指向同一对象。修改内容时，关联入口看到的是相同版本。

从类别关系看，文本类与图像类有共同对象，代码类与图像类也有共同对象。W3C的知识表示入门同样区分类与实例、类的交叉及明确声明的不相交关系：一个对象可以同时属于多个类，不能仅由类名不同认定它们互斥。W3C：类、实例与类别关系

学生不需要学习这个文档的表示语言，也能使用这里的基本判断：类别之间是否允许重叠，应由分类含义决定。

2. 统计“涉及某主题的请求”，总和可能超过请求总数

按表中标签，文本类有六条，图像类五条，代码类五条，音频类两条。四类相加是十八，但问题库只有十二条请求。

十八表示请求与主题之间的标签关联次数：Q09贡献三次，Q04、Q05、Q06、Q07各贡献两次，其余每条一次。它不是十八条独立请求，也不是完成了十八个彼此独立的任务。

如果把四类数字做成总量为十二的饼图，就会混淆含义。可以用柱状图分别显示每个主题涉及多少请求，同时注明主题可交叉；要展示互不重复的构成，则需要另选合适的单一划分依据。

左图的柱子可以重叠地计入同一请求，右图在本次状态约定下不会这样。两张图的数字都可能正确，但它们在回答不同的问题。

3. 想统计不重复对象，要扣除重复部分

小叶想安排一场面向文本或图像问题的答疑。令文本集合为 $T$，图像集合为 $I$。两者共同包含Q04和Q09，所以共同对象有两条。

如果直接六加五，Q04和Q09各被算了两遍。要得到至少涉及其中一个主题的不同请求数，应计算：

两条竖线在这里表示集合里有多少个对象。这个公式把每条共同请求多算的那一次扣掉，得到两个有限集合合并后的不同对象数。OpenStax：两个集合的运算与计数

九条对应Q01、Q02、Q04、Q05、Q06、Q07、Q09、Q10、Q12。Q03与Q11只有代码，Q08只有音频，因此没有计入这次文本或图像范围。

4. 多个交叉范围，最好同时保留对象依据

如果再加入代码类，文本与代码共同两条，图像与代码共同两条，三个主题同时涉及的只有Q09。计算文本、图像或代码的不重复请求数时，需要：

为什么最后加回一？Q09一开始在三类中被加三遍，又在三个两两交叉中被减三遍，变成一次也没保留，因此要加回一次。最终只有纯音频的Q08在这三个主题之外。

这不是要求遇到许多标签都手算长公式。对实际问题库，可以直接按编号合并去重。但知道交叉部分怎样影响数量，能帮助小叶判断统计说明是否合理，也能发现AI给出的总量有没有换了含义。

同样，主题出现更多次，不直接表示它占用了更多工时或更困难。一条代码问题可能几分钟解决，另一条文本问题可能需要充分讨论。标签数、请求数和工作量需要根据各自含义使用。

五、类别之间，究竟是什么关系

1. 下位类别的每个对象，也属于相应上位类别

小叶想把代码问题进一步组织成网页代码问题、数据处理代码问题等。若把“网页代码问题”定义为涉及网页程序及其行为的问题，那么每一条网页代码问题也都属于代码问题。

这是一种包含关系。可以用子集表示：网页代码问题集合包含于代码问题集合。子集的含义是，前一个集合的每个成员都是后一个集合的成员；后者可能还有不属于前者的其他对象。OpenStax：子集与包含关系

例如与网页无关的本地计算程序问题，也可以属于代码问题，却不因此成为网页代码问题。仅仅知道一条请求属于代码类，还不足以把它放进网页代码类。

这个方向值得看清。如果代码问题之下还有网页代码问题，其下再有表单交互问题，那么一条表单交互问题可以沿着这个关系归入较广的类别。反过来，从代码问题出发，不能直接推到某个具体下位类别。

2. 一条具体请求，与一类请求不同

Q03是“修复网页表单报错”这条具体请求。它可以属于网页代码问题，但Q03本身不是一种与网页代码问题并列的类别。

目录中当然可以把具体记录放在某个类别下面。使用时需要知道，这一层已经从类别进入对象。否则，AI可能把“Q03”当成一种通用问题类型，后续新问题又被放进某个旧编号下面，结构就开始混乱。

可以用一句话检查关系：这里想说“每一个A都是B”，还是“这一个对象属于B”？前者连接类与类，后者连接具体对象与类。图上都可能画成上下位置，但含义不同。

3. 整体中的一部分，也不是整体的一个下位类别

Q09需要修正文案、配图和交互代码。配图子任务是这条综合请求的一部分，但它不是“Q09的一种”。一段程序是某个系统的组成部分，也不会因此成为这个系统的一种类型。

组成关系帮助拆解工作，类别关系帮助判断对象属于什么。若混为一谈，就可能把一个子任务的性质错误地传给整体：配图部分已经完成，不表示Q09已经完成；文案部分不需要运行代码，也不表示整个请求没有代码工作。

同样，把一篇文章拆成标题、正文和参考资料，是按组成部分分析；把文章分成实验报告、评论和访谈，是按某种类型区分。两种结构都可以有用，但不能用同一套推断随意替换。

图中箭头已经写出关系。只画连线而不说明含义，容易让读者把“相关”“属于”“包含部分”都理解成一种联系。让AI画知识结构图时，也可以要求它交代重要连线表示什么。

4. 多个上位类别可能都适用

“同时涉及文案和代码的请求”可以既归入文本问题，也归入代码问题。只要每个对象确实同时满足这两方面条件，多个上位归属并不矛盾。

树形目录每个节点通常只有一条主要路径，查找很方便，但它未必能完整表达所有交叉关系。小叶可以保留主要目录，同时用标签补充另一入口，不必为了目录只能放一次而否认对象的其他方面。

需要避免的是随意增添上位关系。例如Q03当前很紧急，不能由此说所有网页代码问题都属于紧急问题。一个实例具有某种属性，尚不足以把整个类别也放进那个范围。

六、分类分到多细，才对工作有帮助

1. 粒度决定保留多少区别

只分成“AI问题”和“非AI问题”，对这个问题库几乎没有帮助，因为十二条已经都与AI使用有关。它没有为当前查找增加有用区别。

如果每条请求都创建一个只包含自己的独立类别，虽然能够区分所有对象，又难以看出它们的共同点。分类粒度就是在这些宽窄之间选择：需要保留哪些区别，哪些细节可以先不作为类别。

小叶想安排不同主题的答疑时，文本、图像、代码、音频可能已经有用。后来代码问题很多，表单报错反复出现，再考虑细分网页交互、数据处理等方向，就有了具体需求。

增加类别的理由，应当能够连接到新的查找、解释或行动。如果只是因为AI能迅速生成一百个听起来专业的名称，就全部放进目录，使用者可能还需要重新学习这一百个名字，实际查找未必改善。

2. 细分以后，类别仍要能够解释

例如把代码问题分成“基础问题”“进阶问题”“高级问题”，看起来分了三级，但如果没有共同判断依据，不同人会把同一问题放在不同位置。

如果当前需求是寻找相似修复案例，按报错现象或程序环节细分可能更直接；如果需求是安排教学顺序，则可以结合所需前置知识来分。分类是否有用，要回到实际需要保留的差异。

这也意味着，同一层的类别不必在字数、成员数量或名称长度上完全对称。真实问题分布可能不均匀。可以检查特别大的类别是否需要拆分，也可以检查长期只有一个零散成员的类别是否有必要独立保留，但没有要求所有格子一样大。

3. 多个维度可以组合，不必把所有组合都做成目录

主题、状态、紧急程度分别记录后，小叶可以临时筛出“紧急且未处理的请求”，本例只有Q04；也可以筛出“涉及代码且已解决的请求”，本例有Q05与Q11。

如果把所有组合预先做成独立目录，就会出现“未处理的紧急文本图像问题”等越来越长的名称。很多组合暂时没有对象，维护起来也不方便。

分别记录维度，再按需要组合条件，可以减少这种重复组织。它保留了类别含义，也让查找方式随任务变化。日常表格就能实现这种安排，不需要先建一个复杂系统。

主题与状态相互独立地记录，是指它们回答不同问题，不是断言二者在统计意义上独立。某些主题可能更难处理，因此当前状态分布可能不同。记录维度的分开与现实变量的概率关系，需要区别理解。

七、遇到边界对象，先看困难来自哪里

1. 同时属于两类，不等于不知道属于哪类

Q04明确需要改标题和配图。它同时涉及文本与图像，不是资料不足，也不一定是两个类别的边界模糊。多标签已经可以准确表达这个情况。

如果强制它只能选一个主题，就会把一个清楚的交叉情况制造成“到底是哪类”的争论。此时应该先查看分类方式是否合适，而不是不断要求更有把握地二选一。

若为了分派工作确实需要一个主要入口，可以另外指定牵头者或主要处理方向，并保留其他主题。这个选择服务协调，不会让原来的多方面需求自动消失。

2. 信息不足时，补充对象事实

另有一条新请求只写“AI做出来不对，帮我看看”，没有内容、文件或现象。小叶暂时不知道它涉及文本、图像还是代码，主要困难是信息不足。

可以请对方补上原任务、实际结果和不符合预期的地方。这里的“待补充信息”描述我们对请求的了解状态，不是一个与文本、图像并列的主题。

如果先把它放进待处理入口，应保留这个理由。以后资料补齐，就可以沿原有主题规则归类。若一直把未知记录归入“其他”，后面会难以区分究竟是分类范围不足，还是请求根本没有说清。

3. 事实已经清楚，程度用词仍可能留有边界

小叶希望把问题分成简单与复杂。有些只改一个明显错字，有些要同时重写流程、修复程序并检查结果，判断相对容易。但中间还有许多请求：需要查几个条件，修改范围不大，却依赖不熟悉的工具。

即使掌握了请求内容，“简单”对哪种学习者、以耗时还是前置知识判断，仍可能没有唯一明确界线。模糊概念常通过这样的边界情形表现出来；它与单纯没有拿到资料，需要分别处理。Stanford Encyclopedia of Philosophy：模糊性与边界情形

可以先明确相对对象，例如面向已经学习过程序设计基础的同学；再给典型例子和中间例子，说明哪些因素使难度增加。这样能够改善判断，却不保证任何请求都自然分成两个截然不同的种类。

4. 很小的变化积累起来，也可能改变类别判断

从修改一篇长文章中的一个词开始，每次多改一个词，逐渐扩展到整段甚至全文。相邻两次的修改范围很接近，但把开头和最后相比，原来的局部改动已经扩展成大范围修改，很难仍按最初的“小修改”来安排。

不能因为相邻两种情况很接近，就推出首尾也应该采用同一个判断。另一方面，也不必假装某一个词的增加总会产生本质跳变。这里有逐步变化的工作量，也有为了安排工作而采用的分类。

学生遇到这种情景，可以把原始信息保留下来，例如修改范围、涉及资料和前置知识，再根据使用需要给出大致分类。分类提供一个概括，原始信息帮助处理概括没有充分表达的差异。

5. 新类型出现时，区分其他与未知

再设一条新请求：“怎样安排多个AI共同完成一次社团调查？”小叶已经理解它在询问任务组织，却发现目前四个主题都没有很好覆盖。这时可以暂记为其他已知主题，并说明是流程与任务设计。

如果同类请求经常出现，就可以考虑增加相应类别。若只是偶然出现一次，可以保留说明，不必立即扩展很多层级。当前十二条都能被四主题覆盖，不证明未来所有问题都会如此。

与“AI做出来不对”相比，这条请求的困难不同：前者尚未弄清内容，后者内容已知但现有类别不合适。把它们都塞进一个没有解释的剩余栏目，会丢掉对改进分类很重要的信息。

八、需要作出安排时，怎样使用边界和门槛

1. 行动可能需要明确规则

小叶要安排值班，不能一直停在“这个问题算不算比较紧急”的讨论中。他可以为一个具体入口规定：尚未解决、且距离明确截止时间不超过二十四小时的请求，打上临近截止标签。

这是本章另外设定的一项工作规则，不是前面三条紧急请求的实际判断依据。它只处理距离截止时间这一方面，未覆盖没有截止时间但影响很大的问题，也不等于所有紧急情况的完整定义。

对尚未解决、截止时间已知且尚未到期的请求，剩二十三小时五十九分和恰好二十四小时都符合；剩二十四小时一分钟不符合。“不超过”包含恰好等于门槛的情况，表达清楚以后才能一致执行。

已经过期或截止时间未知的情况，应另作相应说明，不能让缺少时间被默认成不紧急。规则需要处理的范围清楚，边界上的判断才有依据。

2. 清楚的门槛，不意味着门槛两侧存在巨大差异

剩二十四小时与剩二十四小时一分钟的请求，时间只差一分钟。采用不同标签，是为了工作入口能够一致处理，不代表前者在现实重要性上突然远高于后者。

因此，可以保留实际截止时间，按需要排序，并结合影响范围和已有安排判断。标签为行动提供帮助，原始信息支持更细的取舍。

如果执行中发现这个门槛总把需要提前准备的请求排在后面，就可以调整规则或增加其他依据。修改的是当前工作办法，不必声称发现了“紧急”的唯一自然界线。

3. 程度、把握和最终安排，需要看各自在表达什么

“难度为零点八”“有八成把握它属于复杂问题”“决定安排到进阶答疑”，是三种不同说法。第一种可能是某个尺度上的程度评分，第二种描述对归类判断的把握，第三种是行动安排。

它们可以有关联，但不能因为都能写成一个分数或标签，就互相替换。如果AI给出零点八，小叶应先看这个数字按什么口径产生。未经验证的自报把握，也不能直接当作同类判断的实际正确率。

对很多日常任务，保留“需要哪些前置知识、预计处理范围、为什么安排到这一组”的解释，可能比一个没有依据的精确小数更有用。是否使用评分，取决于它能不能支持当前判断。

九、让AI参与分类，应该交代和检查什么

1. 类别名称之外，还需要归类依据

小叶把资料交给AI，只说“按文本、图像、代码、音频分类”，并没有完整表达前面的规则。AI看到“网页文案”，可能因为网页与程序有关就标代码；看到“用文字解释报错”，又可能因为回答形式是文字就标文本。

要减少这种歧义，可以提供每类的含义、允许多标签的说明，以及几个容易混淆的例子。本章的依据是请求实际需要处理的内容，因此仅修改网页上的宣传文字，不自动涉及代码；如果还要求修复网页提交逻辑，就有了代码工作的依据。

还可以让AI在归类时指出请求中的相关内容。例如Q06的代码依据是“调整图片裁切脚本”，图像依据是“调整裁切结果”。这让小叶能够回到材料检查，而不是只看到一个孤立标签。

归类说明仍可能写错，需要看它援引的内容是否真实存在、是否支持当前标签。解释写得流畅，不能补上原请求没有提供的事实。遇到材料不足，应记录具体缺少什么；遇到已有规则没有覆盖的新类型，则应说明它为什么不适合现有类别。

开始使用一套规则时，可以检查若干普通请求，再专门检查多主题、内容不完整和接近边界的请求。只检查最典型的简单例子，容易错过规则真正不清楚的地方。检查的目的是找到需要改进的说明，不是从几条正确示例直接推断整个问题库都已分对。

2. 从相似材料中发现分组，与按既定类别归类有不同用途

有时小叶还不知道应该设哪些类别，可以先让AI找出反复出现的问题及可能的分组。这能为设计目录提供候选方案。

在数据分析中，聚类也用于根据数据中的关系形成组。组内是否相似，与采用什么特征、怎样衡量相似性以及使用什么方法有关；评价聚类结果也需要相应依据。scikit-learn：聚类及其评价

放回本章的例子，若特别关注使用场景，海报标题与海报背景图可能被放在一起；若关注处理媒介，海报标题可能与活动介绍放在一起。这两种思路揭示了不同共同点，不能仅凭某次自动分组就宣布其中一种是材料唯一正确的结构。

小叶可以先看每组的具体成员，再判断这些共同点是否支持答疑、查找或教学。若适合使用，再给类别明确含义，并试着归入新请求。这就把发现候选结构与采用工作规则连接起来。这里是对方法用途的说明，本章没有运行实际聚类实验，也没有测量AI的归类能力。

3. 分类改变后，旧资料与旧统计也要能够解释

假设问题库原先分别使用“写作”和“文本”两个标签。小叶发现含义可能重叠，想合并为“文本”。如果两个标签指向同一请求，合并后按编号去重，才能得到新类别的请求数；不能直接把旧数量相加。

合并前还要看旧词实际指什么。如果“写作”原来只包括从头起草，而“文本”原来只包括已有文案修改，合并就改变了分类粒度；如果它们原来就是同义重复，合并主要是在统一名称。两种修改都可能合理，但以后解释历史统计时，依据不同。

反过来，把原来的代码类拆成网页代码与其他代码，需要旧记录包含足够信息。旧表只有“代码”两个字，不能凭这个标签还原所有更细的归属。可以回看原请求，暂时无法判断的保留待核查，不应为了让新目录填满而猜测。

因此，保存原请求、记录规则版本和变更内容很有价值。分类表可以调整，但应让后来的使用者知道，当时的标签表示什么。若要比较不同时间的类别数量，尽量采用相同规则重新整理，或清楚说明范围发生了怎样的变化。

十、把分类做成一件能够开始、也能够改进的工作

小叶不需要先设计出所有校园AI问题的完整知识体系。他已经有十二条记录和具体用途，可以先把主题、状态和紧急信息分别记录，在实际查找中检验这个安排。

一份简短的分类说明，就能保存本章最重要的约定：

每个编号代表一条完整请求。主题按实际需要处理的内容标记，可以多选；当前状态按同一时点的整条请求记录，只选一个。主题不明时说明缺少的信息，主题明确但不在当前范围内时记录具体内容。所有入口保留原编号，统计不同请求时按编号去重。类别调整时保留旧规则与修改说明。

这段说明可以配上十二条中的几个代表例子。它没有规定未来所有可能类别，却已经让现在的对象单位、交叉关系和例外处理有据可依。

接下来，小叶实际尝试查找“紧急且未处理的请求”，能找到Q04；想阅读代码问题的已解决案例，能找到Q05和Q11。如果某类资料经常难以找到，再检查是标签判断错误、粒度不合适，还是缺少了一个重要维度。不同问题对应不同修改，不必每次都推倒重建目录。

这里还有一个容易忽略的界限：把请求放进代码类，只表达它满足本章的主题条件，不会同时告诉我们它很难、很重要、适合哪个AI或一定需要多久。想获得这些结论，还需要各自的事实和理由。

分类把对象之间某些关系表达出来，让后续判断有了清楚的起点。下一章讨论命题、前提与结论时，我们会进一步检查：从已经说清的事实出发，哪些结论得到了支持，哪些只是悄悄加进去的推测。

十一、练习与参考分析

练习一：改造一个混在一起的目录

小叶的同学提出五个互相排斥的栏目：代码、图像、紧急、未处理、已解决。每条请求只能放进一个栏目。Q03正在处理而且紧急，Q12已经解决。应该怎样调整这个安排？如果同学坚持首页只能显示一个入口，是否就必须放弃其他信息？

**参考分析：**先指出五个栏目混用了主题、优先情况和当前状态。Q03同时符合代码与紧急，按原规则必须丢掉其中一个方面；它正在处理的状态还没有位置。Q12同样同时符合图像与已解决。困难主要来自栏目结构，不能靠反复要求归类者“选得更准”解决。

可以分别建立主题标签、当前状态和紧急信息。按本章给定事实，Q03记录代码、处理中、紧急；Q12记录图像、已解决、不紧急。两条仍各有一个编号，相关入口指向原记录。

首页只能显示一个主要入口，是展示或分派的需要。例如可以按当前状态组织首页，同时保留主题标签和紧急标记，并提供筛选。这不等于每条请求在所有方面只能属于一个类别。也可以优先展示紧急请求，但不能因此漏掉非紧急请求的正常处理入口。这里需要先分清资料中保存什么与首页首先展示什么。

练习二：十八次标签关联，为什么只有十二条请求

根据本章十二条记录，说明四主题数量相加为什么得到十八。若答疑范围为“文本或图像”，有多少条不同请求？同学说“文本标签最多，所以文本问题占用工时最多”，这个判断得到了支持吗？

**参考分析：**七条请求各有一个标签，四条各有两个标签，Q09有三个标签，因此标签关联为七加八加三，共十八次；独立请求为七加四加一，共十二条。十八这个数可以用于描述标签关联，不能直接改称请求总数。

文本六条，图像五条，共同对象是Q04与Q09。六加五减二等于九。这里“或”包含同时涉及文本与图像的情况，并按不同编号计数；若先排除两类共同成员，得到的将是另一种筛选含义。

工时结论没有得到支持。标签表示涉及哪类工作，没有提供实际耗时。多标签请求还可能同时包含几种工作，若需要按主题统计工时，应进一步约定如何记录各部分时间及共同讨论时间。不能直接拿主题出现次数代替工时，也不能把一条综合请求的全部工时重复归给每个标签而不说明。

练习三：总数吻合，哪里仍然可能出错

一个版本漏掉了Q07，又把Q03同时放进处理中与已解决。未处理、处理中、已解决三组数量分别变成三、四、五，加起来仍是十二。仅看这个合计，能否确认状态分类正确？如果修复了重复与遗漏，是否就证明所有状态符合实际？

**参考分析：**不能。三组的并集缺少Q07，尚未覆盖本章讨论范围；处理中与已解决又共享Q03，不满足当前状态的互斥要求。一次遗漏与一次重复相互抵消，解释了合计为什么仍然正确。

核对时可以从原始十二个编号出发，检查每个编号在三组中出现几次。Q07出现零次，Q03出现两次，其他编号各一次。按本章原始事实，应将Q07恢复到未处理，并删除Q03在已解决中的错误登记。这里能够确定如何修复，是因为题目已经给了原始状态；真实资料有冲突时，需要查看更新记录或确认事实，不能随意保留其中一份。

修复后，结构检查通过。但若有人把一条仍未修好的请求单独标成已解决，它仍可能只出现一次。所以还需根据完成记录判断状态内容。覆盖、互斥与事实正确，分别回答有没有漏、有没有不允许的重叠、标签有没有符合对象。

练习四：三种上下关系，可以怎样推断

判断以下关系分别属于哪一种：网页代码问题与代码问题，Q03与网页代码问题，Q09的配图子任务与Q09。再分析两句话：“Q03很紧急，所以网页代码问题都很紧急”；“Q09的配图已经完成，所以Q09已解决”。

**参考分析：**第一组是类与类的包含关系：按本章定义，每个网页代码问题都是代码问题。第二组是具体对象与类的归属关系：Q03是网页代码问题的一个实例。第三组是部分与整体的组成关系：配图子任务属于Q09包含的工作。

第一句话从Q03这一个实例推广到整个网页代码类，推理缺少依据。而且，表中Q05涉及网页提交逻辑，Q09涉及网页交互代码，二者都标为不紧急，已经是这个普遍结论的反例。类别之间的包含关系不会使某个成员的全部属性自动成为所有成员的共同属性。

第二句话只确认了整体的一部分。Q09还包含文案与交互代码的工作，要确认整条请求已解决，需要核对全部约定要求及必要的整合结果。题目没有给出这些信息，因此尚不能得出结论。若将三种关系都画成没有说明的上下级，就容易把可以沿类别向上归属的推断，错误地套用到整体完成状态上。

练习五：四个“分不清”，该用同一种办法吗

考虑四种情况：请求明确要求改标题与配图；请求只写“AI做出来不对”；请求明确询问如何组织多个AI分工，但当前只有四个媒介主题；请求内容已知，但是否算复杂在同学之间有分歧。分别说明应优先检查什么。再判断尚未到期的请求距离截止恰好二十四小时，是否符合本章另设的临近截止规则。

**参考分析：**第一种是清楚的多主题交叉，按允许多标签的规则处理即可。第二种主要缺少对象事实，可以补充任务与结果，暂时记录未确定的原因。第三种是当前类别范围不合适，可以说明已知的新主题，再决定是否增加类别。第四种要检查“复杂”的参照对象、判断因素与典型例子；若这些仍留下中间情形，可保留程度信息，并按实际安排需要约定处理办法。

这四种困难不应都被改写成AI判断不够自信。多主题问题可能根本不需要二选一，缺少事实的问题需要新信息，类别缺口需要调整范围，程度边界则需要澄清尺度或行动规则。

恰好二十四小时包含在“不超过二十四小时”之内，还须满足尚未解决等给定条件。二十四小时一分钟不满足这个时间条件，但差一分钟不说明现实重要性发生巨大变化。截止时间未知也不能被自动当作时间充足；应明确保留未知状态，按需要补充信息。

练习六：目录变细以后，旧数量能直接搬过去吗

另设一个独立的小问题库：旧规则把五条请求都记为代码，除此以外只留下了简短标题。小叶想拆成网页代码与非网页代码两个互斥类别。阅读现有资料后，能确认两条是网页代码，一条是非网页代码，另外两条暂时无法确定。应怎样登记？如果AI建议把两条未知请求平均分给两个类别，这样做有什么问题？

**参考分析：**可以记录两条已确认网页代码、一条已确认非网页代码，以及两条待核查的归属信息。五条原始请求都要保留，待核查描述当前掌握的信息，不是又发现了一种与网页、非网页并列的代码主题。

平均分配会把没有依据的归属写成已知事实。目录数量看起来平衡，并不意味着分类符合请求内容。在补充信息以前，只能报告各类已经确认多少，以及还有多少未确定；不能说网页代码总共恰好两条，也不能说已确认的三条就是整个问题库。

如果确实需要知道在这个二分规则下可能的数量范围，网页代码可以是两至四条，非网页代码可以是一至三条，两类最终合计仍为五条。这是未知归属允许的范围，不代表各情景概率相同，更不是让我们任选一个数字填写。

进一步可以回看完整请求或询问同学，补齐判断依据。应保留旧规则及此次拆分说明；比较历史数量时，先看旧资料能否按新规则重新整理。此题的五条属于另设问题库，不能并入本章原有十二条请求的计数。