# AuditSense 智能审核

> 面向资产评估报告审核场景的行业级 AI 审核系统。目标是把"审核依据"变成一套**确定的、固定的标准化审核流程**，让 AI 扮演一个严格按步骤执行、逐项核对低级错误的"实习生"。

- 产品名称：AuditSense（内部代号 GSDJSense）
- 运行形态：浏览器端工作台（AUI）+ 后端 AI 审核服务
- 适用对象：评估机构、审核复核人员、报告编制人员
- 当前状态：**已部署运行**，按既定审核流程执行报告检查并输出结构化问题清单

## 为什么需要"确定的 AI 审核"

很多人会好奇：既然通用 AI 工具也能检查低级错误，为什么还要专门做一个专用的"低级错误检查"？

要回答这个问题，可以先看看当前的审核环境：审核依据是我们的评估准则。

但同一套准则交到不同学识背景的审核人手里，往往会被各自解读——说有指南，但实际上，依然难以形成统一标准。A 审核人和 B 审核人拿着同一份准则、同一份报告，审核完成后，也可能会得出不一样的审核结果。

问题在于：这件事缺少标准，也就缺少说服力。就像证监局查评估公司时，评估公司很多时候只能"捏着鼻子认了"。大家不争辩，并不是心甘情愿，而是因为行业没有统一标准——公说公有理、婆说婆有理，争辩只会让事情更糟糕。

通用 AI 工具也面临类似情况：把任务和手册交给 AI，AI 可以按手册的流程逐项执行。但通用 AI 工具往往以 skill（技能）驱动任务，带有一定的随意性，更依赖 AI 自己的理解。即使最终能完成任务，也缺少确定性，难以成为标准。

而做行业 AI 审核工具，是希望设计并实施一套"**确定的 AI 审核**"：它应该是固定的审核流程——一套标准化动作，严格按列好的步骤一项一项完成。AI 不需要分析整个流程，只需在关键节点按要求介入并作出判断。

下面这张图对比了"传统人工审核"、"通用 AI 工具"、以及我们追求的"确定的 AI 审核"三条路径的差异：

```mermaid
flowchart LR
    subgraph T[传统人工审核]
        T1["同一套评估准则"] --> T2["审核人各自解读"]
        T2 --> T3["A 与 B 结论不一"]
        T3 --> T4["缺乏统一标准<br/>缺乏说服力"]
    end

    subgraph G[通用 AI 工具]
        G1["任务 + 手册"] --> G2["skill 驱动, 带随意性"]
        G2 --> G3["依赖 AI 自身理解"]
        G3 --> G4["缺少确定性<br/>难以成为标准"]
    end

    subgraph S["确定的 AI 审核"]
        S1["固定审核流程"] --> S2["严格按步骤逐项执行"]
        S2 --> S3["AI 在关键节点<br/>介入并作判断"]
        S3 --> S4["标准化、可复现<br/>可成为行业标准"]
    end
```

## 我们的设计理念：AI 就是那个"实习生"

基于这样的想法，我们可以建立一套标准的审核流程。

理论上，一个刚毕业来实习的人，只要拿到这份工作流程手册，就能逐项检查报告是否存在错误（低级错误）。这不涉及技术，也不需要复杂专业知识；只要智力、逻辑、三观正常、知识储备足够即可。

而我们设计的这个 AI 审核，就是**那个"实习生"**。

这件事很困难，它不只是一个简单工具，甚至有可能成为让行业变得更好的一个起点。公司甚至申请把这件事变成一个行业课题，希望行业能更加重视我们评估师的执业环境。

对比一下人工审核与"确定的 AI 审核"在流程执行层面的差别：

```mermaid
flowchart LR
    subgraph 人工["人工审核（靠经验）"]
        A1["拿到报告"] --> A2["凭个人理解<br/>自由发挥检查"]
        A2 --> A3["结论因人而异<br/>难以复现"]
    end

    subgraph AI["确定的 AI 审核（靠流程手册）"]
        B1["拿到报告"] --> B2["按流程手册<br/>逐项固定步骤检查"]
        B2 --> B3["标准化执行<br/>可复现可追溯"]
    end
```

## 产品形态

AuditSense 由两部分组成：

### 1. AI 审核服务（后端）

承载审核流程执行的引擎。它读取约定的审核流程，把报告内容按步骤交给 AI 逐项核对，并在关键节点采集判断结果，最终汇总为结构化的问题清单（含问题定位、严重程度、修改建议等）。

