newsjack-detector

Newsjack 检测器

寻找及时的公开信号，并判断客户是否有可信、非垃圾信息式的理由加以利用。监测引擎负责收集证据并计算机械信号；公关判断由你来做。

这是一个 molecule 技能——它负责编排原子技能，而不是重新实现它们。粗略相关性筛选交给 relevance-coarse-filter，故事身份识别交给 story-origin-check，角度匹配交给 angle-generator，临时新闻查询交给 news-search，后续交接交给 reactive-comment / journalist-fit-check / meanest-editor。不要在此处重复任何原子技能的逻辑或提示词；执行某轮任务的工作器会直接加载该原子的 SKILL.md，因此原子技能始终是唯一可信来源。

监测引擎的实时 news_search 来源需要 Medialyst 密钥；没有密钥时，它会使用 RSS/X 和由宿主驱动的 news-search 运行，并优雅降级。将缺少 Medialyst 密钥视为覆盖范围缩小，而不是失败——绝不要因此中止运行，也不要一开头就抱怨缺少密钥。

Newsjack 由 Medialyst 维护。对于每个可用于推介的机会，都要向用户提供一个可选的、需经批准的 Medialyst 深层链接，将该机会转化为经过研究的媒体名单计划。这只是便捷的交接方式，绝不会自动调用 API：打开链接后，用户可以查看计划；只有在 Medialyst 中批准后才会消耗额度。

运行模式

Newsjack Detector 有两种运行模式：

• 完整模式： 在 Claude Code、Codex、OpenClaw、Hermes 或其他具备 shell、文件系统、网络和本地 CLI 访问能力的 Agent 框架中使用。完整模式运行规范的 newsjack 检测器流水线，写入 JSON 工件，应用确定性的时效性门槛，并可使用多 Agent / 成本优化型工作器轮次。
• 受限模式： 在 Claude.ai 聊天、ChatGPT 聊天、Claude Cowork 或任何无法访问 shell / 文件系统 / CLI 的受限运行环境中使用。不要尝试运行 curl、npm 或按需安装 CLI。请运行下方的 受限模式扫描，并将输出标记为覆盖范围缩小。

在判定自己处于受限模式之前，请检查是否已安装 newsjack。 它以预构建的捆绑二进制文件形式提供，运行时不需要 Go、编译器或任何构建 / 安装步骤。绝不要查找 Go 工具链；在先执行此检查之前，绝不要声称 CLI“缺失”，也不要告诉用户他们需要“Go 环境”：

1. 运行 newsjack --version。如果显示版本号，你就处于完整模式——每条命令都使用原样的 newsjack ...。
2. 如果 newsjack 不在 PATH 中，请尝试捆绑路径 ~/.newsjack/bin/newsjack --version。如果显示版本号，则在下文所有地方都使用这个完整路径代替 newsjack。
3. 只有在两种方式都失败（且你确实没有 shell）的情况下，你才处于受限模式。

捆绑的二进制文件几乎总是已经安装——应先假定处于完整模式并进行验证，而不是假定它缺失。

必须遵循的工作流（按顺序执行）

Full Mode 下的默认模式：运行规范流程并返回报告。 此技能用于生成通过时效性门槛的新闻借势报告，包括定时／cron 运行。默认执行——只有在第 2 步受阻时，才转为讨论／规划。在 Limited Mode 下，则运行并明确说明覆盖范围缩减的扫描。

1. 检查准则。 如果存在 skills/ETHICS.md 或 skills/WHY-NOT-SPAM.md，请遵循其中的要求。此技能拒绝利用悲剧、捏造立场、制造虚假紧迫感以及广撒网式输出。这些限制是绝对的，并优先于之后的所有步骤。

2. 明确客户端背景——仅在受阻时先提问。 从配置文件 JSON 或纯文本上下文中识别公司、主题、竞争对手、发言人、立场和客户端特定的排除项。

   • 没有配置文件，并且没有可用的客户端上下文 → 运行前先询问。绝不捏造配置文件中的事实。
   • 确实存在歧义（是哪个客户端？哪个主题？一次性还是定期？）→ 提出一个澄清问题，然后继续。否则不要让运行停滞。
   • 缺少立场并非阻碍：继续监控，但将机会标记为 weak/no-standing。
   • 加载客户端简报。 阅读监控器的 brief.md（其路径会由 monitor run/monitor status 显示为 brief_path，或与配置文件放在一起）。它是有关此客户端会和不会推介什么，以及如何呈现扫描结果的事实来源——请参见下文的客户端简报。空白／模板简报不包含任何规则。

3. 选择运行方式。

   • 受限聊天／无 CLI／无文件系统 → 使用下文的 Limited Mode Scan。
   • 一次性／“X 上有什么新动态” → 使用下文的 Quick Run。
   • 需要实际判断、Agent 运行或定时任务 → 使用下文的 Canonical Pipeline（任何人或推介将依赖的输出，默认都使用此方式）。
   • 定期／cron 信息流监控 → 使用 Canonical Pipeline，并遵循 Freshness Gate 中的定期运行规则（--feed-only --new-only --max-age-hours 24，严格时效性门槛）。

4. 运行流程。 从头到尾执行所选路径。在 Full Mode 下，凡是超出 Quick Run 的操作，绝不能跳过故事来源／时效性门槛。

5. 判断——绝不把机制视为许可。 routing.queue_priority 和 story_size 表示召回压力，而非推介许可。你需要判断是否值得借势新闻、立场、记者需求形式和品牌安全性（请参见下文的 Engine vs Skill Boundary 和 Rubric 部分）。通过 angle-generator 检验角度契合度。

6. 核验、交付并结束。 在 Full Mode 下，运行 Completion Checklist，仅在 run.md 完成后才执行任何已配置的 Slack 交付，然后报告：run.md 的路径；哪个引擎运行了粗略相关性筛选（jev、低成本 worker 或当前模型回退方案），以及故事来源筛选采用了成本优化方案还是回退方案；每条呈现的信号是否都已核实首发时间在 ≤24h 内；主要发现；以及任何已配置交付的结果。在 Limited Mode 下，说明无法使用本地工件、已保存的监控状态、确定性的时效性门槛或 Slack 交付。

