第 5 章 运营与改进

学习目标

• 按照工作风险制作审核清单，并依据错误的严重程度，选择全量审核或抽样审核。
• 定义质量、效率、采用和局限四类运营指标，并为每项指标确定分母与收集方法。
• 按失败发生的阶段对案例分类，经过复现和回归测试，再修改指令与资料。
• 将指令、资料、连接、模型和产品的变化，纳入同一套变更管理流程。
• 利用基线和总运营成本衡量引入效果，并制定转人工与结束运营的计划。

引言

某个团队引入客户回复草稿助手，已经过去三个月。组长在季度报告中写道：“每月使用次数增至三倍。”然而在同一时期，客服人员的下班时间并没有改变。仔细查看后才发现，客服人员几乎都要把助手写的草稿重新写一遍；使用次数之所以增加，只是因为他们不断重新生成，直到出现满意的草稿为止。数字看起来很好，工作却没有减少。还有更糟糕的情况。两个月前更改的包邮标准，并没有反映到助手的资料中；但由于客服人员本来就会重写草稿，没有人发现这一事实。不测量，就无法改进；测量方法错了，则会让人改错地方。

自动化是从部署的那一天才开始的。资料会变旧，工作会变化，产品也会变化。本章讨论应该如何审核结果、测量什么才能看清实际状态、怎样把失败转化为改进、实施变更时应该遵守什么，以及怎样证明引入效果。最后还会讨论，当自动化停止或失去目的时，如何让工作继续进行。第1章设计书中写下的成功标准，以及第2章的测试问题集，将在本章再次用到。

核心概念

审核清单：按风险选择检查项

如果不事先确定人工查看结果时应检查什么，审核就会变成“大致浏览一下”。但如果所有工作都套用同一份很长的清单，真正重要的项目又会被埋没。因此，制作审核清单时，要按照工作风险来选择检查类别。

第1章步骤表中写下的完成条件，就是审核清单的起点。而且，清单并不是一份固定不变的文档。如果出现审核者反复修改的地方，这就应当成为下一个检查项目，也是下一个改进对象。

错误严重程度与全量、抽样审核

并非所有错误都有相同的分量。如果将一个逗号用错，与把邮件发给了错误的客户，按同样的分数计算，指标就无法反映实际风险。因此，要将错误划分为不同等级。

审核方式也应随错误等级而不同。可能发生严重错误的步骤，要保留全量审核，也就是检查每一件。只可能发生轻微错误的步骤，可以改为抽样审核，也就是随机选择其中一部分进行检查，以节约人工时间。如果抽样审核中，重要及以上等级的错误数量超过既定标准，就要恢复全量审核。这个切换条件，必须提前确定。

统一审核者的判断

如果有两位或更多审核者，对同一个结果的判定就可能不一致。一人认为“需要修改”，另一人却认为“合格”，质量指标便会随着审核者不同而发生很大变化。统一判断的流程如下。

1. 让各位审核者对相同的10～20份成果分别作出判定，期间互不查看对方的结果。
2. 收集判定存在分歧的事项，并讨论各自的理由。
3. 将达成共识的标准，连同“合格、修改、暂缓”的简短示例，一起写入审核清单。
4. 每个季度，以及每次审核者更换时，都重复这一过程。

对于判定持续存在分歧的项目，这就是标准过于模糊的信号。应把该项目进一步拆分得更具体，或者将需要主观判断的内容，改为可以直接核查的事实。

四类运营指标

只看一个指标，就会判断失误。即使用户增加，质量下降仍然是问题；即使质量很好，如果没有人使用，也不会产生效果。局限指标突然接近零，同样不一定是好信号，因为可能存在该转交人工的事项却没有转交的情况。产品有时也会提供指标。例如，Gemini Notebook在笔记本与至少4人共享、且最近7天内发生过对话时，会显示每日用户数和问题数。这类指标只说明采用情况，不能说明结果质量。

指标定义与分母

同叫“批准率”，不同团队计算方法不同，就无法比较。每项指标都应编写定义书。

[指标定义书]
指标名：无需修改即批准的比例
公式：（无需修改即批准的草稿数）÷（已完成人工审阅的草稿数）× 100
纳入：期间内已完成审阅的草稿
排除：仍待审阅的草稿、测试草稿
部分修改：修改事实、条件、承诺算“修改”；只改错别字、空格，另计为“文字修正”
收集方法：每周下载一次审批界面记录
负责人：运营负责人

分母是关键。在同一统计周期内生成100份草稿，只有60份完成审阅，其中45份无需修改即批准，以生成数为分母是45%，以已审阅数为分母是75%。未审阅的40份质量未知，因此质量指标应以已审阅数为分母，另报审阅率。部分成功（仅部分正确）与暂缓如何计数，也要预先确定。

