龙虎斗App AI ESG风险与绿色金融助手

龙虎斗App收到一个ESG High Risk提醒以后，为什么页面应该先显示事件Evidence和Status，而不是先显示一个红色Score？

手机震动，推送写着“Company A：ESG High Risk”。点开之后，如果第一屏是一个红色的大数字，用户能做的只有两件事：相信它，或者不相信它。两种反应都没有价值，因为数字本身不告诉用户发生了什么、有多确定、该去查什么。龙虎斗App的Risk Alert页面把红色数字放在第三屏，前两屏是事件与证据。

第一屏：这是什么事件，处于什么状态

事件类型（例如Environmental · Regulatory Action）、状态（Penalty Issued、Under Investigation、Alleged等）、事件时间、直接主体与传导关系（“子公司A-1，全资”）。状态是最重要的信息：Alleged与Penalty Issued在证据等级上完全不同，用户必须在看到任何数字之前知道这一点。如果状态是Alleged，页面明确写出“指控，未经认定”。

第二屏：证据在哪里

独立来源数与总提及数分开显示（“3 sources / 27 mentions”），每条来源带等级（Official、Company Filing、Major Media等）、时间与原文链接，转载归入Cluster并标注“无信息增量”。企业的公开回应与原事件并列，这是Right to Context。如果来源之间存在矛盾，页面显示Conflict而不是替用户选一方。

第三屏：分数与归因

分数以“72 → 64”的形式出现，旁边是Attribution：“New Event”。用户知道变化来自这条事件，而不是Methodology升级。分数标注Demo，页面底部写明评分为功能演示，不属于受监管评级或授信结论。

为什么顺序重要

先看数字，用户会用数字去解释事件（“分数这么低，事情肯定很严重”）；先看事件与证据，用户会用证据去判断数字是否合理。后者才是研究工作的正确顺序。此外，先显示证据能减少Alert Fatigue：用户很快学会区分“一条官方处罚”与“一条未经证实的指控”，不再对每一次红色提醒都同样紧张。

Alert的排序逻辑

龙虎斗App的Alert按Severity、Materiality、Confidence、Recency与Business Exposure组合排序。Business Exposure来自用户的Watchlist设置：这家企业是持仓、贷款客户还是供应商，暴露不同，优先级不同。一天100条Alert没有人会看，排序的目的是让真正重要、证据更强、与用户相关的事件先浮出来。

用户可以做什么

标记“主体错误 / 事件重复 / 状态过期 / 非ESG事件”，这些反馈进入回流数据用于改进检测；查看原始来源；把事件加入跟踪；请求龙虎斗AI助手解释。页面的最后一个按钮永远是“查看原始来源并人工复核”，因为AI识别结果可能包含待核实事件或模型误判，不构成企业违法认定。

一个具体的推送场景

以示意中的Company A为例。推送到达后，第一屏显示“Environmental · Regulatory Action · Penalty Issued · 2026-08 · 直接主体：子公司A-1（全资）”。用户立刻知道三件事：这是环境类事件，已经进入处罚状态而不是指控，事件落在全资子公司上。第二屏显示三条独立来源：监管处罚决定书（Official）、公司公告的整改计划（Company Filing）、一篇主流媒体的原发报道（Major Media），下面一行小字“24篇转载已归入同一Event”。用户知道证据等级高，而且传播量并不代表事件数量。企业回应就在同一屏，用户看到企业已经公告整改计划。第三屏才是“ESG Risk 72 → 64，Attribution：New Event”。此时用户对这个数字的理解已经建立在事件与证据之上。

Company Response与Correction

企业的公开回应在推送后可能才出现。龙虎斗App在企业公告回应或媒体更正时更新同一Event，并向已收到推送的用户发送一条“事件更新”而不是新的风险提醒，更新内容与原事件在同一页面展示。这样用户不会因为一次更正而收到第二次“高风险”，也不会错过企业的回应。

如果状态是Alleged

同样的推送流程，如果事件状态是Alleged，例如某劳工组织指控供应商存在用工问题，第一屏会用不同的视觉处理：状态标签为“Alleged · 指控，未经认定”，Severity显示为区间并标注“待确认”，页面顶部不使用红色。第二屏的来源等级会显示为NGO / Industry Source，并提示“无独立来源交叉确认”。第三屏的分数变化可能很小甚至为零，因为Alleged状态的事件在Methodology中权重有限。用户看到的是一条需要跟踪的争议信号，而不是一次“风险爆发”。这种区分正是龙虎斗官网全站强调的Allegation不是Finding在移动端的具体体现。

Confidence的显示方式

Confidence显示为“主体与事件识别置信度”，并附一句说明：它表示我们多确定这条事件属于这家企业，不表示企业违法的概率。这个说明在移动端尤其重要，因为屏幕小、信息密度高，最容易被误读的就是一个百分比。

