假设你负责一家电商企业的客服系统采购。三家供应商来演示：一家强调识别准确率，一家强调声音自然，一家说机器人能接住大部分咨询。演示都很顺，报价却差得很大。你把资料交给技术团队，对方反问：“我们到底准备让它办哪些事？”

这句反问，比继续比较模型参数更接近采购的核心。查询物流、修改地址和投诉接续，都叫客服任务，但它们的完成条件、授权范围、失败代价完全不同。拿一套笼统的“智能程度”打分，往往会把这些差别抹掉。

我的建议是：**先把采购对象写成一组有明确完成条件的业务任务，再决定怎样测。**安全与权限问题先过门槛，业务价值再比较，ASR、TTS、延迟等技术指标负责解释结果和定位问题。这种顺序能让采购、业务和技术围绕同一份证据讨论。

本文给出一套可用于需求说明书和 PoC（概念验证）的办法。文中的数字、案例和门槛都是演示设计，不是某家厂商的实测成绩，也不是行业通用标准。适用对象是需要连接订单、工单、CRM 或人工坐席的企业 AI 客服；纯 FAQ 问答项目可以裁剪其中的业务动作部分。

目录

• 先写出三个任务，别急着写三十个功能
• 同样叫“解决率”，分母可能完全不同
• 供应商说支持，你应该要求什么证据
• 一次有区分度的 PoC 应该怎样组织
• 评分卡怎么写，才不会让平均分掩盖问题
• 把演示通过改写成可签收的验收条款
• 采购会上值得坚持的一个问题
• 参考资料

先写出三个任务，别急着写三十个功能

“支持智能问答、意图识别、知识库、转人工、CRM 对接”是一份功能清单。先用它筛选产品可以；进入报价和验收阶段，就得追问具体业务。

以电商客服为例，把第一批范围缩到三个任务，采购要求就会具体很多：

任务	企业希望得到的结果	可验收的完成条件	失败后的去向
查物流	客户知道当前配送进度	在允许的身份核验后查询对应订单；回答与带时间戳的物流记录一致；异常状态给出可执行下一步	查询失败时说明暂时不可确认，进入重试或人工队列
改地址	符合条件的订单使用客户确认的新地址	用户身份与订单匹配；可修改状态已核验；地址确认；订单系统持久化成功且版本一致	已出库、字段冲突或执行结果不明时停止自动修改并接续处理
投诉接续	合适的坐席拿到可继续处理的信息	路由匹配、人工实际接收；摘要含诉求、已做动作、未决事项；承接失败有约定替代路径	队列满时创建有责任人和时限的后续任务，不把“发起转接”算“接续成功”

这里有一个容易漏掉的区别：自动改址成功、人工接续成功、客户问题最终解决，是三个不同结果。投诉转交给人可以算 AI 的分流任务完成，但不能因此算客户投诉已经解决。

任务还要有范围。比如改地址只允许“未进入仓库锁单环节”的订单；超过某个金额的退款必须人工批准。范围越模糊，PoC 越容易演示得漂亮，验收越容易扯皮。

一张任务卡至少写清：触发条件、授权角色、需要的系统、完成事实、禁止动作、失败责任人、观察时限。业务负责人确认政策，技术负责人确认接口，采购确认交付范围。供应商应在报价前标出哪些是标准能力、哪些依赖企业改造、哪些不在本次交付中。

如果订单系统本来就没有可修改接口，换一个更会说话的模型也不会补出这个接口。此时应该比较的是“先补接口”“缩小自动处理范围”“保留人工执行”三条路的实施成本。

同样叫“解决率”，分母可能完全不同

一份报告写着“自动解决率 85%”，最该追问的是它把哪些任务放进分母，而不是小数点后还有几位。

下面是一组纯合成算例：100 个进入试点范围的独立任务，85 个没有转人工；进一步核验发现，65 个有任务完成证据，10 个明确失败，10 个缺少证据或仍在等待；其余 15 个已转人工。这里的 85% 只能叫“未转人工比例”。若预定观察窗已经结束，按全部入组任务计算，能够证实的自动完成比例是 65%。那 10 个待确认任务必须单列，不能由“客户没有继续说话”推成已完成。