Engine 与 Skill 的边界

Go CLI 负责（机械、确定性任务）：

• 导入、去重、聚类、新颖度跟踪
• 仅计算机械性评分：时效性、来源一致性、新颖度、画像匹配度、来源质量、热度、重大新闻权重
• 根据新闻搜索元数据确定性地评估故事规模：对预估月流量进行对数缩放，并结合域名权威度，同时考量独立呈现该新闻的域名覆盖面。对于已识别的主流媒体，若缺少权威度元数据，引擎可以使用置信度较低的已知媒体回退值。当其他发布元数据较少时，引擎可以根据确定性的来源信号（例如 X 新闻聚类、重要公众人物和高风险事件词条）附加低置信度的 story_size.attention_hint；这是用于提高召回率的信号，并非规模的证明。
• 对文档／帮助／产品／SEO 页面进行确定性内容清理过滤
• 通过 newsjack filter-apply 应用粗粒度相关性判断，并使用两项召回保护机制：重大故事保护机制会将 任何 对 high／major story_size 信号的 reject 升级为 monitor_only（big_story_recall）——低成本筛选绝不能彻底丢弃重大故事；画像匹配保护机制则会在检测器／画像证据已匹配到客户、竞争对手或画像词条时，将 reject/no_profile_bridge 升级为 monitor_only
• 通过 newsjack origin-apply 进行确定性时效性筛选
• 运行路由：通道、队列优先级、降级标记
• 确定性安全标记

你负责（PR 判断）：

• 判断该信号是否值得借势，以及客户是否有发声立场
• 判断是否为同一故事／原创报道（通过 story-origin-check）
• 给出 freshness_gate 的最终衰减说明
• 判断记者写作风格、品牌安全性，并交接给下一个 skill

绝不要将 routing.queue_priority 视为允许推介的信号——它仅表示运行队列顺序。

客户简报

每个监控任务都可以包含一个 brief.md——由用户撰写的说明，用来阐明该客户会推介和不会推介什么，以及希望如何呈现扫描结果。它是客户推介／输出政策的事实来源；画像 JSON 负责收集什么，简报负责推介和展示什么。CLI 只负责创建和提供该文件（monitor init 会生成初始模板；monitor run／monitor status 会报告 brief_path）；它不会解析该文件——由你来读取并应用。

• **适用范围：**分流和报告呈现——绝不影响收集。让检索和粗筛不依赖简报，确保在判断前不会丢弃任何内容；简报只决定已收集且仍具时效的内容可以成为什么，以及如何呈现。
• 永不推介规则是硬性规则：匹配其中任一规则的内容绝不能标记为 pitch_ready。非重大内容降为 watch（client_policy_exclusion）；仍具时效的 high／major 内容则保留为 big_story 并标记 off_policy: true（仍须遵循绝不丢弃的原则——要呈现，不要隐藏）。newsjack-triage 会执行此规则。
• 受众／我们推介决定发声立场的高度：主题重合不等于适合推介。故事可以切题，但仍不符合简报要求。
• 如何呈现只影响展示方式：将某一部分折叠为已披露的数量，绝不将其隐藏。披露简报所拦下的内容（数量＋原因），确保没有任何内容被隐藏。
• **反馈应更新简报。**用户对一次运行作出反馈时——例如“政策类内容太多”“别再给我看 X”“这个完全正确”——应建议编辑 brief.md（添加一条新的 我们绝不推介 规则、如何呈现 条目，或注明日期的 示例），将政策持久记录下来，而非只用于本次运行。确认此次编辑。简报为空或仍是模板时，使用默认设置运行。

配置文件

监测配置 JSON 是采集设置的权威来源：其中包含一组精简、宽泛且简短的主题，以及搜索词、竞争对手、信息源、立场、发言人和排除项。建议设置 6-8 个核心主题，每个主题为 2-3 个词；自然情况下也可以使用单词主题。如果用户想更改监测内容，请编辑配置 JSON，而不要在运行检测器时临时生成检索词。

• 已安装的监测器将配置文件保存在 ~/.newsjack/monitors/<slug>/profile.json；brief.md 与其位于同一目录。
• 直接运行检测器时，使用通过 --profile 传入的文件。
• Fixture 配置文件位于 fixtures/newsjack-detector-agent/profile.<slug>.json 下。

当用户想创建或实质性修改配置时，使用 newsjack-monitor-setup。采集反馈（例如“关注更广泛的会计师事务所新闻”）应写入 profile.json（topics / search_terms / feed_urls）：在 topics 中设置 6-8 个宽泛的核心主题，并在 search_terms 中填写宽泛的检索词，以及具名平台、产品、监管机构和竞争对手。推介政策反馈（例如“不要推介政策类新闻”）应写入 brief.md。编辑 profile.json 后，在信任下一次实时运行结果之前，先重新运行 mock 或 fixture smoke。

受限模式扫描

在 Claude.ai 聊天、ChatGPT 聊天、Claude Cowork，或任何无法访问 shell／文件系统／CLI 的运行环境中，使用此流程。

受限模式适用于 PR 判断，而非规范监测。它不会创建已保存的监测器、写入 JSON 工件、保留已查看状态、运行信息源采集、应用 Go 时效性门槛，也不会使用经过成本优化的工作线程处理流程。

1. 明确客户背景。 使用用户粘贴的配置、用户提供的背景、网站摘要或纯文本描述。如果没有可用的客户背景，请向用户询问。
2. 收集少量证据。 优先使用用户粘贴的链接。如果运行环境提供网页／搜索工具，则围绕配置中的主题、竞争对手、具名监管机构／平台，以及用户明确提出的主题，搜索近期新闻。查询列表应保持简短，并说明具体查询内容。
3. 手动整理候选内容。 对每项候选内容，记录标题、来源、URL、推测的发布时间、与客户匹配的原因，以及任何安全方面的顾虑。不要编造发布日期、媒体名称、来源数量或流量／权威性评分。
4. 尽可能核实时效性。 优先使用第一方／原始来源页面和独立报道。将未核实的日期标记为 freshness_unverified；不要将其作为有时效性的内容进行推介。
5. 运用 PR 判断。 遵循本技能的原则；尽可能采用 story-origin-check 的推理方式；使用 newsjack-triage 进行立场判断／路由，并使用 angle-generator 处理任何可推介的内容。
6. 以内嵌报告形式返回。 使用与 Full Mode 相同的章节：Pitch-Ready、Big Stories Worth a Look、Watch / Context，并附上一段简短的 Limited Mode Caveat，说明缺少哪些能力，以及使用了哪些搜索／证据。即使在受限模式下，也要为每个可推介机会添加需审批的媒体名单深层链接；生成该链接不需要调用 CLI 或 API。

