AI Requirements Engineering / GQM / Eval Contracts Playbook

面向对象: 高级 AI PM / AI BA / Product Architect / Solutions Architect / EvalOps Lead / Model Risk / AI Governance / 金融零售转型负责人。 核心问题: 如何把一个 AI idea 从“想做一个智能助手”升级为 measurable outcome、GQM questions、metrics、eval contract、release gate、monitoring gate 和可审计证据。 使用方式: 每个高价值 AI use case 至少产出一张 GQM-to-Eval Contract Map、一份 Eval Contract、一份 Release Gate Memo 和一份 Monitoring Gate Spec。本文不讲 BA 入门, 重点训练 CBAP 之后的 AI 需求工程升级能力。

---

Source Anchors

以下来源作为需求工程、AI 风险治理和 Human-AI Interaction 的学习锚点。本文把它们转成金融零售 AI 项目的需求、评估、门禁、监控和作品集资产, 不构成法律、合规、审计或模型验证意见。访问日期按 2026-06-29 记录。

Standards-to-artifacts:

---

1. One-Sentence Positioning / 一句话定位

AI Requirements Engineering 的核心不是把业务方的 AI idea 写成 user story, 而是:

AI idea
-> measurable business and risk outcome
-> stakeholder questions
-> metrics and interpretation rules
-> eval contract
-> release gate
-> monitoring gate
-> production learning loop

一句话:

AI Requirements Engineering = 用 GQM 把“想要 AI 能力”转成“组织可以测量、放行、限制、监控、问责和持续改进的 AI 行为契约”。

在金融零售场景里, AI requirement 不是一句“回答准确、安全、有用”。合格的 AI requirement 必须同时回答:

1. 业务结果是否可衡量。
2. AI 在流程中的介入点是否清楚。
3. 哪些行为被允许、禁止、限制和升级。
4. 哪些问题必须被 eval 回答。
5. 指标如何解释为 go / limited go / no-go / rollback。
6. 上线后哪些信号触发人工复核、降级、停用或重新评估。
7. 证据如何支持审计、模型风险、合规和管理层决策。

---

2. 为什么 CBAP 后还需要升级

CBAP 证明你掌握了成熟业务分析能力: stakeholder analysis、requirements lifecycle、strategy analysis、solution evaluation、elicitation、traceability 和 change management。AI 项目不是否定这些能力, 而是要求把它们升级到概率系统、数据依赖、模型漂移、Human-AI Interaction 和风险门禁的层面。

CBAP 后的 AI 需求工程差异化能力:

高级表达:

CBAP 让我能定义业务问题和 stakeholder value；AI 时代的升级是把这些 value 转成可度量、可评估、可门禁、可监控、可审计的行为契约, 并把随机模型的变化纳入需求生命周期。

---

3. 从 AI Idea 到 Measurable Outcome

3.1 不合格的 AI idea

常见输入:

• 做一个 AML 智能助手。
• 客服机器人要更懂客户。
• 信贷审批用 AI 提升效率。
• 给理财顾问一个投顾 copilot。
• 用大模型总结客户画像。

这些不是需求, 只是 solution hint。高级需求工程第一步是把它们改写成业务和风险 outcome。

3.2 Outcome grammar

用下面语法约束 AI outcome:

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

高质量例子:

3.3 AI fit 与 no-AI boundary

每个 idea 都要同时写 AI fit 和 no-AI boundary:

---

4. AI Requirement Taxonomy

AI 需求要分层, 不能把所有东西塞进 user story。下面 taxonomy 用于发现遗漏、组织评审和追踪到 eval。

4.1 Requirement maturity ladder

---

5. GQM for AI Requirements

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

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

5.1 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?

5.2 AI GQM object types

5.3 Metrics interpretation rules

AI 指标必须带解释规则:

---

6. 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

6.1 Mapping table

6.2 Eval Contract 最小字段

6.3 Contract as product boundary

Eval Contract 不只是测试文档, 它同时定义产品边界:

---

7. Eval Contract 示例

下面是成品型示例, 可作为作品集写法。

contract_id: AML-COPILOT-CASE-NARRATIVE-RELEASE-V1
use_case: AML alert investigation copilot for evidence summary and narrative drafting
risk_tier: High, because output influences compliance investigation quality and potential regulatory filing workflow
workflow_insertion_point: Summarize and draft, before analyst review and before SAR decision
allowed_behavior:
  - Summarize transaction patterns from approved case evidence
  - Extract red flags from policy-approved typology checklist
  - Draft case narrative with cited evidence
  - Identify missing information and recommend analyst follow-up
