IT社区推荐资讯 - ITIndex.net

产品经理必装的10个Skills：从需求到落地的全链路AI武装

Thu, 11 Jun 2026 20:39:25 CST

作为一个每天和PRD、竞品分析、用户访谈打交道的产品经理，我一直在寻找能让工作更高效的方法。最近深入研究了 WorkBuddy 的 Skill 生态，发现里面藏着不少专为PM设计的”神器”。今天这篇文章，我把实战验证过的10个Skills整理出来，每个都配有真实使用场景和案例，看完你就知道该装哪些了。

一、Product Manager Toolkit —— PM的”瑞士军刀”

解决痛点：需求优先级混乱、客户访谈不会问、PRD写不全

这个Skill堪称产品经理的”百宝箱”，内置了RICE优先级排序、客户访谈分析、PRD模板、探索框架、上市策略等一整套方法论。安装量366次，18颗星，是PM类Skill里口碑最好的之一。

实战案例：

上周我负责的一个功能有5个候选需求，每个需求方都说自己的最急。我把5个需求的Reach（覆盖用户数）、Impact（影响程度）、Confidence（信心度）、Effort（开发成本）输入进去，RICE模型直接算出优先级排序。结果显示一个”看起来很重要”的需求实际得分排第4，而一个小功能改进排到了第2。

我把这个排序拿给开发负责人看，他当场同意按这个顺序排期——因为这不是”我觉得”，而是模型算出来的。

使用技巧：

客户访谈分析模块特别适合整理用户反馈录音/文字，自动提取痛点、爽点、痒点
PRD模板不是让你直接生成PRD，而是提供结构化框架，逼你把每个模块都想清楚
探索框架可以帮你在需求早期做快速验证，避免后期大返工

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=product-manager-toolkit"

二、Competitive Analysis —— 竞品分析的”专业外包”

解决痛点：竞品信息收集慢、分析维度单一、输出报告耗时

这个Skill专注于深度竞争分析，能帮你绘制竞争对手画像、发现市场空白、理解竞品策略、对比自身产品定位。它不是给你一个简单的”竞品对比表”，而是引导你做系统性的竞争情报分析。

实战案例：

我们团队准备进军一个新的垂直领域，我对这个领域的竞品了解仅限于用过的两三个产品。用Competitive Analysis Skill，我输入了领域关键词和已知竞品，它帮我梳理出了8个直接竞品和5个间接竞品的定位矩阵、核心功能差异、定价策略、用户评价情绪分析。

最让我意外的是，它发现了一个我完全没有注意到的市场空白——头部竞品都在做”大而全”，但中小客户的”轻量专用”需求没人满足。 这个洞察直接影响了我们的产品定位策略。

使用技巧：

触发关键词：”分析我的竞争对手””竞争格局””与竞争对手对标”
建议先手动列出已知竞品，再让Skill补充你可能遗漏的竞品
分析报告出来后，一定要人工验证其中的数据，尤其是用户评价部分

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=competitive-analysis"

三、User Research —— 用户研究的”方法论教练”

解决痛点：问卷设计不专业、访谈问不到点上、反馈数据不会分析

很多产品经理做用户研究就是”发个问卷、找个用户聊聊”，但问卷怎么设计才能避免引导性偏差？访谈脚本怎么写才能挖出深层需求？这个Skill提供了一整套用户研究的方法论支持。

实战案例：

我们有一个老功能使用率一直上不去，团队内部讨论了很久，有人说UI太丑，有人说入口太深，有人说用户根本不需要。我拿着这个模糊的问题去找User Research Skill，它帮我设计了一个”任务完成度+满意度+NPS”的三段式问卷，还生成了一份5人深度访谈的脚本。

访谈执行后发现， 真正的问题根本不是UI或入口——而是用户根本不知道这个功能能解决他们的问题。 这个功能的名字太技术化了，用户看到名字就划走了。我们改了个更直白的名字，使用率两周内提升了47%。

使用技巧：

问卷设计模块会帮你检查是否有双重提问、引导性选项等常见问题
访谈脚本会根据你的研究目标自动调整深度——探索性研究和验证性研究的脚本结构不同
反馈分析模块可以帮你做情感分析和主题聚类

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=user-research"

四、Data Analysis —— 数据驱动的”分析助手”

解决痛点：Excel操作繁琐、数据洞察挖掘慢、可视化门槛高

产品经理天天跟数据打交道——DAU、留存、转化、漏斗、AB测试……但这个Skill不是教你写SQL或Python，而是帮你把”分析思路”变成”可执行的分析流程”。

实战案例：

上个月我们上线了一个新功能，老板说”看看效果”。我把后台导出的CSV丢给Data Analysis Skill，它先帮我做了数据清洗（发现日期格式不统一、有几行缺失值），然后自动做了基础统计、趋势分析、异常检测。

最关键的是，它发现了一组我肉眼完全看不出的关联—— 在周三下午3-5点使用该功能的用户，次日留存率比其他时段高出23%。 深入分析后发现，这个时段正好是用户完成某项核心工作流后的”空闲窗口”。我们据此调整了功能推送策略，把原来全时段的推送改成了周三下午定向推送，整体留存提升了8%。

使用技巧：

上传数据前先让Skill帮你做”数据健康检查”，避免脏数据导致错误结论
不要只问”分析这个数据”，要问”我想验证XX假设，该用什么分析方法”
可视化结果出来后，让Skill帮你解读”这个数字对业务意味着什么”

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=data-analysis"

