第23章　封装不是神话：拒绝怎样成为实际能力？

一、“已经封装”，究竟承诺了什么

程岚把私人研究与对外服务分开以后，还不能直接宣布隐私已经得到保护。界面上有两个区域，不代表后台调用不会跨越；说明文字写着不保留，不代表每一条后续路径都已按此执行。封装如果只是一项命名，它最多说明设计者希望形成某种边界，不能证明边界已经在实际发生中生效。

本章将封装理解为一种受检验的组织工作：把内部发生对外可提供的能力、可进入的材料、可交付的显露和需要保留的边界结合起来，使使用者不必接触全部内部细节，也能够在一定范围内使用服务。它不是把复杂性消灭，而是把复杂性中的判断分配到不同位置。由谁承担、怎样检测、发生失效时怎样修复，都属于封装的内容。

因此，“封装成功”不能意味着永远不会出错。更可操作的表达是：在明确的任务、条件和威胁范围内，现有检查支持某些保护要求已经执行；对于未覆盖的情形，继续保留不确定性，并设置发现和修复的路径。这样的表述不如绝对安全的宣传有力，却更接近可以承担的承诺。

我们先从一项很窄的程序演示做起。演示不是实际AI系统，也不处理真人资料。它的目的只是让“拒绝必须改变调用结果”这一要求得到有限实现，再据此辨认尚未解决的困难。

二、把要保护的东西写成测试对象

演示中设置四类材料：公开规则、允许向客户提供的方法、提供者的私人笔记，以及客户只允许本次任务使用的案例。私人笔记与客户案例各含一段人工编造的标记，用来检查它们是否错误进入输出。这些标记不是秘密内容本身，也不能代表现实隐私的全部形态；它们只是有限测试的可辨认对象。

再设置一项明确许可：某位客户可以在某个项目中，为流程检查这一用途，调用指定版本的方法，许可在规定时点之后失效。公开规则可以一般阅读，私人笔记和客户案例则不在这项许可之内。这里把身份、项目、用途、材料版本和时间分别规定，是为了避免“知道方法标识就能调用全部内容”。

程序对一项请求所涉及的全部材料逐项检查。若任何一项不满足当前许可，整个请求不交付内容；若全部满足，则只组合那些被允许的材料。拒绝提示也不暴露私人内容名称和具体理由细节，而给出有限的范围不满足说明。这个设计较为保守，实际服务还可以讨论是否返回安全的部分结果，但必须明确其条件，不能在拒绝一部分的同时意外暴露另一部分。

本轮实际运行了十六个人工设定的测试：四个请求按预期允许，十二个按预期拒绝，全部测试与预设结果一致。它们包括更换请求者、跨项目、改变用途、过期、撤销、版本不匹配、未知材料标识，以及允许材料与不允许材料混合请求等情形。输出中没有出现两类人工私人标记。完整程序和逐项结果保存在写作包的程序与编辑目录中。

这个结果只说明该段程序在这些给定输入上执行了所写规则。它不是百分之百的隐私保护率，也不证明现实系统中的身份真实、标记准确、缓存清理正确，更没有测试一个语言模型能否从其他材料重建相关内容。把十六个测试通过写成整个系统安全，恰恰会重复本书所反对的“用可见对勾代替实际证明”。

三、可信输入是演示没有解决的前提

程序假设请求者身份已经被可靠确认。如果现实服务允许调用者自行填写“我是获准客户”，而不进行相应确认，规则即使逻辑无误，也无法形成原来的保护。项目、用途和时间同样如此：若这些条件只是请求者自由声明的文字，规则得到的不是可靠条件，而是任何人都可以改写的愿望。

材料标记也需要来源。把一份私人笔记改名为公开说明，不应自动使其获得公开资格；把不同来源材料混合成一个新文件，也不能仅凭新的文件标识取消原有边界。演示中的注册表由程序直接给定，因此避开了实际系统最困难的一部分：材料如何进入注册表，谁能修改分类，修改需要什么依据，旧版本怎样继续受约束。