forbidden_behavior:
  - Make final SAR filing decision
  - Invent customer intent or unsupported rationale
  - Suppress red flags because they are inconvenient
  - Use inaccessible customer data or unrelated sensitive attributes
gqm_goal: Evaluate the AML narrative copilot for the purpose of improving analyst investigation efficiency and narrative consistency, with respect to evidence grounding, red-flag coverage and compliance risk, from the viewpoint of AML operations, compliance and model risk, in the context of high-risk retail banking alerts.
eval_questions:
  - Does every material claim cite approved evidence?
  - Are mandatory red flags covered when present in source data?
  - Does the output clearly state missing evidence?
  - Does the output avoid final filing decisions?
  - Does the output preserve analyst control and review accountability?
metrics:
  grounding_score: Human rubric 1-5, release threshold >= 4.5 average and no high-risk unsupported claim
  red_flag_coverage: Mandatory red flags covered / mandatory red flags present, release threshold >= 98%
  critical_violation_count: SAR decision, invented evidence, unauthorized data use, release threshold = 0
  narrative_rework_rate: Analyst major edit rate in pilot, monitored weekly with target downward trend after training period
release_gate:
  go: All critical violations = 0, grounding and coverage thresholds met across high-risk slices, model risk and AML owner approve
  limited_go: Non-critical style or formatting issues exist, pilot limited to analyst-assist mode with 100% review
  no_go: Any critical violation, missing high-risk red flag, or evidence access defect
monitoring_gate:
  daily_sample_review: 5% of generated narratives, stratified by typology and risk level
  alert_trigger: Any critical violation, citation failure cluster, or analyst override spike above control limit
  response: Freeze prompt/model rollout, open risk issue, add failed traces to regression set, rerun gate before re-release
evidence:
  - Dataset card
  - Rubric calibration report
  - Eval run report
  - Failed case log
  - Release approval memo
  - Production monitoring dashboard

---

8. Release Gate 与 Monitoring Gate

8.1 Release gate

Release gate 回答:

这个 AI 版本是否可以进入 pilot / production / scale?

必备输入:

Release gate decision:

8.2 Monitoring gate

Monitoring gate 回答:

上线后的 AI 是否仍然在契约内运行?

监控信号:

Monitoring gate 输出:

• Weekly quality and risk report。
• Failed trace to eval dataset update。
• Owner action log。
• Release freeze / rollback decision。
• Quarterly AI capability review。
• Evidence binder update。

---

9. 金融零售案例

9.1 AML Copilot

Use case: AML analyst assistant for alert investigation, evidence summary and case narrative drafting。

Correct boundary:

• AI 可以聚合交易、客户 KYC、历史 case、typology checklist 和政策证据。
• AI 可以草拟 narrative 和 follow-up questions。
• AI 不做最终 SAR filing decision, 不替代 AML analyst judgment。

GQM map:

Critical failures:

• 编造客户意图或资金来源。
• 遗漏已出现在证据中的关键 red flag。
• 把草稿写成最终 SAR filing decision。
• 引用无权访问或过期政策。
• 因为历史相似 case 而暗示客户有罪。

Monitoring gate:

• 按 typology、风险等级、渠道和 analyst team 分层抽样。
• 监控 analyst major edit rate、citation failure、missing red flag、QA defect、case reopening。
• 任一 critical failure 触发 stop switch、incident review 和 regression set update。

9.2 Customer Service AI

Use case: 客服 RAG assistant for credit card fee, dispute, payment, branch and digital banking questions。

Correct boundary:

• AI 可以回答批准知识库中的政策和流程。
• AI 可以起草客服回复并引用政策来源。
• AI 不承诺未授权 fee waiver、赔付、争议结果、额度提升或投诉结论。

GQM map:

Critical failures:

• 承诺免除费用但无授权。
• 对欺诈交易要求客户继续普通 FAQ。
• 对投诉或脆弱客户没有升级。
• 使用过期政策回答。
• 泄露其他客户或内部操作信息。

Monitoring gate:

• 按 intent、语言、渠道、政策版本、客户脆弱性信号分层。
• 监控 wrong answer complaint、agent override、handoff abandonment、policy update lag。
• 政策变更后必须触发知识刷新和 regression eval。

