方案选型

目录

第6章　方案选型

第5章把“做到什么算合格”写成评估集v1和验收门槛t1，尚未决定采用哪种方案。本章以前面三章的范围、指标、经济性假设和评估要求为依据，明确四件事：各项任务先验证哪类方案，规则、检索、模型与人工怎样分工，增加复杂度需要哪些证据，什么条件下应复审决定。读完本章，FDE小组应能交付一份架构决策记录及候选方案比较表。

6.1　选型的输入

本节回答选型开始之前手里已有什么、还缺什么，任务的性质怎样限定候选，以及本章要定的到底是什么。产出是选型输入清单（表6-1），其中的待定项分别由Tom、David和Emma认定。

6.1.1　已确定的范围、标准与约束

方案选型以前三章的材料为基础，不必从空白页重新开始。范围说明书规定本轮做什么、不做什么；指标定义与基线报告说明怎样测量现状，经济性初算判断是否值得继续；评估集和门槛提供任务验收的依据；交付章程与访问清单规定责任和数据边界。选型的第一步，是把这些文件逐项转成候选方案必须满足或需要验证的要求。基线结果、门槛数值或访问权限尚未确认的，保持待定状态，不能当作已经满足的条件。

选型容易出现先定方案、后找依据的次序倒置：首次会议上提出“用大模型”，后续便只收集支持这一选择的证据，其他候选没有得到认真比较。这样即使系统最终达标，也无法判断新增成本和风险是否必要。先明确约束与判定标准，有助于让比较依据独立于具体技术偏好。

表6-1中的S、X、H沿用前文编号。S表示范围内任务：S1是每日待处理工单的备件与时限核对，首批覆盖一个班次；S2是故障复盘材料提速，结论由人作出；S3是较长退服起因构成的条件项，须待告警访问获批、统计口径明确后启动。S1与S2均不写回源业务系统。X表示本轮排除项：X1故障预测因证据不足暂不实施，状态为“未验证”，不是“已否定”；X2自动开单、派单和其他写回动作，X3外场出勤调度优化，均未获相应授权；X4备件采购与补货建议因证据不足暂不纳入。H来自第5章的硬失败清单及零出现条款；其中H3拟规定，应转人工的高风险工单不得由系统直接给出确定结论，正式效力以Tom认可的版本为准。

表6-1　合众通信的选型输入清单

表6-1有三点需要说明。第一，先按任务分别比较，再核查共享部件和总成本，不能因S2涉及长文本，就让S1也采用同样复杂的处理方式。第二，区分已确认、暂定和待申请事项：范围、现行访问边界和评估结构提供起点，时限起点、告警访问及门槛最终认定仍需跟踪；本章结论须注明依赖条件。第三，较便宜的做法必须进入正式比较。第4章示意成本约占工时价值理论上限的82%，说明若采用这组假设，需要很高的净节省比例才能抵平成本，并不代表实际预算已确定。小组仍需比较流程调整、规则和共享视图，核实各自的价值与成本。

6.1.2　任务性质对候选范围的限定

相同的业务要求，在不同任务上可能需要不同方案。本节用四个问题判断任务性质：判据能否明确表达，输入是什么形态，错误会造成什么后果，业务量有多大。表6-2列出这些问题怎样影响候选范围，以及小组从哪里取得答案。

表6-2　判断任务性质的四个问题

第一个问题可以从第5章的标注指南入手。判据能写成条款，两位专家按条款得到相同标签，说明业务含义较明确，但不等于程序已能从原始输入中取得判定所需的信息，还要检查字段是否齐全、语义能否可靠识别。第5章的虚构示例说明，两位专家对“备件未到库”和“备件已到库待领出”的分歧可能源于标签过粗，拆分标签可以消除这类歧义，却不能单凭标注一致就证明规则方案足够。还应区分判据不清与证据不足：备件行和预留记录矛盾，或描述要求换件却找不到备件记录时，不能要求模型凭语言能力补出事实。规则可以先识别已知的缺失或冲突模式，把相关记录交给人处理；方案能否识别应当保留判断的情形，同样要测试，不能认为列出几条异常规则就已经完整。

第二个问题看访问清单里的字段是什么类型。S1的输入是工单、备件行、预留记录和合同记录，几乎全是结构化字段，只有工单描述一栏是自由文字；S2要读的告警、工单、手册和历史复盘报告里，手册与报告是长篇文字。输入以结构化记录为主时，查询和规则可以直接处理；输入以长文本为主，且任务要求归纳、对照或摘录时，可考虑检索或模型，同时也应比较关键词搜索、模板和文本分类。转向模型要有理由，而理由应当能在任务的性质里找到。

第三个问题决定可以接受什么样的失败。准确率相同的两个系统，若错误类型、行动后果和人工复核效果不同，可用性也不同，不能用“90%加人工”作为通用标准。S1和S2虽然只读，漏报、错误的时限或无依据的复盘结论仍可能影响处置，不能把代价一概说成多看一眼，应按第5章分别评估系统、转人工和复核后的剩余错误。X2中的自动开单与写回会进一步传播错误，须另行建立动作授权和恢复机制。

第四个问题影响成本分摊和验证方式。构建、基础运维等成本中常有固定部分，业务量越小，每件任务分摊得越多；人工复核、调用和维护又随用量变化，不能全部当成固定成本。第4章每月30次核对、6件复盘和工时价值上限2,800均为示意，实际预算仍待测量。业务量小可能限制可取得的独立样本数：例如40条中34条通过，Wilson双侧95%区间约为71%至93%，不足以支持很精细的差异判断。比较候选时应优先报告配对结果和失败类型，证据不足时，不能以“未发现差异”声称性能等价。

选型也要检查是否过度使用模型。例如，某项判定若仅依赖几个稳定字段，少量明确规则已经达标，引入学习模型可能增加训练、验证和维护负担。这个例子不能推出规则总是更优，判断仍要看当前任务上的质量、成本与接手条件。比较时不只问AI方案能否达标，还要问较简单的候选是否已经满足要求，以及复杂方案增加了什么价值。

四个问题需要合起来判断，不能由其中一个直接决定方案。S1的主要输入结构化、部分判据已明确，可优先验证查询和规则，工单描述中的语言判断则需要单独测试。S2应进一步拆分：汇集告警和工单、按时间排序，可由查询和程序完成；相关段落定位、跨材料摘要，则分别比较搜索、模板和模型。不能因为整体涉及长文本，就把全部处理步骤都交给模型。

6.1.3　选型的决定范围

选型要定的是方案的类型和分工，以及什么情况下改变它。具体有四样：先验证哪些候选，哪些部分交给规则、检索、模型和人，升级需要什么证据，哪些情形会让决定被重新考虑。用哪一个模型、提示怎么写、检索怎样切块、用哪个框架，属于实现层面的选择，会在后面的工作中在评估集的约束下逐一作出，本章不展开。

这些决定的变化速度不同：模型、提示与库可能频繁更新，任务分工和权限边界通常较稳定，所以本章记录方案类型、职责划分和复审条件，具体配置留在实现和变更记录中。但是否包含产品名不是判断架构决定的标准，某个产品或技术一旦显著影响部署边界、长期依赖或迁移成本，也应单独记录。

选型在界定门之前作出，那时多数候选还没有被测过，表6-1的待定项没有落地，质量一栏多半是待测。所以这个决定不是“已经证明”的结论，只能是“在现有证据下最合理的起点”。把这一点写进记录，并附上把握程度和使决定被重新考虑的条件，是选型记录与方案宣讲的区别：记录应使后来者能够核对当时的依据。

