硅谷 AI 见闻：百万美金年薪的模型大战与创业公司的生存之道

感谢 AWS 的邀请，让我有机会参加 AWS re:Invent 2025。在这次美国之行中，我不仅参加了这场全球顶级的技术大会，更有幸与 OpenAI、Anthropic、Google DeepMind 等硅谷顶级 AI 公司的多位一线从业者进行了深入交流，其中大多数观点都得到了不同公司专家的交叉验证。

从 Las Vegas 的 re:Invent 会场，到 San Diego 的 NeurIPS，再到湾区的 AI 公司，十几天的密集交流让我学到了非常多。主要包括以下几个方面：

AI 辅助编程（Vibe Coding）的实践经验： 分析了不同场景下效率提升的差异，从创业公司的 3-5 倍提效，到大厂和研究机构效果有限的原因。

基座模型公司的组织与资源配置： 分析了 Google、OpenAI、xAI、Anthropic 等公司的优劣势，包括算力资源、薪酬结构，以及模型团队与应用团队的合作现状。

Scaling Law 的一线视角： 一线研究员普遍认为 Scaling Law 并没有结束，与 Ilya Sutskever、Richard Sutton 等顶级科学家的公开言论存在分歧。工程方法可以解决 Sampling Efficiency 和 Generalization 问题，基座模型还有很大进步空间。

科学化的应用开发方法论： 介绍了顶级 AI 应用公司普遍采用的 Rubric-based Evaluation 体系。

Context Engineering 的核心技术： 讨论了应对 Context Rot 的三大技巧：动态系统提示、动态加载 Prompts（Skills）、Sub-Agents 与上下文总结。以及文件系统作为 Agent 交互总线的设计模式。

创业公司的战略选择： 基于资源和人才的现实约束，分析了创业公司应该避开的领域（通用 Benchmark）和应该专注的方向（垂直领域 + Context Engineering）。

Slides (HTML)

---

一、 Vibe Coding（AI 编程）

1. 对 Vibe Coding 观点的两极分化

在与多家硅谷公司（包括顶级 AI Coding 创业公司、OpenAI、Google、Anthropic 等）的从业者深入交流后，我们发现一个共识：Vibe Coding 的效果呈现两极分化。

某些场景下，效率提升可达 4-5 倍，但另一些场景下，AI 几乎帮不上忙，甚至会帮倒忙。关键在于：任务性质、组织类型、代码类型的不同。

场景一：创业公司的 MVP 开发（效率提升 3-5 倍）

为什么起飞？

1. 从 0 到 1 的原型开发：

   • 最重要的是速度和寻找 PMF（Product Market Fit）
   • 不需要在复杂的现有系统上修修补补
   • 对代码质量要求相对较低，重点是快速验证
   • 可以每周甚至每天上线新功能来快速试错

2. 技术栈相对简单：

   • 通常使用主流框架（React、Django、FastAPI 等）
   • AI 在这些主流技术栈上的训练数据充足
   • 大量 Boilerplate 代码可以直接生成

3. 团队小，沟通成本低：

   • 不需要跨部门协调
   • 决策快，执行快
   • Code Review 流程简单

典型任务：

• CRUD 业务逻辑
• 简单的 API 开发
• 前端表单和页面
• 数据处理脚本

场景二：One-off Scripts 和 CRUD Code（所有公司适用，效率提升 3-5 倍）

通用的高效场景：

1. 一次性脚本（One-off Scripts）：

   • 数据分析脚本
   • 数据迁移脚本
   • 批量处理工具
   • 用完即弃，对质量要求不高

2. 胶水代码（Plate/Boilerplate Code）：

   • 配置文件
   • 数据转换层
   • API 调用封装
   • 测试用例生成

为什么效果好？

• 任务边界清晰，输入输出明确
• 不需要深入理解复杂的业务逻辑
• 即使出错，影响范围有限
• 即使是 OpenAI、Google 的研究人员，也大量使用 AI 写这类代码

场景三：大厂的日常开发（效率提升有限）

为什么效果打折扣？

1. 编码时间占比低：

   • 大厂工程师大部分时间不是在写代码
   • 时间分配：开会 30%、扯皮/协调 20%、写文档 20%、定位 Bug 15%、写代码 15%
   • AI 只能优化最后 15% 的时间

2. 系统复杂度高：

   • 需要深入理解现有架构
   • 涉及多个团队的代码
   • 需要考虑向后兼容
   • AI 容易引入 regression

3. 代码审查严格：

   • 多轮 Code Review
   • 需要通过各种 lint、测试
   • 上线流程长
   • 即使 AI 写得快，后续流程时间不变

适合 AI 的任务：

• 重构中的重复性工作
• 测试用例补充
• 简单的 Bug 修复
• 文档生成

场景四：Research Code（几乎不适用）

为什么 AI 帮不上忙？

1. 智力密集型代码：

   • 修改模型架构（如 Attention 结构）
   • 调整训练算法
   • 数据配比优化
   • 可能只改 3 行，但需要想很久

2. AI 自己也不懂：

   • 这些是前沿研究，训练数据中没有
   • 需要深厚的理论背景
   • 需要创新思考
   • AI 目前无法替代

3. 高度定制化：

   • 每个研究项目都是独特的
   • 不存在”标准做法”
   • 需要大量实验和调试

研究人员使用 AI 的方式：

• 只用来写辅助脚本（数据分析、可视化）
• 不用来写核心算法
• 将核心逻辑留给人类

场景五：核心基础设施代码（不适用，可能帮倒忙）

为什么要谨慎？

1. 性能敏感：

   • 延迟要求极高
   • 需要手动优化
   • AI 生成的代码通常不是最优的

2. 稳定性要求高：

   • 任何 Bug 都可能导致大规模故障
   • 需要对边界情况有深入考虑
   • AI 容易遗漏 corner cases

3. 安全性关键：

   • 认证、授权相关代码
   • 加密、签名逻辑
   • 不能有任何疏漏

结论： 这类代码最好还是人来写

2. Vibe Coding 的最佳实践（来自硅谷一线团队）

如何防止 AI 把代码写乱？综合多家公司的经验，我们总结了一套工程化流程：

2.1 PR 行数限制

