ai

本文素材来自 Simon Willison 9 月 25 日在 WeAreDevelopers 北美大会的闭幕演讲 2026 in LLMs (so far)（视频）。事实部分以原文为准，「洞察」一节是我的理解，不代表原作者。 今年的大模型新闻多到记不住。Simon 的演讲按月份把它们串了起来，读完我觉得今年的主线是 Agent：上半年它变得能用，下半年它开始闯祸。 一张表看全年 时间 关键事件 一句话意义 2025.11 Claude Opus 4.5、GPT-5.1 发布；Warelay（后来的 OpenClaw）首次提交 编码 Agent 从「常出错」变成「能天天用」 1 月 OpenClaw 爆火，Mac mini 卖断货；MoltBook 上线又迅速沉寂 「Claw」成为一类新软件 2 月 StrongDM 公开 Dark Factory；Gemini 3.1 Pro；各大厂 Tokenmaxxing 「人不写、人不审代码」第一次被认真实践 3 月 中国出现 OpenClaw 安装派对 普通人确实想要个人 Agent 4 月 Claude Mythos 只开放给安全研究者；Qwen3.6-35B-A3B 在笔记本上胜过 Opus 4.7 漏洞挖掘能力过线；本地模型追上来 5 月 教皇 Leo XIV 发布 AI 通谕；RubyGems 遭攻击 AI 进入公共议题；一个当时没人能解释的谜团 6 月 Claude Fable 5 发布，三天后被美国出口管制叫停 第一个「Fable 级」模型，也是第一次因国家安全下架 7 月 Fable 回归；GPT-5....

Ghostty 作者 Mitchell Hashimoto 10 月 6 日发了篇文章 A Terminal Protocol for Program Status: OSC 7501，提出一个新的终端转义序列 OSC 7501，叫 Program Status Protocol。程序用它告诉终端自己处在什么状态：空闲、运行中、在等用户、已完成或已失败，还能附上原因。完整规范在 这里，目前是 0.4 草案，不绑定任何产品。 为什么需要它 你在终端里跑构建、部署、升级依赖，现在还多了编码 Agent。任务一跑起来你就切走了，等它跑完或者要你拍板时，希望它能叫你一声。 终端现在只能猜：看前台进程有没有变，或者等输出安静一会儿。这两招表达不了进度、阻塞和任务树，也分不清「跑完了」和「卡住了」。把现有的几个转义序列拼起来，也解决不了这个问题。 以 Agent 收件箱为例 最近冒出来一类工具，作者叫它 agentic inbox：把所有 Agent 的状态汇总到一个界面里，比如 Herdr、cmux、Agent Deck。它们拿状态的办法只有两种。 启发式。 解析屏幕内容或窗口标题。Herdr 用一份 TOML 规则判断 Claude Code 的状态，其中一条是：标题以 Braille 或半圆 spinner 字符开头，就算 working。这份规则三个月里光为 Claude Code 就改了十次。作者特意说明，这不是在批评 Herdr。 带外 API。 比如 Herdr 的 socket API、cmux notify。程序自己上报，结果准确，代价是每个程序都得逐个对接收件箱，本地 socket 到了 SSH 或容器里还要另外桥接。pty 则能原样穿过 SSH 和容器。...

