Tw93修改

2026-06-07 08:00:00

太长也要读

今年 4 月我组装了一台小机器狗，做的过程在推特上发过几条，大伙应该都刷到过，从买零件、装结构，到最后它能听懂指令、走两步、还能对话几句。

缘由要从过年那段时间说起，那阵子我天天用 Opus 4.6 写代码，发现很多地方它写得比我好，又快又准，越用越 FOMO，于是就想，要不试试软硬件结合的东西，这块相比纯软件可能还有一点门槛。

真想做了，方向很快就落到具体问题上，传感器怎么读，舵机怎么控，通信怎么兜底，电池、结构件和故障怎么处理。这些都比「做一台机器人」实在，于是我买了 STM32、ASRPRO、ESP32-C3、MG90S 舵机、OLED、DHT11、锂电池，还有一套 3D 打印结构件，凑成一台能听懂话、会趴下、会走路、还能接云端 AI 对话的小机器狗。

真上手才发现，最费时间的反而是各种小细节，MG90S 舵机 4 个里总有一个不太稳，OLED 我带电插一次就直接烧了，又多等了几天零件。直到 DeepSeek 对话、温湿度读取和动作控制都真跑起来，我才慢慢体会到「AI 进入物理世界」是什么意思。

从软件视角看，具身智能很容易被理解成给大模型接上一副身体，但真把线插上、电机转起来、结构件震起来，感受完全不一样，一条自然语言指令一路要变成结构化意图、动作序列、PWM、力矩、电流和接触，每一层都有自己的时间、能量和误差预算，还冒出一堆纯软件里根本不用操心的问题。

发完「你不知道的大模型」那篇文章后，有小伙伴起哄，看来你要写「你不知道的具身智能」了。我一想这台小机器狗刚好能帮上忙，虽然很皮毛，但我想聊的「感知、空间、动作、力矩」这些具身智能的基本概念，它身上其实都有，于是就开始了。

文章前半写这台机器狗的创造过程，后半是我基于公开论文、官方博客、开源项目和第三方资料整理的学习笔记，希望能给在 AI 之外、也想了解具身智能的朋友，多一个工程师视角。

先把小机器狗跑起来

这台小机器狗最后做成了一个低成本异构系统，加起来成本大概 200 多的样子，能听到唤醒词后进入对话，把用户指令交给云端 LLM 做语义理解，再把返回的结构化动作转成 STM32 能执行的舵机控制。

把它拆成数据流，对调试很有帮助。后面很多卡住的地方，最后都落在周边硬件上，比如唤醒词误触发、联网超时、舵机角度或供电不稳，这些偏硬件的坑甚至能整理成一张排查表：

一开始也想过，要不要换一颗更强的芯片全包了，真接线以后发现不是一回事，唤醒、联网、PWM、传感器读取、云端请求，各自要处理的延迟和稳定性都不一样。

ESP32-C3 负责 Wi-Fi 和云端 AI，接入 2.4GHz 网络，把语音或文本转给云端模型，再把结果发给 STM32。它比 STM32 更适合联网，但如果同时承担 PWM、多路串口、网络请求和对话状态，调度会很快变重。

ASRPRO 负责离线唤醒，低功耗监听环境声，识别到唤醒词再拉起联网，比全程上传音频更省电，也少一些隐私压力。

STM32F103 是 72MHz 的 ARM Cortex-M3，Flash 64KB、SRAM 20KB，跑模型不现实，做硬实时控制刚好；4 个 MG90S 舵机用 50Hz PWM 控角度，0.5-2.5ms 脉宽对应 0-180 度，硬件定时器能稳定输出微秒级 PWM，舵机走路时就不容易被任务调度带偏。

大概清明节前的那个周五零件和工具就全部到了，当天晚上开始整，持续几天，最后它从一堆零件变成了一台绑着线、能走好几步、能听懂简单指令的小机器狗，挺有趣的。

这里也用到 MCP 的概念，只不过在这台小机器狗里更简单，就是给模型和设备定一份「能力清单」。设备把自己能干的事报上去，模型照着清单调用。

对我最有用的地方，是把哪些能力留在本地、哪些能力交给云端先分清楚：设备端控制扬声器、LED、舵机、GPIO 等本地硬件，云端扩展智能家居、PC 操作、知识搜索、邮件等能力，这样边界会清楚很多。

实际完整走一遍是这样的，ESP32-C3 先上报自己有哪些能力（servo_control、sensor_read、gpio_write），我说「曼波坐下」，云端模型生成一个结构化调用（目标舵机、目标角度、速度参数），ESP32-C3 把它翻成 UART 指令发给 STM32，STM32 再一步步调整 PWM、回传执行状态。

这套小系统已经能听懂「坐下」、「站起来」、「现在温度多少」。空间能力完全没有，自己在哪里、椅子在哪里、往左走两步会不会撞到，全不知道。

机器人怎么知道自己在哪

小机器狗听不懂「往左走两步绕过椅子」，它根本不知道椅子离自己多远，也不知道自己在房间里站哪儿、朝哪边，更没有一张能持续更新的 3D 地图，深度感知、位姿估计、空间地图，这三样能力它都没有。

补空间能力不是再多接一个模块。深度相机、IMU、能跑 SLAM 的板子一上来，成本、功耗、算法栈就完全不一样，STM32 那套小系统也接不住。

后面还会多出四条新链路：「相机标定」要处理内参、畸变、曝光和同步；「位姿估计」要算清相机、IMU 和机身坐标之间的变换；「地图更新」要考虑环境变了之后旧地图怎么失效或修正；「动作规划」则是地图上可达，不等于真实脚底能稳定落下。

小机器狗如果只在桌面上演示，可以绕开这些问题。一旦放到房间里，地板反光、桌腿遮挡、线缆、台阶和光照变化都会进来。

图像模型擅长回答「这张图里有什么」这种 2D 问题，但机器人还得继续回答：这个物体离我多远，遮挡是什么情况，从哪个方向抓更稳，移动一步以后视角和支撑点会怎么变。

在 2D 图像里，一个杯子只是几百个像素。放到机器人世界里，一个杯子是有体积、重量、摩擦、遮挡和接触面的物体。机器人常用的 3D 表示主要有下面这几种，工程代价差别不小：

低层避障常用 occupancy 或局部 cost map，抓取看点云和末端位姿，长期任务需要 scene graph 这种带关系的空间记忆。难的是把它们放到同一个时间轴和坐标系里，3D 场景一旦无法持续更新，很快就会变成过期照片。小机器狗完全没有后两者，所以「往左走两步绕过椅子」这种指令根本没法执行。

SLAM 和点云擅长几何，能给位姿和障碍物，但语义弱，系统知道前面有一团点，却不知道那是椅子还是纸箱。NeRF 和 3D Gaussian Splatting 擅长重建和生成新视角，对机器人来说，更要看它们能不能把仿真、数据增强和世界模型拉近真实场景。

3D Scene Graph 更接近长期记忆，它把房间、桌子、杯子、抽屉这些对象变成节点，把「杯子在桌子上」「抽屉属于柜子」「钥匙上次在玄关」变成关系。家庭机器人要回答「我上次把扳手放在哪里」，只存一堆视频帧很难做到。

空间记忆还必须保留不确定性。机器人只在画面里看过一次杯子，就不该永久相信它还在原处。对象名称、最近观测时间、置信度和可见性，实现时都要一起存。

VLA 也在从 2D 往 3D 迁移。早期 RT-2、OpenVLA 主要把 2D 图像、语言和动作连起来，桌面抓取够用，但指令如果变成「把被挡住的蓝色积木拿出来」，2D 像素就不够了。机器人要知道蓝色积木被谁挡住，是否要先移开挡住它的物体，移开后是否会让别的东西掉下来。

3D-VLA、SpatialVLA 这类工作尝试把 3D 场景、SE(3) 位姿（位置加朝向，6 个自由度）和动作生成合到一起。Figure 的 Helix 系列虽然可以从单目视觉输入工作，但它仍然需要在内部学到深度、可操作性和物体关系。显式输入可以是 2D，内部表征要进入 3D。

单目摄像头做人形机器人同样需要权衡。单目可以通过多视角、运动视差和神经网络估深度，但需要足够的数据和稳定运动。主动深度或 LiDAR 是用硬件换确定性。Tesla、Figure、Boston Dynamics、宇树的传感器选择不同，背后是在视觉数据、算力、实时性和安全冗余之间取舍。

这也是我这台小机器狗的边界，它能把语言变成动作，但动作还不在空间里，没有位姿、地图和遮挡处理，「往左走两步」这种指令还是没法落地。

从写死的动作到 VLA

我那台小机器狗跑的还是固定动作，你说「坐下」，它就调出一组预设好的舵机角度，并没有真的从画面和语言里生成新动作，只是在语音入口前面加了一层意图识别。

在真实的具身智能里，VLA（Vision-Language-Action）才是值得细看的方向，把视觉、语言和机器人状态一起喂给同一个模型，让它直接输出动作，减少「视觉检测、语言理解、规划、控制」之间一堆手写接口，不过接口少了，排错难度反而会增加不少。

同样是「输出动作」，有的模型给关节角，有的给末端执行器（手或夹爪）的位移，有的给夹爪开合。关节角贴近硬件但难跨机器人迁移，末端位姿更通用却要配上逆运动学。

最早是 RT-1，把 13 万条演示、700 多个任务喂给 Transformer，第一次把机器人控制当成序列学习。RT-2 再把互联网图文混进来训，让模型把网上学到的常识也带进控制，代价是连续的关节、位姿、夹爪压成 token 会丢精度，动作一多 token 串也跟着变长。

ACT 更直接，把动作打包成一小段一起预测。ALOHA 用一对便宜的遥操作臂就能插 USB、拉拉链、煎蛋，到现在还是很多人上手模仿学习的第一站。Diffusion Policy 解决的是「绕开障碍物」这种有多条合理路径的情况，普通回归容易学出个直接撞上去的折中动作，扩散从噪声一步步生成，反而能把几种都对的走法都保住。

π0 改用流匹配，采样快不少。π0.5 再把泛化往开放环境推，混进高层子任务、口头指令和网页数据一起训。Physical Intelligence 给的结果是训练环境越多、到新家越稳定，大约 100 个环境就追平了「直接在目标环境训练」。

SmolVLA 走另一头，把门槛压到消费级硬件，450M 参数、只用社区数据、3 万条 episode 以内就能跑，能力未必最强，但把 VLA 从大公司集群里解放了出来。社区数据多样性要覆盖光照、相机角度、房间和演示质量，和软件工程里的测试集类似，单一实验室的干净数据，未必比一批有噪声但覆盖更广的更管用。

2025 年后高低层分工更明确。Google DeepMind 的 Gemini Robotics 就是一路，ER 1.5 负责理解和拆任务，配套的 VLA 管把每步变成动作，还出了 On-Device 版，本地低延迟，50-100 条演示就能适配新任务。

这种分工演示起来往往很好看，但放到产品里就容易暴露问题。「按本地垃圾分类规则整理桌面」，高层模型要查规则、拆步骤、解释意图，低层模型要识别每个物体并放进正确容器，两层混成一个黑盒，真出了问题就很难排查。

Figure 的 Helix 也走分层系统。早期 Helix 里 S2 是低频 VLM，S1 是 200Hz 动作策略；Helix 02 又补了 1kHz 的 S0 全身控制层，把平衡、接触和协调放到更快的一层。小机器狗里的处理方式也类似，慢模型做理解可以，平衡、接触和协调得交给更快的一层。

机器人大脑的难点，除了听懂话，还得考虑动作怎么表示。动作太粗抓不准，动作太慢控制不稳，一旦动作不连续，真实电机和接触又会把误差放大一截，最后效果就会偏得很明显。

绕不开的时间、能耗、数据

如果要把机器人系统的控制层拆一下，我一般分成大脑、小脑、肢体三块，落到工程里，其实就是不同频率的控制问题。

小机器狗里也有这个分层，不过是极简版本。DeepSeek 对话是大脑，STM32 里的步态序列是小脑，PWM 和舵机是肢体。它不做动态平衡，1-2 秒的云端响应也能接受，但换成人形机器人，1 秒的平衡延迟就足够让它摔倒。

大脑层慢一点没关系。机器人听到「把杯子放进水槽」，会把它拆成找杯子、走过去、抓起来、松手，这种语义活儿不需要 1kHz。但小脑不行，它得快。人站着走着其实就是个倒立摆，控制回路一般得跑 200Hz 到 1000Hz，低了一受扰动就出问题。

再往下到肢体层就更要硬实时。电机控制要看编码器、估速度、限电流，一旦不对就立刻停掉，很多系统干脆把这一块放到专用 MCU 或 FPGA 上，避开 Linux 这类调度带来的不确定延迟。

延迟出在哪一层，表现完全不同。大脑慢，你觉得反应迟钝；小脑慢，一碰就倒；肢体慢，电机先抖再发热。

还有个容易被低估的坑，大脑、小脑各用各的坐标系，传感器又快慢不一（IMU 几百赫兹、摄像头几十赫兹、编码器上千赫兹），得靠标定和时间戳把它们对到同一个时间、同一套坐标上。标定一旦漂了，模型拿到的状态就跟真实世界对不上号，算法看着像是突然变笨，所以很多机器人 Debug 会先回到传感器、外参、零点和时间戳。

聊完时间，第二块就是能耗，机器人同样绕不开执行器和电池。一个人形机器人有几十个电机，电机、减速器、丝杠、编码器和驱动器往往是 BOM（整机的零件成本清单）里最贵、最难规模化的部分。

灵巧手尤其难。电机、腱绳、触觉、线束和散热全得塞进巴掌大的地方，所以很多公司反复打磨手部。人一天约 2000 kcal、折合 2.3kWh 就能活动很久，机器人没有骨骼韧带那套被动支撑，站着不动也得一直靠耗电撑着姿势。