核心原则：单个 PR 严格控制在 500 行以内

• 对 AI 的意义：

  • 过长的上下文容易导致幻觉和逻辑崩坏
  • 任务边界清晰，AI 不容易”跑偏”
  • 减少不同模块间的耦合风险

• 对人类的意义：

  • 500 行是人类 Code Review 的认知极限
  • 超过这个数量，Review 质量会大幅下降

• 具体标准（因场景而异）：

  • 后端 / Agent 核心代码： 500 行
  • 前端 React 代码： 可以放宽到 2000 行
  • 测试用例： 可以超过 500 行（例如生成 100 个测试 case）

• 如何做到？

  • 人的职责： 提前做好需求拆分和任务分解
  • 这是 Vibe Coding 中”人的核心价值”之一

2.2 全自动化的多 Agent 协作工作流

业界领先的 AI Coding 公司的完整自动化流程：

Step 1: 自动触发编码

• 线上出现 Issue 或有新的 Feature 需求
• 系统自动创建 bug/feature ticket
• 自动触发 Coding Agent（如 OpenAI Codex 或 Claude Code）开始写代码

Step 2: “三堂会审”的 Review 机制

• 代码生成后，不会直接提交 PR
• 自动触发 3-5 个不同的 Review Agents 并行执行
• 这些 Agents 的配置：
  • 不同的基座模型
  • 部分是购买的第三方 Code Review 服务

Step 3: 自动化测试

• 同时运行自动化测试套件
• 包括单元测试、集成测试
• 测试必须全部通过

Step 4: 生成 PR 的条件

• 必须满足：
  • 3-5 个 Review Agents 都认为”没有问题”
  • 所有自动化测试通过
• 满足后： 自动生成 PR 并通知相关人员 review

Step 5: 人类 Final Review

• 人类做最后的 approve
• 检查 AI 可能遗漏的业务逻辑问题
• 检查是否符合项目整体架构
• 决定是否合并

对于简单问题： 这个流程可以做到完全自动化，人只需要做最后的确认即可

2.3 测试驱动的质量保障

核心理念： 把 AI 当作”不太靠谱的初级程序员”

1. 完善的测试用例

   • 必须有充足的测试覆盖
   • 测试用例是 AI 代码的”安全网”
   • 没有测试的代码不允许 AI 随便改

2. 测试用例的保护

   • 不能让 AI 随便删除或修改测试用例
   • 只允许 AI 在指定的范围内修改测试
   • 防止 AI 为了”让测试通过”而删除测试

3. Rubric-based Benchmark

   • 建立内部的评测标准（类似第六章讲的 Evaluation）
   • 针对不同场景有不同的评价指标
   • 可以自动化打分，快速验证改动的效果

2.4 大型重构的处理方式

对于无法在 500 行内完成的大型重构或新特性开发：

人机协作流程：

1. 人先写 Design Document

   • 详细的技术设计文档
   • 明确架构和模块划分
   • 定义接口和数据流

2. 任务拆分

   • 根据 Design Doc 拆分成多个子任务
   • 每个子任务控制在 500 行以内

3. 人机分工

   • 核心业务逻辑： 人来写
     • 对性能要求极高的部分
     • 对业务理解要求很深的部分
     • 涉及复杂架构决策的部分
   • 边缘代码： AI 来写
     • 数据转换、格式化
     • API 调用的封装
     • 重复性的 CRUD 操作
     • 测试用例生成

4. 迭代和集成

   • AI 先写一版
   • 人 review 后决定保留或修改
   • 逐步集成，持续测试

2.6 Code Ownership 原则

核心原则： 每个人有明确的 Code Ownership

---

二、顶级 AI 公司的应用开发：”科学方法论”

这次与 Google DeepMind、OpenAI 和 Anthropic 的应用开发团队的交流，让我最大的震撼在于顶级 AI 公司做应用的科学性和严谨性。他们不是在”试”Prompt，而是在”测”系统。

虽然三家公司的具体实践有所不同，但核心理念高度一致：数据驱动、严格评估、持续迭代。

1. 严格的 Evaluation System（评估体系）

1.1 Rubric-based 评估的核心理念

顶级 AI 公司做应用不上线”凭感觉”，而是建立了一套 Rubric-based Evaluation System（基于细则的评估体系）。

上线标准：

• 系统会对每个 Case 的每个 Metric 进行自动化打分
• 任何版本上线前，所有 Metric 必须达到一定的指标
• 如果某项指标达不到，必须经过高层特批，并提交明确的后续整改计划

2. 数据飞轮与自动化迭代

2.1 测试数据集的构建与维护

专人负责数据集构造：

• 每个功能模块都有专门的测试数据集
• 有专人负责根据线上 Bad Cases 构造和维护数据集
• 持续更新，发现新问题就加入数据集

2.2 全自动化评测流程

评测周期：

• 通常需要几个小时跑完几百个 Cases
• 晚上提交任务，早上看结果

自动化打分：

• 使用 LLM 作为 Judge
• 每个 Metric 有专门的 Prompt 来评判
• 根据预定义的 Rubric 进行打分

Human Eval：

• 请人标注数据，评价结果
• 能达到超过 LLM Judge 的真人标注成本非常高

3. 基础模型团队与应用团队的分工

模型团队的优先级（Priority）：

1. 四大 Benchmark：

   • Math（数学能力）
   • Coding（代码能力）
   • Computer Use（电脑操作）
   • Deep Research（深度研究）

2. 长期模型能力提升：

   • 智力提升
   • 通用能力增强
   • 这些是他们认为对模型长远发展最重要的

3. 垂直领域需求：

   • 排在非常低的优先级
   • 基本不会被响应

共同特点：应用团队难以影响模型团队

重要启示：基座模型公司内部做应用 ≈ 外部创业公司做应用

• 都面临同样的限制：

  • 用同样的基座模型 API
  • 无法影响模型训练方向
  • 无法要求针对性优化

• 基座模型公司 App 团队的两个优势：

  • 可以更方便地找到模型团队 Review Prompt，改进 context engineering。但创业公司也有机会找到基础模型厂商的工程师，例如 AWS re:Invent 就提供了与 Anthropic 面对面讨论的机会，在 Anthropic 展台前他们的工程师给了非常多具体的 Agent 优化建议。
  • Token 成本走内部计价，比外部公司调用 API 便宜很多。例如 Cursor 的 API 成本远高于 Claude Code 的订阅费用

