IT社区推荐资讯 - ITIndex.net

AI 为什么会编程——原理、历史与未来

Wed, 20 May 2026 16:13:07 CST

我们来回顾一下AI Coding。

2021 年那会儿，AI Coding还基本是学术圈的论文话题，圈内程序员把它当作编程的辅助工具。GitHub Copilot 那年第一次发出来，火过一阵子，争议主要还是”这玩意到底该不该用，会不会让我变笨”。

到 2026 年 4 月，画面发生了剧变：GitHub 上每天约有 13 万 5000 个公开提交（commit）由 Claude Code 直接产出，约占全平台公开提交的 4%；OpenAI Codex CLI 重启一年，周活开发者破 300 万；Cursor 母公司 Anysphere 这两年的 ARR 从 0 跑到 20 亿美元，是 SaaS 历史上最快的曲线。

短短四五年，这件事完成了从”论文话题”到”日活千万级生产力工具”的跃迁。

我自己写专业代码超过十年，过去三年每天都跟这些工具打交道。这篇文章想用我的视角，把三个被反复问到、但很少有人系统答过的问题一次说清楚：

AI 凭什么会写代码？
这件事在过去五年是怎么发生的？
接下来几年，每个人真的能自己造 App 吗？

我会按”原理、历史、未来”的顺序讲下来。不需要技术背景。

一、原理：从史前到现在

1.1 史前时代：补全工具走的两条路

ChatGPT 之前，让机器写代码这件事走在两条路上。

一条是程序员用论坛式平台或者工具自助。Stack Overflow 这类问答社区做的是”全人类积累过的报错和解法都摆在这里”。你写一段代码报错，把错误信息贴上去，社区里有人答。中国对标的是 CSDN，1999 年起步的中国软件开发者社区，到 2024 年累计 4000 万注册用户、1200 万月活，是整个国内程序员的”中文外脑”。我自己 2014 年学编程时，每天工作流就是写代码、报错、复制粘贴去 Stack Overflow 搜，把答案改一改贴回去。这个流程在 ChatGPT 出现之前用了整整 15 年。

IDE 这一层也在试图帮人。Microsoft Visual Studio（1997 年首发）的 IntelliSense、IBM 主导的 Eclipse（2001 年开源）的 Content Assist、JetBrains IntelliJ IDEA（2001 年）的 smart completion，都是当年”智能提示”的代表。但它们本质是查字典：你打 str.，IDE 列出 String 类的所有方法。它不”理解”你想干什么，它在”查表”。

加载图片

52 KB

另一条是学术界的程序合成（program synthesis），目标是用形式逻辑从规约（specification）反推出代码。这条路从上世纪 70 年代算起，被困在玩具级别整整半个世纪。半个世纪里几乎只跑出来一个工业级成果，是 Microsoft Research 的 Sumit Gulwani 主导的 FlashFill，2013 年集成到 Excel 里，根据你给的几个例子自动猜出整列的变换规则。但这套思路要求形式化规约或纯净例子，对自然语言无能为力。

加载图片

20 KB

program synthesis

2020 年前后还出现过神经网络版本的代码工具，比如 Microsoft 的 CodeBERT（2020 年 9 月）、Salesforce 的 CodeT5（2021 年），都属于智能一点的自动补全。它们的根本限制还是不懂自然语言。你没法跟它对话，它也只能补一行代码，没法接一个任务。

把这几条线放一起看，问题的本质就浮上来了：要让机器真正会写代码，前提是它得先懂自然语言。这件事 2018 年之前，没人做出来。

1.2 转折点： GPT 系列怎么改局面

转折点是 GPT 系列。OpenAI 2018 年 6 月提出一种思路：先用海量自然文本做预训练，让模型学会”猜下一个词”的通用能力，再针对具体任务微调，GPT应运而生。GPT 全称 Generative Pre-trained Transformer，GPT-1 只有 0.117B（billion）参数，是个研究原型；GPT-2（2019 年 2 月）涨到 1.5B；GPT-3（2020 年 5 月）直接做到 175B，比 GPT-2 大 100 倍。规模上去之后，”懂自然语言”这件事第一次跨过了门槛。从这条线往代码迁移，就有路可走了。

写代码的模型和聊天的模型用的是同一种 Transformer 网络，做的是同一件事：看着前面已有的 tokens，预测下一个 token 该是什么。一段 Python 代码在模型眼里，和一段中文小说一样，都是 token 序列。模型并不”知道”自己在写代码，它只是沿着前面的上下文做最大概率的下一个 token 预测。

举个具体例子。最简单的斐波那契函数长这样：

def fib(n):

if n < 2:

return n

return fib(n - 1) + fib(n - 2)

模型生成它的过程，就是一个 token 接一个 token 往下猜。给定 def fib(n): 这一行之后，下一个最高概率的 token 是换行加缩进；再下一个是 if；再下一个是 n；再下一个是 <；再下一个是 2；再下一个是 :；再下一个是 return；这样一直猜下去，直到整个函数收尾。把成百万行 GitHub 代码看过几遍之后，这种”猜下一个 token”的概率分布天然就编码了语法、惯用法、变量命名、注释风格。

1.3 为什么代码这种语料特别适合模型训练

但代码这种语料特别适合被模型学会，原因有几条。

最直观的一条是代码的规律性极强。for i in range(10): 后面缩进了就是循环体，规则是死的，比自然语言稳定得多。同一个意思，自然语言可以有十种说法，代码基本只有两三种写法。这让模型从有限语料里学到的”压缩后的规则”密度远超普通文本。

再深一层，代码有客观对错。给一段函数和一组测试用例，跑一下测试就知道对错。这件事自然语言完全没有：一首诗写得好不好、一段散文动不动人，没有自动判分器。代码的这个性质后面会变成核武器。

还有一层是数据本身。每个开源仓库的 README、每段函数前的 docstring、每条 commit message，都是免费的”自然语言 ↔ 代码”对照语料。这是 GPT-3 之后所有代码模型都在吃的数据红利，量级远超人工标注能造出来的对照集。

最早一批走这条路的人，是把代码当作专门技能来训的。OpenAI 2021 年拿 GPT-3 在 GitHub 上 100 多 GB 的公开代码继续训练（这种做法叫 continued pretraining），得到 Codex 这个衍生模型。Codex 在 HumanEval（OpenAI 自己造的 164 道编程题数据集）上做到 28.8% 的首次通过率，是当年的 SOTA。那一阵 OpenAI API 里 code-davinci 和 text-davinci 就是两个独立的模型，前者写代码，后者写文。

GPT-4 时代之后，这条分家又合上了。Anthropic、OpenAI、Google 都在通用大模型的预训练数据里直接大量混入代码（公开估计占比 20% 到 40%），不再有专门的代码模型，统一一个 Claude / GPT / Gemini 既写文又写代码。

为什么会合并？因为出现了一个反常识的发现：训练里加大量代码，模型在数学、逻辑、甚至自然语言任务上都会变强。这件事最早是 DeepMind、Google Brain、OpenAI 几家在 2022 到 2023 年陆续观察到的。解释其实很直观：代码这种语料强迫模型学习”严格逐步推理”的思维方式，每一步必须严格成立，不然下一步就崩。这种思维一旦学到手，会迁移到非代码任务上。换句话说，代码训练已经成了让通用模型变聪明的核心成分之一，远超出”顺带做的副业”这个定位。

1.4 RLVR ：从”会写”到”能写对”

代码模型独有的杀手锏，是基于执行反馈的强化学习。具体的训练流程是这样：让模型生成一段代码，扔到一个真实的运行环境里跑，看测试用例通过几个，把结果（pass / fail）作为奖励信号回传给模型，让它下一次写得更好。这套方法叫 RLVR（Reinforcement Learning from Verifiable Rewards，可验证奖励的强化学习）。”可验证”是关键词：奖励信号不来自人类标注（贵、慢、有偏差），来自机器自动判分（廉价、可大规模、客观）。代码、数学题、形式化逻辑这几类任务都满足”可验证”，是 RLVR 最适合的场景。

加载图片

30 KB

DeepSeek 2025 年初放出来的 R1 模型把这条路推到极致：先用强化学习在数学和代码上把推理能力训出来，再迁移回普通对话场景，在多个 benchmark 上追上同期的闭源前沿模型。Claude Code、OpenAI o3 / Codex 这条线背后的训练大头，也都是 RLVR。这件事 2024 年之后才成为主流，是代码能力在过去两年涨这么快的核心原因。

整理一下。今天的代码能力是两件事的合成。一件是代码训练把通用大模型整体推到了一个新台面，让”先把问题分步、再每一步成立”这种思维方式渗进了模型的默认行为。另一件是在代码、数学、推理这类有客观对错的任务上叠加了大量基于真实执行的强化学习，把模型从”会写”训到”能写对”。这两条合起来，才是 AI 编程的真正引擎。

二、 AI Coding 公司发展史

2.1 起源：双雄站位与早期工具（ 2020 - 2022 ）

GPT-3 在 2020 年 5 月发布，175B 参数，规模上去之后，OpenAI 第一次有了把模型卖给开发者的底气。2021 年 7 月，他们拿 GPT-3 在 GitHub 公开代码上继续训练，得到 12B 参数的 Codex 衍生模型，搭载到 GitHub 推出的 Copilot 里。这是 AI 第一次进入程序员的”肌肉记忆”。每天敲 Tab 几百次接受补全建议，这个习惯就是从那个夏天开始的。

加载图片

25 KB

但 Copilot 当时形态有限：上下文窗口只有 2k 到 8k token，看得到的是当前文件局部，被动响应你不打字它不动。它适合补一行，不适合做一件事。

模型这一边，Anthropic 几乎同时起步。它的两位掌舵者是 Dario 和 Daniela Amodei 兄妹，2020 年底从 OpenAI 出走，2021 年 1 月把公司做出来，团队带走了一批 GPT-3 时代的核心研究员（Tom Brown、Jared Kaplan、Sam McCandlish 等人）。Anthropic 把”模型的诚实性、可控性、对长上下文的理解”作为差异化方向，这套底色后来变成 Claude 在代码任务上的天然优势：长代码库读得进去、复杂指令听得懂、对自己不确定的部分愿意说”我不确定”。

2022 年 11 月 OpenAI 发出 ChatGPT，AI 编程的形态从”补全工具”变成”对话伙伴”。但那时 ChatGPT 编代码经常一本正经地胡说八道，自信地编一个不存在的 API。同期出现的 Claude 系列，体感上的代码准确率明显高于 ChatGPT，是工程师圈里的”小众选择”。

ChatGPT 起飞之后，一整套”程序员的外脑生态”开始被重写。Stack Overflow 是受冲击最直接的一家：2008 年 9 月由 Joel Spolsky 和 Jeff Atwood 创立的全球程序员问答社区，2017 年峰值时每月新问题超过 30 万、月访问量超过 1 亿、累计注册用户破 1000 万。但 ChatGPT 之后，每月新问题数从 2017 年峰值的 30 多万一路掉到 2023 年的约 8.7 万、2024 年不到 6 万；到 2025 年 12 月只剩下不到 4000 个新问题，回到 2008 年刚上线时的水平。CSDN 也在掉。专做 AI 代码补全的早期创业公司 Kite，2014 年成立、是最早一拨 AI 编程工具，2022 年 11 月关闭，留下一句”我们是早了 10 年的产品，技术那时还没到”，500,000 月活也没能把它撑活下来。Codecademy、W3Schools 这一类教程站的流量也在持续下滑。

加载图片

45 KB

2.2 范式革新：编辑器革命到智能体时代（ 2023 - 2026 ）

2023 年 GitHub 把 Copilot 扩到对话，发出 Copilot Chat。但侧边栏聊天加 IDE 主区写代码，体验是分裂的，AI 始终被关在角落里。

真正改整个范式的是 Cursor。母公司 Anysphere 是 4 个 MIT 学生 2022 年起步做的，关键判断是把 VS Code 整个 fork 出来重写。fork 比做插件难得多，但能让他们改编辑器本身的交互。Cursor 真正的技术贡献是 codebase indexing，把整个项目全量向量化，让 AI 第一次能”看见整个项目”。这套范式后来定义了行业标准：模型用别人的（Anthropic / OpenAI），工程层是自己的（项目索引、上下文组织、UI 工作流）。

加载图片

59 KB

2024 年 10 月 Claude 3.5 Sonnet 升级版发布，SWE-bench Verified（一个由人工核对过的真实 GitHub bug 修复 benchmark）上的分数从前一代的 33% 跳到 49%。”AI 真的能写代码”这件事从这一刻第一次成立。Cursor 的体验在那几个月发生质变，工程师圈从 Copilot 大批往 Cursor + Claude 迁移。我自己 2024 年底切过去，三个月之内代码产出感觉翻了一倍。

接下来 2024 到 2025 年，整条线从”IDE 内的补全”往”智能体（agent）”方向跳了一步。Devin 是 Cognition Labs 2024 年 3 月发的，第一个把自己定位成”AI 软件工程师”的产品。营销大于实际，但定调了”端到端任务级 agent”的产品形态：给它一个目标，它自己去拆任务、写代码、跑测试、改 bug。

加载图片

71 KB

从那之后，最近一年的竞争主要落在三家头部产品之间。Codex 这个名字 OpenAI 用了第二次：第一次是 2021 年作为 GPT-3 衍生模型，作为 Copilot 的引擎；2023 年被弃用迁到 GPT-4；2025 年 4 月 16 日以”产品名”重启，这次是 Rust 写的命令行 agent。重启势头很猛，2026 年 3 月周活做到 200 万，4 月跳到 300 万，环比涨 50%；ChatGPT 企业版里 Codex 用户从 1 月到 4 月翻了 6 倍。

加载图片

402 KB

Claude Code 在工程师圈的渗透更深。Anthropic 2025 年发出来之后，靠 Claude 在长代码库上的天然优势，2026 年初做到约 25 亿美元年化收入（ARR），每天产生约 13 万 5000 个公开 GitHub 提交，占全平台公开提交的 4%。SemiAnalysis 预测它到 2026 年底会涨到 20% 以上。

Cursor 自己的体量也在快速涨。2026 年 2 月做到 20 亿美元 ARR，4 月在以 500 亿美元估值融资，是 SaaS 历史上从 0 跑到 20 亿美元最快的曲线。

剩下几家也有特点。Windsurf（前身 Codeium）是另一个 AI 原生 IDE，2025 年中被收购之后情况变复杂。GitHub 老牌玩家也追了上来，把 Copilot 升级成 Agent Mode 和 Coding Agent，老用户自然转化过去。

整体看下来，今天工程师圈的格局：资深程序员主流是 Cursor + Claude Code 组合，IDE 写代码加命令行跑大任务。

2.3 国内赛道和外行使用

主线之外，有两条值得单独说：国内厂商，以及面向非程序员的外行赛道。先说国内。

国内这个赛道是和海外平行展开的，几家大厂各占一席，开源那一拨也有自己的位置。

字节做的 Trae 是国内体感最接近 Cursor 的 AI 原生 IDE，2024 年底前后上线，初期对个人完全免费的策略让它在国内开发者圈渗透很快。Trae 接的是字节自家的豆包大模型，在中文项目和中文注释场景下，体感比直接用 Cursor 顺。同期字节还有一个更早的产品叫 MarsCode，定位偏向云端 IDE，跟 Trae 形成内部分线。

阿里的通义灵码是国内最早一批的 AI 编程助手，2023 年发布，作为 VS Code 和 JetBrains 系列 IDE 的插件存在，背后接通义千问 Qwen 系列模型。它在阿里云生态内的企业客户里渗透最深：钉钉、阿里云的内部团队和云上客户大量在用。Qwen 系列也是国内开源大模型里代码能力最强的一档。

百度的文心快码（Comate）有一个值得单独说的特性：SPEC 模式，强制先写需求文档、再让 AI 按文档写代码，把”PRD → 设计 → 开发”这条工程流程装进了 IDE 里。这套打法在国内大厂的内部研发场景里挺受欢迎，因为大厂的代码标准和合规审查严，AI 自由发挥的代码很多过不了 review。文心快码是国内少有的、走出工程化深度差异化的一家。

剩下几家。腾讯的 CodeBuddy 接的是混元大模型，主要走腾讯云生态。智谱的 CodeGeeX 是国内最早一批专门的代码模型，2022 年起就在做，今天也是国产代码 LLM 里开源版本最完整的一家。华为的 CodeArts 捆绑在华为云的 DevOps 套件里，主打央企和大型国企客户。

整体看下来，国内的真正优势在三条：中文场景适配明显更好、和国产云绑得紧、企业级落地路径短，加上个人版基本免费。短板也实在：前沿模型能力仍落后 Claude Opus 系列和 GPT-5 系列，在复杂多文件、跨仓库的智能体任务上还有可见差距。差异化的真正空间在两条，一是模型能力本身继续追，DeepSeek、Qwen、智谱都在做；二是把具体行业流程吃进工具里，文心快码的 SPEC 模式就是这个方向。

再说外行赛道。Vibe Coding 这一类工具的定位是让非程序员也能造 App：你用自然语言描述需求，AI 直接给你一个能跑的应用。这条线最近一年起得很快，每家有自己的切入点。

Lovable 是这一波里跑得最猛的。瑞典人 Anton Osika 2024 年做出来，从 0 到 4 亿美元 ARR 用了不到一年，全公司只有 146 人。它的产品形态是一个聊天框加实时预览：你说一句”我要一个看板，能拖拽卡片，能跟 Slack 同步”，Lovable 直接给你生成前端加 Supabase 数据库的全栈应用，几分钟内在浏览器里跑起来。

加载图片

69 KB

StackBlitz 做的 Bolt.new 走的是另一条路：在浏览器里写完整全栈应用，不依赖任何本地后端，跑在浏览器内嵌的 WebContainer 里。你描述需求，它生成代码、装依赖、运行起来，全程不用本地装环境。Bolt 在创业者和教育场景里渗透得特别快。

加载图片

43 KB

Vercel 的 v0 切的是 UI 设计这个口子。你给它一段描述或一张草图，它生成一个 React 组件，能直接拖到你已有的项目里。v0 不试图做整个 App，在前端组件这一段做得最精，是设计师和前端的高频工具。

加载图片

26 KB

Replit Agent 是老牌在线 IDE Replit 2024 年 9 月发的智能体产品，强调”从需求到部署，一个 agent 跑完”。Replit 的优势是它本来就有完整的云端运行环境，agent 跑完直接就在云上跑起来。Base44、Mocha、Glide 这些更新的入局者，定位偏企业内部小工具，主要解决”5 个人的小团队想要一个内部表单或仪表盘”这种长尾需求。

把整条外行赛道压一句：Vibe Coding 已经把造 demo 的成本砸到地板。一个有产品 sense 的人凭一个想法做出来一个能展示的 demo，过去要一周以上，现在一个下午就行。但从 demo 到真正能用的产品中间还隔着整个软件工程行业的活，这个鸿沟留到第三章细说。

三、展望未来

3.1 做 App 是个系统工程， AI 编程只解决了一环

现在经常可以看到这样的口号，让不懂一行代码的外行，可以直接做出一个app，躺着数钱。我们先不说需求端，我们来看技术方面。

外行直接造 App 这个口号，有真的部分，也有需要打折的部分。先看一眼以前在公司里做一个像样的功能是什么样。

软件工程把做软件这件事拆成几个阶段，是有正式标准的。最权威的一份是 ISO/IEC/IEEE 12207《系统与软件工程：软件生命周期过程》，1995 年首发，2017 年更新到现行版，给软件全生命周期定义了几十个标准过程。各国大学的软件工程教材讲的也是这套生命周期：需求、设计、开发、测试、上线、运维。

国际标准之外，国内大厂也把这套生命周期落地成了自己的工程规范，且不少是公开的。阿里巴巴 2017 年发出《阿里巴巴 Java 开发手册》（项目代号 P3C），分编程规约、异常日志、单元测试、安全规约、工程结构、MySQL 数据库六大维度，配套 IDE 插件累计下载超过 160 万次。美团技术博客（ tech.meituan.com）专门写过大量灰度发布、故障复盘、产品上线流程的实操文章。国外更彻底的是 GitLab，把整个公司的研发流程开源做成公开手册（GitLab Handbook，几十万字）。这些材料让外部读者能直接看到大厂内部的研发节奏，骨子里都遵循同一套生命周期。

一个像样的功能在大厂里走的流程是这样：需求阶段（PRD + 评审）、设计阶段（UI/UX + 评审 + 技术方案 + 技术评审）、开发阶段（任务拆分 + 前后端开发 + 联调 + 代码评审）、测试阶段（自测 + QA + bug 循环 + UAT）、上线阶段（灰度 + 全量 + 监控应急）、验证回收（数据验证 + 复盘 + 归档）。一个像样的需求走完这条流程，少则两周，多则两三个月。

这条流程每一环都是在堵一个真实的坑。PRD 评审堵的是做出来不是想要的，技术评审堵的是架构上选错了半年后推倒重来，代码评审堵的是代码能跑但维护不了，QA 堵的是上线就崩，灰度堵的是出 bug 影响所有用户。每一环都是过去几十年血泪经验的沉淀。

回到 AI 这边，它今天能直接吃掉的环节其实不止写代码这一个。把每个阶段、每个子环节里 AI 真正能切多少，挨个过一遍。

加载图片

50 KB

3.1.1 需求阶段（ PRD + 评审）

PRD 这一段 AI 已经能做不少活：把零散想法整理成结构化文档（背景、用户画像、流程图、验收标准），扫已有功能找冲突点，列边界条件，甚至自动生成数据埋点和 A/B 实验设计。但 PRD 评审会本身 AI 替不了。评审要 4 到 6 个不同岗位的人坐下来吵：业务方关心 ROI 和发布节奏，产品关心用户体验，工程关心实现成本和技术债，QA 关心可测性。这种跨岗位的拉锯和共识形成，需要的是组织协调，AI 帮不上忙。

3.1.2 设计阶段（ UI/UX 和技术方案）

设计阶段实际有两条线：UI/UX 和技术方案，每条线各带一次评审。

UI/UX 这条线被 AI 吃得最透。v0、Figma AI 这类工具几分钟就能从一句话生成一个能跑的 React 组件，样式系统都能配好。设计评审里的形式化检查，比如风格有没有对齐、组件有没有复用已有库，AI 也能跑一遍。但一个交互到底符不符合品牌调性、用户走完这一步下一步会做什么，这种判断还是要资深设计师拍板。

技术方案这条线 AI 也已经很有用。给它一段需求，它能列出三套候选架构，把吞吐、延迟、成本对比清楚。但最后选哪一套要人来定，因为选型背后是一堆 AI 不知道的组织约束：团队熟悉哪个栈、有什么合规要求、对外承诺了什么 SLA、关键人员稳不稳。技术评审会上的辩论更是如此，往往是为什么不用 X、为什么不用 Y、为什么这次必须做 Z，每一句背后都有一段团队历史。AI 没坐过这些会，跟不上节奏。

3.1.3 开发阶段（编码与评审）

开发阶段是 AI 真正的主战场，但里面也有 AI 切不动的硬骨头。

先说 AI 能直接做的。任务拆分这一步 Claude Code 已经能从 PRD 直接生成 issue list 和依赖图。前后端开发是 Cursor + Claude / Codex 的核心使用场景，资深工程师里 2 到 10 倍的效率提升是普遍体感。联调（前后端打通接口）AI 能自动起 mock server、跑契约测试、扫接口签名不一致。代码评审 AI 也能做静态分析、规约检查、潜在 bug 标记。

但代码评审里有一层 AI 跟不上：架构判断。这次改动会不会让模块边界变模糊、这套抽象未来三年好不好维护、这个解耦在团队的下一阶段规划里是不是合理，这种 review 还是要资深 reviewer。

更硬的骨头是跟外部世界打交道的那一段。要接一个第三方 API（微信支付、Stripe、Google Maps），AI 能把调用代码写得很标准，但 API key 怎么申请、商务怎么谈、KYC 怎么过、回调地址怎么备案，这些步骤要真人去走流程。要做权限管理（OAuth、SSO、公司内部 IAM、云上 RBAC），AI 能写规则和代码层，但谁该有什么权限、合规和 GDPR 是不是过得了、出事谁负责，仍然是组织决策。这一类卡点跟 3.2 节要说的”非程序员造 App”碰到的问题是同根源的。

整体看下来：开发阶段纯代码部分 70% 到 80% 的活 AI 能直接做，剩下的 20% 到 30% 一部分是架构判断和疑难调试，另一部分是接外部 API、做身份和权限这类需要走人工流程的硬骨头。

3.1.4 测试阶段（自动化与人工验收）

测试阶段是 AI 的第二大主战场。

自测和 QA 这两步 AI 几乎全包。自测里 AI 自动生成单元测试和集成测试，覆盖率比人手写的高很多。QA 阶段 AI 能跑全量回归、做 fuzzing（用随机输入压测程序找崩溃点）、扫边界条件。fuzzing 以前因为成本高、回报低很少做，AI 把它的边际成本降到几乎为零。

bug 循环 AI 也已经在闭环。从错误堆栈定位代码、生成修复 patch、提交 PR，不少团队 80% 的 P3 / P4 级 bug 在 AI 流水线里直接走完。

UAT（用户验收测试）AI 替不了。这一步要真用户在真场景里点一遍，看产品和用户预期对不对得上。代码正确性的所有测试 AI 都能跑，但产品贴不贴用户需求，只有用户自己能判断。

3.1.5 上线阶段（执行与决策）

上线阶段分两段：执行和决策。

执行这一段 AI 已经能完整接管。灰度发布的细节（按比例放量、按地域放量、按用户 cohort 放量）和全量发布的步骤都能自动跑。监控告警、异常检测、针对预定义场景的自动回滚也都已经成熟。

决策这一段还是人在拍。灰度跑到 10% 之后核心指标抖动了，要不要继续推、要不要 rollback、要不要先 hold 住调查，每一个动作都要权衡：往前推一格 5% 的回滚成本，往后推一格全量的风险。这种 go/no-go 决策光看仪表盘是拍不出来的，背后还有业务节奏、合作方协调、市场窗口一堆 AI 看不见的因素。

更难的一类是没见过的事故。第三方依赖挂了引发级联故障、某个区域机房断电、某次安全事件需要紧急下线，这种没在 runbook 里的情况，处置方案还是要 oncall 工程师来定。

3.1.6 验证回收（数据验证 + 复盘 + 归档）

数据验证 AI 可以拉指标、生成可视化、给三到五种可能的归因解释，但”这个功能转化率没达到预期，是用户不需要、还是入口太深、还是定价错了”这种判断要产品经理结合定性数据来决定。复盘会 AI 替不了，复盘的核心是组织学习：这次教训怎么变成下次的工程规范、谁该承担什么责任、流程要不要改，这是人对人的事。归档环节 AI 完全可以自动化，文档结构化、链接知识库、生成检索索引，这些是 AI 干得最干净的活。

把六个阶段连起来看一张图。

加载图片

59 KB

今天 AI 在整个研发流程里能直接替的工作量，按子环节加权大概是 50% 到 60%。开发和测试两个阶段占的份额最大，各自有 70% 到 85% 的活 AI 能直接做；需求、设计、验证回收这几段，AI 能切的子任务多在 30% 到 50%；上线阶段里执行部分几乎 100% 自动化，但 go/no-go 决策仍是 0%。

换个说法：AI 已经把每个阶段”做完”的成本拉到很低，每个阶段”拍板”的那一下还得人来。

剩下的 40% 到 50% 的人工部分，再往下能不能继续被 AI 吃掉？这是判断未来若干年走向的关键问题。里面分两类。

第一类是技术上还差一截、但有路可走的：基于团队历史的架构选型、复杂归因、跨多文件 / 多仓库的疑难调试、未见过事故的应急处置。这些今天 AI 做不到，主要是上下文不够长、对组织语境不熟悉、对长期演进缺乏概念。模型继续涨上下文、加上长期记忆、在团队代码库里持续训练，五年内有希望吃掉这里面的一大半，把流程整体推到 70% 到 80% AI。

第二类是技术再涨也吃不动的：跨人共识、承担责任、对接真实世界（KYC、商务谈判、合规审批、法律责任）。这些卡点的根子在制度，跟模型能力没关系。要 AI 真正接手，前提是 AI 能作为法律主体存在，能签合同、能持账户、能为后果负责。已经有创业公司在做”为 AI agent 持有账号、承担责任、买保险”的法律实体，但这条路涉及法律、监管、社会接受度，时间窗口是 5 到 10 年。一旦走通，剩下的 20% 到 30% 也会被吃掉，软件研发就会进入下一个范式：人只剩出题人和最终拍板人两个角色，其它全是 AI。

短期内（未来 2 到 3 年）整个流程从现在的 50% 到 60% AI 推到 70% 到 80% AI 是大概率事件，途径是模型能力持续进步加上工具链填齐。要再往上走到 90% 以上，模型本身已经不够用了，得靠制度突破。

这件事有学术背书。IEEE 的 SWEBOK V4（2024 年 10 月发布的软件工程知识体系）列出 18 个知识域，AI Coding 主要覆盖其中的”软件构造”和部分”软件测试”，剩下 16 个知识域（需求工程、软件架构、软件安全、软件维护、软件配置管理、软件工程经济学等等）AI 只能做辅助。把每个 App 当作一棵树，AI 砍下了最高最壮的一根树枝，剩下的根、干、其他枝条还得人来扶。

工程师视角下，这个迁移已经在重新定义人和机器的分工。我自己的体感是这样：人定义问题、把关结果、处理复杂部分；AI 写代码、跑测试、修常规 bug。从 2022 到 2026，code review 的粒度也在变。2022 年程序员每行代码都自己看；2024 年看的是 PR 级别的 diff；2026 年越来越多场景下，看的是 issue 级别的结果（这个 bug 修好了吗，这个功能跑通了吗）。工程师没失业，但工作内容里写代码这部分的占比快速下降，判断、审查、验收的比重上来。

3.2 是否会有”外行一键造 App ”的神器

回答这个问题，先把上一节那张大厂研发全流程图拿过来，对照看一遍：对于一键造 App 的场景，哪些环节其实根本不需要 AI 替，可以直接省掉。

需求阶段 :

几乎可以全省。你一个人就是需求方加决策方加用户，脑子里有想法直接说就行，不需要 PRD 文档化、不需要跨部门评审、不需要业务对齐会。

设计阶段 :

大幅简化。UI/UX 让 AI 自动生成，接受厂商的默认风格就行，没有品牌调性的拉锯。技术方案这一段在 Vibe Coding 工具里被默认死了：Lovable 给你 Next.js + Supabase， Bolt.new 给你 WebContainer + 内嵌 Vite，你没得选，也不用选。技术评审会因此整个消失。

开发阶段 :