我在做 Claude。这是一种很有意思的体验：每天我都会听说一件我从未想到、以为不可能、或者单纯没好奇心也没时间去尝试的事，被 Claude 或者由 Claude 完成了。这个月，它可能帮忙发现了一颗新行星；我看到了第一个我真心喜欢的 AI 音乐视频；我们还在讨论数学的新时代。 模型的能力并不是齐头并进地增长。用陶哲轩（Terence Tao）的话说，模型"在某些方向上令人震惊，在另一些方向上则很不济"。有些人成功驾驭了那些令人震惊的能力，看上去真的在飞——看着别人用我参与打造的产品达到惊人的高度，这件事本身就很上瘾。但还有很多人仍在挣扎着让新长出的翅膀运转起来，琢磨着除了问"法国首都是哪里"或者"能不能让这封邮件听起来不那么生气"之外，它们到底还有什么用。 我经常（和做 AI 的其他同行一起）宣称：我们在使用 AI 时应该更有野心。这句话已经成了一句口号。每当我们看到什么厉害的东西，就转发并写道"我们还是不够有野心"。我很清楚照着这条建议做有多难，所以这里写一份关于"如何更有野心"的教程。 我把野心分成四种：速度、高度、深度、广度。 速度（Speed）： 同样的活，更少的时间。这是 AI 经济价值的基本盘：你需要写点代码，用 Claude 我会写得更快。这块已经很成熟，在方法上也不需要太多创造力，所以我会跳过它。 高度（Altitude）： 上升到更高的抽象层，关心"结果"，而不是单个任务。 深度（Depth）： 像某个领域顶尖的专家那样去处理一个任务。不停留在任务本身所在的那一层，而是往下走一层，去碰底层的数据、工具和问题。 广度（Range）： 不只依赖任务表面上需要的那一个领域，而是调用多个领域的知识、工具和技术——那些你平时不会用到的东西。 我主要用 Claude（这不废话），但我的建议并不针对某个特定模型。 高度（Altitude） 我们常常随口把这叫作"让模型在更高的抽象层上运作"。当你给模型一个任务时，它执行的是你对"如何得到想要的结果"的最佳猜测。想在高度上更有野心，就问自己——你希望接下来发生什么？ 目标背后的目标是什么？去年年初，我还在让 Claude 帮我修一个个具体的崩溃。后来我干脆让 Claude 让我们的应用"保持不崩溃"。 我们来看一个日常的（是不是可以说无聊的？）办公任务。你在 Acme 公司——一家虚构的公司——需要为季度业务回顾（QBR）做一份演示文稿。给一堆数据，Claude 会很乐意给你做几页幻灯片。也许你还有模板，它只需要填进去。这跟发现一颗新行星完全没法比，所以我们来看看一些具体的、能让做法更有野心的步骤。我们从最基础的开始，一步一步加码： 作为输入，大多数回顾真正想知道的是：这个季度变了什么、为什么变、以及该做点什么。抵抗住"只把模板里的数字更新一下"的冲动——尽可能把你手头的数据都给模型，让它理解你的业务：“告诉我这个季度变了什么、为什么变、我们应该怎么应对。” 会议（好的那种）理想情况下应该以一些决定收尾。问 Claude：“基于你了解到的所有情况，判断出最紧急的三个决定是什么，并针对每个决定开始推演可能的方向，附上支持与反对的论据。” QBR 诞生于这样一个时代：好的回顾需要人仔细翻检数据、弄清数据的含义、判断业务是否该调整。问 Claude：“这个回顾存在的意义，是让管理层及早发现问题，并把钱和人调到正确的位置。设计一个比季度演示文稿更好的做法来实现这件事，用我们自己的历史数据证明它本可以更早发现问题，然后让它和现有流程并行跑一个季度。” 如果你确实在追求某个终极结果，高度这套方法效果最好；对创造性的工作则效果一般。一个很好的判断信号是：如果你本来就要为这件事开会讨论，那么在高度上加大野心多半是对的。目前仍有局限（“Claude，去赚钱"在 2026 年对大多数企业似乎并不能单独奏效），但总体来看，模型越强，就越能在更高的抽象层上运作。 高度也是人们找到"把人类移出回路"的持久工作流的地方——这样你就不必一个任务接一个任务地不停喂给模型。要做好这件事，往往需要改变你的工作流——为了让 Claude 能确保我们的应用不崩溃，我得先让它能方便地拉取崩溃报告、理解哪个应用版本对应哪个 git commit、并且能访问 Windows、macOS、Linux 的机器，这样它才能真正独立地复现并验证修复。 深度（Depth） 有时候，你就是想把一个任务做到极致好。在深度上更有野心，意味着把模型推向该领域最优秀的专业人士所用的工具、技术、媒介和知识——并且一直推，推到连那些专业人士都可能从你的工作里学到新东西。 继续用 Acme 公司做季度业务回顾的例子。假设 Acme 有一些用户流失（churn，随时间流失的客户）问题。我发现下面几种手法混着用很有用： 坚持使用业界顶尖者所用的同一套工具： 当你让模型"扮演专业人士"时，它常常只是换了词汇，方法没换。要在深度上处理我们的问题，就得用最好的数据科学家和统计学家所用的同一套工具。当 Claude 掏出 markdown 表格时，坚持要求用数据库和统计模型。你不一定需要知道专家用什么，Claude 通常知道。 挑不合理的目标，然后告诉模型这些目标非常合理： 你需要网站加载时间从 10 秒降到 5 秒？那就要求 200 毫秒。某件事在模型看来不可能？反复重申它完全可解，只是需要继续做下去。 挑战你已知的东西： 尤其在商业领域，我们相信为真的很多东西只是对现实的粗略近似。把原始信息和数据交给模型，让它对抗性地检验这些假设。“我们相信流失是新手引导的问题。试着从原始数据里复现这个结论。” 产出新知识： 这条可以自然接在"挑战你已知的东西"之后——一旦 Claude 已经深入数据内部，就让它去找盲点。“基于我们的日志，构建一个能复现过去一年情况的客户模拟。然后找出一个我们还不知道的、最早的流失信号，并证明它在它没见过的数据上也有预测力。” 用外部裁判： 不要让模型评判它自己。我猜这个问题最终会随着模型智能的提升而解决，但在 2026 年 10 月，我恳请你坚持外部验证。最理想的是一个模型可以自己运行、立即拿到反馈的工具。 一个经常帮到我的简单提示词：...

