最近做了一次内容与数据采集能力的盘点。目标很朴素：把手头能调用的能力跑一遍，看看哪些可以直接取数，哪些需要登录，哪些要补配置，哪些已经坏了。真正开始以后，我发现这不是一次简单的“跑通率统计”，而是在给每项能力划边界。
我一开始想把结果压缩成一句话：14 项里有 9 项 ok。这个数字看上去很利落，也很容易让人产生“已经覆盖得差不多了”的感觉。后来复核时才发现，9 个 ok 里面混着校验器和重复封装，它们不能直接算成 9 个独立来源。能力盘点的第一步不是数成功，而是先弄清自己到底在数什么。
先把一次运行当成证据
这次盘点不是看目录里有没有文件，也不是看某个入口能不能返回退出码，而是让每项能力实际运行。对成功项，我同时记录耗时和返回内容：有的只用约 0.5 秒，有的要 48.5 秒；有的返回几条，有的返回 20 多条。它们都可以被标成 ok，但可用程度并不相同。
这件事表面上是测试工具，实际上是在确认“可用”这个词的含义。如果只记一个状态，后面的人会默认这些能力的速度、覆盖面和稳定性相近。实际调用时才发现某项要等很久，或者返回结构不足以支持下一步，盘点表就失去了提前提醒的作用。
所以我给每一项都留下几种证据：运行入口、耗时、返回条数或字段、凭据与登录依赖，以及失败发生在哪个阶段。结果形成了第一轮的分组：9 项 ok、1 项 login、2 项 key、2 项 broken。这个分组不是给能力盖永久印章，而是描述它在这次条件下被观察到的状态。
这也意味着，“能运行”只能回答当前条件下是否成功，不能替代对依赖条件的说明。把条件一起记下来，下一次才知道是复现能力，还是恰好复用了当时的环境。
失败不能都叫缺配置
最容易误判的地方，是把所有失败都归因于缺登录或缺密钥。这样做很省事，因为修复动作也很单一：去补一个配置，再跑一次。但不同失败背后的路完全不一样。
有一项趋势能力在两条调用路径上都没有顺利完成，一条表现为网络层错误，另一条卡在页面状态的时序上。有人据此推断“只改 1 行就好”；另一项能力枚举超时，看起来像缺少登录态。**没有经过修复和复验的故障，只能写成现象或推断，不能提前写成根因。**这不是故意把结论说得含糊，而是给后续排查保留正确的入口。故障发生在网络、时序、依赖还是身份条件，决定了下一次应该观察什么；如果一开始就贴错标签，后面的验证很可能只是在证明自己的猜测。
我选择保守记录，是因为“猜对了”不能替代验证。若把趋势能力直接放进“配置缺口”，后续会有人绕过时序排查；若把枚举超时直接放进“缺登录”，就可能把源码、网络和资源限制都漏掉。盘点应该帮助修复，而不是把猜测包装成任务清单。
这里还要区分“缺条件”和“已损坏”。缺条件意味着入口本身可能正常，只是当前环境没有登录态或密钥；已损坏则意味着即使条件齐全，代码或依赖也可能无法工作。两者都不能直接取数，但修复优先级、负责人和验证方式并不相同。
外部影响要先过门禁
有一项趋势雷达能力在本轮没有强行实跑。不是因为它已经坏了，而是它的运行需要确认外部影响：可能写入输出，也可能产生付费调用。没有完成确认，就不能把它和普通的只读采集放在同一条自动测试里。
这一步很容易被速度目标压过去。盘点看起来只差一次运行，如果为了凑齐 14 项结果直接执行，表格可能更完整，却把一次不可逆或有成本的动作混进了验证过程。如果不处理，后果不只是多出一个文件或一次费用，更会让“验证能力”和“触发外部行为”变成同一个动作，下一轮复跑时没人知道边界在哪里。
我把它记成“门禁结果”，而不是 broken。这个判断很重要：未实跑不等于运行失败，拒绝越过门禁也不等于能力不可用。一个成熟的盘点，应该允许“暂不运行”成为有证据的结论。
以后遇到类似入口，我会在状态里额外记录是否有外部副作用、是否需要人工确认、确认缺失时停在哪一步。这样即使没有输出数据，也能知道它为什么没有进入实跑，以及下一步需要补什么条件。
9 个 ok 不等于 9 个来源
第一轮结果出来后，数字很容易成为主角。9 个 ok 看起来像是 9 个采集源已经准备好，但第 3 轮复核把这个假设拆开了：其中有校验器，也有重复封装；原先列出的浏览器态能力，实际只有 3 个独立 skill。
这提醒我，能力、入口和来源是 3 个不同层次。一个来源可能被多个入口包装，一个入口也可能只是检查另一个入口是否可用。把它们平铺在同一张表里，数量会变大，覆盖范围却没有同步增加。
因此，盘点后必须做一次去重。先保留每个能力的独立来源，再标出运行入口和封装关系，最后才统计来源数量。这样可以同时回答 3 个问题：现在有多少能运行的入口，有多少真正不同的来源，还有多少能力只是复用或校验。
如果不拆这一层，后续规划会产生错觉。以为来源够多，就停止补齐覆盖；以为浏览器态很多，就忽略它们共享同一个登录依赖。真正要管理的不是表格里的行数，而是不同来源、不同条件和不同失败路径。
把状态写成可修复的地图
复核之后，修复入口被拆成几类：凭据配置、时序问题、源码导入错误和登录态。分类不是为了让表格好看，而是为了让下一步能直接行动。凭据类要查配置来源和加载方式；时序类要看调用先后和等待条件；导入错误要回到源码依赖；登录态则要确认浏览器环境是否存在、是否过期。
我会给每项至少留下一条“下一步能做什么”。例如，状态为 key 时，说明缺哪类密钥以及怎样验证加载成功；状态为 login 时，说明需要什么登录态，但不把“登录存在”当成已经可用；状态为 broken 时，写清失败阶段，而不是只写“运行失败”。这让状态从标签变成了修复地图。
方法上，我现在更愿意用一张分层记录来做能力盘点：先记独立来源，再记运行入口；先做低风险实跑，再记录外部影响门禁；对每项保存耗时和返回证据；最后做去重，并把已验证事实、合理推断和待复验项分开。盘点的价值不在于给出一个漂亮的成功率，而在于让每个结论都能回到证据和下一步。
这件事让我重新意识到，工具真正改变的不是速度，而是我们愿不愿意把判断过程留下来。一次运行可以告诉我“现在发生了什么”，一张有层次的记录才能告诉下一次的人“为什么这样判断、还能怎样继续”。一个流程成熟的标志，不是它能跑通一次，而是它能在下次少依赖临场记忆。
下次我会怎么做
下次再做类似盘点，我会先定义统计单位：能力、入口、来源和封装分别记，不把它们混成一个数字。然后为每项设置统一字段，包括状态、耗时、返回证据、登录或密钥依赖、外部副作用门禁和失败阶段。
运行时，我会先做低风险项目，把只读结果保存下来；遇到需要确认外部影响的项目，先停在门禁，不用“未实跑”替代“已失败”。遇到异常，也不会马上给出修复结论，而是先记录现象，再安排针对性的复验。
最后我会做一次去重和分类复核：9 个 ok 到底对应多少独立来源，哪些只是重复封装，哪些仍然只是合理推断。这样交付出去的不是一张成功数排行榜，而是一张可继续使用的能力地图。它能告诉我现在能做什么，也能诚实地告诉我，哪里还不能下结论。