公益资源情报

把检索任务当作多通道机会发现与证据核验，不是单次关键词搜索。

意思是：你不能只在一个地方搜一次就算完。一个项目的招募信息可能发在官网，也可能只发在微信公众号，也可能只有政府网站登记了。要同时从多个渠道找，再把结果汇总、核实、去掉重复的，才算完成一次检索。

新手先看这里

如果你是第一次用这个工具，完全没有技术背景，先按这个顺序走一遍：

先读本文件开头和下面的"最小可复制请求"。 白话：先搞清楚这个工具能干什么，以及最基本的搜索任务长什么样子。
复制 examples/example-request.json，改成你的主题、地区和时间窗。 example-request.json 是一份填好的搜索"申请表"样本，里面写了搜什么主题、覆盖哪个地区、从什么时间到什么时间。你只需要把里面的内容换成你自己的需求，不用从零开始写。
运行下面这条命令，生成台账（检索记录表，记录每条搜索任务的执行情况）。 台账就像一张任务清单，列出这次搜索要查哪些渠道、用哪些关键词、搜哪些机构，确保你不遗漏任何该查的地方。先有台账，再开始搜索，这样每一步都有据可查。

python scripts/deep_search_guard.py plan --request request.json --output search-ledger.json --mode deep

如果要搜微信公众号，先记住优先级顺序： 微信不像普通网站那么好搜，有时候工具会被拦截。所以这里设计了三个备用方案，按顺序尝试——
- 第一选择：用 WebSearch 工具直接搜，发 site:mp.weixin.qq.com <关键词> 格式的查询。这是最稳定的方式，不容易被拦截。
- 第二选择（WebSearch 找不到结果时才用）：用 weixin_browser_search.py 脚本，它会模拟真实浏览器在百度上搜微信文章。
- 自动兜底：如果百度把脚本当机器人拦截了，脚本会自己切换到搜狗重新搜一次。
想看成品长什么样，直接打开 examples/example-results.json。 这个文件是一份已经搜好、整理好的结果样本，你可以直接打开看看最终会产出什么格式的内容，方便对照预期。

最小可复制请求

下面是一个最简单的搜索任务示例，把括号里的内容换成你自己的需求即可：

{
  "themes": ["儿童", "社区服务"],
  "opportunity_types": ["合作伙伴招募", "执行机构招募"],
  "publisher_types": ["基金会"],
  "audiences": ["社会组织", "社工机构"],
  "regions": ["全国"],
  "scope_mode": "thematic_search",
  "as_of_date": "2026-07-19",
  "time_window": {
    "start": "2026-01-21",
    "end": "2026-07-19"
  }
}

字段说明：themes（主题）、opportunity_types（机会类型）、publisher_types（发布方类型）、audiences（面向哪类申请人）、regions（地区）、scope_mode（检索模式，thematic_search 表示专题搜索）、time_window（时间窗口）。

你只要先记住三件事

先用 plan 命令生成台账（检索记录表），再开始搜索；顺序不能颠倒。
搜微信公众号时，先试 WebSearch 工具，没结果再用 Playwright（一种浏览器自动化工具）+ 百度，还不行最后兜底搜狗。
结果按"机会"来整理，同一个项目的信息合并成一条；不要把不同渠道找到的同一条信息重复列出。

核心原则

不能假设一个项目的招募信息会同时出现在官网、政府网站、媒体和微信公众号上。每个渠道要独立去查。
通用 Web 搜索、官网各栏目/站内搜索、PDF 等附件和申请系统、政府/公共平台、行业媒体、微信公众号，这些渠道应该同时并行查找，不能只查一个。
来源等级（信息来自哪里、可信度如何）、验证状态（信息有没有被核实）、生命周期（项目现在是开放还是关闭），是三个独立维度，要分开记录，不能混在一起。
同一个项目的官网、公众号、政府平台和媒体页面要合并成一条记录，所有来源和修改历史都要保留。
只有完成了覆盖审计（检查所有该查的渠道是否都查过了）之后才能提交结果；遇到渠道受阻、内容无法获取或日期有冲突，必须如实说明，不能隐瞒。
对于"全国所有基金会/全部机构"这类大范围任务，要切换到 nationwide_monitoring（全国持续监测）模式，不能把一轮 deep（深度）搜索说成覆盖完成了。

详细方法见 references/retrieval-and-verification-framework.md。

工作流

1. 明确任务边界

目的： 在开始搜索之前，先搞清楚这次到底要找什么——范围定清楚了，才不会漏查，也不会白查。

提取或合理补全：主题、地区、申请主体（谁来申请）、机会类型、时间窗（查哪段时间内发布的信息）、排除项（不需要的内容）、输出格式和检索深度。

默认检索"当前开放及最近 180 天"；普通任务用 deep（深度检索，覆盖全部 10 个查询族），窄范围快速核查用 focused（聚焦检索，只用前 4 个查询族），高价值尽调用 exhaustive（穷尽检索，最彻底）。不要因为用户只说"基金会合作项目"就只搜基金会官网，要多渠道并行。

2. 生成强制检索台账