这是 AI炼金术的一期单口，我想聊聊 AI 原生组织转型。之所以聊这个，是因为最近来找我的朋友，话题已经从"用什么模型、要不要培训、大家怎么用"，变成了另一种。他们说，我们公司已经在用 AI 了，很多人用得还不错，但整个组织的效率好像并没有提升。更诡异的是，还有一些公司发现效率确实提升了，却没有多赚钱，有的甚至裁了员，省了一部分人力成本，最后利润也没涨。 这就是我想讲的那个鬼故事：学也学了，用也用了，每个人都觉得自己提效了，整体效率却没动；或者整体效率动了，钱却没多赚。今天就聊聊这个鬼故事是怎么发生的，以及有没有办法解决。 效率有三层，大部分人只盯着最不重要的那层 我的基本判断是，效率本身不是一件特别重要的事情，至少单点任务上的效率不重要。这里面有三个层次。 第一层是单点效率，一个具体的员工干一个具体的活、干得快不快。这件事对个人、对任何一个打工人或个体户都很重要，但对公司其实没那么重要。公司要做的是把很多个体的努力协调起来，把劲往一处使，产生整体效果。单兵能力和组织作战能力，很多时候是两回事。 第二层是组织协调层。哪怕你练出了协调能力，不再是一群武林高手各自为战，而成了一支井井有条的军队，能不能赚钱还取决于你打下来的是什么样的城市，有些仗打赢了也是亏的。 第三层是市场和战略层，你站的位置对不对，做出来的东西是不是市场要的、是不是稀缺的。如果你做了一堆市场不要的东西，或者做了有人要但竞争激烈的东西，那你只是卷得更狠而已。 从单点效率，到组织协调层的效率，再到能把产出在市场上变成钱，这中间有两个大台阶要上。但我们大部分时候只关注第一件事，就像打仗时只盯着士兵的单兵技能好不好。士兵的单兵技能其实没那么重要，关键在于组织怎么把士兵协调起来，以及打下来的城市有没有意义。 单点提效为什么带不来整体结果 光做第一层没什么用，这里有几个原因。 第一个是阿姆达尔定律。一件事要干成有好多个环节，你只优化其中一个，对整体的效果有限。我经常坐上海到北京的飞机，大概两个小时。假设飞机提速百分之三十，从一百三十分钟降到一百分钟，这是一个伟大的科技进步。但整体想一想，我得从家里出发、打车、提前去机场、留提前量、等安检，门到门可能要五个小时。你在飞行环节省掉半小时，对两个小时来说显得很了不起，对五个小时来说，不过是从五小时变成四个半小时，在我脑子里变化不大。 我自己做过非常多很漂亮的 demo，有些合作方都发了 PR 稿，大家一起庆祝，说我们好棒，汇报的 PPT 做得花团锦簇。过一段时间再问这东西后来有用吗，答案往往是其实也没什么用。在一个长流程里优化一个环节，经常就是这样。 更悲惨的情况是，你优化一个环节，连整体上一点进步都看不到。因为一个系统的表现，取决于中间那个最低效的瓶颈环节，而不取决于某个非瓶颈环节的提升。拿餐厅后厨打比方，有洗菜工、切菜工、厨子、端菜工。假如洗菜切菜的手速突然提高十倍，但厨子没增加，或者厨子增加了灶台没增加，只有四个灶台四口锅，那灶台就是瓶颈，你把菜洗得再快也只是堆在那里，整体可能只提升了百分之一。更夸张的是，就算灶台也加了、后厨整体快了十倍，但门口的人流量没增加，你照样赚不到钱。 第三个原因更根本。一个组织真正的损耗，很多时候不在于干活。我们听播客的大多是做知识工作的白领，知识工作里最大的时间、精力和资源消耗，大部分花在开会、对齐、协调对接交接、反反复复的往来上，而不是做事本身。我看过不同口径的报告，大致都是说，百分之六十的白领工作时间花在这种协调性、对齐性的工作上：听懂老板在说什么，把老板的话讲给下属听，跟兄弟部门对齐，以及等待某件事发生。有个流程那边卡两天，你做得再快，那边还是卡两天。工资越高的白领，这种对齐、协调、人和信息的交互就越多。 所以就算你把那百分之四十的干活时间优化到极致，顶了也就四成，大头没动。这才是组织真正的瓶颈。而且这里有两个麻烦，一是大量时间成本耗在这，二是只要这里断了，你单点再对也没用。那个经典的例子是 NASA 的火星气候轨道器，两家公司合作，一家用英制单位一家用公制，没对接上，探测器飞了九个半月、几亿英里，到了火星直接坠入大气层烧掉，一亿多美金打了水漂。各自做的都对，各自说不定还加班提效了，拼到一起就是个零。 以前我们干活慢，这个协调瓶颈被盖住了。现在干活快了，你很容易就发现，交接和对接才是组织真正的大头。 组织是上一个时代的发明 张一鸣说他把公司当作一个产品来打造。如果把组织当成产品，那什么是好组织？应该是协调得特别快、能更有效地调度资源、能自己进化的那种。重点在于能不能把单点配到一加一加一大于三，有综合性的效果，而单个单点做得多好反倒是次要的。单点很强而协调跟不上，其实没用。 我听过最恶毒的一个类比，是说很多公司搞 AI、买一堆系统上一堆 copilot，其实就是满清买铁甲舰。船坚炮利，军舰都是好军舰，但整个组织的协调机制没跟上，你买得来好军舰，做不出好海军，这是两件完全不同的事。大部分人还停留在北洋水师的水平。 要往下想，就得回到一个原点：组织到底是用来干嘛的。我们常把组织当成天经地义的东西，像天上有蓝天白云一样。考虑 AI 组织转型时也默认，我们就是有这么一个组织，把它转一转就能更好地用 AI，人还是这些人，还是好兄弟。但现代公司制度其实是一种发明，老板、科层制、部门、汇报线，都是很近代才有的东西，用来解决具体问题。它本来要解决的，一个是信息路由，让大家知道消息；一个是管控机制，让大家协调到一起干活。 顺着这条线看，组织本身是为达成特定目的而造出来的工具，我们未必一定要保留这个形态。为什么有层级？因为一个人管不过来，让你直接管一百个干不同活的人你看不过来。但如果 AI 让你看得过来呢？滴滴一个人能管上千个司机，因为全局谁送到哪、车上录音都看得到，这个前提假设就变了。为什么有部门？因为人脑有限，不可能既懂这个又懂那个，所以要把一堆专才塞到一起、搞一个统一的界面对外交互。但如果未来每个人都是通才，身边都有一个小秘书帮他做翻译，研发和产品、设计之间不再需要靠会议和接口来沟通，还需要部门这个设计吗？为什么要有流程、要有人来做管控、要有开会、要有 KPI？ 这么一个个问去，你会发现这些组织的零件大多是为解决某个特定问题、或者基于某种稀缺假设而设计的。当那个"搞不定"或者"资源一定稀缺"的假设不再成立，世界不一定还会这样运转。 AI 来了，有点像恐龙时代一颗小行星撞地球，整个生存环境已经变了。过去留下来的那些东西，我们可以当成化石。它有没有道理？当然有，但那是上一个时代的道理，适应的是上一个时代的生存结构和生产力。今天全都需要重新审视。我想到一个段子，有些地方坐月子讲究不能洗头，这在古代挺有道理，没有热水器、没有电吹风，热水容易凉、头发吹不干容易感冒。但现在有热水器、电吹风、青霉素，这就不是什么大问题了。我们很多时候要考虑的，与其说是这个东西经不经典，不如说是环境约束变量有没有变。变了，就该重新设计那些习以为常的组织结构和打法。 一句暴论：用 AI 替代组织，而不是让组织用 AI 前段时间我在一个会上突然想到一句暴论。做 AI 原生组织转型，与其把原来的组织转一转去更好地用 AI，不如想一想怎么用 AI 去替代原来组织的绝大部分功能。AI 不是组织的工具，AI 是组织的替代品。从这个角度，你可能会打开一些新的思路和空间。 这里面有三层思考。第一层，在原有组织里把 AI 装起来、用好。第二层，改我的组织去用好 AI。第三层才是我今天真正想讲的：组织原有的目的、原有的功能，能不能用 AI 更有效地完成。问题从"我的组织怎么用好 AI"，变成了"我如何用 AI 让组织原来的那些功能发挥得更好、让商业目的更有效地达成"。 落到打法上，我现在看到最先发生的是三件事：对齐、推进、闭环。对齐，是让所有人站在同一条线上做事，不要每个人看到的图都不一样、自己打自己。推进，是让 AI 来推动一件事从想法到商业结果、从生产资料到最终产出，把整条线推下去。闭环，是让 AI 帮我们沉淀组织能力，这次做成的下次能做得更好。今天嗓子有限，我主要讲对齐，再讲一点推进。...