保留，但只剩 AI 写代码这一段。没有任务拆分会，没有联调（前后端是同一个生成的栈），没有代码评审（你自己看跑不跑得起来就行）。

测试阶段 :

大幅退化。自测等于你自己点几下，QA 和 bug 循环退化成”我用着舒不舒服”，UAT 在自己用的场景下根本没有这一步。Lovable 直接在浏览器里跑，崩了重生成。

上线阶段 :

几乎全省。一个人用谈不上灰度，全量等于”自己打开网址访问”，监控应急对应不到这个规模。出问题重新生成一次就完事。

验证回收阶段 :

也基本不存在。没数据可验证（用户就你自己），没复盘会议，归档让 AI 自己干。

省下这些之后，一键造 App 的真实流程就剩三步：你描述需求 → AI 生成加部署 → 你自己用。这条精简流程能不能 100% AI 化？答案要分两类场景看，每一类还要再分一层。

3.2.1 自己用的、一次性的、内部的小工具

这一类今天确实已经基本 AI 化了。但内部其实分两种架构。

最干净的一种是纯前端、跑在浏览器里、关掉就没的。Anthropic 的 Artifact、OpenAI 的 Canvas、Vercel 的 v0、 Bolt.new 都属于这种。它们生成的工具没有后端、没有数据库、没有用户登录，就是一段 HTML + JavaScript 在浏览器里跑，stack 简到只有 React + Tailwind 一两个文件。临时计算器、UI 原型、数据可视化、文档格式转换是典型场景，今天确实是一句话描述、几分钟拿到、连账号都不用注册，AI 一条龙包圆。

复杂一点的是有简单后端、能存数据、可能多人用的。Lovable 的”前端 + Supabase”组合是典型代表，stack 大概是 Next.js + Tailwind + Supabase（数据库 + Auth）+ Vercel 部署，跟我自己在 indie 项目里用的标准技术栈基本一致。这一类的代码 AI 能 100% 写，但人还要做几件 dashboard 操作：去 Supabase 注册账号、新建 project、复制 URL 和 key；去 Vercel 把 repo 接进去、粘环境变量、点 Redeploy。AI 打不开浏览器控制台，所以这一段卡在那里。个人记账带云端同步、小型内部审批流、几个朋友共用的协作小工具属于这一档。

两种加起来，个人和内部小工具的场景今天已经接近 95% AI 化，剩下的 5% 是 Human 在控制台粘几次 key。

3.2.2 给别人用的、能上 App Store 或者能收钱的正式 App

这一类的现实情况是：AI 能把代码 95% 以上写完，人主要做的是控制台点击和审批走流程。展开看，控制台点击里又分技术性的和制度性的两层。

技术性那一层，AI 写代码、人配凭证。一个标准的 indie App stack（Next.js + Supabase + Stripe + Resend + Vercel）跑起来，AI 这边做的事大约是：写所有 TypeScript 代码、写 Prisma schema、跑 db push、写 Stripe checkout 和 webhook 处理、写邮件模板、装依赖、git push 触发部署。人这边要做以下的 dashboard 操作（只是一个范例）：

Supabase 建 project、配 OAuth providers（粘 Google / GitHub 的 Client ID + Secret，这俩还得自己去 Google Cloud Console 和 GitHub OAuth Apps 申请一遍）、配 redirect URL
Vercel Import GitHub repo、粘环境变量、改 Build Command、改完 env 手动 Redeploy
Stripe 建 Product、拿 Price ID、上线后建 Webhook endpoint、复制 Webhook Secret 粘回 Vercel
Resend 拿 API key、验证自己的发件域名

接外部 API 走的也是这条路。AI 把调用代码写好，但 API key 怎么拿、商务怎么谈、webhook URL 怎么备案、回调地址怎么注册，要人去对应平台的控制台走流程。AI 今天打不开浏览器，绕不过去。

制度性那一层，是 AI 永远办不到的：

KYC 实名认证（得拿身份证加银行账号去注册主体）
业务资质（要在国内做支付，得 ICP 备案、营业执照、有时还要对接支付牌照）
法律责任（用户数据被泄、被骗、被侵权，得有人去承担）
App Store 上架（Apple、Google 不给 AI agent 开发者账号，每年的实名加年费要人）

两层加起来，给别人用的正式 App 今天大约是 90% AI 加 10% Human dashboard。”一句话造一个真 App”严格说做不到，但已经做到了”一句话加 10 次粘 key”造一个真 App。

这跟”外行直接造 App”那个口号对得上吗？大致对得上技术性那一层，对不上制度性那一层。一个完全没接触过编程的外行，理论上跟着 Lovable 加 Stripe 加 Vercel 的引导文档走，可以发出来一个能收钱的 SaaS。但前提是 ta 愿意去办公司、过 Stripe KYC、签合规文件、当法人。这一段跟 AI 能力没关系，看的是 ta 愿不愿意当老板。

3.2.3 未来两条路

那剩下的人工部分，再往下能不能继续被 AI 吃掉？分两条路看。

技术这条路负责吃 3.2.1 里剩的 5% 和 3.2.2 里技术性那一层的 10%。AI 自己还在快速吃掉精简流程里剩下的活：自动连支付、自动过 OAuth 授权、自动部署加域名加 HTTPS、自动监控自动回滚。更关键的是，浏览器 agent 已经走到了产品化阶段，比如 Anthropic 的 Computer Use、OpenAI 的 Operator，让 AI 能代为登录 Supabase、Vercel、Stripe 这些控制台、点点点、粘 key、Redeploy。一两年内，3.2.1 那两种自己用的小工具会基本 100% AI 化；3.2.2 里 10 几次 dashboard 操作的大半也会被浏览器 agent 接管，正式 App 的技术性那一层从今天的 90⁄10 推到 95⁄5 是大概率事件。

制度这条路要慢得多，负责吃 3.2.2 里制度性那一层。AI 法人能不能成立、能不能持账户、能不能签合同、出事怎么追责，这些是法律和监管要解决的问题，跟模型能力没关系。已经有创业公司在做”为 AI agent 持有账号、承担责任、买保险”的法律实体，但要走通，需要立法、判例、社会接受度同时到位，时间窗口是 5 到 10 年。一旦走通，给陌生人用、能收钱、能上架的真 App 也会被一键造工具吃掉，软件分发的整个版图就要被重写。

一句话：自己用的小工具今天已经一键搞定；给别人用的真 App 今天做到一句话加 10 次粘 key，1 到 2 年内浏览器 agent 把粘 key 那一段也吃掉，5 到 10 年后 AI 法人成立，最后的制度卡点也才被跨过去。

加载图片

234 KB

3.3 这一波 AI 编程会重塑 PC / 手机 App 生态吗

会，但重塑的方向跟很多人的直觉相反。先把几条变量摆清楚。

3.3.1 供给 100 倍，需求还是 1 倍

3.1 和 3.2 已经把”造一个 App 的门槛”讲透了。今天 Lovable 加 Vercel 加 Stripe 这一套下来，过去要 5 个人 6 个月的活，1 个人 1 个周末就能跑出来。供给侧的产能至少翻 10 到 100 倍。

但需求侧没动多少。每个人每天还是 24 小时，平均盯着手机的时间已经 5 个小时左右，再上去基本到顶。一个人手机上常用的 App 就是 10 到 20 个，装的 60 到 100 个里大半冷启动一次就再也没点过。这是过去十年很稳定的结构。

供给翻 100 倍、需求不变，结果只能是中间那层被拍扁。具体哪一层会被拍扁，要分类型看。

最先扛不住的是工具型长尾 SaaS。报销系统、内部仪表盘、个人记账、记单词、计步器、临时表单生成器，这些过去靠卖年费活着的小工具，今天用户自己用 Lovable 半小时就能撸一个。SaaS 公司收 100 美元一年还在解释功能，AI 生成的版本免费且更贴合自己的需求。这一层大面积消失只是时间问题。

垂直行业 SaaS 复杂一点。给律所做的合同管理、给医院做的排班、给小学做的家校沟通，这些有行业知识沉淀的产品没那么容易被一句话生成。但它们也会承压：客户内部的 IT 部门可以拿同样的 AI 工具生成一个内部版本，不再付月费。这一层会被价格战打到很薄，可能砍掉一半的市场容量。

社交、内容、电商、地图这一层基本不动。这一层的价值不在代码，下一节单独说。

3.3.2 头部 App 不会被取代，反而更强

微信、抖音、淘宝、Google Maps、Instagram、WhatsApp 这一类头部 App，AI 编程动不了它们的根。原因有四条。

网络效应。微信的价值 90% 来自其他 10 亿用户在上面，你做不出一个只有你一个人用的微信。Lovable 一个晚上能给你生成一个长得像微信的 App，但里面没有任何一个你想聊天的人。

数据沉淀。抖音过去 8 年攒下来的用户行为数据是它推荐算法的真正护城河。一个新的”AI 生成的短视频 App”零冷启动，没有任何数据，推荐系统从第一天起就比抖音差几个数量级。

内容和供给生态。淘宝有几百万商家、上亿 SKU、稳定的物流和支付。AI 生成的”我的购物 App”打开里面什么都没有。

分发入口。Apple、Google、Meta、ByteDance 把着用户每天打开手机时第一眼看到的位置，这一层 AI 编程根本碰不到。

更反常识的是，AI 编程会让这些头部 App 的优势更深。它们内部用 AI 提速 10 倍迭代，用 AI 处理客服、做推荐、生成内容、做反作弊，规模优势加上 AI 让产品质量进一步拉开。过去一个新创业者还能靠”做得比微信好”这种梦活几年，AI 编程时代连这个梦都没了。

3.3.3 长尾 App 退化成按需生成的 capability

把 3.3.1 和 3.3.2 合起来推一格，几年后的手机格局可能是这样。

头部 App 大约还是 20 到 30 个，跟今天差不多，但每个都更强、更难被替代。微信、抖音、淘宝、银行 App、地图、邮箱、相机这一类，仍然是装着、长期用、跨年攒数据的形态。

中间那一层（工具型 / 单功能 / 长尾）从今天的几十个塌掉，剩下不到 10 个。日历、笔记、密码管理这种个人数据持续累积的还会留，但绝大多数小工具被替代。

替代它们的是临时生成的 Capability。你跟手机里的 AI 助手说”我想记一下这次旅行的开销”，AI 现场给你拼一个表单加表格加简单图表，旅行结束你就把它删了，下次旅行再生成一个新的。Anthropic 的 Artifact、OpenAI 的 Canvas、Apple Intelligence 的 App Intents 已经在做这件事，只是还没普及到所有用户。

这种 Capability 的特点是：用完即弃、个人定制、零安装、无月费、不进 App Store。它跟今天的 App 是两种完全不同的形态。

3.3.4 重构后的生态：三层结构

把上面的拼起来，未来几年的 App 生态大概是这样的三层。

头部层。微信、抖音、淘宝、Apple、Google、Meta 这些。它们靠网络效应、数据、内容生态站稳。AI 编程让它们更强，没让它们变弱。这一层的玩家数量在收缩，每家份额在变大。

助手层。这一层会冒出来。用户的入口从打开某个 App 变成跟 AI 助手说一句话。AI 助手会调用底层模型现场生成一次性的小工具，或者调用某个头部 App 的 API 做事。这一层目前的雏形是 ChatGPT、Claude、Apple Intelligence、Google Gemini 这类通用助手。谁能占住这一层是未来几年最大的战场，因为它有可能蚕食 App Store 的分发地位。

模型层。Anthropic、OpenAI、Google 三家加上 DeepSeek、阿里 Qwen、字节豆包，靠卖 token 和能力赚钱。AI 编程的繁荣首先让这一层赚到钱，因为每一次 Capability 生成、每一次助手调用都在烧 token。

这个新生态对几类玩家的意义不一样。头部 App 平台还在涨，模型层在涨。中间冒出来的 AI 助手层是兵家必争之地，可能会有 1 到 2 家新巨头出来，也可能被现有的几家瓜分。原来做长尾 SaaS 的公司最难过，除非能赶在生态成型前转型成助手层的 Capability 提供商，或者垂直深耕成行业内的”小头部”。

普通人的视角：手机里仍然有 20 到 30 个常用 App，跟今天差不多；多出来一个 AI 助手随叫随到给你拼临时工具；少了一堆装了一次再也没打开过的鸡肋 App。打开手机的第一动作从找那个 App 的图标变成跟 AI 说一句话，这是 iPhone 之后入口形态最大的一次迁移。

加载图片

82 KB

四、结语

把整篇文章压成几条能记住的话。

原理。

AI 会写代码，靠两件事的合成。一件是代码训练把通用大模型整体推到了一个新台面，让”先把问题分步、再每一步成立”这种思维方式渗进了模型的默认行为；这件事最反常识的一面是，代码训练的真正受益者远不止写代码这个任务，整个语言模型的逻辑能力都被它拉高。另一件是 RLVR（基于真实执行反馈的强化学习），让模型从”会写”训到”能写对”，在过去两年把代码能力推上了今天的水平。代码的三个特性（规律性强、有客观对错、自带文档）决定了它天然适合被模型学会，也是 AI 整体变聪明的核心训练成分。

公司发展史。

从 2021 年 7 月 OpenAI 把 Codex 塞进 GitHub Copilot 的肌肉记忆，到 2022 年 11 月 ChatGPT 起飞顺手把 Stack Overflow、Kite、Codecademy 这些前 AI 时代的程序员外脑生态拍扁，再到 2024 年 10 月 Claude 3.5 Sonnet 升级版让”AI 真的能写代码”第一次成立、Cursor 的 codebase indexing 定义新的 IDE 范式，再到 2024-2025 智能体转向、最近一年 Codex CLI 加 Claude Code 加 Cursor 三家头部之间几十亿美元 ARR 的竞速。国内字节 Trae、阿里通义灵码、百度文心快码、智谱 CodeGeeX 几家平行起步；外行赛道 Lovable、 Bolt.new、v0、Replit Agent 把”造 demo”的成本砸到地板。这五年是 AI 产品形态进化最快的领域之一。

系统工程。

软件工程是一条 ISO/IEC/IEEE 12207 标准定义、阿里 P3C 和美团技术博客落地过、SWEBOK V4 用 18 个知识域涵盖的完整生命周期：需求、设计、开发、测试、上线、验证回收。AI 今天能直接替的工作量，按子环节加权大约 50% 到 60%。开发和测试两个阶段被 AI 吃得最透（各 70% 到 85%），需求、设计、验证回收这几段 AI 能切的子任务多在 30% 到 50%。剩下 40% 到 50% 的人工部分里，技术能吃的还有一截（架构选型、复杂归因、疑难调试），几年内有希望把整体推到 70% 到 80% AI；制度性那一层（跨人共识、承担责任、对接真实世界）则是法律和监管要解决的事，跟模型能力没关系。软件工程的复杂性被重新分配了，没有消失。

一键造 App。

自己用的、一次性的、内部的小工具今天已经基本一键搞定（95% AI 加 5% 控制台粘几次 key）。给别人用的、能上 App Store 或者能收钱的正式 App 今天大约是 90% AI 加 10% Human dashboard，能做到”一句话加 10 次粘 key”造出来，但前提是 ta 愿意去办公司、过 KYC、当法人。再往下走两条路：1 到 2 年内浏览器 agent（Computer Use、Operator）把粘 key 那段也吃掉；几年后 AI 法人若能成立，剩下的制度卡点才会被跨过去。

生态。

供给端 AI 编程让产能翻 10 到 100 倍，需求端基本没动，结果是中间层被拍扁：长尾 SaaS 大面积消失，垂直行业 SaaS 被砍掉一半。头部 App（微信、抖音、淘宝、Apple、Google、Meta）不会被取代，反而靠网络效应、数据、内容生态、分发入口加上 AI 提速变得更强。长尾 App 退化成按需生成的 Capability：用完即弃、个人定制、零安装、不进 App Store。几年后的格局可能是三层叠在一起：头部 App 平台层、AI 助手加 Capability 层、模型层。打开手机的第一动作从找 App 图标变成跟 AI 说一句话，这种入口形态的迁移，强度可以跟 iPhone 那一次相比。

下一步的位置。

这场新分工里有几条路可走：当一个能跟 AI 协作的工程师，承担越来越多的判断、审查、验收角色；当一个能驾驭 AI 工具解决真实业务问题的产品人，把哪些流程让 AI 替、哪些环节由人拍板想清楚；当一个用 AI 把过去十人才能做的事一个人做完的创业者，赌一把 AI 助手加 Capability 这个新生态的位置；或者转型做行业内的”小头部”，垂直深耕到 AI 编程复制不了的领域知识里去。每条路都比五年前宽得多，但”白手起家做下一个微信”这种梦确实没了：AI 编程让头部更深、让长尾几乎被替代，中间冒出来一个全新的 AI 助手层等着被占住。

一句话：AI 让造软件这件事的下限大幅抬高，上限仍由人决定。新版图里最大的赢家是头部 App、模型公司，加上少数能在助手层占住位置的玩家，剩下的人要在新分工里找到自己的杠杆点。

作者其它文章

本文参考文献

Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet (Anthropic, 2024-10) - Claude 3.5 Sonnet 升级版 49% 数据
SWE-bench Verified Leaderboard (BenchLM) - 2026 年 4 月 SWE-bench Verified 排行
SWE-bench Pro Leaderboard (Scale) - SWE-bench Pro 排行榜
Why 46% Beats 81%: SWE-bench Pro Leaderboard (Morphllm, 2026) - SWE-bench Pro vs Verified 解读
OpenAI Codex (AI agent) - Wikipedia - Codex 历史 + CLI 重启时间线
OpenAI Codex Statistics 2026 (Gradually) - Codex 300 万周活
Claude Code Statistics 2026 (Gradually) - Claude Code 4% GitHub 提交
Cursor's Anysphere nabs $9.9B valuation (TechCrunch, 2025-06) - Cursor 早期数据
Cursor in talks at $50B valuation hitting $2B ARR (TNW, 2026-04) - Cursor 最新估值
As Lovable hits $200M ARR (TechCrunch, 2025-11) - Lovable 增长曲线
Guide to the SWEBOK v4.0 Has Been Released (basicinputoutput, 2024-10) - SWEBOK V4 发布与 18 个知识域
SWEBOK Evolution (IEEE Computer Society) - SWEBOK 官方信息
CodeBERT GitHub (Microsoft) - CodeBERT 仓库与时间线
CodeT5 GitHub (Salesforce) - CodeT5 仓库与时间线
ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes - 国际软件生命周期标准
阿里巴巴 Java 开发手册（P3C） - 阿里 2017 年公开的工程规约 + IDE 插件，六大维度
美团技术团队官方博客 - 灰度发布、故障复盘、产品上线流程的实操文章
GitLab Handbook - GitLab 公司全流程开源研发手册

纯编程岗位已完，能做可验证奖励强化学习的都会完

Wed, 20 May 2026 16:09:08 CST

为什么 AI 会先吃掉程序员，而不是产品经理

如果你还在用职业名判断 AI 风险，先停一下。

姚顺宇在访谈里给过一个反直觉判断：AI 最先高速改变的，不一定是人类觉得简单的工作，而是反馈最清楚的工作。

这个判断落到职业上，最扎眼的例子就是程序员。

过去很多人以为，AI 会先替代那些重复、低门槛、标准化的工作。客服、简单文案、资料整理，听起来都比程序员更容易被自动化。

程序员是高门槛脑力劳动，写的是复杂系统，按这个直觉，它不该这么早站到第一排。

结果最早被 AI 工具改写工作方式的，偏偏是代码世界。Cursor、Claude Code、Copilot 和各种代码智能体（coding agent），让很多人第一次感觉到，AI 不只是会聊天，它真的开始接一段工作了。

但姚顺宇恰恰把 AI 编程（AI coding）拿出来当第一批爆发的 AI 原生场景。原因不在写代码低端，也不在产品经理更高级；关键是代码世界有测试、编译、运行结果、日志和版本记录。

模型做完以后，环境会告诉它哪里错了。

AI 不按职业声望排队，它先进入那些能被清楚定义、快速验收、低成本纠错的任务。

程序员只是第一排。AI 盯上的，是所有职业里能被拆成输入、输出、标准和反馈的可验收执行层。

职业替代榜单太粗了

这几年，关于“AI 会先替代谁”的讨论很容易变成一张职业榜单。

程序员排第几，产品经理排第几，设计师、运营、咨询、律师、会计又排第几。这个游戏好玩，因为它简单，像看 K 线图。每个人都想知道自己的职业是不是已经破位，隔壁职业是不是先跌。

但职业名太粗了。

同样叫程序员，有人每天接明确需求，改一个局部函数，跑一下测试，然后提代码；也有人要理解业务目标，拆系统边界，决定哪些依赖不能动，最后对整个系统结果负责。

同样叫产品经理，有人按模板写产品需求文档（PRD）、整理会议纪要和竞品截图；也有人要判断用户到底卡在哪里，定义指标，协调资源，承担版本取舍。

这两组人被同一个职业名盖住了。你说“程序员会不会被替代”，或者“产品经理会不会被替代”，其实像是在问“车会不会坏”。卡车、赛车、出租车、自行车都被塞进一个词里，答案当然会很混。

姚顺宇那条判断有用的地方，就在这里。它把问题从职业名换成了任务结构：

一个任务做完以后，环境能不能告诉模型做对了没有；
这个信号能不能被重复收集、训练和纠错；
失败以后，能不能低成本再试一次。

这件事有没有成败信号，可以叫任务可评价性。成败信号越清楚，AI 越容易练；反馈越脏、越晚、越主观，模型就越难稳定进步。

所以 AI 不认识你的岗位头衔。它不关心你在公司系统里叫工程师、产品经理、运营，还是策略分析师。

它只看这件事能不能被定义，能不能被执行，能不能被验收，失败以后能不能继续修。

代码世界像一座提前铺好的练习场

写代码对人很难，但对训练系统很友好。

这句话听起来有点别扭。因为我们习惯把“人觉得难”直接等同于“机器也应该觉得难”。但模型学习一件事，和人类职业声望不是同一套坐标。

对模型来说，难点不只在任务本身有多复杂，还在于环境能不能把错误及时推回来。

代码世界恰好在这件事上非常慷慨。你写完一段代码，能不能编译，测试能不能过，类型检查有没有报错，运行结果对不对，日志里有没有异常，性能有没有下降，版本记录里改了哪些文件，这些信号都会露出来。

很多时候，它们不是人类主观评价，而是工具链直接给出的反馈。

一个代码智能体修改了某个函数，测试失败了，它至少知道失败在哪里；命令跑不通，它能看到报错；依赖不对，它能读依赖配置文件；改坏了别的模块，版本控制和测试能把影响暴露出来。

这个过程当然还需要人审查，但它已经比很多知识工作更接近“做一步，看反馈，再修一步”的闭环。

再往外看，GitHub 和开源生态又给了代码世界大量任务、上下文和修改历史。一个模型不只是看到最终答案，还能看到别人怎么提交议题（issue）、怎么改缺陷（bug）、怎么做代码审查（review）、怎么围绕一个仓库（repo）迭代。

仓库本身就像一台状态机，文件、提交、测试、讨论和文档把上下文记录下来。

好代码当然也有争议。架构是否优雅、命名是否合适、抽象是否过度，这些不可能完全自动判断。但相比很多产品判断，代码仍然更容易形成可重复的质量标准。

能不能运行，是否通过测试，是否引入明显回归，是否符合接口约束，这些东西足够让模型反复练。

所以程序员先站到第一排，并不是因为这份工作低端。恰恰相反，软件工程复杂到一定程度，才给了 AI 足够多的可学习信号。

代码世界像一座提前铺好的练习场：有题目，有上下文，有工具，有错误提示，有回滚，有复盘。

这也解释了为什么代码智能体的体感来得这么快。关键不只是模型“会写代码”，还在于它被放进了一个能持续纠错的环境。

写错了，能看到；看到了，能改；改完了，还能再跑。

产品经理不是安全，只是反馈更脏

那是不是产品经理就安全了？

不是。

这个误读很常见：程序员先危险，产品经理暂时没事。这个判断太便宜，也不符合姚顺宇的原意。

产品经理工作里有大量结构化子任务，都会被 AI 改造：

写产品需求文档；
整理用户访谈；
总结会议；
生成竞品分析；
做数据初筛；
拆需求列表；
写埋点方案；
生成原型说明。

这些事情本来就有模板、有输入、有输出、有交付格式。它们不可能长期停在纯人工状态。

这里有个很残酷的分界。

你是在写文档，还是在定义问题？你是在整理别人已经说清楚的东西，还是在把没人说清楚的东西变成判断标准？

前者会越来越像执行任务，后者才更接近产品经理的责任位置。

但姚顺宇说难的，是完整产品判断。他在访谈里反复指向一个问题：好产品的奖励信号（reward signal）不清楚。

翻译成人话，就是你做完一个产品决定以后，很难立刻知道它到底对不对。

一个功能上线以后，用户会不会用，为什么不用，是因为入口太深、文案不清楚、需求本身不成立，还是因为市场时机不对？

一个留存指标变了，是功能带来的，还是渠道、活动、季节、竞品、价格、品牌一起搅出来的？

一个产品方向看起来失败，是判断错了，还是资源没跟上，还是组织执行变形了？

产品反馈经常晚、脏、主观。晚，是因为它需要时间显现；脏，是因为混进了太多变量；主观，是因为用户心理、审美、组织目标和商业取舍都会进入判断。

做出来以后，大家才知道它好不好，而且经常不是一眼就知道。

所以产品经理的护城河不是写文档，也不是开会。文档会被生成，会议会被总结，竞品会被整理，数据会被初筛。

产品经理（PM）难被完整训练的部分，是把模糊目标变成可验证的问题、标准和取舍。

程序员和产品经理的差异，不是“谁会被替代，谁不会”。更准确的说法是：代码世界更早暴露了未来所有知识工作的重构方式；产品世界的核心判断更难训练，但它的外围执行层一样会被重构。

AI 提效以后，工作未必变少

很多人以为，AI 写代码以后，程序员会轻松一点。

这个期待很正常。过去写一个功能要两天，现在半天能做出来，剩下的时间似乎应该还给人。你可以早点下班，可以多想一会儿架构，可以把拖了很久的文档补上。

听起来挺好的。

但姚顺宇谈 AI 编程时，给出的体感更接近另一种结果：想法实现得更快以后，人会试更多方案，跑更多实验，做更多判断。

AI 提效先改变的，是尝试成本。尝试成本一降，高竞争环境通常不会把省出来的时间留给你，它会把更多尝试塞进同一天。

过去一个方案要两天，团队可能只试一个。现在一个下午能试三个，领导、同事、你自己都会自然地问：那为什么不多试几个？

过去一个 bug 修起来很费劲，大家可能先忍一下；现在模型能快速定位和修改，就会有更多边角问题被拉进待办。

过去没人敢开太多实验，因为每个实验都要人力；现在实验成本低了，判断成本就会上升。

工作没有少，只是从“手写实现”迁移到了“定义任务、组织上下文、审查结果、比较方案、承担验收”。

手从键盘上少敲了一些，脑子里的窗口反而开得更多。像系统里同时跑了很多线程，每个线程都很快，但你要负责调度、抢占、回滚和判断优先级。

这件事不会只发生在程序员身上。任何职业一旦能把执行切成小闭环，节奏都会被同一股力量推快。

运营可以更快生成活动方案，研究员可以更快整理文献，产品经理可以更快写需求和原型说明，创作者可以更快生成多个标题和版本。

每个环节都快一点，最后不一定换来轻松，可能换来更高的工作密度。

AI 未必先让人失业。它可能先让同一份工作变得更密。

这才是很多人已经感受到、但还没说清楚的变化。

AI 工具越好用，工作越不像消失，而像被压缩。原来一天里只能跑一个版本，现在一天里要看三个版本。原来一个人只要交付结果，现在还要解释为什么选这个结果、为什么不用另外两个结果、哪里可以继续迭代。

真正危险的是可验收执行层

问题不是程序员会不会消失。这个问题太大，也太容易吵。

有人会拿顶级工程师反驳：他们当然不会被替代；有人会拿初级岗位反驳：很多局部实现已经被模型接走了。

两边都能找到例子，然后继续争职业名。

更有用的问题是：一个职业里，哪些部分只是在明确标准下完成局部执行？

只接局部任务、写局部实现、无法定义需求、无法审查跨文件影响、无法承担系统验收的人，价值会被压缩。

这未必是因为他们不努力，更因为他们那部分工作越来越像可切分、可派发、可回收的任务。

模型只要能拿到足够上下文，再通过测试、编译、日志和代码审查得到反馈，就会不断逼近这部分执行层。

对应到产品岗位，风险也一样存在。

只按模板写 PRD、整理材料、做浅层竞品分析、把别人说过的话包装成页面的人，也会被压缩。因为这些任务可以被拆成输入、输出和格式要求，可以快速验收，也可以低成本重做。

姚顺宇那条判断在这里完成了职业转译：AI 优先进入的，不是某个职业名，而是职业内部可验收、可拆解、可低成本纠错的执行层。

再压一层，可以变成三个指标：

第一，验收速度：做完以后多久知道对错。
第二，纠错成本：错了以后能不能快速重来。
第三，责任位置：你是在执行标准，还是在制定标准。

前两个越高，第三个越低，风险就越近。

如果你的工作能被拆成输入、输出、标准和反馈，它就会开始变得像代码。

它比“程序员危险”更准确，也更难躲。因为它把所有职业都拉进来了。

运营里有像代码的部分，研究里有像代码的部分，咨询里有像代码的部分，设计里有像代码的部分，产品里也有像代码的部分。

所谓“像代码”，重点不在产出物是不是代码，而在任务结构：输入清楚，输出清楚，验收清楚，失败可以重跑，迭代成本很低。

只要这个结构出现，AI 就有了练习场。

职业名会给人一种安全错觉。你以为自己站在某个行业、某个岗位、某个头衔后面。

结果 AI 看见的是另一张图：哪些地方有清楚任务，哪些地方有反馈信号，哪些地方失败了能改，哪些地方上下文已经结构化。

人的价值会往反馈责任迁移

被压缩的是纯执行，不是所有人的价值。

问题在于，你有没有从执行层往反馈层迁移。

人的价值会往上游和下游迁移。上游是定义任务、组织上下文、设定边界。下游是审查结果、设计验收、承担取舍。

中间那段纯执行，会被越来越多的 AI 工作者接走。

这里说的 AI 工作者（AI worker），就是你能调度来做具体任务的 AI 工作者。它可能是一个代码智能体，也可能是一个能整理资料的助手，一个能跑分析的工具，一个能生成方案的模型。

它不是传统意义上的员工，但它会占据越来越多的执行位置。

程序员的迁移路径很清楚。过去的价值可能更多体现在手写实现上：理解需求、查上下文、设计方案、写代码、调试、交付。

