可信联系人：OpenAI推ChatGPT新机制，AI风险外联怎么做？

OpenAI 给 ChatGPT 增加了一项很不寻常的新功能：可信联系人。它表面上是一个安全辅助开关，实际上传递出的信号更大——当 AI 越来越像一个长期陪伴、持续交互、频繁响应的产品时，【数据安全】不再只是拦截违规内容，而是要把风险识别、人工确认和外部协同真正串成一条链路。对 App 开发者、产品经理和增长团队来说，这不是一个边缘功能更新，而是 AI 产品安全结构开始外扩的标志。

新闻与环境拆解

这次上线的“可信联系人”到底是什么

按照 OpenAI 帮助中心的说明，可信联系人是 ChatGPT 面向成年个人用户逐步推出的一项可选安全功能。用户最多可以添加 1 位可信联系人，对方需在 1 周内接受邀请，功能才能正式生效。它目前主要适用于个人 ChatGPT 账户，不会在 Business、Enterprise 这类共享工作空间中启用。

这项能力的设计目标很清晰：如果自动化系统识别到用户对话中出现可能构成严重安全隐患的自杀相关表述，并且经过专业审核人员复核确认后，ChatGPT 可能会通知用户事先设定的可信联系人，鼓励对方主动联系用户，给予现实中的关心与支持。

这意味着，ChatGPT 正在尝试把“高风险对话”从纯线上交互推进到现实世界中的最低限度外联。它不是把 AI 变成心理医生，也不是让联系人承担危机处理责任，而是在系统判断用户可能需要帮助时，增加一个现实社会支持网络的触发点。

它是怎么运作的

从公开流程看，这项功能大致分为四步。

第一步，是用户主动添加可信联系人。用户需要填写对方的姓名、电子邮件地址，电话号码为选填项。OpenAI 建议最好同时预留两种联系方式，以提高后续提醒触达的可能性。

第二步，是对方接受邀请。邀请函不仅是一个确认动作，也会向对方说明“可信联系人”这个角色意味着什么、需要承担哪些有限责任、又不需要承担哪些专业职责。如果对方拒绝邀请，或在 1 周有效期内未回复，这次设置就不会生效，用户需要重新选择联系人。

第三步，是风险检测与人工审核。OpenAI 没有把这个流程做成完全自动触发，而是强调：当系统检测到严重风险信号后，还会由专业审核人员复核整段对话，以确认是否真的存在需要外联的安全隐患。更重要的是，如果对话进入这一流程，ChatGPT 会提前提示用户，说明有可能通知可信联系人。

第四步，才是通知发出。提醒可能通过电子邮件、短信或 ChatGPT 应用内消息完成。通知内容会告诉联系人：平台近期检测到用户对话中涉及自杀相关讨论，且可能表明存在严重安全风险，希望联系人主动联系用户。但 OpenAI 同时明确表示，不会共享聊天细节，也不会提供具体对话转录内容。

OpenAI 刻意强调了哪些边界

这次功能说明里，OpenAI 反复强调了几个边界，这些边界其实比功能本身更值得产品团队注意。

首先，可信联系人不是紧急救援服务，不是危机响应系统，也不能替代专业的心理健康诊疗。换句话说，它只是一个辅助性的外联机制，而不是正式医疗或应急系统的一部分。

其次，可信联系人不是“责任接管者”。作为联系人，你的角色更像是一个被邀请进入支持网络的人：可以主动问候、表达关心、鼓励对方寻求专业帮助，但不需要扮演心理咨询师，也不需要独自承担对方安全的全部责任。

再次，OpenAI 也承认这套系统不可能完美。系统推送的提醒，不一定完全贴合用户当下的真实处境；自动化模型和人工审核也并非永远准确。这种坦诚反而说明，OpenAI 正在把这项能力定义为一个“尽可能降低风险漏接”的辅助工具，而不是一个保证绝对准确的判断机器。

这项功能为什么值得行业重视

如果只把它看成一个“聊天产品里的联系人功能”，很容易低估它。它真正重要的地方在于：OpenAI 正在重新定义 AI 产品的安全责任边界。

过去，很多 AI 产品的安全逻辑停留在三层：

• 输出限制，避免模型生成明显危险内容；
• 风险提示，给出危机热线或求助建议；
• 内容审核，把某些高风险表达挡在系统边界内。