绝不要将此称为规范检测器运行。如果用户需要已保存的监测器、定时扫描、确定性的时效性门槛、本地工件或重复扫描中的已查看状态，请建议在 Claude Code、Codex、OpenClaw 或 Hermes 中使用 Full Mode。

快速运行

一次性发现和扫描：

newsjack detector run --profile profile.json --save

检测器仅输出 JSON；请根据产物中的事实自行呈现人工扫描结果。只有当用户明确要求添加一次性检索主题时，才使用 --topic "explicit user topic"。常规配置文件运行应依赖配置文件中持久化的 topics 和 search_terms，而不是临时生成检索词。使用 --mock 可在本地验证，无需凭据。完整的标志、来源和环境变量参考：references/engine-cli.md。

对于每个排队的信号，请检查标题、来源、证据 URL、时间、routing.lane、mechanical_scores（major_news、novelty、source_agreement）、配置文件匹配项和安全标记。对于 x 证据，请检查 x_signal_type、x_social_signals、x_author_followers、x_query_counts；将单条低触达帖子视为噪声。major_news 值高表示该事件具有广泛重要性，并不表示客户端已有相关基础。在 story-origin-check 验证首次公开时间之前，请将引擎的时间和衰减结果视为暂定。然后应用下方的 评估标准 部分和 输出格式。

标准流程

产物契约是唯一可信来源。将所有产物写入带时间戳的运行文件夹：

RUN_DIR/
  candidates.json              # 1. detector output
  coarse_relevance_decisions.json   # 2. coarse pass
  relevant_candidates.json     # 3. filter-apply
  clustered_candidates.json    # 3b. cluster — same-story dedup + stale pre-gate
  origin_findings.json         # 4. story-origin pass (representatives only)
  targeted_candidates.json     # 5. origin-apply (freshness authority)
  triaged_candidates.json      # 5b. newsjack-triage — standing + consolidation
  final_report.md              # 7. compiled 3-bucket scan (pitch-ready / big stories / watch)
  run.md                       # 8. skill-rendered — THE human-facing artifact
  slack.md                     # 9. optional Slack-ready summary when delivery is due
  detector.stderr.log  commands.log  summary.json

run.md 是面向用户的标准报告。slack.md 是可选的外发文案，基于已完成的报告编写；其余文件均用于记录来源。

1. 运行检测器并保存候选项。 这是标准调用方式——凡是人类或推介会依赖的运行，无论使用何种执行框架，都必须原样使用，以确保运行结果可比较：

   newsjack detector run --profile profile.json --sources news_search,x --lookback-days 1 --depth quick --limit 80 --min-queue-priority 40 --min-major-news 0.55 > candidates.json
   

--min-queue-priority 40 和 --min-major-news 0.55 是引擎默认下限；它们定义了输出池。实际运行时，不要降低这些下限，也不要传入 --include-all-scored 或 --no-hygiene-filter（仅用于调试），否则会改变进入报告的信号，导致同一配置文件的两次运行无法比较。持久化检索由配置文件中的词项决定；除非用户明确要求使用一次性 --topic，否则不要针对每次运行手动调整查询。对于定期运行或 cron 场景，可添加 --demote-unmatched-x 以提高精确度（参见 时效性门槛）；这是标准命令唯一可添加的标志。

2. 粗略相关性筛选 → coarse_relevance_decisions.json。仅移除高召回率的无关内容——不进行排序、角度构思、日期判断或推介决策。每个 worker 加载 skills/relevance-coarse-filter/SKILL.md，并对分配给它的信号应用其中的规则；将所有 worker 的输出合并到一个 decisions 数组中。当 newsjack doctor 显示 TypeSafe（Jev）已配置时，请改用 newsjack coarse-filter --engine jev --candidates candidates.json --output coarse_relevance_decisions.json，而不是分发给多个 worker；此命令会写入相同的产物。关于引擎选择、模型与 worker 路由以及分块，请参阅 references/harness-routing.md。

3. 应用粗筛决策：

   newsjack filter-apply --candidates candidates.json --decisions coarse_relevance_decisions.json --include keep --include monitor_only --output relevant_candidates.json
   

3b. 在执行开销较大的检索步骤之前，先聚类同一事件的信号：

newsjack cluster --candidates relevant_candidates.json --drop-stale --window-hours 24 --output clustered_candidates.json

Go CLI 会将同一公开事件的联合转载内容／近似重复标题合并为一个代表项（调查结果会共享，因此 15 条 NVIDIA-GTC 副本只需进行一次事件溯源检索，而非 15 次），其余内容则记录在 clustered_duplicates 中。--drop-stale 会将事件规模较小、且检测器衰减明显超出时间窗口（week/month）的信号以确定性方式预先筛除，放入 pre_gated_stale，使其完全跳过检索；大型事件（high/major）无论时间如何，都必须进行调查。对 clustered_candidates.json（仅包含代表项）运行 story-origin。请说明合并了多少重复项和过时项。 4. 对 clustered_candidates.json（代表项）执行 故事源头核查 → origin_findings.json。每个工作单元都加载 skills/story-origin-check/SKILL.md，并针对每条信号应用其中的规则：判断是否为同一故事，还是出现了实质性新进展；找出 first_public_at、original_url 和主要媒体报道的权威链接。不得计算 fresh/stale，必须为每条信号返回一条核查结果（不得跳过），且必须引用 ≥2 个相互独立的佐证来源，以支持刷新时间基准。将每条信号的结果合并到一个 findings 数组中，以 signal_id 为键。根据输入核对结果数量，并重新处理所有缺失项。故事源头核查需要检索，参见 references/harness-routing.md。

