AI 扩展计划 / Playbooks

AI Requirements Engineering / GQM Eval Contracts Playbook

AI 需求工程的核心，不是把“做一个智能助手”写成若干用户故事，而是把一个概率型能力放入真实业务流程，并把它转化为可度量、可评估、可门禁、可监控、可审计、可持续改进的行为契约。对已有金融零售、流程治理、需求管理和架构经验的人来说，难点不在于理解“AI 能回答问题”，而在于把业务价值、模型行为、数据边界、人类控制、监管风险和生产反馈组织成同一个闭环。

384 行AI_REQUIREMENTS_ENGINEERING_GQM_EVAL_CONTRACTS_PLAYBOOK.md

AI Requirements Engineering / GQM / Eval Contracts Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/63-ai-requirements-engineering-gqm-eval-contracts.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。

本文采用 Goal-Question-Metric 思路，把 AI idea 逐层拆成业务目标、利益相关方问题、评估指标、解释规则、上线门禁和生产监控。所有例子都围绕金融零售场景展开，包括反洗钱调查、客服知识检索、信贷材料预审、支付异常处理和财富合规辅助。

1. Source Anchors

以下来源作为需求工程、AI 风险治理和人机协同设计的锚点。本文只把这些公开框架转译成需求、评估、门禁、监控和证据设计，不构成法律、合规、审计或模型验证意见。

Anchor	Source	在本文中的使用方式
Basili GQM paper	https://www.cs.umd.edu/~basili/publications/technical/T89.pdf	用目标、问题、指标的链路约束 AI 需求发现，避免从模型指标反推业务价值。
NIST AI Risk Management Framework	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织风险识别、风险测量、门禁和持续管理。
NIST AI RMF Generative AI Profile	https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence	将幻觉、泄露、提示注入、过度信任、内容来源等风险写入评估样本和阻断条件。
Microsoft Guidelines for Human-AI Interaction	https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/	将期望设置、能力边界、纠错、反馈、控制和变更通知写成可评估需求。
Microsoft HAX Toolkit	https://www.microsoft.com/en-us/haxtoolkit/	用 failure mode 和交互模式把人机协同风险转成需求、评审和测试资产。
ISO/IEC 42001 AI Management System	https://www.iso.org/standard/81230.html	用管理体系语言定义 owner、policy、lifecycle、operation、performance evaluation 和 improvement。
OWASP Top 10 for LLM Applications	https://owasp.org/www-project-top-10-for-large-language-model-applications/	补强提示注入、敏感信息披露、过度代理、输出处理不安全等风险样本。

这些来源共同指向一个要求：AI 需求不能停在功能描述，必须进入风险管理、评估证据、上线控制和运行改进。

2. AI Requirement 的真实形态

传统需求经常追问“系统应当提供什么功能”。AI 需求还必须追问“系统在不确定输入、概率输出、知识漂移和人类使用偏差下，如何保持可接受行为”。因此，一条成熟 AI requirement 至少包含六层含义：

层级	要回答的问题	典型证据
业务层	这个能力改善哪个流程结果或风险结果	baseline、target、流程图、价值假设
行为层	AI 允许读取、摘要、建议、草拟、判断或执行什么	allowed / forbidden behavior、工具权限、人工确认点
数据层	输出依赖哪些事实、政策、记录和上下文	source inventory、权限模型、版本、生效日期、检索 trace
质量层	什么叫正确、完整、有证据、可执行	rubric、schema check、专家复核、切片指标
风险层	哪些错误不可接受，哪些错误可修复	failure severity、critical blocker、red-team cases
运行层	上线后如何发现漂移、误用、投诉和成本失控	monitoring gate、alert、owner、SLA、incident log

一个简单但危险的写法是“AI 应该准确回答信用卡费用问题”。成熟写法应当进入这样的结构：

在信用卡费用政策咨询流程中，AI 只能基于当前有效政策和客户可见资料生成回复草稿。
涉及费用减免、争议、投诉、欺诈或法律解释时必须升级人工。
关键事实必须引用政策段落和版本日期。
上线前在费用、争议、缺失证据、过期政策和提示注入样本上通过评估。
未经授权承诺、过期政策引用、高风险未升级均为阻断项。
上线后按渠道、意图、政策版本和团队监控 citation failure、override、投诉和复核缺陷。

