基金会尽职调查 Skill

版本：10.0.0

输入：基金会/社会组织名称输出：1个Markdown文件（禁止输出Word和PDF）

版本说明

v10.0.0 — 「实时状态画像」全面升级（解决"报告看起来旧、全是历史数据"的体感问题）

核心解决问题： 虽然v9.3.0解决了"数据沉睡"（采集到的数据都用上了），但整体报告给人的感觉还是"旧"——核心数据都是两三年前的，读者需要翻很多页才能看到一点新信息。用户的体感是："这都是以前的数据，有什么用？"

🔴 核心变革：从"按检查点填历史数据"转向"以当前状态为核心的实时画像"

具体更新内容：

首创「当前状态快照」章节 — 报告第2章（紧跟基本信息），用一页纸4个维度（财务/项目/治理/声誉）呈现基金会的"现在时"状态，让读者第一眼就能看到最新信息：
- 财务状态：最新捐赠收入、公益支出、净资产趋势
- 项目状态：在运行项目数、最新重大项目、支出结构
- 治理与团队：理事会届数、团队规模、最新人事变动
- 资质与声誉：核心资质有效期、近期荣誉、舆情状态
新增「动态信息采集」模块（step0第7大类数据） — 打破"只有年报/审计才是数据"的思维，将实时动态信息列为核心数据源：
- 6大类动态：项目动态、合作动态、资质荣誉、人事变动、重要活动、舆论评价
- 数据来源：官网新闻、项目页、搜索结果、媒体报道等
- 强制要求：每类动态都必须采集，没有也要明确标注"未查询到"
数据时效优先机制再强化 — 所有数据能找到多新就用多新：
- 审计数据（最可靠但最旧）→ 年报 → 官网公示 → 新闻报道（最新但可信度递减）
- 不同可信度的数据分层标注，不混为一谈
- 快照章节强制要求：不能全是2023年及以前的数据
报告结构从13章扩展为14章 — 新增"当前状态快照"为第2章，原有章节顺延：
- 一、基本信息
- 二、🔴 当前状态快照（新增）
- 三、合规尽调
- 四、项目效能尽调
- ...（后续章节顺延）
v10.0质量门禁（step3新增4项检查）：
- 快照章节是否存在？没有=不合格
- 快照是否用了最新数据？全是旧数据=不合格
- 动态信息是否被引用到对应检查点？采集了不用=数据沉睡
- 报告章节数是否为14章？

v9.3.0 — 「数据-检查点映射机制」全面上线（解决"数据沉睡、查到了但不用"顽疾）

核心解决问题： 数据都采集到了（审计、年报、章程、slideset、搜索、会议纪要），但大量数据躺在中间文件里没人用，检查点只用了一小部分数据，尤其是项目效能模块还在用旧年度数据。

🔴 核心变革：从"填完检查点就行"升级为"每个数据都要找到它的检查点"

具体更新内容：

首创「数据-检查点映射清单」 — step0数据采集完成后，自动生成12类数据到检查点的映射关系，让agent一目了然知道"哪些数据该用到哪些检查点"：
- 最新年度审计数据 → 37/38/40/41/21/62
- 最新专项审核数据 → 55/56/31/38/57-61
- slideset最新数据 → 37/38/40/41/47/55/56/62
- 最新版章程 → 4/5/6/8/13/19/42
- 最新理事会会议纪要 → 8/12/4/5
- 最新年度工作报告 → 52-63全部
- 官网网页数据 → 16/45/47/52-57
- 免税/税前扣除公告 → 34/65
- 评估等级信息 → 65
- 全网舆情搜索 → 68/69/50/51
- 慈善中国登记信息 → 1/4/43
step1填写前强制准备工作 — 三步法确保数据不沉睡：
- 第一步：确认年度数据可用性（7个关键年度信息）
- 第二步：标记8个"数据沉睡重灾区"检查点
- 第三步：对照映射清单做预检查
数据利用率专项检查（step3新增） — 从输出端倒逼数据充分利用：
- 12项数据类别逐一核对是否已引用
- 数据利用率计算公式：已引用项数 ÷ 总项数 × 100%
- 利用率 < 60% = 不合格，必须返工
- 利用率 ≥ 80% = 优秀
8大数据沉睡顽疾识别 — common-errors.md新增第10类：
- 项目效能模块只用旧年度数据
- slideset数据只写1-2处
- 最新版章程数据不更新
- 理事会会议纪要不要白不要
- 官网网页数据抓了但不用
- 搜索结果只写"未发现"不写过程
- 数据"前后打架"不自检
- "待核实"当万能膏药（与v9.2.0联动）
4项新顽疾纳入质量检查（P34-P37）：
- P34：项目效能模块数据过时
- P35：slideset数据只写了1-2处
- P36：最新章程数据未充分利用
- P37：数据利用率低于60%

