找到社区之后：一个来源目录的探索记录

想了解一个领域，常见的第一步是找社区、作者和公开资料。收集几个地址并不难，难的是之后的问题：它与我要了解的领域有关吗？能看哪些内容？有没有适合持续读取的入口？上次调查得到的结论，现在还成立吗？

“专业社区来源目录”就是围绕这些问题做的一次小范围探索。它保存来源、领域关联、观察通道和调查依据，让下游项目有条件地选择来源。第一轮试点在 2026 年 9 月完成。

链接清单少了哪些信息

一个地址能够打开，只说明这次访问拿到了响应。HTTP 200 可能是作品列表，也可能是登录提示或访问验证页面。即使能读到内容，也不能据此判断它有公开 API、能够读取回复，或者可以长期稳定观察。

因此，目录把三个判断拆开：

判断	要回答的问题	留下的依据
来源审核	这是相关的公开社区吗？	来源性质、领域相关性、公开阅读条件
通道调查	它提供哪些读取入口？	页面声明、官方说明、调查范围
通道验证	某个入口实际能读什么？	验证日期、读取条件、覆盖能力和限制

这三个判断可以处在不同阶段。来源已审核，通道仍可能待调查；通道有官方文档，也可能尚未实际读取。只放一个“可用”标签，会把这些差别抹掉。

来源目录的判断分三层：审核来源的相关性与公开阅读条件，调查官方通道，验证具体读取能力。每层分别保留依据、日期和范围，结果交给下游项目选择。 — 图 1 · 从一个地址，到有依据的来源记录。三层判断分别保存，不由一次请求自动升级。

用站酷做一个具体试点

试点选择了美工与视觉设计方向。2026-09-17 的调查访问了站酷首页和官方帮助中心：未登录时，首页可以看到字体、包装、品牌、海报等作品和作者入口；帮助中心提供作品上传、审核、推荐、评论等说明。这些内容支持将它登记为相关的公开作品交流来源。

首页 HTML 检查返回 HTTP 200，但没有发现 RSS/Atom 声明或开放 API 文档线索。访问“关于我们”页面时出现滑动验证，调查在这里停止。

因此，记录里保留了一个首页网页通道，能力只写到作品列表和标题的人工浏览。不能把“没有找到入口”改写成“全站没有接口”，也不能把“首页可以打开”改写成“已经可以自动采集”。

这个例子解释了为什么目录需要保存调查日期和范围：后续有新的官方说明，或者访问条件变化，可以在原记录上复核，而不用猜测之前的结论是怎样得出的。

用状态表达确定程度

通道记录使用四种状态。它们表达证据和验证进度，并不是简单的优劣排序。

状态	含义	下一步
unverified	发现候选入口，条件或能力待确认	核对官方依据和读取范围
documented	已有官方依据，尚未完成实际读取验证	按说明做最小验证
verified	在记录的条件下完成读取和范围核验	保留结果，按期复核
blocked	验证遇到访问限制或其他阻碍	记录原因，重新确认条件

来源也有自己的审核状态和日期，不能用通道状态代替。当前目录默认复核周期为 90 天，超过周期后提示需要复核；它不会把过去的验证结果当作永久有效。

这里还有两个需要保留的差别：还没调查和调查过但没发现不同；读取受阻和入口不存在也不同。这些差别会影响下一次应从哪里继续。

发现代理只寻找线索

逐个查看公开页面比较费时，因此项目增加了一个有限预算的观察链路发现代理。它读取入口中的标准声明和平台信号，输出候选及证据，报告不会自动修改目录。

发现代理从公开入口读取页面声明和平台信号，先检查访问策略，再在有限预算内验证候选；遇到限制停止。报告交给人工核对，之后才录入正式目录。 — 图 2 · 自动发现与正式登记之间，保留一次对依据和接入条件的核对。

默认实现只发起无凭证 GET，限定同源访问，每个入口最多 8 次实际请求、单次响应最多读取 1 MiB。遇到认证、限流或访问验证会停止后续请求。它不会盲目枚举接口路径，也不负责登录、定时采集或通知。

2026-09-18，项目对 Discourse 和 Flarum 的演示入口做了试验。页面中能识别出 Feed 或 API 根地址线索，但两站当时的 robots 规则都禁止通用 User-Agent 继续访问；代理没有读取后续候选。Discourse 入口在另一次运行中返回了 HTTP 500，程序也没有重试。

结果保留为候选证据，没有录入正式目录。这次试验说明，“发现了路径”和“验证了通道”需要分开。它也提醒了一个实现边界：这里的“代理”是按规则执行的发现程序，当前并没有接入大模型做动态决策。

目录与持续观察分开实现

项目采用 JSON 数据、原生静态页面和 Python 标准库工具。领域别名参与检索，语言、审核状态与通道条件用于筛选；不需要先搭建一个后台服务才能浏览目录。

它的职责止于来源目录、调查、最小验证和依据维护。订阅主题、跟踪帖子或回复、安排检查频率、发送通知，都由使用目录的下游项目处理。这样，一个来源的接入条件可以复用，而具体观察任务仍由各个应用定义。

在项目目录中，可以用这两条命令检查数据和页面线索：

# 在专业社区来源目录项目中运行
python3 scripts/validate_data.py
python3 scripts/check_channels.py --community zcool --timeout 10

第一个命令检查目录数据约束，第二个检查指定社区页面的通道线索。运行后还需要查看报告，不能只凭退出码把记录升级为“已验证”。

下一次扩展，先补什么

目前试点规模很小：美工与视觉设计、游戏技术美术两个领域词条，一条站酷来源；游戏技术美术还没有收录社区。这是一个能表达条件和依据的目录原型，尚不足以评价大规模维护成本。

我更倾向于先补少量真实来源，实际记录调查、复核需要的时间，再决定是否扩大范围。比起先增加很多链接，验证“别人能不能根据记录正确选择入口”更接近这个工具的目标。

依据与后续阅读

站酷首页与官方帮助中心：2026-09-17 调查时访问的页面。
Discourse 演示入口与Flarum 演示入口：2026-09-18 发现试验的对象；演示站线索未登记为正式来源。
项目文档：《数据说明与下游契约》《站酷调查：2026-09-17》《观察链路发现代理》和《工作记录》。