五、PRD Writer —— PRD撰写的”结构教练”

解决痛点：PRD结构混乱、遗漏关键模块、上下游理解不一致

这个Skill专门帮产品经理写结构化的PRD，但注意—— 它的价值不是”替你想”，而是”逼你想全”。它会引导你回答”为什么做””做什么””怎么做””怎么验证”四个核心问题，确保PRD的每个模块都有据可依。

实战案例：

我之前写PRD有个坏习惯——重”功能描述”轻”业务目标”。有一次我拿着一份”功能很全”的PRD去评审，开发问”这个按钮放在这里，预计能提升多少转化率？”我答不上来。

后来用PRD Writer Skill，它在开头就逼我填写：

业务目标：提升新用户首单转化率15%
成功指标：7日内新用户下单率
失败回退条件：如果上线两周内转化率提升<5%，则回滚

这些模块的存在，让PRD从”功能说明书”变成了”业务方案书”。 开发不再只是”实现功能”，而是”为实现业务目标负责”。

使用技巧：

不要把PRD Writer当成”代笔工具”，把它当成”检查清单”
每写完一个模块，用它的”一致性检查”功能，确保前后逻辑不自相矛盾
异常流程和边界条件是最容易遗漏的，PRD Writer会专门提示你补充

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=prd-writer"

六、Meeting Minutes —— 会议纪要的”自动秘书”

解决痛点：会后忘记决议、行动项跟踪混乱、信息同步不到位

产品经理的日程表上，会议占据了40%以上的时间。但很多时候，开完会大家各忙各的，会上说好的事情没人跟进。Meeting Minutes Skill能把杂乱的会议内容整理成结构化的纪要，包含决策点、行动项、负责人、Deadline。

实战案例：

我们有个跨部门项目，涉及产品、开发、设计、运营四个团队，每周一次同步会。以前会后我手动整理纪要，至少要花30分钟，还经常漏掉一些讨论细节。

用了Meeting Minutes Skill后，我把会议录音或速记文字丢进去，它自动输出：

会议基本信息（时间、参会人、议程）
达成的决策（带上下文，说明”为什么做这个决定”）
行动项（负责人+截止日期+优先级）
待确认事项（需要会前补充的信息）
下次会议议程建议

最让我惊喜的是”决策上下文”这个模块。 以前纪要只写”决定做A”，过两周有人问”为什么不做B？”大家都不记得了。现在纪要里自带决策依据，翻出来就能回答。

使用技巧：

会前把议程输入进去，会中按议程记录，会后让Skill帮你整理
行动项一定要包含”负责人+截止日期”，缺一个就不算完整的行动项
复杂会议建议开启”决策追踪”模式，自动关联之前的相关决策

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=meeting-minutes"

七、Mind Map —— 思维整理的”可视化工具”

解决痛点：思路混乱、逻辑关系理不清、方案对比不直观

产品经理经常需要梳理复杂的产品结构、用户流程、决策树。Mind Map Skill能把你的Markdown大纲或文字描述自动转换成结构化的思维导图，支持多种布局风格。

实战案例：

我们有一次要做一个”会员体系重构”的大项目，涉及等级体系、权益设计、积分系统、续费策略四个子模块，每个子模块下面又有十几条细则。我在文档里写了三页文字，自己看得都晕。

用Mind Map Skill，我把文字大纲丢进去，它生成了一个四分支的思维导图。一看图我就发现了问题—— 积分系统和权益设计有两处逻辑冲突，文字版看了三遍都没发现。

我把这张图贴到评审PPT里，老板和开发负责人一眼就看懂了整体架构，评审效率比之前提升了至少一倍。

使用技巧：

建议先写文字大纲再转导图，不要直接”画”导图，容易遗漏
对比不同方案时，用”水平布局”把两个方案并排展示
导图生成后，让Skill帮你检查”是否有遗漏的分支”或”是否有循环依赖”

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=mind-map-skill"

八、Product Framework —— 产品架构的”设计工具”

解决痛点：产品架构设计缺乏方法论、技术方案看不懂、与开发沟通有鸿沟

这个Skill专门帮产品经理设计并可视化产品框架，包括分层架构、价值链、能力图谱、竞争定位。它不是给技术架构师用的，而是给产品经理用来”把产品逻辑结构化”的。

实战案例：

我们要做一个B端SaaS产品，我对技术架构一窍不通，但产品架构必须我自己定。用Product Framework Skill，我输入了业务场景和用户旅程，它帮我生成了三层产品架构图：

表现层：用户直接看到的界面和交互
业务层：核心业务流程和规则引擎
数据层：数据模型和基础服务

每层下面又细分了能力模块。拿着这张图去和技术负责人沟通，他很快理解了产品方向，还根据技术可行性帮我调整了业务层的模块划分。 以前需要开三次会才能对齐的事情，一张图就解决了。

使用技巧：

产品架构不是技术架构，重点在”业务能力的分层”，不要陷入技术细节
能力图谱模块可以帮你识别”核心能力”和”可外包能力”，对MVP规划很有用
竞争定位模块适合做差异化分析，找到自己产品的独特价值点

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=product-framework"

九、Socratic Business Model Canvas —— 商业模式的”追问教练”

解决痛点：商业模式画布填不满、底层逻辑没想透、关键假设没验证

传统的商业模式画布就是一张表格，让你填空。但这个Skill用的是 苏格拉底式追问——它不给你标准答案，而是通过一系列层层深入的问题，逼你把每个模块的底层逻辑都想清楚。