龙虎斗App发现一家Supplier一天新增30篇负面报道以后，为什么用户需要知道这30篇到底对应几个独立Event？

Supplier页面的曲线突然拉起：24小时内新增30篇负面报道。30是示意，但这种曲线在供应商监测里很常见。采购经理看到它的第一个问题应该是“发生了几件事”，而不是“发生了多少报道”。龙虎斗App的Supplier Risk页面把这两个问题分开回答。

30篇报道的三种可能

第一种：一件事被30家媒体转载，这是Article Syndication，事件数为1。第二种：两件不同的事，例如一起安全事故调查和一起劳工指控，各自被十几家转载，事件数为2。第三种：30篇里有一部分说的是同名的另一家工厂，事件数可能为1或2，但主体需要核对。三种情况对采购决策的含义完全不同，而Mention Count对三种情况显示的是同一个数字。

龙虎斗App怎么显示

页面顶部是事件数与独立来源数：“2 Events · 5 independent sources · 30 mentions”。下面按Event展开：Event #1203 Safety · Under Investigation，来源等级最高为Official（监管公告），12篇转载已归入Cluster；Event #1187 Labor · Alleged，来源为劳工组织声明与地方媒体，18篇转载。用户一眼看到：一件事有官方来源，处于调查中；另一件事是指控，尚未认定。

Supplier Entity Resolution的提示

如果30篇中有部分主体匹配置信度不足，页面显示“主体待确认：N篇”，这些报道不计入任何事件，直到人工核对。供应商往往有中文名、英文名、工厂名、子公司名，同名误匹配在供应商监测中比在上市公司监测中更常见。

然后才是传导

事件确认之后，页面显示这家Supplier与用户企业的关系：Tier 1直接合同、采购占比、是否Single-source、替代供应商状态、切换周期。Buyer Exposure分两栏：ESG Exposure（责任链与声誉）与Operational Exposure（交付影响）。一起Under Investigation的安全事故落在Single-source供应商上，Operational Exposure可能很高，即便事件本身尚未有结论。

为什么不合成一个“供应商风险分”

合成分数会丢失用户最需要的信息：分数高是因为事件严重、因为依赖度高、还是因为报道多？三者对应完全不同的应对：核查事件、启动替代来源、或者什么都不做。龙虎斗App把维度分开显示，让采购、ESG与风险团队各自看到自己的维度。

Tier 2的提示

如果事件发生在这家Tier 1的上游供应商，页面显示传导路径：“Tier 2 → Tier 1 → 你”，并标注“间接暴露”与路径上每一层的依赖度。可见度缺口（不知道Tier 2是谁的路径）单独标出，因为No News ≠ No Risk在Tier 2尤其成立。

Source Reliability在供应商页面尤其重要

供应商事件的来源常常是地方媒体、劳工组织或行业网站，来源等级低于监管公告。龙虎斗App在每条Event旁标注最高来源等级，并提示“仅有单一非官方来源”或“已有官方来源确认”。对采购决策而言，一条有监管公告的Under Investigation事件与一条只有社交帖子的指控，需要完全不同的反应。页面不会因为报道数量多而提升来源等级，转载再多也只是一条证据的复制。

Time Decay与旧事件复活

30篇报道里还可能藏着另一种情况：其中几篇是对Supplier B两年前一起已整改事件的回顾性提及，被自动转载后看起来像新闻。龙虎斗App在事件匹配时会把它们归入已存在的历史Event，页面显示“历史事件 · 已Resolved · 新增转载N篇”，不产生新Alert，也不改变当前风险画像。但如果新的Safety事件与那起历史事件属于同一类型，Recurrence检测会被触发，页面提示“同类事件两年内重复出现”，此时历史事件的权重部分恢复。用户由此看到的是一条时间线，而不是一堆孤立的标题。

Watchlist与Alert门槛

用户可以为这家Supplier设置独立的Alert门槛。对Single-source供应商，龙虎斗App建议降低门槛：任何进入Under Investigation的事件都推送；对可替代供应商，只推送进入Regulatory Action及以上状态的事件。Watchlist还可以按Industry或Region设置，例如关注某个工业园区内所有供应商的环境事件，因为区域性执法行动往往同时影响多家工厂。这些设置在静态站中只是功能演示，真实产品中它们决定用户每天看到几条Alert而不是几百条。

用户的下一步

把事件加入跟踪；请求供应商提供说明或审核；标记主体错误或重复；询问龙虎斗AI助手“这两件事对我们的交付有什么影响”，助手会基于依赖度与事件状态给出带引用的说明，并提醒需要人工核查原始来源。AI识别结果不构成供应商违法认定。

