需要为销售角色建立或刷新个性化信息来源关注列表时…

按角色、市场、时间预算和目标，从已验证销售来源（播客、newsletter、社区、基准报告、人物）中筛选排序，生成带状态和最后验证日期的关注列表。

适用场景

解决思路

1. 1. 先区分生态系统：把 B2B SaaS 销售与 B2C 高客单价销售视为两套来源、平台和人物；B2B 主要看 LinkedIn、Slack communities、Substack newsletters、benchmark reports；B2C（房地产、汽车、保险、太阳能/上门、家装）主要看 YouTube、Facebook Groups、付费教练漏斗，且更偏课程卖家和个人品牌。
2. 2. 不要把 B2C 名单换个标签给 B2B，反之亦然；仅对同时服务两边且被明确标记的来源（Sales Gravy、Chris Voss、Jeremy Miner）才跨生态使用。
3. 3. 不要直接交付示例来源列表；先读 [references/sources.md](references/sources.md) 获取两生态的完整、带日期、已验证快照，并按 [references/people-to-follow.md](references/people-to-follow.md)、[references/books.md](references/books.md)、[references/video-channels.md](references/video-channels.md) 补全人物、书籍、视频频道；仅当用户点名快照中没有的来源才超出快照选择。
4. 4. 执行访谈：一次问一个问题，能提供多选就提供多选；最多 8 个问题；对话已回答的问题跳过，其余推断。
5. 5. 问角色与资历：SDR/BDR、AE、一线经理、VP/CRO、创始人销售或其他？
6. 6. 问市场：B2B（交易规模和周期多长？）、B2C 高客单价（哪个垂直：房地产、汽车、保险、太阳能/上门、家装？）还是两者？
7. 7. 问努力上限：每周实际愿意花多少分钟——少于 30、30-60、60-180、更多？取他们在糟糕一周仍会坚持的数字，而不是理想数字。
8. 8. 问截止日期：是否有必须投入工作的日期——QBR、薪酬评估、新区域、求职——还是开放式？
9. 9. 问一次性补课还是长期习惯：补一次现状，还是安装可持续运行的例行程序？
10. 10. 问实际消费的媒介：播客音频（通勤、健身）、newsletters/文字、视频、直播、社区潜水/发帖？
11. 11. 问已经关注什么：新列表必须增加信息，不能重复。
12. 12. 问当前想提升什么：prospecting/cold calling、discovery、negotiation/closing、领导/辅导、薪酬与市场数据、职业变动？
13. 13. 在选任何来源前先使用问题 3、4、5 调序：努力上限决定填充到效率排序的第几层；低于 30 分钟/周只买 newsletters 和一份 benchmark report，其他不买。
14. 14. 硬截止日期提升快速见效来源：benchmark report + 两份 newsletters 能让人一周内跟上；社区和会议按季度回报。开放式答案提升慢速来源。
15. 15. 一次性补课提升 benchmark reports 和 newsletter archives（可集中补看）；长期习惯提升周期性来源；只有长期习惯才值得考虑社区。
16. 16. 只用注意力作为预算，不用钱给来源定价：用户已付费的订阅没有额外阅读成本；一小时节目无论免费与否都花一小时。
17. 17. 按数量级而非精确数字估算每种媒介的注意力成本：newsletter 每期几分钟且有硬终点；benchmark report 每季度/每年几分钟；podcast episode 几十分钟；个人 feed 几分钟但无界；live show 约一小时且按他人时钟；community 每周几十分钟、持续、无终态；conference 数天加差旅。
18. 18. 用效率排序先给最佳比例，而不是最便宜：效率：newsletters > benchmark reports > podcasts > people's feeds > live shows == communities > conferences。
19. 19. 同时保留注意力成本从高到低：conferences > communities == live shows > podcasts > people's feeds > newsletters == benchmark reports。
20. 20. 同时保留价值从高到低：conferences > communities > benchmark reports > podcasts > live shows > newsletters > people's feeds。
21. 21. 尊重两个真实平局：communities == live shows（成本与效率相同，都是同步时段、无存档、买同行接触，所以谁也不领先）；newsletters == benchmark reports（成本相同，都是读完即止的文本，报告更长但频率低得多）。
22. 22. 注意该排序会饿死 conferences 和 communities：它们价值最高但效率最低，纯按分钟/周预算永远买不到，而只有它们产出关系和未公开数字；在以下情况仍要提升它们：目标是职业变动、薪酬谈判或首个同行网络；问题没有发布者回答（小众垂直、未基准化工具、我的阶段这个配额正常吗）；用户孤立（独立创始人、唯一销售、首位销售招聘）；用户已经属于该社区/已预算会议。
23. 23. 把 conference 按每年几天的块预算，绝不按每周分钟评分；按周评分会让它被埋没。
24. 24. 先按效率顺序自顶向下填满用户声明的努力上限，然后停止；再按已知用户信息重新排序：通勤让音频几乎免费，已付费会员从零成本开始，小众且 benchmark 报道稀少会让该层因供给不足而非价值不足下移；该排序是默认不是法律。完整数字算法和重排启发见 [references/curation-method.md](references/curation-method.md)。
25. 25. 构建关注列表第 1 步：读 [references/sources.md](references/sources.md) 的带日期、已验证快照，从其中选择；仅当用户点名缺失来源才外扩。
26. 26. 第 2 步：先按生态系统过滤（B2B、B2C 垂直或两者），再按媒介匹配，再按用户当前目标过滤。
27. 27. 第 3 步：幸存来源按上述注意力效率排序；同一媒介内按实践者信号而非营销触达排序：在职销售自发推荐的来源胜过宣称受众最大的来源；快照会标记哪些是实践者信号、哪些是课程漏斗品牌（其商业模式就是产品）。
28. 28. 第 4 步：限制列表：每周一小时或更少为 5-8 个来源；绝对最多 10-12 个。四十个来源是目录，不是关注列表。
29. 29. 第 5 步：排除用户已关注的内容；直接删除其回答排除的内容——错误生态、从不消费的媒介、无预算用户的付费社区；用一行说明每个刻意排除项，让用户知道是被考虑过而非遗漏；绝不把被排除来源放在底部当作低优先级，否则它仍会被订阅。
30. 30. 第 6 步：对任何在快照中未标记为 `verified-active` 的已选来源运行新鲜度检查；在输出中携带每个来源的状态标签；绝不用 `unverified` 来源冒充已确认活跃。
31. 31. 第 7 步：按来源对用户所做的工作分组最终列表（打磨技能、保持最新、基准薪酬、寻找同行），绝不按媒介做成一个扁平列表；组之间及组内条目都按效率排序，使页面只有一个顺序。
32. 32. 第 8 步：如果运行环境有持久记忆，存储最终列表、访谈答案和快照日期，以便下次刷新从上一次已知良好状态开始，而不是归零。
33. 33. 新鲜度检查：该领域主要失败模式是静默品牌迁移，不是关停（GTMnow、Outbound Squad、Outreach.ai 都替换过旧品牌而未让旧 URL 直接死掉）；旧 URL 会重定向或悄悄腐烂，所以“页面能打开”不能证明任何方向。
34. 34. 如果能浏览或抓取网页，对每个未 `verified-active` 的已选来源：抓取并确认落点（重定向意味着迁移，不是死亡）；确认落地页确实是目标实体；播客要查其自身 feed，而不是公司主页；空个人 newsletter 对个人是不确定，不是不活跃证据；YouTube/Reddit/LinkedIn/X 抓取被阻止记为未知，不是死亡；给你触碰的一切记录最后验证日期。
35. 35. 绝不编造受众数字：只报告已发布且注明来源的数字；否则写 “not stated”。
36. 36. 如果不能浏览网页：仅从快照构建列表；显著标注快照日期；保留每个来源的记录状态；告诉用户哪些条目在投入时间前需要手动复查。
37. 37. 输出形态：交付按待完成工作分组的关注列表；每个条目携带：它是什么/谁运营；媒介和节奏（便于放入每周）；一句“最适合什么”并绑定用户目标；状态（`verified-active`、`unverified` 或 `likely-dead`）和最后验证日期。
38. 38. 结尾给覆盖统计：来源数量；覆盖媒介；估计每周时间成本与声明预算对比；快照日期；已验证 vs 未验证条目数。参见 [references/watch-list-example.md](references/watch-list-example.md) 的工作示例和要避免的诱人错误形态。
39. 39. 成功标准：列表符合声明时间预算；每个条目都有状态和最后验证日期；用户已关注的内容不再作为推荐出现。
40. 40. 周期性刷新：来源会在数月内迁移或死亡，一次性列表会腐烂；如果运行环境支持计划/周期性例程，主动提供安装季度复查：对用户列表重跑新鲜度检查，只报告变化——迁移、死亡、状态升级或降级。
41. 41. 如果不支持，给用户手动例程：每季度用上述新鲜度步骤重新验证每个条目，从最后验证日期最旧和标记 `unverified` 的条目开始；跳过两个发布周期的 benchmark source 要删除。
42. 42. 不要倾倒整个来源目录且不排序不过滤；快照是原料，不是交付物。
43. 43. 不要按最便宜而非比例排序，导致列表变成六份 newsletter 却买不到用户要的唯一结果。
44. 44. 不要让效率顺序静默否决只有会议/社区才能服务的用户目标。
45. 45. 不要因为某来源著名就把 `unverified` 升级为活跃；名气不是验证。
46. 46. 不要编造或四舍五入受众数字；`not stated` 才是正确值。
47. 47. 不要把重定向当死亡，或把页面加载当存活而不检查身份和日期内容。
48. 48. 不要把双生态来源（Sales Gravy、Chris Voss、Jeremy Miner）只归到一边，或把两生态混成一个无差别列表。
49. 49. 不要把课程漏斗个人品牌当作中立实践者资源推荐；适合时可推荐，但要明确说明其性质。
50. 50. 不要凭记忆构造看似合理的 URL，而要从快照取 URL 或说明该来源没有已验证链接。

适用边界 · 注意事项

• 不用于职业规划或面试准备；这类需求应改用 mbfinotti/sales-skills@sales-career。