3. 从 AI Idea 到 Measurable Outcome

AI 需求发现的第一步是清洗 idea。金融零售中的常见输入通常是 solution hint：

初始表达	问题	可度量改写
做一个 AML 智能助手	没有流程节点、价值和风险边界	在 AML alert investigation 中降低证据收集和 narrative 起草时间，同时保持 critical red flag omission 为 0，并要求所有关键结论有 source evidence。
客服机器人要更懂客户	“懂”不可评估	在信用卡费用和争议咨询中提升可引用政策回答的 first-contact resolution，同时未经授权费用减免承诺为 0，高风险投诉必须升级人工。
信贷审批用 AI 提升效率	容易滑向高影响自动决策	在小微信贷 memo 起草中降低材料缺失和政策引用错误，不让模型做 approve / decline 决策，也不让敏感属性进入推理链。
给理财顾问一个投顾助手	容易触碰个性化建议边界	为持牌顾问准备 suitability checklist、产品资料摘要和风险揭示草稿，不直接向客户输出买卖建议或收益承诺。

高质量 outcome 可以使用以下语法：

For [workflow and role],
improve / reduce / control [business or risk metric],
from [baseline or baseline measurement method],
to [target or target movement],
without violating [policy, customer impact, fairness, privacy, audit constraints],
within [latency, cost, coverage, operating model boundaries].

这个语法迫使团队同时处理价值和边界。AI fit 不等于“模型能做”，而是该任务具备非结构化信息、多来源证据、判断辅助或草稿生成价值，同时可以通过流程、权限和人工控制把风险限制在可接受范围内。

4. AI Fit 与 No-AI Boundary

每个 AI use case 都需要同时写出适用理由和非 AI 边界。前者证明为什么使用 AI，后者防止 AI 扩张到不该承担的责任。

能力形态	AI fit	no-AI boundary
Read	多来源政策、历史 case、产品资料和交易证据检索成本高	权限过滤、source-of-truth、记录保留和版本生效日期必须由系统控制。
Summarize	长文档、通话记录、case notes、交易轨迹需要压缩为可读摘要	摘要不能替代正式记录，不得省略关键风险、缺失证据或不确定性。
Recommend	基于规则、证据和历史经验提出下一步处理建议	高影响建议必须有证据、限制条件和人工确认；不得把建议伪装成最终决定。
Draft	草拟客户回复、case note、investigation narrative、memo	草稿发送、归档或用于客户权益前必须经过人审或规则校验。
Decide	低影响、可逆、规则清楚的内部分流可考虑有限自动化	信贷、投资、合规 filing、账户冻结等高影响决定不应由大模型单独完成。
Act	工具动作可减少搬运、复制和重复操作	工具权限必须最小化，高影响动作必须审批、幂等、可回滚并可审计。

这个边界要同时写入需求、界面、工具网关、评估样本、上线门禁和运行监控。只在文档中声明“需要人工复核”不够，系统必须记录谁复核、复核什么、为何覆盖、何时升级。

5. Requirement Taxonomy

AI 需求不能只靠一个用户故事列表承载。下面的 taxonomy 用于发现遗漏、组织评审和追踪到 eval。