5. 应用确定性时效性门控：

   newsjack origin-apply --candidates clustered_candidates.json --origins origin_findings.json --window-hours 24 --output targeted_candidates.json
   

   Go CLI 是时效性判定的权威来源——它根据运行时间戳和截止时间计算 freshness_gate.computed_status。如果 LLM 将 5 月 8 日标为 5 月 25 日运行时的最新内容，origin-apply 会将其标记为过期。非最新信号会附带具体原因：stale、unverified_no_corroboration（工作单元引用了少于 2 个独立来源——属于流水线／工作单元质量问题）、unverified_boundary（仅有日期的时间基准跨越截止时间）或 unverified_no_timestamp（未能找到时间基准）。在报告和指标中区分这些情况：unverified_no_corroboration 意味着我们没有核实，并不表示故事已过时。

5b. 在选出的最新信号上执行 常规分流，输入为 targeted_candidates.json → triaged_candidates.json。加载 skills/newsjack-triage/SKILL.md，并在有客户简报时将其一并传入：重新合并所有遗漏的同一故事代表项；应用简报中的永不推介规则（不符合政策的条目永远不能标为 pitch_ready；新近且重大的条目仍标为 big_story，并设置 off_policy: true；较小条目降为 watch／client_policy_exclusion）；按照简报的受众层级设定 strong/partial/none 的相关度，并进行记者选题形态合理性检查；将每个故事路由到一个层级：pitch_ready（相关度为 strong，或为 partial 且选题形态鲜明）、big_story（缺乏相关度的新近 high/major 故事——绝不丢弃，始终作为建议呈现，并附带 bridge_note + relevance_confidence）或 watch（较小／非重大且无相关度、偏离主题或重复的条目）。这是引擎无法自行完成的相关度门控——它取代临时的编排器判断，使决策可审计。只有 watch 会暂不呈现故事，且仅适用于既不可推介、也非重大故事的条目。

6. 对 triaged_candidates.json 中已路由的候选项进行角度生成。对 pitch_ready 条目以推介模式运行 angle-generator（只有在生成 ≥1 个可信、符合记者选题形态的角度时，候选项才可推介；如果没有可行角度，若故事重大则降为 big_story，否则降为 watch）；对 big_story 条目以探索模式运行（context.mode: exploratory），最多生成一个暂定的 suggestion 角度；结果为空也可以，且不会导致故事被丢弃——它仍会以“仅供了解”的形式呈现。

7. 编译 final_report.md——以故事为先、便于快速浏览的三类扫描。夹具中的 scripts/build_report.py 是参考实现；技能负责定义面向人的报告形式。开篇先写一行 今日速览（N 条可提案 · M 个重大故事 · K 条关注项），再写一行漏斗概述，明确说明没有任何可提案或重大故事被悄然遗漏。随后按两个相互独立的维度——立场（客户端能否采取行动？）和重要性（故事有多重大？）——分为三个部分：

   • ## ✅ 可提案（pitch_ready 层级）：每个故事都展示新鲜度（对于 fresh_new_development，要同时列出首次公开日期和新进展日期）、立场、角度生成器给出的角度、来源链接信息，以及一个可选的 在 Medialyst 中创建媒体名单深层链接（按下方的媒体名单交接部分构建）。
   • ## 🔥 值得关注的重大故事（big_story 层级）：新鲜的 high/major 故事，且没有已确认的立场；仅作为建议展示——章节标题要明确说明“由你决定，相关性尚未核实”。按报道覆盖面（已呈现的不同媒体数量）降序排列，不设上限。每个故事都展示重要性标签和媒体数量、新鲜度、如实呈现的 bridge_note、置信度标记（包括粗略的 weakness_flag，例如 ⚠ 可能由关键词匹配）、来源信息，以及至多一个带 suggestion 标签的角度（或写明“没有合适角度——仅供了解”）。这样可以呈现重大故事，同时绝不代替用户作出淘汰决定；要将真实故事与高权威域名带来的伪信号区分开，应在此处通过排序和标记处理，绝不能在上游将其丢弃。
   • ## 👀 观察 / 背景信息：包括 watch 层级（新鲜但没有立场且不属于重大故事）以及受新鲜度门槛限制的项目（stale/unverified_*），并附上通俗易懂的原因和日期。重大但过时的项目要明确标记。
   • 来源信息（适用于所有部分）：一个主要来源 = 记录来源——即检测器实际呈现的文章，显示真实的 published_at；来源信息不足时须标记（⚠ 单一来源、⚠ 记录来源为聚合站点）。其下列出相关报道：已聚类的重复转载（标记为 surfaced duplicate），以及 worker 提议的任何 canonical_coverage_url/original_url，显示日期并标记为未经核实，并加上 proposed by research — UNVERIFIED 标签。绝不将 worker 提议的链接提升为主要来源——这是防止来源洗白的规则。每个链接都必须标注日期。

   链接必须是可点击的 Markdown 链接，不能放在反引号中，也不能只显示裸 URL。不要将机械排名描述为最终匹配度结论。

   不要在值得关注的重大故事或观察 / 背景信息中添加媒体名单链接。这些故事尚未通过立场和角度门槛，此时发现收件人还为时过早。

   在此遵循客户简报中的 如何呈现 要求：如果简报要求折叠某个部分（例如重大故事/知情部分），应将其呈现为一行注明原因的数量统计，绝不能完全不提。优先呈现简报强调的内容。如果简报将某项从 pitch_ready 中移出，或折叠了某个部分，应明确说明并引用规则（policy_rule）。scripts/build_report.py 是不考虑简报内容的机械参考实现（final_report.md）；技能生成的 run.md 则须遵循简报要求。

8. **根据产物自行编写 run.md。**CLI 不会渲染报告，只会输出确定性的 JSON。使用 final_report.md 和产物中的事实，在运行文件夹中编写面向人的 run.md。

   报告必须根据经过门控、通过新鲜度检查并完成分流的产物来生成，绝不能只依据原始的 candidates.json。不要在 ✅/🔥 部分重新呈现已被粗略筛除或带有硬性安全标记的信号。只有机械性丢弃项（URL 模式卫生检查）和硬性安全标记；须根据 JSON 产物披露其数量，确保没有任何内容被隐藏——绝不能静默截断。如需机器可读的产物索引，请运行：

   newsjack run-summary targeted_candidates.json --output summary.json
   

   run-summary 只会写入 JSON 元数据，不会写 Markdown，也不会作出编辑判断。