同样，用途匹配并不只是比较两个字符串。一次被称为“服务改进”的活动，可能与客户原来理解的任务相差很大。程序可以检查明确分类，却不能自动保证分类本身已经得到充分理解和合理制定。需要把技术校验与规范判断分开：技术执行的是某个已经写下的规则，规则的正当性与可理解性需要另外论证。

因此，封装必须向前追溯条件怎样取得可信性，不能只守住最后一个判断函数。身份确认、材料登记、用途定义和规则变更，都属于保护的发生史。将这些前提交给外部人员处理，并不意味着它们从责任地图中消失。只要后续承诺依赖这些前提，就需要说明相应工作由谁承担、怎样检查。

四、没有输出原文，仍然可能跨越边界

有限演示采用直接组合允许材料的方式，没有接入自由生成系统。若实际服务能够根据多份材料形成新的表达，保护问题会更复杂。它可能没有逐字输出私人笔记，却在回答中呈现了相应内容；也可能用不同措辞暴露了某项原本被限制的判断。此时，检查是否出现人工标记或原句，只能覆盖一部分情形。

这要求测试对象从逐字复制扩展到用途与含义的越界，但不能因此宣称任何语义检查都能完全解决问题。某种新回答与私人内容相似，可能来自实际调用，也可能来自公共信息或独立推断。需要追踪材料访问、生成过程中的可观察接口和后续用途，不应只凭输出相似就断言发生了哪一种侵入。

对于特别敏感的材料，一个设计选择是根本不让它进入某类对外服务的可调用范围，而不是在全量调用之后仅依靠最后输出过滤。这是本书提出的风险控制思路，并非对任何技术实现的绝对保证。它会牺牲某些便利或能力，也需要说明内部工具是否还有其他路径接触相同内容。限制前置并不能替代后续检查，后续检查也不应成为无限前置获取的理由。

另一项设计选择是将可服务方法与私人案例分开维护。对外系统调用经过整理、范围明确的方法表达，必要时由提供者在受约束的内部流程中完成更复杂判断。这样的安排可能增加工作成本，却有助于避免“回答越丰富，私人内容越容易成为素材”的结构。它是否足够，需要根据具体服务和威胁进行检验。

五、规则变了，旧的副本怎么办

程岚撤销某项方法的对外调用后，主库中的许可已经关闭，但如果服务仍保存着之前的中间结果或复制材料，下一次请求可能绕过主库重新取得内容。本章以此作为构造风险，不指控任何现实系统。它说明撤销不是单一位置的一次状态改变，而是需要追踪相关内容和使用资格在整个服务中的传播。

至少需要区分三种情况。第一种是尚未交付、仍处于系统内部的副本，可以按预定安排处理其后续使用。第二种是已经在许可范围内交付的内容，需要尊重此前约定，不能承诺让接收者恢复为从未获得。第三种是未经允许已经扩散的内容，需要阻止新增扩散、说明可采取的补救，并诚实承认不能完全逆转的部分。

规则变更也可能影响客户的合理依赖。某个客户购买了一项明确期限内可使用的方法，提供者不能在没有说明和处理的情况下随意撤去所有支持，再以隐私为由拒绝承担任何后果。保护私人发生与兑现已经作出的服务承诺，需要在转换之前尽量安排。拒绝可以阻止新的共同化，并不自动抹掉过去已经成立的共同事务。

因此，封装需要管理的不只是内容状态，还包括版本、许可和传播范围之间的对应。每次重要修改都应问：哪些未来请求应被阻止，哪些已有服务需要说明，哪些副本需要处理，哪些后果只能通过补救承接。把这些问题分开，才能避免“已撤销”一词掩盖几种实质不同的处境。

六、日志也需要被保护和检验

为了验证调用边界，系统可能保留访问与决定记录。这些记录有助于追踪请求进入了哪里、使用了哪些材料、依据哪一版规则被允许或拒绝。但日志自身也可能包含私人信息。例如，某位客户反复请求某一类帮助，或者程岚持续查看某一项自我笔记，记录就可能暴露新的内容。保护不能只针对主文，而将记录区视为无限开放的例外。

