我们讨论可穿戴到底在讨论什么

很多人讨论 AI 手机、AI 眼镜、AI Pin 时，容易把问题简化成：

• 设备里有没有大模型
• 是不是本地跑 AI
• 能不能替用户点 APP
• 是不是加了一个 AI 助手

但真正的变化不在于“手机里多了一个 AI 功能”，而在于两个更底层的迁移，也就是：

• 端云结合
• AI 原生

什么是端云结合

端侧设备，比如手机、眼镜，有天然的限制，算力、电池、内存、散热等，如果把 AI 能力都放在设备本地，体验会受限很多。但是，如果把所有能力都放到云端，也会有很多问题，网络延迟、实时性、用户隐私等。所以这里引入了端云结合的概念，即「端侧负责靠近用户，云侧负责扩展智能」。

具体来说，端侧适合做那些“近身、实时、隐私、低功耗”的任务：唤醒词检测、语音前处理、本地数据检索、离线场景下的兜底能力。云侧则反过来：跑大模型、多轮规划、长上下文、多模态、RAG 检索、知识更新、多 API 编排等。今年 WWDC 就是聊的这些。

但这里面其实不容易做，不是简单的“本地跑一点、云端跑一点”。什么时候在端侧做、什么时候上云、失败了怎么降级、数据怎么保护、体验怎么保持一致等等，每一件拧出来都有难度，这也是为什么 Apple Intelligence 一直差强人意，国行就更别提了。

从传统 APP 到 AI 原生

我们再回过来看我们的手机 APP，基本是的操作流是这样的：

用户 → APP → 页面 → 按钮 → 服务

这条链路是“给人操作”的，所以 APP 设计有一个假设，即人知道自己要打开哪个应用，也知道该点哪里。该假设在简单任务里成立，复杂任务就低效。

所以做 AI 设备需要换个思路，要从「以人为本」切到「AI 原生」，即：

用户目标 → AI Agent → 工具 / API / 服务 → 结果

用户的定位也变了，不再表达“我要点哪里”，而是说“我想要什么”。对比一下就知道：传统 APP 给人看，所以是界面优先；而 AI 原生是给 Agent 调，所以要能力优先。而这意味着服务商必须把能力开放成可调用的接口，而不是藏在一堆点击路径后面。

眼镜、耳机、车机、机器人、智能家居，这些天然就不适合复杂点击。它们共同的需要是语音、视觉、上下文、API 调用，这些几乎只能在 AI 原生范式下才能玩的起来。

所以要理解 AI 手机/设备，要走出“手机里装了个 AI APP”或者"APP 里加了问答助手”这种思维，而是从一开始，应用的交互、数据流、任务流、权限模型就是为 AI Agent 设计的。流程大概像这样：

用户表达目标
  ↓
AI 理解上下文
  ↓
调用本地模型 / 本地数据 / 传感器
  ↓
必要时调用云端大模型或 API
  ↓
执行任务
  ↓
用户确认关键动作
  ↓
结果反馈和持续记忆

拿这个框架去看豆包手机，它更像是在旧 APP 世界里训练一个会点屏幕的 AI，通过读屏和模拟点击来替人操作。这种方式注定要迁就原有 APP 的 GUI 假设，效率上限也显而易见。

真正的 AI 原生，应该反过来，重建一个让 AI 直接调用能力的新世界：系统和服务从一开始就为 Agent 调用而设计，通过标准化的 API、Intent 和权限体系让 AI 直接完成任务。模拟点击只是过渡，不是终点。

1. How was your first experience with AI models?
2. Do you use AI or are you completely against using it?
3. Do you have any preference among different models, for example Claude vs ChatGPT? If yes, how do you choose?
4. What aspect of AI models do you like and what do you not like?
5. How do you feel about AI generated images? Does it annoy you if someone use them in a blog post?
6. Internet is flooded with AI slop now, full of generated text, images, audio and videos. How do you filter it from authentic human creation? Do you have a strategy?
7. Are you hopeful for a better future with A.I. or a dystopian one?

你第一次使用 AI 模型的体验如何？