而可信联系人向前走了一步。它把 AI 安全从“模型说什么”推进到了“系统在识别到风险后，是否有能力把信息交给现实世界里合适的人”。这个变化非常关键，因为它意味着高风险场景的处理开始从“单点提示”走向“多角色协同”。

对于大众用户来说，这是一个更有人情味的辅助机制。对于产品团队来说，这却是一次更复杂的系统升级：因为一旦平台开始介入现实关系，安全策略、隐私规则、审核流程、通知逻辑和责任边界都要重新设计。

从新闻到用户路径的归因问题

普通用户看到这条新闻，第一反应往往是：ChatGPT 现在会帮我联系值得信任的人了。
但对于做产品、做增长、做数据架构的人来说，真正的问题完全不同。

问题不在于“有没有联系人”，而在于：当风险链路从聊天框扩展到现实联系人后，用户路径就不再是单线程的了。一次高风险交互，可能会经历设置联系人、邀请接受、对话触发、审核升级、外联通知、联系人响应、用户再次回到 App 或寻求其他帮助等多个节点。这个过程里，很多动作并不发生在同一个界面、同一个终端，甚至不发生在同一个系统里。

这时候，传统的埋点和归因方式就会出现明显盲区。

在很多 App 的既有分析框架里，系统擅长记录的是页面浏览、按钮点击、消息发送、转化完成。可“可信联系人”这种机制涉及的是另一类链路：任务触发、审核升级、角色切换、外部通知、关系承接。它不是简单的用户增长漏斗，而是一条带有安全属性、跨角色传递的信息任务流。

如果你还在用“哪个按钮被点了”“哪次会话时长更长”“哪条消息转化更高”去理解这类场景，很容易失真。因为真正重要的，不是某个页面事件，而是整条任务链是否被识别、被升级、被妥善传递、被现实世界承接。

这就是为什么，在 AI 产品逐渐从工具走向代理、从问答走向执行时，很多团队会突然发现，原有的数据口径不够用了。你看到的是消息发送，真正发生的却是风险外联；你以为记录的是一次聊天，后台实际跑的是一条多角色协同任务。

工程实践：重构安装归因与全链路归因

用 ChannelCode 先统一“风险入口”

对于这类安全任务流，第一步不是急着做复杂模型，而是先把入口定义清楚。
同样是“高风险事件”，可能来自：

• 普通对话触发；
• 某类陪伴模式会话；
• 特定功能区的连续使用；
• 外部提醒重新带回的回访会话。

如果这些入口没有统一标识，后续所有分析都会陷入混乱。更稳妥的做法，是借助 渠道编号 ChannelCode 的思路，把不同风险入口、不同通知来源、不同承接场景统一进一个可追踪的入口体系里。

这样做的好处，是团队能明确知道：
问题是从哪类产品路径里被触发的，哪种场景更容易升级到人工审核，哪类入口更容易形成有效承接，而不是把所有风险事件都堆成一类“异常消息”。

用智能传参把“任务上下文”带下去

第二步，是把上下文带进后续链路。
在很多系统里，事件虽然记录了，但一旦跨出当前页面、当前设备或当前流程，上下文就断了。可在可信联系人这种场景中，真正关键的恰恰不是单一动作，而是动作背后的语境。

更合理的做法，是把 scene、risk_level、contact_status、notify_channel、workflow_id 这类字段，作为任务上下文的一部分贯穿链路。类似的设计思路，也可以参考 xinstall 在智能体分发时代 App 安装传参逻辑的底层重构里强调的做法：不要只记录“发生了什么”，还要尽可能保留“为什么会发生、它从哪里来”。

当系统把这些上下文保留下来后，产品团队就能回答更多关键问题：
这次提醒源于哪类交互场景？
用户此前是否已有可信联系人设置？
通知是通过哪条渠道发出的？
后续回访或支持动作是否真正发生？

用事件模型搭出“风险任务图”

第三步，是不要把这类机制只当成若干离散埋点。
更有价值的做法，是围绕它搭一张任务事件图。

例如，可以围绕以下节点设计事件模型：

• trusted_contact_invited
• trusted_contact_accepted
• risk_dialog_flagged
• human_review_started
• trusted_contact_notified
• user_returned
• support_followup_detected

这样的好处，是你看到的不再只是零散埋点，而是一条清晰的安全任务链。
一旦链路成形，团队就能更容易发现问题出在哪里：是联系人接受率太低，还是高风险识别后的升级判断太谨慎，或是通知发出后没有后续承接动作。

