InternalAuditInterprise/0-req-AIAudit.md

0-req-AIAudit · 需求与目标文档

项目：基于本地私有化大模型的电信运营商 AI 全域内审平台（AIAudit） 版本：v0.1（待评审） 日期：2026-06 上游来源：docs/数据不出域，审计全穿透.md

---

1. 引言

1.1 背景

电信运营商年业务规模达 150 亿级，潜在异常金额约 5000 万级，而传统审计依赖人工抽样，覆盖率仅约 5%，存在三类典型困局：

• 拆单规避：大额合同拆分为阈值以下小额合同，规避"三重一大"审批与按金额抽样。
• 时序造假：如"养卡骗补"（脉冲式新增 + 规律性退订）、物联网卡虚假激活等，造假藏在时间序列里，抽样与年度审计难以发现。
• 工具乏力：Excel + 人工方式面对海量单据只能抽样，查不全、查不深。

核心矛盾：审计数据涉及政企合同、用户隐私、财务凭证，上公有云大模型存在合规风险；不引入 AI 又难以应对全量数据。

1.2 目标

建设一套部署在本地机房、数据零出域、覆盖全业务域、可持续进化的 AI 内审能力体系，实现：

• 全量穿透：从抽样审计升级为全量扫描（覆盖率 5% → 100%）。
• 数据不出域：模型—数据—推理—结果全链路内网闭环，数据出域风险归零。
• 常态化监控：从年度快照升级为 7×24 近实时常态化监控。
• 能力沉淀：审计经验固化为可执行规则与机构永久资产，越用越精准。
• 独立可信：审计系统本身独立于被审计业务方，自身全程留痕、分权制衡、可被审计。

1.3 范围说明

本文档按完整蓝图全量编写需求，覆盖数据治理、四大引擎、八大审计场景、人机协同闭环、误报治理、系统自审计、安全合规与价值度量。具体开发优先级与分期（MVP / 二期 / 三期）在后续 PRD（1-prd-AIAudit.md）与任务文档（2-task-AIAudit.md）中确定。

---

2. 术语表

术语	说明
本地私有化 LLM	部署在本地机房、不依赖外网的大语言模型（如千问 70B / DeepSeek），用于推理、规则生成、报告生成、线索解释。
全量穿透	不抽样，对全部业务数据（合同、回款、用户行为等）做关联扫描分析。
风险域	审计场景的归类维度，分为收入域、成本域、采购域、资金域、合规域五大类。
审计场景	具体的造假/风险模式，如政企拆单、养卡骗补、跨期错配等，本平台覆盖八大场景。
线索（Clue）	AI 扫描产出的疑似异常项，附带证据链与判定理由，是审计员处置的起点。
证据链	支撑某条线索成立的关联数据与推理路径（如工商关联、时序聚类、金额分布等）。
审计底稿	由系统自动生成、可追溯的审计工作记录文档。
规则进化引擎	将审计员用自然语言描述的造假模式，自动转化为可执行规则并经沙箱验证、持续迭代的能力模块。
置信度分级	对线索按可信程度分为高/中/低三级，分别对应直接处置/人工复核/归档备查。
误报（假阳性）	AI 判为疑似异常但实际属正常的线索。
审计数据中台（审计数据底座）	审计专用、与业务系统物理隔离、由审计独立掌控的统一数据底座，逻辑上具备数据中台能力（接入、本体建模、时态建模、统一穿透查询），但不与业务方共享。
数据湖	汇聚多源异构业务数据的本地统一存储，是审计数据中台的存储基础。
本体（Ontology）	对审计域核心实体（客户、合同、号码、IMEI、账户、工单、供应商、结算单等）及其关系的形式化定义。
审计知识图谱	依据审计本体，将跨系统实体与关系落地形成的图结构，支撑关联穿透与实控人/关联方识别。
双时态建模	同时记录"业务发生时间"与"系统记录时间"的数据建模方式，支持按任意历史时点回放数据状态。
主数据对齐	客户、合同、号码、工单、供应商等实体在跨系统间的统一识别与关联，是本体层的落地手段。
数据零出域	所有敏感数据、模型与推理过程均不离开本地内网机房。
系统自审计	审计平台自身的操作、规则、模型、数据变更全程留痕且可被审计的机制。
三重一大	重大事项决策、重要干部任免、重大项目安排、大额资金运作的集体决策制度。
BSS/OSS	业务支撑系统 / 运营支撑系统。
IMEI	国际移动设备识别码，用于标识终端设备。
趸交	用户一次性预缴多期费用的缴费方式。