目的： 在搜索之前先生成一张"任务清单"，把这次要查的所有渠道、关键词、机构都列出来，防止漏查，也方便事后审计。

台账（检索记录表，记录每条搜索任务的执行情况）是整个工作流的基础，不能跳过。

python scripts/deep_search_guard.py plan --request request.json --output search-ledger.json --mode deep

台账包含网页搜索、公众号搜索、逐月覆盖、机构下钻（对特定机构深入查找）和末尾补漏查询。执行规范见 references/deep-search-contract.md。

3. 多通道并行发现

目的： 从多个来源同时发现机会，避免只盯着一个渠道而漏掉重要信息。

至少覆盖以下七个渠道：

通用 Web 搜索（用机会相关关键词在搜索引擎上搜）；
发布主体官网的通知、项目、招募、资助、下载与归档栏目（直接去机构官网找对应页面）；
PDF、Word、Excel 附件和独立申请系统（很多项目把通知放在附件里，或有单独的申请入口）；
政府、民政、政府采购、慈善和社会组织公共平台（这些平台有时会登记基金会发布的信息）；
可信媒体和公益行业平台（公益时报、慈善中国等）；
微信公众号搜索与重点官方账号（见下方微信专门规则）；
历史项目反查（从往年项目出发，查今年有没有续期、新一期、延期或更正通知）。

使用 references/search-playbook.md 和 references/weixin-search-and-accounts.md 构造查询。

4. 动态机构下钻

目的： 从初步搜索结果里找出所有相关机构，再对每个机构分别深入查一遍，确保不漏掉任何发布主体。

从首轮结果中提取发布机构、联合主办方、承办平台、品牌项目名称和官方公众号账号，把它们加入搜索目标列表；然后按机构别名（机构可能有简称、曾用名等）分别搜索官网、附件、申请入口、公众号、历史批次和更正通知。

机构白名单（预先整理好的基金会名单）只用于提供初始搜索种子和规范化机构名称，不代表全量机构——白名单之外的机构也可能发布相关信息。见 references/foundations-whitelist.md 与 references/data-provenance.md。

5. 核验与分级

目的： 确保每条信息都来自真实可靠的来源，并按可信度分级，方便后续判断。

优先打开原始通知、项目页、申请入口和附件，核对：发布主体、项目名、年度/批次、申请人条件、地域范围、截止时间、申请方式、联系人及更正记录。

来源等级（信息来自哪里、可信度由高到低）：

T0：发布主体官网、官方项目页、官方申请系统。——最可信，信息直接来自发布方本身。
T1：政府、民政、政府采购及其他公共平台。——官方登记备案的平台，可信度仅次于发布方官网。
T2：已确认属于发布主体的官方公众号原文。——来自发布方官方运营的微信公众号，可信但需确认账号归属。T2 只表示官方微信来源，不自动代表信息完整。
T3：可信媒体、公益行业平台、可确认转载。——第三方媒体或平台转载的信息，来源本身可信，但内容可能不完整。
T4：聚合页（把多个来源汇总展示的页面）、搜索摘要（搜索引擎显示的摘录）、未确认账号、一般转载或正文不可得线索。——只能作为线索，必须找到原始出处才能使用。

注意：T3/T4 的信息经过 T0/T1 交叉核验之后，验证状态可以提升（说明信息更可靠了），但来源等级标注本身不变。

验证状态与链接规则见 references/link-verification-rules.md。

6. 结构化、去重与生命周期判断

目的： 把找到的所有信息整理成统一格式，去掉重复条目，并判断每个项目现在处于什么状态。

按 references/data-schema.md（数据结构规范）记录证据。去重时至少考虑以下几个维度：发布机构规范名、项目规范名、年度/批次、地域、截止日期和申请入口——这些都一样才算同一条，否则要分开记录。

生命周期状态值（每个项目当前处于哪个阶段）：

open——当前开放接受申请
closing_soon——即将截止（临近截止日期）
rolling——滚动接收（随时可以申请，没有固定截止日期）
date_unknown——截止日期不明（找不到明确的截止时间）
closed——已截止（申请窗口已关闭）
historical_lead——历史线索（往年项目，作为参考线索保留，今年是否开放尚不确定）
not_opportunity——非机会（搜到了但不是可申请的机会，如新闻报道、活动回顾等）

延期通知、更正通知和新批次信息写入 change_history（变更历史记录），不要覆盖原有证据。

7. 评分与排序

目的： 给每条结果打分，帮助你快速判断哪些机会最值得优先关注。

python scripts/calculate_resource_score.py --input results.json --output scored-results.json

评分只衡量证据质量（来源是否可靠）、时效（信息是否最新）、匹配度（与你的搜索需求是否吻合）和可申请性（申请条件是否明确），不预测中选概率。规则见 references/scoring-rules.md。

8. 覆盖审计

目的： 检查这次搜索是否真的覆盖了所有应该查的渠道，有没有漏查或受阻的地方，确认可以交付结果。

把查询记录、候选数、去重数、最终结果数和受阻渠道（哪些渠道没查成功）写回台账，然后运行：