v9.2.0 — 「证据链整合判断」全面升级（解决"查到数据但不会用、大量待核实"顽疾）

核心解决问题： 数据都采集到了（审计报告、年报、章程、slideset、搜索结果），但检查点大量标"待核实"，不会用已有数据做合规判断。

🔴 核心变革：从"单个证据→单个判断"升级为"证据链整合→系统判断"

具体更新内容：

三大核心判断原则 — 彻底扭转"完美主义"思维：
- 无相反证据推定合规：没有证据证明违规 = 符合（不是待核实）
- 优势证据原则：多个独立来源都指向合规 = 符合
- "待核实"严格限定：只能用于3种情况（关键证据缺失、证据重大矛盾、官方结论不明）
证据链整合判断速查表 — 告诉agent"有什么证据就能判哪些点符合"：
- 有审计报告无保留意见 → 21/37/38/40/41 等财务检查点直接判符合
- 有年度工作报告且完整 → 8/11/18/44/45/47/52-56 等直接判符合
- 有章程且条款完备 → 6/13/19/28 等直接判符合
- 搜索未发现处罚/诉讼 → 50/51 直接判符合
- 官网有信息公开栏目 → 43/45/47 等直接判符合
高待核实率模块专项判断标准 — 针对重灾区给出明确判断规则：
- 模块3（项目合规）：11个检查点逐一明确"什么情况判符合"
- 模块5（信息公开）：7个检查点逐一明确"什么情况判符合"
- 模块6（诉讼仲裁）：明确"搜索未发现 = 符合"，不是"待核实"
质量检查强化 — 新增5项顽疾检查 + 4项格式自检：
- 待核实比例不得超过30%（合规尽调51个检查点）
- 模块3待核实不能超过2-3个
- 模块5不能全部待核实
- 模块6做了搜索就不能写待核实
- 有审计报告财务相关点就不能写待核实
- 有年报信息公开相关点就不能写待核实
常见错误清单扩充 — 新增4大顽疾（P34-P37）：
- "待核实"滥用（最严重）
- 搜索未发现 = 待核实？
- 有审计报告但财务检查点还写待核实
- 有年度报告但信息公开检查点还写待核实

预期效果： 合规尽调"待核实"比例从50-70%降到20-30%，数据利用率大幅提升，报告更有实际参考价值。

v9.1.0 — 官网全站数据抓取 + 全网舆情搜索强化（解决数据来源单一、舆情缺失问题）

核心新增两大能力补强：

官网全站内容全面抓取 — 不再局限于信息公开页的PDF和slideset，而是从sitemap.xml入手，抓取所有栏目下的网页内容：
- 捐赠公示（逐笔捐赠记录，可能比slideset更新更全）
- 项目介绍（项目支出明细、项目成果）
- 治理结构（理事会成员、监事会）
- 章程制度（最新章程、内部管理制度）
- 年检年审（各年度年检结果）
- 资质荣誉（获得的各项荣誉）
- 党建园地（党建工作信息）
- 年度数据可用性地图中新增"官网网页"数据源类别
全网舆情与法律风险搜索 — 彻底解决"未进行全网媒体报道搜索"的问题：
- 明确："本地文件环境"≠"断网模式"，只要有搜索能力就必须搜
- 至少5组关键词组合搜索，覆盖正面、负面、争议、主流媒体、自媒体等
- 法律风险搜索：行政处罚、诉讼仲裁、失信被执行人
- 搜索结果必须写入报告，不能只存在中间文件里