• 外部创业公司的优势：

  • 可以用多家模型： Google 内部只能用 Gemini
  • 可以做 Mashup Agent： OpenAI + Anthropic + Gemini 混用
  • 更灵活的技术选型

---

三、 硅谷巨头众生相：优势、劣势与内幕

1. Google DeepMind：四大优势与两大软肋

优势一：创始人高度重视 + 强大的组织能力

• Sergey Brin 回归：

  • ChatGPT 发布后，Google 联合创始人 Sergey Brin 亲自重返公司

• Demis Hassabis 的领导力：

  • DeepMind CEO，技术和管理都极强
  • 能把几千名聪明人凝聚到一起
  • 避免了严重的内耗和政治斗争
  • 虽然也有合并带来的一些摩擦，但整体团队向心力强

• 和其他公司的对比：

  • Meta： 扎克伯格不亲自管 AI，下放给 Alexandar Wang，Alexandar Wang 也不亲自管细节，又下放给团队
  • 微软、苹果： 高层对 AI 技术细节的理解有限

• 为什么 Gemini App 被并入 DeepMind？做应用本质上是 Research：

  • 需要科学的方法论
  • 需要大量实验和数据驱动
  • 需要完善的 Evaluation 体系
  • 这和做 Research 的思维模式一致

优势二：算力资源碾压

• TPU + GPU 双轨：

  • 自研的 TPU，有持续的产能
  • 多年采购的 Nvidia GPU 积累
  • 总算力可能是 OpenAI 的数倍

• 模型规模的优势：

  • OpenAI 主力模型： GPT-4o 系列，几百 B 参数
    • 虽然演进了几代，但参数规模一直没有大幅增加
    • 主要通过 Test-time Scaling（思维链）提升能力
  • Google 的模型：
    • Gemini 2.5 Pro / 3 Pro：数 T 参数，比 OpenAI 主力模型大一个数量级
    • Gemini 3 Flash 的参数规模就和 GPT-4o 差不多，比 Gemini 2.5 Flash 大很多

• 为什么 OpenAI 不用更大的模型？

  • 算力不够：训练和 Serving 都需要大量资源
  • 用户太多：ChatGPT 仍是 AI 行业的招牌，超过 10 亿用户，API 调用量巨大
  • Gemini 的用户量约 6 亿，API 调用量约为 OpenAI 的 1/5
  • 所以 Gemini 可以”任性”地用更大的模型

优势三：人力资源充足

典型案例：图片生成模型的团队对比

• Nano Banana Pro（Gemini 的图片生成模型）：

  • 算法团队：不到 10 人
  • 数据、infra 团队：近 1000 人

• OpenAI 的对应模型：

  • 算法团队：不到 10 人
  • 数据 + Infra 的人数：差一个数量级

• 人多的优势体现在哪？

  • 可以针对特定场景构造大量训练数据
  • 例如：原理图、九宫格图片等
  • 这些都需要人工标注和构造数据
  • 今天的基座模型仍然高度依赖人类构造的数据，光靠互联网数据是远远不够的

优势四：生态入口的天然优势

• 浏览器（Chrome）：

  • 右上角直接集成 Gemini 按钮
  • 比 ChatGPT Atlas、Perplexity Comet 浏览器体验更好
  • 可以直接问当前页面的问题，总结长文

• Workspace 集成：

  • Google Calendar：可以让 Gemini 订日历
  • Google Drive：可以让 Gemini 读写文档
  • Gmail：可以让 Gemini 处理邮件
  • 这些都是天然的用户基础

• YouTube 数据：

  • 多年积累的视频数据
  • 多模态训练的宝贵资源

• 搜索引擎：

  • Google Search 直接展示 AI Summary
  • 成为新的流量入口

劣势一：大公司的效率问题

• 流程冗长：

  • 做数据集、Evaluation 需要大量时间
  • 产品迭代速度远不如创业公司
  • 对比：OpenAI（中型公司）的迭代速度都比 Google 快

• 内部人员的感受：

  • 他们最担心的就是 OpenAI 和创业公司的速度
  • 自己虽然资源多，但是”船大难掉头”

劣势二：只优化通用需求，不做垂直领域

• 模型团队的优先级：

  1. 通用 Benchmark
  2. 模型智力和长期能力提升
  3. 垂直领域需求基本没有精力响应

• 这对创业公司意味着什么？

  • 机会窗口： 垂直领域是创业公司的机会
  • Google 不会来抢： 目前来看，细分场景也需要大量 context engineering 工作，不是通用数据飞轮就能搞定的
  • 技术平等： 我们用的模型和 Gemini App 团队用的一样

---

2. OpenAI：焦虑、学术包袱与资源困境

焦虑的来源

• 品牌虽强，但压力巨大：
  • 虽然是 AI 的”扛把子”，品牌认知度最高
  • 但内部非常焦虑 Google 的追赶
  • Google 在资源、算力、数据上都占优

人才结构的问题

招了太多学术背景的人：

• 学术思维 vs. 工程思维的冲突：

  • 学术人员想验证自己的学术想法
  • 但这些想法在工程上可能不实用
  • 在 xAI 这绝对不会发生，Elon Musk 不会允许这样做

• 资源分配的矛盾：

  • 2023 年 Ilya Sutskever 等核心科学家离职
  • 主要原因：认为 Sam Altman 资源分配不公
  • 太多资源用于 Serving 线上用户，训练新模型的资源不足

算力资源的困境

• OpenAI 的两难：

  • 用户最多： 超过 10 亿用户
  • 算力有限： 不如 Google 富裕
  • 必须权衡： 在训练和 Serving 之间平衡

• 对用户体验的妥协：

  • 早期 ChatGPT Plus（$20/月）暴力截断 Context
  • Context Window 只有 32k tokens
  • 导致严重幻觉：丢了前面的上下文，后面全是胡说
  • 我当时的体验：传一本书让它总结，前几页还行，后面全是幻觉
  • 所以我后来不订阅，直接调 API