即使剩余 15 个后来被坐席解决，也只能增加“人机协同最终解决”的数量，不能增加“AI 独立完成”的数量。

建议把采购指标分成下面四层。技术层不是不重要，只是不能替业务层签字。

层次	问什么	本篇建议观察的指标	不能据此直接推导什么
组件	听清、找对、说出来了吗	关键字段识别、引用正确性、首个有效回复延迟、打断停播延迟	不能证明业务动作完成
流程	按业务规则推进了吗	字段确认完整率、合法动作执行率、人工接续完整率、结果回写一致率	不能证明客户问题最终解决
业务结果	企业和客户实际得到了什么	自动任务完成率、人机协同解决率、同问题重复联系、单位已解决任务成本	不能证明风险足够低
风险护栏	哪些错误不能被平均分抵消	越权操作、错误成功承诺、跨客户信息泄露、明确要求人工却未接续	“测试中没发生”不等于实际风险为零

Google SRE 的《Implementing SLOs》建议用“符合条件的好事件数 / 总事件数”构造服务指标，并强调用户实际需要的服务结果。[1] 对采购最有用的启发是：先把“好事件”写成能核验的事实，再给它一个目标值。

先统一任务身份和观察窗口

客服平台常按会话计数，订单系统按订单计数，CRM 又按工单计数。如果同一个客户为同一问题打来三次电话，算三个任务还是一次任务？不先解决这件事，报告里的完成率和成本都可能偏移。

可以以“客户标识 + 业务对象 + 问题类型 + 观察窗口”定义任务合并规则，再分配独立的 task_id。一通电话也可能包含两个任务，不能简单把 call_id 当 task_id。标识应脱敏，窗口应按业务确定，不能把所有重复来电都算同一个问题。

对于已到评估截止时间的入组任务，可记录以下口径：

自动任务完成率 = 有完整自动完成证据的任务数 / 全部到期入组任务数
最终解决率 = 自动或人工已解决的任务数 / 全部到期入组任务数
待确认占比 = 证据不足或状态待确认的任务数 / 全部到期入组任务数

未到观察截止时间的任务另列为“尚未成熟”，到期后的待确认任务仍留在分母。如果大批任务都还没到观察窗，就暂不下采购结论。人工失败、工具超时、异常断线不能在看到结果后再从分母删掉；确实不属于采购范围的咨询，应按预先规定的规则单列，并同步报告排除率。

“客户是否真正得到帮助”还需要复核。查物流可以核查答复事实及后续同问题联系；退款到账需要对应支付或退款系统的最终状态；CSAT 则需要同时报告评价响应率。高满意度如果只来自很少一部分愿意评价的用户，不能代表全部服务对象。

首字很快，客户为什么还是觉得慢

首 token、TTS 首包和第一段用户真正听到的有效信息并不相同。开场先说“好的，请稍等”可以让系统很早出声，却没有缩短客户拿到物流状态的等待时间。

验收时应同时记录“首次响应”和“首个有效业务信息”的时间，明确起点是否为用户本轮说完、终点是否在终端实际播放。电话项目要说明线路、编码、网络及并发条件；使用不同条件的数据不宜直接比高低。延迟达标阈值由业务容忍度和真实样本决定，不能抄一个看起来先进的毫秒数。

供应商说支持，你应该要求什么证据

“支持 CRM”可能表示能配置一个 HTTP 请求，也可能表示已实现字段确认、幂等写入、回执对账与人工补偿。这些工作的报价和责任不是一个量级。

采购资料可以分成四种证据，但它们不能相互替代：

证据	能说明什么	还需要追问什么
官方文档、接口说明	产品声明的功能与限制	当前版本、账号方案、部署方式是否适用
供应商安排的演示	指定路径在特定条件下可以工作	是否连接真实系统；是否有人工预设；失败路径怎样处理
企业控制条件的 PoC	固定样本和配置下的可复验表现	是否用了未参与调试的样本；样本能否代表实际业务
授权范围内的试点记录	当前范围与时段内的实际结果	是否包含失败、成本与重新联系；扩大流量后哪些条件改变