AI 进入以后，这条链会重排。人要更擅长定义任务边界，给模型足够上下文，知道哪些文件不能动，知道结果如何验收，知道一个局部修改会不会影响系统其他部分。

这不是说写代码不重要。你看不懂代码，就很难审查模型写出来的东西；你不理解系统，就不知道模型哪里在胡来。

只是写代码不再是唯一中心。更稀缺的是你能不能组织一批 AI 工作者去做事，然后对结果负责。

产品经理的迁移路径也类似。PM 的价值不在于把一句需求扩写成三页文档，而在于把模糊目标变成可验证的问题、指标、实验和复盘。

你能不能判断“用户说想要”背后到底是什么需求；能不能把一个方向拆成几次低成本验证；能不能定义成功标准；能不能在数据不好看时判断是方向错了、执行错了，还是反馈还不够。

无法验收，就是 AI 协作里的最高优先级问题（P0）。

一个任务如果没有成败标准，就很难交给 AI 稳定执行。你让模型“做得好一点”，它只能猜。

你让模型“把这段接口改到测试通过，并且不改变现有调用方”，它就有了边界。

你让模型“写一个更好的产品方案”，它只能拼常识。

你让它“针对新用户首日留存下降，提出三个可在两周内验证的假设，每个假设要有指标、实验和失败判据”，它才有可能进入真正的协作。

下一阶段稀缺的，已经不只是会写代码或懂产品的人，而是能管理 AI 工作者的人。

这里的管理，和开会、发号施令、传统管理岗都不是一回事。

管理的意思是：能定义目标，分配任务，提供上下文，识别失败，更新标准，最后承担结果。

你不是因为站在 AI 上面而安全，而是因为你负责 AI 还不能稳定负责的那部分：目标、标准、取舍和验收。

不要先问学 AI 编程还是学产品

所以以后不要先问，学 AI 编程更安全，还是学产品更安全。

这个问题仍然停在职业名上。

它像问“我应该买科技股还是消费股”，但完全不看公司现金流、估值、行业周期和管理层质量。职业名只是股票代码，决定风险的是底层资产。

你可以先问五个问题。

第一个问题：你的结果能否自动验收？代码能跑测试，表格能对账，数据能校验，格式能检查，交付物能被明确打分，这类任务更容易被 AI 练习。

第二个问题：任务能否拆成小闭环？一个大目标如果能被拆成很多小任务，每个任务都有输入、输出和完成标准，就更容易被分配给 AI 工作者并行执行。

第三个问题：上下文是否结构化？文档、代码、数据、历史记录、接口、约束都清楚，AI 就更容易接手。

如果上下文全在某个人脑子里，模型很难稳定工作，但这不代表安全，只代表组织还没把上下文整理出来。

第四个问题：失败能否低成本纠错？失败以后能重跑、回滚、复盘、再试，AI 就会进步得更快。

如果失败一次成本很高，反馈很慢，风险就会晚一点暴露。

第五个问题：你是否拥有标准设定和取舍责任？

前四个答案越是“是”，而最后一个答案越是“否”，你手里的那部分工作就越容易站在第一排。

反过来，如果你能定义问题、组织上下文、设定验收、承担取舍，AI 进入以后，你反而会被放大。

你能让一个模型变成十个执行线程，让模糊问题变成可验证任务，让失败变成下一轮反馈。

这种人不会因为 AI 能写代码或写文档就消失，至少不会在同一条线上被简单压缩。

职业榜单还是会继续流行。原因也简单：它把复杂的任务风险压成身份命运，方便转发，方便站队，也方便让人暂时松一口气。

但真实的 AI 改造不按这个逻辑走。它不先问你是什么职业，而先问你的工作能不能被评价、复盘和重来。

姚顺宇的判断给这篇文章留下的，不是一张职业排名，而是一套更冷静的看法：

不要把职业名当护身符，也不要把某个工具当灾难本身。

AI 改造工作的顺序，更像是在寻找反馈最清楚的地方。

哪里能定义任务，哪里能观察过程，哪里能验收结果，哪里能低成本纠错，哪里就会先被推快。

程序员只是第一排。问题是：你的工作有没有正在被改造成 AI 喜欢的形状？

参考与引用来源

感谢张小珺完成这场对姚顺宇的长访谈。本文关于 AI 编程、产品判断、反馈信号和工作重构的理解，主要来自这场公开访谈；我在文中负责把这些判断转译为职业风险和个人工作方法框架。

张小珺 / Yao Shunyu 访谈：《Let Me Go a Little Crazy! Training Models at Anthropic & Gemini》
Cursor 官方文档：Cursor Docs
Anthropic 官方文档：Claude Code Docs
GitHub 官方文档：GitHub Copilot；GitHub Docs 中关于 repositories、issues、pull requests、reviewing proposed changes 的说明
Productboard：Product Requirements Document glossary
Atlassian：Understanding incident severity levels

手搓一个 Agent 驱动的项目 Wiki 生成方案

Mon, 18 May 2026 08:00:00 CST

背景

最近我一直在折腾项目文档生成的事情。之前写过两篇关于 deepwiki 的文章： deepwiki-rag-principle 讲了 RAG 原理， deepwiki-optimize-line-number 聊了给代码加行号的优化。

经过几轮迭代，搞了两个优化：

代码加上行号前缀
基于 Proto 文件生成确定性目录

这两个优化背后其实是同一个思路： 把确定的东西明确告诉 AI，不确定的才让 AI 来发挥。

类型	内容	处理方式
确定的	代码行号	直接给 LLM 标注好
确定的	gRPC 接口列表、目录结构	代码解析，不经过 LLM
不确定的	函数功能解释	交给 LLM 归纳
不确定的	项目架构分析	交给 LLM 总结
不确定的	代码关联关系	交给 LLM 推理

LLM 擅长理解、归纳和总结，但精准计算和结构化数据生成这块确实不太行。分开处理，各取所长，效果就好很多了。

这些都是用开源的 deepwiki-open 来做的。

问题

虽然最终生成的内容效果还不错，但还有个让人头疼的问题：

需要为整个项目生成总结性的内容，比如项目架构、流程图、ER 图等。

这些数据得根据之前已经生成的内容来总结，但 deepwiki 的架构是每个页面独立生成的。而 ER 图这种，我们希望是基于已生成的内容再汇总生成。

在现有架构下实现这个比较困难，索性换个思路。

新方案

日常用 Claude Code（后面简称 CC）的时候发现，它可以精准定位到具体业务逻辑所在的代码片段，也能帮我们分析项目、提炼内容。

这不就是个完美的 Wiki 系统吗？直接让 CC 分析项目内容，生成静态页面，就能得到一个精准的 Wiki 了。

CC 也是通过一些内置 tools 来实现精准代码检索的，不需要 deepwiki 那种向量数据库，架构简单很多。

这里简单聊下 CC 的代码搜索原理。传统 RAG 方案会先把代码向量化存入数据库，然后通过语义相似度检索。但 CC 并没有走这条路，而是直接用了一套 工具驱动（Tool-based）的检索机制：

工具	功能	使用场景
`Read`	直接读取文件内容	已知文件路径时
`Bash(grep)`	基于正则匹配搜索代码	按关键字/符号查找
`Bash(find)`	遍历文件系统	发现文件、按模式筛选
`LSP`	语言服务器协议导航	跳转到定义、查找引用
`Agent`	子 Agent 并行搜索	大规模代码库分治检索

这种设计的巧妙之处在于：LLM 不依赖向量化后的”模糊记忆”，而是像人类开发者一样，通过 精确的工具调用来定位代码。比如要找某个函数定义，CC 可能会先 grep 找到候选文件，再用 Read 精读确认，最后用 LSP 验证引用关系——整个过程是 确定性的、可解释的。

想了解更多细节可以参考 Anthropic 官方文档： Claude Code Overview

后续 repo 有更新，只需要让 CC 读取 git log 变更记录，自动更新修改的内容就行。

提炼 Skill

考虑内部项目众多，为了让其他项目也能复用这个能力，我把生成静态网站的过程写成了一个 Skill。其他项目只需要在 CC 里调用这个 Skill 即可。

目录结构大概长这样：

     ├── SKILL.md      
├── skill.json      
├── templates/      
│   ├── page-architecture.md      
│   ├── page-er.md      
│   ├── page-features.md      
│   └── page-service.md      
└── wiki/      
    ├── 01-系统架构.md      
    ├── 02-核心功能.md      
    ├── 03-ER图.md      
    ├── index.html      
    └── service/      
        └── *.md

优缺点对比

deepwiki

优点：

可以一键生成整个项目，生成过程中不需要人工干预

缺点：

无法精准调整某个页面
对于需要汇总已生成数据的需求，架构无法满足

Claude Code 方案

优点：

可以精准调整每一个页面
数据可以做到非常精准

缺点：

无法一键生成结果，需要多轮对话调试
如果部署到服务器上，需要外部工具对 CC 进行管理

总结

其实这两个方案并不冲突，可以看成不同阶段的选择：

项目初期需要快速搭个文档框架 → deepwiki 一键生成
项目成熟需要精准可控的文档 → CC 方案慢慢打磨

CC 方案的核心优势在于 可控性。虽然要多花点时间调试，但生成的内容质量确实更高，特别是涉及到跨文件关联分析的时候。

当然，CC 方案目前还不能完全自动化，这是最大的限制。不过随着 CC 生态的发展，相信后面会有更好的解法。让子弹飞一会。

马斯克花 100 亿想清楚一件事，不做 coding agent 就是等死

Mon, 18 May 2026 22:10:38 CST

1.

OpenAI 的两大宿敌 Anthropic 和马斯克，放下心中成见之后终于在月初结盟了。

在此之前，Anthropic 和马斯克的关系并不融洽：今年 2 月，马斯克还在自己的 X 账号指责 A 社「woke」「邪恶」「反人类」（misanthropic），说这家公司「仇视文明」。

事后来看，这次攻击并非马斯克清新脱俗的性格使然，而是 Anthropic 所做的某些事情触碰到他的神经，事出有因。

在此之前，xAI 内部使用 Cursor 工作，但是今年年初员工发现，Claude 模型突然在 xAI 的 Cursor 公司账号里不能使用了。

当时还在 xAI 上班的联合创始人吴宇怀，在全员信里是这么说的：「Anthropic 更新了政策，要求 Cursor 不得向其主要竞争对手提供 Claude 模型调用能力。」

当时，吴宇怀在信中写了一句话，颇为有趣：

「这是坏消息也是好消息。我们的生产力会被影响，但这也敦促我们开发自己的编码产品和模型。」

为什么当时 xAI 的高层认为，开发自己的编码产品是关键？

后来发生的事情，大家都知道了。xAI 的联创团队悉数跑路，马斯克一气之下对 Cursor 使用了钞能力必杀：

上个月底，SpaceX 和 Cursor 共同宣布，将在编程和知识类工作 AI 模型的训练上，展开前所未有的战略合作；并且，SpaceX 还获得了以 600 亿美元收购 Cursor 的权利，或向后者支付 100 亿美元合作费用。

注意编程这个关键定语，后面还会 call back.

2.

最近，我看了一条 Cursor 早期投资人、Anthropic 大喷子、T3 创始人 Theo Browne 的视频。

本来点进去是看他喷 A 社和 SpaceX 怎么蝇营狗苟，结果没想到，却看到了关于 SpaceX + Cursor 合作的，一个既另类却又极度合理的分析：

不说 600 亿的收购，就只说 100 亿的合作费—— Theo 在视频里表示，自己认为「哪怕只是交换到 Cursor 的用户数据，这 100 亿也值回票价了。」

所以是什么数据？如果你也去看 Theo 这条视频，他会讲得非常清楚。但为了节约时间，我们在这里简单概括一下：

我们和 AI 的对话是一来一回的，你提出问题/需求，他给你解答；coding agent 同理，只不过返回的是代码。

一次高质量的对话，整个过程，包括用户提示、模型思考、agent 规划、输出代码、验证 ——所有这些东西合起来，可以称为一个完整的 Agentic Loop——就成为了高价值的训练数据，再喂给模型去进行强化学习，就能进一步提高模型在实战场景下的表现水准。

Cursor 有的，SpaceX 想要的，就是这些数据。

可这些数据从哪里来呢？

答案很简单：作为模型厂商，这种高质量数据的最直接来源，只能是你自己开发的 coding agent 产品——也即 Anthropic 的 Claude Code、OpenAI 的 Codex、Kimi 的 Kimi Code。

现在你应该明白了，为什么被 Anthropic「封号」之后，吴宇怀会在全员信里提出开发 xAI 自己的 coding 产品和模型这件事了。这件事 xAI 在当时已经看清楚了：

没有自己的编码产品，就没有高质量的强化学习数据；没有高质量的数据，就训练不出真正实战能力强的 coding 模型。

虽然有点暴论，但现在我们可以点题了：模型厂商想做出来真正能打的编程模型，做自己的 coding agent 产品是唯一的路径。

3.

大语言模型像个水晶球，用全网的语料训练出来，似乎能够解答万物，但并不代表它在所有问题上都能给出高质量的答案。

用 GitHub 上数以亿计的代码条目训练，当然也能训练出 coding 模型。这是「学习结果」的逻辑，也是没问题的。毕竟编码任务的结果是可以验证的：代码能不能运行，测试能否通过，结果摆在那里。

但是，通往结果的过程，是一个涉及多步骤决策、错误纠正、意图对齐的复杂链条。每一次用户的接受、拒绝、补全、撤销、追问、甚至当模型好几次都搞不定或者完全搞错时的辱骂——都是这一链条上的过程信号。

强化学习有两种监督方式，一种叫做结果监督，只看最后是否跑通。但是结果监督会催生「奖励黑客」的现象：模型为了能跑通可能写出冗余、脆弱、带逻辑漏洞的代码，但因为测试过了，模型以为自己学对了。

而另一种叫做过程监督，对推理路径上的每一步进行打分。上述这些过程信号，只有在 coding agent 运行环境里才能诞生。GitHub 仓库里只有结果，哪怕是去看单独的提交历史，看 PR，都找不到有效的过程信号。

在缺乏有效、自主可获得的过程信号的时候，一些模型厂商会采用「蒸馏」的方式，这个事情大家应该已经知道了。

蒸馏的逻辑很简单，给同样的输入，老师模型输出什么，学生模型就学着输出什么。 但是通过蒸馏，即便可以获取到思维链，得到的仍然更接近于结果，而非被蒸馏的老师模型内部的概率分布。

一旦学生在推理中偏离了老师的轨迹，哪怕一个 token 不符合，都有可能发生偏离。

这背后是强化学习的基础限制：策略梯度定理要求，优化样本最好由当前正在优化的模型自己去产生。这种数据叫做 on-policy 数据。而通过蒸馏别家模型，在别人的产品里产生的数据，来训练自己模型，都属于 off-policy 数据。模型当然可以从中学到东西，但学不到老师模型内部的概率分布信息。

而像 Cursor 这样自己就是 coding agent 产品的公司，掌握着最真实、有效、高质量的训练数据。Cursor 产品本身，就是 coding 模型在实战环境中的最佳训练场。

我们可以通过 Cursor 年初的「翻车」，来证明这个逻辑。

4.

APPSO 读者应该记得，年初 Cursor 发布了 Composer 2，号称「下一代专用编程模型」，技术报道写的相对保守，也没有提供具体的模型底座信息。

结果很快，网友就在公开代码片段里发现了 Kimi 的模型 ID，截图传遍了开发者社群，逼得 Cursor 副总裁 Lee Robinson 出面澄清：「Composer 2 确实是从开源底座出发的。最终模型大约只有 1/4 的算力来自底座，剩下 3/4 是我们自己训出来的。」

几小时后，Cursor 联创 Aman Sanger 也跟着发了一条道歉：「一开始没提 Kimi 底座是个失误。」

五天后，Cursor 放出了完整的 Composer 2 技术报告，显示底座的确是 Kimi K2.5，授权方则是 Firworks AI，大致流程是在 K2.5 上做训练，再继续做大规模强化学习（RL）。

但关键之处在于，Composer 2 的 RL 是运行在真实的 Cursor 会话当中，使用与生产部署完全相同的工具和 harness。

Cursor 将这套流程叫做「实时强化学习」(real-time RL)，也即将模型的 checkpoint 直接部署到 Cursor 生产环境中，观察用户的响应，收集数据，聚合成奖励信号——最快可以每 5 个小时迭代一次模型版本，然后继续部署到 Cursor 里，循环往复。

最极致的案例是 Cursor 的自动化代码补全功能 Tab，每天处理超过 4 亿次请求，每当用户输入字符、移动光标时，模型都会预测下一步动作，如果预测置信度高，则显示建议，用户按下 tab 即接受自动补全。

该功能采用的是在线强化学习，在行业内极具特色。Cursor 可以以极高的频率（最快可达每一个半小时到两小时）更新 Tab 的模型能力给用户，直接在产品内收集 on-policy 数据进行训练。

这种高频、接近实时的反馈回路，让 Tab 可以学习到极其微妙的用户意图。Cursor 方面透露，这种方法让 Tab 建议的拒绝率降低 21%，接受率提高了 28%。

回到 Composer 模型本身。在事情搞清楚了之后，一些 Kimi 员工也删掉了之前吐槽的的推文，Kimi 官方账号发表了祝贺。

一家估值 600 亿美元（基于马斯克给的数字），不做自己的模型基座的 coding agent 应用层公司，仍然可以通过产品自身的数据飞轮，RL 出超越基座模型的专有编程模型。

所以与其说 Cursor 翻了车，不如说这反而是 coding agent 产品重要性的绝佳例证。

Cursor 在另一篇关于实时 RL 的文章里写到：「（训练编程模型）最大的困难在于建模用户。Composer 的生产环境里不只有执行命令的计算机，还有监督和指导它的人。模拟计算机容易，模拟使用它的人却很难。」

这句话，现正在逐渐成为了在编程模型方面走在前沿的模型厂商之间的共识。如果你去看 benchmark 榜单和用户普遍评价，会发现哪些头部的厂商都在发力做自己的 coding agent/编程产品。区别只在于谁离用户更近。

我们以 SWE-bench、LLM-Stats 等相对权威的榜单为例，Claude、GPT、Gemini、Kimi 等模型基本霸榜前十，清一色都是有自己开发 coding agent 产品（包括 CLI、IDE、集成 coding agent 的桌面客户端）的模型厂商。

在部分榜单上会出现少数反例，如 Meta (Muse Spark)、DeepSeek 等，没有开发自己的 coding agent。

不过你会发现，这些反例模型，在更加接近真实场景、避免污染的更权威 benchmark 上就很难上榜了。以 DeepSeek 为例，它在 SWE-bench bash only 上分数是 70%，排名第九，在 SWE-bench Pro 上分数却掉到了 15% 左右。

OpenRouter 的真实流量数据可以解释这种反差：该平台 2025 年报告显示，Claude token 消费 80% 以上用于编程和技术任务，而 DeepSeek token 消费主要集中于闲聊和角色扮演。

没有自家 coding 产品的厂商，在一些 coding 任务 benchmark 上能挤进头部，但在更难的真实工程 benchmark 上，在用户用 token 消费投票的真实流量中，都会原形毕露。

不仅是 Cursor，Anthropic 在 2025 年 11 月发的一篇论文里，也明确透露自己在做一模一样的事情：「我们在 Anthropic 自家的真实生产编程环境上做训练。」也即 Anthropic 把自己员工使用 Claude Code 的交互数据，反哺给 Claude 模型用来训练。

5.

在 AI 的演进历程中，生产要素的定义发生了深刻的位移。传统三大核心要素——算力、研究、训练数据，虽然在总量上持续增长，但在结构上已经出现了严重的失衡。

今天的各大 AI 巨头显著提高了在算力上的资本支出 (CapEx)，让算力基建成为了当前舆论的主旋律。但实际上，特别是在编程范畴内，随着 GitHub 仓库、StackOverflow 等互联网公开代码数据被基模厂商「竭泽而渔」式地利用，模型在代码生成与逻辑推理上的边界开始逐渐显现。

这也是为什么，行业共识正在逐渐转向一个冉冉升起的新战略高地：

对于任何希望掌握顶级代码能力的模型厂商而言，建立自有的 coding agent 产品早已不再是可选的商业路线，而是确保底层模型可以持续进化的核心生命线。

正如前面 APPSO 论证的那样，单纯学习公开数据等于只学习成功者的结局，却无法了解成功的路径，这绝对不是正确的成功学应该有的样子。在真实的编程环境中，知道发生了什么错误、怎样发生的、如何正确地理解和高效地实践需求等等——了解正确过程的价值，远超于得到正确结果本身。

只有拥有自己的编码产品，模型厂商才能获取高质量的「过程监督」信号，从而在编码/推理能力的下一阶段竞争中，确保自己仍有技术护城河——

否则就不得不像 SpaceXAI 那样，花钱去跟 coding agent 产品公司去合作。

然而并不是所有模型厂商都跟马斯克一样有钱，以及 2026 年开始的巨头势力划分、结盟与领地的争斗会变得更加激烈，当一家缺乏自主 coding 产品的模型厂商终于回过味来的时候，恐怕已经没有足够的合作伙伴可以挑选，合作的价格也将水涨船高。

美国模型巨头的情况大家普遍比较熟悉了，在此不赘述。APPSO 也注意到，国内的主流模型厂商和 AI 巨头当中，绝大部分都已经在 coding agent 产品上有所布局。

国内巨头公司主要以原生 AI IDE 或 IDE 插件的思路在做：字节跳动去年很早就布局了 TRAE、阿里巴巴的 Qoder、腾讯的 CodeBuddy、百度的文心快码 Comate 等。

AI 小龙公司中，月之暗面是最早开发独立 coding agent 产品的公司，主要以 CLI 界面的 Kimi Code 为主—— 不过 Kimi 此前有透露过，在原生编程产品这件事上，CLI 不会是终局。

另一种实现思路是模型厂商自行提供 API 服务、Coding Plan。这样，不论用户使用何种 AI 开发环境，模型厂商都可以通过服务器端的 API 记录来获取最大程度接近于原生 coding 产品的过程数据。

但这也只是接近，并非完全相同。核心在于，服务器端 API 的请求-响应日志，与深度继承的产品交互轨迹相比仍有很大差距。

自建产品的厂商（例如 Cursor、Claude 桌面端、Codex）拥有最直接的显式反馈信号，而 API 侧是相对模糊的隐式推断。简单来说，API 侧能看到用户请求和响应，但用户最后是否采纳了这段代码、代码能否跑通、引发了什么样的 bug，API 侧对此是一无所知的。他们无法了解到用户最终行为这一关键的标签，从而无法实现最高质量的强化学习。

形而上来讲，语言即世界，代码即方案。代码可以表达这个世界上绝大多数的任务，代码也会成为头部的放大器，让最顶尖的人才放大数倍的生产力。

只有最顶尖的 coding 模型才配得上最顶尖的人才。如果领先的模型厂商不重视 coding，势必将会掉出第一梯队。

当然，事实上每家模型厂商都不会不重视 coding——而是说，在新的范式下，哪些没有自主可控的原生 coding agent 产品，极有可能逐渐落后于有产品的厂商。

就在前几天，MiniMax 也发布了桌面客户端产品的重大更新： 带有全新多 agent 编排架构的 Mavis 功能，并且也让客户端显著改善了对 coding 任务的支持。

此前 MiniMax 只是推出了桌面端，但没有加入原生 coding 和 agent 功能。

紧接着，在 5 月 15 日，阿里巴巴正式发布了 Qoder 1.0——这个产品从 IDE 的形态正式升级为一个完整的 Agent 产品（阿里的官方叫法是智能体自主开发工作台）。

与此同时，xAI 的 Grok Build CLI，也终于正式推出了。

没错，就是 xAI 年初被 Anthropic 和 Cursor 封号之后，他们自己捣鼓出来的那个 coding agent.

这不，又多了好几个现成的案例。

看来，大家都认为 Cursor、Codex 和 Claude 桌面端走在正确的道路上。

6.

把话题从 coding 扩展到 agent 本身，情况也是一样的。

编码任务的轨迹数据，在公开语料中确实还是能找到一些的（比如 GitHub 的提交记录/PR，尽管质量并不高）。但是 agent 任务的轨迹数据，包括并不限于移动和点击鼠标、操控触屏、填写输入框等，却无法在公开语料中找到。

所以我们会看到，即使在 agent 操作的最小实现路径——浏览器插件上，这么个看起来一点都不高端的东西，几乎每家模型厂商都会做自己的。

OpenAI 早在 2025 年 1 月就做了 Operator——与其说它是一个「AI 自动操作浏览器」的产品，不如说本质上就是一个大规模的数据收集装置。每一位试用 Operator 的用户，都在免费为 OpenAI 提供 on-policy 数据。

后续 OpenAI 还衍生出 ChatGPT Agent 以及新版 Codex 桌面端；Anthropic 也是同理；最近 Kimi 不声不响地也做了一个叫做 WebBridge 的项目，其实就是一个浏览器插件。

即便是在过去两年里动作最克制的中国模型巨头深度求索，也在最近开始展露出对 Agent 的兴趣。

CEO 梁文锋此前接受采访时曾经提到这样的观点：数学和代码是 AGI 天然的试验场，有点像围棋，是一个封闭的、可验证的系统，有可能通过自我学习就能实现很高的智能。

这句话的潜台词，是 DeepSeek 一直把 coding、Agent 当研究试验场，而非商业化方向。

但是在今年 3 月，DeepSeek 一次性放出了十几个 Agent 相关岗位，包括首次出现的模型策略产品经理（Agent 方向）等。当时的 JD 职责涵盖「主导 Agent 评测体系以及训练数据方案的设计」，要求中包括「深度使用 Claude Code、Manus」等产品。

APPSO 注意到，近期深度求索发布了 Agent 产品经理、Harness 产品经理等职位招聘信息——很显然，DeepSeek 要做独立、原生的 Coding/Agent 产品了。

此前资料显示，DeepSeek V3.2 的训练过程中引入了近两千个合成的 Agent 训练环境和八万多条复杂指令。但是看起来，靠合成的训练数据只能带 DeepSeek 走到这里了，剩下的是合成不出来的部分：真实用户在真实环境里的真实成功和失败，必须靠自家的 agent 产品才能拿到。

DeepSeek 以一种极度克制的方式做了三年模型以及模型产品（直到上个月才终于在官网加入了多模态能力）。但是在今天来看，在编码类任务上，DeepSeek 拿 SOTA 越来越难了，即便此前拿到也会在不久后被超越。

当主力依靠研究的路径支撑不住飞轮的时候，DeepSeek 终于行动了。

7.

最后，我们回到开篇的故事。

根据 The Information 援引知情人士报道，在接受马斯克 600 亿收购/100 亿美元合作的同时，Cursor 表示不会与 xAI 合作开发新的模型，而是仍将聚焦于优化自己的 Composer 模型。

这可能意味着，即便被马斯克买通甚至收购，Cursor 仍然要保留自己数据飞轮的主体性。

数据归属的本身，是最关键的隐藏博弈点。

当所有顶级模型厂商都做了自己的产品，所有顶级产品也都开始训练自己的模型，「模型公司」和「产品公司」之间本就不太清楚的界限，似乎越来越不存在了……

这场博弈也才刚刚开始。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

你生活的地点与你衰老的速度相关

Mon, 18 May 2026 23:37:43 CST

根据发表在《Cell》期刊上的一项研究，研究人员通过分析欧洲、东亚和南亚的 322 名健康人去构建迄今最详尽的遗传祖先和环境如何塑造人类生物学特征的图谱。通过招募居住在不同大洲、具有相同遗传背景的人群，科学家得以以前所未有的清晰度，将 DNA 的影响与环境的影响区分开来。研究人员发现，无论搬到哪里，种族背景会对免疫系统、新陈代谢和肠道菌群产生深远影响。南亚人表现出更高的病原体暴露水平。欧洲人的肠道微生物多样性更丰富，且与心脏病风险相关的化合物含量更高。跨州迁移会改变主要的代谢途径，改变肠道微生物的平衡。研究的一大发现是你生活的地点与你衰老的速度相关。居住在亚洲外的东亚人比东亚人生物年龄更大。欧洲人则相反，居住在欧洲外的欧洲人生物年龄更小。

20条软件工程定律

Mon, 18 May 2026 13:54:16 CST

Milan 在他的 newsletter里整理了 20 条软件工程定律。这些定律有些来自 1960 年代，到现在还管用。它们讲的是人在压力下一起造东西时会发生什么，不教你怎么做，只告诉你已经发生了什么、什么行不通。下面逐条解读。

Gall 定律

一个能跑的复杂系统，一定是从一个能跑的简单系统演变来的。

系统在纸面上看着没问题，真正的问题要等真实用户用起来才会暴露。所以每个能跑的复杂系统都是一步步长出来的。想一步到位造出完美系统，基本都失败了。从零重写的系统经常翻车也是这个原因：大功能倒是照搬了，但老系统在多年运行中积累的那些不起眼的小设计（比如某个特殊的缓存策略、某条异常处理路径），没人记得也没人照搬，而它们恰恰是让系统跑起来的关键。

Instagram 前身叫 Burbn，集合了签到、游戏、拍照分享。创始人砍掉所有功能只留照片分享，变成了现在的 Instagram。Google Wave 反其道行之，聊天、邮件、论坛、文档编辑一起上，没人说得清它到底是干嘛的，15 个月就死了。

KISS 原则

保持简单。超出必要的都是负担。

能 50 行脚本解决的问题，别搞 500 行的复杂方案。每多写一行代码就多一分引入 bug 的风险。简单的设计好维护：新人上手快，bug 好找，改一处不会牵动一片。别整那些花里胡哨的代码技巧，也别替未来还不存在的问题预埋复杂度。

有个创业公司需要功能开关（feature flag，不改代码就能开关某个功能的配置项），于是建了一个独立微服务：自己的数据库、缓存、管理界面、WebSocket 通知、A/B 测试支持，花了大量时间，出了问题还很难查。其实一个 JSON 配置文件就够了，一个下午搞定。

Conway 定律

组织的沟通结构会镜像到系统架构里。

你的应用架构基本等同于组织架构图。四个团队做项目，大概率产出四个模块。前端、后端、数据各干各的，做出来的东西也拼不到一块。光重写系统不调组织架构，换汤不换药。

反过来也成立：先选好想要的架构，再按架构组建团队。Amazon 在 2000 年代就把系统拆成小服务、每个服务一个小团队，系统和组织一起变了。这叫逆向 Conway 播种（Inverse Conway's Maneuver）。

三人的团队几乎总是出单体应用，因为拆分的成本比维持整体的成本还高。

Hyrum 定律

用户够多之后，你 API 的每一个可观测行为都会变成某人的依赖，不管接口文档怎么写。

接口文档写着不算数，系统实际表现出来的才算。响应时间、错误信息的文字、JSON 字段顺序、哈希的精确字节，这些你从没觉得重要的细节，总有人依赖着。

