prioritizing-my-inbox

排定我收件箱的优先级

活跃项目的收件箱中有数百或数千条未关闭报告。 默认列表顺序会先显示用户建议的报告，然后按状态和更新时间排序。 这个顺序并非针对个人的排序。 此技能会生成一份个性化列表：列出此人最想优先处理的报告，并为每条报告说明原因。

排名由三个输入决定：

1. 此人当前的情况。 activity-summary-get 会返回此人当前关注的主题、拥有和关注的对象，以及参与的产品。
2. 模型的预测。 每条报告都包含 ranking.predictions，其中有 open、action 和 fix 的概率及提升值。
3. 报告需要此人做什么。 建议审阅者、由此人负责回应的声明、pending_input 状态，以及等待合并的已批准拉取请求。

输出是排名列表，而不是数据倾倒。 请结合判断来决定分数之外的排序：分数负责筛选候选项，由你决定顺序。

解析请求

• N：「前 10 条」「我的前 5 条」「25 件事」。默认取 25 条。超过 50 条时，提醒用户后面的候选项相关性较低，并询问是否改用筛选条件。
• 关注点：某个主题、产品或关键词（「只看异常相关的」「错误跟踪」）。除非用户说「仅限」，否则它会作为额外的候选池和加权因素，而不是硬性筛选条件。
• 排除项：「跳过摘要」「不要侦察机群相关的」「不要包含已有拉取请求的内容」。
• 时间范围：「本周」「今天」「自周一以来」。默认查看过去 14 天内创建或更新的报告。
• 模式：「我可以修复的」「等我处理的」「只看新的」。每种模式都会对应下文的候选池或加权因素。

第 1 步：加载此人信息

activity-summary-get
{}

根据响应，构建一个兴趣档案：

• 带有 strength 和 last_seen 的主题。过去 3 天内出现且 strength: high 的主题权重最高。
• 从 computed.owned 和 computed.watched 中提取的具体词项：技能名称、标记键、已保存的查询名称、洞察和仪表板名称。这些词项与报告的匹配效果远胜于通用主题词。
• 产品：来自 computed.products.works_in 和 computed.pages。这些可映射到 source_product 和报告主题。
• profile 中的近期询问内容。此人本周询问过的报告是强候选项。

通用词不适合作为搜索词。 在繁忙的项目中，search: "ranking" 可能会匹配数百条报告，因为摘要中可能顺带提到排名。 优先使用具体词项，例如拥有的技能名称（anomaly-metrics）、标记键，或主题标签中的独特短语。

如果调用返回 status: not_ready 或 404，说明此人没有摘要。 用一句话说明，然后继续使用其他信号。 此时排名将更多依赖建议审阅者路由、声明和模型预测。 可以询问此人是否愿意说出两三个自己关心的主题，并将其用作兴趣档案。

步骤 2：收集候选项

报告行很大（通常每行 3 到 4 KB，主要是摘要），因此应分几组获取小批次，而不是一次拉取一整页。 每次调用的 limit 不要超过 20。 传入已获取报告的 ID 作为 exclude，让后续批次保持新鲜。 exclude 最多接受 100 个 ID，API 会拒绝更长的列表，因此应发送最希望跳过的 100 个 ID（目前最有竞争力的候选项），其余部分在本地去重。 不同批次会有重叠；按 id 去重，并记录每份报告来自哪些批次。

批次	调用	原因
推荐给你	view: "for_you"、sort: "recommended"、created_after: <window>	已分配给他们、正等待他们处理，或由他们认领
最近更新	view: "for_you"、ordering: "-updated_at"，不设 created_after	有新动态的较早报告，例如新的 PR 批准或问题
我的	assignee: "mine"	他们或其 Agent 已负责的工作
可能采取行动	view: "actionable"、ordering: "-ranking_action"、created_after: <window>	模型认为某人会采取行动的事项
新近且可能已打开	created_after: <last 3 to 7 days>、ordering: "-ranking_open"	值得一看的新报告
主题搜索	search: "<specific term>"、created_after: <window>，每个热门主题调用一次（调用 3 到 5 次，limit 设为 10 到 15）	路由未能识别的个人相关事项
需要我提供意见（可选）	view: "needs_input"、scope: "for_me"、created_after: <window>	只有他们能做出的决定

所有批次都使用 inbox-reports-list。 务必为 for_you 和 needs_input 设置时间范围。 created_after 只按创建时间筛选，因此，创建时间早于时间范围、但在范围内更新的报告，只会通过“最近更新”批次出现。 该批次以 updated_at 作为时间范围：持续翻页，直到 updated_at 超出时间范围，并在翻到 3 页后停止。 assignee: "mine" 不设时间范围，因为认领永不过期，所以可能返回数百行。保持默认排序，只读取第一页。 活跃项目的这些视图可能包含上千份报告，而最早的 pending_input 行带有过时的分数，看起来却很高。

对于不在排名功能灰度发布范围内的用户，排名用的 ordering 值和 ranking_min_* 筛选器会返回 400。 出现这种情况时，改用 sort: "recommended"，并查看响应中的 ranker 字段，了解使用了哪种排序。 用户可查看的行仍会带有 ranking.predictions，因此可以在客户端评分。

目标是收集 60 到 150 个不重复的候选项。 这足以选出强劲的前 25 项，而无需读完整个收件箱。

步骤 3：评分