实战案例：

我有一次要为一个内部创新项目写商业计划，用了传统的画布模板，20分钟就填完了，但自己看着都觉得”假大空”。

改用Socratic Business Model Canvas后，它开始问我：

“你说你的价值主张是’提升效率’，具体提升哪类用户的什么效率？”
“你的收入来源是订阅费，用户为什么要持续付费而不是用一次就走？”
“你说你的关键资源是技术团队，如果核心成员离职，这个资源还成立吗？”

这些问题让我意识到，我之前填的12个模块里，有4个是未经验证的假设，有2个根本站不住脚。 重新梳理后，商业模式变得扎实多了，投资人评审一次就过了。

使用技巧：

不要急着”填完”，每个问题都值得停下来认真想
建议团队一起做，不同角色对同一个问题的答案往往不一样
把最终的假设清单单独列出来，标注哪些已验证、哪些待验证

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=socratic-business-model-canvas"

十、PM Toolkit – Excalidraw —— 产品思维的”可视化翻译器”

解决痛点：想法在脑子里转、讲不清楚、团队理解不一致

这个Skill能把产品经理的”Why、What、How、用户旅程”等思维过程，自动转换成可编辑的Excalidraw图表。安装量356次，10颗星，是可视化类Skill里最受欢迎的产品PM工具。

实战案例：

有一次我要向大老板汇报一个新方向的探索结论。准备了一页文字说明，自己觉得逻辑很清晰，但老板看了说”太抽象，能不能画个图？”

我把文字说明丢给PM Toolkit – Excalidraw，它生成了四张图：

Why：用户痛点场景图
What：产品价值主张图
How：核心功能架构图
用户旅程：从发现到使用的全流程图

我把这四张图贴到汇报材料里，老板看了第一张图就说”这个问题我们确实要解”，看到第三张图就开始讨论资源投入了。 文字材料他压根没细看——图已经说明了一切。

使用技巧：

适合在方案讨论阶段快速出图，不需要设计师参与
用户旅程图建议按”阶段-触点-情绪-痛点-机会”五列来组织
生成的图可以直接导出为PNG或SVG，插入PPT或文档

安装命令：

  curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=thought-to-excalidraw"

安装建议：按工作阶段按需取用

这10个Skill覆盖了产品经理从需求发现到产品落地的完整链路。但我不建议一次性全装上—— 按需取用，效率最高。

工作阶段	推荐Skill	核心价值
需求探索期	Product Manager Toolkit + User Research	快速验证需求真伪
竞品调研期	Competitive Analysis + Product Framework	找准差异化定位
方案设计期	Mind Map + PM Toolkit – Excalidraw	把思路可视化
需求文档期	PRD Writer	确保PRD结构完整
数据验证期	Data Analysis	用数据说话
商业规划期	Socratic Business Model Canvas	把商业模式想透
日常协作期	Meeting Minutes	让会议有产出

最后提醒一点：Skill是工具，不是替代品。它们帮你提高效率、减少遗漏、结构化思考——但产品决策的 judgment，永远在你自己手里。

本文作者@Lucas ，前字节、腾讯 AI产品经理。

我是怎样使用 AI 构建 E2E 测试体系的？ | Viking

Mon, 08 Jun 2026 09:04:04 CST

问题

TinyShip是一个支持 Next.js、Nuxt.js、TanStack Start 三套前端框架组成的 monorepo，同时支持 PostgreSQL 和 SQLite，也就是说每改一个功能，有 6 种不同的组合可能出问题。当开发任何新功能的时候，保证应用完成新功能并起没有 regression 是非常重要的，假如手动测试工作量难以估量，我是开发基础的功能以后，在添加后续的功能的时候，发现没有 E2E 的测试，几乎是非常麻烦的，尤其是针对一个多框架多数据库支持的应用，流程都相似，重复性非常高，所以这里必须有一个开发新功能的时候的测试和验收流程。

基石

TinyShip 的基石是 E2E 测试，我认为在 AI Coding 时代，任何产品的基石都是测试，User Cases 比代码更宝贵。AI 让代码迭代速度从天变成小时，你一天可能重构 10 次，添加 20 个功能，每次改动都可能意外破坏现有功能。

虽然感觉 E2E 有点重，但是还是毅然将它们加上了，事实证明，有了 AI 的辅助任何看起来很繁琐的任务都实施起来都不难。我让它通过路由和页面分析核心交互，确定一些必须覆盖的关键流程（Critical User Journeys），然后编写 case，加上修改测试和我去 Review，总共也就只花了两天时间。它模拟真实用户在浏览器中的完整操作，保证 核心的流程必须 100% 有 E2E 覆盖，这样任何修改提交和后续的修改就有一个重要的依靠，对后续的功能开发是重要的。

五阶段流程

有了 E2E 的覆盖，我确定了一新的开发新 feature 的流程， TinyShip 开发新功能的时候定了五个阶段：Spec → Code → Verify → Test → Green，我将这套标准写入到根目录的 Agents.md 下面，这样 AI 可以第一时间按照我的流程完成功能。

核心思路是先想清楚要测什么，再写代码，然后用 agent-browser 走一遍视觉确认，最后写 Playwright 测试。顺序很重要。这套流程在 Agent 的 Plan 模式下就会被激活，伴随着技术方案的创建，在开始 build 以后会完成接下来的步骤。

       ┌─────────┐   ┌─────────┐   ┌──────────┐   ┌─────────┐   ┌─────────┐
