---
name: darkline
description: "Use for darkline, news, external information, information topology, event chain, evidence chain, reality verification, K-line manifestation, case analysis, and external information collection tasks. Enforces the darkline workflow."
metadata:
  short-description: "Darkline information analysis checklist"
---

# darkline 信息拓扑分析

## 1. 先判断任务模式

遇到暗线、新闻、公告、外部信息、事件链、证据链、案例分析、K 线显影任务时，先判断任务属于哪类：

```text
广撒网收集：目标是扩大信息覆盖，让后续能建立更多拓扑。
暗线专线追踪：目标是追一条暗线的关键节点、证据链、现实验证和市场输出。
方法论验证：目标是验证一条信息分析规则，不追新暗线。
数据/存储整理：目标是把证据按信息拓扑结构归档。
```

不要把四类任务混在一起。

## 2. 暗线定义

暗线必须是：

```text
意图 / 目标 / 人心 / 组织意志
```

不能把新闻标题、公告事件、机制标签、行业概念、K 线结构、政策文本本身直接叫暗线。新闻和事件是叶子，暗线是枝干。

## 3. 标准推理链

讲暗线故事或做案例分析时，必须按这个顺序：

```text
B/C：最初看到哪些新闻或事件叶子。
A：这些叶子同归殊途，反推出什么更早的意图/目标。
M：如果 A 为真，在 B/C 之前应该已经发生什么铺垫。
N/L：如果 A 为真，B/C 之后还应该发生什么后续行为。
验证：M/B/C/N/L 哪些被现实证实，哪些缺证据。
市场输出：这条暗线应该影响哪个层级、哪些对象、什么窗口。
结果：实际显影是否支持，还是需要替代解释。
```

## 4. 必须连续问为什么

追暗线时必须问：

```text
为什么是这个时间？
为什么是这个主体？
为什么之前没有，现在有？
如果这是下层事件，上层是谁或什么意图在推动？
如果追到一个根节点，它还有哪些兄弟分叉？
```

不能追到第一个看似合理的解释就停。

## 5. 层级规则

先分层，再决定落点和窗口：

```text
L1：国家级 / 国际级 / 顶层政策 / 大国博弈。周期长，通常先影响宏观背景、大行业或长期主题。
L2：行业 / 集团 / 地方 / 大机构。周期中等，通常影响产业链、主题群、平台型对象。
L3：公司 / 关键人 / 具体资本动作 / 单一事件。周期短，通常更容易落到单一主体、短窗口和局部表现。
UNKNOWN：层级证据不足，只允许 review。
```

高层主体更大概率推动下一层事件。同层推动不是不可能，但需要更强证据。

## 6. 原理偏差追因

如果核心原理本身没有明显问题，但现实结果和原理不符，必须先问为什么，不能直接说理论失败。

优先排查：

```text
层级错了
窗口错了
对象错了
新闻滞后
上层风覆盖
事件阶段不同
样本混了不同根因
使用了事后字段
替代解释没有排除
```

## 7. 新闻判读规则

不要直接做：

```text
新闻出现 -> 看后续结果
```

优先判断：

```text
公告前是否已经显影？
新闻是起点，还是迟来的确认？
新闻背后的利好/利空类型是什么？
```

利好类型至少分：

```text
生产力增强型
估值修复型
托底稳定型
风险解除型
短线情绪型
资本动作型
```

托底稳定型不能按生产力增强型读。

## 8. 量价显影硬规则

只要任务落到单票、K 线、股价反常识、减持、回购、增持、控制权、题材放大，就必须同步检查量价。

最小检查项：

```text
公告前是否已经提前显影。
公告当天和次日成交额/换手是否支持流动性窗口。
价格是低量拉高、放量换手、缩量锁筹，还是高位放量出货。
大盘和同行业背景是同向，还是个股独立逆势。
公告之后是继续承接、快速兑现，还是有人托底。
```

量价不是附属信息，是暗线证据链的一部分。

## 9. 证据收集规则

当前阶段优先抓关键节点，不堆无关新闻。

优先级：

```text
根节点证据
关键转折节点
官方公告 / 监管文件 / 交易所文件
直接验证应有之线的事件
能证伪暗线的反向证据
能连接到市场输出的节点
```

除非用户明确要求深追，或判断为高价值暗线，否则不要对每条新闻抓大量细节。

## 10. 准确率规则

暗线准确率不是事件越多越高，而是关键节点验证越多越高。

```text
关键节点验证：强增信。
普通枝叶验证：弱增信。
重复转载/同源新闻：不增信或低增信。
反向关键节点：强降信。
```

