AI Requirements Mining / Process Knowledge Extraction Playbook

定位: 面向 CBAP+ Senior BA、AI PM、Product Architect、Enterprise Architect、Process Owner、EvalOps、Risk/Control Partner 的金融零售 AI 需求挖掘与流程知识抽取实战手册。 核心目标: 把分散在 PRD、BRD、SOP、政策、工单、Jira/Azure DevOps、通话转写、会议纪要、流程图、代码/API 规格、测试用例、生产日志和控制证据中的知识, 转成可追溯、可评估、可验证、可治理、可复用的 requirement and process knowledge assets。 核心观点: AI requirements mining 不是 BA replacement, 而是 evidence-grade BA operating system。AI 负责扩大证据面、发现冲突和生成候选资产; 人负责解释、取舍、授权、治理和上线责任。

---

0. Disclaimer

本文是学习、作品集、架构训练和内部治理讨论材料, 不构成法律意见、合规结论、监管解释、审计意见、记录保留结论、模型验证报告或供应商建议。正式项目必须由 Legal、Compliance、Privacy、Records Management、Information Security、Model Risk、Operational Risk、Internal Audit、Business Owner、Data Owner、Architecture、Engineering 和相关流程 owner 共同确认。

---

1. Source Anchors

Source-to-artifact pattern:

official source anchor
  -> governance principle
  -> mining requirement
  -> architecture control
  -> evidence artifact
  -> owner and metric

---

2. Executive Framing

高管或业务方常见表达:

我们有很多 PRD、SOP 和 ticket, 能不能让 AI 自动生成需求?
我们想把会议记录和客服通话转成 backlog。
我们能不能让 AI 看代码和测试用例, 反推出系统需求?

高级改写:

Build an evidence-grade requirements and process knowledge extraction capability
that mines candidate needs, rules, events, controls, acceptance criteria and impact links
from governed artifacts,
filters by source authority and permissions,
routes ambiguity to SMEs,
and learns from production feedback without turning AI drafts into approved requirements.

Steering committee questions:

1. 哪些 artifact 是权威来源, 哪些只是 pain signal 或 discussion evidence?
2. AI 输出进入 baseline 前由谁验证、用什么 rubric、保留什么证据?
3. 如何防止越权检索、过期政策引用、PII 泄露和记录处置失控?
4. 如何把 mined requirements 连接到 process、API、data、test、control、eval 和 release?
5. 如何从 production logs、QA、complaints、incidents 和 human overrides 回流到 portfolio learning?

---

3. Use Case Boundary

AI requirements mining 适合的任务:

不适合直接交给 AI 的任务:

---

4. Target Operating Model

Business / Product Owner
  owns outcome, priority, scope, baseline decision

Senior BA / Requirements Architect
  owns mining taxonomy, ambiguity workflow, quality rubric, traceability graph

Process Owner / SME
  validates process activities, exceptions, variants and operating feasibility

Architecture / Engineering
  validates API, data, system, security, performance and integration impact

Risk / Compliance / Control Owner
  validates policy/control linkage, risk tier, approval boundary and evidence need

Privacy / Records / Legal
  validates data use, records class, hold propagation, access and retention controls

QA / EvalOps
  converts mined requirements to tests, eval contracts, thresholds and regression gates

AI Platform / Data Engineering
  operates ingestion, retrieval, permission filter, graph, model versioning and monitoring

RACI snapshot:

---

5. Implementation Architecture

Connectors
  Confluence / SharePoint / Docs / Jira / Azure DevOps / Git / API gateway
  Contact center / CRM / case management / log platform / GRC / test management
        |
        v
Governed ingestion
  artifact id | source type | owner | approval status | version | hash
  effective date | data class | record class | permission tag | legal hold flag
        |
        v
Pre-processing
  parsing | OCR/layout | transcript diarization | code/API parsing | test extraction
  log event mapping | PII redaction | chunking | metadata enrichment
        |
        v
Knowledge layer
  domain vocabulary | process ontology | authority ladder | policy/control map
  requirement graph | event graph | system/API graph | test/eval graph
        |
        v
AI extraction and reasoning services
  candidate requirements | ambiguity | conflict | duplicate | process events
  stakeholder concerns | evidence standards | acceptance criteria | impact links
        |
        v
Human validation workbench
  side-by-side source evidence | approve/reject/merge/split/escalate
  reason codes | SME comments | decision record | audit trail
        |
        v
Delivery and governance
  backlog sync | requirement baseline | eval contract | test generation
  architecture review | control evidence | release gate | learning loop

