第26章
第二十六章 封装不是宣布出来的：试用、检验、修正与成熟
一 一次成功只能说明这一次发生了什么
一个工具第一次给出正确证明，足以使人兴奋，却不足以形成广泛承诺。它可能碰巧遇到熟悉题型，可能使用了隐藏条件，也可能在表达正确结论时包含尚未发现的缺口。封装的发生不能从一次演示直接跳到常规调用，中间需要认识成功与失败怎样分布，以及什么条件使两者改变。
这里的起点不是怀疑一切，而是给成功合适的解释。一次成功说明在当前输入、版本和使用安排下出现了某种结果。若要进一步说某类任务可以被稳定承接，就必须扩大证据范围。主张扩大多少，检验就应当相应改变；不能用更响亮的名称替代尚未完成的工作。
可以把封装成熟看成几种可修订的状态。候选状态意味着方法看起来有希望；限定可用状态意味着在说明范围内有相应依据；常规调用状态意味着维护、异常处理与使用条件已经形成；可继承状态则要求后来者能够在不重造全部过程的情况下继续使用和改进。它们不是所有技术必须依次通过的统一行政等级，而是帮助辨认不同承诺。
不同能力也不会以同一种方式成熟。一项精确算法可以通过形式论证说明对全部合法输入的性质，同时仍需检查实现；一种开放式材料整理需要通过来源与任务测试逐步建立范围；一种研究建议可能长期只能作为候选探索。不能因为它们共享AI界面，就赋予相同的可靠性解释。
NIST在二〇二三年发布的人工智能风险管理框架，把风险放在具体使用情境与生命周期中讨论，并组织治理、映射、测量和管理等功能。[19] 本书不把该框架当作现成的学术能力认证，而采用其中一个重要方向：可信不是一次测试取得后永久保有的标签，而与使用条件和持续管理有关。
因此，成熟需要同时认识工具内部和使用外部。一个系统在固定测试环境中表现良好，用户却以不同定义输入，实际活动仍可能失败。开发者不能把一切问题归给用户，用户也不能期待一个接口替自己自动确定所有任务意义。封装应该尽可能把常见误用变成可识别状态，让边界不只写在没人会读的说明末尾。
重复使用的重要性，在于它能够暴露不同条件，而不只是增加成功次数。若一千次调用都来自同一模板，它们对新领域的支持可能很有限；若少量调用覆盖关键边界，反而能够揭示结构性缺陷。次数是证据的一部分，任务差异与测试设计同样重要。
同时，失败不能只被算成总体成功率中的一个减项。一次失败如果显示适用边界说错，可能要求改变整个承诺；一次格式问题则可能通过局部修正处理。封装成熟需要分类理解失败的意义，而不是只追求一个越来越漂亮的平均数字。不是所有错误具有同样后果，也不是所有修复具有同样范围。
这意味着，可靠封装必须允许暂时降级。发现关键边界不成立，可以缩小任务范围，增加局部检查，或者暂停某项用途。降级不是承认工具文明失败，而是让承诺重新与证据匹配。不能因为宣传已经称其成熟，就强迫后续异常只能被解释为个别使用者的问题。
封装的真正成熟，因而表现为活动在正常条件下能够顺畅调用，在异常条件下能够改变状态。它既让后来者少重复已经稳定的过程，也不让过去的成功阻止新的认识。没有后一个条件，成熟很容易变成封闭。
二 零失败不等于零风险：一个可直接验算的例子
假设某类任务每次失败的概率都是p，各次测试独立，测试任务又来自与未来使用相同的分布。在这些很强的假设下，连续n次没有失败的概率是(1−p)的n次方。这个式子已经足以说明：观察到零失败，不意味着p只能等于零。非零风险也可能暂时没有显露。
若我们把百分之五作为一个分析用尾概率，令(1−p)的n次方等于零点零五，便得到p等于一减零点零五的n次方根。对零失败样本而言，这给出在上述二项假设下的一侧精确置信上界。它不是“真实失败概率有百分之九十五的概率低于该数”的后验陈述，也不是任何工具可以安全使用的统一门槛。 若n为零，该计算没有提供经验约束；文中的数值例均取正整数样本量。置信水平描述重复抽样程序的覆盖性质，不描述一次观测后参数本身的随机性。
当n为一百时，上界约为百分之二点九五；当n为一千时，约为百分之零点二九九。数字来自同一公式，而非某项AI实测。它们的意义在于说明样本量与可支持承诺之间的关系：没有发现错误，也可能只获得相当有限的风险约束。特别高的可靠性主张，需要与之相称的依据。
但实际生成系统往往不满足独立同分布。多次测试可能共享模板和隐藏错误，工具版本可能变化，使用者也可能根据前次回答调整输入。此时，不能机械套用这个上界。公式的价值不仅在于计算，更在于让被省略的假设显露。若条件不成立，就应当改变统计模型或采用其他证据，而不是继续展示一个精确小数。
任务分布也可能掩盖重要差异。设绝大多数输入很简单，少数输入恰好触及概念歧义。总体成功率很高，未必说明关键边界可靠。可以分层报告不同任务的表现，专门构造边界案例，并把不能支持的范围排除在承诺之外。真实封装不需要假装覆盖一切，明确有限范围反而使调用更有根据。
对数学证明而言，统计表现还不能替代某个具体定理的证明。一个系统过去一千次都答对，只能支持关于系统行为的某种经验判断，不能使第一千零一个全称命题自动成立。工具成熟史与当前命题依据，应当分别保存。前者帮助决定如何使用，后者支持此处说了什么。
这并不否定概率证据。许多实际系统只能在不确定条件下运行，合理决策需要统计、测试和后果分析。关键是不要把一种证据越界使用：概率评估不能冒充演绎证明，演绎证明也不能替代命题与现实之间的适配检验。封装应当明确自己采用哪种依据，而不是统一包装为已经验证。
还要注意选择性展示。如果测试者只公布成功案例，读者看到的是经过筛选的集合，而非原任务分布。把演示视频看成可靠性统计，会产生严重误读。成熟封装需要保留足够的测试设计和失败信息，使使用者能够认识证据如何形成，而不是仅仅接受一组美观结果。
另一方面，公开所有原始材料也未必合适。某些材料有隐私、合作或资源限制，可以提供去标识化结果、方法说明和受控复核。重点在于证据能否支持主张，不在于是否无差别曝光全部过程。透明应服务于检验，而不是使参与者丧失合理边界。
这个例子最终说明，反复试用必须与条件分析结合。次数本身不会自动变成成熟，成熟也不是某个永远不变的数字。它是一个逐步形成的认识组织：知道哪些成功可以推广，哪些失败需要改变范围，以及什么新条件会使以往依据不再足够。
三 从工程可靠性到使用者侧封装
一个系统已经取得适当验证，不代表使用者立刻形成合理依赖。有的人仍然逐项重做，无法利用封装节省的资源；有的人则因一次成功便扩大到所有任务。工程侧能力与使用者侧信任，需要通过具体互动逐步对齐。封装既有技术形成，也有使用关系的形成。
帕拉苏拉曼与赖利区分自动化的使用、误用、不用及设计组织层面的不当使用，提醒我们过度依赖与不合理拒用都值得分析。[18] 本书据此不把信任多寡本身作为好坏尺度。需要的是依赖与实际能力范围相称，而不是尽量相信或尽量怀疑。
设想小林最初对文献核对工具逐条检查。几轮之后，她发现系统对完整书目能够稳定定位，却经常混淆仅有缩写的会议名称。她于是允许前一类进入较粗颗粒度调用，对后一类保留补充输入与人工核对。这里形成的不是一个抽象信任分数，而是一张有差异的使用地图。
如果平台只告诉她总体准确率，她很难形成这张地图。合适的接口可以显示来源是否取得、版本是否确定、支持段落是否存在，以及哪些结果只是候选。状态分明，使用者才能把注意放到真正未被承接的位置。强迫她读取全部内部日志，未必比清楚状态更有帮助。
使用者侧封装还包括实际经验。她需要见到系统如何处理异常，知道求助和重开的路径可用，而不只是读过一份承诺。一项替代工具在关键时刻无法取得，说明名义上的退出并未形成有效能力。可靠使用要把资源可得性、响应时间和协作条件一起纳入，而不是只列功能。
然而，个人经验也可能误导。长期只在简单任务中成功，会使她过度推广；一次显眼错误又可能使她拒绝所有已经合格的用途。教育可以通过有代表性的边界案例帮助校准，让经验不只由偶然遭遇组成。校准不是教学生永远检查一切，而是学习区分何时调用整体、何时重新展开。
系统改变后，这种关系也需要更新。一个版本的成功经验不能无限转移到另一个版本；反之，小规模修订也不必要求用户从零重新学习全部内容。维护者应当说明改变涉及哪些承诺，提供相关回归结果，帮助使用者调整适当部分。更新说明因此也是封装的一部分，而非发布宣传的附件。
成熟的使用关系还允许不同角色具有不同深度。普通调用者需要清楚用途与异常入口，专业使用者需要理解关键接口，维护者需要掌握更多内部机制。不能因为普通用户不懂维护就否认其能力，也不能因为有人能够维护就假定普通用户已经获得合适说明。分层不是知识阶级的自然化，而是可以调整的活动分工。
若一个平台主动培养用户无法退出的习惯，把全部经验锁在不透明界面中，熟练度可能增加，主体能力却未必获得可迁移支撑。使用者侧封装应当尽量把有效方法、问题和记录变成可以带走的资源，而不只是对某个品牌的信赖。工具可以更换，已经发生的认知不应因此全部消失。
因此，工程成熟与使用者信任相互支持，却不能互相替代。可靠性不是靠相信产生，合理调用也不是靠技术报告自动形成。两边都需要实际条件与反馈，使一个已经做成的能力真正成为使用者可以进入的新起点。
四 维护使成熟能够持续，而不是停在一次验收
封装交付之后，任务还会变化。新输入出现，资料更新，依赖组件修改，使用者进入不同情境。成熟能力能否继续成立，取决于这些变化是否被认识和处理。把验收当作结束，可能使封装的成功历史逐渐变成过期依据。
可以为每项重要封装保留一份简明记录：当前任务范围，关键依赖，已经通过的检查，已知失效类型，以及需要重新评估的变化。记录不必覆盖每个内部细节，但应当足以让下一位维护者知道哪里不能轻率修改。文明继承需要留下理由，而不只是留下一个能够运行的文件。
维护还包括停止支持的决定。如果某项能力不再有资源维持，应当清楚标明，而不是让旧接口继续以成熟外观运行。使用者可以选择冻结版本、迁移任务或缩小承诺，但不应在不知情的情况下失去关键支撑。封装退出同样需要被设计，不能只设计成功交付。
在研究团队中，维护工作往往不如新成果显眼。为了避免能力随人员离开而消失，可以让方法、反例与验证进入共同资产，并承认维护贡献。这里的共同并不意味着取消个人来源或公开所有私人材料，而是让得到授权的有效条件能够继续被组织使用。没有传递安排，工具遗留不等于能力遗留。
同时，维护不应把系统永久冻结。新问题可能需要不同接口，新的证明可能使原检查更简洁。维护者的任务不仅是让过去继续运行，也包括判断何时应当重新设计。保存与创新不是完全分开的两类劳动，好的维护常常能够发现新的发生机会。
本书因此把封装成熟理解为一种可持续承诺：在所说明范围内有适当依据，在条件变化时能够更新承诺，在失效时有可执行回应，在交接时能让后来者理解如何接续。它不要求零风险的神话，也不接受用永远在发展为由逃避具体质量。
这种成熟还需要经济和制度条件。长期维护不能只靠某位研究者的热情，公共工具也不能仅在发布时获得奖励。谁承担成本、谁获得使用收益、谁有权提出修订，都影响封装能否持续。后面的平台与公共条件讨论，将进一步展开这种责任分配。
对于个人研究者，最重要的实践转向是把使用史写成有差异的能力地图，而不是一个越来越高的信任数字。哪些任务可以整体调用，哪些仍是候选，哪些需要专业支持，哪些已经退出，都应当能被辨认。如此，放心不是停止思考，而是把思考安排到尚未被可靠承接的地方。
本章从一次成功写到维护，说明封装不是技术产品的自我命名，而是活动、证据、使用与制度共同形成的结果。只有经过这种发生，较大颗粒度才有理由被后续活动调用。否则，所谓升级可能只是把更多未解决过程藏在一个按钮后面。
从试用到维护，封装成熟意味着承诺与依据能够持续匹配，而不是平台为自己授予了一个永久称号。较大颗粒度只有在相应范围内得到可靠支撑，才有理由被后续活动调用。支持这种承诺的证据也必须分清：证明回答推论是否成立，测试描述限定条件下的行为，来源核对追踪事实依据，开放探索则保留尚未完成的状态。承认它们各自的边界，才能既不提前神化候选工具，也不把已可靠承接的过程重新压回每个人。