如果给 AI 哲学领域做一次话语权审计你会发现一个清晰但不太被讨论的现象分析哲学传统几乎垄断了 AI 哲学的讨论框架。从“AI 到底能不能思考”到“价值对齐应该对齐谁”从“可解释性”到“责任归属”主流讨论使用的概念、论证方式、评估标准大多来自分析哲学那一套。我把它称作 AI 哲学上的“分析垄断”。这个话题看起来偏学院派落到日常工程里却非常具体。大模型产品经理写的需求文档、算法工程师设计的 benchmark、安全团队的红队测试甚至客服机器人说错一句话之后的责任认定都已经被这种术语体系预先塑造。适合读这篇文章的人是 AI 产品经理、大模型应用开发者、AI Agent 设计者以及对 AI 治理议题有兴趣的从业者。读完你可以做一件很实际的事重新审视自己的 AI 讨论框架看它是不是被单一哲学传统锁死了。1. 什么是AI哲学里的“分析垄断”1.1 它首先表现为一种“默认框架”分析哲学的核心习惯是重逻辑、重概念澄清、重科学结论喜欢把大问题拆成小命题再用清晰的定义推进讨论。AI 哲学里的主流讨论几乎都是这种气质。讨论“AI 是否有意识”先定义意识是功能层面的还是体验层面的讨论“AI 是否安全”先把风险拆成滥用、误用、故障若干类讨论“AI 是否该承担责任”再把责任拆分给开发者、部署者、使用者。这套操作方式本身没有错而且非常高效。问题在于它变成了默认框架。默认的意思是你不觉得自己在做哲学选择只觉得“本来就应该这样讨论”。一旦默认框架被固定很多本该被认真对待的内容就会被自动排除。比如用户在长期使用 AI 产品时产生的依赖感属于第一人称的、难以验证的主观体验分析哲学很难找到合适的位置去安放它。于是产品评审时这类内容经常被当成“软性问题”丢掉。1.2 为什么技术公司会天然接受这套语言分析哲学强调清晰、可操作、可证伪这几乎是为了配合工程技术而生的。写代码需要精确接口做实验需要可复现结果开会需要统一术语。分析哲学的语言正好满足这些需求所以技术公司使用它是理所当然的。还有一种“供应商优势”在起作用。AI 会议、学术论文、大模型技术报告、产品说明全部使用同一套分析式表达。所有人都用“智能体”“目标函数”“对齐”“鲁棒性”这些词沟通成本非常低。当一种语言成为行业的通用语言它就会获得自我强化。大家用同一套词讨论问题很快会误以为这套词就是问题本身。于是在 AI 语境里哲学并不是指多元哲学而是指“被分析哲学整理过的哲学”。这是很多工程师对哲学失望的真正原因他们接触到的哲学不是哲学只是单一方法论的产品。1.3 选择术语就是在选择立场很多人以为术语只是语言的表层不改变实质。但 AI 哲学里的一个典型例子是“智能体”这个概念。“智能体”来自分析哲学的行动理论它默认存在一个独立、理性、拥有意图的行动者。当我们把大模型系统称为 AI Agent 时已经在不自觉地用“个体行动者”的方式理解它它应该有目标、会推理、能调用工具、能自主决策。这个视角很有用却掩盖了另一种可能如果大模型更像一个受语料和用户共同影响的关系性系统呢如果它的“意图”只是用户和提示词互动出来的产物呢不是说要放弃“智能体”这个词而是要意识到使用这个词就选择了某种哲学立场。同样的选择还发生在“模型能力”“知识边界”“幻觉”这些词里。你选定了词表就选定了讨论的边界。2. 分析垄断从哪里来从图灵测试到价值对齐2.1 图灵测试一个非常成功的改写分析哲学在 AI 领域的统治地位至少可以追溯到图灵测试。图灵测试最关键的贡献不是提出了一种验证方法而是一个哲学改写动作把“机器能否思考”这个形而上学问题改写成“机器能否让人类无法区分”。这个改写的价值在于它把不可验证的问题变成了可操作的行为测试。此后几十年很多人都在这个框架里打转衡量 AI 是否智能本质上是看它在行为上是否逼近人类。这个思路延续到了大模型时代。我们衡量模型好不好依然看对话是否自然、回答是否流畅、推理是否连贯。行为主义路径从未真正退出只是换了评价集合。图灵测试的成功让分析哲学有了一个强有力的案例看只要把问题拆成可测试的行为指标工程就能推进。这个案例太成功以至于后来者越来越倾向于把所有哲学问题都改写成行为指标问题。2.2 理性智能体和目标函数治理被简化成约束分析哲学主导 AI 讨论之后的另一个节点是把 AI 理解成理性智能体。理性智能体框架来自决策论和行动哲学核心假设是智能体有一套信念和欲望通过行动最大化自己的期望效用。这个模型在概率机器人、强化学习、现代大模型中都极其成功。因为目标函数是可计算的梯度是可求的训练是可以闭环的。但问题也随之而来。当人类需要治理这个智能体时分析式思路会倾向于把伦理规范编码成约束条件添加安全规则、设置内容过滤、加入拒绝回答机制。价值对齐之所以成为当下最热门的议题本质上是在理性行动者模型上叠加约束。这个路线确实能解决问题但注意它解决的是“约束问题”不是“价值对话”。价值是什么谁的价值优先哪些群体被忽略这些更贴近政治哲学和社会哲学的问题很难被塞进训练脚本里。2.3 从论文到产品发布分析哲学形成了完整产业链今天的 AI 哲学讨论已经不只是哲学界的讨论而是一条完整的产业链。学术论文需要定义清晰、实验严谨正好匹配分析风格。大模型发布会需要给出可量化的能力报告正好匹配 benchmark 体系。政策白皮书需要提出可落地的治理建议正好匹配风险清单和责任框架。产品文档需要说明功能边界正好匹配术语表。这条产业链把所有参与者都连接起来研究员写论文工程师做系统产品经理写需求安全团队做检测政策专家写意见稿。每个人都在这套语言里获益也因此很难看到它的边界。我不反对产业链产业链让沟通高效。但产业链太完整时会有一种惯性非分析式的讨论被自动判定为“不专业”“不可操作”“无法落地”。这不是某个人在排斥而是整套系统在过滤。3. 这种垄断为什么会影响工程落地3.1 模型好不好不再是一个可讨论的问题最直接的影响是“模型好不好”被窄化成“benchmark 分数高不高”。我在看过多个产品评审后发现一旦指标确定所有人都会盯着指标做优化。准确率、召回率、延迟、成本、上下文长度、调用次数这些全部可以量化。但“好”这个判断里面还包含很多难以量化的成分。比如一个医疗问答产品单轮回答准确率很高但用户在追问时明显感觉到机器在生硬重复。指标看不出来。比如一个 AI 教育助手能正确讲完一道题但孩子听了几次之后产生挫败感。指标也看不出来。又比如一个客服机器人能在十分钟内处理完请求但用户被它绕来绕去的回复气到投诉人工客服。指标依然看不出来。benchmark 本身就是一种哲学选择选哪些任务、怎么打分、谁来标注、忽略了哪些真实场景这些都不是中立技术决定。3.2 安全不再是一个制度问题而是一串检测动作分析垄断下“AI 安全”容易被理解成技术动作的叠加内容过滤、关键词拦截、输出审查、红队测试、日志审计。这些动作当然需要做但它们只是安全的一个侧面。我在实践中看到很多安全事件其实不是模型输出导致的而是流程设计不合理、权限边界模糊、激励方向跑偏。比如一个 Agent 可以读取文件但文件系统没有设置最小权限比如一个产品为了降低人工成本故意让机器人优先作答结果高风险场景没有及时升级人工又比如团队为了冲日活把一个本不该由 AI 自动决策的功能放到了无人监督的位置。这些问题不是词表能解决的。它们更像组织制度、权力分配、人员激励的产物需要管理学和批判性的制度分析参与。但分析垄断的语言很难描述这些内容因为检测动作可以列成清单制度设计很难快速量化。3.3 Agent 设计会偏向“任务完成”忽略长期关系分析哲学传统的个体主义视角在 AI Agent 设计中会放大一个倾向只关心任务是否完成不关心系统与用户之间长期关系的演化。一个 Agent 的典型考核指标是任务完成率、工具调用成功率、指令遵循度、每轮对话成本。这些都是“单体行动者”指标。它们会忽略很多事情用户对 Agent 的信任是否在持续增长还是渐渐下降Agent 在用户情绪低落时是否表现得过于刻板一个永远顺从用户观点的 Agent会不会在长期使用中塑造出认知茧房。做 AI 情感陪伴产品的人最先撞上这个问题。如果只按任务完成率评估情感陪伴 Agent 会变成“有求必应的夸夸机”。但真正健康的陪伴有时候需要拒绝、需要指出问题、需要有边界。这种能力很难在分析式指标里体现。3.4 责任归属变成一次归责而不是长期复盘最后一个典型影响是当自动化系统出错时分析式思路会问“谁应当承担责任”。这个问题看似正常但容易退化成一次归责演练开发者说数据没标好算法工程师说测试没覆盖产品经理说需求不明确部署方说权限配置有问题。责任在一个复杂系统里不是静态的也不是单点归属的。它往往是分布式、流动的并且在系统长期运行中不断重构。如果每次复盘都只是想找一个责任主体很快会有人选择不主动暴露问题。更合理的做法是承认责任是分散的然后系统性地改进流程、边界和反馈机制。但这很难被“责任清单”完整表述。4. 被边缘化的哲学视角能补什么4.1 现象学补“体验”现象学传统最关心第一人称体验问的是“一件事情在经验中如何显现”。放到 AI 产品里这个视角提醒我们用户使用 AI 时的体验不只是“能不能完成指令”还包括“被理解的感觉”“被打断的烦躁”“对 AI 能力边界的不安”“怀疑系统在套路自己”这些感受。我曾经参与过一个情感陪伴类原型的评审benchmark 显示两条回答路径质量几乎相同但用户访谈里明显更信任会主动承认“我不确定”的那条路径。用户说AI 承认不确定时反而更愿意继续对话。这个结论没法靠常规指标找到。现象学视角不会直接告诉你产品该怎么做但它会逼你问一个问题用户在某个具体时刻究竟体验到了什么4.2 实用主义补“长期后果”实用主义的核心态度是不纠缠于概念是否绝对正确而是看不同定义在不同场景里会产生什么实践后果。在 AI 领域这种态度非常实用。大模型到底是“概率序列生成器”还是“知识引擎”两种定义在代码层面可能不会立刻带来区别但会影响产品定位、用户预期、责任认定。如果把大模型定义成知识引擎用户会认为答错是“系统故障”责任期望很高。如果定义成概率序列生成器用户或许更容易接受错误但产品价值也会被削弱。实用主义不是帮你选边站而是提醒你请评估这个定义在用户、市场、团队、合规四个层面分别产生什么后果再决定在哪个场景里采用哪种说法。4.3 东方哲学的关系性视角补“人设与边界”很多东方哲学传统强调角色、关系、情境而不是孤立个体。这个视角可以用来重新设计 AI 产品的人设。分析框架下的 AI 人设往往是“一个能力强、知识丰富、永远顺从的助手”。关系性视角会提出另一种设计AI 不是一个孤立全能体它在不同场景中扮演不同角色有些时候它应该知道自己是辅助者有些时候它要有勇气拒绝有些时候它要主动把控制权交还给人类。在 AI 教育、AI 健康、AI 情感陪伴这类高度敏感的场景里关系性视角尤其重要。一个能识别情境边界、知道何时拒绝、何时升级人工的 AI比一个只会完成任务的能力型 Agent 更能获得长期信任。4.4 批判理论补“权力问题”批判理论会问一个很直接的问题当前这套 AI 哲学讨论框架对谁最有利对哪类用户、哪种商业模式最有利一个纯粹分析化的框架天然有利于那些擅长使用这套语言的人。技术团队、大公司、政策专家可以顺畅地参与讨论而那些利益受损的普通用户往往很难把自己的处境翻译成术语表里的语言。这不是说批判理论能直接给出答案。它更像是插入了一个提醒每次产品发布前都可以问一句这个系统改善了谁的生活可能损害谁的利益有没有群体被直接排除在测试范围之外这个问题不一定要写进 OKR但必须有人在会上反复问。5. 想摆脱垄断团队可以先做哪些调整5.1 在 PRD 里加一个“哲学假设”字段写产品需求文档时大多数团队会写目标用户、功能列表、验收指标、风险控制。我建议再加一段简短的“哲学假设”。不用写得很学院一两句话就可以。比如我们默认 AI 是用户的工具我们默认 AI 是用户的陪伴者我们默认 AI 在某些情境下拥有一定自主判断权我们默认 AI 永远不替用户做最终决定。写这个字段的意义不是为了摆弄词汇而是逼团队把默认的东西显性化。很多产品争论到后期本质是底层假设不同。有人在按工具思路设计有人在按伴侣思路设计产品自然不协调。提前写清楚会减少很多无效争论。5.2 把评估从单一指标改成“指标叙事”评估环节最容易受分析垄断影响。我现在的习惯是在查准率、召回率、成本、耗时这些数字之外同时准备两份文本。第一份叫“典型成功场景叙事”内容是在某个真实场景里用户如何在完整流程中使用产品产品在哪些节点让用户觉得有质量。第二份叫“典型失败场景叙事”内容是用户在使用过程中遇到哪些挫败、误解、不信任以及这些问题最后传递到了哪个环节。这两份文本不需要量化但它能让不可量化的内容重新回到决策桌。指标让人快速判断叙事让人理解边界。单看指标容易优化过度只看叙事容易失去可验证性。两者搭配才是更完整的产品评估。5.3 每季度做一次两小时的“反框架”讨论如果团队有兴趣可以每季度做一次小型讨论时长控制在两个小时。话题可以包括我们用来描述 AI 的术语选对了吗我们的评估遗漏了什么如果用户长期使用这个产品会出现哪些我们没有跟踪的问题我们最不愿承认的系统性缺陷是什么这些话题不需要引入大量哲学名词也不需要变成学术报告。它的目的是让团队暂时离开默认术语用普通语言重新描述正在做的事情。很多人会在这种讨论里意识到自己讲的最顺的专业术语本质上只是看待问题的一种方式不是唯一方式。5.4 给 Agent 增加边界和关系设计做 AI Agent 设计时不要只追求“完成任务”。我会在功能方案里额外加四个边界机制拒绝、退出、升级人工、关系建立。拒绝机制代表 Agent 在什么情况下有权不做某件事。退出机制代表用户如何结束对话、转移人工。升级人工代表系统识别到风险后把问题交给人类处理。关系建立代表 Agent 能理解自己与用户不是一次性的任务关系而是可以持续演化的互动关系。这四个机制不一定全部需要但设计时问一遍能避免 Agent 变成一个只知道完成指令却不懂边界的功能机器。这在 AI 情感陪伴、AI 教育、AI 健康等场景里尤其重要。6. 判断自己是否被分析垄断锁死的排查清单6.1 看你的词表打开最近一周的产品文档或者讨论记录统计你描述 AI 时最常用的词。如果集中在“能力、性能、准确率、效率、合规、意图、工具、调度、参数、上下文”大概率处于分析框架。如果出现了“体验、信任、权力、关系、意义、脆弱性、情境、长期影响、责任流动”说明你已经能调用多元框架。词表不是全部但它能反映讨论边界的宽窄。词表越窄能讨论的问题就越少。6.2 看你的失败复盘怎么写出现问题时你倾向于写哪种复盘第一种模型输出不符合预期需要增加数据、调整 prompt、调低温度参数、增加更多标注。第二种使用场景判断错了用户信任破裂了系统边界不清晰这个功能本就不该上线。第二种写法往往能触及框架问题。它不是在说“工具没有执行好”而是在承认“我们理解问题的方式出了问题”。如果你发现自己的复盘长期停留在第一种写法说明你很可能被工具思维锁住了。6.3 看“可解释性”是不是默认前提分析框架下可解释性几乎变成一种道德要求。模型必须能解释自己为什么给出这个答案否则就是“黑箱”“不负责”。但真实产品里过度解释同样有害。一个医疗建议如果配上八百字推理链用户根本看不完一个风控决策如果给出几十项特征权重普通用户只会更困惑。可解释性应当是一种产品设计决策而不是默认前提。你要问的是在这个场景里用户需要多少解释才能建立合理信任而不是机械地追求所有输出都可解释。6.4 看是否问过“谁受益、谁受损”这是一个非常残酷但必要的检查。如果你的团队从未问过这套 AI 系统在改善谁的生活可能损害谁的利益有没有群体被直接排除在测试之外那么你的 AI 哲学讨论很可能是单薄的。你可以把所有 benchmark 都刷到很高把论文写得非常严密把红队测试做到行业前列但它依然缺少一层最重要的讨论。这层讨论不是技术问题而是价值问题。意识到它才算走出了分析垄断给思维画好的圈。说到底分析垄断不是一个需要打倒的敌人而是一个需要被看见的结构。真正的目标是让 AI 产品设计者能随时调取多套框架而不是学会一套话术之后反复使用。工程上我们常说先跑通单任务再考虑批量和并发哲学框架也是一样先意识到自己正在用哪套语言再去谈谁比谁更正确。