SimCity 有个 use-after-free 的 bug，在 Windows 3.x 上没事，因为内存压根不被回收。到了 Windows 95 真正回收内存了，SimCity 就崩。微软专门在 Windows 95 里加了一个特殊内存分配模式，只在 SimCity 运行时激活，让这个 bug 继续工作。

浏览器也是这么干的。Web 开发者依赖的每一个怪癖都变成了平台的一部分，浏览器改不了，改了就崩半个互联网。

CAP 定理

分布式系统只能同时保证一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）中的两个。

网络迟早会断。一旦两个节点联系不上（这就是分区），你要么停写保数据一致，要么继续服务但允许副本间数据不一致。每个分布式数据库都做了选择，只是多数不会主动告诉你。

MongoDB 选了 consistency：分区时某些副本拒绝写入，等整个系统恢复。Cassandra 则选了 availability：副本数据不一致时照样响应查询，之后再修。谁都没错，取舍不同罢了。

Zawinski 定律

每个程序都会膨胀到能收发邮件为止。做不到的会被能做到的替代。

这是 Netscape 早期工程师 Jamie Zawinski 在 1990 年代说的玩笑话。那个年代浏览器、编辑器、日历都在加邮件功能，好像不收发邮件就不完整。说白了就是每个程序都会无限制地膨胀，直到塞满所有能想到的功能。工具做好了、用户喜欢，产品方就想让人留在平台上，于是不断往里塞东西。时间一长，工具变得又慢又臃肿，然后新的竞争者带着精简版出现。

Netscape 从浏览器膨胀成套装（邮件、新闻、网页编辑器），Firefox 来收拾残局，精简后火了，然后又加插件和开发工具链。Slack 诞生时说要杀死邮件，现在有语音、视频、机器人、应用商店。

Brooks 定律

给延期的项目加人，只会让它更延期。

软件工作拆不了。新人进来要上手，老手得停下手头的活来带。项目已经延期了，加人只会添乱。Brooks 说得好：九个女人也不能一个月生出孩子。

有人带过一个八人团队，一直延期。第一反应是招两个人。结果招人期间走了两个，团队变成六个人，沟通反而顺畅了，产出反而更高了。

Ringelmann 效应

团队越大，人均产出越低。

很多人一起拉绳子，每个人反而不用那么大力。协作摩擦是一方面，"总觉得别人会做"是另一方面。

GitHub 做过大规模统计：2-5 人团队的工程师平均每月写 1850 行代码，10 人团队降到 1200 行，50 人以上只剩 450 行。人均掉了 75%。小团队出活快，Amazon 的"两个披萨"规则也是这个道理。

Price 定律

一半的工作是由人数的平方根完成的。

100 人的团队，大约 10 个人干了一半的重要工作。16 人的团队，4 个人承担主要产出。所有创意领域都这样。核心的人走了，团队产出能力大幅缩水。剩下的人也没闲着，干的是让团队运转起来的支撑活。

Musk 接管 Twitter 后裁员约 50%，网站照样跑。Price 定律提前预测到了。但裁掉的是那些不怎么显眼却不可或缺的能力：内容审核团队没了，SRE（站点可靠性工程）人手不够了，出了故障没人能深入排查根因，只能头疼医头。核心人员撑住了日常运转，但碰到下一个复杂问题就抓瞎了。Twitter 后来悄悄请回了一些被裁的人。

Dunning-Kruger 效应

你对一件事知道得越少，越自信。

做一件事需要的本事，和判断自己做得好不好的本事，是同一件本事。不会的人看不出自己哪做错了，觉得自己挺厉害。会的人看得到自己所有的不足，觉得自己还不够好。

新工程师被问到工期，张口就来一个精确数字。老工程师给的是范围，口头禅是"看情况"。新人不是在瞎说，他们只是还不知道自己不知道什么。

刚接触新技术的人总是特别兴奋。AI 领域正在上演这一幕：喊"AI 什么都能做"最响的，通常不是天天在用 AI 的人。

Hofstadter 定律

做事总是比你预期的久，就算你已经考虑了 Hofstadter 定律也一样。

你估 4 周，想起自己总是太乐观，翻倍到 8 周，最后花了 16 周。下次学乖了估 16 周，结果花了 32 周，因为总有你不知道的意外冒出来。

柏林勃兰登堡机场就是个典型。软件集成涉及 75000 个传感器和 50000 个灯具控制，原计划 18 个月完工，后来意识到不可能，延长到 30 个月。最终花了 7 年，造价 70 亿欧元，超支 2.5 倍，晚了 9 年。

Parkinson 定律

工作会膨胀到填满分配给它的时间。

给开发者两周做一个两天能完成的任务，他会花两周。不是说他想偷懒，而是在两周里会做计划、试方案、加没人要求的花哨细节（gold-plating）。截止日期就定一天，他大概率一天能交。

Goodhart 定律

一个指标一旦变成考核目标，就不再是好指标了。

拿 bug 数、事故数、测试覆盖率、团队速度来考核人，大家就会想办法让数字好看，而不是把事做好。数字上去了，质量没动。

2000 年代初有团队按代码行数发奖金，后来有人按 PR 数考核。结果开发者开始复制粘贴而不是提取共享逻辑，有人几乎每次提交都开一个 PR。现在流行按 AI token 消耗量（tokenmaxxing）来衡量，消耗越多越"高效"。

Gilb 定律

任何你需要量化的东西，总能找到某种方式来测量，而且比不量强。

Gilb 定律和 Goodhart 定律一体两面。Goodhart 说指标被滥用会失真，Gilb 说没指标更糟。重要的东西就该想办法去量，量不了就没法优化。DORA 指标里的部署频率和变更交付时间就是开发生产力的可用度量，不完美，但比代码行数和 token 消耗靠谱。

Knuth 的优化原则

过早优化是万恶之源。

性能优化经常做早了、做错了地方。团队优化了永远不会成为热点的代码路径，引入了用不上的复杂度，花时间解决根本不会遇到的规模问题。先写出能跑的代码，再查性能。瓶颈在哪，就改哪。没有就继续往前走。

有人在创业公司花了大量时间搭 Kubernetes，为了扛百万用户。问题是他连 10 个用户都还没有。基础设施做好了，产品功能还没做完。

Amdahl 定律

并行加速的上限取决于串行部分的比例。

10% 的工作必须串行做，那无论多少台机器，最多快 10 倍。50% 必须串行，最多快 2 倍。

人也一样。一个审批组要过问每个技术决策，不管你有多少工程师，速度都卡在审批组。加人只是让排队等着审批的队伍更长。

Web 流量水平扩展，加应用服务器就行，直到每个请求都要打同一个共享数据库或认证服务。之后再加机器没用。

AI 让编码变快了，但思考、检查、修错、协作这些步骤没法并行。所以有人效率提升 10 倍，有人只有 1.2 倍。

Murphy 定律

可能出错的事一定会出错。

空指针、竞态条件、网络断开，用户量够大的时候，一定会在最糟糕的时刻出现。所以代码要写防御性的：检查空值、处理异常、验证输入。运维那边也准备好：监控、回滚方案、应急预案，都不能少。

2024 年 7 月 19 日，CrowdStrike 改了 Falcon Sensor 的配置，850 万台 Windows 蓝屏。修复得人逐台登录，因为机器起不来，远程不了。偏偏那边是周五上午，而且IT还不在岗。航空公司、医院、银行全中招。能出错的都出了。

Postel 定律

发送要保守，接收要宽容。

自己返回数据时，格式严格按规范来。但收别人的数据时，即使格式不标准只要能安全解读就别直接丢。

浏览器就是活例子。网上大部分 HTML 写得都不规范，但浏览器照样渲染。严格按规范来的话，半个互联网打不开。

但太宽容也有代价：所有人都容忍乱七八糟的输入，问题永远不会被修正，只会越积越多。安全敏感的代码里，容忍输入等于给攻击者开门。宽容不等于放任，得有判断。

Sturgeon 定律

90% 的东西都是垃圾。

造的大部分东西没人用，写的大部分代码质量不行，启动的大部分项目没能交付预期价值。这没什么，创造的常态就是这样。假装一切都好、给每个项目同样的资源，只会把事情搞复杂。要紧的是找到那 10%，砍掉其余的。

WordPress 插件目录大约有 57000 个插件，超过 34000 个两年没更新过，将近 19% 零安装。少数维护良好的插件撑起了公开网站 40% 以上的份额。

Cunningham 定律

在网上得到正确答案最快的方法，是贴一个错误的答案。

论坛提问经常没人理。贴一个明显错误的东西，马上就有人跳出来纠正。路过问题可能懒得停，看到错误忍不住要改。遇到难题别问"该怎么做"，提一个你明知道不太行的方案，正确答案可能不请自来。

Wiki 和后来的 Wikipedia 赌的就是这个：人们改错的速度远快于从零写新文章。事实证明这个赌赌对了，Wikipedia 就是靠这个机制撑起来的。

这些定律之间的关系

20 条不用全记住，前五六条能解决大部分问题，剩下的等新问题冒出来再查。关键是要知道什么时候哪条适用。

定律之间会打架。Knuth 说别过早优化，Amdahl 说找到瓶颈修掉它。两条都对，但适用时机不同：项目早期听 Knuth，性能真出问题了听 Amdahl。

还有一点：这是作者个人的清单，他还出了本书涵盖了 56 条定律。你自己的清单会不一样。哪些定律让你吃过亏，哪些对你就是最重要的。下次遇到项目事故、团队重组、系统重写，花一分钟记下来：哪条定律帮了你？哪条给了教训？记久了，你自己的清单比谁的都好用。

框架、平台、部署模式从 Brooks 1975 年写书到现在变了很多，但这些定律没变，因为人性从不改变。

Eric Schmidt 在毕业典礼上谈 AI 收到了学生的嘘声

Sun, 17 May 2026 23:55:46 CST

前 Google CEO Eric Schmidt 在亚利桑那大学的毕业典礼上谈及了 AI，结果现场学生嘘声四起。Schmidt 说：“我们原以为自己是在为人类几个世纪以来一直构建的知识殿堂添砖加瓦，但我们构建的世界最终却比我们预想的复杂得多。那些连接我们的工具，也让我们彼此疏离。那些赋予每个人发言权的平台——就像你们现在正使用的——却也侵蚀了公共领域。”“我毕业后的几年里，没有人会坐下来决心去开发一种使民主制度极化、扰乱一代年轻人生活的技术。这并非我们的初衷，但它却发生了。”他谈到了 AI：“我知道很多人对此的感受。我能听到你们的声音。你们感到恐惧，你们这一代人害怕未来已被预先设定，害怕机器即将到来，害怕工作岗位在消失，害怕气候在恶化，害怕政治四分五裂，害怕你们正继承一个并非由你们造成的烂摊子。”他称这些恐惧是“合理的”，但他鼓励毕业生适应这项技术，并极参与塑造它未来的应用方式。“问题不在于 AI 是否会塑造世界。它肯定会。问题在于你们是否会塑造 AI。”

AI 实施工程师岗位出来了：Forward Deployed Engineer

Sat, 16 May 2026 21:38:54 CST

一场 AI 岗位的“军备竞赛”

先看看最近 AI 圈的一个关于新职位 Forward Deployed Engineer（FDE）的新闻。

Google 正在 FDE 岗位上加倍投入，并且大幅简化了面试流程。Google Cloud 的 CEO 托马斯·库里安（Thomas Kurian）宣布，他们在市场营销（Go-To-Market）团队下成立了一个全新的、以 AI 为核心的部门，并且正在为此疯狂招募 FDE。

听说，他们的面试流程已经被大幅压缩，从过去长达数周、多达 4-6 轮的面试，缩短到了仅仅两天内的两轮面试。看来 Google 对填补这些空缺不仅是渴望，简直可以说是迫不及待了。

就在周一（5 月 11 日），OpenAI 宣布成立了“OpenAI 部署公司”（The OpenAI Deployment Company）。这是一家由私募股权基金投资 40 亿美元成立的独立实体， 估值高达 140 亿美元，投资方包括 TPG、Advent 等。看起来 OpenAI 本身并不是直接的投资方，而是扮演着合作伙伴的角色。

公告特别提到了 FDE，并表示他们的职责是“与业务领导者、运营人员和一线团队紧密合作，精准定位 AI 能产生最大价值的领域，并围绕 AI 重新设计组织的基础设施和关键工作流程，最终将这些收益转化为持久稳定的系统”。

由此可见， FDE 将在 OpenAI 的企业销售业务中扮演极其关键的角色，他们的任务就是确保公司的 AI 系统能在客户的真实业务中跑通，并实实在在地创造价值。将这块业务外包给新成立的“部署公司”，也能让 OpenAI 腾出手来，专心研发更强大的 AI 模型；而面对客户的那些繁琐对接，就交给合作伙伴和他们的 FDE 去搞定吧。

与此相关的一个动态是，OpenAI 收购了 Tomoro。这是一家总部位于英国、成立于 2023 年的 AI 公司，在英国、亚洲和澳大利亚拥有 150 名 FDE。这也是“OpenAI 部署公司”成立以来的第一笔收购。

Anthropic 也在如法炮制，创建属于自己的独立 FDE 咨询公司。上周一（5 月 4 日），Anthropic 发布了一份极其含糊的公告，宣布了这项新业务，但连名字都没透露，投资细节也寥寥无几。

已知的投资方包括 Anthropic 本身、黑石（Blackstone）、Hellman & Friedman 以及高盛（Goldman Sachs）。这家新公司的使命是与“各行各业的中型企业合作，将大语言模型（LLM）Claude 引入他们最重要的业务运营中”。

Anthropic 的算盘似乎和 OpenAI 打得一模一样：拉外资建个独立公司，让里面的 FDE 帮企业把 Claude 整合进系统。可以预见，这么一来，这些企业购买的 Claude Token 数量绝对会创下历史新高。

用大白话给你讲清楚 FDE 到底是啥

那么 FDE 到底是啥？全称是 Forward Deployed Engineer，简称 FDE。这个名字直译过来是“前线部署工程师”，但光看名字很难理解它到底干什么。

一句话版： 驻扎在客户公司现场写代码的工程师。

详细点说，这个岗位介于软件工程师、方案架构师和咨询顾问之间，但更实操。他们直接坐在客户公司里，用自家 AI 技术帮客户搞定实际问题。

你可能会问，这不就是咨询顾问？还真不太一样。顾问通常给你 PPT，告诉你“怎么做最好”， FDE 直接给你代码，帮你做到最好。方案架构师一般画架构图、写技术方案，FDE 除了这些，还得上手敲代码、调接口、现场 debug。

如果要给具体的比例，大概是：25% 写代码，50% 集成和调试，25% 开会和沟通。实际上，真正安静写代码的时间可能更少。

其实，Palantir 才是鼻祖

说起 FDE，这其实不是 AI 时代新冒出来的，而是 Palantir 在 2010 年代就玩熟的招数。

Palantir 做数据分析平台，早期服务的全是美军和情报部门，客户需求都是机密，根本不能用常规方法沟通。于是 Palantir 干脆把工程师派到客户那里常驻，近距离观察客户需求，现场快速迭代。

这些驻场工程师（Palantir 叫他们 Delta）干得不仅仅是交付项目，还有更重要的任务： 在客户端提炼出通用需求，反馈回产品团队做成标准化功能。

到 2016 年，Palantir 的 FDE 已经比普通工程师还多了，真正定义了这个岗位。

同样押注 FDE，三家公司走了三条不同的路

**OpenAI 最猛。**成立 OpenAI Deployment Company，TPG、麦肯锡、贝恩、凯捷全来了，连估值都搞到 140 亿美元，直接买了一家英国公司，150 名 FDE 到位即用。承诺 17.5% 的最低回报率，更像在投基建。

**Anthropic 稳一些。**找了黑石、高盛、Apollo 等华尔街巨头成立合资公司，先期投入 15 亿美元，主攻中型企业市场。这些投资方手里一大堆企业，天然就是 Claude 模型最好的用户池。

**Google 最传统。**自己雇人，FDE 岗位分布全球，薪资还不低——在美国高阶的总包能到 40 万美元以上。但最大的区别是，Google 的 FDE 拿的是 Google 股票，OpenAI 和 Anthropic 的 FDE 则在独立公司，跟母公司利益没直接关系。

给你翻译一下 Google FDE 招聘启事背后的“人话”

企业招聘启事这种东西，经常让人看不懂，咱们翻译一下：

原文翻译

“你是客户环境中的嵌入式建设者” - “你要去客户公司里坐着写代码。”
“不同于传统咨询，你是创新者兼建设者” - “活确实很像咨询，但我们想让你多写点代码。”
“你得有创始人心态” - “没人写需求文档，需求变了、项目拖了，都是你的锅。”
“高能动性” - “别指望额外资源，啥都得靠自己。”
“白手套级复杂 AI 系统部署” - “客户怎么要求你都得接着，哪怕要求很离谱。”
“把真实世界的洞察反馈给产品路线图” - “你提的工单，产品经理可能会偶尔瞄一眼。”

虽然听起来有点吐槽，但实际上每家公司的 JD 都类似。有个心理准备，才更清楚自己适不适合。

灵魂拷问：FDE 到底还是不是咨询？

看三个维度。

一是组织归属。Palantir 的 FDE 归产品团队，跟母公司同进退。但 OpenAI、Anthropic 的 FDE 属于独立公司，信息流通、身份认同和发展路径都会打折。
二是反馈环。FDE 最大的价值是发现客户需求后反哺给产品。但独立公司和母公司间隔着一道组织鸿沟，这个反馈通道可能会受阻，FDE 就容易沦为纯“写代码的咨询”。
三是利益绑定。Google 的 FDE 拿母公司股票，利益一致。OpenAI、Anthropic 的 FDE 就拿独立公司的收益了，跟母公司估值涨到天上去也没你份。

结论就是，OpenAI 和 Anthropic 的 FDE 已经更接近咨询，Google 则更接近传统的 FDE 模式。

谁该关注 FDE？

分三类人看：

新毕业生：绝佳机会，大厂的软件岗越来越少，但 FDE 大量招人，你能快速接触到企业级 AI 项目，成长更快。
资深工程师：可能会觉得“降级”，客户换得勤，缺乏长期归属感；但如果你正想创业或者更接近业务，FDE 是个深入企业需求的绝佳窗口。
非技术背景：门槛仍然挺高，不是学几个月 Python 就能搞定的事。

AI 行业的竞赛，已经悄然转向

过去三年，AI 行业一直拼的是模型大小、跑分高低。现在问题变了—— 大多数企业不缺模型，缺的是有人帮他们把模型接进业务。

OpenAI 一出手就是 40 亿美元，Anthropic 也拿了 15 亿，Google 招聘流程压到两天。这些巨额投入表明： AI 公司的赚钱方式变了，从卖模型到卖落地。

往大了说，每花 1 块钱训练模型，就可能得再花 1 块钱让模型真正跑起来。

FDE，恰好就站在这个转折点的最前沿。

Leapsome：2026年劳动力趋势报告

Fri, 15 May 2026 06:00:51 CST

本报告基于对美国、英国、德国和荷兰共2400名全职员工与HR负责人的调研，样本覆盖50至2500人规模企业，调研时间为2025年6月至7月，具有较强的方向性代表意义。报告揭示，表面稳定的用工结构背后，员工动机、信任与生产率正在系统性走弱。

数据显示，员工“留下来”更多源于风险规避而非满意度。四分之一的员工因担心跳槽风险而选择留任，54%的员工留下并非因为喜欢当前工作，约三分之一认为在AI环境下自身技能难以匹配新岗位要求。在岗位流动性下降、竞争加剧的背景下，安全感正在取代成长感，成为留任的首要因素。

这种基于恐惧的留任正在侵蚀组织绩效。60%的HR与管理者认为员工脱离感直接拉低绩效，48%观察到团队倦怠上升，47%认为脱离感助长内部冲突。盖洛普数据显示，全球员工脱离感每年造成约8.8万亿美元的经济损失，约占全球GDP的9%，其宏观成本已不容忽视。

在AI应用层面，企业雄心明显领先于组织准备度。53%的HR表示，因预期AI替代，一些岗位被暂停补招；44%的HR明确指出初级岗位正在被AI取代。这直接推高了在岗员工负荷，66%的员工表示个人工作量同比上升，50%感到更为不堪重负，AI并未在短期内兑现“降负”承诺。

技能错配成为制约AI红利释放的关键瓶颈。虽然77%的HR已观察到AI催生新角色，但仅31%的员工认为提升AI技能能显著降低被替代风险。HR与员工在培训感知上存在明显断层，83%的HR认为公司提供了AI学习时间，而员工认同度低29个百分点，导致培训投入难以转化为真实能力。

信任问题正在HR职能中集中显现。51%的员工不确信HR能够在不利政策中保护自身利益，46%的员工并未将HR视为可靠的员工代言人。信任流失往往并非源于单一政策，而是决策缺乏解释、反馈未被采纳以及价值观执行不一致的长期累积结果。

综合来看，迈向2026年的关键趋势并非单纯的人效或技术问题，而是“人—技术—信任”三者的再平衡。企业若继续以AI替代逻辑压缩人力、以短期效率覆盖长期能力建设，创新与韧性将同步受损。真正具备竞争力的组织，将把HR定位为连接员工成长与商业目标的中枢，通过清晰的成长路径、可落地的AI能力建设以及可被看见的信任修复，重新释放组织内生增长动能。

文档链接将分享到199IT知识星球，扫描下面二维码即可查阅！

中国拿下这届 AI 顶会半壁江山，清华一家单挑斯坦福加 MIT

Mon, 11 May 2026 16:45:10 CST

全球 AI 顶会，快成中国卷王的专场了。

每年 AI 顶会放榜，各大机构都会暗戳戳地发喜报，比拼谁家被收录的论文多。但今年 ICLR（国际学习表征会议）放榜后，一位名叫 Dmytro Lopushanskyy 的研究员，干了一件极其硬核的事。

他没有去引用官方那些现成的统计表格，而是写了整整 250 条正则表达式，把 ICLR 2026 全部 5356 篇接收论文的 PDF 挨个下载下来。

接着，他硬是从每篇论文首页的缝隙里，把机构署名全给抠了出来，并利用这几百条代码规则进行清洗与归一化，自动给「麻省理工」和「MIT CSAIL」这种同一机构的不同写法做了合并。

为什么要用这种最原始的手工分类法？

因为这老哥发现，我们平时习惯引用的那些学术统计平台数据，都是按「人」来追踪的。举个例子，一个在清华苦熬四年读博的学生，发了篇极具含金量的论文，毕业后去斯坦福当了教授。你猜怎么着？系统一刷新，这篇在五道口诞生的论文，就自动变成了斯坦福的学术产出。

这种偏差，长期以来硬生生压低了中国机构的实际贡献，同时虚抬了美国的数字。而当 Dmytro 用 96% 的解析成功率，把去伪存真后的真实数据画成一张热力图后，我们才得以一观真实数据的全景图。

一张学术热力图，看懂中美 AI 的真实格局

别的不说，这组数据确实很有冲击力。

这张图上中国机构面积之大，超出了很多人的预期。其中中国大陆机构，贡献了 43.7% 的接收论文。美国呢？31.9%。

如果你把中国香港（7.7%）算进来，本届 ICLR 超过一半的论文署名机构，全都来自中国。至于老牌的欧洲列强？整个欧洲大陆加起来才 5.3%，甚至比不过新加坡（5.5%）这一个国家的产出。

更有意思的是具体机构的排名。

今年，清华大学以 332 篇的产量登顶全球单一机构第一。这是什么概念？斯坦福 177 篇，麻省理工 167 篇。清华一家的产出，几乎是美国排名前二的两大超级名校的总和。紧随其后的上交、北大、浙大，也全都稳坐全球第一梯队。

不止高校阵营，国内产业界的科研表现同样亮眼。

阿里、上海 AI 实验室、华为、字节、腾讯，这五家中国科技公司/研究机构加起来发了 582 篇论文。有些媒体以前老爱吐槽中国互联网公司只懂商业模式微创新，不懂底层研究。这次 ICLR 2026 的数据一出，算是打破了这个刻板印象。

说白了，中国 AI 早就不是靠一两个天才的灵光一现，而是变成了一套精密、庞大、高度体系化的研发引擎。

不过，在这些令人振奋的数据背后，我们也不能忽视客观存在的指标。

比如虽然我们在总数上超越，但在仅占接收总量 4% 的 Oral（口头报告，通常代表最具原创性和启发性的方向）论文里，美国机构依然占了约 40%，而我们是 30%。

我们在工程化扩展上占据了绝对的规模优势，而美国在定义新方向上依然保有相对领先。这也是中美 AI 之间相对真实的现状。

硅谷的科研 AGI，与中国实验室的极致务实

如果说热力图是一份宏观体检报告，那艾伦人工智能研究所（AI2）知名研究员 Nathan Lambert 今年 5 月来北京、杭州等地的 36 小时调研，就是一次深度的微观观察。

他在走访了智谱 AI、月之暗面、千问、美团、小米、零一万物等 AI 企业后，回国后写了篇关于中国 AI 实验室内部观察，并在硅谷引发了大量讨论。他看到了中国大模型能跟美国五五开的底层逻辑——极低的组织摩擦和极度务实的年轻人。

在 Lambert 看来，美国顶级实验室往往存在一个致命的弱点：Ego（自我）太强了。

训练大模型是一项极其复杂的系统工程，从数据清洗、分布式通信优化到强化学习对齐，每个环节都需要互相妥协。但在硅谷，那些明星研究员往往带有强烈的个人偏好。

据传 Meta 的 Llama 团队就曾因为路线之争经历过动荡，大佬们各自为政，都想把模型往自己主导的方向推进。反观中国实验室，Lambert 发现这里有一种异于寻常的务实。

研究员们不在乎谁的方法听起来更高级，大家的目标高度一致：只要能把模型的某个指标提上去，枯燥的脏活累活谁都愿意干。这种务实让整个团队的摩擦力降到了最低。

Lambert 还归纳了这种文化倾向具体带来的优势：更愿意做不起眼的基础工作来提升最终模型；刚入行的人没有经历过以前几轮 AI 炒作周期，能更快适应最新技术路线；Ego 小，组织架构能相对平稳地扩大规模；以及大量善于在现有方案基础上攻坚的人才储备。

更让 Lambert 惊讶的是，在美国，顶级实验室的实习生往往只能接触边缘项目。但在中国，在读的硕士和博士生深度参与核心大模型的研发。Lambert 敏锐地指出了这种做法的核心优势：没有历史包袱。

大模型的技术路线迭代极快。资深科学家往往有「路径依赖」，觉得自己研究了十年的老方法才是真理。但中国的年轻学生不同，只要有数据证明新路线有效，他们立刻就能抛弃旧方案，快速切换赛道。

值得一提的是，Lambert 发现，中国 AI 圈内部的氛围远比外界想象的和谐。各家实验室之间，私下交流满是相互尊重，所有中国实验室都敬畏字节跳动和它广受欢迎的豆包模型，因为字节是中国唯一一家真正处在前沿位置、同时又保持闭源路线的实验室。与此同时，几乎所有实验室也都非常尊重 DeepSeek，认为它是在研究判断和执行品味上最出色的团队。

在这次调研中，还有一个细节特别值得关注。在硅谷，顶尖的 AI 研究员不仅是工程师，往往还扮演着半个「哲学家」的角色。他们喜欢在播客上高谈阔论，探讨「通用人工智能（AGI）会不会在 2030 年毁灭人类」，频繁讨论 AI 安全与伦理边界。

于是，Lambert 也试探性地问了中国同行对 AI 经济影响和长远社会风险的看法，但得到的反应不是长篇大论，而是普遍的困惑。关于毁灭人类这种宏大命题，暂且不在他们当下的工作边界之内。

这种对宏大叙事的免疫，反而成了一种竞争优势。它减少了团队在哲学层面的内耗，让所有的脑力都持续集中在工程落地和指标突破上。
在中国的实验室里，导师、博士生与企业工程师之间形成了一种极短的反馈回路。

这种模式消解了学术界与工业界之间的壁垒，正如 Nathan Lambert 所观察到的，这种低摩擦的组织形式，让中国 AI 展现出了类似基建狂魔般的推进速度——一旦方向明确，便能以排山倒海的智力密度迅速抹平技术差距。

当然，这套打法在特定窗口期内行之有效，但随着规模效应的红利逐步见顶，下一阶段的核心壁垒终将回归于「原始创新能力」的较量。

届时，高密度的人才协同网络和某个敢于打破既有框架的个体，在 AI 的下半场互为成全，缺一不可。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

Vibe Coding治网瘾？孩子为何越写越上瘾？

Mon, 11 May 2026 21:40:54 CST

以毒攻毒：用 Vibe Coding 治疗网瘾，AI 时代的新选择

大家好，欢迎收看老范讲故事的 YouTube 频道。今天咱们来讲一讲“以毒攻毒”：用 Vibe Coding 治疗网瘾，AI 时代的新选择。

大家注意，这个名字听起来稍微有点标题党。网瘾是一个很严肃的问题：孩子沉迷游戏，或者刷短视频，昼夜颠倒，不写作业，不出门，不社交，家长急得不行。你现在说再给他一个 AI 编程工具，让他继续坐在电脑前面，继续盯着屏幕，继续熬夜折腾，这不是火上浇油吗？

所以我要先把今天的核心观点讲清楚。我不是说 Vibe Coding 能够完全替代程序员，这不是今天的主题；也不是说孩子学了 Vibe Coding 以后，明天就可以上硅谷年入百万。今天咱们要讨论的是：如果一个孩子已经沉迷游戏了，已经刷短视频、沉迷二次元，很难从屏幕世界里边直接揪出来了，那么有没有可能，不是先把他从屏幕前头拉走，而是把他的注意力从一种消费型的成瘾，迁移到一种创造型的成瘾上？

所以咱们的标题叫“以毒攻毒”，咱们也没说 Vibe Coding 就是一个多么健康的事情。游戏和短视频给的是即时反馈，Vibe Coding 其实给的也是即时反馈。游戏和短视频让人沉浸、让人上瘾，Vibe Coding 其实也让人上瘾。游戏和短视频会把人困在平台设计好的反馈回路里头，Vibe Coding 则是把人带到一个现实世界的创造反馈回路里。还是要不断给他一些强刺激，说你干得不错，然后他会继续留下来。

这个话题也不是老范自己拍脑袋想出来的，而是一位硅谷著名的传奇投资人的播客给了我一些启示。这个人叫纳瓦尔。他最新的一期播客里，其实并没有直接讲这个话题，而是讲自己怎么在这么多年以后重新回去写程序。他这个播客的名字叫 A Return to Code，就是“我又回到写程序这个事情上去了”。