---

3. 角色定义

角色	说明	核心诉求
审计员	一线内审人员，复核线索、研判定性、决定整改或移交、签字。	看得懂线索、查得到证据、处置留得下痕。
审计主管	审计部门负责人，分派任务、审批处置结论、查看全局看板。	全局掌控、成效可量化、流程合规。
规则管理员	配置与维护审计规则、阈值，使用规则进化引擎。	自然语言配规则、沙箱验证、版本可控。
系统管理员	负责数据接入、模型部署、权限分配、系统运维。	接入稳定、权限可控、运行可观测。
系统审计员（独立监督）	审计"审计系统本身"，核查规则/阈值/线索是否被人为放水或拦截。	任何改动可追溯、线索不可被删除掩盖。
被审计业务方	各业务条线（政企、市场、财务、工程等），是审计对象。	（非系统用户）系统须与其解耦，保证独立性。

独立性原则：本平台是独立的内部审计系统，与被审计业务方解耦；业务方无权配置规则、修改阈值或删除线索。

---

4. 功能性需求（EARS 格式）

EARS 关键词：WHEN（事件触发）/ IF…THEN（条件）/ WHILE（状态持续）/ WHERE（特定场景或特性）/ THE…SHALL（系统须）。

需求 1：多源异构数据接入

用户故事： 作为系统管理员，我希望平台能接入各业务系统的数据，以便为全量审计提供统一数据底座。

验收标准

1. WHERE 存在 BSS / OSS / ERP / 财务 / 合同 / 工单 / 信令等数据源，THE 平台 SHALL 提供接口、数据库与文件三类接入适配能力，将数据汇入审计专用数据底座（审计数据中台）。
2. WHEN 配置一个新数据源接入任务时，THE 平台 SHALL 支持配置连接方式、字段映射与同步周期，且无需修改源系统。
3. THE 平台 SHALL 支持全量初始化导入与增量同步两种模式。
4. IF 某数据源接入失败或中断，THEN THE 平台 SHALL 记录失败原因并向系统管理员告警，且不影响其他数据源的接入。
5. THE 平台 SHALL 保证所有接入数据仅存储于本地内网，任何接入过程不向外网传输数据。

需求 2：审计数据中台 · 本体层与主数据对齐

用户故事： 作为系统管理员，我希望平台建设一个由审计独立掌控、按审计本体组织实体与关系的专用数据底座，以便穿透分析时主键能对得上、关系能连得通。

验收标准

1. THE 平台 SHALL 建设审计专用、与业务系统物理隔离的数据底座（审计数据中台），由审计独立掌控，被审计业务方无写入、配置或删除权限。
2. THE 平台 SHALL 依据审计本体（Ontology）定义客户、合同、号码、IMEI、账户、工单、供应商、结算单等核心实体及其关系，形成审计知识图谱。
3. THE 平台 SHALL 对上述核心实体在跨系统间进行统一识别与关联（主数据对齐），并将关系落地到知识图谱，以支撑隐性实控人、关联方网络、"马甲"供应商等穿透分析。
4. WHEN 数据接入数据底座时，THE 平台 SHALL 自动探查缺失、重复、口径不一致问题并执行清洗，且为每个数据源/数据集建立可在管理界面查看的数据质量评分。
5. IF 检测到关键字段缺失或实体无法对齐，THEN THE 平台 SHALL 标记该记录并提示人工干预，而非静默丢弃。
6. THE 平台 SHALL 对外提供统一的穿透查询与图谱查询服务，作为各引擎与审计场景的共同数据入口。
7. THE 平台 SHALL 支持接入真实业务系统数据，同时支持导入脱敏/样例数据用于盲测与演示。

需求 3：审计数据中台 · 时态层与增量同步

用户故事： 作为审计主管，我希望数据底座原生支持时间维度并近实时更新，以便既能识别时序造假，又能把结论回溯到当时的数据状态。

验收标准

1. THE 平台 SHALL 采用双时态建模（业务发生时间 + 系统记录时间）组织原始数据，支持按任意历史时点回放数据状态。
2. THE 平台 SHALL 对关键审计对象（如用户生命周期、回款、话务、佣金发放、资源使用量等）保留时间序列，以支撑时序模式造假识别。
3. THE 平台 SHALL 支持按可配置周期执行增量同步。
4. WHILE 常态化监控处于开启状态，THE 平台 SHALL 持续接收增量数据并触发相应审计规则的重算。
5. THE 平台 SHALL 记录每次同步的时间戳、数据量与数据版本，并保证任一结论可回溯到产生它时的数据版本。