细节记不太清了，是在 ChatGPT 刚出来那会儿，应该是问生成小游戏或者代码相关的问题，欻（chua）的一下出来很多，看着有模有样，有点小震撼。后面还找各个提示词玩，印象比较深的是一个情景游戏的提示词，类似故事推演，不过玩几步也没意思。

你会使用 AI 吗，还是完全反对？

一直在用，不会反对。

你对不同模型有偏好吗（如 Claude vs ChatGPT）？如果有，你如何选择？

没有什么偏好，国外用的不多，没条件吃细糠，因为买了 Minimax 的 Token Plan，目前主要在用这个。用下来中规中矩，有时候有点傻，今天就在一个 Bug 上纠缠了很久，然后试了 GPT 一下子就好了，那一刻，说实话有点“恨铁不成钢”，但平时没啥问题，便宜省心。

你喜欢 AI 模型的哪些方面？不喜欢哪些？

现在基本上用 CLI 的 Agent 模式，单 Chatbot 已经很少用了，Agent 这套东西用起来挺好的，配置好 Skill 能完成好多任务，而且还能自我进化。不喜欢的地方可能是原生模型本身带的比如啰嗦、一上来就输出，等等，所以需要一套好的缰绳系统。

你如何看待 AI 生成的图片？如果有人在博客中使用，会让你反感吗？

图片用的不多，平时社交媒体的消息流中会看到一些粗制滥造的 AI 图片，很反感，但这跟是不是 AI 生成没关系，丑图即使是大师画的我也反感。另外，在一些科普或技术文中，我觉得 AI 生成的一些逻辑图挺好的，方便内容理解。

现在互联网上充斥着 AI 生成的内容（文字、图片、音频、视频）。你如何区分它们和真人创作？有没有策略？

没特意去区分 AI 还是真人，正如前面说的，真人创作的低质内容我也反感。策略的话，一时也说不准。如果非要说点什么，可能是多读点书、同时学会思考，提高自己的鉴赏力。「真诚是必杀技」，内容创作也一样，不管背后是 AI 还是人。

你对 AI 的未来更乐观，还是更担忧其走向反乌托邦？

应该算乐观的吧，反乌托邦倒不至于。目前看 AI 确实在提高生产力，也在慢慢渗透到各行各业，这一点我还是偏乐观的。再往后怎么走，我觉得还是看那些大公司和政府怎么引导。最近在玩《地铁：离去》，如果说反乌托邦是那样的世界，那我们人类混得挺惨的。就如这种文学、影视作品里的反乌托邦，往往不是技术本身的错，而是掌握技术的人、或者技术所处的组织环境出了问题。

前段时间刚好看了纪录片《恐龙时代：你不知道的故事》，就地球演变史来讲，我们人类目前所处的阶段真就挺好的，我希望人类文明能借助 AI 走出地球、走向其他星系。

这两年大模型发展很快，完全跟不上。越看越觉得，单纯从 Transformer²、提示词工程³（Prompt Engineering）、缰绳系统⁴（Harness Engineering）这些概念入手，很容易陷入细节、落个「只缘身在此山中」。倒不如后退一步，问一个更基础的问题：

LLM 到底用了什么魔法，能解决这么多问题？

我尝试从第一性原理出发，结合跟 LLM 的聊天，来重新理解 LLM。

从序列建模说起

最早接触「序列」这个概念还是刚工作那会儿在做胎压监测算法⁵的时候。当时公司的核心产品，就是基于每个轮胎过去几分钟的胎压间接变化，去预测是否存在漏气风险。它本质上是一个典型的时间序列问题。那也是我第一次直观地感受到：序列里蕴含的信息，远比我们想象的要多。

LLM 也是一个序列模型。

所谓序列建模，实际上就是：

根据过去的信息，预测下一步。

这件事在很多领域都非常常见。比如上面提到的胎压监测；再比如当你读到这里的时候，你会猜测后面我会写什么。

数学表达一下就是：

当前状态 + 当前输入 -> 下一状态

而这也是循环神经网络（RNN）的设计直觉。

从 RNN 到 Transformer

RNN 的直觉很自然，它的核心思想是：当前状态由当前输入和上一时刻状态共同决定。