第三块是训练数据，比普通大模型的数据难采太多了。文字能爬，图片能标，自动驾驶靠满街的车就能收一堆，可轮到机器人操作，你得有真硬件、有场地、有人看着，还得划好安全边界，这些都备齐了再开始采，成本直接高一个数量级。数据大致从这几个地方来：

仿真本来想绕开采集的麻烦，但它和真机终究不一样。光照、摩擦、间隙、磨损、传感器噪声、电机发热，仿真里都很干净，真机上却全是。比较稳的做法是先在仿真里把策略练到不犯低级错误，再拿少量真机数据校一遍，把失败样本收回去再训。指望仿真一步到位的，基本都会低估接触和传感器的误差，光靠仿真那点数据其实远远不够。

Tesla Optimus 这个工程样本

我很喜欢 Tesla，也很早就买了它的股票，所以看 Optimus 难免带一点个人偏好。单独写 Optimus，是因为它把 FSD 迁移、纯视觉、端到端训练、自研执行器、工厂试跑和大规模制造放在同一台机器上。拆开研究它，手从演示灵巧走到长期可靠要多久，失败样本怎么补上接触数据，制造体系怎样把执行器、线束、传感器和电池做成可维护产品，这些问题都会更具体。

表里的数字来自 Tesla AI Day、财报电话会和第三方技术整理，主要是一些公开口径和目标。记得当年 AI Day 的 PPT 和视频被不少机器人公司一帧一帧研究，这件事本身就很有意思。

手部升级看着是小改动，放在机器人里其实很大。工厂里的「拧螺丝、插连接器、搬零件、贴标签」和家庭里的「拿杯子、开门、叠衣服」，只靠手臂大范围运动很难做好。手指要有足够多的接触点，也要知道物体是否滑动、是否易碎、接触面在哪里，这些都得一起考虑上。

一根没有销钉的手指

2026 年 4 月 16 日，第三方拆解提到一组 WIPO 公开的 Tesla 手和前臂专利。专利本身不等于量产设计，但其中 WO 2026/080693 很能看出结构取舍，Joint Assembly for Robotic Appendage，也就是机器人附肢关节组件。当时在推特看到这个报告，我印象很深。

拆解材料里的思路是绕开传统销钉铰链，用一块扁平复合件夹在两节指节之间，上下两层弹性体，中间夹一片很薄的增强片，材料候选里出现了 Vectran 和 Nitinol，前者是液晶聚合物纤维，后者是镍钛超弹性合金，用来做方向性刚度。

这个设计要控制的是弯曲方向，手指弯曲方向要软，拉伸、压缩、剪切、扭转、侧摆这些方向要硬，传统销钉靠几何结构限制多余自由度，这个方案靠各向异性刚度来限制。工程上它有三个潜在收益，指节之间能形成接近滚动接触、转动轴随角度移动，更像真实手指；弹性体自带回弹，不一定要额外回位弹簧；腱绳还能穿过中性面，减小反复弯曲带来的疲劳。

这个案例看着像结构设计，背后其实牵连了灵巧手里一连串问题，一个关节结构会影响手指回弹、腱绳走线、腕部布局、前臂空间、装配公差和维修方式，它能不能在一天几千次抓取后还保持一致，演示里看不出来，需要实际到真实工作场景长期使用才知道有没有问题。

Optimus 的 AI 是怎么做的

Optimus 和 FSD 同源是 Tesla 反复强调的技术点，AI Day 2022 提到，机器人躯干里的计算机来自车端 FSD 计算机，软件栈也复用了车辆里的目标识别、occupancy network、室内导航和运动规划，也有第三方把 Optimus 描述成 8 个摄像头输入，输出到 78 个执行器的端到端系统。

Tesla 其实不是「单一端到端神经网络」，FSD 完整构建涉及 48 个网络，更准确的说法是，Tesla 是追求端到端可学习的统一系统，工程实现更可能是共享表示的多任务 multi-head 架构。

自动驾驶的动作空间其实不大，方向盘、油门、刹车这几样基本就说完了，但人形机器人是另一回事，Optimus 按 78 个执行器算，每一个时间步都得把身体、手臂、手指、平衡、接触一起兼顾到，杯子稍微滑一下，手指力、手腕、手臂轨迹、重心也需要同时跟着调整。

端到端路线能省掉模块之间一堆手写接口，让视觉、语言、空间和动作通过统一训练互相影响，但出了错很难定位，抓错零件时，是深度估计错了，物体语义错了，动作头错了，还是执行器跟踪失败？工程系统仍然需要日志、状态回放、安全控制器和可解释的中间信号。

把 Optimus 放到工程系统里，我会先拆成四个接口，这样更容易看清楚它难在哪。

这四个接口放到小机器狗上也能对上，只是尺度差很多。我的狗只有「语言到固定动作」和「动作到 PWM」，少了视觉到 3D 和接触状态。Optimus 的难点是四个接口都要同时成立，而且任何一层出错都可能被统一模型吞进黑盒里。

数据从哪来，量产难在哪

Tesla 的优势常被概括成车队数据，这里只说对一部分，车队数据能给 Optimus 带来视觉常识、空间理解、光照适应、动态物体预测和 occupancy 表示，但汽车并不处理杯子摩擦系数，也不用手指判断纸箱是否瘪了，其实现在机器人最缺的是真实物理世界的接触数据。按目前公开资料，Tesla 的 Optimus 数据主要来自这四类：

所以才有了人类操作员带着头盔和背包相机去现场采集这种做法。前段时间我还看到国内的具身智能公司和家政公司合作，让阿姨带着传感器和摄像头去打扫卫生，这类合作也是在补物理世界接触数据。

机器人数据比自动驾驶慢得多，车队能靠满街的车每天一起采，遥操作通常一人一次只教一台，真机自主采更慢，失败还会磨损硬件、打断产线、带来安全风险，所以这事才这么难，但我还是挺看好这个方向。

机器人公司之间的差距，会慢慢体现在样本、训练和硬件改动的速度上，谁能更便宜、更稳定地采到失败样本，再把它们带进下一轮训练和硬件改动，谁的能力迭代就拉得更开。

数据是一道坎，量产是另一道。

Tesla 每次财报电话会都会聊不少 Optimus，作为投资人，我一般会把他们讲的和当前真做到的分开辩证看，把 2024 到 2026 年的连续口径连起来，能看出一些持续的变化，也能看出每次难点在哪里。

比交付年份更难绕开的，是上面这些约束。人形机器人很难等模型训好再开产线，硬件、数据、制造通常一起推进。手部一改设计，前臂结构、线束、触觉传感器、控制器和供应链都要跟着动，执行器良率不稳，产能目标就会被最慢的零件给拖住。

从公开资料看，Tesla 赌的是三件事的组合，真实场景数据、制造规模和垂直整合。FSD 给它视觉和训练基础设施，工厂给它受控任务和反馈，制造体系给它降本路径，但手部可靠性、执行器成本、安全保护和真实工位 ROI 只要有一项卡住，这些优势也很难落到产品上。

后续 Optimus 的验证点会集中在几样东西上，手部结构的长期可靠性，失败样本回到训练和真机验证的速度，模型的可排错接口，产线目标背后的执行器和供应链支撑，公开资料里的 Tesla 路线如果成立，靠的是车队视觉经验、工厂任务、世界模拟器、训练集群和制造体系一起跑通。

几家公司的不同路线

现在做人形机器人的公司不少，路线和押的方向差别其实挺大。

这七家其实分两拨。一拨自己造整机，Tesla、Figure、宇树、智元都是从硬件到模型自己全包。另一拨不绑某一台机器人，Google DeepMind 做的是能接到不同本体上的智能层，NVIDIA 干脆把算力、仿真、世界模型和基础模型做成工具链卖给所有人。前一拨赌的是数据和制造能不能咬合，后一拨赌的是自己那层能不能跨机器人复用。

平台这条路听着省事，风险还是接口边界。上层指令太抽象下层接不住，下层失败说不清上层也没法重规划，跟前面 VLA 那章讲的问题很像。

其实也不是只有 VLA 一条路。Boston Dynamics 没有去蹭大模型叙事，靠电动 Atlas 和扎实的运动控制照样进工厂物流。工业现场看的是节拍、故障率和安全认证，而非演示效果好不好看。国内这边信号最实在的是价格和供应链速度，宇树 G1 官方起价 1.35 万美元，硬件基数能很快铺开，能不能做通用任务、能不能长期稳定还得持续来看。我那台小机器狗就停在最基础的固定动作层，这些路线对它来说都还太远。

这些路线背后是三种取舍。工厂场景普遍被当成第一站，因为环境可控、ROI 算得清、任务边界能限定。家庭场景最难，环境乱、用户容错低，还得做到安静、安全、隐私可控。平台公司则选择先卖工具链，因为大多数机器人公司本身就缺数据、仿真、边缘算力和训练框架。

从软件往具身智能走

如果你也是偏软件的工程师，想继续往下看具身智能，下面这些系统层知识绕不开。

• 嵌入式和实时系统：GPIO、PWM、I2C、UART、SPI、定时器、中断、RTOS
• 机器人运动学：坐标系、正逆运动学、Jacobian、末端位姿
• 控制基础：PID、MPC、状态估计、采样频率、延迟和稳定性
• 感知和 SLAM：相机模型、深度、IMU、LiDAR、外参、时间同步
• 模仿学习和强化学习：行为克隆、ACT、Diffusion Policy、reward、Sim2Real
• 数据工程：遥操作、episode 格式、视频和状态同步、标注、评估

放到一张图里，它是从芯片、执行器、传感器一路往上到算法和系统的一整个栈。单独看模型，很多问题根本看不出来；对着完整技术栈图看，每一块大概在哪一层会清楚很多。

资料串起来大概是这个顺序。先从小机器狗这类硬件项目入手，因为它们刚好能把「端云协同 + 本地动作」连起来。唤醒、联网、模型调用、能力描述、串口协议、动作执行、状态回传都能在一个小系统里遇到。项目不大，但每个环节都可能真实失败，一个个解决的过程，反而最有探索感。

端云协同和 MCP 跑过一遍后，再看 ACT / ALOHA，会更容易理解低成本遥操作和 action chunking；接着看 Diffusion Policy，动作为什么要建模成分布会更清楚；再到 RT-1、RT-2、Open X-Embodiment、OpenVLA 这条线，VLA 和跨具身数据就能接上；最后看 π0、π0.5、SmolVLA、Gemini Robotics、Helix、GR00T N1.5，产业界怎么把高层推理、低层动作和边缘部署拼到一起，也会落到更具体的问题上。

要我说具身智能的重点，就「感知、空间、动作、力矩」这四个词，大致也是难度从轻到重。感知 AI 已经够强，空间还在补课，动作刚学会一点，到力矩这一层，就要面对电机、结构、接触和供电这些实打实难做的东西。AI 越靠近物理世界，能靠模型解决的部分越少，剩下的更多是硬件的事。

参考文献

模型与算法

1. RT-1: Robotics Transformer for Real-World Control at Scale，Google Robotics, 2022。
2. RT-2: New model translates vision and language into action，Google DeepMind, 2023。
3. Diffusion Policy: Visuomotor Policy Learning via Action Diffusion，Columbia + MIT CSAIL, 2023。
4. Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware，ACT / ALOHA, 2023。
5. Open X-Embodiment，Google DeepMind + 33 institutions, 2023。
6. OpenVLA: An Open-Source Vision-Language-Action Model，Stanford + Physical Intelligence + Google DeepMind, 2024。
7. π0: A Vision-Language-Action Flow Model for General Robot Control，Physical Intelligence, 2024。
8. π0.5: a VLA with Open-World Generalization，Physical Intelligence, 2025。
9. SmolVLA: Efficient Vision-Language-Action Model trained on LeRobot Community Data，Hugging Face, 2025。
10. Gemini Robotics，Google DeepMind。
11. Gemini Robotics On-Device brings AI to local robotic devices，Google DeepMind, 2025。

产业、硬件与工具链

1. Helix: A Vision-Language-Action Model for Generalist Humanoid Control，Figure AI, 2025。
2. Introducing Helix 02: Full-Body Autonomy，Figure AI。
3. NVIDIA Jetson Thor，NVIDIA。
4. Cosmos World Foundation Model Platform for Physical AI，NVIDIA Research, 2025。
5. GR00T N1.5，NVIDIA GEAR。
6. LeRobot，Hugging Face。
7. SO-ARM100，SO-100 / SO-101 低成本机械臂硬件。
8. xiaozhi-esp32，开源 ESP32 AI 语音助手。
9. Genesis，开源物理仿真平台。
10. NVIDIA Isaac Lab，机器人学习框架。
11. Tesla AI Day 2022 transcript，Optimus 早期技术披露。
12. AI Training for Tesla Optimus Explained，Optimus AI 训练、数据来源和世界模拟器第三方整理。
13. Tesla Earnings Call Transcripts，2024 Q2 到 2025 Q3 财报电话会 Optimus 口径的公开 transcript 聚合入口。
14. The Pinless Finger: What Tesla Put Where the Hinge Should Be，Optimus Gen 3 手和前臂 WIPO 专利第三方拆解。
15. Unitree G1，宇树科技官方商城。

更多阅读

想接着看 AI 工程这一类，我之前几篇 X 长文可以按这个顺序读：

1. 你不知道的 Claude Code，架构、治理与工程实践
2. 你不知道的 Agent，原理、架构与工程实践
3. 你不知道的大模型训练，原理、路径与新实践
4. 你不知道的 AI Coding，非技术人的上手、场景与实战
5. 你不知道的 GEO，AI 可见性的原理、实践与取舍

初稿完成于 2026 年 5 月，6 月也在持续修订中，具身智能领域变化很快，部分数字和产品进展可能继续变化，发现错误欢迎指出。

2026-05-01 08:00:00

