企业评估 AI 项目时，最容易统计的是模型调用次数、Token 消耗和活跃用户数，但这些数字并不直接等于业务价值。Sarah Friar 提出的 AI 记分卡把注意力拉回四个更接近经营结果的维度：完成了多少有用工作、每个成功任务花费多少、系统是否可靠，以及算力投入带来了多少回报。
这套框架的价值不在于制造一个漂亮的总分，而在于让产品、工程和财务团队使用同一组可验证的数据讨论 AI 投资。
从“使用了 AI”转向“完成了工作”
有用工作（useful work）不是生成了多少文本，也不是员工打开了多少次助手，而是 AI 是否推动任务达到可验收状态。例如：
- 客服工单得到正确答复，并通过质量抽检；
- 代码补丁通过测试、审查并合入主分支；
- 发票字段提取结果通过规则校验或人工复核；
- 销售研究报告包含所需字段，且引用可以追溯。
因此，每类任务都需要提前定义“成功”。只记录模型返回 200 OK 会严重高估效果，因为请求成功不代表业务任务成功。
任务价值也不一定相同。处理一封低优先级邮件和发现一笔高风险异常，不能简单地各计一次。可以为任务配置业务权重，或者直接记录经过财务团队认可的价值估算：
# scorecard-policy.yaml
# 以下阈值和金额仅为实践示例，需要按实际业务调整。
task_types:
support_reply:
success_checks:
- answer_grounded
- policy_compliant
- customer_issue_resolved
estimated_value_usd: 8
invoice_extraction:
success_checks:
- schema_valid
- amount_verified
- vendor_verified
estimated_value_usd: 3
code_change:
success_checks:
- tests_passed
- review_approved
- merged
estimated_value_usd: 40
关键是把成功条件放在工作流末端，而不是停在模型输出处。对于有延迟反馈的任务，可以先记录 pending，等客户确认、代码合并或人工复核完成后再更新结果。
四项指标如何落到数据表里
可以把每次任务执行记录为一条事件，至少包含任务类型、是否成功、计算成本、人工复核成本、业务价值和验证结果。基于这些事件计算四项指标：
- 有用工作量：成功且通过验收的任务数，也可以补充加权工作量和价值总额。
- 每个成功任务成本：总执行成本除以成功任务数。总成本应包含模型、基础设施、重试和人工复核，而不只是 API 账单。
- 可靠性（dependability）：在目标任务分布中稳定成功的比例。生产环境还应按任务类型、模型版本和风险等级拆分，避免平均数掩盖局部故障。
- 算力回报（return on compute）：业务价值与计算成本的比率。它能回答每投入一单位模型与基础设施成本，产生了多少可确认价值。
这些指标需要一起看。降低模型成本可能提高算力回报，却也可能降低成功率；加入人工复核会提高可靠性，但可能推高每个成功任务的成本。记分卡的作用正是暴露这种取舍。
一个可运行的最小记分卡
下面是一个仅使用 Python 标准库的示例。假设每条记录已经由下游验证器或人工审核标记为成功或失败，business_value 也是内部认可的估算值。将代码保存为 scorecard.py 后运行 python scorecard.py 即可：
from collections import defaultdict
runs = [
{
"task_type": "support_reply",
"success": True,
"compute_cost": 0.18,
"review_cost": 0.40,
"business_value": 8.00,
},
{
"task_type": "support_reply",
"success": False,
"compute_cost": 0.22,
"review_cost": 0.60,
"business_value": 0.00,
},
{
"task_type": "invoice_extraction",
"success": True,
"compute_cost": 0.05,
"review_cost": 0.10,
"business_value": 3.00,
},
{
"task_type": "code_change",
"success": True,
"compute_cost": 1.40,
"review_cost": 6.00,
"business_value": 40.00,
},
]
def calculate_scorecard(items):
attempts = len(items)
successful = [item for item in items if item["success"]]
useful_work = len(successful)
compute_cost = sum(item["compute_cost"] for item in items)
total_cost = sum(
item["compute_cost"] + item["review_cost"] for item in items
)
realized_value = sum(item["business_value"] for item in successful)
return {
"attempts": attempts,
"useful_work": useful_work,
"dependability": useful_work / attempts if attempts else 0,
"cost_per_success": total_cost / useful_work if useful_work else None,
"return_on_compute": (
realized_value / compute_cost if compute_cost else None
),
}
by_type = defaultdict(list)
for run in runs:
by_type[run["task_type"]].append(run)
for task_type, items in by_type.items():
metrics = calculate_scorecard(items)
print(f"\n{task_type}")
print(f" useful work: {metrics['useful_work']}/{metrics['attempts']}")
print(f" dependability: {metrics['dependability']:.1%}")
print(f" cost per success: ${metrics['cost_per_success']:.2f}")
print(f" return on compute: {metrics['return_on_compute']:.2f}x")
这个示例刻意按任务类型输出结果。若只计算全公司的平均值，高价值且容易完成的任务可能掩盖高风险流程中的低可靠性。
生产版本还应记录模型版本、提示词版本、延迟、重试次数、验证器版本和人工干预原因。这样，当指标变化时，团队才能定位究竟是模型升级、输入分布漂移，还是验收规则发生了变化。
不要急着把四项指标压成一个分数
单一综合分数方便做管理看板，却会隐藏业务约束。对于医疗、金融或权限变更等高风险场景，可靠性通常是硬门槛，不能用更低的成本抵消。对于低风险、批量生成的内部内容，团队则可能接受较低成功率，通过自动重试换取更低成本。
更稳妥的决策方式是设置分层门槛：
- 先确认任务定义清晰，成功结果可以验证；
- 为可靠性和安全性设置不可被成本抵消的最低值；
- 在达到质量门槛后，再优化每个成功任务的成本；
- 用算力回报比较模型、提示词、工作流和人工介入策略；
- 同时展示样本量和置信区间，避免根据少量成功案例扩张项目。
上线前的检查清单
采用这套记分卡时，最重要的不是一次性填满仪表盘，而是建立稳定的测量闭环：任务进入系统，模型执行，业务结果被验证，成本与价值随后回写。
上线前至少确认以下事项：成功条件是否由业务负责人认可；失败和重试的成本是否完整计入；价值估算是否避免重复记账；高风险任务是否单独统计；模型或提示词版本是否可追溯；指标改善是否经过对照实验验证。
当团队能够回答“AI 稳定完成了什么工作、每次成功究竟花了多少钱、算力投入产生了多少价值”时，AI 项目才从使用量展示走向了可经营、可优化的生产系统。