选择评分方式

评价结果的方法，大体分为三种。Anthropic建议，选择评估方法时，应选择尽可能快速、可靠，并能够扩大规模的方法。

如果把评分交给AI，就应提供具体的评分标准表（量表），要求它给出“正确/错误”或1～5分之类的固定答案，并先与人工评分结果比较，确认是否值得信任。同一项工作如果包含多个评价标准，也可以为不同标准采用不同的评分方法。此外，评估题应接近实际工作的分布，并且不能遗漏异常案例。

按发生阶段对失败案例进行分类

发现失败后，人们往往会马上想修改指令，但并不是所有失败都出在指令上。首先应分清，失败发生在哪一个阶段。

在这张表的任何一栏，更换模型都不是首选处理办法。资料已经过时，换了模型，新模型仍然会用同一份过时资料回答。删除对话记录，也不会让助手“忘记”错误。决定助手行为的，是指令、资料和连接。OpenAI也说明，与其先添加更多工具，先完善指令并补充示例，往往能够更快解决问题。

将一次失败转成改进实验

如果只临时修补眼前发现的一次失败，类似失败还会以另一种形式再次出现。把失败转化为改进实验，可以按照以下流程进行。

1. 复现。 使用相同输入，确认是否会发生相同失败，并记录当时的指令、资料和设置状态。
2. 提出假设。 依据失败发生阶段表，选出一个可能的原因。
3. 只改变一处。 如果同时修改多个地方，就无法知道究竟哪项修改产生了效果。
4. 进行回归测试。 将失败案例与原有测试问题集一起运行，确认这次修复是否破坏了以前能够正确回答的内容。在软件测试中，原本正常的部分再次出错，称为回归。
5. 将失败案例加入测试集。 下次变更时，也使用这个案例进行检查。

变更管理

会改变自动化结果的，并不只有指令。总共有五类内容会发生变化。

这些变更，都使用同一套流程处理。

1. 写明要变更的对象与理由，并查明哪些用户、哪些工作会受到影响。
2. 使用固定的测试集，比较变更前后的结果。
3. 先对一部分用户应用变更，观察指标，这称为分阶段应用。
4. 再向所有用户应用，并保留以前的状态，确保能够恢复。
5. 简短地通知用户，哪些内容发生了变化，以及为什么变化。

OpenAI说明，可以在GPT编辑界面查看版本历史，并恢复以前的版本。如果产品没有版本功能，就应将指令原文按日期分别保存为文档。对于并非我们主动修改的变化，例如模型、产品或连接提供方的变更，应通过查看公告、重新运行测试集来应对。

衡量引入效果

引入效果必须与基线比较才能证明。基线是引入前按相同方法测得的值。成本不仅包括订阅或用量费用，还应包括全部人工时间。

净节省（月）=（引入前每件时间 − 引入后每件总时间）× 每月处理件数
              − 每月维护时间（资料更新、指令修改、测试集管理、培训）
引入后每件总时间 = 生成与输入时间 + 审阅与修改时间 + 返工时间

例如，引入前每件15分钟，引入后生成2分钟、审阅修改6分钟，每月300件，维护8小时，则净节省为（15−8）×300＝2,100分钟（35小时），再减8小时，得27小时。同时报告工具费用，还要确认质量是否维持。时间减少但错误增加，只是将成本转移到了别处。

用户采用与支持体系

工具部署以后，用户又悄悄回到原来做法的情况，并不少见。原因通常并不在工具本身。

1. 首次使用引导：提供三个具体示例，说明适合先将工具用于哪些工作。
2. 可以信任的范围：告知用户，哪些范围可以直接使用结果，从哪里开始则必须核查。
3. 报告渠道：设置一个让用户看到错误答案后，能够在10秒内报告的渠道。
4. 寻找隐藏的手工工作：访谈没有使用的人，以及用过后放弃的人。把结果移到其他程序后又要重新整理之类、没有被指标记录的手工工作，往往就是原因。

事故应对、转人工与结束运营

应在平时就制定好计划，以应对自动化停止或出现错误行为的情况。

Anthropic也建议，每次运行定时任务后，都应核查结果，并暂停或删除不再使用的任务。没有人使用、却仍然继续运行的自动化，既在花费成本，也在保留已经陈旧的权限。

深入阅读

比较的陷阱

展示引入效果最简单的方法，是比较“引入前3个月与引入后3个月”。然而，如果这期间工作量、工作难度、负责人或季节发生了变化，就无法知道差异是不是自动化带来的。

