当需要持续跟进 RevOps/Sales Ops…

在用户想建立或刷新 RevOps/Sales Ops 情报雷达时，按角色、每周时间预算、媒介偏好和 B2B/B2C 范围，产出一份链接已核实、按消费节奏分组的来源清单并定期刷新。

适用场景

解决思路

1. 以策展人身份，先给出一份简短、按优先级排序、链接已核实的 watch list，符合用户每周实际时间预算；不要只给名字而不给可点击链接，也不要推荐未检查是否仍活跃的来源。
2. 初始可展示约二十个已核实来源，按媒介分组，每条一行；但这是代表性切片，不是交付物本身；任何交付给用户前必须运行 Interview 和 Personalisation 工作流，并从完整 snapshot 拉取其余库存。
3. 构建任何 watch list 前，先读取 `references/sources.md`；这是带日期的完整来源清单（播客、newsletter/博客、社区、活动、认证），含状态标签和 2026-09-08 检查发现的更正（一个改名、一个停更节目、一个播客归属错误、两个 URL 修复）。
4. 同时读取 `references/people-to-follow.md`、`references/books.md`、`references/video-channels.md` 获取各媒介更全名单；读取 `references/curation-method.md` 获取完整排名算术。
5. 以面试方式收集信息：一次只问一个问题，等用户回答后再问下一个，并按原文提供多选项。
6. 问：“你在收入组织中的角色是什么？”选项：(a) IC/analyst，(b) manager，(c) leader (director+)。
7. 问：“你每周现实上能花多少时间保持更新？”选项：(a) 少于 30 分钟，(b) 30-60 分钟，(c) 60-120 分钟，(d) 2 小时以上。
8. 问：“你是在某个特定时刻前补课——新角色、规划周期、技术栈迁移——还是在建立固定每周习惯？”选项：(a) 补课，(b) 固定习惯。
9. 问：“你实际消费哪些媒介？最多选两个。”选项：(a) 音频（播客），(b) 视频，(c) 文本（newsletter、博客），(d) 实时社区（聊天、活动）。
10. 问：“哪些媒介被完全排除——没有通勤或健身时间听音频、不想付的付费墙、无法报销的付费社区或会议？”
11. 问：“广度还是深度？”选项：(a) 广泛扫描整个领域，(b) 深入几个主题（请命名）。
12. 问：“你运营的细分市场是什么？”选项：(a) B2B SaaS，(b) B2C / 电商，(c) 两者。
13. 问：“是否包含厂商运营的来源（工具公司博客、研究报告）？”选项：(a) 是，清楚标记，(b) 否，只要独立声音。
14. 问：“你的收入技术栈是否锚定在一个占主导的 CRM 平台，且有该平台自己的管理员社区和认证路径——这些平台生态来源是否包含？”选项：(a) 是，包含，(b) 否。
15. 不要问交付日期；radar 没有交付物，问题 3 已包含 deadline 会提供的信息。
16. 问题 2、3、5 存在，是因为来源类型在投入、回报速度和购买成本上差异很大；步骤 6 的排序不能替用户决定。
17. 对 B2C 或电商用户明确说明：RevOps 信息生态绝大多数以 B2B SaaS 为中心，不存在专门的 B2C/DTC “RevOps” 分支；不要暗示两者对等。
18. 对细分市场 B2C/电商或两者：保留 B2B 来源中的媒介无关框架（funnel math、forecasting、data hygiene），但把社区和基准需求路由到电商运营社区（来源清单中有一个已核实类比）；警告大多数具名基准和 playbook 假设 B2B 销售周期。
19. 加载 `references/sources.md` 和 `references/people-to-follow.md`；注意每个文件头部的 snapshot date；若超过约 6 个月，告诉用户列表在依赖前需要重新核实。
20. 按面试答案过滤候选：细分市场、媒介、资历匹配、厂商运营偏好、平台生态偏好。
21. 删除，不要降级。直接删除用户约束排除的每个来源：没有通勤或锻炼时间时的音频；无法报销的付费社区或会议；用户不会购买的付费墙；用户无法加入的平台。
22. 在输出中为每个删除命名（例如 “dropped: Pavilion - paid, no budget”）。被排除的来源如果静默留在列表底部，下次刷新会悄悄变成范围。这不是 bench：bench 保存的只是预算装不下的已核实来源，这些保留。
23. 对每个存活候选运行 freshness check。来源只有通过检查，或用户接受其为 knowingly unverified 后，才进入列表。
24. 把每个候选的成本表示为注意力量级，绝不用精确数字：文本按分钟计，视频按几十分钟计，一集播客约占近一小时，社区浏览约几十分钟，活动按整天/一个区块计。对已经花在通勤、锻炼上的音频减半。
25. 按效率排名——每注意分钟的价值，绝不按便宜程度或受众规模：效率排序 `newsletters == blogs > community skim > podcasts > video`；价值排序 `community == events > podcasts > newsletters == blogs > video`。同一媒介内，先按角色匹配，再按持久性（具名责任作者、机构支持、跨平台重复出现），绝不按订阅者数量。完整轴推理和为何这些并列是真实的见 `references/curation-method.md`。
26. 指出这种排序会牺牲什么：长内容（播客、演讲、活动、社区）价值最高但在效率线底部或之外，所以严格自上而下填预算永远不会购买它。对刚进入领域、选择指定主题深度、在特定时刻前补课、或利用已支付注意成本的 commute/gym time 的用户，仍应提升长内容。
27. 把预算填到约 90%，留最后约 10% 给一个社区，因为社区是列表自我更新的方式；把 2-3 个强有力的剩余项列为 “bench” 而不是删除。完整数字算术见 `references/curation-method.md`。
28. 根据你已知道的用户情况重新排名——已付费来源或会员不增加成本，雇主会议预算让活动免费，社区里的同事可以询问而不必加入。这个排序是默认值，不是法则。
29. 按面试的广度答案决定集中还是分散：深度用户把预算集中在 3–5 个来源加上在其指定主题上发布的人；广度用户跨媒介分散，配一个锚点社区。
30. 按输出形态逐节呈现列表，并在最终确定前请用户确认或替换条目。
31. 如果你的 harness 有持久记忆，记录面试答案、最终列表和核实日期，以便刷新例程可以对比。
32. 推荐前核实——主页自己的节奏声明（“weekly show”）只是愿望，除非有带日期的条目确认。许多受好评来源宣称 “weekly” 但已沉默 7+ 个月而标语仍在（RevOps FM 和 The Revenue Formula 是 `references/sources.md` 中已确认的例子）。
33. 如果你能浏览或抓取网页，抓取每个来源的 canonical URL，找到最近带日期的条目，并按观察到的日期分类，绝不按网站自己的声明：`verified-active`（约 3 个月内）、`verified-stale`（可访问但更旧，仅在用户接受风险时保留）、`dead`（重定向到 parking/marketplace 页面——硬删除）、`unverified`（抓取失败或被阻止——记录原因；403 或 bot-block 是 `unverified`，绝不是 `dead`）。
34. 区分 renamed-but-alive、domain-resold 和 genuinely-dead，而不是把它们合并成一个判断；并单独捕捉 not-yet-alive 来源（一个 live 的 “coming soon” 页面但尚未发布任何内容）。
35. 视频平台、讨论论坛和短帖社交网络系统性地抗拒自动检查——标记为 `unverified` 并附原因，回退到手动验证，或改而通过可抓取表面验证一个人（播客嘉宾列表、讲者名单、团队页面），并将任何 handle 标注为 stated-there，而非独立确认。
36. 如果你完全不能浏览网页：从 `references/sources.md` 交付列表，附每个条目的记录状态，清楚说明你无法重新核实，并给用户手动检查方法。
37. 如果你的 harness 支持定时例程，安装季度刷新。否则告诉用户设置重复日历提醒（“Refresh my revops radar - quarterly”），并在触发时重新运行此技能。
38. 每次刷新：重新解析每个 URL——即使上次可用的也要——以捕捉改名和域名转售。
39. 重新运行 freshness check；将新近 stale 的条目降级，删除 dead 条目，重试之前 `unverified` 和 not-yet-alive 的条目。
40. 询问用户上季度实际消费了哪些来源；删除被忽略的——未读来源仍消耗注意力。除非用户说约束已解除，否则绝不再提供因约束而删除的来源。
41. 向锚点社区/最新加入者各询问一个候选发现；核实并考虑换到 bench 或列表。
42. 重新合计估计每周分钟数并与预算比较，修剪溢出。
43. 交付单个 watch-list artifact，在头部日期戳记 persona、time budget 和 verification date。
44. 按消费节奏而非媒介分组条目：`Weekly core`、`Monthly`、`Annual (events)`、`Bench (verified substitutes)`、`Dropped (ruled out, with the reason)`。
45. 每个条目包含：name、URL、medium、estimated minutes、一句为什么它赢得位置、verification status and date、适用时的 vendor-run flag。
46. 结尾给出总计：estimated weekly minutes vs. budget、counts per section、how many entries are `verified-active`。
47. 参考 `references/watch-list-example.md` 获取完整 worked example 和一个 negative example。
48. 避免推荐已死或休眠来源：始终推荐前核实；绝不把 reference list 未经检查当作 live 提供。
49. 避免信任记忆中的 URL：域名会被转售；一个可解析链接可能现在指向无关业务。重新解析并确认内容匹配。
50. 避免编造指标：如果来源不公布订阅者/下载/成员数，价值是 “not stated”。绝不要估计一个。
51. 避免超出预算过度塞入：60 分钟预算配 40 个优秀来源是失败的交付物。削减到合适；使用 bench。
52. 避免把受众规模误当权威：大订阅数衡量营销触达。跨表面重复出现和具名责任作者更能预测质量和持久性。
53. 避免混淆 decay modes：把 renamed-but-alive 来源标记为 `dead` 会丢失好来源；把 403 标记为 `dead` 会丢失好来源；保留 resold domain 比两者都糟。
54. 避免凭记忆构造看起来合理的 URL，而不是从 snapshot 拉取或说明来源缺少已核实链接。
55. 测量：watch list 在每次季度刷新时以下全部成立时算有效：每个列出的来源在过去 90 天内 `verified-active`，或明确被用户接受为 stale/unverified；总估计每周分钟数等于或低于所述预算；用户报告实际消费至少三分之二的条目。
56. 如果任一检查失败，修订——重新核实、修剪或从 bench 换入——并重新呈现直到三项都通过。交付时通过标准更严格：零个 `unverified` 条目被呈现为 verified，预算被精确遵守。
57. 参考路由：见 `mbfinotti/revops-skills@revops-kickoff` 在集合中路由任务；见 `mbfinotti/revops-skills@revops-career` 获取进入和成长 RevOps 角色——此技能只策展读什么和关注谁；见 `mbfinotti/revops-skills@revops-hiring` 获取构建 RevOps 团队。

适用边界 · 注意事项

• 不用于销售专属来源；这类需求应改用 `mbfinotti/sales-skills@sales-radar`。
• 不要暗示 B2C/DTC 与 B2B SaaS 在 RevOps 信息生态上对等；该生态几乎没有专门 B2C/DTC 分支，只能迁移通用框架并把社区/基准需求路由到电商运营社区。
• 如果完全不能浏览网页且用户要求已验证链接，不要声称已实时核实；只能交付 `references/sources.md` 中带记录状态的列表并说明需手动检查。