python scripts/deep_search_guard.py audit --ledger search-ledger.json --output coverage-audit.json

只有当审计结果 can_finalize=true（可以收尾）时，才能宣称已完成本次约定范围内的检索。若未通过审计，要继续补搜，或明确说明当前交付的是部分结果，以及还有哪些缺口和阻塞原因没有解决。

9. 生成离线 HTML

目的： 把整理好的结果输出成一个可以在浏览器里直接打开的网页文件，方便分享、存档和离线查看。

python scripts/render_resource_page.py --input results.json --output gongyi-resources-YYYY-MM-DD.html

输出的 HTML 文件必须保留网页与公众号区块、来源标签、评分、截止状态、搜索、排序、筛选、覆盖说明和检索日期。格式见 references/html-output-spec.md。

微信专门规则

微信公众号的内容不像普通网页那样可以被搜索引擎直接抓取，所以需要特殊的搜索方式。这里采用三级优先级，从最稳定的方式到最后的备用方案，依次尝试（详见 references/weixin-search-and-accounts.md）：

WebSearch 工具（首选）——之所以优先用这个，是因为它走的是搜索接口而不是模拟浏览器，不容易被平台当成机器人拦截，稳定性最高。发送 site:mp.weixin.qq.com <关键词> 格式的查询。台账记录字段：execution=websearch_tool、search_method=websearch_site_query、search_engine=websearch_api。
weixin_browser_search.py（备用一）——仅在 WebSearch 返回 0 条结果或工具不可用时才启用。它通过 Playwright（浏览器自动化工具，让程序像人一样操作浏览器）模拟真实浏览器在百度上执行 site: 查询，能找到更多微信文章，但有时会被百度识别为机器人而拦截。台账记录字段：execution=browser、search_method=browser_site_query。
搜狗微信搜索（备用二）——搜狗有专门的微信文章搜索通道，是最后的兜底方案。由备用一脚本在百度失败时自动触发，不可以直接指定为主引擎。

其他不变规则：

blocked（被拦截）不等于 no_results（确实没有结果）；只有百度明确返回无结果时才记 no_results，被反爬拦截要记 blocked，两种情况要区分清楚。
搜索摘要只作候选线索，当正文页面打不开时，保留 content_pending（内容待获取）或 date_pending（日期待确认）的标记，不要自己补写或猜测事实。
台账必须记录实际执行了哪个通道，不能把"计划用某个方式"写成"实际已用某个方式执行"。

查询族

查询族（一组围绕同一主题、使用不同角度和关键词的搜索查询，目的是从多个方向覆盖同一类信息，避免因为措辞不同而漏掉结果）的使用规则：

focused 模式只使用前 4 个核心查询族；deep 与 exhaustive 模式使用全部 10 个查询族：

partner_recruitment——合作伙伴招募类查询
implementing_agency——执行机构招募类查询
grant_application——资助申请类查询
project_call——项目征集类查询
official——官方通知类查询
attachment——附件文件类查询
government——政府平台类查询
media——媒体报道类查询
renewal——续期/新批次类查询
correction——更正/延期类查询

每个查询族至少保留两条语义不同的查询（同一主题换不同关键词），确保覆盖面更广。附件查询要分别写成 filetype:pdf、filetype:docx、filetype:xlsx 三条独立查询，不要写成 filetype:pdf OR ... 合并成一条（合并的写法有时会漏掉结果）。

结果整理

同一个机会从多个渠道找到的信息合并为一条记录，所有来源写入 sources[] 字段。
延期通知、更正通知、新批次信息写入 change_history（变更历史），不要覆盖旧证据。
用 evidence_score（证据质量分）、relevance_score（相关度分）、urgency_score（紧迫度分）和 review_priority（人工复核优先级）来排序；不要把这几个分数加在一起变成一个综合总分，那样会丢失细节信息。
只要还有受阻渠道、待核实字段或未检查的机构，就不要说"全网已无遗漏"——这句话在完成覆盖审计之前永远不成立。

交付要求

每次交付必须同时提供以下内容：

检索日期、覆盖范围、时间窗和申请主体；
优先机会摘要，附可点击的原文链接和申请入口；
待核实条目、已截止信息、历史线索与排除项说明；
遇到的冲突、正文不可得的情况、验证码墙、登录墙和其他受阻渠道说明；
查询数量、下钻机构数、候选数、去重后数量、验证通过数和饱和状态；
明确声明"不能保证覆盖全部互联网或 100% 无遗漏"的边界说明；
可筛选离线 HTML 文件（用户有要求时提供）。

参考文件

方法框架：references/retrieval-and-verification-framework.md
深搜门禁：references/deep-search-contract.md
查询策略：references/search-playbook.md
微信通道：references/weixin-search-and-accounts.md
关键词体系：references/keywords-and-types.md
链接核验：references/link-verification-rules.md
数据结构：references/data-schema.md
评分规则：references/scoring-rules.md
HTML 规范：references/html-output-spec.md
端到端示例：references/end-to-end-example.md
便携测试：references/portable-setup.md