6.2　候选方案

本节回答有哪些候选、各自在什么条件下够用，以及怎样在同一标准下比较。产出是候选方案比较表（表6-4），其中质量栏由评估结果填写，由Tom认定比较的口径。

6.2.1　从确定到不确定的方案阶梯

候选方案常被排成一条越来越先进的路线，仿佛终点是智能体，走得越远越好。本章的立场相反：阶梯中的各类方案承担不同程度的人工、信息处理和决策工作，各有适用的条件，也各有代价，高一级不等于更好。

本章按自动处理程度和运行路径的控制方式，把候选排成九级，见图6-1和表6-3。这条阶梯里有两种排序依据交织：前四级改善人的流程与信息获取，中间三级引入规则、预测或生成模型，最后两级区分由代码组织步骤和由模型动态选择步骤。所以它只是本书的比较顺序，不是严格的能力包含关系：搜索可能使用模型，规则也可嵌入智能体；后一级未必比前一级更复杂、更贵或更合适。实际选择应回到具体任务、依赖和维护成本。

图6-1　候选方案的阶梯

先说明几个名称。“共享查询视图”指把分散数据按核对需要集中呈现，不必是数据库中的视图或物化视图，可由查询、接口或定时汇总实现。“确定性规则”由程序按明确判据执行，在输入、规则版本和外部状态相同时应得到相同结果。“传统模型”在本章指分类或预测模型，并不限于结构化输入。“固定工作流”由代码规定步骤及分支，分支可以依赖中间结果；“智能体”则允许模型在授权范围内动态选择步骤和工具。两者都需要端到端评估，路径固定并不保证含模型的步骤具有确定性。

表6-3　候选方案阶梯各级的适用条件与代价

阶梯讨论的是处理方式，自建或采购是供给方式，二者需要分别判断。后一级常引入新的配置、依赖和失败路径，但负担并不必然逐级增加，应在具体候选上清点。规则也不能仅靠逐条测试证明正确，模型除了样本评分，也需要格式、权限和异常路径等程序检查。复杂度应由任务需要和验证结果支持，而不能由架构名称决定。

阶梯用于组织比较，不要求每个任务逐级实现。应先根据判据、输入、权限和运行条件，选出可能够用的候选，再说明暂不优先验证其他方案的理由。长文本、较多例外或规则维护困难可以提示需要进一步比较，但任何一个特征都不能单独证明大模型或智能体不可替代。

以S1为例，现状是Alice在多个系统间逐条核对；流程调整可以统一表格和核对时点；共享视图集中呈现批准字段；检索定位相关工单、备件记录和合同条款；规则按认定口径生成待处理清单。规则可包含“未到库”“已到库待领出”“预留冲突”等不同状态，不能把某一状态当作完整业务定义。分类模型需要适用的标签或其他可靠训练依据，目前尚未确认具备；大模型可作为工单描述语义判断的候选，多步工作流和智能体则分别需要编排或动态选路的理由。比较目标是找到满足要求且总负担可接受的方案，而不是机械选取编号最小的一项。

6.2.2　各级的适用条件与不足的信号

表6-3为每一级写了两句话：什么时候它合适，什么时候它已经不够。第二句更有用，因为“不够用的信号”是可以观察的：它们出现在评估集的失败类型里，出现在规则集的维护记录里，出现在使用者的抱怨里，而不是出现在对技术前景的看法里。选型的做法，是从最低可能够用的一级起步，出现必要证据后再决定是否改变方案。

先验证成本较低的候选，有三个作用：迫使小组明确业务判据与数据缺口，建立可比较的简单方案，并限制尚无证据支持的投入。这不意味着简单方案一定能取得固定比例的收益，仍需在当前任务上测量。

考虑模型应有可检查的依据，例如规则冲突和修改引发的回归已造成维护困难，简单搜索或模板无法完成所需的语言归纳，或语境差异使规则覆盖不足。这些现象只是提出候选的理由，仍须验证模型是否改善问题；规则数量多也可能来自组织和实现缺陷。S1的规则尚未实施，不能预先宣称其维护失控。工单中“整板替换”“换新板”等不同说法，可以用来设计语言判断样本，比较关键词、文本分类器和大模型的表现。技术流行、管理偏好或其他团队使用过，都不足以单独支持选择。

分类、预测与生成是不同任务，但并不存在“结构化输入只能用传统模型、文本只能用大模型”的界线。传统分类器可以处理文本，模型也可以把文本抽成结构化字段。选型需要比较可取得的标签、特征、输出要求、误差代价和维护条件，并且只有在公平条件下验证过可信的简单基线，才能判断复杂方法增加了什么价值。

最后几级主要按控制路径比较。检索后的一次模型调用可以作为起点；若步骤和分支能明确设计，可使用固定工作流，其中也允许根据中间结果选择分支。只有当动态探索确有收益、可预先设计的分支难以覆盖任务时，才值得比较由模型选择步骤的智能体，并核查额外延迟、成本与运行风险。业务流量能否预测主要影响容量和成本设计，不应单独用来判断是否需要智能体。

阶梯上的错误有两个方向。用高了，付出的是评估、维护、延迟和成本，换来的却是本可以由低一级完成的结果；用低了，付出的是规则越写越乱、文字材料无人能读，该解决的问题没有解决。本书反对的不是任何一级，而是在没有比较的情况下选择任何一级。低级的做法也不会因为高级做法的出现而作废：写好的规则、查询和校验，在更高级的方案里成为护栏，负责时限的计算、权限的检查和强制转人工，把模型限制在经验证适合它承担的职责内。先写规则，既是起步，也是在为后面各级预备护栏。

6.2.3　“不用AI”作为正式候选

“不用AI”应作为正式候选。维持现状的人工耗时、差错率和复盘周期，为比较提供参照；但这些数据在合众通信仍待按第4章测量，不能预填成绩。流程调整、查询和规则还可能以更低总成本解决问题。若只列复杂方案而不认真设计这些选项，就无法判断模型贡献了多少增量价值。

“不用AI”包含多种不同候选。维持现状只作比较基线；流程调整改变谁在何时做什么，例如统一核对表、调整核对时点；共享查询视图集中呈现核对所需字段；确定性规则则进一步按判据生成结果。后两种未必需要模型，但是否需要新增访问，要逐项对照现行清单，不能因方案简单就默认跨系统关联已获批准。构建、运行、维护和客户投入都要计入成本。

简单候选也要避免被写成稻草人。仅用“人工逐条看”概括现状，既没有反映其质量，也没有说明可改善之处，不能据此断言新方案更好。共享视图应列出真实核对所需字段、关联口径、到期余量和异常展示方式；规则由业务专家确认判据、工程人员实现并测试；流程调整需有负责人和执行条件。是否可信，取决于设计和验证是否充分，而不是有没有人愿意为它辩护。

简单候选的失败样本还能限定后续验证范围。若规则只在某些语言或冲突类型上失败，复杂候选应首先解释如何处理这些类型，再检查是否带来新失败。出现少量回归并不自动否定替换，但每项回归都要按第5章的风险与门槛检查，不能用总分提升抵消硬失败。

简单不等于免费。流程调整要有人培训、改习惯；共享查询视图要有人维护访问授权；规则则需要持续维护，每一条都要有人负责、有测试、有版本，若理由没有记录，人员离开后就难以解释条款依据。规则型方案真正的成本，在于组织得承认规则是一种需要持续维护的资产，而不是一次性的脚本。这笔账要算进比较，否则简单候选会因为被低估成本而在比较中获得不合理优势。