这非常符合我们对这个世界的理解。我们阅读是一个词一个词读，控制系统也是按时间步更新状态。从这个角度看，RNN 很“自然”，很像真实世界里的状态演化。

但它的问题也很明显：

• 难以并行训练
• 长序列上容易遇到梯度消失或梯度爆炸
• 需要把过去的信息压缩进一个固定大小的隐藏状态向量，容量有限

所以 RNN 的设计直觉虽然优雅，但工程扩展性不够好。

而 Transformer 的思路不太一样。它不是一步一步更新状态，而是把整个上下文拿出来，让所有词元（token）之间互相建立关系。也就是说，RNN 像是状态逐步演化，Transformer 则像全局关系建模。

相比之下，Transformer 的优势就出来，即可以并行计算，也就非常适合 GPU 这类硬件。

而 LLM 之所以能发展到今天，很大程度上不是因为它需要在理论上最“自然”，而是因为 Transformer 这种结构足够适合规模化，是工程的选择。

LLM ≠ Transformer

很多人一提到 LLM，就会想到 Transformer，但我倾向把它们分开看：

Transformer 是当前最成功的实现方式，但 LLM 范式本身不等于 Transformer。

那什么是 LLM 范式？简单说就是：

一个模型 + 大量数据 + 提示词，去解决大量不同任务。

这和过去的 AI 思路有很大不同。

AI 范式的演化

我暂且粗略分为下面几个阶段：

1. 规则系统：人写规则，机器执行
2. 传统机器学习：人设计特征，模型学习规律
3. 深度学习：不同任务，训练不同模型
4. LLM：一个通用模型，通过提示词适配不同任务

以前我们经常做的是针对不同的任务去做不同的模型，比如：

• 翻译任务 -> 翻译模型
• 分类任务 -> 分类模型
• 语音任务 -> 语音模型

而 LLM 的思路是：不同任务 -> 不同提示词 -> 同一个模型

这就是范式变化的核心：

任务不再主要通过「换模型」来完成，而是通过「换上下文」来完成。

所有任务都变成补全问题

LLM 的训练目标看起来非常简单：根据上下文，预测下一个 token。表面上看，这只是一个“文字接龙游戏”，但它厉害的地方在于，很多任务都可以被转化成文本补全问题，比如：

翻译：请把下面这句话翻译成英文：……
问答：请回答这个问题：……
写代码：请补全下面的函数：……
总结：请总结下面这段文字：……
规划：请制定一个三天学习计划：……

这些任务看起来完全不同，但对 LLM 来说，最后都变成了：

给定上下文，继续生成后面的文本。

这就是 LLM 范式最强的统一性。

Prompt 其实是一种运行时编程

提示词的本质不是“提问技巧”，而是一种运行时配置。你可以在提示词里定义：

• 角色
• 目标
• 约束
• 示例
• 输出格式
• 判断标准
• 可使用的工具

比如：

你是一名嵌入式工程师，请从故障诊断角度分析以下 CAN 报文异常。

这句话没有改变模型参数，也没有重新训练模型，但它改变了模型接下来生成内容的方向。

所以，LLM 带来的一个重要变化是：

我们不再只靠改代码或重训模型来定义系统行为，而是可以通过上下文临时塑造模型行为。

降维

在理解 LLM 的过程中，LLM 告诉我有一个东西很重要，这就是「降维」。

我（LLM）实际上在做一件非常激进的事，就是把各种复杂的智能行为，统一压缩成 next-token prediction。

原本不同任务可能需要不同系统，而 LLM 的思路是：先把它们都表达成文本序列；再统一成“预测下一个 token”。

也就是说，它把真实世界中的各种“下一步动作”，压缩成了语言空间里的“下一个 token”。原本的任务是各式各样的，比如：推理、规划、翻译、写代码、解释、创作，它们看起来都不一样。但 LLM 把它们统一成了三件事：

1. 表示层：一切都变成 token 序列
2. 任务层：一切都变成补全问题
3. 机制层：一切都变成统计学习

传统观念是不同智能问题需要不同的算法，而 LLM 观念是：所有智能问题只是同一个数据分布问题。

预测下一词 ≈ 推理？