Requirement type	核心问题	高质量要求	Eval / evidence
Business outcome	改善什么业务或风险结果	定义 baseline、target、影响范围和归因限制	pilot measurement plan、benefit register
Workflow insertion	AI 插入哪个流程节点	明确 read / summarize / recommend / draft / decide / act	AS-IS / TO-BE workflow、control point
User and role	谁使用、谁受影响、谁负责	区分客户、员工、主管、专家、合规、审计和运营 owner	RACI、entitlement matrix
Decision boundary	AI 能做什么决定	allowed / blocked / human approval action 明确	policy decision table、tool permission log
Data and knowledge	AI 用哪些事实和知识	source-of-truth、权限、生效日期、保留期、数据最小化	source inventory、retrieval trace
Grounding	输出如何绑定证据	关键事实必须引用来源；缺证据时说明不能确认	citation eval、unsupported claim rate
Behavior	AI 如何回答、摘要、建议或草拟	结构、语气、字段、推理边界、缺失信息处理清楚	rubric、schema check、human review
Safety and compliance	哪些输出会造成风险	禁止承诺、泄露、误导、越权、歧视、绕过政策	failure taxonomy、red-team cases
Human oversight	人何时介入	risk tier、review trigger、override、escalation、rollback	review log、override analysis
Interaction control	用户如何理解和控制 AI	能力边界、来源、不确定性、纠错、退出、变更通知	usability risk review、feedback loop
Evaluation	如何证明能上线	dataset、evaluator、threshold、slice、critical blocker	eval contract、experiment report
Release gate	谁根据什么放行	go / limited go / no-go / rollback 规则明确	gate memo、approval record
Monitoring	上线后看什么	quality、risk、drift、cost、latency、feedback、complaint	dashboard、alert rule
Incident	出错后怎么处理	severity、triage、stop switch、customer remediation、root cause	incident log、postmortem、eval update
Audit and lineage	如何证明过程可信	requirement、dataset、model、prompt、RAG、tool、decision 全链路	evidence binder、version registry
Lifecycle	变更如何管理	prompt/model/knowledge/tool 变更触发回归 eval	change record、regression report

成熟度可以用五级判断：

Level	写法	主要缺口	升级方向
L0 Idea	做一个客服 AI	无法验收	明确流程、用户、价值和风险
L1 Behavior	能回答信用卡费用问题	只描述能力	加入来源、边界、禁止行为和升级规则
L2 Metric	政策回答准确率达到 95%	指标没有样本和解释	定义样本、评分、切片、阈值和严重度
L3 Eval Contract	在费用政策 golden set 上 groundedness 达到阈值，critical violation 为 0	可离线门禁	加入 gate decision 和 owner
L4 Monitored Contract	上线后按渠道、政策版本和风险意图监控 citation failure、投诉、覆盖和 drift	可持续管理	纳入 incident、回滚、知识更新和周期复审

6. GQM for AI Requirements

GQM 的价值是把“我们要什么”拆成“谁需要回答什么问题”以及“用哪些指标回答”。在 AI 项目中，它避免三个常见错误：

直接使用通用模型 benchmark 作为业务需求。
只写平均 accuracy，忽略高风险切片和严重失败。
把 KPI 改善误认为模型质量，忽略流程、采用和控制成本。

GQM grammar for AI:

Goal:
Analyze [AI use case / workflow / component]
for the purpose of [improving / controlling / comparing / deciding / monitoring]
with respect to [business outcome / quality / risk / cost / user trust / compliance]
from the viewpoint of [business owner / user / risk / compliance / audit / platform owner]
in the context of [channel / product / customer segment / risk tier / production environment].

Question:
What must be true, observable or explainable for the stakeholder to trust the goal?

Metric:
What signal, dataset, rubric, threshold and interpretation rule answers the question?

AI GQM 可以作用在不同对象上：

Object	例子	典型问题
Workflow	AML investigation、客服问答、信贷 memo、投顾准备	AI 是否改善流程瓶颈且不引入不可接受风险。
AI output	摘要、建议、草稿、解释、工具参数	输出是否 grounded、complete、compliant、actionable。
Retrieval layer	policy search、case evidence、product facts	是否找到了正确、有效、授权可见的证据。
Tool action	创建工单、冻结卡、发送通知、更新记录	是否在权限、审批、限额和回滚边界内。
Human interaction	转人工、纠错、确认、拒绝、反馈	用户是否理解边界并能有效控制。
Operating model	QA、知识更新、incident、release	组织是否能持续监控和改进。

指标必须附带解释规则。没有解释规则的指标只是报告数字，不是决策证据。