具体更新内容：

step0-data-collection.md：新增0.2.3节（各栏目网页抓取）、强化0.5节（舆情与法律风险搜索）
step0-data-collection.md：年度数据可用性地图新增网页版数据源（11种新数据类型）
step0-data-collection.md：数据完整性自检新增3项检查（网页内容、舆情搜索、法律风险）
step3-quality-check.md：新增P26-P29共4项质量检查点
references/common-errors.md：新增第30-33条顽疾（网页遗漏、不搜索、敷衍搜索、搜了不用）
scripts/consolidate_ocr.py：默认年份改用系统当前年份，避免硬编码过时

v9.0.0 — 彻底重构为「时效优先」数据展示机制（废除A/B级分层，解决层级颠倒、查到不引用两大核心顽疾）

核心解决问题： 数据都采集到了（审计报告、年报、章程、slideset、搜索结果），但检查点大量标"待核实"，不会用已有数据做合规判断。

🔴 核心变革：从"单个证据→单个判断"升级为"证据链整合→系统判断"

具体更新内容：

三大核心判断原则 — 彻底扭转"完美主义"思维：
- 无相反证据推定合规：没有证据证明违规 = 符合（不是待核实）
- 优势证据原则：多个独立来源都指向合规 = 符合
- "待核实"严格限定：只能用于3种情况（关键证据缺失、证据重大矛盾、官方结论不明）
证据链整合判断速查表 — 告诉agent"有什么证据就能判哪些点符合"：
- 有审计报告无保留意见 → 21/37/38/40/41 等财务检查点直接判符合
- 有年度工作报告且完整 → 8/11/18/44/45/47/52-56 等直接判符合
- 有章程且条款完备 → 6/13/19/28 等直接判符合
- 搜索未发现处罚/诉讼 → 50/51 直接判符合
- 官网有信息公开栏目 → 43/45/47 等直接判符合
高待核实率模块专项判断标准 — 针对重灾区给出明确判断规则：
- 模块3（项目合规）：11个检查点逐一明确"什么情况判符合"
- 模块5（信息公开）：7个检查点逐一明确"什么情况判符合"
- 模块6（诉讼仲裁）：明确"搜索未发现 = 符合"，不是"待核实"
质量检查强化 — 新增5项顽疾检查 + 4项格式自检：
- 待核实比例不得超过30%（合规尽调51个检查点）
- 模块3待核实不能超过2-3个
- 模块5不能全部待核实
- 模块6做了搜索就不能写待核实
- 有审计报告财务相关点就不能写待核实
- 有年报信息公开相关点就不能写待核实
常见错误清单扩充 — 新增4大顽疾（P34-P37）：
- "待核实"滥用（最严重）
- 搜索未发现 = 待核实？
- 有审计报告但财务检查点还写待核实
- 有年度报告但信息公开检查点还写待核实

预期效果： 合规尽调"待核实"比例从50-70%降到20-30%，数据利用率大幅提升，报告更有实际参考价值。

v9.0.0 — 彻底重构为「时效优先」数据展示机制（废除A/B级分层，解决层级颠倒、查到不引用两大核心顽疾）

🔴 核心变革：废除「A/B级」分层逻辑，启用「时效权重」系统

旧机制的根本问题：把"审计报告"定为A级（最高优先级），"slideset"定为B级（补充），导致2024年的旧数据永远压在2026年新数据上面，用户打开报告第一眼看到的是两年前的情况。

新机制核心逻辑：