需求 4：本地私有化 LLM 引擎

用户故事： 作为审计员，我希望用自然语言与系统交互，以便不写 SQL、不翻 Excel 就能查数和获取线索。

验收标准

1. THE 平台 SHALL 在本地机房部署私有化大语言模型（如千问 70B / DeepSeek），且模型推理过程不依赖外网。
2. WHEN 审计员以自然语言提交查询时，THE LLM 引擎 SHALL 理解意图并返回结构化结果或线索。
3. THE LLM 引擎 SHALL 支持异常模式推理、自然语言规则配置、报告自动生成与线索解释四类能力。
4. WHERE 涉及电信审计专业领域，THE LLM 引擎 SHALL 基于审计领域语料进行微调以提升专业准确性。
5. THE 平台 SHALL 记录模型版本，使任一结论可回溯到产生它的模型状态。

需求 5：全量穿透引擎

用户故事： 作为审计员，我希望系统对全部业务数据做关联扫描，以便不再受抽样覆盖率限制。

验收标准

1. THE 全量穿透引擎 SHALL 对全部合同、回款、用户行为等数据执行关联扫描，而非抽样。
2. THE 全量穿透引擎 SHALL 直连审计数据中台（数据底座），将数据就地提供给本地 LLM 分析，数据不出域。
3. WHEN 一个审计任务执行时，THE 引擎 SHALL 输出本次扫描的覆盖范围与数据量，以证明全量性。
4. THE 引擎 SHALL 支持跨系统关联分析（如合同—回款—工商—账户的关联穿透）。

需求 6：规则进化引擎

用户故事： 作为规则管理员，我希望用自然语言描述新的造假模式并自动生成可执行规则，以便把审计经验沉淀为机构资产。

验收标准

1. WHEN 规则管理员用自然语言描述一种造假/风险模式时，THE 规则进化引擎 SHALL 自动将其转化为可执行规则。
2. WHEN 一条新规则生成后，THE 引擎 SHALL 在沙箱环境中用历史数据验证其命中率，并在确认前不投入生产。
3. THE 引擎 SHALL 对每条规则保存版本历史，记录创建人、修改人、时间与变更内容。
4. WHILE 系统运行，THE 引擎 SHALL 支持基于审计员反馈对规则进行迭代优化。
5. THE 平台 SHALL 维护一个可持续增长的本地审计规则库，作为机构永久资产。

需求 7：线索驱动引擎

用户故事： 作为审计员，我希望系统主动把高价值线索连同证据链推送给我，以便从"人找数据"转为"数据找人"。

验收标准

1. WHEN 全量穿透或规则命中产生异常聚类时，THE 线索引擎 SHALL 生成线索并附带证据链与"人话"判定理由。
2. THE 线索引擎 SHALL 为每条线索标注所属风险域、审计场景与置信度等级。
3. THE 平台 SHALL 将线索推送至对应审计员的工作台/看板。
4. THE 线索引擎 SHALL 对线索按价值/风险排序，使审计员可优先处理高价值线索。

需求 8：场景一 · 政企收入全链路穿透

用户故事： 作为审计员，我希望识别政企收入中的拆单规避与虚假回款，以便发现规避审批和长期挂账的异常。

验收标准

1. THE 平台 SHALL 沿"立项→审批→报价→签约→开票→回款"链路对政企合同做全链路穿透。
2. IF 多个合同金额集中分布在审批阈值边缘（如阈值以下），THEN THE 平台 SHALL 识别为疑似拆单并生成线索。
3. THE 平台 SHALL 通过工商关联穿透识别隐性实控人（如注册地址、法人亲属、付款账户同源）。
4. WHEN 出现批量回款违约或长期尾款挂账时，THE 平台 SHALL 通过回款时序聚类识别异常并生成线索。
5. THE 平台 SHALL 支持一键生成《政企客户回款异常专项线索清单》。

需求 9：场景二 · 市场业务真实性（养卡骗补）

用户故事： 作为审计员，我希望识别"骗补后弃养"的周期性造假，以便发现脉冲式新增加规律性退订的套补模式。

验收标准