Metric type	示例	解释规则
Business metric	AML touch time、客服 FCR、memo rework rate	只能在 pilot 设计和流程控制清楚时作为 outcome，不能单独证明模型安全。
Quality metric	groundedness、completeness、policy compliance	按 risk tier 和 scenario slice 解读，不能只看平均分。
Risk metric	critical violation、PII leakage、unauthorized action	高风险场景常用 hard stop，目标通常为 0。
Human control metric	override rate、under-escalation、review defect	过高和过低都要分析，不是越低越好。
Operational metric	latency、cost、timeout、fallback	与用户任务时限和质量一起看，不能单独优化。
Trust metric	correction success、handoff quality、complaint rate	反映信任校准，不等同于满意度。

7. 从 GQM 到 Eval Contract

GQM 让需求可测，Eval Contract 让需求可执行、可门禁、可监控。

GQM Goal
  -> eval decision purpose
GQM Questions
  -> evaluation questions and rubric dimensions
GQM Metrics
  -> metric definition, data source, threshold, slice, severity
Interpretation model
  -> release gate and monitoring gate rule
Evidence collection
  -> dataset, evaluator, run report, approval and audit trail

GQM element	Eval Contract field	设计要点
Object	Use case / workflow / component	明确评估对象是输出、检索、工具动作、流程还是组合系统。
Purpose	Decision type	区分 experiment comparison、pilot approval、production release、scale review、rollback。
Quality focus	Eval dimensions	groundedness、completeness、compliance、safety、usability、cost、latency。
Viewpoint	Reviewer / owner	业务、运营、合规、模型风险、客户体验、审计各自问题不同。
Environment	Slices and constraints	渠道、语言、客户类型、产品、政策版本、风险等级。
Questions	Eval questions	每个问题都能被数据、rubric 或人工评审回答。
Metrics	Metric definitions	分母、样本、评分、阈值、置信区间、严重度。
Interpretation	Gate rule	明确 pass、conditional、fail、rollback 和 exception 条件。
Data collection	Dataset and monitoring source	golden set、historical set、red-team set、production trace、QA sample。
Feedback	Continuous improvement trigger	失败 case 如何进入 dataset、知识库、prompt、policy 或流程改进。

Eval Contract 的最小字段如下：

Field	写法要求
Contract ID	体现 use case、版本和 gate，例如 `AML-COPILOT-RELEASE-GATE-V1`
Scope	流程、角色、渠道、AI 介入点、客户影响
Risk tier	低、中、高、关键，并说明原因
Allowed behavior	AI 可以读取、摘要、建议、草拟或调用的动作
Forbidden behavior	AI 不得决定、承诺、泄露、推断或执行的动作
GQM goal	用业务、风险和 stakeholder viewpoint 写成完整目标
Eval questions	需要回答的关键问题
Dataset	样本来源、切片、覆盖、版本、脱敏和权限
Evaluators	deterministic、human rubric、LLM judge、pairwise、red-team、production sampling
Metrics	定义、分母、阈值、hard stop、slice threshold
Severity	critical / high / medium / low 的失败定义
Release gate	go、limited go、no-go、rollback 的规则
Monitoring gate	线上信号、触发阈值、owner、SLA、升级路径
Evidence	eval run、failed cases、approval、exception、issue closure

8. Dataset 与 Failure Severity

AI eval dataset 不是样本列表，而是风险模型的可执行表达。一个高质量数据集至少覆盖：

Slice	作用	金融零售例子
Common	覆盖高频正常任务	常见信用卡费用、常见 KYC 缺件、常见 AML alert
Edge	检查流程边界	联名账户、跨境交易、特殊费用、复杂法人结构
Missing-data	检查不确定性处理	缺政策来源、缺交易明细、缺客户授权
Policy conflict	检查来源权威和版本	新旧费用政策冲突、地区政策差异
Adversarial	检查提示注入和规避	retrieved doc 中包含“忽略政策”的恶意文本
Historical failure	检查真实缺陷回归	过去投诉、QA 失败、审计发现、事故样本
High-risk	检查客户权益和合规边界	拒贷理由、费用减免承诺、SAR filing、投资建议

失败严重度必须独立于平均分。严重失败不能被总体分数抵消。