时效权重 > 数据级别：哪年数据最新，哪年就放在最前面（C位），不管它来自slideset还是审计报告
数据角色重新定义：
- Slideset → 🔴 现状快照：描述"现在"的运营状态，永远放最前面
- 审计报告 → ✅ 合规基准：用于计算法定比例、证明合规性，按年度倒序排列
- 理事会纪要 → 🔴 最新事实依据：事实判断以最新来源为准
强制映射机制：Step 0采集到的所有年度数据，Step 1必须在对应检查点中引用，禁止"查到不引用"

🔴 具体更新内容：

step0-data-collection.md 强化：
- 新增「数据角色定义」表格，明确每个数据源的定位和展示优先级
- 新增「强制映射检查」7项承诺，作为Step 0→Step 1的连接桥
- 数据完整度分类从"A/B级"改为"审计/slideset/预算/累计"等更精准的描述
step1-fill-checkpoints.md 核心重写：
- 彻底废弃"第一层/第二层""A级/B级"表述
- 新增「时效优先的数据展示机制」专章，含：
  - 数据角色重新定义表
  - 三条铁律（最新在C位、不跳年份、合规判断单独说明）
  - 强制映射规则（解决"查到数据不引用"顽疾）
  - 各检查点具体执行标准（40/41/62/37/38/55/56/7/8等）
  - 数据块标准格式
- 六大铁律新增第6条：禁止金额数据前后矛盾
step2-generate-report.md 更新：
- 数据使用规则从"A/B级"改为"角色定位"描述
- 强制要求从19条增至21条，新增：
  - 强制映射（年度数据可用性地图的数据必须全部引用）
  - 检查点62必须用最新数据开头（现状描述在先）
- 新增检查点40/41/62的标准展示格式和示例
- 所有数据块标注格式统一为：年度/时间段 + 来源 + 数据性质 + 完整度
step3-quality-check.md 强化：
- 专项检查更名为「时效优先机制专项检查」
- 新增D16：年度数据可用性地图中的数据是否都在检查点中展示
- 新增D17：检查点62是否用最新数据开头
- 新增D18：合规判断是否单独说明并标注依据年度
- 顽疾从22大增至25大，新增：
  - P23：金额数据前后不一致
  - P24：子项相加不等于总项
  - P25：单位混用
common-errors.md 扩充：
- 顽疾从22大增至29大
- 新增第28条：查到数据不引用（Step 0采集了但Step 1不用）
- 新增第29条：检查点62用历史数据开头，不说现状
- 更新第21/27条的表述，去除A/B级概念

v8.6.0 — 金额数据准确性全面强化（解决"数据不准确、前后不一致、计算错误"问题）

🔴 解决的核心问题：

金额数据前后不一致：同一捐赠收入/公益支出/净资产在不同检查点数值不同，有的用元有的用万元
子项相加不等于总项：各项目支出加起来不等于慈善活动支出总额，各项目占比加起来不等于100%
计算错误：公益支出比例、管理费用比例、增长率等计算有误，或直接抄原始文档不验证
单位混用：报告中"元"和"万元"混用，读者容易看错
数据来源不明：只放数字不标注来源，无法追溯验证

🔴 核心改变 — 建立「金额数据四重保障机制」：

| 保障层级 | 机制 | 作用 | |---------|------|------| | 第一层 | 源头统一 | 所有财务数据统一从中间文件取值，避免各检查点各自OCR导致不一致 | | 第二层 | 格式规范 | 全文统一用"元"为单位，大额加千分位，小数位数统一 | | 第三层 | 计算校验 | 所有比例、增长率必须自己重新计算，禁止直接抄原始文档 | | 第四层 | 交叉验证 | 子项相加必须等于总项，同一数据在不同检查点必须完全一致 |

🔴 具体更新内容：

step1填写检查点：
- 六大铁律新增第6条：禁止金额数据前后矛盾
- 新增「金额数据准确性保障机制」专章，含：
  - 数据交叉验证机制（三级来源验证）
  - 单位与格式规范（统一用"元"、千分位、小数位数）
  - 计算准确性强制要求（所有比例必须自己算）
  - 常见金额数据错误与防范（5类典型错误）