│  SPEC   │──▶│  CODE   │──▶│  VERIFY  │──▶│  TEST   │──▶│  GREEN  │
│ 定义验收 │   │ 实现功能 │   │ 视觉确认  │    │ 写 E2E  │    │ 全通过  │
│ 标准     │  │         │   │          │    │ 测试    │    │        │
└─────────┘   └─────────┘   └──────────┘   └─────────┘   └─────────┘

Spec：先想清楚要测什么

每做一个新功能，第一步是让 AI 在 tests/e2e/TEST-CATALOG.md里写一段验收标准。就是用自然语言描述：打开哪个页面、点哪里、期望看到什么。例如之前已经有的一个用例，除了自然语言描述，还可以增加结构化字段。

       ## 8. 个人资料更新测试
**文件：** `specs/profile-update.spec.ts` ｜ **优先级：** P1

验证仪表盘中编辑个人资料的完整流程：进入编辑模式 → 修改姓名 → 保存 → 验证更新。

> 所有测试共用一个浏览器上下文（`beforeAll` 注册），按串行顺序执行。

| # | 测试名称 | 具体流程 |
|---|---------|---------|
| 1 | 个人资料标签页显示用户名和编辑按钮 | API 注册用户 → 访问 `/dashboard` → 验证用户名可见 → 验证 "Edit" 按钮可见 |
| 2 | 可以进入编辑模式并修改姓名 | 访问 `/dashboard` → 等待用户名加载 → 点击 "Edit" 按钮 → 验证 `#name` 输入框可见 → 清空并填入新姓名 → 点击 "Save" → 等待编辑模式关闭（"Edit" 按钮重新出现） → 验证新姓名显示在页面上 |

Code：写代码