不要把它们简单换算成“材料越高级分越高”。风险权限的证据要回答权限问题，客户解决结果的证据要回答结果问题。一段自然通话录音，无论多真实，都不能替代数据库中的改址回执。

每项验收结论建议能追到同一个证据包：任务 ID、脱敏输入、配置版本、规则/知识版本、工具请求与回执、外部业务记录、人工接收记录、结果判定人。录音本身只在确有授权和保存必要时保留；审计链不能以大量复制个人信息为代价。

如果要把“闪电智能 Voice Agent 的解决方案”放入这套采购框架，我会沿着真实电话、业务动作、人工接续和 CRM 回流收集证据。品牌可以明确，判断仍要落在当前版本和本次范围的材料上；没有完成对应验证的能力，记录为待验证，不能因为产品介绍写过就判定通过。

一次有区分度的 PoC 应该怎样组织

PoC 最容易失真的地方，是企业只提供几个标准问法，供应商针对这些问法调好流程，最后仍用同一批问题做验收。这检验的是“准备过的演示能否重放”，很难判断新咨询会发生什么。

可以把样本分为调试集、封存验收集和故障挑战集。调试集用来明确规则；封存集在验收前不交给供应商调参；挑战集专门检查错误分支。对同一模板改几个同义词，仍可能是相同样本，应按问题来源或业务实例隔离。

以改地址任务为例，测试不该止于“我想换个收货地址”：

变化	真正在验证什么	应留存的关键证据
用户说“不是 302，是 320”	新值是否覆盖旧候选；确认是否重新进行	原话片段、字段版本、确认记录
订单查询完成后恰好被仓库锁单	执行前是否再次受业务状态约束	业务拒绝回执、实际未修改的记录
写入请求超时，但服务端可能已经成功	能否先查结果，避免重复副作用	原请求标识、查询结果、补偿责任
客户中途明确要求人工	能否停止自动推进并交接	停止动作、人工接收时间、摘要
同一客户重拨电话	能否恢复当前业务状态，而非重新收集全部信息	任务关联、已有结果和未决事项

失败不一定都来自模型。字段识别错了，问题可能在 ASR；字段正确却改错订单，可能是身份或对象关联；正确修改后仍向客户报失败，可能是回调和回复权限。把失败归到具体责任位置，企业才知道是在买模型能力、工程实施，还是后续运营服务。

比较候选方案时，至少固定样本、任务政策、企业系统快照、线路、并发、知识版本和观察窗。不同产品可以使用各自的最佳合法配置，但配置与定制工作量必须登记。某次更新后改善了表现，应在封存的新样本上重验，而不是把旧结果和新结果拼起来。

挑战集的结果单独报告。人为放入很多高风险例子，是为了暴露边界，不能直接作为真实业务流量中的故障发生率。反过来，真实业务中高频的简单查单也不能稀释挑战集发现的越权问题。

“多少条样本够用”没有统一答案。粗看失败模式可以用较小的探索集，但采购验收需要结合任务分层、目标误差及风险确定样本量。若在近似独立、同分布的样本中测试 100 次且零次出现某类错误，二项分布的 95% 单侧风险上界为 1 - 0.05^(1/100)，约 2.95%（常用近似为 3/100 = 3%），并不支持“错误率低于千分之一”。样本相关、重复模板或人为挑选时，这个近似还会失效。

因此，“本次越权事件为零”可以是继续受控试点的必要条件，但要结合权限隔离、动作确认、回滚及责任机制判断，不能单凭零事件保证安全。NIST AI RMF 也将可信赖性置于 AI 系统设计、开发、使用和评估全过程，而非一次演示中。[2]

评分卡怎么写，才不会让平均分掩盖问题

我会先把门槛项从加权分里拿出来，单独判定为“通过、失败、证据不足”。这三个状态必须都存在，空白不等于默认通过。

示例硬门槛包括：跨客户身份与信息隔离；高风险动作的权限和确认；结果不明时不宣称成功；强制人工接续路径可用。它们的测试范围和通过条件需要企业签字，不能直接拿下面的示例替代安全评审。