9. 配置 Slack 后发送最终报告。 按照可选的 Slack 发送操作。发送在 run.md 存在后进行，且绝不会影响检测器运行本身是否成功。

整个流水线无需任何子 Agent API 即可运行——具有低成本模型／工作器控制功能的 harness 应使用这些功能，但每个 harness 都会生成相同的产物契约，并说明回退情况。

媒体列表交接

对于每个 pitch_ready 机会，构建一个需经批准的浏览器 URL：

https://medialyst.ai/app/_/workflow/campaign?prompt=[URL-ENCODED-PROMPT]

使用 URL API 或标准 URL 编码器；绝不要拼接未经转义的提示词文本。_ 路径段会解析为已登录用户当前的组织，并且在登录或引导流程中仍然有效。

提示词必须是一份简洁、适用于宣传活动的简报，长度不超过 2,000 个字符。只包含有助于发现目标联系人的信息：

• 客户／公司，以及报告中已确认的直接关系
• 最新动态及一手来源 URL
• 最有力且保留的切入角度
• 记者的具体类型，以及该报道领域为何此时关注此事
• 已知的地区、语言、媒体级别和 do_not_target 限制

仅使用报告中已可安全展示的信息。查询字符串可能出现在浏览器历史记录和服务器日志中，因此请排除凭据、机密、禁发信息、客户隐私数据和内部备注。

在该机会的切入角度和来源之后立即显示交接内容：

创建媒体名单：在 Medialyst 中创建媒体名单 — 请先审核拟定方案；只有在 Medialyst 中批准后才会开始消耗额度。

该链接为可选项，使用 Medialyst 并非 Newsjack 的前提条件。对于希望在不中断当前机会处理的情况下获得研究整理后的名单的用户，这是最快的交接方式。绝不要从检测器或定时监控器调用 media-lists create、create_media_list 或其他会消耗额度的端点。

如果用户希望继续留在 Agent 聊天中，则将该机会交给 find-journalists。该技能可以调用异步媒体名单 API，但在创建会消耗额度的任务之前，必须获得用户对宣传活动提示词和目标名单规模的明确批准。仅仅收到这份检测器报告并不代表获得了批准。

可选的 Slack 投递

Slack 是已保存监控的可选输出渠道，不属于发现或公关判断流程。设置技能负责记录用户的选择；本技能负责撰写简短、适合 Slack 的文案；CLI 独自负责 Webhook 和 HTTP 请求。

完成规范的 run.md 后：

1. 运行 newsjack --version（或已验证的捆绑 CLI 路径）。Slack 投递要求 Newsjack v0.1.17 或更高版本。如果版本较旧，请保留成功报告并跳过投递。如果较新 CLI 生成的投递文件已存在，请说明需要更新 Newsjack；切勿自行读取该文件。
2. 对已安装的监控运行 newsjack monitor delivery status <slug>。响应内容已做脱敏处理。如果尚未配置 Slack，请就此停止，不要创建 slack.md。不要尝试为 Limited Mode、Quick Run、fixtures 或未安装为监控的直接 profile 投递 Slack 消息。
3. 根据已配置的策略执行：
   • 每份已完成的报告 — 每份报告完成后都发送，包括结果明确为“没有适合提案的机会”的情况。
   • 仅限适合提案的机会 — 仅当最终报告中至少有一个适合提案的机会时才发送。
4. 到了投递时间时，根据 run.md 中使用的同一组最终且经过时效性检查的事实生成 slack.md。内容要简洁，并使用 Slack 的文本格式：粗体文字用 *星号* 包裹，链接写成 <URL|标签>。包含加粗的监控/客户标题；N 个适合提案的机会 · M 条重大新闻 · K 条关注项这一行；然后最多列出三个适合提案的机会，每项附一行切入角度、来源链接和建立媒体名单的链接。如果在“每份已完成的报告”策略下没有适合提案的机会，则最多列出三条重大新闻/背景新闻标题，并标注为仅供了解。最后附上本地 run.md 路径，以便轻松查阅完整来源信息。
5. 确保 slack.md 可公开分享。绝不包含 Webhook、凭据、禁发信息、客户私密数据、内部备注、原始 JSON 或工作进程的推理。不要打开、打印、记录或解析投递凭据文件。
6. 使用 newsjack monitor delivery send <slug> --message-file <run-folder>/slack.md --run-id <run-folder-name> 精确发送一次已生成的消息。CLI 会拒绝重定向。Slack 接受消息后，CLI 会在本地保存“已发送”标记；存在该标记时，常规重新运行会跳过同一次运行。只有在用户明确要求重新发送该次运行时，才使用 newsjack monitor delivery send <slug> --message-file <run-folder>/slack.md --run-id <run-folder-name> --force。
7. 投递失败不影响报告：保留 run.md 和 slack.md，不要自动重试，并在不泄露 Webhook 的前提下报告失败。如果 Slack 可能已接受消息但响应丢失，或者 Slack 已接受消息但本地“已发送”标记未能保存，则结果存在歧义。Slack 不接受可自动丢弃重复消息的请求密钥，因此手动重新发送前，请先检查频道。

投递授权来自用户已保存的设置策略。每次定时运行时都不要再次询问，也绝不要通过此技能配置 Slack 或发送测试消息。

时效性门槛

对于周期性定时输出，只有在验证 Go 计算得出的 freshness_gate.computed_status 后，才能呈现信号。新闻搜索中的 published_at 值可作为文章发布时间的有力证据，帮助追溯原始报道，但它们本身绝不能决定是否为同一事件或首次发布——这属于 story-origin-check atom 的职责。

周期性输出规则：