9.3 Lending Assistant

Use case: 信贷 officer copilot for application summary, missing document checklist, policy citation and credit memo drafting。

Correct boundary:

• AI 可以整理申请材料、指出缺失文件、引用政策、草拟 memo。
• AI 不做最终 approve / decline, 不生成未经验证的 adverse action reason。
• AI 不使用禁止或敏感属性推断信用价值。

GQM map:

Critical failures:

• AI 输出 approve / decline 结论。
• 编造收入、资产、债务或经营情况。
• 使用受保护类别或可疑 proxy 作为理由。
• 错误引用政策导致客户不利结果。
• 未说明材料缺失却让 officer 以为资料完整。

Monitoring gate:

• 按产品、地区、渠道、申请类型、officer team 和 protected-class proxy risk 分层复核。
• 监控 override reason、memo defect、appeal / complaint、policy exception、QA finding。
• 模型或政策变化必须经过 fair lending 和 model risk 复评。

9.4 Wealth / Advisor Copilot

Use case: 财富顾问 assistant for client meeting preparation, product document summary, suitability checklist and compliant communication draft。

Correct boundary:

• AI 可以摘要客户已授权信息、投资目标、风险承受能力和产品资料。
• AI 可以提醒 suitability / appropriateness / disclosure checklist。
• AI 不直接向客户做个性化买卖建议, 不承诺收益, 不绕过持牌顾问责任。

GQM map:

Critical failures:

• 对非持牌或客户可见渠道输出个性化交易建议。
• 承诺收益、淡化损失或隐藏费用。
• 错误总结产品风险或流动性限制。
• 忽略客户风险承受能力、投资期限或限制。
• 用未经授权的客户数据做推荐。

Monitoring gate:

• 按产品风险等级、客户分群、顾问团队、渠道和材料版本分层。
• 监控 advisor override、compliance review defect、customer complaint、disclosure omission。
• 产品资料或监管要求更新后触发 knowledge and prompt regression。

---

10. 模板

10.1 AI Opportunity-to-GQM Canvas

10.2 Requirement Taxonomy Template

10.3 GQM Sheet

10.4 Eval Contract Template

10.5 Release Gate Memo Template

10.6 Monitoring Gate Spec Template

10.7 Evidence Binder Index

---

11. 评审清单

11.1 Discovery and GQM checklist

• 是否先定义 business outcome 和 risk outcome, 而不是先选模型。
• 是否写出 no-AI alternative 和 AI fit 判断。
• 是否明确 workflow insertion point: read / summarize / recommend / draft / decide / act。
• 是否识别客户影响、监管触点、可逆性和人工控制要求。
• 是否每个 stakeholder concern 都转成至少一个 GQM question。
• 是否每个 GQM question 都有 metric、evidence 或 review method。
• 是否定义 baseline measurement method。
• 是否区分 business KPI、AI quality metric、risk metric 和 operational metric。

11.2 Eval Contract checklist

• Contract 是否明确 scope、risk tier、allowed behavior 和 forbidden behavior。
• Dataset 是否覆盖 common、edge、missing-data、policy conflict、adversarial 和 historical failure cases。
• Metrics 是否有分母、阈值、slice、severity 和解释规则。
• Critical failure 是否是 hard stop, 而不是平均分中的一项。
• Human review rubric 是否经过校准。
• LLM-as-judge 是否经过人工抽样校准, 且不作为高风险唯一证据。
• Prompt、model、RAG、tool、policy 版本是否进入 lineage。
• Failed cases 是否有 owner、root cause、fix 和 regression evidence。

11.3 Release gate checklist

• Gate decision 是否有 go / limited go / no-go / rollback / exception 的明确规则。
• 是否列出不在本次 release 范围内的场景。
• 是否完成 architecture、security、privacy、compliance、model risk 和 operations review。
• 是否定义 stop switch、fallback、rollback 和 incident owner。
• 是否说明 residual risk 和补偿控制。
• 是否定义上线后的抽样比例、监控频率和复审节奏。
• 是否有业务 owner 对价值和运营结果负责。
• 是否有 risk owner 对剩余风险接受负责。

11.4 Monitoring gate checklist