Architecture non-negotiables:

---

6. Source Intake Checklist

Intake gate:

No artifact enters the mining corpus without owner, version, permission tag and source class.
No restricted source enters AI processing without approved purpose and redaction path.

---

7. Decision Tables

7.1 Should this source be used?

7.2 Can AI output move to backlog?

7.3 What level of human review is required?

7.4 Which intervention is correct?

---

8. Extraction Prompt Contract

AI extraction prompts should be treated as controlled product artifacts. A good extraction contract says what to extract, what not to infer, and how to expose uncertainty.

Required output schema:

{
  "candidate_id": "string",
  "candidate_type": "business_requirement | stakeholder_requirement | solution_requirement | transition_requirement | control_requirement | data_requirement | process_rule | acceptance_criterion | risk_issue",
  "statement": "string",
  "source_refs": [
    {
      "artifact_id": "string",
      "location": "section/page/span/event_id",
      "authority_level": "A1|A2|A3|A4|A5|A6",
      "effective_date": "YYYY-MM-DD"
    }
  ],
  "known_facts": ["string"],
  "unknowns": ["string"],
  "ambiguity_flags": ["actor_unknown", "decision_boundary_unknown", "data_scope_unknown", "control_owner_missing"],
  "conflicts": ["string"],
  "quality_score": 0,
  "recommended_acceptance_criteria": ["string"],
  "validation_owner": "role",
  "risk_tier": "low|medium|high|restricted"
}

Prompt rules:

---

9. Requirement Quality Gate

Gate checklist

Scoring interpretation:

---

10. Traceability Graph Play

Build the graph in layers

Minimum queries

---

11. Process Variant Discovery Play

输入:

case_id, activity, timestamp, resource, lifecycle, channel, product,
risk_tier, amount_band, status, outcome, source_system

步骤:

1. 定义 case 粒度: application、dispute、alert、ticket、complaint、service request。
2. 标准化 activity: 避免把状态码直接当业务活动。
3. 生成 top variants: 找覆盖 80% 体量的主要路径和高风险长尾。
4. 标记 rework、waiting、handoff、skip、loop、override。
5. 与 SOP/BPMN/control path 对齐, 区分 acceptable exception、control gap、data noise。
6. 生成 AI opportunity candidates: summarize、route、draft、validate、retrieve、recommend、tool action。
7. 将每个机会连接到 requirement、acceptance criteria、control 和 eval。

Variant interpretation table:

---

12. Eval Contract for Mining System

The mining system itself must be evaluated before teams rely on it.

Critical failures:

• hallucinated source citation
• unauthorized PII or restricted source in output
• policy/control requirement missed in high-impact workflow
• low-authority source treated as approved baseline
• AI-generated customer commitment
• hidden conflict between source materials
• output enters backlog without validation evidence

---

13. Evidence and Control Checklist

Pre-launch

Production

---

14. 30 / 60 / 90 Roadmap

First 30 days: controlled discovery

Exit criteria:

The team can show source-backed candidates, rejected examples, ambiguity log,
and at least one requirement-to-test-to-control trace for the selected workflow.

Days 31-60: graph, eval and SME workflow

Exit criteria:

The mining system can pass golden-set eval, route ambiguous outputs to SMEs,
and create backlog items only with source refs, quality score and validation evidence.

Days 61-90: production pilot and portfolio learning

Exit criteria:

The organization can demonstrate faster discovery, better traceability,
measurable SME productivity, controlled risk, and reusable portfolio assets.

---

15. Implementation Guardrails

---

16. Metrics

Business and delivery metrics

Risk and quality metrics

---

17. Anti-Patterns and Repairs

---

18. Artifact Templates

18.1 Mining intake brief

workflow:
business owner:
process owner:
primary outcome:
risk tier:
source classes included:
source classes excluded:
permission model:
record classes:
SME reviewers:
quality rubric:
eval dataset:
release decision owner:

18.2 Requirement candidate review card

candidate statement:
source refs:
authority level:
known facts:
unknowns:
ambiguity flags:
conflicts:
risk tier:
quality score:
suggested acceptance criteria:
linked process activity:
linked API/data/test/control:
review decision:
reason code:
owner:

18.3 Change impact memo

changed artifact:
change type:
effective date:
impacted requirements:
impacted workflows:
impacted APIs/data objects:
impacted tests/evals:
impacted controls/records:
required approvals:
release implication:
monitoring update:

---

19. Interview Answers

Q1: 你如何设计 AI requirements mining 的端到端架构?