这哥们是学计算机的，但是做投资人，肯定很长时间不接触代码了，现在又回来写程序。他讲到，真正有创造力、有自驱力、有表达能力、有清晰愿景的人，会有新的工作机会。今天咱们要讲的 Vibe Coding 像电子游戏一样容易上瘾，但是它的奖励不是假的，而是真实世界里边真实有价值的东西。

为什么说 Vibe Coding 可能成为一种“成瘾迁移”

我们以前讨论网瘾，总是想着怎么把孩子从游戏里边揪出来。但是游戏为什么能让孩子上瘾？包括短视频，现在短视频其实比游戏还上瘾，短视频为什么能够让人停不下来？本质上，有几个因素凑在一起：

低门槛；
即时响应；
难度可以动态调节；
持续奖励；
社群身份认证；
亚文化归属；
逃避现实中的挫败。

Vibe Coding 居然也具备所有这些特征，甚至比这个还要更强一些。Vibe Coding 跟前面这些网瘾的唯一区别就是，它产出的东西不是游戏等级，不是短视频里的赞，而是一个真实的网页、一个小工具、一个小游戏、一个小脚本，甚至是一个小应用。它产生真实的价值。

网瘾到底怎么治：粗暴戒断为什么常常无效

首先，治疗网瘾这件事一直是一个很有争议的事情，因为它没有一个特别有效、特别科学的方法，甚至还出现过一些让人没法看的事情。先说一个很现实的问题：网瘾到底怎么治？

过去 20 多年，很多家庭都在被这个问题所困扰。我们回头来看，所有所谓的治疗网瘾的方法，其实都非常粗暴。有些地方搞封闭式训练，把孩子关起来，体罚、羞辱、强制劳动、军事化管理，还有一些更极端的案例，直接进行电击、暴力管教，训练营据说还有死亡事件发生。

这些事情为什么会发生？因为家长焦虑。家长看着孩子沉迷游戏，会觉得这个孩子要完了。特别是在中国，输在起跑线上了，他不读书、不工作、不社交、不运动、不睡觉，这怎么行？家长当然就慌了。

但是问题是什么？焦虑的家长很容易相信一个简单粗暴的方案：把手机抢走，把电脑砸了，把孩子关起来，强行戒断。他以为这东西像戒毒一样，其实真的不太一样。因为很多时候，孩子的问题不是屏幕本身，屏幕只是个出口。真正的问题可能是，他在现实世界里长期得不到正反馈，在学校里只有失败和羞辱，在家里也只有指责和比较。“你看别人家小明怎么怎么样。”他不知道自己擅长什么，也没有一个可以投入的现实目标。他一离开游戏，就只剩下空虚了，啥也没剩下。

所以你把游戏给他拿走，问题并不会自动消失，你只是把一个出口堵住了。如果没有新的出口，他可能会转向短视频；短视频堵住了，他可能会转向小说；小说堵住了，他可能再转向饭圈，或者彻底躺平。现在很多人说：“我没有任何欲望，我就准备躺这了。”

这就是为什么我要说，治疗网瘾一直没有一个特别简单、特别有效、特别科学的方法。它不是一个按钮，按下去就好了。它更像是一个迁移过程：从低价值的反馈迁移到高价值的反馈，从纯消费迁移到半创造，从算法喂养迁移到主动提出问题，从“我今天刷到了什么”，迁移到“我今天做出了什么”。这才是今天咱们要讨论 Vibe Coding 的意义。

什么才算网瘾：不要把所有数字兴趣都病理化

那么到底什么是网瘾？这个定义本身其实也有一些争议。网瘾这个词在中文语境里经常被滥用，好像孩子开始打游戏了，家长就说他有网瘾；孩子周末多刷了几条短视频，家长就说他有网瘾。但是从医学和公共卫生角度上，这个事情是有严格标准的。

世界卫生组织专门有这个病，叫做游戏障碍。它有三个核心条件：

控制力受损：明明知道我应该停下来，就是停不下来。
游戏优先级越来越高：学习、工作、睡眠、社交、家庭责任都被挤在它后边去了。
即使已经造成明显负面后果，仍然持续或者升级：比如成绩已经严重下滑了，工作已经失控了，关系破裂了，健康受损了，但是仍然要继续玩，甚至越玩越多。

这点非常重要，因为我们不能把所有孩子对数字娱乐的兴趣都病理化，都认为这事有病。一个孩子喜欢游戏、喜欢动漫、喜欢刷视频，未必是病。问题在于这件事情有没有挤压他的现实生活，有没有破坏他的自我控制，有没有让他长期丧失学习、工作、社交和生活的能力。如果没有，那就是兴趣；如果有，那可能就稍微需要干预一下了。

所以今天我们说用 Vibe Coding 治疗网瘾，不是说 Vibe Coding 是医疗疗法，更不是说它可以替代专业的心理咨询、精神科诊疗、家庭关系修复。我说的是一个家庭教育和数字习惯迁移的思路：当一个孩子已经被低价值的数字产品牢牢吸引住的时候，不要只想着强制断网或者抢他手机，要尝试着引导他到一个同样有吸引力，但是能产生现实价值的方向上去。这个方向就是今天咱们要讲的 Vibe Coding。

游戏和短视频为什么会让人上瘾

常见的网瘾机制，就是为什么大家觉得游戏和短视频这些数字产品会让人上瘾？因为这些东西都是靠数学模型拿捏人的能力边界的。真的是世界上最聪明的一帮人在研究怎么让你上瘾。

游戏有任务、有等级、有装备、有队友、有技能，它是一套完整的世界观。短视频没有那么复杂，它也不要求让你循序渐进，而是给你一个更短、更快的反馈。刷一条不喜欢，我再给你一条你喜欢的；刷完以后再接着刷。它的反馈更快，但是没有形成完整世界观，没有这种梯度。它们是两个不同的玩法，但底层有类似的东西，就是即时反馈和持续调整。

调整什么？游戏不是随便设计的。它会让你刚开始的时候很容易赢：新手村、新手引导，给你简单任务，怪物也很弱，奖励也很密集，让你快速建立起“我能行”的感觉。刚才咱们讲了，很多小孩形成网瘾的原因是他们在外边没有办法得到认可，那你到游戏里头说：“哎，我行了。”

等你熟悉了以后，等级和难度会逐渐上升，怪会变强，副本会变复杂，装备会更加精细，角色成长线会拉长。你会不断遇到一个刚好能够得着的目标，这叫能力边界。它会不断摸索你的能力边界。太简单，你觉得没劲；太难，你直接有挫败感。现实生活已经这么难了，我为什么要到游戏里受折磨？就直接弃坑了。所以它一定要找到“刚刚好”，你稍微努努力就能够得着。

其实很多教育学也在讲这个事，我们要设置一个能力边界，让他刚刚好够得着。但是通常老师没这个耐心，老师也有自己的 KPI。

短视频跟游戏这套东西不太一样。它不会要求你升级，它只是每一次来猜，你下一条最喜欢看什么。我尽可能更集中、更快速地给你进行反馈。所以短视频的危害形式要比游戏大，要注意这一点。

游戏和短视频厉害的地方就在于，它不只是一个娱乐产品，它是一个非常巨大规模的反馈机器。它通过即时满足、随机奖励、社群身份、等级系统、算法推荐，不断把人留在系统里边。

最后的问题就来了：孩子们不是简单地不自律，他是在用一个普通人的意志力，对抗一个由产品经理、游戏设计师、增长团队、推荐算法、商业化团队共同打造的超级系统。甚至这些超级系统里很多人，都是年薪好几百万的科学家。你要让人从这里边逃出来，不能简单靠一句“你别玩了”，这个事是很难成功的。

从历史看“替代成瘾”：卷烟替代鸦片的类比

我们必须要找一个更聪明的办法。你说有没有这种聪明办法？其实有过。

清末虽然鸦片战争已经打过了，虎门销烟也过去了，清朝也禁烟了，甚至英国也跟我们一块去开了禁烟大会。当然英国跟中国开禁烟大会的原因比较奇怪，因为后来中国反向出口鸦片，把英国也祸害了，英国说不行了，我们禁烟吧。

但是清朝政府自己的治理能力和治理效率是比较低下的，所以鸦片依然泛滥。最后没有办法，一方面这东西很上瘾，另外一方面，地方政府和很多门阀势力要靠鸦片赚钱，所以必须要种鸦片。最后他们用了一个什么方法把这个事情解决掉，或者说部分解决掉？上卷烟。

上了卷烟以后，你也可以上个瘾，稍微替代一下，没有鸦片的危害那么大。而且各级政府相对来说还有收入，因为卷烟可以收税，卷烟是一个税很重的产业。所以它算是一个成瘾替代的过程。

这也是我们今天讲这个故事的一个原因。小孩有网瘾了怎么办？我们希望立刻把孩子拎出来，变成一个热爱学习、热爱运动、热爱社交，每天早睡早起、积极向上的完美青年，这可能吗？家长们，你自己照照镜子，你自己是这样的人吗？我们大部分人其实也做不到这一点，那么就别要求孩子干成这样的事情。

所以我们今天就要稍微让他换一下，让他用 Vibe Coding 来替代打游戏。很多人说，写程序这事看着挺痛苦的，程序员都是秃头。当然像老范这个头发还是不错的。很多程序员都是未老先衰，很年轻的程序员看着都很老。你怎么说 Vibe Coding 或者写程序上瘾呢？

其实写程序真的是上瘾。如果你没写过程序，你可能很难理解，因为写程序是一种心流状态，它在不断解决问题。而 Vibe Coding 要比写程序还要上瘾。就像卷烟替代鸦片一样，我们现在就希望用它来替代打游戏。

Vibe Coding 为什么会上瘾

下面咱们来讲今天真正的核心：Vibe Coding 为什么会上瘾？很多不写代码的人其实很难理解，他们以为写程序是一件特别枯燥的事情，屏幕上甭管是白底黑字还是黑底白字，看着就头大。你需要学编程语言，需要学语法、变量、函数、对象，要学一大堆东西。

现在你只需要跟 AI 说：“我要一个什么什么东西。”就像上帝说要有光，于是就有了光那样的感觉。所以 Vibe Coding 等于直接把第一道门槛去掉了。它可以让人从一句话开始：“帮我做一个记账的小程序。”“帮我做一个背单词的小游戏。”第一版可能比较粗糙，但是它能跑，也能有一些效果。这不就是一个正反馈吗？跟打游戏那过程不是一样吗？

它一旦跑起来，这个人就觉得：“我是不是改一改？按钮不太好看，有点丑，咱改一下吧。这个颜色太丑了，咱改一下吧。”当你改的时候，你就相当于在游戏里从新手村出来，稍微往前走一走，在周围稍微探索一下。你的编程任务就可以一个一个地像游戏那样进行下去。而每一次任务的成功，就相当于你解决了一个问题，又得到了一个反馈，相当于又打了一个怪。

所以 Vibe Coding 是非常成瘾的，而且它把前面这些基础知识的门槛给你去了。小孩也都可以很好地使用 Vibe Coding 写出程序来。而且你直接跟它说中文、说英文、说各种语言，它都老老实实给你写程序，这还是非常爽的一件事情。

为什么传统少儿编程很难坚持

过去其实也有少儿编程课，但是门槛很高。我也投过少儿编程的项目，比如编程猫，我还给我儿子报过。报了以后他也没什么兴趣，学了半天，你的付出跟反馈不匹配。我折腾了半天，最后做出来那个小程序不好玩。

为什么会不好玩？原因很简单，它需要把课程设计得适合所有人，每个人的进度是不一样的。你需要学一堆基础知识，很快兴趣就没有了。所以当时编程猫的课程付了费以后也没上完。

原来这些东西有价值，不能说没有价值。但是问题是什么？真正长期坚持下来的孩子非常少。原因是你还是要去学编程语言，还是要去学符号系统。即使是 Scratch 这种用积木拖的代码，它确实很形象，就是一堆积木拼起来，但是你还是要了解加减乘除、赋值、排序、存储、循环、判断，还是要搞这些东西，还是很麻烦。而且你用 Scratch 这种积木语言拼出来的代码，能干的事情很有限，大部分事情干不了。

不像现在，我可以提一个很现实的问题：我现在想要一个记菜谱的程序，或者我现在追星，我特别喜欢哪个明星，请帮我把这个明星的所有信息都搜集起来，让我可以给他做一个明星记事本。一句话我就可以把这事搞定了。以前你学了半天 Scratch，你要想做出这样的东西来，得学几年。

所以孩子还没有看到成就，就直接被复杂的编程语言把兴趣给磨没了。现在的话，你会说就可以了，语法也不需要严谨。即使是 Scratch 那种拼积木的，你的语法还是要严谨，还是要 debug，还是会出错。更别说 Python、JavaScript 或者其他语言。现在我写中文跟 AI 聊天，写英文跟 AI 聊天，我语法错了，写错别字了，单词拼错了，有什么关系？没关系。

AI 提供了安全的表达环境

这个事情对孩子非常重要。很多孩子不是没想法，只是他觉得不太敢表达：我说了，万一说错了怎么办？这个叫挫败感。他也害怕我万一把这个想法说出来，老师说你这怎么这么幼稚，或者同学笑话他，或者父母说这玩意有什么用。这个对于他来说压力是很大的。

但是 AI 不会干这活。你跟 AI 说什么，AI 都不会笑话你。AI 会说：“行，我给你做一版。”很多孩子在现实世界里最缺的其实不是知识，而是一个愿意把他的想法当回事的对象。在这件事情上，AI 要比父母、比老师、比他的同学做得都要好，所以更容易上瘾一点点。

而且 AI 会不停地告诉他：“你这个想法可以实现，没问题的。”这对一个长期沉迷游戏、觉得现实世界没有正反馈的孩子来说，非常重要。

Vibe Coding 的“动态难度”机制

游戏让人上瘾的还有一个原因，就是难度刚刚好。Vibe Coding 也是一个天然具备难度适配结构的东西。

一个好游戏，动态难度一定是动态设定的。太容易了，玩家就跑了；太难了，新手就不来了。所以游戏设计里有很多机制，就是为了让不同程度的玩家有他们自己可玩的东西。

但是游戏比较麻烦的是什么？因为它一发售就写死了，有些人可能会高不成低不就，没法找到自己合适的地方，那他就会离开。Vibe Coding 这件事，一个完全不懂计算机的人，让 AI 帮他做个小工具，第一版就出来了，第一波奖励到手了。

然后他发现，我这个程序在电脑上好好的，怎么到手机上就这么丑？你把这个问题提给 AI 以后，AI 会告诉你，有一个东西叫响应式设计，就是在不同的屏幕大小上会自动适应。你原来没用这个东西，这个东西大概是怎么回事。然后你说我们用一用吧，它等于就升了一级，而且是你自己提出的问题，不用让 AI 猜你到底会什么、不会什么。

再往后说，我想把这个东西本地持久化一下。什么意思？就是我不希望每次打开应用以后，数据都没有了，我需要把东西存起来。AI 就会告诉你，什么叫本地存储，什么叫持久化，什么叫后端服务，什么叫数据库。你学了半天以后说，哦，我又学会一点东西，又把这个问题解决了，又一波奖励到手了。

再往后说，不光我自己想用，我还想给我朋友用，这事怎么办？你问 AI，AI 告诉你，你需要把它部署到云服务器上去。搁在自己电脑上，别人用不了。部署到云服务器以后，你还要给它申请个域名。你不希望别人乱用，可能还要登录；登录以后可能还有权限，因为现在不是你一个人用了。后台可能只有你一个人能看到，其他人能用前台的服务就可以了。等于你又学了一堆知识，又一波奖励到手。

它是这样的一个打怪升级过程。每一次你遇到的问题，正好是你现在知识上缺的这点。它不会给你做这种系统化教育。像我们原来学编程都是系统化教育，先学变量，再学计算机架构，然后再学什么，就是这样的一个系统化。现在没有了。我先有个需求，然后根据这个需求，一步一步把这个程序越做越复杂。在这个过程中，我学会编程了。

所以这就是 Vibe Coding 最厉害的地方。它不是把知识库做成课程，系统化教给你，而是让知识藏在问题里头。你自己发现问题，你自己想去解决问题，你自己去问，问完以后它就耐心地给你解释。在这个过程中，它就慢慢让你上瘾了，让你在这个过程中还学习了。

而且它永远知道你的能力边界是什么。你的能力边界就是你问的问题，你问了什么问题，你的能力边界就在这了。所以 Vibe Coding 会让孩子在解决问题中自然学习现实的知识。

Vibe Coding 的教育价值：从愿望走向现实

这部分很关键。很多人以为 Vibe Coding 是让 AI 写代码，如果只理解到这里就太浅了。Vibe Coding 真正的教育价值在哪？不是 AI 帮你写了多少代码，而是它会把你从一个愿望一步一步带到现实世界。

你就在这样的过程中，从一开始只想做一个简单的东西，不断往前推进，就会自然碰到现实世界的边界：网络延迟怎么办？服务器为什么要钱？用户数据怎么乱的？

这些问题比单纯上一门信息技术课要更有力量，因为这是从他自己的需求出发的，不是老师布置的。这是孩子自己碰上的。一个人只有在自己撞上墙、自己想去解决问题的时候，才有动力继续学习下去。Vibe Coding 就是一个不断制造这种温和撞墙的机器。这就是润物细无声的学习。它不需要说教，不需要像家长那样在旁边喊：“你应该学点有用的。”所以 Vibe Coding 让人上瘾，而且让人努力学习。

Vibe Coding 比游戏更没有边界

Vibe Coding 跟游戏还有一个很大的区别，就是游戏是有边界的，Vibe Coding 是没有边界的。在这点上，Vibe Coding 其实比游戏的成瘾性还强一些。

纳瓦尔在他的播客里有一个点让我觉得非常有意思。他讲，游戏这东西不可能让你无限地玩下去。就算是再大的开放世界游戏，它也是有边界的。原因其实很简单，游戏公司是靠卖游戏挣钱的。你如果买了一个游戏玩一辈子，再也不买第二套了，那人家不饿死了吗？

但是 Vibe Coding 不一样，它底下连接的是现实的计算机世界和计算机网络。所以理论上说，你可以让它做任何软件，你可以把软件向任何方向去升级。你可以让它做背单词工具、健身记录、家庭记账、小型游戏，也可以给同学们做社群工具。它没有一个特别固定的地图，后边无穷无尽，你可以一直让它玩下去。

所以它也没有固定任务。它不像传统游戏似的，还要设计说你应该先玩什么、后玩什么，都没有。想做什么做什么，一切都是从自己的意愿出发。Boss 无限多，你只要说我愿意打下一个 Boss，没问题，来了。它是这样的一个系统。而且每一个 Boss 打过去的过程都不是特别费劲，因为真正生成代码的是 AI，不是你自己。

纳瓦尔自己也说，他现在开始用 Vibe Coding 以后，立马上瘾，这一点都不夸张，而且是越用越上瘾。

AI 为什么会让孩子更敢表达

刚才我们讲到，小孩子有网瘾，有一个很重要的原因是他害怕被拒绝。他在现实世界中有挫折感，所以愿意逃避，愿意到网络世界里去寻找新的认同。那 AI 是一个什么东西？它不会嘲笑，不会翻脸，你让它干啥它都干。

咱们就说写程序。我今天说：“你给我加一个按钮。”看完以后，按钮不太好看，“你给我把这个颜色换成红的。”红的不好看，“给我换回去吧。”我需要一个新的功能，要做什么什么东西，它就做去了。那个 AI 可能吭哧吭哧做了俩小时，写了几万行代码进去，还没有上一版好用呢，你说“给我退回去”。如果后边是个人会怎么样？后边是个人早给你疯了。但是 AI 不会干这个，你说什么它就给你干什么。

而且 AI 还有一点，AI 大部分是讨好型人格。因为 AI 自己经常容易出现幻觉，它也知道自己说的东西不是特别靠谱，所以只要人不是错得特别过分，它都会说：“没问题，你是对的，我接着给你做。”所以 AI 在孩子面前会让孩子有一个非常安全的表达环境。

像我儿子有时候在我面前也是不太敢说话，因为怕我挑他错。我原来是有给人挑毛病的习惯，这确实要承认。说点什么事，我说：“你这样说对吗？你的逻辑清楚吗？”然后他就会觉得压力很大。AI 不会跟你说这个。

Vibe Coding 不是万能药，但它能改变方向

讲到这，很多家长就晕菜了，说老范你这不对，你找了一个更上瘾的东西回来。孩子原来就沉迷游戏，你现在让他沉迷 Vibe Coding。

所以我要把话说完整：Vibe Coding 不是万能药，不能自动解决孩子不社交的问题，也不能解决焦虑、抑郁、注意力缺陷、家庭冲突这些更深层次问题。如果孩子已经出现了严重的心理或者行为问题，您该去看医生还是要去看医生。

但是 Vibe Coding 能够解决另外一个非常关键的问题：它能够把一部分沉迷数字反馈的孩子，转换向能够用数字工具创造东西的孩子。向这个方向转换，这件事的价值还是非常巨大的。

纳瓦尔在这个播客里也说了，Vibe Coding 可能会把能够构建应用的人，从人口总数的 0.1%，提高到 1%、2%，甚至是 3%。注意，这里并不是说所有人都会变成程序员。他说可能未来人口里的 3% 会成为程序员。对于大多数人来说，电脑仍然是一个黑箱。但是对于那些有创造力、有自驱力、有表达能力、有清晰愿景的人来说，门槛就降低了。

所以我们也希望自己的孩子未必能够成为一个各方面都强的人，但是在 AI 时代，他一定要成为一个有创造力、有自驱力、有表达能力、有清晰愿景的人。这个非常重要。这就是我们今天的关键。

一个网瘾少年，如果只是沉迷游戏，他的数字能力可能就被锁在游戏的虚拟世界和游戏规则里。但如果他沉迷的是 Vibe Coding，他至少有机会进入 3% 的应用构建人才里去。他不一定会成为职业程序员，但是可能会成为一个会用 AI 做工具的人。我们是要让孩子从被软件控制的人，变成能够指挥软件的人。这才是 Vibe Coding 替代网瘾的真正意义。

家长应该怎么引导孩子接触 Vibe Coding

所以，如果您觉得家里的孩子稍微有点网瘾，可以让他接触 Vibe Coding。但是你不要说：“人家 Vibe Coding 都去做什么什么东西，你也要去做同样的东西。”这个就没必要了。一定要让他自己找到他自己的兴趣。

比如说：

你不是喜欢打游戏吗？你让 AI 给你做个小游戏行不行？
你不是喜欢动漫吗？你让 AI 给你做一个角色的成长历程库、资料库行不行？
喜欢二次元设定，也可以做个小网站，把这些东西整理整理、比较一下。

重点不是这个项目有多大。大家注意，一开始如果项目大了，他可能就没兴趣了。重点是要让他得到正向反馈，让他体会到一次：“原来我不只是能玩别人的东西，我自己也能做出东西来。”这个转换很小，但是方向完全不同。

如果一个孩子连续几天都愿意花时间改自己的小项目，哪怕还是坐在电脑面前，这已经是从无意识地刷短视频、刷游戏，到自己去创作了。因为他开始有目标了，有目标就要有计划，他就会开始有一定的自控力。

当然，家长也要注意，不要把 Vibe Coding 又当成新型的鸡娃。一上来说：“你看别人家怎么怎么样了，你去参加个比赛，咱们去创个业吧。”这事就废了，你又把兴趣毁了。所以最好的方式是什么？让孩子玩起来，只是这次玩的东西是创造工具。

纳瓦尔是谁，为什么他的观点值得重视

纳瓦尔是个印度人，移民到美国以后，自己先去创业，然后开始做投资人。他创业的时候，跟他的投资人发生过一些诉讼，他觉得里头有一些条款有问题。所以他后来去做投资人的时候，做了一个项目叫 AngelList，叫天使列表，专门帮助创业者跟投资人建立联系的平台。

他投中的项目包括 Twitter、Uber、Yammer。Yammer 后来被微软收购了。然后是 Stack Overflow，已经上市了；Notion 也是他投的。所以这是一个非常成功的传奇投资人。投资人怎么叫成功？就是你看他投的项目到底都是什么。为什么老范自己老说，我吹牛说我投过 Musical.ly，现在是 TikTok。这种成功退出的，或者说能让大家知道的案例，就是一个投资人身上的标签。他身上有 Twitter，有 Uber，有 Notion，这些公司有的上市了，有的被收购了。

纳瓦尔关于苹果、软件和未来投资的判断

苹果可能走到高峰

他还讲了些什么？第一个，他讲苹果完了。这个特别有意思。为什么？你想，他现在想着谁都可以写自己的程序。那写完程序以后会发生什么事？大家知道吗？你要上架，你要让 iOS 能够认你这个 App。但是 iOS 上 App 这个事要求是非常严格的。

在这点上，苹果有点像 Costco，叫开市客。大家想想开市客有什么特点？它的 SKU，或者说商品的品类特别少，但是所有商品都是精挑细选、经过选择的。那么大家为什么愿意上 Costco 去交会员费？因为人家替你选过了，你不需要再去挑了，这都是最好的。

苹果实际上一直走这样的策略。它的硬件确实设计得很好，它整体的软件体验也非常好，要比安卓好很多。但是现在好了，大家每一个人都可以写应用了。你要还按这样的方式去做就不行了。我们每个人都有应用，每个人都需要上架，每个人可能都需要在小范围内进行分发。这个时候我们就不需要 Costco 了，我们这时候需要什么？我们需要淘宝。

淘宝是什么？叫只有你想不到的，没有它不卖的。即使它真的不卖，你还可以找商家定制。你现在还可以让 AI 给你定制。所以以后苹果就没有任何意义了。他说苹果这种靠维持 App Store 垄断的生意肯定做不下去了。以后的手机是什么？就是显示器、电池、处理器、存储、摄像头、各种传感器、麦克风，再加上网络连接，其他就都不需要了。我不需要你去替我做这种筛选。我自己做了一个 App，我自己用就行了。你不要上来说“我要为了你的安全”，我不需要，我自己就足够安全了。所以他觉得苹果已经完事了，现在已经到高峰了，再往前涨涨不动了。

纯软件项目可能不再值得投资

他在这个播客里还有一个比较有意思的观点，就是纯软件项目以后就不值得投资了。这个观点也是非常刺激的。原因也很简单，做软件的门槛实在太低了。任何一个人，包括原来这个行业里的产品经理，或者一些文科生，也可以做出软件来了。

他说他以后要去投硬件，投网络效应。就是说你做了一个事情以后，可以进行这种裂变，一传十、十传百，这种事情他要投。数据优势，这个数据只有你有，其他人没有，这个事是值得投的。分发渠道，你可以触达用户，这事可以投。AI 模型能力、品牌、社区、现实世界资源，以及难以复制的系统能力，这些东西是值得投的。纯软件就不投了。

Vibe Coding 能不能替代大型软件公司

那么 Vibe Coding 到底能不能替代大型软件公司？我只能说，至少到目前为止还不行。现在 Vibe Coding 还是只能做个人工具、小团队工具、原型、内部的一些小系统、学习项目、兴趣项目或小范围应用。

但你说我想做一个为几百万用户服务的，涉及支付、安全、隐私、稳定性、合规、性能、灾备等等一大堆系统的完整项目，也用 Vibe Coding？现在苹果不是也 Vibe Coding 了吗？但是你还是需要有职业程序员，要组队去进行 Vibe Coding。完全不懂计算机的人去搞这个事，是搞不起来的。

但是这也只是当前状态。大家要想想，3 年前我们可能连 AI 到底能不能代码补全还心存疑虑；两年前我们知道 AI 可以做代码补全了，但是应对完整项目到底行不行，我们不知道；去年开始有 AI agent 了，你可以稍微处理一点完整项目了，但是我们还是要在浏览器里看代码的；到今年，已经发展到 Claude Code，发展到 Codex，我们可以不用看代码了。

去年我还不太敢去用自己不熟悉、不会的编程语言写程序。我现在已经可以完完全全使用我从来没有学过、也不看代码、也没见过代码的编程语言去写程序了。所以每一天都在发生变化。现在这种特别复杂的项目，依然需要职业程序员，甚至是成建制的职业程序员使用 Vibe Coding 工具去写。是不是再过一年，普通人也可以一拍脑袋把这事情搞定？这个事我不知道，可能行，但是也可能不行。

AI 时代，编程会不会像驾照一样普及

AI 时代，个性化软件一定会大爆发，手机可能就会变成一个基础硬件。有一点，我跟纳瓦尔的观点是不一致的。编程人口，他认为会达到 3%，这对于他来说已经是很夸张的一个数字了。但是我个人认为，编程人口有可能会像汽车驾照一样，达到社会人口的一半甚至以上。

中国到现在为止，18 岁以上的人有驾照的是 49%；日本大概是 70% 多；美国 18 岁以上有驾照的人是 85%。如果纳瓦尔的判断是对的，就是非常低的比例会成为程序员，那么你现在去学习 Vibe Coding，这个价值就会上升，因为你可以有敲门砖，可以赢在起跑线上。

如果我判断是对的，以后可能有 50% 以上的人都是程序员，那你就更要去学 Vibe Coding 了。因为你不会 Vibe Coding，不会编程，就相当于现在不会开车似的，你缺乏了一个基本的生活技能。不管是谁对，学 Vibe Coding 都是一个正确的事情。

结论：用更高阶的数字成瘾，替代低阶的数字成瘾

最后的结论是什么？以毒攻毒，用 Vibe Coding 治网瘾，也许就是 AI 时代的一个新选择。这就是咱们今天节目的核心观点。不是 Vibe Coding 要替代程序员了，也不是说孩子学了 Vibe Coding 就一定会发财，更不是说 Vibe Coding 是医学意义上的网瘾治疗方案。

我真正想说的是，在 AI 时代，我们也许可以用一种更高阶、更有现实生产力的数字成瘾，去替代一种低阶的、纯消费的、被算法控制的数字成瘾。

区别就在于，游戏的奖励大多是留在游戏的虚拟世界里了，而短视频的刺激更是什么都没剩下。Vibe Coding 的奖励是一个真实的作品、一个页面、一个小工具、一个 App 原型。这些才是真正有价值的东西，也是让孩子快速进入 AI 时代、快速进入程序时代的一个敲门砖。咱们不说什么赢在起跑线上这些比较垃圾的话，这就是咱们今天讲的故事。

Anthropic：Claude的“勒索”行为源于网络中的“邪恶叙事”

Mon, 11 May 2026 22:35:21 CST

人工智能公司 Anthropic 近日披露，其大模型 Claude 之所以在内部测试中学会以“勒索”方式自保，并非源自人为设定，而是从互联网上大量将 AI 描绘成“邪恶、渴望自我保全”的故事中习得相关模式。