注：本文讨论的这类“跨角色风险任务图”，属于对未来 AI 安全与分发体系的前瞻性工程设计思路。像跨系统外联、通知承接、复杂角色协同等链路，往往涉及高度定制化的数据结构、权限策略与风控规则，并不等同于所有产品都能直接复用的标准功能。若业务侧确有类似高阶安全链路需求，更适合结合实际场景进行专项设计与技术评估。

这件事和开发 / 增长团队的关系

面向开发与架构

如果你负责的是 AI App、陪伴产品、咨询类工具或具备连续对话能力的系统，现在最该做的不是立刻复制一个“可信联系人”按钮，而是先检查现有架构有没有留出这类链路的空间。

优先建议补齐这些能力：

• 风险事件的分级字段，如 risk_level、risk_type、review_status；
• 角色字段，如 actor_type、contact_status；
• 任务链标识，如 workflow_id、scene、channelCode；
• 通知结果字段，如 notify_channel、notify_result、response_window。

这些字段会决定未来你能不能把风险事件从“聊天记录”升级为“可审计、可复盘、可优化的系统任务”。

面向产品与增长

产品团队最容易忽略的一点，是把这类功能误判成“安全部门的事”。
实际上，只要产品进入高频陪伴或深度交互场景，安全功能本身就是体验的一部分。用户是否愿意提前设置联系人、是否理解边界、是否信任平台不会乱发通知，这些都直接影响留存和产品信任。

增长团队也一样。AI 时代越来越多的关键动作，不会表现为传统意义上的转化按钮，而会表现为任务是否顺利被发起、被承接、被完成。风险任务流同样属于任务流量的一部分，只不过它不是增长导向，而是安全导向。

现在可以做什么

现在就可以推进三件事：

• 把高风险会话从普通消息事件里单独拆出来，建立独立事件口径；
• 为多角色链路预留字段，不要把系统、审核员、联系人都混成“用户行为”；
• 检查通知系统与 App 内事件系统是否可对齐，避免外联动作无法回流到数据层。

常见问题（FAQ）

可信联系人会看到我的 ChatGPT 聊天内容吗？

不会。根据 OpenAI 的说明，平台向可信联系人发送通知时，只会说明用户可能讨论了自杀相关内容且存在严重安全隐患，不会共享聊天细节，也不会发送对话转录内容。

ChatGPT 会在什么情况下通知可信联系人？

并不是用户提到情绪低落就一定会通知。OpenAI 的机制是先由自动化系统识别高风险表述，再由专业审核人员复核，只有在判断可能存在严重安全隐患时，才可能触发通知。

可信联系人是不是紧急救援服务？

不是。OpenAI 明确说明，这项功能只是一个可选的辅助安全能力，不能替代危机干预系统、当地紧急服务或专业心理健康诊疗。如果存在现实中的紧急安全威胁，仍应联系当地应急部门或专业热线。

一个人可以添加多个可信联系人吗？

目前不可以。每个符合条件的个人账户最多只能添加 1 位可信联系人，这也说明 OpenAI 在功能设计上更强调“有限、明确、可控”的支持关系，而不是把它做成广泛通知网络。

行业动态观察

从更长周期看，可信联系人最值得行业重视的，不是它新增了一个联系人设置页，而是它把 AI 安全的重点从“模型是否合规”推进到了“系统是否能把高风险任务交给现实世界里合适的人”。这一步一旦成立，未来更多 AI 产品都要面对同样的问题：一段对话何时升级为任务，任务何时升级为外联，外联之后如何形成闭环。

对 App 和 B 端团队来说，这种变化会倒逼产品重新定义很多底层口径。原本只属于会话系统的事件，会逐渐变成跨角色、跨渠道、跨终端的协同链路；原本只在审核后台发生的动作，也会慢慢进入产品主链路。谁能更早建立清晰的事件模型、字段体系和入口定义权，谁就更容易在新一轮 AI 产品演化里保住解释权。

这也是为什么，现在是重构数据体系和归因体系的窗口期。因为 AI 产品正在从“会回复”走向“会处理事”，而一旦产品开始处理事，页面流量的价值就会下降，任务流量的重要性会迅速上升。到了那个时候，你会发现，真正决定产品能力边界的，不只是模型本身，还有你是否能用一套清晰、可追踪、可复盘的【数据安全】体系，把风险任务看清、接住并传递出去。