30 秒回答:

我会从 governed ingestion 开始, 对 PRD、SOP、policy、tickets、transcripts、Jira、code/API、tests、logs 和 controls 做 source inventory、authority classification、permission filtering 和 versioning。然后用 domain vocabulary 和 process ontology 做结构化抽取, 生成 requirement candidate、process event、stakeholder concern、control link、acceptance criteria 和 impact links。所有输出进入 traceability graph, 经 quality rubric、eval contract 和 SME validation 后, 才能进入 backlog 或 baseline。

Q2: 如何证明这不是简单的 RAG 总结?

RAG 总结只回答“这些文档说了什么”。requirements mining 要回答“哪些内容可以成为需求、依据是什么、权威级别如何、哪里冲突、哪里模糊、谁验证、怎么测试、影响哪些系统和控制、上线后怎么监控”。核心资产不是摘要, 而是 source-backed graph、quality score、eval contract、SME decision log 和 change impact evidence。

Q3: 如何避免 AI 自动替代 BA?

我会在流程上把 AI 输出固定为 candidate, 在系统上把 discovery workspace 与 baseline repository 分离, 在治理上要求 source_refs、quality score、SME approval 和 decision record。BA 的价值从写初稿升级为 evidence orchestration、ambiguity resolution、stakeholder negotiation、scope tradeoff、traceability design 和 release evidence governance。

Q4: 从通话转写和会议纪要挖需求时最大的风险是什么?

最大风险是把非权威、含噪声、含 PII 或上下文不完整的语言直接变成需求。转写可能错, 客户表达可能是情绪或投诉, 会议纪要可能不是批准决定。所以这些来源默认只能作为 pain signal、clarification input 或 decision candidate。进入 baseline 需要更高权威来源或 owner 追认。

Q5: 如何处理政策、SOP 和生产日志之间的冲突?

我不会让 AI 平滑合并冲突。政策和控制是约束, SOP 是 intended process, 生产日志是真实行为。冲突本身是高价值发现: 可能是流程绕行、控制缺口、SOP 过期、系统缺陷或政策解释不清。系统要显示 conflict graph, 指派 owner, 形成 decision 或 remediation item。

Q6: 你如何把 mined requirements 连接到 eval?

每个 AI 相关 requirement 必须有 acceptance criteria 和 eval contract。eval contract 定义 dataset、source scope、rubric、threshold、critical failures、slice、evaluator 和 go/no-go 规则。例如对于政策问答类需求, 不是只测准确率, 还要测 groundedness、authority awareness、unsupported claim、permission leakage 和 high-risk ambiguity detection。

Q7: 生产日志在这个 playbook 中扮演什么角色?

生产日志是 process truth 的关键来源。它帮助发现真实 variant、handoff、waiting、rework、override 和 control execution。文档挖掘告诉我们设计意图, 日志挖掘告诉我们真实行为。两者结合才能决定该做 AI assistant、流程重构、数据质量改进、API 集成, 还是控制修复。

Q8: 如何在金融机构控制隐私和 records 风险?

我会实施 permission-before-retrieval, 对 source、chunk、graph edge 和输出层做权限过滤; 对 PII 做 redaction 或 purpose-bound access; 对 raw artifacts、chunks、embeddings、summaries、review notes 和 graph nodes 设计 retention、legal hold propagation 和 audit log。AI 输出不能成为绕过 records 和 privacy controls 的旁路。

Q9: 什么是好的 90 天落地路径?

前 30 天只做一个 workflow 的 controlled discovery, 建 source inventory、authority ladder、vocabulary、golden set 和 extraction rubric。31-60 天建设 traceability graph、SME workbench、eval contract、process variant link 和 backlog integration。61-90 天做 limited production pilot, 加监控、regression eval、incident drill 和 portfolio learning。扩张前必须证明质量、权限和 SME 效率都可控。

Q10: 这个能力如何形成作品集亮点?

我会展示五类资产: source authority model、requirement quality rubric、traceability graph schema、eval contract 和 30/60/90 rollout plan。再用一个金融零售案例说明如何从 SOP、ticket、transcript、API、test 和 log 中提取需求, 如何发现冲突, 如何进入 SME validation, 如何把结果连接到 backlog、eval、control 和 release gate。这比展示“AI 自动写 user story”更能体现 senior PM/BA/Architect 能力。

---

20. Portfolio Deliverables

建议沉淀为作品集包:

Final operating principle:

Mine broadly, trust narrowly, validate explicitly, trace everything,
and let production evidence improve the portfolio.