龙虎斗App显示一家企业Green Finance Score下降以后，为什么页面必须把Event Change和Methodology Change分开？

Green Finance页面上，一家企业的研究分从81降到74。数字是示意，问题是真实的：这7分从哪里来？如果页面只显示新分数，用户会默认是企业出了问题；如果页面显示归因，用户可能发现其中5分来自Methodology升级，企业侧只有2分的变化。这两种理解会导致完全不同的行动。

Green Finance Score的子模块

龙虎斗App的Green Finance Score不是一个黑箱数字，它由Environmental、Social、Governance、Climate、Carbon、Controversy与Data Quality子模块组成，每个子模块有自己的证据状态。分数下降时，页面先显示哪些子模块变化了，再显示每个子模块的变化来源。

Event Change：企业侧的变化

新事件（例如一条进入Regulatory Action的环境处罚）、既有事件状态升级（从Investigation到Penalty Issued）、数据更新（新的排放披露）。这些变化指向企业本身，用户需要查看事件Evidence与Status，判断是否需要行动。页面把这类变化标为“Event Change”，并链接到对应事件。

Methodology Change：评分侧的变化

Methodology版本升级（例如Recurrence规则变化）、权重调整（例如Climate模块权重提高）、模型版本更新（例如Entity Resolution模型改变了某些事件的归属）。这些变化与企业行为无关，用户不应把它们读成企业恶化。页面把这类变化标为“Methodology Change”，注明版本号，并提示“不同版本分数不可直接比较”。

Source Correction：第三类

既有事件被更正，例如旧案更新为Dismissed，或主体归属纠错。这类变化可能让分数回升，它也不是企业“变好”，而是数据修正。页面单独标注。

为什么移动端更需要这种拆分

移动端的信息密度高、阅读时间短，一个孤立的数字最容易被误读。把归因放在分数旁边，用户在三秒内就能知道“这是企业的事还是模型的事”，而不需要打开电脑去查方法论文档。

Green Eligibility与Credit Risk仍然分开

Green Finance页面在分数之外还有两个独立区块：Eligibility Checklist（Use of Proceeds是否界定、项目边界、Baseline、外部核查，缺失项标为Evidence Gap）与Credit Risk提示（“Green Eligibility ≠ Creditworthiness，传统授信分析仍需独立完成”）。分数变化不改变这两个区块的独立性。

一个具体的下降场景

示意中的7分变化在页面上会这样展开。Climate子模块下降3分，归因为Methodology Change：v4.0把Physical Risk与Transition Risk的权重从合并计算改为分别计算，企业的资产位置数据没有变化。Carbon子模块下降2分，归因为Methodology Change：新版本要求Scope 3披露，缺失时按Data Quality扣减。Controversy子模块下降2分，归因为Event Change：一条新的环境处罚进入Regulatory Action状态，链接到事件页面。用户看到的结论是：企业侧有一条需要核查的新事件，其余变化来自评分方法升级，不同版本的分数不可直接比较。如果没有这种拆分，用户只会看到一个下降了7分的数字，然后去猜。

Data Quality是最容易被误读的子模块

Data Quality下降经常被读成企业变差，其实它描述的是画像建立在多少信息之上。一家企业停止发布可持续发展报告，Data Quality会下降，但这可能是披露策略调整而不是ESG表现恶化；相反，一家企业开始详细披露轻微事件，Controversy子模块可能上升而Data Quality上升，这是透明度提高而不是风险增加。龙虎斗App在Data Quality子模块旁单独说明“该变化反映信息覆盖度，不反映企业表现”，并在Disclosure Bias明显时提示用户。移动端的分数最容易被断章取义，这一行说明的价值不亚于分数本身。

Physical与Transition在Climate子模块里分开

Climate子模块内部再分为Physical Exposure与Transition Exposure两行，各自带时间尺度与情景来源。用户点开可以看到企业哪些资产位于高风险区域、企业披露了哪些适应措施、哪些信息缺失。页面不把两行相加，也不把情景下的等级写成“将会发生”。

Greenwashing Detection在Green Finance页面的位置

Green Finance页面还有一个Claim-Evidence Gap区块，它不是分数，而是清单：企业声明“2030年Net Zero”，页面逐项核对Target Boundary、Base Year、Scope、Plan与External Verification是否存在，缺失项标为Evidence Gap。企业声明“该项目年减排2万吨”，页面核对Baseline与口径。这些缺口不进入分数，也不被判定为欺诈，它们告诉用户“看起来绿色”与“有证据支持”之间还差什么。对企业融资团队，这是申请前的自查清单；对银行研究人员，这是尽职调查的问题清单。

页面底部