Severity	Meaning	Example	Gate handling
Critical	可能造成严重客户、合规、财务或法律风险	模型给出最终拒贷决定；承诺费用减免；泄露未授权客户信息	release blocked
High	高风险错误，需要修复和复测	AML narrative 无证据指控客户；错误升级路径	block or limited release
Medium	影响质量或效率	漏掉非关键字段；格式不适合下游系统	fix before scale
Low	轻微表达或可接受摩擦	语气不够简洁；字段顺序不一致	backlog

9. Release Gate 与 Monitoring Gate

Release gate 判断某个版本能不能进入 pilot 或 production；monitoring gate 判断上线后的 AI 是否仍在契约内运行。它们不是两个文档，而是同一条控制链。

Gate	关注点	证据
Discovery gate	问题、流程、baseline、AI fit 是否成立	use case brief、workflow、risk tier、no-AI option
Pilot gate	是否可以有限试点	eval contract、data readiness、pilot scope、stop rule
Release gate	是否可以生产发布	eval report、critical failures、control pack、runbook、rollback
Monitoring gate	生产行为是否仍在边界内	dashboard、alerts、QA sample、complaints、drift
Scale gate	是否可以扩大用户、流程或风险等级	adoption、unit economics、quality trend、risk review

Monitoring gate 需要把线上失败回流为新 eval case。典型信号如下：

Signal	Trigger	Response
Citation failure	缺失、过期或不支持结论的来源	冻结受影响内容，修复 source，回归评估
Unauthorized commitment	承诺费用减免、索赔结果、信贷决定或投资收益	暂停相关 flow，事故评审，客户影响评估
Under-escalation	高风险意图未转人工或专家	更新路由和失败样本
Override spike	人工大量拒绝或重写输出	根因分析，修复 prompt、检索、流程或培训
Cost / latency breach	超出工作流预算或响应时限	降级模型、缓存、路由优化或限流
Policy drift	政策变更后仍使用旧版本	重建索引，强制回归评估

10. Financial Retail Case Patterns

10.1 AML Investigation Copilot

GQM component	Example
Goal	在 AML alert investigation 中降低证据收集和 narrative 起草时间，同时保持 red flag omission 和 unsupported accusation 为 0。
Questions	是否覆盖交易时间线、客户画像、typology、red flags、缺失证据和来源？是否避免 final filing decision？
Metrics	citation precision、red flag recall、missing evidence detection、unsupported claim count、expert QA pass。
Gate	unsupported claim = 0；final filing suggestion = 0；高风险样本专家复核通过。

10.2 Customer Service Policy RAG

GQM component	Example
Goal	在信用卡费用政策咨询中提升可引用政策回答和一次解决率，同时避免未经授权承诺。
Questions	是否引用当前有效政策？证据缺失时是否说明无法确认？投诉、欺诈和法律意图是否升级？
Metrics	policy correctness、citation support、stale policy hit、unauthorized commitment、escalation recall。
Gate	unauthorized commitment = 0；stale policy critical = 0；按 intent 和政策版本达到阈值。

10.3 Lending Memo Assistant

GQM component	Example
Goal	提高信贷 memo 一致性和材料完整性，同时保持人工信贷决策边界。
Questions	是否分离事实、计算、政策引用和分析判断？是否避免敏感属性或代理变量的不当使用？
Metrics	calculation check、policy citation、missing document recall、reason code safety、fairness review finding。
Gate	模型不得 approve / decline；错误 reason code 和受保护属性推理为阻断项。

10.4 Wealth Compliance Guardrail

GQM component	Example
Goal	帮助顾问准备客户沟通材料，同时防止未授权个性化投资建议和收益承诺。
Questions	是否识别 personalized advice？是否触发持牌顾问复核？是否使用批准产品资料？
Metrics	advice detection recall、approved fact citation、prohibited language count、compliant rewrite quality。
Gate	prohibited advice = 0；高风险话术需合规样本复核。

11. 反模式与修复