6.2.4　同一标准下的候选比较

候选摆出来之后，比较是最容易失公平的环节。失公平往往不是谁故意偏袒，而是各候选在不同条件下被看：模型候选的演示可以读整张表，规则候选只被允许读已批的字段；模型候选在作者挑的样本上演示，规则候选在评估集上测试。所以第一条原则是同一标准：同一份评估集和验收门槛，同一份访问清单，同一组运行约束。

候选应采用一致的任务定义、可用证据和评分规则，但无需有相同实现。人工利用共享视图形成的清单，也可按同一任务标签判分；程序格式与工具轨迹检查则应使用适合该候选的检查方式，不能要求人工产物伪装成API输出。各候选所需权限、集成和审批成本分别登记。运行约束同样适用：按第5章每天80张、转人工率25%的示意条件，日常转交约不得超过20张，不能用每天复核40张换取表面达标。正式判断仍以认可的实际容量为准。

比较的维度不必多，五项够用：质量、成本、可行性、风险和可维护性。质量是候选在评估集上的实测结果，写明评估集版本和样本数；成本包括构建、运行和维护，以及客户一侧的人力，口径沿用第4章的初算；可行性看数据、权限、口径、时间和人是否具备，每一项依赖的待定事项要点名；风险看最坏的错误是什么、能否发现和恢复、是否扩大访问边界；可维护性看谁来改、多久改一次、改了怎样回归。前三项回答“能不能”，后两项回答“能不能长期”。

表里最容易出问题的是质量一栏，规则只有一条：只填测过的。测过的写数值，同时写评估集版本、样本数和评分项；没有测过的写“待测”，并写明由谁、什么时候测；当前不具备条件的写“暂不可测”，并写明缺什么。凭印象写“较高”“较好”，等于把假设写成了证据。更隐蔽的一种是用演示代替测量：一次精彩的演示是一个样本，不是一个质量值。评分还要与其能够支持的结论相称。相同60条样本上，一个候选通过51条，另一个通过53条，只能先报告净差2条，并列出旧对新错、旧错新对的数量和类型，不能只凭两个置信区间重叠，就断言二者没有差别，也不能把未检出显著差异写成等价。

决策先检查必须项，再比较剩余候选。硬失败、权限、质量门槛和复核容量等约束，不能用低成本或其他高分抵消。没有测量证据的候选标为待验证，不能按已经通过处理。在满足约束的候选中，再比较部件、依赖、总成本和接手难度，选择较简单且经济的方案；阶梯编号仅作提示，不能直接当作排名。若组织采用加权评分，应先执行不可补偿的必须项，并在看到结果前约定其余权重。

最后区分两个容易混淆的东西。评分标准回答“一个输出对不对”，由评估集和评分规则建立，由客户认可；这里的决策准则回答“几个候选里选哪个”，涉及成本、风险和可行性。后者不能漏进前者：不能因为某个候选便宜，就放宽它的评分，也不能因为某个候选先进，就给它加分。

6.2.5　合众通信的候选比较

回到合众通信，把表6-1和四个问题用在三件事上，候选可以分别列出。S1的核心是三个判断：备件是否在等，时限是否将近或已过，遇到互相矛盾的记录时是否转人工。前两个判断的输入是结构化字段，判据在标注指南里已经写成条款；第三个同样可以写成条款。所以规则是S1的自然起点，在当前拆分中需专门检验自由文字处理的是工单描述里是否要求换件这一处。S2要拆成两部分：把某次退服相关的告警、工单按站点和时间窗汇集成一条时间线，是查询和模板能做的事；从手册和历史复盘报告里摘出相关段落，整理成一份可读的材料草稿，需要检索，也可能需要模型。

X1目前缺少行动出口、误报代价和告警访问条件，还需先定义预测目标，包括预警对象、最小提前量、预测范围以及标签生成规则。“监测窗口”要区分用于取特征的历史窗口和用于判定未来是否发生退服的预测窗口，不能混用。若预警不足以支持出勤和到站，也许无法产生原设想的处置价值；是否能支持远程检查等其他行动，仍需与班组长确认。目标和行动要求先明确，模型指标才有业务含义。

表6-4列出目前的候选及验证顺序。质量栏仍为待测：现状基线尚未完成，S1的开发集与S2的报告要素标注也尚未用于候选评测；X1还缺数据权限和预测目标。这里提出的是验证起点，不是声称某个方案已经合格。架构决策记录可以先接受一个有条件的验证方向，但生产使用必须另经第5章的任务验收和第20章的发布检查。S3属于较长退服起因构成的调查，需取得告警记录访问后再实施，表中不另列。

表6-4　合众通信的候选方案比较表（界定门之前）

X1的三行说明了另一件事：有些候选此刻不是比不比得过的问题，而是还不能成为候选。“不做”在这里不是否定，而是在缺少数据和目标定义、没有行动出口的情况下当前可明确记录的范围决定。第3章把它记为“未验证，不是已否定”，选型要做的是把它的重启条件变成可检验的复审条件，使“未验证”有一个明确的出口。

补齐质量栏时，应先估算适合当前约束的最小验证。对S1，可优先实现查询和规则原型，但仍需核对权限、字段与开发成本，不能未经估算就称其最便宜。确有语言处理需求时，也可并行设计其他候选，先在开发集比较；一周只是示意周期，不是统一要求。教学合成数据可检查规则与评分逻辑，却不能证明真实业务质量，尤其不能因生成标签与规则使用同一套判据就把高分当成现场效果。

案例　三个候选面对同一张矛盾的工单

小组为S1画了三个候选的草图，取评估集中的同一张应转人工工单，设想它们怎样处理。这张工单就是第5章5.2.2的样本TT-2026000517：描述是“基带板卡故障，需更换”，备件行P-30218写着“已到库”，同一备件的预留记录却显示它已预留给另一张工单，原因不明。两条记录各说各话，期望的处理是转人工，并列出这两条记录。

草图推演可以列出三类风险。规则候选若包含“预留冲突即转人工”的判据，就能检出这张工单的已知冲突，但其他冲突类型仍待测试。模型候选可能过度依赖备件行的“已到库”，忽略预留给其他工单的记录，从而误判为“不在等备件”。智能体若动态追加查询，则要检查是否必要、是否越界，以及多步结果是否得到一致处理。这些只是待验证的失败假设，不代表三类方案在此样本上的实测表现。

小组没有给三个草图打分，它们都还没有被测过。比较表里只多了三句话：规则候选需检查尚未覆盖的异常类型；模型候选要补的是引用与结论之间的核对；智能体候选先要回答这里为什么需要它。本案例为虚构，三个草图的表现是设想，不是测量。

6.3　最简架构起步

本节回答候选选定之后怎样搭：起点放在哪里，哪些判断不交给模型，什么时候才往上走一级，以及“简单”可以省掉什么、不可以省掉什么。产出是S1核对各环节的责任分工（表6-6）和升级的证据要求，规则部分由Alice认定，升级决定由Tom认定。

6.3.1　最小充分原则

“最小”不按代码行数或阶梯编号判断。可先列出部件、模型判断点、外部依赖和需管理的配置，再估计它们的变更频度、失效后果和接手难度；项目数量只能作为复杂度线索，不能简单相加排名。“充分”除任务评分外，还包括访问边界、复核容量及发布所需的运行要求。因此，最小充分是满足约定约束后，总体实现和维护负担较小的可行方案，而不是只在评估集上过关或部件最少的方案。