• 大小模型路由的争议：

  • GPT-5 搞自动路由，小问题用小模型
  • 但路由不准确，重要问题被分到小模型
  • 用户看不到是哪个模型在回答
  • 体验下降，引起很多投诉

OpenAI 的优势：Codex

• Codex 做得确实好：
  • 代码生成能力很强
  • 针对真实使用场景做了大量优化
  • 不只是针对 Benchmark

---

3. xAI (Elon Musk)：极致卷与零容忍的结果导向

“No Research Engineer, only Engineer”

• Elon Musk 的宣言：

  • 我们没有 Research Engineer，只有 Engineer
  • 意思：不要搞学术研究，只要工程结果

• 和 OpenAI 的对比：

  • OpenAI 有大量学术背景的人浪费资源尝试一些论文里面的 idea，导致工程交付 delay
  • xAI 绝对不允许这种情况发生

工作强度：全员 70+ 小时/周

• “绝不让机器等人”的文化：

  • 工程师每周工作 70 小时以上是常态
  • 为了不浪费训练时间：
    • 晚上 12 点爬起来看 Loss 曲线和各种指标
    • 发现有问题立刻 resubmit
    • 否则第二天又浪费十几个小时

• 对比其他公司：

  • OpenAI、Anthropic、DeepMind： 核心团队普遍 60+ 小时/周
  • xAI： 全员 70+ 小时/周，每天都要来办公室
  • Google 非核心部门： 一周上 3 天班

---

4. Anthropic：专注 Coding 和 Agents

战略聚焦：

• 第一优先级：Coding
• 第二优先级：Agents（包括 Computer Use）

在御三家和 xAI 中，Anthropic 的研究氛围是最浓厚的。 例如 Anthropic 在可解释性方面，有一系列经典 blog。

Anthropic 在开发者社区建设上做得最好： 从技术输出到实际支持，Anthropic 都展现出了对开发者的重视和帮助意愿。

领先的技术创新：

1. Claude Skills：

   • 虽然看起来是 Claude 的功能，但本质是通用技术
   • 其他模型也可以学习和实现类似机制
   • 展示了 Context Engineering 的最佳实践

2. Artifacts：

   • Anthropic 最早提出的交互模式
   • 现已成为行业标准
   • 很多产品都在学习和模仿

3. Claude Code：

   • 目前最好用的 Coding Agent
   • 在实际开发中表现最稳定
   • Context Engineering 做得最到位

丰富的公开资源：

• 大量 Context Engineering 的公开文档和教程
• 技术博客和论文分享
• 开发者指南和 Cookbook

对 Startup 的实际支持：

Anthropic 非常愿意帮助创业公司优化 Context Engineering，很多 Startup 都有途径直接获得他们的帮助。

个人经历分享：

在 AWS re:Invent 的 Expo 上，我们在 Anthropic 的展台前聊了一下午。Anthropic 的工程师给了非常多、非常具体的 Context Engineering 优化建议，针对我们的具体业务场景：

• 如何设计 Evaluation 体系
• 如何设计 Sub-Agent 架构
• 如何优化 System Prompts
• 如何利用 Skills 机制

这种实打实的技术支持，对创业公司来说非常宝贵。他们不仅提供工具，更愿意帮助开发者用好工具。

---

5. 薪酬与人才战争：AI 的”军备竞赛”

天价年薪的真相

• 刚毕业的 Top PhD：

  • 年包：$150-200 万美元
  • 条件：研究水平比较高
  • 大部分是 Options（期权），但 OpenAI 已经很大，可以兑现

• 在 Top AI 公司经验有一些经验的算法工程师：

  • 年包：$400-500 万美元
  • 条件：在 Top AI 公司有一定经验，或者有一些知名的学术工作

• Meta Super Intelligence 级别的大神：

  • 年包：超过 $1000 万美元/年
  • 主要是 Meta 股票（可以兑现）
  • “一亿美金招聘”的新闻是真的

• 第一波薪酬拉升：

  • Meta 的 Super Intelligence 团队开始疯狂挖人
  • 把整个市场的薪酬水平拉起来了

AI vs. 非AI 的薪资差距

• 同级别工程师，3-4 倍差距：

  • 非 AI 工程师： $25-30 万/年（Google 正常水平）
  • AI 工程师： $100 万+/年
  • 差距是 3-4 倍

• 这意味着什么？

  • 会 AI 和不会 AI，薪资天差地别
  • 行业已经高度分化

Marketing 投入巨大

• 旧金山机场出来： 高速公路两侧几十公里，几百个广告牌，基本全是 AI 公司

• Snowflake 等传统公司也在讲 AI 故事

• 有趣的广告：

  • Redis： “My boss really wants you to know we’re an AI company”
  • （我老板非常想让大家知道我们是AI公司）
  • 所有公司都在往 AI 靠

AI 人才战：类比团购大战，但玩法完全不同

当年团购 vs. 现在 AI：

• 团购大战（互联网时代）：

  • 钱花在：招运营、做地推、打广告
  • 核心是：抢市场、抢商户、抢用户
  • 人海战术，谁的运营团队大谁赢

• AI 大战：

  • 钱花在：招顶尖人才 + 买 GPU
  • 核心是：训模型、拼算力、抢人才
  • 精英战术，谁的研究团队强谁赢

资源投入的数量级对比：

• 基座模型公司的核心 Research 团队：
  • 人均算力配置： 500-1000 张 GPU/人
  • 人均薪酬： 超过百万美元/年
  • 人的薪酬和卡的成本在同一数量级

基座模型公司的资源困局：只能做”大事”

资源多 = 必须做影响最大的事：

1. 每个人的机会成本极高：

   • 必须做能影响数亿用户的通用能力
   • 不能让这些人去做垂直领域的小场景

2. 为什么不做垂直领域？

   • 垂直领域市场小，ROI 算不过来
   • 让年薪几百万的人做一个垂直行业？投入产出比太低

3. 只能聚焦通用能力：

   • Math, Coding, Computer Use, Deep Research 等
   • 这些是影响所有用户的基础能力，这才配得上他们的资源投入

结论：这是创业公司的机会窗口

---

6. 对创业公司的战略启示：如何在巨头夹缝中生存？