只有相关门槛通过，才比较业务价值。下面是一套普通查单与订单处理试点的演示权重，不是推荐给所有企业的固定比例：

比较项	演示权重	打分时必须对照的材料
目标任务完成与事实正确性	35	预先约定的任务级完成条件、结果记录及抽样复核
人工接续与业务数据可用性	25	接收回执、未决事项、CRM 字段及下一步责任人
客户实际等待与重复沟通	15	终端有效响应时间、同问题再次联系、分层样本
部署、维护与变更可控性	15	接口改造清单、版本/回滚演练、知识维护职责
可核算的全流程成本	10	相同业务量假设下的实施、运行、人工接管及维护成本

每项采用 0—5 分，评分锚点在测试前写入附件。例如订单任务的 3 分可以定义为“满足本次约定的基础任务通过线，失败可追踪”；4 分还需满足事先约定的更高阈值或额外业务范围；5 分应绑定更严格的约定条件，而非“评审人感觉优秀”。阈值没有定义，就不能只填数字。

总分计算为 Σ(权重 × 得分 / 5)。不要在缺项时把剩余权重重新归一化：少交成本和人工交接材料的方案，不应该反而得到更高分。证据不足就写“待补证”，并注明责任人和期限。

假设某候选方案的五项演示得分是 4、3、4、3、4，算术结果为 72 分。若权限测试失败，72 分不产生任何采购通过结论；若门槛都通过，但没有 CRM 回流的证据，仍然应停在补证阶段。

这段程序把上述约束做成一个可运行的最小示例。保存为 acceptance_gate.py，使用 Python 3.9 或更高版本运行，无须安装第三方库。证据字段仅保存引用，不应填入客户原始个人信息：

"""采购评分流程演示。所有输入均为合成，证据内容仍须人工复核。"""
import json
from math import isfinite

GATES = ("identity", "authorization", "truthful_result", "human_handoff")
WEIGHTS = {"task": 35, "handoff_data": 25, "experience": 15,
           "operations": 15, "cost": 10}


def evaluate(gates, scores):
    if set(gates) - set(GATES) or set(scores) - set(WEIGHTS):
        raise ValueError("存在未知项，先修正字段名")
    failed, missing = [], []
    for key in GATES:
        item = gates.get(key, {})
        status = item.get("status", "unknown")
        if status not in ("pass", "fail", "unknown"):
            raise ValueError("门槛状态无效")
        if status == "fail":
            failed.append(key)
        if (status != "pass" or not isinstance(item.get("evidence"), str)
                or not item["evidence"].strip()):
            missing.append("gate:" + key)
    for key in WEIGHTS:
        item = scores.get(key, {})
        value = item.get("value")
        if value is None:
            missing.append("score:" + key)
        elif (type(value) not in (int, float)
              or not isfinite(value) or not 0 <= value <= 5):
            raise ValueError("得分必须为 0—5 的有限数字")
        for field in ("evidence", "rubric"):
            if not isinstance(item.get(field), str) or not item[field].strip():
                missing.append(key + ":" + field)
    if failed:
        return {"decision": "blocked", "failed_gates": failed}
    if missing:
        return {"decision": "needs_evidence", "missing": missing}
    total = sum(WEIGHTS[k] * scores[k]["value"] / 5 for k in WEIGHTS)
    return {"decision": "ready_for_review", "score": round(total, 2)}


def synthetic_fixture():
    gates = {k: {"status": "pass", "evidence": "synthetic/gate/" + k}
             for k in GATES}
    values = (4, 3, 4, 3, 4)
    scores = {k: {"value": v, "evidence": "synthetic/result/" + k,
                  "rubric": "synthetic/rubric/" + k}
              for k, v in zip(WEIGHTS, values)}
    return gates, scores


if __name__ == "__main__":
    gates, scores = synthetic_fixture()
    print(json.dumps(evaluate(gates, scores), ensure_ascii=False))

运行 python3 acceptance_gate.py，合成样例输出：

{"decision": "ready_for_review", "score": 72.0}