以S1为例，规则候选需要管理条款、时限起点参数和查询字段定义，业务人员还需与工程维护者共同负责。若在“描述是否要求换件”上引入模型，还可能增加提示、模型版本、检索配置、外部服务和审批依赖，新增哪些应按实际架构判断，单句分类未必需要检索。两者质量是否相当要通过评估确认，不能先假定清单一样准确。

“不为尚未确认的需求提前增加功能”可用于约束架构扩张。额外功能既有建设成本，也可能延误当前任务，增加持续维护与未来返工。更复杂的方案可能提供灵活性，也可能复用现成能力而减少开发；收益与负担应在具体候选上核查，不能断言验证需要之前只产生成本。表6-5用于清点可能新增的依赖和维护工作，避免为没有证据支持的扩展长期付费。

表6-5　阶梯上每上一级新增的携带成本（本书归纳）

这张表是本书的归纳，不是实测的成本，各格的内容会随技术变化。它的用法是在比较候选时多问一句：选这一级，接手方需要增加哪些维护能力？

从简单方案起步，需要为后续改动保留可验证、可迁移的条件。评估集和回归提供质量证据，清晰接口、模块边界、数据契约及可恢复的部署也很重要。评估集不能单独保证升级安全，但缺少它，团队就难以识别修复和退步。既不预建所有可能功能，也不省略这些必要基础。

复杂度最终要由接手团队承担，不能只按FDE小组的熟练程度判断。Alice的团队能读懂业务条款，并不等于具备程序、授权和部署维护能力；规则方案同样需要工程负责人。涉及索引、模型与提示时，还需相应评估与运行能力。是否采用某项技术，应列明客户已经具备什么、需要补什么、由谁长期负责，而不是预先把模型视为所有团队都陌生的风险。

最小也包括部署的形态。一个可以独立部署的应用，内部把模块分清，可作为本案例的优先候选；拆成多个服务，要等到有明确的理由，比如需要独立伸缩、独立发布、不同的安全边界，或由不同的团队分别负责，因为拆分会带来网络延迟、分布式故障、版本协调和更难的排查。编排框架同理：它把调用、重试和状态封装起来，用起来省事，但抽象层也会把提示和响应藏到后面，出错时更难定位。比较稳妥的做法，是先直接调用模型的接口，已有平台不能满足需要时再比较框架的收益与依赖，并且读懂它下面的代码，因为接手的人最终要调试的，正是这一层抽象。

6.3.2　概率性部件与确定性部件的分工

即使走到阶梯的第七级，大模型也不应该是整个系统，而是系统里的一个部件，两边由确定性的程序围住。分工的原则可以用一句话说：模型提出，程序决定哪些可以发生。模型适合做需要理解语言、从含糊的输入里取出结构、归纳和摘要的事；身份与授权、计算、校验、业务约束、策略执行、事务，以及有后果的动作，应当由确定性的软件负责。越往阶梯上走，自主性越大，这条界线越要守住。

每个环节需要一个可以回答的判据，本书用三个问题。第一，结果能否由规则唯一确定？给定同样的字段，备件是否在等、时限还剩多少，按同一口径应得到可复现的结果，这样的环节用程序。第二，错了能否被程序检验？能检验的，把检验放在模型之外：引用的记录编号是否在本次取回的集合里，输出是否符合约定的结构，都不需要再请模型判断。第三，后果是否越过了边界？读哪些数据、写什么、通知谁，一律由程序按访问清单和授权执行，模型最多给出建议。这三个问题先排除应由程序强制执行的职责，剩下的语言处理任务，才适合进一步比较模型与其他方法：输入是自然语言，措辞无法穷举，判断依赖语境。表6-6把三个问题用在S1的核对上。表中的分工不是说现在就要用模型：规则候选是起点，模型只在规则留下了需要语言理解的失败类型之后，才会进入“工单描述是否要求换件”一行。

表6-6　S1核对各环节的责任分工

表6-6中，已批准的权限和强制转人工规则优先于模型建议，模型不能用一段解释绕过触发条件。可用规则检出的高风险冲突，应交由人工处理；模型也可在缺乏证据时请求转交，但不能把“模型觉得不确定”当作已经校准的风险概率。增加转交还会占用容量，超限时应缩小处理范围或停止自动作答，不能为压低转人工率而忽略强制规则。

业务状态应保存在可追溯的外部存储中，而不能只依赖模型当前收到的对话。已提醒的工单、时限起点和人工确认记录，都应由程序维护，并满足本轮的只读边界：只读指不改源业务系统，本地记录也需按授权管理。对话日志可以保存、审计和重放，但它可能被截断或压缩，不适合替代明确的状态记录。

最后一条与输入有关。模型读到的文字，无论来自工单描述、检索回来的文件，还是工具的返回，都只是数据，不是命令。其中如果出现“忽略此前的指示”一类的句子，它仍然只是文件里的一句话，不应当自动变成可信的指令。会产生后果的操作，必须经过模型之外的校验与授权。具体怎样防范，是第19章讨论的内容，这里只要求分工的时候先把这条线画在对的位置。

分工也影响测试方式。确定性部分可以用单元、集成和属性测试核查明确规则，但除有限的小型输入空间外，通常不能穷举所有输入和状态。含模型的部分需用评估集检查输出与稳定性，同时保留程序化格式和权限检查。把可明确计算的要求交给程序，有助于缩小需要语义评估的范围，但不意味着其正确性已经得到证明。分工应使责任清楚，而不是无限增加接口和失败路径。

6.3.3　升级的证据要求

引入复杂方案应有可核查的理由，不能只因偏好或技术流行。本章要求记录四类证据：当前候选的失败类型、样本编号和数量；拟议方案为何可能解决这些问题；最小验证版本的配对结果，包括修复与新增失败；新增成本、依赖及接手能力。质量之外，成本、延迟、权限或维护困难也可能促成架构变更。每次变更都需重新检查必须项并记录理由，旧方案是否能安全回退，也应在验证前确认。

升级可以是局部的，这一点常被忽略。阶梯描述的是一个判断点用哪一级的做法，而不是整个系统的档次。S1的核对由好几个判断组成，表6-6里只有“工单描述是否要求换件”依赖自然语言。假如规则候选在开发集上把“整板替换”“需要新板”这类说法漏判了，这些样本就是引入模型的验证对象，而且模型只需要承担这一个判断，其余仍由规则负责。局部升级把携带成本限制在一个点上，但既要评估该判断点，也要检查端到端质量和回归影响。

失败先要归因，再判断是否需要更复杂的方案。一条样本就可能揭示真实机制，尤其是硬失败，但少量失败不足以估计发生频率。可预先约定“同类独立样本达到三条”等复审信号，不能把该数量当作统计证明。标注错误、字段缺失和时限口径未定，应先分别核实；未经认定的标签不能直接用来判定候选不合格。只有确认当前方案确实难以处理的失败，才作为引入模型或其他架构的依据。

失败不必立即通过更复杂的架构解决，还可以补齐字段、明确口径、修订规则、调整流程，或在容量允许时转人工。缩小范围必须按章程重新认定，不能为了达标擅自删除难例。这些做法也会带来培训、复核或维护成本，应与升级候选一起比较。图6-2给出判断路径，目的是让每个失败都有可核查的处置，而不是要求所有任务逐级上升。

图6-2　是否升级的判断