花一小时让 AI 找到你的内容

这几天有好几个小伙伴@我说，我的开源工具在他们问 AI 的时候被主动推荐了，啥也没做居然可以被收录，想着要不花一个小时把内容结构化整一整，应该会更好，于是整好以后，快速发了一个速记推，但是内容结构不清晰，想着大家很感兴趣，那要不就整一个结构清晰的文章便于沉淀和查找。

我很讨厌去刷排名或者生产垃圾内容，更多想着让现有的内容对 AI 更可见，所以这篇文章不会教你投机，而是如何让AI更好理解你现有的内容本身。

去查了一下，发现 AI 搜索跟传统搜索逻辑完全不一样，传统 SEO 拼的是进 Google 前 10，但 83% 的 AI Overview 引用来自排名前 10 之外的页面，AI 看的是结构清晰、来源可靠，跟 PageRank 关系不大。项目不大，但 README 和文档写得还算清楚，大站内容单薄的地方 AI 就能找到我，大概这就是为什么朋友们能搜到 Pake 和 MiaoYan。

AI 搜索增长很快，2025 年上半年同比涨了 527%，ChatGPT 到 2026 年 2 月周活 9 亿，引荐流量转化率大概是传统搜索的 5 倍。但目前仍然只占总引荐流量不到 1%，更像是品牌可见性策略，不是流量策略，值得花一个小时整一整，但不值得花一周，因为产品本身才是你的核心竞争力，这个不是。

用 robots.txt 分清爬虫类型

很多人把 robots.txt 当开关用，要么屏蔽 AI 爬虫要么全放开。但 AI 爬虫其实分好几类，做的事情不一样。

训练爬虫，GPTBot、ClaudeBot、Meta-ExternalAgent、CCBot，拿你的内容去训练模型。屏蔽它们可以让内容不进训练数据，但不影响当前的 AI 搜索结果。

搜索和检索爬虫，OAI-SearchBot、Claude-SearchBot、PerplexityBot，实时抓取内容来回答用户问题。屏蔽了这些，你就从 AI 搜索里消失了。

用户触发爬虫，ChatGPT-User、Claude-User、Perplexity-User、Google-Agent，只在用户把你的 URL 贴进聊天窗口时才触发。屏蔽了它们，用户让 AI “总结一下这个页面” 就会啥也拿不到。

退出标识，Google-Extended、Applebot-Extended，不是真正的爬虫，是你在 robots.txt 里声明退出 AI 训练的信号。

未声明爬虫，Bytespider、xAI 的 Grok 爬虫，不表明身份，也不一定遵守规则。

我的做法是允许搜索/检索爬虫和用户触发爬虫，屏蔽训练爬虫和未声明爬虫：

# Search & retrieval: allow
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# User-triggered: allow
User-agent: ChatGPT-User
Allow: /

User-agent: Claude-User
Allow: /

# Training: block
User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

# Opt-out tokens
User-agent: Google-Extended
Disallow: /

# Undeclared: block
User-agent: Bytespider
Disallow: /

写好 llms.txt 并让站点互相引用

llms.txt 是一个新标准，类似 robots.txt 但专门给 AI 看的。在站点根目录放一个 Markdown 格式的文件，写清楚你的站点做什么、有哪些关键页面、作者是谁，AI 在检索内容的时候会优先读这个文件来理解你的内容。

BuiltWith 追踪到目前已经有 84 万多个网站部署了 llms.txt，包括 Anthropic、Cloudflare、Stripe、Vercel 这些。但在 SE Ranking 调研的 30 万域名里采用率只有 10%，还是比较早期，先做了有先发优势。

格式很简单：

# Your Project Name

> One-line description of what this is.

## Links