后端能力包括：

- 按固定流程编排审核步骤，支持**必检项目**与 **Agent 扩展检查**两类检查
- 文档 / 报告内容解析与检索（支持 Word、Excel、PDF 等底稿格式预览）
- 基于知识库与知识图谱的证据定位
- 问题清单的记录、分类与严重度分级（高 / 中 / 低 / 信息四级，历史 critical 归并为 high）
- 对话式智能体，可在审核过程中追问与解释
- 任务调度与并发控制：按项目、数据版本隔离，支持排队、暂停、停止与断点恢复
- 审核表导出：按工作流运行记录导出检查汇总、必检项目、扩展检查、问题明细与最终输出（Excel 可直接打开）

### 2. 前端工作台（AUI）

一个浏览器端的可视化工作区，用于承载审核任务与结果。整体形态类似一个"工作台/编辑器"，主要包含：

- **工作区**：项目、文件与审核任务的浏览、预览与组织
- **对话面板**：与审核 AI 进行提问、追问与解释互动
- **检查清单与审核计划**：执行前可查看本次将执行哪些检查项、固定章节清单与动态范围
- **问题面板**：查看问题清单、定位结果、严重程度与修改建议，可逐条确认
- **知识图谱视图**：查看报告内容与依据之间的关联
- **运行与轨迹面板**：展示审核执行过程、运行状态、任务队列与历史轨迹
- **控制台与状态栏**：后端服务状态、运行状态与登录会话

工作台本身也是审核流程的"操作界面"——审核人员在这里载入报告、发起审核、查看和确认每一项发现，而不是把 AI 当黑盒使用。

整体来看，AuditSense 由"前端工作台"与"AI 审核服务"协同完成一次审核：

```mermaid
flowchart TB
    U["审核人员"] -->|载入报告 / 发起审核| E["前端工作台<br/>（AUI）"]

    E -->|提交审核任务| S["AI 审核服务<br/>（后端）"]
    E -->|读取问题清单 / 结果| R["问题清单<br/>（含定位、严重度、建议）"]

    S --> C["固定审核流程编排"]
    C --> D1["报告解析 / 检索"]
    C --> D2["知识库 / 知识图谱<br/>证据定位"]
    C --> D3["关键节点<br/>AI 介入判断"]

    D1 --> R
    D2 --> R
    D3 --> R

    R -->|确认 / 复核| E
```

## 审核结果与导出

一次工作流运行结束后，结果按以下口径呈现：

- **检查汇总**：执行编号、执行状态、必检数、已检查、未完成、通过、问题、警告、覆盖结论与扩展检查数。
- **必检项目**：按预定检查项逐项核验；未完成项必须补查，不能计为通过。
- **扩展检查**：Agent 在审核过程中主动增加的检查，单独列示，不计入必检覆盖率。
- **问题明细**：按严重程度（高 / 中 / 低 / 信息）筛选，筛选只影响明细展示，不减少检查清单。

审核表可导出为 Excel，桌面 Microsoft Excel 可直接打开。注意"节点运行完成"不等于"检查通过"：未执行、无结论以及旧记录缺少证据的情况都标记为 `!`。

## 运行与恢复

工作流运行记录保存在 Sense 的 MongoDB 中，运行轨迹由 `GSDJAgentTrace` 记录；Desktop 的 SQLite 记录属于另一个宿主，不会自动成为 Sense 的断点。

当前 Mongo 保存逻辑在文档超过 BSON 大小上限时会先移除检查点状态，必要时再移除事件记录。因此任务列表中存在记录或界面出现完成状态，不能单独证明可在重启后恢复完整运行。恢复能力取决于检查点是否完整保存，使用前应验证实际部署的存储与恢复行为。

## 使用前准备

- 使用现代主流浏览器（推荐 Chrome / Edge）
- 已部署并可访问 AuditSense 后端服务
- 已配置管理密码登录（Web 界面与全部 `/api/*` 接口均需登录）
- 具备可用的审核流程配置与知识库数据

## 当前状态与说明

> 本产品**已部署运行**，按固定的审核流程逐项核对报告内容并输出结构化问题清单。审核结论仍需由审核人员复核确认，工具负责把检查过程标准化、可复现、可追溯。

审核流程、检查项与知识库会随行业讨论持续完善。若功能、入口名称或部署方式调整，请同步更新本页内容。

## 支持与反馈

- 帮助页面：/help/#/sense/
- 邮件支持：[jun.yin@live.com](mailto:jun.yin@live.com)