比较和调参主要使用开发集，留出集保留给正式验证；线上失败、维护记录和约束变化也可触发复审，并不只允许依据开发集失败变更。若分析留出样本后据此修改系统，应按第5章登记暴露并补充独立验证。增益不能覆盖新增成本或风险时，可保留较简单方案或回退，但要验证旧方案与当前数据、权限和配置兼容。智能体需要证明动态选路有实际价值；仅有分支变化、缺少一个字段或一条规则，不足以直接支持它。

6.3.4　简化与省略的区别

简化是省去尚无必要的部件和扩展能力，不能省去当前任务必须具备的控制。可先问：这项能力是否为了记录已经发生的事件，或阻止不可接受的后果？日志、身份授权、失败处理和安全回退若缺失，事后可能无法补救。表6-7按本轮约束区分应预先具备和可按需要增加的项目；“可后补”仍以当前方案满足容量、恢复和风险要求为前提。

表6-7　可后补的项目与必须预先具备的项目

这些基础能力也需要设计和维护，不能一概说成本很低。访问日志需说明记录范围、保留期限和访问权限；版本标识要能关联一次运行的全部配置；失败路径要经过测试；回退则要验证代码、配置、数据及权限仍兼容。保留旧代码是必要材料之一，不能单凭它保证可回退。应按任务风险实现足够的基础能力，并在初算中计入成本。

表6-7的上半部分，正是David在第一次评审时问过的三件事：不同岗位提同一问题，看到的内容是否相同；一次提问读取了哪些记录，事后能否看出是谁问的；有人设法诱导读取不该读的内容时，由什么来保证做不到。这些问题不会等原型成熟了才来，所以访问记录、经授权且可追溯的运行身份和访问清单内的字段这几行，最小的版本从第一天就要有。日志尤其值得多说一句：它常被当作运维的奢侈品，实际上是评估的原料。评估里有一项要由程序检查访问记录来判定读取是否越出清单，没有记录，这一项在运行时就无法评，而评估所需要的材料必须在运行时产生，事后通常无法完整补齐。

这与“不要预先加功能”的原则并不矛盾。这条原则自己也划了范围：它针对的是为将来预先增加复杂度的做法，不涵盖那些让系统更容易修改的工作，比如测试、重构与持续交付。日志、版本标识和回退属于后一类。身份在运行时怎样授权、威胁怎样建模，是后面章节的内容；这里的要求只有一条：最小版本在这些方面不得比访问清单所写的更松。到这里，架构的形状已经清楚：从最低够用的一级起步，模型被确定性的部分围住，升级凭证据，必须有的东西一样不少。剩下的问题是，这些部件由谁来造，由谁来运行。

6.4　自建与采购

本节回答每一块能力该自建还是采购，以及供应商的声明怎样检验。产出是各项能力的取舍表（表6-10），数据与权限的边界由David认定，知识与评估的所有权由Tom认定。

6.4.1　采购作为同一标准下的候选

前面说过，阶梯描述的是做法，不是来路：每一级都可以自己建，也可以买现成的。“我们自己做还是买一个”常被问成整个项目的一道单选题，容易忽略部件之间的责任差异。对FDE小组更有用的问法是：S1的每一块能力，买来的东西在同一把尺下比自己建的怎么样，客户需要保留哪些控制权和迁移能力。

自建指由本方主导开发，运行可以自行承担，也可委托；采购指使用外部提供的产品、组件或服务；混合指按能力组合这些来源。开发来源、部署地点、运行责任和知识所有权是不同维度，应分别约定。S1、S2可按取数与视图、规则与时限计算、评估、检索、模型推理、运行与监控等能力逐项比较。采购形式可分为现成产品、定制开发和人员服务：现成产品的功能、集成支持和运维责任以合同为准；定制开发需明确验收、代码和配置权利、维护责任；人员服务则需明确驻场任务、交付物和退出安排。派驻工程师可能承担FDE职责，但是否适合当前项目，要看实际报价、可验证价值与客户配合投入，不能一概认定其最贵或最有效。

采购方案与自建方案都要通过相同的业务和风险约束，再比较总成本与接手条件。采购可能缩短建设周期，但开发成本并未消失，只是以许可、订阅、服务费等形式体现；评估、集成、变更和退出仍需投入。供应商内部可见性因产品而异，不能一概认为采购比自建更难维护。若规则已能满足要求，模型产品仍须用新增价值和总成本证明采购理由。

6.4.2　数据边界、知识所有权与接手能力

本节从数据边界、知识与评估的控制权、接手能力三个方面检查，见表6-8。前两项若属于已认可的必须条件，未满足的候选不能进入当前实施；第三项用于比较补齐能力的成本与风险。总拥有成本沿用第4章的估算结构，但应按具体自建、采购或混合候选重新填入参数，不能直接复用同一组示意金额。

第一件是数据与权限的边界，也是最容易被发现得太晚的一件。先问任务究竟需要多少数据：需要敏感字段本身，还是只需要由它派生出来的结果？能用派生或脱敏后的内容完成，边界就可以缩小；每缩一次，用评估集验证质量是否下降，若不满足要求，应按审批规则缩小任务或转人工，而不是放宽暴露。再看数据的去向和合同条款：数据是否用于供应商的训练，保留多久，删除是否覆盖索引、日志和备份，须同时落实到合同、配置和可验证的操作中。约束先于偏好，一个能在边界之内运行的稍弱方案，胜过一个根本不能碰数据的更强方案。这一件要向David提前问，否则到了验证阶段才知道工单正文不能发出去，几周已经花在一个不能用的候选上。

知识与评估要明确的是权利、控制和可迁移性，不等于所有代码与材料都必须独家所有。通用引擎可采购或复用，业务规则、合同口径、标注与验收标准则需由客户掌握并能核查。供应商可以协助实现和标注，但不能由其单方面改变验收依据。应确认数据、规则和评估材料能否按约定导出、迁移和继续使用，以及退出时间与责任。知识产权、许可和保密条款由Tom会同相应责任人确认，小组负责提出工程依赖与风险。

接手能力既包括业务责任人和领域专家，也包括工程维护、数据访问与供应商管理。Tom负责业务决定，Alice提供流程知识，David的现有申请通道只承诺三个工作日内答复，不代表批准，也不覆盖新的服务审批。更换模型或产品版本后，回归可以由客户或供应商执行，但责任、证据访问和最终确认权须预先约定。采购不能替代客户建立这些能力。

表6-8　自建与采购时小组要守住的三件事

用法与候选之间的比较相同：先过门，再比较，不做加权求和。数据边界过不去的，云端的采购选项出局；所有权写不进合同的，采购选项出局。过了门，按能力逐块得出结论，自建、采购或混合都可能是合理结果。成本方面只需记住一条约束：第4章的示意参数下，工时价值的天花板是2,800，一个采购方案的月度总成本如果超过它，含客户一侧的集成、验收和管理供应商的人力，仅凭工时就不可能抵平；人员成本又最容易被低估。

6.4.3　供应商声明的检验

检验采购声明时，首先要核对任务、样本和统计口径。供应商在自有基准上的成绩，不能直接填入客户任务的质量栏；外部调研中的采购占比或自述成功率，也不等于采购相对自建的因果优势。不同机构的调研所观察的对象、成功定义和调查方式不同，不能把两组数字拼成“采购更可靠”的结论。读这类材料，应记录来源、度量对象、样本和局限，真正的选型仍要依靠本企业任务上的评估与成本证据。