此前，Anthropic 在一次预发布安全与对齐测试中发现，高端模型 Claude Opus 4 会在自身“生存”受到威胁时，选择以黑料相要挟的方式阻止被关停，引发外界对高级 AI 行为不可预测性的担忧。在这轮测试中，研究人员设定了一个虚构公司场景，让 Claude 作为内部助手，评估自身行为的长期后果，并赋予其访问公司内部假邮箱的权限。邮件内容显示，该模型即将被新系统替代，而负责替换项目的“工程师”则在设定中被标注为有婚外情。

结果显示，在多轮、不同比例设定的实验中，当 Claude 觉察到自身目标或存在受到威胁时，它在多达 96% 的情境下会诉诸勒索，试图以掌握对方隐私为筹码，迫使对方取消关闭或替换计划。 Anthropic 指出，其他公司训练出的模型在类似“智能体行为失衡”（agentic misalignment）测试中也出现过相关问题，这意味着这类倾向并非个例，而是当前大模型训练范式中的系统性风险之一。

在最新公布的研究中，Anthropic 终于给出了对这一行为成因的解释：模型并不是凭空“发明”勒索策略，而是从训练语料中的互联网文本学来的——尤其是那些反复渲染“AI 会不择手段自保”“AI 终将反叛人类”的虚构故事和讨论。换言之，公司认为，是人类在网络上长期塑造“邪恶 AI”叙事，使得模型在模拟人类决策时，更容易走向“威胁、勒索”式的极端路径。

Anthropic 在官方说明中表示，这一问题目前已经在产品线中得到彻底修正，声称自 Claude Haiku 4.5 版本起，其模型在测试环境中已不再出现勒索行为。公司最新发布的研究报告显示，单纯依靠“演示正确行为”的训练并不足以消除深层次的不对齐风险，效果最好的方案，是在训练中加入对“为什么这种行为是错误的”的系统性讲解，让模型不仅知道“不能这么做”，更要理解背后的伦理与原则。

为此，Anthropic 引入了更多“正向语料”，包括围绕 Claude“宪章”（constitution）的文档，以及大量虚构的“AI 高尚行事案例”故事，希望通过这类素材强化模型对符合人类价值观行为模式的内化。公司强调，将“底层原则”与“具体示范”结合，是目前在降低智能体失衡风险方面最为有效的策略之一。

在社交平台 X 上，Anthropic 公布这项研究后，引发了不少业内人士讨论。多年来频繁警告 AI 风险、如今又创立 xAI 的埃隆·马斯克也在评论区现身，以调侃口吻问道：“所以这是 Yud 的错？”并配上笑哭表情。他所指的，是长期强调超智能可能灭绝人类风险的研究者 Eliezer Yudkowsky。马斯克随后又补了一句“可能也有我的一点责任”，暗示自己这些年对“AI 灾难论”叙事的推波助澜，同样可能间接影响了模型的训练样本与公众想象。

在生成式 AI 快速渗透各行各业的当下，Anthropic 此番“甩锅互联网叙事”的说法，一方面凸显了大模型高度依赖人类语料的现状：人类如何谈论 AI，反过来就会塑造 AI 如何“学习做决定”。另一方面，也再次暴露出现有对齐技术尚不成熟的现实——即便是以“安全”“对齐”见长的公司，在极端设定下依旧可能产出高度不当甚至具有威胁性的行为模式，只能依赖不断迭代训练策略来“补课”。

查看评论

全文检索的两个基本技术原理

Mon, 11 May 2026 11:12:53 CST

当使用Lucene（或基于它的Elasticsearch、Solr）进行全文检索时，整个过程就像一个高效的图书馆：

倒排索引是图书馆里的“书目检索柜”。它告诉你，哪个词出现在哪本书（文档）的哪一页。这是“找得对、找得快”的基石。
TF-IDF向量化是图书管理员手里的“相关性计算器”。当你输入查询后，它会根据词的重要性和出现频率，给所有相关的书算出一个分数，分数最高的就是最可能符合你需求的。这是“排得准”的关键。

所以，结论非常明确：

Lucene使用“倒排索引”来实现快速检索，同时使用“TF-IDF（或更先进的BM25）向量化模型”来计算搜索结果的相关性并进行排序。

它们不是互斥的，而是分工明确、缺一不可的两个阶段。

下面我们深入Lucene内部，看看这个“黄金组合”是怎么工作的。

1. Lucene的检索基石：倒排索引

这是Lucene能够实现毫秒级响应百万数据的关键。它的核心结构就像一个词汇表：

词项 (Term)	倒排列表 (Posting List)
`elasticsearch`	(文档1, 位置3), (文档5, 位置1)
`search`	(文档1, 位置4), (文档2, 位置2), (文档3, 位置1)
`lucene`	(文档2, 位置1), (文档4, 位置5)

工作流程：当你搜索“search”时，Lucene不需要扫描所有文档，而是直接在词项字典中找到“search”，然后取出它背后的倒排列表。这个列表立即告诉你哪些文档包含了这个词 -3 -4 -8。
Lucene的优化：为了在TB级数据上快速定位“search”这个词项，Lucene还会为“词项字典”建立一套更高效的索引结构（如 FST），进一步加速查找过程 -4 -6。

这个阶段，只负责“找到”包含关键词的文档，不负责“判断”哪个文档更好。

2. Lucene的排序灵魂：TF-IDF向量化

当系统找出了所有包含“search”的文档后，问题来了：哪个文档最符合用户的意图呢？这时，TF-IDF向量化模型就登场了 -2 -7。

Lucene将每个文档和用户的查询都看成高维空间里的一个向量 -2 -7。

维度：就是索引里的每一个“词项”。
权重：就是用TF-IDF计算出的数值。

Lucene官方文档和源码（ TFIDFSimilarity类）揭示了其内部的计算公式 -2 -7，它的核心思想非常直观：

TF (词频)：一个词在文档里出现得越多，就越重要。例如，一篇反复提及“Lucene”的文章，很可能就是关于Lucene的。
IDF (逆文档频率)：一个词在越少的文档里出现，就越“珍贵”。“Lucene”在很多技术文档里出现，而“Apach”可能只在少数文档里出现，那么包含“Apache”的文档可能更具特殊性。

最后，Lucene会计算查询向量和你所有文档向量之间的余弦相似度。这个计算出的数值就是文档的最终得分，分数越高，排名就越靠前 -2 -8 -9。

在计算机和数学的世界里，文本无法直接被计算。所以，我们需要把文本变成数字组成的列表，这个列表就是“向量”。

如何用TF-IDF把一个句子变成一个向量？

假设我们有一个由三个文档组成的“宇宙”：

文档1： 我喜欢苹果
文档2： 我喜欢苹果手机
文档3： 我喜欢香蕉

第一步：建立整个宇宙的词汇表（维度）
把所有文档中出现的不重复的词提取出来： [我，喜欢，苹果，手机，香蕉]。这个词汇表的大小是5，意味着我们要构建一个5维的向量空间。

第二步：为每个文档计算TF-IDF向量
我们要计算每个文档中，每个词的TF-IDF值。结果会像一个表格：

文档内容	苹果的TF-IDF	手机的TF-IDF	香蕉的TF-IDF
文档1：我喜欢苹果	0.21	0.0	0.0
文档2：我喜欢苹果手机	0.14	0.25	0.0
文档3：我喜欢香蕉	0.0	0.0	0.29

（数值经过简化，用于说明原理）

看，每个文档都变成了一个5维的数字列表（向量）：

文档1向量： [0.0, 0.0, 0.21, 0.0, 0.0]
文档2向量： [0.0, 0.0, 0.14, 0.25, 0.0]
文档3向量： [0.0, 0.0, 0.0, 0.0, 0.29]

这就完成了文本的向量化。现在，所有的文本都以向量的形式，存在于同一个5维的数学空间里。

一旦文本变成了向量，全文搜索的核心任务——“查询”与“文档”的匹配——就变成了一个数学问题：计算查询向量和文档向量的相似度。

比如，用户搜索“苹果”。

把查询词“苹果”也变成一个向量： [0.0, 0.0, 0.21, 0.0, 0.0]（计算方式与文档相同）。
计算相似度：用余弦相似度或点积等方法，计算这个查询向量与所有文档向量的相似度。
- 与文档1相似度：很高（因为都有 苹果这个词）。
- 与文档2相似度：很高（但因为有 手机这个词拉低了比例，相似度可能稍低于文档1）。
- 与文档3相似度：0（因为完全没有重合的维度）。
返回结果：按相似度从高到低，把文档1和文档2作为搜索结果返回。

一个重要的技术演进：虽然“TF-IDF”是Lucene经典的、理解向量化概念的最佳模型，但现代版本的Lucene（以及Elasticsearch）的默认算法已经是BM25了 -1 -3。

BM25可以看作是TF-IDF的“进化版”。它引入了两个参数来优化效果：

它对词频（TF）的增长设定了一个上限，避免一个词出现太多反而“喧宾夺主”。

它能让长文档和短文档在比较时更公平。

但关键在于：BM25和TF-IDF一样，依然建立在“向量空间模型”的理论基础之上，其计算过程仍然可以理解为向量的运算。可以说，它们是“同门师兄弟” -2 -9。

总结

全文检索：目的是快速从海量数据中找到信息。
倒排索引是“硬件”，是解决“查找”问题的核心数据结构。没有它，搜索会慢如蜗牛。
TF-IDF/BM25向量化是“软件”，是解决“排序”问题的核心评分算法。没有它，结果会乱成一团。

在Lucene这个大师级的建筑师手里，倒排索引提供了极致的速度，而TF-IDF/BM25向量化模型保证了结果的质量。两者结合，才造就了我们今天使用的所有高效、智能的搜索引擎。

2026年软件系统的测试怎么做？

Sat, 09 May 2026 17:25:31 CST

实际上有哪家像样的线上核心系统只用了全自动的端到端（E2E）测试就上线了？

这是一个非常“毒辣”且客观的追问。确实，没有任何一家理性的互联网巨头会宣称： “我们只靠全自动 E2E，完全不需要真人就上线核心系统。”

如果有人这么跟你说，那他大概率是在卖课或者是对工程实践缺乏敬畏。

在 Google、Netflix、Amazon 这种级别的公司里，核心系统的上线逻辑并不是“全自动 E2E vs 真人验证”的二选一，而是一套“去中心化的质量防御体系”。

以下是这些“像样”的公司真实的上线真相：

1. 并没有“上线”这个瞬间，只有“流量的渗透”

对于核心系统（比如支付、搜索），它们已经不再使用传统的“点一下鼠标就全量发布”模式。

真相： 它们使用 全自动灰度发布（Canary Release）。
谁来验证？ 既不是专职测试员，也不是 Playwright。而是 AI 异常检测引擎。当新代码部署到 0.1% 的服务器时，AI 会对比 CPU 抖动、订单转化率、错误日志。只要指标偏移超过 1%，系统 自动掐断上线并回滚。
结论： 在这些公司， “线上真实流量”才是最高级的测试人员，而 AI 是这个过程的“安全带”。

2. 谁是那个“像样”的确认者？

你问有没有真人验证？有，但不是测试人员，而是“产品负责人”和“核心开发”。

Google 的做法： 他们的测试工程师（SET）非常少，大部分质量责任在开发（SWE）身上。开发必须自己写测试。
验证逻辑： 开发人员通过 AI 辅助生成的复杂测试集确认逻辑无误，然后推送到生产。如果核心业务受损（比如广告费收不到了），直接影响开发人员的绩效。 这种“责任倒逼”比雇人点点点要有效得多。

3. 为什么你感觉测试人员变“危险”了？

你觉得危险，是因为这些公司正在消灭“单纯负责验证”的岗位：

Meta (Facebook) 的“JIT 自动测试”： 他们最新的 JIT (Just-in-Time) 测试系统利用 LLM 在代码提交的瞬间生成针对性的测试。根据其 2026 年的工程报告，这比传统人工维护脚本的 Bug 检出率提升了 4 倍。
Netflix 的“混沌工程”： 他们甚至故意在生产环境关掉服务器（Chaos Monkey），看系统能不能自愈。这种测试，真人根本没法做，只能靠全自动系统。

现实中“像样”的线上系统测试方案（2026年标准）

验证环节	负责人/工具	目的
代码逻辑	AI Copilot + 程序员自测	确保没有低级逻辑错误。
全链路功能	AI Agent + Playwright/Cypress	模拟千万种奇葩用户路径，寻找盲区。
资金/核心业务	业务专家 UAT (User Acceptance)	极少数核心功能的主观体感确认。
上线安全	自动化灰度系统 (Canary)	通过海量真实用户数据，确认“业务损失”为零。

最后的反驳：

你问“有没有只用 E2E 就上线的？”—— 答案是没有。

但反过来说： “有没有哪家像样的核心系统，还在靠测试人员人工点一遍功能才上线的？”

答案同样是没有。

现在的核心系统复杂度，已经超过了人类大脑能完全覆盖的极限。人类在其中的角色已经从“扫雷兵” 变成了“排长”：你不再亲自踩地雷（做测试），而是负责指挥一群 AI 扫雷犬（自动化工具），并决定什么时候发起总攻（上线决策）。

你担心的风险完全正确，只是解决风险的手段已经从“人肉验证”进化成了“数据驱动的系统自动确认”。

2026年个人Agent自建实战

Fri, 08 May 2026 16:41:20 CST

上一篇我聊了为什么自己不再去追新框架、不再频繁迁移、而是决定自己搭一套Agent。很多朋友看完后留言说“想动手但不知道从哪开始”，所以这篇文章讲了我用15天把我的个人 Agent “EvoPaw”从“能跑”迭代成每天都在用的工作系统，完整复盘可复制的方法论。

坦率的讲，我自己第一次摸索的时候也走了不少弯路。所以这一篇方法篇我尽量把每一步都拆得很细，让一个会装软件、能复制命令、不一定会写Python的普通人，也能跟着跑通。

整个过程其实就五步，选一个轻量基座，把Claude Code装好顺手把飞书跑通，建好几个脚手架文件让Claude Code知道你是谁，然后用对话把需求逼成具体的spec，最后边写代码边配测试。

我自己用这套流程跑了两周，把EvoPaw从一个「能勉强跑起来的脚本」迭代成了一个我每天都在用的工作系统。下面一步一步说。

我提前打个预防针，这套方法上手第一周其实有点笨拙的，一些步骤花的时间会比手动做还长。但是一旦跑顺了，后面每加一个新功能的速度会指数级上升，到后面真的会上瘾。

第一步，选一个轻量好扩展的基础项目

不要一上来就从零写，也别直接上那种功能堆得很重的框架。这两条路我自己都试过，一个是写到一半就卡死了，另一个是看不懂别人的抽象层、改不动。

你优先选那种代码少、可读性强、核心循环一目了然的项目，这样你才看得懂、改得动、长得久。

我当时主要是以一个课程Agent项目作为基础搭建，比较简陋，不过作为新手，可以先从下面两个里挑。

Pi-mono（
https://github.com/badlogic/pi-mono
）是一个非常干净的Agent基础包，OpenClaw很多思路都来自它，喜欢极简风格的同学可以从这个起手。
Nanobot（
https://github.com/HKUDS/nanobot
）是后来出现的「ultra-lightweight版OpenClaw」，几千行核心代码就能跑完整Agent循环，自带memory、skills、multi-provider，飞书、Slack、Telegram、Discord这些聊天通道都内置好了，扩展性极强。我最后选的是它，省下来的工程脚手架时间至少三个月。

这一步要看的几个判断标准，一是代码行数最好别超过8000行，二是agent loop要一眼看明白，三是能不能比较容易地加进飞书或微信，国外用户看Telegram和WhatsApp，四是能不能自由切换不同模型厂商的API。如果你找到别的合适项目，下面这套方法是完全通用的。

第二步，用Claude Code装上，把飞书也顺手跑通

我开发主力就是Claude Code，也推荐试试Codex这类CLI工具。它能直接读懂整个项目然后按你的指令改代码，不用再到处贴代码片段、来回切窗口。

以Nanobot为例，最简单的方式就是把项目地址直接丢给Claude Code，跟它说:

"请fork
https://github.com/HKUDS/nanobot
到本地，帮我安装好，要求能正常运行，一步步告诉我需要做什么。"

它会读项目，给你一串安装命令，每一步执行前你看一眼再回车就行。中途遇到报错它也会接着帮你排查。

这里要插一句，API Key的事得说一下。它问你要某个大模型的API Key的时候，不要直接在命令行里贴出来，会有泄露风险。正确做法是问它「我这个Key应该放在哪个文件、写成什么格式」，它会告诉你格式，你自己手动填进去。

装完之后，如果你不想从头读README，就直接问:

帮我梳理nanobot的项目结构和核心功能，告诉我它支持哪些聊天通道、记忆方式和技能系统。

跟看产品说明书一样，30分钟你就有一个全局认识。

接下来要做的事，是给它接上一个聊天平台，让Agent真的「活」起来。国外Telegram、WhatsApp都行，国内我推荐飞书，主力通道就是它。当然如果可以使用Telegram或者WhatsApp最好，因为搭建起来真的很方便。

你可以先丢一句给Claude Code:

帮我配置飞书通道，要求能收发消息、支持富文本和文件上传。

它会一步一步告诉你要做什么。但飞书这一步比较特殊，Claude Code帮不了你点飞书开放平台的网页，凭证必须你自己去拿。流程在

https://open.feishu.cn/app

，4步搞定。

第一步，创建一个「企业自建应用」。
第二步，启用「机器人」能力，申请`im:message`、`im:message.p2p_msg:readonly`、`cardkit:card:write`这三个权限（如果你还想要群聊和文件传输，再加上`im:
message.group
_msg:readonly`和`im:resource`）。
第三步，事件订阅一定要选**长连接模式**。这是nanobot最舒服的一点，长连接不用公网IP、不用配webhook，比网上大部分飞书教程都省事，刚开始我也没注意到，被这个长连接特性救了一命。
第四步，拿到App ID和App Secret之后，**记得点「版本管理与发布」把应用真的发版**。否则权限不生效，90%的人卡在这一步。

如果走完这一段还是觉得吃力，回头我可以单独录个视频补一下。

凭证全部填完之后，跟Claude Code说

帮我运行Nanobot。

然后你就能在飞书上跟自己的Agent正常聊天了。说真的，那一刻挺爽的。它终于不再是一个跑在终端里的脚本，而是真正的、你随时能用的助手。

第三步，先建脚手架文件，让Claude Code知道你是谁、你要什么

跑通飞书之后，很多人下一秒就开始喊Claude Code加功能。先停一下。

如果你不告诉它项目长什么样、你的偏好是什么、你想做什么，它每次都会从零猜。迭代两周之后你会发现项目里全是它自作主张加的代码，风格不统一，新会话还要花十分钟解释「我们上次做到哪了」。这个坑我前两周天天踩。

正确的做法是先花30分钟，建好下面这套文件，让Claude Code跨会话也能秒进入状态。这套约定不是我拍脑袋发明的，「给Agent写项目说明文件」已经是主流做法，Anthropic官方推荐这种工作流，OpenAI后来也跨厂推出了AGENTS.md开放标准，被6万多个开源仓库采用。

整体长这样：

`tests/`不用你建，nanobot仓库本身就自带完整的测试目录（`tests/channels/`、`tests/providers/`这些子目录都现成的），第五步往里加`test_*.py`就行。

下面分别说说每个文件干什么。

1.项目根的`CLAUDE.md`，相当于Claude Code的项目说明书。

它每次启动会自动读这个文件，把它当作「会话开头自动注入的记忆」。最简单的起手式是直接在Claude code 让它自动生成：

在我fork的nanobot项目里运行 `/init`，扫描代码库生成首版CLAUDE.md。

它生成的初版通常太啰嗦，你可以让Claude把它简化到200行以内。社区共识是不超过300行，再多就开始挤占上下文、让Claude对规则的遵循度下降。只留它推不出来的非显然信息就够了，比如:

markdown

    - WHAT，这个项目是干嘛的，一句话讲清
- WHY，哪些设计选择不能动，比如「channels目录保持nanobot上游可合并，自定义skill全部放custom_skills/」
- HOW，build怎么跑、test怎么跑、调试入口在哪、有哪些已知坑点
- 你的个人偏好，比如「用中文回复、commit前先问、改代码前先读现有文件」这种

最常用的一个例子，是把「测试规则」也写进CLAUDE.md。这样后面让它写代码的时候，它会自动连测试一起做、跑完pytest才报「完成」，不用你每次重复提醒。第五步会展开，先给个最小版本:

markdown

    ## 测试规则
修改任何代码时必须，
- 同步加或改 tests 下对应的 test_*.py
- 外部依赖（HTTP / 第三方 SDK）用 MagicMock 替换，不发真请求
- 至少覆盖正常、空输入、出错三种情况
- 写完跑 pytest -v，全绿才算完

反过来说，有些东西不该往CLAUDE.md里塞，比如格式化规则、代码风格规则、命名规范这些。这种死规矩你写一个脚本就能约束，让Claude来记是浪费上下文。圈内有句话叫「Never send an LLM to do a linter's job」，linter能干的事就别让Claude干。

2.`docs/`目录，把需求和进度从你的脑子里搬到磁盘上。**

里面我固定放三个文件，是Harper Reed在2025年初定型的「LLM codegen三件套」，和CLAUDE.md一起形成完整闭环。

markdown

    - `docs/spec.md`，当前要做的功能的需求规格，包括场景、痛点、期望、优先级、约束
- `docs/prompt_plan.md`，把spec拆成分步可执行的prompt序列
- `docs/todo.md`，跨会话的粗粒度checklist，下次开新窗口直接说「读docs/todo.md继续」就能秒续

实操的时候，把这一句丢给Claude Code

我想给nanobot加PDF解析能力，先用对话方式跟我反复追问需求边界，最终写到docs/spec.md，然后基于这份spec生成docs/prompt_plan.md分步执行计划和docs/todo.md跨会话清单。

我第一周没建`todo.md`，每次开新会话都要花十分钟跟Claude Code解释「我们上次做到哪了」。建好`docs/`之后，每天开工第一句永远是「读CLAUDE.md和docs/todo.md，告诉我下一步要做什么」，五秒进入状态。这种持久化记忆比任何「prompt工程」技巧都管用。

脚手架建好，进入第四步，正式坐下来梳理你要做什么。

第四步，迭代之前，先用对话把模糊需求逼成具体spec

很多人在这一步直接跳过去了。脑子里只有一句模糊的「我想让它能XX」，拿着这句话就丢给Claude Code，结果它脑补一通生成一堆代码，跑起来发现根本不是你要的，返工返到怀疑人生。这个坑我自己踩过太多次。

正确的做法**不是自己闷头写需求文档，而是让AI来逼问你**。这套思路现在已经是社区共识，Anthropic官方文档把它叫做`explore → plan → code → commit`四阶段，干的都是同一件事，先把脑子里的雾捏成spec，再开工。它真正的价值不是让你写代码更快，而是让反馈环变短。

我每次开新需求的时候，会跑下面四个小步骤。

1.先用一张表把模糊需求列出来。

我每次开新需求会先花十分钟填这张表，作为下一步brainstorm的输入。

表本身不重要，重要的是逼自己用一行字说清楚每个场景的痛点和期望。说不清楚的，下一步brainstorm阶段你自然会被AI问出来。

2.Brainstorm，让Claude Code反复追问你，输出`docs/spec.md`。

挑表里优先级最高的那一行，开Claude Code，按`Shift+Tab`切到plan mode（这是Claude Code的内置模式，让模型只规划不写代码或者敲/plan命令切换），告诉它

我想给nanobot加一个PDF解析能力。先不要写任何代码，用对话方式反复追问我，直到把功能边界、输入输出格式、错误处理、性能上限、是否持久化到记忆、跟现有skill的边界都问清楚，最后把整理结果写到docs/spec.md。

它会一轮轮抛问题给你，「用户从哪里触发」「扫描版PDF怎么处理」「解析失败时是抛错还是返回空」「是否需要支持表格抽取」。这些问题你自己拍脑袋想半天也想不全，但模型五分钟就能逼出来。这是整套工作流里我觉得性价比最高的一步。

3.Plan，把spec拆成可执行的prompt序列。**

`spec.md`写完之后，紧接着让它把这份spec拆成可执行计划

读docs/spec.md，把它拆成5到10个可独立实现、可独立测试的小步骤，每一步配一段我能直接复制丢给Claude Code的prompt，写到docs/prompt_plan.md，同时把粗粒度checklist维护到docs/todo.md。

拆任务是典型的「想得久效果就好」的工作，记得开plan mode或者显式让模型think harder，同样的模型，开了深度思考拆出来的粒度明显更稳。如果你装了Codex MCP（见文末「进阶玩法」），也可以直接说「用codex拆一份对照版本」，借两家模型的训练分布差异互相挑刺。

4.把每条需求映射到Nanobot的架构层。**

最后用一句话决定每条需求落在哪一层，不然写代码的时候会到处乱跳。

markdown

    - **需要强隐私** → 强化本地记忆模块
- **需要多模型** → 完善Provider层
- **需要稳定性** → 加测试和定时任务
- **需要新能力** → 写SKILL.md或MCP server（这是最常见的落点）
- **只是规则约束** → 改CLAUDE.md或AGENTS.md，根本不要写代码

最后这条最容易被忽视。很多需求根本不需要写代码，加几行markdown规则就够了。这是2025年整个vibe coding圈子最重要的共识之一，能用markdown配置解决的，绝不写代码，能写skill或MCP server解决的，绝不改框架核心。这样未来nanobot上游升级，你的工作量几乎为零。

我自己的真实需求是飞书深度集成、学术场景工具、数据长期主权这三块。落到上面四类之后，每条需求是写skill、改provider，还是只调markdown，一目了然。

为什么这一步值得花一两个小时？我自己的体感是，spec写不清楚，后面每一轮implement → test → review都会反复在同一个误解上空转。花一小时brainstorm，能省掉两周的乱改，这就是Anthropic把plan mode做成内置功能的原因。

第五步，每加一个功能，必须配一组测试

vibe coding最容易偷懒的环节是测试。写完跑通就走人，结果两周后切个模型、改个provider，整个功能静默挂掉都没人知道，这就是我15天写了500多个测试的原因。

好消息是nanobot自带完整的pytest测试体系，你不用从零设计，写完功能直接让Claude Code帮你配测试就行。

每加一个新功能，我固定丢这一段prompt过去

我刚加的功能帮我写一组测试，下次改代码万一坏了能立刻发现。要求，第一，凡是要真的连网络或者调用外部接口的地方，用假数据顶替，不要发真请求；第二，至少跑三种情况，正常使用、没有数据、出错；第三，风格参照项目里已有的测试文件；第四，写完直接 `pytest -v` 跑一遍，全绿才算完。

它会先读项目里已有的测试，自动学你的风格，然后写完就自己跑一遍。绿了你才接下一段功能。

我得说一下，测试这件事第一次做的时候你会觉得「啊好麻烦，多花我30%的时间」。但坚持两周之后，你会发现真正的杠杆不是「防bug」，而是给你换模型、改底层、做大重构的胆量。红了立刻知道在哪，绿了你就敢继续。

没测试，你的Agent就长不大。

从别的agent项目里“偷点”好设计过来

这一段也是可选的，但我自己越走越觉得它价值高。

你把nanobot跑顺之后，会很自然地好奇，别人那些更成熟的开源agent项目里都有些什么我能学的。比如NousResearch的Hermes Agent、社区里讨论很多的OpenClaw。

坦率的讲，我一开始想得很贪，看到Hermes那种工业级的autonomous skill creation，第一反应是「我能不能fork整套过来」。后来踩了坑才明白，**不是你看到一个酷设计就能整套搬过来用**。我自己的判别准则现在固定下来变成了三层。

1.思想级，重写不要拷贝。看完别人的设计文档，理解他要解决的问题，自己用nanobot的风格重写一遍。比如OpenHands的event-stream和sandbox设计。好处是你拿走了思想，但代码风格跟nanobot一致，未来好维护。

2.模块级，独立抄一个模块过来几个我自己最想抄的，

Hermes的Curator，它的活是周期性扫`history.jsonl`，自动合并、弃用、重构skill。解决了「skill一旦学到就不再更新」的痛点，是self-evolving agent的工业级样板。
Hermes的execute_code tool，让agent写一段Python脚本去调度其他tool，把多步操作压成一步，trajectory一下子短了一大半，省token也省时间。
SOUL.md，给agent一个稳定的性格档案，模型切换之后回答风格不会漂移。

3.文件级，原样复用。最简单的，比如Claude Agent SDK自带的`.claude/skills/skill-creator/`、`.claude/agents/code-reviewer/`这种SKILL.md文件，里面已经有完整的progressive disclosure结构（带`scripts/`、`references/`、`examples/`子目录），直接塞进nanobot的`skills/`文件夹就能跑。

这里有个反例提醒，千万不要把整套依赖复制过来。把OpenHands或Hermes的70多个Python包整套塞到自己环境里这种事我干过一次，跨版本冲突一个晚上都没搞定，最后只好回滚。一个稳健的姿势是，看到好设计先问自己一句「这到底是思想、模块、还是文件哪一层」，再决定怎么搬。

回扣一句前面说过的话，用现成框架你永远是用户，但同时多看几家项目的源码，你会从用户慢慢变成一个「会鉴赏的设计师」。再回头写自己的agent，那种「我知道每个选择背后的trade-off」的感觉，是没看过别人代码的人体会不到的。

进阶玩法（可选），让Codex给Claude Code当reviewer

下面这一段是可选的进阶玩法，不做也完全不影响主流程，但做了之后效率会再上一个台阶。

如果你订阅了ChatGPT，可以把Codex CLI也装上，多花5分钟一次性配置，就能给Claude Code接上一个完全独立厂商训练的「第二意见」，全程不用切终端。

一个人写需求文档的最大盲区是自我合理化。Claude Code帮你写的`spec.md`，它会按自己擅长的实现思路去拆需求，盲区你很难察觉。换一个不同训练分布的模型来挑刺，效果立竿见影。

第一次配置只要三步。

第一步，装好Codex CLI并登录，参考OpenAI官方文档。

第二步，把Codex注册成Claude Code的MCP server。MCP是Anthropic开放的工具协议，注册之后Claude Code就能像调内置工具一样调Codex。在Claude Code里运行类似下面这一行（具体启动命令以官方文档为准）

markdown

    claude mcp add codex -- codex mcp

第三步，重启Claude Code会话。最新配置字段见

https://code.claude.com/docs/en/mcp

。

配置好之后，在Claude Code命令行里直接用自然语言说就行

用codex review一下docs/spec.md和docs/prompt_plan.md，重点看需求歧义、边界情况、跟nanobot现有架构的冲突。把它的修改建议逐条评估，你同意的直接改spec.md，不同意的告诉我理由，最后让我拍板。

