dsh-equity-diligence

一级市场尽调 · 公开信息调查工作台

把「尽调前的公开信息调查」从个人手艺，变成一条流程标准化、交付标准化、信息收集自动化的流水线。

面向一级股权市场从业者（PE / VC / CVC / 战投 / FA）的调查工作台，以 [DeepSeek Harness](https://github.com/deepseek-ai) 插件形式运行在 Web GUI 中：

25 个内置模块（23 个专用方向 + 1 个通用兜底 + 1 个交付构建器） · 32 类类型化底稿 · 36 种勾稽算子 · 12 条核查触发器 · 代码化交付验收

> 状态说明（请先读）：软件已完整（内核、执行器、交付、UI 全链路可跑，102 项测试通过），但 25 个模块的方法论均为 draft，尚未经金融专家逐模块评审。本仓库不声称任何模块已 stable。见 [已知限制](#14-已知限制)。

---

目录

• [1. 它解决什么问题](#1-它解决什么问题)
• [2. 做法：三层解耦](#2-做法三层解耦)
• [3. 和「直接问 AI」的区别](#3-和直接问-ai的区别)
• [4. 快速开始](#4-快速开始)
• [5. 一次调查长什么样](#5-一次调查长什么样)
• [6. 内置模块](#6-内置模块)
• [7. 模块现状：谁写的、成熟到什么程度](#7-模块现状谁写的成熟到什么程度)
• [8. 预设方案](#8-预设方案)
• [9. 自定义模块](#9-自定义模块)
• [10. 底稿、勾稽与验收](#10-底稿勾稽与验收)
• [11. 交付物](#11-交付物)
• [12. 架构](#12-架构)
• [13. 命令与工具](#13-命令与工具)
• [14. 已知限制](#14-已知限制)
• [15. 合规边界](#15-合规边界)
• [16. 参与贡献](#16-参与贡献)

---

1. 它解决什么问题

正式尽调（IC、进场 DD）之前，分析师必须先回答一整组公开信息问题：这家公司是谁？股权和控制权怎么走？做什么业务、赚什么钱？客户和供应商是谁？技术从哪来？有没有诉讼、处罚、经营异常？行业地位如何？和我们有没有合作可能？还有哪些必须进场核？

这些问题大部分只靠公开信息就能答。缺的从来不是方法，而是把方法组织成一条可复用的流水线。现实中的四个卡点：

| 痛点 | 具体表现 | 本项目的做法 |

|---|---|---|

| 信息收集困难 | 来源散在公告、工商、中基协、裁判文书、官网、媒体里；不知道该查哪些渠道、按什么顺序查、查到什么程度算够 | 模块内置检索路径、来源优先级（公告 > 工商 > 媒体）、最低证据数与覆盖率门 |

| 重复劳动多 | 每换一个标的，都要重写一遍提示词、重捋一遍流程；同一个人做十遍，十遍都不一样 | 方案（playbook）+ 预设：一次配置，反复用于不同标的；断点恢复、幂等重跑 |

| 数据形式非标 | 每个人交上来的 Excel 列不一样、口径不一样、金额单位不一样，汇总时靠人眼对齐 | 32 类底稿 JSON Schema 约束字段与口径；交付工作簿由代码生成，列结构固定 |

| 交付一致性差 | 同样的问题，不同团队给出的深度、结构、证据强度差异很大；"查了没有/查得对不对"说不清 | 底稿之间声明式勾稽 + 交付前代码验收（QA 阻断项） |

2. 做法：三层解耦

┌───────────────────────────────────────────────────────────────┐
│ 平台层  插件统一工作流                                        │
│         项目 → 方案 → 单元 → 底稿 → 证据 → 审核 → 交付        │
│         （状态机、断点恢复、幂等、预算、暂停取消，都在内核里）│
├───────────────────────────────────────────────────────────────┤
│ 能力层  skill = 模块单元                                      │
│         每个调查方向一个模块：方法论 + 任务模板 + 门 + 降级   │
│         23 个专用方向 + 1 个通用兜底 + 1 个交付构建器 = 25    │
├───────────────────────────────────────────────────────────────┤
│ 质量层  底稿类型化 → 勾稽可声明 → 交付代码验收                │
│         32 类底稿 · 36 种勾稽算子 · 12 条核查触发器 · 代码验收│
└───────────────────────────────────────────────────────────────┘

2.1 平台层：用插件把「工作流」钉死

不把流程写进提示词，而是写进内核。分析师面对的不再是"和 AI 聊天"，而是六个动作：

立项 → 看方案 → 编译 → 运行 → 处理议题 → 交付

内核负责：底稿版本（revision）、上游变更只标直接下游 stale、预算上限、暂停/取消/断点恢复、证据出网审计。流程不会被一次对话的上下文长度冲掉。

2.2 能力层：每个调查方向是一个 skill 模块

一个模块就是一个标准文件夹，不需要写运行时代码：

assets/modules//
├─ module.yaml          # 身份、输入/输出类型、门、预算、参数
├─ SKILL.md             # 方法论：查什么、去哪查、怎么记、口径怎么写
├─ prompts/collect.md   # 任务模板（变量注入：项目、目标、上游底稿、输出 schema）
├─ rules/gates.json     # 机器可判定的规则（必填、覆盖率、勾稽）
├─ rules/rubric.md      # 五维质量 rubric
└─ fallback.md          # 工具不可用时的最低调查清单

新方向 = 加一个文件夹，不改内核。没有专用方向时，用 generic-investigation + 自由调查（mode=adhoc）兜底。

2.3 质量层：底稿有类型，勾稽可声明，交付靠代码验收

这是和"让模型写一份报告"最本质的差别：

• 底稿有类型：32 类 JSON Schema，逻辑主键 type + scope + subjectId + partitionKey + period/asOf，历史 revision 不覆盖；
• 勾稽可声明：模块在 rules/gates.json 里声明底稿内部与跨字段的一致性关系（求和=100、两字段必须相等、集合必须覆盖、引用的证据必须存在……），也可以在项目级自定义；
• 交付靠代码验收：Python + Node 两层体检，结构、列语义、状态字段、公式、标绿、摘要↔底稿一致性，失败即阻断交付，不靠人看。

3. 和「直接问 AI」的区别

| 维度 | 直接问 AI | 本工作台 |

|---|---|---|

| 流程 | 每次重新描述，随对话漂移 | 方案固化为可编译的 DAG，缺生产者/成环/顺序错都在编译期报错 |

| 证据 | 结论里夹来源，无法核 | Claim–Evidence 账本，quote 必须逐字命中原文，原文 hash 快照不可变 |

| 查不到 | 容易变成"无"或编一个 | 强制状态字段：not_disclosed_after_search 必须链到检索记录，不留空 |

| 数据形状 | 一坨 Markdown | 32 类带 schema 的底稿，可被下游模块引用 |

| 一致性 | 靠复查 | 36 种勾稽算子 + 交付 QA 阻断项 |