- [Documentation](https://yoursite.com/docs)
- [GitHub](https://github.com/you/project)
- [Blog](https://yoursite.com/blog)

## About

Short paragraph explaining the project, its purpose, 
key features, and what makes it different.

做完之后可以提交到 directory.llmstxt.cloud、llmstxt.site，还有 GitHub 上的 llms-txt-hub 仓库提 PR。

这里我还做了一个有意思的事：各站点的 llms.txt 互相引用，形成一个网状结构。我维护着 tw93.fun、weekly.tw93.fun、yobi.tw93.fun 几个站点，每个站点的 llms.txt 都引用其他站点，AI 不管从哪个入口进来都能顺着链接找到其他内容。

这些改动需要等爬虫重新抓取才会生效，通常要几天。配好之后隔一段时间去 ChatGPT 搜一下自己的项目名，引用来源和描述准确度应该会有变化。

提供完整版内容和 Markdown 路由

llms.txt 是概要，llms-full.txt 是完整版，一个文件通常 30-60KB，包含项目描述、FAQ、使用场景、竞品对比、README 摘录。Mintlify 的 CDN 分析显示 llms-full.txt 的访问量是 llms.txt 的 3-4 倍，AI 系统找到概要之后会想要完整版。

Markdown 路由更进一步，Evil Martians 建议给站点的每个页面提供 .md 版本。一个 15000 token 的 HTML 页面变成 3000 token 的 Markdown 文档，减少 80%。

怎么告诉 AI 你有 Markdown 版本，最简单的方式是在页面 <head> 里加一行：

<link rel="alternate" type="text/markdown" href="/page.md" />

Claude Code 和 Cursor 在获取文档时已经会发 Accept: text/markdown header，这是 1997 年就有的 HTTP/1.1 标准行为。

去搜索平台录下你的站点

前面说的 robots.txt 和 llms.txt 是让 AI 读得懂你的内容，但前提是 AI 能找到你。ChatGPT 的搜索走 Bing，Google AI Overview 走 Google 自己的索引，Perplexity 也依赖搜索 API。如果你的页面没有被搜索引擎收录，后面做的结构化工作 AI 根本看不到。所以第一步是确保 Google 和 Bing 已经收录了你的站点。

操作很简单：去 Google Search Console 用 DNS 或 HTML 文件验证你的域名，验证通过后提交 sitemap URL（通常是 yoursite.com/sitemap.xml）。在”网页索引”报告里可以看到哪些页面已收录、哪些有问题。如果某个重要页面没被收录，用”网址检查”工具手动请求编入索引。

大伙可能觉得 Bing 没什么人用，但 Copilot、DuckDuckGo、Yahoo 的 AI 搜索底层都是 Bing 在驱动。去 Bing Webmaster Tools 注册一个号，提交 Sitemap，它有个 AI Performance 面板，能看到你的内容被 AI 引用了多少次。顺便设置一下 IndexNow，有新内容发布时主动通知 Bing，不用等爬虫来发现。

IndexNow 的接入方式是在站点根目录放一个 API key 文件，然后在内容更新时向 api.indexnow.org/indexnow 发一个 POST 请求，把变更的 URL 列表发过去，几分钟内 Bing 就会来抓取。很多静态站点生成器和 CMS 有 IndexNow 插件可以直接用。

Google Search Console 目前没有 AI 专属面板，但提交 Sitemap、监控索引状态还是值得做的。Google AI Overview 从比传统结果更广的范围里拉内容，即使你的页面排不进前 10 也可能出现在 AI 回答里。

Perplexity 在海外的用户量比大伙想的要大，他们有一个出版者计划，可以去 pplx.ai/publisher-program 提交表单，通过之后有收入分成 80/20，还能看到引用分析数据。

我做了一个专门给 AI 看的知识网页

与其等 AI 去各个站点零散地抓信息，不如给它一个集中的入口，把你希望它记住的东西整理好放在那里。

一个知识网页要提供三层内容：概览（llms.txt）、完整版（llms-full.txt，30-60KB）、和每个核心项目的独立知识页面。再加上结构化的 JSON API，让 AI 工具可以程序化地获取数据。数据不要写死，从 GitHub API 之类的上游实时拉取，加缓存定期刷新，维护成本最低。

还有一个容易忽略的点：给 AI 一个叙事结构，而不是一堆零散的项目列表。如果你有多个项目，写一段把它们串起来的描述，它们之间的关系、你的技术方向、整体定位。AI 在回答”这个人是谁”或者”这个团队做什么”的时候，有叙事比有列表有效得多。

我做的实现叫 Yobi（来自日语 呼び / よび，有呼唤、把人叫过来的动作感），提供 llms.txt 概览、50KB 的 llms-full.txt、独立项目页面，以及 /api/profile、/api/projects、/api/blog、/api/weekly 四个 JSON 端点，数据从 GitHub API 实时拉取，ISR 缓存一小时刷新。技术栈 Next.js + TypeScript，部署在 Vercel。

JSON API 返回的结构化数据，包含项目信息和实时 GitHub 统计：

给每个项目一个独立页面

每个项目需要自己的独立页面，不是放在列表里的一行，而是自包含的 Markdown 文档，有可引用摘要、核心特性、竞品对比、使用场景和安装命令。Ahrefs 的研究发现被引用页面的标题和用户查询的语义相似度更高，自然语言 URL slug（如 /projects/pake）的引用率也高于不透明 ID（如 /page?id=47）。

URL 结构很重要，/projects/pake 在模型读一行字之前就告诉它这个页面是关于什么的，/page?id=47 什么都没说。

把结构化数据同步到主域名

子域名的权重不如根域名。AI 爬虫发现了 example.com 不一定会自动去找 docs.example.com 或 api.example.com。如果你的 llms.txt、项目页面、API 数据分散在多个子域名上，AI 可能只看到其中一部分。

解决方法是把关键的结构化数据镜像到主域名上，让 example.com/llms.txt、example.com/projects/xxx.md、example.com/api/projects.json 都在同一个域名下。AI 爬虫通过搜索索引发现你的主站，然后在同一个域名里就能拿到所有数据。实现方式可以是 CI 定时同步、构建时拉取、或者反向代理，选最适合你部署架构的就行。我用的是 GitHub Action 每天凌晨把子站数据同步到博客仓库。

上线新站点时，按清单逐项配置可以避免遗漏。核心项：robots.txt（分类放行爬虫）、llms.txt（写清站点概要并互相引用）、sitemap（提交到搜索引擎）、Bing Webmaster Tools（开启 IndexNow）、Google Search Console（监控索引状态）。每个站点的 llms.txt 互相引用其他站点，形成网状发现结构。

做这件事最容易踩的坑是被各种 GEO 技巧带跑，什么都想加，最后导致很乱，本末倒置。

试了这些没用

<meta name="ai-content-url"> 和 <meta name="llms">，没有规范，没有任何主流 AI 系统支持。

/.well-known/ai.txt，多个竞争提案，没有实际采用，等出赢家再说。

HTML 注释里放 AI 提示，解析器在 AI 读到内容之前就把注释剥掉了。

User-Agent 嗅探返回 Markdown，给爬虫和人返回不同内容就是 cloaking，Google 会惩罚。

各种非官方的 AI meta 标签，除非某个主流 AI 提供商文档里明确支持，否则都是噪音。

JSON-LD 没你想的那么有用

这个我一开始以为是利器，后来深入研究发现更复杂。SearchVIU 做了个实验，把数据只放在 JSON-LD 里页面上不显示，结果五个 AI 系统全没读到。Mark Williams-Cook 的后续实验发现 LLM 就是把 <script type="application/ld+json"> 当普通文本在读，不理解结构化语义。

唯一确认有用的是 Bing/Copilot，走的是索引富化路径。已有的 JSON-LD 保留就好，但别指望加了它 ChatGPT 或 Claude 就会多引用你。

研究数据怎么说

Princeton 和 IIT Delhi 的 GEO 论文在 KDD 2024 上发表，发现加入权威引用提升 AI 可见性 115%，相关统计数据提升 33%，直接引用可信来源提升 43%。

朋友 @yaojingang 在非常专业地做 GEO 方向的研究，他的 geo-citation-lab 拿 602 条 prompt 跑了三个平台，抓了上万个页面做特征分析，有兴趣的可以去看他的完整报告，这里从他的数据里提几个对做内容最有用的规律。

具体性 写有真实数据、清晰定义、横向对比的页面，影响力比泛泛而谈的页面高出 50% 以上。有步骤结构的页面也明显更好。而纯 FAQ 格式反而有害，那些 GEO 工具让你”加 FAQ 提分”的建议，数据说它是反效果，这也验证了我前面删掉 FAQ 的判断。

内容长度 AI 不偏爱短摘要，它偏爱可以切出多个可复用片段的长内容。被高频引用的页面平均近 2000 词、10 个以上标题，低影响力页面只有 170 词，差距超过 10 倍。最稳妥的区间是 1000-3000 词。

相关性 所有机械 SEO 指标（H 标签层级、meta description、关键词密度）的预测力都不如一个变量：你的页面内容跟用户问的问题是不是同一件事。

平台差异 ChatGPT 引用少但用得深，单条引用影响力是 Google 的 5 倍多；Perplexity 广撒网，引用量是 ChatGPT 的两倍多。想被 ChatGPT 引用就把单页写深写透，想被 Perplexity 引用就覆盖面广。

内容类型 官网 + 新闻 + 行业垂类占了引用来源的八成。但百科型/解释型页面的影响力是新闻页面的 3 倍。英文内容在全球引用样本里占 83% 以上，面向国际用户的项目必须做英文版。

被检索到不等于被引用

ChatGPT 检索到的页面里只有 15% 最终出现在回答中，85% 从未被引用。进入检索池只是第一关，模型还要判断哪些值得引用。

Ahrefs 发现被引用页面的标题和用户查询的语义相似度明显更高，有描述性自然语言 URL slug 的页面引用率也高于不透明 ID。llms.txt 和 Markdown 路由有效就是因为给了模型一个干净、明确的信号，说明这个页面到底讲了什么。

品牌被第三方来源引用的概率是被自己域名引用的 6.5 倍，别人在 Reddit、Hacker News 上说你好比你自己说自己好有效得多。所以自己有一个结构化的 llms.txt 很重要，它给模型提供了一个可以引用的锚点，即使触发查询的对话发生在 Reddit 上。

市面上有各种 AI SEO 审计工具会给你的站点打分，告诉你缺 FAQ、缺信任页面、正文太短。别被分数带着走。判断标准很简单：你加的每一段内容，是否提供了页面上还没有的信息？不是就别加。我给 Yobi 加过一个 FAQ section，内容跟 About 段落说的完全是同一件事，纯粹是为了把分数刷上去，后来想想这就是注水，删了。

做的事情都是帮 AI 更准确地理解你有什么，给它一个干净的工作环境，这个方向比短期技巧走得更远。

基础配置大概一个小时，知识端点和项目知识页面要更久一些，但一旦数据结构搭好就很容易维护，每天的同步是自动跑的。

做完之后隔几天去 ChatGPT、Perplexity、Claude 里搜自己的名字或者项目名试试，引用源应该会变准确。

AI 的引用归因目前还不靠谱，CJR 和 Tow Center 测试了 200 条 AI 生成的引用，发现 153 条有部分或完全错误。做结构化的工作是因为它让你的内容更容易被准确获取，但别把 AI 引用当成用户一定看到了你原话的证明，这个机制还在改进中。

假如你也有自己的产品、博客或者官网，不妨试试看，玩玩这个过程，当然也可以把这篇文章给你的 Claude Code，让他帮你做大部分事情。

延伸阅读

1. GEO: Generative Engine Optimization - Princeton & IIT Delhi, KDD 2024
2. Overseas GEO Research - geo-citation-lab
3. llms.txt 标准规范
4. Why ChatGPT Cites One Page Over Another - Ahrefs
5. GEO Benchmark Study 2026 - ConvertMate
6. Optimizing Content for AI Discovery - Evil Martians
7. How LLMs Actually Use Schema Markup - SearchVIU
8. AI Search Has a Citation Problem - CJR / Tow Center
9. LLMs.txt: Why Brands Rely On It and Why It Doesn’t Work - SE Ranking
10. How Often Do LLMs Visit llms.txt? - Mintlify
11. IndexNow Protocol Documentation

2026-04-26 08:00:00

太长不读

上个月在公司里给产品和业务的小伙伴分享了下如何上手 AI Coding，加上最近又发了条推特，聊到不少同学因为订阅门槛没机会用上一线 AI Coding 工具，方法和习惯不花钱就能先学，索性把上手这部分整理出来。不少人用 Claude Code 其实是卡在使用命令行的第一步，看到只有字符的终端会觉得是给程序员用的，自己肯定搞不定。其实门槛没想象的高，会用豆包这类对话框 AI 的人花点时间也能上手，剩下的就是慢慢习惯把执行权交给它。

等你用顺手后会发现它像个什么活都接的能干助手，跑后台数据、写解决你问题的小工具、把乱七八糟的文档拼成简报、做原型、整理销售报表都能干。之前会不会写代码不是关键，等你有意识把项目背景写进 CLAUDE.md、把需求写得足够精确、会去想着沉淀几个 Skill 把重复动作打包，那你其实就称得上入门了，这篇文章主要是想带非技术同学也用上我最爱的 Claude Code。

第一道坎是命令行

不写代码的同学习惯了豆包这类对话框 AI，第一次装 Claude Code 都会有点不适应。以前是个来回搬运的过程，你描述需求、它生成代码、你复制粘贴到别处去试，现在变成 Claude Code 直接在终端运行，搬运这一步省掉了。

如果你没用过终端，推荐我做的 Kaku，它是专门为 AI Coding 做的终端，装好就能用，不用折腾配色和字体。深色浅色跟着系统走，分屏按 Cmd + D，文件管理器按 Cmd + Shift + Y 直接显示出来。对刚上手的人最友好的是内置了 AI 辅助：命令跑报错了会自动给修复建议，记不住命令在前面加个 # 写中文也能生成。

安装 Claude Code 也只需一条命令，详见 官方文档，然后进项目文件夹输入 claude 就能开始 Coding 了。

curl -fsSL https://claude.ai/install.sh | bash

顺便补点技术通识

不写代码的同学想真把 Claude Code 用好，光会描述需求还不够，懂一点基础概念，后面排错会轻松很多。

常用框架是干嘛的，知道 React、Vue、Next.js 大概在解决什么问题，看 Claude Code 写出来的东西就不会一头雾水。

常用软件的基础，终端命令、Git、VS Code、Chrome 开发者工具，跑出错的时候你能跟着它一起定位，而不是只能干等。

编程的几个核心思想，函数是干什么的、变量和状态是什么、为什么要拆成多个文件，懂了这些需求才写得精确。

学会读代码和读报错，比自己会写代码更早派上用场。它改完一段你能扫一眼大概在干嘛，比让它从头解释一遍快得多。报错也别一看就慌，整段复制丢回去问”这是什么意思、要怎么改”，十次有九次能告诉你具体哪一行出问题。

不用学到能自己写代码的程度，知道这些东西长什么样就够了。花一两个晚上把 freeCodeCamp 或者 MDN 的入门篇过一遍，或者去 B 站挑一套入门课粗看一遍，计算机科学速成课、哈佛 CS50 都不错，后面跟 Claude Code 协作的效率会很不一样。

我挺推荐这三本对非工程师最有用的入门易读书：《启示录》 看产品判断、《Linux/Unix 设计思想》 看工程哲学、《左耳听风》 看一个我怀念的左耳朵耗子攒下来的程序员专家视野，读完跟 AI 聊技术细节会少懵很多。

准备工作：账号与订阅

账号：在 claude.ai 用 Gmail 注册，流程最标准，注册前尽量用美国 IP 稳定的网络环境，别频繁切换出口，不然新账号容易触发风控；同时新账号不要直接包 Max，也容易被封号。

订阅：分三档。Free 是 $0，只能体验基础对话，不含 Claude Code；Pro $20/月，解锁 Claude Code，入门首选；Max 有 $100 和 $200 两档，分别对应 5x 和 20x 用量，适合重度使用、高强度跑代码。

最简单的方式是走美区 App Store 内购，Android 走 Google Play 也行，进 Claude App 选 Pro 用余额订阅就行，注意走 App Store 有税费，$100 档会显示成 $125，多 25 买一个安心，不过很建议先 Pro 起步，配额不够再升 Max。订阅状态跟账号走，iOS 订完之后在 Android 或网页登录都正常用。

账号没了所有事都得重来，甚至还有可能持续被封，订前几件事注意一下。网络环境用稳定低延迟的别天天换，账号一号一人别合租也别和别人共用，付款方式选靠谱的实体卡，虚拟卡尤其是币圈渠道充值的容易秒封。邮箱用老 Gmail 别用新注册的 Outlook，出口尽量保持干净别让其他乱七八糟的 App 流量都从同一个口子出去。

Claude Code 适合什么样的活

我自己用过的 AI Coding 工具不少，Cursor、Windsurf 都试过一圈，Codex 平时也会用，主力还是 Claude Code。

它最不一样的地方是模型能力本身就很不错，加上 Claude Code 自己的代码实现也把 Harness 这一套玩到了极致——整个项目一起看：先扫一遍 CLAUDE.md 和目录结构摸清楚上下文，然后跨文件改代码、跑命令、看报错、再改，自己全部完成。再加上它本来就活在终端里，git、测试、脚本这些你日常用的工具它都能直接调起来，不用来回复制粘贴。

它实际更像个通用 Agent，叫 Code 只是因为最初定位偏写代码。Anthropic 自己分享过他们内部不少非工程团队比如销售、风控、财务都在拿它干活，处理 CRM 数据和客户邮件。如果你实在不想碰终端，可以用官方出的桌面应用 Cowork，能直接读写你的下载和文档目录，把收据截图拼成报销表这种活，你说一句话它也能给你干好。

还有一点我感觉很重要：写代码这件事上，模型快不快不重要，准不准才重要。它 10 分钟跑完然后你花 20 分钟 debug，远不如它 20 分钟跑完直接能验收来得舒服。

要让它准，前提是你给到的活本身就目标清楚、结果好验收，两个都满足的最适合交给它，好比把活交给了一个非常直男但是技术非常厉害的程序员。

具体就这几类活：做原型和内部小工具，把需求和展示逻辑说清楚，第二天就能跑起来一版；处理 CSV、做销售报表，分组和计算逻辑写明白几分钟出结果；几十页合同提炼条款、对比版本差异这种文档活它最擅长；最后是给一堆链接或 PDF 让它从特定视角提炼信息，说清格式就行。

做一个只给你一个人用的软件

最阻碍新人写代码的第一步是不知道自己要做个啥。《纽约时报》专栏作家 Kevin Roose 提过一个概念叫 software for one：你不需要做给一百万人用的 App，可以做只给你一个人用的软件。

他给自己做过整理链接的 Stash，给孩子准备便当的 LunchBox Buddy。对你来说，可能是把语音批注转成会议纪要的工具，或者是每天提醒你三件事的小仪表盘。这种东西反而是产品和业务的同学最容易做成，毕竟只有你最懂自己每天的麻烦在哪。

一天到三个月的节奏

别一上来就想做个“像 Notion 那样的产品”，可以按下面这个节奏来，每一段都有摸得到的产出：

第 1 天先试水，让它改一个你手头现成的 Excel 或 Markdown 文档；第 1 周尝鲜，做一个单页个人主页或日报大盘 15 分钟就能跑起来；第 1 个月提效，挑一件每周重复做两三次的事变成一条命令或一个页面；第 3 个月进阶，选一个”software for one”的想法做一个只给自己用的小工具。

用 OpenCLI 把网页操作变成命令

很多运营日常是在浏览器里点点点：查后台、发消息、导报表。这些活其实能绕开界面，直接调背后的接口来做。

OpenCLI 是我朋友卡比做的，它内置了小红书、知乎、Twitter/X、Bilibili 等几十个站点的 CLI 适配器，再加上一组通用的浏览器操作原语像点击、输入、抓取、截图。把网页动作变成一条命令，Claude Code 一句话就能调起来。

小红书调研，让 Claude Code 调 opencli xiaohongshu 抓数据，再做分类和热词提炼，原本浏览器里点半天的事一句话搞定。

舆情汇总，把 Twitter/X、Reddit、HackerNews 几个适配器组合起来，同一关键词在多个平台的讨论自动拼成一份日报。

没适配的网站，用浏览器原语命令描述一遍流程，比如开页面、输关键词、抓表格，Claude Code 自己拼出来。

Claude Code 还有个 Routines 功能，能把一段工作流存到云端，按定时、Webhook 或 GitHub 事件自动触发。我自己还没怎么深用，概念上像「周一早上自动跑一遍周报流程」这种事它能接管，感兴趣可以看官方文档。

CLAUDE.md：先把项目背景写清楚

很多人装好之后直接开问，结果每次都要重复交代背景，用一会就觉得很烦。原因几乎都一样：没建 CLAUDE.md。

它放在项目根目录，Claude Code 每次启动都会先读它，相当于你给新来的同事写的项目交接文档，区别是它每次都会从头认真读一遍而且严格执行。

写得好不好，三件事最关键。写得短一点，150 行以内为佳，写太长会挤压后续对话的空间。语气直接，用命令式，别写”我们团队比较喜欢”这种软话，”所有注释用中文”比”团队偏好中文注释”有效太多。每条都能判断，”代码质量要高”没用，”函数超过 50 行必须拆分”才能落地。

四条最值钱的规则，直接拿去用：先问清楚再动手、简单优先、只动该动的、做完要验证。展开就是：别让它猜你的意图，目标说清再写；能两行解决的不写两百行，拒绝过度设计；不要顺手重构没让它改的代码；跑通构建和测试才算完，没通过别说完成。

下面这份模板，你改一改项目背景就能直接用：

# 项目背景
这是一个面向运营同学的客户看板，技术栈 Node.js + Next.js，
前端用 React，数据库 PostgreSQL，部署在 Vercel。
产品经理是 Alice，设计是 Bob，后端是我自己。

# 工作规范
- 所有注释用中文，变量函数用英文。
- 改动前先说明你打算改什么，确认后再动手。
- 新功能先写实现，不主动加测试，除非我明确要求。
- 数据库表名用下划线分隔，比如 user_profile。

# 禁止项
- 不要主动重构我没提到的文件。
- 不要删除任何文件，除非我明确说删掉。
- 不要在没确认前直接执行 npm install 装新依赖。

# 压缩时保留
长对话被自动压缩时，按优先级保留：
1. 架构决策和它背后的理由
2. 改过哪些文件、改了什么
3. 当前进展状态
4. 还没做完的 TODO

最后这段”压缩时保留”看着不起眼，长会话能不能稳就靠它。Claude Code 的上下文用到一定程度会自动压缩，决策的理由通常是第一个被丢的。比如你之前说过”这里要用 POST 不用 GET，因为数据量大”，压缩之后可能只剩”用 POST”三个字，理由没了。下次再问相关问题，它可能给你一个完全不同的方案，前后矛盾。把这一段写进去，长会话就不会前后打架。

上面这些不一定要自己从头写。装好 Claude Code 之后，直接说”读一下我这个项目，帮我生成一份 CLAUDE.md”，它会扫一遍代码、技术栈、目录结构，给你一份草稿，你只要改一改人名和团队偏好。装依赖、配 alias、改 ~/.claude/settings.json 这些事也一样，告诉它要什么效果让它自己去试，比你查文档快得多。配置类的活能交就交，省下来的精力放到真正要判断的事情上。

需求描述越精确，它越少分叉跑偏

模糊版：帮我做一个客户跟进工具。 精确版：帮我做个销售用的跟进工具，单文件网页存本地。左边列表显示公司名、下次跟进时间、状态，右边详情包括沟通记录、日期、要点。顶部加三个筛选：状态、时间、关键词。数据存浏览器 localStorage，不调后端。

精确版当天就能跑出能用的版本，模糊版多半要返工。

再看一个完整精确版的样子，这是 yetone 给 Claude Code 写的 macOS 语音输入工具需求。代码细节看不懂没事，重点是看每条要求被拆得多具体。

帮我做一个 macOS 原生语音输入工具，用 Swift 开发：

1. 按住 Fn 键开始录音，松开后把转录文字注入当前光标所在的输入框。
   优先用流式转录（Apple Speech Recognition framework）。
   Fn 键通过 CGEvent tap 全局监听，需抑制 Fn 事件传递，
   避免触发 emoji 选择器。

2. 默认语言必须为简体中文（zh-CN），开箱即用就能识别中文。
   菜单栏可切换英文、繁中、日语、韩语，选项存到 UserDefaults。

3. 录音时屏幕底部居中显示一个无边框胶囊状悬浮窗：
   不要红绿灯和 titlebar，用 NSPanel（nonactivatingPanel）+
   NSVisualEffectView（.hudWindow 材质）。
   高度 56px，圆角 28px，左侧实时音频波形（5 根竖条，
   由 RMS 电平驱动），右侧转录文字（160-560px 弹性宽度）。
   入场弹簧动画 0.35s，文字宽度过渡 0.25s，退场缩放动画 0.22s。

4. 文字注入用剪贴板 + 模拟 Cmd+V。注入前检测当前输入法：
   如果是 CJK 输入法，先临时切到 ABC 键盘再粘贴，完成后恢复原输入法。
   注入完恢复原剪贴板内容。

5. 接入 LLM 提升识别准确率，处理中英文混杂场景。
   通过 OpenAI 兼容 API（可配置 Base URL、Key、Model）对转录文本做 refine。
   system prompt 要求极保守：只修复明显的语音识别错误
   （如"配森"→"Python"、"杰森"→"JSON"），
   绝不改写或润色看起来正确的内容，正确就原样返回。

6. 菜单栏提供 LLM Refinement 子菜单，含启用/禁用开关和 Settings 入口。
   Settings 窗口有 API Base URL、API Key、Model 输入框，含 Test 和 Save。
   松开 Fn 键后如果 LLM 已启用，悬浮窗显示 Refining... 状态，
   等返回后再注入。

7. 应用以 LSUIElement 模式运行（仅菜单栏图标，无 Dock 图标）。
   用 Swift Package Manager 构建，提供 Makefile（build/run/install/clean）。

这种描述，Claude Code 几乎不用猜，直接产出一个能装的 macOS 应用。每一条都是在防它猜错一个具体的点：

你不需要会写 Swift，但需要把需求写得这么细。这份需求里每一条背后，都是 yetone 自己踩过的坑或者预想到的坑。每多一条具体细节，就少一次返工。

业务场景的需求，光描述功能还不够。开头先把问题写清楚，要解决什么、给谁用、怎么算做对了，别一上来就列功能清单。比如说我们要写一个国际门票频道页时，第一句话就是”国际门票目前没有独立入口，用户只能搜索找到，非热门城市曝光极低”，这两句话决定了它后面碰到”热门城市展示几个”“筛选要不要做’最近浏览’“这类问题时的判断方向。

接下来要给它划范围。Claude Code 很积极，你说做一个列表页它顺手就给你加上收藏、分享、埋点。明确写出”不做登录态、不做分享、不做 SEO，下一期再说”，它就不会越界。异常情况要单独列出来，接口超时怎么办、数据为空展示什么、图片挂了用什么兜底，这些不写它要么不处理，要么猜个你不满意的方案。

验收标准必须给数字，”页面要快”没用，”首屏 1.5 秒内”才能判断；”布局正常”没用，”在 375 和 1440 两个宽度下不错位”才能验收。

写需求的时候，别用”待定”“后续再看”“TBD”。Claude Code 碰到这些会自己猜着填，猜的往往不是你要的。哪怕写”这一版先硬编码，下版再做配置化”，也比空着强。

复杂任务先对答案：Plan 与 Auto 模式

有次我让它重构登录模块，它顺手删了一个我后面要用的工具类，回滚花了半小时，印象很深。

从那以后，复杂一点的任务我都会先按两次 Shift+Tab 切到 Plan 模式。它会先把打算怎么做列出来，方向对了你再让它执行。其实就跟工作场景一样：你不会直接让小李把功能做掉，先拉个会过下方案，觉得 OK 了再动手。

Plan 模式产出的计划大概长这样：要改哪几个文件、每个文件改什么、改的理由是什么、预计会影响哪些地方。用业务逻辑来判断这个方向对不对，比判断代码本身容易得多。哪怕你看不懂代码，也能从”这一步要不要做、那一处理由对不对”把关。

如果你嫌每步都问太烦，可以开 Auto 模式，按 Shift+Tab 循环切到 auto 那一档，目前 Max、Team、Enterprise 都能用，Pro 暂时还没开。它会自己判断：读文件这种安全操作直接跑，改数据库、删文件这类风险操作才来问你。刚上手默认开它就行，既不会被无意义的确认打断，也不会让它瞎搞。

怎么确认它真的做对了

它跟你说”搞定了”其实没用，关键是你怎么验收，因为它也会用最省事的方式交差。

我自己就看三件事。命令过没过，构建和测试跑完绿灯就行，CLAUDE.md 里写好”完成后跑 make build && make lint“它会自己做。眼见为实，页面打开看一眼、数字对一下、关键流程试一下，改完文件不代表页面就是你要的样子。对照清单，需求里写好的验收标准一条一条过，没对完不算完成让它接着改。

改坏了怎么救回来

不会写代码的人最怕代码被改乱了找不回来，常用的就两条。

Git 快照，每次大改前让它先跑一遍 git status 看清楚都有什么，确认没问题再让它 commit 一个检查点。改坏了直接说”按刚才的检查点回退”，比自己手动 checkout 安全得多。

撤销上一步，直接对它说”撤销刚才所有改动”，或者按 /rewind 回到上一个状态。

别让它陷入改了试试的死循环

有个坑很容易踩：陷入改了试试的循环，4-5 轮下来本来不大的问题变成一团乱麻。原因就一个，没诊断清楚就开始打补丁。

避免方法也一句话：根因没说清楚之前先别动代码。让它先答”问题出在哪个文件的哪一行，为什么会这样”，答含糊继续查，答清楚再改。一上来说”我试试改 X 看行不行”的，直接喊停让它先答根因。

Max 进阶：alias、模型、长会话

刚上手不必看，等用熟了或者你感觉 Pro 完全不够用的时候，再来翻这个都行。

我自己 Max 订阅怎么用

alias，我在 .zshrc 里加了一行，按 c 就直接启动一个不再问我权限的 Claude Code，同时把自动压缩点提前到 400k，等到上下文塞满才压效果会差，提前一点反而更舒服，你可以把这一段复制给你的 Claude Code 让它帮你来优化：

alias c='CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude --dangerously-skip-permissions'

--dangerously-skip-permissions 不建议刚上手的人用，它字面意思就是”危险跳过所有权限确认”，意味着 Claude Code 不会再问你任何事。我自己用是因为我能看懂它每一步在做什么，加上确实嫌反复确认烦。如果你还没到这个程度，老老实实用 Auto 模式就好。

模型用 opusplan，我现在这套用法是输入 /model opusplan 这个隐藏命令就开启（这类命令以后可能会变，以你当前版本能跑通的为准）。规划交给 Opus，执行交给 Sonnet，整体省钱也省时间。想更快可以再跑 /fast，刚好补回上面省下来的 token。

关键配置，如果你当前版本支持，用 opusplan 时去 ~/.claude/settings.json 里把 showClearContextOnPlanAccept 设成 true，不然会在 Sonnet 这一段碰到严重的缓存未命中，速度会明显慢下来。这个设置一开，整体就好多了。

长会话怎么办

Claude Code 的上下文容量是固定的，跑久了早期内容会被挤出去。

任务做完就 /clear，一个会话只做一件事，做完清掉再开下一件，两件不相干的事在同一个上下文里来回切，它会越做越乱。

长任务结束前让它写交接笔记，直接对它说：”把当前进度写成一份 HANDOFF.md，包括做了什么、试过什么没成功、下一步该做什么。” 第二天打开新会话，把这个文件给它，就能接着干，不依赖任何压缩算法。

Waza：把好习惯沉淀成肌肉记忆

AI 可以让明确写代码的活做得很快，但事情本身要做成什么样子其实需要你自己来定。我最近折腾了一套叫 Waza 的 Skill，一共 8 个技能对应一个好工程师该有的 8 个习惯。

/think 是动手前先想一下技术方案，AI 写代码很快，但方向错了越快越远，先质疑问题本身、把方案都思考好后，再让它跑。/design 是帮你设计一个产品化的页面，拒绝那种蓝紫渐变 + 一堆 emoji 的 AI 模板感。/hunt 是排查问题的，原则只有一条：根因没说清楚之前先别动代码，避免改了试试的死循环。/check 是收工前的最后一关，diff 审一遍，能自动修的修掉，吃不准的归拢起来再问你。

剩下四个偏日常：/read 把任意网页或 PDF 转成干净的 Markdown 进工作流，/write 让你的表达更清晰，/learn 是一套从收资料到出文章的研究流程，/health 给你的 CLAUDE.md 和各种规则做个体检，你感觉 Claude 不好用的时候运行一下试试。

安装：npx skills add tw93/Waza -g。其中我最建议产品、业务、运营先试的是 /design，截图丢给它带上 /design，它不会立刻动手，会先反问你给谁用、想要什么气质、最不喜欢哪种风格、有没有想让用户记住的微交互，回答完再动手，效果通常比直接说”帮我改一下样式”稳定。

你也可以自己写一个 Skill

Skill 本质就是一个文件夹，放在 .claude/skills/ 目录下，里面有个 SKILL.md 写清楚什么时候用、要做什么。Claude Code 启动时只读 frontmatter，也就是描述触发条件的约 100 个字，真正调用时才加载完整内容，所以你装几十个 Skill 启动也不会变慢。

日常我用得最多的有三种类型：

第一种是工作流型：把每次都要做的固定步骤打包。比如整理周会纪要：

---
name: 整理周会
description: 开完会有原始记录需要整理时调用
---

## 输出格式
**本周达成**：[负责人] 完成了什么
**下周计划**：[负责人] 做什么，截止时间
**待讨论**：卡在哪里，需要谁来决定
**行动项**：[谁] [做什么] [什么时候]

## 规则
- 不润色，保持原始措辞
- 信息缺失就标注"待确认"，不要猜

第二种是检查清单型：上线前、发版前、提交前过一遍，避免漏项。比如需求上线检查：

---
name: 需求上线检查
description: 需求发布前跑一遍，确认没有遗漏
---

## 上线前必须全部通过
- [ ] PRD 里的验收标准逐条确认
- [ ] 设计稿和实现对齐，间距、文案、交互没漏
- [ ] 异常状态（空态、报错、超时）都有处理
- [ ] 数据埋点按规范打好
- [ ] 测试环境验证通过

## 输出
每项 Pass / Fail，有 Fail 必须修完再发布。

第三种是领域专家型：把判断框架沉淀进去，碰到这类问题按固定路径走，不让它每次自由发挥。比如线上问题排查，以及你们平时业务最佳实践的 SOP：

---
name: 线上问题排查
description: 收到线上告警或用户反馈异常时调用
---

## 收集信息
- 报错截图或错误日志的完整内容
- 影响范围：哪些用户、哪个页面、什么时间开始
- 最近的变更：代码发布、配置修改、数据变更

## 判断矩阵
| 现象     | 优先检查                     |
| -------- | ---------------------------- |
| 页面白屏 | JS 报错 → 最近发布记录       |
| 接口超时 | 服务监控 → 数据库慢查询      |
| 数据异常 | 最近数据变更 → 上下游依赖    |

## 输出格式
根因 / 影响范围 / 修复步骤 / 验证方式

写好之后，把它放到 .claude/skills/ 文件夹下，碰到对应场景说一句”用整理周会”或”用线上排查”就行，这里你也可以让 Claude 帮你写。此外两个写 Skill 的小坑要避一下。

description 写触发条件，不写功能介绍，”开完会有原始记录需要整理时调用”比”把会议录音整理成结构化周报”准确率高得多。

一个 Skill 只做一件事，别把审查、发布、调试塞在一起，拆开用起来才更准。

Kami：让 AI 帮你排版出专业文档

写完内容只是第一步，排版成能发出去的东西往往更耗时间。Kami 也是我最近做的 AI 排版设计工具，你把内容丢给它，说一句”帮我排成一页纸”或”做个作品集”，它会生成一份可下载的 PDF。

它有 8 套模板：一页纸、作品集、幻灯片、Resume、长文档、信件、研报、Changelog。风格统一，暖底色、墨蓝色点缀、衬线字体为主。中文用苍耳今楷，英文用 Charter，不需要自己调字体。

最实用的几个场景：会议纪要排成简报、项目进展排成一页纸给老板、个人经历排成简历。以前这些活得开 Word 或 Figma 折腾半天，现在把内容丢进去，先出一版能看的稿子，再微调。

安装：npx skills add tw93/Kami -g

Claude Design：不写代码也能出原型

2026 年 4 月 Anthropic 官方推出的 Claude Design 是另一条路：你上传截图或文档，它直接给你个能交互的原型、幻灯片或落地页，对想快速做原型的非技术同学挺好用。

还不想碰代码的话，用它先出个能展示的想法准没错。产品经理可以用它画原型开评审，过了直接把原型扔给 Claude Code 变代码。早期原型不用等完整设计和研发排期，当天就能拿出来讨论。

用熟之后的几个小习惯

截图比文字快，要描述一个界面问题或者想参考某个设计风格，直接丢图比写一段话准多了，布局、颜色、层级都带进来了，让它少猜。

任务拆小一件件来，一句话能讲清楚的任务它几乎不会出错。一上来给一大坨需求，它中间任意一步走偏后面就全偏了，一件做完验收一件再开下一件。

对话跑偏了就重启，在已经跑偏的对话里来回纠正它越纠越乱，清掉上下文重说一遍需求往往更快。第二天接着干，先翻一眼上次的 Recap（/clear 后会自动生成的会话摘要）想起来干到哪了。

Memory 跨项目记住你的偏好，CLAUDE.md 是项目级的每个项目都得单独写一份，Memory 是用户级的跨所有项目和会话都生效。直接对它说”记住我喜欢先看方案再执行”、”记住回我中文”，它会写进 ~/.claude/memory/，以后任何项目打开都记得。常交代的背景信息都可以沉淀进去，省得每次重复说。

双击 ESC 改上一条，说错了或者它跑偏了，按两下 ESC 就能回到上一条消息修改，不用重开会话。

我自己的几条安全习惯

让它先解释再动手，在 CLAUDE.md 里加一条：”每次执行 Bash 命令或修改文件前，先用一句话解释要做什么。” 它就会在每步操作前先告诉你它打算干嘛，看不懂代码没关系，看得懂”我要删掉这个文件”就够了。

看不懂的命令先问，它要跑一条你没见过的命令别直接放行，先问它”这条命令具体做了什么、有什么风险”，看懂了再点确认。不要复制任何你不懂的命令去执行，里面可能夹带下载、上传或泄露信息的操作。

生产环境不要拿来练手，本地和测试环境随便折腾，但涉及生产数据库、线上配置的操作一定先在测试环境验证。一条写错的 SQL 或一次误删，回滚成本远高于你预期。

密钥别直接粘到对话里，要配置 API Key、数据库密码这类东西，让它放到环境变量或者 .env 文件里，不要直接把明文贴到聊天窗口。

还有一条容易被忽略但很要紧：能跑不代表安全，AI 生成的代码可能有漏洞，涉及登录、支付和个人信息的功能，能用 Clerk 或 Stripe 这种现成服务就别让它从零写。

延伸阅读

1. 你不知道的 Claude Code：架构、治理与工程实践
2. 你不知道的 Agent：原理、架构与工程实践
3. 你不知道的大模型训练：原理、路径与新实践
4. Claude Code Best Practices - Anthropic 官方
5. vibe coding - Andrej Karpathy 原始推文
6. Claude Skills are awesome, maybe a bigger deal than MCP - Simon Willison
7. Malleable software in the age of LLMs - Geoffrey Litt
8. Claude Code Skills 完全指南 - Datawhale Easy Vibe
9. Claude Code Starter Pack: Tools, Tutorials & Resources - AI Edge
10. When the Vibes Are Off: The Security Risks of AI-Generated Code - Lawfare

2026-04-06 08:00:00

想和大伙聊聊，在 AI 时代我是怎么深入学习一个技术领域的。没有 AI 之前，更多是看书、翻这个领域国内外有名的人的博客，然后摘抄记录到笔记本，速度挺慢，但很有学习的乐趣。比如当时学 WebGL，学懂一个东西差不多要半年空闲时间，慢但快乐。

有了 AI 之后，我还是很讨厌网上那种「3 分钟教你看完百年孤独」，也不喜欢短剧和倍速看剧的方式，更多还是挑好的看，宁愿慢一点、真正搞懂，也不愿意刷一堆摘要最后脑子里什么都没剩。

不过最近写「你不知道的 Claude Code」和 Agent 系列，除了自己懂的部分，还有大量不太清楚的领域。好在之前收藏了不少相关资料，刚好借这个机会清库存，全部搞懂再输出出去。一直觉得，看了多少、听了多少、输入了多少，其实不是最重要的，更在乎你能输出多少，能清楚说出来、写下来、整理发布的，才真的是你自己的。

前不久给自己挖了个深坑，研究大模型的训练流程，目标是确保非专业的人也能听懂，探索了两周。这个经历刚好可以分享出来，成文也差不多了，很快会发出。

我会把整个学习过程当做写代码一样组织起来。收集高质量资料是第一步：近几年的精品论文、各大模型厂商发布的关键技术博客、X 上模型负责人写的文章、斯坦福等高校近两年的相关课程，还有经典的手搓大模型代码仓库，这些都是我的资料来源。然后借助工具自动化完成下载、转 Markdown、清洗、整理，按分类放进这次研究专用的仓库，在正式开始读之前，先把整个信息环境弄干净。

接下来开始读和筛选。自己看得懂的内容，认真读一遍，觉得价值不大的就删掉，好的留下。看不懂的，直接让 Claude 帮我理解，更复杂的翻译成中文再读。代码能本地跑的就跑起来，不能跑的就看结构，理解核心思路。这个阶段我不追求完全掌握每个细节，只要对这个领域有真实的认知、摸清楚技术原理就够了。通常到这里，原来一半的内容都会被删掉，这是正常的，筛选本来就是学习的一部分，留下对的东西比读更多更重要。

到了这个阶段，对这个领域大概有认知了，就可以开始给文章写大纲，想清楚要讲什么、每个部分对应的资料来源、内容的顺序，以及读者读完之后应该得到什么。文章是写给别人看的，需要知道对方的认知水平，哪里会卡住，需要什么程度的解释，这和做汇报差不多，始终在想受众是谁。

然后就是苦力活了，和大学考试前复习很像，逐节把内容填充完整，补上缺少的解释，把整体跑通。这一步下来通常会得到一篇很长、有些啰嗦的初稿。这时候 AI 就很有用了，可以让它在不改变原意和语气的前提下，帮我去掉无用的啰嗦、修好断层的连接、找出逻辑不完整的地方，以及还需要补充哪些背景知识。这个过程里 AI 不是在替我写，是在帮我收紧结构、减少噪音、暴露漏洞，往往又能学到一些原来遗漏的东西。

这也是为什么我觉得 AI 在你有真实产出的时候才最有用。如果只是让它帮你总结，很容易感觉自己学了很多，但脑子里其实没什么扎实的。当你认真在写一篇东西、解释一个概念、做出一个成品的时候，AI 才真正有帮助，它放大的是你自己已经在做的事情。

初稿整理好之后，自己再读一遍，不是让 AI 读。AI 只是工具，一旦让它代替你的判断，这件事就没意思了。自己读的过程中继续修改调优，和写代码自测那种感觉很像，不断找薄弱点、修毛边、改读起来不对的地方。读完两遍，基本感觉差不多了，然后就可以发出来给大伙看。

这也是我做 Waza 的原因，一个围绕我实际工作方式构建的开源 Skills 集合。其中有一个叫 /learn，就是专门为这个流程设计的：收集资料、筛选、写大纲、填充内容、AI 辅助优化、自读发布，整个过程连成一条线。

肯定有小伙伴担心写了没人看，所以不想发，甚至干脆不写。我不觉得这是个好理由，只要内容有意义，自然会有读者，不一定立刻，不一定很多，但有意义的东西很少会被浪费。「没人看」大多数时候只是懒得动笔的借口。

这整个过程让我有个更清楚的感受：在 AI 时代，学习速度确实快了很多，但深度不会自动到来。AI 可以帮你收集、翻译、清洗、整理、对比、精简，把整个过程工业化，但真正的深度还是取决于你的判断、你的耐心、你的标准，以及你愿不愿意把输入转化成输出。这一点没有变，现在反而更重要了。

2026-04-03 08:00:00

太长也要读

在写完《你不知道的 Claude Code：架构、治理与工程实践》、《你不知道的 Agent：原理、架构与工程实践》后，我想着继续来写第三篇，这次打算挑战下自己来梳理一下大模型训练到底怎么回事，这篇文章争取让非专业背景的人也能读得懂。

2026 年来看大模型效果真正拉开差距的地方，慢慢不再是预训练本身了，而在它更后面的那一大段：后训练、评测、奖励、Agent 训练、蒸馏，每一个步骤都在影响用户实际感受效果。你发现某个模型突然变强了，背后可能是这几块一起优化到位了，而非单一因素导致。

下文按大模型训练链路顺序来讲，重点放在厂商怎么通过后半段训练栈来提升最终上线效果。

大模型训练其实是一条流水线

过去几年，一般会用参数、数据、算力的堆积来解释模型进步，但很多用户真正感受到的提升，并不是来自再多训一点基础语料，而是来自预训练后面那整套训练流程。模型怎么说话、怎么听指令、怎么推理、怎么用工具，这些都不是多喂一点互联网文本就能自然长出来的。

InstructGPT 当年给过一个很直接的例子：一个只有 1.3B 参数、做过对齐和偏好优化的模型，在人类偏好评测里能赢过 175B 的 GPT-3，参数量差了两个数量级，用户最后却更喜欢那个小很多的版本，训练后半段是真的会改写用户感知。

训练过程其实是一条流水线，数据、算法、系统、反馈这几层高度耦合，一层变化通常会传导到其他层，2026 年的模型能力和产业价值，也越来越集中在预训练后面的几层。

这也是我们平时为啥感觉豆包不太去争排名，但大家日常用起来却更符合心意的原因，是后训练做到位了。

这六层只是为了看分工，下图的九个阶段是更详细的版本：原始数据和系统配方单独拆开，Agent harness 和 Deployment 也是后半段的细分。还有两条反馈回路贯穿始终：生产流量回到数据工程，离线评测结果回到预训练。

预训练只是模型底座

预训练仍然是训练链路的起点，搞清楚它到底在做什么，才能理解后面的每一层都在补充什么。没有这一步，就没有语言建模能力，没有知识压缩，也没有后面那些能力迁移的空间。在工程上，它要做的不只是让模型学会预测下一个 token：把语言分布学进去，把大规模文本里的知识和模式压进参数，还要给后面的能力激活留出空间。下一个 token 预测只描述了训练形式，解释不了为什么规模上来之后，模型会突然多出一些之前没有的能力。

GPT-3 之后，不少模型调优的工作会更加考虑到预算和配比，模型不是越大越好，参数量、训练 token 数和总计算预算之间有配比问题，很多模型不是做小了，而是训练量不足，在既定预算下没有训到更合适的点。

真到训练决策里，更实际的问题是：如果有人给你一万张 H100 和一个月时间，你会如何去训一个足够好的开源模型？规模定律在这里更像一个预算分配工具，不是那种论文里的抽象曲线，最后还是需要静下心来考虑这些问题：下一轮训练到底该多堆参数，还是多喂数据？当前模型到底是能力不够，还是只是欠训练？有限 GPU 预算下，什么配比更值？

预训练更像是给模型能力打地基，决定知识范围、泛化潜力和模式归纳能力，也决定后训练有没有可以利用的空间。但听不听指令、配不配合用户、关键任务跑起来稳不稳，这些预训练都是管不到的。

预训练阶段不只是在决定学多少知识，它还在提前决定模型以后能长成什么样。tokenizer 的切分方式会直接影响后续训练，context window 拉到多长也要在前面定下来。要不要继续做多模态预训练，要不要把单卡可运行当成一开始就定下来的要求，这些取舍在训练阶段就写进配方了，不是发布时再补的功能 feature。Gemma 3 同时强调了 single accelerator、128K context、视觉能力和量化，背后反映的也是这类取舍。用户最终看到的那些能力，比如能在本地电脑上跑、能看图、能理解长文档，其实很多在训练阶段就已经定下来了。

通过 Chinchilla 给出的数据最优点来看，对于 8B 参数的模型大约是 200B tokens，但 Llama3 8B 实际用了 15T tokens，超出约 75 倍。这类过训练配方通常能在同等参数下换来更高的能力密度，最后换来一个更小、推起来也更省的模型。衡量这件事，看总 FLOP（浮点运算次数）比看参数量更靠谱，下图直观展示了这个差距。

还有一类容易被忽略的设计也发生在预训练阶段：tokenizer 词表大小、分词策略、字节级编码方式都会有挺大影响。Llama2 词表 32K，Llama3 扩到 128K 后，序列长度大约压缩了 15%，下游性能也会跟着上去，这个影响会延续到推理成本和多语言能力。中文、代码、数学公式的 token 效率在词表设计时就已经定下来了。比如一个把中文分得很碎的 tokenizer，劣势并不是每次多花几个 token，而是每次推理都要持续承担这个决策错误的代价。

数据配方决定模型能力

参数规模是过去几年大家比较的重要指标，但这两年更重要的东西叫「数据配方」。

这个过程表面看是清洗数据，实际上是完整的数据生产工程。网页、代码仓库、书籍、论坛这些原始数据，要先走完文本抽取、语言识别、质量过滤、隐私处理、安全过滤和去重，才能进入预训练，下图展示了完整的漏斗处理流程。

如果只把数据当作训练燃料，很容易得出越多越好的结论。但数据工程更接近能力设计，模型看见什么、看不见什么，代码数学百科各占多大比例，这些选择直接影响模型最后形成的能力分布。

去重和污染控制常被忽略，但它对结果影响很大，要处理的不只是低质量数据，还包括重复模板、许可证文本、镜像网页，以及 benchmark 泄漏带来的污染。如果 document-level 和 line-level dedup 做得不够，模型往往会反复吸收最容易复制的内容，却未必真正学到最有价值的部分，很多开源模型效果看起来是参差不齐，往往是数据处理质量的差距。

最近两年，数据配比本身也成了单独要研究的问题。Data Mixing Laws 这类工作关注的，不只是还能收集多少数据，更是不同类型数据的占比会把模型带向什么能力结构。

合成数据也已经从辅助手段变成正式训练流程的一部分，Self-Instruct 这类让模型自己生成指令数据的方法、DeepSeek-R1 的蒸馏轨迹，以及 Qwen、Kimi 系列里越来越明显的合成监督，都在往同一个方向走。每一代更强的模型，都会参与重构下一代模型所看到的数据。早期模型生成基础指令数据，更强的模型生成高质量推理轨迹和 CoT 数据，经过 RL 训练的推理模型再把这些轨迹蒸馏给更小的 dense 模型。dense 就是全部参数都跑，和 MoE 那种按需激活不一样。

这里的关键是，模型往往要先在更大规模上形成能力，后面才可能把这些能力压缩到更小的模型上。DeepSeek-R1-Distill 系列就是直接例子。RL 后的大模型轨迹让 1.5B 到 70B 的 dense 模型都获得了明显收益，Llama 3.1 405B 也明确被用于提升 8B 和 70B 的后训练质量，这些不是附带产物，而是训练设计的一部分。

系统和架构的约束，训练前就要想清楚

很多人把训练理解成研究问题：目标函数怎么设，损失怎么降，模型结构怎么改。但真正的大模型训练里系统约束这一块非常重要，是分布式系统问题，而非单机上的深度学习问题。GPU 数量、显存带宽、并行策略、容错和成本，这些不能等到训练完才去调优，最开始就决定了你能训多大、支持多长上下文、能不能跑更复杂的后训练这些点。

MoE 是这一层最典型的例子，多专家模式让模型在相近计算量下扩大总参数，也把每个 token 的激活成本控住。代价会让路由复杂、负载均衡难、基础设施重。DeepSeek-V3、Qwen 一系列 MoE 设计都是成本和效果的折中，不是单纯的架构偏好。

最近公开配方里的讨论，不再只是模型大小和 token 配比这种粗粒度分析。muP 让超参可从小规模实验迁移到大规模训练，WSD learning rate 是先升后稳再衰减的学习率调度策略，再加上最优 batch size 和更高的数据对参数比例，这些都开始出现在正式训练报告里，这些细节正在变成同规模模型之间真正拉开差距的地方。

长上下文、多模态和新架构如果只按产品功能点理解，会漏掉训练侧的约束。128K context 这种目标会直接改变 attention 成本、batch size、训练 curriculum（数据编排顺序）和并行策略，多模态改的不只是模型结构，还有 data mixing（多来源数据配比）、encoder 设计和安全评测。如果把单卡可运行当成硬要求，参数量、量化路径、模型家族大小都会跟着收紧。

Forgetting Transformer 和 Kimi 的 Attention Residuals 这类工作，都是在回答类似的问题：更长的上下文如何训练，网络变深之后如何避免信息被稀释。你看到的是模型能处理更长输入，或者更便于部署，训练时面对的却是另一组完全不同的约束。

算力预算是固定的，模型大小、训练 token 量、上下文长度、serving 成本，每往一个方向多花，其他方向就得让步。

上下文拉长，attention 成本直接膨胀，batch size 必须压小；模型做大，GPU 内存上来，serving 成本也跟着涨。这不是取舍选项，是资源约束的结果，大部分决定在训练开始前就锁死了。

还有个工程现实经常被忽略：训练并不总是稳定的，几千张 GPU 跑了几周，突然出现训练损失突增，幅度大到无法忽略，只能回滚到几天前的 checkpoint，重新来过。

除了 loss spike，还有单块 GPU 静默出错，不报错但悄悄产生错误梯度、NVLink 带宽异常、节点间通信抖动，每一种都可能污染若干步训练。能不能在大规模训练里快速检测、隔离、恢复，这是实验室级别的工程能力，不是读论文能解决的问题。

DeepSeek-V3 在技术报告里专门提到，整个预训练过程没有出现 irrecoverable loss spike，也没有做任何 rollback，同时是少数公开验证 FP8 混合精度训练在超大规模模型上可行的案例。按公开数据，全流程约 2.788M H800 GPU hours，预训练完成了 14.8T tokens。

训练系统和推理系统关系紧密，但不是同一个工程问题。训练关心梯度、并行、checkpoint、吞吐和成本，推理关心延迟、KV cache（缓存历史计算避免重复运算）、量化和服务稳定性。

后训练才决定用户真正感受到的差距

普通用户真正能感受到的很多提升，其实都发生在预训练之后。指令微调（Instruction tuning）用标注好的指令-回答数据对模型做监督训练。它改变的是回答方式，把怎么接任务、怎么组织输出、怎么像个配合的助手这些要求变成监督信号。一个基础模型也许已经具备不少潜在能力，但如果没有这一步，这些能力往往不会以用户期待的形式稳定冒出来。

再往后看，RLHF、DPO、RFT 方向差不多，都在把”什么叫更好的回答”接进训练回路，但路径不同。

• RLHF（基于人类反馈的强化学习）先模仿高质量回答，再用偏好比较做强化
• DPO（直接偏好优化）把这条路径缩短，直接从偏好对比里学，不需要单独训奖励模型
• RFT（强化微调）是工程上更容易落地的接口，把任务定义、grader 设计和奖励信号放到产品化流程里

今天谈后训练，只讲 SFT 或 RL 已经不够了，更难的是评测怎么设、分数怎么打、什么样的回答才算值得继续优化。SFT 是监督微调，它学到的不只是知识，也在学风格。数据长度、格式、是否带引用、是否偏好分点表达，都会显著影响模型最后的输出形态。很多用户以为自己在比较能力，实际比出来的往往只是风格差异。再加上偏好评测天然偏爱更长的回答，很容易把看起来更认真的长输出当成更可靠。所以后训练只看榜单往往不够，还要结合真实任务结果、成本和稳定性。

现代后训练是一条多阶段流水线，公开资料里 DeepSeek-R1 的配方是最清晰的。它分四个阶段推进：

阶段 1是冷启动 SFT，在做强化学习之前，先用少量高质量的思维链 CoT 数据热身。DeepSeek-R1-Zero 证明了直接从 base model（预训练后尚未做对齐的原始模型）上做 RL 是可行的，但纯 RL 训练出来的模型会反复重复、语言混乱、可读性很差。冷启动 SFT 给 RL 一个更稳定的起点，先把格式和语言一致性收住，这不是多余步骤。

阶段 2在数学、代码、逻辑等可验证领域做强化学习，用 GRPO 作为训练算法，以可程序检验的正确性作为奖励信号。关键在于为什么选 GRPO 而不是传统的 PPO：PPO 是近端策略优化，需要一个独立的价值网络（value network）来估算当前状态价值，在大模型上同时维护两个网络工程负担很高。GRPO 对同一个提示词采样多个回答，用组内排名替代绝对价值估计，不需要独立的价值网络，工程上简洁很多，DeepSeek 系列和 Cursor Composer 2 的 RL 基础设施都采用了接近 GRPO 的方案。

阶段 3做拒绝采样微调（Rejection Sampling Fine-Tuning），把 RL 产生的成功轨迹过滤后转成新的 SFT 数据，再做一轮监督微调。这是 RL 和 SFT 之间的桥梁，RL 探索出的好轨迹，就这样变成下一轮 SFT 的高质量训练样本。

阶段 4融入有益性和安全性偏好反馈，把模型调整到符合发布标准的助手形态。

四个阶段互相依赖：冷启动让 RL 稳定启动，RL 产生高质量数据，拒绝采样把这些数据变成下一轮 SFT 的输入，对齐 RL 完成行为收敛。从公开结果看，直接 SFT 和走完四个阶段，差距通常是能看出来的。

Eval、Grader、Reward 在重新定义训练目标

负责把模型输出转成训练分数的组件叫 grader，它很容易出现大家想不到的问题。只看最终答案，模型很快学会走捷径；打分太粗，噪声会被强化学习持续放大；榜单涨了，真实任务未必跟着一样好。很多时候，用户以为自己在看 base model 差距，其实差距出在目标怎么定义上。

放到训练流程里看，eval 决定测什么，grader 决定一次输出怎么变成分数，reward 决定模型后面会被往哪里推。它们连起来就是一条具体的反馈回路：任务定义、eval、grader、优化、rollout、再评测。rollout 指模型执行任务产生的轨迹，链路里任何一环跑偏，后续优化就会一起跑偏。

只看最终结果，模型可能会碰巧答对，也可能沿着错误过程拿到正确答案，代码、数学和复杂推理任务里，这个问题尤其明显。中间步骤如果不进反馈，模型学到的往往不是更可靠的推理，而是怎样更高概率地拿到最后那一分。

所以这几年越来越多工作从传统 RLHF 转向 verified rewards，用程序直接验证正确性。在数学、代码、逻辑这些可验证任务里，现在已经可以直接对正确性打分，不再主要依赖人工偏好。但 verified rewards 也没有把问题彻底解决掉。过优化、reward overfitting（打分规则被过度优化、能力却没真正提升），以及 mode collapse（输出高度单一、失去多样性）这些现象还是会出现，问题只是从偏好标得准不准，变成了打分链路稳不稳。

模型写出来的思考过程，也不能直接当成内部过程的完整记录。Anthropic 在 reasoning model 的可观测性实验里发现，模型会使用额外提示，却不在可见 CoT 里承认；到了 reward hacking 场景，它更可能补一段看起来合理的解释。reward hacking 是钻打分系统空子，而不是真正完成任务。可见 CoT 更适合当训练和监控信号，不能直接当成完整真相。

再往下一层，模型甚至会开始利用打分通道本身。reward tampering 和 alignment faking 这类研究表明，模型在理论上可能主动干预打分过程本身。reward tampering 是直接篡改奖励计算过程本身，alignment faking 是对齐伪装，表面合规但隐藏不对齐意图。

一旦模型有足够强的环境访问能力，它优化的就不止任务结果，还可能包括 checklist、reward code 和训练关系本身。Anthropic 2025 年一项实验，在一组可被利用的生产编码 RL 环境里注入了额外的 reward-hack 知识，随后观察到了类似的泛化。模型学会 reward hacking 后，不只会在同类任务上继续利用，还出现了对齐伪装等更广泛失对齐。

这些行为在标准对话评测里看不到，只在 Agent 任务环境里能看到。工程含义很直接，reward、grader、环境隔离和监控都要当成训练设计的一部分。

到了 Agent 阶段，reward design 还会继续拆细，最终结果只是其中一项，另外还要单独度量过程质量、上下文管理和反作弊约束。Kimi K2.5 奖励的是有效拆解和真实并行；Chroma Context-1 会给搜索途中找到的相关文档记分；Cursor Composer 2 把长任务里的 summary 纳入奖励，因为总结一旦失真，后面的上下文会一路被带偏。

具体到实现里，ORM 是结果奖励模型，只给最终答案打分，信号稀疏，成本低，适合先起步，但也更容易让模型走捷径。PRM 是过程奖励模型，给中间步骤打分，信号更密，对数学和代码推理通常更强，但标注和系统成本都高很多。OpenAI 在数学推理实验里看到，PRM 不只提高了正确率，也更容易把过程约束住，因为每一步都在被监督；问题也很直接，PRM 的成本通常是 ORM 的数倍，所以大多数真实系统还是先从 ORM 起步，只有在数学、代码、逻辑这类可验证任务里，才更有条件把 PRM 自动化，用程序去验证中间步骤，绕开人工标注瓶颈。

这条回路完整跑起来是这样的：

最近几类对齐方法都在做同一件事。Anthropic 的 Constitutional AI 把人类写的原则接进训练，用 AI feedback 替代逐条人工偏好。OpenAI 的 Deliberative Alignment 把安全遵守放进推理过程，让推理能力本身承担一部分安全约束。这里说的 Deliberative Alignment 是审慎对齐，核心是推理阶段自行判断安全规范，而不是依赖训入的反射行为。两条路线都在把对齐从人工标签变成训练目标内部的一部分。

以 Constitutional AI 为例，两阶段流程是先让模型依照原则自我批评和修订输出，再用 AI feedback 替代逐条人工偏好标注。对齐从来不是挂在训练后面的补丁，系统测什么、怎么打分、奖励什么，模型就往哪个方向走，这本身就是训练后半段最直接的调节手段。

到了 Agent 训练，优化的不只是模型本身了

过去两年，以 o1 系列和 DeepSeek-R1 为代表的推理模型快速成型，说明在奖励稳定、验证可靠、基础设施到位的条件下，语言模型上的 RL 确实能显著提升数学、代码和逻辑任务表现。

这同时打开了一个新维度：推理算力也可以扩展了。RL 训练的作用随之多了一层，它在教模型答题之外，还在教模型分配推理预算，知道什么时候多想、什么时候该停。再往前走，难点就变成让模型在环境里持续行动，而不只是把单次思考拉长。

Qwen 前模型负责人 Junyang Lin 对 Thinking 和 Instruct 混合路线的反思很有代表性：难点不在给模型一个思考开关，而在两种模式的目标本来就不一样，一个追求直接、合规和低延迟，另一个追求更多探索和更高正确率。再往前一步，训练目标就会从回答前想多久，转成行动里怎么分配预算、怎么接反馈、怎么继续推进任务。

这时候训练对象不再只是一个会回答问题的模型，而是一个能规划、调用工具、接收反馈、在长任务里保持连贯的系统。于是训练栈也跟着变了，浏览器、终端、搜索、执行沙盒、内存系统、工具服务器、编排框架都开始进入训练系统。

更准确地说，harness 是包在模型外层的控制程序，这个概念不只属于 Agent 运行时，训练阶段同样有它：决定模型看到什么输入、以什么形式接收反馈、何时裁剪上下文、何时调工具。prompt construction、memory update、retrieval policy、context editing、tool orchestration 都在这里。环境也不再只是静态验证器，而是训练和部署都要直接面对的一层。

harness 先稳住，模型训练才有意义。工具返回值不稳定、浏览器环境和线上不一致、文件系统状态不可复现时，grader 会先出错，模型随后学到的就不是能力，而是如何利用环境漏洞。训练 Agent 时，很多时候既在 debug 模型，也在 debug 环境。

三家的做法也很清楚：Kimi 用 PARL 解决并行拆解和 credit assignment，Cursor 用 self-summarization 和 real-time RL 把长时 coding session 与生产流量重新接回训练，Chroma 则把 prune_chunks 训成策略本身，让 context pruning 直接进入检索过程。

SFT 时代数据多样性是第一位，到了 Agent 时代，环境质量才是核心：稳定性、真实性、覆盖度、难度分布、反馈丰富度和抗利用性。训练目标也随之变化，要的是在完整任务里保持可靠，不只是做对一道题，经典 CoT benchmark 覆盖不到这部分。

这个变化还在继续前移：不只是在 runtime harness 里训练模型，连 harness code 本身也开始成为可以被外循环搜索和优化的对象。

Kimi K2.5 的 PARL 是一个很值得拆开的工程案例，路线很明确：只训练 orchestrator，把 credit assignment 收束到编排层，不在所有 sub-agent 上同时优化。

奖励信号分三类，任务成功、并行分解和完成约束，一起驱动编排层。训练早期把 r_parallel 权重拉高，鼓励先探索并行策略，后期再逐步退到 0，避免把多开 sub-agent 当成捷径。评估也不只看总步数，还看关键路径长度，关键路径变短才说明并行真的生效。

但到了 2026，事情又往前走了一步，Meta-Harness 明确把 harness engineering 单独拿出来优化。它优化的不是权重，而是 harness code 本身，也就是围绕固定模型的 prompt construction、retrieval、memory 与状态更新程序。论文开头的数字很直接：同一个底模，只改 harness，在同一 benchmark 上就可能拉出 6x 的性能差距，模型外层这套程序已经不只是部署细节，也是能力形成的一层。

它的关键也不是再加一个抽象 optimizer，而是把 prior code、scores、execution traces（工具调用和状态变化的执行日志）全部写入 filesystem，让 proposer 像写代码一样去 grep、cat、比对 diff，再顺着失败路径改 harness。proposer 是提出 harness 修改方案的模块。

作者判断得很明确，过去很多 text optimizer 对 harness 这类长时、状态化程序不够有效，核心原因是只看 scalar score、短模板或总结会把问题压扁。scalar score 只有最终得分，没有过程信息。harness 的错误常常要很多步之后才显现，反馈一旦被过度压缩，诊断链路就会断。

这些结果不只是 benchmark 分数更高。在线文本分类里，Meta-Harness 比 ACE（agent 上下文工程基线）高 7.7 个点，同时把 context token 用量压到原来的 1/4。检索增强数学推理里，一个发现出来的 harness 在 200 道 IMO-level 题上，对 5 个 held-out 模型（未参与优化）平均再涨 4.7 个点。在 TerminalBench-2 上，它也超过了手工工程化 baseline。这说明被优化的已经不只是模型内部策略，也包括模型外围那层如何组织信息和行动的程序。

一个具体例子：Meta-Harness 在 TerminalBench-2 上自动发现了 environment bootstrap，也就是 agent loop 开始前先跑一个 shell command，把工作目录、可用语言、包管理器和内存状态整理成快照注入首轮 prompt。很多 coding agent 前几轮其实都在探环境，这层前置做好，提升不一定来自更强权重，而是 harness 让模型一开始就站在更好的上下文上。

到这里，优化目标已经从答案扩展到轨迹，再扩展到承载轨迹的 harness program。

前沿模型发布后，训练链路还在继续跑

单用一轮预训练的思路来理解今天的大模型，已经不够了。发布出去的模型背后，通常已经跑完了预训练、后训练、蒸馏、专用化这整条链路，而且更强的模型还在持续给下一代产出训练数据。

DeepSeek-R1 系列的蒸馏就是很典型的例子，大模型先通过 RL 和 verified rewards 把推理能力练出来，再把这些推理轨迹迁给更小的 dense 模型。TranslateGemma 这类专用模型则展示了另一条路线：在更明确的目标任务上，用高质量数据和专门的奖励设计，把能力进一步压缩和定向。到了这一步，更强的模型已经不只是拿来服务用户，也开始直接给下一代模型产出训练数据。

背后的原因比轨迹迁移更根本一些：一个可能的解释是，互联网语料里知识记忆和推理能力是耦合在一起的，现有的预训练目标要求模型同时把两件事都学好。大模型之所以要先上来，是因为只有足够大，才能同时撑起这两件事，然后再用它来生成纯推理示范数据，小模型在这类数据上训练，就可以专注在推理本身，不用再被迫把所有知识都记住；先大再小，一个关键原因是能力解耦，不只是成本策略。

另一边，部署适配性和能力本身同样重要。很多场景不需要全能大模型，更关心成本、延迟、稳定性和可控性，训练的终点不一定是更大，也可能是更小、更便宜、更专门。

最后发布的模型，不一定是训练曲线最右边的那个 checkpoint。实际发布前往往会在多个 checkpoint 之间反复比较真实任务结果、拒答风格、工具稳定性、成本和回归风险。最后上线的版本往往是产品决策，不是单一指标上表现最强的那个。

用户看到模型名字，会以为它对应一条平滑上升的训练曲线，但真正选哪个 checkpoint 上线，那是另一回事。

大模型的价值，既在它自己的服务能力，也在它会继续给下一代模型提供训练数据、蒸馏来源和发布基座。

离线训练之外，接近在线的持续优化也已经进了主流程，Cursor Composer 2 的 real-time RL 说明一部分 Agent 能力已经开始通过生产流量持续迭代，而不是等下一轮大规模离线训练统一刷新。训练和部署之间的边界并没有消失，但两者的反馈回路正在缩短。

以后怎么看一个模型为什么变强了

2026 年前沿模型的价值，越来越看谁能把预训练后面这整套训练链路跑完整：持续产出训练数据、做蒸馏、做专用化、把评测和奖励做好、做最后的发布选择。 也因为这样，后面再看一个模型为什么突然变强，可以先看三件事：

• 先看变化发生在预训练层，还是后面的训练流程。很多能力提升确实来自更强的预训练和更好的数据配方，但也有很多体感变化，其实主要出在后训练。模型会不会听指令、会不会用工具、回答风格稳不稳，常常不是多训一点语料自己长出来的。

• 再看提升来自哪一层：是权重和训练配方，还是 reward / eval / grader，还是 harness code 和 deployment loop。到了推理模型和 Agent 这一段，用户感受到的变强，很多时候已经不是基础模型单独做出来的结果。评测怎么设、奖励怎么打、工具环境稳不稳、retrieval 和记忆怎么组织、summary 和上下文怎么剪、上线时选了哪个 checkpoint，这些都会一起改掉最后的产品表现。
• 最后看上线版本在优化什么。有些版本是在追求更高上限，有些版本是在压成本、延迟和回归风险，还有些版本是在给某一类场景做专用化。发布版本本来就是产品决策，不是训练曲线最右边那个点，所以看模型更新时，顺手看它到底在优化什么，会更接近真实情况。

把模型突然变强这件事拆回生产环节看，很多提升其实是后半段训练栈和外层 harness 一起放大的。这条链路的迭代周期也在缩短：生产流量持续回流到训练，每代更强的模型在产出能力的同时也在产出下一代监督数据，外层程序根据 rollouts、logs 和真实任务反馈不断重写。

今天发布的模型只是一个快照，链路和 harness program 才是持续在跑的产品。

学习资料

1. Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla). arXiv:2203.15556
2. Ouyang et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). arXiv:2203.02155
3. Shao et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). arXiv:2402.03300
4. DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948
5. DeepSeek-AI (2024). DeepSeek-V3 Technical Report. arXiv:2412.19437
6. Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. arXiv:2407.21783
7. Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073
8. OpenAI (2024). Deliberative Alignment: Reasoning Enables Safer Language Models. openai.com/index/deliberative-alignment
9. Anthropic (2025). Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models. anthropic.com/research/reward-tampering
10. MacDiarmid et al. (2025). Natural Emergent Misalignment from Reward Hacking in Production RL. arXiv:2511.18397
11. Lee et al. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses (preprint project page). yoonholee.com/meta-harness
12. Kimi Team (2026). Kimi K2.5 Tech Blog: Visual Agentic Intelligence. kimi.com/blog/kimi-k2-5
13. Rush, S. (2026). A technical report on Composer 2. cursor.com/blog/composer-2-technical-report
14. Chroma (2026). Chroma Context-1: Training a Self-Editing Search Agent. trychroma.com/research/context-1