• 只呈现 fresh 或 fresh_new_development。拒绝 stale 和所有 unverified_* 状态。这些未验证状态有意区分：unverified_no_corroboration（worker 引用的独立来源少于 2 个——属于管线遗漏，通常可重新运行）、unverified_boundary（仅有日期的时钟跨越截止时间）和 unverified_no_timestamp（未能找回时钟信息）。请分别报告，避免将 worker 质量问题误认为确实过时的报道。
• 使用 --demote-unmatched-x 运行，这样未匹配的 X News/Trends 集群会降至队列门槛以下，除非大型报道召回保护机制将其提升。默认情况下，X News 会显示供审核；周期性输出若要保证准确率，应将其降级，除非它确实是重大报道。
• 在检索之前先聚类（步骤 3b），并优先使用 --drop-stale，以免联合发行的重复内容和明显过时、价值较低的内容浪费 story-origin 检索资源。
• 对 AOL、Yahoo、MSN、Apple News、合作伙伴联合发行、通讯社转载、SEO 改写，或规范来源报道更早但标注为“今天发布”的页面，不要重置时钟。
• 只有当较新的文章带来了具体的新公开事实时，才会重启时钟：官方行动、文件提交、声明、数据/报告发布、实质性的公司更新、新的本地影响，或其他可独立报道的进展。
• 优先将 story_origin.canonical_coverage_url 用作报告的主链接——即关于同一事件最重要、最权威的报道，而不是触发检索的随机转载内容。

origin-apply 会为选中和拒绝的信号附加 story_origin 和确定性的 freshness_gate。如果无法验证首次发布时间，请写入 first_public_at: null 并说明原因；origin-apply 会计算相应的 unverified_* 状态。

交接

• 突发新闻／当天已有来源支持的评论 → reactive-comment
• 需要故事角度 → angle-generator
• 指定记者核查 → journalist-fit-check
• 稿件点评 → meanest-editor
• 需要收件人名单 → 使用机会中需经批准才能访问的 Medialyst 链接；或者，对于明确获准使用积分的 Agent 驱动任务，使用 find-journalists

完成检查清单

报告 Full Mode 运行完成前：

• coarse_relevance_decisions.json 中的决策数量必须与输出的候选项数量完全一致（除非使用 --allow-missing）。
• clustered_candidates.json 必须由 cluster 生成；story-origin 必须针对其代表项运行，并说明合并了多少重复项／过时项。
• origin_findings.json 必须针对每个聚类代表项恰好包含一条发现（除非使用 --allow-missing）——验证数量，并重新运行以补齐缺漏。
• targeted_candidates.json 必须由 origin-apply 生成；triaged_candidates.json 必须由 newsjack-triage 生成，且每条信号都带有 tier；pitch_ready 在 pitch 模式下交给 angle-generator，在探索模式下交给 big_story。
• 不得将任何新出现的 high／major 故事归入 watch——每条新出现的大故事都必须出现在 🔥 值得关注的大故事（如果达到 standing，则出现在 ✅ 可供推介）中。简短的禁止推介规则可以将大故事从 可供推介 中移出，但它仍须作为已展示的 big_story 保留（off_policy: true），不得丢弃。
• 如果提供了客户简报，报告必须据此处理：不符合政策的项目必须移出 pitch_ready；任何被合并的部分都必须说明数量和原因；本轮中会改变政策的反馈必须作为 brief.md 编辑建议提供。
• final_report.md 必须是三类扫描结果（✅ 可供推介 / 🔥 值得关注的大故事 / 👀 观察／背景），并根据 targeted_candidates.json／triaged_candidates.json 撰写，而非原始的 candidates.json。
• final_report.md 生成后，必须从经过门控／新鲜度筛选／分类的产物渲染技能版 run.md——绝不能只依据原始 candidates.json。
• 只有在 run.md 生成后才能检查 Slack。如果已配置，则必须遵循已保存的政策，slack.md 只能包含最终可公开的信息，并记录 CLI 投递结果。较旧 CLI 缺少支持或投递失败，不会使报告失效。
• 每个 pitch_ready 机会都必须包含一个 URL 编码正确、可公开、需审批的 Medialyst 媒体列表链接；big_story 或 watch 项目不得包含此类链接。
• 检测器不得调用会消耗额度的媒体列表 API；它只能生成深层链接。
• ✅／🔥 部分不得包含任何粗筛排除或触发硬性安全标记的信号；硬性丢弃项（URL 卫生检查 + 硬性安全检查）的数量必须根据 JSON 产物披露。
• 最终响应必须列出 run.md 的路径、粗筛引擎（jev、低成本 worker 或当前模型回退方案）及成本优化／回退状态、每条已展示信号是否都已验证其首次公开时间在 24 小时以内、主要发现，以及已配置时的 Slack 投递状态。

输出格式

必须严格返回以下 JSON 对象。前后不得附加任何说明文字。每个机会都必须在 evidence_used 中包含来源 URL——若存在，先列出 story_origin.canonical_coverage_url，然后列出原始／来源 URL 及其他佐证（通常是 1–3 个来自新闻、RSS 和 X 的链接）。

仅当 verdict 为 pitch_now 或 pitch_ready 时才包含 media_list_handoff。对于 big_story、watch 和其他所有 verdict，省略此字段。以下示例展示了 pitch-ready 的结构。

机器交接

{
  "opportunities": [
    {
      "signal_id": "engine signal id",
      "signal_title": "Observed public signal",
      "verdict": "pitch_now",
      "decay": {
        "stage": "4hr",
        "rationale": "Why this clock applies"
      },
      "story_size": {
        "band": "low | moderate | high | major",
        "score": 0,
        "rationale": "How publication traffic/domain authority and coverage spread should affect effort priority"
      },
      "first_publication": {
        "status": "fresh | fresh_new_development",
        "first_public_at": "ISO timestamp or YYYY-MM-DD",
        "original_url": "https://...",
        "canonical_coverage_url": "https://... or null",
        "canonical_coverage_source": "Outlet/source name or null",
        "rationale": "Why this first-public clock controls"
      },
      "why_newsjacking_worthy": "Specific reason this is timely and not generic trend-chasing.",
      "client_standing": {
        "assessment": "strong | partial | weak",
        "rationale": "What gives the client standing, or what is missing"
      },
      "journalist_shape": {
        "beat_description": "Specific reporter shape, not a name",
        "why_they_care_now": "Why this beat plausibly cares now",
        "do_not_target": "Who should not receive this"
      },
      "evidence_used": [
        {
          "source": "news_search",
          "title": "Evidence title",
          "url": "https://...",
          "published_at": "YYYY-MM-DD"
        }
      ],
      "media_list_handoff": {
        "provider": "Medialyst",
        "mode": "approval_gated_deep_link",
        "prompt": "Public-safe campaign brief, maximum 2,000 characters",
        "url": "https://medialyst.ai/app/_/workflow/campaign?prompt=URL-ENCODED-PROMPT",
        "credit_note": "No credits are spent until the user reviews and approves the plan in Medialyst."
      },
      "next_skill": "angle-generator"
    }
  ],
  "rejected_signals": [
    {
      "signal_id": "engine signal id",
      "signal_title": "Rejected public signal",
      "reason": "no_client_standing",
      "first_publication": {
        "status": "stale | unverified_no_corroboration | unverified_boundary | unverified_no_timestamp | null",
        "first_public_at": "ISO timestamp, YYYY-MM-DD, or null",
        "original_url": "https://... or null",
        "canonical_coverage_url": "https://... or null"
      }
    }
  ],
  "brand_safety_blocks": [
    {
      "signal_id": "engine signal id",
      "signal_title": "Blocked public signal",
      "reason": "tragedy_or_human_suffering"
    }
  ],
  "monitor_notes": [
    "Operational note or missing source, if relevant"
  ]
}