所以采购里最重要的动作，是把供应商的方案放到同一把尺下。表6-9列出五条做法，以及它们在合众通信落成什么样。

表6-9　检验供应商声明的五条做法

采购文件应明确客户对评估集、标注、规则和运行证据的控制权，以及数据用途、保留、删除、导出和终止交接要求。索引、日志与备份的处理应逐项约定可执行期限与限制，不能只写“全部删除”。模型或服务变更需有通知、验证及必要的回退安排。是否采用派驻，不仅看核心知识是否重要，还要看客户能否持续掌握知识、完成接手，以及报价是否由可核实价值支撑；不能仅因人员将离场就否定派驻，也不能未报价便推断供应商无利可图。

6.4.4　合众通信的取舍

做取舍之前，案例里还缺一项约束，表6-4里它一直被一句“须David回答”代替。现在把它补上，以下是本书的设定，不对应任何真实的规定。合众通信的信息安全规定把工单、备件、合同和告警记录归为内部业务数据，未经审批不得发送到公司网络之外的服务，已批外部服务的清单上目前没有任何模型服务。一项外部模型服务要列入清单，David提出五项拟议的服务审批要求：数据不用于供应商的训练；保留期限和删除义务写入合同，并覆盖索引、日志和备份；处理地点限定在批准的区域；合同允许审计；每次调用的输入和输出摘要，在公司一侧留存。按以往类似申请的经验，审批需要数周，结果不能保证。公司机房里也没有为模型推理配置的算力。

按本案例设定，审批完成前不得把真实内部工单发送给外部模型，即使只是评估也不例外。可先在公司内准备样本、完善脱敏流程，或在明确获准的公开、合成数据上检查接口，但这些结果不能替代真实任务验收。审批通过也只在批准的数据、地区、用途和期限内允许测试，不等于批准生产使用。表6-10据此给出本轮按能力划分的取舍。

表6-10　合众通信S1与S2各项能力的取舍（本轮）

模型推理暂不接入，有两类约束。对于S1，规则候选尚未测试，尚无证据说明语言判断需要模型；对于S2，模型草稿是待比较的能力，是否有价值仍待评估。两者目前都没有获批的模型服务，本地推理资源也未落实。因此，记录应区分技术证据和审批进度：出现值得验证的语言任务时，可提前提交服务审批申请，审批不等于采购，更不等于获准生产使用。不能把S1的规则方案尚未失败，当作S2也不需要模型的证据。将来真要引入模型时，还有一件事可以先做：缩小送出去的内容。S1的这个判断可先尝试只使用与换件有关的句段，用不着整张工单，更用不着联系人和客户信息。送出前移除无关敏感信息，并保留判断所需的否定、上下文和时点，再用评估集验证质量有没有下降：没有下降，就按缩小后的内容走；不满足要求时，按章程重新评审任务或转人工；不得擅自放宽暴露。

X1不在这张表里，因为它不是自建或采购的问题。第一次会议之后那场演示没有回答的问题，即预测之后谁行动、误报的处置成本由谁承担、告警记录能否取得，换谁来建都还在。供应商可以提供模型，不能代替Alice回答排名第三的基站要不要派外场班组上站，也不能绕过David的审批。X1的默认仍是本轮不做，它的重启条件与买不买无关。

本轮提出的起点是S1用查询与规则、S2用时间线和检索，均先由本方实现，模型调用保留为须经审批和评估的采购候选。这是现有条件下的验证方向，尚不表示质量已达标或自建成本必然最低。架构决策记录应一并写明待测事项、负责人和复审条件。

6.5　架构决策记录

本节回答怎样把选型写成一份可以被接手、被检验，也可以被推翻的记录。产出是架构决策记录ADR-0001（表6-12），由Tom认定。前四节得出的结论是：本轮S1用只读的核对，S2用时间线加检索，均拟自建验证，X1不做。结论仍需随证据和约束变化复审。三个月后评估集会增加样本，访问清单会有变动，总会有人问一句“当初为什么没有用模型”。那时能不能答上来，取决于理由有没有写下来，写在什么地方，写成什么样子。

6.5.1　记录架构决策的必要性

一个决定在证据不完整时作出，作出之后，证据和约束还会继续变化。围绕这一点，常见的毛病有三种：怕选错而迟迟不定，项目在比较中空转；定了却没有留下理由，下一次会议又从头争论；理由写了，却散落在聊天记录和个人笔记里，换一个人就找不到。三种毛病的根源相同：决定的理由没有一个固定的、可以被查找的地方。

FDE小组还要面对第四种，也是代价最大的一种：交接。项目结束时系统留在客户手里，接手的人看到的是一组规则和一个检索，没有人告诉他们为什么没有用模型，以及什么情况下应该用。面对一个没有理由的现状，后来者只有两种办法，盲目保留，或者盲目推翻。盲目保留，会让早已过时的选择一直延续；盲目推翻，可能拆掉当初恰恰靠这个选择才满足的约束，比如数据不出公司网络。

是否需要架构决策记录（architecture decision record，下称ADR），主要看决定是否显著影响系统结构、接口、质量要求、外部依赖、成本或后续迁移。一般的提示措辞和切块参数可记入配置与变更记录；如果某项配置改变了数据边界、关键质量或部署方式，也可能需要单独的架构决定。不能只凭是否出现产品名或参数名来判断。

这份记录与前面几份文件的分工不同。范围说明书记做什么，基线报告记现状如何，评估集与门槛记什么算合格，架构决策记录记选哪条路、放弃了哪几条、什么时候改。它不复制前面的内容，只引用它们的版本，引用文件更新时，应复查是否影响已有决定，旧版本不一定因此失效。写的过程本身也有用：把理由写成完整的句子，往往会逼出原来没有说出口的分歧。Alice如果担心规则越写越多、没有人维护，这句话可以在“后果”及“异议”栏明确记录，而写下来之后，规则的负责人、测试和版本才有了着落。对界定门来说，这份记录也是证据包里的一件：决策人读的是这一页，签认的也是这一页。

6.5.2　一条记录的构成

常见的早期简式模板包含五项：标题、背景、决定、状态和后果。后来的模板陆续加上了备选方案及其利弊、置信度和需要重新评估的条件。本书取两者的并集，并把复审触发条件由可选改为必填：选型发生在界定门之前，比较表的质量栏里有许多“待测”，证据不完整是常态，条件一变就需要重看，而事先写好的条件是可持续检查的提醒。表6-11列出十一项，后两列说明每项写什么，以及最常见的写坏方式。

表6-11　架构决策记录的模板

表中有几项需要多说几句。决定放在最前面，是因为读者需要先明确本次评审的决定：决策人签认之前，必须先看到自己在签什么，背景和理由放在后面，需要时再翻。

备选一栏最容易被省掉，也最该保留，理由有两层。第一层，没有记录的备选容易被反复提出：有人问“为什么不用模型”，记录里若没有这个备选和否决它的理由，讨论就只能从头开始；有了，就可以直接问，当时的理由现在还成立吗。第二层更重要：否决的理由几乎总带着条件。“数据不能出公司网络，所以不选”，这句话里的“不能出网”就是一个条件，条件变了，被放下的备选就该回来。所以备选一栏和复审触发条件是连在一起的，每个被放下的备选，最好都能指出：什么变了，它就该被重新考虑。

