# 珩宇科技 · 每日信息摘要口径

> 适用：产品运营岗每日信息梳理　版本：v1.3（2026-06-01）
> 目的：把散在多个渠道的当日信息，压成一份"看完就知道要做什么"的摘要

---

## 一、四个分类的判定标准

| 分类 | 判定标准 | **不属于本类的情况** |
|---|---|---|
| **① 变更** | 已经发生的、与原计划不同的事：需求变更、排期调整、接口改动、人员或职责变动、环境变更 | 仅在讨论中、尚未确定的调整 |
| **② 决定** | 有明确决策人、已经拍板的事 | 群里"我觉得可以"这类倾向性表态；讨论中的多个方案 |
| **③ 风险** | 可能导致延期、故障、客户投诉或返工，**且截至当前尚未解决** | **当日已解决或已回滚的问题**——归入变更或不列 |
| **④ 需回复** | **需要我本人**给出回应、确认或决定的事项 | 仅知会我、抄送我、或 @ 我但明确说"不用回"的 |

## 二、跨渠道去重

同一件事往往会在多个渠道各出现一次（典型路径：群里先讨论 → 邮件正式确认 → 项目系统状态更新）。

**判定为同一件事的依据：** 同一需求编号 / 工单号 / 项目节点，或明确指向同一对象与同一动作。

**合并规则：**

1. 合并为 **1 条**，**以正式程度最高的渠道为准**（正式度：项目系统 ≈ 邮件 > 群聊）；
2. 保留各渠道的出现位置，便于回查；
3. **如果各渠道说法不一致，以时间最晚的正式记录为准，并把不一致单独标出**。

## 三、改口与撤回

群聊中经常出现"先说 A、后改 B"。处理规则：

1. **只采纳最终结论**，中间过程不写入摘要；
2. **但如果最终结论只出现在群聊、尚未进入邮件或项目系统，必须标为"待补正式记录"**——这类最容易在第二天出事；
3. 明确撤回的内容不写入摘要，仅在需要时注明"已撤回"。

## 四、@ 我的三种情况

| 情况 | 判定 | 处理 |
|---|---|---|
| @ 我 + 提出了需要我回答的问题或要我决定 | **需回复** | 列入④，标注截止时间 |
| @ 我 + 只是同步信息、告知进展 | 知会 | 不列入④ |
| @ 我 + 后续消息中已由他人代为解决 | 已消解 | 不列入④，但需确认确已解决 |

## 五、噪音（不进摘要）

订餐、团建、生日祝福、纯表情回复、与本人职责无关的其他项目讨论、重复转发的公司公告。

## 六、摘要固定结构

1. 今天必须我做的事（含截止时间，按最晚可处理时间排序）
2. 变更 / 决定 / 风险 三类清单
3. 待补正式记录的事项
4. 与我明日安排的冲突提示
5. 仅知会（一句话带过）

---

*本口径为虚构练习素材。*