1. THE 平台 SHALL 对用户生命周期进行时序模式识别，识别"脉冲式增长 + 规律性衰减"的周期性造假。
2. WHEN 某渠道新增用户在固定周期后集中退订时，THE 平台 SHALL 识别为疑似养卡骗补并生成线索。
3. THE 平台 SHALL 校验渠道佣金发放与业务质量（如在网时长、通话/流量活跃度）的匹配度。
4. THE 平台 SHALL 对沉默/零通话/零流量用户进行批量聚类筛查（含物联网卡虚假激活）。
5. THE 平台 SHALL 对项目交付物与收入确认进行交叉验证。

需求 10：场景三 · 收入与成本跨期匹配

用户故事： 作为审计员，我希望发现收入确认时点与成本摊销错配的异常分录，以便纠正跨期错配。

验收标准

1. THE 平台 SHALL 自动勾稽收入确认政策、实际账务与合同条款三者的一致性。
2. IF 趸交/预收款被一次性确认收入而对应成本分期摊销，THEN THE 平台 SHALL 识别为确认时点错配并生成线索。
3. THE 平台 SHALL 监控设备交付/上架与收入确认之间的时间差。
4. WHEN 按使用量计费的合同被提前全额确认收入时，THE 平台 SHALL 识别为异常并生成线索。

需求 11：场景四 · 渠道佣金与代理商套利

用户故事： 作为审计员，我希望追踪终端流向与佣金匹配度，以便识别虚假放号、套机套卡与异地窜货套利。

验收标准

1. THE 平台 SHALL 校验终端 IMEI 与用户绑定的真实性。
2. THE 平台 SHALL 校验佣金发放与用户在网时长的匹配度。
3. WHEN 终端出现"激活即沉默/流失"或跨省流通时，THE 平台 SHALL 进行 IMEI 级终端流向追踪并生成线索。
4. THE 平台 SHALL 对代理商进行业务质量时序衰减分析。

需求 12：场景五 · 网络建设与工程采购

用户故事： 作为审计员，我希望识别围标串标、虚增工程量与虚假巡检，以便保障采购合规。

验收标准

1. WHEN 同一项目多家投标报价相似度过高或技术方案文件雷同度过高时，THE 平台 SHALL 进行投标关联分析并生成线索。
2. THE 平台 SHALL 验证工程量与资源消耗的匹配度。
3. THE 平台 SHALL 对巡检 GPS 轨迹与工单记录进行交叉验证，识别照片复用与坐标伪造。
4. THE 平台 SHALL 构建供应商画像并识别同一实控人的"马甲"供应商。

需求 13：场景六 · 互联互通与网间结算

用户故事： 作为审计员，我希望识别话务量操纵与短信刷量，以便保障网间结算真实性。

验收标准

1. WHEN 话务量出现突发峰值或通话时长集中于整数倍时，THE 平台 SHALL 识别为疑似非真人行为并生成线索。
2. THE 平台 SHALL 将网间结算数据与网络侧原始信令进行比对。
3. THE 平台 SHALL 对 SP/CP 业务量与收入结算进行交叉验证（如短信申报量 vs 实际到达率）。
4. THE 平台 SHALL 对国际来话进行真实路由溯源。

需求 14：场景七 · 云业务 / IDC 与新兴业务

用户故事： 作为审计员，我希望识别云资源"空转"确认收入与 IDC 虚租，以便发现资源闲置但确认收入的异常。

验收标准

1. THE 平台 SHALL 比对云资源实际使用量（如 CPU 利用率、存储占用）与合同计费量的匹配度。
2. IF 云资源利用率长期极低但已全额确认收入，THEN THE 平台 SHALL 识别为"空转"并生成线索。
3. THE 平台 SHALL 对 IDC 出租率与电力消耗进行勾稽，识别虚租。
4. THE 平台 SHALL 对新兴业务客户进行关联方识别与预付模式异常分析。
5. THE 平台 SHALL 校验收入确认与交付验收的时序一致性。

需求 15：场景八 · 员工内部舞弊与资源滥用

用户故事： 作为审计员，我希望识别内部号码套利、权限滥用与积分套现，以便保障内控有效性。

验收标准

1. THE 平台 SHALL 对员工权限操作日志进行异常模式识别。
2. WHEN 内部测试号产生大量对外流量收入却计入内部成本时，THE 平台 SHALL 识别为用途偏离并生成线索。
3. THE 平台 SHALL 追踪积分/电子券流向，识别异常刷积分与套现（如单日发放量异常）。
4. THE 平台 SHALL 分析权限与岗位的匹配度，识别越权（如客服岗拥有财务调账权限）。