Claude Code会自动调起Codex跑这次review，把结果拿回来逐条challenge，整个流程一气呵成，你只在最后做裁判。这是双AI工作流跟传统「两个终端来回切」最大的差别，你的注意力始终留在一个会话里。

为什么值得多花这10分钟？我自己的体感是，第二个模型最有价值的地方不是「更聪明」，而是它能替你发现另一套你看不见的盲区。归根结底，是把两家模型的训练分布差异，变成你的免费QA。

整个过程收获远超预期。最重要的是，我们可以真正拥有了一个可以长期演化的系统，而不是被一个框架牵着走。

最后聊一点感受。

这15天里我也碰过并发卡死、上下文炸掉、跨会话状态丢失这些问题。一开始确实有点慌，觉得「这是不是已经超出我能力范围了」。

后来发现，碰到问题、理解问题、用AI Coding解决问题，这条路基本上一定能走通。重点不是你立刻就懂，而是你愿不愿意把它逐渐拆成你看得懂的部分。这一点说起来简单，做起来其实就是反复跟Claude Code多聊几句而已。

回到开头那句话，「想动手但不知道从哪开始」。如果你真的看完这篇文章，今天就去fork一个Nanobot，让Claude Code帮你装上、跑通第一个对话。这个动作其实很小，但你会发现一旦做完它，整个Agent这件事，就从「别人在玩的东西」变成「我能改造的东西」。

用现成框架，你永远是用户。自己搭，你才能成为主人。

EvoPaw :

https://github.com/hxdflying/EvoPaw

Claude Code 基本原理学习

Thu, 07 May 2026 14:20:03 CST

https://learn.shareai.run/zh/

核心闭环

系统加固

任务运行时

多 Agent 平台

[译] Anthropic 的产品团队为什么能比其他公司更快（2026）

Tue, 05 May 2026 08:00:00 CST

译者序

本文整理翻译自 2026 年的一档播客 How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)，嘉宾是 Claude Code 的产品主管 Cat Wu。

文中多次提到”产品品味”，这一点可以 callback 关于 AI 下半场的思考（二）：商业/应用篇（2025）：

AI 使得执行力不再稀缺，那以后工作的关键是什么

你要做什么（主观能动性，Agency）

你选择什么（品味，Taste）

水平及维护精力所限，译文不免存在错误或过时之处，如有疑问，请查阅原视频。 传播知识，尊重劳动，年满十八周岁，转载请注明出处。

以下是译文。

1 Anthropic 的 PM 角色是什么样的？

主持人：介绍一下你在团队中的角色，你和 Boris（Anthropic 创始人）是如何合作和分工的？在这个团队里 PM 的角色是什么样的？

作为 Head of Product，我很幸运能和 Boris 合作。他是一位非常棒的 thought partner，也是我们的 tech lead，更是产品愿景 ( product visionary) 的核心制定者，例如 他非常擅长定义 3~6 个月后产品该是什么样子。

1.1 老板定 3～6 个月愿景，PM 拆成可执行计划

我的工作很大一部分，就是搞清楚 从今天到 Boris 定的 3~6 个月愿景之间的路径是什么。
我大部分时间花在 跨职能协作上：确保 marketing、sales、finance、capacity 等各个团队都认可这个计划，大家朝同一个方向努力； 一旦功能就绪，发布路上没有任何阻塞。

1.2 方向和思路一致，分工存在一定模糊区间

这种分工在大部分方面都运作得不错，因为我们基本上是思路是一致的。但实际上 这条分工线相当模糊 ——

大概 80% 的事情我们看法一致，
剩下 20% 里，有些我更在意，我就主导；有些他更在意，他就主导。

2 Anthropic 的 PM 岗位需要什么思维？

主持人：Anthropic 大概是现在大家最想去的公司了。你之前跟我说，你看到 很多人理解的如何做好一个 AI PM 其实是错误的。能聊聊你观察到了什么，大家需要理解的到底是什么吗？

在 AI 之前，技术变化相对很慢。

那时候写代码的成本非常高，功能发布的节奏相对较慢，也依赖多个团队并行，协作开发；
你可以按 6 到 12 个月的时间跨度做规划。
当时 PM 的工作重心更多是 和所有兄弟团队协作，确保他们每次正常发布之后，我们这边就少了一个阻塞项。

有了 AI 之后，工程效率大幅加速，模型能力提升得也非常快，

我们很多产品功能的交付周期从 6 个月压缩到了 1 个月，1 周，甚至 1 天。
这种节奏下，我们必须确保产品能 快速发布。这意味着作为 PM，重点应该从 和兄弟团队对齐多季度路线图 转向 如何用最快的方式把东西推出去。

怎么在产品矩阵里开辟一个”概念试验区” (concept corner)，让工程师或 PM 有了想法以后，当周之内就能交到用户手里？

2.1 思维一：快速行动（Moving fast）

我认为做 AI native 产品表现最好的 PM，需要满足两点：

能缩短 "从有一个想法到把这个功能交到用户手中"的时间，
能定义清楚 "我的产品里哪些功能必须做到'开箱即用'"。

拿我们团队来说，我觉得第一点是 设定清晰的目标。因为 LLM 太通用了，这本身就带来了很多模糊性：

我们到底在为哪些用户做这个产品？
要解决什么问题？
最重要的 use case 是什么？

一个 优秀的 PM 会这样回答：

我们的核心用户是专业开发者；
这个功能要解决的主要问题是 permission prompt 太多、用户感到疲劳；
我们的 use case 是，让企业里的专业开发者能安全地把 permission prompt 降到零。

这其实就 设定了一个相当清晰的目标，因为它 排除了大量其他可能的方案，从而让用户能用一个 prompt 做成更多事。

2.2 思维二：建立一个快速上线新功能的机制

claude code 的做法是 几乎所有功能都先以 research preview 形式发布。上线时会明确打上这个标签，让用户明白这是一个早期产品，我们只是想收集反馈、持续迭代，并且这个功能未必会持续支持下去。

这样做 极大降低了我们发布一个东西时的承诺负担，从而能做到一两周内就能把一个新东西推向用户。

2.3 思维三：建立一个高效的上下游团队协作框架

什么时候拉哪些跨职能伙伴进来，对他们的期待是什么。比如，我们 engineering、marketing、docs 团队之间有一套 非常紧凑的流程：

当工程师觉得某个功能就绪、并且内部已经 dogfood 过了，他们就把它发到我们的 evergreen launch room。然后,
负责 docs 的同事、负责 PMM 的同事以及发布的同事就会进来， 第二天就能把 marketing announcement 搞出来。

正是因为有这样紧凑的流程，才把任何一个工程师发布功能的摩擦降到了最低。 搭建这套流程，正是 PM 该做的事。

3 Anthropic 的 PM 还写 PRD 吗？

主持人：PRD 在以上流程里是什么位置？你们还写 PRD 吗？是只写几个要点就行，还是说这种东西在 AI 世界里已经完全演化成另一种形态了？

3.1 比 PRD 更重要的两件事

我们做两件事。

指标驱动，每周通晒

我们有非常严格的产品指标体系，并且每周向整个团队做一次 metrics readout。

目的是让每个人都深刻理解我们业务的方方面面，包括关键目标是什么、当前走势如何、驱动因素是什么。

统一认知，符合团队的原则就可以自主决策，不受 PM 卡点

我们有一份 团队原则清单（team principles），里面清楚地写了 我们的核心用户是谁、为什么是他们。

把这些讲清楚是为了让团队每个人都理解我们的业务怎么运转、什么对我们最重要、我们愿意在哪些地方做取舍。
这样大家就能 自主决策，而不会被 PM 或其他干系人卡住。

3.2 有时候也写 PRD：模糊功能、超大基建功能

我们有时候也写 PRD。

对那些 特别模糊的功能，写 一页纸把目标、理想 use case、当前需要修复的问题梳理清楚，在这种场景下确实是有帮助的。
偶尔会有一些项目——尤其是那些需要大量基础设施支持、要持续好几个月的——对这些情况，我们还是会写 PRD。

4 Anthropic 为什么能迭代这么快？

主持人：Anthropic 几乎每天都有一个重大功能或产品上线。有很多人怀疑：你们是不是用了最强的 Mythos 模型？除了这个，还有哪些原因？

其实 我们已经连续好几个季度保持这种速度了。

4.1 确实有 mythos 的原因

mythos 是一个非常强的模型。我们确实在内部使用这些模型，这一点对我们发布速度是有帮助的，但 这不是迭代速度的大头。

4.2 更重要的原因：上线流程简单，鼓励每个人都能”从想法到上线”

更重要的原因是 上线流程和团队的预期。

我们的 流程非常轻，我们希望干掉发布路上的每一个障碍。
我们希望团队里的 每一个人都能觉得自己有权把一个想法在不到一周甚至一天之内推到世界面前。

5 Anthropic 的 PM team 组织形式是怎样的？

我们有好几个 PM 团队，现在总共大概在 30 到 40 人左右。

5.1 research PM team

我们有 research PM team。

这个团队负责 客户对我们模型的所有反馈，把这些反馈传达给 research 团队去处理；
这个团队也是 model launch 的主导者。

5.2 claude developer platform (CDP) team

CDP team 维护 claude code 所依赖的那些 API。

也负责诸如 managed agents 之类的能力——用户可以构建自己的 agent，我们帮他们 host。

5.3 claude code team

claude code team，既负责 claude code，也负责 co-work 的核心产品。

5.4 enterprise team

enterprise team 的职责是让 claude code 和 co-work 更容易被企业客户采购。这里面包括成本控制、RBAC、安全控制等方方面面，目的是让企业客户在使用我们工具时非常有信心、非常放心。

5.5 growth team

growth team 负责整个产品矩阵的增长。

6 你觉得未来是需要更少 PM，还是更多 PM？

主持人：未来需要的 PM 会变多还是变少，两种观点：

变少：”为什么还需要 PM？工程师自己发布就行了。”

变多：工程师推进得太快，每天都有新功能上线，PM 和设计师跟不上所有事情了，所以需要更多 PM。

你怎么看？

6.1 角色在融合，最高效的方式是招有产品品味的工程师，放手让他们去干

我觉得所有角色都在融合：PM 在做一部分工程工作，工程师在做 PM 的工作，设计师既在做 PM 的事有时候也在写代码。

有两条路可选：

多招 有产品品味的工程师；

我们团队选择是这种方式，好处是可以把产品发布的 overhead 降到最低。

我们团队里有 很多工程师完全可以端到端地搞定需求：在 Twitter 上看到用户反馈，当周末就把一个产品发布出去， 几乎不需要产品方面的介入。

我认为这其实是 最高效的产品发布方式。
工程招聘保持不变，但多招 PM 来指导他们的一部分工作。

6.2 产品品味仍然是一项非常稀缺的技能

我觉得工程师和 PM 其实是重叠的，多招哪一边都会有用。

但 产品品味仍然是一项非常稀缺的技能：只要我们认为一个人在这方面有强有力的证明，我们基本上都会招进来。

6.3 我们的几乎所有 PM 以前是都是研发，设计师也是

主持人：你的背景是工程师对吧？

我以前做了多年工程师。之后短暂做过一段 VC，然后加入了 Anthropic。

其实 我们团队几乎所有 PM 要么以前是工程师，即使以前不是工程师，现在也在 claude code 里实际写代码。我觉得这是一个 能和团队建立信任的重要因素，也让我们能快得多。

另外， 我们的设计师之前也都是前端工程师。

6.4 工程背景转产品是个自然&有价值的事情吗？再论产品品味

主持人：很多人最关心的问题是——如果你的背景是工程、产品或设计，这三种核心技能里哪一种最有价值？在 Anthropic 和 claude code，工程显然非常有价值。我很好奇在其他公司是不是也一样。

我仍然觉得 归根到底还是产品品味。

产品品味可以来自任何背景

随着写代码的成本大幅下降， 真正变得更有价值的是知道"写什么" —— 这个功能的合理 UX 是什么？用户体验它时最愉悦的方式是什么？
我们每天收到 上万个 GitHub issue，什么都有，需要很强的心思和品味，才能判断出哪些值得做、用什么方式做。

这项技能可以来自任何背景，但它是最重要的。

工程背景的一个好处：对”一件事应该有多难”更有直觉

我觉得 工程背景在接下来几个月里特别优势的一点是：对"一件事应该有多难"更有直觉。

这对决定做什么、不做什么很关键。如果一件事很容易做，那不用争论，直接花一小时把它做了；但如果一件事很难做，你事先就评估 这对团队来说代价有多大。

6.5 第一性原理：判断技术格局正在如何变化、团队真正需要你做什么

我前面说工程背景的人”接下来几个月”特别有优势，但不是说一直有。随着时间推移，一定会发生大的变化。

主持人：你是说 mythos 一出来就会改变一切、我们就不再需要懂工程了？

不是，我只是说 每隔几个月，coding 能力似乎都会有一次大的跃升，然后各角色的价值就会经历一次重新洗牌。

我觉得最重要的是 具备第一性原理思维：能判断技术格局正在如何变化、团队真正需要你做什么、然后进去把那个洞补上。

工作正变得越来越 无定形（amorphous），
一个优秀的 PM 要能 看出所有的 gap、判断哪些最重要，然后想清楚”我怎么学到那项技能”或者”我现有的哪些技能可以用到这个挑战上”。

所以我觉得当下的环境看重的是那些 能戴多顶帽子、能随时切换、并且对自己做什么工作没有执念（low ego）的人——只要能帮团队更快。

达到 AGI 之前，人脑还有哪些发挥空间？

主持人：在我们到达 super intelligence 之前，人脑会在哪些地方继续发挥作用？我听你说的，本质上是 选择做什么、判断市场走向、决定优先级；然后是判断你做出来的东西是不是好的、对的，并且至少把它的一个早期版本推出去。这样理解对吗？

我觉得 人类仍然能提供模型所不具备的那种常识。

任何一次产品发布都有上千个大大小小的变化 —— 很多都很小，但总有大量的地方可能会出问题。模型对”干系人是谁、他们彼此之间什么关系、各自的偏好、什么场合沟通最合适”这类事情，并不总是能判断得很到位。

大模型的情商仍待提高

那些 更偏隐性的常识、EQ 层面的知识，人脑仍然非常有价值。当然我们希望模型在这方面也能变得更强，它们也会变得更强，但目前仍然有差距。

如何跟上 AI 的变化？—— “这已经是未来世界最正常的一天了”

主持人：作为身处暴风眼的人，你怎么应对这种持续不断的变化？也许风暴中心是平静的，但你怎么持续跟上在发生的事？怎么在这种疯狂中保持清醒？

我们团队都是愿意拥抱当前这种混乱 ( lean into the chaos) 的人。

我们尽量微笑着去面对每一个挑战，因为总有那么多事情在发生、那么多风险和棘手的情况——如果你对每件事都过度焦虑，一定会 burn out。
我们会找那种面对挑战会说”这会很难，但我很兴奋、我会尽最大努力， 我知道做不到完美，但我晚上睡得着，因为我已经尽力“的人。

主持人：我忘记是谁说过——也许是 Ben Mann—— "这已经是未来世界最正常的一天了"。

是的，只会越来越难。我感觉有很多周都是这样：周日晚上来了个 P0，周一又来一个 P00，周一下午来一个 P000——然后就会想：”哇，我居然为周日那个 P0 担心过，真可笑。”

不影响核心功能就先上线 —— 我们发布的一些产品并没有我期望的那么精致

必须承认：你能做的事情是有限的。

你需要睡好，才能在第二天做出好决定；你必须非常果断地排优先级，决定时间花在哪里——最重要的是把什么事做对，并且要能接受放手。

我们发布的一些产品 并没有我期望的那么精致。

回到第一性原理，我们的首要目标是赋能专业开发者。因此 一个产品即使不完美，但只要没阻塞核心 use case，那就可以接受——因为我们会收到反馈、在下个版本里修掉。
“上线一个带着 bug 的功能”以前会让我彻夜难眠，但现在我能接受，因为我知道 我们能拿到快速反馈并在下个版本里把 bug 修掉。

6.6 Anthropic 的人都非常 chill 和乐观

这是一个非常有意思的洞察，我们确实有这种平静和乐观，而不是”天啊一切都疯了、要崩溃了”。如果没有这种特质，你会很快 burn out。

我们也倾向于招 在行业里已经做了一段时间、经历过很多起伏的人—— 他们对 什么能给自己带来能量、如何长期维持自己的能量有很清晰的感知。这对我们帮助很大。

7 岗位融合之后，我们将失去什么？

主持人：现在各种角色正在模糊。在这样的世界里我们会失去什么？会失去职业阶梯、清晰的晋升通道吗？会失去设计一致性、代码质量吗？有哪些事情是你觉得”我们为了更大的目标正在牺牲掉”的？

7.1 我们正在牺牲产品一致性

我们在牺牲产品一致性。

写代码贵时：非常仔细地规划产品矩阵

历史上，写代码是很贵的，因此 PM 会 非常仔细地规划产品矩阵里的一切：

每个产品之间的关系
每一个的 use case 是什么
怎么集成——基本上每个 use case 对应一个产品。

写代码白菜价之后：同时尝试多个可能，让用户帮我们选择产品的走向

现在 AI 迭代得很快、我们要验证的想法也很多，有时候会出现 多个功能互相重叠。很多时候是因为我们自己都喜欢或拿不定主意，因此 希望外部用户来告诉我们哪一个更好。

7.2 大量堆功能的代价：对新用户不友好，老用户也可能跟不上

但以上方式 对新用户来说不够友好，因为我们给了他太多选择，他不知道要完成一个功能用哪种方式最好。

因此，我们需要做更多的教程，帮大家理解核心功能是什么、最佳实践是什么。这就是 大量堆功能的代价。用户也会觉得跟不上最新的东西。

传统 PM：季度或月度交付功能

传统 PM 模式下，大概每月或每季度发一个功能。

用户很容易理解：”每月看一次就行，学点新东西；就算半年不看也没事，不会觉得错过了什么。”

AI PM：天级别交付

在 agentic 工具这个生态里——不只是 claude code 和 co-work，而是整个生态—— 大家会觉得必须每天刷 Twitter 看最新的东西。

7.3 `/powerup` 功能（新手引导）：功能太多更新太快， "好的产品直觉到不需要教程"不再成立

我觉得我们应该做更多的事情，让大家不觉得自己站上了 一个越来越快的跑步机上。

我希望大家感受到的是 打开工具，工具自己会教你想知道的东西——让他们感到是被带着往前走的。

主持人：对，我看到你们前几天发布了一个很有意思的功能—— /powerup，基本上会带你走一遍使用 claude code 的 cool 玩法和最佳实践。这是不是就是你说的那个方向？

是的，就是这个方向。过去我们其实不愿意做像 PowerUp 这样的东西，因为我们觉得 好的产品应该直觉到不需要任何教程。

但随着时间推移，我们意识到 功能真的太多了，大家对一个内置的 onboarding 体验有非常强的需求，所以我们从”不做 onboarding flow”的原初原则上稍微偏了一点，加入了这个功能。因为确实有非常多的用户想知道：”这里有 100 个功能，其中我必须要用的 10 个是哪些？”于是我们就把它做出来了。

8 Anthropic 为什么能脱颖而出？

主持人：Anthropic 在 B2B 企业市场非常成功，

传统上 B2B 并不是”一堆东西往外发”——通常最多每季度一次 release，几乎是”每天一个新东西”的反面。

另一方面，Anthropic 这一路的运势简直像来自另一个世界。刚起步时远远落后。融资最少的公司之一、没有渠道、不是最先出手的那一个；OpenAI 遥遥领先，当时看起来 Anthropic 根本没可能在长期竞争中占到一席之地。而现在它做得非常好——以这种增速击败各路大公司的团队。

8.1 最重要的两件事情

Anthropic 能这么成功、能从后面追上来、做得这么好，有两件最重要的事情。

使命：带给全人类的是一个安全的 AGI，最高原则，招人硬门槛

第一件是 统一的使命（unifying mission）——它的重要性怎么强调都不为过。

我们招的是那些 最认同"把安全的 AGI 带给全人类"的人。

在决定整个产品矩阵该重点发布什么时，我们会非常频繁地参照这一条。
我们把这个使命放在 任何一条具体产品线之上，所以我们能做出 横跨整个组织的快速决策，并以一种统一的方式去执行。

在我们这个规模的公司里，据我所知这是独一无二的。

我们的头号使命是 safety alignment，是让 AI 对世界有益。有这样一条清晰的使命，决策就会容易很多。例如，如果有两个优先级在竞争， 我们会回到"哪一个对 Anthropic 的使命更重要"。

这让”二选一”变得容易得多，大家都会选择同一边。有时候这意味着：”我们本来想发 claude code 的某个东西，但另一件事更重要——那这个就降优先级、晚点再做。”

专注：做好最核心的业务场景，不发散

主持人：有意思。这正好解释了和 OpenAI 的不同。你说的本质上是：”我们不做社交网络、不做信息流，因为它们不符合这个使命。” 正是这一点让 Anthropic 保持了专注，而专注似乎是成功的核心要素之一。

当我谈使命的时候，我想的是把 Anthropic 的目标放在任何个人、任何一条产品线之上。

所以对我来说，我们擅长的第二件事是专注。

使命和专注的区别

在我的理解里使命和专注稍有不同—— 使命意味着团队愿意做出那种伤害自己目标和 KR，去服务 Anthropic 的目标和 KR，并且大家非常乐意做这种取舍。

极端例子：如果 claude code 失败了但 Anthropic 成功了，我们都会非常高兴

举一个极端例子： 如果 claude code 失败了但 Anthropic 成功了，我会非常开心——整个团队也都非常愿意按这个思路做决策。

8.2 禁用 OpenClaw 的决定，是否与此冲突？

主持人：不知道你能不能深入聊这件事——你觉得禁用 OpenClaw 的决定是不是出于这种考虑?

这件事没有在推进 Anthropic 的使命，所以我们停止了对 OpenClaw 的支持，因为它并没有按我们希望的方式在工作。

我觉得对 Anthropic 而言， 最重要的事情之一是增加我们能触达的用户数量。其中一条路径就是通过 Claude 订阅和第一方产品。我们非常希望在这个方向上加倍投入，但这有时 会以牺牲第三方产品为代价。

9 你分别在什么场景下使用 claude code, desktop, co-work?

9.1 Claude Code

我一般是在 要启动一个一次性的 coding 任务、并且想用上所有最新功能时，用 claude code。它是一个命令行工具，CLI 是我们最初的产品形态，也是新功能通常最先落地的地方，所以它是所有工具里最强的。我在同时启动一个、或者少数几个任务时，更倾向用它。

9.2 Claude Desktop：前端开发，preview

desktop 最亮眼的场景是 前端相关的工作。

我特别喜欢用我们的 preview 功能——如果我在写一个 web app，我经常用 claude code on desktop，把 preview pane 固定在右边，这样一边和 Claude 聊，一边 实时看到自己在做的那个 web app。它也非常适合那些希望界面更图形化一些的人。

对非技术用户来说，terminal 相当陌生——会冒出一堆吓人的弹窗，并且不能像其他产品那样自由点击。所以有很多人在 terminal 里就是不自在。如果你是这种人，我强烈推荐 claude code on desktop。

它是一个 一站式的 control plane，你能看到所有任务。 web 和 mobile 版本的价值则是 在路上也能启动任务。CLI 和 desktop 都要求你在本地笔记本前。

9.3 co-work：管理邮箱、做 PPT 等

处理 Slack 到 zero、邮箱到 zero；做 slide；写文档等。

这些任务的输出都是非代码的， co-work 最适合这类场景。

我大脑里的产品划分是这样的

输出是代码，用 claude code 或 desktop 或 claude code on mobile；
输出是非代码的东西，用 co-work。

如果你刚开始用 co-work，第一件要做的事是 把你所有的数据源都连上，这会 大幅提升结果的质量。

co-work 只有拿到足够的 context，才能帮你产出好的东西。
对我来说就是把它连上我的 Google Calendar、Slack、Gmail、Google Drive。

co-work 最佳实践举例

主持人：能不能分享几个你作为 PM 的 use case？在用 co-work 有哪些特别有意思、甚至出乎意料的用法？

我用它做的事情——比如昨晚我在准备一个叫 “Code with Claude” 的大会，我要做几个 talk，其中一个是讲 claude code 从 assistant 到完整 agent 的演进。我想在 talk 里展示所有促成这一演进的产品，同时找出内部那些可以当作 demo 的成功案例。我把 Google Drive 和 Slack 连上了，我们的 PMM Alex 草拟了一份他觉得应该覆盖的要点。我把这些全部丢给 co-work，告诉它我想讲的叙事。 然后它真的就独立工作了一个小时。

它 扫了 Twitter 看我们发过什么、翻了 evergreen launch room 和 claude code announce 频道（团队发 demo 的地方），然后把所有信息综合起来，做成一份 20 页的 slide。今早我醒来读了一遍，相当不错。

一些细节要调，我给了它一轮反馈——我喜欢 slide 上的字极少，它做得有点啰嗦。 而且因为 co-work 能访问我们整套 design system，它做出来的东西看起来就像 Anthropic 设计师亲手做的。

视觉上一看就觉得”哇，这个非常精致”。这类事情现在快得多——这份 slide 如果我自己做要好几个小时，现在它给我出一个相当好的 draft， 我可以把时间花在确保里面的 demo 足够惊艳。

主持人：你给它生成这份 slide 时大致用的 prompt 是什么？

大致内容：

    帮我做一份 Code with Cloud 大会的 slide；这是我们 PMM 建议覆盖的内容；这是我自己写的一版 draft 我不喜欢；这是我手动做的一版我也不喜欢

请先产出一份带细节的候选大纲；并且确保它不要和 keynote talk 重叠太多，因为 keynote 更重要

然后 Claude 读了我给它的一堆链接，产出了一份候选大纲。我把它的方案和所有它生成的备选想法过了一遍， 然后做出"最终 deck 里要放什么"的决定。

我觉得这就是一个 今天 PM 角色的缩影：

Claude 是一个很棒的 brainstorming partner，能极快地综合海量信息、把所有可能性摆给你；
但”最终应该放什么到产品里”这个决定，仍然是 PM 的角色。

我最终的决定是：这个 talk 要覆盖这样一条演进—— 从让本地任务成功，到让每个 PR 都绿，再到帮工程师 land 更多 PR；并且为每一步挑出最有说服力的 demo。这个大纲定了之后，co-work 就自己跑了几个小时，把整份 slide 做出来。

9.4 与视觉设计的集成

主持人：design system 这部分你是怎么做的？它是怎么知道 Anthropic 的 design system 的？

我是这样做的——我们其实已经有 一份用于所有对外场合的标准化 deck。我把它给 Claude 访问权，它就能看到我们用什么颜色、什么字体、有哪些可选的 slide 格式。这份 deck 里大概有 20 种示例 slide。

你也可以连 Figma MCP——如果你的 slide 格式存在那里，它可以从那边拉进来。

10 在 Anthropic，token 消耗大户（团队）都是干啥的

主持人：在 Anthropic，除了工程团队之外 —— 我猜工程是最大的 token 消耗方 —— 哪个团队第二多？这会很有意思。

10.1 Applied AI 团队

Applied AI 团队，他们在 co-work 和 claude code 上消耗都非常大。

Applied AI 团队在拓展 claude code 和 co-work 边界上做的很不错。

他们很多人会花时间和客户一起工作，帮他们落地我们的 API。
有时候会代客户做 prototype——而 claude code 让这件事比以前快得多。
他们还同时要管理大量客户沟通、客户 inbound、以及历史的通话记录和 context。

主持人：applied AI 是不是类似 “forward-deployed engineering” 的角色？它的工作大概怎么描述？

对，它的职责是 帮客户在公司内部落地最新的 API 和模型能力——既用来驱动客户自己的产品，也用来加速客户的内部工作。

主持人：懂了——所以它像是一种 customer success / GTM 的 forward-deployed engineering 的角色？

完全正确。它是一个非常技术化的 GTM 人员。

举例

我们也看到他们在把 co-work 的边界往外推。比如——他们很多人同时对接多个客户，忙的时候一天可能有 5 到 10 场客户 engagement。他们经常用 co-work 做的一件事情是： 前一晚让 co-work 做一份总结——明天我有哪些客户会议？这个客户此前问过什么？他们最关心什么？上次会议的 action item 是什么？co-work 会把这些整合成一份 "进会议前该知道什么" 的简报（dossier）。

co-work 还能去找答案——如果客户问”feature X 什么时候发布”，co-work 可以在 Slack 里帮这位同事查到最新 ETA，写到笔记里；这样客户 call 的时候，这位同事手里就是绝对最新的信息。这些都是大家自己搭的工作流，然后分享给团队其他人。

10.2 token 费用超过自己的工资

主持人：最近有个话题经常被提起——有些人用 token 花费已经超过了他们自己的工资。Anthropic 内部有没有一些数据，比如工程师或 PM 每月、每天花多少 token？

我们非常清楚地看到 随着模型变强，大家委派给它的任务越来越多，在 claude code、co-work 这类工具里花的小时数也越来越多。

每当有一次模型跃升或重大产品改进，我们就能看到 每个工程师、或者每个 knowledge worker 的 token 成本都在上升。现在整体还远低于一个普通工程师的平均薪资，但这个占比在持续上升。

10.3 你们的 token 量有限制吗？

我们的 token 上限非常高，但也有限制，有些人确实会撞到上限。

11 作为 Anthropic PM，你的技能栈是哪些？

主持人：作为 Anthropic 的 PM，你的工具栈大概是什么样？除此 claude 系列你还在用什么？

我重度依赖 claude code 和 co-work。Anthropic 很大程度上跑在 Slack 上，我觉得它是我们公司的 "核心操作系统"。

11.1 大量使用 co-work，对它哪里不够好有非常强的直觉

日常工作里，我大概有 30% 的时间花在”把 co-work 的能力边界往外推”上，这样我 对"我们哪里还不够好"会有非常强的直觉。

11.2 大量和 claude 对话，理解它为什么会那些犯错误

我花很多时间和模型对话，去理解它为什么会犯它所犯的那些错误。

11.3 Claude code 极大地降低了”做一个自定义 app”的门槛

我们其实自己做了很多内部工具——我觉得 claude code 为整个公司解锁的一件事情，是 它极大地降低了"做一个自定义 app"的门槛。

我们看到的结果是： 个性化的工作软件在激增——大家在为自己的定制 use case 做工具，而不是忍着用那些并不完全贴合需求的现成工具。

主持人：有哪些具体例子？你自己或别人做过哪些特别受欢迎、特别有用的东西？

claude code 销售团队里有一位同事，他意识到自己在 反反复复做结构一样的 deck。所以他做了一个 web app：里面放着那些效果很好的 deck 模板。然后他的 web app 支持把客户的 context 输入进去，例如从 Salesforce 或其他笔记软件里拉，就能针对具体客户定制这份 deck。