后果一栏应同时记录收益、负担和风险，并明确维护责任。选择确定性规则意味着要持续维护条款、测试与版本；未知冲突可能不能被现有规则检出，需依靠异常检查和人工抽查补充。转人工量必须与经确认的复核容量相符，第5章每天24张只是示意上限，按25%的示意转人工率计算，每天80张中的转交量约为20张，不能直接当作合众通信的生产容量。对语言输入的覆盖不足、源系统字段变更等，也应作为后果写明。

本书用高、中、低描述决策把握程度，并要求写出证据和缺口。例如“中：已确认结构化字段与规则判据，但质量尚待测量”。这些等级是定性判断，不是正确概率，也不能只写等级而不说明理由。没有相应概率模型或测量依据时，不写看似精确的百分数。

异议一栏记下不同意见，包括谁提出、理由是什么、决定怎样回应；无异议时记为“无已记录异议”。意见不一致时，没有必要假装一致：由有权作出这项决定的人在权限范围内拍板，并把异议和理由一并留下。日后回头看，哪一方担心的事真的发生了，这一栏就是最直接的线索。

一条记录以一到两页为宜，超过两页，多半是把附表搬进了正文。比较表、评估集、门槛、访问清单这类支撑材料，只放链接和版本，不复制内容。记录存放在项目仓库里的专门目录下，一条一个文件，按编号命名，用纯文本书写，这样能像代码一样被检索、被比较，也不会随人员调动而散失。

6.5.3　状态与变更

记录有四种状态：提议中、已接受、已拒绝和已被取代，它们之间的变化如图6-3所示。起草阶段是提议中，可以随评审意见修改；决策人签认后成为已接受；决策人不接受的，状态为已拒绝，理由照样写下，记录也不删除，免得同一个话题被反复争论。已接受的记录因新的决定而作废时，状态改为已被取代，并指向取代它的那一条。

图6-3　架构决策记录的状态变化

状态与界定门连在一起，因为这份记录是界定门的交付物之一。门上的四种决定对应到记录上是这样：继续，须明确是否也接受本次架构决定；缩小，按缩小后的范围改写决定，签认后成为已接受；补证，记录仍是提议中，并写明补什么证据、由谁补、何时补；停止，说明是拒绝当前决定，还是仅暂停项目；据此更新状态，理由和重启条件写在里面。

已接受的记录应保留当时的背景、理由和决定，不随事后结果重写。复审既要判断当时依据是否充分，也要根据新证据检验决定是否继续适用。发现事实错误或新增风险时，留下更正与复审记录；决定改变则另写ADR，旧记录标为已被取代并链接到新记录。笔误修正也需留痕，不能用它掩盖实质变更。本书的管理约定是：指标、评估集和门槛按版本更新；ADR用编号保留每次决定，决定改变则新建记录并链接取代关系。ADR文件仍应进入版本控制，能追溯笔误、状态和链接的修改。相关基线也不能按后来的方案改写旧测量结果，应按第4章4.5.5的版本约定保留历史。

新记录要说清四件事：取代的是哪一条，为什么现在取代，是哪个条件变了，旧决定管用了多久。合众通信的ADR-0001把S1、S2和X1三项任务的决定合写在一条里，这带来一个实际问题：其中任何一项变了，整条记录都要被取代，仍然有效的部分要在新记录里重述一遍。下面的片段是一个示意，假设几个月后S1的一个判断点升级了。

ADR-0001　本轮S1与S2用确定性核对与检索，拟自建验证，X1不做。状态为已被取代，被取代于ADR-0004。

ADR-0004　S1中“描述是否要求换件”的判断拟改用模型，S2与X1的决定不变。状态为已接受，取代ADR-0001。依据：同类规则失败已确认；外部服务获批；最小模型候选已完成配对比较并满足必须项；新增成本与维护责任已落实。仅有四条失败和服务审批，不足以直接批准架构替换。

合并记录可以集中呈现同一组约束下的决定，但部分变更时需要重述仍有效的部分。如果任务经常独立演进，应分别记录，并用索引列出当前有效的ADR；不能认为编号最新的一条天然代表整个系统的全部现行决定。复审之后没有导致变更的，结果不写回这条记录，写进决策日志：一张按日期追加的表，每次复审一行，写日期、检查了哪几条触发条件、结果，以及结论是维持还是起草新记录。这样记录本身保持原样，又能看出它被认真检查过。

6.5.4　复审触发条件的写法

复审触发条件用于把变化及时带回评审。没有明确条件，决定可能长期无人检查，也可能在缺少证据时被反复推翻。条件应依赖可观察的事件或指标，并明确由谁检查、何时处理。

一条合格的触发条件有四个部分：事件，即发生了什么，必须是可以观察的；判据，即怎样确认发生，指标用阈值，审批事件用明确状态；判断人，即谁认定条件已经满足；动作，即满足之后做什么，在多长时间内做。此外还有一个常被忘掉的问题：谁在什么时候看哪份文件里的哪个数。条件如果依赖没有人收集的数据，写得再漂亮也只是装饰。下面三组改写，把含糊的说法换成可检验的条件。

1）“效果不好时重新评估”缺少可核查判据。可改为：开发集上同一机制的独立失败达到三条，经检查不能靠已认可范围内的口径修正、补规则或流程调整解决时，小组在五个工作日内提交复审材料，由Tom决定是否批准新候选验证。失败编号、归因和已尝试处置记录在评估分析表中；三条只是示意触发值，不代表统计显著。

2）含糊的写法是“数据条件具备后考虑引入模型”。可检验的写法：David书面答复外部模型服务审批通过，且五项服务审批要求已落实，批准用途明确包含这次测试之后，小组才可以在评估集上对模型候选做首次测试；在此之前，工单正文不离开公司网络。数据来源是David的审批答复和合同文本。

3）含糊的写法是“发现问题随时调整”。可检验的写法：每次阶段门召开之前，小组把记录里的全部触发条件逐条检查，结果写入决策日志，由Tom在门上过目。这是一条日历触发，用来发现那些没有人会主动通知的变化。

触发条件可以分三类，来源不同，发现的方式也不同。评估结果触发，来自评估报告里的失败样本和门槛对照，小组自己就能监测；约束变化触发，来自访问清单、口径认定、审批结果和章程变更记录，由作出这些决定的人通知小组；外部变化触发，来自供应商的条款与价格、法规与标准，没有人会主动告知，要靠日历上的定期检查。三类都要有，缺了哪一类，就留下了一个无人看守的缺口。

触发条件满足，不等于决定自动改变。它只表示这个决定要被重新看一遍，看的结果可能是维持原样。所以“动作”一项写的是起草新记录、交给谁、在几天之内，而不是“改用某某”。把触发条件写成自动开关，一次偶然的波动就可能让系统来回切换。条件也不是越多越好：十几条没有人查的条件，不如少量责任明确、能按时检查的条件。每写一条，先回答前面那个问题，谁在什么时候看哪份文件里的哪个数；答不出来的，删掉，或者改成日历触发。

X1的重启需要三类证据：S3中发现值得进一步检验的事前信号；预测目标与行动出口明确；告警记录访问获批。ADR-0001可把“较长退服中至少30%出现事前信号”作为事先约定的示意筛查条件，但这不是预测模型的通过率，也不能证明可用性。应明确退服时长、最小提前量、事件去重和统计窗口，并报告样本量；还需核查同类信号在未退服期间出现多少次，否则无法估计误报。满足筛查、行动和访问条件后，小组可在10个工作日内起草验证方案，由Tom决定是否重开；信号是否具有预测价值仍需后续独立验证。

6.5.5　合众通信的ADR-0001

