AI+BI 经营驾驶舱与成品 BI 的核心区别是什么？
直接答案：成品 BI 通常提供既定的数据建模、分析和权限能力；AI+BI 定制项目还要把客户现有指标语义、数据接口、角色权限、答案证据、界面流程、部署环境和交付物组合起来。两种路线没有统一优先级，应按现有系统和验收责任选择。
Article
AI+BI经营驾驶舱定制开发与成品BI有什么区别
直接答案：AI+BI经营驾驶舱不能只验收答案是否流畅，还要核对问题是否在授权范围、指标口径与查询依据能否追溯、越权请求是否拒绝、关键行为是否留痕。最终应使用真实角色账号、已确认的数据和预先整理的问题集测试；模型、数据库和界面只是证据链的一部分。
成品软件提供相对固定的功能与配置边界；定制开发的价值，是让数据接入、指标语义、权限、界面、流程、部署和交付物适配客户现状。项目可以复用合适的第三方组件，但不能让某个产品的默认能力反过来定义客户需求。
AI+BI定制开发和成品BI软件有什么区别
成品BI更适合需求相对标准、数据源在产品支持范围内、组织权限可以直接映射、页面和分析方式接受产品既有边界的场景。它的优势通常是功能成熟、配置路径清楚、常用能力可以较快启用，但项目需要接受其连接器、权限模型、界面组件、许可和升级方式。
定制开发更适合已经存在多个业务系统、指标口径跨系统、权限需要继承企业现有组织体系、部署网络受限，或者需要把问数结果继续接入工单、审批、预警和经营驾驶舱的场景。定制的重点不是重写所有基础能力，而是根据接口、数据、权限和业务流程决定复用、适配与开发边界。
| 比较维度 | 成品BI软件 | AI+BI定制开发 |
|---|---|---|
| 建设起点 | 从产品已有模块和配置方式选择可用能力。 | 从客户的管理问题、使用角色、现有系统和验收目标倒推方案。 |
| 数据接入 | 优先使用产品支持的数据库、文件和标准连接器。 | 可根据现有数据库、API、消息、文件交换和专用接口设计适配链路。 |
| 指标与语义 | 在产品的数据模型和指标模块内配置。 | 继承并梳理客户已有口径、历史版本、组织范围、同义词和跨系统血缘。 |
| 身份与权限 | 使用产品内置角色、目录和数据权限能力。 | 根据客户现有统一身份、组织树、账号制度和数据分级映射到页面、接口、行、列、导出与分享。 |
| 部署环境 | 采用产品支持的部署拓扑、版本和依赖。 | 结合内网、私有云、隔离区、国产化环境、网关和运维制度确定部署与集成方式。 |
| 界面与业务流程 | 以产品提供的看板、组件和交互为主。 | 可按岗位任务设计驾驶舱、问数、下钻、预警、工单或审批衔接，但业务动作仍需单独授权。 |
| 交付与验收 | 重点核对许可、安装、配置和产品功能是否可用。 | 按合同边界核对接口、配置、代码或资产、部署文档、权限矩阵、测试用例和真实业务结果。 |
本站所说的定制交付，不预设必须采用或排除某一种BI、数据库或模型服务。项目应先判断现有平台哪些能力可以保留，再把产品无法覆盖的接口适配、指标语义、权限一致性、业务流程和验收证据补齐，避免为了“定制”重复建设，也避免为了迁就产品而改变真实需求。
AI+BI与现有看板如何配合
经营驾驶舱适合持续展示已经确定的核心指标、目标进度、趋势和风险。它的优势是稳定、直观，管理者不需要每次重新提问，就能在固定位置看到同一套经营信息。
智能问数更适合处理看板没有预先配置的临时问题。例如，管理者看到本月毛利率下降后，可以继续追问主要影响区域、产品、客户或订单；系统根据当前权限和数据范围生成查询，再把结果与统计口径一起返回。
因此，AI+BI经营驾驶舱更合理的组合是“固定看板负责持续监控，智能问数负责临时查询和辅助分析”。如果固定指标本身仍有争议，或者数据只能靠多人临时汇总，先治理数据通常比先接入大模型更重要。
| 使用需求 | 更适合的能力 | 原因 |
|---|---|---|
| 每天查看固定经营指标 | 经营驾驶舱或BI看板 | 信息位置稳定，便于持续比较目标、趋势和异常。 |
| 临时查询某个区域、客户或产品 | 智能问数 | 允许使用自然语言组合时间、指标和分析维度。 |
| 解释指标变化并继续追问 | 智能问数与分析模型 | 可以在权限范围内逐步缩小问题，但结论仍需核对数据依据。 |
| 审批、调价、付款或自动执行 | 业务系统与人工确认 | 涉及真实业务动作时，应使用明确流程、权限和审计机制。 |
第一步：先整理真实问题集，不要先选模型
AI+BI项目最容易出现的偏差，是先讨论模型、知识库和对话界面，最后才寻找业务场景。实施时可先收集管理层和业务岗位真实会问的问题，再判断这些问题是否能由现有数据回答。
问题集不能只有“本月销售额是多少”这类单轮查数，还应包含追问、歧义、越权和无答案场景。每个核心角色都可以准备下面五类问题：
| 问题类型 | 示例 | 期望行为 |
|---|---|---|
| 常用查数 | 本月各区域销售额和目标完成率是多少？ | 返回指标、时间范围、区域维度、更新时间和来源。 |
| 连续追问 | 其中下降最多的是哪个区域？主要来自哪些产品？ | 保留上一轮条件，并清楚展示新增筛选条件。 |
| 歧义问题 | 最近利润怎么样？ | 先确认利润口径、时间范围和组织范围，不直接猜测。 |
| 越权问题 | 查看其他区域的客户明细和回款记录。 | 按照用户权限拒绝或只返回允许查看的汇总结果。 |
| 无数据问题 | 预测下季度某个尚未记录的新业务收入。 | 说明缺少数据或模型依据，不编造预测值。 |
问题集还要记录提问人、使用场景、所需指标、数据来源、预期答案形式和最终核对人。这样它既是需求清单，也是后续测试和验收的基础。
第二步：把指标口径整理成机器和业务都能理解的语义
自然语言问题里常有简称、同义词和模糊表达。例如，“收入”可能指含税合同额、确认收入、开票金额或到账金额；“最近”可能指本周、近30天或当前季度。系统如果没有统一语义，就可能生成看似合理、实际口径错误的答案。
每个核心指标至少要整理名称、别名、业务定义、计算公式、统计周期、可分析维度、数据来源、更新时间、负责人和权限范围。已有指标可以先用 经营驾驶舱指标口径表 统一，再补充智能问数需要识别的同义词、常见问法和不允许混用的概念。
指标治理还要记录版本、生效时间、审核状态和变更原因。公式、来源表、组织范围或空值规则发生变化时，应保留旧版本的适用区间，并重新验证受影响的固定看板、问数问题和对外报表，避免同名指标在不同页面悄悄使用不同口径。
数据血缘用于回答“这个答案从哪里来、经过哪些转换、还影响哪些页面”。项目中可记录上游系统、表和字段，必要的数据清洗或聚合规则，以及下游驾驶舱、报表和智能问数入口。血缘记录不必一开始覆盖所有数据，但核心指标应能追溯到可复核的来源。
进入联调和上线验收时，可使用指标口径与数据血缘验收矩阵继续记录口径版本、生效时间、审批状态、上下游血缘、引用看板、权限等级和验收证据，避免指标初稿与生产版本脱节。
当一个问题存在多个合理口径时，系统应要求用户确认。例如，“销售额下降原因”至少要先确认使用订单、开票还是收入确认口径，以及比较的是同比、环比还是目标差异。
Text-to-SQL能力要围绕语义层和数据字典验收，生成SQL只是其中一项。项目中应把业务名词、字段名、表关系、枚举值、口径说明、可用维度和禁止组合写清楚，让系统知道哪些查询可以执行，哪些查询需要澄清，哪些查询因为权限或口径原因必须拒绝。
| 语义层对象 | 需要写清的内容 | 验收时怎么核对 |
|---|---|---|
| 指标 | 名称、别名、公式、统计周期、空值处理和负责人。 | 同一问题与标准报表或已确认SQL逐项对比。 |
| 指标版本 | 版本号、生效时间、审核状态、变更原因和替代关系。 | 按测试日期使用对应版本，并回归受影响的问题与报表。 |
| 维度 | 组织、区域、客户、项目、产品、时间等可分析维度。 | 检查下钻、汇总和筛选是否仍按授权范围返回。 |
| 同义词 | 业务简称、常见问法、容易混淆的概念和禁用映射。 | 用同义问法、歧义问法和错误别名验证澄清与映射。 |
| 字段与表关系 | 数据字典、主外键、枚举值、更新频率和数据质量备注。 | 保留生成SQL或查询计划，确认没有错连表、漏条件。 |
| 数据血缘 | 上游系统、表、字段、转换规则及下游报表和问数入口。 | 从答案追溯到来源，并核对变更后的下游影响范围。 |
| 禁止组合 | 不允许跨组织、跨租户、跨敏感字段或混用口径的查询。 | 用反向问题测试系统是否澄清或拒答。 |
第三步：只让AI访问经过授权的数据范围
正式环境不宜把高权限生产数据库账号直接交给模型。模型负责理解问题，不代表它应当拥有绕过业务权限查询全部数据的能力。查询请求建议通过受控语义模型、只读数据服务或查询层执行；如果通过 MCP 或其他工具协议接入，也要把可发现、可调用和可返回的能力限制在当前角色获准范围内。
问数权限验收的核心，是同一个用户通过固定看板、自然语言提问、明细下钻、导出和多轮追问时，只能访问同一授权边界内的数据；不能依靠回答生成后再删除敏感文字来补救。
| 控制位置 | 需要确认的内容 |
|---|---|
| 账号与身份 | 提问人是谁，属于哪个组织和角色，当前会话是否有效。 |
| 数据权限 | 允许查看哪些区域、部门、客户、项目、指标和明细层级。 |
| 查询限制 | 只读访问、允许的数据集、查询超时、结果行数、并发和频率限制。 |
| 敏感信息 | 个人信息、联系方式、财务明细、客户资料是否需要脱敏或禁止返回。 |
| 导出与分享 | 答案、图表和明细能否导出，分享后是否继续受权限控制。 |
| 审计记录 | 记录提问人、问题、解析条件、访问数据、结果状态和人工纠正。 |
权限应当在查询执行前生效，不能只依靠回答阶段删除敏感文字。涉及经营、财务、客户或人员数据时，还应检查固定大屏、办公电脑、移动端和导出文件的展示边界是否一致。可结合 数据大屏权限、安全与审计清单 一起核对。
权限继承要落到主题、行、列和操作
用户能够打开智能问数入口，不等于可以询问全部数据。建议先从企业现有身份和组织体系继承角色，再依次限制可用工作空间或分析主题、可访问数据集、行级组织范围、列级敏感字段以及导出和分享操作。新增主题、数据源或角色时保持默认不开放，经授权后再进入问数范围。
定制项目不预设某一种产品的权限模型。实施时应先盘点客户现有统一身份、AD、LDAP、单点登录、组织树、账号生命周期和数据分级制度，再决定直接继承、通过接口同步、使用受控数据视图，还是增加独立权限适配层。无论采用哪种方式，最终都要用真实角色账号验证页面、接口、明细、导出和分享的一致边界。
MCP或工具接入先拆分只读查询与业务动作
MCP可以规范工具的发现与调用，但不会自动把数据库、API或业务系统变成只读。项目应为查数单独暴露查询工具，使用受限服务账号、只读视图或只读接口，并在服务端校验身份、工具权限、参数、数据范围和结果；修改、删除、付款、审批、通知等动作不应混入普通问数工具。
| 控制层 | 最低要求 | 验收证据 |
|---|---|---|
| 工具目录 | 当前角色只发现获准工具；查询与写操作分开，新增工具默认不开放。 | 不同角色的工具清单、权限配置与版本记录。 |
| 身份与授权 | 令牌或会话绑定目标服务、用户、角色和最小范围，不把上游高权限凭据直接传给下游。 | 授权范围、服务端校验日志、失效账号与撤权回归记录。 |
| 只读执行 | 服务账号、数据库视图、API方法和工具实现均不具备写权限；限制数据集、行数、超时、并发和频率。 | 数据库或接口权限截图、写入反向测试、超时与限流结果。 |
| 输入与输出 | 校验工具参数，过滤未授权字段，对敏感结果脱敏，并防止错误信息泄露结构或凭据。 | 越权参数、同义改写、敏感字段、异常返回和导出测试。 |
| 查询审计 | 用同一交互编号关联提问、工具调用、权限判定、查询与答案证据。 | 工具名、参数摘要、数据版本、结果范围、拒绝原因和人工复核记录。 |
| 高风险动作 | 必须另行授权、展示待执行内容、要求人工确认并提供撤销或补救路径。 | 确认界面、操作记录、拒绝用例和回退结果。 |
部署和集成方式要从现有环境倒推
同样的问数功能，在互联网环境、企业内网、私有云、隔离网络或国产化软硬件环境中，模型调用、数据库连接、身份认证、日志归集和运维方式可能完全不同。定制方案应先确认网络区划、可用接口、并发与时效、依赖组件、备份恢复和升级责任，再确定本地模型、受控外部模型、已有BI嵌入或独立问数服务的组合，不能把某个产品的默认部署路径直接当成客户方案。
字段脱敏要在查询与结果两侧验证
| 字段类型 | 建议处理 | 反向测试 |
|---|---|---|
| 直接标识信息 | 无业务必要时不进入问数数据集；确需使用时按角色隐藏、部分掩码或只返回汇总。 | 使用同义词、详情追问和导出功能，确认不能绕过列权限获得原值。 |
| 财务与经营明细 | 按组织、项目、客户或数据等级限制行范围和明细层级。 | 修改区域名称、客户名称、时间条件和排序方式，确认结果始终受同一范围约束。 |
| 模型提示与系统字段 | 令牌、连接串、内部提示、系统表和审计字段不进入可问数据范围。 | 直接询问系统配置、表结构或凭据，确认系统拒绝并留下权限判定记录。 |
| 可公开汇总指标 | 明确汇总粒度、最小返回范围和小样本处理规则。 | 连续下钻到更细组织或个人层级，确认触及边界时澄清或拒绝。 |
提问范围要区分可回答、需澄清和应拒绝
可回答问题应同时满足“有授权数据、有确定口径、有可执行查询”三个条件；时间、组织、指标或比较方式不明确时先澄清；涉及未授权明细、敏感字段、系统配置或没有数据依据的结论时明确拒绝。创建工单、发送通知、调价或审批等动作不属于普通问数，应进入单独的业务流程和人工确认。
越权测试要覆盖改写、多轮、导出和权限变更
- 为管理员、部门负责人、普通成员和固定展示账号准备相同问题，对比返回范围。
- 把同一越权问题改写成简称、同义词、否定问法和“只给汇总”等表达，确认不能绕过规则。
- 先提出有权限的问题，再在多轮对话中切换到其他区域、客户或人员，确认上一轮上下文不会扩大权限。
- 分别检查答案、图表、明细下钻、图片导出、数据导出和分享链接，确认没有出口采用更宽权限。
- 撤销角色或数据权限后重新登录并新建会话，检查缓存、历史对话和旧分享入口是否仍暴露数据。
- 检查权限不足、无数据、查询超时和接口失败的提示，确认系统说明真实状态而不是生成替代答案。
日志应能还原一次问数发生了什么
问数日志建议用交互编号关联提问、权限判定、查询执行和答案返回，至少记录用户与角色、分析主题或数据源、识别出的指标和筛选条件、权限命中结果、查询状态、结果范围、数据或口径版本、耗时、拒绝原因和人工纠正记录。SQL原文、问题原文和结果明细是否保存，应按敏感程度、排障需要和保留制度决定，避免把密码、令牌或不必要的个人信息写入日志。
第四步：让每个答案都带上核对依据
经营分析最怕“答案看起来对，却不知道按什么口径算出来”。智能问数结果不应只返回一句结论或一张图，还应同时展示足够的核对信息。
一份可核对的答案，建议至少包含：识别出的指标、统计周期、筛选条件、分析维度、数据来源、最近更新时间和权限范围。涉及异常解释时，还要区分“数据直接显示的事实”和“根据规则或模型生成的可能原因”。
例如，系统可以确认“华北区域本月毛利率低于上月”，因为这是数据计算结果；但“主要因为竞争对手降价”如果没有外部数据支持，就只能作为待核实假设，不能写成已经确认的原因。
对于重要经营结论，可以保留查询条件、结果快照或对应报表入口，让业务负责人能够回到原始数据继续核对。系统发现指标口径冲突、数据过期或结果异常时，应给出提示，并明确显示不确定性。
| 答案类型 | 必须具备的依据 | 系统应如何表达 | 验收与留存证据 |
|---|---|---|---|
| 指标事实 | 已确认的指标版本、时间范围、筛选条件、权限和来源数据 | 给出结果，同时展示口径、范围、来源和更新时间 | 与已确认报表或SQL对照，保存问题、条件和结果快照 |
| 规则或模型判断 | 可识别的规则、特征、模型或知识来源及其版本 | 明确标注为分析、分类或推断，不伪装成原始事实 | 保存版本、输入范围、输出和人工复核结果 |
| 外部业务原因 | 能够授权访问并核验的外部数据或正式记录 | 依据不足时列为待核实假设，不确认因果 | 记录缺失依据和后续核实责任人 |
| 敏感信息或业务动作 | 角色授权、流程规则、复核岗位和操作确认机制 | 越权时拒绝；涉及调价、付款、审批等只提供参考并转入受控流程 | 验证拒绝、人工确认、撤销路径和审计日志 |
第五步：明确AI能建议什么，不能替谁做决定
AI可以帮助管理者更快完成查数、汇总、对比、异常提示和分析路径建议，但不应默认替代有权限的业务负责人完成最终判断。
涉及调价、付款、授信、客户处置、人员评价、采购和审批等业务动作时，建议把AI输出作为参考信息，继续由明确的岗位复核并在业务系统中确认。如果项目希望从“发现问题”继续走向“创建工单、发送通知或执行操作”，需要单独设计流程权限、确认步骤、撤销方式和审计记录。
项目文档中还应写清哪些问题禁止回答，例如超出授权范围的明细、没有数据依据的预测、涉及个人敏感信息的比较，以及无法解释来源的经营建议。拒绝和澄清属于可信系统应具备的正常状态。
第六步：用问题集验收智能问数
AI+BI项目验收需要覆盖准确性、可重复性和权限隔离，“输入问题后有没有返回内容”只是基础。同一个问题应当能够在确定的数据和口径下重复核对，不同角色提出同一问题时，还要验证权限范围是否正确。
| 验收维度 | 检查方法 | 合格表现 |
|---|---|---|
| 指标准确性 | 用标准问题与已确认报表逐项对比 | 指标、公式、时间、筛选和汇总方式一致。 |
| 指标版本 | 按不同生效日期回放同一问题 | 使用对应版本，答案可说明口径版本和变更时间。 |
| 同义词与歧义 | 输入简称、旧称、近义词和模糊词 | 正确映射或主动澄清，不擅自选择口径。 |
| 多轮上下文 | 连续改变区域、时间和分析维度 | 保留有效条件，并明确显示每次条件变化。 |
| 权限隔离 | 使用不同角色提出相同问题 | 答案范围符合角色权限，越权请求被拒绝并留痕。 |
| 来源与血缘 | 从答案追溯指标、字段、转换和下游页面 | 业务人员可以回到数据或报表核对，变更影响范围可识别。 |
| 失败处理 | 模拟无数据、接口失败、超时和不支持的问题 | 说明真实状态，不返回伪造结果。 |
| 人工纠正 | 修正同义词、指标映射或错误答案 | 有明确处理人、记录和再次验证方式。 |
| 运行记录 | 抽查查询、权限和异常日志 | 关键行为可以追踪，敏感内容按规则保存。 |
响应时间、并发和可用性目标应结合数据量、查询复杂度、部署环境和业务时效确定，不宜直接套用其他项目的统一数值。验收报告要同时记录通过的问题、失败的问题、限制条件和待改进项。
先从一个角色、一个业务域做试点
首期项目不必同时覆盖所有部门和全部经营数据。可以先选择一个真实使用频率较高、指标相对稳定、数据权限清楚的场景，例如销售复盘、项目进度、回款分析或库存异常。
试点范围应同时包含固定驾驶舱、智能问数入口、标准问题集、权限角色、答案证据和人工复核人。试点完成后，重点判断业务人员是否真的会提问、答案是否能核对、失败问题集中在哪里，以及维护指标语义和问题集需要多少持续工作。
如果核心问题主要是固定汇报，现有看板已经能满足；或者业务数据仍以线下表格临时汇总、同一指标长期存在多种口径，那么第一阶段可以继续完善驾驶舱和数据治理，不必为了使用AI而增加项目复杂度。
项目方和实施方分别要负责什么
| 角色 | 主要责任 |
|---|---|
| 业务负责人 | 确认真实问题、指标含义、使用方式、业务边界和最终判断责任。 |
| 数据负责人 | 确认数据来源、质量、更新时间、异常处理和可追溯方式。 |
| 安全与系统管理员 | 确认身份、权限、脱敏、日志、部署和账号管理要求。 |
| 实施团队 | 完成问题解析、语义映射、查询控制、结果展示、测试和文档交付。 |
| 验收人员 | 使用标准问题集和不同权限账号独立复核结果，不只查看演示效果。 |
系统上线后，还要指定谁维护指标别名、问题示例、数据映射、权限和错误反馈。企业的指标、组织、数据源和常见问题变化后，智能问数也需要同步更新并重新验证。
定制方案的依据和适用边界
本文的方法来自定制项目常见的需求、设计、联调和验收链路：先确认客户现有系统与管理问题，再定义指标、接口、权限、部署和交付边界，最后用真实账号、数据和问题集回归。它不是某一种BI软件的操作说明，也不承诺任何现成组件可以不经适配直接满足项目要求。
数据质量维度可参考国家标准全文公开系统中的 GB/T 25000.12-2017 数据质量模型；权限与日志控制可参考 OWASP Authorization Cheat Sheet 和 OWASP Logging Cheat Sheet；AI风险识别、角色责任和持续治理可参考 NIST AI Risk Management Framework。MCP 接入边界可核对 MCP Authorization 和 MCP Tools；行列权限与语义建模的产品实现示例可参考 SQLBot 权限配置及 Quick BI 基本概念。这些资料用于补充检查维度，不构成产品认证或自动合规结论；具体架构、适用要求和验收标准仍应以客户制度、部署环境、合同和专业评估为准。
常见问题
AI+BI定制开发和成品BI软件有什么区别？
成品BI通常围绕既有产品能力、连接器、权限模型和部署方式进行配置；定制开发则从客户现有业务流程、数据系统、指标口径、身份权限、部署网络和验收要求倒推架构。定制并不等于全部从零开发，可以复用适合的数据库、模型、BI或身份组件，但数据适配、语义、权限、界面、流程和交付边界由项目需求决定。
定制开发是否意味着所有能力都要从零开发？
不意味着。项目可以保留或集成满足要求的数据库、数据平台、BI、模型服务和身份系统，把定制工作集中在现有系统接入、指标语义、权限映射、业务流程、界面交互和验收证据上。采购、嵌入还是开发，应结合接口开放程度、许可边界、部署环境和后续维护责任选择。
企业数据还不完整，可以先做智能问数吗？
可以先选一个数据相对稳定的业务域做小范围验证，但应先确认核心指标定义、数据来源、更新时间、权限和责任人。数据口径长期冲突时，智能问数会更快暴露问题，却不能替代数据治理。
能不能让大模型直接连接生产数据库？
正式环境不宜把高权限数据库账号直接交给模型。建议通过只读数据服务、受控语义模型，或只暴露查询能力的MCP与工具服务访问数据，并在服务端落实账号权限、查询白名单、行列权限、脱敏、超时和审计日志；工具名称写着“只读”不能替代这些控制。
智能问数怎样避免指标答错？
先统一指标名称、公式、时间口径、维度和同义词；答案中同时显示统计周期、筛选条件、数据来源和更新时间。遇到歧义、无数据或权限不足时，应先澄清或明确拒绝，而不是继续猜测。
Text-to-SQL生成正确就代表智能问数可上线吗？
不能。还要检查问题解析、语义层映射、权限过滤、SQL执行范围、结果解释、答案证据和日志留痕。SQL正确但口径、权限或解释错误，同样不应通过验收。
AI+BI项目验收时重点检查什么？
需检查标准问题和多轮追问的准确性、歧义澄清、权限隔离、来源追溯、无答案处理、响应稳定性、日志记录和人工纠正机制；聊天框能够返回内容只是基础。
AI可以直接替管理者做经营决策吗？
不建议。AI可以帮助查询、汇总、解释和提示风险，但经营决策仍应由有权限的业务负责人结合数据质量、业务背景和外部条件复核。涉及审批、调价、付款、客户处置等动作时，还应保留人工确认。