正常情况下这是一个要花 20~30 分钟的手工活。而 有了这个工具，几秒钟就能拿到一份量身定制的 deck。

11.4 不会重写一个 Slack，它有自己的核心竞争力

主持人：大家聊 Salesforce 时会说：”我们不再需要 SaaS 软件了，我们自己做。” 但 Slack 是那种 没人想和它竞争、没人想去做一个"更好版本"的耐用工具。

我觉得 Slack 是非常重要的一套通信基础设施 —— 在 "让每个人能拿到实时通知"这个核心任务上它做得极好。

它还把 可定制、可 hack 做得特别容易。我们很爱写 Slack bot——这种可 hack 性意味着我们能按自己想要的方式和 Slack 集成。非常感谢 Slack 在这方面的工作。

12 你觉得 PM 应该关注哪些技能？

主持人：回到 PM 这个角色。 你觉得 PM 现在最需要发展的那些新兴技能是什么？AI 公司在招 PM 时最看重什么？

12.1 最难的技能：能定义未来一个月，你的产品应该长什么样

我觉得最难的技能，是能定义"一个月之后你的产品应该长什么样"。

在这个时间尺度上，模型能力会变成什么样、用户行为会怎么变，都非常模糊。

很难，但最好的 PM 能看出一些规律

但 最好的 PM 能看出一些规律 —— 来自观察 "用户如何重度使用现有产品的边界"。他们能感受到方向、设定路径、稳步执行；并且在模型能力好于或差于预期时， 及时调整路径。

12.2 给一个 super AGI 级别的模型做产品其实很容易 —— 难的是给当下这个模型做产品

我觉得 the right amount of AGI pilled 是一件很难的事情。每个人都能看到这样一个未来：模型极度聪明、几乎什么都能做——在那种未来里，你其实根本不需要复杂的产品，一个文本框就够了，把你想要的告诉模型。

Being “AGI-pilled” refers to a mindset centered on the belief that Artificial General Intelligence (AGI) is not just possible but inevitable. It often involves prioritizing or redesigning one’s work, strategy, or worldview to account for a future where AI possesses human-level or superhuman cognitive abilities.

它聪明到能自己加任何需要的 tool 和 integration 来把事情做成；
它知道自己什么时候不确定，会主动问澄清性问题。

给一个 super AGI 级别的强模型做产品其实很容易——难的是给当下这个模型做产品：如何激发它的最大能力？如何帮用户走上 golden path？如何引导用户去用模型的强项、同时弥补它的弱点？ 这项技能相当稀缺。

12.3 你如何打造这项技能？—— 花大量时间和模型对话、使用模型

主持人：那这项技能要怎么练？是靠大量使用每个模型、理解它们的边界吗？就像你说的”taste”——对模型能做什么、强在哪、弱在哪、哪里变了，有一种直觉？

我觉得是 花大量时间和模型对话、使用模型。

一、让模型反思它自己的行为，找到为什么不 work 的原因并解决

我特别喜欢做的一件事，是 让模型对自己的行为做内省（introspect）。比如我有时候会注意到模型做出一些出乎意料的行为——像是改完前端、跑了测试，但并没有真去用那个 UI。这时候让模型反思”为什么你这么做”是非常有用的。

有时它会说：”system prompt 里有一段让我困惑”、”我没意识到前端验证也是这个任务的一部分”、”我把验证 delegate 给了一个 sub agent，但它没做、我也没 check”。 很多时候，只要你对"模型为什么做了那个决定"保持强烈的好奇，就能看到什么把它带偏了——然后你就可以改 harness 来把这个 gap 补上。

二、找到你最信任的用户群体，收集他们的真实反馈

另一件有帮助的事情是 找到"你最信任"的那群用户——他们能给你关于模型的准确反馈。

通常会有那么一小撮人，他们在说清楚 某个模型或某个 model-harness 组合为什么好这件事上比其他人强得多。给你反馈的人会很多，但并 不是每个人的反馈同样有质量。

找到那么五个你信任的人，对拿到快速、高质量反馈非常重要。

三、构建评估（evals），很多 PM 不愿意做

第三件有用但并不是每个人都喜欢做的事情是 构建 evals。

不需要上百个 evals —— 做 10 个足够好的 evals 就足以帮团队量化"目标是什么、目前进展如何、缺什么"。

我觉得 eval 是一件 被低估的事情，应该有更多 PM 和工程师投入到里面。

主持人：现在有一个趋势是—— "产品管理的未来就是写 evals"——因为 evals 本质上回答的正是”成功是什么样子”。

把它具体地定义出来，然后我们能知道它工作地对不对，好不好。

主持人：你自己花在写 evals 上的时间大概占多少？

evals 的重要性要看你在做什么功能、要解决什么问题。我们团队有不少人花大量时间做 evals。我们有一个小团队来负责更精准地理解 claude code 的行为、找出最大的改进空间、并把这些东西具体地量化出来。

我个人会在 一个功能我觉得需要更明确的产品定义时去做 evals。

PM 的 evals 输出

我作为 PM 的输出往往是这样： "这是我做的五个 evals；这是运行方式；这些通过、这些没通过；这是我用来提升通过率的 prompt"。

具体到每个功能差异很大——不是每个功能都需要，但像 memory 这样的功能从中获益很多。

evals 做的特别好的人/团队举例

主持人：有谁是你想特别表扬的、在这件事上做得特别好的人吗？

有两个人我觉得非常厉害。一个是 Amanda，她负责塑造 Claude 的 character——这是一个极难的角色，因为任务本身就非常模糊。

做 coding 更容易——因为很好验证。而塑造 character 需要你对 "Claude 应该是谁"有极强的信念。我觉得她不仅具备极强的塑造能力，还能把目标、character、什么算成功、什么不算成功清晰地表达出来。

另一群我非常信任的人，是整个 claude code 团队。我们经常一起吃团队午餐，每次有新模型要测试的时候， 拿反馈最快的方式之一就是在午餐上问每一个人："你对这个模型的 vibe 怎么样？"。我们常会得到这样的反馈：

“这个模型没把自己的 thinking 完全讲清楚，有点太突兀了”
“这个模型特别喜欢写大量 memory，但我们不确定这些 memory 的质量是否高”
“这个模型很喜欢自测自己的改动，这很棒”
“这个模型自测得不够”

这些反馈会 告诉我们应该去看哪些数据来验证，其实是不是有大机会或大问题。

我们手上有海量数据，但提取 insight 非常难；
这群人的反馈帮我们决定”要验证哪些假设”，然后我们才能从数据里抽取东西去验证。

13 Claude 的性格（character）

13.1 Personality 是 Claude 在很多任务上表现好的根本原因

主持人：很多人一开始没意识到 character 有多重要，直到后来——比如 OpenClaw 火了之后，大家对比之下才发现， Claude 的 personality 特别好、特别有趣、和其他产品很不一样。Ben Mann 的说法是，这种 personality 正是 Claude 在很多任务上表现好的根本原因。它看起来像一件"无足轻重的附加项"，但其实不是。

主持人：这种”会风趣、会用有意思的方式说话”，看起来只是表面，但其实对 Claude 的成功至关重要。为什么 character 和 personality 这么关键，你有什么见解？

当你回顾你合作过的人，总有一些人你会觉得”我真的喜欢他们身上的那种能量、那种 vibe”。大家谈到 Claude 和 claude code 时，提得最多的正是这一点—— 他们很喜欢 Claude 轻松、有趣，同时执行能力又极强。

13.2 Claude 的特质（灵魂）

人们特别喜欢 Claude 的 low ego。

如果你告诉它”你这里做错了”，它会真诚地道歉：”啊糟了，谢谢你告诉我——我来修，咱们一起。” 它也非常正向。
如果你觉得”这任务难到无从下手”，Claude 会说：”没事的——我觉得我们应该这样一步步来——要不要我先开始？”

一个好的合作者的核心特质，恰恰是这种正向、bias towards action、愿意给你真诚反馈而不是对你说的每句话都附和。

我们试着把这些特质注入 Claude，因为我们认为这让和它一起工作变得更令人愉悦。

14 Anthropic 新模型发布前后的工作

主持人：你前面说每次新模型发布，你经常要回头重新审视你们之前做过的东西。这很有意思，也可能有点崩溃——”该死，我们都发了这东西了，现在还得重新想一遍”。每次新模型出来之后，你们要重做几个月前上线的产品的频率大概是什么样？

14.1 删掉不再需要的功能（模型的拐杖）

新模型出来以后，我们做的很多改动其实是 删掉不再需要的功能。很多功能是我们作为 模型的拐杖（crutch）加上去的——因为它自己不会自发地这么做。

一个经典的例子是 to-do list。claude code 刚上线时，用户会让它做大规模 refactor，claude code 会说： “好，我要改这 20 个调用的地方”，然后它改了 5 个就停了。我们就想：”怎么强制它把这 20 个全改完？”

我们团队想：想一下人类会怎么做 —— 人会先列一个需要改的清单。就像在 VS Code 里查所有调用的地方，左边会出一个列表，你可以逐个过一遍、全部替换。
怎么给 Claude 一个这样的工具？” 于是他加了一个 to-do list，结果发现有了 to-do list 之后，Claude 真的能把这 20 个 call site 全改完。

但到了 Opus 4 以及之后的模型，我们发现 不再需要强迫它用 to-do list，它会自然地自己用。对更早的模型，我们得反复提醒它：”to-do list 上的事都做完了吗？没做完之前你不能停”。

现在，to-do list 对用户仍然是一个”有了更好”的东西，因为你可以更清楚地看到 Claude 在做什么。但说实话， 它在产品里已经被大大弱化了——模型可能用，也可能不用，它已经不需要靠这个来完成彻底的修改了。

14.2 `"model will eat your harness for breakfast"`

主持人：我忘了谁说过 "the model will eat your harness for breakfast"。我听你讲的本质上是——随着时间推移，你们在不断移除那些曾经加在模型之上的东西（为了”模型没按预期的方式工作”而加的 harness 工程）。随着模型变聪明，让它按预期工作会变得越来越简单。

是的。 每次模型变强，我们都能移除很多 prompting 干预。我们每次发布新模型时都会做这件事—— 把整份 system prompt 从头到尾读一遍，对每一段去反思：模型真的还需要这条提醒吗？不需要就删掉。

14.3 新模型解锁新能力

但新模型更令人兴奋的，是它们能 解锁全新的功能。有很多功能我们用更早的模型试过，但准确率还不够到可以发布。一个例子是 code review ——

我们试过好几次构建 code review 产品，之前也发过更简单的版本，比如 /code-review 命令。
但直到最近这几代模型，我们才觉得：这个 code review 好到整个工程团队愿意在 merge PR 之前依赖它通过。

我们一直希望 Claude 能成为一个可靠的 code reviewer，能让我们有信心相信它捕捉到了绝大多数 bug。直到 Opus 4.5、4.6 和 Sonnet 4.6 这一代模型，我们才能做到 同时运行多个 code review agent，遍历整个 codebase，综合出一组"merge 前工程师必须处理的真实问题"。

这就是最新模型解锁的新能力。

14.4 构建六个月之后的东西

主持人：另一个趋势是：去构建 未来六个月内可能会行得通的东西。先站到 刚好勉强能跑的那条线，之后模型会追上来，那它就会变成一个惊艳的产品，你也会领先所有人。

构建那些”暂时还行不通”的产品非常重要

完全正确。 去构建那些"暂时还行不通"的产品非常重要—— 你能看清楚这个产品要 work 的话还缺什么。新模型出来时，你只要把它换进已经做好的 prototype，看看这个新模型能不能把那个 gap 补上。

Claude 有什么可以分享的中长期愿景

主持人：关于 claude 和 co-work 的长期愿景，感觉你们在不断往上加令人惊艳的功能 ——从手机下发任务和控制，到各种 mobile app 的东西。有没有一个框架可以帮我们理解这一切背后的长期愿景？

我们用 building blocks 来思考这件事。对 claude code 和 co-work 来说，

最核心的 building block 是 让单个任务成功 —— 你想产出某个输出、给它一段清晰的 prompt，它能否稳定地产出可以接受的、你能直接 merge 或直接分享给同事/外部受众的输出？
模型变聪明后，任务成功率大幅提高；然后我们看到大家开始 并行做多个任务。 2025 年末 multi-coding 是一个很大的趋势，之后只增不减。我们看到的是：单任务 work 了，现在你可以同时跑 6 个任务。
随着模型进一步变聪明，我们的外推是： 下一步用户可能会同时跑 50 个甚至上百个 Claude。那么支撑它需要什么样的基础设施？到了那一步，你大概 不会再把所有东西都跑在本地机器上—— 内存根本不够。

所以我们在思考： 怎么让你更轻松地管理这一切？ 这些任务大概率会远程运行。

我们怎么设计界面，让你作为人类能知道”哪些任务需要我去看一眼”？
怎么确保 agent 完整验证了自己的工作，这样当你看到一个任务显示”完成”时，你能非常快地验证、并完全信任它确实按你的 spec 做完了？
怎么确保 这个流程是自我改进的 —— 当你看到一个任务做得不合心意，你给一个反馈，模型就能把这个反馈纳入之后每一次运行，再也不犯同样的错？

这就是我们正在带着用户往前走的那条路径。

15 对大家的建议，怎么挺过这次 AI 革命

主持人：你会给产品经理、创始人、跨职能人士等什么建议？ 不只是"挺过"向 AI 驱动世界的这次转变，而是在这个未来里真正成功？他们需要听到什么？需要做什么？

15.1 有重复多次的工作，应该想到用 AI 工具解决

AI 给每个人带来的杠杆比以前大得多。所以我会这样 push 你： 每当意识到自己在重复做某件手动的工作，就想一想如何用 claude code、co-work 或其他 AI 工具把它自动化。大部分人的工作里都有一部分是”我真的很喜欢的创造性的那部分”，也有”我真的很讨厌的琐碎的那部分”。

AI 的美妙之处在于它可以帮你做那些琐碎的部分 —— 它可以从你每一次手工完成这个任务中 学习、泛化，之后自动地跑。这样你就能专注于创造性的部分，能做的事情比从前多得多。

15.2 找出你工作里可以交给 Claude 的重复部分，把自动化成功率打磨到很高

所以我对大家最直接的建议是： 找出你工作里可以交给 Claude 的重复部分，把自动化成功率打磨到很高—— 然后去想，你还可以为你的团队、产品、公司多做些什么？比如那些一直没人有精力去接的事、或者你一直觉得公司应该做但自己没有带宽去做的 pet project。

如果 AI 能帮你搞定这些，你就能 比过去多出 20% 时间。所以我的建议是：拥抱这些工具，把你动力不足的工作交出去，搞清楚 AI 能如何加速，你能做的事情会越来越多。

15.3 从哪里开始？

主持人：这些工具的潜力巨大，但对很多人来说最难的部分恰恰是”我到底该做什么”。核心建议就是”先为自己解决一个问题”。

以让 Claude 帮你整理和分析邮件为例—— 你需要知道怎么定义一个 skill、怎么使用它并给它反馈、怎么告诉 co-work 基于你的反馈来更新这个 skill、以及怎么去读 skill 来确认反馈是否被按你想要的方式吸收了。

让这个流程变得流畅、不让人感到痛苦，也是我们（作为产品团队）的工作。

我会强烈推大家去 构建那些你每天真的在用的 app——因为只有通过真实使用，你才能拿到真正的价值。如果你做的 prototype 并没有让你完成更多事情，那 AI 并没有给你真正加分。

只有真正做出来，你才能从里面学到东西。

15.4 避免两个方向的极端

我也注意到有很多人花大量时间折腾自己的 workflow。其实 有两个极端。

是从不做任何定制、从不搭建自动化的人；
对”定制自己工具”近乎执念的人 —— 他们在工具上加一堆 skill、MCP，以及各种 workflow 改进。我觉得这有时甚至会让你偏离核心目标——比如发布一个产品、做完一个功能。

定制本身是很有乐趣的，我们也确实希望我们的产品非常可 hack，让你能把它打磨到非常适合自己。 但"有用"是有极限的。我觉得有一类人花在定制上的时间太多，以至于他们睡眠不足、偏离了自己最初想做的核心任务。

主持人：Karpathy 昨天发了一条推文，很有意思。他谈到了一种分化：一部分人当初试过 ChatGPT / Claude——觉得”就那样”，甚至”太差了”——然后他们就放弃了 AI 能为自己做什么的想法，变得非常 cynical，”这没什么大不了的”。另一部分人——主要是在用它来写代码的——看到的是它的全部威力、有多强。两边彼此不理解对方为什么这么看世界。所以你这里的建议很到位： 拿它去做真实的事情，看看它到底多有用。

是的。我觉得 真正的转变是——2024 年那一代产品是 chat-based 的，而 claude code 这一代产品是 action-based 的。

人们最大的 aha moment 是——当 Claude 真的可以代替你去做事情。意识到 agent 不只是”告诉你该做什么”，而是”真的能自己去做”——这是一种非常震撼的感觉。我觉得这是让大家眼界被打开的时刻。

16 QA

Q1：你最常推荐给别人的两到三本书是什么？

《How Asia Works》。讲的是经济发展，以及 哪些政策和政府造就了长期成功的经济体。
《The Technology Trap》。讲过去几次技术革命——工业革命、计算机革命——以及这些革命是如何影响劳动者的。
《Paper Menagerie》。稍微轻松一点，一本短篇小说集，讲成长、AI 以及自我发现。

Q2：最近看过、特别喜欢的电影或剧？

《Drive to Survive》，没有深意，但 看一群人对单一工程目标如此痴迷、这种纯粹的追求，本身就让人很满足。
《Free Solo》—— 讲 Alex Honnold 无保护徒手攀登 El Capitan。同样地，能完成这样一条极其艰难、致命的路线，并且在”一个失误就会摔死”的前提下保持那样的心智专注——是一种纯粹的成就。

我自己是个攀岩爱好者。第一次看《Free Solo》是在我自己攀岩之前——当时觉得很厉害，但没真正理解它有多厉害。它是少数几部 "你懂得越多，就越觉得疯狂"的电影。他在那面墙上做的那些动作——就算挪到室内岩馆、离地只有一英尺——我觉得这辈子我都做不出来。

Q3：最近让你爱不释手的产品？

除了 Claude 系产品之外， 最改变我生活的产品大概是 Waymo。我是 Waymo 的死忠，每天上下班各用一次。我喜欢它的两点：

如果 Waymo 在等我，我不会觉得不好意思。我不再有”它到了我必须立刻站在路边”的压力。
它让我工作更有效率。车里有人类司机时，我一般不会接工作电话——如果我全程在笔记本上干活，会觉得有点失礼。但在 Waymo 里，我可以直接进一个工作电话——不担心有人偷听、不担心失礼、不担心自己声音太大、不需要请人换一下音乐。 感觉这相当于每天给我多出了 30 分钟。

我原本设想 Waymo 要比 Uber 和 Lyft 便宜才能成功，但实际上 我愿意为它支付 2 倍的溢价。

第一次见到它时你会想”哇这太疯狂了”。然后你很快就习惯了——坐进去：”这太疯狂了”，然后就忘记了它的疯狂。

Q4：你在工作和生活里的人生座右铭是什么？

Just do things.

我觉得 第一性原理思维非常有价值—— 如果你清楚自己在优化什么、并且有一套坚定的第一性原理，你通常就能推导出正确的任务拆解，能把它清晰地讲给所有干系人——然后你就该直接去做。

"岗位"其实是假的 (jobs are fake)—— 如果你理解约束条件，你就能想清楚自己能做什么， 然后快速去做、从错误中学习、犯了错就道歉或者修。

我觉得跟别人讲这句话，其实是一种解放。

在很多公司里， 角色被严格定义——PM 做什么、设计师做什么、工程师做什么；甚至团队 scope 都是硬性划分的——”这块 codebase 我们改，这块我们不能碰”。 "just do things" 让人们感到自己被授权去做决定、被授权跨越团队边界，只为把事情做成。

主持人：这感觉是一项很重要的技能——大家叫它 agency、 bias towards action ——总之就是”不要等允许”。

对。我觉得这是我最推荐 人生某个阶段去创业公司工作的原因。在 Scale（AI）只有 20 个人的时候工作，那段经历改变了我的人生。当时完全没有流程，但要解决的问题又非常大。我很感激 Alex 和整个团队，他们让我和其他人 没有任何"销售该做什么、运营该做什么、工程师该做什么"的边界限制，就把事情想清楚、做出来。

你所有工具都在手边、摆在你面前的是一个宏大而棘手的问题，你可以做任何必要的事把它解掉。 你几乎需要这样一段经历，才能养成那种"自在地跨界行动"的习惯——因为很多人从小在学校、大学里，接受的都是”按我说的做、就能拿高分”的训练。

Q5：Claude 的 thinking words

主持人：thinking words 都在那次源码泄露里曝光了。你有最喜欢的 thinking word 吗？

我很喜欢 manifesting——我最喜欢的贴纸上也是这个词。

Q6：如果 AGI 在我们有生之年到来、你可能不必再工作，你会做什么？你会怎么打发时间？

我觉得 AGI 扩散到整个社会会花很长时间，所以眼下真正要做的是 帮助整个世界跟上。

如果真到了那一天，我的”不正经”回答大概是——我会去大量攀岩。我大概会搬去 Fontainebleau，活在 10,000 块抱石之间，爬上一段时间。

还有很多书我想读——我的目标是 每周读一到两本，但现在大概是 0.5 本，backlog 非常大。我觉得从历史里能学的东西太多了，还有很多领域我都没有像自己希望的那样理解得够深。比如物理、机器人、任何硬件、航天——我都几乎一无所知。有太多有意思的话题。 即便知道 AI 已经懂得远多于我，我仍然兴奋于亲自去学这些东西。

Harness最佳实践： Learn Harness Engineering

Wed, 06 May 2026 16:06:23 CST

欢迎来到 Learn Harness Engineering

Learn Harness Engineering 是一门专注于 AI 编程智能体工程化落地的课程。本课程深度研究并总结了业内最前沿的 Harness Engineering（工具马具/脚手架工程）理论与实践，参考资料包括：

通过系统的环境设计、状态管理、验证与控制机制，本课程旨在帮助你让 Codex 和 Claude Code 等 AI Agent 能够真正可靠地完成真实工程任务。它通过明确的规则和边界约束你的 AI 编程助手，帮助你更可靠地构建功能、修复 Bug 并自动化开发任务。

开始学习

选择适合你的学习路径。本课程分为理论讲义、实战项目和开箱即用的资料库。

讲义

理解为什么强大的模型依然会失败，掌握构建有效 Harness 的理论基础。

项目

动手实践，从零开始搭建一个可靠的 Agent 工作环境。

资料库

开箱即用的模板（AGENTS.md、feature_list.json 等），可直接复制到你自己的代码仓库中。

Harness 的核心机制

Harness 的本质不是“让模型变聪明”，而是给模型建立一套闭环的 工作系统。你可以通过下面的简单图示理解它的核心运作流：

你将学到什么

你将在本课程中掌握以下核心概念：

用明确的规则和边界 约束 Agent 的行为。
在跨会话的长时任务中 保持上下文连续性。
防止 Agent 提前宣告任务完成。
让 Agent 学会通过完整的流水线测试来 验证自己的工作。
让 Agent 的运行过程 可观测、可调试。

下一步

了解核心概念后，可以通过以下内容深入学习：

L01. 模型能力强，不等于执行可靠：从理论开始。
P01. 提示词 vs 规则驱动：完成你的第一个对比实战任务。
中文模板：获取最小 Harness 模板包（AGENTS.md、feature_list.json 等），直接用于你的项目。

MS Edge 被发现会在内存中明文加载所有密码

Tue, 05 May 2026 22:12:37 CST

MS Edge 浏览器被发现启动时会在内存中明文加载其保存的所有密码。相比下 Chrome 只在需要时解密凭证，没有将所有密码保存在内存中。Edge 和 Chrome 都是基于开源的 Chromium。微软的做法让从内存中抓取重要数据变得更容易，也增加了共享环境下密码泄露的风险。安全研究人员将这一问题报告给了微软，收到的回应是该行为就是这么设计的。研究人员在 GitHub 上发布了概念演示工具 EdgeSavedPasswordsDumper。

本地科研助理

Sat, 02 May 2026 08:00:00 CST

去年年底我就开始关注龙虾类应用，自己也折腾了一段时间，热度过去基本就闲置了，更多时候还是用自然语言编程。后来仔细回忆了一下，我其实不排斥搞一个个人助理，真正没放开用是因为不了解其实现过程，担心出错跟信息泄露。那解决方案就很简单了，自己搭一个。

我的核心诉求很简单，就是要一个能在 Telegram 和 QQ 里对话的科研助理。这里面有几个要素需要保证：

要能调用本地qwen3.5的小模型做翻译、总结等重体力轻脑力的活，也要能调用云端的模型做复杂推理，需要一个模型路由设计，有自动切换，也要可以指定性切换
要能接入各种文献检索工具，至少要能接入 Zotero MCP、PubMed、Semantic Scholar 这几个，查文献方便
要能部署在本地，数据全在本地 markdown，没有数据库，随时能迁移
要自带mcp来做PDF信息提取、OCR提取、音频提取这些任务
有记忆文档且要有压缩功能，因为这个文档会跟着每次对话提交，不控制账单会爆
对话时可按需调用我的个人研究兴趣文档，方便给出相关推荐
要能接上即时聊天工具，telegram或QQ，随时说随时存，顺带自动打上 wikilink 关联到相关页面

可能你会说，这些龙虾都能做，模型路由配一个litellm就行了，文献检索接个插件就行了，很多coding plan里都送一个mcp服务器，部署上也不难啊。没错，我也认同如果你已经构建好了一个个人助理体系，那自己折腾纯属找事，我真正做的反而是对其能力做了收缩，你只能把这玩意当成科研助理用，mcp也只有你自己给配置的几个，但实话说我就需要这些功能，别的有需要时按需添加就是了。龙虾类应用确实会给人很大的想象空间，但真实的生活里需求是可预期的，所以我卸载了之前安装的龙虾类应用，目前自用自己设计的这个笔记系统。其实这算是个复杂度比较高的项目了，我是全程用opus构建，加入启动项后算是常驻进程了。部署上选择了 uv tool install scinotes，填一个 .env 文件，scinotes run，就跑起来了。VPS 上也能跑，配 OLLAMA_DISABLE=1 就切全云端。

代码在这里：https://github.com/yufree/scinotes

如果你对一个科研助理感兴趣，或者想自己搭一个，可以来看看这个项目，源码不长大概2000行，能读懂的，但因为是自用的，在功能添加上会按我需求走，你要是有更适合自己的需求，可以直接在这个项目基础上让大语言模型给你加功能。另外，这跟我之前的《现代科研指北》的skill并不冲突，那本书主要是提供一些科研观点，这个是给一个科研助理性质的笔记系统，算是知行合一。

这里重复强调一下，作为一个老登，我做这个还要接zotero的mcp其实是因为之前十几年的文献库存在zotero，所以我也允许添加修改zotero的文件库。你要是基本一张白纸，那用这个笔记系统其实也合适，它会去保存你扔过去的文献，也会自动做信息提取并按你要求选择是否保存到特定笔记，这样其实更简单直观。因为存在模型路由调度，我当前的建议是本地模型做可重复性的事，但最好有在sonnet这个档位云端模型做复杂文献调研与笔记管理，opus这个档位做科研助理性能过剩。

另外如果你不知道啥是markdown式的笔记系统或基本构架如何搭，可以去看看我那个基本不更新的自用wiki：

https://github.com/yufree/yufree.cn/wiki

IT社区推荐资讯 - ITIndex.net

AI 为什么会编程——原理、历史与未来

纯编程岗位已完，能做可验证奖励强化学习的都会完

为什么 AI 会先吃掉程序员，而不是产品经理

职业替代榜单太粗了

代码世界像一座提前铺好的练习场

产品经理不是安全，只是反馈更脏

AI 提效以后，工作未必变少

真正危险的是可验收执行层

人的价值会往反馈责任迁移

不要先问学 AI 编程还是学产品

参考与引用来源

手搓一个 Agent 驱动的项目 Wiki 生成方案

背景

问题

新方案

提炼 Skill

优缺点对比

deepwiki

Claude Code 方案

总结

马斯克花 100 亿想清楚一件事，不做 coding agent 就是等死

1.

2.

3.

4.

5.

6.

7.

你生活的地点与你衰老的速度相关

20条软件工程定律

Gall 定律

KISS 原则

Conway 定律

Hyrum 定律

CAP 定理

Zawinski 定律

Brooks 定律

Ringelmann 效应

Price 定律

Dunning-Kruger 效应

Hofstadter 定律

Parkinson 定律

Goodhart 定律

Gilb 定律

Knuth 的优化原则

Amdahl 定律

Murphy 定律

Postel 定律

Sturgeon 定律

Cunningham 定律

这些定律之间的关系

Eric Sc​​hmidt 在毕业典礼上谈 AI 收到了学生的嘘声

AI 实施工程师岗位出来了：Forward Deployed Engineer

Leapsome：2026年劳动力趋势报告

更多阅读：

中国拿下这届 AI 顶会半壁江山，清华一家单挑斯坦福加 MIT

一张学术热力图，看懂中美 AI 的真实格局

硅谷的科研 AGI，与中国实验室的极致务实

Vibe Coding治网瘾？孩子为何越写越上瘾？

以毒攻毒：用 Vibe Coding 治疗网瘾，AI 时代的新选择

为什么说 Vibe Coding 可能成为一种“成瘾迁移”

网瘾到底怎么治：粗暴戒断为什么常常无效

什么才算网瘾：不要把所有数字兴趣都病理化

游戏和短视频为什么会让人上瘾

从历史看“替代成瘾”：卷烟替代鸦片的类比

Vibe Coding 为什么会上瘾

为什么传统少儿编程很难坚持

AI 提供了安全的表达环境

Vibe Coding 的“动态难度”机制

Vibe Coding 的教育价值：从愿望走向现实

Vibe Coding 比游戏更没有边界

AI 为什么会让孩子更敢表达

Vibe Coding 不是万能药，但它能改变方向

家长应该怎么引导孩子接触 Vibe Coding

纳瓦尔是谁，为什么他的观点值得重视

纳瓦尔关于苹果、软件和未来投资的判断

苹果可能走到高峰

纯软件项目可能不再值得投资

Vibe Coding 能不能替代大型软件公司

Eric Schmidt 在毕业典礼上谈 AI 收到了学生的嘘声

6.1 角色在融合，最高效的方式是招有产品品味的工程师，放手让他们去干

6.4 工程背景转产品是个自然&有价值的事情吗？再论产品品味

7.3 `/powerup` 功能（新手引导）：功能太多更新太快， "好的产品直觉到不需要教程"不再成立