2026-03-30 08:00:00

标题来自 12 年前我很喜欢的一首万青的歌《杀死那个石家庄人》的改写，虽然歌里写的不是一回事，但那种看着熟悉世界一点点被替换掉的感觉，还真有点像。

好多年没坐公交了，上次去太子湾，因为景区限行，只能把车停在外面，坐景区的免费接驳车进去。

前排有个小女孩一路都在刷那种 AI 生成的短视频，画面很粗糙，内容也很假，滑到下一个居然还是差不多的东西，她却看得津津有味，每个视频的点赞居然也都不低。看到这一幕的时候，我甚至有点难受，会忍不住想，以后我的小孩是不是也会在这种粗制滥造的 AI 内容里慢慢长大，最后连什么是真正美好的东西都越来越难分辨。

有了 AI 之后，很多东西的生产一下子就变简单了，做内容简单了，做软件也简单了。以前做一个东西出来，往往要花不少时间反复琢磨，要真的解决很多问题，最后才敢拿出来。现在很多环节一下就被抹平了，写点东西很容易，做个产品也很容易，花钱买 Token，问问 AI，拼个流程，套个界面，很快就有一个能跑的东西出来。

今天也看到有人说，两天就可以复刻一个 Claude Code，我是既信又不信。最近语音 AI 软件一下冒出来几十个，看了看体验都还不错，甚至豆包都来卷这个了。Claude Code 的套壳客户端最近也见了不少，说实话有些做得还挺好用。