我相信这也是很多人刚开始接触大模型时困惑的地方。预测下一个词，看起来是一件很低级的事。为什么它会表现出推理、规划、写代码这样的高级能力？

AI 给我的回答是：

推理过程本身，很多时候可以被表达成一段结构化的语言序列。

比如一道数学题的解题过程，不只是最终答案，而是一连串有结构的步骤：

1. 先分析条件
2. 再列出关系
3. 然后推导
4. 最后得到结论

代码也是类似的。一个函数的实现过程，背后有语义、有结构、有约束、有模式。为了更好地预测下一个 token，模型不能只记住表面文字，它会被迫学习隐藏在语言背后的结构。也就是说：

• 训练目标：预测下一个 token
• 中间结果：学到语义、知识、结构、推理模式

这点很关键。训练目标和最终能力，不一定是同一个东西。就像一个人练习投篮，目标是把球投进篮筐，但过程中会形成肌肉记忆、空间感和节奏感。LLM 也是类似，预测下一词是训练目标，但为了完成这个目标，模型会逐渐学到更深层的表示。

语言为什么这么重要

LLM 能成功，还有一个很重要的前提：

语言不是普通数据，它是人类认知的外显轨迹。

人类把大量知识和思考过程都写进了语言里：事实、推理、解释、计划、类比、代码、数学、指令、任务描述、价值判断，等等。所以训练大模型，不只是学语法，也是在学习人类如何组织知识、表达问题和解决问题。

LLM 之所以能从语言中学到推理，不是因为“文字本身有魔法”，而是因为人类把大量推理过程、知识结构和问题求解方法，都沉淀在了语言数据中。

从上下文开始理解 LLM

如果要从第一性原理理解 LLM，我觉得最应该关注的不是 token，也不是 attention，而是上下文（context）。因为 LLM 的能力施展几乎都围绕上下文展开。

上下文决定了：

• 当前任务是什么
• 需要使用什么知识
• 应该扮演什么角色
• 输出需要满足什么格式
• 有哪些约束条件
• 是否需要推理
• 如何组织答案

模型参数是固定的，但 context 会改变它的行为轨迹。所以，理解 LLM 的关键，不只是理解模型本身，而是理解：

如何通过上下文塑造模型的行为。

这也解释了最近很多新出的概念，比如 AGENTS.md、缰绳系统都是围绕上下文展开的。

LLM 范式

总结一下，对于 LLM 范式：

1. 把世界变成 token
2. 用预测下一个 token 学习结构
3. 通过规模化获得迁移能力
4. 再用上下文控制模型行为

一个简单的思维框架

理解 LLM 的意义，不只是理解一个技术热点。更重要的是，它提供了一种拆解复杂系统的方法。以后再遇到新技术、新模型、新框架，或许都可以从四个问题入手：

1. 它在表达什么

它如何“看世界”？LLM 把世界看成 token 序列。

2. 它怎么运行

它的运行机制是什么？LLM 通过神经网络在上下文中建模 token 之间的关系。

3. 它怎么获得能力

能力是人手工设计出来的，还是从数据中学出来的？LLM 的大量能力来自自监督学习和规模化训练。

4. 你怎么控制它

你是在编程它，还是在引导它？LLM 的主要接口是提示词和上下文。

这四个问题其实可以总结如下：

任何复杂系统 = 表达方式 + 计算机制 + 学习方式 + 交互接口

这可能比记住某个具体模型结构更重要。

结尾

回到最开始的问题：

LLM 到底是什么？

我现在的理解是：

LLM 是一个极大规模的序列建模系统。它把各种智能行为压缩到语言空间里，通过「预测下一词」学习隐藏结构，再通过「上下文」在运行时塑造行为。

这不是一个完美的定义，但对我来说足够有用。它解释了为什么 LLM 既强大又有局限。强大，是因为它把大量任务统一到了一个框架里。局限，是因为降维必然会丢失信息。它学到的是数据分布中的结构，而不是世界本身。所以，理解 LLM 不应该只停留在“它会不会真正思考”这个问题上。更重要的是理解：

它如何表示世界，如何学习结构，又如何被上下文控制。

也许，这将成为我们理解硅基文明的起点。