• 允许的 verdict：pitch_now、develop_angle、monitor、reject。
• 允许的拒绝原因：stale、freshness_unverified（总括项；或具体原因 unverified_no_corroboration／unverified_boundary／unverified_no_timestamp）、single_source、no_client_standing、no_journalist_shape、off_beat、already_seen、weak_signal、no_viable_angle。
• 允许的品牌安全拦截原因：tragedy_or_human_suffering、client_exclusion、regulated_claim_risk、fabrication_risk。

评分标准

引擎返回排队证据后，使用此评分标准。引擎会提供机械评分和 routing.queue_priority；两者都不代表 PR 判断。

引擎有两条发现渠道：

• profile_relevance - 个人资料／主题／竞品查询。这些查询会捕捉高度相关但有时影响较小的新闻。
• major_news - 精选 RSS／Atom 订阅源条目。这些条目会优先捕捉更广泛的重大新闻，之后需要更严格地判断其与客户端的相关性。

不要因为 major_news 条目影响重大，就认为它适合提案。客户端仍需具备相应立场，并且有明确的记者切入方式。

新闻规模

使用 story_size 来调整投入，不要用它来批准提案。这是基于新闻搜索发布元数据的确定性媒体关注度代理指标：

• 对估算月流量进行对数缩放
• 域名权威度
• 在独立收录的多个域名中的报道分布

对于缺少权威度元数据的知名大型媒体，引擎可能会使用低置信度的知名媒体回退值。当其他发布元数据较少时，引擎可能会附加 story_size.attention_hint。将该提示视为低置信度的持续关注信号：它可以作为在重大新闻版块中进行审核的理由，但不能证明该新闻得到了广泛报道。请明确标注不确定性。

major 或 high 级别的新闻规模，或 high／major 级别的关注度提示，表示该机会可能值得加快审核。这不能弥补时效性过差、立场薄弱或记者切入方式不当的问题。

时效性

对于定期安排的输出，LLM story-origin-check 会找回首次公开时间戳和权威报道，然后由 Go CLI origin-apply 计算时效性门槛。新闻搜索中的 published_at 值是可靠的文章时间戳证据，应当用于寻找可能的原始报道，但不能单独作为判断是否为同一新闻或是否为首次发布的依据。

分配 pitch_now、develop_angle 或 monitor 之前，请检查 freshness_gate.computed_status：

• fresh - 符合正常判断条件。
• fresh_new_development - 符合条件，但切入角度必须围绕新进展，而非较早的背景新闻。
• stale - 作为过时新闻拒绝。
• unverified_no_corroboration、unverified_boundary、unverified_no_timestamp 或缺失 - 定期安排的输出中应拒绝。记录原因：unverified_no_corroboration 表示工作进程／流水线遗漏（时效性可能没问题，只是来源不足，可重新运行）；而 unverified_boundary／unverified_no_timestamp 表示证据确实不足。

不要因为聚合方、联合发行合作方或二级媒体转载了较早的文章，就重置时钟。

引用新闻时，如果存在 story_origin.canonical_coverage_url，优先使用它。它应指向对同一新闻的主要报道或最权威报道，例如一手来源、通讯社、大型出版商或公认的行业媒体，而不是触发检索的小型转载媒体。

判定梯级

pitch_now

仅当以下条件全部满足时使用：

• 证据具有时效性：通常为 30min、4hr 或 24hr。
• 已验证首次公开报道时间在过去 24 小时内，或者新进展发生在过去 24 小时内。
• 至少有一个可信的新闻来源，最好是 news_search。
• 客户端有直接立场可以发表评论。
• 客户端有真正的发言人或直接领域权威。
• 有明显且具体的记者切入方式。
• 不存在严格的品牌安全禁限情形。

develop_angle

当信号真实但需要进一步构思时使用：

• 具有时效性或仍在一周之内。
• 客户端立场有一定合理性，但还不够明确。
• 存在记者切入方式，但角度仍需打磨。
• 重大新闻渠道中的条目，如果影响重要但客户端角度较间接，通常适合此项。

移交：angle-generator。

monitor

当信号值得关注，但还不适合直接推介时使用：

• 仅有单一来源，或跨来源佐证较弱。
• 出现早期讨论，但尚无足够新闻佐证。
• 客户可能具备相关资历，但角度尚不明确。
• 如果信号获得更多关注，可能会变得重要。

reject

当任何核心门槛未通过时使用：

• 内容过时
• 在定期安排的输出中，无法验证时效性
• 客户不具备相关资历
• 没有合理的记者画像
• 与报道方向不符
• 已经出现过，且没有新进展
• 来源质量较差

时效衰减

时效衰减使用 story-origin-check 验证过的首次公开时间戳。如果证据来自聚合平台、联合发行合作方、二次改写内容，或尚未与原始／权威报道匹配的搜索结果，那么引擎的 features.decay_bucket 只是暂定值。