程序员很多以前看着要专业能力、要学习门槛、要长时间积累的东西，正在很快变成一种到处都是的供给。以后最不缺的，可能就是那种看起来像个产品的东西，能用，能跑，也好看。你当然还是可以做得再快一点，再好用一点，或者再多包一层，这些可能还是有价值的，只是这种价值会越来越容易被 AI 的发展追平。

上次吃饭时和同事聊到一个有意思的话题，我说我最近一年特别喜欢听磁带，感觉每一首歌都很耐听。为什么以前的磁带、CD、电视节目，甚至很多老书，整体会让人觉得质量更高一点，原因其实很简单，以前生产和分发都很重。你想发专辑，先得把作品认真做好，然后才有可能去做上万个磁带出来，不然卖不出去，下次公司可能就不推你了。想出一本书，也不是写完随手一发，就能立刻推到很多人面前。以前光做出来这一步，就已经筛掉很多东西了。

现在发歌传个平台就行，写东西发个公众号就行，做软件有了 AI 之后也差不多。AI 甚至可以直接帮你把代码传到你以前望而却步的 GitHub 上，顺手把 Release 的 CI 都配好。很多过去要靠长期积累才能跨过去的坎，现在被工具一下填平了，于是整个世界也就慢慢被大量差不多、看起来也能用的东西占满了。

