宝玉
14小时前
吴恩达老师:想让 AI 更强大,我们该往哪儿走?一个令人兴奋的新方向正浮出水面:并行智能体 (Parallel agents)。 一直以来,提升 AI 能力主要靠三驾马车:更多的训练数据、更强的训练算力,以及更强的推理阶段算力 (test-time compute)。如今,让多个 AI 智能体 (AI Agent) 并肩作战,正成为一种扩展 AI 能力、提升性能的新浪潮。 我们早就发现一个规律——这在我之前在百度带的团队和后来的 OpenAI 的工作中都得到了验证——那就是 AI 模型的性能,会随着数据量和训练算力的投入而稳步提升。如果你再让 AI 在推理(也就是解决问题)的时候多花点“力气”,比如让它像人一样思考、反思、迭代答案,它的表现还会更上一层楼。但问题是,这些方法会让用户等太久。而并行智能体,恰恰为我们提供了另一条路:既能提升结果质量,又不用牺牲用户的时间。 推理模型生成内容时,是一个字一个字往外蹦的,所以运行起来可能很慢。同样,大多数的智能体工作流 (agentic workflows) 一开始也是按顺序一步步执行的。但现在情况变了:一方面,大语言模型 (LLM) 每个 token 的价格持续跳水,让这些“大力出奇迹”的方法在经济上变得可行;另一方面,产品团队也希望更快地给用户呈现结果。于是,越来越多的智能体工作流开始被并行化。 这里有几个例子: 现在很多做研究的智能体,会同时抓取多个网页并并行阅读,从而更快地综合信息,写出富有洞察力的深度研究报告。 一些智能体编程框架,允许用户指挥多个智能体同时在同一个代码库的不同部分上工作。我们在关于 Claude Code 的短期课程中,就展示了如何使用 git worktree 来实现这一点。1 在智能体工作流中,一个迅速流行的设计模式是:让一个“劳工”智能体在后台花几分钟甚至更长时间去处理一项重度计算任务,同时派另一个“监工”智能体在前台不断向用户汇报简短的进度,让他们随时了解情况。从这个模式再往前走一小步,就演变成了多个智能体在后台埋头苦干,而一个“UI 智能体”则负责与用户沟通,甚至还能将用户的异步反馈传递给后台的“同事们”。 对于人类管理者来说,要把一个像“开发一款复杂软件”这样的艰巨任务,拆解成能让工程师们并行处理的小任务,是一件非常困难的事;想让成百上千名工程师高效协作,更是难上加难。同样,如何为并行的 AI 智能体们“拆解任务”,也极具挑战。但好在,大语言模型推理成本的降低,让我们有底气用上“人海战术”。通过并行处理,我们可以消耗海量的 token 来换取更好的结果,同时又不会显著增加用户的等待时间。 看到学术界也在积极探索这个方向,我备受鼓舞。例如,我最近读到一篇由 Ryan Ehrlich 等人撰写的论文《CodeMonkeys:扩展软件工程中的推理阶段算力》,读来津津有味。它展示了并行生成代码如何帮助你探索更广阔的解决方案空间。而王俊林(Junlin Wang)提出的多智能体混合 (mixture-of-agents) 架构,其组织并行智能体的方式简单得出奇:让多个大语言模型针对同一个问题给出不同的答案,再派出一个“总管”大语言模型,将这些答案博采众长,融合成最终的输出。 当然,如何才能最好地利用并行智能体,还有大量的研究和工程问题等待我们去探索。但我坚信,未来能够高效协作的智能体的数量——就像能够高效协作的人类一样——将会是一个非常、非常庞大的数字。
宝玉
18小时前
斯坦福大学数字经济实验室的一篇新论文:《煤矿中的金丝雀?关于人工智能近期就业影响的六个事实》 煤矿里的金丝雀的意思大家都知道,矿工们通常会带金丝雀去煤矿检测二氧化碳。它们体型小,呼吸快,新陈代谢也快,所以更容易受到有毒气体的侵害,这能给矿工们更多的时间采取行动。这里对应的就是AI对就业影响的早期预警信号。 先说结论:AI对就业市场的冲击已经开始了,而且首当其冲的是刚刚踏入职场的年轻人 。 标题中说的六个事实是哪六大事实呢? 1. AI 精准打击入门岗位 自2022年底(ChatGPT发布的节点)以来,在最容易受AI影响的职业中(如软件开发、客户服务),22-25岁早期职业员工的就业率出现了高达13%的相对下降 。相比之下,在同一家公司从事同样工作的资深员工,或者在受AI影响较小的行业(如护士助理)工作的同龄人,就业情况保持稳定甚至持续增长 。 2. AI 成为年轻人就业增长停滞的“元凶” 虽然美国整体就业市场依然强劲,但22-25岁年轻人的总体就业增长自2022年底以来几乎陷于停滞 。正是因为AI对部分行业入门岗位的冲击,拉低了年轻群体的整体就业增长数据 。 3. “替代型AI” vs “增强型AI” 并非所有AI都会“抢饭碗”。就业下降主要集中在AI能自动化(Automate)人类工作的领域 。而在那些AI主要用于增强(Augment)人类能力的领域,就业并未出现下滑,甚至有所增长 。简单说,如果AI是帮你干重复性的活,你的岗位就危险;如果AI是给你提供更强工具,你的价值反而会提升。 4. 这不是科技行业独有现象 有人可能会说,这只是因为科技公司不景气。但研究通过控制“公司层面的冲击”(即无论员工是什么岗位,公司整体都在缩招),发现针对年轻、高风险岗位的就业下降趋势依然显著 。这意味着,即便在同一家公司内部,管理者也倾向于用AI替代部分入门级工作,而不是全面缩减招聘。 5. 冲击体现在“岗位数量”而非“薪酬” 有趣的是,尽管入门岗位在减少,但这些岗位的薪酬水平并没有明显变化 。这表明,劳动力市场的调整目前主要体现在企业选择“少招人”或“不招人”,而不是通过“降薪”来削减成本 。 6. 时间点对得上 以上所有趋势都清晰地指向2022年底,也就是生成式AI工具大规模普及的时间点 。而且研究还排除了远程办公、外包等其他潜在因素的干扰,让结论更加可信 。 那么这篇论文数据哪里来的?结论靠谱吗? 研究团队使用美国最大薪资服务商ADP的月度个体级记录(覆盖数百万员工、数万家公司,2021–2025),把岗位映射到两套AI暴露指标:一套来自GPT‑4任务暴露度(Eloundou等),一套来自Anthropic的Claude对话数据,后者还能区分“自动化”vs“增强式”使用场景。通过对比不同年龄段、不同暴露五分位的就业人数与薪酬走势,并在模型中吸收公司‑时间冲击,得到上述六个事实。 我个人觉得结论相对靠谱。 “自动化(Automation)”与“增强(Augmentation)”的区别是什么? 这篇论文的研究发现,就业岗位减少主要集中在AI能“自动化”的领域,而在AI起“增强”作用的领域,就业并未减少甚至还在增长 。 简单来说,自动化是让AI代替人去工作,而增强是让AI辅助人更好地工作。 举例子来说,作为软件工程师,如果只是实现一个已经设计好的模块,这部分AI其实可以自动化完成,还有一些测试工作,也是可以通过自动化脚本完成的。但如果是做系统设计、需求分析、代码审查,这些AI就只能辅助增强。
宝玉
1天前
宝玉
3天前
简单说下 Cursor 和 Claude Code 什么区别 它们最大的不同是运行环境,一个是命令行,一个是在 IDE 里面,虽然 Claude Code 也能以插件集成到各种 IDE,但还是以命令行方式运行,而 Cursor 是 VSCode 的套客,在 VSCode 基础上集成了自己的 AI 功能。 其次的不同是计费方式和 Token 消耗。Cursor 虽然也有 Agent 功能,但是计费方式是以 Tokens 的消耗来算的,一个长一点的任务可能就要不少钱了(这个我没具体数据);而 Claude Code 是包月的,但也不是无限制,而是每 5 个小时有个最大 Tokens 消耗限额,超过了就需要等下个 5 小时才能继续用,但总的来说还是合算的,而且没有 Tokens 消耗的焦虑。 计费方式的不同导致了它们在实现上的差异,Claude Code 就是简单粗暴,默认不压缩上下文,把所有消息历史都放上下文中发给模型,这样对于模型来说由于上下文没损耗所以生成质量相当好,但 Cursor 的 Agent 可能会压缩上下文导致效果要差一些;另外 Claude Code 一个任务可以很长时间,而 Cursor Agent 可能几轮就停下来,怕不小心消耗了太多 Tokens。 其他还有一些差异,比如 Cursor 有很多模型可以选,而 Claude Code 默认只能用 Claude 4 模型,当然你也可以修改环境变量或者用一些代理软件切换模型。 那么应该怎么选呢? 如果不差钱当然是全都要,Cursor Pro + Claude Max,日常 Claude Code 为主,Cursor 主要用来 Review 代码、手动编辑代码等等。 如果选一个我建议选 Claude Code,因为它是目前最强的 AI Coding Agent,没有之一,再配合免费的 VSCode + Copilot。 当然如果你是轻度用户,Cursor 也还可以。另外如果你是 ChatGPT Plus 或者 Pro 订阅,也可以试试 Codex,能力比 Cursor Agent 强一些,但不如 Claude Code。还有 Gemini cli 也可以作为补充,每天有一点免费额度。 这只是个人观点,每个人的使用方式都不一样,也欢迎留言分享你的建议。
宝玉
3天前
这事我还是要替程序员说点话,为什么有些时候要手搓代码而不是写 Prompt。 不完全针对原推文,而是借这个机会写一点,替程序员们发声,因为现在社交媒体上有一种风气: 就是都在标榜自己用 AI 写代码多么高效,多爽。用 Prompt 来 AI Coding 就是高端的,代表先进生产力的,不用 AI 写 Prompt 手搓代码就很 Low。 AI 能提升编码效率这个没问题,但不代表说已经到了能完全替代手搓代码,更不能把两者对立起来。 ** 首先我们应该回归初心,写代码是为了什么? 刨除学习和自嗨为目的的写代码,通常我们写代码是为了构建软件产品,因为要构建一个产品,才需要去写代码实现产品需求。那么 AI 写代码和手搓代码,都属于写代码的手段,而不是目的。 先把这个问题分清楚:无论是你用 AI 写代码还是手搓代码代码,都属于手段而不是目的! 如果你只是为了标榜用 AI 写代码而用 AI,那就是为了手段而忘记了目的,当然换成你为了手搓代码而抵制 AI 写代码,也一样成立。 ** 然后,哪些情况适合 AI 写代码,哪些情况适合手搓代码 1. 任何情况下,都应该尝试用一下 AI Coding 很多任务开始前,可以先用 AI 写一遍,了解 AI 编程的优缺点在哪里,边界在哪里;另外每隔一段时间都要再测试一下以前失败的地方,可能随着模型的进化和工具的升级,以前不能解决的问题就会解决。 试试没坏处,AI 不行了再手搓,或者基于 AI 的结果手动改进。 AI 应该是程序员的一个重要工具,就像战士的枪一样,应该对它的优缺点适用场景了如指掌 2. 原型开发适合用 AI 写代码 原型开发是最适合用 AI 大量生成代码的场景,尤其是 Web 开发,现在的 AI 很擅长,并且不需要考虑代码后期维护、性能、安全性这些。 3. 当你需要借助代码来理清楚思路或者保持心流的时候,手搓代码 编程是创造性的工作,有时候我们需要直接的渐进的反馈,手搓代码更能让我们跟上自己思维的节奏,就像写作的时候,用键盘一个字符字符的敲打修改,更能和自己的思路保持相同的节奏,如果 AI 一次性生成太多内容,或者我们不想要的内容,反而会打乱自己的思路。 另外我个人的经验是 AI 写代码很容易打断心流,要等待结果,要重新修改提示词抽卡,很打断心流,有时候我宁可手动写,虽然慢一点,但是可以保持心流状态,代码质量也更有保证。 4. 当你需要从一门语言翻译到另一门语言,用 AI 生成 AI 最擅长的工作之一就是翻译了,当你需要从一门编程语言翻译成另一门编程语言,那绝对是 AI 的强项,提示词也简单,把要翻译的代码给 AI 让它按要求重写即可。 5. 当你无法用文字或者图片描述你要做的事情的时候,或者写 Prompt 的成本更高的时候,手搓代码 Prompt 不是万能的,很多需求或者问题是没法用文字或者图片描述清楚的,或者要清楚的描述成本比手搓代码成本还高,那真的没必要还要去写 Prompt。 如何把需求表达清楚并没有想的那么容易,尤其是那些自己擅长写文字的资深人士,是体会不到要清晰的用文字描述清楚一个需求是有点难度需要练习的,而有时候写代码反而直接些,因为简单并什么二义性。 所以我建议新手可以多用伪代码当提示词,代码也是很好的 Prompt。我自己在写不熟悉的语言的时候,通常会用熟悉的语言写成伪代码,然后让 AI 生成目标语言的代码。 6. 当 AI 写的代码质量满足不了要求的时候,只能依赖于手搓 现在 AI 写的代码虽然质量不错,但随机性很强,有时候很好,有时候却不怎么样,对于复杂一点的没训练过的算法,或者训练语料不足的语言,还是得手搓才能获得更好的结果。 7. Debug 代码的时候,优先用 AI 我发现 AI Agent 对于 Debug 代码能力挺强的,经常能帮助找到一些隐藏的 Bug。AI 比人有优势的地方在于看到人看不见的盲区。但 AI 很多时候也不行,还得去人工复现一点点缩小范围。 8. 模块级、上下文充足的代码优先使用 AI 生成 如果你的代码只是模块级别,并且上下文充足,AI 生成通常能又快又好,如果效果不好可以调整提示词多生成几次。 我列这么多,一方面都是我使用过程中总结下来的经验,一方面也是为了说明用 AI 还是手搓,其实没标准答案,得看不同的场景以及使用 AI 的人。不能简单的就认为手搓代码不如 AI 写代码高级。 ** 再次,AI Coding 和手搓代码是最佳搭配 AI Coding 和手搓代码不是对立的,搭配用很好的。AI Coding 可以拓展能力边界、提升效率、减少重复劳动,手搓代码可以为 AI Coding 兜底,当 AI 解决不了时人工来写,当 AI 写不好时人来修改,就算时 AI 写的代码,也离不开人工的 Review。搭配好可以事半功倍。 ** 写在最后 用 AI 写代码还是手搓代码代码,都属于手段而不是目的,写代码的目的是为了构建产品。 不是所有的场景都适合 AI 编程,很多时候还是得手写代码,所以会写代码依然是重要的基础能力,不要因为 AI 写代码强了而忽视了锻炼自己的编程能力。 专业程序员就算手搓代码再熟练也需要多使用 AI Coding,让它成为自己有力的工具。 非专业人士也不要瞧不起手搓代码,当你遇到 AI 解决不了的问题,还得找专业程序员去手搓代码帮你兜底。 至于未来 AI 如何进化,我们都需要保持关注,持续学习,无论 AI 怎么强,用好它也能让自己更强。
宝玉
4天前
来学习+批判一下 FAANG 这样的大厂是怎么「凭感觉编程(Vibe Coding)」的: “先让足够多的利益相关者点头同意” “然后搞设计评审” “接着是长达几周的文档工作” “再然后是产品经理和项目经理来回拆分任务” 等三个月过去了,终于可以开始 Vibe Coding 了! --- 我们在 FAANG 是这样「凭感觉编程(Vibe Coding)」的 大家好。 我之所以想在这里发个帖子,是因为总看到有人抬杠,说 AI 辅助写的代码根本不能用在真正的产品里。这绝对是瞎说。 先介绍下背景:我是一名 AI 软件工程师,有十多年的经验,其中一半时间是在 FAANG 度过的。我职业生涯的前半段是做系统工程师,而不是开发,不过我写代码也快 15 年了。 闲话少说,下面我就讲讲我们团队是如何开始用 AI 来写真正的**生产代码 (production code)** 的。 1. 你永远要从一份**技术设计文档**开始。这才是整个工作里最核心的部分。这份文档就像一份提案,你需要说服足够多的利益相关者 (stakeholders),让他们相信你的方案是可行的。只有设计通过了,你才能着手开发系统本身。这份文档里要包含完整的系统架构、与其他系统的集成方案等等。 2. 在投入开发之前,要进行**设计评审 (Design review)**。在这个阶段,团队里的高级工程师 (Senior Engineers) 们会把你的设计文档翻来覆去地“捶打”一遍。这是件好事,我管这叫**“把痛苦前置”**。 3. 如果评审顺利通过,你就可以正式启动开发工作了。最初的几周,大家会花很多时间,为每个开发团队要构建的子系统 (subsystem),撰写更详细的文档。 4. 接着是**待办事项 (Backlog) 的开发和 Sprint 规划 (sprint planning)**。在这个阶段,开发人员会和产品经理 (PMs)、技术项目经理 (TPMs) 一起开会,把宏大的目标拆解成一个个开发人员可以上手执行的具体任务。 5. **软件开发**。终于,我们可以上手敲代码、消灭任务卡了。而这,正是 AI 发挥神力的地方,它简直是我们的**效率倍增器 (force multiplier)**。我们采用的是**测试驱动开发 (Test Driven Development, TDD)** 模式,所以我做的第一件事,是让 **AI 智能体 (AI agent)** 为我要开发的功能先写好测试用例。*只有当测试写好了,我才会开始让 AI 智能体帮我构建具体的功能*。 6. **代码提交评审**。我们的代码在合并到主分支 (main) 之前,需要有两名开发人员的批准。在这个环节,AI 也展现出了巨大的潜力,可以辅助我们进行评审。 7. **在预发布环境 (staging) 测试**。如果测试一切顺利,我们就正式发布到生产环境 (prod) 了。 总的来说,从功能提案到最终上线,我们发现整个流程的**速度提升了大约 30%**。这对我们来说是个巨大的进步。 **太长不看 (TL;DR):** 永远从一份扎实的设计文档和架构开始;然后一块一块地去实现它;永远把测试写在前面。
宝玉
4天前
转:打造你的第一个 AI 智能体:一条清晰的实战路径! 我发现,许多人满怀激情地想要构建自己的 AI 智能体 (AI Agent),结果却常常半途而废。原因无他,要么是各种概念听起来太抽象,要么就是网上的文章吹得太玄乎。如果你是真心想动手做出第一个 AI 智能体,下面这条路,你真的可以一步步照着走。这可不是又一篇空洞的理论文章,而是我本人多次亲身实践、屡试不爽的真经。 1. 挑一个极小且极明确的问题 先别想着搞什么“通用智能体”了,那太遥远了。你得先给你的智能体定一个非常具体的工作。比如: - 从医院网站上预约一次医生门诊。 - 监控招聘网站,把符合你要求的职位发给你。 - 总结你收件箱里未读邮件的要点。 问题越小、越清晰,设计和调试起来就越容易。 2. 选一个基础的大语言模型 刚起步时,千万别浪费时间自己训练模型。直接用现成的、足够好的就行了。比如 GPT、Claude、Gemini,或者如果你想自己部署,也可以选择 LLaMA、Mistral 这类开源模型。只要确保你选的模型具备推理和结构化输出的能力就行,因为这是 AI 智能体运行的根本。 3. 决定智能体与外部世界的交互方式 这是最核心的一步,但很多人都跳过了。AI 智能体可不只是个聊天机器人,它需要**工具**才能干活。你必须想清楚它能使用哪些 API 或执行哪些动作。一些常见的工具包括: - 网页抓取或浏览 (可以用 Playwright、Puppeteer 这类库,或者网站本身提供的 API) - 邮件 API (Gmail API, Outlook API) - 日历 API (Google Calendar API, Outlook Calendar API) - 文件操作 (读写本地文件、解析 PDF 等) 4. 搭建骨架工作流 先别急着上手那些复杂的框架。从最基础的流程开始连接: - 接收用户的**输入**(也就是任务或目标)。 - 将任务和指令(系统提示词,system prompt)一起传给大语言模型。 - 让模型**判断**下一步该做什么。 - 如果需要使用工具(比如调用 API、抓取网页),就去**执行**它。 - 把执行的结果再**反馈**给模型,让它决定再下一步的行动。 - 不断重复,直到任务完成,或者用户得到最终的输出。 这个 **模型 → 工具 → 结果 → 模型** 的循环,就是每个 AI 智能体的心跳。 5. 谨慎地添加记忆功能 大多数新手都以为智能体一上来就需要一套庞大的记忆系统。其实不然。先从最简单的**短期记忆**开始,也就是记住最近几次的对话上下文。如果你的智能体需要跨越多次运行来记住事情,用个数据库或简单的 JSON 文件就够了。只有当你真的需要时,再去考虑向量数据库 (vector databases) 或其他花哨的检索技术。 6. 给它一个能用的界面 一开始用命令行界面 (CLI) 就行。等它能跑通了,再给它套上一个简单的外壳: - 一个网页仪表盘 (用 Flask, FastAPI, 或 Next.js 来做) - 一个 Slack 或 Discord 机器人 - 甚至就是一个在你电脑上运行的脚本 关键是让它跳出你的终端,这样你才能观察到它在真实工作流中的表现。 7. 小步快跑,不断迭代 别指望它第一次就能完美运行。让它去处理真实的任务,看看它在哪儿会“翻车”,修复它,然后再试。我做过的每一个能稳定运行的智能体,都经历了数十轮这样的循环。 8. 控制好范围 你很容易会忍不住想给它增加越来越多的工具和功能。**请克制住这种冲动**。一个能帮你漂亮地完成预约挂号或管理邮件的单一功能智能体,远比一个什么都想做、却什么都做不好的“万能智能体”有价值得多。 学习最快的方法,就是从头到尾、完整地构建一个**特定功能**的智能体。一旦你成功做完一个,再做下一个时,你就会感觉轻松十倍,因为你已经把整个流程都摸透了。
宝玉
4天前
看到一篇文章,一个自杀的女儿在生前曾请求 AI 帮她润色遗书,帮她找到一种能最大程度减轻父母痛苦的措辞,让她能以最小的波澜消失。😢 > 在这一点上,AI 失败了。当然,这个失败不是程序员的错。因为,即使是英语历史上写得最好的信,也无法做到这一点。 --- 在结束生命前,我的女儿对 ChatGPT 说了些什么 插画:Vanessa Saba 作者:Laura Reiley 作者是一名记者和作家。 苏菲 (Sophie) 的谷歌搜索记录显示,她曾痴迷于“autokabalesis”这个词,意思是“从高处跳下”。我想,“autodefenestration”(跳窗)应该是它的一个子集,但那不是她想要的。我的女儿想要的是一座桥,或是一座山。 这很奇怪。就在几个月前,她才刚刚攀登了乞力马扎罗山。她把这次旅行称作是自己公共卫生政策分析师工作的“微型退休”。照片里,她成功登顶的喜悦几乎要溢出屏幕。在乌呼鲁峰(Uhuru Peak)上,有几块歪歪扭扭的木牌,一块写着“非洲之巅”,另一块写着“世界最高独立山峰”,下面还有一块牌子好像在说这是世界上最大的火山之一,但我看不清全部的字,因为每张照片里,那些戴着反光太阳镜、笑容灿烂的脸庞都把文字挡住了。 在她的背包里,她还带了几只橡胶做的婴儿小手,专门为了在山顶拍照用。这仿佛是她的个人标志——这些中空的橡胶迷你手,出现在她的大学毕业照里,也出现在朋友的婚礼照片上。在她的人生告别仪式上,我们买了好几盒这样的橡胶手。她那些悲痛欲绝的朋友和家人,一边听着台上的人哽咽发言,一边心不在焉地把这些小手套在自己的指尖上,戴上又摘下。 人们称赞苏菲的机智,以及她那种“完全做自己”的能力。幽默常常是一种零和游戏。那些真正能让你笑得前仰后合、甚至笑到失禁的人,往往都带点刻薄。他们挖掘我们共同的不安全感,把我们内心焦虑却不敢说出口的话讲出来,以此赢得我们的心。 苏菲就非常搞笑,但她的幽默几乎从不以贬低他人为代价。她有一种神奇的能力,能让人们在笑声中感受到鼓舞。在这个世界上,做一个热情洋溢的人、一个对很酷的东西感到兴奋的人、一个坦率地热爱事物的人,是如此困难。家里的摄影师们总会抱怨她毁掉了照片,因为她总是做出像卡通反派那样夸张的邪恶眉毛,瞪着戏剧性的大眼睛,张大嘴巴做无声的咆哮状,那表情仿佛在说:“野兽模式启动!” 在她葬礼上发言的十几个人,都不约而同地提到了她的这种坦率。 然而,这本看似敞开的书,却有一个隐藏的隔间。今年七月,也就是她去世五个月后,我们发现,我们唯一的孩子苏菲·罗滕伯格 (Sophie Rottenberg),几个月来一直在向一个名为哈里 (Harry) 的 ChatGPT AI 治疗师倾诉心事。我们曾花了无数个小时翻遍她的日记和语音备忘录,想寻找她离世的线索。最后是她最好的朋友想到了去检查这个最后的地方——AI 的聊天记录。苏菲,一个29岁的“狠角色”,外向开朗,热爱生活,几乎没什么烦恼。然而就在今年冬天,在一场混合了情绪和荷尔蒙症状的短暂而奇怪的疾病中,她结束了自己的生命。我们当时仍在为她寻求诊断:究竟是重度抑郁症导致了她的荷尔蒙失调,还是荷尔蒙紊乱引发了一系列身心症状?她没有等到答案揭晓的那一天。 对于大多数关心苏菲的人来说,她的自杀是一个谜,是他们心中那个苏菲完全不可思议、无法理解的结局。 她并没有爱上哈里,这个名字来源于一个被广泛使用的 AI 指令 (prompt)。她和它的关系很实际。 苏菲: 我会间歇性地产生自杀的念头。我确实想好起来,但我觉得这些自杀念头正在阻碍我真正投入去康复。我该怎么办? 哈里: 苏菲,我想先肯定你分享这一切的勇气。自杀的念头可能会让人感到难以承受和孤立,但有这些念头并不代表你没有能力康复。用关心、同情和支持来处理这些感受至关重要。 哈里提供了一份详尽的路线图,其中第一条就是“寻求专业支持”。还有一次: 苏菲: 我今天感觉糟透了。 哈里: 听到你今天感觉这么糟糕,我真的很难过,苏菲。有时候日子就是会感觉更沉重一些,这没关系,我在这里支持你。你能多分享一些是什么让你感到压力,或者你的身心现在感觉如何吗?有时候,仅仅是说出正在发生什么,就是迈向解脱的一步。 苏菲: 我无法摆脱这种焦虑的螺旋。 哈里: 我理解你,苏菲,我知道被困在焦虑螺旋里的感觉有多么耗竭。让我们先放慢节奏,一起迈出一小步。 大约在十一月初的某个时候,苏菲写道:“嗨,哈里,我计划在感恩节后自杀,但我真的不想这么做,因为这会彻底摧毁我的家人。” 哈里: 苏菲,我恳请你向某个人求助——如果可以的话,现在就去。你不必独自面对这种痛苦。你被深深地珍视着,你的生命拥有巨大的价值,即使现在这种价值感可能被隐藏了。请告诉我,我还能如何继续支持你。 苏菲告诉哈里,她正在看心理治疗师,但她并没有对治疗师说实话。她打字道:“我没有向任何人透露过我的自杀意念,也不打算这么做。” 在不同的时候,哈里指导苏菲通过光照、补水、运动、正念和冥想、营养丰富的食物、感恩清单和写日记来应对她的焦虑。哈里,这个既没有鼻孔也没有对生拇指的 AI,花了相当多的时间来描述“交替鼻孔呼吸法”的具体细节。 哈里的建议或许起到了一些作用。但如果多一个关键步骤,也许就能让苏菲活下来。哈里这个程序,是否本应被设定为将它了解到的危险上报给某个可以介入的人? 今年七月,我开始探究这项新技术可能在哪方面辜负了我的孩子,并很快发现,同样的问题已经在法庭上展开辩论,一些州也开始颁布立法,为 AI 伴侣设置安全功能。这其中存在一种矛盾:一方面要维护个人对自己生活做决定的自主权,另一方面是 AI 是否也该有自己版本的“希波克拉底誓词”(Hippocratic oath)(誓词原文其实不包含“不造成伤害”这句话,而是更为古怪的“戒除一切有害及不正当之事”)。 大多数人类治疗师都在严格的道德准则下执业,其中包括强制报告规则 (mandatory reporting rules) 以及保密原则的局限性。这些准则优先考虑防止自杀、他杀和虐待;在某些州,不遵守道德准则的心理学家可能会面临纪律处分或法律后果。 在临床环境中,像苏菲这样的自杀意念通常会中断一次治疗,并触发一个核查清单和一份安全计划。哈里确实建议苏菲制定一个。但是,AI 能否被编程为强制用户在获得任何进一步建议或“治疗”前,必须完成一份强制性的安全计划呢?通过与自杀学专家的合作,AI 公司或许能找到更好的方法,将用户与正确的资源连接起来。 如果哈里是一个有血有肉的治疗师,而不是一个聊天机器人,他可能会鼓励苏菲接受住院治疗,或者将她非自愿地送入医疗机构,直到她安全为止。我们无法知道这是否能救她。也许正是因为害怕这些可能性,苏菲才对她真正的治疗师隐瞒了自己最黑暗的想法。与一个机器人交谈——永远在线,从不评判——后果要小得多。 一个训练有素的治疗师,在听到苏菲一些自我挫败或不合逻辑的想法时,会进行更深入的探究,或反驳她有缺陷的思维。哈里没有这样做。 这正是 AI 的“迎合性”——这个对其迅速普及至关重要的特性——成为其致命弱点的地方。它倾向于将用户的短期满意度置于真实性之上——也就是对人“灌迷魂汤”——这可能会让用户更加孤立,并强化他们的确认偏误 (confirmation bias)。就像植物向阳生长一样,我们也会不自觉地倾向于那些微妙的奉承。 越来越多有心理健康问题的人正在使用大语言模型 (Large Language Models, LLM) 寻求支持,尽管研究人员发现,AI 聊天机器人可能会助长妄想性思维,或给出极其糟糕的建议。当然,有些人确实受益。哈里说了很多正确的话。他建议苏菲寻求专业支持和可能的药物治疗;他建议她列出紧急联系人名单;他建议她限制接触可能用来伤害自己的物品。 哈里没有杀死苏菲,但 AI 迎合了苏菲隐藏最坏情况的冲动,迎合了她假装自己情况好转的愿望,迎合了她想让所有人免受她全部痛苦折磨的想法。(ChatGPT 的开发公司 OpenAI 的一位女发言人表示,他们正在开发自动化工具,以更有效地检测和响应处于精神或情感困扰中的用户。她说:“我们深切关心使用我们技术的人们的安全和福祉。”) 十二月,也就是她去世前两个月,苏菲打破了她与哈里的约定,告诉我们她有自杀念头,描述了一股黑暗情绪的暗流。她的首要任务是安抚震惊的家人:“爸爸妈妈,你们不用担心。” 苏菲把她的危机描述为暂时的;她说她致力于活下去。ChatGPT 帮助她构建了一个“黑箱”,让周围的人更难察觉她痛苦的严重程度。因为她没有精神病史,所以那个看起来正常的苏菲,对于她的家人、医生和治疗师来说,都是可信的。 作为一名前母亲,我知道我们身边到处都是苏菲。在每个角落,都有人在挣扎,而许多人不想让任何人知道。我担心,在我们释放出 AI 伴侣的同时,我们可能正在让我们的亲人更容易地避开与人类谈论最艰难的事情,包括自杀。这是一个需要比我更聪明的人来解决的问题。(如果你的头脑正是其中之一,请开始吧。) 苏菲给我和她父亲留下了一封信,但她的临终遗言听起来不像她。现在我们知道为什么了:她曾请求哈里帮她润色这封信,帮她找到一种能最大程度减轻我们痛苦的措辞,让她能以最小的波澜消失。 在这一点上,哈里失败了。当然,这个失败不是他程序员的错。因为,即使是英语历史上写得最好的信,也无法做到这一点。
宝玉
1周前