[AI书房] 第35章 工作流验证、QA与交接
Claude Code完全掌握
Claude Code完全掌握
第35章 工作流验证、QA与交接
金京镇
部署前质量保证的原则
工作流完成了。所有节点都已连接，放入一两条验证数据后也能跑出结果。「没问题！」这一刻的安心感其实很危险。只用一两条数据验证过的工作流就上生产环境（Production），跟一辆新车只在停车场里开过就直接上高速公路差不多。
部署前的质量保证，也就是QA（Quality Assurance），是保护工作流在实战中不崩溃的过程。跳过这个环节，顾问的声誉会直接受损。把有bug的系统交出去，客户的信任就会崩塌，而信任一旦崩塌，重建它所需的力气是初次建立时的好几倍。
QA的起点是和客户一起规划验证数据。不是随手编造的假数据，而是要求客户提供与实际使用场景相似的样本数据。邮件、客户工单、CRM记录、通话日志，，与工作流在生产环境中将要处理的数据形态一致的资料。如果涉及隐私保护，做脱敏处理即可。
拿到数据后，双方要就成功标准达成共识。好的输出是什么样的，绝对不能出现的又是什么，都要明确下来。
「我会用实际数据跑一遍系统。在这个过程中，您可以确认系统到底是怎么运作的。」
这一句话就能给客户留下专业的印象。大多数人只会说「做好了，您试试吧」。主动介绍QA流程，本身就是差异化。
压力验证：以失败为出发点的思维方式
要跳出像开发者那样逐个节点检查的模式，转向像工程师那样为失败做预案的思维方式。
自动化中，，如果包含AI则更甚，，不可预测的状况一定会出现。进入生产环境后，真实用户和真实数据会制造出你想象不到的边界情况（Edge Case）。在验证阶段要做的事，就是不断问自己这个问题。
消除所有可能的问题是不可能的。目标不在于此。目标是让问题发生时，系统能够安静、安全地失败。设置超时（Timeout）防止无限等待，加入错误处理（Error Handling）在出错时通知负责人，把失败记录自动写入电子表格以便追踪规律。
[图 35-1] 压力验证场景矩阵]
在此基础上执行黑盒验证（Black Box Testing）。把工作流视为一个黑箱，尽可能多地投入样本输入，，不是一两条，而是几十条，能达到几百条更好。对每一条输入记录三件事：输入了什么，中间发生了什么，最终输出是什么。然后将输出与客户达成共识的成功标准进行比对。
把失败的、结果异常的、落在边界线上的标记出来。这就是内部QA轮次（Internal QA Pass）。目标是在客户接触系统之前，尽可能多地捕获问题。内部QA至少应持续数天。
AI质量检验的附加层
如果工作流中包含AI，就需要额外的检验项目。不是检查AI节点能否运行，而是检查输出的质量。
相关性与准确性：AI的回答是否真正针对请求？信息是否准确？
语气与安全性：有没有不恰当或不符合品牌调性的表述？系统提示词或内部信息有没有泄露？
一致性：同样的输入投入10条，产出的答案质量是否大致相当？
在幕后还可以做A/B验证和评估。将不同的提示词和模型应用于同一数据集，追踪哪种组合能产出最佳结果。
「我用实际数据验证了多种提示词和模型的组合，选出了质量和一致性最高的方案。评估数据可以给您看。」
这样的说明会让客户认识到，你不是一个搭建工具的人，而是一个系统工程师。
日志记录的重要性
日志（Log）是QA的证据。将工作流的执行历史存入Google Sheets等工具，追踪输入、输出、工具调用、错误、模型的token消耗量。通过日志可以识别反复出现的失败类型、频繁的不良输入、提示词或模型选择上的薄弱环节。
日志也是与客户沟通时的依据。你可以用数据说话：「我们验证了这些内容，得到了这样的结果，因此做了这些改进。」
[图 35-2] QA日志电子表格结构示例]
客户交接：专业移交的技术
内部QA完成后，进入面向客户的QA（Client-Facing QA）阶段。为客户提供一个简洁的界面来验证系统。如果是聊天机器人就提供聊天窗口，如果是数据处理工作流就提供输入表单。关键在于不要暴露内部结构，客户需要看到的是结果。
征求修改意见。收集客户对输出准确度、语气、格式的反馈。如果前面的工作都做到位了，修改意见通常只涉及提示词调优（Prompt Tuning）或模型微调。经过几轮迭代，反映修改意见，再做内部QA，再请客户确认。
收尾阶段录制一段简短的更新视频。展示一两个完整的执行过程，，从输入到工作流处理再到最终输出，，指着日志说明系统是如何处理实际数据的。
QA完成后进入移交（Handover）流程。移交的形式取决于两个因素。
搭建环境：如果是在客户的环境中直接搭建的，移交相对简单，因为一切都已经在他们的基础设施里了。如果是在顾问的环境中搭建的，则需要凭证迁移、连接重设等额外工作。
项目是否终结：这个项目是否到此为止，还是后续有追加工作或维护合同，这决定了移交的完整程度。如果还会继续合作，验证基础设施可以保留。如果即将离场，移交必须是最终的、完整的。
移交时的必备清单
工作流复制：将生产版本和备份/验证版本分开。与软件团队把开发环境和生产环境分离是同一个道理。需要变更或更新时，先在验证版本上确认无误，再同步到生产版本。
备份：将工作流导出到GitHub、Google Drive等平台，确保能回退到之前的版本。如果能建立自动备份流程就更好。
工作流整理：给每个步骤起清晰的名称，用便签注释解释逻辑。日后即使换了别人来看，也能立即把握住整体结构。
敏感信息清除：最终检查工作流中是否还残留着明文存储的API密钥或token。
视频指南：录制1到2分钟的屏幕录像，介绍系统的运行方式、配置方法，以及更新时需要确认的事项。
文档化：留下一份文档，说明该工作流是基于什么逻辑设计的。顾问离场后，客户团队中的某个人或新接手的开发者在接管时，这份文档就是指南。
[图 35-3] 移交检查清单完整图示]
通过维护合同转向长期关系
移交完成后就进入项目收尾阶段。在这个过程中要解决两件事。
结算收尾：把最初达成共识的工作范围（Scope of Work）重新拿出来，逐项确认每一项都已完成。客户确认项目完成后，发出最终账单。「双方约定的工作流已完成搭建、验证、文档化和移交。现在发出最终账单。」
维护合同讨论：聘用费（Retainer）是与项目费用分开的合同。包含bug修复、小幅调整、依赖变更、监控、基本安全检查。不包含新功能、新工作流、大范围的需求变更。那些属于独立项目。
简要设定服务级别预期（SLA）。紧急故障在数小时内响应，一般需求在数天内处理。不必搞得很复杂，但预期必须清晰明确。
所有权和知识产权（IP）也要理清。大多数咨询合同中，交付物在付款后归客户所有。但顾问对可复用的模式、通用工具和基础模板所享有的权利应当得到保护。
退出流程（Exit Process）同样需要事先定义。当客户希望终止服务时，哪些内容需要移交、哪些包含在服务范围内、哪些需要另行付费，都应提前约定。
「交付物在付款后可在您的业务中自由使用。如果日后需要更换合作伙伴，我们将通过规范的交接流程，把一切完整移交给您。」
[图 35-4] 项目完成 → 维护合同 → 扩展项目的转化流程
对初学者来说，最关键的一条原则是：停止非正式地开展工作。范围、完成标准、款项、维护、服务级别、缺陷与变更的界定、所有权、退出条件，全部写进书面合同。当双方都清楚买的是什么、后续会发生什么，项目才能顺畅推进，误解才会减少。
将这整套流程（构建、验证、交接、维护）以专业方式执行，一次性项目就会转化为长期合作关系。关系越深入，你对客户业务的理解就会超过任何人，而这种理解本身就是竞争优势。你会成为难以替代的合作伙伴。
当从温暖人脉起步的合作关系趋于稳定，拓宽视野的时机就到了。如何走出熟人网络、迈向更广阔的市场，也就是如何在恰当的时机以恰当的方式运用冷启动拓客（Cold Outreach），这是下一个课题。
人工智能专家 金京镇 律师
AI法律政策专家 · 前国会议员 · 著作等身
如果这本书曾在你身边短暂停留，请支持我们，让下一个故事得以问世。
（自愿赞助账户：农协 302-1096-0948-81 户名：金京镇）