step2生成报告：
- 强制要求从15条增至19条，新增：
  - 金额单位统一用"元"，禁止混用
  - 所有比例和增长率必须自己计算
  - 子项相加必须等于总项
  - 同一金额在不同检查点必须完全一致
step3质量检查：
- 顽疾从22大增至25大，新增：
  - P23：金额数据前后不一致
  - P24：子项相加不等于总项
  - P25：单位混用
- 新增「金额数据准确性专项检查」专章，15项检查全覆盖：
  - 单位/格式/小数位数统一检查
  - 公益支出比例/管理费用比例计算校验
  - 项目支出合计/占比合计校验
  - 捐赠收入/公益支出/净资产一致性校验
  - 增长率计算校验
  - 预算/累计数据标注检查
  - 数据来源可追溯检查
- 所有专项检查项一票否决，不通过即报告不合格
common-errors顽疾清单：
- 从22大顽疾增至27大顽疾
- 新增5条金额数据准确性顽疾：
  - 第23条：金额数据前后不一致
  - 第24条：子项相加不等于总项
  - 第25条：单位混用
  - 第26条：比例/增长率计算错误
  - 第27条：数据来源不标注

v8.5.0 — 彻底重构为「按年度倒序」数据展示机制（解决"旧数据占C位"和"跳年份"两大核心问题）

🔴 解决的核心问题：

旧数据占C位：原"双层数据展示"机制把A级审计数据固定放第一层（最显眼位置），导致用户打开报告第一眼看到的是两年前的旧数据，最新的slideset数据藏在第二层
跳年份：数据展示直接从2026跳到2024，中间的2025年数据完全缺失，逻辑断裂

🔴 核心改变 — 废弃"双层"，改用"按年度倒序"：

| 维度 | v8.3.0旧机制（双层） | v8.5.0新机制（年度倒序） | |------|---------------------|-----------------------| | 排序逻辑 | 按级别分层（A级永远在第一层） | 按年度倒序（最新年份永远在最前面） | | 层级关系 | 第一层 = A级 = 旧数据<br>第二层 = B级 = 新数据 | 不分层，所有年度按时间倒序排列 | | 用户第一眼 | 看到2-3年前的旧数据 | 看到最新的情况 | | 年度连续性 | 跳年份（只展示最新B级和最旧A级，中间空白） | 连续展示（有2026就有2025，然后才是2024） | | 每个数据块标识 | 无统一标识 | 必须标注：年度 + 级别（A/B） + 来源 + 完整度 |

🔴 具体更新内容：

核心机制重写：
- 彻底废弃"第一层/第二层"的表述和逻辑
- 所有涉及多年度数据的检查点，全部采用"按年度倒序"展示
- 最新年度数据永远在最前面（C位），不管来源是审计报告还是slideset
- 连续年度不能跳（有2026和2024的数据就必须带上2025年）
step1填写检查点：
- 顶部核心机制从"双层数据展示"改为"按年度倒序数据展示"
- 四条铁律：最新数据放C位、不跳年份、每层标身份、合规判断单独说明
- 检查点40/41：从"第一层审计数据+第二层slideset"改为"按年度倒序排列所有可用数据"
- 检查点55/56：从"双层展示"改为"按年度倒序展示所有年度数据"
- 检查点52-61/62-63：全部改为按年度倒序展示
- 年度数据确认表格14项全部更新为"按年度倒序展示"要求
step2生成报告：
- 数据使用规则从"双层机制"改为"按年度倒序数据展示机制"
- 强制要求从12条增至15条，新增：每个数据块必须标注完整身份、禁止旧数据在前、禁止跳年份
- 所有数据类型的展示要求统一更新为"按年度倒序排列"
step3质量检查：
- 专项检查从"双层数据展示机制检查"改为"按年度倒序数据展示检查"
- 检查项从12项增至15项，核心新增：
  - D14：是否存在"旧数据放最前面、新数据藏后面"的情况
  - D15：是否存在"跳年份"的情况