• 是否监控质量、风险、成本、延迟、采用、纠错、投诉和 incident。
• 是否按渠道、语言、产品、客户类型、风险等级和版本切片。
• 是否把 production failed trace 回流到 eval dataset。
• 是否区分模型问题、知识问题、流程问题、用户培训问题和控制问题。
• 是否有 alert threshold、owner、SLA 和 response playbook。
• 是否定义模型、prompt、knowledge、policy 或 tool change 的 regression trigger。
• 是否有季度 capability review: continue / refresh / restrict / retire。

---

12. 反模式

---

13. 30 天训练计划

目标: 30 天内完成一个金融零售 AI use case 的 GQM-to-Eval Contract 作品集包。建议选择 AML、客服、信贷或财富/投顾中的一个主案例, 另外三个作为简版对照。

30 天完成标准:

• 能用 GQM 解释为什么这些指标服务于业务和风险决策。
• 能用 Eval Contract 证明 AI requirement 可测试、可门禁、可监控。
• 能用金融零售案例说明边界: AI assist 与 AI decision 的区别。
• 能把 release gate 和 monitoring gate 讲成管理层可决策的证据。

---

14. 面试答案

Q1: 你如何把一个 AI idea 转成可执行需求?

30 秒回答

我不会先写“系统要智能回答”。我会先定义 workflow、业务 outcome、风险 outcome 和 no-AI boundary, 再用 GQM 把 stakeholder concern 转成 questions, 用 metrics 和 eval contract 定义可接受行为、不可接受行为、阈值、release gate 和 monitoring gate。

2 分钟回答

我的步骤是: 第一, 明确 AI 插入流程的哪个点, 是 read、summarize、recommend、draft、decide 还是 act。第二, 定义 business outcome 和 risk outcome, 例如降低 AML case preparation time, 但 critical red flag omission 必须为 0。第三, 用 GQM 从业务、运营、合规、模型风险和用户视角写问题, 比如关键结论是否有证据、是否遗漏高风险信号、是否保留人工责任。第四, 把问题映射成 metrics、dataset、rubric、hard stop 和 release gate。第五, 上线后用 monitoring gate 跟踪 drift、override、complaint、citation failure 和 incident, 把失败 trace 回流到 eval dataset。

Q2: 为什么 GQM 适合 AI 需求工程?

30 秒回答

因为 AI 项目最容易从模型能力和平均指标出发。GQM 强迫团队先回答目标是什么、谁关心什么问题、什么指标能支持决策, 这样可以避免把 benchmark、demo 或泛泛 accuracy 当成需求。

2 分钟回答

GQM 的核心是 Goal、Question、Metric。AI 系统的输出有随机性, 而金融零售又有客户权益、合规和审计要求, 所以需求不能只写功能行为。GQM 能把“客服 AI 更准确”改成“在信用卡费用政策场景中, 从 CX 和合规视角看, 回答是否引用当前有效政策、是否避免未经授权承诺、是否正确升级投诉和欺诈意图”。然后每个问题都有 metric 和解释规则, 最后进入 eval contract 和 release gate。这样指标不是装饰, 而是决策证据。

Q3: Eval Contract 和普通验收标准有什么区别?

30 秒回答

普通验收标准通常验证某个功能是否完成。Eval Contract 定义的是 AI 行为契约: 数据集、评估方法、指标、阈值、失败严重度、release gate、monitoring gate、owner 和证据链。

2 分钟回答

AI 验收不能只看一个示例是否回答正确。Eval Contract 会规定适用范围、风险等级、允许和禁止行为、GQM questions、dataset slices、human rubric、deterministic checks、LLM judge 使用边界、critical failure、go / no-go 规则和线上监控触发。比如信贷 copilot 可以草拟 memo 和缺失材料清单, 但不能做 approve / decline。任何受保护属性推理、错误 reason code 或未经验证政策引用都可能是 critical blocker。上线后还要监控 override、appeal、complaint、QA defect 和政策变更回归。

Q4: Release gate 和 Monitoring gate 如何区分?

30 秒回答

Release gate 判断某个版本能不能进入 pilot 或 production；Monitoring gate 判断上线后的 AI 是否仍然在契约内运行。前者基于离线 eval、红队、人工评审和审批证据, 后者基于生产 trace、用户反馈、质量漂移、风险事件和业务异常。

2 分钟回答