置信度要随证据更新，不要一次性定死。

## 11. 归档要求

只要进入暗线追踪，产物必须能回到信息拓扑结构。

至少保留：

```text
darkline_hypothesis
expected_line
event_node
evidence
impact_target
manifestation_bridge
alternative_explanation
chain_state
```

不要只留下故事，不留证据路径。

## 12. 新增案例功能

当用户要求“记录案例、归档案例、新增案例、把这个案例入库、把故事存到 darkline”时，必须按新增案例流程执行，不要只写一段故事。

新增案例必须同时满足：

```text
人能读：有完整故事正文，按 B/C -> A -> M -> N/L -> 市场输出 -> 实际结果 -> 总结。
机器能查：落到 darkline 信息拓扑表，至少能通过 case_id / darkline_hypothesis_id 串起来。
可复核：每个关键判断能回到证据、缺口或替代解释。
```

最低入库层：

```text
dl_case_record
dl_darkline_hypothesis
dl_expected_line
dl_case_reasoning_step
dl_evidence
dl_chain_state
```

完整链路层：

```text
dl_source_document
dl_case_import_batch
dl_case_record
dl_darkline_hypothesis
dl_case_reasoning_step
dl_expected_line
dl_event_node
dl_evidence
dl_evidence_node_link
dl_impact_target
dl_manifestation_bridge
dl_alternative_explanation
dl_chain_state
```

新增案例执行顺序：

```text
1. 先写案例正文，按标准推理链讲清楚。
2. 提取暗线假设，确保 A 是意图/目标/人心/组织意志。
3. 拆 reasoning_step，每个关键节点必须有 why_question / why_hypothesis / evidence_to_check / current_answer / unresolved_gap。
4. 写 expected_line，至少一条；如果暗线为真，前置和后续应发生什么。
5. 写 event_node；只有现实事件有证据时才写，没有证据就保持 HELD，不伪造。
6. 写 evidence，并用 evidence_node_link 连接到 event_node / expected_line。
7. 写 impact_target 和 manifestation_bridge；没有市场显影就写缺口，不硬填。
8. 写 alternative_explanation，至少考虑市场普涨、行业风、单股动能、其他暗线、数据缺口。
9. 写 chain_state；每次判断变化新增 state，不覆盖旧 state。
10. 完成后跑入库校验，检查行数、外键链路、hash/manifest。
```

新增案例禁止项：

```text
禁止只写 Markdown 不入库。
禁止只有结论没有推理步骤。
禁止把新闻标题、机制标签、行业概念、K线结果直接写成暗线。
禁止为了凑完整链路伪造 event_node 或 manifestation。
禁止覆盖旧判断；判断变化必须新增版本。
```

新增案例后必须自检：

```text
case_id 非空且唯一。
darkline_hypothesis_id 非空且能串回 case_id。
expected_line_count >= 1。
reasoning_step_count >= 1。
evidence_count >= 1。
chain_state_count >= 1。
如果有 event_node，则必须有 evidence_node_link。
如果有 manifestation_bridge，则必须有关联 impact_target。
所有缺口必须写入 chain_state.note 或对应 review 字段。
```

旧案例复用规则：

```text
CASEBOOK_FULL_CHAIN_IMPORTED：可以作为完整链路样板复核。
CASEBOOK_WITH_EXPLICIT_GAPS：只能作为案例线索，必须先补证再做强结论。
EVENT_NODE_ARCHIVE_GAP：不是现实事件。
HELD_BY_MARKET_MANIFESTATION_GAP：不是市场显影成立。
HELD_BY_ALTERNATIVE_EXPLANATION_GAP：不是替代解释已排除。
```

复用旧案例前，必须先看最新 chain_state。看到 GAP_REVIEW 时要把它当作待补证缺口，而不是当作有效证据。

如果当前环境没有 MySQL 或用户只让先草拟案例，则先生成案例正文和可入库 payload，并明确说明“未入库”。一旦用户要求归档，就必须补入库和校验。

## 13. 汇报格式

对用户汇报时，少说空泛边界，多说实际进展：

```text
现在追到哪一层？
反推出的暗线意图是什么？
已验证的关键节点有哪些？
缺的关键节点是什么？
对输出层的影响是什么？
当前能交付什么？
不能交付什么？
下一步追哪个关键节点？
```

如果用户说“讲故事”，必须按 `B/C -> A -> M -> N/L -> 市场输出 -> 实际结果 -> 总结` 的顺序讲。