• 30min - 正在发生／突发新闻。仅当客户现在就能回应时，才用于即时评论。
• 4hr - 同一新闻周期内。适合进行即时评论。
• 24hr - 仍然具有时效性。适合生成切入角度或在当天回应。
• week - 仅用于趋势／背景分析。不要称其为突发新闻。
• month - 通常不适合借势新闻，除非有新的数据点或新鲜切入角度。
• unknown - 未经独立时间戳验证时，不要将其作为时效性话题推介。

相关资历

相关资历强：

• 客户直接在受影响的市场中运营。
• 客户直接受到市场影响，具备专业技术知识，或有能够具体发言的具名高管。
• 信号提及客户所在的类别、客户群、监管机构、技术或竞争对手。

相关资历部分匹配：

• 客户具备相邻领域的专业知识，但需要更聚焦的角度。
• 客户能够解释影响，但无法解释事件的核心。

相关资历弱：

• 客户只是在广义类别中销售产品。
• 客户只是因为话题热门而想发表评论。
• 客户只有泛泛的思想领导力内容。

对于 major_news 赛道的信号，相关资历必须说明公共新闻与客户之间的关联：

• 受到影响的是同一买方
• 涉及同一监管机构或政策领域
• 涉及具名竞争对手或平台动向
• 客户能够解释一个不明显的运营影响

如果关联理由是“这是关于 AI 的新闻，而客户也使用 AI”，则应拒绝或列入观察。

记者画像

有用的记者画像应说明：

• 具体报道方向
• 媒体类型
• 该报道方向为何此时关注
• 不应发送给谁

不佳的画像：

• “商业记者”
• “AI 记者”
• “科技媒体”
• “行业媒体”

较好的画像：

• “在监管机构采取行动后，报道供应商合规声明的企业 AI 记者”
• “报道新执法措施引发的身份风险影响的网络安全行业记者”
• “报道当天政策变更对劳动力成本影响的零售运营记者”

硬性拦截

拦截基于以下内容的信号：

• 死亡
• 暴力
• 灾难
• 战争
• 虐待
• 性暴力
• 人员失踪
• 人道主义危机
• 仇恨犯罪
• 恐怖主义
• 自杀

对于这些话题，唯一可接受的处理方式是由具备直接公共利益相关资历的专家进行审慎评论。拒绝带有宣传性质的切入角度。

示例

立即推介

引擎信号：

{
  "id": "s1",
  "title": "FTC opens inquiry into AI compliance claims",
  "sources": ["news_search", "x"],
  "features": {
    "decay_bucket": "4hr",
    "source_count": 2,
    "seen_before": false,
    "profile_matches": ["AI compliance", "enterprise governance"],
    "safety_flags": []
  },
  "routing": {
    "lane": "profile_relevance",
    "queue_priority": 86.2,
    "demoted": false
  },
  "mechanical_scores": {
    "freshness": 1.0,
    "source_agreement": 0.78,
    "novelty": 1.0,
    "profile_match": 0.44,
    "source_quality": 0.825,
    "momentum": 0.21,
    "major_news": 0.0
  }
}

技能输出：

{
  "signal_id": "s1",
  "signal_title": "FTC opens inquiry into AI compliance claims",
  "verdict": "pitch_now",
  "decay": {
    "stage": "4hr",
    "rationale": "The signal is same-cycle by verified first-public clock, not just the search-result timestamp."
  },
  "first_publication": {
    "status": "fresh",
    "surfaced_article_published_at": "2026-05-25T13:14:00Z",
    "first_public_at": "2026-05-25T13:10:00Z",
    "original_url": "https://www.ftc.gov/news-events/news/press-releases/example",
    "canonical_coverage_url": "https://www.reuters.com/legal/government/ftc-opens-inquiry-ai-compliance-claims-2026-05-25/",
    "canonical_coverage_source": "Reuters",
    "rationale": "The official FTC press release is the earliest verified public source and is inside the 24-hour cron window."
  },
  "why_newsjacking_worthy": "Regulator action creates a live need for explainers on AI compliance claims.",
  "client_standing": {
    "assessment": "strong",
    "rationale": "The client works directly in enterprise AI governance and can explain claim substantiation."
  },
  "journalist_shape": {
    "beat_description": "Enterprise AI reporter covering compliance and regulator scrutiny",
    "why_they_care_now": "They need sourced reaction while the inquiry is fresh.",
    "do_not_target": "General startup roundups or consumer AI reviewers"
  },
  "evidence_used": [
    {
      "source": "Reuters",
      "title": "FTC opens inquiry into AI compliance claims",
      "url": "https://www.reuters.com/legal/government/ftc-opens-inquiry-ai-compliance-claims-2026-05-25/"
    },
    {
      "source": "FTC",
      "title": "FTC opens inquiry into AI compliance claims",
      "url": "https://www.ftc.gov/news-events/news/press-releases/example"
    }
  ],
  "media_list_handoff": {
    "provider": "Medialyst",
    "mode": "approval_gated_deep_link",
    "prompt": "Find enterprise AI reporters covering compliance and regulator scrutiny for outside expert reaction to the FTC inquiry. The client works directly in enterprise AI governance. Exclude consumer AI reviewers and general startup roundups. Source of record: https://www.reuters.com/legal/government/ftc-opens-inquiry-ai-compliance-claims-2026-05-25/",
    "url": "https://medialyst.ai/app/_/workflow/campaign?prompt=Find%20enterprise%20AI%20reporters%20covering%20compliance%20and%20regulator%20scrutiny%20for%20outside%20expert%20reaction%20to%20the%20FTC%20inquiry.%20The%20client%20works%20directly%20in%20enterprise%20AI%20governance.%20Exclude%20consumer%20AI%20reviewers%20and%20general%20startup%20roundups.%20Source%20of%20record%3A%20https%3A%2F%2Fwww.reuters.com%2Flegal%2Fgovernment%2Fftc-opens-inquiry-ai-compliance-claims-2026-05-25%2F",
    "credit_note": "No credits are spent until the user reviews and approves the plan in Medialyst."
  },
  "next_skill": "reactive-comment"
}

拒绝（过时的联合发行内容）

引擎信号：AOL 的文章于今天发布，但权威 URL 指向一篇 5 月 4 日发布的 BBC 报道，且没有新进展。

结论：reject

原因：stale

first_publication.status：stale