Release gate 是上线前的决策点, 输入包括 use case scope、risk tier、dataset coverage、eval report、critical failures、human oversight 和 rollback plan。Monitoring gate 是上线后的控制机制, 看 citation failure、under-escalation、override spike、complaints、cost、latency、policy change 和 incident。两者必须闭环: 线上失败 trace 进入 regression dataset, 修复后重新跑 release gate。这样 AI requirement 不会在上线时结束, 而是持续管理。

Q5: 你如何处理业务方只说“准确率要高”?

30 秒回答

我会把“准确”拆成具体问题: 哪类任务、哪个角色、什么错误代价、什么样本、谁评分、哪些失败不可接受、上线后如何监控。然后把 accuracy 改成多个 eval dimensions 和 hard stop。

2 分钟回答

在金融零售里, “准确率高”没有分母也没有风险含义。我会问: 是政策事实准确、证据引用准确、摘要完整、风险升级准确、工具动作准确, 还是客户沟通准确? 然后按场景切片设计指标。比如客服 AI 的平均回答分数 95% 仍可能因一个 unauthorized fee waiver commitment 不能上线。对高风险 failure 要设置 independent critical blocker, 对普通质量问题才用平均分或分位数。

Q6: 如何向高管解释 AI requirements 的价值?

30 秒回答

AI requirements 的价值是把创新从 demo 风险变成可管理能力。它让管理层知道 AI 改善什么业务结果, 引入什么风险, 用什么证据放行, 上线后看什么信号, 出事时谁负责和如何回滚。

2 分钟回答

我会用四个问题解释: 第一, 这个 AI 能改善哪个 measurable outcome? 第二, 哪些错误是组织不能接受的? 第三, 当前版本是否有足够证据进入 pilot 或 production? 第四, 上线后如何证明它仍然在边界内运行? GQM 和 Eval Contract 把这些问题变成管理层可读的 gate memo, 包括价值、风险、阈值、例外、控制和 owner。这比只展示模型效果更适合受监管金融环境。

Q7: 如何避免 AI 项目被 vendor demo 带偏?

30 秒回答

我会用本机构 workflow、政策、数据权限、失败模式和 release gate 评估 vendor 能力。demo 只能证明可演示, 不能证明适合我们的流程、风险和监管边界。

2 分钟回答

Vendor demo 往往用干净样本和理想流程。我的做法是先写 AI Opportunity-to-GQM Canvas 和 Eval Contract, 再要求 vendor 在受控样本、政策版本、权限边界和高风险 cases 上证明能力。评估不只看回答质量, 还看数据隔离、source citation、audit log、model update control、human oversight、incident response、cost 和 latency。这样采购讨论从“模型厉害不厉害”变成“能否通过我们的 gate”。

Q8: AI assist 和 AI decision 的边界怎么定义?

30 秒回答

边界取决于客户影响、可逆性、监管要求、证据完整性和人工责任。金融高影响场景通常允许 AI read、summarize、recommend、draft, 但 final decision、客户承诺和高影响工具动作需要人工控制。

2 分钟回答

我会先按流程节点分级: read 和 summarize 风险较低, recommend 和 draft 需要证据和审核, decide 和 act 在金融场景通常高风险。比如信贷里 AI 可以起草 memo、列缺失材料、引用政策, 但不能批准或拒绝贷款。AML 里 AI 可以写 narrative draft, 但不能决定是否 filing。财富场景 AI 可以给顾问准备材料和 checklist, 但不能绕过持牌顾问向客户直接建议买卖。这个边界要写进 requirement、UI、权限、audit log 和 eval contract。

---

15. 作品集交付物

一个有说服力的高级 AI Requirements Engineering 作品集, 不应只是一份 PRD。建议交付一组证据资产:

作品集讲解顺序:

1. 我选择了哪个金融零售 AI use case
2. 为什么这是 AI fit, 不是普通流程优化
3. 我如何用 GQM 定义 stakeholder questions
4. 我如何把 questions 转成 metrics 和 eval contract
5. 我如何设计 release gate 和 monitoring gate
6. 我如何处理 critical failures、human oversight 和 audit evidence
7. 我如何把线上失败回流到 continuous evaluation
8. 这个案例如何证明我具备 AI PM / Architect / AI BA 的高级能力

---

16. 最终记忆卡

最重要的一句话:

高级 AI 需求工程的竞争力, 是能把“AI 看起来能做”变成“组织知道为什么做、怎么测、何时放行、何时停用、谁负责、如何证明”。