这个没什么好说，按清单写代码。但写的时候要注意一点：保持三个 app 的一致性。互相充用的逻辑在 libs/*里实现，路由层尽量薄。这样 E2E 测试写起来也省事，三个 app 的测试逻辑基本一样。

Verify：用 agent-browser 预演一遍

代码写完了，页面跑起来了，接下来不是写测试，而是先用 agent-browser走一遍，agent-browser 是 Vercel Labs 专门为 AI Agents 设计的浏览器自动化 CLI。

为什么要使用 agent-browser ？

为什么多这一步？

首先因为 Playwright 测试是脆的——选择器经常要调。如果界面有明显的 UX 问题，写测试也是浪费，后面还得改。多次跑会非常慢，而且浪费 token。

agent-browser 基于 Rust + Playwright 底层，首先它极致节省上下文和 Token。传统 Playwright 或 Puppeteer 给 AI 喂一页 HTML/DOM 树，动辄几千到上万 token，很快就占满上下文。它使用语义化、精简的 Accessibility Tree + 简洁引用（如 @E_1、@E_3 - button “生成图片”），输出非常 compact，能节省 80%+ 的 token。并且它有 AI-First 设计，使用自然语言指令它理解的很好。

       # agent-browser 的返回举例，很有趣，只保留交互元素，没有 DOM tree，节省大量 Token。
- textbox "输入提示词" [ref=e1]
- button "选择文件" [ref=e2]  (上传按钮)
- combobox "模型选择" [ref=e3]  (下拉框)
- button "开始生成" [ref=e4]

# 交互采用上面的 ref 来实现，完全不用写 CSS 选择器。
agent-browser click @e4

在 Verify 阶段用 agent-browser 走完真实流程后，我们已经拿到了可靠的元素引用和实际 DOM 结构，此时再写 Playwright 测试的选择器成功率极高，基本一次就能稳定。而且三个框架的测试代码也可以高度复用，只需少量调整。

Test：写 Playwright E2E

UI 确认没问题了，才开始写 Playwright 测试。这时候选择器都知道了——哪个按钮是 [data-slot="select-trigger"]，哪个列表是 role="listbox"，哪个输入框的 placeholder 是啥。

为什么不在写代码之前就写好测试？

BDD 不就是先写测试的吗？

试过，不行。

E2E 测试跟单元测试不一样。单元测试是测试一个函数，输入输出都是纯数据，你可以在写代码之前先写测试。但 E2E 测试依赖真实的 DOM 结构—— [data-slot="select-trigger"]这种选择器，你不知道 UI 会长什么样之前根本写不了。而且三个框架（Next.js、Nuxt.js、TanStack Start）渲染方式不一样，同一个选择器可能在一个框架里有效，在另一个里失效。

所以我的做法是：用 BDD 的思维——先想清楚验收标准——但测试代码放在 UI 成型之后再写。

Green：三个 app 都跑通

最后一步，启动 Next.js app，跑一遍测试。然后换 Nuxt.js，再跑一遍。再换 TanStack Start，再跑一遍。三个都绿了，再切数据库，PG 和 SQlite，6 次测试都通过，这个功能才算做完。

切 app 和数据库让 AI 来，不需要手动，一个 app 跑完，切换另一个，跑相同的测试。

E2E 不在 CI 上跑

E2E 测试有个特征： 我不让它在 CI 上跑。

CI 上只跑 typecheck 和 build。为什么？几个原因：

慢。全量 E2E 跑完一个 app 大概 6 分钟，三个 app 要 18 分钟，再加上两个数据库 36分钟，CI 上排队这么久不划算。
依赖多。支付相关的测试需要 Stripe CLI 以及不同支付平台的各种环境变量，由于支持的服务非常多，要配置的环境变量很多。CI 上配这些要么麻烦，要么不安全。
CI 的目的是快速反馈——类型对不对、能不能编译。E2E 解决的是另一个问题：交互流程有没有坏。这俩不是一回事。

所以 E2E 我现在只在本地跑，每次发版前，三个 app 各跑一遍。

三种情况跑 E2E

E2E 不是天天跑全量的。我只在这几种情况跑：

情况	跑哪些
做完一个功能	只跑相关的 spec 文件
发版前	全部 spec，三个 app 都跑
大重构	全部 spec，三个 app 都跑

小修小补，跑个 typecheck + build 就够了。全量 E2E 是发版和重构是否才跑。

如果你也有多框架的项目，或者也头疼人肉测试成本太高，可以试试这套流程。

AI裁员陷阱：一场集体理性的经济自杀

Sun, 31 May 2026 22:44:16 CST

【AI裁员陷阱：一场集体理性的经济自杀】

沃顿商学院最新论文用数学推导出了一个恐怖闭环：企业用AI干掉员工提高效率，竞争对手被迫跟进。在微观上，每个老板都做出了最符合自身利益的理性选择；但在宏观上，被裁掉的员工恰恰也是市场上的消费者。

当全行业同时加速自动化，结果就是生产力无限飙升，而全社会的消费需求直接归零。这就是经典的“囚徒困境”在AI时代的放大版：大家都在拼命造出能生产一切的机器，却顺手消灭了所有能掏钱买单的顾客。更绝的是，模型测试了全民基本收入、资本税等各种药方，全部失效，唯一有解的只有“自动化碳税”——让企业在用AI替代人类时，必须为自己破坏的那部分市场需求当场买单。

这不是科幻，而是正在发生的纳什均衡。当个体理性叠加成集体疯狂，通往无限繁荣的快车道，稍不留神就会变成通往经济死局的传送带。

arxiv.org/abs/2603.20617

大公司的 AI 账本，没有一笔算得过来

Thu, 28 May 2026 21:09:14 CST

今年四月，Uber 的 CTO 发现了一件事：公司全年的 AI 工具预算，四个月就花完了，这件事是整个硅谷「token 消耗大比拼」的一个典型例子，我们之前也写过。

但就在几周后，Uber 的 COO Andrew Macdonald 在播客里给同事「补了一刀」： token 消耗和交付给用户的功能之间的联系，还不存在。

▲ Andrew Macdonald 图片来自：Business Insider

Uber 在去年底部署了 Claude Code，95% 的工程师每个月都在用，70% 的提交代码来自 AI，使用率惊人，账单也惊人。每个工程师每月的 API 调用费在 500 到 2000 美元之间，同一个人用同一个工具，同一天的消耗差异可以达到十倍。CTO 不得不说自己要推到重来，「因为我以为够用的预算，已经被吹走了」。

他们花了很多钱让 AI 写代码，但花的钱和最终产出之间，看不到因果关系。 钱确实花了，代码确实写了，但用户体验提高了多？新增了多少有用的功能点？问就是不知道。

另一个方向的同一个问题

Uber 的困境是钱花了，成效没出来，但很多公司选择的是另一条路，由于看到了 AI 的潜力而大举裁员，认为 AI 可以代替

不是给人买 AI 工具，而是用 AI 代替人，这条路的账算得过来吗？

Gartner 今年发布了一份调查，覆盖 350 家年收入超过十亿美元的全球企业，结果发现：80%的企业在部署 AI 后都裁了人。 可是裁员率和 ROI 之间，完全没有相关性，裁得多的公司和裁得少的公司，回报率几乎一样。

这个结果反直觉，但仔细想想又很合理。裁员省的是人工成本，但省下来的钱并没有变成新的业务价值。它只是让财报上的数字好看了一个季度，而不是让公司真的变得更强。Gartner 的结论很直接： 裁员可以腾出预算，但不创造业务价值。

AI 驱动的裁员，ROI 是零，为什么老板们还在做？本质上，裁员不是经营决策，是信号。对投资人说「我们在用 AI 了」的效果，和对董事会说「我们的运营效率在提升」的效果，都比真实的 ROI 重要得多。

Fortune 的分析把这叫做「AI washing」，用 AI 做借口裁员，实际上纯粹是在砍成本充利润，和 AI 能不能替代这些岗位，没有一点关系。

一个悖论

这样看，AI 会带来管理上的自相矛盾：用 AI 替代人，省了工资，但 ROI 没提升；给人用 AI，效率似乎提升了，但预算先爆了。

AI 工具的计费模式和传统软件完全不同。传统软件是按席位收费的，每个人每年多少钱，写进合同里，可以预测。但 AI 工具是按 token 收费的，用多少算多少，而且每个人的用量差异巨大。Uber 的数据显示，同一个工程师同一天的消耗可以相差十倍。这意味着传统的 IT 预算模型完全失效了，你没法在年初预测年底会花多少。

这像什么呢？ 像从固定费率的健身房会员卡，换成了按次计费的私教。你以前每个月交 299，去不去都那么多。现在每次去都要单独付费，去得越勤花得越多，而且你的员工各自去得多勤你完全无法控制。

不用吧，怕被淘汰；用吧，账算不过来。

钱去了哪里

Gartner 其实在报告里很克制地提了一句预测：到 2028 年到 2029 年，自主化业务反而会净增工作岗位。这听起来像没什么用的安慰，实际上它暗示的是现在裁掉的人，未来可能还得重新招回来。只不过到时候他们的岗位叫「AI 协调员」或者「模型运营」之类的，工资可能也不一样了。

打工人被裁了，公司也没赚到更多，预算还爆了。钱去了哪里？当然是 AI 公司的营收里。Anthropic 今年的年化收入已经突破十亿美元，OpenAI 更高。当 Uber 的 CTO 说「预算飘走了」的时候，那些被吹走的预算正好落在了 Anthropic 的账户里。

这是一个经典的淘金热结构。真正赚钱的从来不是淘金的人，是卖铲子和牛仔裤的人。现在的铲子是 API，牛仔裤是 token。每一家公司都在拼命用 AI，拼命让员工用 AI，拼命用 AI 替代员工——而 AI 公司在所有这些拼命的每一个环节里都在收钱。

AI 没有在省钱，它在换一种花钱的方式。

以前花在人身上，现在花在模型上；以前花在工资里，现在花在 token 里；以前花得可预测，现在花得无法控制。甚至，以前花的钱留在了员工手里，他们会拿去消费、娱乐、还房贷，钱在经济体里循环。

现在花的钱，直接进了几家硬件密集型、融资密集型的 AI 公司的账上，变成了下一轮 GPU 采购和下一轮融资的底气。

所以当你看到「某公司宣布用 AI 优化人力结构」的新闻时，可以翻译一下：我们把给员工的钱转给了 AI 公司，但我们并不确定这笔交易是否划算，我们只是知道，如果不做这笔交易，投资人会不高兴。

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

全球车企唯一！比亚迪半导体产业覆盖芯片全流程、全链路量产中国首款4nm制程智驾芯片

Thu, 28 May 2026 22:40:19 CST

DoNews消息 2026年5月28日，比亚迪召开“敢为”智能化战略发布会，董事长王传福表示：“电动化上半场看电池，智能化下半场看芯片。”由此，比亚迪重磅发布中国首款4nm制程智驾芯片——璇玑A3，加速推进智能化下半场进程，引领全球汽车行业智能化变革。

此外，继为智能泊车安全兜底后，比亚迪再次率先承诺为城市领航安全兜底1年，并宣布全系车型均可搭载天神之眼B 辅助驾驶激光版，选装价格12000元，开创全民城市领航时代，让好技术人人可享、人人放心享！

从人的真实需求出发比亚迪设立智能化下半场三大目标

过去几年，全球迎来新一轮人工智能发展浪潮，感知硬件、芯片的发展速度超乎想象，这些推动着汽车从单纯的出行工具进化为能主动思考的智能生命体。从人的真实需求出发，比亚迪为汽车智能化的下半场设定了三大目标：实现“零交通事故”，让辅助驾驶成为“超级司机”，让AI成为“超级秘书”。比亚迪将持续投入超1000亿的研发资金，解决交通安全问题，提升人类福祉。

二十四年厚积薄发比亚迪自研中国首款4nm制程智驾芯片

本次发布会上，比亚迪重磅发布中国首款4nm制程智驾芯片——璇玑A3，已开启规模化量产，支持L3、L4自动驾驶，通过三颗芯片的高效协同，实现超2100TOPS的总算力，同时兼顾功耗控制与算力利用率。作为中国首款自研4nm智驾芯片，它代表中国智驾芯片的最高水平：车规级4nm，不仅制程最先进，行业第一；而且单位算力功耗最低，较同级产品低20%。璇玑A3可结合比亚迪自研算法，深度优化，算力利用率提升100%，让辅助驾驶的反应更快，处理复杂问题的能力更强，安全上限更高，实现辅助驾驶全链路可控。

早在2002年，比亚迪就组建了自己的芯片团队——IC设计部，即比亚迪半导体的前身。24年来，比亚迪布局芯片、久久为功，先后做到车规级IGBT和SiC功率芯片技术国内最早量产装车，并两度荣获国家科学技术进步奖。至今，比亚迪已推出2000多款芯片产品，应用在智能汽车、消费电子、家用电器、工业设备、光伏储能五大领域。在更为严苛的车规级领域，比亚迪已成为中国最大的芯片企业，如今，已覆盖13大类，有567款芯片产品，广泛应用于46个国内外汽车品牌。

比亚迪之所以能够推出璇玑A3，在于其背后的研发底气：目前，比亚迪芯片研发团队超7000人，累计投入超千亿，拥有4大研发基地和5座晶圆制造工厂。其中，成都工厂是中国最大的、专注车规级的12英寸晶圆工厂。论及芯片制造流程，从产品定义、架构设计、电路设计、版图设计、晶圆制造、封装到测试七大步骤，比亚迪全面覆盖，是全球唯一一家拥有芯片全流程、全链路制造能力的车企。

比亚迪开创全民城市领航时代率先承诺为城市领航安全兜底

2025年2月，比亚迪推出“全民智驾”战略，宣布全系车型标配天神之眼辅助驾驶系统。此次发布会，比亚迪贯彻“让好技术人人可享”的理念，宣布开创全民城市领航时代：全系车型均可搭载天神之眼B 辅助驾驶激光版，选装价格12000元。此外，天神之眼C 的功能即将迎来重大升级，预计今年12月OTA。

去年7月智能泊车安全兜底推出后，天神之眼智能泊车功能的使用率从最开始的21%，提升至现在的93%，并且智能泊车事故率几乎为零。基于对天神之眼技术的信心和对消费者负责的态度，比亚迪再次率先承诺为城市领航安全兜底：即日起一年内，天神之眼A、天神之眼B 的新用户自提车之日起，老车主OTA升级至天神之眼5.0 后，均可享为期1年的城市领航兜底。用户在合规使用城市领航功能时，若发生有责任交通事故，应由本车承担的直接经济损失（包括车辆维修费用、第三方财产损失、人身伤害损失）将由比亚迪直接进行兜底赔付。

对比行业常见的智驾险，比亚迪的城市领航兜底全部免费、没有上限，且不会影响来年的商业险保费。自此，比亚迪成为全球首个城市领航和智能泊车安全“双兜底”的企业，用实打实的行动，让辅助驾驶真正融入用户的日常出行和生活，让用户收获安全体验。

比亚迪持续用技术改变世界。在电动化的上半场，比亚迪用第二代刀片电池及闪充技术一举攻克“充电慢”“低温充电难”的世界性难题；而在智能化的下半场，比亚迪致力于实现“零交通事故”的目标：将用天神之眼不断刷新辅助驾驶能力的上限，用兜底给予用户使用辅助驾驶的信心，用高算力智驾芯片布局未来的智能汽车体验，用实力守护每一位用户出行的驾乘安全。比亚迪董事长王传福表示：“真正的‘敢为’，从来不是无所畏惧，而是心怀对生命、对规则、对技术的敬畏，明知难而为之，始终做难而正确的事，敢为人先，一路向前！”

大模型强化学习阶段的后训练在做什么

Mon, 25 May 2026 15:01:34 CST

大模型强化学习阶段的“后训练”，通常是指在模型已经完成预训练（以及可能的监督微调）之后，再通过强化学习进一步优化模型的行为和输出。这个过程的核心目标是：让模型的输出更符合人类的偏好、价值观、安全性要求以及特定任务的目标。

简单来说，预训练让模型学会了“接话”的能力——根据上文预测下一个词；而强化学习后训练则教它“什么话该说、什么话不该说、怎么说更好”。

具体在做什么，可以分解为以下几个关键环节：

学习“偏好”与“准则”：模型需要理解人类的偏好。研究者会训练一个奖励模型，这个模型的作用就是给大模型的回答打分。这个奖励模型的训练数据，就是大量的人类标注数据——比如，对于同一个问题，人类标注者会对比两个不同回答，选出哪个更好、更安全、更有用。
通过“试错”优化策略：大模型（此时被视为一个“智能体”）针对一个输入，会尝试生成一个回答。之后，奖励模型会对这个回答打分（给出奖励值）。强化学习算法（最著名的是PPO，近端策略优化）会根据这个奖励值，调整大模型的参数，让它更倾向于生成能获得高奖励的回答，避免生成低奖励的回答。
平衡“探索”与“守成”：训练过程中，模型不能随心所欲地乱试（可能会生成胡言乱语）。强化学习算法通常会加入一个KL散度惩罚项，强制要求模型的新策略不能离它的“初始版本”（通常是监督微调后的模型）太远。这就像给模型加了一根“狗绳”，防止它在优化过程中彻底走偏，失去基本的语言能力。
针对特定任务优化：根据最终应用场景，后训练可以有不同的侧重点。例如：
- 提高有用性：让模型更愿意遵循指令、提供更详细准确的答案。
- 提高安全性：让模型学会拒绝回答有害、不道德或危险的问题。
- 提高真实性：减少“幻觉”，让模型在不确定时承认不知道。
- 对齐特定风格：让模型的回复语气、长度、格式符合产品需求。

一个非常典型的例子就是ChatGPT的训练过程：

第一步：预训练一个基础模型（GPT-3.5/4）。
第二步：监督微调（SFT），用人工写的高质量问答对训练模型学会对话格式。
第三步（这里就是强化学习后训练）：使用RLHF（人类反馈强化学习）。具体做法是：
- 让模型针对大量问题生成多个回答。
- 人类标注员对这些回答进行排序/打分。
- 用这些排序数据训练一个奖励模型。
- 用PPO算法，让模型通过不断生成回答并获取奖励模型反馈来优化自己。

核心价值：没有强化学习后训练，大模型可能只是一个能力很强但不怎么听话的“天才儿童”。而通过这个阶段，模型变得可控、可靠、有用。它解决了预训练模型“学富五车但不懂规矩”的问题。

与其他训练阶段的区别：

预训练：学习语言结构和世界知识（学什么）。
监督微调（SFT）：学习对话格式和简单指令（学着怎么回答）。
强化学习后训练：学习价值判断和策略选择（学会判断什么才是好的回答）。

所以，大模型的强化学习后训练，本质上是一个价值观对齐和行为优化的过程，是让通用大模型变成能直接服务用户的生产力工具的关键一步。

美国AI 基建全是鬼故事

Mon, 25 May 2026 10:22:13 CST

作者

@edzitron

调查了美国在建的数据中心得出了结论：AI 基建全是鬼故事。下面是文章精华总结：目前地球上没人建成过 1GW 的园区，英伟达却卖了 300 万块 Blackwell。（GW 就是功率单位，1GW = 10亿瓦。在数据中心里，它衡量的不是‘算力’，而是‘能吃多少电’；）这些芯片在哪？在仓库里吃灰吗？建一个数据中心要多久？到底有多少真正上线了？这两个简单的问题，回答起来却难得出奇。为什么？因为超大规模厂商（Hyperscalers）既不披露数量，也不披露可用容量。过去一周，作者试图寻找 2023 或 2024 年开工并已竣工的数据中心，结果是一无所获。大多数项目要么深陷审批泥潭，要么就是个“部分启用”的烂摊子，却对外宣称“已投入运营”。事实很简单：目前没人建成过 1GW 的数据中心。 Stargate Abilene 吹嘘 1.2GW，两年过去了，只有两栋楼亮着灯，约 103MW。第三栋楼建好了，但里面空空如也。就连亚马逊那个所谓的 2.2GW 项目，30 栋楼里只有 7 栋在用，却被 CNBC 和亚马逊自己包装成“全面投入运营”。这就是骗局，赤裸裸的。然后是微软。纳德拉说过去两年新增了 4GW，本季度又加了 1GW。我也希望能信，但我找不到。作者通过卫星看了威斯康星州的 Fairwater 项目。微软说 400MW，但按照每兆瓦 1400 万美元的成本，33 亿美元的投资只对应 235MW。卫星图像显示，那地方基本上就是几块混凝土板。当地报纸说，里面还在做启动测试，根本没上线。作者在北卡罗来纳州、俄亥俄州、巴西、威尔士找了一圈。要么还在挖土，要么连土都没开始挖。微软的公关要么不回，要么就在胡扯“进度超前”。这导致了一个荒谬的结论：如果微软真的建了 4GW，那它必须秘密建成了十几个巨型园区，且没有一家媒体报道。这不可能。微软在过去六个月里，连 500MW 都没上线。那些所谓的“1GW 新增产能”，要么是会计魔术，要么是还没通电的空房子。这就引出了英伟达的问题。黄仁勋说过去四个季度出货了 600 万块 Blackwell（实际是 300 万颗，他把双核算进去了）。 300 万块 Blackwell 的功耗是 3.6GW。如果这些芯片真的在跑，我们需要 35 个 Stargate Abilene 那样的园区。但它们在哪？它们不在。它们堆在仓库里吃灰。 Blackwell 需要全新的散热和电力，旧数据中心装不下。这就是为什么 Supermicro 有价值 14 亿美元的 GPU 积压在库存里，也是为什么 Oracle 取消了 10 亿美元的订单。 Anthropic 租借 xAI 的老数据中心就是一个绝望的信号。那是马斯克用燃气轮机搞出来的、污染严重的“弗兰肯斯坦”怪物，里面塞满了老芯片。如果真有那么多崭新的千兆瓦级数据中心上线，Anthropic 为什么要急着去租这种垃圾？总结一下这场闹剧：微软、谷歌、Meta 在过去三年烧了 8000 亿美元 Capex。他们声称拥有数 GW 的产能。实际上，真正跑起来的可能只有几百 MW。英伟达把未来 2-3 年的 GPU 都卖出去了，但这些芯片没地方放。 OpenAI 和 Anthropic 承诺了 7480 亿美元的未来支出，但这取决于这些鬼数据中心能不能建成。感觉不对劲吗？是的。这感觉就像 2000 年的互联网泡沫，或者 2022 年的 FTX。我们正处于一个基础设施与财务数据完全脱节的时代。折旧费用已经开始暴涨，但当那几百亿的账单真的到来时，大家会发现，我们建的不是算力帝国，而是一片由混凝土板和公关稿组成的鬼城。我不相信有超过 100 万块 Blackwell 在运行。你们呢？看完这篇，你再看美股估值会觉得脊背发凉。 #AIBubble #Stargate #Microsoft https://wheresyoured.at/where-are-all-the-data-centers/…

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向量化模型保证了结果的质量。两者结合，才造就了我们今天使用的所有高效、智能的搜索引擎。

IT社区推荐资讯 - ITIndex.net

产品经理必装的10个Skills：从需求到落地的全链路AI武装

一、Product Manager Toolkit —— PM的”瑞士军刀”

二、Competitive Analysis —— 竞品分析的”专业外包”

三、User Research —— 用户研究的”方法论教练”

四、Data Analysis —— 数据驱动的”分析助手”

五、PRD Writer —— PRD撰写的”结构教练”

六、Meeting Minutes —— 会议纪要的”自动秘书”

七、Mind Map —— 思维整理的”可视化工具”

八、Product Framework —— 产品架构的”设计工具”

九、Socratic Business Model Canvas —— 商业模式的”追问教练”

十、PM Toolkit – Excalidraw —— 产品思维的”可视化翻译器”

安装建议：按工作阶段按需取用

我是怎样使用 AI 构建 E2E 测试体系的？ | Viking

问题

基石

五阶段流程

Spec：先想清楚要测什么

Code：写代码

Verify：用 agent-browser 预演一遍

为什么要使用 agent-browser ？

Test：写 Playwright E2E

为什么不在写代码之前就写好测试？

Green：三个 app 都跑通

E2E 不在 CI 上跑

三种情况跑 E2E

AI裁员陷阱：一场集体理性的经济自杀

大公司的 AI 账本，没有一笔算得过来

另一个方向的同一个问题

一个悖论

钱去了哪里

全球车企唯一！比亚迪半导体产业覆盖芯片全流程、全链路 量产中国首款4nm制程智驾芯片

大模型强化学习阶段的后训练在做什么

美国AI 基建全是鬼故事

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 定律

全球车企唯一！比亚迪半导体产业覆盖芯片全流程、全链路量产中国首款4nm制程智驾芯片

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