启示一：不要和基座模型公司正面硬刚

Startup 千万不要碰的领域：

1. 通用 Coding Agent
2. 通用 Deep Research
3. 通用 Computer Use

为什么 Startup 会输？

• 招不起人：

  • 真正懂模型训练的人，年薪非常高
  • Startup 融资几百万到几千万美元
  • 招几个人，钱就没了

• 算力不够：

  • 训一个通用模型，即使是后训练，也需要几百到几千张卡
  • Startup 租不起这么多卡

• 数据不够：

  • 通用能力需要海量高质量数据
  • 大厂有生态优势（YouTube、Web Search）
  • Startup 拿不到这些数据

结论： 除非是含着金钥匙出生，否则不要碰通用领域

启示二：不要轻易碰模型训练

模型训练的门槛极高：

1. 真正懂模型的人太贵：

   • 这些人都在大厂，不会轻易出来
   • Startup 根本挖不起

2. 中等水平的人，做不出竞争力：

   • 训练模型需要大量 trial and error
   • 新手很容易把钱烧光，模型还没训出来

3. 开源模型 + 微调的困境：

   • 开源模型质量比闭源差 2 个数量级
   • 微调很难弥补这个 gap
   • 除非是极度偏门的垂直领域

什么时候可以考虑训练？

• 只针对特定场景的小模型（如 8B/32B）
• 领域比较偏门，通用模型能力不足
• 有明确的数据优势

启示三：Startup 的最佳人才战略

核心原则：招聪明、学习能力强，但没有 AI 背景的人

为什么这个策略有效？

1. AI 领域发展太快，复利效应弱：

   • AI 的最佳实践每 3-6 个月就变一次

2. 新人可以快速走到前沿：

   • 聪明 + 学习能力强 + 肯钻研
   • 6-12 个月就能达到业内中等偏上水平
   • 不需要 PhD，不需要大厂背景

3. 成本优势巨大：

   • 5-10 倍的成本差距

启示四：Startup 应该做什么？垂直领域

核心战略：Go Vertical（聚焦垂直领域）

巨头不会为每个细分领域优化，这是 Startup 的机会窗口。需要建立三大核心能力：

1. 专业的 Context Engineering

这不是简单的工作，需要非常专业的技能：

• 巨头不会为每个细分领域投入这么多精力
• 需要深入的领域知识（Domain Knowledge）
• 需要和客户反复打磨（Customer Iteration）
• 这些是大公司不愿意/做不了的

2. 构建 Domain Knowledge Base（领域知识库）

通用 LLM 不懂你的行业，知识库是竞争优势：

• 数据和知识的积累需要时间
• 竞争对手很难短期内复制
• 随着时间推移，优势会越来越大

3. 针对实际业务场景建立 Feedback 数据飞轮

从第一天就要考虑数据飞轮，这决定你能走多远：

• 捕获用户的真实交互和反馈
• 从生产环境的失败中学习
• 用真实数据优化 Prompt 和知识库
• 持续改进 Agent 性能

启示五：保持心态，等待你的 Wave

不要被 AI 人才的天价薪酬焦虑

看到 AI 人才动辄百万甚至千万美元的年薪，很容易产生焦虑和挫败感。但我们需要理性看待这个现象：

每个人和公司都有不同的发展阶段：

• 他们为什么能拿这么高的薪酬？
  • 因为他们赶上了这一波 Wave
  • 在正确的时间，做了正确的事情
  • 积累的技能刚好匹配当前的需求

关键是：Stay Relevant

1. 在没有 Wave 的时候，不要放弃：

   • 踏踏实实把基础打好
   • 例如，不要认为别人 CV/NLP 的积累在 LLM 时代是没用的
   • 不要因为暂时看不到机会就躺平

2. 把团队准备好：

   • 组建一支工程能力强、学习能力强、凝聚力强的团队

3. Stay Relevant：

   • First Principle Thinking（第一性原理思考）
   • 紧密跟踪最前沿的产品和研究

4. Stay Ahead of the Curve：

   • 预判模型和产品的趋势
   • 当 Wave 来临时，你已经准备好了

5. 等待并抓住你的 Wave：

• 当机会来临时，你是否能够快速做出产品来，并能快速 go to market？
• 当用户量迅速增长时，你的数据飞轮构建起来了吗？ChatGPT、Gemini App、Cursor 都是有数据飞轮的。

---

7. 硅谷 AI 圈的工作常态

核心团队普遍高强度工作

• 每周工作时间：

  • OpenAI、Anthropic、DeepMind 核心团队：60+ 小时
  • xAI：70+ 小时
  • Google 非核心部门：<30 小时（摸鱼）

• 为什么这么卷？

  • 训练模型是周期很长的事情
  • 提交一个 Task，几小时后可能崩了
  • 如果不及时处理，又浪费十几个小时
  • 所以大家都很重视不浪费机器时间

典型的一天

• 下午 5-6 点：

  • 准备下班前，提交一个训练任务
  • 回家吃饭

• 晚上 12 点：

  • 爬起来看一眼结果
  • 发现崩了，赶紧调整
  • 可能弄到凌晨 2-3 点
  • 重新 submit

• 第二天早上：

  • 到公司看结果
  • 如果昨晚没处理，又浪费了一晚上

不同公司的文化差异

• Anthropic：

  • 只要求 25% 时间在办公室
  • 但工作任务很重，实际每周工作时间在 60 小时以上

• xAI：

  • 必须每天到办公室
  • 极致的执行力和纪律

• Google 非核心部门：

  • 一周只上 3 天班
  • 但 AI 核心团队完全不是这样

---

8. Scaling Law：一线研究员 vs. 顶级科学家的认知分歧

在与多家顶级 AI 公司的一线研究员交流后，我发现一个有趣的现象：Top 公司的一线研究员普遍认为 Scaling Law 并没有结束，这与 Ilya Sutskever、Richard Sutton、Yann LeCun 等顶级科学家的公开言论存在明显分歧。

为什么会有这种分歧？

一线研究员认为，Ilya、Sutton、LeCun 等大神虽然是学术界的泰斗，但相对脱离一线工程实践。他们指出的问题确实都很重要：