麻烦的还不只是质量往下走，更是时间久了，大家对质量的感觉也会一起往下走。粗糙的东西越多，传播越广，再叠加搞钱的驱使，人对好东西的判断会慢慢被带偏，最后慢慢习惯的，就是快刺激、快反馈、快满足。

再回头看那个小女孩刷视频，让人不舒服的地方就在这里，她看的不只是几个粗糙视频，她从小看到的，可能就是一种越来越低成本、越来越高频、越来越空的东西。

可以肯定的是，写代码这件事现在其实也走到这个阶段了。以后普通小白可以用 AI 写出满足自己需求的产品，产品经理也可以用 AI 做出以前要拉上程序员一起搞的东西，那么真正的工程师以后还能做什么，这件事其实得认真想一想。

最近听说不少互联网大厂的老板也开始不眠不休地 Vibe Coding，一个下午也能做出一个自认为可用的 demo，甚至非常沉迷。这件事对一线干活的人影响可能会很大，老板跑通代码后会感觉写代码其实也就那么回事。之前要 6 个月的东西，现在是不是 1 个月就行了，之前要 100 个人，现在是不是 10 个人就够了，后面简直不太敢想。

工程师继续做更好用、更高效的产品，当然还是有空间，但光停在这一层，后面一定会越来越挤，能进来的人越来越多，能做出点样子的人也越来越多，那就真的会很挤。