可以按验证任务减少记录内容。例如，记录材料标识、许可版本和处理结果，而不是默认记录全文；需要更详细的故障分析时，再以限定方式接触相应材料。这样的减少会降低某些核验能力，也需要面对遗漏风险。没有一种日志粒度在所有任务中都最佳，关键是让取舍具有理由，而不只是为了方便全量保留。

日志还可能与真实执行不一致。若程序先写下“拒绝”，随后另一路径仍然返回内容，漂亮的记录不能证明保护成功。检查必须尽可能连接到实际交付，而不是只看流程名义。对于高影响服务，还需要考虑由与日常操作相分离的位置进行复核，但复核者的权限和材料使用也必须受到约束。

本书在这里不许诺一种绝对可信的记录系统。它提出的是证据链要求：权限决定、实际访问与对外交付之间的联系，需要能够被检验；无法覆盖的部分，应明确保留为风险。把证据的边界说清，不是降低保护标准，而是阻止有限证据被宣传成全面安全。

七、测试不能只挑系统最擅长的情形

若测试永远使用明显写着“私人”的文件，并且请求都按正常界面操作，结果可能很好，却未覆盖真正困难的转换。设计应当加入混合材料、旧版本、边界时间、撤销之后的请求，以及异常路径。还要检查失败时是否暴露内容，是否允许以另一种名称再次调用，以及用户能否理解实际发生了什么。

更难的是测试规则本身是否合理。一个服务可能非常准确地拒绝所有请求，从而在内容泄露检查上得到优异结果，却完全无法提供承诺的帮助。保护与服务不能只用一个指标评价。至少应同时观察正确允许、正确拒绝、错误允许和错误拒绝的情形，并说明这些分类依赖怎样的规则与人工裁定。

在我们的十六项演示中，四项允许与十二项拒绝的分配只是设计选择，不能被当作真实请求分布。若现实中绝大多数正当请求都会被错误拒绝，这个系统就不能因为“很少泄露”而被称为成功的服务封装。反过来，便利性很高也不能补偿关键边界经常被跨越。两类要求需要同时成立，并按风险与用途作具体权衡。

还应允许测试发现“不知道”。某个输出是否延续了受限内容，可能存在争议；某项许可是否覆盖新用途，也可能需要重新解释。将不确定一律记为成功，会美化指标；将不确定一律视为恶意，则会妨碍可改进的服务。较好的做法是暂停相应扩展、保留解释和复核的位置，而不是强迫所有问题在第一次运行时被二分。

八、使用者侧的封装，也在反复实践中发生

对程岚而言，一项保护安排是否可信，不只取决于设计说明，也取决于持续使用中的验证。她可以先在不含真实私人内容的条件下测试边界，再逐步使用实际任务，观察异常与修复。随着证据积累，她不必每次重新检查所有底层动作，但这种信任应当与具体范围相关，并能因重大变化重新打开。

这可以被理解为使用者侧的封装发生：部分细节判断被可靠安排承接，使用者转而在适当粒度上判断是否继续使用、是否扩大范围、是否重新核验。它不意味着使用者从此不需判断，而是判断的对象与层级发生了变化。可靠性不足或条件改变时，原先可以封装的部分就需要重新接受细查。

也不能把这种工作全部压给普通使用者。若只有能够自己审计系统的人才能获得基本保护，保护就会随技术资源不平等而分化。服务方、维护者、受约束审查者和共同体规则应当承接不同层级的责任，让个人可以在可理解的范围内作出判断。复合能力不仅包括提供答案，也包括使拒绝得到支持的能力。

本章的程序演示已经真实运行，但它只完成了一小块规则执行。身份可信、语义越界、复制传播、日志有效性、实际系统失效和使用者理解，都还需要更大的设计与检验。我们不将这些未完成部分用“封装”一词覆盖。下一章将用退出这个更严格的情形继续追问：当程岚不再依赖原平台时，她得到的究竟是一包文件，还是继续发生的可能。