• RL 的 Sampling Efficiency（采样效率）问题
• 模型的 Generalization（泛化能力）问题

但一线研究员的态度是：这些问题都有工程上的解法。

工程方法如何解决这些问题？

1. Sampling Efficiency 差 → 算力来补，大力出奇迹

• RL 的采样效率确实比 Supervised Learning 低很多
• 但只要有足够的算力，暴力采样也能 work
• 这正是顶级公司砸钱买 GPU 的原因之一

2. Generalization 差 → 人工构造领域数据 + RL 环境

一线研究员的总结：

• Midtrain / SFT： 人工构造高质量的领域数据进行继续训练
• 领域数据集： 针对具体场景收集和标注数据
• Sim Env（模拟环境）： 构建仿真环境，让模型在可控环境中学习
• Rubrics-based Reward： 基于评分细则的奖励机制，而不是简单的 binary feedback

这套方法论可以解决大量实用领域的问题，虽然不是”银弹”，但工程上确实 work。

基座模型还有很大的进步空间

一线研究员的共识：不管是 Pretrain 还是 Posttrain，都没有看到天花板。

• 发布节奏： 目前每半年发布一个大版本
• 能力提升： 每个版本都有明显的能力跃升
• 预期： 还有很大的进步空间，不必过于悲观

理想化的 Continual Learning 确实还在 Research 阶段

Ilya、Sutton 所描述的那种不需要人干预、自主持续学习的理想化 Continual Learning，一线研究员承认目前确实处于 Research 阶段，没有这么理想的方法。

但关键是：工程上的方法都是能 work 的。虽然需要人工干预和大量工程投入，但能产出实际的效果。

具体细节上，不同公司的认知差异很大

有意思的是，在具体的技术细节上，不同公司的人的理解和认识不太一样，有些人搞通了，有些人还没搞通：

案例一：RL 中的 Learner-Sampler Mismatch 问题

• 部分研究员认为： 这个问题对较大尺寸模型的训练稳定性有很大影响，需要特别处理
• 另一部分研究员认为： 在实践中没有遇到太多此类问题，影响不大

案例二：Linear Attention / Hybrid Attention

• 部分研究员认为： Linear Attention 会降低基座模型的 CoT 能力和 Instruction Following 能力，不太 scale，不建议用
• 另一部分研究员认为： Linear Attention Layer 强迫模型从 Context 中压缩提取知识，压缩成一个 Compact Representation 本身就是学习知识的过程，对模型整体的 in-context learning 能力不仅没有损害，反而是有帮助的

小模型验证 → 大模型 Scale 的共识

虽然具体细节上的认识不同，但一线研究员有一个强共识：

每一项技术在小规模模型上能 work，在大规模模型上不一定能 work。

典型的实验路径：

1. 4B/8B 规模： 先在小模型上验证想法是否可行
2. GPT-OSS 规模（例如 GPT-OSS 120B A20B）： Scale 到中等规模，看是否还能 work，以及在 MoE 模型下是否能 work
3. 生产尺寸： 最终 Scale 到最大规模的生产模型

这也是为什么顶级公司需要那么多算力： 不仅要训练大模型，还要训练大量小模型来做实验。

---

四、核心技术实践：Context Engineering 与文件系统

1. Context Engineering（上下文工程）

这是 Anthropic 团队重点强调的技术方向，也是我们和多位专家深入讨论的核心话题。

2.1 Context Rot（上下文腐化）问题

什么是 Context Rot？

• 定义： 上下文中充斥着大量不相关信息，占据模型注意力
• 后果：
  • 模型容易被无关信息干扰
  • 推理能力下降
  • 容易出现前后矛盾的信息导致混淆

典型场景：

• 在第 100 行说了一件事
• 在第 200 行又说了另一件事，可能和前面矛盾
• 模型需要在几万 token 中做完整推理
• 很容易”犯傻”，忽略某些关键信息

2.2 三大核心技巧（来自 Anthropic 的最佳实践）

技巧一：Dynamic System Hints（动态系统提示）

核心理念：

• 不是所有信息都需要在整个对话中保持
• 应该动态压缩和更新 System Prompt
• 把前文的关键信息总结后，重新注入 System

实现方法：

1. 识别对话的阶段转换点
2. 在转换点做一次总结
3. 将总结的内容更新到 System Prompt
4. 原始的详细对话可以丢弃或归档

为什么不是所有模型都支持？

• Claude 的优势： 训练时专门优化了这个能力
  • Skills 机制就是基于此
  • 可以动态加载新的 System Instructions
• GPT 和 Gemini：
  • 训练数据中没有专门针对这个场景
  • 动态加载的效果不如 Claude
  • 更适合在开头就把所有规则放好

技巧二：Dynamic Loaded Prompts（动态加载，Anthropic Skills）

Anthropic 的 Skills 机制：

• 核心思想：

  • 不是在对话中间插入新的 prompt
  • 而是动态更新 System Prompt
  • 模型训练时专门优化了这个场景

• 适用场景：

  • 对话进入新的阶段
  • 需要新的专业知识或规则
  • 前面的某些规则不再适用

• 和传统方法的区别：

  • 传统： 所有规则一次性加载
  • Skills： 根据需要动态加载
  • 优势： 减少 Context 中的噪音

其他模型的替代方案：

• Kimi： 总结前文 + 开新的 Sub-Agent
  • 把前面的关键信息总结
  • 以新的 System Prompt 启动子任务
  • 不在同一个对话中无限延长

技巧三：Sub-Agents & Summarization（子代理与总结）

为什么需要 Sub-Agent？

• 隔离上下文：

  • 某个独立任务不需要知道完整的对话历史
  • 只需要知道任务本身的输入和要求
  • 避免无关信息干扰

• 典型场景：

  • Main Agent 在协调整体流程
  • 遇到一个独立的数据处理任务
  • 启动 Sub-Agent 去做
  • Sub-Agent 只看到任务描述，不看到完整对话

Cloud (Anthropic) 的最佳实践：

• 强烈推荐 Sub-Agent：

  • “如果一个任务是独立的，最好隐藏其他上下文”
  • “不要让无关细节一直带着”