需求 16：审计域全景与风险分级

用户故事： 作为审计主管，我希望按风险域和热力图查看全局，以便明确监控优先级。

验收标准

1. THE 平台 SHALL 将所有审计场景归入收入域、成本域、采购域、资金域、合规域五大风险域。
2. THE 平台 SHALL 提供风险热力图，以"发生概率 × 金额影响"两维度呈现各场景优先级。
3. WHERE 场景为高概率高金额，THE 平台 SHALL 支持将其配置为全量持续监控。
4. THE 平台 SHALL 支持按风险域、场景、地市/单位等维度筛选与下钻查看线索。

需求 17：人机协同闭环（线索到销项）

用户故事： 作为审计员，我希望从线索到整改销项全流程在线，以便每一步都接得住、留得痕。

验收标准

1. WHEN 一条线索被生成时，THE 平台 SHALL 支持将其分派给指定审计员。
2. THE 平台 SHALL 支持审计员对线索进行复核研判、定性分类，并决定整改或移交。
3. WHEN 审计员完成研判时，THE 平台 SHALL 自动生成可追溯的审计底稿。
4. THE 平台 SHALL 对取证、整改跟踪、销项复核全过程留痕，形成处置闭环。
5. THE 平台 SHALL 跟踪每条线索的状态（待研判/研判中/整改中/已销项/已移交等）。

需求 18：误报治理与置信度分级

用户故事： 作为审计员，我希望线索按置信度分流并可解释，以便不被海量假阳性淹没。

验收标准

1. THE 平台 SHALL 将线索按高/中/低三级置信度分流：高置信直接推送处置、中置信人工复核、低置信归档备查。
2. THE 平台 SHALL 为每条线索提供证据链与判定理由，不得仅给出无法解释的"黑盒打分"。
3. WHEN 审计员标注线索为"误报"或"属实"时，THE 平台 SHALL 记录反馈并据此持续校准阈值与模型。
4. THE 平台 SHALL 在运营看板上公开命中率、准确率、线索转化率等指标。

需求 19：独立性与系统自审计

用户故事： 作为系统审计员，我希望审计系统本身经得起审计，以便防止放水与拦截。

验收标准

1. THE 平台 SHALL 对规则配置、阈值调整全程留痕，任何改动可追溯到操作人、时间与变更内容。
2. IF 任何用户尝试删除已生成的线索，THEN THE 平台 SHALL 拒绝删除，并将线索及其处置过程完整保留。
3. THE 平台 SHALL 对"配规则、看线索、改阈值、出报告"等关键操作进行分权管理，使其相互制衡。
4. THE 平台 SHALL 对模型版本、规则版本、数据版本进行三重留痕，使任一结论可回溯到当时的模型与数据状态。
5. THE 平台 SHALL 保证被审计业务方无权配置规则、修改阈值或删除/拦截线索。

需求 20：应用层与自然语言交互

用户故事： 作为审计员，我希望零门槛使用平台，以便专注研判而非操作工具。

验收标准

1. THE 平台 SHALL 提供自然语言查询、线索看板、智能报告、预警推送四类应用入口。
2. WHEN 审计员发起自然语言查询时，THE 平台 SHALL 返回结果且无需用户编写 SQL。
3. THE 平台 SHALL 支持一键生成结构化审计报告与专项线索清单。
4. WHEN 触发高置信预警时，THE 平台 SHALL 主动向相关审计员推送通知。

需求 21：成效度量与价值测算

用户故事： 作为审计主管，我希望量化平台成效，以便向上汇报价值并指导优化。

验收标准

1. THE 平台 SHALL 统计可挽回收入/止损金额、线索数量、线索转化率等成效指标。
2. THE 平台 SHALL 支持历史数据全量重跑，并与既有审计结论进行同台盲测对比。
3. WHEN 盲测完成时，THE 平台 SHALL 输出成效报告，呈现此前抽样漏掉而本平台发现的线索。

---

5. 非功能性需求

5.1 安全与合规（最高优先级）

1. THE 平台 SHALL 保证模型、数据、推理、结果全链路在本地内网闭环，敏感数据一比特不出机房。
2. THE 平台 SHALL 满足国资/运营商/等保的合规要求，提供权限分级与不可篡改的操作日志。
3. THE 平台 SHALL 对所有用户操作生成不可篡改的审计轨迹（含操作人、时间、对象、动作）。
4. THE 平台 SHALL 对敏感数据（政企合同、用户隐私、财务凭证）进行访问控制与脱敏管理。