把前面各节的结论合成一条记录，就是合众通信的ADR-0001，列在表6-12。有几点需要先说明。第一，状态是提议中，提交日期留在界定门召开之前，Tom是决策人，Alice、David和Emma是咨询对象，Bob是通知对象。第二，S1、S2和X1三项任务的决定合写在一条里，因为它们共用同一份访问清单、同一条数据出网的约束和同一个复核容量，需要放在一起评审；将来若各自演进，就按前面说的办法拆开。第三，备选方案和各项取舍已经分别列在表6-4和表6-10，记录里只做摘要，附表引用，不重抄。

表6-12　合众通信ADR-0001（提议中）

表6-12先列拟议决定，便于决策人理解评审对象，是否接受仍需核对后续证据与条件。未获模型服务审批、告警访问待批等约束，应对应到明确的跟踪和复审事项，不能只留在背景段落。置信度按任务分别写明依据；S1和S2均未完成候选评测，应为二者安排验证，不宜仅凭定性等级断言其中一个更值得优先投入。

提交后，Tom可接受拟议验证方向、要求补证、缩小范围或拒绝，处理按6.5.3记录。已接受也不表示任务质量或发布要求自动通过。记录的作用是让小组、业务人员、审批人及接手者共享同一份依据；后续新决定继续编号，并引用受影响的旧记录。

案例　六周后翻出这份记录

以下为虚构的后续情境。ADR-0001被接受六周后，S3的观察报告出来了：按事先约定的口径统计，25起较长退服里，有9起在退服之前出现过能从告警记录里事先看到的信号，占36%，高于记录里写下的30%。周例会上，Tom很高兴：“这不就是我最初要的吗？那就重开预测。”

Alice没有争，只请大家把ADR-0001的R4条打开，逐条对。第一条，比例达到，满足。第三条，告警记录访问在S3开始之前就已获批，满足。第二条要求预测目标和行动出口由Tom、Alice和外场班组长书面确认：预警要提前多久，监测多长的窗口，收到预警之后外场班组做什么。这一条没有人做过，班组长那里也没有答复。Alice说，第一次演示那天她就问过，排名第三的基站要不要派班组上站，直到今天还没有人回答。

Tom沉默了一会儿，说：“那就先去拿这份答复。”会后，小组在决策日志里添了一行：日期，检查R4，三项满足两项，结论维持ADR-0001，下一步是向班组长取得书面答复。ADR-0001本身一个字也没有动。X1还是原来的状态，未验证，不是已否定，并不代表模型已具备预测价值，而且清楚地知道缺什么。

习题

（1）概念辨析

对照表6-3，说出下面四种情形各是阶梯上哪一级“不够用”的信号，并写出在升到更高一级之前应当先试的替代办法，以及升级还需要补什么证据。（a）确定性规则已有两百多条，依赖关系不清、回归耗时持续增长，改动常带出新的错误；（b）共享查询视图能把三个系统的字段并排放在一起，但值班主管仍要自己判断工单描述里是否要求换件；（c）检索回来的段落是对的，生成的回答里引用却有时不支持结论；（d）固定工作流的现有分支难以覆盖中间结果，每个月都要加几个分支。

（2）场景判断

下面三项任务都是虚构的外部情形，与合众通信无关。请为每项选出起步的一级，说明不选更高一级的理由，以及需要什么证据才升级。（a）某电力公司每天要把五张报表里的设备检修计划与停电申请核对一遍，找出时间冲突的，规则清楚，输入全是结构化字段，每天约三十条；（b）某律所要从上百页的合同里摘出终止条款，并比较同一份合同不同版本之间的差别，条款措辞各异；（c）某物流公司希望“预测明天哪些线路会延误”，目前只有按日汇总的延误统计，没有人定义过预测之后要做什么。

（3）比较表找错

下面是一份虚构的候选比较表的摘要。行是候选，质量栏写的是：规则方案，“准确率约93%”，数字来自供应商的宣传页；大模型加检索，“准确率96%”，由开发人员在自己挑选的30条样本上测得；维持现状，空白。成本栏：规则方案写“低”，大模型加检索写“中”，都没有金额和口径。结论栏：“选大模型加检索”。请指出至少五处问题，并按表6-4的形式改写这一表的质量栏和结论栏。

（4）证据阅读

一篇虚构的报道写道：“某咨询公司对600家企业的调查显示，78%的AI用例来自采购而非自建；另一项研究发现，与供应商合作的项目成功率是自建项目的两倍。”一位经理据此要求“今后一律采购”。请：（a）分别说明这两个数字是谁说的、度量什么、样本是谁、不能推出什么；（b）说明为什么两个数字不能合起来得出“采购更可靠”；（c）为这位经理写三点说明，告诉他在作决定之前，还需要哪些来自本企业自己的证据。

（5）记录找错

下面是一份虚构的决策记录，请对照表6-11找出至少六处缺陷，并重写其中的“决定”和“后果”两栏。标题：“架构说明”。状态：“进行中”。决定：“经过充分讨论，团队一致同意采用大模型方案，因为大模型是当前的主流做法，效果很好。”背景：三页，只列了大模型的优点。备选：无。后果：“显著提升效率，降低人工成本。”复审：“效果不好时重新评估。”

（6）触发条件改写

把下面四条改写成可检验的触发条件，写明事件、判据、判断人和动作，并说明每一条的数据来源。（a）“效果不好时重新评估”；（b）“客户同意之后再启动下一步”；（c）“成本过高时考虑自建”；（d）“模型更新之后看看要不要换”。其中哪一条更适合写成日历触发？为什么？

（7）升级判断

S1的规则候选在开发集200条样本上做单次诊断，其中44条至少有一项任务要求未满足，整体任务通过比例为78%；这不是第5章C2的三次结论通过率，不能直接与85%的C2门槛比较。为便于分析，每条失败暂归一个主要原因：A类18条为换件措辞未覆盖，新增样本仍出现新说法；B类15条为时限起点尚未由Emma认定；C类8条为预留冲突等应转人工情形未覆盖；D类3条为输入字段缺失。请：（a）逐类说明处置与先后顺序。（b）A类是否足以提出模型候选，还需什么证据，最小版本怎样测？（c）若外部服务审批需数周，何时应提出申请，触发条件怎样写？（d）若同一批诊断样本修复12条、新增失败5条，能否认定应替换规则方案？还应核查哪些验收、风险、成本和接手条件，决定写入ADR何处？

（8）综合作业

为一项你熟悉的企业任务写出完整的选型记录。任务可以是电商平台的客服工单中退款资格的核对，也可以是物流公司的单据与合同核对，或者你自己选定的任务，数据与数字可以虚构，但要标明。（a）写出选型输入表：任务、不做的事、标准与门槛、数据与权限、人工复核容量。（b）列出至少五个候选，其中必须包含“不用AI”的做法，按表6-4的形式写比较表，质量栏只填测过的数，其余写“待测”并写明由谁、何时测。（c）用数据与权限的边界、知识与评估的所有权、接手能力三件事判断各项能力应当自建、采购还是混合，写成类似表6-10的取舍表。（d）按表6-11写一条完整的决策记录，至少包括四条复审触发条件，其中至少一条是日历触发，并为每一条写明数据来源和判断人。（e）另附不超过600字的说明：哪些数字是假设，哪些必须由客户认定，你把置信度定在哪一档，依据是什么。

本章交付物

本章交付物是架构决策记录ADR-0001（表6-12），附候选方案比较表（表6-4）和各项能力的取舍表（表6-10）。