“绿色融资条件初步筛选：需要人工复核。”以及“评分为功能演示，不构成贷款批准、信用评级或投资建议。”这两句话在Green Finance页面的每一屏都存在。龙虎斗App不显示任何“审批通过”字样，不输出授信金额，也不对具体证券或贷款给出买卖或授信建议。

龙虎斗App发现Green Bond出现新的Controversy以后，为什么投资研究页面应该把Issuer Risk和Project Eligibility分开显示？

一只绿色债券的发行人出现了新的争议：一家子公司因废水排放被处罚。推送到达，投资研究人员打开龙虎斗App的Green Bond页面。此时页面需要回答的不是“这只债券还绿不绿”，而是两个分开的问题：发行人怎么了？募投项目怎么了？

Issuer Risk：发行人的事

争议事件通过龙虎斗ESG风险的流程识别、去重、标注状态，作为Issuer Risk关联到债券。页面显示事件类型、状态（Penalty Issued）、直接主体（子公司）、传导关系（全资）、证据与企业回应。它告诉用户发行人的ESG事件暴露变化了，以及这可能对发行人信息可靠性意味着什么。

Project Eligibility：项目的事

募投项目是否受影响，取决于事件是否涉及项目本身。如果被处罚的子公司与募投项目无关，Project Eligibility记录不变，页面明确写出“事件不涉及募投项目，项目资格判断无变化”。如果事件涉及项目所在实体或设施，Project Eligibility进入“需要重新评估”状态，并列出需要核查的事项：项目是否仍在运行、技术参数是否变化、是否影响分配报告。

为什么分开

发行人的争议不自动改变项目的资格，项目的问题也不自动改变发行人的整体画像。混在一起会产生两种错误：因为发行人有争议而否定一个仍然合格的项目，或者因为项目合格而忽视发行人报告可靠性的问题。分开显示让研究人员各自评估，再综合判断。

Reporting状态

页面同时显示债券的报告状态：分配报告是否到期、是否发布、是否完整；影响报告的Baseline与口径是否说明；发行后External Review是否覆盖。争议事件可能提高用户对报告可靠性的关注，页面把这些信息放在一起，但不合成一个分数。

EuGB的特殊标注

如果这只债券是European Green Bond，页面标注其受监管标签属性，并提示External Reviewer需在ESMA注册，龙虎斗AI不能替代其审查意见。普通Green Bond与EuGB不混用标签。

龙虎斗AI助手在这里的角色

用户可以问“这条处罚与募投项目有关系吗”，助手基于Knowledge Graph中的主体、设施与项目关系给出带引用的回答；如果关系不明确，回答“未找到证据表明事件涉及募投项目，建议核查发行人公告”。它不回答“这只债券该不该买”，因为AI输出不构成投资建议。

Entity Resolution决定争议算给谁

争议事件的直接主体是子公司，而债券的发行人是母公司。龙虎斗App先通过Knowledge Graph确认子公司与发行人的股权关系，再判断子公司是否与募投项目相关。如果被处罚的子公司恰好是项目的实施主体，Project Eligibility区块立即标注“需要重新评估”；如果它只是集团内另一条业务线，Issuer Risk区块记录传导暴露，Project Eligibility不变。这一判断在页面上以关系图的形式展示，用户可以看到争议主体、发行人与项目之间的连线。

Allocation与Impact在同一页面的位置

Green Bond页面除了Issuer Risk与Project Eligibility，还有Allocation与Impact两个跟踪区块。Allocation区块显示资金分配进度、项目清单与框架类别的匹配情况、未分配余额的管理方式；Impact区块显示影响指标、Baseline、口径与核查状态，缺失项标为Evidence Gap，没有真实数据时显示“影响数据未提供”而不生成任何估算。新的Controversy出现时，这两个区块不自动变化，但页面会提示“发行人出现新事件，建议关注下一期报告的完整性”。这样设计的目的是让研究人员看到争议对债券各个环节的具体影响，而不是一个笼统的“风险上升”。

Time Decay对债券存续期的意义

绿色债券的存续期可能长达数年，发行人在这期间出现的事件会随时间衰减。一起发行后第一年的处罚，到第四年如果已经整改并且没有重复，它对Issuer Risk的贡献会很低；但如果同类事件在存续期内反复出现，Recurrence会让历史事件重新变得重要。页面把Issuer Risk的Timeline完整展示，用户可以看到事件的密度与类型变化，而不只是当前状态。这对判断发行人报告的可靠性尤其有用：一个事件频繁但报告完整的发行人，与一个事件稀少但报告缺失的发行人，需要不同的研究态度。

页面的结尾

Issuer Risk区块、Project Eligibility区块、Reporting状态区块、EuGB标注（如适用）、AI助手入口，以及固定的一行：龙虎斗提供的绿色债券相关内容属于研究辅助与技术演示，不构成证券投资建议、External Review或Second Party Opinion。