5.2 性能与时效

1. THE 平台 SHALL 支撑 70B 级大模型在本地 GPU 集群（A100 / H100 / 国产 GPU）上的推理。
2. WHEN 审计员发起常规自然语言查询时，THE 平台 SHALL 在可接受响应时延内返回结果（目标：秒级，复杂全量任务可异步）。
3. THE 平台 SHALL 支持 150 亿级业务规模的全量数据扫描，长耗时任务以异步任务方式执行并反馈进度。

5.3 可用性与易用性

1. THE 平台 SHALL 面向审计人员提供零门槛（无需写 SQL/不翻 Excel）的交互方式。
2. THE 平台 SHALL 支持 7×24 常态化运行与监控。

5.4 可扩展性

1. THE 平台 SHALL 支持新增数据源、新增审计场景与新增规则而无需重构核心架构。
2. THE 平台 SHALL 支持模型替换/升级（如更换或升级本地 LLM）。

5.5 可追溯性与可解释性

1. THE 平台 SHALL 保证任一线索/结论可回溯到产生它的模型版本、规则版本与数据版本。
2. THE 平台 SHALL 保证每条线索均附带可读的证据链与判定理由。

5.6 信创适配

1. THE 平台 SHALL 可适配国产 GPU 与信创软硬件环境。

---

6. 关键约束与假设

6.1 约束

• 数据零出域：所有数据处理、模型推理必须在本地内网完成，禁止任何敏感数据外传（红线约束）。
• 独立性：本平台为独立内部审计系统，与被审计业务方解耦，业务方不得配置规则、改阈值或删除线索。
• 数据底座物理隔离：审计数据中台为审计专用、与业务系统物理隔离，由审计独立掌控；不做成与业务方共享的全行级中台，以规避独立性风险。
• 本地算力依赖：依赖本地 GPU 集群承载 70B 级模型推理。
• 数据接入依赖：全量审计能力依赖 BSS/OSS/ERP/财务/合同/工单/信令等系统的数据可接入与数据质量。
• 数据治理前置：数据接入与治理是工作量最大、需提前立项的一环，是全量穿透的前提。

6.2 假设

• 本地机房具备部署 70B 级模型所需的 GPU 算力与存储资源（或在项目内规划到位）。
• 各业务系统可提供数据接口/数据库访问/文件导出之一作为接入方式。
• 存在过去 2–3 年的历史审计数据与结论，可用于场景微调与同台盲测。
• 初期可使用脱敏/样例数据进行开发、演示与盲测验证，再逐步对接真实生产数据。

6.3 范围边界（本期需求暂不展开，留待 PRD/分期确定）

• 具体的开发优先级与分期（MVP / 二期 / 三期）。
• 具体技术栈选型（后端框架、前端框架、数据库、向量库、推理框架等）。
• 具体的模型选型与微调方案细节。
• 与各业务系统对接的具体接口规格。

---

7. 需求清单索引

编号	需求名称	风险域/分类
R1	多源异构数据接入	数据中台
R2	审计数据中台·本体层与主数据对齐	数据中台
R3	审计数据中台·时态层与增量同步	数据中台
R4	本地私有化 LLM 引擎	核心引擎
R5	全量穿透引擎	核心引擎
R6	规则进化引擎	核心引擎
R7	线索驱动引擎	核心引擎
R8	场景一·政企收入全链路穿透	收入域
R9	场景二·市场业务真实性（养卡骗补）	成本域
R10	场景三·收入与成本跨期匹配	收入域
R11	场景四·渠道佣金与代理商套利	成本域
R12	场景五·网络建设与工程采购	采购域
R13	场景六·互联互通与网间结算	资金域
R14	场景七·云业务/IDC与新兴业务	收入域
R15	场景八·员工内部舞弊与资源滥用	合规域
R16	审计域全景与风险分级	全局
R17	人机协同闭环（线索到销项）	闭环
R18	误报治理与置信度分级	闭环
R19	独立性与系统自审计	合规/制度
R20	应用层与自然语言交互	应用层
R21	成效度量与价值测算	价值

---

请检查确认本需求文档。 确认通过后，我将进入下一阶段，基于本文档生成产品需求文档 1-prd-AIAudit.md（含产品定位、成功指标、用户画像与场景、MoSCoW 功能优先级、关键流程、权限矩阵、版本规划、风险等）。如需修改，请直接告诉我要调整的部分。