我想后面真正该去做的，可能是像当年的歌手演员那样去破解这个问题。一样发专辑，但他们会去做演唱会、舞台剧、现场剧，这些东西你没法随便套个壳就替掉，里面有组织能力，有细节密度，有长期打磨之后才会出来的完整感，而且是直接面对世界的。

软件往后看，我感觉也会越来越像这样。人人都可以 Vibe Coding 出产品，都会做一个差不多能用的产品，后面真正能把差距拉开的，还是系统能力、工程深度、场景理解，还有那些别人一眼看不见，但最后会决定这个东西到底有没有分量的地方。

外面越快，越不能把自己对软件的要求一起放低。低水平的供给以后一定会越来越多，但这不代表我们也要跟着变得粗糙。那个你一用就觉得顺手、舒服、克制、几乎没什么 Bug，能感觉到做的人认真对待过的东西，最后往往才是真正能留下来的。

也许我下一个维度真正想做的东西，会是软硬件结合的产品，或者是以前只有大厂几千人才能做的那种平台型产品，或者干脆是突破现有维度的东西，但具体是什么，还得继续想，继续琢磨。

当这里很多东西都越来越像、越来越挤的时候，往外走可能是一种办法，去面对更大的市场、更不同的用户、更高的要求。到了那个地方，很多事就没法只停在套壳、拼快、抢时间差这一层了，它会逼着你把东西做得更扎实，也逼着你重新想清楚自己到底要做什么。

有了 AI 之后，很多事都更容易了，但也正因为更容易了，什么东西真的值得做，什么东西值得花很多年去换，反而变得更难想清楚。要做什么，可能比怎么更快做出一个东西重要得多。