剔除 status 为 resolved、suppressed 或 failed 的报告，以及 work_state: done 的报告。 只有当对方询问出了什么问题时，才保留 failed。 然后为每个候选项打分。 references/scoring.md 包含默认公式、各项指标背后的理由，以及计算示例。 简而言之：

score = priority_base × model_multiplier × freshness
      + interest_bonus + needs_me_bonus

• priority_base：P0 为 5，P1 为 4，P2 为 3，P3 为 2，P4 为 1，无优先级为 1.5。
• model_multiplier：取 action 和 fix 提升值的平均值；仅当 ranking.status 为 scored 且 scored_at 在约 7 天内时应用。否则为 1.0。缺少提升值表示未知，不代表低。
• freshness：优先考虑最近 2 天内更新的报告；对 3 周未更新的报告降低权重。
• interest_bonus：与兴趣档案进行匹配。标题匹配优于摘要匹配。与近期出现且强度高的主题匹配，优于与过时主题匹配。
• needs_me_bonus：建议的审阅者、由对方负责答复的声明、路由给对方的 pending_input，以及已获批准但仍未合并的拉取请求。

然后进行判断：

• 合并系列报告。 编写每日摘要的侦察器会生成标题几乎相同的报告（“每周结账健康状况，10 月 26 日：……”“每周结账健康状况，10 月 27 日：……”）。保留最新的一篇，并注明合并了多少篇较早的报告。
• 合并重复报告。 关于同一问题的两篇报告（通常一篇来自侦察器，一篇来自 GitHub 来源，并关联同一个拉取请求）只占一个名额。附上两篇报告的链接。
• 找出已完成的工作。 pending_input 报告可能要求对方完成某项工作，而对方之后已经完成了，例如刚在步骤 1 中调用的工具。将其保留在列表中，并将“可能已经完成，要解决吗？”作为下一步。清除此类报告很有用。
• 尊重“已处理”。 already_addressed: true，或由其他人正在积极推进的拉取请求，都会降低报告的优先级；但如果对方是审阅者，则不降低。
• 保持多样性。 如果某个主题占据列表的一半以上，就降低其中最弱项目的排序，让对方也能看到其他方面的内容。如果对方只要求查看该主题，则跳过这一步。
• 优先展示正等待对方处理的事项。 对方报告中的已批准拉取请求，或只有对方才能做出的决定，往往比由其他人负责的高优先级事项更重要。

步骤 4：展示列表

先用一行说明使用了哪些内容：活动摘要的版本和标题（缩短后）、候选池，以及评分的候选项数量。 然后按相关性从高到低列出排名结果。 每篇报告：

1. [<title>](<_posthogUrl>) · P2 · 1d · ready, PR #123 open (approved)
   Why you: activity-summary rollout theme, you're the suggested reviewer
   Model: action 9.1x · fix 4.7x
   Next: review and merge the PR

• 标题链接，来自 _posthogUrl。始终包含。
• 优先级、时效（取自 updated_at；新报告则取自 created_at）、状态（status、work_state、PR 及其审阅状态；如果由其他人负责，也注明负责人）。
• 与你有关的原因：用通俗语言说明它排名靠前的一个或两个主要原因。指出匹配的主题或由对方负责的对象。
• 模型：action 和 fix 的提升值（如果其他值缺失，则使用 open）。如果没有评分或评分已过时，请写“未评分”或“评分已过时”，不要留空。提升值是模型估算值，因此应将其表述为相对可能性，而不是胜算。
• 下一步：一项具体操作。审阅 PR、回答问题、认领、忽略，或直接阅读。

每项控制在三到四行，每行简短。 列表之后最多添加三行：

• 说明合并了哪些内容（系列、重复项），以及有哪些值得注意的内容被排除。
• 说明如何调整：“说‘聚焦异常评分’、‘跳过摘要’或‘列出我能修复的前 10 项’即可重新排序”。
• 提出可以深入了解任意条目的建议。对于深入查看、执行操作或解决问题，转交给 inbox-exploration。

如果对方要求使用表格，或者 N 较少且对方希望快速浏览，则使用表格代替列表。

重新排序

当用户调整请求时，重复利用已有的候选项。 只有当调整需要你没有的候选池时，才获取更多（新的主题搜索、更宽的时间范围、暂缓的报告）。 常见调整：

用户说	操作
“更多关于 X 的内容”／“重点关注 X”	为 X 添加一个搜索池，大幅提高 X 匹配项的权重
“只要 X”	筛选出与 X 匹配的项
“跳过摘要”／“跳过侦察器 Y”	按标题模式或 scout_name 排除
“我可以修复的内容”	保留没有 PR 且 actionability: immediately_actionable 的项，提高 fix 提升值的权重
“有哪些事在等我处理”	仅保留需要用户处理的报告（对这些报告保留 pending_input、PR 审批和用户认领的项）
“只看新内容”	将时间范围设为最近 1 到 3 天，并按 created_at 排序
“忽略模型”	将 model_multiplier 设为 1.0，并说明这一点

防护措施

• 此技能仅用于读取。未经用户按名称指定报告，不要对列表中的报告进行认领、驳回、解决或执行操作。此类操作请使用 inbox-exploration。
• 模型预测描述的是可能发生的情况。较高的 fix 概率不代表报告已修复。请查看 status 和 PR 字段。
• 切勿长篇复述活动摘要。它是用于排序的个人上下文。请提及报告匹配的主题，而非用户画像。
• 如果收件箱为空或候选池没有返回结果，请先运行 inbox-exploration 中的设置检查，再告知用户收件箱为空。