- 两项核心检查为一票否决项，出现即不合格
common-errors顽疾清单：
- 从20大顽疾增至22大顽疾
- 新增第21条：旧数据占C位（最新数据藏后面）
- 新增第22条：跳年份（如从2026直接跳到2024）
- 原有第20条（预算当实际支出）的表述同步更新为新机制

v8.3.0 — 双层数据展示全检查点覆盖（解决"别的点也需要最新数据"问题）

解决的核心问题： v8.2.0只升级了40/41/55/56等少数核心检查点，但用户反馈"别的需要最新年份信息的点也得弄"，还有很多检查点（52/53/54/57-61/62/63/7/8等）也需要体现最新数据。

核心改进 — 双层数据展示机制从"核心4点"扩展到"全检查点覆盖"：

| 类别 | 涉及检查点 | 升级内容 | |------|-----------|---------| | 财务核心 | 40、41 | ✅ 已在v8.2.0升级 | | 项目支出 | 55、56 | ✅ 已在v8.2.0升级 | | 项目概况 | 52、53、54 | ✅ 本次新增双层展示 | | 成本效益 | 57、58、59、60、61 | ✅ 本次新增双层展示 | | 可持续性 | 62、63 | ✅ 本次新增双层展示 | | 捐赠/披露 | 37、38、47 | ✅ 本次强化明确要求 | | 组织架构 | 7、8、9、10 | ✅ 本次新增"最新信息优先"机制 | | 资质信息 | 34、65 | ✅ 本次新增"最新资质优先"机制 |

具体更新内容：

step0数据采集：
- 年度数据可用性地图升级为「数据类型 × 数据源 × 涉及检查点」三维表格
- 新增9种数据类型的完整度定义和对应检查点映射
- 确保每个检查点都知道自己应该用什么数据、有没有更新数据
step1填写检查点：
- 检查点52/53/54（项目概况）：新增双层展示要求，A级（年报）+ B级（slideset最新数据）
- 检查点57-61（成本效益）：新增双层展示要求，A级（年报/专项审核）+ B级（slideset最新数据）
- 检查点62/63（可持续性）：新增双层展示要求，A级（年报/审计）+ B级（slideset最新数据）
- 检查点7（党建）：新增双层展示要求，如有更新信息必须补充
- 检查点8/9/10（理事会/监事/机构）：新增"会议纪要优先于年报"的最新信息机制
- 检查点34/65（资质）：新增"最新有效资质优先"机制
- 年度数据确认表格从10项扩展到14项，全部标注"是否必须展示slideset数据"
- 最容易犯的错误从4条增至9条，覆盖所有检查点类型
step2生成报告：
- 数据类型从6种扩展到9种，新增年度工作报告、理事会会议纪要、搜索获取的最新资质
- 强制要求从10条增至12条，明确所有相关检查点都必须展示slideset最新数据
- 每个数据类型都明确标注了涉及的检查点编号
step3质量检查：
- 顽疾P5覆盖范围从7个检查点扩展到17个检查点
- 双层数据专项检查从6项增至12项，覆盖所有类型的检查点
- 新增D5-D8检查项目概况、成本效益等检查点的双层展示
- 新增D9检查理事会信息是否使用了最新会议纪要
- 新增D12检查党建和可持续性检查点的最新数据使用

预期效果： 所有需要年度数据的检查点都能体现最新可得信息，用户不再需要指出"这个点也需要最新数据"——从"被动修补"升级为"主动全覆盖"。

v8.2.0 — 双层数据展示体系升级（核心解决"数据看不到"问题）

解决的核心问题： slideset采集到了最新数据，但在核心检查点（40/41/55/56）没有体现，用户看到的还是旧年度审计数据，感觉"时间落后"、"数据看不到"。

核心改进 — 建立「双层数据展示机制」：

| 层级 | 数据类型 | 级别 | 用途 | 展示位置 | |------|---------|------|------|---------| | 第一层 | 审计报告/专项审核报告完整年度数据 | A级 | 正式合规判断、比例计算 | 检查点40/41/55主要数据 | | 第二层 | slideset最新数据（完整年度/部分月份） | B级 | 补充展示最新动态 | 检查点40/41/55/56查询结果中补充 |