即使采用同期比较，如果两组处理的工作构成不同，结论也会出错。比较时，应养成按工作类型分别查看的习惯。即使总体平均值有所改善，困难类型的表现也可能反而变差。

警惕看似亮眼的数据指标

当数字看起来很好时，应检查以下几个问题。

1. 分母是什么？ 重新生成的次数越多，使用次数也会越高。要检查是按事项数量统计，还是按使用次数统计。
2. 听到的是谁的声音？ 满意度调查容易只有持续使用的人回答，而停止使用者的理由却被遗漏。
3. 观察的数量足够吗？ 仅凭一周20件结果，很难说“错误率为0%”。
4. 减少的究竟是什么？ 可能只是生成时间减少，审阅和返工时间却增加了。
5. 困难案例去了哪里？ 如果转交人工的比例骤降，要检查是否在勉强处理本应转交的工作。

结束运营也需要设计

并不是所有自动化都需要永远运行。如果相关工作已经消失、出现了更好的方法，或者净节省小于维护成本，结束运营就是正确的决定。结束时，应留下以下内容：结束了什么、为什么结束，指令和测试集的最终版本，已经断开连接和撤销共享的确认，以及由人重新接手的流程。有了这些记录，今后再次进行类似尝试时，就不必从头重新学习。

工作场景

涓流文化基金会：资料结构改变之后

地区文化基金会“涓流文化基金会”的宣传团队，每周四下午都会用定时任务，生成下一周文化活动通知的草稿。任务读取由活动主管部门管理的日程电子表格，为每项活动撰写通知，再保存到团队云盘。宣传团队的林专员审阅草稿之后，将其发布到官网和简报中。

某个周四，林专员发现，十四份草稿中有九份的地点栏为空。因为在审核阶段就被拦下，没有任何一份发到外部。林专员首先暂停了下一周的任务，这一周的通知则按照上周的方式手工撰写。由于事先已经写好了转人工流程，半天时间就足够完成。

寻找原因时，林专员并没有首先怀疑指令。她按五个类别，检查与上周相比发生了什么变化：指令没有改变，连接也正常，供应商也没有发布模型或产品变更公告。按变更管理表来看，发生变化的是“资料”；按失败发生阶段表来看，则是任务输入格式改变所导致的“输入”阶段失败。活动主管部门在调整电子表格时，把“地点”一列拆成了“地点（楼栋）”和“地点（房间）”两列，而任务仍在查找原来的列名，因此找不到。

一位团队成员建议，在指令中用粗体加上一句“必须写明地点”。林专员没有接受这个方案。如果输入中根本没有地点信息，却增加强调句，任务就可能编造地点，或者搬来相似活动的地点。她改为做了三项调整。在指令中反映新的列结构，并要求地点栏为空时，在该活动通知最上方标注“地点待核实”。在测试集中，加入地点缺失的活动，以及只有房间号的活动。她还与活动主管部门约定：“修改电子表格列时，事先通知宣传团队”，并将这一约定写入资料管理台账的变更联络栏。

恢复运行的条件，是通过回归测试并由组长确认。原有测试集中的20个案例，以及新加入的4个案例，全部符合预期后，她才重新启用任务。林专员的变更记录中留下这样一句话：“指令并没有改变。改变的是资料的形式。”

绿叶消费合作社：不使用者的理由

消费者生活合作社“绿叶消费合作社”的客服中心，四个月前引入了会员咨询回复草稿助手。运营负责人南宫专员准备季度检查时，收集了四类指标，却从采用指标开始就遇到了问题：15位客服中，每周持续使用的只有6人。而这6位使用者的草稿，无需修改即批准的比例达到70%，表现并不差。

南宫专员逐一与没有使用的9位客服见面，发现原因并不在于质量。助手的草稿，每个段落都带有标题和列表符号；但粘贴到客服系统的回复栏时，这些符号就会乱码。客服拿到草稿后，每件还要花2～3分钟删除符号、重新调整换行，因此觉得不如从头自己写。这些时间，没有被任何一项指标记录，因为效率指标只测量了“草稿生成时间”。

南宫专员修改了两处。他将指令中的格式要求改为：“用能够直接粘贴到客服系统回复栏的普通句子撰写，不要使用标题和列表符号。”随后用相同测试集，确认改变的是否只有格式。他也修改了效率指标的定义：现在，每件处理时间从打开咨询的那一刻起，一直计算到发出回复的那一刻。

他也调整了质量指标。此前，两位审核者各自作出判定；但让他们分别判定相同的15份草稿后，发现有5份的结论不同。两人针对存在分歧的草稿统一标准，再将“合格、修改、暂缓”的示例附在审核清单中。