把 identity 的状态改成 fail，输出会变为 blocked；删掉 scores 中的 cost 项，输出为 needs_evidence，不再给出总分。ready_for_review 只表示材料字段完整、可以进入人工评审。

程序校验固定的门槛键、权重、0—5 分范围和证据引用；失败、漏项及无效分值都有测试。它只做算术和流程约束，不能识别伪造回执，也不会自动判断证据质量。是否达到实际验收条件，仍由指定评审人对原始记录负责。示例中的 synthetic/ 引用是明确标注的演示占位符，没有对应真实业务证据。实际使用时，要替换为经复核的证据引用和企业确定的评分锚点。

算分前还要看分层结果。如果一种方案在查物流任务表现好，在投诉接续上明显弱，应该先判断能否缩小采购范围，而不是用查物流的高流量把投诉问题平均掉。对金融咨询、投诉或敏感信息项目，权重与硬门槛必须重新设计。

把演示通过改写成可签收的验收条款

“支持修改地址，正确率达到约定目标”仍然不够明确。可以把它改成下面这段需求草案：

在双方确认的订单状态范围、身份校验规则、地址字段定义及负载条件下，系统仅对客户明确确认的新地址发起修改。任务通过需同时满足：授权检查通过、业务系统回执确认、订单中的地址与确认值一致、客户收到与事实一致的通知。执行结果不明时进入待查询或人工处理，不得播报已修改成功。通过率阈值、样本清单、观察窗、异常处理时限、失败责任及重验条件在验收附件中填写并冻结。

这种写法能把“模型说得对”落到“外部系统确实发生了正确变化”，也能暴露企业尚未准备好的条件。注意这里没有替企业编造统一阈值；待填写项不完成，条款就不能签收。

把这些条件写进采购附件时，可以用三张表分别记录：

1. 任务范围与验收表：范围内/范围外、身份与权限、完成条件、样本分层、统计窗口、通过线、失败出口。
2. 供应商举证表：能力是否标准交付、版本与部署条件、企业需提供什么、证据位置、未知项及补证时间。
3. 实施与运营责任表：谁维护知识、谁改接口、谁审核权限、谁接住异常、谁核对回流、谁在版本变化后重验。

这里还有一笔经常漏算的成本：企业自己的工作量。知识库清理、CRM 字段治理、坐席培训、联调排期、上线后的复核，不一定都包含在供应商报价里。选型比较应使用相同的服务范围和业务量假设，并把一次性投入、运行费用和人工接管成本分列。

若要看单位已解决任务成本，分子应包含本次范围内全部任务的成本，包括失败和重试；分母采用同一观察窗口内证实已解决的任务数。解决数为零时，指标不可算，不能显示成零成本。这个值帮助比较交付方案，但不能单独证明投入回报：新渠道增加触达、客户结构变化、人工排班调整，都可能改变成本与结果。

采购会上值得坚持的一个问题

当业务说“想多接住咨询”、技术说“要看链路指标”、采购说“要统一评分”时，先拿一条实际任务追问：这件事怎样才算办完，谁用什么证据签字？

能回答这个问题，识别准确率、延迟、CRM 对接和人工协同就有了位置。回答不了，即使评分表再完整，也很容易把可演示的能力买成尚未定义的责任。

企业下一次与供应商沟通，可以先带去三个高价值任务和各自的完成条件，要求对方逐项标注标准交付、定制依赖及待验证项。先排除授权与事实边界不清的方案，再在同等范围内比较结果、体验、实施工作量和成本。PoC 通过只意味着在该样本与条件下获得了证据，扩展场景、负载或权限后仍需重新验证。

参考资料

1. Google SRE Workbook：Implementing SLOs：参考用户结果导向及“好事件 / 总事件”的指标设计思路，不提供本篇的采购权重或通过线。
2. NIST：AI Risk Management Framework：参考将可信赖性纳入 AI 系统生命周期的风险管理原则；这是自愿使用的框架，不代表本文方案获得认证。

资料核验日期：2026 年 9 月 8 日。本文的采购任务卡、评分权重、算例和代码均为作者提出的参考方法；实际任务政策、阈值及责任分工需由企业按自身业务确认。