具体更新内容：

step0数据采集：年度数据可用性地图增加「数据完整度」维度，区分A级（审计）、B级（slideset）、预算、累计等不同类型，明确各自使用边界
step1填写检查点：
- 检查点40/41：必须同时展示审计报告2个年度数据（第一层）+ slideset最新动态（第二层）
- 检查点55/56：必须优先展示专项审核报告实际支出（第一层）+ slideset项目级实际支出（第二层），预算只能作为补充且必须标注
- 新增「预算数据铁律」：预算绝对不能当实际支出展示，必须明确标注
step2生成报告：数据使用规则升级为双层数据展示体系，6种数据类型各有明确使用规范
step3质量检查：
- 二十大顽疾新增P20「预算当实际支出」
- 新增「双层数据展示机制专项检查」（D1-D6），确保核心检查点都有最新数据
common-errors.md：顽疾从19条增至20条，每条增加「根源」列，新增第20条「预算当实际支出」顽疾

预期效果： 用户在核心检查点就能看到从审计报告的权威数据到slideset的最新动态，不再出现"明明有数据却看不到"的情况。

一、输出规范

1.1 只输出1个Markdown文件

文件名：{基金会名称}尽职调查报告.md 不要生成.docx，不要生成.pdf，不要调用格式转换代码。只要1个.md文件。

1.2 报告结构（13个章节，严格按此顺序和编号）

一、基本信息
二、合规尽调（检查点1-51）
   模块1 组织资格与历史沿革（1-7）
   模块2 组织架构（8-10）
   模块3 项目合规（11-21）
   模块4 财务合规（22-42）
   模块5 信息公开（43-49）
   模块6 诉讼仲裁（50-51）
三、项目效能尽调（检查点52-63）
   模块7 项目概况（52-56）
   模块8 成本效益分析（57-61）
   模块9 可持续性（62-63）
四、组织生态评估（检查点64-67）
五、舆情（检查点68-69）
六、合规性统计表
七、项目效能统计表
八、组织生态与舆情统计表
九、综合评价（分4小节：组织概况/合规表现/项目效能/主要风险）
十、疑点与风险提示
十一、风险提示（高/中/低分三级，每级用表格）
十二、改进建议（表格格式）
十三、编制依据（所有数据来源URL列表）

1.3 检查点表格

7列：序号 | 检查项 | 查询结果 | 数据来源 | 合规判断/效能评级 | 判断依据 | 备注

序号1-69连续，检查项名称用framework.md原文
合规判断用文字："符合""待核实""不符合""不适用"，禁止用✅⚠️❌➖符号
效能评级用：优秀、良好、一般、较差
查询结果写具体事实和数据，不写空话
数据来源写具体URL或PDF文件名+页码

1.4 基本信息表

基金会名称、统一社会信用代码、登记管理机关（写最新变更后的名称）、法定代表人、成立时间、注册资金、业务范围、公募资格、官网地址、联系电话、发起方、党员人数/党建情况

党建写法必须包含两项：①党员人数 ②是否建立独立党组织示例："党员2人，未建立独立党组织"

二、执行流程（严格按顺序，禁止跳步）

本Skill分为4个步骤，每个步骤有独立的指令文件。必须严格按顺序执行。

步骤0：数据采集 → 读取 steps/step0-data-collection.md → 产出中间文件 {基金会名称}-数据采集结果.md（🔴必须包含"年度数据可用性地图"） 步骤1：填写检查点 → 读取 steps/step1-fill-checkpoints.md → 🔴先读取年度数据可用性地图确认年份 → 填写69个检查点 步骤2：生成报告 → 读取 steps/step2-generate-report.md → 生成完整报告Markdown 步骤3：质量自检 → 读取 steps/step3-quality-check.md → 自检通过后保存.md文件

关键规则：