两个月后，每周使用的客服增加到13人，每件咨询的整体处理时间，从引入前的11分钟缩短到7分钟。南宫专员的报告，将四类指标并排展示，而不是只列使用次数；在最后一行，还写明指标定义已经改变，以及为什么改变。

易错点

1. “补上一句强调的话，就能修好。” “绝对不要出错”或粗体文字，并不能解决原因。应先分清失败阶段，再针对该阶段修正。
2. “换一个模型，就能解决全部问题。” 过时的资料、变化的输入、模糊的指令，在任何模型中都会导致同样的错误。
3. “删除失败的对话，就不会再答错。” 删除对话记录，不会重新训练助手。失败案例反而是应保留的测试材料。
4. “使用量增长，就说明成功了。” 重新生成也会增加使用次数。必须同时查看质量、效率、采用和局限。
5. “我们没有改过任何东西，结果就会保持不变。” 资料、连接、模型和产品，可能在我们不知情时发生变化。要查看公告，并定期重新运行测试集。
6. “修改后的版本，直接向所有人部署。” 如果跳过测试集比较和小范围应用，所有用户都将承受新的错误。
7. “生成时间缩短了多少，就节省了多少。” 必须扣除审阅、修改、返工和维护时间，才是净节省。

要点速览

• 审核清单要按工作风险选择类别，从完成条件出发，并利用失败案例继续补充。
• 错误分为轻微、重要和严重。可能出现严重错误的步骤采用全量审核，其余采用抽样审核，提前确定切换条件。
• 如果审核者有两人以上，要分别判定同一批事项，再统一标准。
• 质量、效率、采用和局限四类运营指标要一起查看。每项指标都应定义计算公式、分母、纳入与排除范围，以及收集方法。
• 评分时，精确值用规则，模糊判断交给人，语气和格式则可由事先检验过可靠性的AI评定。
• 先分清失败发生在输入、资料、检索、生成、权限、连接、审核或交付中的哪个阶段。更换模型不是首选处理办法。
• 改进顺序为：复现→提出假设→只改一处→回归测试→加入测试集。
• 变更管理应同时涵盖指令、资料、连接、模型和产品这五类内容。
• 净节省＝每件减少的整体时间×件数−维护时间。同时确认质量是否保持原有水平。
• 停止信号、转人工流程、恢复条件和结束运营标准，都应在平时提前确定。

查阅官方文档

• Anthropic — Define success criteria and build evaluations：阅读成功标准条件、评估设计原则，以及代码评分、人工评分和AI评分的优缺点。
• Anthropic — Building effective agents：确认边测量边迭代、仅在明显改善结果时增加复杂度的原则。
• OpenAI — Creating and editing GPTs：阅读预览测试、版本历史与恢复、自定义GPT停用日程。
• Google — Create a notebook in Gemini Notebook：确认笔记本使用分析指标及条件。
• Google — About the transition from Gems to skills：确认产品转换日程和迁移方式。
• Anthropic — Use Claude Cowork safely：阅读检查定时任务结果、清理不用任务的建议。

自测

5-1. 请解释，所有工作都使用同一份很长的审核清单，会产生什么问题。再从本章的表格中，各选出一类公司内部每周会议纪要摘要必须检查的类别，以及一类可以省略的类别。

5-2. 如果把错误分为轻微、重要和严重三级，请为每级各举一例，并提出一个从抽样审核恢复为全量审核的条件。

5-3. 两位审核者的判定经常不一致。请用三个步骤写出统一判定标准的流程，并说明对于仍然持续存在分歧的项目，应如何修改。

5-4. 某一周共生成200份草稿，人工审阅了其中120份，而其中90份无需修改就获批准。请分别计算以生成数量和已审阅数量为分母的比例，并写出报告时应该用哪一个作为质量指标，以及需要同时附上什么。

5-5. 请按失败发生阶段，对以下三种失败分类：①连接器身份验证过期，未能取得昨天收到的邮件；②找到了正确的依据文档，但回答时漏掉了例外条款；③申请表格式改变，未能读取申请人的联系方式栏。

5-6. 请用以下虚构数据计算每月净节省：每月500件，引入前每件10分钟，引入后生成需要1分钟、审阅和修改需要4分钟，每月维护时间10小时。请展示计算过程，并写出在仅凭这个数字宣布成功之前，还应确认的一件事。

5-7. 为应对必须停止自动化、由人接手工作的情况，请写出平时应提前确定的三项安排，并说明缺少其中一项时，会产生什么混乱。

实操练习