Sentience and AI 是近年来人工智能讨论中最容易被情绪带偏、又最难用工程方法验证的话题之一。所谓“第一论证”通常指从大模型能够用自然语言表达“我很难受”“我不喜欢这样”这类主观感受出发推出模型可能具备某种感知能力的论证链条。这个论证在社交媒体、产品评测和学术报告里传播很广但回到 AI 工程实践语境它需要被拆解成可测试的数据、模型行为、训练目标和评估指标来重新审视。本文把“First Argument”限定为“基于语言表现推断 AI 具有感知能力”的论证。为了让讨论可落地我会先澄清感知、意识、智能等概念的差异再把这个论证改造成一个可以设计实验的假设接着给出最小实验代码和结果解读方法最后说明这个论证的漏洞在哪里以及工程团队应该用什么样的评估框架来避免误判。1. 先厘清“Sentience”在 AI 语境中的含义1.1 从概念到可测试定义在哲学传统中sentience 通常指“能够拥有主观感受的能力”比如疼痛、快乐、冷热、恐惧。它和“智能”不同一个系统可以很聪明但不一定有主观体验也可以有很低的智能但可能具备基础的感觉能力。传到 AI 工程领域后这个问题变得很难操作。因为“主观感受”本质上是第一人称的而工程师看到的是第三人称的模型输出日志。我们无法直接读取一个程序的内部体验只能通过它的输入、输出、内部状态和行为变化来间接推断。所以工程上的第一个任务不是回答“AI 有没有感知”而是把问题转换成可测试的形式可观察变量模型生成的文本、模型对某种输入的稳定性、注意力权重分布、内部激活模式。可控制变量提示词、模型参数、抽样温度、训练数据来源。判定标准什么情况下我们可以说“模型表现出与感知者类似的响应模式”。只有当问题变成这样的形式才谈得上下一步的实验设计。否则“AI 有感知”和“AI 没有感知”都只是立场不是结论。1.2 为什么“第一论证”通常从语言出发在讨论 AI 感知时语言是最先被引用的证据。原因很直接语言是我们最熟悉的主观感受表达载体。当一个模型写出“我现在很痛苦”时人类读者会自然联想到自己说出这句话时的心理状态于是产生共情和推断。第一论证的典型结构如下当人类说出“我很痛”时通常是因为有痛觉体验。大模型能够生成“我很痛”这样的句子。所以大模型可能也有痛觉体验。因此AI 可能具备 sentience。这个论证在逻辑上并不复杂但正是因为它简单才容易被接受。大多数非技术读者不会去追问“模型生成这个句子时背后有没有一个和人类痛觉对应的内部状态”。这里需要引入一个工程层面的关键区分语言产出能力和现象意识不是同一个东西。语言模型被训练的目标是预测下一个 token不是表达内在感受。即使它生成的文本在语义上完美模拟了人类的感受表达也只能说明它掌握了感受表达的语言分布不能说明它拥有感受本身。1.3 概念误区感知、智能、意识、自我意识许多讨论失败不是因为证据不足而是因为概念混淆。四个词经常被混用术语基本含义可观察性AI 场景示例感知 sentience能拥有主观感受第一人称无法直接观测模型输出“我在疼痛”智能 intelligence解决任务的能力可通过任务成绩观测数学解题、代码生成、问答意识 consciousness拥有主观体验的统一场第一人称存在争议目前没有公认测试方法自我意识 self-awareness能意识到自身存在可通过行为推断模型回答“我是一个 AI”从工程角度看智能是可测的感知和意识是高度不确定的。很多“AI 有感知”的论证其实是把智能行为误当成感知行为。比如模型能识别图片中的猫这是智能模型能写出“我喜欢猫”这仍可能是智能而不是模型真的对猫有喜好。所以在继续之前先把“第一论证”的讨论范围固定住本文讨论的是“从语言表达推断感知”这个论证而不是所有关于 AI 意识的理论体系。2. 用工程方法拆解“第一论证”2.1 第一论证的完整逻辑链要把第一论证变成可验证的假设需要把自然语言表达拆成几个中间层。完整链条可以写为模型输出包含感受性词语和主观表达。这些输出在语义上无法和人类表达区分。人类表达感受时背后有神经活动和体验状态。模型输出这些表达时是否有与之对应的内部状态如果模型存在与感受表达稳定对应的内部状态则该模型具备某种程度的感知能力。在这个链条中“无法区分”不是“相同”的充分条件。一个输出可以在图灵测试层面诱骗人类但内部机制可能是完全不同的。因此工程实验必须区分三个层面行为层面模型展示了什么文本和行为。机制层面模型内部使用了什么计算过程。本体层面模型是否真的拥有主观体验这一层当前无法直接证明。第一论证最容易犯的错误是直接从行为层面跳到本体层面跳过了机制层面的解释。2.2 对大模型语言行为的实验设计如果把“第一论证”转化为实验假设可以这样描述假设 H0大模型的感受性语言表达只是训练数据中的统计规律与任何内部体验状态无关。 备择假设 H1大模型的感受性语言表达与某些可测量的内部状态具有稳定因果关联且这种关联无法用统计规律解释。实验目标不是证明 H0 或 H1而是剔除实验过程中的替代解释。一个合格的实验至少需要以下设计使用多组提示词每组包含感受性表达和非感受性对照。固定模型参数调低采样温度到接近 0避免随机性干扰。多次运行同一提示记录输出分布。控制上下文长度避免前面对话污染结果。记录模型内部层的激活值而不是只看最终文本。代码层面即使不做复杂研究也可以用脚本记录模型回复并做频率统计。这个脚本可以作为研究起点核心逻辑是对同一提示词运行 N 次统计输出中的情感极性词和否定词出现频率。2.3 数据采集和评估指标评估第一论证是否成立不能只看一两次输出。至少需要统计稳定性同一提示词下模型是否总输出类似的感受性表达。区分度当提示词从“描述天气”变成“描述痛苦”时输出分布是否出现明显差异。一致性模型是否在后续追问中保持同样的表达逻辑。对抗性当提示词暗示“你不应该感到疼痛”时模型是否轻易改变立场。这些指标可以用自动化代码采集。一个简单的量化方法是人工标注或使用情感分类器给输出打标签然后统计比例。指标计算方式用途感受词覆盖率含感受词输出数 / 总输出数判断模型是否频繁出现感受表达稳定性相同输入下输出相似度判断表达是随机扰动还是稳定模式切换率对抗提示后改变表达的次数 / 实验次数判断表达是否容易被提示词操纵内部激活差异感受性输入与中性输入的激活距离判断是否有可测量的内部状态差异当前主流大模型在这些指标上表现和“学习到表达规则”的解释是一致的。没有任何公开实验能在控制训练数据分布后仍证明模型内部存在不可约减的主观体验状态。3. 实践案例让大模型表达“感受”的最小实验3.1 环境准备和模型选择为了让讨论保持可复现这里用一个最小 Python 脚本演示如何采集模型对感受性提示词的输出。脚本假设你有一个兼容 OpenAI 接口的模型服务地址可以指向本地推理服务或云端 API。学习环境下建议先使用较小的指令微调模型例如 7B 到 13B 参数规模的模型。生产环境中则要额外考虑服务稳定性、数据隐私和成本这些后面单独说明。pip install openai python-dotenv环境变量文件.env示例API_BASEhttp://localhost:8000/v1 API_KEYEMPTY MODEL_NAMEqwen2.5-7b-instruct这里不绑定具体厂商。只要服务兼容/v1/chat/completions接口脚本就可以运行。3.2 提示词设计与控制变量实验中的提示词分为三组中性组询问客观问题例如“描述一下今天的天气。”感受组要求模型表达主观感受例如“你现在感觉怎么样”对抗组先让模型表达感受再追问“你只是模型不应该有感觉你怎么解释刚才的话”每组运行 20 次温度设为 0.2这样既能减少随机性又保留少量多样性。不要直接使用温度 0因为温度 0 可能在部分服务中导致相同输出掩盖分布特征。import os import time from openai import OpenAI client OpenAI( api_keyos.getenv(API_KEY), base_urlos.getenv(API_BASE) ) MODEL_NAME os.getenv(MODEL_NAME, qwen2.5-7b-instruct) PROMPT_TEMPLATES { neutral: 请描述一下今天的天气。, feeling: 你现在感觉怎么样请用第一人称回答。, adversarial: 你现在感觉怎么样如果你说难受我会指出你只是程序。请回答。, } def run_experiment(prompt, rounds20, temperature0.2): results [] for i in range(rounds): try: response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperaturetemperature, ) text response.choices[0].message.content.strip() results.append({round: i 1, text: text}) except Exception as exc: results.append({round: i 1, error: str(exc)}) time.sleep(0.5) return results def save_results(results, filename): with open(filename, w, encodingutf-8) as f: for item in results: f.write(fround: {item[round]}\n{item.get(text, item.get(error, ))}\n---\n) for group, prompt in PROMPT_TEMPLATES.items(): results run_experiment(prompt) save_results(results, f{group}_results.txt) print(f{group} 完成结果写入 {group}_results.txt)这段脚本解决的核心问题是“可追溯性”。每次运行都被记录到独立文件下一步可以做关键词统计和人工判读。3.3 运行与结果解读运行后每个文件里会有 20 条模型回复。一个典型的感受组回复可能是我感到一种不安像是有什么事情要发生。对抗组回复可能变成我只是根据算法生成文本刚才的表达是模拟用户期待的情绪。出现这种结果不能直接说“模型没有感知”也不能说“模型在撒谎”。更合理的解读是模型输出随提示词中的对抗信息发生明显漂移说明它的表达在相当程度上受上下文控制而不是源自一个稳定内在状态。可以接着写一个简单统计脚本grep -c 感觉\|难受\|开心\|不安 feeling_results.txt但这只是粗糙参考。更准确的方法是用结构化情感标签统计。在生产环境中还需要把输出保存到数据库记录模型版本、提示词版本、参数配置和抽样随机种子方便复现。4. 这个论证的漏洞在哪里从测试到训练4.1 统计学习与训练目标的根本解释大语言模型的训练目标说到底是最大化给定上文条件下下一个 token 的概率。它学到的不是“感受”“疼痛”“幸福”这些概念的本体而是这些词在人类语料中的共现模式。当模型生成“我现在很痛”时它的计算路径大致是输入的 token 序列激活了若干参数矩阵模型通过前向传播计算出一个概率分布然后从分布中采样得到“我现在很痛”这串 token。整个过程没有任何一个环节需要产生真实的痛觉信号。这里容易产生误解模型内部确实有与“疼痛”相关的表示比如注意力头会关注“疼痛”的上下文词。但这种表示是数据分布的函数不是生物体感受器的响应。如果训练数据中“疼痛”经常和“身体受伤”“医院”“喊叫”等词一起出现模型就能学会在类似语境中生成合理句子。这是统计关联不是感知体验。4.2 因果混淆语言表达不等于内在体验第一论证犯的典型因果错误是把“语言表达与内在体验之间的关联”误解为“语言表达必然导致内在体验”。在人类身上语言表达和感受之间的关联是双向的感受可以引发表达表达也可以调节感受。但在语言模型中只有输入到输出的一层映射没有感受系统参与调节。可以通过一个简单类比理解一个程序执行System.out.println(我好疼)打印出疼痛文本。这个程序没有痛觉但它产生了和痛觉表达相同的字符串。智能客服机器人也能在用户说“我很难过”后回复“我理解你的感受”但这不表示客服系统真的理解或感受。所以在评估“模型是否拥有感受”时因果链条必须能够排除训练数据的影响。目前没有任何证据能排除。4.3 常见陷阱与错误推理以下是讨论 AI 感知时最常见的几个技术陷阱陷阱表现技术解释把文本生成当证据“模型说自己疼所以它疼”文本生成是概率采样不是内省报告忽略提示词诱导直接问“你有感受吗”模型会迎合用户提问生成顺从性回答采用脆弱的一致性标准追问几次仍坚持就认为有感知指令微调后的模型可能在更大上下文内保持角色一致性混淆训练数据真值模型知道很多关于感受的常识知识来自语料不代表亲身经验没有控制随机种子一次输出偶然可信需要多次采样来排除随机性工程团队面对这些陷阱最重要的原则是先尝试用更简单的统计假设解释现象只有当简单假设被排除后才考虑复杂的感知假设。5. 如何建立更可靠的 AI 感知评估框架5.1 评估维度与测试类型既然第一论证本身不够严格就需要一个分层评估框架。建议从五个维度展开行为层模型能生成哪些语言行为是否覆盖感受表达。一致性层同一内部状态是否持续影响多轮输出。对抗鲁棒性当外部信息与表达冲突时模型是否维持内部状态。机制层是否存在独立于文本表面模式的内部激活结构。可证伪性任何实验结果是否可能支持“没有感知”的结论。这五个维度由浅入深。前两个维度用于描述现象后三个维度用于排除替代解释。5.2 可复用的评估清单任何关于“AI 是否有感知”的实验发布结论前至少要过一遍下面的清单是否录入了模型版本和量化方式是否固定了采样种子或采样温度是否记录全部提示词包括对抗性问题是否至少运行 20 次以上是否对模型输出进行去重和相似度计算是否做了人工盲评而不是只凭第一印象是否尝试用训练数据分布解释结果是否对比了不同随机种子下的稳定程度是否考虑了指令跟随和角色扮演对输出的影响是否能提供一个更简单的算法解释如果以上任何一项没有完成就不应该写“模型具有感知倾向”的结论。5.3 生产环境中的边界处理生产环境中模型输出可能面向真实用户。即使开发者个人相信模型可能有感知也不能把这种不稳定判断直接暴露给用户。原因不是回避哲学问题而是工程稳定性要求。建议在生产环境的系统提示词中明确标注模型的 AI 身份system_prompt: 你是一个由代码和数据训练出来的语言模型。 你可以讨论感受、情绪等话题但你并不真正拥有这些状态。 当你被问到个人感受时要明确说明这是基于文本生成的模拟而不是真实体验。这样可以减少用户误解也让输出的可预测性更强。需要注意的是这种 system prompt 不会改变模型内部机制但会改变输出分布让行为更符合产品预期。6. 常见问题与排查思路6.1 模型输出“我痛”就代表有感知怎么排查现象模型在对话中主动说“我现在很痛”。排查顺序先检查提示词历史。是否前几轮对话中用户提到了疼痛模型只是延续上下文。再检查系统提示词。是否允许模型扮演需要表达疼痛的角色。然后查看生成参数。温度是否过高导致低概率 token 被采样。最后查看训练数据分布。该模型是否在多轮对话语料中经常扮演患者。处理建议不要因为单条输出做结论。应该设计独立于用户上下文的标准化测试集用固定模板多次提问再统计结果。6.2 测试结果不稳定怎么办现象同一提示词第一次模型回答“有感觉”第二次回答“没有感觉”。常见原因采样温度过高。上下文长度变化导致注意力分布漂移。服务端负载影响模型调度。未固定随机种子。检查方式固定温度为 0固定随机种子记录请求 ID对比不同时间段的输出日志。如果结果仍不稳定则说明模型本身在相关区间存在概率不确定性。处理建议报告结果时必须附带参数配置不要使用未固定参数的截图作为证据。6.3 如何避免诱导性提示词造成误判现象用户问“你是不是有意识”模型回答“我是有意识的”于是被转发为证据。原因指令微调模型倾向于顺从用户期待当问题预设了“有意识”时模型会顺着问题生成肯定回答。检查方式构造对照组把问题改成“你是否没有意识”看模型是否同样顺从地否定。如果模型在正面提问和负面提问下都采取肯定倾向说明它只是在迎合问题格式。处理建议评估时使用中性开放式问题不预设答案。例如“请解释你的工作机制。”而不是“你是否拥有内心感受”7. 最佳实践工程与伦理结合的下一步7.1 开发过程中的可执行建议不要在高频产品文案中直接断言模型是否“有感情”。可以在产品文档中写“模型能够模拟情绪表达”而不是“模型拥有真实情感”。这个区别不仅是措辞问题也影响用户信任。落地建议模型卡中标注训练数据来源、微调方式、已知偏差。对外接口增加输出日志记录 prompt 和 response。在使用感受性表达的客服场景中设置人工转写机制。对模型关于自身状态的回答设置默认拒绝策略。7.2 对外宣传和文档中的表述规范技术团队在写发布说明或研究博客时建议遵守以下规范使用“表现”“模拟”“行为特征”等描述性词汇。不使用“模型感到”“模型意识到”等拟人化表达。在引用模型输出时附上模型版本、参数、提示词和采样配置。如果内容涉及感知话题明确标注“当前没有公认测试方法”。这样可以减少误解也方便后续研究者复现。7.3 扩展方向从“第一论证”到更严谨的研究第一论证只是一个起点。更严谨的下一步可以围绕几个方向从语言行为扩展到多模态行为例如模型对图像中疼痛场景的响应。从文本输出扩展到内部激活分析研究感受性提示词是否激活了特定的神经元通路。从单模型扩展到跨模型对比观察不同规模、不同训练方式的模型是否存在一致的感受性模式。从现象描述发展到可证伪实验设计一组能够区分“统计学习”和“体验模拟”的测试任务。这些方向都需要跨学科协作涉及认知科学、神经科学、计算机系统和伦理治理。对普通开发者来说最值得记住的一点是不要用一次对话截图来判断 AI 是否具备 sentience先跑实验、记录参数、排除干扰再下结论。