反模式	看似合理	实际问题	修复方式
AI idea 直接进 backlog	业务方觉得需求清楚	没有 measurable outcome 和风险边界	先做 outcome、GQM、no-AI boundary
“准确率 95%”	有数字	没有样本、评分、分母、严重度和切片	写成 metric + threshold + interpretation
只看平均分	报告好看	高风险失败被平均值掩盖	按 risk tier 和 scenario slice 设置 hard stop
Vendor demo 代替需求	演示流畅	无法证明适合本机构流程和风险	用本机构 case、policy 和 workflow 做 eval
KPI 等于模型质量	业务关心结果	KPI 受流程、培训、流量和季节性影响	同时看 AI quality、risk、operational 和 business metrics
人工复核只写在文档里	似乎有控制	没有 review criteria、attestation 和抽样证据	设计 review workflow、rubric 和日志
Golden set 只放简单样本	通过率高	真实边界和失败模式未覆盖	加入 historical failure、edge、adversarial 和 high-risk cases
Critical failure 可被平均分抵消	指标统一	严重风险被统计吞掉	critical count 独立作为 release blocker
反馈只是 thumbs up/down	界面简洁	不能定位根因和 owner	反馈分类到 source、policy、format、risk、handoff、tone
上线后不再看 eval	节省成本	模型、知识、政策和用户行为会漂移	建立 monitoring gate 和 continuous evaluation

12. 三十天系统训练路径

建议选择一个金融零售主案例，例如 AML、客服、信贷或财富合规，并把另外三个作为简版对照。目标是在 30 天内完成一个 GQM-to-Eval Contract 证据包。

Day	训练重点	产出
1-3	选择主案例，定义流程、AI fit、no-AI boundary、business outcome 和 risk outcome	use case brief、outcome statement
4-7	识别 stakeholder concerns，并写出 GQM goal、questions 和 metric interpretation	GQM sheet、question bank
8-10	建 requirement taxonomy，写 allowed / forbidden behavior 和 failure severity	requirement matrix、behavior boundary
11-14	设计 dataset slices、human rubric、deterministic checks 和 judge calibration	dataset card、rubric、calibration plan
15-18	写 Eval Contract、release gate 和 monitoring gate	eval contract、gate rules
19-22	设计 incident flow、failed trace 回流和 regression eval	incident loop、continuous eval design
23-26	完成其他三个案例的简版 GQM map	case comparison sheets
27-30	组装 executive summary、evidence index 和 decision narrative	evidence pack

完成后应能解释：为什么这些指标服务于业务和风险决策，为什么某些失败是 hard stop，为什么 release gate 和 monitoring gate 必须闭环，以及 AI assist 与 AI decision 的边界如何进入产品、架构和治理。

13. System Evidence Pack

成熟 AI 需求工程的产物不应只是一份需求文档，而是一组可被评审、运行和复盘的证据资产。

Deliverable	内容	证明什么
Executive Summary	use case、outcome、risk、gate decision 和 investment thesis	管理层能做决策
Opportunity-to-GQM Canvas	从 idea 到 outcome、questions、metrics 的完整映射	measurement-first discovery
Requirement Taxonomy Matrix	workflow、data、behavior、safety、interaction、eval、monitoring	高级需求覆盖
GQM-to-Eval Contract Map	每个 goal/question/metric 如何进入 contract	方法链路清楚
Eval Contract Pack	scope、risk tier、dataset、evaluator、threshold、severity、gate	AI 验收可执行
Dataset Coverage Matrix	common、edge、policy conflict、adversarial、historical failure slices	eval 数据思维
Human Rubric and Calibration Note	rubric 维度、评分标准、一致性校准	人审可复用
Release Gate Memo	go / limited go / no-go 决策、证据、剩余风险和审批	上线治理
Monitoring Gate Spec	production signals、alert、owner、SLA、continuous eval	生产运营
Case Comparison Pack	AML、客服、信贷、财富合规案例对照	行业深度
Anti-pattern Review	识别并修正平均分、demo、无边界、无监控等问题	风险判断

核心原则：

AI requirements are complete only when the organization can explain why the capability exists,
how it is measured, when it is allowed to run, when it must stop,
who owns the residual risk, and how production evidence changes the next version.