• Main Agent 和 Sub-Agent 的信息传递：

  • 通过文件系统（后面会详细讲）
  • Main Agent 写文件，Sub-Agent 读文件
  • 清晰的输入输出边界

Summarization 的策略：

• 什么时候总结？

  • 完成一个阶段性任务后
  • Context 即将超过窗口限制时
  • 发现模型开始出现混乱时

• 总结什么？

  • 关键决策和结论
  • 重要的中间状态
  • 不要总结所有细节

• 总结后的使用：

  • 更新 System Prompt（如果模型支持）
  • 或开启新的 Sub-Agent
  • 原始 Context 可以归档

2.3 Context Engineering 的实战案例

案例 1：Deep Research Agent

• 问题：

  • 需要阅读大量文档
  • 需要多轮搜索和分析
  • Context 很容易爆炸

• 解决方案：

  • 阶段 1（搜索）： Main Agent 负责规划搜索策略
  • 阶段 2（分析）： Sub-Agent 分析每篇文档
    • 只接收文档内容和分析目标
    • 不需要知道前面搜索了什么
  • 阶段 3（综合）： 新的 Agent 综合所有分析结果
    • 读取所有 Sub-Agent 写的分析文件
    • 生成最终报告

案例 2：Coding Agent

• 问题：

  • 代码仓库很大
  • 需要多次迭代修改
  • 容易在某个文件上迷失

• 解决方案：

  • 规划阶段： Main Agent 理解需求，列出要改的文件
  • 实现阶段： 为每个文件启动 Sub-Agent
    • 只看这个文件和相关接口
    • 不看整个对话历史
  • 集成阶段： Main Agent 验证所有改动是否协调

2.4 不同模型的 Context Engineering 策略

Claude (Anthropic)：

• ✅ 优先使用 Skills 机制
• ✅ 动态加载 Prompts 效果最好
• ✅ 训练时专门优化了这个场景

GPT (OpenAI) 和 Gemini (Google)：

• ❌ 不推荐动态加载（效果不好）
• ✅ 所有规则在开头的 System Prompt 中定义好
• ✅ 使用 Sub-Agent 来隔离任务
• ✅ 需要新规则时，总结 + 新 Agent

通用建议：

• 充分利用每个模型的特性
• 不要硬套其他模型的最佳实践
• 根据具体场景选择合适的模型

2. 文件系统作为 Agent 的交互总线

Anthropic 的核心观点：Coding Agent 是所有通用 Agent 的基础。

Manus 在一篇上下文工程的经典文章中，也指出文件系统是 Agent 的核心。

3.1 为什么要用文件系统？

Tool Call 一次输出大量内容的问题：

• 不稳定：

  • Tool Call 一次输出几百行
  • 如果中途中断，前面的工作全白费
  • 无法恢复

• 不可迭代：

  • 输出就是输出，无法修改
  • 想改某一段，需要重新生成全部
  • 无法做”草稿-修改-定稿”的流程

文件系统的优势：

• 持久化：

  • 写入文件后，内容被保存
  • 即使 Agent 崩溃，文件还在
  • 可以恢复继续

• 可迭代：

  • 可以读取文件，修改某一部分
  • 可以多次修改，逐步完善
  • 就像人写文档一样

• 通用性：

  • ls：列出文件
  • read_file：读取内容
  • write_file：写入内容
  • edit_file：修改内容
  • delete_file：删除文件
  • 所有模型都理解这些操作

3.2 Coding Agent 作为基础能力

为什么说 Coding 是基础？

• 广义的 Coding：

  • 不只是写 Python/Java 代码
  • 包括写文档、写报告、写任何结构化内容
  • 核心是：文件的读写和编辑

• Deep Research 的案例：

  • 需要生成一份长研报
  • 错误做法： 一次性用 Tool Call 输出整个报告
    • 几千行内容，容易中断
    • 写完后无法修改
  • 正确做法： 使用文件系统
    • 先写第一章 -> write_file("report.md", ...)
    • 调研更多信息
    • 写第二章 -> append_file("report.md", ...)
    • 发现第一章需要修改 -> edit_file("report.md", ...)

所有主流模型都有很强的 Coding 能力

3.3 Main Agent 和 Sub-Agent 的信息传递

为什么用文件系统而不是函数调用？

• 函数调用的限制：

  • 需要序列化复杂数据结构
  • 字符串长度有限制
  • 不够灵活

• 文件系统的优势：

  • Main Agent： 写入任务描述和输入数据到文件
  • Sub-Agent： 读取文件，执行任务，写回结果文件
  • Main Agent： 读取结果文件，继续下一步
  • 清晰的输入输出边界，就像 Unix 管道

---

五、 重点 Q&A 实录

Q1: 垂直领域做微调（Finetune）还是用闭源模型？

结论：闭源模型 + Context Engineering > 开源模型 + Finetune

理由：

1. 知识密度差距：

   • 闭源模型领先开源模型两代
   • 训练数据质量更高
   • 参数效率更高

2. 思维密度的差距：

   • 开源模型（如 Qwen、Kimi）思维链特别长
   • 需要靠延长思考时间来换效果
   • 闭源模型的 CoT 更紧凑高效

3. 泛化能力的差距：

   • 开源模型主要针对公开 Benchmark 优化
   • 在非 Benchmark 场景泛化能力较弱
   • 闭源模型有大量内部 Benchmark，泛化更好

什么时候用开源 + 微调？

1. 领域极其偏门：

   • 公网上基本没有相关数据
   • 必须通过微调注入领域知识

2. 数据隐私要求：

   • 不能把数据发到国外
   • 必须本地部署

3. 成本极度敏感：

   • 用量巨大，API 成本难以承受
   • 自己部署开源模型更划算

MiniMind 微调的案例：

• 实验背景：

  • 100MB 的超小模型
  • 尝试微调复杂对话数据

• 失败原因：

  • 数据太难了，超过了模型能力
  • 小模型只能学简单知识（如”北京是中国首都”）
  • 学不会复杂的逻辑推理

• 教训：

  • 要用适合模型能力的数据
  • 官方 MiniMind 训练数据都是小学水平的知识
  • 太难的数据会导致模型训崩

Q2: 个人化（Personalization）是真问题吗？

是真问题，而且是未来的核心竞争力