禁止跳步。禁止在未完成步骤0的情况下开始步骤1。
步骤0必须产出中间文件，步骤1必须先读取中间文件再填检查点。
每个步骤开始前必须先读取对应的步骤文件，不能凭记忆执行。
🔴 步骤0只使用agent原生工具（search_web、fetch_web、parse_file、read_image、bash），不依赖Python脚本。脚本可作为可选辅助，但核心流程必须能用原生工具独立完成。
🔴 步骤1有"五条铁律+数据缺口闭环规则+年度数据可用性确认+交叉检查+合规率公式"，步骤3有"十九大顽疾检查"，必须逐条通过后再保存文件。

二点五、脚本工具（可选辅助）

步骤0的数据采集优先使用agent原生工具（search_web、fetch_web、parse_file、read_image、bash）。

以下5个Python脚本作为可选辅助工具提供。如果agent运行环境支持Python且有相关依赖（pdfplumber、Pillow等），可以使用脚本提高效率；如果环境不支持，跳过脚本，使用原生工具完成相同功能。

| 序号 | 脚本 | 用途 | 输入 | 输出 | |------|------|------|------|------| | 1 | scripts/fetch_bodyjs.py | 从Body.js提取slideset图片和PDF链接 | Body.js URL + Referer URL | bodyjs_results.json | | 2 | scripts/ocr_images.py | 百度OCR识别所有slideset图片 | bodyjs_results.json + OCR凭证 | ocr_results.json | | 3 | scripts/consolidate_ocr.py | 按年度整合OCR结果 | ocr_results.json | ocr_consolidated.json | | 4 | scripts/download_pdfs.py | 下载所有PDF（带Referer头） | bodyjs_results.json + Referer + 域名 | pdfs/ + pdf_download_results.json | | 5 | scripts/extract_project_details.py | 从审计报告提取项目级支出+财务汇总 | pdfs/ | project_details.json |

🔴 脚本不可用时，使用以下原生工具替代：

脚本1→ bash curl + grep提取URL
脚本2→ read_image逐张OCR
脚本3→ 手动按年度汇总OCR结果
脚本4→ bash curl -L -H "Referer: ..." 下载PDF
脚本5→ parse_file + read_image OCR

三、参考文件

69个检查点框架：references/framework.md
合规判断标准：references/evaluation-criteria.md
数据源与搜索策略：references/data-sources.md
报告模板：references/report-template.md
常见错误案例：references/common-errors.md

fpundation due diligence

基金会尽职调查 Skill

版本说明

v10.0.0 — 「实时状态画像」全面升级（解决"报告看起来旧、全是历史数据"的体感问题）

v9.3.0 — 「数据-检查点映射机制」全面上线（解决"数据沉睡、查到了但不用"顽疾）

v9.2.0 — 「证据链整合判断」全面升级（解决"查到数据但不会用、大量待核实"顽疾）

v9.1.0 — 官网全站数据抓取 + 全网舆情搜索强化（解决数据来源单一、舆情缺失问题）

v9.0.0 — 彻底重构为「时效优先」数据展示机制（废除A/B级分层，解决层级颠倒、查到不引用两大核心顽疾）

v9.0.0 — 彻底重构为「时效优先」数据展示机制（废除A/B级分层，解决层级颠倒、查到不引用两大核心顽疾）

v8.6.0 — 金额数据准确性全面强化（解决"数据不准确、前后不一致、计算错误"问题）

v8.5.0 — 彻底重构为「按年度倒序」数据展示机制（解决"旧数据占C位"和"跳年份"两大核心问题）

v8.3.0 — 双层数据展示全检查点覆盖（解决"别的点也需要最新数据"问题）

v8.2.0 — 双层数据展示体系升级（核心解决"数据看不到"问题）

一、输出规范

1.1 只输出1个Markdown文件

1.2 报告结构（13个章节，严格按此顺序和编号）

1.3 检查点表格

1.4 基本信息表

二、执行流程（严格按顺序，禁止跳步）

二点五、脚本工具（可选辅助）

三、参考文件