一、一条可以返回的引文，与一个不能兑现的证据
设想一项资料整理服务能够为每个论点附上一条看起来规范的引文。使用者因此以为，生成已经与核验结合。但打开材料以后，他发现有的文献确实存在，却不支持相应论点；有的论点来自后人的解释，却被写成原作者直接主张。界面上的引文完整，没有使证据关系自动成立。
这个设例说明，可靠性不只涉及有没有输出，也涉及输出与承诺之间怎样连接。返回一条文献与确认文献支持某个断言，是不同功能。若把二者收进一个叫作“已验证”的标签，调用者就可能托付了系统尚未承担的工作。
国家标准与技术研究院二〇二四年的生成式人工智能风险文件，将自信表达却错误或虚假的内容、信息完整性以及人机配置等列为需要关注的风险，并强调风险随应用情境与系统层级变化。[14]本书在这里不复制其全部分类，而用封装视角进一步追问：什么使一个尚未可靠的过程，看起来已经成为可以放心调用的整体？
回答这个问题，并不是为了证明所有人工智能都不可信。它是为了把托付建立在相应证据上，让真正成熟的封装可以被使用，让尚未成熟的部分不被完成品的外观掩盖。反焦虑不能以低估实际风险为代价。
二、功能承诺需要比按钮名称更具体
一项叫作“资料核验”的服务，可能只检查链接是否能打开，也可能检查引文格式，还可能比较断言与原文。三个功能都与核验有关，却支持不同结论。可靠性说明的第一步，是把服务名称展开成实际能够承担的功能，而不是让使用者凭名称补足全部想象。
同样，“完成研究”可能只意味着生成一份报告，“理解材料”可能只意味着能够回答若干问题，“智能判断”可能只是按照既定标签分类。名称本身不是错误，问题在于它是否让承诺越过实际边界。一个有限而准确的名称，往往比一个包罗万象的名称更有利于成熟使用。
在重要活动中，可以先写出最小的功能说明：输入是什么，输出是什么，哪些关系需要成立，哪些情况不在范围内。这个说明不要求穷尽一切可能，但应当足以让调用者知道自己实际上托付了什么。若连这一层都说不清，讨论整体准确率便容易失去对象。
功能说明还应允许拒绝。材料不足时返回尚不能判断，可能比持续生成完整回答更符合承诺。拒绝不是能力的反面，而可能是边界辨认的一部分。一个无法承认未完成的系统，会把未知条件不断转换成看似完成的结果。
三、可靠性不能只看平均表现
设想一项服务在格式清楚的材料中表现良好，却在存在否定、转述和争议的材料中反复出错。如果测试材料主要来自第一类，总体成绩就可能掩盖第二类困难。对于需要处理争议的使用者，平均表现并不足以说明服务可靠。
因此，测试需要对应实际使用范围。常见情形、边界情形与后果较重要的情形，应当分别被看见。它们未必在数量上平均分配，也不能只按出现频率决定关注程度。某些少见错误如果会改变整项结论，就需要在任务分析中取得相应位置。
还要区分错误类型。漏掉一条无关标点，与把反对意见写成赞同，虽然都可以计为一次错误，意义完全不同。若指标只把它们相加，便可能以许多轻微改进掩盖少数关键失效。能力评估应当与任务承诺对应，而不是让容易计数的项目独占质量定义。
同样，测试结果应当说明无法观察的部分。某些长期影响无法在短期试验中确定，某些新材料类型尚未覆盖。承认这些限制，并不意味着测试无用；它使证据能够在自己的范围内发挥作用，而不被扩张成无条件保证。
四、重复使用很多次，为什么仍可能没有检验到边界？
一个使用者连续获得许多正确结果，可能逐渐形成整体信任。但若这些结果来自高度相似的任务，证据主要支持的仍然是那个狭窄范围。把同一种简单材料重复一千次，并不等于已经检验了一千种重要条件。次数与覆盖不能直接互换。
更严格地说，统计推断总有抽样与依赖条件。若每次试用都由同一个人选择容易成功的例子，或者多次结果共享同一错误来源，那么把它们当作独立、具有代表性的证据就不合适。这里不需要给普通使用者上一门完整统计课，却需要避免“我用过很多次，所以任何任务都可以”的推论。
可以用一个纯数学设想帮助理解：假定每次试验独立，失败概率固定为某个数，连续没有失败的概率才可以按相应乘法关系计算。现实中的任务分布、版本与情境不断变化，这些假定未必成立。数学公式再精确，也不能替没有检查的适用条件作证。
因此，重复使用应当与有目的的边界检验结合。哪些材料与过去不同，哪些结果一旦出错影响较大，哪些失败模式尚未被尝试，都是继续测试的线索。成熟信任来自对条件的理解，而不是只把顺利次数累积成心理保证。
五、流程稳定，不等于结论有依据
一套程序可以稳定地产生相同格式，甚至稳定地返回同一种判断，但结论仍然可能缺少依据。稳定性是封装的重要特征，却必须围绕正确的功能理解。若要承接事实核验，仅仅稳定输出格式并不足够；若要承接材料分类，也需要说明分类标准与任务的关系。
反过来，输出文字每次略有不同，也不必意味着功能不稳定。若关键证据、约束和不确定性得到持续保留，表达变化可能并不影响任务。对生成式流程，应该辨认哪些差异允许变化，哪些关系必须保持，而不是把逐字一致当作唯一可靠性标准。
这使验收条件需要与承诺分层。格式可用、证据可定位、断言被支持、行动适合现实，是不同层级。前一层通过，可以成为后一层的条件，却不能自动替后一层盖章。可靠封装不是把所有层级收进一个成功信号，而是让相关承诺各有实际支持。
在资料核验的设例中，可以采用分开的状态：“已找到相关文献”“已定位相应段落”“该段落支持本断言”“该断言适用于当前问题”。每次状态推进都需增加相应证据，而不是把同一个链接复制到四个位置。只达到前一状态的结果仍可有用，但调用接口应保留它尚未承担的功能。
六、验证可以封装，但验证也有边界
如果每次使用工具都必须从头独立完成同一任务，才能确认其结果，那么这一级的托付仍然有限。我们可以建设独立检查、约束验证、来源定位与异常识别，让验证本身部分进入封装。关键不是验证是否由自然人亲自完成，而是它实际提供了什么证据。
设想一个安排任务要求每个成员只能出现在一个同时段位置，且所有位置都必须有人。候选安排可以由某种生成过程提出，另一个流程按照明确约束逐项检查。这样的检查能够支持是否满足这些规则的判断，却不能证明规则已经照顾所有人的真实处境。形式约束与活动适宜性仍然不同。
这个例子展示了验证封装的潜力，也显示其边界。某些错误可以通过明确规则发现，另一些需要新的材料与互动。两者可以继续组合，却不能因为某部分可自动检查，就宣布整项任务已经获得无条件可靠性。
验证还应尽量避免同源回声。两个工具若只是重复同一段未经支持的材料，彼此赞同不能被当作两份独立证据。多模型、多步骤或多轮讨论都可能有用，但可靠性增长需要由实际差异与检验关系说明，而不是由参与者数量决定。
因此，所谓并行审查应报告各条检查线实际做了什么。程序查到引文格式完整，属于格式证据；返回原文并核对语义，属于内容证据；使用不同模型重复询问，至多提供新的候选意见。若审稿意见最终都由同一个模型形成，也应如实称为分角色自审，而不能借“并行”声称已经获得独立同行认可。审查自身必须遵守它要求正文遵守的归属原则。
七、从文字到行动，承诺范围会再次改变
一个系统提出一份安排，与它直接修改共享日程、发送通知或调整资源，是不同层级的行为。前者主要产生候选，后者开始改变他人的现实条件。不能因为文字生成在试用中表现良好，就把相同信任直接延伸到所有外部操作。权限扩大需要与实际功能和后果重新对应。
这并不意味着外部行动永远不能自动化。某些明确、稳定且可检验的任务，可以形成合适封装。问题在于行动范围是否清楚，哪些条件允许执行，异常如何被发现，已经发生的改变能否适当修复。范围越大，越需要让这些关系显露，而不是仅仅增加一个笼统授权。
设想社区通知流程把候选名单当作最终名单发送出去。文字内容可能完全正确，错误却发生在状态转接：讨论中的材料被当作已经确认的安排。这里的可靠性缺口不在语言表达，而在流程怎样区分候选、确认与执行。评价模型输出本身，未必能发现这种系统层面的失效。
因此，封装的测试应当覆盖转接，而不只覆盖单个模块。什么被认为已完成，什么可以成为下一步依据，谁或什么机制能够改变状态，都需要明确。复合系统越长，接口处的意义越不能被当作无须说明的细节。
八、条件改变以后，旧证据还能支持多少？
某个流程在一种材料上经过充分试用，后来被用于另一种材料，可靠性应当如何判断？最危险的做法，是因为名称相近就沿用全部信任。报告、访谈与文学文本都包含文字，却对事实、转述与虚构具有不同要求。输入形式相似，不代表任务机制相同。
版本变化也会带来类似问题。内部实现更新以后，有些旧测试仍然相关，有些则需要重新进行。保持界面一致有助于使用，却不能掩盖影响承诺的变化。对于重要流程，维护者需要说明哪些范围已经重新验证，哪些仍然处于观察之中。
使用者的任务目标改变，也可能使原来的工具不再适合。用于寻找线索的回答，转而被当作公开结论；用于初步理解的翻译，转而被当作精确引文。这些变化有时没有伴随任何技术更新，却已经扩大了实际承诺。可靠性分析不能只盯着产品版本。
因此，成熟封装应当具有条件敏感性。它不必知道世界上一切变化，却应当帮助活动辨认与承诺有关的变化。把不适用提示看成麻烦而不断绕过，可能是在主动拆除可靠性的边界。
九、可解释不等于正确，不可逐项解释也不等于无从检验
一个系统能够给出流畅理由，理由本身仍然需要证据。解释可能只是对结果的合理化表达，不能因为听起来连贯就证明内部判断可靠。对调用者而言，重要的是解释能否连接可核对的材料与约束，而不是长度是否足够令人安心。
反过来，无法让每位使用者理解全部内部机制，也不必意味着完全不能托付。某些功能可以通过外部测试、独立验证与长期维护获得支持。需要说明支持的范围与限制，而不是把完全透明设为一切使用的前提。
这里存在两种不同的理解任务。一种是理解实现机制怎样工作，另一种是理解在何种条件下可以对结果作出何种承诺。二者可以相互支持，但不必由同一个人以同样深度掌握。复合文明允许分工，也要求分工之间的证据关系真实存在。
因此，可靠性不是黑箱与白箱的简单二选一。内部可见程度、外部检验方式、任务后果与维护条件共同影响托付。任何单一标签都不能替代具体分析，更不能成为完全信任或彻底否定的快捷理由。
十、一份怎样的失效记录才有用？
设想资料服务把某位作者的转述写成了他的直接观点。一份无效记录可能只写“系统出现幻觉”，然后继续使用。这个标签说明出现问题，却没有帮助下一次活动辨认条件。更有用的记录需要保存足以复现或理解失效的材料、任务要求、相关输出，以及错误怎样被发现。
接着需要说明修复发生在哪里。是修改一处文字，还是调整了引用规则？是补充材料，还是缩小了服务承诺？局部修订可以解决当前文件，却未必改变后续流程；流程改变也需要重新测试，不能因为已经找到一个解释就宣布问题永久消失。
记录颗粒应当适当。保留关键片段与版本通常比无限保存全部私人材料更符合需要；涉及个人信息时，还应考虑哪些内容确实有必要进入工作记录。本书提出的是最少而充分的可追踪方向，不是要求将所有互动公开或集中储存。
最后，失效记录应当能够进入后续调用。若使用者永远看不到已知限制，维护记录便只存在于后台。可靠性不仅依靠修好问题，也依靠让相关人知道当前边界，使过去失败真正成为未来活动的条件。
十一、何时应该缩小、暂停或重新设计？
当结果无法支持原先承诺时，可以缩小适用范围；当错误后果超出可承受条件时，可以暂停相关使用；当问题来自流程接口，而不是单个输出时，则需要重新设计活动。这些选择不应被视为对人工智能的背叛，它们是能力建设的一部分。
缩小范围有时能够使功能真正成熟。把服务从完整事实核验调整为来源定位，让调用者知道后续仍需比较原文，可能比维持虚假的全面能力更有价值。有限可靠的单元能够进入新的复合，不必因为不全能而失去意义。
暂停也不等于永远拒绝。一项流程可以在补足材料、支持与验证之后重新使用。关键是恢复应当有具体根据，而不是仅凭时间过去或名称更新。信任可以重建，但不能靠遗忘失败来重建。
对于后果重大的实际任务，通用生成式工具不应被当作相关专业制度与验证的替代品。本书讨论能力与风险的分析框架，不提供对任何具体高风险部署的许可。风险越大，越需要相应领域的证据与责任安排。
十二、末端使用者不应成为全部不确定性的容器
某些系统把所有难以处理的情况都交给人，却没有为人提供时间、材料与支持。表面上，每一步都有人工确认；实际上，确认者可能无法承担所要求的判断。这样的安排把未完成的封装留给末端个人，却又在成功时宣称系统已经自动运行。
解决方向不只是培训使用者更认真。需要检查任务怎样分配，哪些异常可以由其他机制承担，哪些范围本来就不应当承诺，是否存在适当的升级处理与修复。个人学习可以是其中一部分，但不能替代全部设计与组织工作。
同样，使用者也不能因为工具参与，就把自己已经作出的承诺全部取消。实际拥有的权限、提供的材料与对外说明，仍然需要被辨认。可靠的复合关系不是谁都不负责，而是不同作用与不同责任能够对应。
因此，风险治理与主体边界分析在这里相遇。只有准确知道能力由哪些过程承担，才能判断哪些支持缺失、哪些责任错位。把人说成永远最终负责，或把系统说成自动负责，都不足以完成这种对应。
十三、不确定的远期风险，与眼前可辨认的风险
关于更强人工智能的远期情景，可以继续研究，但不应把所有讨论都推向一个最终结局。眼前的材料失真、错误转接、权限扩大与支持不足，已经具有可以分析的条件。它们不需要等待某种一般智能出现，才值得被认真处理。
反过来，能够处理若干眼前问题，也不证明远期风险已经消失。不同时间尺度需要不同证据与方法。本书不从局部封装机制推导整个人工智能未来必然安全，也不从远期不确定推导现在所有工具都不值得使用。
较稳健的态度是保留分层判断。明确当前承诺，研究中期部署条件，对远期情景保持适当的不确定说明。这样，个人与组织能够在已有证据上行动，同时不把未知伪装成确定。
这也让焦虑获得可处理的颗粒。人不必每天独自承担整个人类未来的全部不确定，才能合理使用一项工具；但在自己实际参与的活动中，可以要求必要证据、支持与修正。关注不等于无边界恐慌，行动也不需要绝对保证。
十四、值得托付的整体，需要持续发生
可靠封装不是界面设计完成时颁发的一张证书，而是功能、条件、验证、维护与使用经验共同形成的关系。它可以扩大，也可以收缩；可以在某个层级稳定，又在新任务中重新展开。理解这种动态性，有助于摆脱盲信与永疑的两极。
真正成熟的工具关系，允许使用者在证据支持的范围内放心调用，也允许异常改变信任。它不要求人人重做全部内部工作，更不把所有不确定都交给一句“最终由人负责”。内部复杂性应当得到真实承接，外部承诺则应当保持诚实。
验收需要跟随功能承诺，而不是跟随按钮名称。即使可靠产出已经成立，学习也仍是另一项主张。下一章检查，在什么活动安排中，学生能交出好结果却未形成目标所需的经验，以及怎样为这种经验创造条件。