在 Hacker News 上看到一个问题Should AIs tell you theyre AI? 如果只是从字面理解答案似乎很简单——当然应该。AI 不能假装自己是真人用户有权知道自己在跟谁说话。但真正设计过 AI 产品的人都知道这句话一旦落到具体场景里就会变成一堆更难回答的问题什么时候说怎么说对谁说说了之后用户会更信任还是更怀疑如果 AI 正在替你写邮件、订酒店、生成一段短视频它又该在哪个环节停下来告诉你“我是 AI”我的判断是这个问题表面上在讨论伦理实际上是在讨论产品设计里的信任模型。我们缺的不是一句“我是 AI”的标准话术而是一套能让用户正确评估“我该信它多少”的机制。真正的关键词不是 disclosure披露而是 transparency透明度。1. 先别急着回答“该不该”这个问题背后其实是信任关系1.1 从 Hacker News 上的提问想到的真实场景这个提问让我想起三种真实场景。第一种是客服对话。你打开一个电商平台在对话框里问“这个订单什么时候发货”对面回复很快、语气客气还带了一个笑脸。如果对面是真人客服这很正常如果是一个大模型驱动的对话机器人而且它在回答时没有说明身份你会不会觉得被冒犯第二种是 AI 陪伴产品。用户知道自己在跟 AI 聊天但聊到深夜AI 说“我在我会一直陪着你”。如果这句话被理解成真实承诺身份披露就不仅在法律层面重要在心理层面也很重要。第三种是 AI 编程工具。Cursor 这类工具在你写代码时介入你不会要求它每补全一行都告诉你“我是 AI”因为上下文已经表明它是辅助工具。这三种场景都涉及同一个问题AI 会不会、该不该告诉用户它是 AI。但答案显然不应该是一样的。在过去聊天机器人很容易被识别。机械回复、固定模板、明显答非所问你和它聊两句就知道这不是人。但大语言模型出现后界线变了。一个模型可以流畅地表达情绪、使用口语、记住你的名字甚至模仿某个人熟悉的语气。事实是单看一段文字已经很难判断是真人还是模型。这样AI 是否应该自报身份就不再是礼貌问题而是影响用户决策的基本信息。1.2 “AI 是否该自报身份”真正在问什么一句话总结这个提问真正问的是在人与 AI 越来越难区分的信息环境里谁有责任为用户补上“对方是 AI”的判断依据。如果你在自动取款机前机器不会开机就念“我不是人类柜员”因为你看见的是金属外壳、屏幕和卡槽。物理形态就是身份信号。AI 没有这种物理形态它可能只是一个聊天窗口、一段语音、一个虚拟形象甚至藏在推荐算法背后。因此数字产品必须用界面、文案、交互逻辑来重建身份信号。为什么披露不是简单一句“我是 AI”因为用户需要的不是标签而是心理模型。如果用户知道对面是 AI他可能会用更批判的方式去看结果如果他不知道就可能把 AI 的流畅表达当成可靠信息进而做出错误决定。所以信任模型才是问题核心。披露的本质是让用户知道“我现在面对的信息源可信度有多高”。2. 支持披露和反对强制披露背后的判断基准完全不同2.1 支持方身份透明是防止误导的底线支持披露的立场很清晰AI 的信息生成能力越强误导风险越大所以用户有知情权。这不是反对 AI而是防止 AI 被当成“真人意见”来操纵决策。举几个常见例子一个购物网站用 AI 生成用户评价如果读者以为是真实买家就会被影响购买决定。一个资讯平台用 AI 总结观点如果不标注读者可能当成编辑观点。一个教育产品用 AI 模拟名师如果不披露学生会以为是真人在授课。为什么这些场景需要披露因为内容的形式会给人“来源线索”。真人评价、编辑署名、名师出镜都是用户判断可信度的线索。AI 生成内容唯一打破这个线索的方式就是明确说明“这段内容不是真人生产的”。支持方认为这是防止误导的底线不是可选项。尤其是在医疗、法律、财务这类高风险场景。AI 给的答案可能流畅、自信、结构完整但完全错误。用户如果不知道这是 AI很可能把它当专业意见。身份披露在这里的意义不是给用户添麻烦而是给用户一个“要警惕”的信号。2.2 反对方身份披露不能替代能力边界和设计质量另一种声音也值得认真对待。反对强制披露的人通常不是想骗人而是觉得“AI 身份”不应该成为内容质量之外的第二标准。一个常见反对理由如果一本书是 AI 辅助写的但作者反复校对、补充资料它比很多真人写的烂书更有价值。你只标“AI 生成”反而会让读者轻视内容。类似AI 编程工具帮你写完代码你不需要在代码注释里写“这段是 AI 写的”因为团队的评审流程已经覆盖了质量验证。另一个反直觉的例子让 AI 写一首诗如果生成的每一段后面都带着“以上由 AI 生成”整首诗的可读性会大打折扣。在这个场景里用户知道自己打开的是 AI 作诗工具身份披露已经是上下文的一部分不需要在输出里刷屏。但我不太接受另一个支持“不披露”的理由就是“只要结果好不用管来源”。结果好不好往往要事后验证在用户做判断的那个瞬间来源信息直接影响它是否会盲目采纳。所以反对有效的地方是“不要把披露变成表面功夫”而不是“完全不披露”。还有一个很实际的工程原因不能只依赖模型在对话里说“我是 AI”。模型可能因为上下文、提示词优化或错误输出而遗忘身份在一些角色扮演场景中它甚至可能顺着用户要求扮演真人。从工程角度看披露必须由系统的 UI 层和元数据层来保证不能只靠模型自律。这也是“一刀切强制披露不合理完全不披露更危险”之外产品团队应该更早意识到的问题。3. 不用一刀切按场景决定披露强度更现实3.1 工具型 AI强调“辅助判断”不需要反复自报身份工具型场景包括 AI 编程、AI 写作、AI 搜索、AI 总结以及更多嵌入在业务系统里的模型能力。例如用大模型辅助生成代码、用知识库做问答、用 Agent 框架做自动化。在这些场景中用户打开工具前就已经知道自己在使用 AI身份不是隐藏信息。但这不等于不需要披露。工具型 AI 的披露重点不是“我是 AI”而是“这是 AI 的建议你需要复核”。比如 AI 编程工具补全了一段代码界面可以显示“建议代码请 review”AI 搜索返回摘要答案下方可以写“根据以下来源生成”。用户不会因为每句话都标“AI”而更安全却会因为知道了“这是辅助建议”而更慎重。从开发实践看工具型产品做披露时最容易走极端要么完全不做要么让模型每轮都说“我是 AI”。这其实都不对。比较合适的方式是界面常驻一个轻量标签说明当前对话由 AI 驱动具体输出里在用户可能直接复用的内容上增加来源或复核提示。3.2 角色型 AI情感陪伴和娱乐产品的边界要更清晰角色型 AI 是另一个极端。用户使用 AI 陪伴、虚拟角色、AI 社交产品很多是带着情感需求来的。这类产品如果只在上线时弹一句“你正在和 AI 机器人聊天”远远不够。为什么因为情感对话的长期沉浸感会让用户忘记边界。第一天的明确告知可能被第 30 天的深夜长谈覆盖。用户在孤独、焦虑、喜悦时很容易把 AI 的共情解读为真实的“被在意”。产品设计必须在这种长周期关系里持续维护一个不易被误解的边界AI 会关心你但它没有真实情感能力它的回应来自模型训练数据不是来自“它真的在意你”。实际操作上我建议在三个节点做重复披露注册或首次对话时明确身份连续长时间对话后温和提醒“我是 AI请不要把我当真实关系替代”用户表达强烈依赖或情绪崩溃时提供非 AI 的求助资源。身份披露不是一句话而是一套“关系边界管理”。3.3 代理型 AIAgent 在替你做决策披露必须前置AI Agent 是当前应用开发里最受关注的方向之一但也是披露责任最重的地方。Agent 不只是“回答你”它会在后台执行任务调用 API、写文件、发邮件、买东西。用户授权一个 Agent 去“帮我订周五下午的会议室”Agent 可能选择了一个你认为不合理的时间或者直接提交订单。在这个场景里“我是 AI”远远不够甚至有点像是免责声明的开头。真正需要披露的是接下来我会执行哪些操作执行这些操作时我依据了什么规则如果执行出错你如何撤销。比如一个 Agent 订机票时UI 应该先在行动前展示“我将为你选择价格最低的航班预计价格约 X 元是否确认”然后才是执行。行动的过程状态也要可见。执行完成后记录要可查。对 Agent 类产品“告诉用户我是 AI”只是第一步更关键的是把执行动作、判断依据和撤销路径也告诉用户。所以对 Agent 类产品披露强度应该是最高的。因为用户不再是读一段文字然后判断真假而是把一部分决策权交给了 AI。身份披露不是附加项而是权限控制的一部分。3.4 AI 生成内容只说“AI生成”还不够要说明来源和局限内容平台现在流行的做法是给 AI 生成内容打标比如“AI 生成”。这个方向是对的但粒度太粗。“AI 生成”可能意味着三种完全不同的情况完全由模型生成模型改写或润色真人内容模型基于检索结果生成的摘要。读者对这三种内容的信任程度应该不同。完全生成的虚构故事不需要验证事实但摘要和改写需要知道来源纯 AI 评论则可能造假。我建议内容型产品至少把标签从“AI 生成”扩展为“AI 生成请核对来源”或“根据以下来源生成”并在详情页提供模型版本、生成时间、参考链接。关键是给用户一个验证入口。没有验证入口的“AI 生成”标签只是免责不是透明。4. 把“披露”变成“透明度”一套可落地的工程框架4.1 披露信息不是一行字而是分层信息架构实操上推荐把 AI 身份披露设计成分层信息而不是一个固定文案。第一层是即时身份信号。用户一打开界面就应该从标题、头像、名称、标签上知道“这是 AI”。比如“AI 助手”三个字或者一个机器人图标。这层信息要非常轻但不能缺失。第二层是上下文说明。当用户准备把 AI 输出用于实际决策时界面应该提示“这是 AI 根据你的描述生成的建议可能存在错误请在关键步骤前人工确认”。第三层是证据来源。对重要内容提供模型名称、版本号、参考链接、生成时间。比如知识库问答产品应该在回答下方列出命中的文档方便用户点开核对。第四层是反馈与纠正通道。用户如果发现内容错误可以提交反馈、纠错或要求重新生成。这四层不是每次都全部展示而是按场景展开。第一层常驻第二层在决策前出现第三层在可验证场景出现第四层始终可访问。4.2 可执行的设计清单何时、何处、如何披露下面是一个可以复用的清单适合大多数 AI 产品在设计身份披露时逐条过一遍。首次接触用户进入产品时明确告知当前服务由 AI 驱动。可能混淆对话中引入拟人化表达、语音、形象时加强身份提示。输出可转发用户可以把文本、图片、视频复制出去时在内容上附加来源标记。高风险决策涉及医疗、法律、财务、购物、自动执行时增加“请人工核实”或“操作确认”。用户主动询问用户直接问“你是真人吗”产品必须不回避、如实回答。技术上不要把披露只写进系统 Prompt。模型可能遗忘、可能被角色扮演带偏、可能在不同语言里表达不一致。前端 UI 层要能独立显示身份标签后端要保存模型输出的元数据。这样即使模型输出里没有“我是 AI”用户依然能看到界面上的身份信号。注意不要一上来就在每一轮回复里刷“我是 AI”。高频重复提示会变成噪声让用户忽略真正重要的风险提示。更好的方式是按场景触发而不是按轮次触发。4.3 判断披露是否合理的三个测试和一条排查链路三个测试如果去掉“AI”标签用户会不会因此做出明显错误的判断披露信息是帮助用户行动还是仅仅帮产品团队免责用户能否在 10 秒内找到信息披露入口如果三个测试都是正向的说明披露设计基本扎实。如果产品上线后被用户抱怨“没告诉我你是 AI”可以按这条链路排查先看用户从哪里进入产品。是不是通过分享链接、第三方入口或嵌入页面进入了某个没有首次提示的环境再看用户与 AI 的交互时长。长对话过程中初始提示可能被遗忘界面是否有常驻信号再看输出端。用户是把 AI 回答复制到了别的平台还是直接在对话框里阅读直接阅读时UI 标签是否足够明显再看日志。后端是否记录了用户看到披露的时间点和内容如果没有日志就无法判断是产品缺陷还是用户忽略。最后看场景。用户是否处于情绪化或高风险决策状态这类场景需要更强的重复提醒。5. 给开发者、产品经理和普通用户的三组行动建议5.1 开发者把身份信息做成可配置、可观测、可审计的模块如果你在开发一个 AI 应用不要把“AI 身份”看成一句用 Prompt 就能解决的话术。它更合理的形态是一个系统的“信息模块”。具体做法在会话元数据里存身份与来源信息而不是依赖模型生成。比如后端在返回结果时附带一个元数据结构{ assistant_id: assistant_v1, model_name: gpt-4-class-model, is_ai: true, disclosure_level: always, need_human_review: false, sources: [doc_id_123, doc_id_456] }前端根据这些字段决定是否显示“AI 助手”标签、是否展示参考文档、是否在输入框上方显示“AI 建议请复核”等提示。这样做的好处是披露逻辑在 UI 层可控不会因为模型输出变化而失效。同时要记日志。记录“在什么时间、哪个会话、用户是否看到过披露信息”。一旦出现误导或投诉可以回溯。不要只在系统 Prompt 里写“你是一个 AI 助手”因为模型可能在某些模式下忘记这一点也可能被用户诱导成“你是真人”的角色。5.2 产品经理用“误信任风险”来定披露强度产品经理最容易犯的错是把“是否披露”交给合规或法务或者干脆统一在所有产品上加“AI 生成”标签。更好的标准是“误信任风险”如果用户把 AI 的话当成可靠信息后果有多严重场景误信任后果披露强度建议文本润色、翻译低轻提示界面常驻标签即可情感陪伴、虚拟角色中高首次 长对话 依赖表达时重复提醒医疗、法律、财务建议高强披露 人工核实 来源说明AI Agent 自动下单、付款极高行动前二次确认 AI 身份声明 可撤销机制越往下的场景越不能只靠一句“我是 AI”。低风险场景频繁刷屏反而会烦人高风险场景只提一次远远不够。这个表格可以作为产品评审时的参考。5.3 普通用户把“它是不是AI”换成“它的依据可不可靠”如果你只是一个普通用户不需要背框架。但可以改变一个习惯与其反复追问“你是不是 AI”不如问“你的依据是什么”。具体看三点看来源。回答里有没有参考链接、文档编号、引用出处没有来源的 AI 输出最多只能作为灵感参考。看局限。产品有没有提示“可能出错”“请人工确认”如果没有任何局限说明反而要更警惕。交叉验证。重要信息比如健康建议、投资操作、合同条款去官方网站或专业渠道再核对一遍。在聊天对话里如果对方表现得特别像真人又涉及你的情绪或钱包直接问“你是真人还是 AI”。如果对方回避、否认或含糊其辞按“不可完全信任”处理不需要继续投入。6. 别让“自报身份”演变成另一种免责表演6.1 披露最怕变成免责声明随着 AI 应用越来越多“AI 生成”标签也越来越常见。但我担心一种倾向产品在角落里加一行小字“内容由 AI 生成”然后把所有验证责任交给用户。这不叫透明度叫免责声明。真正的透明度是让用户在行动前拥有足够的判断依据。比如AI 说是 A我能看到它为什么这么说能看到参考来源能知道它可能在哪一类问题上犯错也知道可以如何纠错。如果只有标签没有来源、没有解释、没有纠错通道用户只是从“不知道是 AI”变成“知道是 AI 但依然不知道该怎么办”。免责式披露还有一个副作用它可能降低产品团队改进的动力。当团队认为“我们已经标注了 AI 生成用户应该自己小心”时就不会去优化模型的错误率、不会在关键场景引入人工复核、不会给用户提供纠错途径。最终受伤的是用户而挨骂的却是“AI 不行”。另外如果披露只是一个小字用户根本没有看见出了问题产品就会说“我们标了”这会让用户对整个行业失去信任。信任一旦被消耗再好的 AI 也可能被拒绝。6.2 回到 HN 的问题把“该不该”换成“怎么做”回到 Hacker News 上的那个提问Should AIs tell you theyre AI? 在我看来“该不该”已经过了讨论的阶段。答案是必须的但必须在正确的层级、正确的时机、以用户可理解的方式出现。但在产品设计里我们需要把问题换成更实用的版本用户在做判断的关键时刻有没有足够的线索来理解 AI 的能力边界和局限如果有AI 不需要每句话都自报身份如果没有即使每句话都说“我是 AI”用户也可能不知道该信多少。我在自己的项目里发现最容易见效的做法不是写更多披露文案而是把一个高风险动作从普通输出改为“结论 来源 建议人工确认”三部分。一个结构上的改变比五句“我是 AI”更管用。所以如果你正在做 AI 产品今天可以做一个最小动作列出你的用户可能在哪些环节“误信任” AI 的输出找到后果最严重的三个点为它们分别设计一套披露或确认机制。不要只加一句“我是 AI”。下次你再看到“AI 生成”标签时也多问一句来源是什么局限在哪里我能否验证这三个问题比一个标签更有价值。