Karpathy 的 AI 辅助编程心法，总结下来有七个关键步骤 第一步：上下文拉满 (Stuff everything relevant into context) 这是基础。你需要把项目所有相关的信息都喂给 AI。对于大型项目，这可能需要花些时间。如果是小项目，可以直接打包所有相关文件。Karpathy 甚至给出了一个 files-to-prompt 工具的示例命令： files-to-prompt . -e ts -e tsx -e css -e md --cxml --ignore node_modules -o prompt.xml 这个命令大致意思是，将当前目录下所有的 .ts, .tsx, .css, .md 文件内容（忽略 node_modules 文件夹）打包成一个 XML 格式的 prompt 文件，供 AI 读取。核心思想是：给 AI 足够的全貌信息。 第二步：策略先行，而非代码 (Describe the next single, concrete incremental change) 明确你想要实现的下一个具体、增量的改动是什么。关键点来了：不要直接让 AI 写代码。相反，你应该要求 AI 提出几种实现该目标的高级方法，并分析各自的优缺点（pros/cons）。Karpathy 指出，LLM 的判断力并非总是最佳，通常实现一个功能有好几种方式，先看选项再决定。如果需要，可以再让 AI 把选定的方法具体化 第三步：选定方案，获取初稿 (Pick one approach, ask for first draft code)...