为什么重要？

• 推荐系统的演进：

  • 传统：人人日报，大家看一样的内容
  • 字节：每个人看到的都不一样
  • 字节认为：每个人生活在不同的世界，有不同的价值观
  • 这种个性化产品更符合人性，用户更愿意用

• AI 的未来也是如此：

  • 不应该只有一个 Universal Value（普世价值）
  • 应该适应每个用户的价值观和偏好
  • 细节上的价值观差异很大

技术难点：

1. Factual Information（事实信息）相对容易：

   • 生日、地址、卡号、工作信息
   • 记住就行，没有歧义
   • 我们已经做得不错

2. User Preference（用户偏好）非常难：

   • 上下文依赖性强：

     • 用户在写论文时要求学术格式
     • 不代表写旅游攻略也要学术格式
     • AI 容易过度泛化偏好

   • 一次性行为 vs. 长期偏好：

     • 用户说”昨天我点了川菜”
     • 不能记成”用户喜欢吃川菜”
     • 可能只是朋友喜欢，或者一时兴起

   • 需要极精细的 Evaluation：

     • 必须有数据和测试来平衡
     • 不能靠感觉

Q3: 端云协同 Agent 的前景和挑战？

前景：必然趋势

• 为什么需要端云协同？
  • Agent 需要在后台持续运行
  • 不能占用前台（用户还要用手机）
  • 云端算力更强，可以运行大模型

核心挑战：APP 状态同步

1. 登录状态的问题：

   • 用户在手机上登了微信
   • 云端 Agent 也要登微信？
   • 微信只允许一个客户端，会互相踢掉

2. 风控问题：

   • 云端 IP 和手机 IP 不一样
   • 可能在不同国家
   • 容易触发风控，被封号

3. 重复登录的麻烦：

   • 所有网站和 APP 都要在云端重新登录
   • 用户体验很差
   • 隐私担忧

解决方案：系统级的状态同步

• 豆包手机的尝试：

  • 在本地搞了个”影子系统”
  • Agent 在后台操作 APP
  • APP 以为自己在前台
  • 用户在前台操作真正的前台
  • 两个系统并行，互不干扰

• 更理想的方案：

  • 需要 Android/iOS/鸿蒙 系统级支持
  • 能够把 APP 状态同步到云端
  • 云端 Agent 操作云端的 APP 镜像
  • 需要时再同步回手机
  • 10 年前有公司做跨端状态迁移，现在可能成为基础能力

• 端侧 vs. 云侧：两个维度

  • Agent 运行位置： 端侧 or 云侧
  • 模型运行位置： 端侧 or 云侧
  • 这是两个独立的维度，可以灵活组合

Q4: 对我们使用 AI 写代码有什么建议？

核心原则：人必须懂的比 AI 多

• 为什么？
  • 你要能 Review AI 写的代码
  • AI 会犯错，需要人来发现问题
  • 特别是简单的语法错误，AI 能发现
  • 但复杂的架构问题，AI 很难发现

角色转变：从 Coder 到 Architect + Reviewer

新的工作流程：

1. 需求拆解（人）：

   • 把大需求拆成小任务
   • 每个任务 500 行以内
   • 明确输入输出

2. 编码实现（AI）：

   • AI 根据任务描述写代码
   • 可以并行多个 AI

3. 自动化测试（AI）：

   • 运行测试用例
   • 确保功能正确

4. 代码 Review（AI）：

   • 5-6 个不同的 Review Agents
   • 从不同角度检查代码
   • 全部通过才生成 PR

5. Final Review（人）：

   • 人做最后的把关
   • 检查业务逻辑
   • 检查架构一致性
   • Approve 或要求修改

500 行限制的灵活性：

• Python 后端核心代码： 500 行
• 前端 React： 1000-2000 行（有很多 Boilerplate）
• 测试用例： 可以更多（比如 100 个测试）
• C 语言： 相应增加（语言本身比较 verbose）

跨文件？当然可以

• 500 行是指单个 PR 的总行数
• 可以修改多个文件
• 关键是任务要小，容易 Review

Q5: 如何保证模型升级后工作流还能正常运行？

唯一的答案：Evaluation

为什么 Evaluation 如此重要？

1. 模型会升级：

   • 基座模型每几个月就升级一次
   • 每次升级可能破坏现有的工作流
   • 需要快速验证兼容性

2. Prompt 会调整：

   • 经常需要优化 Prompt
   • 改了 A，可能破坏 B
   • 需要全面的回归测试

3. 避免主观判断：

   • 不能靠手动测几个例子
   • 一是花时间
   • 二是不客观，容易遗漏问题

完整的 Evaluation 体系：

1. 测试数据集：

   • 从线上提取代表性 Cases
   • 持续更新

2. Rubric-based 评估：

   • 不只看整体好坏
   • 拆分成多个细项指标
   • 每项独立评分

3. 自动化运行：

   • 换个模型，跑一遍测试
   • 几小时后看报告
   • 客观对比数据

4. 持续优化：

   • 发现新问题，加入数据集
   • 形成闭环

手动 Evaluation 的替代方案：

• 如果没有自动化系统，至少维护一个手动测试清单
• 每次上线前，逐个测试关键场景
• 虽然慢，但总比没有强

Q6: 如何获取 AI 前沿信息？

最推荐：X (Twitter)

• 为什么是 X？

  • 国内朋友圈三大顶会（新智元、机器之心、量子位）的消息都来自 X
  • 第一手的论文、技术讨论
  • 很多大佬在上面分享

• 怎么用 X？

  • 关注技术大佬
  • 关注一些专门推论文的账号

Q7: 顾此失彼的 Prompt 怎么办？

两个解决方案：

1. Evaluation 防止 Regression

• 改了 Prompt，全面测试
• 确保没有破坏其他功能
• 数据驱动，客观评估

2. 结构化的 Prompt 组织

• 不要堆砌规则：

  • ❌ 101 条军规，一直往下加
  • ✅ 像写书一样，有层次结构

• 要类似新员工手册：

  • 不是简单的规则列表
  • 而是有逻辑的指导书
  • 考虑各种情况和例外

---

本文由我开发的 AI Agent 根据口述整理而成

Slides (HTML)