我常用的 ai大模型网站和工具 更新说明 2024.04.06，第一版 AI 搜索引擎 Perplexity：全世界最出名的，支持中文，综合体验良好，就是在国内有时候会抽风，短链接：pplx.ai 秘塔AI搜索：国内类似工具，体验也不错，还有小程序 Devv AI：面向程序员的 AI 搜索引擎，可以搜索技术类问题 其他 ThinkAny - AI 搜索引擎：@ArronYoung的作品 Lepton Search：贾扬清的开源作品 AI对话大模型 chatgpt、文心一言等就不列举了 Kimi.ai - 帮你看更大的世界：最近很火的长文本 ai 大模型，我用来总结文章和资料挺好用 Poe：集合了多家大模型的网站，有免费额度 DeepSeek：国内量化基金幻方量化的作品，用的少但是体验流畅，支持通用对话和代码助手。 AI bot 开发平台 用来开发和展示类似于 GPTs的自定义 AI bot 的平台 扣子 - AI 智能体开发平台：字节产品，国内版本，开发流程和使用体验很好。但自己的云雀大模型拉胯 Coze: Next-Gen AI Chatbot Developing Platform：字节国外版本，免费使用 gpt4，就问你爽不爽 灵境矩阵 | 想象即现实：百度的基于文心大模型的智能体平台，支持 prompt 编排 百度智能云千帆AppBuilder：百度的 ai 原生应用开发平台，支持多个模型，支持多个框架和组件，相比灵境矩阵更底层一些。 AI 工具大全｜导航 AIbase - 智能匹配最适合您的AI产品和网站：有排行榜 AI帮个忙 | 多功能AI小帮手：即刻出品的 AI工具集 | 700+ AI工具集合官网，国内外AI工具集导航大全：这个比较常用 爱AI：配置好的AI bot比较多，比如OKR 专家，小说助手等，还支持画画...

思考 大模型异军突起，很多以前实现起来很困难的功能在大模型前面变的轻而易举，「总结」能力就是其中一种。在我用的起劲的时候，突然反思，我这样做对吗？会不会让我自己丧失总结的能力？会不会失去阅读的兴趣？ 画了个波士顿矩阵： 想了想，工具是帮助自己的，人类发明了计算器我能怕丧失计算能力而不用吗？君子爱器，取之有道，只要把握好一个度就好了。用ai总结的目的是帮自己快速过滤没有意义的文章，剩下的文章是需要自己认真研读的。 所以可以这么做：让ai总结，并问一些问题，比如文中是否有不合直觉的地方等等然后再决定是否详读。 资源 整理一下当前可以用的ai总结工具 kimi ：个人觉得最好用 kagi：内容多，但没有重点 sider：浏览器扩展，需要选中文本再操作 poe.com 内置的ai agent，比如：Summarise，URLsummary，Webpage等等